Azurestack

先日HCCJPにてハンズオンイベントを開催しました。ハンズオン資料作成、ハンズオン講師等務めさせてもらいました。 ざくっと概要を理解するものとしてはそんなに悪く無いできだと思いますのでよろしければ参考にしてみてください。 ※Azureの理解という観点でみると「Azure, Azure Stackで同じ概念、操作でできるもの」に引っ張られすぎている感は否定できませんけれども。 https://gitpitch.com/hccjp/hybridcloudhandson1

#この投稿は下記３つのブログにクロスポストしています。 - [https://diary.ebisuda.net/](https://diary.ebisuda.net/) - [https://windowsadmin.ebisuda.net/](https://windowsadmin.ebisuda.net/) - [https://cloud.ebisuda.net/](https://cloud.ebisuda.net/) 今日はお休みの日ですが、Interact 2019にて登壇させてもらってきました。 休日のコミュニティイベントへの参加も解禁しましたが、今回はさらに長男と次女をつれていきました。そして私と一緒に登壇させました。 長男はきちんと自己紹介できましたが、次女は恥ずかしがって私の後ろに隠れてしまいました。そして結局、事前にはなにも教えておかずにその場で「こうやって」って操作をさせて、MinecraftのサーバーをAzure上に展開してもらいました。 どうやら結局なんだかよくわかっていなかったようですが、それでも楽しかったようなので良かったです。 セッションは参加してくれた人に何度も笑ってもらいました。それがよかったです。笑いもなにもない真面目なITのセッションって本当にくらーい感じになってしまうのでそういうのは好きじゃないんです。なんでも楽しいのがいいですよね！ 資料はSlideshareにアップロードしておきましたので、よろしければご覧くださいませ。 ** あなたも「違いが分かる人」になりましょう！ ～ Azure, AzureStack, AzureStack HCI ～ ** from Masahiko Ebisuda

AWS Outpostsの発表はずいぶん前(re:invent 2018)になされ、私もブログでも言及していました https://cloud.ebisuda.net/aws-outposts%E3%81%A8microsoft-azure-stack%E3%81%AB%E9%96%A2%E3%81%97%E3%81%A6%E6%9C%AC%E8%B3%AA%E7%9A%84%E3%81%AB%E5%A4%A7%E4%BA%8B%E3%81%A0%E3%81%A8%E6%80%9D%E3%81%86%E3%81%93%E3%81%A8/ まだOutpostsは市場には登場していませんが、Youtube上で解説動画が見られることを教えてもらいました。 https://youtu.be/Cnn3BYsE6ug?fbclid=IwAR0FbjkR0wjh3lIUMPbMm9zqeJwV1mO4RzkRIPAZH3nEZEhht1yJ-whPjm4 このような形でしっかりと解説を聞くのは初めてだったので、聞きながらTwitterで感想をつぶやいてみました。 AWS OutpostsとAzure Stack - Togetter Outpostsが予定どおり出荷されて(2019年後半を予定)、オンプレミスでも「クラウド」を利用する機運が高まってくれると良いなとあらためて思います。

Azure Stack上の仮想ネットワークと任意の場所のネットワークとをVPN接続で接続することができます。やり方はいろいろとありますが、簡単にできるものの一つとしてWindows ServerでのVPN接続があります。Azure StackとのVPN接続は(私の調べる限り)Windows Server 2012 R2では接続できず、Windows Server 2016以上が必要なようです。下記に方法を紹介します。 まずは、接続対象となる仮想ネットワークを作成します。 仮想ネットワークに対して「仮想ネットワークゲートウェイ」を作成します。このゲートウェイとVPNを接続することになります。 次に「ローカルゲートウェイネットワーク」を作成します。これは今回ですとWindows Server 2016に対応します。 次に「接続」を作成します。 接続の種類は「サイト対サイト(IPsec)」になります。 次はWindows Server 2016側の構成を行います。こちらはきちんとドキュメント、スクリプトが確認できませんでした。私は主に下記のコマンドレットを実行して構成しました。ここでAzure Stackの仕様にあわせるように細かくオプションを設定することがWindows Server 2012 R2ではできませんでした。 Install-WindowsFeature RemoteAccess -IncludeManagementTools Add-WindowsFeature -name Routing -IncludeManagementTools Install-RemoteAccess -VpnType VpnS2S Add-VpnS2SInterface -Name $SP_AzureGatewayIpAddress -Protocol IKEv2 -Destination $SP_AzureGatewayIpAddress -AuthenticationMethod PSKOnly -SharedSecret $SP_PresharedKey -Persistent -IPv4Subnet @($SP_Subnet) -AuthenticationTransformConstants GCMAES256 -CipherTransformConstants GCMAES256 -EncryptionMethod AES256 -PfsGroup PFS2048 -SALifeTimeSeconds 14400 -SADataSizeForRenegotiationKilobytes 819200 -MMSALifeTimeSeconds 28800 -CustomPolicy ...

