開発者がクラウド コンピューティング プラットフォームにワークロードを展開する場合、多くの場合、これらのサービスを実行する基盤となるハードウェアを考慮する必要はありません。ハードウェアのメンテナンスや物理的な制限は、人々が理想とする「クラウド」のイメージでは見えにくいものですが、ハードウェアは必然的に定期的なメンテナンスが必要となり、ダウンタイムが発生する可能性があります。このダウンタイムがお客様に伝わるのを防ぎ、クラウドの約束を真に実現するために、Linode は Live Migration と呼ばれるツールを提供しています。 ライブ マイグレーション テクノロジーを使用すると、サービスを中断することなく、Linode インスタンスを異なる物理サーバー間で移動できます。ライブ マイグレーション ツールを使用して Linode インスタンスを移動すると、移行プロセスは Linode インスタンスで実行されているプロセスからはまったく見えなくなります。ホストのハードウェアのメンテナンスが必要な場合、そのホスト上のすべての Linode インスタンスは、ライブ マイグレーションを通じて別のホストにシームレスに転送できます。移行操作が完了すると、顧客に影響を与えるダウンタイムを発生させることなく、物理ハードウェアの修復を開始できます。 これは、クラウド技術と非クラウド技術の分岐点となる決定的な技術となりつつあります。この記事では、このテクノロジーの詳細について詳しく見ていきます。 Linode が Akamai ソリューション ファミリーに加わったことを記念して、今すぐ Linode にサインアップすると、100 ドル相当の無料使用クレジットを獲得できます。これにより、Linode クラウド プラットフォームが提供するさまざまなサービスを使用できます。詳細と登録については、ここをクリックしてください↓↓↓ 海外クラウドサービスならAkamaiが最適です! ライブマイグレーションの仕組みほとんどの新しいプロジェクトと同様に、Linode のライブ マイグレーションは、多くの調査、多数のプロトタイプ、同僚や経営陣からの多大な支援から始まりました。最初のステップは、QEMU がライブ マイグレーションをどのように処理するかを調査することです。 QEMU は Linode が使用する仮想化技術であり、ライブマイグレーションも QEUM の機能です。したがって、私たちのチームの焦点は、同様のテクノロジーを再発明するのではなく、このテクノロジーを Linode に導入することです。 では、ライブ マイグレーション テクノロジーは QEMU でどのように実装されているのでしょうか?全体のプロセスは次の 4 つのステップに分かれています。
これらの手順では、QEMU ライブ マイグレーションの実行方法の概要を示します。ただし、ターゲットの QEMU インスタンスをどのように起動するかを正確に指定するには、依然として非常に手動のプロセスが必要です。さらに、上記のプロセスにおける各操作は、正しいタイミングで実行する必要があります。 Linode がライブマイグレーションを実装する方法QEMU 開発者が実装したテクノロジーを分析した後、それを Linode に導入する方法を検討する必要があります。その答えこそが、私たちの仕事の最優先事項です。 ライブ マイグレーション ワークフローのステップ 1 では、着信ライブ マイグレーション接続を受け入れるために、ターゲット QEMU インスタンスを起動する必要があります。このステップを実装する際、当初の考えは、現在の Linode インスタンスの構成ファイルを取得し、それをターゲット コンピューターに適用することでした。理論的にはこれは単純なはずですが、さらに考えてみると、実際の状況ははるかに複雑であることがわかります。特に、構成ファイルは Linode インスタンスがどのように起動されるかを伝えますが、起動後の Linode インスタンスの完全な状態を必ずしも完全に記述するわけではありません。たとえば、 Linode インスタンスの起動後に、ユーザーはブロック ストレージデバイスをホットプラグして接続できますが、これは構成ファイルに記録されません。 ターゲット ホスト上に QEMU インスタンスを作成するには、現在実行中の QEMU インスタンスをプロファイルする必要があります。確認します 品質管理 このインターフェースは、QEMU インスタンスのレイアウトに関する豊富な情報を提供しますが、ゲスト システムの観点からインスタンス内で何が起こっているかを理解するのには役立ちません。たとえば、ローカル SSD とブロック ストレージの場合、ディスクがどこにリンクされているか、仮想ディスクがどの仮想化 PCI スロットに接続されているかのみを知ることができます。 QMP を照会し、QEMU インターフェイスを検査および分析した後、ターゲットの場所で同一のインスタンスを作成する方法を記述するプロファイルを構築できます。 ターゲット マシンでは、ソース インスタンスがどのようになっていたかについての完全な説明を受け取り、それをターゲット上で忠実に再現できますが、違いが 1 つあります。主な違いは、ターゲット QEMU インスタンスが、QEMU が着信移行を受け入れることを可能にするオプションを使用して起動されることです。 この時点で、ライブ移行の記録プロセスは基本的に終了しています。次に、QEMU がこれらの操作をどのように実装するかを確認する必要があります。 QEMU プロセス ツリーは、制御プロセスと複数のワーカー プロセスで構成されます。ワーカー プロセスのうちの 1 つは、QMP 呼び出しを返すか、ライブ マイグレーションなどのタスクを処理する役割を担い、他のプロセスはゲスト CPU に 1 対 1 でマッピングする必要があります。ゲスト環境は QEMU 側から機能的に分離されており、独立したシステムのように動作します。 この意味で、次の 3 つのレイヤーのコンテンツを処理する必要があります。
ターゲット インスタンスが起動し、受信移行を受け入れる準備が整うと、ターゲット ハードウェアはソース ハードウェアにデータの送信を開始するように指示します。ソースはこの信号を受信した後に処理を開始し、ソフトウェア内の QEMU にディスク コンテンツの転送を開始するように指示します。ソフトウェアは、ディスク転送の進行状況を自動的に監視して転送操作が完了したかどうかを確認し、ディスク転送が完了するとメモリの内容の移行を自動的に開始します。この時点で、ソフトウェアはメモリ移行の進行状況を監視し、メモリ移行が完了すると自動的にカットオーバー モードに切り替わります。上記のプロセスはすべてLinodeを通じて行われます データは40Gbpsのネットワーク経由で送信されるため、ネットワーク操作を迅速に完了できます。 カットオーバー: 主な手順カットオーバー操作は、ライブ マイグレーション プロセスの最も重要な部分です。これを理解することでのみ、ライブマイグレーション操作を完全に理解することができます。 カットオーバーポイントでは、QEMU は、すべてがカットオーバーされ、ターゲット マシン上で実行される準備ができていることを確認しました。ソース QEMU インスタンスは両端を停止します。つまり、次のようになります。
時間とネットワークの両方の要求が停止されるため、切り替えはできる限り迅速に行う必要があります。ただし、カットオーバーを成功させるには、いくつかのチェックが必要です。
切り替えプロセスには時間が限られているため、上記の操作をできるだけ早く完了したいと考えています。これらの問題を解決したら、カットオーバーを続行できます。ソース Linode インスタンスは自動的に「カットオーバー完了」信号を受信し、ターゲット インスタンスを実行します。宛先 Linode インスタンスは、ソース インスタンスが一時停止された状態から再開されます。ソース インスタンスとターゲット インスタンス上の残りのコンテンツはクリーンアップされます。将来、ターゲット Linode インスタンスを再度ライブマイグレーションする必要がある場合は、上記の手順を繰り返します。 エッジケースの概要ライブ マイグレーションの実装のほとんどは簡単ですが、エッジ ケースを考慮すると、機能自体の開発は広範囲にわたっています。このプロジェクトの成功は、ツールの素晴らしいビジョンを信じ、タスクを完了するために必要なリソースを提供した経営陣のおかげであることは言うまでもありませんが、もちろん、プロジェクトが成功裏に完了できると信じていた多数の従業員の存在も切り離せません。 次の領域で多くのエッジケースが発生しました。
CPU タグ付けQEMU には、ゲスト オペレーティング システムに CPU を提示するためのさまざまなオプションがあります。 1 つのオプションでは、ホスト CPU モデルと機能 (つまり、CPU タグ) をゲストに直接渡すことができます。このオプションを使用すると、ゲストは KVM 仮想化システムでサポートされているすべての機能を制限なく使用できます。 Linode が初めて KVM を採用したとき (ライブ マイグレーション前)、パフォーマンスを最大化するためにこのオプションを使用しました。しかし、このオプションは、ライブ マイグレーション機能の開発中に多くの課題をもたらしました。 ライブ マイグレーション テスト環境では、ソース ホストと宛先ホストは 2 台の同一のコンピューターです。しかし、現実の世界では、ハードウェア クラスターは 100% 同一ではなく、マシン間の構成の違いによって CPU マーキングが異なる場合があります。これは、プログラムが Linode のオペレーティング システムにロードされると、Linode がプログラムに CPU タグを提示し、プログラムがソフトウェアの特定の部分をメモリにロードしてそれらのタグを活用できるため重要です。 Linode インスタンスが CPU タグをサポートしていないターゲット マシンにライブ マイグレーションされると、プログラムはクラッシュします。これにより、ゲスト オペレーティング システムがクラッシュしたり、Linode が再起動したりする可能性があります。 マシンの CPU シグネチャがゲストにどのように表示されるかには、次の 3 つの要因が影響していることがわかりました。
したがって、ライブマイグレーションを実装する場合は、CPU タグの不一致によってプログラムがクラッシュしないようにする必要があります。可能なオプションは 2 つあります。
ソースとターゲットの CPU タグを一致させることを決定した後、次の 2 つのアプローチを組み合わせて最終的に目標を達成しました。
2 番目のアプローチは高速である必要があり、作業が複雑になります。場合によっては、900 台を超えるマシンの最大 226 個の CPU タグをチェックする必要がありました。 226 個の CPU フラグすべてをチェックするコードを書くのは非常に困難であり、そのコードは長期間にわたって保守される必要があります。しかし、Linode の創設者 Chris Aker 氏の驚くべきアイデアにより、ついに問題は解決しました。 この方法の鍵となるのは、すべての CPU フラグのリストを作成し、それをバイナリ文字列として表現することです。次に、ビットごとのand演算を使用して文字列を比較できます。このアルゴリズムを説明するために、次の簡単な例を使用できます。次の Python コードは、ビット単位のANDを使用して2 つの数値を比較できます。 ビット単位のAND演算がなぜその結果を生成するのかを理解するには、まず数値を 2 進形式で表す必要があります。 10進数の「 2 」と「 3 」を2進数で表すとどのように処理されるかを見てみましょう。 ビットAND は、 2 つの異なる数値の 2 進数の「桁」または「ビット」を比較します。この操作は、上記の数字の右端の桁から始まり、左に向かって行われます。
したがって、完全な結果のバイナリ表現は 00000010 となり、これは 10 進数では「 2 」になります。 ライブ マイグレーションの場合、CPU タグの完全なリストは、各ビットがタグを表すバイナリ文字列として表されます。ビットが「 0 」の場合、対応するタグが存在しないことを意味します。ビットが「 1 」の場合、タグが存在することを意味します。たとえば、1 ビットは AES フラグを表し、別のビットは MMX フラグを表すことができます。バイナリ文字列内のこれらのタグの位置は維持され、文書化され、その後、データセンター内のすべてのマシンで使用されます。 このリストは、CPU フラグが存在するかどうかを確認するための一連の if ステートメントを維持するよりもはるかにシンプルで効率的です。たとえば、追跡およびチェックする必要がある CPU フラグが合計 7 つあり、それらを 8 ビットの数値 (将来の拡張用に追加のビットを含む) に格納できるとします。たとえば、このような文字列は 00111011 のようになります。ここで、右端のビットは AES が有効であることを意味し、右から 2 番目のビットは MMX が有効であることを意味し、右から 3 番目のビットは他のフラグが有効であることを意味します。 次のコード スニペットでは、どのハードウェアがこれらのフラグの組み合わせをサポートしているかを確認できます。また、このコードは 1 サイクルで一致するすべての結果を返すことができます。比較が if ステートメントのセットとして実行される場合、目的の結果を得るためにより多くのサイクルが必要になります。ライブ マイグレーションのソース マシンに 4 つの CPU タグが含まれている場合、一致するハードウェアを見つけるのに 203400 サイクルかかります。 ライブ マイグレーション操作では、ソース コンピューターとターゲット コンピューターの両方の CPU タグ文字列に対してビット単位の AND演算が実行されます。両方のコンピューターの CPU タグ文字列が等しい場合、ターゲット コンピューターに互換性があることを意味します。このプロセスについては、次の Python コード スニペットを参照してください。 上記のコード スニペットでは、宛先マシンがソース マシンよりも多くのタグをサポートしていることに注意してください。ソースのすべての CPU タグがターゲット マシンに含まれているため、ターゲット マシンは互換性があると見なされます。これは、ビット単位のAND演算によって保証されます。 当社の内部ツールは、上記のアルゴリズムの結果を使用して、互換性のあるハードウェアのリストを作成できます。このリストは、当社のカスタマー サポート チームとハードウェア運用チームに提示され、これらのチームは社内ツールを使用してさまざまな運用タスクを調整できます。
ソフトウェアを「実行」するには、多くの開発作業が必要です... 障害処理ソフトウェア分野ではあまり議論されないトピックがあります。それは、障害を適切に処理することです。ソフトウェアは少なくとも「実行」できる必要があります。これを実現するには、ライブ マイグレーション機能の開発など、多くの開発作業が必要になることがよくあります。ツールが正常に動作しない場合にどうするか、その状況に適切に対処するにはどうすればよいかについて、私たちは多くの時間をかけて考えました。私たちは多くのシナリオを検討し、具体的な対応を決定しました。
o解決策: 顧客はこれを実行できます。ライブマイグレーションは中断され、処理を続行できません。ライブマイグレーションは後で再試行できるため、この動作は適切です。
o 解決策: ソース ハードウェアに通知し、特別に設計された内部ツールを使用してデータ センター内の別のハードウェアを自動的に選択します。運用チームにも通知が送られ、障害が発生したターゲット ハードウェアを調査できるようになります。これは本番環境で以前にも発生したことがあり、ライブ移行では問題なく処理されました。
o ソリューション: ライブマイグレーションの進行状況を自動的に監視します。過去 1 分間に進捗がなかった場合は、ライブ マイグレーションはキャンセルされ、運用保守チームに通知されます。これはテスト環境以外では発生したことはありませんが、このシナリオに対しては十分な準備が整っています。
o回避策: ライブ マイグレーションがクリティカル ステージに到達しない場合は、ライブ マイグレーションが停止され、後で再試行されます。 o 重要なフェーズに達した場合、移行は続行されます。これは、復元操作を続行するために、ソース Linode が停止し、ターゲット Linode が電源オンの状態である必要があるため重要です。 これらのシナリオはテスト環境でシミュレートされており、上記の動作はさまざまな状況で最適な対応であると考えています。 技術の変化に遅れを取らない数十万回のライブマイグレーションを成功させた後、 「ライブマイグレーションの開発はいつ終わるのか」という疑問が湧くのは当然です。テクノロジーがますます広く使用され、時間の経過とともに改善されるにつれて、プロジェクトは永遠に続くように思えます。この質問に答える一つの方法は、プロジェクトの作業の大部分がいつ完了するかを考えることです。答えは簡単です。信頼性が高く、信用できるソフトウェアを生み出すという私たちの取り組みは、今後も長く続くでしょう。 Linode は時間の経過とともに新しい機能を追加するため、ライブマイグレーションがそれらの機能と互換性があることを保証するための作業を継続的に行う必要がある場合があります。いくつかの新機能を導入する場合、ライブ マイグレーションに関する新しい開発作業を行う必要はないかもしれませんが、機能が期待どおりに動作するかどうかをテストする必要がある可能性があります。一部の機能については、開発の初期段階でライブ移行に必要な互換性テストや関連作業を実行する必要がある場合があります。 他のほとんどすべてのソフトウェアと同様に、継続的な研究を通じて、同じことを達成するためのより良い方法を常に見つけることができます。たとえば、ライブ マイグレーション機能に対して、よりモジュール化された統合アプローチを開発すると、長期的にはメンテナンスの負担が確実に軽減されます。あるいは、ライブ マイグレーション機能を基盤コードに組み込み、Linode のすぐに使える機能にすることもできます。 私たちのチームはこれらすべてのオプションを検討し、Linode プラットフォームを動かすツールは健在であると確信しており、今後もツールの進化と成長を維持するために努力を続けます。 この記事の内容は大丈夫でしょうか?今すぐ Linode プラットフォームで試してみませんか?今すぐ登録すると、100 ドル相当の無料クレジットを獲得できることをお忘れなく。早速、この記事で紹介した機能やサービスを実際に体験してみましょう↓↓↓ 海外クラウドサービスならAkamaiが最適です! フォローを歓迎します アカマイ 、高可用性 MySQL/MariaDB リファレンス アーキテクチャと豊富なアプリケーション例を初めて知ることができます。 |
<<: クラウドネイティブの可観測性プラットフォームである OpenObserve の初体験
>>: クラウド ネイティブの可観測性 OpenTelemetry の基礎 (アーキテクチャ/分散トレース/メトリック/ログ/サンプリング/コレクター)
過去数年間のクラウド コンピューティング サービスへの劇的な移行により、企業はこれまでにない柔軟性と...
1. フォーラムはプロモーションプラットフォームですフォーラムの特徴は、無料であることです。無料とい...
9月の毎日の生放送で、ウェイ・ヤーはいつものように商品を紹介した。しかし、この商品は、ブランドのTm...
Racknerd は現在、米国西海岸のロサンゼルスにある Multacom データ センターにあるク...
モノのインターネット (IoT) は、データから即座に洞察を得て、これまで以上にスマートで競争力があ...
百度は2009年4月に鳳凰巣システムを立ち上げて以来、このシステムは継続的に更新されており、ウェブマ...
「新型コロナ」の流行という「ブラックスワン」現象は、その驚異的な威力を示した。一方で、この流行は経済...
ちょうど hostmist の VPS プロモーションを見つけました。256M メモリを搭載した K...
2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っています当社のウェ...
[[418928]] 1. ツールの説明Docker >= 19.03 をインストールします。...
今日、インターネットで医療SEOに関する記事を読みましたが、その内容に深く感動しました。その理由は、...
itldcはどうですか? itldc Seattle VPS はいかがでしょうか? itldcはロサ...
石玉珠は今年初めにインターネットの世界から姿を消しましたが、彼が率いたジャイアントグループが生み出し...
ホストキャットのサイトの記事の下に、XXのVPSのCPUがものすごく弱くて、スコアの実行やコンパイル...
最近の若者は皆、ウェブサイトを通じて初めての大金を稼ぐことを望んでいます。しかし、彼らはその背後にあ...