ネットワーク接続の構成

HCX は、公衆インターネットと専用回線を経由して、ネットワーク、スイッチ、ポート・グループなどのデータ・センターのコンポーネントに接続する必要があります。

• HCX 仮想アプライアンスを正常にインストールするために開く必要があるポートについて詳しくは、ポートのアクセス要件を参照してください。
• オンプレミスの vSphere 環境と VMware Cloud Foundation for Classic - Automated HCX クラウド環境の両方で、 vSphere オンプレミスデバイスと VCF for Classic - Automated HCX デバイス間のネットワークタイムプロトコル（NTP）クロック同期を許可する必要があります。 UDP ポート 123 に、HCX の仮想アプライアンスとネットワークがアクセスできる必要があります。

オンプレミス環境

HCX をインストールする前に、実行したいタスクがサポートされる環境であることを確認してください。 HCX をインストールするには、オンプレミス環境が、以下のタスクをサポートする環境でなければなりません。

• vSphere 5.5 Update 3 または 6.0 Update 2 の仮想センター。
• vMotion およびポリシーの移行機能を使用するには、NSX のバージョン 以降が必要です。 6.2.2
• vSphere サービスアカウントと、それに割り当てられている管理者システムロール。
• HCX アプライアンスをインストールするための十分なディスク・スペースが vCenter 内にあること。
• インストール中にプロビジョンされるオンプレミス VM 用の十分な IP アドレス。
• 『ポートのアクセス要件』に必要なものとして記載しているポートおよびファイアウォールが開かれていること。
• シングル・サインオン (SSO) サーバーがリモートにある場合は、外部ルックアップ・サービスを実行する vCenter、外部 SSO サーバー、または Platform Services Controller (PSC) の URL を確認する必要があります。 HCX Manager を vCenter に登録するときに、この URL を指定する必要があります。
• VMware vCenter®、ルックアップ・サービスの独自の内部インスタンスを持っていない場合、以下のいずれかの理由が考えられる。
  • vCenter 6.0u2 が外部 Platform Services Controller を実行している。
  • vCenter がリンクモード（セカンダリ がプライマリ のSSOサービスまたは外部のSSOサービスを使用する）の場合。 vCenter vCenter

レイヤー 2 インストール環境の確認

レイヤー 2 ネットワーク拡張には、次の要件があります。

• vSphere Enterprise Plus エディション。
• vSphere vCenter、レイヤー2拡張をサポートするには以下の要件を満たす必要がある：
  • vSphere Enterprise Plus ライセンス。
  • vSphere 分散スイッチ (vDS) を備えていること。 分散スイッチは、vSphere Enterprise Plus エディションで提供されます。
  • インストールする場合、オンプレミスのレイヤー 2 コンセントレーター・サービス・アプライアンスは、拡張する vNIC ポートと VLAN にアクセスできなければなりません。
  • ネットワークがパブリック・インターネットまたはVPN（代替パス）経由で張られる場合、 VCF for Classic - Automated の L2C VMはIPアドレスを必要とする。 そのリモート IP アドレスを使用して、レイヤー 2 コンセントレーターを構成する必要があります。
  • 複数台のレイヤー 2 コンセントレーターが必要な場合は、L2C ごとにオンプレミスとクラウドの両方の IP アドレスが必要です。

デプロイメント前の計画

HCX をデプロイするときに多くの時間がかかるのは、デプロイメント前の段階です。 一般に、情報システムのマイグレーション・プロジェクトの完了には数カ月から数年の時間がかかります。 しかし、HCX を使用すると、マイグレーションを短時間で実行し、デプロイメントの直後にクラウドへのネットワーク接続を開始することができます。

エンタープライズ・レベルのお客様の場合は、HCX のデプロイメントに、 セキュリティー・チーム、ネットワーク・チーム、ストレージ・チーム、vSphere インフラストラクチャー・チームがかかわるのが普通なので、 可能なら POC にもそうしたチームに参加してもらうのが得策です。 HCXの導入と運用を迅速に実現するためには、効果的なプロジェクト管理と関係者の早期参加が不可欠である。

