OpenStack: 分散オブジェクトストレージ Swift 第7回: Swift運用のTips

リングを管理する

プロキシサーバノード上でストレージ管理のためのリングを作成し、それらをクラスタ内の全てのノードに配布する必要があります。
リングには、ストレージパーティションをどのノードのディスク(デバイス)に配置するかの情報が置かれています。リングの詳細は、「Swiftの概要と構造」を参照ください。
なお、これらの情報は、Swift Project pageを参照しています。

1. リングからデバイスを削除するには次のようにします。


														swift-ring-builder <builder-file> remove <ip_address>/<device_name>

2. リングからノードを削除するには次のようにします。


														swift-ring-builder <builder-file> remove <ip_address>

3. リングにデバイスを追加するには次のようにします。


														swift-ring-builder <builder_file> add z<zone>-<ip>:<port>/<device_name>_<meta> <weight>

4. あるノードに接続されているデバイスのうち、条件に一致するデバイスを調べるには次のようにします。


														swift-ring-builder <builder-file> search <ip_address>

5. リングを変更した後には、それらの変更を”コミット”する必要があります。


														swift-ring-builder <builder-file> rebalance

リングを作り直した時は、そのリングをクラスタ内の全てのノードにコピーする必要があります。

リング作成のスクリプト化

アカウント用およびコンテナ用のリングの作成とバランス調整を行うスクリプトを作成することができます。
以下に、アカウント用のリングを作成するスクリプトの例を記載します。
プロキシノード上でmake-container-ring.shスクリプトを作成する時と同じようなコマンドを使用します。

1. プロキシノード上で次の内容のスクリプトファイルmake-account-ring.shを作成する。

#!/bin/bash
cd /etc/swift
rm -f account.builder account.ring.gz backups/account.builder backups/account.ring.gz
swift-ring-builder account.builder create 18 3 1
swift-ring-builder account.builder add z1-<account-server-1>:6002/sdb1 1
swift-ring-builder account.builder add z2-<account-server-2>:6002/sdb1 1
swift-ring-builder account.builder rebalance

<account-server-1>、<account-server-2>などの値は、初期設定を行っているアカウントサーバのIPアドレスに置き換えてください。アカウントサーバは、いくつでも必要なだけ設けることができます。
ここでは、全てのアカウントサーバはポート6002をlistenし、ストレージデバイス”sdb1″(これはアカウントサーバをセットアップした時/srv/nodeの下に作成されるディレクトリ名)を持つものとします。”z1″、”z2″はゾーンを表し、それぞれのデバイスをどのゾーンに入れるか選択することが可能です。

2. このスクリプトファイルを実行可能にし、それを実行してアカウント用のリングファイルを作成します。


														chmod +x make-account-ring.sh

 sudo ./make-account-ring.sh

3. 生成されたリングファイル/etc/swift/account.ring.gzをSwift環境の全てのアカウントサーバが、動作するノードの/etc/swiftディレクトリにコピーします。アカウントのリングの設定を変更した時には、生成されたリングファイルを毎回、全てのノードに配布することを忘れないようにしてください。

システム更新の処理

システムの更新と再起動は、ゾーンごとに別のタイミングで行うことを推奨します。この手順を踏むことにより、Swiftクラスタのサービスを止めることなく、システムを更新することができます。また、一つのゾーンの更新が終わった後、次のゾーンの更新を始める前にしばらくそのまま運用し、その更新が問題を起こさないことを確認することを推奨します。

ディスク障害の処理

ディスクの障害が発生した場合に最初に行うステップは、ディスクのマウントを解除することです。これによりSwiftは、問題が解決されるまでの間、障害を簡単に迂回できるようになります。ディスクをただちに交換できる場合には、ディスクを交換してからフォーマットと再マウントを行い、後はレプリケーションに任せ、データが自動的に復元されるのを待つだけでよいです。ディスクをただちに交換できない場合は、マウントを解除したままにしておき、そのディスクをリングから削除するのがベストです。これで、ディスクが交換されるまでの間、そのディスク上にあった全てのレプリカは、別のディスクのどこかに置かれるようになるため、ディスクが交換された時点で、ディスクを再びリングに追加すればよいのです。

ノード障害の処理

