これがAzure Stackの全体像! 10個の仮想マシンの役割とは？

物理マシン1台で作るAzure Stack TP1は簡易的なものなのか?

第2回の記事でAzure Stackのセットアップが自動化されていることや、Azure Stack Technical Preview 1（TP1）が物理マシン1台の上に作られることなどを紹介しました。読者の中には「TP1はベータ版相当だから、簡易的な環境が作られているのだろう」と思われた方がいるかもしれません。しかし、実際のAzure Stack TP1は、将来データセンタでAzure Stackが動くことを想定し、最新の技術要素を盛り込んだ構成になっています。

例えば、IaaS（Infrastructure as a Service ）に相当する部分では、最新のハイパーバイザやSoftware Defined Network（SDN）、Network Functions Virtualization（NFV）、Software Defined Storage（SDS）が使われています。また、ベース技術には、Azure Stack環境の安定運用とアップデート作業をサポートする新しいサービス実行基盤を採用しています。パブリッククラウドAzureが年に数百ものアップデートを行える理由は、サービス開発の速さに加え、更新されることを前提に作られたアーキテクチャだからです。そして、Azure Stackはその仕組みを受け継いでいます。

現在開発中のAzure Stackの解説の中には、耳慣れない技術の名前が出てくることも少なくないため、不安を感じる方もいるでしょう。しかしその技術の多くが、すでに世界中の企業が何年も使っているAzureで採用されている技術であることを知れば、導入の敷居も下がるのではないかと考えています。

さて、ここからは自動セットアップによって物理マシンと仮想マシンの両方に分散して組み込まれた機能について見て行きましょう。

Azure Stackの全体像

まずはこちらの図をご覧ください。

Azure Stackセットアップ後の機能配置

物理マシンでは、Hyper-V Hostとストレージ系のサービスが動いています。また、「～VM」と書かれているのが仮想マシンで、合計10個あります。ただ、10個並べるとわかりにくいので、これらを4つのグループに分けてみましょう。

(1) Azure Stackのコア基盤

• ADVM　　 ：Azure Stackシステムをセキュアに稼働させるための認証基盤
• SQLVM　 ：Azure Stackシステムの基礎となるデータベース
• PortalVM ：Azure StackのユーザーインタフェースやAPI部分を担当するWebサーバ
• xRPVM　 ：各種サービスとAzure Stackのスムーズな連携を担当するサーバ　
  　　　　　（新しいサービスを容易に追加できるのも、このVMのおかげ）

(2) Azure Stackのストレージ基盤

• 物理マシン　：複数の物理ディスクをプール化して、データを格納するバックエンドサービス
• ACSVM　　：BlobやKey-Value型のストレージサービスを提供するフロントエンドサービス

(3) Azure Stackのネットワーク基盤

• 物理マシン　：Hyper-V Hostの物理ネットワークカードと仮想スイッチ（エクステンションが重要）
• NCVM　　：Azureから引き継がれたSDNのコントローラ
• MuxVM　　：Software Load Balancerなどをテナントネットワークに提供
• BGPVM　　：Azure Stackシステムの内部と外部を接続

(4) Azure Stack TP1を使いやすく（試しやすく）するための仮想マシン

• ClientVM　：前回紹介したようなAzure Stackポータルへの誘導やスムーズな操作を支援
• NATVM 　　：別のPCからAzure Stack環境にリモート接続する際の入口

こうしてグループ分けをしてみるとわかるとおり、（1）がコア基盤としてAzure Stackのクラウドコントローラ部分をカバーしています。見慣れないxRPVMについて軽く触れておくと、AzureやAzure Stackでは、Resource Provider（RP）というモジュールをAzure Stackに追加することで、新しいサービスを簡単にAzureの世界に取り込めるようにしています。その仕組みをつかさどるのがxRPVMで、さまざまなRPを受け止め、各サービスとAzure Stackをつなぐ役割を担っています。

