この記事はリクルート ICT統括室 Advent Calendar 2023 25日目の記事です。

概要

初めまして、ICT統括室の原口です。
本記事では、私のチームが管理運用するオンプレかつVMware/vSphereで仮想化されたシステムを、Oracle社が提供するVMwareCloudソリューションである、OCVS（Oracle Cloud VMware Solution）へ移行した際にハマったポイントをご紹介します。

経緯

オンプレかつVMware/vSphereで仮想化されたシステムを維持管理しているなかで、急なスケールアウトができない、利用数が縮小されても保守満了や減価償却終了までは物理サーバーを処分できない、今から新基盤をつくる大きな初期投資をしたくない、などの課題がありました。

そんななか、2024年10月にオンプレ環境のHWの保守契約満了（EOSL）を控えており、上記課題の改善や、運用コストの軽減、より仮想マシンの需要増減に柔軟に対応できる基盤として、VMware Cloudクラウドソリューションへの移行を検討しました。検討の結果、Oracle社が提供するVMwareCloudであるOCVS（Oracle Cloud VMware Solution）へ移行することになりました。

OCVSとは

ハマったことの紹介の前にそもそもOCVSとはなにかを簡単に紹介させていただくと、
OCVSはVMware vSphere、VMware NSX、VMware vSAN、VMware HCXといったVMware Software Defined Data Center（SDDC）環境を構成するサービス群を、Oracle社が提供するOracle Cloud Infrastructure（OCI）上に構築するクラウドサービスです 。

ユーザーは従来のオンプレミス環境と同様にVMware/vSphere環境を利用でき、かつクラウドならではのメリットであるインフラ管理・運用コストの削減や、柔軟なスケーリングも実現することが可能です。
将来的にはネイティブクラウドサービスに移行したいが、
・すぐに移行するのは色々手間だな
・いったんそっくりそのままVMware/vSphere環境をクラウドに持って行けないかな

と考える方には向いているサービスといえます。

OCVS構築/移行時の課題やハマったところ

ここからは実際にOCVSを構築した際と、構築したOCVSへオンプレ環境から仮想マシンを移行した際に出た課題や、ハマったポイントについて紹介します。

OCVS構築時の課題

オンプレからOCVSへの移行について仮想マシン利用者へ告知した際、以下のような要望が多く寄せられました。
・アプリケーションを止めたくないので、なるべく仮想マシンを停止せずOCVSへ移行したい
・負荷分散装置の移行が大変なのでIPアドレスは変えたくない
・ソフトウェアライセンスに関連するため、MACアドレスを変えたくない

それらの課題を解決するうえで、VMware HCXの機能が有効であることがわかりました。

VMware HCXとは

オンプレ環境からクラウド環境に仮想マシンを移行することができるツールのことで、オンプレ環境で構成しているネットワークセグメントをOCVS環境に展開する機能（L2延伸）なども備えており、オンプレ環境で利用していたIPアドレスやMACアドレスをそのまま利用することが可能になります。

L2延伸に伴うトロンボーン現象への対策

L2延伸ではオンプレ環境と同一のネットワークセグメントをクラウド側に伸ばしているため、ネットワークのDefault Gatewayはオンプレ環境のままになります。このままではOCVS内の通信にも関わらず、一度オンプレ環境のDefault Gatewayを通過してしまいます。この現象をトロンボーン現象とよび、我々が構築した環境でも発生してしまいました。

＜対策＞
このトロンボーン現象については、VMware HCXが提供するMobility Optimization Networking（MON）機能で回避できることがわかりました。
本機能を有効化することで、HCXでL2延伸したネットワークにおいてOCVS側のGatewayにパケットを送信できるようになり、結果トロンボーン現象を回避することができました。

iSCSI接続でマウントしているストレージ領域の対応

OCVSに移行できるのはあくまでvSphereにより仮想化されている範囲になりますので、オンプレ基盤で物理的なハードウェアの機能を直接使っているような場合はvSphereによる仮想化が行われていないため、そのままの状態ではOCVSへ移行することはできません。
我々のチームが管理するオンプレ環境では、GuestOSから直接iSCSI形式でストレージ装置をマウントする仮想マシンが存在し、該当する仮想マシンをOCVSへ移行する場合、事前にvSphereによって仮想化されたvmdk形式などのディスクに付け替える必要がありました。

＜対策＞
該当の仮想マシンへvmdk形式のディスクを別途割り当て、iSCSI形式でマウントしているストレージ領域からデータコピーすることで対応しました。

OCVS移行時の課題

AD参加サーバへのログインが遅い

