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/
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 ダッシュボードの共有とアクセス制御」に「共有できます」とかいてあるものの、やり方が書かれていないようなのでまとめてみました。
ダッシュボードをカスタマイズする
おもむろにカスタマイズを始めてもかまわないのですが、せっかくなので「＋新しいダッシュボード」を押して新規に作成してみましょう。まっさらなダッシュボードにイチから好みのタイルを並べられます。
左の「タイルギャラリー」からタイルをドラッグアンドドロップで配置できます。プリセットでいろいろパーツが用意されているほか、「マークダウン」タイルを配置すると、自由に文字を書いたり画像を貼ったりオブジェクトを埋め込んだりできます。 「旧ポータルへのリンクが見あたらなくなった！」という方は、https://manage.windowsazure.com/ のリンクを貼っておくと良いのではないでしょうか。
終わったら、上の「カスタマイズ完了」を押して下さい。 この時点では、個人のアカウントに紐付いてカスタマイズが保存されている状態です。
カスタマイズしたダッシュボードを共有する
再びこちらから「共有」を押して下さい。
こんなブレードが開きますので、適宜項目を埋めて「発行」しましょう。 場所は、画面では「Brazil South」となっていますが、何かに影響するんでしょうか。
しばらくすると、発行が終わってこんなブレードが開きますので、「ユーザーの管理」から共有範囲を確認、設定してください。
共有したダッシュボードは、ダッシュボード名をクリックすると出てくるプルダウンから選択できます。共有しただけで共有先ユーザーのダッシュボードが自動的に変わるわけではなく、ここで明示的に選択する必要があります。 プロパティとかユーザーポリシーで制御できるといいんですけど、今のところはできなさそうです。
「Dashboards」リソースグループについて
共有したダッシュボードは「Dashboards」というリソースグループが自動的に作成されて、そこに収められるようです。 が、リソースグループを開いても何もないように見えます。 リソースグループを削除しようとしたり、移動させたりしようとすると、
といった形で、Microsoft.Portal/dashboards というリソースが現れます。 これがリソースの実体になるようで、削除したり移動させたりすると、せっかくカスタマイズしたダッシュボードが消えてしまいますのでご注意を。
ちなみに、移動させた場合はもういちど元のリソースグループに戻してやると、ダッシュボードも復活します。 もう少しあれこれやってみたところ、「dashboards」というリソースグループに入っていれば、ダッシュボード選択のプルダウンから「全てのダッシュボードを参照」を選ぶことであとから見つけて使うことができるようです。 ただし、移動元のサブスクリプションから自動で消えてくれるわけではないので、こんな感じに…(削除すればいいんですが)。
更に余談ですが、Resource Explorer に「Microsoft.Portal」のリソースプロバイダーは出てこないようです。 というわけで、ちょっと気になったのでまとめてみたというお話しでした。
AzureのストレージサービスをExcel方眼紙職人的にまとめてみる
随所で分かりづらいという声を耳にしますし、料金表の記載がまたテクノロジーとは別の切り口なのが分かりづらさに拍車をかけている気もしますね。
料金 - Cloud Storage | Microsoft Azure
ということで、ある種の割り切りの下でExcel方眼紙職人的にまとめてみました。
基本的には料金表ページそのままなんですが、まとめてみると、BLOBストレージアカウントの存在で「？」となりがちなのと、BLOB Storage にページBLOBがあるのに「Disk Storage」がまた出てくるあたりが違和感の源でしょうか。 File Storage あたりも微妙なところですが、これは用途がはっきりしているのでまだ大丈夫かなと。
料金と用途の観点からは分かり易くなってきたと思いますが、いざ使ってみようという時に、ポータルの表記だったり実装の階層構造だったりが一致しないのでまたちょっと混乱するんですよね。
AzureクラシックVMからARMへのマイグレーションにおける注意点
以前の記事では無停止で綺麗に移行できるケースを紹介しましたが、少なくとも現時点で完璧なツールというわけでもなく、いくつかの注意点があります。 ということで、今回は公式ドキュメントから注意点をいくつか拾っていきたいと思います。 経験上から「引っかかりそうだな－」というところを抜粋していますので、こちらで雰囲気を掴んだら、ドキュメントの方も読んでみて下さいね。
ベースはこちら。
仮想ネットワークに含まれないVMのマイグレーション時
- ARMモデルのVMは必ずVNETに所属する必要があるということから、マイグレーションの際に停止・起動が発生します。
- 具体的に書かれていない気がしますが、試した限りでは「Prepare」時にシャットダウンまで行われ(割り当て解除済み状態)、「Commit」完了後に起動されます。
仮想ネットワークに含まれるVMのマイグレーション時
- ストレージアカウントに関する制限
「Unsupported features」からの抜粋
- ネットワーク関連が厄介そうです
- クラウドサービスやVMに割り当てていない予約IPアドレス。 マイグレーションに使うコマンドの対象がVNETかクラウドサービスなので、まあ当然というか、割り当てておかなければASMに残されるということになります。マイグレーション後に再利用予定のあるIPアドレスであれば、とりあえずでもいいので割り当ててから持っていきましょうということですね。
- エンドポイントのACLも対象外です (Prepareの段階でエラーが出ます)。暗黙のロードバランサーはARMの明示的なリソースとしてのロードバランサーに移行され、エンドポイントは受信NAT規則に置き換えられますが、受信NAT規則にはACLが存在しないため、必然的に移行対象外となる、ということですね(NSGを作ってくれても良さそうな気はしますが)。
- VNETのGateway(サイト対サイト、ExpressRoute、ポイント対サイト)もサポート外 とのこと。これは結構つらいですね…
「Unsupported configurations」からの抜粋
- クラシックリソースに対するRBAC。 これもリソースのURIが変更になるためある意味仕方が無いですね。移行後に手動で再設定する必要があります。
- 複数サブネットに接続されたVM。 これは困るケースも多そうです。
- Web/Workerロールを含むクラウドサービスやVNET。そりゃそうなんですが、ちょっと惜しいですね。同様に、App Service Environment や HDInsight を含むVNETもサポート対象外とのこと。
移行のワークフローにおける注意点
- まず基本として、移行は「Prepare」→「Check」→「Commit / Abort」の流れで行います。
- Prepareはコマンド、Checkは人手による確認、Commit / Abort はコマンドで行います。
- サポート対象外の構成が存在した場合は「Prepare」の工程でエラーが出ます。試した限りでは自動的に削除されるものは無さそうなので、それなりに配慮されているようです。
- Prepareが成功してからCommitもしくはAbortが完了するまでは、管理系の操作がブロックされます。試しにPrepareしたあとのVMに対して、キャプチャやエンドポイントの構成などをポータルから行ったところ、「HostedService xxxx 内の展開 xxxx は、移行処理中であるため変更できません。」というエラーが出ました。台数によっては数時間かかる場合もあるようなので、その辺の考慮も必要になりそうです。
- クオータにも注意。ARMはARMのクオータがあるので、必要に応じてあらかじめ増やしておきましょう。移行中にクオータ制限にかかった場合はrollbackしましょうと書いてありますね。
AzureのクラシックVMからARMへのマイグレーション機能がGAしてました
記事が出たり引っ込んだりしてたみたいですが、ちゃんと上半期中にGAしたみたいですね。 首を長く長く伸ばしながら待っていてどうにかなりそうなところでした。
▼General availability of IaaS migration from classic to resource manager | ブログ | Microsoft Azure
手組のスクリプトで引っ越すことと比べて、ダウンタイム無しで移行できるのが最大のメリットですかね。
リンク先のドキュメントも、「Updated:」の日付は古いですが、内容は最新化されています(英語版のみ)。 PowerShell, Azure CLI の両方ともちゃんと更新されていましたので安心ですね。
マイグレーションできるもの、出来ないものがありますので、こちらのページから事前によく確認して移行計画を検討しましょう。
[(追記) 補足記事を書きました： 2016/7/5]
＜主なポイント＞
- IPアドレスやDNS名(クラウドサービスのURL)はそのまま引き継がれます。
- GAのタイミングでストレージアカウントのマイグレーションに対応しました。
- VMとVNETだけARMに移してVHDはクラシックのストレージアカウントに残していくこともできます(v2VMからクラシックのストレージアカウントに繋がるようにしたみたいですね)。
- 移行後は「<cloud-service-name>-migrated」というリソースグループが新たに作られます。
- 「mycloudservice」であれば「mycloudservice-migrated」ですね。
- ただし、DNS名はそのまま移行されますので、「mycloudservice.cloudapp.net」となります。
- クラウドサービスに付いていた暗黙のロードバランサーはARMのロードバランサーが明示的に作成され、エンドポイントは受信NAT規則に置き換えられます。ただし、エンドポイントACLは引き継がれないということなので、NSGは手作業を作ることになりそうです。
- クラシックVMのイメージとディスクはARMのストレージアカウントにマイグレーションできないのであらかじめ削除して下さい。
- VNETもマイグレーションされるので、旧ポータルで作って暗黙のリソースグループが割り当てられているVNETは、やっぱり別リソースグループのままマイグレーションされます(ので、もともと長い暗黙のリソースグループ名に-migrated」が付けられて更に長く)。
さて、ここから移行作業です。 といってもコマンド自体はいたってシンプルで、このあたりに書いてあるとおりです。 この記事ではPowerShellで書いていきますが、CLIでも同じような手順です。
Migrate IaaS resources from classic to Azure Resource Manager by using Azure CLI | Microsoft Azure
事前準備
アカウントにログインし、マイグレーションリソースプロバイダーを登録します。
# ARMのアカウントにログイン Login-AzureRmAccount # ARMのサブスクリプションを選択 Select-AzureRmSubscription -SubscriptionId [サブスクリプションID] # マイグレーションリソースプロバイダーを登録する Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate # ASMのアカウントにログイン Add-AzureAccount # ASMのサブスクリプションを選択 Select-AzureSubscription -SubscriptionId [サブスクリプションID]
移行作業(VNETに接続している仮想マシンの場合)
この場合、VNETをまるっと移行させるイメージになります。実質2行のスクリプト。エラーが出たらロールバック出来ます。
# VNETを指定して移行準備 Move-AzureVirtualNetwork -Prepare -VirtualNetworkName [VNET名] # エラーが出なければコミット Move-AzureVirtualNetwork -Commit -VirtualNetworkName [VNET名] # prepareでエラーが出た場合はロールバック Move-AzureVirtualNetwork -Abort -VirtualNetworkName [VNET名]
移行作業(VNETに接続していない仮想マシンの場合)
この場合は、クラウドサービスを指定して移行させるイメージになります。 また、ARMのVMはVNET必須なので、VNETを新規に自動作成して移行するか、ARMに既存のVNETに移行するということになります。
▼新規にVNETを作って移行する場合
$serviceName = "[クラウドサービス名]" $deploymentName = (Get-AzureDeployment -ServiceName $serviceName).DeploymentName # 移行準備 Move-AzureService -Prepare -ServiceName $serviceName -DeploymentName $deploymentName -CreateNewVirtualNetwork # エラーが出なければコミット Move-AzureService -Commit -ServiceName $serviceName -DeploymentName $deploymentName # prepareでエラーが出た場合はロールバック Move-AzureService -Abort -ServiceName $serviceName -DeploymentName $deploymentName
▼ARM環境に既存のVNETに移行する場合
$serviceName = "[クラウドサービス名]" $deploymentName = (Get-AzureDeployment -ServiceName $serviceName).DeploymentName # 移行準備 Move-AzureService -Prepare -ServiceName $serviceName -DeploymentName $deploymentName -UseExistingVirtualNetwork -VirtualNetworkResourceGroupName "[既存VNETのリソースグループ名]" -VirtualNetworkName "[VNET名]" -SubnetName "[サブネット名]" # エラーが出なければコミット Move-AzureService -Commit -ServiceName $serviceName -DeploymentName $deploymentName # prepareでエラーが出た場合はロールバック Move-AzureService -Abort -ServiceName $serviceName -DeploymentName $deploymentName
▼マイグレーション状況の確認
(Get-AzureVM -ServiceName "[クラウドサービス名]" -Name "[VM名]").VM.MigrationState
ストレージアカウントのマイグレーション
ストレージアカウントだけクラシックのままで構わない、とか事情があって移行できない、という場合にはこの手順は不要です。今回、ARMのVMからクラシックのストレージアカウントにあるVHDに接続できるようになったみたいですね。 マイグレーションにあたって、VMのイメージやディスクはARMに移行できませんので、あらかじめ削除しておかないとエラーが出ます。 あと、同じストレージアカウントに、ASMのVMが載っていてもエラーになりますので、先にVMを全て移行しておきましょう。
$storageAccountName = "[ストレージアカウント名]" # 事前準備 Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName # エラーが出なければコミット Move-AzureStorageAccount -Commit -StorageAccountName $storageAccountName # prepareでエラーが出た場合はロールバック Move-AzureStorageAccount -Abort -StorageAccountName $storageAccountName
手順はここまでです。 基本的に prepare → commit と繰り返すだけなので作業そのものは簡単ですね。 制約事項を事前によく確認して移行計画をきちんと考えておけば、さほど困るところは無いかと思います。 検証中に「Internal Error」が1回出ましたが、再実行で解決できました。逆ににっちもさっちもという状態になった場合はサポートに頼るしか無いかもしれません。
