第4章 アーキテクチャー例

短期間のワークロードは、継続的インテグレーション/継続的デプロイ (CI-CD) のジョブを含めることができます。これにより、コンピュート集約型のタスクセットを実行するためのコンピュートインスタンスが多数同時に作成されます。次に環境は、インスタンスを削除する前に、結果とアーティファクトを各インスタンスから長期ストレージにコピーします。

Hadoop クラスターや HPC クラスターなどの長期間のワークロードは、通常大量のデータセットを受信し、それらのデータセットに対してコンピューティング作業を実行して、その結果を長期ストレージにプッシュします。コンピューティング作業が終了すると、インスタンスは別のジョブを受信するまでアイドル状態となります。長期間のワークロード用の環境は、より大きく、複雑な場合が多いですが、ジョブとジョブの間にアクティブな状態を維持するように環境を構築することで、ビルドのコストを相殺することができます。

コンピュートを重視した OpenStack クラウドのワークロードは、ほとんどの場合、永続ブロックストレージを必要としません (ただし、HDFS で Hadoop を使用する一部のクラウドを除く)。共有ファイルシステムまたはオブジェクトストアが初期データセットを維持管理し、コンピューティング結果の保存先としての役割を果たします。入出力 (IO) オーバーヘッドを回避することにより、ワークロードパフォーマンスを大幅に強化することができます。データセットのサイズによっては、オブジェクトストアまたは共有ファイルシステムをスケーリングする必要がある場合があります。

クラウドユーザーは、必要に応じて新規リソースに即時にアクセスできることを期待します。このため、使用状況が標準的な場合と、リソースの需要が急上昇した場合の計画を立てておく必要があります。計画が保守的過ぎると、クラウドが予想外に過剰にサブスクライブされる可能性があります。また、計画がアグレッシブ過ぎると、クラウドが予想外に過小使用の状態となり、不要な運用/保守コストを費すことになる場合があります。

拡張計画の重要な要因は、クラウドの使用状況トレンドの経時的な分析です。平均スピードやクラウドのキャパシティーではなく、サービス提供の一貫性を測定します。このような情報は、キャパシティーパフォーマンスをモデリングして、クラウドの現在および将来のキャパシティーをより正確に判断するのに役立てることができます。

ソフトウェアのモニタリングについての情報は、「追加のソフトウェア」 を参照してください。

現在の標準的なサーバーオファリングは、最大 12 コアの CPU を搭載します。また、一部の Intel CPU はハイパースレッディング・テクノロジー (HTT) をサポートしており、その場合はコアのキャパシティーが倍になります。HTT 対応の複数の CPU をサポートするサーバーの場合は、利用可能なコア数が CPU 数を乗算した値となります。ハイパースレッディングは、インテル専有の同時マルチスレッディングの実装で、インテルの CPU 上での並列化を向上するために使用されます。マルチスレッドアプリケーションのパフォーマンスを向上させるには、HTT を有効化することを検討してください。

CPU での HTT 有効化の決定は、ユースケースによって異なります。たとえば、HTT を無効にすることによって、コンピューティング集約型の環境に役立つ場合があります。HTT を有効にした場合と無効にした場合のローカルワークロードのパフォーマンステストを実行すると、特定の例では、どちらのオプションがより適切かを判断するのに役立てることができます。

以下のストラテジーを 1 つまたは複数使用して、コンピュート環境にキャパシティーを追加することができます。

コンピュートを重視した OpenStack クラウドは、プロセッサーとメモーリソースに対する需要が極めて高いため、CPU ソケット、CPU コア、メモリーをより多く提供することができる サーバーハードウェアを優先すべきです。

このアーキテクチャーには、ネットワーク接続とストレージ容量はそれほど重要ではありません。ハードウェアは、ユーザーの最小要件を満たすのに十分なネットワーク接続性とストレージキャパシティーを提供する必要がありますが、ストレージとネットワークのコンポーネントは主にデータセットをコンピュート用のクラスターにロードし、一定したパフォーマンスは必要ありません。

コモディティーハードウェアにオープンソースのソフトウェアを使用して、ストレージアレイをビルドすることができますが、デプロイには、専門知識が必要となります。サーバーで直接アタッチされたストレージを使用するスケールアウトストレージソリューションを使用することもできます。ただし、その場合には、サーバーのハードウェアがストレージソリューションをサポートする必要があります。

ストレージハードウェアの設計時には、以下の要素を考慮してください。

「2章ネットワークに関する詳細」に記載した基本的なネットワークの考慮事項に加えて、以下の要素も考慮してください。

