アーキテクチャーガイド

OpenStack Networking は、OpenStack クラウド内の仮想ネットワークインフラストラクチャーの作成と管理を処理します。インフラストラクチャー要素にはネットワーク、サブネット、ルーターなどが含まれます。また、ファイアウォールや仮想プライベートネットワーク (VPN) などの高度なサービスもデプロイすることができます。

OpenStack Networking は、クラウド管理者向けに、どの物理システムで実行する個々のサービスを柔軟に決定するかを提供します。すべてのサービスデーモンは、評価目的で、1 つの物理ホストで実行できます。あるいは、各サービスに一意の物理ホストを割り当てるか、複数のホストにレプリケートして冗長性を提供できます。

OpenStack Networking はソフトウェア定義であるため、新規 IP アドレスの作成や割り当てなど、ネットワークのニーズの変化にリアルタイムで対応することができます。

OpenStack Networking の利点は以下のとおりです。

OpenStack Networking サービスおよびエージェントの配置は、ネットワーク要件によって異なります。以下の図は、コントローラーのない共通のデプロイメントモデルの例を示しています。このモデルは、専用の OpenStack Networking ノードおよびテナントネットワークを利用します。

この例は、次の Networking サービスの設定を示しています。

OpenStack Block Storage サービスは、仮想ハードドライブの永続的なブロックストレージ管理機能を提供します。Block Storage により、ユーザーはブロックデバイスの作成/削除やサーバーへの Block Device の接続を管理することができます。

実際のデバイスの割り当て/割り当て解除は、Compute サービスとの統合により処理されます。リージョンおよびゾーンを使用して、分散ブロックストレージホストを処理できます。

Block Storage は、データベースのストレージや拡張可能なファイルシステムなど、パフォーマンスの影響を受けやすいシナリオで使用できます。また、raw のブロックレベルのストレージにアクセスできるサーバーとして使用することもできます。また、ボリュームスナップショットを作成してデータを復元したり、新しいブロックストレージボリュームを作成したりできます。スナップショットはドライバーのサポートに依存します。

OpenStack Block Storage の利点は以下のとおりです。

ボリューム、スケジューラー、API などのメインの Block Storage サービスは実稼働環境で同じ場所に配置できますが、ボリュームサービスのインスタンスを複数デプロイして API およびスケジューラーサービスのインスタンスを管理する方が一般的です。

以下の図は、Block Storage API、スケジューラー、ボリュームサービス、およびその他の OpenStack コンポーネントの関係を示しています。

Object Storage サービスは、HTTP 経由でアクセス可能な、大量データ用のストレージシステムを提供します。ビデオ、イメージ、メールのメッセージ、ファイル、仮想マシンイメージなどの静的エンティティーをすべて保管することができます。オブジェクトは、各ファイルの拡張属性に保管されているメタデータとともに、下層のファイルシステムにバイナリーとして保管されます。

Object Storage 分散アーキテクチャーは、ソフトウェアベースのデータのレプリケーションによる水平スケーリングおよびフェイルオーバーの冗長性をサポートします。このサービスは非同期および最終的な一貫性のレプリケーションをサポートするため、複数のデータセンターデプロイメントで使用できます。

OpenStack Object Storage の利点は以下のとおりです。

オブジェクトストレージは、データベースおよび設定ファイルとして機能するリング .gz ファイルを使用します。これらのファイルには、すべてのストレージデバイスの詳細と、保存されたエンティティーから各ファイルの物理的な場所へのマッピングが含まれます。したがって、リングファイルを使用して、特定のデータの場所を判断できます。各オブジェクト、アカウント、およびコンテナーサーバーには、一意のリングファイルがあります。

Object Storage サービスは、他の OpenStack サービスとコンポーネントに依存してアクションを実行します。たとえば、Identity サービス(keystone)、rsync デーモン、およびロードバランサーがすべて必要です。

以下の図は、Object Storage が他の OpenStack サービス、データベース、ブローカーとの対話に使用する主なインターフェイスを示しています。

OpenStack Database-as-a-Service では、ユーザーはさまざまなリレーショナルデータベースおよび非リレーショナルデータベースを選択、プロビジョニング、および操作することができ、より複雑なデータベース管理タスクを標準で処理できます。

OpenStack Database-as-a-Service には、以下のような利点があります。

以下の図は、Database-as-a-Service と他の OpenStack サービスの関係を示しています。

