Azure Stackのアーキテクチャを見てみよう(その2)

前回、Azure Stackのポータルと、ハイブリッドな管理基盤「Azure Resource Manager」について説明しました。強力なライバルたちと戦うMicrosoft Azureのクラウドとしての進化を、手元で動かせるAzure Stackとしてどのように受け止め、どのように実装しているのか少しはイメージしていただけたのではないでしょうか。それらを踏まえ、今回は「Core Services」や「Foundational Services」について説明します。

Azure Stack におけるCore ServicesとFoundational Servicesの位置づけ

Azure StackのCore Services

Azure Stackは単なる仮想化基盤ではないため、クラウドとして必要な機能が組み込まれています。その1つがCore Servicesです。Core Servicesは、以下のようなものを管理する役割を担っています。

・ Subscriptions
・ Role-based access control(RBAC：役割ベースのアクセス制御)
・ Gallery
・ Metrics
・ Usage

例えば、Azure Stackを使ってクラウドサービスを提供する側に立ったとすると、利用者であるお客様に利用料を請求することになります。この課金処理を正確に実施するためには、どの利用者がどの程度リソースを使ったのかといった情報を持っている必要があります。そこで、利用者によるリソースの使用状況を把握する手段として使われるのがCore Servicesの「Usage」です。

また、そのUsageの情報を特定の利用者と紐付ける必要があります。第3回の記事でも紹介したとおり、Azure Stackを利用するには「Get a Subscription（サブスクリプションの取得）」という処理が必要です。この作業によって利用者にはSubscription IDが割り当てられ、そのIDでAzure Stack上にリソースを作成することになります。Azure Stackでは、利用者の作業も、作られるリソースもSubscriptionと紐づけられるので、Subscriptionの管理を行うCore Servicesはとても重要な役割を担っていると言えます。

Azure Stackのステータスは現在Technical Preview 1で、Core Servicesについての情報はほとんどありませんが、「Gallery」やRBACの管理などもこのレイヤで行われているようです。この辺りについては、今後Azure Stackが登場するまでの間にアップデートがあればお伝えするつもりです。

Foundational Servicesが管理する4つのサービス

Azure StackはPaaSもIaaSも含めた、さまざまなサービスを提供可能なクラウドですが、Foundation Servicesはその全てに関わる基盤として、以下のサービスを管理します。

・ Compute
・ Storage
・ Networking
・ Platform Services

まずは一般的な仮想化環境を振り返ってみましょう。ハイパーバイザー用のサーバが数台、ファイバーチャネルなどで共有ストレージに接続されているような環境では、メインは仮想化基盤であって、ストレージはその基盤を構成する部品でしかありません。ネットワークは既に社内のルールに基づいて結線され、仮想化基盤を導入するためにVLANの設定などが行われます。利用者は「あくまでも割り当てられたネットワークを利用するだけ」とも言えます。

しかし、第5回の記事で解説したように、Azure Stackで仮想マシンを作成する際には、利用者自身が意識的にストレージとネットワークを設定することになります。なぜなら、Azure Stackでは、ストレージもネットワークも独立したサービスだからです。Azure StackにおけるFoundational Servicesは、Compute(仮想マシン)、Storage、Networkingといった独立したサービスを管理する役割を担っています。そして、そのFoundational Servicesと連動するのが、冒頭の図にある「クラウドインフラ」の部分です。

Azure Stackのクラウドインフラには、まもなく登場予定の「Windows Server 2016」が利用されます。ハイパーバイザー層はMicrosoft Azureの基盤としても利用されている「Hyper-V」です。もしHyper-Vの実績を疑う方がいたら、巨大なデータセンターで動くMicrosoft Azureを思い浮かべていただければそれで十分でしょう。日本で1年間に購入される物理サーバ台数よりも多い数のHyper-Vが、Microsoft Azureで既に稼働しているのですから……。

また、Windows Server 2016のSDS（Software Defined Storage）も大きな進化を遂げました。ストレージのプール化や階層化は既に提供済みですが、共有ストレージが不要な「Storage Spaces Direct」によって、ローカルストレージしか持っていない複数台のHyper-V環境を1つのクラスター環境として束ねて利用することが可能になっています。ストレージとしての同期/非同期レプリケーションや、ポリシーベースのQoSといった機能も追加されました。

さらに、Azure Stackの基盤としてのストレージは、Microsoft Azureのストレージと同様に遠隔地への非同期レプリケーションが行える可能性があります。現時点でのAzure Stackは物理1台構成のため試すことができませんが、Azure Stackのストレージアカウントの設定には「ローカルに3つの複製、遠隔地に3つの複製」の合計6つを確保可能にするGeo-Redundantストレージ設定が用意されています。

Azure Stackストレージアカウントの設定に出てくるGeo-Redundant設定

一方、SDN（Software Defined Networking）に関してもMicrosoft Azureと同様の機能を提供すべく進化しています。大きなところでは、VXLAN（Virtual eXtensible Local Area Network）によるオーバーレイネットワークの提供や、NFV（Network Functions Virtualization）としてソフトウェアロードバランサーや分散ファイアウォールを提供するなどです。Azure Stackのインフラとして重要な役割を果たすHyper-VやSDN/SDSについては、別途紹介する予定ですのでお楽しみに。

*　*　*

さて、今回は、Azure Stackをクラウドサービスとして利用する際に必要となるCore ServicesやFoundational Servicesについて解説しました。次回は、Azure Stackの拡張性について解説します。