ノードがハードウェア上の問題を抱えている場合は、そのサーバ上のSwiftサービスを止めておいてください。運用者がトラブルシューティングを行っている間、障害を迂回してサービスが継続されます。
ノードを再起動するだけか、数時間程度の作業で復旧できるのであれば、障害の迂回をSwiftに任せておいて、サーバを修復して再起動するのが最善です。ノードがオンラインに復帰すると、レプリケーション処理によりダウン中に更新されなかったデータの更新が確実に行われます。
ノードがもっと重大な問題を抱えている場合は、ノードの全てのデバイスをリングから削除してしまうとよいでしょう。ノードが修理されてオンラインに復帰した時点で、サーバのデバイスを再びリングに追加します。追加時には、デバイスを再フォーマットしてからリングに戻すことが重要です。修理前とは全く異なるパーティション群が、このデバイス上に配置されることになるからです。

障害ディスクの検出

ディスク障害が起こりそうになると、/var/log/kern.logに記録されるエラーメッセージ数が急激に増えます。cron経由で実行して不良デバイスを監視するswift-drive-auditというスクリプトがあります。
このスクリプトがエラーを検出すると不良ディスクのマウントを解除するので、Swiftはエラーを迂回することが可能です。このスクリプトは、以下のオプション指定ができる設定ファイルを引数に取ります。

[drive-audit]

このスクリプトは、Ubuntu 10.04でしか動作確認されていません。そのため、他のディストリビューションまたはOSで使用する場合には、本格的な運用に入る前に十分な評価を行うことが必用です。

クラスタの健全性

クラスタの健全性を測定するswift-stats-reportというツールがあります。この測定では、コンテナやオブジェクトが意図通りに分散され、クラスタ内の適切な場所に保存されているかどうかを確認します。
例えば、通常各オブジェクトは3つのレプリカを持っています。このオブジェクトの健全性は、各レプリカが適切な場所に配置されているかどうかを確認することによって測定できます。3つのうちの2つだけが適切な場所にある場合、そのオブジェクトの健全性は66.66%であるとされています(100%の時に完全)。
作成から時間の経過したオブジェクトであれば、そのオブジェクト1つの健全性は、そのオブジェクトが存在するパーティション全体の健全性を反映しています。クラスタ内の一定割合のパーティション群にオブジェクトを配置してみれば、クラスタ全体の全般的な健全性について妥当な評価を行うことが可能です。実際、全体の約1%のパーティションを対象に確認するあたりが、評価の精度と結果を得るための時間のバランスが取れているでしょう。

この健全性の値を得るためには、最初に新しいアカウントを作成します。次に、異なるパーティションに置かれるように、システム上にコンテナやオブジェクトを配置していきます。swift-stats-populateツールは、コンテナおよびオブジェクトの名前をランダムに生成し、バラバラのパーティションにそれらを配置していきます。後は、クラスタの運用を続ける間、繰り返しswift-stats-reportツールを実行して、これらのコンテナおよびオブジェクトのそれぞれの健全性を確認します。これらのツールは、クラスタ全体のノードと全てのリングファイルに直接アクセスする必要があるため、これらツールはプロキシノードにインストールするのがよいでしょう。
swift-stats-populateツールとswift-stats-reportツール設定は、設定ファイル/etc/swift/stats.confにて行います。以下に、サンプルの設定ファイルを記載します。

[stats]
auth_url = http://saio:11000/auth/v1.0
auth_user = test:tester
auth_key = testing

設定ファイルでは、パーティションのカバー率(デフォルト1％)、再試行回数、実行時の並列度、csv形式の出力指定などのオプションも利用できますが、通常はデフォルト設定で十分です。設定ファイルの編集が完了したら、swift-stats-populate -dを実行し、コンテナとオブジェクトをクラスタ全体に配置します。コンテナとオブジェクトの配置が終わったら、swift-stats-report -dを実行し、クラスタの全般的な健全性のレポートを取得します。健全性が完全なクラスタの例を以下に記載します。


														$ swift-stats-report -d

 Queried 2621 containers for dispersion reporting, 19s, 0 retries

 100.00% of container copies found (7863 of 7863)

 Sample represents 1.00% of the container partition space
 Queried 2619 objects for dispersion reporting, 7s, 0 retries

 100.00% of object copies found (7857 of 7857)

 Sample represents 1.00% of the object partition space

ここで、オブジェクト用リング内のあるデバイスの加重(weight)を意図的に倍にした後、swift-stats-report -dを再度実行してその影響を見ることにしましょう。実験のために、レプリケーション機能をオフにしておきます。


														$ swift-ring-builder object.builder set_weight d0 200

 $ swift-ring-builder object.builder rebalance

 …

 $ swift-stats-report -d

 Queried 2621 containers for dispersion reporting, 8s, 0 retries

 100.00% of container copies found (7863 of 7863)

 Sample represents 1.00% of the container partition space
 Queried 2619 objects for dispersion reporting, 7s, 0 retries

 There were 1763 partitions missing one copy.

 77.56% of object copies found (6094 of 7857)

 Sample represents 1.00% of the object partition space

