仮想化プラットフォームからハイブリッドクラウド・ソリューションへの移行：実践に基づく報告

多くの企業や組織が、従来の仮想化プラットフォームからハイブリッドクラウド・ソリューションへの移行を進めています。先頃、Red Hat エンジニアのグループがこのプロセスを実施し、仮想化ワークロードを OpenShift に移行するための高度なツールである仮想化移行ツールキットを使用して、Red Hat Virtualization から Red Hat OpenShift への大規模な移行を実行しました。

私たちが使ってきた Red Hat Virtualization 環境は、10 年以上にわたり数百の仮想マシン (VM) を正常に実行しました。その中にはエンジニアが開発やテストの目的で使用したものもあれば、実稼働のワークロードに使用されたものもあります。しかし、Red Hat Virtualization のサポート終了日が近づいていることから、VM を OpenShift に移行するべきだと判断しました。

Red Hat Virtualization で実行されていた VM の性質を考慮し、また、エンドユーザー側での中断を最小限に抑えるため、OpenShift Virtualization を使用して OpenShift 上の VM 内でワークロードの実行を継続することにしました。そのため、移行には仮想化移行ツールキット 2.4 を使用しました。これは、強化された移行機能を備えた、当時最も先進的なバージョンでした。

Red Hat Virtualization から OpenShift に移行する過程で、私たちは Red Hat 自身の課題やユーザーが経験した課題など、さまざまな課題に直面しました。この記事では、私たちがそれらの課題にどのように対処したのかについて説明し、その経験から得られた知見を提供します。

準備と計画

移行を成功させるためには、綿密な計画が不可欠でした。移行の計画を立て始めると、いくつかの課題があることがわかりました。

第 1 に、移行先の OpenShift クラスタに、移行されたワークロードに対処できる十分なリソースがあることを確認する必要がありました。まず、最近 Red Hat Virtualization で使用されていない VM と、所有者が新しい OpenShift 環境に移行しないように要求している VM を特定しました。これらの VM は移行の対象外としました。次に、移行を計画している VM のディスクについて、OpenShift に十分なストレージ容量があることを確認しました。また、OpenShift のターゲット VLAN に、移行する予定の VM に割り当てる IP アドレスが十分にあることも確認しました。

第 2 に、Red Hat Virtualization で使用していたプロビジョニングモデルと OpenShift Virtualization 環境で使用しているプロビジョニングモデルをブリッジする必要があることがわかりました。Red Hat Virtualization では、管理者によって新しい VM がユーザーに割り当てられました。対照的に、OpenShift Virtualization では、管理者によってユーザーがプロジェクトに割り当てられ、ユーザー自身がプロジェクト内で VM を作成できます。

第 3 に、仮想化移行ツールキットでは、ソースとターゲットの両方のプロバイダーがユーザーの資格情報を使用して設定されます。このようにして、ユーザーは、パーミッションを持つ VM を移行するソースプロバイダーと、ユーザーに代わって VM を作成するターゲットプロバイダーを定義します。私たちのケースでは、各ユーザーに自身の VM を移行するよう依頼するのではなく、すべての VM を一度に移行する方法を選びました。そのため、両方のプラットフォームで管理者権限を持つユーザーが、Red Hat Virtualization のすべての VM にアクセスし、OpenShift のすべてのプロジェクトで VM を作成できるようにする必要がありました。

ターゲットの OpenShift クラスタに十分なストレージ容量があるかどうかを判断するために、最近 (私たちのケースでは過去 1 年間) 使用された VM とそのディスクサイズを確認するのは簡単な作業ではありませんでした。さらに、Red Hat Virtualization の VM の所有者に OpenShift で対応するプロジェクトを作成してもらい、異なるプロビジョニングモデルをブリッジするには、さらなる労力が必要でした。私たちは、Python スクリプトを実装することでこれらの課題に対処しました。

1 つ目のスクリプトグループは、oVirt SDK を使用して Red Hat Virtualization からデータを収集しました。このデータから、VM が最後に使用された日時を特定し、過去 1 年間に使用されなかった VM を除外しました。移行する VM の最終リストが完了した後、ディスクのサイズと所有者に関する詳細情報を収集しました。Red Hat Virtualization から取得したデータによると、移行する VM のデータを保存するための十分なストレージ容量が OpenShift クラスタにないことがわかりました。これに対処するため、新しいストレージクラスを追加して OpenShift クラスタのストレージを増やしました。

2 つ目のスクリプトグループは、Kubernetes API を使用して OpenShift クラスタでプロジェクトを準備するために使用されました。最初のスクリプトセットから取得したデータを使用して、移行する各 VM の所有者のセットを特定しました。次に、所有者の各セットについて、OpenShift クラスタ内にプロジェクトを作成し、所有者に管理者権限のある ClusterRole を付与して、そのプロジェクトを所有者に割り当てました。

これを説明するために、2 人の Red Hat Virtualization ユーザー、Alice と Bob が所有する shared_vm という VM を例に挙げます。OpenShift で alice-bob-ns という名前のプロジェクトを作成します。これは、Alice と Bob の両方がアクセス権を持っています。次に、 VM shared_vm を alice_bob_ns プロジェクトに移行します。Red Hat Virtualization で Alice と Bob が所有する他の VM も同じプロジェクトの alice_bob_ns に移行することができます。Alice と Bob は、単独で、または他のユーザーと共同で所有する Red Hat Virtualization の VM とともに他のプロジェクトに割り当てることができます。このアプローチにより、Red Hat Virtualization および OpenShift 環境で異なるプロビジョニングモデルに対応できます。

