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

浅草橋青空市場

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

Ignite 2016 で発表されたAzureネタの個人的なまとめ

Igniteで大量のアップデートがあったようですね。個人的に気になった発表を、このあたりのURLからいくつか抜粋してみました。

▼Cloud innovations empowering IT for business transformation | Blog | Microsoft Azure
https://azure.microsoft.com/en-us/blog/cloud-innovations-empowering-it-for-business-transformation/

仮想マシン関連のアップデート

  • 新しいインスタンスシリーズが登場しましたね(H、L)
    • HはHPC向けインスタンス、高速なCPUと高速なI/O。現時点で利用可能です。
    • Lは大きなローカルストレージを搭載(とはいえ揮発するのでは?)。間もなく登場とのこと。
  • Nシリーズ(GPUインスタンス)も申請無しで選べるようなのでパブリックプレビューということでしょうか。
  • SAP HANA on AzureがGAしたそうです。
    • 単一インスタンスでメモリ3TB。他の用途でも使いたいのですがHANA専用のようですね。
  • Azure Disk Encryption がLinux向け、Premium Storage向けにもGAしました。
  • 1つのNICに複数のIPアドレス(パブリック、プライベートとも)を割り当てられるようになりました。
  • 複数NICの接続についても、パブリックIPアドレスが割り当てられる等の向上があったようです。
  • 「Accelerated Networking」としてVM向けのネットワーク高速化が進められているようです。
    • まずは一部リージョンのD15v2、DS15v2から。
    • SR-IOV対応ドライバ組み込み済みのVMをデプロイする形なので、事前準備が必要です。
    • これに伴い、VMディスクのパフォーマンスも向上するようです。

ネットワーク関連のアップデート

  • Azure DNSがGAしました。SLA99.99%。Route53のためだけにAWSを使う必要はなくなりそうです。
  • 内部ロードバランサーに複数のIPアドレスを割り当てられるようになりました(確か外部LBは以前から)。
  • VNet PeeringがGAし、料金も設定されました(1.02円/GB、送受信とも)。
  • VPN Gatewayがアクティブ-アクティブ構成をサポートしました。
    • VNet間、VNet-オンプレミス間のどちらでも構成できるようです。
    • 可用性のためだけにExpressRouteを敷く必要は無くなりそうですね(要High Performance SKUっぽいのでそれなりに値が張りますが)。

セキュリティ関連

  • Application GatewayにWAF機能が追加されたようです。
    • OWASP Top10 あたりの主要な脆弱性を対象にして、検出のみかブロックかを選べるようです。
    • カスタムルールは今後対応とのこと。
    • AWS WAFはCloudFront統合なんですが、AzureはL7LBに乗せてきましたね。
  • Security Centerにいろいろと機能追加されたようです。
    • パートナーのセキュリティソリューション(WAFや脆弱性診断など)がポータル上から導入できるようになったとのこと。
    • ストレージアカウントに対するセキュリティ診断機能が導入されるようです。
    • 他にも、レポート系の機能がいろいろと強化されつつあるようですね。

Igniteのセッションをオンデマンドで見られます。

  • MyIgnite - On Demand

「App Service On Linux」がプレビューで提供され始めたようですね

「App Service On Linux」がプレビューで提供され始めたようですね。 …と思ったら、当初のドキュメントが消えていてGitHubにも見あたらなかったので、マーケットプレイスのリンクを貼っておきます。 (で、こっちはこっちで名称が「Web App On Linux」と微妙に違ってますね)

▼Web App On Linux on Microsoft Azure Marketplace

azure.microsoft.com

どういう状態か気になるところですが、マーケットプレイスのリンクから、もしくはポータル内で検索することでサービスの作成はできました。 Kuduも動いていて、Environmentを除くと結構面白いですね。 Debug console ではbashが動きます。 というところでお約束のコマンド実行結果。特に面白みのない結果(と言う状況自体が面白いのですが)。

/home>uname -a
Linux f12e154155a0 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 GNU/Linux
/home>cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

apacheの設定ファイル等は /etc/apache2 以下に置いてありました。 このあたりも標準的な感じになっていて扱いやすそうですね。

当初はデフォルトドキュメントも無くディレクトリが見える状態だったようですが、いまデプロイしたらいつものが設定されるようになっていました。エラーページも同様のようでした。 f:id:yhara90:20161010011351p:plain

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/