読者です 読者をやめる 読者になる 読者になる

浅草橋青空市場

Microsoft Azure のニュースや情報を中心にあれこれと

Azure VMのMACアドレスが固定化されるようになってました

各方面で「待望の」とつぶやかれているとおり、みんな待ち望んでいたMACアドレス固定化が実現されたようです。

blogs.technet.microsoft.com

completed
How can we improve Azure Virtual Machines?
  • 625 votes
  • 44 comments

Static MAC address

We need static MAC addresses on the vm's network cards due to the licensing model of the software we need to install.

We cant obtain new licenses every time the MAC address changes.

Having the ability to change the address back to the original might also work for us

feedback.azure.com

というわけで、どこまでちゃんと固定化されるのか試してみました。

まずは元のVMでifconfig。

$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0D:3A:40:92:37

VMをSTOP->STARTします。

Stop-AzureRmVM -Name [VM名] -ResourceGroupName [リソースグループ名]
Start-AzureRmVM -Name [VM名] -ResourceGroupName [リソースグループ名]
$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0D:3A:40:92:37

ちゃんと維持されていますね。

次にVMを再デプロイしてみましょう。ポータルからポチッと「再デプロイ」です。

$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0D:3A:40:92:37

VM(だけ)を削除したうえで同じVHDから再度生成、元のNICを割り当ててみます。

$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0D:3A:40:92:37

これでも維持されます。

駄目だとは思いますが、新しいNICを作って付け替えてみましょう。

$vm = Get-AzureRmVM -ResourceGroupName '[リソースグループ名]' -Name '[VM名]'
$nic_1 = Get-AzureRmNetworkInterface -ResourceGroupName '[リソースグループ名]' -Name '[NIC名(取り外す方)]'
$nic_2 = Get-AzureRmNetworkInterface -ResourceGroupName '[リソースグループ名]' -Name '[NIC名(取り付ける方)]'

$vm = Remove-AzureRmVMNetworkInterface -NetworkInterfaceIDs $nic_1.id -VM $vm
$vm = Add-AzureRmVMNetworkInterface -Id $nic_2.id -VM $vm
Update-AzureRmVM -ResourceGroupName '[リソースグループ名]' -VM $vm
$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0D:3A:40:9C:E1

当然ですが変わりますね。

元のNICに戻してみます。

$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0D:3A:40:92:37

ちゃんともとのMACアドレスが維持されています。

ということで、ごく普通の感覚でNICを取り扱っても大丈夫そうです。

(追記: Windows でもやってみました) ゴーストNICができなくなるということで改めて確認してみました。

元のMACアドレスf:id:yhara90:20160805174946p:plain

STOP/START後のMACアドレス。維持されてますね。 f:id:yhara90:20160805174949p:plain

ゴーストNICありません。 f:id:yhara90:20160805174952p:plain

Azure VNet Peering でクラシックVNetとピアリングする(PowerShell)

いろいろ試していて、そういえばPowerShellでクラシックVNetとピアリングする方法が見あたらない気がしたのでメモ。

$vnet1 = Get-AzureRmVirtualNetwork -ResourceGroupName '[リソースグループ名]' -Name '[VNet名]'
$vnet2 = '[リソースID]'
Add-AzureRmVirtualNetworkPeering -name '[ピアリング名]' -VirtualNetwork $vnet1 -RemoteVirtualNetworkId $vnet2

試した限りでは、ARM → クラシック方向のピアリングだけ設定すれば疎通するようです。 ポータルから設定するときも同じ手順なので、たぶんこれで大丈夫かなと。

リソースIDは、ポータルからだとVNetのブレードを開いたあとの「プロパティ」ブレードで確認できます。

普通にARMのVNet間をピアリングする場合は、@yuiashikagaさんの記事をどうぞ。

qiita.com

Azure VNet Peering が構成できたので軽く性能測定

親切な方のおかげでVNet Peeringが構成できたので軽く性能測定してみました。

用意したもの

手順

  1. VNetのピアリングをすませておく → (参考) VNet Peering を試してみる - Qiita
  2. 仮想マシンWindows Firewall設定を変更して疎通できるようにしておく。対向のプライベートIPアドレスで許可設定するのが手軽かと思います。
  3. それぞれの仮想マシンiperfのWindows版をダウンロードして入れておく。
  4. コマンドプロンプトから送受信側それぞれにiperfを立ち上げる。
    • 受信側: iperf3.exe -s
    • 送信側: iperf3.exe -c [受信側のIPアドレス]
  5. 送信側のコマンドを実行すると勝手に測定が始まります。

