03-5946-8400
HOME
目次
自社のVMware環境移行先として、Oracle Cloud VMware Solutionは適しているのか？
Broadcom によるライセンス体系の変更を受け、 VMware 環境のクラウド移行を検討する企業が増えています。
有力な移行先の一つとして Oracle Cloud VMware Solution （以下、 OCVS ）が注目を集めていますが、「自社に適しているか判断できない」「移行リスクが不安」といった声も少なくありません。
本記事では、 OCVS の基礎から、 VMC on AWS ・ GCVE ・ AVS など他クラウド VMware サービスとの比較、向き不向きのケース、移行や運用時の検討ポイントまでを解説します。
1. OCVSとは
OCVS （ Oracle Cloud VMware Solution ） とは、 Oracle Cloud Infrastructure （以下、 OCI ）上で VMware 仮想化環境をそのまま稼働させられるクラウドサービスです。オンプレミスの VMware ワークロードを、運用プロセスやツールをほぼ変えずにクラウドへ移行でき、既存の VMware 管理スキルをそのまま活用できる強みがあります。
OCVSの構成
OCVS はベアメタルサーバーを専有する形で提供され、ホスト単位の課金体系を採用しています。本番構成は最小 3 ノードから最大 64 ノードに対応し、非本番用途向けに 1 ノード構成も選択可能です。
OCVSの利用料金
従来のライセンス込み料金は廃止され、 2026 年 5 月 21 日以降は BYOL （ Bring Your Own License ）モデルが導入されています。契約形態は時間単位、月単位、1年、3年から選択でき、クラスタ内での混在も可能です。
※参考：OCVS BYOL移行の主要日程
※参考：クラウドの価格表 | オラクル | Oracle 日本
2. OCVSがVMware環境の選択肢として注目される理由
OCVS は既存の VMware 環境を維持しながら、顧客主導で管理できるクラウドサービスとして評価されています。選ばれる主な理由を4つの視点から解説します。
1. 完全な制御権
すべての VMware コンポーネント（ ESXi ・ vCenter ・ NSX ）に admin/root 権限が付与され、バージョンアップやパッチ適用のタイミングを自社主導で決定できます。
他社のマネージド型サービスとは異なり、事業者の都合で VMware ソフトウェア層が自動更新されるリスクがありません。 NSX のフル管理権限により、マイクロセグメンテーションや複雑なルーティング設計もオンプレミスと同じロジックで構築可能です。
2. OCIネイティブサービスとの接続性
OCVS は、顧客自身の OCI テナント内に直接 SDDC （ Software-Defined Data Center ）が展開される設計です。そのため、 AI やデータ分析、 Autonomous Database といった OCI ネイティブサービスと、同一 VCN （仮想クラウド・ネットワーク） 内で低遅延に通信できます。他社クラウドで必要となるテナント間接続が、 OCVS では不要です。
3. スケーラビリティ
OCI コンソールからの操作により、約 1 時間で ESXi ノードを追加・削除できるため、急なワークロードの増加へ即座に対応できます。
最小 3 ノードからスタートし、最大 64 ノード構成時には 8,192 コア、 131TB メモリ、 3.48PB ストレージまでスケールアウトが可能で、中堅規模から大規模環境まで幅広くカバーします。
4. 高可用性
最低 3 台のベアメタルサーバーを ESXi ホストとして構成し、各ホストを OCI の異なる障害ゾーン（フォルト・ドメイン）に分散配置することで、ハードウェア障害に伴う単一障害点を排除しています。
また、占有型ベアメタルサーバーを使用するため、他ユーザーのワークロードが自環境の性能に悪影響を及ぼすノイジーネイバー問題を物理レベルで回避できる点も大きなメリットです。
3. 類似ソリューションとの比較と選定基準
OCVS の位置づけを明確にするため、他社クラウドが提供する類似ソリューションとの比較をまとめました。
| OCVS | VMC on AWS | GCVE | AVS | |
|---|---|---|---|---|
| サービスの性質 | 非マネージド（専有型） | マネージド | ||
| 機能面 | オンプレミスと同一のフル機能が利用可能 | 一部の vSphere 機能が制限される | ||
| 構成 | Intel/AMD Standard 、 Intel/AMD DenseIO 、 Intel CPU + NVIDIA GPU から選択可能 | Intel 標準のみ | ||
| スケーラビリティ | クラスタあたり最大 64 ノード | クラスタあたり最大 16 ノード | クラスタあたり最大 32 ノード | クラスタあたり最大 16 ノード |
| 運用：基盤管理 | Oracle | AWS | Microsoft | |
| 運用：VMware層管理 | 顧客主導（ root 権限あり） | クラウドプロバイダー主導（ ESXi への root アクセス不可） | ||
| 主な制限 | 最小 3 ノード（ DenseIO シェイプのみ 1 ノード可、ただし非本番向け） | 最小 2 ノード | 最小 3 ノード | |
※ VMC on AWS は 2024 年 5 月以降、 AWS による新規販売を終了しています。既存利用は可能ですが新規移行先には選択できません。
OCVS と他 3 社の決定的な違いは「管理モデルの思想」にあります。他社サービスは VMware 層をクラウドプロバイダーが管理するマネージド型ですが、 OCVS は顧客自身が管理する非マネージド型です。事業者の都合でバージョンが自動更新されない安定性は、確実な稼働が求められる基幹業務システムにおいて不可欠な要件となります。
4. OCVSはどんなケースに適しているのか
さまざまな利点を持つ OCVS ですが、決して万能ではありません。ここでは、 OCVS の向き不向きを解説します。
向いているケース
レガシー OS や古いミドルウェアを抱えたワークロードの移行先として適しています。 OCVS は ESXi のバージョン固定が可能なため、他社サービスで発生しがちな強制アップグレードに伴うシステム停止リスクを回避できます。
また、 ESXi への root 権限が必要な既存運用ツール（監視・バックアップ・セキュリティエージェント）を継続利用したい場合にも有効です。 OCVS はすべての VMware コンポーネントに root 権限が付与されるため、他社マネージド型では稼働しないツールもそのまま利用できます。
よくあるユースケース
OCVS の特性を活かした、 3 つの代表的な活用パターンを紹介します。
オンプレミスからクラウドへの移行
VMware HCX （以下、 HCX ）による無停止ライブ移行（ IP アドレス変更不要）と、 ESXi バージョンをオンプレミス側に合わせる機能により、古い OS やミドルウェアを改修なしでリフト＆シフト移行できます。
ハイブリッドクラウド化
FastConnect や VPN でオンプレミスと OCI を接続し、 OCVS と OCI ネイティブサービスを同一 VCN 内で連携させます。既存ワークロードを維持しつつ、新規開発分にのみ OCI マネージドサービスを活用する「いいとこ取り」の構成が可能です。
ディザスタ・リカバリ
平時は最小構成で待機させ、有事の際のみノードを追加するコスト効率の高い運用が可能です。オンプレミス側の Site Recovery Manager と vSphere Replication をそのまま OCVS 側でも利用できるため、切り替え手順が共通化されます。
向かないケース
一方で、 OCVS が適さないケースもあります。仮想マシンが数台から十数台程度の小規模環境では、最小 3 ノード構成のコストが割高になるため、 OCI コンピュートインスタンスへの移行が適切です。
また、インフラ管理を完全にアウトソースしたい場合にも向きません。 OCVS は ESXi のパッチ適用やバージョン管理を自社で行う必要があるため、運用負荷をなくしたいなら AVS などのマネージド型サービスが合致します。
オートスケーリングやフルマネージドバックアップなど、クラウド固有の機能を最大限に活用したい場合も OCVS は最適とはいえません。 VMware スタックを維持しない OCI ネイティブへのリファクタリングを検討すべきです。
5. OCVSへ移行・運用する際の課題と検討ポイント
OCVS への移行では、以下の検討ポイントを事前に整理し、移行後の運用を含めた総合的な計画を立てることが必要です。
スペック：パフォーマンスとコストのバランス
OCVS はベアメタルサーバーを専有するため、通常の仮想マシンのようにあとから vCPU や vRAM などのリソースを微調整できません。シェイプ（ Standard ／ DenseIO ）の選定が、パフォーマンスとコストのベースラインを決定します。
特にメモリはオーバーコミットが困難なため、現行環境の実使用量を正確に把握し、余裕を持たせた設計が求められます。
ネットワーク：帯域不足と遅延が与える影響
HCX による仮想マシンのレプリケーションデータが FastConnect の帯域を圧迫し、移行中の現行業務に通信遅延などの影響を及ぼすリスクがあります。また、物理距離による通信遅延をアプリケーションが許容できるかどうかは、移行前のPoCによる検証が必要です。
移行方式：業務継続性維持に潜むリスク
許容停止時間とネットワークリソースのトレードオフを考慮しなければなりません。停止時間は発生するものの、大量の仮想マシンを一括移行できる Bulk Migration を基本とし、無停止が必要なシステムにのみ Replication Assisted vMotion を適用するといった移行計画が推奨されます。
まずは低リスク・低重要度の仮想マシンを先行移行し、 HCX の挙動や帯域への影響を検証したうえで、高リスク・高重要度なシステムへ移行する段階的アプローチが望ましいです。
バージョンと互換性：最新が正解とは限らない
OCVS が提供する ESXi のバージョンとオンプレミス側のバージョンとの互換性、 HCX による移行可否、既存バックアップや監視ツールの対応状況を事前に確認する必要があります。
旧バージョンにはサポート終了のリスクがあるため、移行を機にモダンなバージョンへ統合するのが一般的ですが、既存のレガシーアプリケーションとの互換性検証は不可欠です。
バックアップ・リカバリ：オンプレミスと同じ手法が通用しないリスク
OCI Object Storage への書き込み速度は一般に LAN 内よりも遅いため、オンプレミスと同様のバックアップでは時間内に完了しないリスクがあります。
また、 OCI は OCVS 上の仮想マシン専用バックアップサービスを提供していないため、サードパーティ製ツールの利用が必須です。バックアップデータの保存先としては、 OCI Object Storage や File Storage を活用できます。
運用体制：VMware管理者からの脱皮
クラウドへの移行後は、物理障害（ Oracle 責任）と論理障害（顧客責任）の切り分けフローを確立し、 OCI コンソールの操作やサポート問い合わせ手順をチーム全員が習得する必要があります。既存の VMware 管理スキルに加え、OCIコンソール操作・IAM（権限管理）・ネットワーク設定といった OCI ネイティブの基礎知識習得が不可欠です。
運用コスト：クラウド化すれば運用コストは下がるという誤解
OCVS は非マネージドサービスであり、 ESXi のパッチ適用やバージョン管理などはすべて顧客責任となります。そのため、「クラウド移行＝運用負荷削減」と捉えたまま導入すると、移行後に大きなギャップが生じかねません。
また、他社クラウドと比較して安価だとしても、データ転送料はオンプレミスには存在しなかった新たなコスト項目であり、事前に正確な見積もりが必要です。
こうした新たなコスト項目も含め、「コストは下がる」という思い込みを排除し、ステークホルダーと事前にすり合わせを進める姿勢がプロジェクト成功の前提条件となります。
6. まとめ
OCVS は、既存 VMware 環境を維持しつつ顧客主導で管理できるため、VMware資産を活かしたい中堅・大規模企業にとって有力な移行先です。ただし、自社における向き不向きの客観的な判断や、移行・運用時のリスクを正しく把握することが重要です。
自社対応の可否は、 VMware と OCI 双方の運用経験、 HCX 移行の実行経験、そして移行規模の 3 軸で判断できます。 OCI の運用が未経験のケースや、移行規模が大きくネットワーク、バックアップ、 DR 設計の見直しを伴う場合は、専門の外部パートナーへの相談が合理的です。
Rworks では、 VMware 環境からの移行サービスを提供しており、移行先環境がオンプレミス・クラウドに関わらず、お客様の環境に適した構成設計から構築・運用までを一貫してサポートできます。OCVS への移行をご検討中の方も、ぜひお気軽に Rworks へご相談ください。
Tag： OCVS
Contactお問い合わせ
お見積もり・ご相談など、お気軽にお問い合わせください。