OpenStack: 分散オブジェクトストレージ Swift　第2回: Swiftの機能

実際にSwiftに対してオブジェクト操作が行われた時の内部の動きを追いかけてみましょう。

【オブジェクトのGET】

1. プロキシは、クライアントからのGET要求を受け付ける。

2. プロキシは、アカウントサーバにアカウントの存在を問い合わせる。

3. アカウントサーバは、アカウント情報を返却。

4. プロキシは、コンテナサーバにコンテナ情報を問い合わせる。

5. コンテナサーバは、コンテナ情報を返却する。ACL情報も含まれる。

6. アクセス権があれば、プロキシはオブジェクトサーバに、オブジェクト取得を要求する。

7. オブジェクトサーバは、オブジェクトの中身を読みだし、プロキシに返却する。

8. プロキシは、クライアントに、オブジェクトの中身を返却する。

アカウント、コンテナ、オブジェクトのアクセスのいずれかが失敗することがあります。その場合、プロキシは同じデータの複製を持つサーバを選びリトライを行います。
データの複製をもつサーバすべてが障害を起こしていない限り、目的のオブジェクトを取り出すことができます。

レプリケータは、本来データの複製があるべきところに、最新データを配置しようとします。各レプリケータは、自マシン上のデータと本来あるべきマシン上の複製とを照合し、それら全てが最新のデータを持つようにします。複数あるデータの複製のひとつが掛けてしまった場合、または古いデータが残っている場合、サーバ故障などにより代替のサーバ上にデータが置かれている場合など、障害の原因が取り除かれるとただちに、自動的にあるべきデータ配置に修復されることになります。

レプリケーション処理は、データを持っているマシン上のレプリケータが行います。自マシンのデータ障害を修復するために、正しいデータをもつマシンを探して、そこからデータをコピーして来るという動きはしません。データ障害をもつマシン上のレプリケータは単に口を空けて待つことが仕事です。口を空けていれば、最新のデータを持つ別のマシンのレプリケータから、データ転送が行われることになります。

オブジェクトのレプリケータの場合、もともとこの異なるマシン間のデータの同期ずれの検出とデータの転送を、全てrsync機能に任せていました。しかし、この処理は非常にCPU時間を消費するため現在は少しチューニングが施されています。一度同期が確認された箇所は、その箇所に何か変更が発生する、または障害が発生するまでは、rsync処理の対象から外すように工夫しています。

何らかの障害からの復旧後にレプリケータが動作するときには、システム上に新旧のデータが混在している可能性があります。ネットワーク障害やサーバダウンが発生中にオブジェクトが更新されると、新旧世代のオブジェクトが同時に存在する状態になります。障害からの復旧後、互いに自分の持っているデータを相手に送り合います。その結果、一つのオブジェクトサーバ配下に、一つのオブジェクトに対して複数バージョンのオブジェクトの複製が集まることがあります。オブジェクトサーバ上に保存されるオブジェクトは更新のたびに新しいタイムスタンプを付与するので、rsyncでコピーして一箇所に集めても、オブジェクトが上書きされることなく、タイムスタンプが異なるオブジェクトの複製が複数共存する状態になります。

このような状態になったとしても、オブジェクトサーバは一番新しいタイムスタンプが付いているオブジェクトの複製を有効として扱うため、古い世代のオブジェクトがアクセスされることはありません。また、ここでオブジェクト削除時に残すtombstoneファイルが重要な役目を果たします。tombstoneファイルを残すことにより、オブジェクト削除状態もrsync機能により他のマシンに伝搬させることが可能となります。Tombstoneの仕組みが無ければ、削除したはずのオブジェクトが復活してしまうという現象を目にするかもしれません。

レプリケータは、ゴミ掃除の仕事も担当しています。一つのオブジェクトに対して複数世代のオブジェクトの複製が残っている場合、古い世代のものは削除します。また、tombstoneも十分長い時間が経過した後には削除してしまいます。

