OpenStack 高可用性の概要

OpenStack 高可用性の概要

高可用性システムは、以下の問題を最小化することを目指しています。

  1. システム停止時間: 指定された最大時間を超えて、ユーザーサービスが利用不可能になること。
  2. データ損失: 意図しないデータの削除や破損。

多くの高可用性システムは、単一障害事象のみにおいて、システム停止時間やデータ損失に対する保護を保証します。しかしながら、単一障害が一連の障害を悪化させていく、段階的な障害に対しても保護されることが期待されます。多くのサービスプロバイダーは、コンピューティングサービスの稼働率などの Service Level Agreement (SLA) を保証します。それは、計画停止を除くシステム停止時間と稼働時間に基づいて計算されます。

冗長性とフェールオーバー

高可用性は、各サービスの冗長インスタンスを実行する、冗長ハードウェアを用いて実装されます。あるサービスのインスタンスの 1 つを実行しているハードウェアの部品が故障した場合、システムはフェイルオーバーして、故障していないハードウェアで動作している別のサービスインスタンスを使用します。

高可用性の重要な側面は、単一障害点 (SPOF) を減らすことです。SPOF は、障害が発生した場合にシステム停止やデータ損失を引き起こす、設備やソフトウェアの個々の部品です。SPOF を削減するために、以下の冗長性に対するメカニズムを確認します。

  • スイッチやルーターなどのネットワークの構成要素
  • アプリケーションおよびサービスの自動的なマイグレーション
  • ストレージ構成要素
  • 電源、空調、防火などに関する設備

コンポーネントが故障して、バックアップシステムがその負荷を引き継ぐ場合、多くの高可用性システムは、十分な冗長性を維持するために、できる限り早く故障したコンポーネントを置き換えます。この方法は、デグレードされた保護状態を最小化することに時間を使います。

多くの高可用性システムは、複数の独立した (不連続な) 障害が発生すると停止します。この場合、多くのシステムは可用性の維持よりデータを保護することを優先します。

高可用性システムは、一般的に 99.99% 以上の稼働率を達成します。おそよ年間 1 時間未満の停止時間になります。高可用性システムは、これを実現するために、障害発生後の復旧時間を 1 ~ 2 分以内に、ときにはさらに短く抑えるべきです。

OpenStack 自体のインフラストラクチャーは、現在その可用性要件を満たせます。つまり、適切な OpenStack インフラストラクチャーの 99.99% の稼働率が実現可能です。しかしながら、OpenStack は個々のゲストインスタンスの可用性 99.99% を保証できません。

このドキュメントは、高可用性システムを実行する方法をいくつか議論します。コアな OpenStack サービス、OpenStack とかなり一緒に使われる他のオープンソースサービスを強調しています。

お使いの OpenStack 環境で動作するアプリケーションソフトウェアすべてに対する高可用性の課題を解決する必要があります。重要なことは、お使いのサービスが冗長であり利用できることを確実にすることです。どのように実現するのかは、あなた自身によります。

ステートレスサービスとステートフルサービス

以下は、ステートレスサービスとステートフルサービスの定義です。

ステートレスサービス
リクエストに応答して、その後さらなる注意を必要としないサービス。ステートレスなサービスを高可用化するために、複数のインスタンスを配備して、負荷分散する必要があります。ステートレスな OpenStack サービスに nova-apinova-conductorglance-apikeystone-apineutron-apinova-scheduler があります。
ステートフルサービス
最初のリクエストの結果に応じて、後続のリクエストがあるサービス。ステートフルサービスは、あるアクションが一般的に複数のリクエストに影響するため、管理することが難しいです。追加インスタンスを配備して負荷分散するだけでは、問題を解決できません。例えば、horizon ユーザーインターフェースが、新しいページを開くたびに毎回リセットされると、ほとんど役に立たないでしょう。ステートフルな OpenStack サービスには、OpenStack のデータベース、メッセージキューがあります。ステートレスなサービスの高可用化には、アクティブ/パッシブまたはアクティブ/アクティブな設定のどちらを選択するかに依存する可能性があります。

アクティブ/パッシブとアクティブ/アクティブ

ステートフルサービスは、アクティブ/パッシブまたはアクティブ/アクティブとして設定できます。これらは以下のように定義されます。

アクティブ/パッシブ設定

動作中のサービスが停止したとき、オンラインにできる冗長インスタンスを維持します。例えば、メインのデータベースが故障したとき、オンラインになる災害対策データベースを維持する限り、OpenStack はメインのデータベースに書き込みます。