OpenStack Compute サービスは、オンデマンドで仮想マシンを提供する、OpenStack クラウドの中核です。Compute は、下層の仮想化メカニズムと対話するドライバーを定義し、他の OpenStack コンポーネントに機能を公開することにより、仮想マシンが一式のノード上で実行されるようにスケジュールします。

Compute は、KVM をハイパーバイザーとして使用する libvirt ドライバー libvirtd をサポートします。ハイパーバイザーは仮想マシンを作成し、ノードからノードへのライブマイグレーションを可能にします。ベアメタルマシンをプロビジョニングするには、「OpenStack Bare Metal Provisioning (ironic)」 も使用できます。

Compute は Identity サービスと対話してインスタンスおよびデータベースアクセスを認証し、Image サービスを使用してイメージにアクセスしてインスタンスを起動し、ダッシュボードサービスを使用してユーザーおよび管理インターフェイスを提供します。

プロジェクトおよびユーザーがイメージへのアクセスを制限し、プロジェクトおよびユーザーのクォータ（単一ユーザーが作成することのできるインスタンス数など）を指定できます。

Red Hat OpenStack Platform クラウドをデプロイする場合には、さまざまなカテゴリーに従ってクラウドを分類することができます。

以下の図は、Compute サービスと他の OpenStack コンポーネントの関係を示しています。

OpenStack Bare Metal Provisioning により、ハードウェア固有のドライバーを使用するさまざまなハードウェアベンダーの製品で物理マシンまたはベアメタルマシンのプロビジョニングを行うことができます。Bare Metal Provisioning は Compute サービスと統合して、仮想マシンのプロビジョニングと同じ方法で、ベアメタルマシンのプロビジョニングを行い、bare-metal-to-trusted-tenant のユースケースの解決策を提供します。

OpenStack Baremetal Provisioning には、以下のような利点があります。

Bare Metal Provisioning は、スケジューリングとクォータの管理に Compute サービスを使用し、認証に Identity サービスを使用します。インスタンスイメージは、KVM ではなく Bare Metal Provisioning をサポートするように設定する必要があります。

以下の図は、物理サーバーがプロビジョニングされているときに Ironic と他の OpenStack サービスがどのように対話するかを示しています。

Ironic API を以下の図に示します。

OpenStack Image は、仮想ディスクイメージのレジストリーとして機能します。ユーザーは、新規イメージを追加したり、既存のサーバーのスナップショットを作成して直ちに保存したりすることができます。スナップショットはバックアップ用、またはサーバーを新規作成するためのテンプレートとして使用できます。

登録されたイメージは、Object Storage サービスや、単純なファイルシステムや外部の Web サーバーなどの他の場所に保存できます。

次のイメージディスク形式がサポートされています。

コンテナーの形式は、Image サービスで登録することもできます。コンテナー形式は、イメージに保存する仮想マシンメタデータのタイプおよび詳細レベルを決定します。

以下のコンテナー形式がサポートされています。

以下の図は、Image サービスが Image データベースからイメージを登録して取得するために使用する主なインターフェイスを示しています。

OpenStack Orchestration は、ストレージ、ネットワーク、インスタンス、アプリケーションなどのクラウドリソースを作成および管理するためのテンプレートを提供します。テンプレートは、リソースのコレクションであるスタックの作成に使用されます。

たとえば、インスタンス、フローティング IP、ボリューム、セキュリティーグループ、またはユーザーのテンプレートを作成できます。Orchestration は、1 つのモジュラーテンプレートや、自動スケーリングや基本的な高可用性などの機能を使用して、すべての OpenStack コアサービスへのアクセスを提供します。

OpenStack Orchestration には、以下のような利点があります。

次の図は、2 つの新規インスタンスとローカルネットワークの新規スタックを作成するために Orchestration サービスが使用する主なインターフェイスを示しています。

OpenStack Data Processing により、OpenStack 上の Hadoop クラスターのプロビジョニングと管理を行うことができます。Hadoop は、クラスター内の大量の構造化/非構造化データを保管および分析します。

Hadoop クラスター は、Hadoop Distributed File System (HDFS)、Hadoop の MapReduce (MR)フレームワークを実行しているコンピュートサーバー、またはその両方を実行するストレージサーバーとして機能するサーバーのグループです。

Hadoop クラスター内のサーバーは同じネットワークに置く必要がありますが、メモリーやディスクを共有する必要はありません。したがって、既存のサーバーの互換性に影響を与えることなく、サーバーおよびクラスターを追加または削除できます。

