Red Hat Summit3.4. ネットワークリソース
クラウドデプロイメントのハイパーバイザーでは、ネットワークの可用性が非常に重要です。たとえば、ハイパーバイザーが各ノードで少数の仮想マシン(VM)のみをサポートし、アプリケーションが高速ネットワークを必要としない場合は、1 つまたは 2 つの 1GB のイーサネットリンクを使用できます。ただし、アプリケーションで高速ネットワークが必要な場合や、ハイパーバイザーが各ノードに多くの仮想マシンをサポートする場合は、1 つまたは 2 つの 10GB のイーサネットリンクが推奨されます。
標準的なクラウドデプロイメントでは、通常、従来のコアネットワークトポロジーに必要なものよりも多くのピアから排他的ピア通信を使用します。VM はクラスター全体でランダムにプロビジョニングされますが、これらの仮想マシンは、同じネットワーク上にあるかのように相互に通信する必要があります。この要件は、エッジとネットワークのコア間のリンクが過剰にサブスクライブしているため、ネットワークの速度が低下し、従来のコアネットワークトポロジーでパケットロスを引き起こす可能性があります。
3.4.1. サービスの分離
OpenStack クラウドには従来、複数のネットワークセグメントがありました。各セグメントは、クラウド内のリソースへのアクセスを、オペレーターとテナントに提供します。ネットワークサービスには、他のネットワークとは別のネットワーク通信パスも必要です。サービスを別々のネットワークに分割すると、機密データを保護し、サービスへのアクセスから保護できます。
最小限推奨されるサフィゲーションには、以下のネットワークセグメントが含まれます。
- クラウド REST API にアクセスするためにテナントとオペレーターが使用するパブリックネットワークセグメント。通常、クラウド内のコントローラーノードと swift プロキシーのみが、このネットワークセグメントに接続する必要があります。場合によっては、このネットワークセグメントがハードウェアロードバランサーや他のネットワークデバイスがサービスを提供することもあります。
クラウド管理者がハードウェアリソースを管理し、ソフトウェアおよびサービスを新しいハードウェアにデプロイする設定管理ツールによって使用される管理ネットワークセグメント。場合によっては、このネットワークセグメントは、相互に通信する必要のあるメッセージバスやデータベースサービスなど、内部サービスにも使用される場合があります。
このネットワークセグメントのセキュリティー要件により、このネットワークを不正アクセスから保護することが推奨されます。このネットワークセグメントは通常、クラウド内のすべてのハードウェアノードと通信する必要があります。
アプリケーションとコンシューマーが物理ネットワークへのアクセスを提供し、ユーザーがクラウドで実行しているアプリケーションにアクセスするために使用するアプリケーションネットワークセグメント。このネットワークは、パブリックネットワークセグメントから分離する必要があり、クラウドのハードウェアリソースと直接通信しないでください。
このネットワークセグメントは、アプリケーションデータをクラウド外の物理ネットワークに転送するコンピュートリソースノードおよびネットワークゲートウェイサービスによる通信に使用できます。
3.4.2. ネットワークタイプを選択します。
選択するネットワーク種別は、クラウドネットワークアーキテクチャーの設計において重要なロールを果たします。
- OpenStack Networking (neutron)は、OpenStack forward-looking ロードマップの中核となるソフトウェア定義ネットワーク(SDN)のコンポーネントで、現在開発中です。
- コンピューティングネットワーク(nova-network)は、OpenStack テクノロジーのロードマップでは非推奨でしたが、現在はまだ利用可能です。
コンピュートネットワークと OpenStack Networking の間に移行パスはありません。したがって、コンピュートネットワークをデプロイする場合には、OpenStack Networking にアップグレードすることはできません。また、ネットワーク種別間の移行は手動で行う必要があり、ネットワークの停止が必要になります。
3.4.2.1. OpenStack Networking (neutron)を選択するタイミング
以下の機能のいずれかが必要な場合は、OpenStack Networking を選択します。
Overlay ネットワークソリューション。OpenStack Networking は、仮想マシンのトラフィックの分離に GRE および VXLAN トンネリングをサポートします。GRE または VXLAN は、ネットワークファブリック上の VLAN 設定を必要としません。ノード間で IP 接続を提供するのに物理ネットワークのみを必要とします。
また、VXLAN または GRE では、802.1q VLAN 上の 4094 固有の ID 制限と比較して、理論上の固有 ID の 1,600万固有の ID を許可します。コンピューティングネットワークは、802.1q VLAN でネットワークの分離をベースとし、GRE または VXLAN によるトンネリングをサポートしません。
テナント間で IP アドレスが重複している。OpenStack Networking は、Linux カーネルのネットワーク名前空間機能を使用します。これにより、重複や干渉のリスクなしに、同じコンピュートノード上の 192.168.100/24 などの同じサブネット範囲を使用することができます。この機能は、大規模なマルチテナンシーのデプロイメントに適しています。
比較により、コンピュートネットワークは、すべてのテナントが使用するサブネットを認識しておく必要のあるフラットトポロジーのみを提供します。
Red Hat 認定のサードパーティーの OpenStack Networking プラグイン。デフォルトでは、Red Hat OpenStack Platform はオープンソースの ML2 コアプラグインと Open vSwitch (OVS)メカニズムドライバーを使用します。OpenStack Networking のモジュラー構造では、物理ネットワークファブリックやその他のネットワーク要件に基づいて、デフォルトの ML2/Open vSwitch ドライバーの代わりに、サードパーティーの OpenStack Networking プラグインをデプロイすることができます。
Red Hat は、パートナー認定プログラムを拡張して、Red Hat OpenStack Platform 用のより多くの OpenStack Networking プラグインを認定しています。認定プログラムの詳細と、認定された OpenStack Networking プラグインのリストは、http://marketplace.redhat.comを参照してください。
- VPN-as-a-service (VPNaaS)、Firewall-as-a-service (FWaaS)、または Load-Balancing-as-a-service (LBaaS)。これらのネットワークサービスは OpenStack Networking でのみ利用でき、コンピュートネットワークでは使用できません。ダッシュボードでは、テナントは管理者の介入なしにこれらのサービスを管理できます。
3.4.2.2. Compute Networking (nova-network)を選択するタイミング
Compute Networking (nova-network)サービスは、主に 2 つのモードで動作するレイヤー 2 ネットワークサービスです。これらのモードは、VLAN の使用方法によって異なります。
- フラットネットワークモード。クラウド全体のすべてのネットワークハードウェアノードおよびデバイスは、アプリケーションデータへのアクセスを提供する単一のレイヤー 2 ネットワークセグメントに接続されます。
- VLAN セグメンテーションモード。クラウド内のネットワークデバイスが VLAN によるセグメンテーションをサポートする場合、クラウド内の各テナントには、物理ネットワーク上の VLAN にマッピングされたネットワークサブネットが割り当てられます。クラウド設計が複数のテナントをサポートし、コンピュートネットワークを使用する必要がある場合は、このモードを使用する必要があります。
コンピューティングネットワークは、クラウドオペレーターによってのみ管理されます。テナントはネットワークリソースを制御できません。テナントがネットワークセグメントやサブネット等のネットワークリソースを管理および作成する必要がある場合は、インスタンスへのネットワークアクセスを提供するために OpenStack Networking サービスをインストールする必要があります。
次の場合は、Compute Networking を選択します。
- デプロイメントに、フラットなタグなしネットワークまたはタグ付けされた VLAN 802.1q ネットワークが必要な場合ネットワークトポロジーは理論的なスケールを 4094 の VLAN ID に制限し、物理スイッチは通常はるかに少ない数をサポートすることに注意してください。このネットワークにより、管理およびプロビジョニングの制限も軽減されます。ノード間で必要な VLAN セットをトランク接続するようにネットワークを手動で設定する必要があります。
- デプロイでテナント間で IP アドレスが重複している必要がない場合。これは通常、小規模なプライベートデプロイメントにのみ適しています。
- Software Defined Networking (SDN)ソリューションや物理ネットワークファブリックとの対話機能が必要ない場合。
- セルフサービスの VPN、ファイアウォール、または負荷分散サービスが必要ない場合。
3.4.3. 一般的な留意事項
- セキュリティー
ネットワークサービスを分離し、トラフィックが不要な場所を越えずに適切な宛先に流れるようにします。
以下の要素の例を見てみましょう。
- ファイアウォール
- 分離したテナントネットワークを結合するためのオーバーレイ相互接続
- 特定のネットワークを介したルーティングまたは回避
ネットワークがハイパーバイザーにアタッチされると、セキュリティーの脆弱性が漏洩する可能性があります。ハイパーバイザーが侵入するのを軽減するには、他のシステムから複数のネットワークを切り離し、ネットワークのインスタンスを専用のコンピュートノードにスケジュールします。このように分離することで、攻撃者は侵害されたインスタンスからネットワークにアクセスするのを防ぐことができます。
- 容量のプランニング
- クラウドネットワークには、容量と拡張管理が必要です。容量計画には、ネットワーク回路の購入や、数カ月または数週間で測定できるリードタイムのハードウェアを含めることができます。
- 複雑性
- 複雑なネットワーク設計は、保守とトラブルシューティングが難しい場合があります。デバイスレベルの設定はメンテナンスに関する懸念が容易になり、自動化されたツールはオーバーレイネットワークを処理できますが、機能と特殊ハードウェア間の非分割的な相互接続を回避または文書化して、停止を防ぎます。
- 設定エラー
- 誤った IP アドレス、VLAN、またはルーターを設定すると、ネットワーク領域やクラウドインフラストラクチャー全体でも停止する可能性があります。ネットワーク設定を自動化し、ネットワークの可用性を妨げる Operator エラーを最小限に抑えることができます。
- 標準以外の機能
ベンダー固有の機能を利用するようにクラウドネットワークを設定すると、追加のリスクが発生する可能性があります。
たとえば、マルチリンクアグリゲーション(MLAG)を使用して、ネットワークのアグリゲータースイッチレベルで冗長性を提供することができます。MLAG は標準の集約形式ではなく、各ベンダーはその機能のプロプライエタリーフレーバーを実装します。スイッチベンダー間で MLAG アーキテクチャーは相互運用できないため、ベンダーのロックが発生し、ネットワークコンポーネントのアップグレード時に遅延や問題が発生する可能性があります。
- 単一障害点
- ネットワークに、アップストリームリンクが 1 つしかないために、SPOF (Single Point Failure)があり、電源が 1 つしかない場合は、障害が発生した場合にネットワークが停止する可能性があります。
- チューニング
- リンクロス、パケットロス、パケットステルム、ブロードキャストステルム、ループを最小限に抑えるようにクラウドネットワークを設定します。
3.4.4. ネットワークハードウェア
ネットワークハードウェアがすべての実装に適用できる OpenStack クラウドをサポートするための、単一のベストプラクティスアーキテクチャーはありません。ネットワークハードウェアを選択する際の主要な考慮事項は次のとおりです。
- 可用性
中断されないクラウドノードのアクセスを確保するには、ネットワークアーキテクチャーは単一障害点を特定し、適切な冗長性またはフォールトトレランスを提供する必要があります。
- ネットワークの冗長性は、冗長な電源供給またはペアスイッチを追加することで実現できます。
- ネットワークインフラストラクチャーでは、LACP、VRRP などのネットワークプロトコルを使用して、高可用性ネットワーク接続を実現することができます。
- OpenStack API とクラウド内の他のサービスが高可用性であることを確認するには、ネットワークアーキテクチャー内で負荷分散ソリューションを設計する必要があります。
- 接続性
- OpenStack クラウド内のすべてのノードには、ネットワーク接続が必要です。場合によっては、ノードが複数のネットワークセグメントにアクセスする必要がある場合があります。設計には、クラウドのすべての north-south および east-west トラフィックに十分なリソースが含まれるように、十分なネットワーク容量と帯域幅を含める必要があります。
- ポート
設計には、必要なポートを持つネットワークハードウェアが必要です。
- ポートの提供に必要な物理領域があることを確認します。コンピュートまたはストレージコンポーネント用により多くのラックスペースを残すため、ポートの密度が高くなることが優先されます。適切なポートの可用性は、障害ドメインを防ぎ、電力密度を支援します。より高い密度のスイッチはより高価で、ネットワークが必要ない場合は、ネットワークをオーバー署名しないことが重要です。
- ネットワークハードウェアは、提案されたネットワーク速度をサポートしている必要があります。たとえば、1 GbE、10 GbE、または 40 GbE （または 100 GbE）です。
- Power
- 選択したネットワークハードウェアに必要な電源が物理データセンターが提供することを確認します。たとえば、リーフアンドスピーンのファブリックまたは行末(EoR)スイッチのスパインスイッチでは、十分な電力が得られない可能性があります。
- スケーラビリティー
- ネットワーク設計には、スケーラブルな物理ネットワークおよび論理ネットワーク設計が含まれている必要があります。ネットワークハードウェアは、ハードウェアノードが必要とするインターフェイスの種類と速度を提供する必要があります。
