OpenStack Platformによる中断のないサービス（HA）の確保：トポロジオプション

投稿者： Piotr Siwczak



最初のOpenStackインフラストラクチャを開発していたとき、その多くのコンポーネントをハードウェアに分散する方法に関する情報を見つけるのが困難でした。 Rackspace Architecture Reference（以前にreferencearchitecture.orgに投稿されていましたが、現在は古くなっているようです）を含む多くのドキュメントを調べました。 OpenStackのドキュメントの設計図も確認しました。 当時はコンポーネントの相互作用に関する基本的な知識しかなかったため、APIサービス、nova-scheduler、Glanceなどのすべてのコンポーネントを含む「コントロールノード」という非常に単純なスキームに決めました。 Keystone、データベース、およびRabbitMQ。 ノードの制御下で、コンピューティングノードという「主力製品」のファームを配置しました。 また、プライベート（固定IPアドレスとサーバー管理のトラフィック用）、パブリック（動的IPアドレスのトラフィック用）、ストレージ（nova-volume iSCSIプロトコルを使用したトラフィック用）の3つのネットワークを編成しました。



ミランティスで働き始めたとき、私はアプローチを大きく変えました。 1つまたは2つのコントロールノードを持つ専用のコンピューティングノードファームを作成するための私のアイデアはすべて間違っていることに気付きました。 一方で、私のアプローチはコンポーネントの分離という点では優れていましたが、実際には、OpenStackに過負荷をかけることなく、稼働中のコンポーネントを簡単に混合および組み立てることができます（たとえば、同じノードでnova-computeサービスとnova-schedulerサービスを組み合わせます）。 OpenStackの「制御ノード」と「コンピューティングノード」の意味は、OpenStackコンポーネントの柔軟な分散に応じて異なる場合があります。



一般に、各OpenStackインストールには少なくとも3種類のノード（および場合によっては4番目）が必要であると想定できます。私の同僚のOleg Gelbukhは次のように説明しました。



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



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



- 計算ノード 。 このノードは、そのコンピューティングパワーを使用するハイパーバイザーと仮想インスタンスをホストします。 マルチホストスキームが使用されている場合、コンピューティングノードは、その上にある仮想インスタンスのネットワークコントローラーとしても機能します。 また、ノードは、バランサー、glance-apiなど、多くのリソースを必要としない内部OpenStackサービスをホストできます。



- ストレージノード。 nova-volumeサービスを使用する場合に必要です。 このノードは、nova-volumeサービスをホストします。 このノードは、iSCSIトラフィックの受信者でもあります。



エンドノードの役割は明らかですが、通常、OpenStackコンポーネント間でトラフィックを均等に分散し、中断のない動作を保証するように設計されたソフトウェアロードバランサーまたはハードウェアとソフトウェアの複合体を収容します。すべての内部OpenStackオフィスプロセス（スケジューラー、APIサービス、Glance、Keystone、RabbitMQ、MySQL）が「シン」に配置され、その上で責任を負うサービスのみ OpenStack（RabbitMQおよびMySQL）の状態を維持するため。 その後、APIサービスとそれらのスケジューラインスタンスの場所により、コンピューティングノードは内部OpenStackサービスプロセスに参加できます。



Mirantisは、幅広い顧客向けにサービストポロジを展開した経験があります。 ここでは、これらのトポロジについて簡単に説明し、図で説明し、OpenStackをデプロイするさまざまな方法について説明します。 （サービスの分離はさらに継続できます。）

ハードウェアロードバランサーを使用したトポロジ

この展開オプションでは、負荷分散用に設計されたハードウェアとソフトウェアの複合体が、OpenStackサービスを接続するためのターミナルノードとして使用されます。 APIサーバー、スケジューラー、およびnova-schedulerサービスのインスタンスは計算ノードにデプロイされ、一方、glance-registryおよびHorizo​​nインスタンスは制御ノードにデプロイされます。



Nova独自のコンポーネントはすべて、ステータス情報を保存しないWebサービスです。 プールに追加のインスタンスを追加することにより、スケーリングが可能です（詳細については、スケーリングAPIに関するMirantisの記事を参照してください）。 したがって、これらのコンポーネントをコンピューティングノードのファーム全体に簡単に分散できます。 データベースとメッセージキューサーバーは、クラスターを使用して両方のコントロールノードに展開できます（この方法については、次のいずれかの記事で詳しく説明します）。 さらに良いことに、コントロールノードには、内部OpenStackサービスではないプラットフォームコンポーネントが含まれています（MySQLとRabbitMQは標準のLinuxデーモンです）。 このようにして、クラウド管理者は、外部エンティティであるデータベースチームの管理を専用のRabbitMQクラスターに委任できます。 したがって、中央制御ノードは削除され、この構成では、線形にスケーリングできるコンピューティングノード/ APIノードのセットが残ります。

専用のエンドノードを備えたトポロジ