4月27日に品川の日本MicrosoftさんのセミナールームにてAzure Stackに関する値段をやります。 Microsoft Azure Stack で、攻めの老朽化対策 - Windows Server 2008 や VMware の移行に向けた将来性のある選択肢 - | JBS 日本ビジネスシステムズ株式会社 今回はAzure Stackの魅力や良さは理解しつつも「ちょっと値段が高すぎて…、だって3千万も4千万もするんでしょう？とても予算的に手が出なくて…」と、値段が原因で手が出なかった方に「本当の値段」がわかるような内容にしたいなと思っています。 値段と言っても様々な観点があります。 ハードウェア料金- ラックや電源等含めた設置場所- 既存の環境と接続するための設計- ハードウェアを設置するための設置作業- 設置後にAzure Stackを構成するための作業- 構築した環境を実際に利用可能にするための構成- 構築した環境を運用監視- Update / Upgrade- バックアップ- 構築され運用されている環境をユーザーが利用するための仕組みを作る、回す- 可動したリソースに対して支払うライセンス費用- 基盤のオペレーターに対して支払う報酬- (既存環境から移行する作業) これまで単純に1だけの値段を見て「高い」という反応をされてしまうお客様も結構多かった印象です。1の値段が例えば5千万だろうと1億だろうと1～10トータルで長期的に考えたときの値段のほうが本質的に重要ですからAzure StackのTCOは本質的に圧倒的に安いというのが私の考えではあります。(※ただしそのためには「誰が何をするのか」という部分でのパラダイム・シフトが合わせて必要です。) ですが、今回のセミナーでは1の値段だけをみて「高い」と反応してしまっていた方にも「お？これなら先に進められるかも!」という感覚を持ってもらえるような値段が出せそう、ということで話が始まっています。 本当にセミナーに来てもらって、具体的な話が出来る方にしか伝えられない情報になりそうなので、是非お越しいただければと思います！ 申込みは下記からお願いします！ Microsoft Azure Stack で、攻めの老朽化対策 - Windows Server 2008 や VMware の移行に向けた将来性のある選択肢 - | JBS 日本ビジネスシステムズ株式会社