Hadoop のコンピューティングサーバーとストレージサーバーは共存するため、保存されたデータの高速分析が可能になります。すべてのタスクはサーバー全体で分割され、ローカルサーバーリソースを使用します。

OpenStack データ処理の利点には、以下が含まれます。

データ処理は、Cloudera (CDH)と Hortonworks Data Platform (HDP)ディストリビューションと、Apache Ambari などのベンダー固有の管理ツールをサポートしています。OpenStack Dashboard またはコマンドラインツールを使用して、クラスターをプロビジョニングおよび管理できます。

次の図は、Data Processing サービスが Hadoop クラスターのプロビジョニングと管理に使用する主なインターフェイスを示しています。

OpenStack Identity は、全 OpenStack コンポーネントに対してユーザーの認証と承認を提供します。Identity は、ユーザー名/パスワード認証情報、トークンベースのシステム、AWS 式のログインなど複数の認証メカニズムをサポートしています。

デフォルトでは、Identity サービスはトークン、カタログ、ポリシー、および ID 情報に MariaDB バックエンドを使用します。このバックエンドは、開発環境または小規模なユーザーセットを認証する場合に推奨されます。LDAP や SQL などの複数の ID バックエンドを同時に使用することもできます。トークンの永続性に memcache または Redis を使用することもできます。

ID は、SAML とのフェデレーションをサポートします。フェデレーションアイデンティティーは、アイデンティティープロバイダー(IdP)と、アイデンティティーがエンドユーザーに提供するサービスとの間の信頼を確立します。

OpenStack Identity の利点は以下のとおりです。

以下の図は、Identity が他の OpenStack コンポーネントでユーザーを認証するために使用する基本的な認証フローを示しています。

OpenStack Dashboard は、ユーザーおよび管理者がインスタンスの作成/起動やネットワークの管理、アクセス制御の設定などの操作を行うためのグラフィカルユーザーインターフェイスを提供します。

Dashboard サービスは、プロジェクト、管理、設定のデフォルトダッシュボードを提供します。Dashboard は、モジュール型設計により、課金、モニタリング、追加の管理ツールなどの他の製品と連結することができます。

次のイメージは、Admin Dashboard の Compute パネルの例を示しています。

ダッシュボードにログインするユーザーのロールによって、利用可能なダッシュボードおよびパネルが決まります。

次の図は、ダッシュボードアーキテクチャーの概要を示しています。

この例は、以下の対話を示しています。

OpenStack Telemetry は、OpenStack をベースとするクラウドのユーザーレベルの使用状況データを提供します。データは、顧客の課金、システムの監視、警告に使用することができます。Telemetry は既存の OpenStack コンポーネント (例: Compute の使用イベント) や libvirt などの OpenStack インフラストラクチャーリソースのポーリングにより送信される通知からデータを収集することができます。

Telemetry には、信頼できるメッセージングシステムを介して認証されたエージェントと通信してデータを収集および集約するストレージデーモンが含まれます。さらに、サービスは、新しいモニターの追加に使用できるプラグインシステムを使用します。API サーバー、中央エージェント、データストアサービス、およびコレクターエージェントを異なるホストにデプロイできます。

サービスは、MongoDB データベースを使用して収集したデータを保存します。コレクターエージェントと API サーバーのみがデータベースにアクセスできます。

以下の図は、Telemetry サービスで使用されるインターフェイスを示しています。

一部の Red Hat OpenStack Platform コンポーネントは、サードパーティーのデータベース、サービス、およびツールを使用します。

2 つの別個のスイッチで 2 つの LAN を使用する場合は、次の方法で 2 つの LAN を接続して互いに情報を共有できます。

仮想ローカルエリアネットワーク(VLAN)を使用すると、同じスイッチ上で動作するコンピューターのネットワークトラフィックを分割することができます。異なるネットワークのメンバーであるようにポートを設定することで、スイッチを論理的に分割することができます。この設定により、ポートがミニ LAN になり、セキュリティーの目的でトラフィックを分割できるようになります。

たとえば、スイッチに 24 個のポートがある場合、ポート 1 - 6 を VLAN200 に、ポート 7-18 が VLAN201 に属するポートを定義できます。VLAN200 に接続されているコンピューターは、VLAN201 のコンピューターと完全に分離され、直接通信できなくなります。2 つの VLAN 間のトラフィックはすべて、2 つの別個の物理スイッチであるかのようにルーターを通過する必要があります。また、ファイアウォールでセキュリティーを強化することで、相互に通信できる VLAN を判断することもできます。

