2.2. Block Storage サービスの管理
以下の手順で、Block Storage サービスをニーズに合わせて設定する方法を説明します。以下の手順はすべて管理者権限が必要です。
2.2.1. 高可用性のためのアクティブ/アクティブデプロイメント
アクティブ/パッシブモードでは、Block Storage サービスがハイパーコンバージドデプロイメントで失敗した場合、ノードのフェンシングは望ましくありません。これは、ノードのフェンシングがトリガーとなり、不要なストレージのリバランスが行われる場合があるためです。Pacemaker は制御サイトに存在しますが、エッジサイトは Pacemaker をデプロイしません。その代わりに、エッジサイトは、高可用性ハイパーコンバージドデプロイメントをサポートするために、アクティブ/アクティブ設定の Block Storage サービスをデプロイします。
アクティブ/アクティブのデプロイメントでは、利用可能なすべてのノードに負荷をバランスさせることにより、スケーリング機能およびパフォーマンスが向上し、応答時間が短縮されます。アクティブ/アクティブ設定の Block Storage サービスをデプロイすると高可用性環境が構築され、ネットワークの部分的な障害や単一または複数ノードでのハードウェア異常が発生している間に管理レイヤーが維持されます。アクティブ/アクティブのデプロイメントにより、クラスターはノードに障害が発生している間 Block Storage サービスの提供を続けることができます。
ただし、アクティブ/アクティブのデプロイメントでは、ワークフローが自動的に再開することはありません。サービスが停止すると、障害が発生したノードで実行中の個々の操作も、障害が発生している間は実施に失敗します。この場合は、サービスが停止していることを確認し、インフライトの操作に提供されていたリソースのクリーンアップを開始します。
2.2.1.1. 高可用性のためのアクティブ/アクティブ設定の有効化
cinder-volume-active-active.yaml ファイルを使用すると、アクティブ/アクティブ設定で Block Storage サービスをデプロイすることができます。このファイルにより、director は Pacemaker 以外の cinder-volume heat テンプレートを使用し、etcd サービスを分散ロックマネージャー (DLM) としてデプロイメントに追加するようになります。
cinder-volume-active-active.yaml ファイルの CinderVolumeCluster パラメーターに値を割り当てて、アクティブ/アクティブ設定のクラスターの名前も定義します。CinderVolumeCluster は、Block Storage のグローバルパラメーターです。したがって、同じデプロイメントにクラスター化した (アクティブ/アクティブ) バックエンドとクラスター化していないバックエンドを含めることはできません。
現在、アクティブ/アクティブ設定の Block Storage は、Ceph RADOS Block Device (RBD) バックエンドでのみ機能します。複数のバックエンドを使用する場合、すべてのバックエンドがアクティブ/アクティブ設定をサポートする必要があります。アクティブ/アクティブ設定をサポートしないバックエンドがデプロイメントに含まれている場合には、そのバックエンドをストレージに使用することはできません。アクティブ/アクティブのデプロイメントでは、アクティブ/アクティブ設定をサポートしないバックエンドにデータを保存した場合、データ損失の危険性があります。
手順
アクティブ/アクティブ設定の Block Storage サービスのボリュームを有効にするには、オーバークラウドのデプロイメントに以下の環境ファイルを追加します。
-e /usr/share/openstack-tripleo-heat-templates/environments/cinder-volume-active-active.yaml
2.2.1.2. アクティブ/アクティブ設定のメンテナンスコマンド
API バージョン 3.17 以降を使用している場合、アクティブ/アクティブ設定のデプロイ後に、さまざまなコマンドを使用して環境と対話することができます。
| ユーザーのアクション | コマンド |
| クラスター名、ホスト、ゾーン、ステータス、状態、無効にした理由、およびバックエンドの状態などの情報を含む、サービスの一覧を表示する。
注記: Ceph バックエンド用に director によりデプロイされた場合、デフォルトのクラスター名は |
|
| 個別サービスではなく、クラスター全体についての詳細および概要情報を表示する。 |
注記: このコマンドには、cinder API のマイクロバージョン 3.7 以降が必要です。 |
| 特定クラスターについての詳細情報を表示する。 |
注記: このコマンドには、cinder API のマイクロバージョン 3.7 以降が必要です。 |
| 無効にしたサービスを有効にする。 |
注記: このコマンドには、cinder API のマイクロバージョン 3.7 以降が必要です。 |
| クラスター化したサービスを無効にする。 |
注記: このコマンドには、cinder API のマイクロバージョン 3.7 以降が必要です。 |
2.2.1.3. ボリュームの管理と管理解除
管理解除および管理のメカニズムにより、バージョン X を使用するあるサービスからバージョン X+1 を使用する別のサービスに、ボリュームを容易に移行することができます。このプロセス中、どちらのサービスも稼働を続けます。
API バージョン 3.17 以降では、Block Storage クラスター内の管理に使用できるボリュームおよびスナップショットの一覧を確認することができます。これらの一覧を表示するには、cinder manageable-list または cinder snapshot-manageable-list で --cluster 引数を使用します。
API バージョン 3.16 以降では、cinder manage コマンドにもオプションの --cluster 引数を指定できるので、以前に管理解除したボリュームを Block Storage クラスターに追加することができます。
2.2.1.4. クラスター化したサービスでのボリュームの移行
API バージョン 3.16 以降を使用すると、cinder migrate および cinder-manage コマンドに --cluster 引数を指定して、アクティブ/アクティブデプロイメントのデプロイ先を定義することができます。
Block Storage クラスター化サービスのボリュームを移行する場合、オプションの --cluster 引数を渡し、位置に関する host 引数を省略します。これは、引数が互いに排他的であるためです。
2.2.1.5. サーバーメンテナンスの開始
すべての Block Storage ボリュームサービスは、起動時に独自のメンテナンスを実行します。複数のボリュームサービスがクラスターにグループ化されている環境では、現在実行されていないサービスをクリーンアップすることができます。
コマンド work-cleanup により、サーバーのクリーンアップがトリガーされます。このコマンドは以下の出力を返します。
- コマンドでクリーンアップすることのできるサービスの一覧
- 現在クラスター内で実行されていないため、コマンドでクリーンアップすることのできないサービスの一覧
work-cleanup コマンドは、API バージョン 3.24 以降を実行しているサーバーでのみ機能します。
手順
以下のコマンドを実行して、クラスターのすべてのサービスが実行中かどうかを確認します。
cinder cluster-list --detailed
あるいは、
cluster showコマンドを実行します。いずれかのサービスが実行されていない場合は、以下のコマンドを実行してそのサービスを特定します。
cinder service-list
以下のコマンドを実行してサーバーのクリーンアップを開始します。
cinder work-cleanup [--cluster <cluster-name>] [--host <hostname>] [--binary <binary>] [--is-up <True|true|False|false>] [--disabled <True|true|False|false>] [--resource-id <resource-id>] [--resource-type <Volume|Snapshot>]
注記--cluster、--host、--binary等のフィルターで、コマンドでクリーンアップする対象を定義します。特定のリソースを含め、クラスター名、ホスト名、サービスの種別、およびリソースの種別で絞り込むことができます。フィルターを適用しない場合、コマンドはクリーンアップ可能なすべてを対象に処理を試みます。クラスター名で絞り込む例を以下に示します。
cinder work-cleanup --cluster tripleo@tripleo_ceph
