HPE Blog, Japan
1745830 メンバー
3941 オンライン
108723 解決策
新規ポスト
Tech_Power_blog

Microsoft Azure Stack 技術レポート Part 1

クラウド時代の到来とともに、多くの企業がパブリッククラウドの利用に動き出し始めています。しかし、業界規制や性能要件などの要因でシステムの一部をオンプレミスインフラに残すケースが少なくありません。しかし、例えばパブリッククラウドでMicrosoft Azureを利用しつつ、オンプレミスで別のシステムを利用する「ハイブリッドクラウド」環境では、アーキテクチャや維持管理、支払方法の違いから運用管理が非常に煩雑になることもあります。そこで、もしオンプレミスのシステムをクラウドと同じ運用スタイル、同じアプリケーションで稼働、さらに支払方法を統一すれば、“理想のハイブリッドクラウド”の運用環境が実現する。これが、Microsoft Azure Stackが生まれた背景です。

今回は、そのMicrosoft Azure Stackの概観をご紹介したいと思います。

 

Microsoft Azure Stackとは?

Microsoft Azureで実証されたテクノロジーとイノベーションを、お客様のデータセンタに展開できるクラウド生まれのインフラストラクチャーです。Azureパブリッククラウドとオンプレミスの一貫性を持ち、利用感覚(ポータルやUI、SDKツール)から支払方法(Azureと同様の従量課金)までを統一した、ハイブリッドクラウドソリューションです。

  •  Azure 利用者のためのオンプレミス環境

Azureパブリッククラウド を利用しつつも、ネットワークレイテンシやコンプライアンス等の理由から、オンプレミス上でAzureのワークロードを処理する必要があるケースに対応します。

Azure パブリッククラウドの契約は必須で、 Azure Stack だけを単体で利用することはできず、Azureパブリッククラウドとのハイブリッド利用が前提です。

 

  • “Extending Microsoft Azure into your datacenter”

Azure 側で提供されている IaaS / PaaS サービスを オンプレミスでも利用可能

  • Azure パブリッククラウドを動かすためのエンジンとコードが利用されています。
  • 一般のオンプレミスのプライベートクラウドとは異なり、パブリッククラウド的な運用スタイルです。

 

  • ハードウェアベンダーからのアプライアンス提供のみ

正式リリース時はHPE / Dell EMC / Lenovo / Cisco の4社によるハードウェアとのセットでのみ販売されます。

  • ソフトウェア単体での販売は行われません。
  • プリインストール に近い形態で出荷されます。

図1. Microsoft社のHybrid Cloud戦略図1. Microsoft社のHybrid Cloud戦略

図2.同じUI:左:Public Azure、右:Microsoft Azure Stack図2.同じUI:左:Public Azure、右:Microsoft Azure Stack  

Microsoft Azure Stackのタイムライン

 Azure Stack商用版の正式リリースは2017年中旬を予定しています。下記図3で示した通り、Azure StackにはPoC版のシングルノード(正式名称:Azure Stack開発キット)と商用版のマルチノード(正式名称:Azure Stack Integrated System)という2種類のモデルが提供されます。

 図3. Azure Stackロードマップ(2017年5月現在)図3. Azure Stackロードマップ(2017年5月現在)

 シングルノードは、現在テクノロジープレビュー版のバイナリが一般公開されており、好きなサーバー上で動かすことができます。これに対し、マルチノード版は一般には非公開であり、お客様自身で自由に試すことはできません。現在は前述の4つのOEMベンダー内で、正式リリースに向けての検証が行われています。

 Azure Stackのソフトウェアライセンス提供方法は、従来とは異なります。買い切りではなく、実際の利用分を従量課金で、EA(Enterprise Agreement)やCSP(Cloud Solution Provider)の取次店がAzureパブリッククラウド利用料金と一緒に毎月請求します(EA契約の場合、コンピュートノードに搭載する CPU コア数をベースにした年間固定料金も用意される予定です)。

  

正式リリース(GA)までにできること

 前述の通り、商用構成のマルチノード版は今日時点では一般公開されていませんが、HPEはMicrosoftと強固なアライアンスを結んでおり、Azure Stackマルチノードの検証センター(HPE-Microsoft Azure Stack Innovation Center)を提供しています。マイクロソフト社員によるデモが実施できるほか、一般入手できないマルチノード環境を、日本を含めた各国からリモートアクセスして検証可能です。また、スイスのジュネーブとシンガポールのHPEオフィスにも同様の検証センターを提供しており、さらに拡大していく予定です。

 これに対し、PoCのシングルノード版は手軽に入手できます。既に試されている方が多いかもしれませんが、現在最新であるTechnical Preview 3(TP3)バージョンのリフレッシュ版のバイナリがMicrosoft Azure Stackのウェブページからダウンロード可能です。

このシングルノード版につきましては、HPEはエントリー/ハイパフォーマンスと2種類の推奨構成を記載したホワイトペーパー(英語版)も提供しています(エントリー構成に制限がありますので、後述のTP3の注意点をご参照ください)。正式リリースまでにAzure Stackの中身を少しでも知りたい方はぜひ上記のサイトを参考にしながらお試しください。

図4. Azure Stackの2つのバイナリと検証計画図4. Azure Stackの2つのバイナリと検証計画