この展開構成では、ハードウェアロードバランサーを、サービスファーム全体にトラフィックを分散するエンドノードに置き換えます。 前のアーキテクチャとのもう1つの重要な違いは、コンピューティングノードではなくコントロールノードにAPIサービスを配置することです。 実際、制御ノードは「より太く」なり、コンピューティングノードは「より薄く」なりました。さらに、両方の制御ノードは、動作モードからスタンバイモードに切り替える必要があります。 制御ノードの障害状態は、PacemakerやCorosync / Heartbeatなどのツールを使用して判断できます。

制御ノードの単純な冗長性を備えたトポロジ

この展開オプションでは、エンドノードがコントロールノードと結合されます。 APIサービスとnova-schedulerサービスは制御ノードにインストールされ、ノードを追加してHAProxyを再構成することにより、制御ノードのスケーリングが可能です。 継続性を確保するためにHAProxyの2つのインスタンスが展開され、PacemakerやCorosync / Heartbeatなどのツールを使用して、障害の検出と特定のHAProxyのスタンバイモードから動作モードへの切り替えを行うことができます。

サービスを配布する多くの方法

Mirantisがさまざまなクライアントに実装している物理ノード間でのサービスの分散を説明しました。 ただし、システム管理者は、ニーズに応じて、さまざまな方法でサービスを結合および結合できます。 下の図は、Mirantisの経験に基づいて、さまざまなタイプのノードにOpenStackサービスを分散するさまざまな方法を示しています。

さまざまなタイプのノードのハードウェア要件

エンドノードの主な負荷は 、ネットワークサブシステムによって提供されます。 このタイプのノードには、高いCPUパフォーマンスと高いネットワーク帯域幅が必要です。 また、ノードの操作では、可能であれば、ネットワークインターフェイスを組み合わせて冗長性を確保し、ネットワーク帯域幅を増やすと便利です。



クラウド制御ノードは「厚い」または「薄い」ことができます。 最小構成には、システムの状態をサポートするOpenStackコンポーネント（データベースとAMQPサーバー）が含まれます。 冗長クラウド制御ノード構成には、少なくとも2つのノードが必要です。 ネットワークの冗長性にはネットワークインターフェイスバインディングを使用し、バックアップストレージにはRAID1またはRAID10アレイを使用することをお勧めします。 制御ノードの最小構成：



-6コアプロセッサ1つ



-RAM 8 GB



-ソフトウェアアレイRAID1に1テラバイトのハードドライブ2台



コンピューティングノードには、最も利用可能なメモリとプロセッサパワーが必要です。 ディスクシステムの要件はそれほど厳しくありませんが、SSDを使用するとパフォーマンスが大幅に向上します（通常、ノードインスタンスのファイルシステムはローカルディスクにあるため）。 冗長性のない構成では、1つのディスクを使用できます。障害が発生した場合は、ディスクを交換し、サーバーを新しいコンピューティングノードとしてクラスターに戻します。



実際、コンピューティングノードのハードウェア要件は、仮想オブジェクトの平均パラメーターと1つの物理ノード上のオブジェクトの望ましい密度を評価するユーザーに依存します。



ストレージ管理ノードは、ブロック形式の永続的なデータストレージを仮想サーバーに提供します。 通常、ブロックデータストレージには重要なデータが含まれているため、その可用性とデータの整合性を確保することが非常に重要です。 ストレージノードには、少なくとも6つのディスクが含まれている必要があります。 冗長ディスクアレイ（RAID1）にオペレーティングシステムをインストールすることをお勧めします。 残りの4つのディスクは、RAIDコントロールノードの構成に応じて、RAID5またはRAID10アレイに組み立てられます。



ブロックストレージはiSCSI上で共有されます。これは、ネットワークサブシステムの負荷が高いことを意味します。 iSCSI経由のデータ交換には、少なくとも2つの接続されたインターフェイスをお勧めします。この種類のトラフィック（ジャンボフレームなど）の交換用に特別に構成されている場合があります

ネットワークトポロジー

OpenStackネットワークトポロジは、一般的なデータセンターに似ています。 （他のMirantisの記事では、OpenStackネットワークの構築に関するより詳細な概要を提供しています：FlatDHCPManager、VlanManager。）インスタンス間の内部通信は、固定IPアドレス（プライベートデータセンターネットワーク）を介して行われます。 このネットワークは、nova-networkコンポーネントによって提供されるネットワークアドレストランスレーターとファイアウォールを介してパブリックとペアになります。 外部とのデータ交換には、フローティングIPアドレスを使用したパブリックネットワークが使用されます（非武装データセンターゾーン）。 サーバーを管理するには、制御ネットワークを使用します（データセンターのIPMI / BMネットワーク（インテリジェントプラットフォーム管理インターフェイス/ベースボード管理コントローラー））。 また、必要に応じて、nova-volumeサービスに別のストレージネットワーク（データセンターのデータストレージネットワーク）を使用できます。 次の図は、クラウドトポロジを示しています（ただし、この場合、iSCSIトラフィックは管理トラフィックと組み合わされています）。 eth1の2つのネットワークは、802.1qカーネルモジュールを使用したeth1の上のタグ付きインターフェイスです。