みなさんこんにちは。胡田です。Wordpressがメジャーバージョンアップしてエディタがかなり変更になり、戸惑っております。(慣れない…) さて、今回はAzure Stackの更新処理の素晴らしさについて…と、このネタはすでにこのブログでも書いた気がします。ですが、先日のHCCJPの第3回勉強会に合わせて動画を作成し、youtubeにアップロードしましたので改めて。 動画を見てもらうとわかってもらえると思うのですが、オペレーションは本当に簡単です。 テストする- (テストOKであれば)Updateのボタンを押す 本当にこれだけで、クラスタのホストノードがOSレベルで最新に刷新され、複数台動いているAzure Stackを構成するVM群も刷新されます。上で動いているユーザー作成のリソースもすべてライブマイグレーションで移動させながらの処理となります。 本当に私が昔からずっと夢見ていた 決め打ちの機器構成にしておけば構成組むのに悩まなくて済む- 構築作業も定型化、効率化、高品質化できる- 横展開できる- 構築も自動化できる- 更新も自動化できる というのが実現されているのがAzure Stackなんです。そしてさらに構築したシステム自体がセルフサービスポータルを備え、セルフサービスで勝手に利用してもらうことができるという現実。素晴らしすぎて涙が出ます。いままで自分が何十年も苦労していたインフラ周りの苦労は何だったのかと。 「こうすれば全部自動化出来るじゃん」ということは今までもずっとあちこちで言ってました。他の同業者さんの中にも同じような事を言っていた方はやっぱりおおくいると思うのです。でも、それを製品レベルできちんと仕上げちゃうというのはさすがMicrosoftだよなぁと思うのです。 本当にブラフ抜きで、Azure Stack相当の環境をAzure Stackを使わずに設計～構築しろっていわれたら数千万円レベルの費用では作れないと思います。更新にだってもちろん同じくらいの費用がかかります。そう思うとAzure Stackって本当に安いんですよね。 Azure Stackの絶対的な金額はもちろん高いのですが、でも、それって何と比べて高いんでしょう？Azure Stackが実現している範囲や運用まで含めたトータルのコストを考えた時に本当に高いんでしょうか？私は「圧倒的に安い」ことを確信しています。 「本当かなぁ？」と思う人は、是非、インフラを管理している管理者、あるいはベンダーに「全ホストOSの最新版への更新と基盤の全ミドルウェアの更新を、上で動いている仮想マシンを落とさずに作業する場合の期間と費用の見積もりをちょうだい」と言ってみると良いです。数ヶ月の期間をかけて数百万円～数千万円の費用がかかる見積もりが出てきますよ。間違いなく。本当に。 あるいは「まず調査、テストをしっかりしないといけません。そもそも停止時間なしで出来るかどうかも怪しいです。そのうえでの見積もりになります。でも、リスクなど考えると新規にシステムをside by sideで作成して、リソースを移動する手法をお勧めします」的な答えが返ってくるはずです。つまり「できない」「別でつくちゃったほうが確実で安い」という回答だって当たり前にありえます。 そんな現実がある中で、世界中のすべてのクラスタをボタン一発で更新できちゃう仕組みを備えているAzure Stackは本当に凄いです。この1点だけでもAzure Stackを導入する価値があると私は思うところです。だって、きちんとUpdateし続けないとセキュリティ的にやばいですよ。世の中の流れからも取り残されてしまいます。「作ったはいいけど更新できないシステム」沢山ありませんか？基盤が古くて新しいバージョンのゲストOSが動かせない基盤、ありませんか？更新できないのを言い訳するために「安定させるために基盤はいじりません」的なことを言ってませんか？ このあたり「うちは大丈夫！」って自信をもって言えるのはパブリッククラウドでPaaSを使っているところ以外にはほぼ無いだろうと思います。あるいはオンプレミスでAzure Stackを使っているところ、ですね。 この凄さ、伝わるといいなぁと思いながら動画を作りました。(あんまり伝わっていないと思いますが…。)

