【IIJ GIOの裏側を語る#4】 無停止運用を目指したライブマイグレーション

カテゴリー: 裏側を語る   パーマリンク
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第4回です。

前回の本ブログで触れたとおり、今回はP2の運用プロセスについてお話しします。
解説者は引き続き、IIJクラウド本部の田口です。

keisuk-t_01_150

執筆者の紹介

株式会社インターネットイニシアティブ
クラウド本部 クラウドサービス1部 部長
田口 景介

「第4回:無停止運用を目指したライブマイグレーション」

突然ですが、以下の図は、昨年のカレンダーにメンテナンスを実施した日にチェックを付けた記録です。

giomente3

ご覧になっていかがでしょうか。多いと感じられますか?それとも見慣れた頻度に感じられますか?おそらく、大半の方には、単一システムのメンテナンス頻度としては、度を超えて多いと感じられるのではないでしょうか。

それぞれのメンテナンスは大小様々です。
大掛かりな新サービスメニューをリリースするメンテナンス、定期的に実施されるサーバプールやストレージの増設メンテナンス、ハードウェア障害に伴う保守交換作業、脆弱性対応のための緊急システムアップデート、一部リソースにかかる負荷を平準化させるためのマイグレーションなど、内容は多岐にわたります。

これだけの頻度でメンテナンスが実施されるのは、それだけIaaSというものが他のサービスに比較して相当に複雑なものであり、数十のマイクロサービスから構成されていることが理由の一つです。

サービスを停めないメンテナンス戦略

かようにP2では頻繁にメンテナンスが実施されているわけですが、実のところサービス停止を伴うメンテナンスは1度しか行われていません。しかも、それはコントロールパネルが停止されるだけで、仮想サーバやネットワークアプライアンス類のリソースが停止するものではありません。

P2をご利用いただいているお客様にも、これほどメンテナンスが実施されているとは思われていないのではないでしょうか。

それはIaaSとして当然のように感じられるかもしれませんが、何の戦略もなく実現することではありません。サービスの設計段階からシステムの更新を無停止で行うことをスペックに盛り込み、実装されているからこそ可能なのです。

また、メンテナンスを無停止で実行できるということは、障害に対する可用性が高いことも意味しています。残念ながら昨年ネットワーク障害に起因するサービス停止を発生させてしまいましたが(大変申し訳ありません・・・)、それを除けば設計どおりの品質を担保できたのではないでしょうか。

避けられないハードウェア障害

もっとも、サーバのハードウェア障害はいかんともしがたく、即仮想サーバの停止に至ります。

稀にクラウドサービスはいかなる障害にも耐性があると思われ、たとえサーバにハードウェア障害が起ころうとも無停止で利用できることを期待される方がいらっしゃいます。しかし、IaaSにおいてサーバの冗長化は利用者の責任とされていますので、この点はどうかご容赦ください。

もっとも、いったん停止しても自動的に別筐体が割り当てられるので、すぐに起動が可能です。また、グループを分けてアクティブ・スタンバイに構成することで、物理的にネットワークやサーバを分離して複数の仮想サーバを収容することが可能です。

ハイパーバイザのメンテナンス

それでは、ハードウェア障害による停止はやむを得ないとして、仮想サーバが収容されるハイパーバイザノードにメンテナンスが必要になった場合、どうなるでしょう?

もしハイパーバイザの再起動が必要となれば、それは障害発生時と同じことで、仮想サーバの停止を伴うことになります。IaaS基盤の都合に合わせてお客様の仮想サーバを停止することはおいそれとできませんが、かといって仮想サーバを動かしたままハイパーバイザをアップデートすることもできません。

そこで活躍するのがライブマイグレーションです。ご存じの方も多いと思いますが、ハイパーバイザからハイパーバイザへ、仮想サーバを停めることなく移動させる技術です。

P2の運用にはライブマイグレーションが積極的に活用されており、メンテナンスが必要な時、あるいは特定のリソースに過剰な負荷が集中しているとき、ライブマイグレーションを利用して仮想サーバを停めずにさまざまな作業を実施しています。

hyper_5

ライブマイグレーションを前提とした設計

ただし、ライブマイグレーションは便利な技術ですが、どんなIaaSでも利用されているわけではありません。それは、利用を前提にサービスがデザインされていなければならないからです。

ライブマイグレーションとは、仮想サーバのCPUやメモリなどの状態を別ハイパーバイザ上へ転送し、後にストレージをつなぎ直し、IPアドレス等のリソースを再度割り当てることで、仮想サーバを移動させる技術です。これを短時間に実行するために、ローカルディスクのように別筐体へつなぎ直すことができないストレージはサービススペックに盛り込めません。逆に言えば、ローカルディスクを提供しているIaaSでは、ライブマイグレーションを利用できない可能性が高いのです。

また、ごくまれにゲストOS(の特定のカーネルバージョン)によっては、ライブマイグレーションに失敗するケースが存在します。例えば、一見マイグレーションに成功したかに見えても、パケットを受信できなくなるなどの症状が発生し得ます。したがって、検証済みのOSのみ利用できるようにすることがサービスを安定運用する一つの条件になります。

つまり、サービスを安定運用するためのライブマイグレーションと、いくつかのサービススペックの有無はトレードオフの関係にあるのです。

膨大なサーバを半自動的にアップデートする仕組み

もっとも、ライブマイグレーションが利用できたとしても、数千、数万というサーバから構成されるIaaS基盤において、仮想サーバを一切停めずにハイパーバイザのアップグレードを実施するのは簡単なことではありません。手作業では困難なものになることは容易に想像ができるでしょう。

その点、P2の基盤にはハイパーバイザを半自動的にアップデートする仕組みが実装されていますし、必要とあらばライブマイグレーションを活用することもできるので、無停止でハイパーバイザを更新することが可能です。その仕組みを簡単に紹介しましょう。

まず、P2のハイパーバイザサーバは起動時に最新のソフトウェアを使ってリモートブートし、自動的に構成されて稼働を始めます。つまり、サーバを再起動するだけで最新のハイパーバイザへアップデートが完了します。

そこで、まず仮想サーバを一つも収容していない空のハイパーバイザサーバへ再起動するように指示を出します。すると、それ以降に起動される仮想サーバはアップデート済みのハイパーバイザにだけ収容される仕組みになっているので、仮想サーバが停止されるに従い旧バージョンのハイパーバイザから仮想サーバが抜けていきます。

そして、空になったハイパーバイザは自動的に再起動され、徐々にアップデートが進んでいきます。その後、一定期間経過してもアップデートされていないサーバのみライブマイグレーションを利用し、手作業でのアップデートを実行、これで完了です。

このように、随所に無停止かつ自動化された運用プロセスがサービス開発当初から計画されており、それがサービスデザイン、システムデザインに反映されているがゆえに、常にセキュアで安定したIaaSがご提供できているのです。


次回は、他社と一線を画すIIJのVMwareサービス「VWシリーズ」について解説します。

コメントは受け付けていません。