仮想インフラストラクチャー設計
販売終了 ：2025年10月31日をもって、新規のお客様による「 VMware Solutions 」サービスの新規導入は利用できなくなります。 既存のお客様は、引き続き IBM Cloud® 上で、稼働中の VMware® ワークロードを利用・拡張することができます。 詳細は VMware 、マーケティング終了 IBM Cloud を参照。
仮想インフラ層には、物理インフラ層で提供されるコンピュート、ストレージ、およびネットワークリソースを仮想化する VMware® ソフトウェアコンポーネントが含まれます： VMware vSphere ESXi™、 VMware NSX-T™、およびオプションとして VMware vSAN™。
VMware vSphere 設計
vSphere ESXi 構成は、以下の側面から成ります。
- ブート構成
- 時刻同期
- ホスト・アクセス
- ユーザーのアクセス権限
- DNS 構成
次の表は、各側面の仕様の概要を示しています。 ESXi の構成とインストール後、ホストが VMware vCenter Server® に追加され、そこから管理されます。
このデザインでは、Direct Console User Interface (DCUI) と VMware vSphere® Web Client からバーチャルホストにアクセスできます。 セキュア・シェル (SSH) と ESXi シェルは、プロビジョニング後に無効になるのがベスト・プラクティスです。
デフォルトでは、直接ログインできるユーザーは、ホストの物理マシンの ルート ユーザーおよび ibmvmadmin ユーザーのみです。 管理者は、Microsoft® Active Directory™ (MSAD) ドメインからユーザーを追加して、ホストへのユーザー・アクセスを可能にすることができます。 VMware Cloud Foundation for Classic - Automated ソリューション・デザインのすべてのホストは、中央の NTP サーバーと同期するように設定されている。
| 属性 | 構成パラメーター |
|---|---|
| ESXi ブート・ロケーション |
さまざまなホスト構成が展開されるかもしれない：
|
| 時刻同期 | IBM Cloud® NTP サーバーを使用 |
| ホスト・アクセス | DCUI をサポート。 SSH と ESXi シェルはサポートされますが、デフォルトで無効です |
| ユーザーのアクセス権限 | ローカル認証と MSAD |
| ドメイン・ネームの解決 | DNS を使用 (共通サービス設計を参照) |
| EVC モード | vSphere バージョンでサポートされる使用可能な最高レベル。 ただし、インテル® Cascade Lakeプロセッサーを搭載した管理クラスターの場合、Cascade Lake EVCが vSphere バージョンでサポートされていないため、EVCは設定されません。 |
vSphere クラスターには、 VMware Cloud Foundation for Classic - Automated インスタンスを管理する仮想マシン（VM）と、ユーザー・ワークロード用のコンピュート・リソースが格納されている。
- VMware Cloud Foundation for Classic - Automated インスタンスが vSAN, を使用する場合、初期導入時の ESXi ホストの最小数は 4 台です。
- VMware Cloud Foundation for Classic - Automated インスタンスが共有ファイルレベルまたはブロックレベルのストレージを使用する場合、初期導入時の ESXi ホストの最小数は 3 台です。
初期デプロイメント時には、このクラスターに最大 20 台の ESXi ホストをデプロイできます。 初期デプロイメントの後は、最大 50 台のホストまでクラスターをスケールアップできます (一度に追加できるホストは最大 20 台)。
より大きなユーザー・ワークロードをサポートするには、以下の操作を実行して環境を拡大できます。
- 既存クラスターで追加のコンピュート・ホストをデプロイする。
- 同じ vCenter Server アプライアンスによって管理される追加のクラスターをデプロイする。
- 新しい VMware Cloud Foundation for Classic - Automated インスタンスを、専用の vCenter Server アプライアンスとともにデプロイする。
VMware vSAN 設計
この設計では、 VMware vSAN ストレージが VMware Cloud Foundation for Classic - Automated インスタンスに採用され、 vSphere ホストに共有ストレージを提供する。
次の図に示すように、vSAN は、vSphere クラスター内の複数の ESXi ホストそれぞれのローカル・ストレージを集約し、集約ストレージを単一の VM データ・ストアとして管理します。 この設計では、ESXi オペレーティング・システム (OS) と vSAN データ・ストアのためのローカル・ディスク・ドライブがコンピュート・ノードに含まれます。
異なるホスト構成で展開されるかもしれない：
- で構成されたローカル・ディスク。 RAID-1
- ミラーリング構成の M.2 ブートドライブのペア
- シングル M.2 ブートドライブ
vSAN では、以下のコンポーネントが使用されます。
- 2 ディスク・グループ vSAN 設計。各ディスク・グループは 2 つ以上のディスクで構成されます。 グループ内の最小サイズの SSD 1 つがキャッシュ層として使用され、残りの SSD または NVMe ドライブが容量層として使用されます。
- vSAN のキャッシュまたはキャパシティーのために使用される個々のドライブのオンボード RAID コントローラーが RAID 0 アレイで構成されます。
- すべてのストレージから単一の vSAN データ・ストアが作成されます。
vSAN 用仮想ネットワークのセットアップ
この設計では、vSAN トラフィックは専用プライベート VLAN 上の ESXi ホスト間を横断します。 プライベート・ネットワーク・スイッチに接続された 2 つのネットワーク・アダプターは、vSphere 内で vSphere 分散スイッチ (vDS) として構成され、どちらのネットワーク・アダプターもアップリンクとして指定されます。 vSAN VLAN 用に構成された専用 vSAN カーネル・ポート・グループは、vDS 内に常駐します。 プライベート vDS でジャンボ・フレーム (MTU 9000) が使用可能になります。
vSAN はアップリンク上のトラフィックのロード・バランスを行いません。 その結果、高可用性をサポートするために、一方のアダプタがアクティブで、もう一方がスタンバイ状態になる。 vSAN のネットワーク・フェイルオーバー・ポリシーは、物理ネットワーク・ポート間の明示的フェイルオーバーとして構成されます。
物理 NIC 接続の詳細については、物理ホストの NIC 接続を参照してください。
vSAN ポリシー設計
vSAN が使用可能になって構成されると、VM ストレージ特性を定義するためにストレージ・ポリシーが構成されます。 ストレージ特性では、VM ごとに異なるサービス・レベルが指定されます。
この設計のデフォルトのストレージ・ポリシーは、単一障害を許容します。 デフォルト・ポリシーは消去コーディングで構成され、障害許容度の方法 は RAID-5/6 (Erasure Coding) - 容量 に設定され、1 次レベルの障害 は 1 に設定されます。 RAID 5 構成は最低 4 つのホストを必要とします。
あるいは RAID 6 構成を選択して、**「障害許容方式 (Failure tolerance method)」を「RAID-5/6 (イレージャー・コーディング) - 容量 (RAID-5/6 (Erasure Coding) - Capacity)」に設定し、「障害のプライマリー・レベル (Primary level of failures)」を 2 に設定することもできます。 RAID 6 構成は最低 6 つのホストを必要とします。 デフォルトのストレージ・ポリシーでは「重複排除 (Deduplication)」と「圧縮 (compression)」**が通常有効になりますが、必要に応じて無効にできます。
vSphere コンソールから特に指定されない限り、インスタンスはデフォルト・ポリシーを使用します。 カスタム・ポリシーが構成された場合、vSAN は可能であればそのカスタム・ポリシーを保証します。 しかし、ポリシーを保証できなければ、そのポリシーを使用する VM をプロビジョンすることはできません。ただし、VM が強制的にプロビジョンできるようになっている場合を除きます。
新しい ESXi ホストの追加後、または ESXi ホストのパッチ後は、ストレージ・ポリシーを再適用する必要があります。
vSAN の設定
vSAN の設定は、IBM Cloud 内に VMware ソリューションをデプロイするためのベスト・プラクティスに基づいて構成されます。 vSAN の設定には、SIOC 設定、明示的フェイルオーバー設定のポート・グループ、ディスク・キャッシュ設定が含まれます。
- SSD キャッシュ・ポリシーの設定 - 「先読み (Read Ahead)」、「ライトスルー (Write Through)」、「直接 (Direct)」 (NRWTD) なし
- ネットワーク I/O 制御の設定
- 管理 - 20 共有
- 仮想マシン - 30 共有
- vMotion - 50 共有
- vSAN - 100 共有
- vSAN カーネル・ポート - 「明示的フェイルオーバー (Explicit Failover)」
NFS 接続ストレージ
NFS サーバー LIF マイグレーションで NFS v4.1 を使用すると、過度の待ち時間が発生することがあります。 NFS ネットワーク接続ストレージを使用する場合、このアーキテクチャーによって、NFS v4.1 ではなく NFS v3 の使用が指示されます。 各 vSphere ホストはそのホスト名を使用して NFS ストレージに接続されます。
1 つの 2-TB NFS データ・ストアが、4 IOPS/GB パフォーマンス・ティアの管理コンポーネントが使用するために 1 つのクラスターに接続されます。 他のデータ・ストアを、各種のサイズとパフォーマンス・ティアでワークロードに使用するためにクラスターに接続することもできます。
また、このアーキテクチャーでは、NFS ストレージがあるサブネット用に作成されたサブネット経路がすべてのホストに含まれていることも必要です。 このサブネット経路は、この設計で NFS トラフィックに指定されたポート・グループ、サブネット、VLAN をすべての NFS トラフィックで使用するよう指示するためのものです。 複数の NFS データ・ストアが接続されている場合、複数の経路を構成する必要が生じることもあります。これらのデータ・ストアが異なるリモート・サブネットにある可能性があるためです。
管理VMは NFS データストアに置くことができる。 このアプローチにより、一部の管理マシンが、NFS ホスト名を解決するために使用される DNS サービスの責任を担うことがあるため、ブートストラッピングの問題が生じます。 そのため、このアーキテクチャーでは、管理データ・ストア用に少なくとも 1 つの IP アドレスを各ホストの /etc/hosts でハードコーディングするよう指定しています。