Amazon Web Services ブログ

OpenShift Virtualization on Red Hat OpenShift Service on AWS と Amazon FSx for NetApp ONTAP による仮想マシン (VM) のライブマイグレーション

本稿は、2024 年 11 月 18 日に IBM & Red Hat on AWS Blog で公開された “Live Migration of Virtual Machines (VMs) with OpenShift Virtualization on ROSA and Amazon FSx for NetApp ONTAP” を翻訳したものです。

私たちは、既存のパラダイムに挑戦する革新的なテクノロジーに度々直面します。アップストリームの KubeVirt プロジェクトをベースに構築された OpenShift Virtualization は、まさにそのような技術の一つです。

OpenShift Virtualization により、組織は従来の仮想マシン (VM) とコンテナ化されたアプリケーションを統一されたプラットフォーム上で同時に実行できます。これは特に、完全な刷新なしでモダナイゼーションを必要とするレガシーアプリケーションを持つ企業にとって価値があります。Kubernetes をコントロールプレーンとして使用することで、スケーラビリティ、自己修復、一貫した管理といった大きな利点が得られます。すでに OpenShift に投資している組織にとって、この統合は既存のツールとワークフローを活用できるため、運用が簡素化されます。これはまた、クラウドを活用してワークロードを Amazon Web Service (AWS) に移行し、その後クラウド上でビジネスをさらにモダナイズするお客様にとっても魅力的です。OpenShift Virtualization は VM を AWS に移行し、OpenShift と AWS のネイティブサービスを使用して進化させるためのリフト&シフトアプローチを提供します。

OpenShift Virtualization は、追加のライセンスやサブスクリション費用なしで OpenShift に含まれています。AWS では、マネージドOpenShift である Red Hat OpenShift Service on AWS (ROSA) 上で実行でき、VM とコンテナ化されたアプリケーションを管理するためのオーケストレーション機能を活用できます。この統合により、チームは VM とコンテナの両方に対して同じ管理ツールとプラクティスを使用でき、運用の効率化と合理化が図れます。

コンテナオーケストレーターで VM を実行するアプローチは、アプリケーションを展開する際の柔軟性の増大するニーズに対応しています。組織は、別々のインフラストラクチャ環境を管理する必要なく、特定のワークロードの要件に基づいて VM とコンテナの両方を実行できます。

Amazon FSx for NetApp ONTAP は、ONTAP の一般的なデータアクセスと管理機能を備えた、AWS 上のフルマネージドの共有ストレージを提供します。FSx for ONTAP では、顧客アカウント内にストレージコンピュートノードまたは接続ストレージを追加する必要があります。ストレージのスケーリングと回復性は、顧客アカウントにエンドポイントのみが表示されるサービスチームアカウント内で実現されます。これにより、基盤となるインフラコストと、回復性を実現するためのアベイラビリティゾーン(AZ)間のデータ転送コストが削減されます。FSx for ONTAP は、NetApp Trident をストレージオーケストレーターとして使用することで、OpenShift 上で実行されるアプリケーションや VM で利用できます。

ソリューションの概要

以下では、FSx for ONTAP を ROSA クラスターのデフォルト StorageClass として設定し、その後 FSx for ONTAP ストレージをボリュームとして利用するVMを作成する方法について見ていきます。また、ゲスト認証情報を使用して VM に接続する方法と、VM を現在のノードから新しいノードへライブマイグレーションを実行する方法についても説明します。

前提条件:

以下の図は、複数の AZ にデプロイされた ROSA Hosted Control Plane(HCP)クラスターを示しています。ROSA クラスターでは、コントロールプレーン(マスター)ノードはサービスチーム内にあります。一部のワーカーノードは OpenShift Virtualization をサポートするためにメタルインスタンスタイプとなっています。FSx for ONTAP ファイルシステムは同じ VPC 内にデプロイされています。NetApp Trident プロビジョナーは ROSA クラスターにインストールされており、この VPC のすべてのサブネットがファイルシステムに接続できるようになっています。OpenShift Virtualization は、OpenShift OperatorHub からオペレーターを使用してインストールされています。

ROSA FSx アーチ付き

ROSA と FSx for ONTAP のアーキテクチャ

Trident CSI ドライバーのセットアップ

デフォルトの StorageClass が trident-csi に設定されていることを確認してください。

