中断のない（HA）Open Cloudに向けて：商用インストールでのOpenStackの使用の概要

著者：オレグ・ゲルブフ



OpenStackプラットフォームを商用で使用するためのいくつかの基本的な要件があります。スタートアップの開発環境用の小さなクラスターとして、またクラウドサービスのリソースプロバイダーの大規模なインストールとしてです。 最も一般的で、結果として、次の要件が最も重要です。



-中断のない（HA）サービスと冗長性

-クラスターのスケーラビリティ

-技術運用の自動化



Mirantisは、これら3つの要件すべてを満たすアプローチを開発しました。 この記事は、当社のアプローチを説明する一連の記事の最初の記事です。 この記事では、使用する方法とツールの概要を説明します。

無停電（HA）および冗長性

一般に、OpenStackプラットフォームに基づくサービスは、複数のグループに分割できます。この場合、各サービスの中断のないサービスアプローチに基づいています。



APIサービス

最初のグループには、APIサーバーが含まれます。

-nova-api

-グランスAPI

-一目レジストリ

-キーストーン



HTTP / RESTプロトコルが使用されるため、クラスターに追加されたロードバランサーを使用して冗長性を比較的簡単に実現できます。 ロードバランサーがヘルスチェックをサポートしている場合、これは基本的な高可用性APIを提供するのに十分です。 OpenStackプラットフォームの2012.1リリース（Essex）では、Swift APIのみが「ヘルスチェック」呼び出しをサポートしていることに注意してください。 他のサービスの機能をテストするには、この呼び出しをサポートするためにAPIへの追加が必要です。



コンピューティングサービス

2番目のグループには、仮想サーバーを実際に管理し、それらにリソースを提供するサービスが含まれます。



-nova-compute

-nova-network

-nova-volume



これらのサービスは、実稼働環境で特別な冗長性を必要としません。 これらのサービスグル​​ープへのアプローチは、基本的なクラウドコンピューティングパラダイムに基づいています。つまり、多くの交換可能なワークフローがあり、そのうちの1つが失われても、クラスターが提供するサービスの障害ではなく、一時的なローカル管理性の中断のみにつながるパラダイムです。 したがって、外部監視システムを使用してこれらのサービスを追跡するだけで十分であり、イベントハンドラーの形式で実装された主要な回復シナリオを自由に使用できます。 最も単純なシナリオは、管理者に通知を送信し、失敗したサービスを再起動することです。



nova-networkサービスのマルチホストサポート機能によって提供されるネットワークデータ転送サービスの高可用性については、公式のOpenStackドキュメントに記載されています。 ただし、実際の作業環境では、このスキームに頻繁に切り替えると、ネットワークルーティングを介した外部ハードウェアルーターへの負荷転送が使用されます。 したがって、nova-networkサービスはDHCPサーバーの機能のみを実行し、複数のノードのサポートにより、DHCPサーバーが唯一の障害ポイントではないことが保証されます。



プランナー

冗長性は、nova-schedulerサービスの不可欠な部分です。 nova-schedulerの最初のインスタンスを起動すると、RabbitMQサーバーのスケジューラーキューからメッセージの受信を開始します。 これにより、nova-computeサービスがステータスを更新するために使用する追加のキューscheduler_fanout_が作成されます。 キュー名のパラメータは、新しいスケジューラインスタンスの識別子に置き換えられます。 その後起動されるすべてのnova-schedulerは同様の方法で動作するため、追加の労力なしで並行して動作できます。



キューサーバー

RabbitMQキューサーバーは、すべてのnovaサービスの主要な通信チャネルであり、実稼働環境の構成で信頼できる必要があります。 クラスターの作成とキューミラーリングは、最初はRabbitMQサーバーでサポートされており、ロードバランサーを使用してクラスターモードで動作しているRabbitMQサーバー間で接続を分散できます。 Mirantisは、Nova RPCライブラリのアップデートも開発しました。これにより、プライマリサーバーに障害が発生し、接続を受け入れられない場合にバックアップRabbitMQサーバーに切り替えると、フェイルオーバーが可能になります。



データベース

ほとんどの場合、OpenStackプラットフォームをデプロイするとき、MySQLデータベースが使用されます。 また、Mirantisはインストールでこのデータベースを使用する場合がほとんどです。 現在まで、中断のないスケーラブルなMySQLデータベースを保証するいくつかのソリューションがあります。 最も一般的に使用されるレプリケーション管理ツールは、マルチマスターレプリケーションマネージャーMySQL-MMMです。 このソリューションは、Mirantisによって実行されるいくつかのインストールで使用され、既知の制限を除き、十分に信頼性の高い動作をします。

MMMの使用に重大な問題はありませんでしたが、データベース、特にWSREP、Galeraに基づくMySQLクラスタリングエンジンの円滑な運用を確保するために、より最新のオープンソースソリューションの使用を検討しています。 Galera Clusterは、シンプルで透過的なスケーラビリティメカニズムを提供し、WSREPレベルで実装されたデータ変更の複数のソースを使用した同期レプリケーションによるフォールトトレランスをサポートします。

拡張性

負荷を分散する方法、または負荷を並列に分散する方法がわかったので、クラスターにサービスプロセスを追加し、それを拡張してより多くの負荷を提供できる、つまり「水平」スケーリングを実行できるメカニズムが必要です。 OpenStackプラットフォームのほとんどのコンポーネントについては、サーバーインスタンスを追加し、ロードバランサー構成に含めて、クラスターを水平方向にスケーリングするだけです。 ただし、これは産業プラントで2つの問題につながります。



