
- Oracle Cloud
- Exadata
- Oracle Database
データ圧縮だけじゃない!HCCがOracle Exadata ExascaleにもたらすI/O削減とコストメリット
本記事でもExaDB-XSを利用するメリットをご紹介します。今回はデータベースのストレージ領域およびI/O削減効果のあるHybrid Columnar Compression(以下、HCC)に焦点を当て、オンプレミスと比較した際のコスト優位性をご紹介します。
|
前回の記事 で、VMware HCX(以下、HCX)の環境構築手順をお伝えしました。
今回はHCXを活用してオンプレミス環境にある仮想マシンをOracle Cloud VMware Solution(以下、OCVS)環境へスムーズに移行する方法を、操作画面を交えながらステップバイステップでご紹介します。
この記事を読むことで仮想マシンの具体的な移行作業がイメージでき、クラウド移行をより身近に感じていただけるでしょう。
Index
HCXを使った仮想マシンの移行方法は4つあります。
移行方法 | 特徴 | 仮想マシン停止 | 利点 | 適用例 |
---|---|---|---|---|
HCX Cold Migration | 停止している仮想マシンを構成ごとコピーして移行する | あり | 最もシンプルで安全に移行可能 | 停止が許容されるシステム |
HCX vMotion Migration | vMotion機能で仮想マシンを起動したまま移行する | なし | オンラインで移行可能 | 台数が少なく停止が許容されないシステム |
HCX Bulk Migration | vSphere Replication機能で仮想マシンのデータを移行先にコピーしておき、移行実行時に移行元仮想マシンを停止して最終同期を行い切り替える | あり | 最大100台の仮想マシンを同時並行で移行可能 | 台数が多く短時間の停止が許容されるシステム |
HCX Replication Assisted vMotion Migration | vSphere Replication機能で仮想マシンのデータを移行先にコピーしておき、vMotion機能で仮想マシンを起動したまま移行する ※HCX Enterpriseライセンスが必要 |
なし | ・大規模移行に対応 ・仮想マシンを無停止で移行可能 |
台数が多く停止が許容されないシステム |
上記のとおり各移行方法にはそれぞれ特徴があります。そのため、システムの稼働状況や停止可否、ライセンスなどの要件に応じて最適な移行方法を選択することが重要です。
ここからはそれぞれの移行方法の具体的な手順を紹介していきます。
今回は、移行用の仮想マシン4台(HCXtest01~HCXtest04)を事前に用意し、それぞれを使って移行作業を行います。
最初にご紹介する移行方法は、パワーオフ状態の仮想マシンを移行するHCX Cold Migrationです。
移行対象の仮想マシンがパワーオフ状態になっていることを、あらかじめ確認しておきます。
移行元環境のvSphere Clientで左上のハンバーガーメニューからHCXプラグインのUIにアクセスします。
[Services]-[Migration]と画面遷移し、"NEW MOBILITY GROUP"を押下します。
移行元の仮想マシン一覧が表示されるので、移行する仮想マシンにチェックを入れて"SELECT"を押下します。
今回は仮想マシンHCXtest01を使用します。
"Group Name"に任意の名前を入力し、"Transfer and Placement"の各項目を選択します。
主な設定項目は以下のとおりです。
Compute Container:移行先のリソースプールやESXiホストを選択
Storage:移行先のデータストアを選択
Migration Profile:Cold Migrationを選択
Destination Folder:移行先の仮想マシンフォルダを選択
選択が終了したら"VALIDATE"で正しく移行できるかを確認します。
よくある"VALIDATE"の失敗例として、ISOイメージが仮想マシンにマウントされている場合があります。その場合はISOイメージをアンマウントしてから作業を行うようにします。
しかし、アンマウントしても下の画面のようなエラーが出続けるケースもあります。
その場合は、画面下部にある仮想マシン名のプルダウンマークを展開して"Force unmount ISO images false"のチェックを入れてください。
"VALIDATE"が成功したら"GO"を押下します。
移行タスクが始まります。
しばらくすると移行タスクが完了し、仮想マシンが移行先環境に移動します。
移行先環境のvSphere Clinetで仮想マシンが移行したことを確認します。
次にご紹介する移行方法は、パワーオン状態の仮想マシンを停止させずに移行できるHCX vMotion Migrationです。
移行対象の仮想マシンがパワーオン状態であること、またネットワークがL2延伸されていることを確認しておきます。
基本的な手順はHCX Cold Migrationと同様ですが、以下画面の"Migration Profile"で"vMotion"を選択するとHCX vMotion Migrationが行われます。
今回は仮想マシンHCXtest02を使用します。
"Transfer and Placement"の各項目を選択したら"VALIDATE"で確認し、"GO"を押下します。
移行タスクが完了したら移行先環境に仮想マシンが移動していることを確認します。
移行中のpingの様子を確認してみます。
L2延伸しているのでHCXtest02のIPはそのままになります。
下の画像は、移行元環境にある仮想マシンHCXtest04からpingを送っている様子です。
移行中一時的に応答時間が長くなっていますが、途切れてはいません。
続いて、複数の仮想マシンをまとめてスケジュール移行できるHCX Bulk Migrationをご紹介します。
移行する仮想マシンは一時的に停止されるため、短時間の停止が許容されるシステムを対象とした移行方法です。
手順はこれまでと同様ですが、以下画面の"Migration Profile"で"Bulk Migration"を選択します。
今回は仮想マシンHCXtest03を使用します。
移行タスクが完了したら移行先環境に仮想マシンが移動していることを確認します。
以下の画面は、移行元環境の仮想マシンHCXtest04からのpingを送っている様子です。移行の過程で仮想マシンが停止するのでpingの応答は途切れます。
移行が完了すると再びpingの応答があることがわかります。
最後に、ディスクを事前に同期しvMotion機能で移行するHCX Replication Assisted vMotion Migrationをご紹介します。
移行する仮想マシンがパワーオン状態であり、停止できないシステムを対象とします。HCX Enterpriseライセンスが必要になる点に注意が必要です。
こちらも手順はこれまでと同様で、以下画面の"Migration Profile"で"Replication Assisted vMotion"を選択します。
今回は仮想マシンHCXtest04を使います。
移行タスクが完了したら移行先環境に仮想マシンが移動していることを確認します。
先に移行していた仮想マシンHCXtest02からpingを送っていましたが、途切れてはいません。
移行後は同一リージョンになるため、応答時間が短くなっています。
今回はHCXでの4つの移行手順をご紹介しました。
操作方法はシンプルで、移行作業も容易であることがお分かりいただけたかと思います。
次回はOCVS環境・オンプレミス環境間の仮想マシンの通信において重要なMONの設定手順を記載予定です。
どうぞお楽しみに!
■本記事の内容について
本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
本記事でもExaDB-XSを利用するメリットをご紹介します。今回はデータベースのストレージ領域およびI/O削減効果のあるHybrid Columnar Compression(以下、HCC)に焦点を当て、オンプレミスと比較した際のコスト優位性をご紹介します。
Exascaleがついに登場!Exadata Exascaleと標準的なPaaSサービスであるOracle Base Database Serviceをコストで比較するのに加え、簡易的なパフォーマンス比較もしながら、Exadata Exascaleの優位性を明らかにしていきます。
前回の記事でOCVS)でHCXを利用するための前提となる手順の前半をお伝えしました。本記事では後続の手順であるサービスメッシュ作成・L2延伸手順を記載し、仮想マシンを移行できる状態、つまりHCX環境の構築完了までを説明します。