コンピューティング ベスト プラクティス
このページでは、Google Cloud VMware Engine のコンピューティングのベスト プラクティスについて説明します。
アプリケーションに最適なリージョンを選択する
アプリケーションに最適なリージョンを選択するには、次の要素を考慮してください。
- ネットワーク レイテンシを最小限に抑え、カスタマー エクスペリエンスを向上させるには、ユーザーに最も近いロケーションを選択します。Google Cloud コンソールには、リージョン間とインターネット ユーザーと Google Cloud リージョン間のレイテンシを可視化できるリアルタイム パフォーマンス ダッシュボードがあります。
- アプリケーションのパフォーマンスを維持するには、最も近い Google Cloud リージョンを選択して、オンプレミス施設への接続を最適化します。マルチクラウド デプロイの場合は、他のクラウド ベンダーのリージョンとの近さを考慮してください。
- アプリケーションがPayment Card Industry(PCI)コンプライアンス ポリシーや欧州一般データ保護規則(GDPR)などの規制に準拠し続けるように、これらの要件をサポートするリージョンを選択します。
- 費用と料金はリージョンによって異なります。デプロイを計画する際は、これらのリージョン間の違いを考慮してください。
- 地域を選択する際、一部の SKU は一部地域でのみ利用可能で、他の地域では利用できない場合があります。
マルチリージョン設計を選択するタイミングを決定する
次の状況では、同じワークロードまたはプロジェクト スコープでリージョン全体に複数の VMware Engine プライベート クラウドにデプロイすることをおすすめします。
- Site Recovery Manager(SRM)または Zerto を使用する障害復旧の実装。
- ユーザーベースへのグローバルな可用性または低レイテンシを必要とするアプリケーション。
- リージョン固有の容量計画の要件。
ゾーンの復元力を考慮した設計
VMware Engine は、特定のリージョンでゾーンの冗長性を提供します。これらのリージョンでは、フォールト トレランスを強化するために、プライベート クラウドを拡張クラスタとしてデプロイすることもできます。これらのリージョンの詳細については、VMware Engine リリースノートをご覧ください。
拡張クラスタとしてデプロイされたプライベート クラウドには、2 つの独立したゾーンにノードがあります。この設計をサポートするには、各ゾーンに同じ数のノードが必要です。このような設計により、ゾーンの復元力と VMware vSphere High Availability によってアプリケーションの可用性が確保されます。
拡張プライベート クラウドをプロビジョニングする場合、VM は拡張プライベート クラウドの両側で実行される場合があります。アフィニティ ルールを使用して、ワークロード VM をグループ化してサイトに固定し、クラスタ内のホストへのワークロード VM の配置を制御します。このような設計により、アプリケーションの高可用性(HA)によってゾーンの復元性が確保されます。
複数のプライベート クラウドに環境を分離する
プライベート クラウドは、vCenter Server によって管理される独立した VMware Cloud Foundation スタックです。
VMware Engine のフットプリントを複数のプライベート クラウドに分離できます。たとえば、次の場合に専用の vCenter Server を使用します。
- 特定のワークロード タイプ(仮想デスクトップ インフラストラクチャ(VDI)など)の場合
- プライベート クラウドの上限が不十分な場合
- ライセンスとソフトウェア管理用
- 費用の透明性とシンプルさ
- モニタリング用
- 規制要件への準拠
- 管理コンポーネントとインフラストラクチャを含むすべてのレイヤでマルチテナンシーの場合
管理エンドポイントが不要に増殖しないように、必要な数のプライベート クラウドのみを使用します。
コア数を最適化する
VMware Engine では、ESXi ハイパーバイザに公開される有効な CPU コアの数を減らすことができます。これは、一部のソフトウェア ライセンス契約では望ましい、または必須となる場合があります。
最初のクラスタには vCenter や NSX Manager などの重要なコンポーネントがホストされるため、最初のクラスタのコア数を減らすことはおすすめしません。
クラスタ内の有効なコア数を減らしても、クラスタの実行コスト(特に Oracle ワークロードの場合)は変わりません。詳細については、サポートとライセンスに関するガイダンスをご覧ください。
詳細については、カスタムコア数の制限事項をご覧ください。
復元力を高めるために予備ノードを追加する
VMware Engine クラスタは、復元力を確保するために少なくとも 1 つの予備ノードを持つようにサイズ設定する必要があります。この予備ノードはクラスタで使用でき、負荷が高いときや競合が発生したときに追加の容量とリソースを提供できます。これらの予備ノードは、既存のプライベート クラウドの一部として課金されます。
より高い信頼性が必要な場合は、メンテナンスの時間枠に使用できるように、クラスタにスペアノードを追加することを検討してください。これらの予備ノードで実行するようにワークロードをスケジュールすると、プライベート クラウドでのクラスタの使用を最適化できます。
許容する障害の数を定義する
VMware vSAN の場合、vSAN ストレージ ポリシーの許容障害数(FTT)属性を使用して、データの完全性や VM の可用性に影響を与えることなくクラスタが許容できる障害数を定義します。
FTT 値が高いほど、必要な容量ホストが多くなります。
次のステップ
- ネットワーキング、セキュリティ、ストレージ、移行、費用に関するベスト プラクティスをご確認ください。
- プライベート クラウド VMware Engine コンポーネントについて確認する。
- VMware Engine を試す。詳細については、機能、メリット、ユースケースをご覧ください。
- Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを確認する。詳細については、Cloud アーキテクチャ センターをご覧ください。