ほとんどのクラスターは、サービスインスタンスではなくノードによってスケーリングされます。 この点で、クラスターの「スマート」スケーリングの実行を可能にするノードの役割を決定することが必要になります。 役割は、基本的にノードで実行されている一連のサービスに対応し、クラスターにノードを追加することで拡張します。



制御ノードの追加によるクラスターの水平スケーリングには、特定の順序でいくつかの場所で構成を変更する必要があります。つまり、クラスターをデプロイし、サービスを開始してから、ロードバランサー構成を更新して新しいノードを含める必要があります。 計算ノードの場合、手順は簡単ですが、それでも、機器からサービス構成まで、すべてのレベルで高度な自動化が必要です。



ノードとロール

OpenStackサービスは高度な柔軟性を備えたサーバーに分散できますが、OpenStackプラットフォームをデプロイするための最も一般的なオプションは、管理ノードとコンピューティングノードの2種類のノードを持つことです。 開発用の典型的なOpenStackインストールには、計算グループを除くすべてのサービスを開始する1つの制御ノードと、コンピューティングサービスを実行し、仮想サーバーをホストする複数のコンピューティングノードが含まれます。



このようなアーキテクチャは商用インストールには適さないことが明らかになります。 小規模なクラスターの場合、コンピューティングノードにAPIサーバーをインストールし、データベース、キューサーバー、およびコントロールノードのコントロールパネルのみを残して、クラスターノードをできるだけ自給自足にすることをお勧めします。 制御ノードの構成には、冗長性が含まれている必要があります。 このアーキテクチャには、次のノードロールが定義されています。



- 終了ノード 。 このサイトは、負荷分散および稼働時間サービスを実行します。これには、負荷分散およびクラスター構築のためのソフトウェアが含まれる場合があります。 負荷のバランスを取るように設計されたネットワーク内のハードウェアとソフトウェアの複合体は、エンドノードとして機能できます。 冗長性を確保するために、クラスター内に少なくとも2つのエンドノードを作成することをお勧めします。

- 制御ノード 。 このサイトは、キューサーバー、データベース、Horizo​​nコントロールパネル、監視システムなど、クラウド全体の操作を提供する通信サービスをホストします。 このノードでは、nova-schedulerサービスとAPIサーバーを自由に配置できます。負荷分散はエンドノードによって制御されます。 冗長性を提供するには、クラスター内に少なくとも2つの制御ノードを作成する必要があります。 管理ノードとエンドノードは同じ物理サーバー上で組み合わせることができますが、novaサービスの構成を変更する必要があります-ロードバランサーが使用するポートからそれらを転送する必要があります。

- 計算ノード 。 このノードは、そのコンピューティングパワーを使用するハイパーバイザーと仮想インスタンスをホストします。 マルチホストスキームが使用されている場合、コンピューティングノードは、その上にある仮想インスタンスのネットワークコントローラーとしても機能します。



構成管理

上記のアーキテクチャを各物理サーバーに実装するには、特定の一連の手順を実行する必要があります。 いくつかのステップは非常に複雑で、他のステップには複数のノードのセットアップが含まれます。 たとえば、ロードバランサーを構成したり、データ変更の複数のソースでレプリケーションを設定したりします。 OpenStackプラットフォームをデプロイする現在のプロセスは複雑であるため、実装を成功させるには、これらの操作（スクリプト）のスクリプトを記述することが重要です。 これにより、有名なDevstackやCrowbarなど、いくつかのプロジェクトが出現しました。



インストールプロセスの簡単なスクリプト記述は、実稼働環境にOpenStackソリューションを正常にインストールしたり、クラスターのスケーラビリティを提供したりするには不十分です。 また、アーキテクチャの変更やコンポーネントバージョンのアップグレードが必要な場合は、新しいスクリプトを開発する必要があります。 これは、設定ソフトウェアというこれらのタスク専用に設計されたツールを使用して実行できます。 それらの中で最も有名なのはPuppetとChefであり、それらに基づいて開発された製品もあります（たとえば、上記のCrowbarはChefをエンジンとして使用します）。



OpenStackをさまざまなプロジェクトにデプロイするために、PuppetとChefの両方を使用しました。 当然、各プログラムには独自の制限があります。 私たちの経験では、構成ソフトウェアが集中オーケストレーションエンジンによってサポートされている場合に最高の結果が得られ、スムーズで成功した展開が得られることが示されています。 ハードウェアレベルで物理サーバーをセットアップするアプリケーションおよびインストールの品質を確認する一連のテストと組み合わせると、広範なハードウェア構成および論理アーキテクチャでOpenStackプラットフォームを迅速にインストールできる統合アプローチが得られます。

運用自動化

ノードの役割を考慮した構成システムでオーケストレーションエンジンを使用すると、展開プロセスをかなり高度に自動化できます。 スケーリングを自動化することもできます。 これにより、OpenStackの運用と保守のコストが削減されます。 ほとんどの最新のオーケストレーションエンジンには、クラスター全体または個々の部分を管理するタスクを実行するオペレーター用のコマンドラインインターフェイスまたはWebインターフェイスを作成できるAPIがあります。



これについては、次の記事で詳しく説明します。