パブリックネットワークには次の目的があります。



-フローティングIPを含むインスタンスを世界中に公開します。



-クライアントがOpenStackサービスAPIへの接続に使用するエンドノードの仮想IPアドレスを表示します。



パブリックネットワークは通常、プライベートネットワークおよび管理ネットワークから分離されています。 パブリック/企業ネットワークは、クラウド所有者のパブリックネットワークの範囲からの1つのクラスCネットワークです（パブリッククラウドにはグローバルルーティングが使用されます）。



プライベートネットワークは、すべてのコンピューティングノードに接続されたネットワークセグメントです。 計算ノード上のすべてのブリッジはこのネットワークに接続されます。 計算ノードのインスタンスが固定IPアドレスでトラフィックを交換するのは、このネットワーク上です。 VlanManagerを使用する場合、このネットワークは、クラウドに存在するプロジェクトごとに1つずつ、隔離された仮想ローカルエリアネットワークに分割されます。 各VLANには、このプロジェクトに割り当てられたIPアドレスのネットワークが含まれ、このプロジェクトに属する仮想マシンを組み合わせます。 FlatDHCPスキームを使用する場合、さまざまなプロジェクトの仮想マシンは、単一の仮想ローカルエリアネットワークと単一のIPアドレススペースを使用します。



管理ネットワークはすべてのクラスターノードを統合し、OpenStackクラスターのコンポーネント間で内部データを交換するために使用されます。 セキュリティ上の理由から、このネットワークはプライベートネットワークおよびパブリックネットワークから分離する必要があります。 管理ネットワークは、トラフィックがそれほど激しくない場合、計算ノードとストレージノード間でiSCSIデータを交換するためにも使用できます。 これは、プライベート範囲のIPアドレスとは別のクラスCネットワークです（グローバルルーティングなし）。



ワークロードにブロックストレージデバイスによって処理される大量のデータが含まれていない場合、 iSCSIネットワークは必要ありません。 負荷が大きい場合、制御トラフィックとの混同を避け、iSCSIトラフィックを最適化する機会を提供するために、専用接続を介してiSCSIを介してデータを交換することをお勧めします。たとえば、ジャンボフレーム、インターフェイスのキュー長の分布などです。

OpenstackとOfficeプロセス ネットワーク

Uninterruptible Mode（HA）では、すべての中央OpenStackコンポーネントをロードバランサーの背後に配置する必要があります。 これには専用のハードウェアまたはエンドノードを使用できます。 エンドノードは、中断のない負荷分散ソフトウェアを実行します。 OpenStack Utility Farmは単一のIPアドレスにあります。 次の表は、ロードバランサーを使用したさまざまなネットワークでのサービスの場所を示しています。

OpenStackコンポーネント	ホストの場所	ネットワークの場所	注釈
nova-api、glance-api、 一目レジストリ、 keystone-api、 地平線	マネージャー/ 計算的	パブリックネットワーク	ユーザー（APIエンドポイント）はこれらのサービスに直接アクセスするため、それらをパブリックネットワークに配置するのが論理的です
ノヴァスケジューラー	マネージャー/ 計算的	管理ネットワーク
nova-compute	計算的	管理ネットワーク
nova-network	マネージャー/ 計算的	管理ネットワーク
MySQL	マネージャー	管理ネットワーク	複製/中断なし（HA）トラフィックを含む
うさぎ	マネージャー	管理ネットワーク	rabbitMQクラスタートラフィックを含む
nova-volume	ストレージノード	管理ネットワーク
iSCSI	ストレージノード	管理ネットワーク（専用LAN）または専用ネットワーク iSCSI	ブロックストレージトラフィックが大量にある場合は、専用ネットワークを使用する必要があります。

結論

OpenStackデプロイメントはさまざまな方法で編成できます。これにより、スケーラビリティと可用性が提供されます。 この事実は、オンラインのドキュメントからは明らかではありません（少なくとも私には明らかではありませんでした）。システム管理者が中央制御ノードが必要であると確信したいくつかのケースを観察しました。

これはそうではありません。 実際、データベースのある中央制御ノードとプラットフォーム外のメッセージングサーバーなしでのインストールが可能です。



分散アーキテクチャの場合は、サービスの複数のインスタンスにトラフィックを慎重に分散し、ステートフルな固定（MySQLやRabbitMQなど）を使用してリソースの複製を確保する必要があります。 OpenStackチームはドキュメントでこれについてまだ言及していないため、MirantisはプラットフォームスケーリングとAPIサービスに関する今後の一連の記事でこのギャップを埋めようとします。



元の記事（英語）： www.mirantis.com/blog/117072