ファイアウォールは、IP ルーティングと同じ OSI レイヤーで動作します。多くの場合、それらはルーターと同じネットワークセグメントにあり、すべてのネットワーク間のトラフィックを制御します。ファイアウォールは、ネットワークに出入りできないトラフィックを規定する事前定義済みのルールセットを使用します。これらのルールは細かくすることができます。たとえば、VLAN 200 上のサーバーが VLAN201 上のコンピューターとのみ通信できるルールを定義でき、その後の水曜日ではしか、トラフィックが Web (HTTP)で、一方向に移動するルールを定義できます。

これらのルールを強制するために、一部のファイアウォールはステートフルパケット検査(SPI)も実行します。ここで、パケットの内容を調べて、それらが要求するものであることを確認します。ハッカーは、マスカレードが他のトラフィックとして送信することで、データを排出することが知られています。SPI は、その脅威を緩和するのに役立つ 1 つのメソッドです。

ネットワークブリッジは、OSI モデルの同じレベル 2 で動作するスイッチですが、ルーターと同様に別個のネットワークを接続することのみが対象です。

OpenStack Networking は、集中型ネットワークノード（仮想ネットワークコンポーネントをホストする機能専用の物理サーバー）上で仮想ルーターをホストします。これらの仮想ルーターは、仮想マシンとの間のトラフィックを転送し、環境の継続的な接続に不可欠です。多くの理由で物理サーバーが停止する可能性があるため、ネットワークノードが使用できなくなった場合に仮想マシンの停止に対して脆弱になる可能性があります。

OpenStack Networking はレイヤー 3 高可用性を使用してこの脆弱性を軽減し、業界標準の VRRP を実装して仮想ルーターと Floating IP アドレスを保護します。レイヤー 3 高可用性により、テナントの仮想ルーターは複数の物理ネットワークノードに無作為に分散され、1 つのルーターがアクティブなルーターとして指定され、1 つのルーターがスタンバイルーターとして指定され、アクティブなルーターをホストするネットワークノードが停止した場合に引き継ぐ準備が整います。

詳細は、Networking Guide のLayer 3 High Availability セクションを参照してください。

Load Balancing-as-a-Service (LBaaS)は、受信したネットワーク要求を指定のインスタンス間で均等に分散できるようにします。この分散により、ワークロードがインスタンス間で共有され、システムリソースをより効果的に使用できます。受け取った要求は、以下の負荷分散メソッドの 1 つを使用して分散されます。

詳細は、ネットワークガイド の Load Balancing-as-a-Service の設定セクションを参照してください。

OpenStack Networking はテナントネットワークの IPv6 アドレスをサポートしているため、IPv6 アドレスを仮想マシンに動的に割り当てることができます。また、OpenStack Networking は物理ルーター上で SLAAC と統合することができます。これにより、仮想マシンは既存の DHCP インフラストラクチャーから IPv6 アドレスを受け取ることができます。

詳細は、ネットワークガイドの IPv6 セクションを参照してください。

短期間の容量計画や予測を実行するには、以下のメトリクスの記録をキャプチャーすることを検討してください。

vCPU、vRAM、およびレイテンシーメトリクスは、容量計画で最もアクセス可能です。これらの詳細を使用すると、標準の 2 次回帰を適用し、次の 3 カ月をカバーする使用可能な容量予測を受け取ることができます。この見積もりを使用して、追加のハードウェアをデプロイする必要があるかどうかを判断します。

このモデルでは反復を確認し、予測傾向と実際の使用量から偏差を予測する必要があります。この情報は、標準の統計ツールを使用して、または Nash-Sutcliffe などの特殊な分析モデルで分析できます。傾向は、2 次回帰を使用して計算することもできます。

リソースの合計使用量は 1 年間で異なる可能性があり、通常は元の長期容量推定値によって偏差が発生します。したがって、2 次回帰は、特に使用が周期的な場合に、キャパシティー予測には不十分な測定となる可能性があります。

長期デプロイメントを計画する際には、1 年以上にわたるデータに基づいた容量計画モデルが、少なくとも最初の派生値に適合する必要があります。利用パターンによっては、周波数分析が必要になる場合があります。