Azure Stack統合システムは必要ポート数を少なくするためにExtension Hostという機構を導入します。そのために既存のAzure Stackオーナー含めて1811Updateを導入するまでに新しく追加される2つのワイルドカードSSL証明書を追加する必要があります。 参考：Enhance security and simplify network integration with Extension Host on Azure Stack | Blog | Microsoft Azure というわけで、私も証明書の更新作業をしたのですが一部ミスをして無駄に時間を使ってしまったこともあり…(反省)…顛末を記録しておきます。 作業の流れ 作業は以下の流れになります。 - 新しい証明書要求の作成 - 証明書への署名 - 証明書のインポートとエクスポート - 証明証のテスト - 証明書の入れ替え 新しい証明書要求の作成 証明書の作成は証明書要求(CSR)を作成し、それを証明局にて署名してもらう流れになります。Azure Stack用のCSRの作成は以前は苦労して自分で準備する感じでしたが今は作成ツールが用意されており相当楽になりました。ドキュメントも更新されています。 まず下記のページに証明書の要件が記載されています。が、これを加味したCSRを作成してくれるツールが用意されているので極論を言えばこちらは理解しなくても作業的には大丈夫です。(でも理解しておくのがもちろんベターです。) - [Azure Stack 統合システムの Azure Stack 公開キー インフラストラクチャ証明書の要件 | Microsoft Docs](https://docs.microsoft.com/ja-jp/azure/azure-stack/azure-stack-pki-certs) そして、実際のCSRの作成方法は以下のページに記載されています。 - [Azure Stack 統合システム デプロイのための Azure Stack 公開キー インフラストラクチャ証明書を生成する | Microsoft Docs](https://docs.microsoft.com/ja-jp/azure/azure-stack/azure-stack-get-pki-certs) 実際の作業はReadinessCheckerというツールを使って行います。マニュアルどおりなので簡単です。 注意点1 私がハマったポイントの1つ目のポイントですが、このReadinessCheckerのバージョンが古いと肝心のExtension Host用のホスト名が追加されていないという状況になりますので注意してください。必ず最新バージョンで作業を行ってください。 Generate Azure Stack Public Key Infrastructure certificates for Azure Stack integrated systems deployment | Microsoft Docs　の下のクローズされたFeedBackに私の残念な投稿が…。欧米の方はこういうときにとても優しいコメントをくれるので助かります(笑 ...

Ignite 2018で参加した下記のセッション内で解説されていたUpdateの仕組みについてまとめておきます。Azure Stackの信頼性の根幹がここにあり、私はこの仕組が素晴らしいと思うのです。 元ネタは以下です。 MyIgnite - The guide to becoming a Microsoft Azure Stack operator このエントリ内の画像等も全て上記からの引用です。 まず前提としてAzure StackではUpdateはほぼ毎月出てきますし、最新から2つ前までしかサポートされません。Updateは当て続けることがそもそもの前提です。構築後に全くUpdateを当てずにおいておくような運用はそもそもできないと考える必要があります。これはセキュリティ上大変望ましいことですし、一度Azure Stackにしてしまえば「アップデートができない！」「EOS問題どうしよう」というようなことにはそもそもならないわけです。(基盤に関して) でも、その毎月に近い速度で出てくるUpdateは安定したものでないと困りますよね？そこでUpdateをどうやって作って、どうやってテストして顧客に出しているか、ということを解説したのが下記のスライドです。 Windows Serverの毎月のKBを元にパッケージを作り、開発者の環境でUpdateパッケージをビルドし、4ノードの環境でバグだしをしながらパッケージを展開、確認する。- できたものを100セットのマルチノード環境に展開して、確認、バグだしをする。- 2の工程で安定したものをハードウェアベンダーに提供し、それぞれのOEMベンダーの環境で展開、確認、バグだしする。- 長期間可動し続け、Updateを適用し続ける10のマルチノード環境に展開、確認、バグだしする。- 全ての工程でバグを出し、テストを繰り返し、安定したものを顧客に提供する。 かなりの規模でテストが行われていることがわかりますね。このスライドには明記されていませんが、もちろん顧客の環境でも万が一問題があればUpdate自体が更新されます。 さらに、実際のUpdate時の挙動を説明もありました。 まず、Updateのフェーズ1では必要なものをダウンロードするのですが、このフェーズのポイントはAzure Stackのソフトウェアと共に、ホストOSはイメージが取得されている点です。そう、Azure StackのNodeに関しては「パッチを当てる」ではなく、イメージを差し替えているんです。 Azure StackのNodeはVHDブートをしているわけです。Update前はUpdate前の現在のVHDから各Nodeが起動しています。その上でAzure Stackのソフトウェア(青)とテナントのVM(緑)が稼働しています。 新しいVHDを全てのNodeに配置します。 そして、Nodeがドレインされ、Node上で動いていた仮想マシンは別のNodeのLive Migrationされます。この時移動されるVMにダウンタイムはほぼありません。 そしてドレインされたNodeのブートするVHDが新しいものになります。 そしてその新しいVHDからブートしたシステムに対してコンフィグが適用されます。(※裏ではPowerShell DSCが使われています。) これを全Node繰り返します。 次にイメージベースのUpdateAzure Stackのソフトウェアにも適用します。 適用時間は20時間以上かかります。 このような仕組みになっています。 はっきり言ってAzure Stackの本体は毎月のUpdateでほぼ全部イメージベースで入れ替わっているわけです。Azure Stackはハードウェアに関しても細かく規定がありアプライアンスとなっており、それをイメージベースで更新している、ということは全世界で「同じ」環境が再現されているわけであり、だからこそAzureとの一貫性も保たれるし、Azure Stack間での一貫性も保たれるわけですね。 この仕組ってインフラエンジニアなら誰しもが考えるけれども諦めるような壮大な仕組みだよなと私は思うんです。事前に大規模に自動的にテストしながらイメージベースで環境を入れ替えてしまう。そうすれば環境の有無に悩まされることもなく全部で同じことができます。SIerのインフラエンジニアなら「全案件に横展開できるイメージを作成してそれを展開しまくれば環境構築OKにしてしまいたい」って思ったことあると思うんですよね。Azure Stackではそれが実現されてます。すごいです。 で、この仕組なら、本当は累積的なUpdate適用が可能なんじゃないの？と私は思います。だってイメージベースで全部入れ替えちゃってるんですよね？ほとんど？きっと今はなにか事情があってまだできていないのだとは思いますが、将来的にはある程度Updateを飛び越えてのUpdate適用が可能になる気もします。毎月の機能的なバージョンアップと持っているデータの整合性等の話もあると思うので難しいところもあるとは思いますが。 そして、私が言いたいのは「やればやるほど品質が上がる仕組みになっている」ということです。このUpdateの仕組み自体もより洗練されていくでしょうし、Updateが出てきたら気軽に当てることが当たり前になるITの世界に早くなればいいのになと思います。Azure Stackは間違いなくそこに一番近いシステムだと思います。

Test-AzureStackはAzureStackの全体的なテストを実施してくれる便利なコマンドレットです。 ただ、実行するにはERCSにRemote PowerShellで入って～と結構手間がかかります。そこで、自動的に実行して結果をTeamsに投稿するスクリプトを書きました。タスクスケジューラーにでも登録して毎日実行させておくと幸せになれるかなと思います。 コードはGitHubにあげておきました。 - [ebibibi/TestAzureStackAtERCS](https://github.com/ebibibi/TestAzureStackAtERCS) 毎日結果を確認しています。自分で作ったスクリプトの投稿する結果と会話するやばい人になってます。 ちなみにUpdateの実行中のTest-AzureStackは失敗しました。ある意味当たり前といえば当たり前なのかもしれませんが、ちょっとどうにかならないだろうか？という気もします。コード側で対処入れてもいいのですが…。

日経SYSTEMSの2017年9月号のAzure Stackに関連する記事に私のコメントも掲載されています。 日本ビジネスシステムズの胡田氏は「Azure StackでID管理に用いるAzure Active Directoryは、ユーザー企業のオンプレミス環境で一般的なActive Directoryとは別物。混乱を招く恐れがある」と指摘する。私も、Web上や雑誌上でも記事を書いたり、インタビューを受けてコメントが掲載されたりなどかなり露出がふえており、大変ありがたいことです。私は人生の生存戦略において、外部露出を増やす戦略でやっていますので実名でこのように雑誌記事にコメントがのるのは大変ありがたいことでして、是非インタビューでもなんでもお声がけいただければと思います。 と、大変ありがたい話ではあるのですが、流石に短い紙面でこのコメントだけ掲載だと相当の誤解を産んでしまうのも致し方がないところだと思います。このコメントに関しては追加で補足をさせてもらおうと思います。 まず、Azure StackでID管理にAzure Active Directoryを用いるというのは半分正しく、半分正しくありません。Azure Stack自体へのアクセス、特に管理ポータルへのアクセス時に使うIDはAzure Active DirectoryとADFSのどちらかが選択可能です。推奨はAzure Active Directoryであり、つまりはクラウド上のIDですからインターネット接続が行えることが前提条件となります。Azure Active DirectoryのIDということはつまりはO365で利用しているIDとも共通とすることができるわけであり、Microsoftの戦略からするとクラウドIDの中心としてのAzure Active Directoryを軸に全てのクラウドサービスをコントロールしようとしていますので、Azure Stackもその1つということで何も違和感がありません。 ただ、一方で「インターネットには接続させない、クラウドサービスは利用できない」という環境ではAzure Active Directoryを使うことはできませんから、そのためのオプションとしてADFSおよびADFSと連携するActive DirectoryをIDとすることもAzure Stackでは可能となっています。この場合、「ユーザー企業のオンプレミス環境で一般的なActive Directory」のIDをそのまま利用可能となりますから、何も混乱なく利用可能となります。 さらにいうと、企業においてAzure Active Directoryを利用する場合にはそのIDはオンプレミスのActive DirectoryとAD Syncにて同期されているケースが非常員多いため、Azure Active DirectoryをIDとしている場合でも、それは事実上Active DirectoryのIDと統一であり、混乱を招くようなものではないケースが多いでしょう。 記事上では表現されていませんが、私が危惧している心配はAzure Stackのマネジメントポータル利用時のIDではなく、Azure Stack上に構築されるシステムへのアクセスに利用されるIDに関してなのです。 もちろんAzure Stack上にIaaSを利用してWindows Serverを展開し、そのWindows Serverを既存のネットワーク上のActive Directoryにドメイン参加させ、いつもと同じようにAD統合認証でシステムを作成する…、これはもちろんやろうと思えばできるのですが、これをやろうと思うと、オンプレミス同士にもかかわらずVPN接続が必要になってきます。これ、非常に違和感が出てしまうんじゃないかと思っています。 もちろんAzure StackはAzureそのものなのですから、VPNで接続するというのはAzureと同等であり、一貫性があります。 でも、同じ社内ネットワークに存在している「隣のサーバー」なのにVPNをはらないとネットワーク的につながらないというのはちょっと違和感を感じるひとが多いいんじゃないかと思うんです。 さらにAzure StackになるとInfrastructure as Codeも非常にやりやすくなります。コードにシステムを表現しておいて、それを展開して環境を作り出す…必要なくなったら消す…そんなことをバンバンするようになってくると…。既存環境へのVPN接続やドメイン参加をして…ということが非常に足かせになってしまいます。そもそも同じ環境を2つ作ろうとおもうと、コンピューターアカウントが重複して問題が発生してしまったりもしますしね。 つまり、Azure Stack上でAzure Stackらしい使い方をしようと思うと、今までのようにActive Directoryを使った認証にするのではなく、自然とAzure Active Directoryを使った認証システムを採用することになると思っています。 Azure Active Directoryに寄せることで色々とメリットも出てきます。Azure Active Directory Premiumの各種機能を使って認証を強化したり、セキュリティを強化したりできるが大きいでしょうか。 このあたりをきちんと理解してシステムを組んでいくようになるのがすぐ近い未来だと私は思っています。「社内であっても認証にActive DirectoryではなくAzure Active Directoryを使う」このあたりをきちんと理解し、システムを構築するようになるまでには、まだまだ結構色々とあちこちで苦労があるだろうなと思ってます。 雑誌のコメントにはこのようなバックグラウンドがあり、それが凝縮されてあのような表現になっているわけです。 Azure Stackを利用するなら、IaaSでVPNをつかって既存のシステムとネットワーク的にに連携してAD統合認証…ではなく、PaaSをつかって認証はAzure Active Directoryを使ったシステムをまず第一に考えて行きたいですね！ ...

今日は桃の節句ですね。さて、今週のトピックスです。 - Announcing preview of Azure HDInsight 3.6 with Apache Spark 2.1 | Blog | Microsoft Azure 1 user Get credits that enable: 4 Windows or Linux Virtual Machines 24 x 7 for a month And much more… Learn more [azure.microsoft.com ](http://b.hatena.ne.jp/ebibibi/?url=https%3A%2F%2Fazure.microsoft.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, azure 27 clicks 2017/03/03 - Azure Command Line 2.0 now generally available | Blog | Microsoft Azure 1 user Back in September, we announced Azure CLI 2.0 Preview . Today, we’re announcing the general availability of the vm , acs , storage an… ...