Azure Stack

Azure Stack Hub 1910にバージョンアップ後、手元の環境では特権エンドポイントへの接続に失敗していましたので、その回避策の記録です。 参考:Azure Stack での特権エンドポイントの使用 | Microsoft Docs 発生したエラーは下記 u 警 N 発 + E 発 + s 告 e 生 n 生 i : w 場 $ t 場 E n - 所 s e 所 n g T P e + + r t + + h S E s - E e p e S : s C F P : r C F a e i a u S \ - a u s n s a t l S a P t l s a s z n e l e z S e l w m i u g y s u s g y o e o r = o Q s r e o Q r s n e r u i e s r u d s N ~ y a o s s y a o : t e ~ I l n t i I l f f a w ~ n i a o n i r R c - ~ f f : c n f f o s u k P ~ o i k o i m o n \ S ~ e パ \ $ ~ e m n E S ~ d ラ E s ~ d E e i R e ~ E メ R e ~ E : n C s ~ r ー C s ~ r \ i g S s ~ r タ S s ~ r a m W i ~ o ー W i ~ o z p s o o ~ r o o ~ r u o t r n ~ I ' r n ~ I r r a k ~ d S k d e t r s - ~ e s s e t C ~ : : s \ : : t d u C ~ s C a p o m ~ O P i o I P c c n p ~ p S o n n a k o s n u ~ e S n n v r \ m c e t ~ n e e a a E m r c e ~ E s の c l m R a i t r ~ r s 引 t i e C n p E N ~ r i 数 E d t S d t R a ~ o o を R D e W s C m ~ r n 確 C a r o t S e ~ : O 認 S t A r f h . ~ p で . a r k r r p $ ~ ( e き p : g s o e s E ~ S n ま s u \ m w 1 r ~ y F せ 1 ( m p : c ~ s a ん : : e a t a 2 s ~ t i 。 3 ) n s h n 4 V ~ e l 引 0 t s e m ~ m e 数 [ V w e 文 I ~ . d が 文 E a o m r 字 P ~ M 字 n l r o r : ~ a n : t i d d o 1 - ~ n u 1 e d . u r 2 C ~ a l 7 r a t l : o ~ g l - t x e n ~ e P i t C f ~ m ま S o ' a i ~ e た S n . E n g ~ . は e E C n u ~ . 空 s r E o r ~ . で s r C t a ~ . す i o l t ~ R 。 o r i f i ~ e n n , e i o ~ m u ] M n n n ~ o l 、 i t d N ~ t l P c ' a ~ e a r t m ~ R ま r o i h e ~ u た a s n e ~ n は m o c P ~ s 空 e f l W p で t t u i a な e . d n c い r P e d e 引 B o o : 数 i w u w R を n e n s e 指 d r a m 定 i S p P o し n h p o t て g e r w e 、 V l o e R コ a l v r u マ l . e S n ン i C d h s ド d o e p を a m v l a 再 t m e l c 度 i a r e 実 o n b d ) 行 n d s a し E s t [ て x . t a N く c E h e だ e n a f w さ p t t i - い t e l P 。 i r m e S o P i S n S g ' e S h M s e t i s s c i s m r o i a o n o k s ] n e o , C f o t t R m h . e m e A m a m z o n u t d l r e e e E s S x s t c a e d c p i k t s . i c D o o N n v S e . r p a s b d l 1 e ' . i T n o d f i i r n e d c t t o h r e y c ' o C m : m \ a P n r d o s g r w a i m t h F i u l n e a s p \ p W r i o n v d e o d w s v P e o r w b e s r , S h r e u l n l \ t M h o e d u I l m e p s o \ r M t i - c M r o o d s u o l f e t . c A o z m u m r a e n S d t a a c g k a . i D n N S w \ i j t a h - J t P h \ e ' , V e o r r b o i s n e a p n a y r a p m a e r t e e n r t . c F u o l r t u a r e l i d s i t r e o c f t o a r p i p e r s o . v . e d v e r b s , t y p e G e t - V e r b . 私は、ラッパーのPowerShellを自分で書いてそれを使用して接続していますので少し通常とエラーメッセージの表記が異なりますが、肝の部分は下記部分です。 ...