結果

だいたい2Gbps程度出ているようです(F8sのスペックで)。 VPN Gateway 経由だと、Gateway のスペック的に100Mbpsか200Mbpsが上限なので、だいぶ早いですね。

Connecting to host 172.19.0.4, port 5201
[  4] local 172.18.0.4 port 49262 connected to 172.19.0.4 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   212 MBytes  1.78 Gbits/sec
[  4]   1.00-2.00   sec   244 MBytes  2.04 Gbits/sec
[  4]   2.00-3.00   sec   239 MBytes  2.01 Gbits/sec
[  4]   3.00-4.00   sec   251 MBytes  2.11 Gbits/sec
[  4]   4.00-5.00   sec   233 MBytes  1.95 Gbits/sec
[  4]   5.00-6.00   sec   233 MBytes  1.95 Gbits/sec
[  4]   6.00-7.00   sec   223 MBytes  1.88 Gbits/sec
[  4]   7.00-8.00   sec   222 MBytes  1.86 Gbits/sec
[  4]   8.00-9.00   sec   244 MBytes  2.04 Gbits/sec
[  4]   9.00-10.00  sec   246 MBytes  2.06 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  2.29 GBytes  1.97 Gbits/sec                  sender
[  4]   0.00-10.00  sec  2.29 GBytes  1.97 Gbits/sec                  receiver

iperf Done.

f:id:yhara90:20160803131208p:plain

結果(追記)

VMのサイズによってネットワークのパフォーマンスが違うわけですが、「中」とか「非常に高」といった非常にざっくりした表現なので、どれくらい違うのか測ってみました。ピアリング前提です。

Windows VM のサイズ |Microsoft Azure

▼F1sサイズ: パフォーマンス「中」 如実に低いですね。500Mbps程度というところ。

Connecting to host 172.19.0.4, port 5201
[  4] local 172.18.0.4 port 49178 connected to 172.19.0.4 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.01   sec  59.8 MBytes   499 Mbits/sec
[  4]   1.01-2.01   sec  59.9 MBytes   500 Mbits/sec
[  4]   2.01-3.00   sec  59.0 MBytes   498 Mbits/sec
[  4]   3.00-4.00   sec  60.1 MBytes   506 Mbits/sec
[  4]   4.00-5.01   sec  59.4 MBytes   495 Mbits/sec
[  4]   5.01-6.00   sec  59.6 MBytes   503 Mbits/sec
[  4]   6.00-7.01   sec  59.5 MBytes   497 Mbits/sec
[  4]   7.01-8.00   sec  59.6 MBytes   503 Mbits/sec
[  4]   8.00-9.01   sec  59.2 MBytes   495 Mbits/sec
[  4]   9.01-10.00  sec  59.9 MBytes   505 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   596 MBytes   500 Mbits/sec                  sender
[  4]   0.00-10.00  sec   596 MBytes   500 Mbits/sec                  receiver

iperf Done.

▼F16sサイズ: パフォーマンス「非常に高」 非常に、かどうかはともかく、2.5Gbps弱まで上がりますね。

Connecting to host 10.110.0.4, port 5201
[  4] local 10.10.0.4 port 49182 connected to 10.110.0.4 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   290 MBytes  2.43 Gbits/sec
[  4]   1.00-2.00   sec   279 MBytes  2.34 Gbits/sec
[  4]   2.00-3.00   sec   293 MBytes  2.46 Gbits/sec
[  4]   3.00-4.00   sec   288 MBytes  2.42 Gbits/sec
[  4]   4.00-5.00   sec   299 MBytes  2.51 Gbits/sec
[  4]   5.00-6.00   sec   293 MBytes  2.46 Gbits/sec
[  4]   6.00-7.00   sec   293 MBytes  2.46 Gbits/sec
[  4]   7.00-8.00   sec   316 MBytes  2.65 Gbits/sec
[  4]   8.00-9.00   sec   289 MBytes  2.43 Gbits/sec
[  4]   9.00-10.00  sec   280 MBytes  2.35 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  2.85 GBytes  2.45 Gbits/sec                  sender
[  4]   0.00-10.00  sec  2.85 GBytes  2.45 Gbits/sec                  receiver

iperf Done.

Azure VNet Peering が来たけど使えないのでドキュメントを読む

期待のVNET Peeringなんですが、ドキュメントも公開されて早速やってみようとしたところで「SubscriptionNotRegisteredForFeature」ということでお預け状態です。