シングルノード版は「開発キット」として正式リリース後にも引き続き提供されますので、将来Azure Stackの商用版を利用する傍ら、シングルノード版のホストに開発キットの正式リリースバージョンをインストールすることで、そのままテスト機として利用できます。両者は機能面においてほぼ差はありませんが、以下のポイントが異なります。

  ・ハードウェア構成:シングルノード版は1台のサーバー上でシステムをシミュレーションしますが、マルチノード版は最小4ノードからスタートし、最大16ノード(正式リリース時は12ノード)までサポートします。

 ・フェールオーバー機能:シングルノード版はテスト用でフェールオーバー機能が実装されていませんが、マルチノード版は「可用性セット」と「フェールオーバークラスタリング」が標準で実装されています。利用者が作成した仮想マシンなどは自動的にフェールオーバー対象として登録されますし、物理マシンやネットワークなどが障害した場合も、事前に構成してある別のノードへとサービスが移されます。

 ・ネットワーク:シングルノード版は仮想マシンを利用してネットワークスイッチをシミュレーションしています。

 ・容量:シングルノード版のサーバーはマルチノードシステムほど多くのワークロードを稼働できません

 

TP3を試す場合の注意点

 シングルノード版の最新バージョンであるTP3 refresh(4月版)を検証する場合、基本的にMicrosoftに公開されているデプロイガイドに沿って実施いただければ問題ありません。ここでは、ガイドに明記されていない注意点をいくつかアドバイスしましょう。

  • ハードウェアの推奨構成

Microsoft が提示している最小構成(特に1 OSディスク200GB, メモリ96GB)でシングルノード版のTP3 refreshを検証する場合、PaaSまでデプロイするとメモリのリソースが足りなくなる可能性があります(4月時点のオフィシャルガイドでは、PaaS機能の最低メモリは128GBが必要と記載されています)。また、ダウンロードしたバイナリを展開した後、ベースとなるOS ディスクの空き領域が不足し、途中でデプロイが失敗する可能性もあります(CloudBuilder.vhd展開後の空き領域は180GB以上必要)。

HPE社内で検証した結果、TP3 refreshがデプロイ直後に使用したメモリ容量は74GBと、必要最小構成を下回っていましたが、テスト用の仮想マシンや、PaaSサービスであるSQL ServerやApp Serviceまで展開すると、メモリの使用量が110GBを超えました。そのため、各機能を本格的に検証したい場合は、OSディスクが300GB以上、メモリが256GBあるハイパフォーマンス構成を推奨します。 

図5. 機能の拡充に合わせて管理系仮想マシン群のメモリ使用量も増えてきている図5. 機能の拡充に合わせて管理系仮想マシン群のメモリ使用量も増えてきている

  • デプロイに必要な事前情報
  •  ネットワーク環境

DHCPサーバーが存在しない環境では、ホストマシンとMAS-BGPNAT01(デプロイ中に自動作成され、ルータとして外部通信用を行う仮想マシン)用の静的IPアドレス、サブネット、ゲートウェイ、DNSサーバー、NTPサーバーのIPアドレスを用意しましょう。

Azureパブリッククラウド側との連携や、バイナリに含まれるWindows Server 2016評価版のライセンス認証のために、インターネット接続が必要です。

Microsoftのオフィシャルデプロイガイドに記載されたように、インターネットはプロキシを用いらずに接続できる環境が最も望ましいですが、TP3からこれまでと比べてプロキシによるトラブルは大きく改善されたため、プロキシ経由でも気軽に検証可能になりました。デプロイの際に最初にホストマシンとMAS-BGPNAT01にIE ブラウザのプロキシを設定してください。

Azure StackはHTTPを用いて内部通信をも行いますので、プロキシ設定の影響を受けます。DNSサーバーが異なるなど、設定しているプロキシサーバーがAzure Stack内部の名前解決をできない場合は、例外設定(Server Coreの仮想マシンはnetshによる設定)が必要です(図6を参照)。また、この設定情報は作成された仮想マシンに継承されませんのでご注意ください。そのときは、グループポリシーなどを活用しましょう。図6 プロキシの例外設定図6 プロキシの例外設定

  •   デプロイに利用するアカウント
  • Azure ADを利用する場合

全体管理者(Global Admin)権限を持つAzure Active Directoryのアカウントが必要です(「onmicrosoft.comドメイン」のもの。Windows Live IDではないので注意)。
 例:<adminname>@<directoryname>.onmicrosoft.com

  • ADFSを利用する場合

特にありません。デフォルトスタンプディレクトリサービスは認証プロバイダーとして利用し、デフォルトアカウントは azurestackadmin@azurestack.localとなります。 

TP3 refreshは検証できる機能も拡充され、以前のバージョンよりも大幅に安定するようになりました。ただし、環境依存の問題などでデプロイに失敗することも想定されます。ご自分で原因を特定できない/解決できないエラーに遭遇した場合、Microsoft Azure Stack公式ページに掲載されるトラブルシューティングを参照してみてください。また、Azure Stack専用のMSDN Forum上で質問すれば、MicrosoftのAzure Stackにかかわるエンジニアから回答を貰えるほか、同じエラーに合う他のユーザーの質問も参考にできますので、ぜひご利用ください。

 

今回は主にMicrosoft Azure Stackの概観及び正式リリースまでに検証できるTP3 refreshの注意点についてフォーカスしました。次回はHPEによるAzure Stackのソリューションについて、詳しくご紹介いたします。

 

(文責:ITスペシャリスト 凌宇)

0 感謝
作者について

Tech_Power_blog

「HPE Tech Power Club」のコミュニティアカウントです。テクノロジスト、アーキテクト向け情報を発信します。