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向けのネットワーク高速化が進められているようです。
ネットワーク関連のアップデート
- 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機能が追加されたようです。
- Security Centerにいろいろと機能追加されたようです。
- パートナーのセキュリティソリューション(WAFや脆弱性診断など)がポータル上から導入できるようになったとのこと。
- ストレージアカウントに対するセキュリティ診断機能が導入されるようです。
- 他にも、レポート系の機能がいろいろと強化されつつあるようですね。
Igniteのセッションをオンデマンドで見られます。
- MyIgnite - On Demand
- https://myignite.microsoft.com/videos
- いまの時点で全718セッション、Azureでフィルタしても149セッションありますね(見切れない)。
「App Service On Linux」がプレビューで提供され始めたようですね
「App Service On Linux」がプレビューで提供され始めたようですね。 …と思ったら、当初のドキュメントが消えていてGitHubにも見あたらなかったので、マーケットプレイスのリンクを貼っておきます。 (で、こっちはこっちで名称が「Web App On Linux」と微妙に違ってますね)
▼Web App On Linux on Microsoft Azure Marketplace
どういう状態か気になるところですが、マーケットプレイスのリンクから、もしくはポータル内で検索することでサービスの作成はできました。 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 以下に置いてありました。 このあたりも標準的な感じになっていて扱いやすそうですね。
当初はデフォルトドキュメントも無くディレクトリが見える状態だったようですが、いまデプロイしたらいつものが設定されるようになっていました。エラーページも同様のようでした。
Azure VMのMACアドレスが固定化されるようになってました
各方面で「待望の」とつぶやかれているとおり、みんな待ち望んでいたMACアドレス固定化が実現されたようです。
feedback.azure.com
625 votes
44 commentsというわけで、どこまでちゃんと固定化されるのか試してみました。
まずは元の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アドレス。
STOP/START後のMACアドレス。維持されてますね。
ゴーストNICありません。
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さんの記事をどうぞ。
Azure VNet Peering が構成できたので軽く性能測定
親切な方のおかげでVNet Peeringが構成できたので軽く性能測定してみました。
用意したもの
手順
- VNetのピアリングをすませておく → (参考) VNet Peering を試してみる - Qiita
- 仮想マシンのWindows Firewall設定を変更して疎通できるようにしておく。対向のプライベートIPアドレスで許可設定するのが手軽かと思います。
- それぞれの仮想マシンにiperfのWindows版をダウンロードして入れておく。
- コマンドプロンプトから送受信側それぞれにiperfを立ち上げる。
- 受信側： iperf3.exe -s
- 送信側： iperf3.exe -c [受信側のIPアドレス]
- 送信側のコマンドを実行すると勝手に測定が始まります。
結果
だいたい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.
結果(追記)
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」ということでお預け状態です。
既に試せている人もいるようでうらやましい限りですね。 いつの間にかポータルからブレードも消えてしまってますが、このあとどうなるんでしょうね。
ということで、出遅れ組としてはやることもないのでドキュメントをかいつまんでまとめるなどして予習に励むことにします。
まず全体像についてはこちら。
ハウツー的なのはこちら。リンク先はとりあえずポータル上での操作方法ですが、PowerShellでもARMテンプレートでも設定出来るようです(CLIはまだかな？)。
VNET Peering の特徴
- VNet間を低遅延、広帯域でつなぐことができます。
- Gatewayを挟む必要が無いので、余分な費用もかからず、Gatewayのスループットにも左右されないのが良いですね。
- 料金は「プレビュー中なので無料」「GAしたら通常のチャージが発生する」って書いてありますが、リージョンまたげないのでやっぱり無料では？
- ARMのVNetからクラシックVNetに接続できます(ちなみにクラシックVNet同士は駄目)。新しいVMからARMで、という対応もできそうですね。
- ユーザー定義ルート(UDR)を上手く使って、仮想アプライアンス(F5とかですかね)を挟み込むことができるようです。
VNet Peering の制約など
- リージョンまたぎはできません。同じリージョンのVNet同士だけです。ただし、サブスクリプションはまたげるようです。
- VNet同士でIPアドレスが被ってはいけません。
- カスケードはできません(A-B-C みたいなトラフィックは流せない模様)。
- Azureから提供される内部向けの名前解決はVNetをまたがないようです。
- VNetあたりのピアリング数に限りがあるような記載があるのですが、ちょっと見あたりませんでした。
といったところでしょうか。 だいぶ実用的な仕様になった気がしますので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で制限をかければ問題ないですよという説明をしてきましたが、よりすっきりします。
実際の構成については、DNSとSSL用の証明書が必要になる点が外向けASEとの違いのようです。 既に日本語のドキュメントもありますので安心ですね。
▼App Service 環境での内部ロード バランサーの作成と使用 | Microsoft Azure
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/