作成する各インスタンスには、インスタンスのサイズや容量を決定するフレーバーまたはリソースのテンプレートが提供されます。フレーバーは、セカンダリー一時ストレージ、スワップディスク、使用量を制限するメタデータ、または特別なプロジェクトアクセスを指定することもできます。デフォルトのフレーバーには、これらの追加属性が定義されていません。インスタンスのフレーバーにより、容量予測が可能です。これは、一般的なユースケースは予測されるサイズで、アドホックにはサイズ設定ではないためです。

仮想マシンを物理ホストにパックしやすくするために、フレーバーのデフォルト選択で、すべてのディメンションにおいて、最大のフレーバーのサイズを半分（合計）します。フレーバーには、vCPU の半分、vRAM の半分、エフェメラルディスク領域の半分があります。後続の最大のフレーバーはそれぞれ、前のフレーバーの半分になります。

次の図は、汎用的なコンピューティング設計と、CPU 最適化のパックされたサーバーでのフレーバー割り当てを視覚的に示しています。

デフォルトのフレーバーは、コモディティーサーバーハードウェアの典型的な設定に適しています。使用率を最大化するには、フレーバーをカスタマイズしたり、新規フレーバーを作成してインスタンスサイズを利用可能なハードウェアに合わせたりする必要がある場合があります。

可能であれば、フレーバーを各フレーバーの 1 つの仮想 CPU に制限します。タイプ 1 ハイパーバイザーは、1 つの vCPU で設定された仮想マシンにとって、CPU 時間をより簡単にスケジュールできることに注意してください。たとえば、4 vCPU で設定されている仮想マシンに CPU 時間をスケジュールするハイパーバイザーは、タスクが 1 つの vCPU のみを実行する必要がある場合でも、4 つの物理コアが使用可能になるまで待機する必要があります。

ワークロードの特徴は、特に CPU、RAM、または HDD 要件の異なる比率をタスクの場合に、ハードウェアの選択とフレーバーの設定にも影響を与える可能性があります。フレーバーに関する情報は、インスタンスおよびイメージの管理 を 参照してください。

Red Hat OpenStack Platform のデフォルトの割り当て率は、物理（ハイパースレッディング）またはハイパースレッドごとに 16 vCPU です。

次の表に、システム用に予約されている 4GB など、使用可能な合計メモリーに基づいて物理ホストで適切に実行できる仮想マシンの最大数を示します。

たとえば、60 インスタンスの最初の greenfields 表現を計画するには、3+1 コンピュートノードが必要です。通常、メモリーのボトルネックは CPU のボトルネックよりも一般的です。ただし、必要に応じて割り当て比率を物理コアごとに 8 vCPU に下げることができます。

KVM ハイパーバイザーには、共有不可能なメモリーなど、少量の仮想マシンメモリーのオーバーヘッドが必要です。QEMU/KVM システムの共有可能なメモリーは、各ハイパーバイザーで 200 MB に丸めることができます。

通常、仮想マシンごとに 100MB のハイパーバイザーのオーバーヘッドを予測できます。

メモリーは、ハイパーバイザーのデプロイメントの制限要素です。各物理ホストで実行できる仮想マシンの数は、ホストがアクセスできるメモリーの量によって制限されます。たとえば、256 GB の RAM、200 1 GB を超えるインスタンスを持つクアッドコア CPU をデプロイすると、パフォーマンスが低下します。したがって、インスタンス全体に分散するには、CPU コアとメモリーの最適な比率を慎重に決定する必要があります。

コンピュートノード用に、以下のような追加デバイスを検討する場合があります。

外部ストレージ用に Ceph を検討する場合、Ceph クラスターバックエンドのサイズを変更して、予想される同時仮想マシンの数を妥当なレイテンシーで処理する必要があります。許容可能なサービスレベルは、書き込み操作のために 20 ミリ秒以内に I/O 操作の 99% を維持し、読み取り操作では 10 ミリ秒未満に維持できます。

各 Rados Block Device (RBD)の最大帯域幅を設定するか、保証された最小コミットを設定して、I/O スパイクを他の仮想マシンから分離することができます。

OpenStack クラウドには従来、複数のネットワークセグメントがありました。各セグメントは、クラウド内のリソースへのアクセスを、オペレーターとテナントに提供します。ネットワークサービスには、他のネットワークとは別のネットワーク通信パスも必要です。サービスを別々のネットワークに分割すると、機密データを保護し、サービスへのアクセスから保護できます。