次の yaml ファイルが StorageClass の作成に使用されました。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: trident-csi
provisioner: csi.trident.netapp.io
parameters:
backendType: "ontap-nas"
fsType: "ext4"
allowVolumeExpansion: True
reclaimPolicy: Retain

New OpenShift storage class

新しい OpenShift StorageClass

StorageClassを作成する前に、以下の yaml ファイルがシークレットと ontap-nas ドライバーを使用したバックエンドオブジェクトの作成に使用されました。

apiVersion: v1
kind: Secret
metadata:
name: backend-fsx-ontap-nas-secret
namespace: trident
type: Opaque
stringData:
username: vsadmin
password:

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
name: backend-fsx-ontap-nas
namespace: trident
spec:
version: 1
backendName: fsx-ontap
storageDriverName: ontap-nas
managementLIF:
dataLIF:
svm:
credentials:
name: backend-fsx-ontap-nas-secret

デフォルトの VolumeSnapShotClasses が以下のように設定されていることを確認してください

以下の yaml ファイルが VolumeSnapshotClass の作成に使用されました

kind: VolumeSnapshotClass
metadata:
name: fsx-snapclass
driver: csi.trident.netapp.io
deletionPolicy: Delete

ボリュームスナップショットクラス

ボリュームスナップショットクラス

デフォルト値が設定されていない場合、コンソールまたはコマンドラインから以下のように設定できます

oc patch storageclass trident-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'

oc patch VolumeSnapshotClasses fsx-snapclass -p '{"metadata": {"annotations": {"snapshot.storage.kubernetes.io/is-default-class": "true"}}}'

OpenShift Virtualization でテンプレートから仮想マシンを作成する

テンプレートから VM を作成するには Web コンソールを使用します。

ステップ 1: Red Hat OpenShift Virtualization コンソールから、VM を作成します。クラスター上で利用可能なテンプレートを使って VM を作成できます。

テンプレートから VM を作成

テンプレートから VM を作成

ステップ 2: VM のオペレーティングシステムを選択します。

この一覧から Fedora VM テンプレートを選択しています。

VM テンプレートの選択

VM テンプレートの選択

ステップ 3: VM の詳細設定:

VM に名前を付けた後、Customize Virtual Machine をクリックします。Disks タブを選択し、Add disks をクリックします。ディスクの名前を変更し(分かりやすい意味のある名前を推奨)、StorageClass に trident-csi が選択されていることを確認します。Save をクリックします。Create VirtualMachine をクリックします。

VM 設定

VM の設定

ステップ 4: VM に接続されるストレージの定義:

VM ストレージ

VM ストレージ

ステップ 5: 前のステップで作成した StorageClass を使用して共有ストレージを追加します:

FSx ストレージを VM に追加

FSx for ONTAP ストレージを VM に追加

数分後、VM は実行状態になります。

VM ステータス

VM ステータス

接続されたストレージの確認:

ストレージの確認を行います。まずディスクを確認し、次にファイルシステムを確認します。VM のファイルシステムには、パーティション、ファイルシステムの種類、マウントポイントが表示されます。

Disks

ディスク

ファイルシステム

ファイルシステム

VM 用に 2 つの PersistentVolumeClaim (PVC) が作成されます。1 つはブートディスク用、もう 1 つはホットプラグディスク用です。

ボリュームクレーム

PersistentVolumeClaim (PVC)

PersistentVolumeClaim (PVC) の詳細を見ると、ボリュームは Trident-CSI ドライバによって提供されている事、そして shared または ReadWriteMany として設定されている事がわかります。

ボリュームクレームの詳細

PersistentVolumeClaim (PVC) の詳細

VM の OS 内部から確認してみましょう。

ステップ 7: Web コンソールを開くボタンをクリックして VM に接続し、Guest の資格情報を使ってログインします。

VM コンソールを開きます。

VM コンソールを開く

ステップ 8: 次に、使用されているディスク容量を確認し、ファイルシステム上にテストファイルを作成します。

df

dd if=/dev/urandom of=random.dat bs=1M count=10240

df

DF アウトプット

df コマンドの出力

仮想マシンのライブマイグレーション

ライブマイグレーションとは、実行中の VM を、通常の運用を中断したり、ダウンタイムを発生させたり、エンドユーザーに悪影響を与えたりすることなく、あるホストから別のホストに移動するプロセスを指します。ライブマイグレーションは仮想化における重要な進歩と考えられています。実行中の OS、メモリ、ストレージ、ネットワーク接続を含む VM 全体を、現在のノードから移行先に移動することができます。