クラスタ内のオブジェクトの健全性が著しく低下したことが分かります。もちろん、4つのデバイスしかないテスト環境で評価したためであり、もっと多くのデバイスが存在する実運用環境では、1つのデバイスの設定変更による影響はもっと小さなものになります。次に、レプリケータを動かし、全てのデータが設定通りのところに置かれるようにしてから、swift-stats-report -dを再び実行します。


														… オブジェクトレプリケータを開始し、レプリケーション処理が終わるまでログを監視する …

 $ swift-stats-report -d

 Queried 2621 containers for dispersion reporting, 17s, 0 retries

 100.00% of container copies found (7863 of 7863)

 Sample represents 1.00% of the container partition space
 Queried 2619 objects for dispersion reporting, 7s, 0 retries

 100.00% of object copies found (7857 of 7857)

 Sample represents 1.00% of the object partition space

以上が、クラスタの健全性を監視するswift-stats-reportの使い方の概略です。
パフォーマンスの監視など、これ以外の機能もいくつかあるが、現在のところ、それらはまだ開発段階であり、ほとんど使用されていません。例えば、swift-stats-populate -pとswift-stats-report -pでパフォーマンスのタイミングデータを取得できますが、この処理は初期化に時間がかかります。
これらのタイミングデータは、CSVファイル(デフォルトでは、etc/swift/stats.csv)に出力され、これをグラフ化すれば、クラスタのパフォーマンスの傾向を見ることができます。

Swauth用の補足的なクリーンアップスクリプト

Swauthを利用している場合、有効期限が切れ、ゴミとなったトークンを掃除するcronjobをインストールするとよいでしょう。これらの有効期限が切れたトークンが生じるのは、1人のユーザが認証を複数回同時的に行った時です。一般に、これらの有効期限が切れたトークンはそれほど問題にならないが、トークンの有効期限(既定値は1日、すなわち86400秒)の間に1回掃除することを推奨します。
設定は簡単であり、具体的には、Swauthを実行しているプロキシノードのいずれかにおいて、crontabエントリにswauth-cleanup-tokens -A https://<PROXY_HOSTNAME>:8080/auth/ -K swauthkey > /dev/nullを追加するだけです。

デバッグのヒントとツール

Swiftに向けて発行されたリクエストには一意のトランザクションIDが与えられる。このIDは、そのリクエストに関係する全てのログ行に含まれているはずです。これは特定のリクエストによって駆動された全てのサービスを調べる時に便利です。
特定のアカウント、コンテナ、オブジェクトがクラスタ内のどこに配置されているかを知る必要がある場合は、swift-get-nodesコマンドで各レプリカの場所を調べます。
サーバ上のオブジェクトを調べていて、更に情報が必要になった場合には、swift-object-infoコマンドそのオブジェクトのアカウント、コンテナ、レプリカの位置とメタデータを表示します。
アカウントのデータを監査したい場合は、swift-account-auditでアカウントをクロールして、見つかった全てのコンテナおよびオブジェクトをチェックすることが可能です。

サービスを管理する

Swiftサービスの管理にはswift-initを使用します。swift-init <service> <command>の形式で利用します。
serviceは管理対象とするSwiftサービス(object、container、account、proxyなど)で、次のcommandなどが使用可能です。

サービスのシャットダウンでは、現在処理中のリクエストが全て完了してから、サービスを停止します。また、serviceにall引数を指定することもできます。swift-init all <command>では、全てのSwiftサービスに対してコマンドが実行されます。

オブジェクトオーディタ(Object Auditor)

システム障害時、XFSファイルシステムは書き込み途中のファイルを切り捨てたり、0バイトのファイルを生成したりすることがあります。object-auditorはこれらの問題を検出するが、システムクラッシュ時には、レート制限を緩くしたオブジェクトファイル一掃コマンドを実行して、これらの壊れたファイルをすぐに検出するとよいでしょう。
このコマンドは、”swift-object-auditor /etc/swift/object-server.conf once -z 1000″というように、実行します。ここで、”-z”は、1秒間に1000ファイルの速度でゼロバイトのファイルだけをチェックすることを意味しています。

次回はSwiftのAPIを紹介する予定です。

Swift運用のTips