最小限推奨されるサフィゲーションには、以下のネットワークセグメントが含まれます。

選択するネットワーク種別は、クラウドネットワークアーキテクチャーの設計において重要なロールを果たします。

ネットワークハードウェアがすべての実装に適用できる OpenStack クラウドをサポートするための、単一のベストプラクティスアーキテクチャーはありません。ネットワークハードウェアを選択する際の主要な考慮事項は次のとおりです。

ネットワーク要件は、パフォーマンス機能を決定するのに役立ちます。たとえば、小規模なデプロイメントでは 1 ギガビットイーサネット(GbE)ネットワークを使用する可能性があり、複数の部門に対応する大容量インストールや、多くのユーザーが 10 GbE ネットワークを使用する必要があります。

実行中のインスタンスのパフォーマンスは、これらのネットワーク速度により制限される可能性があります。ネットワーク機能の組み合わせを実行する OpenStack 環境を設計することができます。異なるインターフェイス速度を利用することで、OpenStack 環境のユーザーは目的に合ったネットワークを選択できます。

たとえば、Web アプリケーションインスタンスは、1 GbE 機能を持つ OpenStack Networking を使用してパブリックネットワーク上で実行でき、バックエンドデータベースは、10 GbE 機能を備えた OpenStack Networking ネットワークを使用して、そのデータを複製できます。場合によっては、設計にはリンクアグリゲーションを組み込むことで、スループットを向上させることができます。

クラウド API にフロントエンドサービスを提供するハードウェアロードバランサーを実装することで、ネットワークパフォーマンスを向上させることができます。ハードウェアロードバランサーは、必要に応じて SSL ターミネーションを実行することもできます。SSL オフロードを実装する場合は、選択したデバイスの SSL オフロード機能を確認することが重要です。

CPU、メモリー、ディスクタイプなど、コンピュートノードで使用されるハードウェア仕様は、インスタンスのパフォーマンスに直接影響を及ぼします。OpenStack サービスの調整可能なパラメーターは、パフォーマンスに直接影響を与える可能性があります。

たとえば、OpenStack Compute のデフォルトのオーバーコミット率は、CPU の場合は 16:1、メモリーの場合は 1.5 です。これらの比率が高いと、noisy-neighbor アクティビティーが増える可能性があります。このシナリオを回避し、使用状況が増加したら環境を監視するように、コンピュート環境のサイズを慎重に検討する必要があります。

Block Storage は、NetApp または EMC などのエンタープライズバックエンドシステムや Ceph 等のスケールアウトストレージを使用する、または Block Storage ノードで直接接続されたストレージの機能を利用できます。

Block Storage をデプロイして、トラフィックがホストネットワークを通過できるようにすることができます。これは影響を受ける可能性があり、フロントサイド API トラフィックのパフォーマンスに悪影響を受ける可能性があります。したがって、コントローラーおよびコンピュートホスト上の専用のインターフェイスでデータストレージネットワークを使用することを検討してください。

ユーザーは通常、ハードウェアロードバランサーの背後で実行されるプロキシーサービスを介してオブジェクトストレージにアクセスします。デフォルトで、高度に回復性のあるストレージシステムは、保存されたデータを複製します。これにより、システム全体のパフォーマンスに影響を与える可能性があります。この場合、ストレージネットワークアーキテクチャー全体で 10 GbE 以上のネットワーク容量が推奨されます。

コントローラーノードは、エンドユーザーに管理サービスを提供し、クラウド操作の内部にあるサービスを提供します。コントローラーインフラストラクチャーを実行するために使用されるハードウェアを慎重に設計することが重要です。

コントローラーは、サービス間のシステムメッセージング用にメッセージキューサービスを実行します。メッセージングのパフォーマンスの問題により、インスタンスのスピンアップや削除、新しいストレージボリュームのプロビジョニング、およびネットワークリソースの管理などの運用機能が遅延する可能性があります。これらの遅延は、特に自動スケーリング機能を使用する場合に、アプリケーションが一部の状態に対応する能力に悪影響を与える可能性があります。

また、コントローラーノードが複数の同時ユーザーのワークロードを処理できるようにする必要があります。顧客のサービスの信頼性を向上させるために、API および Horizon サービスの負荷を確実にテストしてください。

