年始からバタバタしてますね。
CPU の脆弱性から Azure のお客様を保護するために – Japan Azure Technical Support Engineers' Blog
背景等を含め、こちらの記事で分かり易く説明されています。
この記事ではメンテナンスの立ち会いがてらに、実際のところどんな感じだったかのメモを残しておこうと思います。
メンテナンス対象となっているVMをまとめて確認したい
「サービス正常性 → 計画済みメンテナンス → 影響を受けるリソース」で、いまのアカウントで管理している全サブスクリプションの情報がまとめて一覧で見られます。メンテナンスが終わったリストは残念ながら見あたりませんでした。
(2018年1月5日 11時21分 追記)
メンテナンス完了 → ホスト障害 → メンテナンス終わってないホストに着地 → またメンテナンス対象に
という流れで再度メンテナンス対象になるケースを見かけました。やはり推奨されているとおり、Azure Monitor や Instance Metadata でこまめに見ておくのが良さそうです。
(追記終わり)
各VMのメンテナンスウィンドウを確認したい
仮想マシン一覧のブレード(Virtual Machine)で列を追加できます。今回のようにプラットフォーム側でスケジュールを設定された場合は、「メンテナンス - 自動スケジュールされたウィンドウ」列に表示されます。ここが空欄であれば実施済みと判断して良さそうに思います。セルフサービス期間には「メンテナンス」列に「完了」と出ていたんですが、セルフサービス期間を過ぎると何故か消えてしまうようです。
(2018年1月4日 20時57分 追記)
と思ったら、いま見た感じだと「完了」はちゃんと表示されるようになっていて、逆に「メンテナンス - 自動スケジュールされたウィンドウ」列が無くなっていました。列の追加からも消えてしまいました。
(追記終わり)
メンテナンスがいつ頃行われたのか確認したい
「メンテナンス - 自動スケジュールされたウィンドウ」欄が空欄になっているがちょっと不安、という場合には、仮想マシンの「リソース正常性」から「履歴の表示」でメンテナンス(による再起動)が実施されたかどうかを確認することができます。メッセージにはいくつかのパターンがあるようです。
おそらく前者はホスト移動無しでパッチ適用した場合、後者はホスト更新のため自動再デプロイされた場合のメッセージかなと思います。
セルフサービス期間を過ぎているがなんとか手動でやりたい
公式情報によると 「Azure インフラストラクチャの大部分は、本脆弱性に対応するため更新済みとなります」 ということで、割り当て解除・開始や再デプロイ、(主に)v3系へのサイズ変更なんかでメンテナンス済みのホストに移動する可能性はあるかなと思います。
といっても、相当な勢いでメンテナンスが進んでいるようなので、あまりジタバタしない方が良さそうには思います。今日のお昼頃に手動で再デプロイしてみた仮想マシンではこんな感じのログになっていまして、正常にアクセス可能になるまで結構な時間がかかりました。
ゲストOSへのパッチ適用は必要？
必要なはずです。詳しくは各ベンダーやディストリビューションの情報を確認しましょう。
Azure以外のクラウドは？
AWSで年末からずっとメンテナンスが走っていたのもこの件だったんでしょうね。公式なリリースはこちら。あと数時間で基盤側のアップデートが終わるので、ユーザー側でもOSパッチを当てるようにとのこと。Amazon Linuxはパッチ提供済みなので yum update kernel で適用されるそうです。
Processor Speculative Execution Research Disclosure
Google Cloud Platform については、基盤側は対応済みなのでゲストOS側のパッチを当てるようにとのこと。影響があるのはGCE、GKE、Cloud Dataflow、Cloud Dataproc。
Google Online Security Blog: Today's CPU vulnerability: what you need to know
クラウドではありませんが、VMwareについてはパッチが提供されているようですね。
(2018年1月5日 追記)
IBM Cloud からもリリースがありました。1/5から1/8の間にパッチ適用、インスタンスの再起動あり、バックアップ推奨。タイミングはメンテナンスチケットで通知されるとのこと。
We're taking action to secure VSIs against recent security vulnerabilities - IBM Cloud Blog
(追記終わり)
性能が落ちるという情報があるが大丈夫？
AWSのフォーラムで話題になっていたようですね。実際に、身近なEC2でも特にParavirtualizedなインスタンスでは比較的大きめな影響が出ていたようです。
Degraded performance after forced reboot due to AWS instance maintenance
Azureについては、ネットワークに影響が出る可能性があるかも、ということで、これは後ほど実測してみようかと思います。
CPU の脆弱性から Azure のお客様を保護するために – Japan Azure Technical Support Engineers' Blog
(2018年1月5日 追記)
と言うわけで実測してみました。
まずはUbuntuでUnixBenchを実行した結果です。誤差程度といいますか、東日本のAシリーズはむしろ新しいハードウェアに乗って性能アップしちゃったのかもしれません。Bシリーズについては、ちょっと性能が出すぎてしまっている感があるので参考程度に。
| リージョン | インスタンスタイプ | スコア (メンテ前) |
スコア (メンテ後) |
前後比 |
|---|---|---|---|---|
| 東日本 | Standard A1 (1 vcpu, 1.75 GB memory) | 742 | 799 | 108% |
| 東日本 | Standard_A1_v2 (1 vcpu, 2 GB memory) | 785 | 820 | 105% |
| 東日本 | Standard F1s (1 vcpu, 2 GB memory) | 1,770 | 1,676 | 95% |
| 西日本 | Standard B1ms (1 vcpu, 2 GB memory) | 1,015 | 1,890 | 186% |
| 米国西部2 | Standard F2s_v2 (2 vcpus, 4 GB memory) | 2,877 | 2,914 | 101% |
続いてネットワークのパフォーマンス。公式ドキュメントの案内通り、NTttcp で測定しました。
見た感じ、アナウンス通り少しパフォーマンスが落ちているように見えますね。SR-IOVを有効にした場合で以前と同程度という結果でした。Dシリーズ(Dv2、Dv3)だけの結果なので偏りがあるかもしれませんが、ご参考まで。
(2018年1月5日 訂正)
Windows Updateの影響を考慮してなかったので、改めて測定し直しました。
結果、プラットフォームのメンテナンス前後ではパフォーマンスは変わらず、Windows Update を適用すると少し落ちて、SR-IOVを有効にすると回復する、といった結果になりました。
最後に、ストレージのベンチマークを簡単に(2018年1月5日 追記)。L4sにアタッチしたデータディスク(P30)を CrystalDiskMark のデフォルト設定で計測しました。結果としてはアップデートの影響は無く、スペック通りの性能が出ていました。
▼Azureメンテナンス前(2017年12月 計測)
▼Azureメンテナンス後、Windows Update未適用(2018年1月5日 計測)
▼Azureメンテナンス後、Windows Update適用(2018年1月5日 計測)
