仮想インフラストラクチャー設計
仮想インフラストラクチャー層には、物理インフラストラクチャー層で提供されるコンピュート、ストレージ、ネットワーク・リソースを仮想化する VMware® ソフトウェア・コンポーネント (VMware vSphere ESXi®、VMware NSX-T™、VMware vSAN™ (オプション)) が含まれます。
VMware vSphere 設計
vSphere ESXi 構成は、以下の側面から成ります。
- ブート構成
- 時刻同期
- ホスト・アクセス
- ユーザーのアクセス権限
- DNS 構成
次の表は、各側面の仕様の概要を示しています。 ESXi の構成とインストール後、ホストが VMware vCenter Server® に追加され、そこから管理されます。
この設計では、Direct Console User Interface (DCUI) および 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 プロセッサー搭載の管理クラスターでは、 vSphereで Cascade Lake EVC がサポートされていないため、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 アプライアンスによって管理される追加のクラスターをデプロイする。
- 独自の vCenter アプライアンスとともに、新しい VMware Cloud Foundation for Classic - Automated インスタンスを展開する。
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 でハードコーディングするよう指定しています。