以下では、VM を現在のノードから新しいノードへライブマイグレーションする方法を見ていきます。FSx for ONTAP を介した共有ストレージのおかげで、VM が実行されている OpenShift ノードや AZ に関係なく、データにアクセスすることができます。

ステップ 9: 3 つのドットメニューの下にある Migrate をクリックします。

VM 移行

VM マイグレーション

Overview タブから、マイグレーションが成功したことがわかります。

VM の移行ステータスが完了しました

VM マイグレーション完了のステータス

マイグレーション後のストレージの確認

再度、 VirtualMachines タブから VM に接続し、VM OS 内からストレージの状態を確認するコマンドを実行します。

df

ls

ストレージを検査

ストレージの確認

VM が新しいノードで実行されているにもかかわらず、ストレージ、ファイルシステム、およびボリュームクレームを確認すると、これらの項目はすべて変更されていないことがわかります。

結論:

OpenShift Virtualization と FSx for ONTAP を組み合わせることで、ハイブリッド環境の最適化を目指す組織にとって強力なソリューションが実現します。OpenShift Virtualization により、ユーザーは統一された Kubernetes プラットフォーム内で VM とコンテナ化されたアプリケーションの両方を管理でき、運用効率と柔軟性が向上します。一方、FSx for ONTAP は、OpenShift とシームレスに統合される、スケーラブルで高性能なストレージを提供し、データへの容易なアクセスと保護を確保します。

この組み合わせにより、企業はレガシーワークロードを効率的に管理しながら、アプリケーションのモダナイゼーションを進めることができます。単一の環境で多様なワークロードを実行できることで、チームは運用を効率化し、複雑さを軽減し、リソースの利用効率を向上させることができます。OpenShift Virtualization と FSx for ONTAP は、今日のダイナミックな企業環境の要求に応える堅牢なインフラストラクチャを提供し、イノベーションと成長を可能にします。

Trident の詳細については、NetApp Trident ドキュメントを参照してください。NetApp ソリューションドキュメントの Red Hat OpenShift Virtualization セクションで補足情報とビデオを確認できます。

ライアン・ニクシュ

Ryan Niksch

Ryan Niksch は、アプリケーションプラットフォーム、ハイブリッドアプリケーションソリューション、およびモダナイゼーションに焦点を当てたパートナーソリューションアーキテクトです。Ryanは人生で様々な役割を経験してきており、物事を改善することへの情熱と、自分が関わったものを見つけた時よりも少しでも良い状態で残したいという願いを持っています。

バヌマシー・スンダール

Banumathy Sundhar

Banumathy Sundhar はテクニカルマーケティングエンジニアとしての現在の役割と、テクノロジーイネーブルメント専門家としての過去の役割において、プラットフォームと製品の普及促進、技術分野の深い探求、ライブまたは録画デモの提供、情報共有、ブログやライブ・バーチャルのセッションを通じた教育とスキルアップを行ってきました。ハイブリッドクラウド環境において、OpenShift クラスターと統合された NetApp 製品によるソリューションの技術的検証を顧客向けに提供してきました。前職では、ハンズオンラボを中心としたコンテンツ、技術プレゼンテーション、認定試験準備セッション、カンファレンスやインストラクターサミットでのラボセッションなど、技術トピックに関する幅広いトレーニングを開発・提供してきました。

マユール・シェティ

Mayur Shetty

Mayur Shetty は、Red Hat のグローバルパートナーおよびアライアンス組織のシニアソリューションアーキテクトです。業界での経験は約20年に及び、 4 年間在籍した Red Hat では、OpenStack Tiger チームのメンバーとしても活動してきました。それ以前は、Seagate Technology でシニアソリューションアーキテクトとして、OpenStack Swift、Ceph、その他のオブジェクトストレージソフトウェアを活用したソリューションを推進していました。また、IBM では ISV エンジニアリングをリードし、Oracle データベース、IBM システムおよびストレージに関するソリューションの開発に携わりました。Sun Cluster ソフトウェアの開発や、Sun Microsystems の ISV エンジニアリングチームでも活動してきました。

翻訳はパートナーソリューションアーキテクト 豊田が担当し、監修はネットアップ合同会社の藤原様に協力頂きました。原文はこちらです。