▼はじめに
前回、どうする、仮想化基盤？ Vol.3で日本オラクルが提供するOracle Cloud VMware Solutionに移行する際の検討ポイント Part１についてご紹介させていただきました。
本どうする、仮想化基盤？Vol.4ではOCVSに移行する際に必要となる検討項目のうちサイジングと移行方式について解説させていただきます。
この記事を通してOCVSの導入における検討方法について理解を深めていただき、クラウド移行に向けた最適な選択肢を見つけていただくことを目的としています。
本記事の内容は大きく３セクションとなっています。
▼EXSiサイジングのポイント
▼L2延伸
▼仮想マシンOSサポート状況の調査・検討
▼ESXiサイジングのポイント
Oracle Cloud VMware Solution（OCVS）の導入に際して、ここではOCVSの概算見積もりを算出する際の目安となるサイジング手法にあたって考慮すべきCPUリソースや現行リソースの分析ポイントについて解説します。
① OCVS利用にあたり最低限必要なCPUリソース
OCVSの利用には、vCenterやNSX Managerなどの管理リソースを含む必要なCPUリソースを確保することが必要です。これらの管理リソースは合計で49仮想コアのリソースを確保する必要があります。
管理リソースの考慮を怠ると、仮想マシンのパフォーマンスに影響を及ぼす可能性があるため、あらかじめリソース計画に組み込むことが求められます。
② 現行リソースの分析
OCVSに適したサイジングを行うためには、まず現行環境のリソースを分析することが重要です。以下の観点でリソースを評価し、OCVSでの最適な設定を行います。
・割り当て仮想CPU数
現行の仮想マシンに割り当てられているCPU数を確認します。
その際、CPU利用率とピーク時のCPU利用率を把握するようにしてください。サイジングやオーバコミット率の算出のINPUTとなります。
・割り当てメモリ
メモリはオーバーコミットができないため、実際のワークロードに対して十分なメモリを確保する必要があります。現行環境でのメモリ使用量を把握し、追加のリソースが必要かどうかを判断します。
・割り当てストレージサイズ
各仮想マシンに割り当てられているストレージ容量を確認します。OCVSでは、仮想ディスクのストレージリソースもオーバーコミットできないため、必要なサイズを正確に見積もることが求められます。
・ストレージのIOPS
ストレージパフォーマンスは仮想マシンの応答性に影響するため、要件を明確にします。
高いIOPSが求められる場合、NVMe SSDの利用が可能で、ストレージのパフォーマンスを向上させることができます。
・バックアップの保管世代
バックアップの保持ポリシーに基づき、バックアップの世代数を決定します。OCVSでは、バックアップデータもストレージリソースを消費するため、保管世代の見積もりがサイジングに影響します。
・オーバーコミット
前述の通りOCVSでは、CPUリソースのオーバーコミットが可能ですが、メモリとストレージについてはオーバーコミットできません。このため、CPUリソース以外は現行のワークロードに応じた正確な見積もりが必要です。
③その他サイジングに係る考慮軸
・クラスタの検討
移行元環境でクラスタが分割されている場合は、OCVS移行後にクラスタ分割を踏襲するか、統合するか方針を決める必要があります。
クラスタを統合するほうがリソース集約率があがるためコスト面でメリットがでることが多いですが、SWライセンスなどの制約上、分割用要件がある場合はそれぞれ用途ごとにクラスタを分割しサイジングを行う必要があります。
・オーバコミット率の検討
オーバコミット率の要件がある場合は、要件を踏襲するか改めてリソース集約の観点で計算し直して新しい集約率でサイジングを行います。
・縮退運用時の可溶性構成の検討
VMWare HAの観点でクラスタのノードが故障した場合のリソース利用率について検討する必要があります。
基本的にはノードが1台故障した場合でも安定稼働が継続できるようサイジング結果＋1台（３台の場合は4台構成）とするようサイジングを行います。
・CPUアーキテクチャの検討
OCVSでは選択するベアメタルシェイプによってノードごとに割り当てられるOCPU・メモリ・ストレージ容量に選択肢があります。
・Standardシェイプ（Intelアーキテクチャ）の場合のCPU観点
最小構成の場合は
Standard Shape Intel X9 16OPUの３ノード構成を選択します。
その場合の物理コアと仮想コア数は以下の通りです。
16 x 3 = 48 物理コア
16 x 3 x 2 = 96仮想コア
そのためオーバコミット率100%（オーバコミット無し）の場合は96仮想コアというサイジングがIntel アーキテクチャの最小構成となります。
オーバーコミット200%を許容する場合は、192仮想コア（96 x 200%）利用可能となります。
オーバコミット率はCPU利用率に基づいて計算します。
現状のCPU利用率・最大CPU使用率の方針（例：80％以下）を満たすよう計算します。
・メモリ観点
1ノードあたり、1,024GBのメモリが割り当てあられます。
3ノード利用する場合は
1,024 GB x 3 = 3,072GB
となりますので、3,072GB利用可能となります。
メモリはオーバコミットできませんので、現状の割り当てメモリが上記に収容可能であるかどうか、と言う観点でサイジングを検討します。
・ストレージ観点
Standardシェイプの場合はストレージはVMFSでブロックボリュームを利用します。
必要なブロックボリュームを算出してそれぞれのデータストアとして利用します。
OCVSでは、ストレージ容量の利用率は80%以下とする必要があります。
また、OCVS管理のために8TBの領域が別途必要となります。
たとえば、10,000GBのデータを移行する場合、12,000GBを準備し、さらに8TBを追加で確保することが必要です。
具体的には、10,000 / 0.8 = 12,500GB、そして管理領域として8,356GB（8,192GB + 164GB）を追加する必要があります。
そのため10TBのデータ容量を移行する際に必要となるストレージサイズは20,856GBの容量が必要となる試算となります。
尚、DenseIOシェイプの場合は内臓のNVMeSSDをvSANとして利用が可能です。
割り当てられているNVMeSSDの範疇に収まるようサイジングを考慮してください。
DenseIOシェイプの場合もブロックボリュームをVMFSとして利用することが可能となりますので、内臓ディスクだけでは容量が不足する場合は、VMFSの利用を検討する必要があります。
・注意事項
本資料で提示する構成は、移行先 OCVSの概算算出を目的とした、机上による簡易的なサイジングからの想定であり、データベースの性能を保証するものではありません。
実際の厳密なサイジングにつきましては、実機での検証により決定していただ句必要がある旨注意が必要です。
▼L2延伸＆仮想マシン移行方式
OCVSへの移行やクラウドとのハイブリッド環境を構築する際、L2延伸（Layer 2 Extension）は、オンプレミスとクラウド環境を同一ネットワークセグメントで接続し、仮想マシンのシームレスな移行を実現するために非常に重要です。また、IPアドレスを変更したくない・影響が大きいと言った場合にも有用な機能となります。
L2延伸を行うには、利用する環境や目的に応じて以下の3つの方式があります。
トロンボーン現象を回避するためにはHCXのL2延伸を選択する必要がありますが、求められる前提条件や制約事項があるため要件に応じて方式を選択する必要があります。
① VMware NSX-T を使ったオーバーレイレイヤー 2 延伸
この方式は、オンプレミスとクラウド環境の両方でNSX-Tを利用している場合に適しています。NSX-Tを使用し、オンプレミスとクラウドの間でオーバーレイネットワークを形成します。
② HCX を利用したレイヤー 2 延伸
VMware HCXを利用したL2延伸は、オンプレミス環境からクラウドへの仮想マシン移行を行う場合に適しています。HCXは、仮想マシンの大量移行や、オンプレミスとクラウドのハイブリッド構成における相互運用性を重視した機能を提供します。
③ 仮想アプライアンスを介したレイヤー 2 VPN
仮想アプライアンスによるL2 VPNは、NSXやHCXの新規ライセンスを購入することなく、比較的簡単にL2延伸を行いたい場合に適しています。たとえば、NSX Autonomous Edgeなどの仮想アプライアンスを使用して、オンプレミスとクラウドの間でL2 VPNを構成します。
●トロンボーントラフィックについて
トロンボーントラフィックとは、ネットワークパケットが一度遠回り（トロンボーンのような形）してから目的地に到達する状況を指します。この現象は、特にハイブリッドクラウド環境やレイヤー2延伸を行う際に起こりやすく、効率の悪いトラフィックフローが発生する原因となります。
具体的には、例えばオンプレミスのネットワークとクラウドネットワークがレイヤー2で延伸されている場合、本来ならクラウド内で完結するトラフィックが、オンプレミスに戻ってから再びクラウド側に転送されるという無駄な経路を取ることがあります。この結果、ネットワークの帯域幅を余計に消費し、遅延が増加する可能性があります。
トロンボーントラフィックが発生しやすいのは、以下のようなケースです：
オンプレミスとクラウドの双方で同一のネットワークセグメントを延伸しているが、ルーティングが適切に構成されていない場合
HCXなどを利用して、クラウドとオンプレミス間の仮想マシンの移行やハイブリッド構成を構築している場合
アプリケーションがオンプレミスとクラウドの両方に分散して稼働しており、データの往復が多発する場合
トロンボーントラフィックを最小限に抑えるためには、ルーティング制御やネットワーク構成の最適化が重要です。HCXのMobility Optimized Networkingを活用したり、クラウド側にルーティング機能を適切に設定することで、不要なトラフィックの往復を防ぎ、ネットワークパフォーマンスを向上させることができます。
●HCXを利用したL2延伸について
VMware HCXを利用したL2延伸は、オンプレミス環境からクラウド環境への仮想マシン移行や、クラウドとのハイブリッド環境を構築する際に有効です。HCXは、仮想マシンの大量移行や、オンプレミスとクラウドの相互運用性を重視した機能を提供しますが、導入にあたってはいくつかの前提条件をクリアする必要があります。以下に、HCXでL2延伸を行う際の主な前提条件を示します。
・HCX Enterprise Edition
HCXを利用する際は、HCX Enterprise Editionが推奨されます。これは、HCXの機能であるMobility Optimized Networking（MON）を利用するためで、MONはオンプレミスとクラウド間で最適なネットワークパスを提供し、トロンボーントラフィックを軽減する役割を果たします。Enterprise Editionにより、MON機能を活用でき、パフォーマンスが向上します。
・vSphere Distributed Switch（vDS）の必要性
HCXでL2延伸を行うには、**vSphere Distributed Switch（vDS）**が必要です。vDSは、ネットワークの管理と制御を集中的に行うことで、HCXとオンプレミス環境間で安定したネットワーク延伸をサポートします。もしオンプレミス環境がvDSを使用していない場合は、あらかじめ導入を検討する必要があります。
・VMwareサポートバージョンであること
HCXでのL2延伸を行うには、VMwareがサポートするバージョンであることが前提です。HCXは、特定のvSphereバージョンに対応しており、サポート外のバージョンではHCXが動作しない可能性があります。事前にHCXの互換性マトリクスを確認し、対象のバージョンがHCXでサポートされていることを確認してください。
これらの前提条件を満たすことで、HCXを活用した効率的なL2延伸とシームレスな仮想マシン移行が可能になります。
▼仮想マシンの移行方式
Oracle Cloud VMware Solution（OCVS）への移行に際して、仮想マシンをクラウドに移行する方法としては、主に3つの選択肢があります。それぞれの方式には特徴とメリットがあり、移行の要件や既存の環境に応じて最適な手法を選択することが重要です。
1. OVFテンプレートのエクスポート・インポート
最もシンプルな移行方式は、仮想マシンをOVFテンプレートとしてエクスポートし、OCVS環境にインポートする方法です。この手法は、仮想マシンを一時的に停止し、OVFファイルとしてエクスポートし、クラウド上のOCVS環境に再度インポートすることで完了します。
2. VMware Hybrid Cloud Extension (HCX) を利用
OCVSには標準でHCX Advancedライセンスが付属しており、これを利用して仮想マシンをスムーズに移行できます。HCXを利用することで、オンライン移行やバルク移行、Replication Assisted vMotion（RAV）など、多彩な移行オプションが利用可能です。
・HCX vMotionによるオンライン移行
HCX vMotionを利用して仮想マシンをオンラインで移行できます。ただし、同時実行できる移行数には制限があり、大規模な環境では計画的な移行スケジュールが必要です。
・Bulk Migrationによる並列移行
複数の仮想マシンを並列に移行するためのバルク移行は、スケジュール移行も可能ですが、リブートに相当するダウンタイムが発生します。このため、ダウンタイムが許容される範囲で利用すると効果的です。
・Replication Assisted vMotion
RAV機能は、切替のタイミングを自由に設定できる柔軟な移行オプションで、HCX Enterpriseライセンスが必要です。HCX Enterpriseライセンスは、サブスクリプションまたはBYOL（Bring Your Own License）形式で取得可能です。
3. サードパーティーツールを利用
仮想マシンの移行には、Veeam Backup & Replicationなどのサードパーティ製ツールも有効です。これらのツールは、オンプレミスとクラウド間のバックアップおよびリストア機能を提供し、災害対策と併用して移行を行うことが可能です。
▼仮想マシンのOSサポート状況調査
Oracle Cloud VMware Solution（OCVS）への移行に際して、移行先で稼働するオペレーティングシステム（OS）のサポート状況を確認することは重要です。OCVSは、VMwareの**VMware Compatibility Guide（VCG）**に準拠しており、サポートされるOSとバージョンが規定されています。
・移行元ESXiホストのOSバージョン確認
特に、移行元が古いESXiホストで運用されている場合、古いバージョンのOSが仮想マシンで稼働していることがあります。ESXiのバージョンアップに伴い、こうした古いOSはサポート外になる可能性があるため、移行前にサポート状況を調査しておくことが必要です。
・VMware Compatibility Guideの確認
OCVSがサポートするOSは、VMware Compatibility Guideに基づいています。移行前に、このガイドを参照し、移行先のOCVS環境で使用可能なESXiバージョンにおいてサポートされているOSを確認してください。これにより、移行後のOSが正しく動作し、サポートが受けられる状態であることを確認できます。
OCVSでサポートされるOSはVMware Compatibility Guideに従います
https://www.vmware.com/resources/compatibility/search.php
・移行前の準備
移行をスムーズに行うためには、移行元のESXiホスト上で稼働する各仮想マシンのOSバージョンと、OCVSのサポート状況を比較して、適合性を確認します。特に、古いOSの場合、事前にバージョンアップを行っておくことで、移行後の問題を未然に防ぐことができます。
▼まとめ
Oracle Cloud VMware Solution（OCVS）は、オンプレミスのVMware環境をそのままクラウドに移行するための強力なソリューションです。
OCVSへの移行を成功させるためには、リソースのサイジングやネットワークのL2延伸、仮想マシンのOSサポート状況の確認など、移行前にさまざまな検討が必要です。
ESXiホストのサイジングでは、適切なリソースを確保するために、仮想CPUやメモリ、ストレージの要件を慎重に見積もることが重要です。また、L2延伸では、オンプレミスとクラウド間のネットワーク接続を最適化し、スムーズな移行を実現するために、HCXやNSX-T、仮想アプライアンスを活用することで選択肢が広がります。
仮想マシンの移行方法としては、OVFテンプレートのエクスポート・インポートから、HCXによるオンライン移行、さらにはサードパーティ製ツールを利用する方法まで多様なオプションがあり、移行要件に合った手法を選ぶことが重要です。さらに、OSサポート状況の調査では、OCVSが準拠するVMware Compatibility Guideに基づき、移行先での稼働が保証されるOSバージョンを確認し、必要に応じてバージョンアップを検討することで、移行後の問題を未然に防ぎます。
OCVSの導入によって、オンプレミス環境を維持しつつ、クラウドのメリットを活かした柔軟なITインフラを構築することが可能です。各移行ポイントを適切に検討し、クラウド環境での安定した運用を確保することで、ビジネスの成長と競争力の強化を目指しましょう。