OpenStack Object Storage Administation Manual(Essex1.4.8)(Jun 5,2012)
の冒頭だけ翻訳してみました。
翻訳..といってもとりあえず意味がわかればいいとおもったので
Yahoo翻訳に毛の生えた修正をしただけですが..
※翻訳内容..というか私の英語力にも一切責任を持ちません..
正式な日本のコミュニティの翻訳などが既に公開されているのであれば
コメントでリンクを紹介していただけると助かります。
Computeの方を先に翻訳しようかとも思ったのですが、
アーキテクチャのところを読むと、
OpenStackではswiftがどうもカナメになっているので
ここを適当なパラメータでセットアップするとまずいかもしれないとおもったもので..
認証機能であるkeystoneも重要なのですが..
単独文書がぱっとみ見当たらなかったなあ..
1. OpenStackの利用開始
OpenStackは、非常にスケーラブルなオープンソースのクラウド・コンピューティング・ソフトウェアを提供するオープンソース技術の集合体です。現在、OpenStackは2つの関連したプロジェクトを拡張します：
- OpenStack Compute：仮想マシンとネットワーク管理を用いたコンピューティングパワーを提供
- OpenStack Object Storage：冗長な、スケーラブルなオブジェクト記憶容量のためのソフトウェア
OpenStackと密接に関係しているプロジェクトとして、Glanceと呼ばれるイメージ・サービス・プロジェクトがあります。
OpenStackの利用者は、プライベートもしくはパブリック・クラウドとして大規模なクラウド配置を展開する企業、サービスプロバイダ、VARS、SMB、研究者、そしてグローバルデータセンタなどです。
OpenStackとは何か？
OpenStackは、パブリック/プライベートクラウドを構築するためのオープンソースソフトウェアです。OpenStackは、さまざまな組織へ仮想マシンやクラウドストレージ導入を助けるコミュニティでありプロジェクトです。OpenStackには、OpenStack Compute(コードネームnova)、OpenStack Object Storage(コードネームswift)、OpenStack Image Service(コードネームglance)を含むコミュニティによって維持されているオープンソースプロジェクト群が内包されています。OpenStackは、クラウド組織化のためのオペレーティングプラットフォームやツールキットを提供します。
一旦クラウドコンピューティングのコンセプトを明確にすれば、OpenStackはより簡単に定義されます、しかし我々はあるミッション（プライベート/パブリッククラウド・大規模/小規模両方における、スケーラブルで、弾力性のあるクラウドコンピューティングの提供）上にあります。そのミッションの中心は、クラウドは実装が単純であるべき、そしてクラウドは非常にスケーラブルであるべきという、一対の基本的な要件です。
もしあなたがOpenStackに不慣れであるならば、あなたは疑う余地なくインストール、配備や利用に関する質問をするでしょう。それは最初は抗いがたいことのように見えます。しかし、恐れないでください。あなたを導き、オンランププロセス（一般道から高速道へ入る手順）の間に遭遇する問題の解決を支援する情報を得る場所があります。プロジェクトがあまりにも新しくそしてあまりにも頻繁に更新されるので、すべての情報の改定日を確認して下さい。もしあなたが数カ月前の文書を読んで正しくないと感じたならば、 https://launchpad.net/~openstack のメーリングリストを通じて我々に更新・削除する旨を教えてください。
OpenStackのコンポーネント
OpenStackには主に3つのコンポーネント(Compute、Object Storage、Image Service)で構成されています。順番に見ていきましょう。OpenStack Compute は、クラウド・ファブリック(構造)・コントローラで、ユーザもしくはグループのどちらかのための仮想インスタンスを開始するために使用されます。また特定のプロジェクト（オープンソースの..ではなくOpenStack上の）の複数インスタンス含む、それぞれのインスタンスやプロジェクトを設定するために使用されます。
OpenStack object Storage は、冗長性とフェールオーバーを内装した非常にスケーラブルで大容量システムにおける、オブジェクトを格納するためのシステムです。Object Storageは、アーカイブデータのバックアップを取得したり、画像や動画（ブラウザで使用するストリーミングデータ：多分このあたりPDF自身が文字化けしている）を提供したり第2第3の静的データを保管したり、データストレージ統合のための新規アプリケーションを開発したり、ストレージ容量を予測が困難な場合にデータを保管したり、あなたのWebアプリケーションのための弾力的で柔軟なクラウドベースストレージをつっくたりする、様々なアプリケーションを保有しています。
OpenStack Image Serviceは、バーチャル・マシン・イメージのための検索・照会システムです。OpenStack Image Service は、イメージを保存するためにOpenStack Object Storeを使用する、AmazonのSimple Storage Solution(S3) ストレージディレクトリを使用する、もしくはS3へのアクセスの中間サーバとしてOpenStackを使ってS3ストレージを使用する、3つの方法で構成できます。以下の図は、お互いがどのような関係であるのか、そしていかにオープンソースクラウドコンピューティングのゴールを果たすことができるのか、といったプロジェクト間の基本的な関係を示しています。
OpenStackプロジェクト アーキテクチャ概要
（ケン・ペプル著）
OpenStack Compute(nova) アーキテクチャについて投稿した私の初期のブログを見なおすことが一番良いと私は思います。今回は、単一のサービスのアーキテクチャの詳細を説明する代わりに、一緒に活動している OpenStack プロジェクトの全体を紹介します。
皆さんの理解のレベル合わせのために、OpenStackプロジェクトのコンポーネントや歴史の概要を説明しましょう。プロジェクトは、2010年RackspaceとNASAによって設立され、４つのバージョンをリリースし、4月に5番目のバージョン("Essex" もしくは"2012.1")をリリース予定です。
当初それは"コア"サービスのトリオで構成されていました：
- Object Store(Swift) はオブジェクトストレージを提供します。ファイルの格納・照会を行うことができます（しかし、ファイルサーバのようにディレクトリをマウントすることは出来ません）。幾つかの企業がSwiftベースの商用ストレージサービス提供しています。KT、Rackspace(Swiftを作り始めた)、そして私の会社Internapの3社です。実際、このブログ投稿のための画像はInternap Swift実装経由で提供されています。
- Image(Glance)は、仮想ディスクイメージのためのカタログやリポジトリを提供します。これらのディスクイメージは、ほとんどの場合、一般的にOpenStack Compute内で使用されています。このサービスが技術的にオプションである間は、どんなクラウドでも必要となるでしょう。
- Compute(Nova)は、オンデマンドな仮想サービスを提供します。AmazonのEC2サービス同様、Elastic Block Service(EBS)と類似するボリュームサービスも提供します。Internap社は、Novaで構築された商用コンピューティングサービスを提供します、そしてこのサービスはMercado LibreやNASA(Novaを作り始めた)の組織内にて使用されています。
次のリリースでは2つの新しい"コア"プロジェクトを推進します：
- ダッシュボード(Horizon) は、すべてのOpenStackサービスのためのWebベースのUIモジュールを提供します。
- Identity(Keystone)は、すべてのOpenStackサービスのための認証認可機能を提供します。そしてそれは特定の配置サービスの範囲内のサービスカタログも提供します。
これらの新しいプロジェクトは、オリジナルの３つのプロジェクトを支援するための追加的なインフラを提供します。
概念アーキテクチャ
OpenStackプロジェクトは全体的に、"非常にスケーラブルなクラウドオペレーティングシステムを提供する"ためにデザインされています。これを実現するために、各々の構成するサービスは、完全な Infrastructure as a Service(IaaS)を提供するために、一緒に動作するようにデザインされています。各サービスが提供する（そして次に使用することが可能）、パブリックなアプリケーション・プログラミング・インタフェイス(API)を通して、各サービスの統合を実現しています。これらのAPIが他のサービスを使用するために利用が許可されている間、APIがメンテナンスされている限りは実装者に対してもサービスの外部利用を許可します。これらのは、（ほとんどが）クラウドのエンドユーザが利用できるAPIと同じです。
以下のように、概念的にサービス間の関係を描くことができます：
- Horizonは、他のOpenStackサービスのWebフロントエンドの提供
- Novaは、仮想ディスク(Image)やGlanceの関連するメタデータの読み書き
- Glanceは、Swift内の実際の仮想デスクファイルを保存
- すべてのサービスは（最終的に）Keystoneを用いて認証をうける（予定）
上図は、最も一般的な設定下で実装者はすべてのサービスを一緒に使用していると仮定した、様式化され簡略化されたアーキテクチャのビューです。この図は、クラウド"オペレータ"側のみを表現しています（どうやってクラウド利用者が実際に使用しているかについては描かれていません）。例として、多くのComputeユーザが Object Storageをヘビーに（直接）使用しているとします。
論理アーキテクチャ
あなたの予想通り、実際の論理アーキテクチャは上図で見ていただいた概念アーキテクチャよりはるかに複雑です。いかなるサービス指向アーキテクチャの場合と同様に、すべての可能性のあるサービス通信組み合わせを例示しようとためしても、図はすぐに"ぐちゃぐちゃに"なります。以下の図において、私は最も一般的であると信じて、OpenStackベースのクラウドの統合アーキテクチャを示しています。
上図の説明は以下のとおりです：
- エンドユーザは、一般的なWebインタフェイス(Horizon)もしくは直接各サービスのAPIを経由して相互接続することが可能
- すべてのサービスは、一般的なソース(Keystone経由により容易化）を経由して認証を行う
- 個々のサービスはお互いのパブリックAPI(特権の必要な管理コマンドが必要な場合を除く)を経由して相互接続する
下記のセクションでは、さらに各サービスのアーキテクチャを掘り起こします。
ダッシュボード
Horizonは、エンドユーザーおよび管理者のOpenStackサービスのインターフェースを提供するDjango Webアプリケーションモジュールです。
大抵のWebアプリケーションと同様に、アーキテクチャは適正かつシンプルです。
- Horizonは、ふつうはApacheのmod_wsgi経由で配置されます。コア自身はロジック(様々なOpenStack APIと相互接続)やプレゼンテーション(異なるサイトのためにカスタマイズが容易)の大部分が再利用可能なpythonモジュールとして分離されています。
- データベース（どちらにも設定可能）。大部分は他のサービスのデータに依存するため、自身は大変小さなデータしか格納しません。
ネットワークアーキテクチャの観点から、このサービスは、各々のサービスのパブリックAPIと通信することができるような、利用者へのアクセス許可が必要です。もしあなたが（例えば、他のサービスのために、など）管理者の機能を使用したい場合、管理APIエンドポイント（このAPIは非利用者がアクセス可能であるべき）への接続も必要です。
Compute
Novaのアーキテクチャは実際あまり変化はありませんでした。EC2互換性とコンソールサービスのために、いくつかの新しいヘルパーサービスを追加しました。
- nova-apiはエンドユーザへCompute APIおよびVolume APIコールを許可・応答します。OpenStack API、Amazon EC2 API、そして特別な管理API(管理作業を行う特権ユーザのために)をサポートします。いくつかのポリシー（大部分はクオータチェック）を強制するだけでなく（インスタンスの実行のような）オーケストレーションアクティビティの多くも実行します。Essexリリースでは、nova-apiはモジュール化されており、実装者に特定のAPIのみの実行を許可します。
- nova-computeプロセスは、ハイパバイザAPI(Xen API(XenServer/XCP)、libvirt(KBM/QEMU)、VMwareAPI(VMware)など)を経由して仮想マシンインスタンスの作成、停止を行う、ワーカーデーモンが中心です。作成・停止を実行するプロセスはかなり複雑ですが、基本はシンプルです：キューからアクションを受領し、一連の（KVMインスタンス開始、のような）システムコマンドを実行し、データべース上のステータス更新を実行します。
- nova-volumeは作成を管理し、Computeインスタンスの永続ボリューム(機能的にAmazon Elastic Block Storageに類似)のアタッチ・デタッチを行います。iSCSIやCephのRados Block Deviceなど、様々なプロバイダからボリュームを使用することができます。
- nova-network ワーカーデーモンは、nova-computeやnova-volumeと大変似ています。キューからネットワーキングタスクを受領し、（ブリッジインタフェイスのセットアップやiptablesのルール変更などのような）ネットワーク操作のためのタスクを実行します。
- nova-scheduleプロセスは、概念的にOpenStack Novaの中で最もシンプルなコードです：キューから仮想マシンインスタンスリクエストを取得し、どこで実行するべきか（具体的には、どのComputeサーバホストで実行すべきか）を定義します。
- キューはデーモン間のメッセージを伝達するための中央ハブ機能を提供します。これは、ほかの(Apache Qpidのような)AMPQメッセージキューでも実装可能ですが、現在では RabbitMQによって実装されています。
- SQLデータベースストアは、大部分のクラウドインフラのビルドタイム状態やランタイム状態を格納します。状態には、使用可能か、インスタンスが使用可能 か、ネットワークやプロジェクトが使用可能かなどのインスタンスタイプを含んでいます。それゆえ、OpenStack Novaは、SQL-Alchemyによってサポートされている様々なデータベースをサポートしていますが、現在（テストや開発作業のためだけの使用であ れば）sqlite3、MySQL、PostgreSQLが広く使用されています。
最後の2つのリリースの間に、Novaはコンソールサービスを増やしました。
コンソールサービスは、proxy経由での仮想インスタンスのコンソールへのアクセスをエンドユーザに提供します。これは、新しい２つのデーモン（nova-consoleとnova-consoleauth）を含んでいます。
Novaは疑わしいものすべて（認証機能のためのKeystone、イメージ機能のためのGlance、そしてWebインターフェイス機能のHorizon）と相互接続します。ですが、Glanceとの相互接続は興味深いです。nova-computeがイメージ作成での利用イメージをダウンロードする間、APIプロセスは更新やGlanceの照会が可能です。
Object Store
Swiftアーキテクチャは、水平方向へのスケールと同様に、いかなるシングルポイントでの失敗を防ぐために、分散されています。OpenStack Object API経由でリクエストを受け付けるProxyサーバもしくはローレベルのHTTPも含まれています。
ファイルアップロード（メタデータやコンテナ作成の更新）のためにファイルを受領します。その上、Webブラウザへリストされるファイルやコンテナも提供する。Proxyサーバは、パフォーマンス向上のためにオプションのキャッシュ（通常はmemcache）を使用することがあります。
- アカウントサーバは、Object Storageサービスにて定義されたアカウントを管理します。
- コンテナサーバは、Object Storeサービス範囲内のコンテナ群（例：フォルダ）のマッピングを管理します。
- オブジェクトサーバは、ストレージノード上の実際のオブジェクト（例：ファイル）を管理します。
- 大規模データストア上の管理タスクを実行するためのいくつかの定期的なプロセスがあります。最も重要なプロセスは、クラスタによる一貫性と可用性を保証する、レプリケーションサービスです。他の定期的なプロセスはオーディッター（監査）、アップデータ（更新）、リーパー（削除）です。
認証機能は、設定変更しやすい WSGI ミドルウェア(通常ではKeystone)経由で取り扱います。
- glance-apiは、イメージ照会・表示・保管のためのImageAPIコールを受け取ります
- glance-registry はイメージのメタデータ（サイズ、タイプなど）格納・実行・表示を行います
- イメージメタデータを格納するデータベース。Novaの様に、サーバパフォーマンスに合わせてデータベースを選択することができます（多くの人がMySQLもしくはSqliteを使用しています）
- 実際のイメージファイルのためのストレージリポジトリ。図では、最も利用されそうな構成（Swiftをイメージリポジトリとして利用）を見せました、しかしこれは、Swift、通常のファイルシステムをサポートするGlance、RADOSブロックデバイス、Amazon S3やHTTPなどに変更可能です。なおこれらに変更した場合、読み込みのみとなることに注意して下さい。
キャッシングをサポートするためにGlance上で動作するいくつかの定期プロセスが存在します。
最も重要なプロセスは、クラスタを用いて一貫性と可用性を保証するレプリケーションサービスです。他の定期プロセスはオーディッター（監査）、アップデータ（更新）、リーパー（削除）を含んでいます。
図からも分かる通り、GlanceはIaaS全体の絵の中心の役割を担っています。エンドユーザもしくかNovaコンポーネントからイメージ（やイメージメタデータ）のためのAPIリクエストを受け付け、ディスクに格納します。
Identity
Keystoneは、OpenStackポリシー、カタログ、トークン、そして認証のための、統合のシングルポイントを提供します。
- Keystoneは、設定変更可能なカタログサービス、ポリシーサービス、トークンサービス、認証サービスの提供と同じ様に、APIリクエストを取り扱います。
- keystoneの各機能は、特定のサービスを使用するために異なった手段を講じてバックエンドでのプラグ差し替えることができます。多くは、LDAPかSQL、もしくはKey Value Store(KVS)のような標準バックエンドをサポートしています。
ほとんどの人々はこれをカレントの認証サービスのためのカスタマイズポイントとして使用することとなるでしょう。
将来のプロジェクト
これで、OpenStack Essexアーキテクチャツアーは終わりです。しかし、OpenStackはこのまま立ち止まってはいません - 後続のOpenStackリリース(Folsom)は他のコアサービスを迎え入れることになるでしょう：
- 他のOpenstackサービス（最も見込みのあるノヴァ）によって管理されるインターフェース装置の間で、ネットワーク（クアンタム）は「サービスとしてのネットワーク連結性」を提供します。 彼ら自身のネットワークを作成して、それからインターフェースを彼らに付けるのをユーザーが許すことによって、サービスは働きます。
Folsomリリーススケジュール（おそらく2012年秋）がまだセットされていないにもかかわらず、私はこのための絵を更新することを6ヶ月待つことはできないでしょうね。
なぜクラウドなのか？
今日のデータセンタでは、多くのコンピュータが同様に計算能力やネットワーク帯域の不足に悩んでいます。例えば、プロジェクトが計算を完遂するために膨大な計算能力を必要としていますが、計算後はそれほど計算能力を必要としないとします。必要に応じて自動で、あるいは簡単な操作で、増減できる様な柔軟性にとんだ利用が可能なサービスを望む場合、クラウドコンピューティングを選択するでしょう。"クラウドコンピューティング"というフレーズは、ユーザからプロバイダへサービスの責務が移るレイヤ内の雲状の形を含む図の中で、しばしば見受けられます。図中のこの手のクラウドは、作業を完遂させるために使用する計算能力に余裕を持つサービスである意味も含まれています。毎日供給を受けている電力のように、クラウドコンピューティングは、契約者や利用者に対して共有のコンピューティング資源（ネットワークや、通信、ストレージサーバ、アプリケーションサーバもしくはコンピューティングタスクサービス）へのアクセスさせることを提供します。
これらはまぎれもないクラウドの特徴です：
- オンデマンドセルフサービス：利用者は簡単な操作でサーバやネットワークの提供を受けることが可能
- ネットワークアクセス：どんなコンピューティングであってもネットワーク経由で利用可能、多くの異なったデバイスは標準メカニズムを通じてアクセス許可を受ける
- リソースプーリング：複数利用者が、他の消費者の需要を満たすクラウドへのアクセスすることができる
- 柔軟性：プロビジョニングは需要に基づいて迅速にスケールアウトする
- 従量サービス：時間単位での従量課金ユーティリティのように、クラウドは、リソース使用を最適化し、サービスレベルや（ストレージや実行量などの）サービスのタイプによってコントロールすべきです
クラウドコンピューティングは、利用者が要求するれあろう能力に依存した異なるサービスモデルを提供します。
- SaaS: Software as a Serviceの略称。Webベースのメールサービスなどのような、利用者にソフトウェア利用サービスを提供します
- PaaS: Platform as a Serviceの略称。（例としてダウンロード無しでEclipse/Javaのような環境を提供する様な）利用者にプログラミング言語やクラウドプラットフォームプロバイダが提供するツールを用いてアプリケーション配置サービスを提供します。
- IaaS: Infrastructure as a Serviceの略称。どんなソフトウェアやOSでも稼動可能なコンピュータインスタンス、ネットワーク接続、ストレージのような基盤を提供します。
パブリッククラウドやプライベートクラウドのような用語を聴く場合、クラウドの配置モデルのことを指しています。プライベートクラウドは、組織の敷地内外にかかわらず、単一組織のために運用します。パブリッククラウドは、一般的に公共、もしくはほとんどがクラウドサービス企業によって所有された巨大企業グループに対して有効な基盤です。NISTは、課題を共有する特殊なコミュニティをサポートする複数組織が共有するようなコミュニティクラウドを定義しています。
また、クラウドはハイブリッドとしての意味で説明することがあります。ハイブリッドクラウドは、パブリック、プライベート両方のクラウドで構成された配置モデル、もしくは物理・仮想サーバを含むクラウドコンピューティングのハイブリッドモデルのことをさします。
クラウドコンピューティングを使うことで何を得たのでしょうか？クラウドコンピューティングは大規模なコンピューティングニーズへの対応を助けることができます、また既存のハードウェアを使い潜在的にハード依存を解消するために仮想サーバによって巻き取る運動を先導することができます。人々はまた、ネットワークコンピューティングを通じて得られる高可用性から、コラボレーションのためにクラウドコンピューティングを使用します。文書作成、複雑な計算、電子メールコミュニケーションなどの生産性向上のためのスィートをクラウドコンピューティングを通じて利用することもできます。クラウドコンピューティングはまた、クラウドユーザへの追加ストレージ、ユーザデスクトップ上の追加ハードウェアの要求の排除や、クラウド内の巨大なデータストレージへのオンラインでのアクセス実現にも役立ちます。
クラウドコンピューティングの本質的な特性やそのサービスモデルや配置モデルについてのより詳細な議論は、米国NIST(National Institute of Standards and Technology)作成の http://www.nist.gov/itl/cloud/ を参照して下さい。
2. OpenStack Object Storageへのイントロダクション
OpenStack Object Storageはスケーラブルなオブジェクト・ストレージ・システムです。従来のファイルシステム方式ではありません。従来のSANやNASの様に、システムにマウントすることは出来ません。OpenStack Object Storageはストレージに関して異なる考え方であるため、下記の鍵となる概念を説明するために少しだけ時間を掛けて下さい。
アカウントとアカウントサーバ
OpenStack Object Storage システムは多くの異なるストレージの（一般消費者を含む）利用者の方々に使っていただくためにデザインされました。ユーザは認証システムを用いて本人であることを確認しなくてはなりません。
アカウントサービスを実行するノードは、個々のアカウントを別のものとして扱います。アカウントサーバは、ストレージシステムの一部であり、コンテナサーバやオブジェクトサーバと連動した設定を行わなくてななりません。
認証とアクセス許可
OpenStack Object Storage 接続パラメータや認証トークンを受領するために、認証サービスに対して認証を受ける必要があります。トークンは、受領以降すべてのコンテナやオブジェクトに渡されます。ミドルウェアとして利用可能な認証サービスの一例としてswauthがあります。swaushは https://github.com/gholt/swauth からダウンロードすることができます。OpenStack Identity Service(コードネーム：Keystone)を認証サービスとして使用することもできます。Keystoneは https://github.com/openstack/ からダウンロードすることができます。
ノート
一般的に言語依存APIは、認証や、トークンパッシング、HTTP通信に対応しています。
XContainer-Read:accountname / X-Container-Write:accountname:username (これは、accountnameに対応するアカウントのどんなユーザに対しても読み込みを許可し、accountnameに対応するアカウントのusernameに対応するユーザに対してのみ書き込みを許可することを意味しています)を用いてユーザかアカウントのいずれかのオブジェクトのアクセス制御を実現しています。ObjectStack Object Storage上に格納されているオブジェクトのパブリックアクセス権を与えることもできますが、サイト上のホットリンク（別のサイトからイメージファイルのリンクを貼り他人の帯域を使用する、などの）ホットリンクのようなコンテンツ窃盗を防ぐためにReferer(紹介者)ヘッダを使ってパブリックアクセスを制限することもできます。パブリックコンテナの設定はアクセスコントロールリスト越しに認証を実施しないで使用されます。例えば X-Container-Read:refere:any を使えば、他の認証設定にも関わらず誰でもコンテナからの読み込みを許可します。
一般的に、各ユーザは自身のストレージアカウントを持っており、アカウントのフルアクセス権限を保有指定します。ユーザは前述のとおりユーザ自身で証明することで認証を受けなくてはなりませんが、一旦認証を受けたユーザはアカウント範囲内のコンテナやオブジェクトのコンテンツの作成・削除を行うことができます。あるユーザが他のアカウントからコンテナへアクセスできる唯一の方法は、認証システムのAPIアクセスキーもしくはセッショントークンを共有することです。
コンテナとオブジェクト
コンテナは、データのストレージコンポーネントで、データを構成する１つの方法を提供します。コンテナは、Windows(R)のフォルダもしくはUNIX(R)のディレクトリのようなものと考える事ができます。コンテナと他のファイルシステムの概念との間の主な違いは、コンテナはネストできない点です。しかしながら、アカウント範囲内であれば無制限にコンテナを作成することができます。データは必ずコンテナ内に格納されていなくてはなりません。このためデータアップロード前にアカウント内に少なくとも１つのコンテナを定義しておかなくてはなりません。
コンテナ名には、先頭にスラッシュ(/)をつけることができません、また長さは256バイト未満でなくてはなりません。URLエンコード処理後であっても長さについては規制されることに注意して下さい。例えば、コンテナ名"Course Doc"はURLエンコード後"Course%20Docs"となるため、11バイトではなく13バイトとして扱います。
オブジェクトは基本となるストレージ要素であり、OpenStack Object Storageシステムに格納したファイルを表すあらゆるオプションのメタデータです。OpenStack Object Storageへデータを格納した時、データは、as-is(無圧縮、無暗号化)で格納されます。そしてデータは、ロケーション、オブジェクト名、キー・値ペアのメタデータで構成されています。
例えば、写真画像のバックアップを保存するために選択することができます、そしてアルバムに整理することができます。この場合、各オブジェクトはメタデータをつかって Album:Caribbean Cruise や Album:Aspen Ski Trip のようなタグ付けされます。
オブジェクト名は、URLエンコード後の長さが1024バイト未満でなくてはなりません。例えば、オブジェクト名"C++final(v2).txt"は、URLエンコードを実施すると"C%2B%2Bfinal%28v2%29.txt"となるので、長さは16バイトではなく24バイトとして扱います。
ストレージオブジェクトの許可されている最大サイズは5GBで、最小サイズは0バイトです。ビルトインラージオブジェクトを使用する事ができます、また5GBより大きいオブジェクトを検索するSwiftユーティリティを使用することができます。
メタデータは、どんなオブジェクトでもキー・値ペアは90を超えるてはいけません、そしてすべてのキー・値ペアの合計バイト長は4KB(4096バイト)を超えてはいけません。
重要すべてのオペレーションは認証システムから受けた正しい認証トークンを含まなくてはなりません。
言語依存APIバインディング
幾つかの有名な言語サポートされているAPIバインディングが、Rackspace Cloud Files製品から入手可能です（OpenStack Object Storageコードを使っています）。バインディングは、REST API（プログラマにコンテナやワーキングディレクトリの代わりにオブジェクトモデルを使用してHTTP通信経由で作業することを許可）の上位に抽象レイヤを提供しています。バインディングは自由にダウンロード（ビールを飲んだりスピーチのように簡単に）、利用、改変できます。すべては、各バインディングにパッケージされているCOPYINGファイルに書かれているとおりMITライセンス準拠のもと使用可能です。もしAPIに改善を行うのであれば、変更を我々に提出していただく事をおすすめします（必須ではありません）。
Rackspace Cloud FilesのAPIバインディングは http://github.com/rackspace にホストされています。github経由であなたのコード変更を投稿するか、よろしければ cloudfiles（アットマーク）rackspacecloud.com へ送って下さい。その際、どの言語のどのバージョンを修正しdiffを送信したかを明示しておいて下さい。
それぞれのバインディングのドキュメントもあります(HTML、PDF、CHMのいずれか)。利用開始を助けるための例示として、スニペットコードが掲載されています。現在OpenStack Object StorageがサポートしているAPIバインディングは以下のとおりです：
- PHP (バージョンは 5.x のみ、モジュール: cURL, FileInfo, mbstring)
- Python (2.4以降)
- Java (JRE v1.5以降)
- C#/.NET (.NET Framework v3.5のみ)
- Ruby (1.8以上、およびmime-tools モジュール)
3. OpenStack Object Storageのインストール
OpenStack Object Storageサービスは、REST API経由でオブジェクトストレージの提供および検索と一緒に動作します。
システム要件
ハードウェア：OpenStack Object Storageは一般に販売されているハードウェア上で動作するようにデザインされています。
テーブル 3.1. 推奨ハードウェア
| サーバ | 推奨ハードウエア | ノート |
|---|---|---|
| Object Storage オブジェクトサーバ | プロセッサ：DualCore メモリ：8もしくは12GBRAM ディスク容量：1GBあたりのコストを最適化 ネットワーク：1GB NIC×1 |
ディスク容量は、ラックへどのくらい搭載されているかに依存します。また業界標準故障率をもとに1GBあたりのコストを最適化したいと望むでしょう。Rackspace社のストレージサーバは、24個の2TB SATAドライブと8コアプロセッサを搭載したかなり一般的なタイプの4Uサーバを現在使用しています。ストレージドライブ上のRAIDは必須ではありませんが推奨します。 Swiftのディスク使用パターンは可能な限り最も悪いRAIDにおけるケースです、RAID5もしくは6を使用する場合最も速く悪化します。 例えばRackspace社では Cloud Filesストレージサーバは24個の2TB SATAドライブと8コアプロセッサで動作しています。 ほとんどのサービスは設定内のworkerもしくはconcurrency valueのいずれかをサポートしています。 これは、サービスがコアの有効利用できるように設定が許可されています。 |
| Object Storage コンテナ/アカウントサーバ | プロセッサ：Dual Quad Core メモリ：8もしくは12GBRAM ディスク容量：1GB×1 ネットワーク：1GB NIC×1 |
SQLiteデータベースを使用してトラッキングを行うIOPSのために最適化されます。 |
| Object Storage プロクシサーバ | プロセッサ：Dual Quad Core ネットワーク：1GB NIC×1 |
多くのAPIリクエストにタイ硫黄するにはより高いスループットのネットワークが必要になります。 プロクシサーバはCPUパフォーマンスが最後になるように最適化して下さい。 プロクシサーバはよりCPUやI/O負荷が集中します。 もしあなたが 10g ネットワーキングをプロクシに使用する場合、もしくはSSL通信をプロクシでターミネートする場合、より多くのCPUパワーが必要になるでしょう。 |
オペレーティングシステム：OpenStack Object Storage はUbuntu、RHEL、CentOS、Fedora上で動作します。Rachspace社ではUbuntu 10.04LTS上で動かしています。
ネットワーキング：推奨は1000Mbpsです。OpenStack Object Storage外部のネットワークとの接続を行うためにはプロクシサーバを経由させ、ストレージネットワークを意図的に単一あるいは複数のプライベート上に分離します。
データベース：OpenStack Object StorageにおけるSQLiteデータベースは、OpenStack Object Storageコンテナおよびアカウント管理プロセスの一部です。
パーミッション：OpenStack Object Storageはrootもしくは、（sudoersファイルにて全てのパーミッションを許可しているのであれば）sudoパーミッションを持ったユーザどちらかでインストールします。
オブジェクトストレージネットワーク計画
ネットワーク資源の節約し、ネットワーク管理者に対するAPIアクセスや必要に応じてストレージネットワークを提供するためのネットワークやパブリックIPアドレスのニーズの理解を確実にするために、この章では推奨及び必須の最小サイズ両方を提供します。
少なくとも1000Mbpsのスループットを推奨します。
このドキュメントでは２つのネットワークにつついて説明します。一つはプロクシサーバに接続するためのパブリックネットワーク、そして2つめはクラスタの外部へアクセスできないがすべてのが接続されているストーレジネットワークです。すべてのOpenStackストレージサービスは、同様に各ストレージノード上のrsyncデーモンはSTORAGE_LOCAL_NET IPアドレス上の問い合わせを受けるために構成されています。
パブリックネットワーク（パブリックルーティング可能なIPレンジ）：このネットワークはクラウド基盤の範囲内のAPIエンドポイントへアクセスできるパブリックIP提供のために利用されます。
最小サイズ：8IPs(CIDR/29)
ストレージネットワーク(RFC1918 IPレンジ、パブリックルーティング不可）：このネットワークは、オブジェクトストレージ基盤の範囲内のすべての内部サーバ通信のために利用されます。
推奨サイズ：255IPs (CIDR/24)
オブジェクトストレージインストールアーキテクチャの例
- ノード - 1つ以上のOpenStackオブジェクトストレージサービスが動作しているあるホストマシンプロクシ
- ノード - プロクシサービスが動作しているノード
- 認証ノード - ノードプロクシサービスから分離されて認証サービスが動作している任意のセパレート
- ストレージノード - アカウント、コンテナ、およびオブジェクトサービスが動作しているノード
- リング - OpenStack Object Storageデータの物理デバイスへのマッピングのセット
信頼性を向上させるために、パフォーマンス向上を目的としたプロクシサーバを追加しても良いです。
このドキュメントでは、リング内の分離したゾーンとして各ストレージノードを説明しています。最小5ゾーンを推奨します。ゾーンとは、可能な限り他のノード（サーバ、ネットワーク、電源、構成ハチとの分離）と分離したノードグループです。リングは、それぞれのレプリカが分離したゾーンに格納されていることを保障します。以下の図は、できうる最小インストール構成の一つをあらわしています。
OpenStack Object Storage を Ubuntu 上にインストール
開発やテストプロセスのために、OpenStack Object Storageを単一サーバへインストールすることができます。また高可用性および高冗長性を可能にするためにオブジェクトストレージシステムを分散させたい場合は、複数サーバへインストールすることができます。
もしソースコードからの開発プロセスのためにUbuntu上へ単一ノードをインストールするのであれば、Swift オールインワンインストラクションかDevStackを使って下さい。
手順マニュアルは http://swift.openstack.org/development_saio.html、認証およびダッシュボードを含むオールインワン構成の場合は http://devstack.org を参照して下さい。
開始する前に
もしあなたが新しいサーバをインストールしようしているのであれば、Ubuntu Serverインストールメディアのコピーを手に取ってください。
このドキュメントは、以下の続くノードタイプを使ってクラスターのインストールを論証します。
- Swiftプロクシサーバプロセスが動作するする、またオプションでswauthもしくはtempauthサービスが動作する１つのプロクシノード。ここでは認証サービス(コードネーム:keystone)を使用することとして説明します。プロクシサーバはプロクシリクエストを適当なストレージノードへ渡すために動作します。
- 実際に格納されたオブジェクトと同様に、アカウントデータベースやコンテナデータベースのストレージを管理する、Swiftアカウントサーバ、swiftコンテナサーバ、swiftオブジェクトサーバプロセスが動作する、5つのストレージノード。
ノート
初期はより少ないストレージノードで使用することができます、しかし１つのプロダクションクラスタに最低５つのノードの使用を推奨します。
一般的なインストール手順
- 1. Ubuntu Server(10.04から12.04)もしくはRHEL、CentOS、FedoraのいずれかベースとなるOSをすべてのノード上にインストールします。
- 2. swiftサービスとopenSSHをインストールします。
# apt-get install swift openssh-server rsync memcached python-netifaces python-xattr python-memcache
# yum install openstack-swift openstack-swift-proxy openstack-swift-account openstack-swift-container openstack-swift-object memcached
- 3. すべてのノード上でディレクトリを作成・設定します。
mkdir -p /etc/swift
chown -R swift:swift /etc/swift/
- 4. /etc/swift/swift.confを作成します。
[swift-hash]
# random unique string that can never change (DO NOT LOSE)
swift_hash_path_suffix = fLIbertYgibbitZ
ノート
/etc/swift/swift.conf 内の接尾値は、リング内のマッピングを明確にするためのハッシュを行う場合、saltのようないくつかのランダムなテキスト文字列をセットすべきです。
次に、ストレージノード、プロクシノード、そして認証ノードをセットアップします。このウォークスルーでは、一般的な認証機能として、OpenStack 認証サービス(Keystone)を使用します。
ストレージノードのインストールおよび設定
ノート
OpenStack Object Storage はどんなモダンなExtended Attributes (XATTRS)をサポートするファイルシステム上で動作すべきです。テストやRackspace社のベンチマーキングをもとに、Swift利用ケースにおける最高の全体パフォーマンスを実証している事から、我々は現在XFSを推奨しています。XFSは完全にテストされた唯一のファイルシステムでもあります。
- 1. ストレージノードパッケージのインストール：
# apt-get install swift-account swift-container swift-object xfsprogs
# yum install openstack-swift-account openstack-swift-container openstackswift-object xfsprogs
- 2. ノード上の各デバイスに、XFSボリュームをセットアップ（以下の例は、/dev/sdbを使用した場合）：
fdisk /dev/sdb (set up a single partition)
mkfs.xfs -i size=1024 /dev/sdb1
echo "/dev/sdb1 /srv/node/sdb1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 0" >> /etc/fstab
mkdir -p /srv/node/sdb1
mount /srv/node/sdb1
chown -R swift:swift /srv/node
- 3. /etc/rsyncd.confを作成：
uid = swift
gid = swift
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
address =
[account]
max connections = 2
path = /srv/node/
read only = false
lock file = /var/lock/account.lock
[container]
max connections = 2
path = /srv/node/
read only = false
lock file = /var/lock/container.lock
[object]
max connections = 2
path = /srv/node/
read only = false
lock file = /var/lock/object.lock
- 4. /etc/default/rsync内の以下の行を編集：
RSYNC_ENABLE = true
- 5. rsyncデーモンを開始：
service rsync start
ノート
rsyncデーモンは認証を必要としません、このためローカル、プライベートネットワーク上で動作させるべきです。
- 6. /etc/swift/account-server.confを作成：
[DEFAULT]
bind_ip =
workers = 2
[pipeline:main]
pipeline = account-server
[app:account-server]
use = egg:swift#account
[account-replicator]
[account-auditor]
[account-reaper]
- 7. /etc/swift/container-server.confを作成：
[DEFAULT]
bind_ip =
workers = 2
[pipeline:main]
pipeline = container-server
[app:container-server]
use = egg:swift#container
[container-replicator]
[container-updater]
[container-auditor]
- 8. /etc/swift/object-server.confを作成：
[DEFAULT]
bind_ip =
workers = 2
[pipeline:main]
pipeline = object-server
[app:object-server]
use = egg:swift#object
[object-replicator]
[object-updater]
[object-auditor]
[object-expirer]
- 9. ストレージサービスを開始：
swift-init object-server start
swift-init object-replicator start
swift-init object-updater start
swift-init object-auditor start
swift-init container-server start
swift-init container-replicator start
swift-init container-updater start
swift-init container-auditor start
swift-init account-server start
swift-init account-replicator start
swift-init account-auditor start
プロクシノードのインストール及び設定
プロクシサーバは、リクエストを受け取り、アカウント、コンテナ、もしくはオブジェクトのロケーションを調べ、リクエストを正しくルーティングします。プロクシサーバもまたAPIリクエストを取り扱います。ファイルproxy-server.confを設定することによりアカウント管理が可能です。
ノート
すべての命令がrootユーザーとして動くと仮定しています。
- 1. swift-proxyサービスをインストール：
# apt-get install swift-proxy memcached
# yum install openstack-swift-proxy memcached
- 2. SSLルート証明書を作成：
cd /etc/swift
openssl req -new -x509 -nodes -out cert.crt -keyout cert.key
- 3. デフォルトインタフェイスで通信待受するためにmemcachedの設定を変更します。できるだけローカル、非パブリックネットワーク上にて動作させるべきです。/etc/memcached.confの以下の行を編集・変更して下さい：
-l 127.0.0.1
to
-l
- 4. memcachedを再起動：
service memcached restart
- 5. Swift プロクシファイル内にOpenStack設定コマンドを使ってkeystone Adminトークンをセットして、Object Storageに認証トークンをセットアップします。
# openstack-config --set /etc/swift/proxy-server.conf filter:authtoken admin_token $ADMIN_TOKEN
# sudo openstack-config --set /etc/swift/proxy-server.conf
filter:authtoken auth_token $ADMIN_TOKEN
- 6. /etc/swift/proxy-server.confを作成：
[DEFAULT]
bind_port = 8888
user =
[pipeline:main]
pipeline = catch_errors healthcheck cache authtoken keystone proxy-server
[app:proxy-server]
use = egg:swift#proxy
account_autocreate = true
[filter:keystone]
paste.filter_factory = keystone.middleware.swift_auth:filter_factory operator_roles = admin, swiftoperator
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
# Delaying the auth decision is required to support token-less
# usage for anonymous referrers ('.r:*').
delay_auth_decision = true
service_port = 5000
service_host = 127.0.0.1
auth_port = 35357
auth_host = 127.0.0.1
auth_token = 012345SECRET99TOKEN012345
admin_token = 012345SECRET99TOKEN012345
[filter:cache]
use = egg:swift#memcache
set log_name = cache
[filter:catch_errors]
use = egg:swift#catch_errors
[filter:healthcheck]
use = egg:swift#healthcheck
ノート
もし複数のmemcacheサーバを動作させているのであれば、proxy-server.conf相当のファイルの[filter:cache]セクションに複数の IP:ポート番号 を設定する必要があります。
10.1.2.3:11211,10.1.2.4:11211
プロクシサーバのみがmemcacheを使用します。
- 7. アカウント、コンテナ、およびオブジェクトリングを作成します。ビルダコマンドは基本的にいくつかのパラメータが設定されたビルダファイルを作成します。パラメータの18という値は、2の18乗を表しており、パーティションサイズがこの値に設定されます。リング全体で使用を見込んでいるストレージの合計値をもとに、この"パーティション乗数"値をセットします。3という値は各オブジェクトのレプリカの数を表しています。最後の値は、１回以上のパーティション移動を制限するための時間を表しています。
swift-ring-builder account.builder create 18 3 1
swift-ring-builder container.builder create 18 3 1
swift-ring-builder object.builder create 18 3 1
- 8. 各ノードのストレージデバイスに対してそれぞれにリングへのエントリーを追加します：
swift-ring-builder account.builder add z- :6002/ 100
swift-ring-builder container.builder add z- :6001/ 100
swift-ring-builder object.builder add z- :6000/ 100
例えば、もし仮にIP 10.0.0.1上のゾーン1内の任意のパーティションでストレージノードをセットアップしたとします。このパーティションのマウントポイントで/srv/node/sdb1です、そしてrsync.confのパスは/src/node/とすると、DEVICEはsdb1になり、以下の様なコマンドとなるでしょう。
swift-ring-builder account.builder add z1-10.0.0.1:6002/sdb1 100
swift-ring-builder container.builder add z1-10.0.0.1:6001/sdb1 100
swift-ring-builder object.builder add z1-10.0.0.1:6000/sdb1 100
ノート
ゾーンあたり1ノードとして5つのゾーンが存在する場合、ZONEは1から開始して、ノードが追加されるたびに1づつ値を増やしていかなくてはなりません。
- 9. 各リングのリングコンテンツを確認します：
swift-ring-builder account.builder
swift-ring-builder container.builder
swift-ring-builder object.builder
- 10. リングのリバランスを実行します：
swift-ring-builder account.builder rebalance
swift-ring-builder container.builder rebalance
swift-ring-builder object.builder rebalance
ノート
リングのリバランスはかなりの時間がかかります。
- 11. account.ring.gz、container.ring.gz、およびobject.ring.gzを/etc/swiftの各プロクシ/ストレージノードへコピーします。
- 12. すべての設定ファイルのオーナをswiftユーザにします：
chown -R swift:swift /etc/swift
- 13. プロクシサービスを開始します：
swift-init proxy start
OpenStack Object Storageの設定
プロクシサーバおよびストレージサーバは設定完了したので、各サービスを再起動します。
swift-init main start
swift-init rest start
さらにプロクシサーバを追加することでインストールの微調整を行うことができます。
プロクシサーバの追加
信頼性を理由に、複数のプロクシサーバを持ちたいと思うかもしれません。それは最初のプロクシサーバと同様にセットアップし、追加の設定ステップを加えることで可能です。
一度2つ以上のプロクシを保有したら、プロクシ間の負荷分散も行いたくなるでしょう、そしてそれはストレージエンドポイントもまた変更になることを意味します。負荷分散の異なる戦略を選択することもできます。例えば、複数のプロクシの前にラウンドロビンDNSを使用したり、実際のロードバランサー（poundのような）を使用してストレージURLをロードバランサを示すように設定するなどです。
初期のプロクシノードを最初のセットアップで設定し、次に2台目以降のプロクシサーバのための追加のステップは以下のとおりです。
- 1. 追加するすべてのプロクシサーバの/etc/swift/proxy-server.conf内のmemcacheサーバリストを更新します。もし複数のmemcacheサーバが動作しているなら、複数の IPアドレス:ポート番号 のリストパターンを使用して：
10.1.2.3:11211,10.1.2.4:11211
各プロクシサーバの設定ファイル内に以下のように、設定します。
[filter:cache]
use = egg:swift#memcache
memcache_servers =:11211
- 2. ファイル/etc/swift/proxy-server.confのdefault_cluster_urlを、最初に構築したプロクシサーバから、ロードバランサURLに変更して下さい：
[app:auth-server]
use = egg:swift#auth
default_cluster_url = https:///v1
# Highly recommended to change this key to something else!
super_admin_key = devauth
- 3. default_cluster_url変更後、認証データベースを削除しOpenStack Object Storageユーザを再作成しなくてはなりません。または書くアカウントの正しいURLを使って認証データベースを手動で更新しなくてはなりません。
- 4. 次に、すべてのリング情報を、新しいプロクシノードを含む全ノードへコピーしてください。そして更に全ストレージノードがリング情報が取得しているか確認して下さい。
- 5. すべてのノードでsyncを実行した後、/etc/swiftのadminがキーを保有していることおよびリングファイルのオーナー情報が正しいことを確認して下さい。
インストールの確認
プロクシサーバや認証サービス経由でアクセス可能なサーバからこれらのコマンドを実行することができます。ファイルproxy-server.confのdefault_swift_clusterの設定を調べて、認証コマンドを発行した時の(httpもしくはhttpsを含んでいる)URLが合致するかを確認して下さい。
- 1. 正しい認証サービスURLを使ってswift CLI、swiftを実行して下さい。$ export ADMINPASS=secretword を使って、環境変数ADMINPASSをexportしてください。
$ swift -V 2 -A http://:5000/v2.0 -U adminUser:admin -K 012345SECRET99TOKEN012345 stat
- 2. X-Storage-URLとX-Auth-Tokenを取得して下さい：
$ curl -k -v -H 'X-Storage-User: adminUser:admin' -H 'X-Storage-Pass: $ADMINPASS' http://:5000/auth/v1.0
- 3. アカウントのHEADが可能か確認して下さい：
$ curl -k -v -H 'X-Auth-Token:'
- 4. swiftを使ってファイル名bigfile[1-2].tgz(2個のファイル)のコンテナネームmyfilesに更新して下さい：
$ swift -A http://:5000/v2.0 -U adminUser:admin -K $ADMINPASS upload myfiles bigfile1.tgz
$ swift -A http://:5000/v2.0 -U adminUser:admin -K $ADMINPASS upload myfiles bigfile2.tgz
- 5. swiftを使ってmyfilesコンテナから全てのファイルをダウンロードして下さい：
$ swift -A http://:5000/v2.0 -U adminUser:admin -K $ADMINPASS download myfiles
トラブルシューティングノート
もし問題が発生した場合、var/log/syslog（もしくはいくつかのdistros上のメッセージ）を確認して下さい。Rackspace社では/var/log/kern.log内のエラーメッセージを確認することでドライブ失敗のヒントにする事がります。
4. OpenStack Object Storageシステム管理
Object Storageシステムの本質概念を理解することにより、より良いストレージソリューションの監視や管理を行うことができます。
Object Storage動作を理解する
このセクションではObject Storage管理における概要を提供します。
リング
リングは、ディスクや物理的な位置上に格納されたすべての要素間のマッピングを表しています。アカウント、コンテナ、オブジェクトのためのリングは分離されています。他のコンポーネントが、オブジェクト、コンテナやアカウントに対してなにかの操作を実行するために必要な場合、クラスタ内のロケーションを明確にするために妥当なリングを用いて相互接続する必要があります。
リングはゾーン、デバイス、パーティションやレプリカを使用してマッピングを維持します。リング内の各パーティションは、デフォルトでは、クラスタにまたがって３回再構築されます、そしてパーティションのためのロケーションはリング内にて保守されたマッピング内に格納されています。リングはまたどれが失敗シナリオでのハンドオフとして使用されたデバイスかを明らかにする責任があります。
データはリング内のゾーンの概念により分離されます。パーティションの各レプリカは異なるゾーンに属することが保証されています。ゾーンは、１つのドライブ、もしくは１つのサーバ、もしくは１つのキャビネット、もしくは１つのスイッチ、もしくはあるデータセンタと同等のものを表現します。
リングのパーティションは平等にOpenStack Object Storage設備内のすべてのデバイス間を分割します。パーティションが頻繁に移動する（例えば、もしあるデバイスがクラスタ上に追加された時）必要がある場合、リングはパーティションの最小数とパーティションの唯一のレプリカも一度に移動されることを保証します。
ウェイトは、クラスタにまたがったデバイス上のパーティションの配布のバランスを取るために使用されます。ウェイトは、例えば、クラスタ上で異なったサイズのドライブが使用される場合に役に立ちます。
リングはプロクシサーバや（レプリケーションのような）幾つかのバックグラウンドプロセスによって使用されます。
プロクシサーバ
プロクシサーバはのこりのOpenStack Object Storageアーキテクチャの残りと一緒に結びつける役割を持っています。
各リクエストにおいて、リング内のアカウントやコンテナもしくはオブジェクトのロケーションを調べ、それに従ってルーティングを行います。パブリックAPIもまたプロクシ経由で利用されます。
大量の失敗もプロクシサーバによって取り扱われます。例えば、もしオブジェクトのPUTの際にサーバが有効でない場合、ハンドオフしたサーバのリンクに問い合わせ代わりのルールティングを実行します。
オブジェクトがオブジェクトサーバから入出力ストリームされる場合、プロクシサーバによってユーザへ直接ストリームされます。プロクシサーバはストリームデータをスプールしません。
設定ファイルにて有効にすることでアカウント管理されたプロクシサーバを使用することができます。
オブジェクトサーバ
オブジェクトサーバは、オブジェクトをローカルデバイスへ格納・検索・削除可能な大変シンプルなBLOBストレージサーバです。オブジェクトは、ファイルの拡張属性(xattrs)内に格納されたメタデータつきのファイルシステム上のバイナリファイルとして格納されます。オブジェクトサーバの基礎となるファイルシステムの選択はファイル上のxattrsをサポートすることが必須となっています。ext3のような、幾つかのファイルシステムはattrsをデフォルトで保有しています。
それぞれのオブジェクトはオブジェクト名のハッシュ値や操作のタイムスタンプから導出されたパスを使って格納されています。
最後の書き込みはいつも成功します、そして最後のオブジェクトバージョンが保存されます。削除もまたファイル（".ts"でエンコーディングされた０バイトファイル、これは墓碑を意味します）の１つのバージョンとして取り扱いを受けます。削除されたファイルは正確にレプリケートされオーダバージョンは失敗シナリオのため再現することが不思議にもできません。
コンテナサーバの主な仕事はオブジェクトの問い合わせを取り扱うことです。コンテナサーバは、どこにオブジェクトのものがあるか、どんなオブジェクトがある特定のコンテナに格納されているかを知りません。問い合わせはsqliteデータベースファイルとして格納されます、そしてクラスタをまたいで複製されます。オブジェクト総数やコンテのストレーし使用合計を含む統計情報もまたトレースされます。
アカウントサーバ
アカウントサーバは、オブジェクトよりもむしろコンテナのリスティングに責任がある点を除いて、コンテナサーバと大変似ています。
レプリケーション
レプリケーションはネットワーク停止期間やドライブ失敗のような一時的なエラー状況に直面した密着した状態でのシステムを維持するために設計されています。
レプリケーションプロセスは、最終バージョンを含むすべてを守るために、ローカルデータとリモートコピーを比較します。オブジェクトレプリケーションは、各パーティションの小区分の素早い比較のために、ハッシュリストを使用します、そしてコンテナ/アカウントレプリケーションはハッシュ値の組み合わせを使用してハイウォータマーク（上限水位）を共有します。
レプリケーション更新はプッシュベースです。オブジェクトレプリケーションのために、更新はちょうど同等のファイルのrsyncを実行する程度です。
アカウント/コンテナレプリケーションはHTTPもしくは全体のデータベースrsync経由で失ったレコードをプッシュします。
レプリケーションはまたシステムからデータを削除した事を保証します。あるアイテム（オブジェクト、コンテナ、もしくはアカウント）が削除された場合、アイテムの最終バージョンとして墓石(tomstone)がセットされます。レプリケーションは墓石を参照しアイテムがシステムから完全に削除されたことを保証します。
ラックスペース社では、各サーバ自身の上のプロクシサービスに、そしてストレージサービスを同一のサーバ上に配置しています。プロクシには10gネットワーキングへ送信しストレージサーバには1gで送信することを許可し、より管理しやすいプロクシへの負荷分散を維持しています。追加のストレージサーバを増やして、ストレージサービスは水平スケールアウトさせ、より多くのプロクシサーバを追加することで全体のAPIスループットも拡張しています。
もしアカウントもしくはコンテナサービスのどちらかへのより多くのスループットが必要であれば、自身のサービスをそれぞれ配置したほうが良いです。例えば、より早いデータベースのディスクI/Oを得るために、より高速な（しかしより高価な）SASもしくはSSDドライブを使用してもよいです。負荷分散やネットワーク設計は読者の課題として残っています、しかしこれはクラスタの大変に重要な部分なので、Swiftクラスタとしてのネットワークデザインに多くの時間を費やすべきです。
リングの準備
最初のステップはリング内のパーティション数の決定です。ドライブをまたいで分離する保険をかけるために、ドライブごとに最小100パーティションを推奨しています。１つの良い開始ポイントは、クラスタを構成する最大ドライブ数を計算することです。そして100パーティションごとに増やし、そして２の乗数の近似へ切り上げていきます。
例えば、ほんの5000ドライブしか無いクラスタを構築しているとします。この場合合計500,000パーティションを保有することとなり、これは切り上げるとかなり2の19乗に近い値です。
パーティション数を（比較的）小さくすることも、良いアイディアです。パーティションを増やせば増やすほど、レプリケータや他のバックエンドジョブがより多く動作し、より多くのお金を進行中にリングは使い果たします。ゴールは少ないリングと最大クラスタサイズの間で良いバランスを発見することです。
次のステップは、データを格納するレプリカ数を決定することです。現在の推奨値は３です（テストされている唯一の値として）。より大きい数値であればあるほど、より大量にストレージが使用され、よりデータロスの見込を減らすことができます。
クラスタが保有するゾーン数の決定も重要です。最小の５ゾーンから開始することが推奨です。より少ないゾーン数で開始することも可能ですが、外部テストでは、失敗発生時は少なくとも5ゾーン以上で開始することが最適であることがわかっています。分離できる限りできるだけゾーン数を多く設定してみることも推奨しています。考慮に入れておくこととして、物理ロケーション、電力の可用性、ネットワーク連結性などがあります。例えば、ある小さなクラスタで、それぞれ電源とネットワークを持つキャビネットごとにゾーン分割を決めようとしているとします。
ゾーンの概念は大変抽象的です、このためデータを分離する最も良い方法によって自由に使います。ゾーンは１から始まる数字により配列します。
これでリングの構築を開始ができます：
swift-ring-builder <builder_file> create <part_power> <replicas> <min_part_hours>
このコマンドで、2の<part_power>乗のパーティションの<builder_file>を作成するリングビルドプロセスを開始します。<min_part_hours>は、特定のパーティションが正常に移動できる時間(24が良い値です)をあらわします。
デバイスをリングに追加することができます：
swift-ring-builder <builder_file> add z<zone>-<ip>:<port>/<device_name>_<meta> <weight><builder_file>は事前に作成されたビルダファイルの名前、<zone>はデバイスを追加するゾーンの番号、<ip>はデバイスが追加されるサーバのIPアドレス、<port>はサーバが待ち受けているポート番号、<device_name>はサーバ上のデバイス名（例えば、sdb1）、<meta>はデバイスのメタデータ文字列（オプション）、そして<weight>はクラスタの残りのデバイスに比例したデバイス上にいくつパーティションをきるかのフロートウェイト（100.0×デバイスサイズ(TB)からはじめるのが良い）です。クラスタ上に各デバイスの初期設定を追加してください。
すべてのデバイがリングへ追加された後、実行して下さい：
swift-ring-builder <builder_file> rebalanceこのコマンドはリング上にデバイスをまたいでパーティションを割り当てます。リバランスを実行する前にすべての必須の変更をリングへ反映するときはいつでも重要です。
このコマンドは、リングを可能な限りバランスのとれた、そして可能な限り移動されるパーティションが少ない状態にすることを保証します。
上のプロセスは、各ストレージサービス（アカウント、コンテナ、そしてオブジェクト）にリングを作る時に実行されるべきです。ビルダファイルは将来のリングへの変更で必要となります、このためビルダファイルの保管やバックアップすることは重要です。ファイルresulting.tar.gzはクラスタ上のすべてのサーバにプッシュされる必要があります。リング構築に関するさらなる情報として、オプション無しで実行中のswift-ring-builderは有効なコマンドやオプションのヘルプテキストを表示します。
サーバ設定リファレンス
Swiftはpaste.deployを使って管理サーバ設定を行います。デフォルト設定オプションは[DEFAULT]セクションにセットされ、オーバライドされる特定のオプションはどれも他のセクションにセットされます。
オブジェクトサーバ設定
オブジェクトサーバ設定例はソースコードリポジトリのetc/object-server.conf-sampleを参照して下さい。
以下の設定オプションが有効です：
テーブル4.1. object-server.confの[DEFAULT]セクションのデフォルトオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| swift_dir | /etc/swift | Swift設定ディレクトリ |
| devices | /srv/node | デバイスがマウントされる親ディレクトリ |
| mount_check | true | 誤ってルートデバイスへの書き込みを避けるためデバイスマウント時チェックをするかどうか |
| bind_ip | 0.0.0.0 | バインドするサーバのIPアドレス |
| bind_port | 6000 | バインドするサーバのポート番号 |
| workers | 1 | フォークするワーカの数 |
テーブル4.2. object-server.confの[DEFAULT]セクションのデフォルトオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| use | オブジェクトサーバのpaste.deployエントリポイント。多くのケースではegg:swift#objectにすべきです。 | |
| log_name | object-server | ログ出力時のラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| log_requests | True | 各リクエストをログ出力するかどうか |
| user | swift | 実行ユーザ |
| node_timeout | 3 | 外部サービスのリクエストタイムアウト |
| conn_timeout | 0.5 | 外部サービスのコネクションタイムアウト |
| network_chunk_size | 65536 | ネットワーク経由での読み書きチャンクサイズ |
| disk_chunk_size | 65536 | ディスク読み書きチャンクサイズ |
| max_upload_time | 86400 | オブジェクトアップロードを許可される最大時間 |
| slow | 0 | 0以上の場合、PUTもしくはDELETEリクエストが完了するまでの最小時間（秒） |
| auto_create_account_prefix | . | アカウントが自動作成される場合の先頭文字列 |
| allowed_headers | content-disposition,content-encoding,x-delete-at,x-object-manifest, | オブジェクトのメタデータがセットされるヘッダリスト(カンマ連結) |
| mb_per_sync | 512 | 指定したMBごとにPUTやsyncデータを実行 |
テーブル4.3. object-server.confの[object-replicator]セクションのレプリケータオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| log_name | object-replicator | ログ出力に使用されるラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| daemonize | yes | レプリケーションをデーモンとして実行するかどうか |
| run_pause | 30 | レプリケーションパス間の待機時間（秒） |
| concurrency | 1 | 生成されるレプリケーションワーカ数 |
| timeout | 5 | -timeoutや-contimeoutオプションでrsyncのための送信タイムアウト値 |
| stats_interval | 3600 | レプリケーション統計のログ出力間隔（秒） |
| reclaim_age | 604800 | オブジェクトが再クレームされるまでの経過時間（秒） |
テーブル4.4. object-server.confの[object-updater]セクションのアップデータオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| log_name | object-updater | ログ出力時使用されるラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| interval | 300 | 取得間隔の最小時間 |
| concurrency | 1 | 生成されるアップデータワーカ数 |
| node_timeout | 10 | 外部サービスのリクエストタイムアウト |
| conn_timeout | 0.5 | 外部サービスのコネクションタイムアウト |
| slowdown | 0.01 | オブジェクト間の待機時間(秒) |
テーブル4.5. object-server.confの[object-auditor]セクションのオーディッタオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| log_name | object-auditor | ログ出力時使用されるラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| files_per_second | 20 | １秒で監査される最大ファイル数。個々のシステム空間に従ってチューニンしてください。0は無制限を意味します。 |
| bytes_per_second | 10000000 | １秒で監査される最大バイト数。個々のシステム空間に従ってチューニンしてください。0は無制限を意味します。 |
コンテナサーバ設定
コンテナサーバ設定サンプルはソースコードリポジトリの etc/container-server.conf-dsampleにあります。
以下の設定オプションが有効です：
テーブル4.6. container-server.confの[DEFAULT]セクションのデフォルトオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| swift_dir | /etc/swift | Swift設定ディレクトリ |
| devices | /srv/node | デバイスがマウントされる親ディレクトリ |
| mount_check | true | 誤ってルートデバイスへの書き込みを避けるためデバイスマウント時チェックをするかどうか |
| bind_ip | 0.0.0.0 | バインドするサーバのIPアドレス |
| bind_port | 6000 | バインドするサーバのポート番号 |
| workers | 1 | フォークするワーカの数 |
| user | swift | 実行ユーザ |
テーブル4.7. container-server.confの[container-server]セクションのサーバオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| use | コンテナサーバのpaste.deployエントリポイント。ほとんどのケースではegg:swift#containerにすべきです。 | |
| log_name | container-server | ログ出力時のラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| node_timeout | 3 | 外部サービスのりクエストタイムアウト |
| conn_timeout | 0.5 | 外部サービスのコネクションタイムアウト |
テーブル4.8. container-server.confの[container-replicator]セクションのレプリケータオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| log_name | container-replicator | ログ出力時のラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| per_diff | 1000 | |
| concurrency | 8 | 生成されるレプリケーションワーカ数 |
| run_pause | 30 | レプリケーションがパスされる間隔（秒） |
| node_timeout | 3 | 外部サービスのりクエストタイムアウト |
| conn_timeout | 0.5 | 外部サービスのコネクションタイムアウト |
| reclaim_age | 604800 | コンテナが再クレームされるまでの経過時間（秒） |
テーブル4.9. container-server.confの[container-updater]セクションのアップデータオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| log_name | container-updater | ログ出力時のラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| interval | 300 | 取得するためのパス最小時間 |
| concurrency | 4 | 生成されるアップデータワーカ数 |
| node_timeout | 3 | 外部サービスのりクエストタイムアウト |
| conn_timeout | 0.5 | 外部サービスのコネクションタイムアウト |
| slowdown | 0.01 | コンテナ間の待機時間（秒） |
テーブル4.10. container-server.confの[container-auditor]セクションのオーディッタオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| log_name | container-auditor | ログ出力時のラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| interval | 1800 | 取得するためのパス最小時間 |
アカウントサーバ設定
アカウントサーバ設定サンプルは、ソースコードリポジトリの etc/account-server.conf-sample を参照して下さい。
以下の設定オプションが有効です：
テーブル4.11. account-server.confの[DEFAULT]セクションのデフォルトオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| swift_dir | /etc/swift | Swift設定ディレクトリ |
| devices | /srv/node | デバイスがマウントされる親ディレクトリ |
| mount_check | true | 誤ってルートデバイスへの書き込みを避けるためデバイスマウント時チェックをするかどうか |
| bind_ip | 0.0.0.0 | バインドするサーバのIPアドレス |
| bind_port | 6000 | バインドするサーバのポート番号 |
| workers | 1 | フォークするワーカの数 |
| user | swift | 実行ユーザ |
テーブル4.12. account-server.confの[account-server]セクションのサーバオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| use | アカウントサーバのpaste.deployエントリポイント。多くのケースではegg:swift#accountにすべきです。 | |
| log_name | account-server | ログ出力時のラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
テーブル4.14. account-server.confの[account-auditor]セクションのオーディッタオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| log_name | account-auditor | ログ出力時のラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| interval | 1800 | 取得パスの最小時間 |
テーブル4.15. account-server.confの[account-reaper]セクションのリーパオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| log_name | account-auditor(※reaperの誤り？) | ログ出力時のラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログ出力レベル |
| concurrency | 25 | 生成されるレプリケーションワーカ数 |
| interval | 3600 | 取得パスの最小時間 |
| node_timeout | 10 | 外部サービスのリクエストタイムアウト |
| conn_timeout | 0.5 | 外部サービスのコネクションタイムアウト |
プロクシサーバ設定
プロクシサーバ設定サンプルは、ソースコードリポジトリの etc/proxy-server.conf-sample を参照して下さい。
以下の設定オプションが有効です：
テーブル4.16. proxy-server.conf [DEFAULT]セクションのデフォルトオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| bind_ip | 0.0.0.0 | バインドするサーバのIPアドレス |
| bind_port | 80 | バインドするサーバのポート番号 |
| swift_dir | /etc/swift | swift設定ディレクトリ |
| workers | 1 | フォークするワーカ数 |
| user | swift | 実行ユーザ |
| cert_file | ssl.crtのパス | |
| key_file | ssl.keyのパス |
テーブル4.17. proxy-server.conf [proxy-server]セクションのサーバオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| use | プロクシサーバのpaste.deployエントリポイント。多くの場合egg:swift#proxyを指定すべきです。 | |
| log_name | proxy-server | ログ出力ラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログレベル |
| log_headers | True | Trueの場合、各リクエストログヘッダを表示します。 |
| recheck_account_existence | 60 | 既存コンテナをmemcachedへ送るキャッシュタイムアウト（秒） |
| object_chunk_size | 65536 | オブジェクトサーバから読み込み時のチャンクサイズ |
| client_chunk_size | 65536 | クライアントから読み込み時のチャンクサイズ |
| memcache_servers | 127.0.0.1:11211 | memcachedサーバのリスト（IPアドレス:ポート番号 をカンマで連結） |
| node_timeout | 10 | 外部サービスのリクエストタイムアウト |
| client_timeout | 60 | クライアントからチャンクを読む時のタイムアウト |
| conn_timeout | 0.5 | 外部サービスのタイムアウト |
| error_suppression_interval | 60 | もうこれ以上エラー制限がないと考慮される最後のノードエラーとの間隔（秒） |
| error_suppression_limit | 10 | これ以上エラー制限を考慮されないエラー数 |
| allow_account_management | false | アカウントがPUTやDELETEが呼び出し可能かどうか |
テーブル4.18. proxy-server.conf [filter:swauth]セクションのpaste.deployオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| use | プロクシサーバのpaste.deployエントリポイントで、 https://github.com/gholt/swauth からダウンロードしてswauthを使用する場合egg:swauth#swauthを指定すべきです。 | |
| log_name | auth-server | ログ出力ラベル |
| log_facility | LOG_LOCAL0 | syslogログファシリティ |
| log_level | INFO | ログレベル |
| log_headers | True | Trueの場合、各リクエストログヘッダを表示します。 |
| reseller_prefix | AUTH | 認証サーバのネーミングスコープ。swiftストレージアカウントや認証トークンはこの先頭文字列が付きます。 |
| auth_prefix | /auth/ | 認証サーバのHTTPリクエストパス先頭文字列。swift自身は"v"から始まる文字列を予約しています。 |
| default_swift_cluster | local#http://127.0.0.1:8080/v1 | 新規アカウントを配置するデフォルトのswiftクラスタ（swauthを使用している場合のみ必要） |
| token_life | 86400 | トークンが妥当である秒数 |
| node_timeout | 10 | リクエストタイムアウト |
| super_admin_key | None | .super_adminアカウントのキー |
| recheck_account_existence | 60 | 既存コンテナをmemcachedへ送るキャッシュタイムアウト（秒） |
| object_chunk_size | 65536 | オブジェクトサーバから読み込み時のチャンクサイズ |
| client_chunk_size | 65536 | クライアントから読み込み時のチャンクサイズ |
| memcache_servers | 127.0.0.1:11211 | memcachedサーバのリスト（IPアドレス:ポート番号 をカンマで連結） |
| node_timeout | 10 | 外部サービスのリクエストタイムアウト |
| client_timeout | 60 | クライアントからチャンクを読む時のタイムアウト |
| conn_timeout | 0.5 | 外部サービスのタイムアウト |
| error_suppression_interval | 60 | もうこれ以上エラー制限がないと考慮される最後のノードエラーとの間隔（秒） |
| error_suppression_limit | 10 | これ以上エラー制限を考慮されないエラー数 |
| allow_account_management | false | アカウントがPUTやDELETEが呼び出し可能かどうか |
配置や設備をチューニングする際には、若干の時間や努力が必要かもしれません。本章ではOpenStack Object Storage設備のパフォーマンスを向上させるいくつかの考慮事項を紹介します。
memcachedにおける考慮事項
幾つかのサービスは、認証トークや既存のコンテナ/アカウントなどのタイプ検索キャッシュでmemcachedを使用しています。Swiftは実オブジェクトデータのキャッシングを一切行なっていません。RAMやCPUが有効であればmemcachedはどんなサーバ上でも動作させることができます。Rackspace社ではmemcahcedをプロクシサーバ上で動作させています。
proxy-server.conf内の設定オプションmemcache_serversはすべてのmemcahcedサーバを含めなければなりません。
システム時刻
時刻は相対的(relative)ですが、Swiftでは比較的(relatively)重要です！Swiftユーザはオブジェクトの最新版であることを決めるためにタイムスタンプを使用します。クラスタ上の各サーバができるだ可能な限り密接にsyncするシステムタイムが大変重要です（プロクシサーバにとってより重要ですが、一般的にすべてのサーバにとって）。システム時刻ができるだけ密接になるようにするために、Rackspace社ではローカルNTPサーバによるNTPを使用しています。時刻がそれほどずれないように監視すべきです。
ほとんどのサービスは単独のワーカか並列値の設定かどちらかをサポートしています。これは、サービスにコアの有効利用を許します。プロクシやストレージサービスの並列レベルとして有効コア数の２倍を最初にセットすることはよいことです。もし１より多いサービスが１つのサーバをシェアしているのであれば、最良のバランスを見つけるための試行が必要になるかもしれません。
Rackspace社では、プロクシサーバは、デュアルクアッドコアプロセッサ、８コアを持っています。Rackspace社のテストでは、16ワーカーが、10gネットワークでのサチレーションや良好なCPU使用公立のために調度良いバランスであることがわかっています。
Rackspace社のストレージサーバはすべて同一のサーバ上で一緒に動作しています。これらのサーバは、デュアルクアッドコア、全部で８コアを保有しています。アカウント、コンテナ、オブジェクトサーバを各々８ワーカで動作させています。レプリケータ（並列値2）という例外を除き、ほとんどのバックグラウンドジョブは並列値１で実行されます。
上記の設定は推奨であり、CPU使用効率、ネットワーク接続姓やディスクI/Oを保証するための設定テストを済ませています。
ファイルシステムの考慮事項
Swiftは大部分がファイルシステムに対して明確な見解なく設計されています－唯一の要件はファイルシステムが拡張属性(xattrs)をサポートしていることだけです。ユースケースやハードウェア構成の徹底的なテストの結果、多目的でXFSがベストの選択でした。もしXFS以外のファイスシステムの利用を決めるなら、テストを行うこと強く薦めます。
もしXFSを使用するのであれば、幾つかの設定値が劇的にパフォーマンスに影響します。以下のようなXFSパーティション構築を推奨します：
mkfs.xfs -i size=1024 -f /dev/sda1
XFSがxattrデータをiノートへ格納するため、iノードサイズ設定は重要です。もしメタデータがあまりにも大きくてiノードへフィットしないのであれば、新規エクステントが作成されます、そしてそれはパフォーマンス問題をよく引き起こします。iノードサイズを1024バイトへ上げることはデフォルトメタデータ書き込みのための十分なスペース（、にくわえて少しのヘッドスペース）を提供します。SwiftでRAIDを使用することは推奨しません、しかしもしRAIDをつかいたのであればXFSがRAIDアレイの大部分を効率的に利用することができるように、適当なsunitおよびswidthの設定を用意することもまた重要です。
XFSを使用する場合は、マウント時に以下のようなオプションをつけることを推奨します:
mount -t xfs -o noatime,nodiratime,nobarrier,logbufs=8 /dev/sda1 /srv/node/sda
標準swiftインストールの場合、すべてのデータデバイスは/srv/node以下にマウントされます（上記のコマンド例では/dev/sda1を/srv/node/sdaへマウント）。もし他のディレクトリへのマウントを選択するのであれば、全サーバのデバイス設定オプションを正しいディレクトリを指すよう変更して下さい。
Rackspace社では現在SwiftをUbuntu Server10.04上で動作させています、そして自分たちのユースケースに合わせて次のような変更を行なっています。
以下の様な設定を/etc/sysctl.confへ行なっています：
# disable TIME_WAIT.. wait..
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
# disable syn cookies
net.ipv4.tcp_syncookies = 0
# double amount of allowed conntrack
net.ipv4.netfilter.ip_conntrack_max = 262144
更新されたsysctl設定をロードするにはsudo sysctl -pを実行して下さい。
TIME_WAIT値を変更していることに注意して下さい。残りのパケット受領を保証するためにOSはデフォルトではポートオープンで60秒ホールドします。
高負荷時、あるいは生成されるコネクションの数で、ポート範囲外で実行することは簡単です。ネットワーク管理下にいる限りはこの値を変更するか、高負荷を想定せずにそれらの値を調整しても良いです。
ログ出力に関する考慮事項
Swiftは直接syslogへログを出力するセットアップになっています。各サービスはlog_facilityオプションを使ってsyslogログファシリティ出力先を設定する事ができます。syslog-ngを使ってサーバ上の特定のローカルのログファイルあるいはリモートのログ記録用サーバのログをローテーションさせることを推奨します。
リングの働き
リングはデータをクラスタ上のどこに配置するかを決定します。アカウントデータベース、コンテナデータベース、個々のオブジェクトの分離したリングがあります、しかし各リングは同じ手順で動作します。リングは、サーバプロセス自身リングを更新しないように（代わりにリング更新のための他のツールが与えられている）完全に管理されています。
リングはデバイスを示すパーティションインデックスとしてパスのMD5ハッシュ値からの可変ビット数を使用します。ハッシュ値からのビット数はパーティション乗数として知られています、そしてパーティション乗数が２はパーティション数を表しています。完全なMD5ハッシュリングのパーティショニングは、、クラスタの他の部分に対して、より有用か各アイテム別々にもしきは突然クラスタ全体での動作することより少なくとも複雑ではないかのどちらかで終了するアイテムのバッチが、直ちに動作することを許可します。
もう１つの設定可能値はレプリカ数で、これは単一のリングで構成されるパーティション→デバイス 割り当ての数を表しています。定められたパーティション番号により、各レプリカのデバイスは、他のどのレプリカのデバイスとも同じゾーンに存在しません。ゾーンは、物理ロケーション、電力系統、ネットワークやその他の複数のレプリカ同時に複数のレプリカが無効となるほかの項目に基づいたデバイスのグループ化に利用されます。
リングビルダを使ったリング管理
リングはリングビルダと呼ばれるユーティリティにより構築、手動管理されます。リングビルダはデバイスへパーティションを割り当て、最適化されたPython構造をgzip化された、ppicke化されたディスク上のファイルへ書き込みます。サーバプロセスは時々ファイル更新時間をチェックし、必要に応じてリング構造のインメモリコピーを再ロードします。リングビルダがリングの変更管理を行う方法により、少し前のリングを使うことは時々パーティションのサブセットの３つのレプリカのうちの１つが誤っていることを意味します。そしてそれはより簡単にとりかかることができます。
リングビルダはまたリング情報や将来のリングを構築するために必要な追加情報を自身のビルダファイルに保存します。ビルダファイルの複数のバックアップコピーを取ることは重要です。オプションの一方は、ビルダファイルを各サーバがリングファイル自身をコピーしている間外部へコピーするためのものです。他方のオプションは、クラスタ自身のビルダファイルをアップロードするためのものです。ビルダファイルの完全喪失は、新たなリングをスクラッチで作成することを意味します。そしてほぼすべてのパーティションは最終的に異なるデバイスへ割り当てられることになります。それゆえほとんどすべてのデータは新しいロケーションへ複製しなくてはなりません。このため、ビルダファイル損失からの復旧は可能ですが、データは拡張された時間では確実に到達できません。
リングデータ構造について
リングデータ構造は３つのトップレベルフィールドから構成されています：クラスタ内のデバイスリスト、パーティションに割り当て対象として表示するデバイスIDリスト群、そしてパーティションのハッシュ値計算のためのMD5ハッシュ値をシフトするビット数を示す整数です。
リング上のデバイスリスト
デバイスリストは、devsとしてリングクラスに内部で認識されています。デバイスリストの各項目は以下のキーを使ったディクショナリとなっています：
テーブル4.19. デバイスとキーのリスト
| キー | タイプ | 説明 |
|---|---|---|
| id | 整数 | リストデバイスのインデックス |
| zone | 整数 | デバイス配置されるゾーン |
| weight | 浮動小数点数 | 他のデバイスと比較した相対的なデバイスのウェイト。この値は普通他のデバイスと比較されたデバイスのディスク容量と直接一致します。例えば、ある１テラバイトのデバイスのウェイトは100.0で、別の２テラバイトのデバイスのウェイトは200.0です。時間とともに要求されるデータ量増減を終わらせたデバイスのバランスを取り戻す時にも使用します。平均ウェイト100.0にすることで必要に応じてウェイトを後で下げる柔軟性を提供します。 |
| ip | 文字列 | デバイスが搭載されているサーバのIPアドレス |
| port | 整数 | デバイスのリクエストの対応を行う受付サーバプロセスのTCPポート番号 |
| device | 文字列 | デバイスのディスク上の名前。例：sdb1。 |
| meta | 文字列 | デバイスの追加情報を格納する一般利用のフィールド。情報はサーバプロセスが直接利用しませんので、デバッグに使用できます。例えば、インストールやハードウェア製造元のデータや時刻などをここに格納できます。 |
パーティション割り当てリスト
これは、デバイスID配列('I')リストです。最も外側のリストは、レプリカごとに配列('I')を含んでいます。各配列('I')はリングのパーティションカウントと等しい長さを持っています。配列('I')の各整数はデバイスリスト上のインデックスです。パーティションリストはリングクラスに対して_replica2part2dev_idとして内部認識されます。
このため、パーティションに割り当てられたデバイスディクショナリリストを作成するために、Pythonコードは以下のようになります：
devices = [self.devs[part2dev_id[partition]] for part2dev_id in self._replica2part2dev_id]
数百万のパーティションになるので、配列('I')はメモリ保護のために使用されます。
パーティションシフト値
パーティションシフト値は_part_shiftとしてリングクラスで内部認識されています。この値は、ハッシュが存在すべきデータ上のパーティションを計算するMD5ハッシュをシフトするために使用されます。ハッシュの先頭4バイトだけはこのプロセス内で使用されます。たとえば、パス/account/container/objectのパーティションを計算するためのPythonコードは以下のとおりです：
partition = unpack_from('>I', md5('/account/container/object').digest())[0] >>self._part_shift
リングのビルド
リングの初期のビルドでは最初にデバイスのウェイトを元に各デバイスへ割り当てる理想的なパーティション数を算出します。例えば、パーティションが20乗であれば、1,048,576(2の20乗) パーティションとなります。もし同一のウェイトで1000デバイス存在するなら、各々1,048.576パーティション希望するでしょう。デバイスは次に希望するパーティション数でソートし、初期プロセスのいたるところで順番に保持されます。
-------
..次のバージョンでちゃったし..
おじさん、もう疲れちゃった..