OpenStack Identity サービス(keystone)を考慮することが重要です。OpenStack Identity サービス(keystone)は、すべてのサービスを内部的に OpenStack およびエンドユーザーに提供します。このサービスにより、サイズが適切に行われない場合、全体的なパフォーマンスが低下する可能性があります。

監視が重要なメトリクスには以下が含まれます。

設計は、バックアップおよび復元ストラテジー、データ評価または階層的なストレージ管理、保持戦略、データの配置、およびワークフローの自動化の影響を受ける可能性があります。

効果的なクラウドアーキテクチャーは以下をサポートする必要があります。

たとえば、コンピュートホストに障害が発生した場合、インスタンスはスナップショットから復元されるか、インスタンスを再起動することができます。ただし、高可用性については、共有ストレージや信頼性の高い移行パスの設計などの追加のサポートサービスをデプロイする必要がある場合があります。

オンライン分類された広告会社では、プライベートクラウドに Apache Tomcat、Nginx、MariaDB を含む Web アプリケーションを実行します。ポリシーの要件を満たすために、クラウドインフラストラクチャーは会社のデータセンター内で実行されます。

会社には予測可能な負荷要件がありますが、需要の夜間に合わせてスケーリングが必要です。現在の環境には、オープンソースの API 環境を実行する会社の目標に柔軟性がありません。

現在の環境は、以下のコンポーネントで設定されています。

会社は、ハードウェアロードバランサーと、Web サイトを提供する複数の Web アプリケーションを実行します。環境オーケストレーションは、スクリプトと Puppet の組み合わせを使用します。この Web サイトでは、アーカイブが必要な日に大量のログデータが生成されます。

この例のアーキテクチャーには、3 台のコントローラーノードと少なくとも 8 つのコンピュートノードが含まれます。静的オブジェクトには OpenStack Object Storage を使用し、その他すべてのストレージのニーズには OpenStack Block Storage を使用します。

OpenStack インフラストラクチャーコンポーネントが高可用性を確保するために、ノードは Red Hat Enterprise Linux の Pacemaker アドオンを HAProxy と共に使用します。

アーキテクチャーには、以下のコンポーネントが含まれます。

Compute サービスがそれぞれのコンピュートノードにインストールされている。

この汎用アーキテクチャーは 140 Web インスタンスまで実行でき、少数の MariaDB インスタンスは 292 vCPU と 584 GB RAM を必要とします。ハイパースレッディングを備えたデュアルソケット 16 進コア Intel CPU を備えた一般的な 1U サーバーでは、CPU のオーバーコミットの比率が 2:1 個と仮定すると、このアーキテクチャーには 8 つのコンピュートノードが必要です。

Web アプリケーションインスタンスは、各コンピュートノード上のローカルストレージから実行されます。Web アプリケーションインスタンスはステートレスであるため、インスタンスの 1 つに障害が発生した場合は、アプリケーションは実行を継続できます。

ストレージの場合は、サーバーで直接接続されたストレージでスケールアウトソリューションを使用します。たとえば、グリッド 結合ソリューションと同様の方法でコンピュートホストにストレージを入力することも、ブロックストレージだけを提供する専用ホストにも反映することができます。

コンピュートホストにストレージをデプロイする場合は、ハードウェアがストレージおよびコンピュートサービスを処理できることを確認します。

組織は、調査プロジェクト用に HPC を提供します。ヨーロッパの 2 つの既存のコンピューティングセンターに 3 番目のコンピュートセンターを追加する必要があります。

以下の表には、追加する各コンピュートセンターの要件をまとめています。

このアーキテクチャーでは、セルを使用してコンピュートリソースを分離し、異なるデータセンター間で透過的なスケーリングを行います。この決定は、セキュリティーグループおよびライブマイグレーションのサポートに影響します。さらに、セル全体でフレーバーなどの一部の設定要素を手動でレプリケーションする必要があります。ただし、セルは、ユーザーに単一のパブリック API エンドポイントを公開する間に必要なスケールを提供します。

クラウドは、元の 2 つのデータセンターのそれぞれにコンピュートセルを使用し、新しいデータセンターを追加するたびに新しいコンピュートセルを作成します。各セルには、コンピュートリソースをさらに分離する 3 つのアベイラビリティゾーンと、高可用性のためにミラーリングされたキューを持つクラスタリング用に設定された 3 つ以上の RabbitMQ メッセージブローカーが含まれます。

