Azure Stack IaaS基盤

Azureが使っているハイパーバイザーと管理ツールって何?

本題に入る前に、少しだけパブリッククラウド「Microsoft Azure」のお話をしましょう。パブリッククラウドでIaaSと言えば仮想マシンのサービスであり、仮想化基盤がなくては始まりません。メガクラウドの1つとして知られるMicrosoft Azureも例外ではなく、その仮想化基盤としては「Hyper-V」が世界中の利用者にサービスを提供しています。

ただし、Microsoft Azureの場合、データセンターによっては物理サーバが100万台あって、1つのクラスタでサーバ1,000台単位を管理するような世界であるため、オンプレミスで重宝されている「Microsoft Failover Cluster（以下、フェールオーバークラスタ）」や「System Center Virtual Machine Manager」のような仮想化基盤管理ツールは使われておらず、APIやスクリプト中心の自動化された管理基盤になっています。

「仮想化の管理ツールを使わずに仮想化基盤を運用する」と聞くと、日本のエンジニアの中には信じられないと思われる方がいるかもしれませんが、メガクラウドの世界では、基盤に対する考え方が大きく違うのです。例えばオンプレミスの場合、〇×表でさまざまな製品を機能比較し、多彩な機能を持つ仮想化基盤を選びがちですが、クラウドはサービス指向なのでサービスに不要な機能はそもそも基盤に入りません。つまり、「ないよりあったほうがいい」のではなく「余計なものはないほうがいい」という考え方なのです。

今ではHyper-Vも十分に安定していて性能も出ますし、もともとWindowsはWMI（Windows Management Instrumentation）というAPIがあるので、コントロールもしやすくなっています。こうしたことから、Microsoft Azureチームは試行錯誤しつつも、Hyper-Vベースでクラウドを構築・運用するための独自の管理基盤を作り上げたわけです。

Azure StackもHyper-Vで動いている!

それでは、Azure Stackに話を戻しましょう。Azure Stackは、Azureファーストなプライベートクラウドなので、できる限りMicrosoft Azureの要素をオンプレミスに持ち込むスタイルになっています。したがって当然、Azure Stack IaaSの仮想化基盤はHyper-Vが基本です。Azure Stackは拡張性があるため、「Hyper-Vしか動かない」と断言はしませんが、少なくとも現在提供されているAzure Stack TP1では、インストール後に物理マシンにログオンするとHyper-Vが動作していることを確認できます。

Azure Stack導入後に、ホストでHyper-Vマネージャを立ち上げたところ

Azure Stack TP1では、自動インストールの処理のなかで全ての設定が完了しているため、自発的にHyper-Vを導入した感覚はしないでしょう。Azure Stackにおけるハイパーパイザーはあくまでも要素技術なので、積極的に前面に出てくると言うよりも、Azure Stackサービスを支えることに専念している裏方のように見えます。

とは言え、IaaSに仮想化基盤は必須ですし、Azure Stackのコア技術の1つでもあるので、Hyper-Vが持つ役割はとても重要です。もし、「Hyper-VのことはよくわからないけどAzure Stackに興味がある」という方は、これを機にHyper-Vがどのようなものかを理解しておくと良いでしょう。

Azure Stack の中核を成すモノ

ここで、マイクロソフトが提供する現行のプライベートクラウドツール「Windows Azure Pack」とAzure Stackの簡易アーキテクチャ図を比較してみましょう。

Windows Azure PackとMicrosoft Azure Stackの簡易アーキテクチャの違い

左側のWindows Azure PackにはWindows Serverの上にSystem Centerが組み込まれ、仮想化基盤をAPIで管理するための「Service Management API層」がポータルとやり取りをしています。

対して右側のAzure Stackでは、Microsoft Azureの管理基盤でもある「Azure Resource Manager」が管理層にあり、その下にはいきなり「Compute」「Storage」「Network」のRP(Resource Provider)が存在しているのがわかると思います。

そう、「Azure Stackを動かす」という目的を達するためにSystem Centerは不要だということです。もちろん、System Center自体の有効性の話をしているわけではありません。オンプレミスにてAzure Stackというハードウェアソリューションを導入するわけですから、管理製品としてSystem Centerの出番が出てくる可能性は十分にあります。しかし、仮想化基盤をベースにクラウドを作ろうとしてきたこれまでのプライベートクラウドと、完全なるサービス志向で作られた「Microsoft Azureのオンプレミス版」とも言える新しいプライベートクラウドでは、スタンスが違うのです。

Azure Stackを導入することで、Microsoft Azureと同様に自動化が当たり前になるということが、こうしたスタンスからもおわかりいただけるのではないかと思います。

ただし、このAzure Stackの図には書いてない物があります。それはフェールオーバークラスタです。第4回の記事でも説明したとおり、Azure Stack TP1ではWindows Serverのフェールオーバークラスタが採用されています。現時点では物理サーバ1台での構成しかできないため、物理サーバがダウンした際の自動フェールオーバーや複数台をまたぐ管理時の注意点などは今後の動向に注目していただく必要がありますが、Azure Stack上でユーザーが作成した仮想マシンもフェールオーバークラスタに自動登録されるところを見ると、Azure Stackとフェールオーバークラスタの間にはそれなりの依存関係がありそうにも見受けられます。

そして何より、フェールオーバークラスタ採用の裏側には、Windows Server 2016で作るハイパーコンバージドインフラの話が関係しているように思えます。これまでの仮想化基盤は、複数台のHyper-Vホストと共有ストレージ装置で構成するのが一般的でした。Hyper-Vとストレージの間のプロトコルがSMB3になっても、基本的な構成パターンは変わらなかったのです。

しかし今、ハイパーバイザーとストレージが同一筐体内にある状態で、複数台のサーバを高速なネットワークで横に並べてシステムを拡張させるハイパーコンバージドモデルが流行り始めています。マイクロソフトもWindows Server 2016でこの構成ができるようになり、Azure Stack のTP1ではこの形をとっています。

Windows Server 2016で作るハイパーコンバージドインフラ

*　*　*

このように、IaaS基盤としてのAzure Stackの内部では、Windows Server 2016のHyper-Vやフェールオーバークラスタ、ハイパーコンバージド設計など、いくつかの最新技術に出くわすことができます。Microsoft AzureとAzure Stackの両方を知り、共通する部分と明らかに違う部分を理解することで、Azure Stackはより身近になっていくことでしょう。

さて今回は、Azure StackのIaaSとしての基盤について説明しました。次回以降はしばらく、Azure StackのPaaSの作り方と操作方法について別の執筆者より解説してもらえることになっています。お楽しみに!