一般的にステートレスサービスをアクティブ / パッシブにインストールすると、必要に応じてオンラインにできる置換リソースを維持します。リクエストは、サービスの最小限の再設定により返す機能を持つ 仮想 IP アドレス を使用して処理されます。 独立したアプリケーション (Pacemaker や Corosync など) がこれらのサービスを監視し、必要に応じてバックアップ側をオンラインにします。

アクティブ/アクティブ設定

各サービスはバックアップも持ちますが、メインと冗長システムを同時に管理します。このように、ユーザーが気が付かない障害が発生した場合、バックアップシステムはすでにオンラインであり、メインシステムが復旧され、オンラインになるまでの間は負荷が高くなります。

一般的にステートレスサービスをアクティブ / アクティブにインストールすると、冗長なインスタンスを維持することになります。リクエストは HAProxy のような仮想 IP アドレスとロードバランサーを使用して負荷分散されます。

一般的にステートレスサービスをアクティブ / アクティブにインストールすることは、すべてのインスタンスが同じ状態を持つ冗長なサービスになることを含みます。別の言い方をすると、あるインスタンスのデータベースの更新は、他のすべてのインスタンスも更新されます。このように、あるインスタンスへのリクエストは、他へのリクエストと同じです。ロードバランサーがこれらのシステムのトラフィックを管理し、利用可能なシステムが常にリクエストを確実に処理します。

クラスターとクォーラム

クォーラムは、クラスターが機能し続けるために、冗長化されたノードのクラスターにおいて機能し続ける必要がある最小ノード数を指定します。あるノードが停止して、他のノードに制御がフェールオーバーするとき、システムはデータとプロセスが維持されることを保証する必要があります。これを判断するために、残りのノードの内容が比較される必要があります。また、不整合がある場合、多数決論理が実装されます。

この理由により、高可用性環境における各クラスターは、奇数個のコードを持つべきであり、クォーラムがノードの過半数に定義されます。クラスター数がクォーラム値を下回るよう、複数のノードが停止した場合、クラスター自身が停止します。

たとえば、7 ノードクラスターにおいて、クォーラムは floor(7/2) + 1 == 4 に設定されるべきです。クォーラムが 4 で、4 ノードが同時に停止した場合、クラスター自身が停止するでしょう。一方、3 ノード以下の停止の場合、動作し続けられるでしょう。それぞれ 3 ノードと 4 ノードに分割された場合、4 ノードのクラスターのクォーラムが多数派のパーティションを動作し続け、(no-quorum-policy クラスター設定に応じて) 少数派を停止またはフェンスするでしょう。

また、クォーラムが、設定例にあるように 3 つに設定されているでしょう。

注釈

クォーラムの値を floor(n/2) + 1 より小さく設定することは推奨しません。これはネットワーク分割の発生時にスプリットブレインを引き起こす可能性があります。

4 ノードが同時に停止するとき、クラスターは十分に動作し続けるでしょう。しかし、ノードがそれぞれ 3 つと 4 つに分断された場合、3 つのクォーラムが両方で他のノードとホストリソースをフェンスしようとするでしょう。フェンスを有効化していないと、各リソースの 2 つのコピーが動作し続けるでしょう。

これがクォーラムの値を floor(n/2) + 1 より小さく設定することが危険な理由です。しかしながら、いくつかの特別な場合に必要となる可能性があります。例えば、他のノードが 100% 確実に停止していることがわかっている場合の一時的な計測などです。

学習やデモの目的に OpenStack 環境を設定している場合、クォーラムのチェックを無効化できます。本番システムは必ずクォーラムを有効化して実行すべきです。

シングルコントローラーの高可用性モード

OpenStack は、シングルコントローラーの高可用性モードをサポートします。これは、高可用性環境を管理するソフトウェアにより、サービスが管理されますが、コントローラーがフェイルオーバーのために冗長化設定されていないため、実際には高可用性ではありません。この環境は、学習やデモのために使用できますが、本番環境としては適していません。

コントローラーをそのような環境に追加して、それを信頼できる高可用性環境に変えられます。

高可用性はあらゆるユーザー向けではありません。いくつかの挑戦を妨害します。高可用性は、大量のデータを持つデータベースやシステムをあまりに複雑にする可能性があります。レプリケーションは大規模システムをスローダウンさせる可能性があります。異なるセットアップには、異なる事前要件があります。各セットアップのガイドラインを参照してください。

重要

高可用性は、デフォルトの OpenStack セットアップで無効化されています。

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.