そして、（2）のストレージ基盤がストレージサービスや仮想マシンの置き場所を提供し、（3）のネットワーク基盤があるからこそ、柔軟でセルフサービスも可能なネットワークが提供できます。また、（4）はAzure Stackそのものを支える基盤というより、利便性を高めるために提供されているものととらえてよいかもしれません。

Azureとの大きな違いを知る（1） ～ストレージ～

Azure StackはAzureの環境を自社内で作るためのものであり、基本的な考え方としてAzureとAzure Stackには同じ技術が使われています。しかし、その考えにこだわりすぎると、利用者が考える理想の基盤から遠ざかってしまう可能性がないとも言えません。例えば、ストレージです。

パブリッククラウドAzureのストレージサービスは、PCサーバで構築され、すでに10兆個以上のオブジェクトを保持する巨大なサービスとなっています。このAzure上のStorage Serviceをそのまま社内に展開しようとすると、「Azure Stack環境を構築する前提条件として、ストレージ用のサーバを100台用意してください」といったことになりかねません。それでは、プライベートクラウド構築の敷居が高くなってしまいます。そこでAzure Stackでは、次期サーバOSであるWindows Server 2016標準のストレージ機能をフル活用した構成をとることで、少数のサーバでもAzure Stackの構築を可能にしています。

ただし、「Windows Server標準のストレージ機能に無いBlobやTableサービスの提供をどうするか」という課題もあります。これを解決すべく、Azure Stack TP1では、ACSVMという仮想マシンが用意され、BlobやTableサービスを提供するフロントエンドサービスが動作しています。最終的なデータ保持は、物理サーバで動くWindows Serverのストレージ機能に集約されているので、ACSVMというフロントエンドサービスと、ディスクをプール化して柔軟にデータ保管場所を提供するバックエンドサービスの連携によって、Azure Stackのストレージサービスが実現されているわけです。

Azureとの大きな違いを知る（2） ～フェールオーバークラスタの標準採用～

「止まらない仕組みを作りたい」――これは、誰もが願うことです。しかし、「IT（特にハードウェア）は壊れるもの」という事実も、また誰もが知るところです。では、壊れた時にどのような対応をするのか? について考えてみましょう。PaaS（Platform as a Service）やIaaSなど、その仕組みによって可用性の高め方は異なりますが、できるだけアプリケーションに近いところで可用性を確立することをマイクロソフトは推奨しています。

ただ、多くの方が利用するIaaSはどうすればよいのでしょうか。例えば、1つのデータセンタに、100万台以上の物理サーバがあるAzureの環境では、当然物理障害も頻繁に起きています。そこで、サービス監視が徹底され、不具合があれば大量のリソースのどこかの空き領域にて再起動させるといったことが自動化されています。また、複数の仮想マシンがすべて停止状態に陥らないよう、サービス状態の監視や通知機能に加えて、仮想マシンの配置時に単一障害点（SPOF：Single Point of Failure）を回避できる「可用性セット」という機能も提供しています。

しかし、オンプレミスでは大量にリソースがあることを前提に構成を考えるわけにもいきません。そこでAzure Stackでは、Azureから引き継いだ「可用性セット」機能に加えて、Windows Serverの標準機能でもある「フェールオーバークラスタ」がベースとして動いています。これにより、物理マシンとしてのHyper-Vやネットワークなどが障害を起こした場合には、事前に構成してある別の物理サーバへとサービスが移されます。また、Azure Stackの利用者がセルフサービスで仮想マシンを作った場合にも、自動的にフェールオーバークラスタのリソースとして仮想マシンが登録されるようになっているので、利用者の仮想マシンも物理障害時には自動フェールオーバします。その分、仮想マシンの作成作業が少し遅いと感じるかもしれませんが、オンプレミスならではの安心サービスがAzure Stackには加えられているのです。

フェールオーバークラスタ技術を使って可用性を高めたHyper-Vと、その上で動くAzure Stack

*　*　*

今回は、Azure Stack TP1の物理マシンや仮想マシンの構成、提供されるサービスのコンセプトなどについて説明しました。ここまでは管理者側の視点が多かったので、次回は、利用者の立場から見たAzure Stackについて解説します。