監視と警告のサービスは、ストレージリソースに対する需要の高いクラウド環境では極めて重要です。これらのサービスは、ストレージシステムの正常性とパフォーマンスのリアルタイムのビューを提供します。統合管理コンソール、または SNMP データを視覚化するその他のダッシュボードは、ストレージクラスター内で発生した問題の発見と解決に役立ちます。

ストレージを重視したクラウド設計には以下の要素が含まれるべきです。

以下のような外部ネットワークコンポーネントの使用を検討してください。

OpenStack Networking は、トンネリング機能を提供しますが、ネットワーク管理されたリージョンのみに制限されています。OpenStack リージョンを超えて、他のリージョンまたは外部システムにトンネルを拡張するには、OpenStack の外部にトンネルを実装するか、トンネル管理システムを使用して、外部トンネルへのトンネルまたはオーバーレイをマッピングします。

一部のワークロードは、大型のデータブロックを転送するために大きな MTU が必要です。ビデオストリーミングやストレージのレプリケーションなどのアプリケーション用のネットワークサービスを提供する場合には、OpenStack ハードウェアノードと、可能な場合にはジャンボフレーム用の補助ネットワーク機器を設定します。この構成は、利用可能な帯域幅の使用率を最大化します。

パケットが通過する全パスにわたってジャンボフレームを設定します。1 つのネットワークコンポーネントがジャンボフレームに対応できない場合には、全パスがデフォルトの MTU に戻ります。

固定のパブリック IP ではなく、Floating IP が必要な場合は、NAT を使用する必要があります。たとえば、DHCP サーバーの IP にマッピングされている DHCP リレーを使用します。この場合には、各新規インスタンスにレガシーや外部のシステムを再設定する代わりに、インフラストラクチャーがターゲットの IP アドレスを新規インスタンスに適用するように自動化した方が簡単です。

OpenStack Networking によって管理される Floating IP 用の NAT は、ハイパーバイザー内に常駐しますが、その他のバージョンの NAT は他の場所で実行される場合があります。IPv4 アドレスが不足している場合には、以下の方法を用いて OpenStack 外の IPv4 アドレス不足を軽減することができます。

場合によっては、インスタンスで IPv6 アドレスのみを使用し、NAT ベースの移行テクノロジー (例: NAT64、DNS64) を提供するインスタンスまたは外部サービスを稼働することもできます。この設定は、グローバルでルーティング可能な IPv6 アドレスを提供し、IPv4 アドレスは必要のある場合にしか使用しません。

QoS は、ネットワークパフォーマンスの低下により優先順位が高くなったパケットに対して即時にサービスを提供するので、ネットワーク集約型のワークロードに多大な影響を及ぼします。Voice over IP (VoIP) のようなアプリケーションでは、継続的な運用には、通常、差別化されたサービスコードポイントが必要です。

複数の混在するワークロードで QoS を使用して、優先順位が低く帯域幅の大きいアプリケーション (例: バックアップサービス、ビデオコンファレンス、ファイル共有など) が他のワークロードの継続的な運用に必要な帯域幅をブロックしてしまわないようにすることもできます。

ファイルとストレージ間のトラフィックに低いクラスのトラフィック (例: ベストエフォート、スカベンジャーなど) のタグを付けて、優先度の高いトラフィックがネットワークを通過できるようにすることが可能です。クラウド内のリージョンが地理的に分散されている場合、WAN 最適化を使用してレイテンシーやパケット損失を軽減することができます。

ルーティングとスイッチングのアーキテクチャーは、ネットワークレベルの冗長性を必要とするワークロードに対応すべきです。この構成は、選択したネットワークハードウェア、選択したハードウェアのパフォーマンス、ネットワークモデルによって異なります。例としては、リンクアグリゲーション (LAG)、ホットスタンバイルータープロトコル (HSRP) があります。

ワークロードは、オーバーレイネットワークの有効性に影響します。アプリケーションネットワークの接続が少量、短期間、またはバースト性の場合には、動的なオーバーレイを実行すると、ネットワークが伝送するパケットの分だけの帯域幅を生成することができます。オーバーレイは、ハイパーバイザーで問題が発生する原因となるのに十分な長さのレイテンシーを起し、パケット毎秒や接続数毎秒などでパフォーマンス低下をもたらす場合もあります。

デフォルトでは、オーバーレイには第 2 のフルメッシュオプションがあり、ワークロードによって異なります。たとえば、大半の Web サービスアプリケーションは、フルメッシュのオーバーレイネットワークで大きな問題はありませんが、一部のネットワーク監視ツールやストレージレプリケーションワークロードでは、スループットでパフォーマンスの問題が発生したり、ブロードキャストトラフィックが過剰となります。