近年、Linux オペレーティング システムはテクノロジー、コミュニティ、商業ソリューションにおいて急速な発展を遂げており、Mobile Cloud はモバイル クラウドのフルシナリオ ビジネスの効率的な移行を保証する新世代の Tianyuan オペレーティング システムと簡単な移行ツールを次々とリリースしています。モバイル クラウドの CentOS 移行のプロセスでは、オペレーティング システム間の仮想マシン移行が変革の重要な部分です。現在のネットワーク環境は複雑です。プラットフォーム上ではスムーズに動作しますが、基盤となる仮想化側では多くの技術的課題に直面しています。
主要な課題
仮想化コンポーネントは同種および異種である
新しい仮想化コンポーネントは、複数の Linux オペレーティング システム上で安定して動作し、異なるオペレーティング システムや CPU アーキテクチャ上で同じソース コードを共有する必要があるため、まず同質性と異質性の問題を解決する必要があります。
OS対応適応
コンピューティング、ストレージ、SDNなどのコアサービスはOS上で相互に互換性を持たせる必要があるが、新しいプラットフォームではビジネスの互換性や適応性の問題を中間層、つまり仮想化層で解決する必要がある。
停止することなく OS 全体でライブ マイグレーションを行う
オペレーティング システム間や仮想化コンポーネントの大規模バージョン間での移行は、仮想マシンの CPU 機能、メモリ レイアウト、デバイス構造などの違いにより失敗し、ビジネスの継続性に影響を与える可能性があります。
仮想化コンポーネントは同種および異種である
同種の異質性により、異なるシステムや異なるアーキテクチャ間の差異が隠蔽され、ライブ ネットワーク バージョンが縮小され、コードのメンテナンスの負担が軽減されます。「コードを一度コンパイルすれば、どこでも実行できる」を実現します。
私たちは、同種異種変換のプロセスにおける多くの問題を解決してきました。たとえば、システムやアーキテクチャが異なれば、コンパイルとインストールの依存関係も異なります。対応する依存関係は、異なるシステムやアーキテクチャに従って仕様ファイルで指定する必要があります。新旧の仮想化コンポーネント ソフトウェア パッケージのインストール中に競合が発生するため、コンポーネントのスムーズなアップグレードを実現するには、rpm の廃止されたメカニズムを使用して対応するインストール パッケージを削除する必要があります。さらに、新旧の仮想化コンポーネントの違いが大きいため、パッチラウンド後に旧バージョンの関数呼び出しが失敗し、コードの違いに応じて一部の関数を再設計する必要があります。
OS対応適応
仮想マシンが OS 上でスムーズに実行できるようにするには、プラットフォーム上のコンピューティング、ストレージ、SDN、仮想化コンポーネントの適応に関するいくつかの問題を解決し、いくつかの最適化を行う必要があります。
Python2バージョンと互換性があります
Python2 のライフサイクルの終了に伴い、libvirt-python は 6.0.0 以降 Python2 のサポートを終了しましたが、一部の製品の変換サイクルが長いため、移行として一時的に Python2 環境の使用を維持する必要があります。基礎となるコンポーネントとして、仮想化は Python2 の libvirt-python パッケージに基づいて構築する必要があります。Python3 と Python2 の構文の違い、インターフェイスの変更、モジュールの変更などから始めて、OS 上の libvirt-python コードを次のように変更しました。
- データ型やクラス定義などの文法的な違いに対応する修正が加えられています。
- 例外キャプチャ、入出力、イテレータなどの API の使用の違いに対応する改訂が行われました。
- Python3 と Python2 の間で名前の変更または非推奨のモジュールに対する変更が行われました。
50 を超えるファイルと数千行のコードを変更した後、最終的に Python2 ベースの安定した信頼性の高い libvirt-python を入手しました。
OVS-dpdk と QEMU の適応
SDN の安定性と信頼性は、ユーザーの仮想マシンのネットワーク サービス品質に直接影響しますが、SDN が新しいプラットフォーム上でスムーズに実行できるように、さまざまな SDN ベンダーの OS への適応作業を積極的に推進し、複数の適応問題を解決しています。 。
SDN の適応中に、QEMU がサーバーとして使用されている場合、ovs を再起動すると仮想マシンがクラッシュする可能性があることが判明しました。QEMU のコアダンプ ファイルを確認し、クラッシュを引き起こす次のコードを見つけます。
QEMU がサーバーとして使用されている場合、ovs が再起動すると、QEMU は上記のコードのロジックに従って積極的に再接続を試行します。プロセス中に、ネットワーク カード デバイスの tcp ステータス ワードが TCP_CHARDEV_STATE_DISCONNECTED に変更され、処理が発生します。 QEMU のクラッシュの原因となるロジックのバグ (実際、QEMU はサーバーとして再接続操作を実行する必要はありませんが、再接続はクライアントとして ovs によって実行される必要があります)。クラッシュを引き起こす具体的なプロセスは次のとおりです。
解決策は、QEMU がクライアントとして使用されている場合にのみ、ovs を再起動し、QEMU が再接続して問題が解決されることです。上記の問題に加えて、ovs ホット アップグレード後の Windows 仮想マシンのネットワーク障害や、Haiguang プラットフォームで testpmd テスト プログラムを実行するときに仮想マシンが停止するなど、他のいくつかの問題も解決しました。
ボリューム移行操作の効率の最適化
分散ストレージはクラウド プラットフォームに基本的なストレージ サービスを提供し、その使用にはボリュームの移行や容量のクエリ操作が伴うことがよくありますが、これらの操作は実際には効率的ではないため、最適化する必要があります。
QEMU ネイティブ バージョンが Ceph ボリューム移行機能を実装する場合、すべてのビットマップは移行前にダーティになります。移行の最初のラウンド中に、ソース ディスク上のすべてのデータが宛先ディスクに移行されます (データが書き込まれていない部分は移行されます)。 0と書き込まれ、マイグレーションが発生します。 データ量が増加し、時間がかかります。ceph ボリュームの移行を最適化し、最初の移行ラウンドのデータ量を削減し、効率が大幅に向上しました (特にソース ディスク領域が大きく、データ量が少ない場合)。次のように：
- QEMU コンポーネントの rbd ドライバーを変更し、バックエンド クラスター Ceph ボリュームの使用領域分布を取得するためのインターフェイスを追加します。
- 移行の開始時に、インターフェイスを使用してボリューム移行のダーティ ビットマップを初期化します。
- 移行プロセス中に仮想マシンが新しい IO を追加すると、対応するダーティ ビットマップがダーティに設定されます。ダーティ ビットマップは継続的に繰り返しクリーンアップされ、データのあるストレージ ブロックのみが移行およびコピーされ、データのないブロックは直接スキップされます。
- ボリュームのライブ マイグレーションは、ダーティ ビットマップが完全にクリアされると完了します。
他にもいくつかの最適化があります。
- ceph ボリューム容量クエリを最適化し、新しいインターフェイスを呼び出すことで、クエリ効率が 30% 以上向上しました。
- QEMU は ceph ボリュームのスナップショット移行機能をサポートしており、ソース ボリュームのスナップショット情報は移行後も保持されます。
停止することなく OS 全体でライブ マイグレーションを行う
他のコア製品との適応に関するさまざまな問題を解決した後、私たちは OS を超えた移行と適応に焦点を当てました。クロスOSマイグレーションにおいてゲストのCPU能力やデバイスの状態など複数の側面を考慮するという問題を解決するために、openEulerコミュニティのVirt SIGメンバーと綿密な共同制作を実施しました。
ターゲットのマザーボードの種類に互換性がないため、移行に失敗しました
BC-Linux7 シリーズ システムから BC-Linux For Euler シリーズ システムに移行する場合、「サポートされていないマシン タイプ」エラーが発生します。2 つのオペレーティング システムの QEMU コンポーネントでサポートされているマシン タイプを比較すると、 BC-Linux7 の仮想化コンポーネントは QEMU コミュニティを切断します。 ネイティブ マシン タイプはプライベート マザーボード タイプを完全にカスタマイズするため、通常は openEuler にホット マイグレーションできません。
移行中にマシン タイプを変更することはできないため、正常に移行するには、BC-Linux For Euler システム上の QEMU の上位バージョンがマシン タイプの下位バージョンと互換性がある必要があります。このため、下位バージョンの QEMU で各マシン タイプがサポートするデバイスを整理し、対応するマシン タイプを上位バージョンの QEMU に移植することで、移行中にサポートされないマザーボード タイプの問題が発生しなくなります。
デバイス構造の違いにより移行が失敗する
QEMU は VMStateDescription (VMSD) データ構造を使用してデバイスの状態を記述および管理し、VMSD のフィールドとサブセクションは移行中に宛先に送信されます。仮想マシンを正常に移行するには、ソース側のデバイス構造フィールドが宛先側のデバイス構造フィールドより多い場合、デバイス状態が宛先側で vmstate_load_state によってロードされるときに、余分なフィールドを無効にする必要があります。そうでない場合は、不足しているフィールドが無効になります。フィールドをスキップする必要があります。
テスト中に、仮想マシンを BC-Linux For Euler シリーズ システムから BC-Linux7 シリーズ システムに送り返すと、ピア エンドはキーボードのデバイス ステータスを正常に受信できませんでした。キーボードの VMSD と比較すると、QEMU の上位バージョンでは kbd_extended_state フィールドの送信が追加されており、移行先にこのフィールドがないため移行は失敗します。
kbd_extended_state_needed は、kbd_extended_state フィールドを送信するかどうかを判定する関数です (デフォルトは True)。kbd_extended_state が原因で仮想マシンのフェッチが失敗しないようにするには、フェッチ時に余分な kbd_extended_state フィールドを送信してはなりません。
さらに、他のデバイス、特に virtio デバイスと vhost_user デバイスの VMSD の高 QEMU バージョンと低 QEMU バージョンの違いも比較し、その違いに変更を加えました。
CPU 機能に互換性がないライブ マイグレーションが失敗しました
仮想マシンの CPU には、カスタム (命令セットが最も少ないが、ホット マイグレーションの互換性が最も優れている)、ホスト パススルー (命令セットが最も多いが、ホット マイグレーションの互換性が最も低い)、およびホスト モデル (2 つの中間) の 3 つのモードがあります。仮想マシンの CPU 機能は、仮想化構成に関連するだけでなく、ホスト マシンの CPU モデルとオペレーティング システム カーネルにも関連します。カスタム モードまたはホスト モデル モードでも、移行先に CPU 機能が不足しているために、いくつかの移行エラーが発生しました。
case1: 目的地にアーチ施設機能がありません
上位バージョンの libvirt では、同じ CPU 機能の名前が Arch-facilities から Arch-capabilities に変更されるため、移行先で Arch-facilities が認識されず、ライブ マイグレーションが失敗します。CPU 機能の互換性チェックに合格するには、ソースの cpu_map.xml で Arch-capabilities を変更する必要があります。
case2: ターゲット側に spec_ctrl 機能がない
BC-Linux7 シリーズ システムで使用される 3.10 カーネルは、「ゴースト脆弱性」を回避するために spec_ctrl を有効にする必要がありますが、BC-Linux For Euler シリーズ システムで使用される 4.19 カーネルは、他の方法でこの脆弱性を回避し、spec_ctrl を閉じて、マイクロコードを更新して、宛先で spec_ctrl 機能を有効にします。
case3: 宛先側に hle/rtm 機能がない
host-model で構成されたモデル仮想マシンのライブ マイグレーションは、宛先に hle/rtm 機能がないため失敗します。当該命令セットを有効にするには、接続先ノードのカーネルの起動パラメータに「tsx=on」を追加する必要があります。
要約する
CentOS の移行は、仮想化コンポーネントの均一な異質性、OS の互換性と適応、openEuler コミュニティとの綿密な共同作成により、OS を超えたノンストップのライブ マイグレーションの最適化を実現しています。変換作業を効率的に実行できます。ただし、既存のモバイル クラウド ネットワークには移行が必要なノードが多数あり、移行の効率と成功率に対する要求が高くなります。次回の共有では、パフォーマンス向上に関する技術的な共有を共有します。ホットマイグレーションの最適化、楽しみにしていてください！