ライブ マイグレーションを使い、Google Compute Engine にダウンタイムのないサービス インフラストラクチャーを
2015年3月13日金曜日
* この投稿は、米国時間 3 月 3 日、 VM Migration の Tech Lead/Manager, Miche Baker-Harvey によって投稿されたものの抄訳です。
はじめに
去年の春、2014 年 4 月 7 日に起きたことを覚えていますか？ その日に起きたことではなく、起きなかったことが今日のポストの主題です。
その日は Heartbleed バグが公表された日で、ゼロデイ攻撃に対処するため、この脆弱性のパッチをシステムに当てようと世界中の人たちが対応していました。Google Clodu Platform 以外のパブリッククラウドのプラットフォームを利用していたら VM を再起動、あるいは少なくとも対象の各ノードで SSL ライブラリを更新し、Web サーバーを再起動しなければならないという影響を受けました。Google でも、 Google Compute Engine でホストするサーバーを含むすべてのサーバーを直ちに修正しました。でも誰一人として気づくことはありませんでした。つまり起きなかったのです。
2013 年 12 月、Google Compute Engine にトランスペアレント メンテナンス（透過的なメンテナンス）を導入しました。それ以来、ソフトウェアのアップデート、ハードウェア問題の解決、予期しない問題の解決があっても VM を止めずに稼働させています。データセンター トポロジーのイノベーションと、ライブ マイグレーション テクノロジーを組み合わせることで、定期的なハードウェアやソフトウェアのメンテナンスがあったとしても、それに VM が影響を受けないようにし、VM、アプリケーション、ワークロード、そのどこにも何も起こらかなかったかのように、インフラを保護し高い信頼性を保てるようにしています。
透過的なメンテナンスの利点
ライブ マイグレーションによって Google が目指したのは、VM を再起動することなく、すべてのデータセンターにあるハードウェアやソフトウェアを最新の状態に保つことです。こういったメンテナンスは、ホストマシンの再起動が必要となるため、透過的なメンテナンスがないのなら、当然 VM にも影響がでます。
ライブ マイグレーションで解決するであろう問題は例えば次のようなものです。これらは実際に私たちが遭遇してきたも問題です。
皆さんが運用の中で様々な問題に直面したときに、ライブ マイグレーションがどれだけ役立っているかを知って驚きました。実際、サイトの信頼性に係わるエンジニアは、まだライブ マイグレーションが皆さんに提供されていなかったころにもツールとして使い、プロダクション時に起きる可能性のある障害への対処や、あるいは軽減していました。
以下は、予期せず実際に発生したものの、実行中のゲスト OS には影響なく対処できた問題です。
トランスペアレント メンテナンスの実施
導入後、マイグレーションは数十万回実施されてきています。多くの VM はマイグレーション導入後に立ち上げられて、すべて複数回マイグレートされました。反応は非常に好意的です。初期のマイグレーションのテスト期間中は、Rightscale でマイグレーションの効果を調べました。対象の VM をすべて 2 回マイグレートした後、次のようなレポートが得られました。
「ログファイルを調べましたが、データベースの中の全データは…まったく異常ありません。もしインスタンスがマイグレートされていたことを Google が教えてくれていなかったとしたら、まったくわかりませんでした。すべてのログとデータは正常ですし、RightScale のクラウド管理 ダッシュボードには、ゾーン、インスタンスのサイズ、IP アドレス、リソースなど、いずれも変化はありませんでした」。
ServerDensity の David Mytton 氏と協働で、レプリケートした MongoDB をライブ マイグレーションしたところ、マイグレーション終了後に David はツイートしました。
実際 Google は、ホストへのカーネルのアップグレードと全 VM にセキュリティ パッチ当てを、どの VM も欠けることなく行っています。そこに含まれる大量のコンポーネント、さらにその依存関係までが、どの時点においても 1 つとして障害を起こしたり、失うことがなかったことを考えると驚異的なことだと思いませんか？ マイグレーションの間、VM を構成する多くのコンポーネント（ディスク、ネットワーク、管理ソフトウェアなど）は、元のホスト マシンとマイグレート先となるマシンにデュプリケートされます。マイグレーション中のどこかで、その 1 つでも障害を起こせば、それがアクティブ（クラッシュなど）なものであれパッシブ（消失など）なものであれ、実行中の VM に影響を与えずにマイグレーションを完全に取り消します。
どのように動作しているのか
実行中の VM をあるホストから別のホストへマイグレーションするとき、ゲスト VM と、それと通信している全てに対して透過的な方法で、マイグレーション元から先へすべての状態を移す必要があります。これをシームレスに行うには、多くのコンポーネントが関与してくるのですが、ここでは、大まかなステップを見ていきます:
マイグレーションのプロセスは、VM を現在のホストマシンから移さなければならないという通知から始まります。その通知には、ファイルへの変更（例えば、リリース エンジニアが新しい BIOS が利用できるようになったことを指摘するため）、ハードウェアへのオペレーションのための定期メンテナンス、ハードウェア障害が起こりそうなときに発生する自動的なシグナルなどから始まります。
Google のクラスター マネージメント ソフトウェアは、データセンターやジョブを制御するポリシー（た（例えば、データセンターの最大稼働率や、ジョブにおいて 1 ユーザーのために 1 度にマイグレーションできる VM の数であるとか）に従って、こうしたイベントやメンテナンス スケジュールを監視しています。
マイグレーションの対象となる VM を選択されたら、マイグレーションが差し迫っていることをゲスト VM に通知します。一定期間経過した後、マイグレーション先となるホストが選ばれ、そのホストでマイグレーション元の VM を受け入れる先となる新しい空の VM をセットアップするように依頼します。図の中の認証（Authentication）は、マイグレーション元と先との接続を確立するためです。
VM のマイグレーションには次の 3 つのステージがあります:
最終的にマイグレーションが完了すると、システムはマイグレーション元の VM を削除します。マイグレーションが実行されたことは、ログからわかります。
全てにおいて透過的にメンテナンスしていくことには、たった 1 つの VM でさえも犠牲にしないという目標があります。これを達成するため、超高レベルの厳格なテストをライブ マイグレーションに対して実施してきました。マイグレーション アルゴリズムの中で注意すべきポイントの全てで、障害を引き起こすためにフォールト インジェクションを使い、それぞれのコンポーネントごとにアクティブとパッシブの障害の両方を生成します。デベロップメント テスト（数か月にわたる）のピーク時には、毎日数万回のマイグレーション テストを実施してきました。
このような複雑で多面性のあるプロセスを行うには、インフラストラクチャーの隅々にまで、強力なスケジューリング、オーケストレーション、オートメーションの組み合わせを深くインテグレーションすることが求められます。
まとめ
ライブ マイグレーション テクノロジーによって、ゲスト VM への影響なくインフラストラクチャーを最高の状態に維持することができます。Google が VM を不老不死にしたと主張するレビュワーもいました。定期的、非計画的メンテナンスが要求される中、物理マシンの再起動が必要な数多くの問題がありながらも、長期間 VM を実行し続けることが可能となっています。
最近発生した、他のクラウド プロバイダに影響を与えたセキュリティ上の問題のいくつかが、私たちに影響がなかったように、今後発生しうる新たな脆弱性に対しても、Google は VM への影響なくCompute Engine を保護できるようにしていきます。
-Posted by Miche Baker-Harvey, Tech Lead/Manager, VM Migration
はじめに
去年の春、2014 年 4 月 7 日に起きたことを覚えていますか？ その日に起きたことではなく、起きなかったことが今日のポストの主題です。
その日は Heartbleed バグが公表された日で、ゼロデイ攻撃に対処するため、この脆弱性のパッチをシステムに当てようと世界中の人たちが対応していました。Google Clodu Platform 以外のパブリッククラウドのプラットフォームを利用していたら VM を再起動、あるいは少なくとも対象の各ノードで SSL ライブラリを更新し、Web サーバーを再起動しなければならないという影響を受けました。Google でも、 Google Compute Engine でホストするサーバーを含むすべてのサーバーを直ちに修正しました。でも誰一人として気づくことはありませんでした。つまり起きなかったのです。
2013 年 12 月、Google Compute Engine にトランスペアレント メンテナンス（透過的なメンテナンス）を導入しました。それ以来、ソフトウェアのアップデート、ハードウェア問題の解決、予期しない問題の解決があっても VM を止めずに稼働させています。データセンター トポロジーのイノベーションと、ライブ マイグレーション テクノロジーを組み合わせることで、定期的なハードウェアやソフトウェアのメンテナンスがあったとしても、それに VM が影響を受けないようにし、VM、アプリケーション、ワークロード、そのどこにも何も起こらかなかったかのように、インフラを保護し高い信頼性を保てるようにしています。
ライブ マイグレーションによって Google が目指したのは、VM を再起動することなく、すべてのデータセンターにあるハードウェアやソフトウェアを最新の状態に保つことです。こういったメンテナンスは、ホストマシンの再起動が必要となるため、透過的なメンテナンスがないのなら、当然 VM にも影響がでます。
ライブ マイグレーションで解決するであろう問題は例えば次のようなものです。これらは実際に私たちが遭遇してきたも問題です。
- インフラの定期的なメンテナンスやアップグレード
- データセンターにおけるネットワークや送電網のメンテナンス
- 不良のメモリ、ディスクドライブ、マシン
- ホストの OS や BIOS のアップグレード
- 直ぐに対策を要するセキュリティ関連のアップデート
- ホストのルートパーティション、ホストのイメージやパッケージ用ストレージのサイズ変更を含むシステム構成の変更
皆さんが運用の中で様々な問題に直面したときに、ライブ マイグレーションがどれだけ役立っているかを知って驚きました。実際、サイトの信頼性に係わるエンジニアは、まだライブ マイグレーションが皆さんに提供されていなかったころにもツールとして使い、プロダクション時に起きる可能性のある障害への対処や、あるいは軽減していました。
以下は、予期せず実際に発生したものの、実行中のゲスト OS には影響なく対処できた問題です。
- ネットワークカードのフラッピング : ネットワークカードは時々故障します。VM のマイグレーションを繰り返し試み、無事にマイグレートできました。これは一部のみ故障する NIC でも効果があります。
- バッテリ / 電源の問題の波及 : 過熱したバッテリの中には隣接するマシンを過熱させるものがありました。VM をマイグレートしてから、マシンを停止してバッテリを交換することができました。
- バグのあるアップデートが稼働マシンに紛れ込んだ : ロールアウトを停止しましたが、稼働マシンには達してしまいました（Canary 環境では出現せず）。バギーなソフトウェアであれば 1 週間もせずに VM 群をクラッシュさせていたと思います。ここでは、影響を受けたマシンの VM 群をバギーではない他のマシンにマイグレートしました。
- 予期しないホストのメモリ消費 : バックエンドのコンポーネントの 1 つはアロケートされた以上のメモリを消費し、VM で OOM（out of memory：メモリ不足）の兆候を示していました。過負荷のマシンから VM をいくつかマイグレードして OOM を回避すると同時に、バックエンドのシステムにパッチを当ててメモリの割り当てを超えないようにしました。
トランスペアレント メンテナンスの実施
導入後、マイグレーションは数十万回実施されてきています。多くの VM はマイグレーション導入後に立ち上げられて、すべて複数回マイグレートされました。反応は非常に好意的です。初期のマイグレーションのテスト期間中は、Rightscale でマイグレーションの効果を調べました。対象の VM をすべて 2 回マイグレートした後、次のようなレポートが得られました。
「ログファイルを調べましたが、データベースの中の全データは…まったく異常ありません。もしインスタンスがマイグレートされていたことを Google が教えてくれていなかったとしたら、まったくわかりませんでした。すべてのログとデータは正常ですし、RightScale のクラウド管理 ダッシュボードには、ゾーン、インスタンスのサイズ、IP アドレス、リソースなど、いずれも変化はありませんでした」。
ServerDensity の David Mytton 氏と協働で、レプリケートした MongoDB をライブ マイグレーションしたところ、マイグレーション終了後に David はツイートしました。
実際 Google は、ホストへのカーネルのアップグレードと全 VM にセキュリティ パッチ当てを、どの VM も欠けることなく行っています。そこに含まれる大量のコンポーネント、さらにその依存関係までが、どの時点においても 1 つとして障害を起こしたり、失うことがなかったことを考えると驚異的なことだと思いませんか？ マイグレーションの間、VM を構成する多くのコンポーネント（ディスク、ネットワーク、管理ソフトウェアなど）は、元のホスト マシンとマイグレート先となるマシンにデュプリケートされます。マイグレーション中のどこかで、その 1 つでも障害を起こせば、それがアクティブ（クラッシュなど）なものであれパッシブ（消失など）なものであれ、実行中の VM に影響を与えずにマイグレーションを完全に取り消します。
どのように動作しているのか
実行中の VM をあるホストから別のホストへマイグレーションするとき、ゲスト VM と、それと通信している全てに対して透過的な方法で、マイグレーション元から先へすべての状態を移す必要があります。これをシームレスに行うには、多くのコンポーネントが関与してくるのですが、ここでは、大まかなステップを見ていきます:
Google のクラスター マネージメント ソフトウェアは、データセンターやジョブを制御するポリシー（た（例えば、データセンターの最大稼働率や、ジョブにおいて 1 ユーザーのために 1 度にマイグレーションできる VM の数であるとか）に従って、こうしたイベントやメンテナンス スケジュールを監視しています。
マイグレーションの対象となる VM を選択されたら、マイグレーションが差し迫っていることをゲスト VM に通知します。一定期間経過した後、マイグレーション先となるホストが選ばれ、そのホストでマイグレーション元の VM を受け入れる先となる新しい空の VM をセットアップするように依頼します。図の中の認証（Authentication）は、マイグレーション元と先との接続を確立するためです。
VM のマイグレーションには次の 3 つのステージがあります:
- 予定されたマイグレーションが行われるまでの間、ほとんどの状態をマイグレーション先へと送信しながら VM はマイグレーション元で動作します。この期間に、例えばすべてのゲスト VM のメモリをマイグレーション先へコピーすると同時に、再度変更されたページがないか追跡しています。この状態がどれだけ続くかは、ゲスト VM のメモリー サイズや、そのページが変更される率（ダーティ状態の率）によります。
- 停止している間、VM が完全に実行を止める時間はほんの短い間ですが、一瞬停止し、マイグレーション先で VM が動作を始めるために必要な残りの状態が送信されます。停止状態に入るのは、マイグレート前の準備期間中の状態の送信が、動作状況に対して増えなくなったポイントに達したときです。ここでは特に、送られるメモリのバイト数とゲスト VM がページを変更する率とのバランスをとるアルゴリズムを採用しています。
- マイグレート後の一定期間、VM はマイグレーション先で実行されていますが、マイグレーション元の VM もそのままマイグレーション先をサポートする機能を提供していることがあります。例えば、ネットワーク ファブリックが VM の新しいローケーションで用意できるまで、マイグレーション元の VM は、マイグレーション先の VM が送受信するパケットの転送サービスを提供します。
最終的にマイグレーションが完了すると、システムはマイグレーション元の VM を削除します。マイグレーションが実行されたことは、ログからわかります。
全てにおいて透過的にメンテナンスしていくことには、たった 1 つの VM でさえも犠牲にしないという目標があります。これを達成するため、超高レベルの厳格なテストをライブ マイグレーションに対して実施してきました。マイグレーション アルゴリズムの中で注意すべきポイントの全てで、障害を引き起こすためにフォールト インジェクションを使い、それぞれのコンポーネントごとにアクティブとパッシブの障害の両方を生成します。デベロップメント テスト（数か月にわたる）のピーク時には、毎日数万回のマイグレーション テストを実施してきました。
このような複雑で多面性のあるプロセスを行うには、インフラストラクチャーの隅々にまで、強力なスケジューリング、オーケストレーション、オートメーションの組み合わせを深くインテグレーションすることが求められます。
まとめ
ライブ マイグレーション テクノロジーによって、ゲスト VM への影響なくインフラストラクチャーを最高の状態に維持することができます。Google が VM を不老不死にしたと主張するレビュワーもいました。定期的、非計画的メンテナンスが要求される中、物理マシンの再起動が必要な数多くの問題がありながらも、長期間 VM を実行し続けることが可能となっています。
最近発生した、他のクラウド プロバイダに影響を与えたセキュリティ上の問題のいくつかが、私たちに影響がなかったように、今後発生しうる新たな脆弱性に対しても、Google は VM への影響なくCompute Engine を保護できるようにしていきます。
-Posted by Miche Baker-Harvey, Tech Lead/Manager, VM Migration
0 件のコメント :
コメントを投稿