オブジェクトのデータの同期にはrsyncを利用すると説明しましたが、コンテナやアカウントのレプリケータは、更新のあったレコードの情報のみを送り合う仕組みも併用しています。前回の同期処理を行った後に更新されたレコードより後に更新されたレコードの整合性確認のみを行います。

Swiftの運用を続けていると、マシンを追加してシステムの能力を増強したり、調子の良くないマシンを交換することが必要になってきます。

このような場合Swiftでは、リングを新しいハードウェア構成に合わせて作り直し、全てのサーバに配布し直す必要があります。新しいリングの更新処理は以下のことを考慮して行われます。

• システムが止まらないこと。Swift上のオブジェクトやコンテナが常にアクセスできる状態にあること。
• オーバヘッドが小さいこと。

リングの再構成は、オフラインでリングビルダという専用ツールを用いて行います。
リングビルダは、パーティションとディスクの対応づけ情報を変更します。前回リングを作成した時の情報を、リング作成時に作られる中間ファイル（ビルダファイル）から取り出し、マシンの追加削除情報と組み合わせて新しいリングを作成します。このとき、以下の事項を考慮してパーティションの再配置を行います。

• 同じzoneにはパーティションの複製を置かない。
• あるパーティションに対応する複製のうち、複数を同時に移動させない（配置場所を変更しない）。
• 最近移動を行ったばかりのパーティションは、移動対象から外す。
• 移動しなければならないパーティションの複製の数をなるべく少なくする。
• 可能な限り、全てのディスクに偏り無くパーティションを配置する。

リングビルダは、何度もパーティション配置を計算し直し、ベストに近い配置方法を求めます。

新しいリングができたら、全てのサーバに配布します。サーバは一定時間毎にリングを監視しており、リングが更新されたことを検知するとリングの情報をサーバのメモリ内に読み込みます。
各サーバにリング配布する時刻およびリングの情報がメモリに読み込まれるタイミングは、サーバ毎にズレが生じます。

これが意味するところは、リングの更新時には古いリングの情報で動作しているサーバと、新しいリングの情報で動作しているサーバが混在しているということです。
混在していたとしても、既にあるオブジェクトのデータは読み出せますし、新しいオブジェクトにデータを書き込むこともできます。
古いリングの情報に示されたサーバにデータが書き込まれてしまうかもしれません。しかし、最終的には全てのリングが最新になり、レプリケータがその新しいリングに従ってデータの移動を行い、全てのデータの整合性が保たれた状態になります。

Swiftの認証システムは任意のものを組み込み可能です。
現在、以下の3つから選択して利用できます。

• Swauth
• OpenStack Identity – Keystone
• tempauth

Swift単体で運用する場合は、Swift専用の認証システムswauthを選ぶと良いでしょう。swauthは、認証データ自体もオブジェクトしてSwift上に保存しています。これにより、認証データの冗長化とアクセス時の負荷分散を実現しています。

OpenStack Compute – Nova と組み合わせて利用する場合は、OpenStackプロジェクト共通の認証モジュールIdentity(Keystone)を利用します。

Swiftの認証を、既存システムの認証システムと連係させたい場合には tempauth を利用します。Swiftプロジェクトが提供しているtempauthは移植用のサンプルコードであり、このコードを改造して既存システムと連係させることが求められます。

いずれの認証システムを選択した場合でも、認証の仕組みは同一です。ユーザクライアントは、Swiftを利用するにあたり、認証システムにアカウント名、ユーザ名、パスワードを渡し、トークンを発行してもらう必要があります。認証システムはアカウント名、ユーザ名、パスワードの有効性を確認し、クライアントにトークンを返却します。
以降、ユーザクライアントはSwiftのAPIを呼び出す時は必ずこのトークンをリクエストヘッダに埋め込まねばなりません。認証システムは、API呼び出し毎にトークンの有効性をチェックし、またトークン情報を基にアクセス権を制御します。

Swiftはトークン情報をmemcachedにキャッシュし、認証処理のスケーラビリティを確保しています。このトークンには有効期限があり、この期限を過ぎてトークンを利用しようとすると、認証システムは認証エラーを返します。クライアントは、一定時間毎にトークンの再発行手続きを行うことが求められます。