Hyper-Vの.vhdファイルからAzure仮想マシンのイメージを作成する(ポータルのGUIで)
たぶんもうちょっと前からあった機能だとは思いますが、ポータルのGUIから仮想マシンのイメージが作れたので記録しておきます。
「日本語版DVDからインストールしたWindows Server 2016が欲しい」というリクエストがあったのでやってみたらできました。
ここで紹介する手順は、いわゆる「仮想マシンのひな形」としての「イメージ」を作る手順なので、仮想マシンをそのままコピーする手順ではありません。そちらのケースは、今のところ.vhd経由だとGUIでは完結しないので、どうしてもと言うことであればAzure Site Recoveryをつかうとか別のアプローチになると思います。
Hyper-V 仮想マシン側の準備
基本的には公式ドキュメントにあるとおりに準備を進めて、Azure用の.vhdファイルを作ります。
Hyper-V仮想マシンが第2世代の場合はこのあたりで第1世代に変換しておくのが良いと思います。
.vhdxから.vhdへの変換や固定サイズ化などは、Hyper-VマネージャのGUIでもできます。
ちなみに、一部の仮想マシンシリーズではNested Virtualizationをサポートしているので、Azure仮想マシン上でHyper-Vを立ち上げてこのあたりの作業を進められるようになりました。Dv3やEv3シリーズあたりがそれです。
Azure Storageへのアップロードには、Azure Storage Explorerも使えます。「ページBLOB」としてアップロードしましょう。
「イメージ」の作成
アップロードが終わったらイメージの作成です。「イメージ」ブレードを開きます。
「追加」をクリックします。
名前などを適宜付けていきます。「ストレージBLOB」で、アップロードした.vhdを指定します。
「作成」を押してしばらくすると、仮想マシンのイメージが出来上がります。
仮想マシンの作成
「イメージ」ブレードからイメージを開いて「VMの作成」をクリックします。
あとはいつも通りに仮想マシンを作るだけです。
ここまで。
気付かないうちにポータルもどんどん便利になりますね。
Azureクラシックポータルが終息
既報の通り、クラシックポータルが2018/1/8をもって終息していました。URLにアクセスすると現行ポータルにリダイレクトされるようになっていました。 https://manage.windowsazure.com/
▼クラシックポータル終息のアナウンス
Azure portal update for classic portal users
移行ガイド的なドキュメントが12月に公開されていたようなので参考まで。
念のためですが、クラシックリソース(クラシックVMやクラシックVNet)については引き続き現行のAzureポータルからアクセスできます。
クラシックポータルにはずいぶんとお世話になりましたので、ちょっと寂しいですね。
Azure仮想マシンのメンテナンスを見守ったメモ
(2018年1月25日 追記)
Azure公式ドキュメントにFAQが記載されていました。オフィシャルな情報としてはこちらをご覧下さいませ。「Accelerated maintenance」なんて名前が付いたんですね。
(追記終わり)
年始からバタバタしてますね。
CPU の脆弱性から Azure のお客様を保護するために (2018/1/25 補足情報の更新) – Japan Azure Technical Support Engineers' Blog
背景等を含め、こちらの記事で分かり易く説明されています。
この記事ではメンテナンスの立ち会いがてらに、実際のところどんな感じだったかのメモを残しておこうと思います。
メンテナンス対象となっているVMをまとめて確認したい
「サービス正常性 → 計画済みメンテナンス → 影響を受けるリソース」で、いまのアカウントで管理している全サブスクリプションの情報がまとめて一覧で見られます。メンテナンスが終わったリストは残念ながら見あたりませんでした。
(2018年1月6日 追記)
メンテナンス期間に突入したせいか、「サービス正常性 → 計画済みメンテナンス → 影響を受けるリソース」と辿ると、メンテ完了したVMも表示されるようになっていました。
(追記終わり)
(2018年1月5日 11時21分 追記)
メンテナンス完了 → ホスト障害 → メンテナンス終わってないホストに着地 → またメンテナンス対象に
という流れで再度メンテナンス対象になるケースを見かけました。やはり推奨されているとおり、Azure Monitor や Instance Metadata でこまめに見ておくのが良さそうです。
(追記終わり)
(2018年1月9日 14時06分 追記)
「サービス正常性 → 計画済みメンテナンス」から今回の告知自体が消えていました。今日の午前中に「COMPLETED: Required Maintenance for Azure Platform impacting Virtual Machines」という件名のメールが届いていたので、一連のメンテナンスが完了したと考えていいんでしょうね(本文内には「REGION(S): Australia East」と書いてありますが…)。
(追記終わり)
各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 our cloud against recent security vulnerabilities - IBM Cloud Blog
(追記終わり)
性能が落ちるという情報があるが大丈夫？
(2018年1月24日 追記)
日本マイクロソフトから記事が出ていましたので、まずはこちらをご覧頂くのが良さそうです。
Windows システム上の Spectre および Meltdown に対する緩和策のパフォーマンスへの影響について – 日本のセキュリティチーム
(追記終わり)
AWSのフォーラムで話題になっていたようですね。実際に、身近なEC2でも特にParavirtualizedなインスタンスでは比較的大きめな影響が出ていたようです。
Degraded performance after forced reboot due to AWS instance maintenance
Azureについては、ネットワークに影響が出る可能性があるかも、ということで、これは後ほど実測してみようかと思います。
CPU の脆弱性から Azure のお客様を保護するために (2018/1/25 補足情報の更新) – 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日 計測)
(2018年1月6日 追記)
AzureのホストメンテナンスというよりWindows Updateの話になりますが、KB4056892でRAMDISKのパフォーマンスが落ちるということでL4sにiSCSIでアタッチして簡単に試してみました。数パーセントから銃数パーセントの低下といったところですかね。
▼KB4056892 適用前
▼KB4056892 適用後
(追記ここまで)
シングルコア仮想マシンでunixbench
ふと見かけたページのベンチマークでStandard A1が使われていたのを見かけて、さすがにイマドキは他の選択肢もあるだろうということでいくつか測定してみました。
いきなり結果
基本は東日本リージョンで測定しましたが、せっかく西日本にBシリーズがあるので参考までに測ってみました。
いつも通りですが、性能ならFシリーズ、コスパはBシリーズという感じですね。
| リージョン | インスタンスタイプ | スコア | 価格 (円/h) |
所要時間 | ベンチマーク費用 (円) |
1円あたりのスコア |
|---|---|---|---|---|---|---|
| 東日本 | Standard A1 (1 vcpu, 1.75 GB memory) | 741.9 | 8.262 | 28:00 | 3.9 | 192 |
| 東日本 | Standard_A1_v2 (1 vcpu, 2 GB memory) | 785 | 5.508 | 27:56 | 2.6 | 306 |
| 東日本 | Standard F1s (1 vcpu, 2 GB memory) | 1,770 | 6.426 | 28:09 | 3.0 | 587 |
| 西日本 | Standard B1ms (1 vcpu, 2 GB memory) | 1,015 | 3.264 | 28:24 | 1.5 | 657 |
| 米国西部2 | Standard F2s_v2 (2 vcpus, 4 GB memory) | 2,877 | 9.080 | 28:04 | 4.2 | 677 |
(2017年12月19日 追記) ついでにFv2シリーズも測定しておきました。これはまだ日本に来ていないので米国西部2リージョンで。米国安いですねぇ。 (追記ここまで)
測り方
各インスタンスを立ち上げてunixbenchをデフォルトで走らせました。
$ sudo apt-get update $ sudo apt-get -y install gcc make perl git $ git clone https://github.com/kdlucas/byte-unixbench $ cd byte-unixbench/UnixBench $ ./Run
Dv3, Ev3, Bシリーズ仮想マシンの性能検証
これは Microsoft Azure Advent Calendar 2017 11日目の記事です。
さて、先日も軽く触れたように西日本リージョンでDv3, Ev3, Bシリーズの仮想マシンが使えるようになりました。
ということで、改めて各シリーズの性能を検証して、使いどころを探ってみたいと思います。
コア単価とメモリ単価
まずはスペックシートの情報と価格から、よく使いそうな4コア仮想マシンのコア単価とメモリ単価を算出してみました。
以前に東南アジアリージョンで算出していたものの西日本版です。
▼コア単価
▼メモリ単価
傾向は東南アジアの時と似ています。コア単価上位にAシリーズがいますが、Fシリーズがほぼ同価格でACUが倍ということで、実質的にはFシリーズの圧勝ですね。
EとDでは、よりメモリが必要であればEシリーズ、CPU性能が高いのはDシリーズ、という棲み分けになりそうです。
ネットワーク
続いてネットワークですが、Azure公式サイトのスペック情報には記載があったり無かったりしましたので、おもだったインスタンスでスループットを実測してみました。
Azureのドキュメントで紹介されているNTttcp.exe を用いて、同じ仮想ネットワーク上の同じサイズの仮想マシン間で測定しました。
▼シリーズ間での違い
▼コア数による違い
こちらもテキスト版をGistに置きました
インスタンスのシリーズによる違いは、Bシリーズが遅めな他は(物理)コア数にほぼ比例するような結果になりました。Dシリーズであれば、同じコア数のv3よりv2の方が広帯域ということです。そしてLシリーズは飛び抜けてますね。
Dシリーズを使って、同じシリーズでのコア数による違いも実測してみました。ほぼコア数に比例して倍々で増えてますね(間にv2が挟まっていますがお気になさらず)。
ストレージ
個人的にはここがいちばん気になるところです。 西日本で今回新たに使えるようになった3種類に加えて、比較用に3種類を加えて測定しました。
| サイズ | スペック | 特徴 |
|---|---|---|
| Standard B4ms | 4 vcpus, 16 GB memory | CPUがバーストできる。要するにt2。データディスクのキャッシュは有効にできない。 |
| Standard E4s v3 | 4 vcpus, 32 GB memory | Turbo BoostとHyper Threadingできてメモリ多め。 |
| Standard D4s v3 | 4 vcpus, 16 GB memory | DシリーズのHyper Threading対応版。 |
| Standard D8s v3 | 8 vcpus, 32 GB memory | Dv3シリーズのコア数による違いの比較用。 |
| Standard DS3 v2 | 4 vcpus, 14 GB memory | Dv3とDv2シリーズの比較用。Dv2は物理コア。 |
| Standard L4s | 4 vcpus, 32 GB memory | 参考用(東日本)、ストレージ最適化インスタンス。データディスクのキャッシュは有効にできない。 |
デフォルトのCドライブ、Dドライブに加えて、データディスクとしてPremiumStorage(P30)をFドライブとしてアタッチしてそれぞれ計測しました。
キャッシュはC, DドライブでRead/Write有効、FドライブはReadのみ有効…とするつもりでしたが、測っていて気付いたのですが、Bシリーズ、Lシリーズは追加したディスクのキャッシュは有効化できないようです。ポータルから見るとこんなメッセージが出ていました。
また、Dv2シリーズは物理コア数、Dv3シリーズはHyper Threadingもカウントした論理コア数ということで、スペック表の記載でもそもそも列の数からして違っています。どういう違いになるか、実測して試してみましょう。ツールはいつものCrystalDiskMarkです。
シーケンシャルリード / ライト (MB/s)
こんな感じになりました。
| サイズ | 測定項目 | Cドライブ (MB/s) |
Dドライブ (MB/s) |
Fドライブ(P30) (MB/s) |
|---|---|---|---|---|
| Standard B4ms | Sequential Read | 30.4 | 32.0 | 35.3 |
| Sequential Write | 30.4 | 32.1 | 35.4 | |
| Standard E4s v3 | Sequential Read | 67.5 | 69.2 | 67.5 |
| Sequential Write | 67.5 | 69.2 | 67.5 | |
| Standard D4s v3 | Sequential Read | 67.5 | 69.2 | 67.3 |
| Sequential Write | 67.5 | 69.2 | 67.5 | |
| Standard D8s v3 | Sequential Read | 134.9 | 136.1 | 135.0 |
| Sequential Write | 135.0 | 136.7 | 135.0 | |
| Standard DS3 v2 | Sequential Read | 134.1 | 136.7 | 134.2 |
| Sequential Write | 101.0 | 136.7 | 135.0 | |
| Standard L4s | Sequential Read | 205.1 | 207.3 | 127.9 |
| Sequential Write | 197.9 | 207.9 | 128.8 |
BシリーズはEv3, Dv3の約半分という結果でした。スペック通りではありますね。
Dシリーズは、Dv3の8コアとDv2の4コアが同じくらいという結果になりました。
Lシリーズはさすが「ストレージ最適化インスタンス」ですね。
Random Read/Write その1 (IOPS, Q= 32,T= 1)
Q= 32,T= 1 の結果です。
| サイズ | 測定項目 | Cドライブ (IOPS) |
Dドライブ (IOPS) |
Fドライブ(P30) (IOPS) |
|---|---|---|---|---|
| Standard B4ms | Random Read 4KiB | 3,684 | 3,898 | 3,935 |
| Random Write 4KiB | 2,333 | 3,910 | 3,955 | |
| Standard E4s v3 | Random Read 4KiB | 8,217 | 8,440 | 8,230 |
| Random Write 4KiB | 7,994 | 8,443 | 5,137 | |
| Standard D4s v3 | Random Read 4KiB | 8,240 | 8,375 | 8,235 |
| Random Write 4KiB | 8,177 | 8,413 | 5,115 | |
| Standard D8s v3 | Random Read 4KiB | 16,357 | 16,574 | 16,417 |
| Random Write 4KiB | 16,316 | 16,675 | 5,134 | |
| Standard DS3 v2 | Random Read 4KiB | 16,433 | 16,627 | 16,476 |
| Random Write 4KiB | 15,109 | 16,553 | 5,130 | |
| Standard L4s | Random Read 4KiB | 20,540 | 20,800 | 5,141 |
| Random Write 4KiB | 20,401 | 20,772 | 5,149 |
こちらもシーケンシャルリード/ライトと概ね同じ傾向です。キャッシュが効く範囲ではインスタンスのサイズというかお値段がそのまま反映されますね。
Random Read/Write その2 (IOPS, Q= 1,T= 1)
こちらは Q= 1,T= 1 の結果です。
| サイズ | 測定項目 | Cドライブ (IOPS) |
Dドライブ (IOPS) |
Fドライブ(P30) (IOPS) |
|---|---|---|---|---|
| Standard B4ms | Random Read 4KiB | 2,929 | 2,561 | 320 |
| Random Write 4KiB | 3,529 | 3,377 | 338 | |
| Standard E4s v3 | Random Read 4KiB | 3,967 | 2,924 | 3,992 |
| Random Write 4KiB | 6,306 | 3,667 | 346 | |
| Standard D4s v3 | Random Read 4KiB | 6,290 | 5,571 | 6,216 |
| Random Write 4KiB | 8,176 | 8,352 | 345 | |
| Standard D8s v3 | Random Read 4KiB | 16,030 | 5,506 | 15,880 |
| Random Write 4KiB | 15,242 | 9,549 | 359 | |
| Standard DS3 v2 | Random Read 4KiB | 9,100 | 4,014 | 12,308 |
| Random Write 4KiB | 8,572 | 5,932 | 336 | |
| Standard L4s | Random Read 4KiB | 18,662 | 6,079 | 441 |
| Random Write 4KiB | 19,585 | 11,122 | 514 |
ちょっと面白い感じになりましたね。それでもLシリーズが速いのはさすが。
まとめ
というわけで、スペック表にあまり記載の無い項目をいろいろと実測してきました。インスタンスタイプ選定のお手伝いになりましたら幸いです。
尚、あくまで個人的に測定した結果ですので、今後、インフラ増強などで変化する可能性がありますのでご注意ください。
過去のベンチマークシリーズ
こちらからどうぞ。
▼Lシリーズ asazure.hatenablog.jp
▼Ev3シリーズ asazure.hatenablog.jp
▼Fv2シリーズ asazure.hatenablog.jp
仮想マシンのNIC追加がポータルからできるようになってました
タイトルで言いたいことを言い切った感じではあるんですが、AzureポータルのGUI操作だけで複数のNICをアタッチできるようになっていました。これまではPowerShellやCLIでの操作が必要だったんですよね。
(参考記事)
Azureで単数NICの仮想マシンを複数NICにする – Japan Azure Technical Support Engineers' Blog
見たままで迷うところはありませんが、簡単に手順を。
「Attach Network Interface」を選んで
アタッチしたいNICを選んで
しばらく待つとアタッチされたNICがタブに表示されます。
インスタンス上でもちゃんと2枚見えてますね(これはUbuntuの例)。
当然ですが、外す方もポータルからできます。便利になりましたね。
西日本で仮想マシンDv3、Ev3、Bシリーズが選べるようになっていました
コミュニティではすでに話題ですが、西日本リージョンの仮想マシンでDv3、Ev3、Bシリーズの仮想マシンが選べるようになっていました。
Cloud Shell からもご覧の通り。もしかしてと思って東日本を確認してみたらやっぱりまだでした。
Dv3、Ev3シリーズといえば「Nested Virtualization」対応で仮想マシンのHyper-Vを有効化できるようになりました。
画像は普通にHyper-Vを有効化してDocker for WindowsをインストールしてLinux Container上でnginxを走らせてみたところ。特殊な手順はなくいつも通りでOKです。
Nested Virtualizationについてはこちらのドキュメントをどうぞ。 docs.microsoft.com
ふと見ると、SR-IOV (Accelerated Networking) も有効になっていました。少し前に東日本で有効化されていましたが、西日本でもいつの間にか有効になったようです。
Accelerated Networking についての詳細はこちら。 docs.microsoft.com
リリースにはまだ記載が無いので、今回のアップデートかもしれませんね。 General availability (Windows) and preview (Linux): Accelerated Networking