既に試せている人もいるようでうらやましい限りですね。 いつの間にかポータルからブレードも消えてしまってますが、このあとどうなるんでしょうね。

ということで、出遅れ組としてはやることもないのでドキュメントをかいつまんでまとめるなどして予習に励むことにします。

まず全体像についてはこちら。

azure.microsoft.com

ハウツー的なのはこちら。リンク先はとりあえずポータル上での操作方法ですが、PowerShellでもARMテンプレートでも設定出来るようです(CLIはまだかな?)。

azure.microsoft.com

VNET Peering の特徴

  • VNet間を低遅延、広帯域でつなぐことができます。
  • Gatewayを挟む必要が無いので、余分な費用もかからず、Gatewayスループットにも左右されないのが良いですね。
  • 料金は「プレビュー中なので無料」「GAしたら通常のチャージが発生する」って書いてありますが、リージョンまたげないのでやっぱり無料では?
  • ARMのVNetからクラシックVNetに接続できます(ちなみにクラシックVNet同士は駄目)。新しいVMからARMで、という対応もできそうですね。
  • ユーザー定義ルート(UDR)を上手く使って、仮想アプライアンス(F5とかですかね)を挟み込むことができるようです。

VNet Peering の制約など

といったところでしょうか。 だいぶ実用的な仕様になった気がしますのでGAが楽しみですね。

App Service Environment がILB対応 / Azure Backup の仕組みについて

アナウンス1件、ドキュメント1件ありました。

App Service Environment(ASE)が内部ロードバランサーとVNETをサポートしたとのアナウンス

なのですが、特にPreviewとの記載はないですが、GAでしょうか?

▼Announcing Internal Load Balancer and Resource Manager VNet support | ブログ | Microsoft Azure

https://azure.microsoft.com/ja-jp/blog/ilb-and-arm-support-for-ase/

ドキュメント内では「ILB ASE」という呼び方になっていますね。 「ARM VNET」とあるので、ASM VNETはサポートしないと言うことでしょうかね。

イントラ等の内部向けシステム用途ということになるかと思いますが、S2S VPNやExpressRouteでオンプレミスと接続したときに外部向けのエンドポイントが一切無しで構築できるようになります、ということのようですね。 これまでもNSGで制限をかければ問題ないですよという説明をしてきましたが、よりすっきりします。

実際の構成については、DNSSSL用の証明書が必要になる点が外向けASEとの違いのようです。 既に日本語のドキュメントもありますので安心ですね。

▼App Service 環境での内部ロード バランサーの作成と使用 | Microsoft Azure

https://azure.microsoft.com/ja-jp/documentation/articles/app-service-environment-with-internal-load-balancer/

Azure Backup における増分バックアップ

新機能ではなくドキュメントですが、Azure Backup の仕組みについて。

よくバックアップストレージの使用量をえいやっと見積もってしまいがちですが、仕組みが分かっているとより安心ですね。 こういうドキュメントが出てくるのはとてもありがたいです。

▼Incremental backups on Microsoft Azure Backup: Save on long term storage | ブログ | Microsoft Azure

https://azure.microsoft.com/ja-jp/blog/microsoft-azure-backup-save-on-long-term-storage/

Azure AD B2CがGA(北米) / 仮想マシンのメンテナンス対策 / VNET Peeringがパブリック

「Azure の料金とサービスの更新に関するお知らせ」が届いたので、気になったものをいくつかピックアップしてみました。

Azure AD B2C が北米でGAしてました

実際に米国でテナントを作ってみると「Production-scale tenant」となりますね。

「北米」の範囲は以下の通りとのこと。結構広いです。 United States, Canada, Costa Rica, Dominican Republic, El Salvador, Guatemala, Mexico, Panama, Puerto Rico and Trinidad and Tobago.

他のリージョンは「over the next few months」とのこと。

Azure Active Directory B2C is now generally available in North America | Blog | Microsoft Azure

仮想マシンのメンテナンス対策

「Azure の料金とサービスの更新に関するお知らせ」というメールが届いた中に「Azure のインプレース仮想マシン移行による、ホスト OS 用の重要なセキュリティ更新実行時における仮想マシンの再起動の排除」とあって何かと思ったんですが、これのことですかね。

Planned maintenance for Linux VMs | Microsoft Azure

前からあったドキュメントのような…と思ったら日本語と記述が違っているので、最近更新されたんでしょうか(ちょうどGitHubが落ちていて差分が追えませんが…)。 メモリの内容を維持したまま30秒以内にライブマイグレーションするようになりつつあるようですね。 メールの方にはテンポラリディスクの内容も保持するように書いてありますが、ほんとでしょうか。