分析ばかりしていて作業に入らない状況の回避

1 台の仮想マシン (VM) または 1 群の VM のマイグレーションを阻む障壁や、マイグレーションにかかる時間の多くは、アプリケーション環境の一部を変更しなければならないことに起因します。 また、そのような変更を設計することや、変更を実施するために必要なダウン時間のスケジュールを設定することも複雑になる可能性があります。 変更実施後にマイグレーションを元に戻すのは難しく、そうしたことを考え始めると、どうしても分析ばかりしている状態にはまりがちです。 マイグレーションに関係するすべての側面を取り込もうとしたり、チーム間の調整をしたり、重要な関係者を入れ替えたりしているうちに、プロジェクトが遅れていくこともあります。

HCXは、アプリケーションに変更を加えることなく、部分的または完全な複合アプリケーションを表すVMまたはVMグループのインスタンスマイグレーション（ cross-vSphere ）を可能にします。 そのため、マイグレーションから手を引くということは、VMを元に戻すか、ネットワークを再編成することを意味する。 その結果、マイグレーション計画の大部分が不要になり、計画プロセスで並列処理を行うことも可能になります。 移動するアプリケーションを選択して大まかなネットワーク設計を作成したら、ネットワークの最終的な接続と設計に取り組みながら、クラウド・インスタンスの最小限の構成だけでアプリケーションのマイグレーションを開始できます。

ストレッチ・ネットワーク

HCX フリートのネットワークのストレッチ・コンポーネントは安定しています。 あるお客様の場合は、他のトラフィックと共有する 1 Gbps の WAN と HCX のマイグレーション・トンネルを使用して、20 を超える VLAN を IBM Cloud® に拡張 (ストレッチ) しました。 この構成では、ネットワークに起因するアプリケーションの問題は何も起きませんでした。 そのようにしてネットワーク・リンクを 6 カ月以上稼働させました。

ストレッチ・ネットワークを追加したり除去したりした時にも、問題は起きませんでした。 近くにある IBM Cloud データ・センター (この特定のお客様の場合は <6 ms 待ち時間) を選択することも、拡張ネットワーキングのネットワーク安定性に影響します。 アプリケーションに十分な帯域幅と低レイテンシーがあれば、ストレッチされたネットワークを長期的に維持することは、設計上マイナス要因にはならない。

マイグレーション・ライフサイクル

以下の各セクションで、HCX の標準的なマイグレーション・ライフサイクルの各段階を説明し、 ワーク・ストリームを並行して進められる箇所を示します。

vSphere インベントリー

• マイグレーションの対象となるアプリケーションにかかわっている VM を大まかに評価します。 つまり、細かい部分にとらわれずに、アプリケーションに関与している VM を大まかに把握します。
• ソース・サイトとクラウド・サイトの間のネットワーク帯域幅が限られている状態で多数の VM をマイグレーションする場合は、 VLAN や VXLAN ごとに VM をグループ分けします (ただし、ソース側で NSX を採用していることが必要です)。 そうすれば、VLAN ごとにグループ分けした VM をマイグレーションし、その VLAN が解放されたところまで関連 L2 ネットワークをストレッチする、という形で HCX のマイグレーション計画を段階的に進められます。

この場合、最初のグループの関連 L2 ストレッチ・ネットワークのストレッチ解除が可能になるのは、 クラウド・サイドのネットワーク設計が最終的に仕上がってデプロイが済んだ後になります。 ストレッチ解除とは、対象の VXLAN トラフィックをスイングして、 クラウド・インスタンスの NSX インフラストラクチャー経由の新しいルートに送付する、ということです。

ベースライン・ネットワーク構成

クラウド側の vSphere インスタンス内にセキュアな境界ネットワークを作成する。 その構成要素として、通常は、NSX DLR またはエッジ・アプライアンスを使用します。 HCX の近接ルーティングを使用する場合は、ファイアウォール・ルールやアップリンク・トポロジーを作成する必要はありません。その作業は、後から実行することも、ストレッチ L2 トラフィックに影響を与えずに並行して実行することも可能です。