HAProxy ロードバランサーの背後に存在する API セルは、Switzerland のデータセンターにあります。API セルは、セルスケジューラーのカスタマイズされたバリエーションを使用して、API コールをコンピュートセルに転送します。カスタマイズにより、特定のワークロードを特定のデータセンターまたはセル RAM の可用性に基づいてすべてのデータセンターにルーティングできるようになります。

フィルターを使用して、セルでの配置を処理する Compute スケジューラーをカスタマイズすることもできます。たとえば、ImagePropertiesFilter は、ゲストが実行するオペレーティングシステム(Linux、Windows など)に基づいて特別な処理を行います。

中央データベースチームは、NetApp ストレージバックエンドを使用したアクティブ/パッシブ設定の各セルの SQL データベースサーバーを管理します。バックアップは 6 時間ごとに実行されます。

3章設計 で説明されている 「コンピュートリソース」 およびコンピュートノードの設計に関する考慮事項で説明されている基本的な設計に関する考慮事項に加えて、コンピュート集約型アーキテクチャーには以下の項目を考慮する必要があります。

クラウドストレージモデルは、データを物理ストレージデバイスの論理プールに格納します。このアーキテクチャーは、多くの場合、統合ストレージクラウドと呼ばれます。

クラウドストレージは通常、ホストされたオブジェクトストレージサービスを指します。ただし、用語には、サービスとして利用可能な他のタイプのデータストレージも含めることができます。OpenStack は、Block Storage (cinder)と Object Storage (swift)の両方を提供します。クラウドストレージは通常仮想インフラストラクチャーで実行され、インターフェイスアクセシビリティ性、スケーラビリティー、スケーラビリティー、マルチテナンシー、およびメーター化されたリソースの幅広いクラウドコンピューティングと類似しています。

オンプレミスまたはオンプレミスのクラウドストレージサービスを使用できます。クラウドストレージは冗長性とデータの分散に対して高い耐障害性があり、バージョン化されたコピーでは高い耐久性があり、一貫したデータレプリケーションを実行できます。

クラウドストレージアプリケーションの例には、以下が含まれます。

OpenStack Storage のサービスについての詳しい情報は、「OpenStack Object Storage (swift)」 および 「OpenStack Block Storage (cinder)」 を参照してください。

大規模なデータセットの分析は、ストレージシステムのパフォーマンスに大きく依存します。並列ファイルシステムは、高パフォーマンスのデータ処理を提供する可能性があり、大規模なパフォーマンスに重点を置いたシステムに推奨されます。

データベースアーキテクチャーは、高パフォーマンスストレージバックエンドの恩恵を受けます。エンタープライズストレージは必須ではありませんが、多くの環境には、OpenStack クラウドがバックエンドとして使用できるストレージが含まれます。

ストレージプールを作成して、インスタンスおよびオブジェクトインターフェイス用に OpenStack Block Storage をブロックデバイスに提供することができます。このアーキテクチャーの例では、データベース I/O 要件が高く、高速 SSD プールから必要なストレージがあります。

3章設計 で説明されている基本的な設計に関する考慮事項、「ストレージリソース」 で説明されているストレージノード設計に関する考慮事項に加えて、ストレージ集約型アーキテクチャーについては、以下の項目を考慮する必要があります。

すべての OpenStack デプロイメントは、サービスベースの性質上、正しく機能するためにネットワーク通信に依存しています。ただし、ネットワーク設定の方が重要であり、追加の設計に関する考慮事項が必要になる場合があります。

以下の表は、ネットワーク中心の一般的なアーキテクチャーについて説明しています。これらのアーキテクチャーは、信頼できるネットワークインフラストラクチャーと、ユーザーとアプリケーションの要件を満たすサービスに依存します。

このアーキテクチャーは、ファイルストレージおよびファイル共有を提供するクラウド向けです。このストレージ中心のユースケースを検討する場合もありますが、ネットワーク側の要件ではネットワーク中心のユースケースになります。

このアーキテクチャーは、バーストの水平方向にスケーリングし、インスタンス数が高いものを生成する大規模な Web アプリケーション用です。アプリケーションでは、データを保護するために SSL 接続が必要であり、個々のサーバーへの接続を失うことはできません。

3章設計および2章Networking In-Depthで説明されているネットワークノード設計に関する基本的な設計に関する考慮事項に加えて、次の項目をネットワーク集約型アーキテクチャー向けに考慮する必要があります。