AWS Outpostsが発表され、Microsoft Azure Stackとの比較論が出ていたりもします。どちらがいいか…を直接比較…とか比較するのはちょっと違う…とかいろいろ話も意見もありますが、そんなことよりもずっと本質的に大事だと私が思っていることがあります。それは「そのインフラが設計、構築、維持運用されるためにどれだけのコストが払われているのか」ということが大事なんじゃないかということです。 私はインフラエンジニアとして単一システムのための個別の環境を構築したり、統合仮想基盤を構築したりした経験があるのでよくわかっているつもりなのですが、「個別にものすごい労力を割いてシステム、プラットフォームを構築、維持管理している」状況があちこちにあります。そして個別最適化されているので知識の属人化が進み下記のような状況が当たり前のようにあります。 - XXさんじゃないとどうなっているかわからない - システムに変更加えようと思うとどこで何が起きるかわからない - 変更加えるためには徹底的なテストが必要 - でもそもそも全く同じテスト環境は構築できない - 『触らぬ神に祟りなし』なので何も更新しない - 脆弱性があっても修正しない - パッチ当てるにしても人間が一つづつ手作業で目視確認しながら作業する - プラットフォームが古いので新しいOS等に更新もできない - でも、よく考えると単に仮想基盤があって仮想マシンが動いているだけ… - 個別に最適化してしまっているので他社で培われたノウハウも展開できない 結果、あるシステム、プラットフォームにかかっている「コスト」はものすごいことになっているケースが多いです。それはハードウェアの話もありますが、むしろ人的コスト、消費されている時間の方が圧倒的に「やばい」と思っています。 一方、パブリッククラウドに目を向けると…、かなりの部分が隠蔽されているので不明な部分も大きいですが下記のような状況があります。 - 一般的なオンプレミスのシステムの規模は比較にならないような圧倒的なスケールで標準化されている(はず) - 通常のオペレーションも大規模に自動化されてなされている(はず) - セキュリティ対策も一般的なオンプレミスの環境とは比較にならないレベルで徹底、統一化されている(はず) - 世界トップのエンジニアたちのノウハウが投入され続けている - 最新のサービスを提供するように更新され続ける 例えば同じスペックの仮想マシンを1台動かすことを考えます。そのときにその基盤となる環境にかかっている人的コスト、消費されている時間はオンプレミスの方がパブリッククラウドの何倍、何百倍、何千倍、下手したら何万倍のオーダーでかかっているだろうと思います。1人のエンジニアが何台動かせる基盤の面倒を見ているか、何人が使えるシステムの面倒をみているかという尺度でも良いと思いますが、正しいデータが出せずに申し訳ないですがもう圧倒的であることは火を見るよりも明らかです。 かけたコストの分だけオンプレミスのシステムにて特別な差別要素のあることをしているなら意味もあるのでしょうけれども、結局やっているのは「サーバーを塩漬けで動かしてます」という話だとそれって単純に貴重なリソースの無駄遣い…ですよね。 その観点からすると、「差別化する必要があるものに関してはオンプレミスで自分たちで手をかけてやる」「差別化する要素がない部分はもっともコストが低いコモディティ化したもので良い」ということになります。 で、やっとAWS OutpostsやMicrosoft Azure Stackの話になるのですがこれらは究極的に「標準化」されているものなんです。個別に設計するのではなく世界規模で標準化されています。そしてパブリッククラウドのノウハウで標準化されているんです。更新だって勝手にやってくれたり、ボタン一発だったりします。テンプレートやコードだって世界で共通のものが動いちゃいます。これってインフラ構築で個別に苦労したことのあるエンジニアがみんな思う「共通化できたらみんな幸せになるのに」というシステムの1つの形だと思います。それを個別の組織レベルではなく、世界規模で行っているわけです。 そして、どのくらい時間がかかるかはわかりませんが「そういえば昔は個別に基盤構築していたよね」という時代が来ると私は確信しています。それはコンピューター製造に共通企画がなかった所から共通規格ができたように。標準的な通信プロトコルがなくて独自プロトコルが乱立していたところから共通規格ができたように。もちろんニッチな所、本質的に標準化できないところではそれはいつまでも残るのですが「全部まかせといていいよね」という話になります。これは「クラウド時代に「買って済ますべきもの」と「自分たちですべきもの」 | Microsoft Cloud Administrators」で書いたことと基本的に同じ考え方です。 結局何が言いたいのかというと、「自分たちでいちいち個別にプラットフォームを構築、維持管理する必要が本当にあるのですか？よく考えたほうが良いですよ」ということです。そうだね、って気がついた人はパブリッククラウドを利用するのでしょうし、どうしてもオンプレミスという場所にシステムを置く必要があるのであればOutpostsやAzure Stackを利用するようになっていくと思います。むしろそうならなければ行けないと思っています。 とはいえ、Outpostsが登場するのはまだ先ですし、Azure Stackも(組織サイズが大きくないと)値段が高すぎるし…ということでまだまだだと言うことには現時点では同意します。でも、きちんと先をみて、「世界標準のプラットフォームへの対応」を組織としても、エンジニアのスキルセットとしてもしておくべきだと強く思うところです。 この文脈においてOutpostsもすごく人気がでて普及してほしいですし、私が個人的に多くの時間を投資しているAzure Stackの普及も進んでほしいと思っています。「個別の無駄な苦労」はしなくて済むならそれでいいと思うのです。 #ちょっと極論を強い口調で書きすぎたかもしれません。気分を害された方ごめんなさい。

Azure Stack 1808 updateが出ましたね。早速適用しました。 - https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-update-1808 今回の更新ではManaged Diskがサポートされたのが一番嬉しいですね。これでAzureとの一貫性の度合いがまた一気に高まりますね。 Azure MonitorもAzureでは当たり前に使うものなので嬉しいです。 で、extension hostはAzureStackの管理者にとって非常に重要なので、今からしっかり理解して準備しないといけないですね。 コンセプトとしては「色々なサービスごとに異なるサブドメインやポート番号を使うと証明書の用意とかFWの穴あけとか大変だから全部同じ証明書で対応できて、TCP443番ポートしか使わないようにしよう」というお話と理解してます。 Azure Stackの既存のサービスもこの仕様に統一されていくようですし、これからの新しいリソースプロバイダーも全部この形に統一されるのでしょう。 Azure Stack用のネットワークポートの穴あけは一度443だけやっておけば良くなるのは素敵です。 代わりに、新しい2つのサブドメインをextension hostのために使用するそうです。証明書の準備が必要なので備えなくてはですね。 正直なところ、RPが出てくるたびに新しい証明書を作るのは面倒だなと思ってましたので、後一回で終えられるなら大歓迎です！

しばらくこのブログを書く時間がありませんでしたが、また少しづつ書いていきたいと思います。 まずは継続的に追いかけて一番力をいれているAzure StackのUpdateから。しばらく月一ペースで更新が出ていましたが、1806はスキップされて、1807が現在の最新の更新です。 また日本語化されていませんが、最新のリリースノートは以下です。 - [Azure Stack 1807 Update | Microsoft Docs](https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-update-1807) なんといってもこの更新で一番注目なのはスケールユニットに対してのノード追加機能が追加されたことだと思います。この点に関しては下記の独立したページに解説が書かれています。 - [Azure Stack add scale nodes | Microsoft Docs](https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-add-scale-node) スケールユニットに追加する物理サーバーはCPU, Memory, Disk数およびサイズが全て同一であることが必要であると記事に明記されています。Generationが異なるAzure Stackのノードを追加できる機能もサポートされるのでは？という推測もありましたが、現時点ではそうはなっていませんね。 ノード追加ステップ自体はシンプルですね。 - 物理サーバーのラックマウント - BMCやBIOSの構成 - ファームウェアの更新 - ポータルまたはPowerShellでのスケールユニットへのノード追加 - 確認 1,2,3に関してはOEMメーカーに実施してもらう必要がありますが、きちんとノード追加の手順が標準化されているというのは本当に素晴らしいことです。自作の仮想基盤を拡張しようと思ったときにどれだけ苦労するかを思えば夢みたいな話です。 他にも今回のUpdateで下記のような事が実現されています。(個人的に注目しているもののみ抜粋) - ARMテンプレートでの条件要素のサポート - Microsoft.Network APIのバージョンアップ（2017-10-01） - 既存VMへのネットワークインターフェースの追加（ポータル, PowerShell, CLI） - バックアップのスケジューリング そして、Update自体が簡単に、安定して動作しているのが良い感じです。私が管理している環境でも、Azure StackのUpdateの最中にサービスは停止しないまでもUpdateが失敗することは過去度々あり、Microsoftのサポートの方に対処してもらっていましたが、ここ数ヶ月分に関してはトラブル無しで安定的に適用できています。 過去に発生したトラブルに対してはロジック的に同じトラブルが発生しないように対処、改善してくれているのがよくわかります。Azure Stackは構成的にどんどん品質が向上していく思想になっていますから、これからもどんどん品質を上げていって貰えればと思います。