OCVS環境が整い、HCXによる仮想マシンのテスト移行を実施したところ、移行処理にかかる時間は期待した性能値の範囲で完了したものの、いざ移行した仮想マシンへドメインユーザでRDP接続するとログイン処理で７分近く待たされる事象が発生してしまいました。
AD構成で仮想マシンを利用しているユーザも多く、7分のログイン処理は業務上許容できる範囲ではないため急ぎ調査を行いました。

＜調査＞
Windows OS周りのログ解析などを行うも調査が難航したため、通信時のパケットキャプチャ解析による調査をすすめました。
パケットキャプチャの内容から、物理機器やVMwareの仮想スイッチ、仮想マシンOSなど、L2延伸したセグメントの経路上にMTU※が1500までとなっている機器や設定があるが、L2延伸での通信時にパケットが再カプセル化される（パケットにヘッダー情報が付与される）ことで、エンドノードの仮想マシンへ到達するまでにパケットの細分化（フラグメント）を起こし、通信速度の劣化が発生しているのでは、と推測しました。
※Maximum Transmission Unit：一度の通信で転送可能なデータの最大値。

＜対策＞
HCXのパラメーターに、L2延伸経路上のMTU値を指定できる設定があることがわかり、MTU値をフラグメントが発生しない程度まで調整することで、ログイン処理が遅延する事象が解消されたことを確認しました。

MTU調整時の苦労話

HCXには各機能毎にMTU値を設定する箇所が存在し、どの設定値をどういった値にすると最適なのかは一か所ずつ変更しては確認、とチューニングに近い調査になってしまいました。
また上記MTU値の調整中、設定箇所やドメインユーザでログインができるMTU値を特定することができたものの、次は仮想マシンの移行性能が極端に遅くなる（移行性能が1/10程度まで落ち、オンプレ環境のEOSLまでに全仮想マシンの移行が完了できないレベルまで性能が悪化）など、MTU値の調整にはかなり苦戦しました。

■性能低下時の利用帯域

そしてさらに、HCＸの「TCP Flow Conditioning（MTU値に基づいてMSS値※を自動調整することでフラグメントを軽減する機能）」の有効化でも通信性能が変わることがわかり、最終的にはHCXの一部（仮想マシンと通信する際に利用するインターフェース）のMTU値を「1500」に調整し、あわせてTCP Flow Conditioningを有効化することで、ドメインユーザでのログイン遅延を解消しつつ移行性能も担保できるようになったことが確認できました。
※Maximum Segment size：TCPにおける1セグメントで転送可能なデータの最大長。MTUからTCP/IPヘッダサイズを引いた値

■最終調整後の利用帯域

今後の課題

L2延伸の解除

L2延伸は上記のようにオンプレ環境のネットワークありきのアーキテクチャなので、せっかくクラウド移行したのにオンプレ環境を残したままの構成を続ける事になってしまいます。
オンプレ環境から全ての仮想マシンが移行完了した後はL2延伸を解除する必要がありますが、解除する際は、L2延伸した対象のセグメントをクラウド側のみにする構成について検討する必要があり、対応方針について継続して検討中です。

得られた成果

・実際に利用者の仮想マシンを移行する状態まで整えるまでに、MTUの調整など色々とハマってしまいましたが、そのかいあってログイン遅延の課題も解決しつつ移行性能は数TBの仮想マシンでもわずか数時間で移行が完了する速度を担保できました。（1.0Gbps以上の移行性能が担保できればオンプレのEOSL期限までに移行対象の全仮想マシンを移行できる試算）

・オンプレ環境でVMware/vSphereを稼働させるESXiホストやストレージの増設を対応する場合、物理筐体の購入からデータセンター敷設といったサプライチェーンのリードタイムや、各種ミドルウェア設定など数日レベルの作業となりますが、OCVSではOCIのコンソール上でわずか数クリックで利用が可能になりました（その他各種設定はあるが1日で完結する）。
また構築検証時、増やしたホストやストレージの減設についてもテストしてみたところ、増設と同じぐらい簡単に減設できたため、筐体障害発生時や急なスケールアウトが必要な際や、仮想マシン利用者が縮退した際のスケールインのリードタイムを大幅に短縮できたと考えます。

さいごに

今回はオンプレ環境のVMware/vSphereをOCVSに移行した際にハマったポイントについてご紹介させていただきました。
まだ移行フェーズ真っ只中なので、また移行中のハマりどころなど新たな観点があればアップデートしたいと思います。
同様にオンプレかつVMware/vSphereで仮想化された環境をOCVSへ移行検討されている方の一助となれば幸いです。

リクルート ICT統括室 Advent Calendar 2023では、リクルートの社内ICTに関する記事を投稿しています。もし興味があれば、ぜひ他の記事もあわせてご参照ください。