ネットワーク拡張

ネットワーク拡張とは、 既存の VLAN または VXLAN をソース vSphere 環境 (仮想分散スイッチ・ポート・グループ (vDS) で表される環境) から HCX のクラウド・サイドにある NSX VXLAN に拡張する、 ということを意味します。

プリフライト・テスト

プリフライト・テストでは、vMotion と一括マイグレーションの両方の機能によって HCX のマイグレーションを実行し、ベースラインの転送速度を確立します。

非実動アプリケーションのマイグレーション

重要度の低い計画段階に入っている VM からマイグレーションを開始します。 開発チームとテスト・チームは、マイグレーションやストレッチ L2 トラフィックのためにインターネット接続を使用します。

クラウド・ネットワークの設計と実装の開始

マイグレーションが継続される一方で、クラウド側のネットワーク設計は最終化され、クラウド側の vSphere インスタンス内に実装される。

ネットワーク接続に関するその他の考慮事項

マイグレーションを続けながら、プライベート WAN ネットワーク接続を発注します。 クラウド・プロバイダーによって接続が確立されるまでに、通常は数週間から数カ月の時間がかかります。 プライベートネットワーク接続が完了すると、HCXはマイグレーションとストレッチ L2 トラフィックに専用プライベートネットワークリンクとインターネットの両方を使用するように設定できます。

物理サーバー

データ・センターをクラウドにマイグレーションすることが目標である場合は、 マイグレーションする VM と対話する物理サーバーを評価して、VM (P2V) またはベアメタルとして IBM Cloud にマイグレーションするか、 ソースにそのまま残すかを判断します。 物理サーバーをソースにそのまま残し、専用ネットワークが確立されるまでマイグレーションの期間に限って HCX を使用する場合は、HCX によってクラウドに拡張 (ストレッチ) した任意のネットワークに物理サーバーを配置するのかどうかを知っておくことが重要です。 このシナリオでは、HCX によって VM だけでなくサブネット全体をクラウドにマイグレーションできます。

マイグレーションの終了時に HCX を除去した後に、物理デバイスとマイグレーション済み VM との間の接続を維持する場合は、 そのサブネットをソースと宛先の両方に配置することはできません。 そのため、ストレッチ L2 ネットワークに存在する物理デバイスをソース・サイトに残したままにする場合は、クラウド・サイドへのルーティングが可能な別のネットワーク・サブネットにその物理デバイスをマイグレーションする必要があります。 唯一の例外は、 他のストレッチ L2 テクノロジー (NSX L2 VPN など) を採用して HCX ストレッチ L2 エンドポイントを置き換える場合です。

実稼働アプリケーションや複雑なアプリケーションのマイグレーション

共有マルチライター VMDK (Oracle RAC や MS Exchange/SQL クラスター) を使用する VM や、 ロー・デバイス・マッピングを使用する VM などの場合は、マイグレーションの前に付加的な考慮事項について検討する必要があります。

ネットワーク・スイング

ネットワーク・スイングは、ソース・サイド・ネットワークでの VM の移動が完了して、クラウド・サイドでのネットワーク設計および実装が完了した後に実施します。 移行の波の中で完了した VM に関連するネットワークのストレッチを解除するように HCX を構成すると、移行した VM がクラウド側の NSX インフラストラクチャを使用してネットワーク トラフィックをルーティングできるようになります。

サポート対象のクライアント・プラットフォーム

ネットワーク拡張の場合は、vSphere 仮想分散スイッチ (vDS) を使用するポート・グループだけがサポートされています。 これは、ESXi ホストが vCenter Server によって管理されている場合、 vDS のみが可能であるため、スタンドアロン ESXi ホストがサポートされていないことを意味します。

サポート対象のクラウド・プラットフォーム

HCX クラウド・サイドは IBM Cloud の自動処理によってプロビジョンされます。

接続オプション

関連リンク

• HCX のコンポーネントと用語集
• HCX オンプレミスのサービス・メッシュ
• VMware Hybrid Cloud のマイグレーション
• パラメーターとコンポーネントのモニター
• HCX のトラブルシューティング