Azure Stackではログ収集や一部の操作を行うためにPEP(privileged endpoint, 特権エンドポイント)に接続するケースがあります。個人的に一番多いのはTest-AzureStackコマンドでテストすることでしょうか。 そのPEPにはRemote PowerShellで接続するのですが、そこに対してどこから接続すべきか、というガイドラインが当初と大きく変更されていますので少々注意が必要です。 - [Azure Stack での特権エンドポイントの使用 | Microsoft Docs](https://docs.microsoft.com/ja-jp/azure/azure-stack/azure-stack-privileged-endpoint) 上記の最新のドキュメントでは下記の説明が記載されています。 注意 セキュリティ上の理由から、PEP への接続は、ハードウェア ライフサイクル ホスト上で実行するセキュリティを強化された仮想マシンから、または Privileged Access Workstation のような専用のセキュリティで保護されたコンピューターからに限定して行う必要があります。 ハードウェア ライフサイクル ホストは、元の構成から変更しないようにするか (新しいソフトウェアのインストールするなど)、または PEP への接続に使わないようにする必要があります。 HLH（ハードウェアライフサイクルホスト）から直接接続するのではなく、その上で動く仮想マシンや専用のPCからの接続が推奨されています。 これ、実は当初はHLHから直接接続することが推奨されていたんです。このことは過去の編集履歴を参照するとわかります。 - [adding update · MicrosoftDocs/azure-docs@a0826e6](https://github.com/MicrosoftDocs/azure-docs/commit/a0826e6e56975c80572d9867ab19a7573d75fef5#diff-191bf0c6135f0e9c0ec5d08b7ec9c30f) ドキュメントがGithub上で管理されているので過去の履歴も追いやすくて良いですね。 これからAzure Stackを利用する場合にはどうということもないのですが、HLHから接続するようにしていたところ、ある時からPEPに接続ができなくなっていてこの事に気が付きました。 OEMのUpdateを適用する中でHLHへのセキュリティ設定が変更され、HLHからPEPへのRemote PowerShellでの接続も禁止されたようでした。 同様の変更は今後は発生しないとは思いますが、いつものことながら英語の最新版のドキュメントを参考にするのが色々と良さそうです。

ASDKを毎月デプロイしていると、AADの中にAzure Stackのアプリケーションが沢山できてしまいます。最新のものを残して古いものを削除する為のスクリプトが無保証で参考に公開されていましたので、共有します。 - [AzureManagement/CleanAzureStackAADApps.ps1 at master · ebibibi/AzureManagement](https://github.com/ebibibi/AzureManagement/blob/master/AzureStack/CleanAzureStackAADApps/CleanAzureStackAADApps.ps1)

主にインフラエンジニアからみて、過去から現在までの流れ…のようなものを私が見えている範囲で記載してみました。昨今はクラウド化の流れと相まって非常に高度な自動化やインフラのコード化まで実現可能となっており例えば「スクリプトも書いたことありません」という人に対してどの領域から飛び込んでもらうのが効率的か…をちょっと悩んでいます。 もうコーディングレスでLogic Appとかそういうところに飛び込んでもらった方がはやいのかもしれないし、仮想基盤のことやWindows, Linuxの中の事はすっ飛ばしてTerraformとかコンテナとかそこに注力するところから入って必要が出たところで仮想マシン内部の処理に入ったほうがいいのかもしれません。でも、現実的にはシェルスクリプトとかPowerShellスクリプトの基礎とかは抑えておかないとだめかもしれないし・・・。結構悩ましい所です。 - 昔はバッチファイルやシェルスクリプトで繰り返し実施する作業の効率化がありました。 - その後Windows的にはWSHの時代があり、vbscriptでスクリプトを書いたひとも多かったと思います。 - その後Microsoft的にはコマンド毎にオプションが違ったりコマンドがなかったりすることを解決し、全て統一するものとしてPowerShellを生み出しました。(私の大好きな[Jeffery Snover](https://twitter.com/jsnover)さんの仕事です。) - これでMicrosoft系はPowerShellで全てオブジェクト指向の管理となりました。(バックグラウンドにあるのは.net framework) - 一方UNIX系は当初からなんでもかんでもテキストであるという思想でした。 - MicrosoftはPowerShellを標準として様々な製品を開発しました。GUIではできないことでもPowerShellでなら操作できる。GUIで操作しても裏ではPowerShellコマンドが自動生成されてそれが実行されている…というものも多くありました。(結果、仕方がなくPowerShellを使うようになった方も多いと思います。) - Microsoftはクラウドサービスにもその流れを取り入れました。PowerShellにてクラウドサービスの管理も行うことになりました。 - Chef, Puppetなどに代表されるような冪等性を備えた仕組みが登場してきました。(Infrastructure as code, Configuration as code) 何度実行しても「記載した望むべき状態になる」ことを特徴とします。 - これ以前は「これを実行したらこうなる、やって見る前に状態を確認して、やってみて、やった結果を確認する」というような作業の流れを記述するようなイメージでした。 - MicrosoftもPowerShell DSCにて冪等性を持つフレームワークを提供しました。 - Microsoftのオープンソース指向が進む中でよりマルチプラットフォーム化を意識した取り組みがなされるようになっていきます。 - PowerShellの継続開発が打ち切られ、PowerShellCoreに舵がきられます。PowerShellCoreはWindowsだけではなく、Linux, Mac等でも動作するマルチプラットフォームなPowerShellです。(バックグラウンドにあるのは.net core) - AzureにもCloudShellの機能がつき、ポータル上でもコードで制御できるようになります。これまでのAzure PowerShellよりも先にAzure CLI(UNIX系の文化)の方が先に搭載されました。Azure管理はPowerShellよりもCLIの方が優先されるようになってきています。 - クラウドサービスも普及する中で、大規模な環境ではもう個別に１台づつターミナルで作業するなり、RDPではいってGUIで操作するなりすることが現実的に不可能な規模になりました。このような環境ではコードで全てを制御可能な環境にすることは必須条件となりました。 - WindowsもWindows Server Coreが出てGUIがなくなり、さらにNano Serverにてどんどん軽量化していきます。 - Windows Server 2016, 2019となると継続的に進化するモデルはGUIが利用できなくなりました。 - 更に軽量化を推し進める中で仮想マシンではなく、コンテナに大きくトレンドが傾きます。 - コンテナの標準であるDockerはDockerfileというコンテナをコードで定義できる機構を備えています。 - クラウドサービスも冪等性をもったテンプレートにて展開可能な構造となります。AzureであればARMテンプレート、AWSであればCloud formationなど。 - ARMテンプレート、Cloud formationによるInfrastructre as Codeと仮想マシンの内部を構成するChef, Puppet, AnsibleのようなConfiguration as Codeによって仮想マシンベースの環境構築の完全自動化が可能となりました。 - ARMテンプレート、Cloud formationによるInfrastructre as CodeとDockerによるコンテナコントロールで完全自動化が可能となりました。 - 複数のコンテナプラットフォーム自体のコントロールという観点ではKubernetesが標準化してきています。 - AWSLambda, Azure Fuctionsのようなインフラ自体を意識せずアプリケーションロジックのみを記載すればそれでおしまいとなるようなサービスも出てきました。ここではInfrastructure as CodeやConfiguration as Codeすら必要ない世界があります。(これですべてまかなえるわけでもないですが) - DevOpsという流れもありますが、NoOpsに向かう流れの方が強そうに感じています。(私の感想) ※NoOpsはインフラ管理者がいらないという意味ではなく、極力インフラの面倒を見なくていいアーキテクチャを採用する、くらいの意味で捉えています。 ...

本日のセミナーにてMS高添さんと一緒に登壇させてもらいました。別のセッションでそれぞれ登壇…ではなくて、2人で前にたってセッションを進めさせてもらいました。ずっと高添さんと一緒にやりたかったのでやれてよかったです。 想像していたよりも私が高添さんに助けてもらうばかりになってしまいましたが、それでも楽しかったです。 さて、本日のセミナーではシステムアーキテクチャやサービス形態の変化を振り返りながら、Azure Stackがどれだけ先進的なのか、という話をさせてもらいました。 システムアーキテクチャとしては今「ハイパーコンバージド」が流行していて非常に引き合いの強さを感じているのですが、Azure Stackはハイパーコンバージドも内包しながらさらに様々なものがサービス化されています。もちろんポータルも完備されていますし、各種APIもそなえています。そしてそれはAzureとも互換性があるものです。 さらに、Azure Stackはサービスとしてのカバー範囲は仮想化の一歩先を行く「IaaS」から「PaaS」はもちろん、コンテナの管理基盤(CaaS)、サーバーレスアーキテクチャ(FaaS)もカバーします。 この図は最近書き直したのですが、以前はIaaS, PaaS, SaaSというクラウドの形態を紹介するために作成しましたが、改めて作り直してやはり今ではCaaS, PaaS, FaaSにイノベーションが多く起こっていることを実感しています。そしてオンプレミスに機器を置くAzure Stackでもこれらがカバーされる…常識を入れ替えて対応する必要を改めて強く感じています。 セミナーでも会話しましたが、このブログが動いているのは15年くらい前からずっと運用し続けているLinuxの仮想サーバーなのですが、最近新しく作った以下のサイトはCaaS, PaaS基盤を使うようにしていまして、日々の面倒なことから解放されて大変に幸せな感じです。 - [このサイトの構造について(Web App for Containers) | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%81%93%e3%81%ae%e3%82%b5%e3%82%a4%e3%83%88%e3%81%ae%e6%a7%8b%e9%80%a0%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6web-app-for-containers/) 自分で新しいシステムを作るならもう仮想マシンベースでは考えたくないくらいのところまで私の感覚は来ています。 クラウドを「構築する」のではなく、「使う」人の為のシステムであるAzure Stack。私が登場時に受けた衝撃はまだセミナーに来てくださっている方やお客さんに伝えきれていない気がしますが、引き続きこのような活動はしていきたいと思います。 なお、4月から会社での役職が代わりシニアエキスパートとしてより技術的な面にも時間を割けるようになる予定です。本も出したいです。それもあって新しいサイトも新しい仕組みで作ってみたりしています。このブログの更新頻度も上がる…予定です。

Source: Azure Roadmap | Microsoft Azure Azure Stackに関してのロードマップが出てますね。(Azure roadmapにてAzure Stackのタグでフィルタ) 以下ざっくりとした拙訳です。 予告通り最大16ノードのスケールユニットへの拡張が開発中- Azure Stack上のゲストOSやデータディスク、ボリュームのAzure Backupを使ったバックアップおよびリカバリが開発中- Azure Stackの構成が勝手に変更されてしまっていないかを検出、修正する機能が開発中- Azure Stackの構成が「規定で堅牢化」されていることを確認できる機能を開発中- Azure Container Service(AKS) on Azure Stack開発中- サービスファブリッククラスターのテンプレート展開開発中。- Azure Stack上でのWindowsおよびLinux仮想マシンでのサービスファブリックのサポート。GA。- Azure Site RecoveryでのAzure Stackサポート　開発中。Azure Stack to Azureの方向に(説明文章が)読めます。- Azure Stackインフラのバックアップとクラウドリカバリ開発中。マニュアル操作を省いたものに改善されるようです。- Azure Stackでのマネージドディスク開発中。- Av2シリーズとFシリーズの仮想マシンサイズ。開発中。- VPNゲートウェイのよりフレキシブルな設定。開発中。- Azure Storage APIバージョン2017-0417のサポート。開発中。- Azure Stackへのノード追加。開発中。- Azure Stackの複数スケールユニットのサポート。開発中。- Azure Stackオペレーターへの機能アップデート。開発中。モニタリング、診断、サービス提供周り。- Azure StackインフラのPCI-DSS, CSA-CCMコンプライアンス認証に関しての説明ドキュメント。開発中。- Azure Stackポータルでの仮想マシン料金の表示。開発中。- Azure Stack上でのWindows, Linuxのコンテナのサポート。GA。- Azure StackへのKubernetesクラスタのテンプレート展開。開発中。 Azure Container Service(AKS)がいいですね！

今回はAzure Stack用に証明書を用意する際のポイントに関して備忘録を兼ねて書いておきます。自社導入時に少々整理する必要がある点もあり、まだあまりまとまった資料もありませんでしたので…。 と思って書き出そうとしたら公式サイトに1月30日にドキュメント追加されてますね！良いことです。 Azure Stack Public Key Infrastructure certificate requirements for Azure Stack integrated systems | Microsoft Docs- Generate Azure Stack Public Key Infrastructure certificates for Azure Stack integrated systems deployment | Microsoft Docs 自分が書こうとおもっていた注意点はここにまとめられていたので…特に書くことがなくなってしまったのですが、ハマりどころだけ書いておきたいと思います。 後からサービスを追加すると追加で証明書が必要になる形態で作られているので、「Azure Stack用の証明書用の予算」は多めに確保しておくのが吉です。組織内のCAからの発行であればそこは気にしなくてよいのですが。ただ、現実的には公的証明局の証明書での運用は難しそうです。(The ACS certificate requires three wildcard SANs on a single certificate. Multiple wildcard SANs on a single certificate might not be supported by all Public Certificate Authorities.)- ドキュメントにある通り、iniファイルを書いて、Windows標準のcertreq.exeで証明書要求を作成するのが1番簡単だと思います。(私がWindowsに慣れているからそう思うだけかもしれませんが)- Windows ServerのCAを利用するには、規定では有効になっていないSANを有効化する必要があります。有効化する方法は下記参照。- セキュリティで保護された LDAP 証明書にサブジェクトの別名を追加する方法- ハッシュアルゴリズムにSHA1は使えないので、必要に応じてcertutilにてCAのハッシュアルゴリズムを変更する必要がある。- 暗号化サービス プロバイダー (CSP) からキー記憶域プロバイダー (KSP) への証明書機関キーの移行

今日、Equnixさん、HPEさん、MicrosoftさんとJBSの４社でのAzure Stackのセミナーを実施させてもらいました。これで10月16日のセミナー、11月8、9日のTechSummit、本日11月21日のセミナーと立て続けに3回、Azure Stackをテーマに登壇させてもらいました。あと、実はこの間にある企業様へのプライベートセッションで2時間喋らせてもらってるので、実質は4回ですね。 これだけ短期間に繰り返し喋らせてもらっていますが、自分の喋ってみての感じですとか、そのイベントに来てくださるお客様をイメージして喋る内容や実施するデモ内容は毎回変化させています。同じ内容だと自分が飽きちゃうというのもありますし(笑 今日の登壇内容のサマリーは以下のような感じになりました。 「クラウド化」による変化高い生産性- 継続的な進化- 管理の委任- クラウド≠場所- クラウド＝方法論- Azure = Azure Stack =クラウド- 未来のシステムはハイブリッドクラウドであり、SaaS, PaaSを積極活用する方向- Azure / Azure Stackの組み合わせは「同じ方法」が使えるところがユニークである- Azureはそもそも複数種類あり、Azure Stackもその1種類である- Azureをすでに使っているユーザーも使っていないユーザーも、Azure Stackを有効活用できる- Azure Stackの導入は非常にシンプルなので、むしろその配置場所や電源容量の確保、既存環境、クラウドとの接続性のほうが導入においては重要- 導入後はAzure Stackがデータセンターを抽象化するため、開発手法を劇的に変化させることが可能- 世界中の開発者との共同開発も可能- Azure / Azure Stackのエコシステムへの参加によるメリットは非常に大きいちょっとこれだけだと何のことかわからないかもしれませんが、おいおいブログでも詳しく書いていきたいなと思います。 ですが、改めてこのように自分がまとめて書いたものを見返しながら、思い出すのはWindows Server 2012登場のころにシドニーで聞いたJeffery Snover氏の話です。そのころはWindows Server 2012がでるぞ…！というタイミングで今の状況とは全く違う状況でしたしAzure Stack…どころかAzure Packもまだお目見えしていない頃だったのですが、そのときに目指す方向として聞いた話がまさに今Azure Stackという形に具現化されたのだなと改めて思います。 きちんと明確なビジョンを描きそこに対して実装を何年も続けていくというのは本当にすごいなと思います。きちんと未来が見えている人の言っている話はきちんときいておくに限りますね。

最近はAzure Stackにどっぷりの胡田です。週明けの11月21日火曜日の午後はEqunixさん、Microsoftさん、HPEさんと一緒にAzure Stackのセミナーを行います！ セミナー概要日時：2017年11月21日（火） 15時 - 19時30分（14時30分　開場）会場：日本ビジネスシステムズ様 セミナールーム東京都港区虎ノ門 1-23-1 虎ノ門 ヒルズ森タワー16階対象：社内情報システムのご担当者様、システムインテグレーター様、クラウドインテグレーター様 お申込み方法：http://info.equinix.co.jp/AzureStack_Reg_LP.html　14:30 –開場15:00 – 15:05ご挨拶エクイニクス・ジャパン株式会社　徳久和幸15:05 – 15:50Azure Stackが導く真のハイブリッドクラウドへの道 日本マイクロソフト株式会社パートナー事業本部 ﾊﾟｰﾄﾅｰ技術統括本部 ﾊﾟｰﾄﾅｰﾃｸﾉﾛｼﾞｰｽﾄﾗﾃｼﾞｽﾄ 高添 修様　15:50 – 16:25解説 「HPE ProLiant for Azure Stack」 その実力とは 日本ヒューレット・パッカード株式会社 シニアソリューションアーキテクト 辻村 洋太郎様16:25 – 16:35休憩16:35 – 17:10ハイブリットクラウド構築の先を行くデータセンターとは！？ エクイニクス・ジャパン株式会社 グローバルソリューションアーキテクト 鈴木 康之17:10 – 17:55Azure Stack有効活用案とデモンストレーション 日本ビジネスシステムズ株式会社 ﾊﾟｰﾄﾅｰｱﾗｲｱﾝｽ本部 ｸﾗｳﾄﾞｱﾗｲｱﾝｽ開発部 部長 胡田 昌彦様 (Microsoft MVP for Cloud and Datacenter Management）17:55 – 18:00御礼日本ビジネスシステムズ株式会社執行役員 パートナーアライアンス本部長 三浦 剛志様18:00 – 19:30懇親会私も登壇させてもらいます。現在HPEさんの「HPE ProLiant for Microsoft Azure Stack」をEquinixさんのデータセンターに導入中なので、その中で出てきた導入時のポイントも含めて、お伝えさせてもらいます。 ...

Azure Stack関連記事、第三弾です。 関連記事は以下です。 Azure Stackは誰がどう使うと幸せになれるのか？- Azure Stackは「できること」ではなく「できないこと」に思想がある 今回は、Azure Stackに関して、現時点で出ている否定的なネット上の記事にあまりにも誤解を招く表現があったので勝手に反論してみたいと思います。 その記事に直接リンクを貼る・・・のはやめておきますが(大人の事情)、その記事には以下のようなことが書かれています。 Microsoft Azureの豊富な機能を使いこなしているユーザー企業にはAzure Stackは向かない(Azure StackではAzureの全ての機能を備えていないから)- 全ての業務システムをAzure Stackで稼働させるのも難しい(拡張性はラック1本に収まる範囲であり限界があるから)- Azure Stackはハイパーコンバージドと呼ばれるジャンルの製品と競合する。Azure StackにはMicrosoftによる運用サービスが付加されている点が異なる。私に言わせると全部間違いです。 1に関して。Azure StackはAzureの拡張であり、Azureを使いこなす企業にこそ1番向くものです。それはマイクロソフトが1番主張していることでもありますし、合わせてハイブリッドでつかうことにより最大の効果が発揮されるものです。このことに関しては「Azure Stackは誰がどう使うと幸せになれるのか？」でも述べました。より具体的な技術的な話はまた他のエントリで解説したいと思います。 3に関して。確かにAzure Stackのアーキテクチャにはハイパーコンバージドという要素もありますが、それはほんの一部分であり、そこは本質では全くありません。Nutanixと競合しているのはWindows Server 2016自体ですよね。ハイパーコンバージドを実現するStorage Spaces Direct、ハイパーバイザーのHyper-V、管理手法を提供するMMC、ちょっと先だとHonoluluですとか。System Centerまで含めてもいいかもしれません。が、このあたりは見解の違いもあろうとは思います。でも、Azure StackとNutanixを比較するのはレイヤーが違いすぎてて…。 で、1番気になってしまったのは2の拡張性に関して。確かに現段階でのAzure Stackの拡張性に制限はあるのですが、その情報を間違って理解しているとしか思えないです。 現時点で拡張性に関して発表されているのは以下です。 Azure Stackは、ユーザー専用の1つのAzureリージョンと捉えることもできます。GA時点では、1つのAzure Stackリージョンに1つのスケールユニット（1つのスケールユニットは最小4ノード、最大12ノードで構成）が配置可能になっています。2017年中にスケールユニットが最大16ノード構成に拡張され、1リージョンに複数のスケールユニットを配置可能になります。また2018年中には、リージョンをまたがる地理的冗長性やスケールに対応する予定です。 「Azure Stack」のスケーリング *引用元：ASCII.jp：ついにGAした「Azure Stack」、“オンプレ版Azure”は何に使える？*確かに現時点(GA時点)では1つのAzure Stackの環境の中に1リージョン、1スケールユニットしか作成できずそれも最大12ノードです。ここをさして「拡張性はラック1本に収まる範囲」と言ってるのだと思いますが、2017年中に1リージョン中に複数スケールユニットを配置可能になればまだ上限は不明ですが、1企業のインフラ全てを扱える程度には拡張可能となるでしょう。 #でも、現状でもAzure Stackのシステムを複数買って動かせば全システム動かせると思いますが…。 …でも、私がもっと伝えたいのはMicrosoftがすでに何を成し遂げているかということです。MicrosoftはAzureや様々な世界規模のサービスを構築し、運用し続けているのです。 そんなMicrosoftにしてみればAzure Stackを「完全にAzureと同じ設計」にしていいのであればそれは簡単な話だったろうと思います。それこそハイパースケールで実装できます。が、それではエンタープライズには合わない…ということで「スケールダウン」させることに非常に苦労しているはずなんです。規模の拡大ではなく規模の縮小に苦労しているのってクラウドの世界ではMicrosoftくらいなのではないかと…。 そんなAzure Stackの下回りで台数の制約に1番からんでいそうなのはあきらかにWindows Server 2016のフェールオーバークラスタとStorage Spaces Directですよね。そこに関しての今後の拡張のロードマップはigniteの以下のセッションで語られていました。 MyIgnite - What’s new in Windows Server clustering and storage: Hyper-converged SHAZAM!このセッション中ではClusterを束ねて管理するCluster Setの概念、機能が解説されています。 この機能を使ってAzure Stackも今後の拡張を担保していくものと理解しました。 Azureですでに実現されていることをスケールを小さくしてWindows Server、そしてAzure Stackで実現していくことをMicrosoftは今後ずっと継続的にしていくことを顧客にコミットしているわけです。「スケールダウン」させた実装を一貫性をもって行い続けることは非常に難易度が高いとは思いますがMicrosoftにしかできないことだと思いますし、素晴らしいビジョンだと思います。 ...

Azure Stack関連記事第二弾です。 関連記事 Azure Stackは誰がどう使うと幸せになれるのか？ | Windowsインフラ管理者への道 今回は、1つの捉え方としてAzure Stackの「できること」ではなくて「できないこと」に注目してもらいたいと思います。 Azure Stackは自由にハードウェアを選択できない OEMパートナーの統合システムとして限定されたモデルから選択する Azure Stackは自由に構築できない 「インストール作業」はエンドユーザーは行わない Azure Stackの基盤を構成する仮想マシン群にはアクセスできない コンソールアクセスをしても拒否される 「いつもの」ソフト群も導入できない 監視ツール アンチウイルスソフト バックアップソフト アップデート適用ロジックはコントロールできない ボタン1つで自動的に適用される 適用順序等もコントロール不可能 ソフトウェアに加えてハードウェアのファームウェア等も自動更新される スケールセット拡張方式もコントロールできない 同じHW、同じモデルを追加することができるのみ(※GA後に機能追加) どうでしょうか。運用の現場にいる人からすると「今のルールとは違う」ということになると思います。 ハードウェアもその時々で最適なものを選択しているし、インストール作業は自分たちでしているし、ハードウェアもその上のOS,仮想マシン含めて全部コントロールしているし、必ず入れる監視ツール、アンチウイルスソフト、バックアップエージェントがあり、アップデートのときにも必ず適用順序や適用後の確認もしている…、拡張するときには都度その構成を検討、設計して、慎重に作業していて…。 これこそが「ITインフラ管理者の仕事である」という意見の人も多いと思います。 ですが、Azure Stackは明確にこれにNOを突きつけています。「そんなことは本質じゃないからもっと本質的なことに時間を取れるように楽にしておいてあげたよ」という声が私には聞こえます。 実は、このあたりクラウドサービスを使っている組織には当たり前のことです。クラウドサービスの下回りがどうなっているかは完全にクラウドベンダーにおまかせですし、視線は「その上」で動いているサービスに向いています。 このクラウドでの当たり前をAzure Stackはオンプレミスでも当たり前にします。構成に悩まない。構築は自分でしない。提供されるサービスを利用し、基盤には立ち入らない。全自動で更新でき、更新を怖がる必要はない。リソースがたりなくなればすでに準備されている方法でスケールアウトすれば良い。 そんなことをされてしまったら自分の仕事がなくなってしまう！という危機感を覚える人ももしかするといるかもしれません。 でも、大丈夫です。それはすでにクラウドに進出した人が過去に通ってきた道ですし、そういう世界にあっても仕事は沢山あります。しかもそれは、より、本質的な仕事です。 インフラ基盤周りに関してはAzure Stackを入れておけばそれでおしまい。AzureとAzure Stackを使って「その上」の話に集中する。それがすぐに可能になります。 いや、むしろAzure Stackを導入するとそうなってしまうのです。なぜなら「いじれない」からです。 この1点だけでもAzure Stackが組織のITインフラ環境に「革命」を起こす製品であると理解いただけると思います。 もっと詳しく話がききたい！という方は、以下のセミナーでもこのあたりを話させてもらう予定なので、是非申し込みいただければと思います。 プライベートクラウド？ハイブリッドクラウド？Azure Stack 活用セミナー | JBS 日本ビジネスシステムズ株式会社 概要およびアジェンダは下記の通りです。 日時 2017年10月16日（月） 14:00-17:00（ 受付開始時刻 13:30 ） 開催場所 虎ノ門ヒルズフォーラム ホールB 東京都港区虎ノ門1-23-3 虎ノ門ヒルズ森タワー4F 地図はこちら 定員 100名 参加費 無料 / 事前申し込み ※同業者様のご参加をお断りさせて頂く場合があります。あらかじめご了承ください。 ...

皆さんこんにちは。最近色々あってめっきりブログ投稿できておりませんが、仕事で年単位で温めてきた「Azure Stack」がいよいよ日本にもやってくるタイミングになりましたので、しばらくはAzure Stackに関しての記事を集中的に書いていきたいなと思います。 まずはじめに、Azure Stackは誰がどう使うと幸せになれるのか、誰のためのソリューションなのかという点について私の考えを書いてみたいと思います。 ずばり私は「まだクラウド化できていない組織」だと思っています。…が、これはAzure Stackのメインターゲットではありません。 「マイクロソフトの狙い」と「市場のニーズ」にずれがあると思うのです。そこを自分がうまく埋められるのではないかとも考えています。 私の個人的な考えですが、一つの切り口としてユーザーの種類は以下5種類くらいに大きく分類することができると思います。 [パブリッククラウドオンリーOKユーザー] パブリッククラウド比率100% クラウドをすでに活用している…というかオンプレミスのサーバーシステムなんてそもそも使っていないユーザー。あるいはオンプレミスに既存システムはあるけれども今後は全てクラウド上にシステムを構築していき、オンプレミスのシステムは長い目では0に向かっていく意思決定がなされているユーザー。 [ほぼパブリッククラウドでOKだけど一部はオンプレに置きたいユーザー] パブリッククラウド比率80～90% クラウドはすでに活用していて、基本的にはクラウドにシステムを構築するし、そのノウハウや手法ももっている。それでもパフォーマンスを高くするためにユーザーのアクセス窓口はパブリッククラウドではなくオンプレミスのユーザー近くに置くべきシステムが場合によってある。法律や厳格な社内ルールで縛られていて、特定のデータはパブリッククラウドには置くことは絶対にできないが、パブリッククラウドの良い点を極力フル活用したいユーザー。 [システムの置き場所は自由に選択できるようにしたいユーザー] パブリッククラウド比率20～80% ベンダーロックインを極力避け、どこにでもシステムを配置できるようにしたいユーザー。マルチクラウドでの可搬性ももちろん視野に入る。 [パブリッククラウドに行きたいけどまだいけていないユーザー] パブリッククラウド比率 0～20% 本当はパブリッククラウドを利用したいけれども、具体的にどうしていいかわからず踏み出せていないユーザー。あるいは、パブリッククラウド採用に対して前例のなさや、ルールの変更等の変更負荷が高すぎて合意形成が取れないユーザー。 [パブリッククラウドには絶対行かないユーザー] パブリッククラウド比率0% オンプレミスにこだわりがあり、パブリッククラウドを利用する気はまったく無いユーザー。 私の考えでは、Azure Stackを使って幸せになれるのは、2,3,4,5のユーザーです。ですが、特に4,5のユーザーに注目してほしいと私は考えています。 マイクロソフトが明確に狙っているAzure Stackの対象ユーザーというのは2および3である、というのが私の理解です。「Azure StackはAzureの拡張である」ということで、すでにAzureも使っているし、そのメリットも享受しているユーザーが何らかの理由(遅延、パフォーマンス、法律、ポリシー等など)でオンプレミスにシステムを構築しなくてはいけないときに、Azureの素敵な世界でいつも素敵にシステム構築しているのに、オンプレミスで全然別のやり方(そしてそれはきっとAzureよりも効率的ではない)をしなくてはいけないのは大変だよね、非効率だよね…ということですね。 「どこでも同じようにできる(開発、運用、保守、その他諸々)」ということを求めるならAzure + Azure Stackの世界感ですよね、というわけです。 これはこれですごく合理的な話だし話の筋は通っていると思います。 でも、現実を見たときに多いのは4や5のユーザーなんじゃないかと私は思っています。エンタープライズの企業規模の大きな企業に関しては特に。思い切ってクラウド化に向けて舵をきれる…ようならいいのかもしれませんが、様々なルールや「やり方」がしっかりと決まっている中でそこに変化を起こして行くのは並大抵のことではなく、検討している間にパブリッククラウドはどんどん変化してしまうし…それでも、なにかしらパブリッククラウドの良さを活かしていかないといけないという問題意識はある…。こういう状況の組織とても多いと思っています。 私は、そんな「まだクラウド化できていない組織」が一気に素敵な環境にジャンプできるそのための起爆剤にAzure Stackがなれるんじゃないかと思ってます。 なぜそう思うのか、その一番の理由は「場所」です。Azure Stackは兎にも角にもオンプレミス上で動作し、インターネットから完全に遮断した状態で「パブリッククラウドと同じもの」が動いちゃうものなのです。これなら様々な理由でパブリッククラウドに『行けなかった/行けていない/行く気がない』組織が、オンプレミスにありながらパブリッククラウドのパワーを手に入れられてしまうのです。しかも、Microsoftおよびハードウェアメーカーの完全なサポート付きで。しかも、パブリッククラウドと一緒なのでガンガン進化し続けます。 これならXXXさんを説得できるかも？と思う人も多いのではないでしょうか？私はオンプレミスで何年もずっと(効率的ではない)やり方をずっと続けてきた組織がAzure Stackを起爆剤として一気に「素敵な世界」を使い始められると思っており、それを実現していきたいなと思っています。 Azure Stack発表から登場まで2年(！)もあった中で、人にはまだ喋っちゃいけない知識ばかり頭のなかにいっぱいある…という状況になってしまいました。それがいよいよお客さんとの会話ができる状況になってきましたので、是非、色々な人にお伝えしていきたいです。大きく言えば日本のエンタープライズのIT環境に革新を起こしたくおもっており、その中心になりたいと思っています。Azure Stackにはそれができる可能性が大いにあると思っています。 …が、Microsoftの想定するメインのユーザー層とはことなることもあり、注意しなければいけない点も多数あります。このあたりの話はこのあとのブログエントリにてお伝えしていきたいと思います。しばらくAzure Stack関連の記事を連続で書く想定です。 注意点が早く知りたい！という方は、以下のセミナーでもこのあたりを話させてもらう予定なので、是非申し込みいただければと思います。 プライベートクラウド？ハイブリッドクラウド？Azure Stack 活用セミナー | JBS 日本ビジネスシステムズ株式会社 概要およびアジェンダは下記の通りです。 日時 2017年10月16日（月） 14:00-17:00（ 受付開始時刻 13:30 ） 開催場所 虎ノ門ヒルズフォーラム ホールB 東京都港区虎ノ門1-23-3 虎ノ門ヒルズ森タワー4F 地図はこちら 定員 100名 参加費 無料 / 事前申し込み ※同業者様のご参加をお断りさせて頂く場合があります。あらかじめご了承ください。 ...

今週後半は暖かい日が続きましたね。春一番が吹いた地域もあったようです。 さて、今週のトピックスです。 - 3分でわかる Azure Managed Diskのしくみ 8 users 3分でわかる Azure Managed Diskのしくみ 1. FD A FD B 2. FD A FD B 3. https://docs.microsoft.com/ja-jp/azure/storage/storage-managed-disks-overv… [www.slideshare.net ](http://b.hatena.ne.jp/ebibibi/?url=http%3A%2F%2Fwww.slideshare.net%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, azure, b 34 clicks 2017/02/15 - なぜWindowsの標準ドライバーはすべて「2006年6月21日」のまま更新されないのか？ - GIGAZINE 71 users Windows純正のドライバーのタイムスタンプはすべて「2006年6月21日」に統一されています。Windowsマニアでもなかなか知らなさそうなトリビアの理由をMicrosoftのエンジニアが明かしています。 Why are all Windows drivers … [gigazine.net ](http://b.hatena.ne.jp/ebibibi/?url=http%3A%2F%2Fgigazine.net%2F) - テクノロジー - あとで読む ...

Microsoft Ignite 2016にてアナウンスがあったものをまとめます。随時更新します。 Security関連 Windows Defender Application Guard Introducing Windows Defender Application Guard for Microsoft Edge | Microsoft Edge Dev Blog Windows 10上のMicrosoft Edgeブラウザを更にセキュアにする機構 Windowsカーネルよりも下位レベルで分離した環境でEdgeを実行 通常のユーザー領域へのアクセスができあい環境でEdgeが動いているため、脆弱性があっても攻撃を防ぐことが可能 Insiderへは来月あたり、広くは来年に提供予定とのこと - Windows Defender Advanced Threat ProtectionとOffice 365 Advanced Threat Protectionの連動 Windows 10上で検出された脅威とOffice 365上で検出された脅威とを連動して調査、対処していくことが可能となる。 - Office 365 Advanced Threat Protection Word, Excel, PowerPoint, SharePoint Online, OneDrive for Businessへの拡張 Dynamic Delivery 添付ファイルがスキャン中のタイミングでもメールを先行して配信。添付ファイルの部分はプレースホルダーの形。 - URL detonation 未知の悪意あるURLをリアルタイムで分析 - Office 365 Threat Intelligence 攻撃に対応してアラートおよび情報を提供し、SIEMシステムと統合可能とすることで脅威にたいしての動的なポリシー設定を可能とする。 - Outlook for iOS, Outlook for AndroidのExchange Onlineメールボックスのネイティブサポート。 Office 365外でのデータキャシュが不必要となり、企業利用にさらに適切となった。 - Enterprise Mobility + Security E5 2016年10月１日からの提供。 Microsoft Advanced Threat Analytics (ATA) Microsoft Cloud App Security Azure Information Protection Azure Active Directory Identity Protection 概要紹介動画　An Introduction to Microsoft Azure Information Protection - YouTube - Azure Active Directory Privileged Identity Management Intune Mobile App Management (MAM) - Secure Productive Enterprise 2016年10月１日からの提供。 Windows 10, Office 365, Enterprise Mobility + Securityが含まれる。 ...

Azure Stack版のClouc Platform Systemに関して発表されています。Igniteでの発表だと思ってましたが、WPCに合わせて発表出ましたね。Igniteではおそらくハードウェアベンダーから具体的なラインナップや価格の発表があるのかな? https://azure.microsoft.com/en-us/blog/microsoft-azure-stack-delivering-cloud-infrastructure-as-integrated-systems/ まずは、DELL, HPE, Lenovoがベンダーとして名前が出ています。 Microsoft is committed to ensuring hardware choice and flexibility for customers and partners. To that end we are working closely with the largest systems vendors – Dell, HPE, Lenovo to start with – to co-engineer integrated systems for production environments. CPSのAzure Stack版リリース目標は2017年半ば。 We are targeting the general availability release of Azure Stack, via integrated systems with our partners, starting mid-CY2017 上記発表を「メジャーベンダーの固定化されたハードウェアでしかAzure Stackが動かない」と受け取った人からコメント欄で苦情の嵐…。(気持ちはよく分かりますね…) ...

Build, IgniteとMicrosoftの大きなイベントが立て続けにあり、新発表がわんさかありましたね。いや、面白いですね。 色々とHotな話があるのですが、個人的に一番衝撃的だったのは「Microsoft Azure Stack」です。オンプレミスでも、ホスティングサービスプロバイダーでも、Azureでも一貫性をもった「Cloud OS」を提供していく…というのはWindows Server 2012のころからのMicrosoftのビジョンですが、いよいよ本格的に具現化していくのだなという印象です。 まず、気になるのは「Windows Azure Packはどうなるの?」という事ですが、冒頭の図によく表されていますね。これはIgniteのセッションの1つであるWindows Azure Pack Roadmap | Microsoft Ignite 2015 | Channel 9のスライドからの引用です。 Microsoft Azure StackはWindows Azure Packとは別物であり、Microsoft Azure Stackが出た後もWindows Azure PackはURによって機能追加が継続される。 ということが読み取れると思います。ただ、あちこちのセッションの動画を見て回ったり、Q&Aでのやりとりを聞いたり…と繰り返しているとちょっと違う印象にもなるところですが。現時点での私の理解は以下です。私の英語力の問題により、誤解や誤りが入っている可能性はあります。また、リリースは随分先になるはずなので、これから変更になる可能性も大いにあると思います。 Microsoft Azure Stackは基本的に今のWindows Server, System Center, Windows Azure Packとは別製品。基盤のOSから一番上のUIまで含んだ単独の製品となる。 - Windows Server 2016の上にMicrosoft Azure Stackをインストールする…というようなことは出来ない。 - Azure Resource Managerという管理層を新たに設け、それによってAzureとAzure Stackとに互換性を持たせる。 - 基本的に「接続先を変更する」という操作だけで切り替えられ、その先がAzureなのかAzure Stackなのかは気にしなくて良くなる。 - リソースはjsonファイルで記述可能であり、デプロイにどどまらず変更も可能。 - Azure上には多数のサービスがあるので、そのうちどのサービスがAzure Stackに乗るのかはビジネス上判断となりこれから決定される。(エラスティックであることが有利なサービスはAzure Stackにはこなかったりするのでしょうね、きっと) - Azure Stackを今すぐ触りたかったら、Azureを触れば良い。Azure StackのPoCはAzureでできる。 個人的には、MicrosoftがAzureで本当に使っているハード(相対的に相当安いはず)まで含めて全部ラックにおさめる形で提供しだしたりすると大変なことになるよなぁと思います。さすがにそこまでは無いかもしれませんが、CPSの例もありますし、似たようなことはDELLさんあたりと組んで行われそうな気もします。 個人的には、Azureも学んでおかないとまずいよなぁと思いながら時間が取れなくて中々…という感じでしたが、もうAzureだのオンプレミスだのを区別する必要もないような世界がもうすぐそこですね。