Update

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は間違いなくそこに一番近いシステムだと思います。

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は構成的にどんどん品質が向上していく思想になっていますから、これからもどんどん品質を上げていって貰えればと思います。