ディスカバリーと依存関係

VMware インベントリを抽出するには、RVTools などの抽出ツールを使用できます。 各仮想サーバーについて、以下の情報に留意してください。

• 依存関係を特定する。 この仮想サーバーは何と通信するのか？ 仮想サーバーは単独で移行できますか？
• ネットワークの特徴。 その環境では、固定IPアドレスを使用していますか、それともダイナミックホスト構成プロトコル（DHCP）を使用していますか？ 複数のネットワークインターフェースカード（NIC）が搭載されていますか？ その環境には、仮想ローカルエリアネットワーク（VLAN）に関する特定の要件はありますか？
• 収納レイアウト。 ディスクの数は？ 現在のIOPS使用量は？ 合計容量は？
• パフォーマンスのベースライン。 どのようなCPU、メモリ、ネットワーク、ストレージ・オプションを使用しているか？
• アプリケーションの特徴。 データベースはありますか？ その環境はウェブサーバーをホストしていますか？ コールドマイグレーションをサポートできる環境なのか？
• コンプライアンス要件。 データの場所、暗号化の種類、監査ログ。

この情報を知ることは、波の計画、方法の選択、スケジュールの見積もりに役立つ。

再IPへの対応

サブネットは拡張できず、VPCは特定のアドレスを予約するため、移行計画段階で以下の選択を検討する必要があります。

• 余分なサブネットが必要ですか？ サブネットごとに移行できない場合、特定のアプリケーションでサブネットを再割り当てする必要があるかもしれません。 アプリケーションを独自のサブネットに分離することを検討してください。
• どの仮想サーバーのIPを変更する必要がありますか？ IPが .0、 .1、 .2、 .3、ブロードキャストアドレスを使用している場合、またはIPレンジを統合する必要がある場合は、IPを変更する必要があります。
• DNSとロードバランサーを更新するには、どのような戦略が必要ですか？ VPC内でIPを維持する場合でも、外部DNS、ロードバランサー、ファイアウォールルールを更新し、新しい環境に誘導する必要があるかもしれません。

移行プロセス中も、この情報を利用できるようにしておくこと。

IBM Cloud Transit Gateway

Transit Gateway は、 VMware 環境を VPC に接続するための主要なメカニズムです。 異なるネットワーク・ドメインを接続するクラウド・ルーターと考えてほしい。

IBM Cloud クラシックより ( VMware on クラシック・インフラストラクチャー )

• Transit Gateway クラシック・ アカウント直接接続
• クラシックVLANとVPCサブネット間のルーティングを提供します

VMware より NSX（NSXオーバーレイ付きクラシック）

• Transit Gateway GREトンネルを経由してNSXエッジに接続します
• GRE エンドポイントは NSX エッジと Transit Gateway
• NSXセグメントとVPCサブネット間のルーティング伝播

VMware Cloud Foundation as a Service（ VCFaaS ）より

• Transit Gateway GRE トンネルを通して VCFaaS のエッジに接続する
• NSX と同様のパターンが取られるが、 VCFaaS ポータルで管理される

設計上の考慮事項

• 移行プロジェクトの早い段階で Transit Gateway を用意する
• VMware と VPC 間で IP 範囲が重複すると問題が発生する可能性があるため、ルーティングは慎重に計画しましょう
• 複数のVPCまたはClassic アカウント接続する必要がある場合は、ハブ・アンド・スポーク・トポロジーを検討してください
• 最初の移行の前に、接続性を徹底的にテストする

vCPU 対 pCPU の比率を理解する

VMware vCPU と物理コアのオーバーサブスクリプション比として、4:1または8:1を採用しています（ ）。 pCore VPC標準インスタンスプロファイルは、仮想CPUとハイパースレッドコアの比率を1:1に保証します。 このオーバーサブスクリプションは、VPCの8 vCPU インスタンスが8つの専用ハイパースレッドを持つことを意味します（より少ないコアを共有できる可能性のある8 vCPUs ではありません）。

IBM Cloud バースト可能な仮想サーバーは、2:1、4:1、10:1のオーバーサブスクリプション比率で使用でき、保証された割り当ての 2x までバーストできます。 バースト可能な仮想サーバーの詳細については、 バースト可能な仮想サーバーを 参照してください。