この問題が解決したところで、仮想マシンの移行に着手しました。

実行

移行自体は以下のいくつかのステップで構成されていました。

1. 移行先の OpenShift クラスタに仮想化移行ツールキットをデプロイ。仮想化移行ツールキットは、それが実行される OpenShift クラスタに、または移行先プロバイダーとして追加されたリモートの OpenShift クラスタに、VM を移行することができます。私たちのケースでは、すべての VM を単一の OpenShift クラスタに移行するため、そのクラスタに仮想化移行ツールキット Operator をインストールしました。
2. OpenShift Web コンソールでは、管理者ユーザーを使用して、以下のようにして移行用の OpenShift クラスタを設定しました。
   1. 移行作業のための管理プロジェクトを作成。
   2. Red Hat Virtualization ソースプロバイダー、ターゲットプロバイダーとしてのローカル OpenShift クラスタ、管理プロジェクトでのストレージとネットワークのマッピングを作成。
3. ターゲットプロジェクトに移行するためには膨大な数の移行プランが必要だったため、管理者権限で実行されるスクリプトを導入して、作成と実行を自動化しました。これらのスクリプトは、以下のアクションを実行しました。
   1. ターゲットプロジェクトごとにコールド移行プランを作成しました。コールド移行を選択したのは、VM のダウンタイムを懸念する必要がなかったからです。コールド移行は通常、ウォーム移行よりも高速です。
   2. 移行プランを開始するにあたって、移行ごとのプランを作成しました。

VM 移行プランのほとんどは正常に完了しましたが、VM の移行中に 2 つの興味深い課題に直面しました。

まず、最初の VM の移行が完了するのに、予想以上に時間がかかることに気付きました。これは多数の移行プランを同時に実行したためでした。

仮想化移行ツールキットでは、1 つの移行プランの一部として並行して実行される VM 移行の数を制限できますが、さまざまな移行プランで実行される VM 移行の数を制限する方法はありません。そのため、多数の移行プランを同時に実行することでネットワーク帯域幅を使い果たし、VM の移行に遅れを生じさせていました。

私たちのケースでは、移行される各 VM のダウンタイムよりも、すべての移行プランの実行に要する時間の方が重要であり、この選択による移行の全体的な時間への影響はありませんでした。ただし、VM の移行がタイムアウトした場合や各 VM のダウンタイムを最小限に抑える必要がある場合など、ネットワーク帯域幅の枯渇によって移行全体にかかる時間に影響がある場合は、移行プランを段階的に実施するか、ウォーム移行を実行することをお勧めします。

次に、120 の VM 移行のうち 3 件が失敗しました。調査したところ、これはコードベースのバグが原因であったことが判明しました。そのバグをすぐに修正し、修正バージョンの仮想化移行ツールキットを使用して、すべての VM を正常に移行しました。この問題の修正は、仮想化移行ツールキット 2.5 に含まれています。

このような調整を行い、すべての VM を OpenShift に移行することができました。

OpenShift での VM の検証

仮想化移行ツールキットによってすべての移行が正常に完了した後、OpenShift Virtualization 上の VM を複数、ランダムに選択して健全性チェックを実行し、それぞれに問題がないことを確認しました。その後、VM 所有者からのフィードバックを待ちました。概して、OpenShift Virtualization に移行した VM について、ユーザーから肯定的なフィードバックを得ましたが、いくつかの問題も報告されました。

まず、一部の VM が起動に失敗し、「no operating system found (オペレーティングシステムが見つかりません)」というメッセージが表示されるという問題がありました。調査の結果、この問題が発生するのは複数のディスクを持つ VM のみであり、誤ったディスクが起動元として選択された場合のみであることがわかりました。私たちは VM の起動順序を手動で変更し、起動可能なディスクから起動するようにすることで、この問題を解決しました。この問題 は、仮想化移行ツールキット 2.5 で適切に修正されています。

また、サービスの中断もいくつか報告されました。移行中に、インフラストラクチャの制約により VM の VLAN が変更され、これらの VM 内の一部のワークロードとサービスは起動時にアクセスできなくなりました。これは、DNS レコードを異なる完全修飾ドメイン名 (FQDN) と新しい VLAN 上の IP アドレスで設定したためです。この問題は、ワークロードと外部クライアントを新しい FQDN 設定に適応させるようユーザーに指示することで解決されました。

得られた教訓

従来のデータセンターからハイブリッドクラウド・ソリューションへの移行は困難を伴います。さまざまなツールによってサポートされるさまざまなアプローチが用意されており、ユーザーはその中から選択することができます。この記事では、Red Hat 社内で実施した Red Hat Virtualization から OpenShift への VM の移行について説明しました。

この移行のためには、入念で包括的な計画を立て、組織内のすべての関係者と明確なコミュニケーションを取る必要がありました。仮想化移行ツールキットは、OpenShift Virtualization への移行を容易にするツールを提供しますが、必要なすべての技術的手順に対応しているわけではありません。

この記事では、仮想化移行ツールキットの使用方法と、仮想化移行ツールキットでは処理されない操作用に実装したスクリプトについて説明しました。これらのスクリプトは GitHub で入手できます。これらのツールを使用して、120 台の VM と 12 TB のデータを効果的に移行することができました。今では OpenShift で正常に稼働しています。

Red Hat Virtualization はサポート終了日が迫っており、多くの組織が同様の移行を検討することが予想されます。Red Hat の経験とツールが、仮想化移行ツールキットを使用して VM を OpenShift に移行する際のお役に立てば幸いです。仮想化移行ツールキットでは、このブログ記事で言及されている問題が修正されており、さらに多くの改善が加えられています。