VNET Peering がパブリックプレビューとなったようです

「link two Virtual Networks in the same geo region directly」ということで、VNET間をゲートウェイ無しで接続できたり、ARM(v2)とASM(v1)の間で接続できたりするので、まずはARMへのマイグレーション用ですかね。

あとは、小さく作りすぎたサブネットを広げたり、ExpressRoute のゲートウェイを置くセグメントを作ってクラウド側の複数のサブネットをまとめてオンプレに繋ぎ込んだり、といった用途にも使えるんでしょうか。

Cloud Platform Release Announcements for July 27, 2016 | Cloud Platform News Bytes Blog

とここまで書いておいて、まだどうやって使うのか分かっていません…

Azureポータルダッシュボードのカスタマイズと共有と「Dashboards」リソースグループ

Azureポータルのダッシュボード、いわゆるデスクトップ的な領域ですが、わりとカスタマイズができます。 かつ、カスタマイズしたダッシュボードを共有して、同じテナントのユーザー同士で使い回すこともできます。

Azure ポータルを使用した Azure リソースの管理 | Microsoft Azure

ただ、こちらの「Azure ダッシュボードの共有とアクセス制御」に「共有できます」とかいてあるものの、やり方が書かれていないようなのでまとめてみました。

ダッシュボードをカスタマイズする

f:id:yhara90:20160726015859p:plain

おもむろにカスタマイズを始めてもかまわないのですが、せっかくなので「+新しいダッシュボード」を押して新規に作成してみましょう。まっさらなダッシュボードにイチから好みのタイルを並べられます。

f:id:yhara90:20160726015900p:plain

左の「タイルギャラリー」からタイルをドラッグアンドドロップで配置できます。プリセットでいろいろパーツが用意されているほか、「マークダウン」タイルを配置すると、自由に文字を書いたり画像を貼ったりオブジェクトを埋め込んだりできます。 「旧ポータルへのリンクが見あたらなくなった!」という方は、https://manage.windowsazure.com/ のリンクを貼っておくと良いのではないでしょうか。

終わったら、上の「カスタマイズ完了」を押して下さい。 この時点では、個人のアカウントに紐付いてカスタマイズが保存されている状態です。

カスタマイズしたダッシュボードを共有する

f:id:yhara90:20160726015859p:plain

再びこちらから「共有」を押して下さい。

f:id:yhara90:20160726015906p:plain

こんなブレードが開きますので、適宜項目を埋めて「発行」しましょう。 場所は、画面では「Brazil South」となっていますが、何かに影響するんでしょうか。

f:id:yhara90:20160726015906p:plain

しばらくすると、発行が終わってこんなブレードが開きますので、「ユーザーの管理」から共有範囲を確認、設定してください。

f:id:yhara90:20160726015907p:plain

共有したダッシュボードは、ダッシュボード名をクリックすると出てくるプルダウンから選択できます。共有しただけで共有先ユーザーのダッシュボードが自動的に変わるわけではなく、ここで明示的に選択する必要があります。 プロパティとかユーザーポリシーで制御できるといいんですけど、今のところはできなさそうです。

「Dashboards」リソースグループについて

f:id:yhara90:20160726021848p:plain

共有したダッシュボードは「Dashboards」というリソースグループが自動的に作成されて、そこに収められるようです。 が、リソースグループを開いても何もないように見えます。 リソースグループを削除しようとしたり、移動させたりしようとすると、

f:id:yhara90:20160726015910p:plain

といった形で、Microsoft.Portal/dashboards というリソースが現れます。 これがリソースの実体になるようで、削除したり移動させたりすると、せっかくカスタマイズしたダッシュボードが消えてしまいますのでご注意を。

ちなみに、移動させた場合はもういちど元のリソースグループに戻してやると、ダッシュボードも復活します。 もう少しあれこれやってみたところ、「dashboards」というリソースグループに入っていれば、ダッシュボード選択のプルダウンから「全てのダッシュボードを参照」を選ぶことであとから見つけて使うことができるようです。 ただし、移動元のサブスクリプションから自動で消えてくれるわけではないので、こんな感じに…(削除すればいいんですが)。

f:id:yhara90:20160726024024p:plain

更に余談ですが、Resource Explorer に「Microsoft.Portal」のリソースプロバイダーは出てこないようです。 というわけで、ちょっと気になったのでまとめてみたというお話しでした。