ネットワーク帯域幅の割り当て

各インスタンスプロファイルは、総ネットワーク帯域幅を指定します。 帯域幅の合計は、デフォルトではネットワークトラフィックとストレージI/Oの間に3:1の比率で割り当てられますが、サーバーのプロビジョニング後にこの割り当てを調整することができます。

割り当てに関する帯域幅の詳細については、 インスタンスプロファイルの帯域幅割り当てについてを 参照してください。

プロフィールがサポートしている場合は、プールアロケーションオプションを選択してください。 プールされた割り当ては、帯域幅を均等に分割するのではなく、すべてのボリュームでストレージ帯域幅を（使用量に基づいて）動的に共有します。 ブートボリュームは最低保証されたままだ。

第一世代のストレージ・プロファイル

第一世代のストレージ・プロファイルは、以下のような状況で利用できる。

• 汎用：ブートボリュームに必要、1GBあたり3IOPS
• 5iops-tier: GBあたり5 IOPS
• 10iops-tier: 1GBあたり10 IOPS
• カスタム：正確なIOPSを指定、現在はボリュームあたり最大48,000

第一世代のストレージ・プロファイルには次のような利点がある。

• 複数のボリュームのスナップショットを自動的に作成するスナップショット一貫性グループ
• ブートボリュームに対するGPTとUEFIの検出
• 全地域で利用可能

ブートボリュームと、スナップショット一貫性グループを必要とする本番ワークロードには、第一世代プロファイルを使用します。

第2世代 (sdp) プロファイル

sdp プロファイルは、パフォーマンスの向上と粒度の細かい IOPS 制御を提供します。

以下の制限事項にご留意ください：

• スナップショット一貫性グループはサポートされていません
• sdp プロファイルがGPTフォーマットのボリュームを検出しない可能性がある
• セキュアブートはサポートされていない

このような制限があるため、 sdp をブート・ボリュームには使用しないでください。 sdp は、パフォーマンスが高く、個々のスナップショットに耐えられるセカンダリ・データ・ボリュームに最適です。

セキュリティー・グループ

VMware 分散ファイアウォール（DFW）または NSX マイクロセグメンテーションを使用している場合、これらのルールを VPC セキュリティグループに移行する必要があります。

VPCセキュリティグループの詳細：

• セキュリティ・グループはステートフルであり、返送トラフィックを自動的に許可する。
• トラフィックが許可されている間、仮想ネットワークインターフェース（VNI）に複数のセキュリティグループを割り当てることができます。
• ルールはソースまたはデスティネーションとしてセキュリティグループを参照することができる。
• 明確な拒否ルールは存在しない。 セキュリティグループは許可制です。

移住戦略：

• 現在のDFWまたはファイアウォールのルールを文書化する
• 仮想サーバーをセキュリティポスチャ（ウェブ層、アプリ層、データベース層）ごとにグループ化する
• これらの階層を反映するセキュリティ・グループを作成する
• 可能な限りグループ間参照を使用し、IPの列挙を避ける
• まずは非本番移行で徹底テスト

暗号化

vSAN 暗号化、暗号化 VMDK、またはゲスト OS の暗号化を使用している場合は、これらのオプションを移行する必要があります。

VPC暗号化の詳細：

• すべてのボリュームは、 Key Protect または Hyper Protect Crypto Services （HPCS）を通じて、プロバイダー管理キーまたはユーザー管理キーによる保存時暗号化に対応しています。
• コンフィデンシャル・コンピューティング・プロファイルは、インテル SGXおよびTDXとセキュア・ブートにより、さらなるセキュリティを提供します。
• 仮想サーバーとストレージ間の転送データは、 IBM Cloud インフラによって暗号化される。

マイグレーションへの配慮：

• ほとんどのワークロードでは、 IBM Cloud- 管理された暗号化で十分であり、マイグレーション特有の作業は必要ない。
• コンプライアンス重視の暗号化には、 Key Protect または HPCS をユーザー管理鍵で使用する。
• セキュアブートが必要な場合は、機密コンピューティングプロファイルを使用し、 sdp ストレージを避けてください。