Red Hat Summit4.5. Network-Focused アーキテクチャー
「Network-Focused Architecture の考慮事項」
4.5.1. Network-Focused アーキテクチャータイプ
すべての OpenStack デプロイメントは、サービスベースの性質上、正しく機能するためにネットワーク通信に依存しています。ただし、ネットワーク設定の方が重要であり、追加の設計に関する考慮事項が必要になる場合があります。
以下の表は、ネットワーク中心の一般的なアーキテクチャーについて説明しています。これらのアーキテクチャーは、信頼できるネットワークインフラストラクチャーと、ユーザーとアプリケーションの要件を満たすサービスに依存します。
| アーキテクチャー | 説明 |
|---|---|
| ビッグデータ | ビッグデータの管理と収集に使用されるクラウドは、ネットワークリソースに大きな需要をもたらします。ビッグデータは多くの場合、データの部分的なレプリカを使用して、大規模な分散クラウド上で整合性を維持します。大量のネットワークリソースを必要とするビッグデータアプリケーションは、Hadoop、Cassandra、NuoDB、Riak、またはその他の NoSQL や分散データベースなどです。 |
| コンテンツ配信ネットワーク (CDN) | CDN を使用すると、ビデオのストリーミング、写真グラフの表示、ホストの Web 会議、多数のエンドユーザーによる分散クラウドベースのデータリポジトリーへのアクセスを行うことができます。ネットワーク設定は、インスタンスのレイテンシー、帯域幅、および分散に影響します。コンテンツの提供とパフォーマンスに影響を与えるその他の要因には、バックエンドシステムのネットワークスループット、リソースの場所、WAN アーキテクチャー、キャッシュ方法などがあります。 |
| 高可用性 (HA) | HA 環境は、サイト間のデータのレプリケーションを維持するネットワークのサイジングに依存します。あるサイトが使用できなくなった場合、元のサイトがサービスに戻るまで、追加のサイトにより負荷に対応できます。追加の負荷を処理するためにネットワーク容量のサイズを設定することが重要です。 |
| 高性能コンピューティング (HPC) | HPC 環境では、クラウドクラスターのニーズに対応するために、追加のトラフィックフローと使用状況パターンを考慮する必要があります。HPC は、ネットワーク内の分散コンピューティングのために East-West トラフィックパターンが高くなっていますが、アプリケーションによっては、ネットワーク内でのノースサウストラフィックが大幅に行われる可能性もあります。 |
| 高速または大量のトランザクションシステム | これらのアプリケーションタイプは、ネットワークジッターおよび遅延の影響を受けます。環境の例には、金融システム、クレジットカード取引アプリケーション、取引システムが含まれます。これらのアーキテクチャーは、データ配信効率を最大化するために、north-south トラフィックで大量の East-west トラフィックを分散する必要があります。これらのシステムの多くは、大規模で高性能のデータベースバックエンドにアクセスする必要があります。 |
| ネットワーク管理機能 | DNS、NTP、SNMP などのバックエンドネットワークサービスの配信をサポートする環境。内部ネットワーク管理にこれらのサービスを使用できます。 |
| ネットワークサービスオファリング | サービスをサポートするために顧客がアクセスするネットワークツールを実行する環境。たとえば、VPN、MPLS プライベートネットワーク、GRE トンネルなどです。 |
| 仮想デスクトップインフラストラクチャー(VDI) | VDI システムは、ネットワークの輻輳、レイテンシー、およびジッターの影響を受けます。VDI にはアップストリームトラフィックとダウンストリームのトラフィックが必要で、キャッシュに依存してアプリケーションをエンドユーザーに配信することはできません。 |
| voice over IP (VoIP) | VoIP システムは、ネットワークの輻輳、レイテンシー、およびジッターの影響を受けます。VoIP システムには対称的なトラフィックパターンがあり、最適なパフォーマンスのためにネットワーク QoS (Quality of Service)が必要です。さらに、アクティブキュー管理を実装して、音声およびマルチメディアコンテンツを配信できます。ユーザーは、レイテンシーおよびジッターの変動に敏感であり、非常に低いレベルで検出できます。 |
| ビデオまたは Web 会議 | 会議システムは、ネットワークの輻輳、レイテンシー、およびジッターの影響を受けます。ビデオ会議システムでは対称的なトラフィックパターンがありますが、ネットワークが MPLS プライベートネットワークでホストされていない場合、システムはネットワーク QoS (Quality of Service)を使用してパフォーマンスを向上できません。VoIP と同様に、これらのシステムのユーザーは、低レベルであってもネットワークのパフォーマンス問題に気づくことができます。 |
| Web ポータルまたはサービス | Web サーバーはクラウドサービスでは一般的なアプリケーションであり、ネットワーク要件を理解する必要があります。ユーザー要求を満たし、最小限のレイテンシーで Web ページを提供するためにネットワークはスケールアウトする必要があります。ポータルアーキテクチャーの詳細に応じて、アーキテクチャーを計画するときに内部 east-west および north-south ネットワーク帯域幅を考慮する必要があります。 |
4.5.2. クラウドストレージとバックアップアーキテクチャー
このアーキテクチャーは、ファイルストレージおよびファイル共有を提供するクラウド向けです。このストレージ中心のユースケースを検討する場合もありますが、ネットワーク側の要件ではネットワーク中心のユースケースになります。
インストールおよびデプロイメントのドキュメントは、5章デプロイメント情報 を参照してください。
4.5.2.1. 設計について
次のクラウドバックアップアプリケーションのワークロードには、ネットワークに影響を与える 2 つの具体的な動作があります。
このワークロードには、外部向けサービスと内部レプリケーションアプリケーションが含まれるため、north-south および east-west トラフィックに関する考慮事項が必要です。
- North-south トラフィック
North-south トラフィックは、クラウドとの間で移動するデータで設定されます。ユーザーがコンテンツをアップロードおよび保存すると、そのコンテンツはサウスバウンドを OpenStack 環境に移動します。ユーザーがコンテンツをダウンロードすると、そのコンテンツは OpenStack 環境からノースバウンドを移動します。
このサービスは主にバックアップサービスとして動作するため、ほとんどのトラフィックはサウスバウンドを環境に移動します。このような状況では、OpenStack 環境に入るトラフィックは環境外に出るトラフィックよりも多いため、ネットワークを非対称にダウンストリームに設定する必要があります。
- East-west トラフィック
- East-west トラフィックは、環境内で移動するデータで設定されます。レプリケーションは任意のノードから行われ、複数のノードがアルゴリズムでターゲットとなる可能性があるため、このトラフィックは完全な対称になる可能性があります。ただし、このトラフィックは north-south トラフィックに干渉する可能性があります。
4.5.2.2. アーキテクチャーコンポーネント
| コンポーネント | 説明 |
|---|---|
| コンピュート | コンピュート管理およびスケジューリングサービスは、コントローラーで実行されます。Compute サービスは、各コンピュートノードでも実行されます。 |
| Dashboard | OpenStack 管理用の Web コンソール。 |
| Identity | 基本的な認証および承認機能。 |
| イメージ | インスタンスの起動およびスナップショットの管理に使用するイメージを保存します。このサービスはコントローラーで実行され、イメージの小さなセットを提供します。 |
| ネットワーク | ネットワークサービス。OpenStack Networking の詳細は、2章Networking In-Depthを参照してください。 |
| オブジェクトストレージ | バックアップのコンテンツを保存します。 |
| テレメトリー | 他の OpenStack サービスの監視およびレポート。 |
4.5.2.3. 設計に関する考慮事項
3章設計 で説明されている基本的な設計に関する考慮事項に加えて、「Network-Focused Architecture の考慮事項」 で説明されている考慮事項にも従う必要があります。
4.5.3. 大規模な Web アプリケーションのアーキテクチャー
このアーキテクチャーは、バーストの水平方向にスケーリングし、インスタンス数が高いものを生成する大規模な Web アプリケーション用です。アプリケーションでは、データを保護するために SSL 接続が必要であり、個々のサーバーへの接続を失うことはできません。
インストールおよびデプロイメントのドキュメントは、5章デプロイメント情報 を参照してください。
4.5.3.1. 設計について
次の図は、このワークロードの設計例を示しています。
この設計には、以下のコンポーネントとワークフローが含まれます。
- ハードウェアロードバランサーは、SSL オフロード機能を提供し、テナントネットワークに接続してアドレス消費を減らします。
- ロードバランサーは、アプリケーションの仮想 IP (VIP)にサービスを提供する間にルーティングアーキテクチャーにリンクします。
- ルーターとロードバランサーは、アプリケーションテナントネットワークの GRE トンネル ID と、テナントサブネットにある IP アドレス（アドレスプールの外）を使用します。この設定により、ロードバランサーはパブリック IP アドレスを消費せずにアプリケーション HTTP サーバーと通信できるようになります。
4.5.3.2. アーキテクチャーコンポーネント
Web サービスのアーキテクチャーは、多くのオプションとオプションのコンポーネントで設定できます。したがって、このアーキテクチャーは複数の OpenStack 設計で使用できます。ただし、ほとんどの Web スケールワークロードを処理するために、いくつかの主要コンポーネントをデプロイする必要があります。
| コンポーネント | 説明 |
|---|---|
| コンピュート | コンピュート管理およびスケジューリングサービスは、コントローラーで実行されます。Compute サービスは、各コンピュートノードでも実行されます。 |
| Dashboard | OpenStack 管理用の Web コンソール。 |
| Identity | 基本的な認証および承認機能。 |
| イメージ | インスタンスの起動およびスナップショットの管理に使用するイメージを保存します。このサービスはコントローラーで実行され、イメージの小さなセットを提供します。 |
| ネットワーク | ネットワークサービス。分割されたネットワーク設定は、プライベートテナントネットワークに存在するデータベースと互換性があります。データベースは大量のブロードキャストトラフィックを出力せず、コンテンツのために他のデータベースに相互接続する必要がある場合があります。 |
| Orchestration | スケールアウト時に使用するインスタンステンプレートを管理します。トラフィックのバースト中に、このテンプレートを使用します。 |
| テレメトリー | 他の OpenStack サービスの監視およびレポート。このサービスを使用して、インスタンスの使用状況を監視し、Orchestration サービスからインスタンステンプレートを呼び出します。 |
| オブジェクトストレージ | バックアップのコンテンツを保存します。 |
4.5.3.3. 設計に関する考慮事項
3章設計 で説明されている基本的な設計に関する考慮事項に加えて、「Network-Focused Architecture の考慮事項」 で説明されている考慮事項にも従う必要があります。
4.5.4. Network-Focused Architecture の考慮事項
3章設計および2章Networking In-Depthで説明されているネットワークノード設計に関する基本的な設計に関する考慮事項に加えて、次の項目をネットワーク集約型アーキテクチャー向けに考慮する必要があります。
- 外部の依存関係
以下の外部ネットワークコンポーネントの使用を検討してください。
- ワークロードを分散したり、特定の機能を読み込んだりするハードウェアロードバランサー
- 動的ルーティングを実装する外部デバイス
OpenStack Networking はトンネリング機能を提供しますが、ネットワーキング管理リージョンに制限されています。OpenStack リージョンを超えて別のリージョンや外部システムにトンネルを拡張するには、OpenStack 外部のトンネルを実装するか、トンネル管理システムを使用してトンネルまたはオーバーレイを外部トンネルにマッピングします。
- 最大伝送単位 (MTU)
一部のワークロードでは、大量のデータを転送するため、より大きな MTU が必要です。ビデオストリーミングやストレージレプリケーションなどのアプリケーションにネットワークサービスを提供する場合は、可能な限り、OpenStack ハードウェアノードとジャンボフレームをサポートするネットワーク機器を設定します。この設定により、利用可能な帯域幅の使用率を最大化します。
パケットを通過するパス全体でジャンボフレームを設定します。1 つのネットワークコンポーネントがジャンボフレームを処理できない場合、パス全体がデフォルトの MTU に戻ります。
- NAT の使用
固定パブリック IP の代わりに Floating IP が必要な場合は、NAT を使用する必要があります。たとえば、DHCP サーバーの IP にマッピングされた DHCP リレーを使用します。この場合、新規インスタンスごとにレガシーまたは外部システムを再設定するのではなく、インフラストラクチャーを自動化してターゲット IP を新規インスタンスに適用することが容易になります。
OpenStack Networking で管理される Floating IP の NAT は、ハイパーバイザーにあります。ただし、他のバージョンの NAT が他の場所で実行されている可能性があります。IPv4 アドレスが足りなくなった場合には、以下の方法を使用して、OpenStack の外部にある欠点を軽減することができます。
- OpenStack のロードバランサーをインスタンスとして、または外部からサービスとして実行します。OpenStack Load-Balancer-as-a-Service (LBaaS)は、HAproxy などの負荷分散ソフトウェアを内部で管理できます。このサービスは仮想 IP (VIP)アドレスを管理しますが、HAproxy インスタンスからのデュアルホーム接続は、パブリックネットワークを、すべてのコンテンツサーバーをホストするテナントプライベートネットワークに接続します。
- ロードバランサーを使用して VIP を提供し、外部メソッドまたはプライベートアドレスを使用してテナントオーバーレイネットワークに接続します。
場合によっては、インスタンスで IPv6 アドレスのみを使用し、NAT64 や DNS64 などの NAT ベースの移行テクノロジーを提供するために、インスタンスまたは外部サービスを操作することが望ましい場合があります。この設定では、IPv4 アドレスを使用する一方で、グローバルにルーティング可能な IPv6 アドレスが提供されます。
- Quality of Service (QoS)
QoS は、ネットワークのパフォーマンスが低下するため、優先度の高いパケットにインスタントサービスを提供するため、ネットワーク集約型のワークロードに影響します。Voice over IP (VoIP)などのアプリケーションでは、通常、継続的な操作に差別化されたサービスコードポイントが必要です。
また、混合ワークロードに QoS を使用して、バックアップサービス、ビデオ会議、ファイル共有などの優先度の低い高帯域幅アプリケーションが、他のワークロードの継続的な操作に必要な帯域幅をブロックするのを防ぐこともできます。
ファイルストレージトラフィックを ベストエフォート や scavenger などの低いクラストラフィックとしてタグ付けして、優先度の高いトラフィックがネットワークを通過できるようにすることができます。クラウド内のリージョンが地理的に分散されている場合は、WAN 最適化を使用してレイテンシーまたはパケットロスを削減することもできます。
- ワークロード
ルーティングとスイッチングアーキテクチャーは、ネットワークレベルの冗長性を必要とするワークロードに対応する必要があります。設定は、選択したネットワークハードウェア、選択したハードウェアパフォーマンス、およびネットワークモデルによって異なります。例としては、Link Aggregation (LAG)や Hot Standby Router Protocol (HSRP)などがあります。
ワークロードはオーバーレイネットワークの有効性にも影響します。アプリケーションネットワーク接続が小規模、有効期間の短い、またはバースト性である場合、動的オーバーレイを実行すると、ネットワークが処理するパケットと同じ量の帯域幅を生成できます。また、オーバーレイは、ハイパーバイザーで問題を引き起こすのに十分なレイテンシーを発生させる可能性があり、1 回あたりのパケットおよび 1 秒あたりの接続速度でパフォーマンスが低下する可能性があります。
デフォルトでは、オーバーレイにはワークロードに依存するセカンダリー full-mesh オプションが含まれています。たとえば、ほとんどの Web サービスアプリケーションでは、完全なメッシュオーバーレイネットワークに関する大きな問題がなく、一部のネットワーク監視ツールまたはストレージレプリケーションワークロードには、スループットまたは過剰なブロードキャストトラフィックに関するパフォーマンスの問題があります。
