Azure Monitor を使ってメンテナンス通知を受け取る

こんにちは、Azure サポート部の石井です。   Azure では、年に一度程度の頻度で、仮想マシンの再起動を伴うメンテナンスが計画しております。 特に何月、と決定されているわけではなく、時期は不定期ですが、通常行われる VM 再起動を伴わないメンテナンスで行えないような、ハードウェアの BIOS・ファームウェア アップデートや、基盤側の OS などソフトウェアの大幅な更新といった目的で行われます。 Azure ご利用のみなさまにはご不便をおけしてしまいますが、何卒、ご協力をいただきますようお願いいたします。   さて、今年中に、仮想マシンの再起動を伴うメンテナンスが計画されております。 本ブログでは、お客様に可能な限り早く、メンテナンスについての情報をお届けさせていただきます。   メール通知の仕組みが改善され、今後は Azure Monitor という仕組みを使って、Azure の管理者の好きなメール アドレスに通知が行えるようになっておりますので事前に通知が受け取れるよう、設定をしてください。   当仕組みは、エンタープライズ アグリーメント (EA)、従量課金、クラウド ソリューション プロバイダー (CSP) など、契約形態に寄らず統一されています。 サブスクリプションごとの設定となりますので、EA や CSP のように、複数の子サブスクリプションを持っている場合には、それぞれの子サブスクリプションに対して、本通知設定をしていただくことをお勧めします。   – 設定方法   今年中に行われるメンテナンスは、Azure Monitor という仕組みと連動し、以下の技術情報の通り設定をしていただいている場合に、登録したメール アドレスに通知がされます。 詳しくは、以下技術情報を参照してください。   新規リリースされた “Azure Monitor” 機能を使って、利用中のリソースに影響しうる大規模障害が発生した場合にメール通知を受け取る https://blogs.technet.microsoft.com/jpaztech/2017/04/10/notifyshdupdate/   現在、ポータルは翻訳の関係から、一部英語表記になっていますので、最新の状態での設定方法をサンプルとして紹介します。   Azure…

0

仮想マシンのデプロイ時にエラーが発生する(VMMarketplaceInvalidInput)

こんにちは、Azure サポートチームの米田です。 今回は、よく弊社にお問い合わせをいただく、Azure仮想マシンのデプロイ時のエラーと対処方法についてご案内します。 ※本手順は ARM (リソースマネージャー モデル / V2)を対象にした記事になります。 ※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。 目的 通常、Azure 仮想マシンを最初に利用する場合は、MarketPlaceにて弊社あるいはサードパーティー様より公開いただいているOSイメージをご選択いただきデプロイするケースが多いかと思います。しかし、仮想マシンの再作成が必要な構成変更を実施する場合や、自身でカスタマイズしたイメージを作成して複製される場合など、MarketPlaceで購入されたOSイメージをベースに仮想マシンを再作成おこないたいというシナリオは比較的良くあるかと思います。このような仮想マシンを再デプロイする際に次のようなエラーが発生しデプロイが失敗してしまう場合があります。       Code:VMMarketplaceInvalidInput イメージから仮想マシンを作成する場合、要求にプラン情報が必要です。OS ディスク名は ‘xxxxx です Creating a virtual machine from Marketplace image requires Plan information in the request. OS disk name is ‘xxxx’. 本記事ではこのエラーの詳細と対処方法をご紹介します。 原因 Azure Marketplaceにて公開されているOSイメージの一部には、仮想マシン内のOSやミドルウェアの料金計算のためにプランと呼ばれる情報が含まれている場合があります。(プラン情報がない仮想マシンイメージもございます)このようなプラン情報が含まれているMarketplaceのOSイメージから作成された仮想マシンは、ディスクやイメージから仮想マシンを再作成する場合にも、このプラン情報を改めて指定しなければならず、それを指定しない場合、上記のエラーが発生します。 仮想マシンに含まれているプラン情報の有無や詳細は次の方法で確認できます。 Azure Resource Explorer(https://resources.azure.com)にアクセスします。 ※Edge, Chrome等のブラウザでアクセスください 複製元の仮想マシンの画面を開きます ※画面上の検索ボタンより仮想マシンを入力するか、画面左メニューより次のように選択していきます。 Subscriptions > “サブスクリプション名” > resourceGroups…

0

Azure Automation: Runbook のスケジュールが編集出来るようになりました

こんにちは、Azure サポートチームの山口です。 Azure Automation をお使いの皆様へ、アップデートのお知らせです。 更新内容 この度、Azure Automation において、Runbook のスケジュールが編集出来るようになりました。 以前までは、Runbook のスケジュールに対して行えるアクションは「停止」または「削除」だけでした。 そのため、スケジュールを再設定したい時は、既存のスケジュールを一旦削除してから同じ Runbook に対して新たなスケジュールを設定する必要がありましたが、今回のアップデートにより、このような手間を掛けることなくスケジュールだけを変更することが可能となりました。 参考: Azure Automation の Runbook をスケジュール設定する https://docs.microsoft.com/ja-jp/azure/automation/automation-schedules スケジュールの編集方法 Azure ポータルにログインして、[Automation アカウント] ブレードから対象の Automation アカウントを選択します。 ハブから [スケジュール] を選び、編集するスケジュールを選択します。 以下のような画面になるので、スケジュールの再設定を行った後、[保存] ボタンを押すと編集した内容が反映されます。


Application Gateway を PowerShell で設定変更するコツ

こんにちは、Azure サポートチームの飯塚です。 最近、おかげさまで Application Gateway をご利用いただいているお客様が増えております。以前は、ポータルからは Application Gateway の作成ができなかったため、手が出しにくいサービスの 1 つでしたが、現在はポータルから作成可能になり、より手軽に Application Gateway をご利用いただけるようになりました。 しかし、作成はできるようになりましたが、作成したあとの設定変更については、まだポータルからはできないことも多い状況です。ポータルから設定できる項目を増やすよう、弊社としましても取り組んでいるところですが、現状では、PowerShell 等での設定変更が必要な場面が少なからずあります。 ただし、PowerShell で Application Gateway を設定する手順は、慣れないと、少しわかりにくい側面がございます。実際にお問い合わせをいただくことも増えてまいりましたので、設定変更のコツを以下におまとめしました。少しでもお役に立てればと思います。 (なお、以下の内容はリソース マネージャー デプロイ モデルを対象としたものです)

0

Application Gateway で利用できる WAF について

皆さんこんにちは、Azureテクニカルサポートの平原です。本日は、Application Gateway (以下 AppGW) で利用ができるようになったWeb Application Firewall (以下WAF)についてよくお問い合わせいただく内容についてご案内をいたします。  

0

Azure Automation : Runbook Webhook を使って仮想マシンの垂直スケール(スケールアップ / ダウン)

こんにちは、Azure サポートチームの山口です。 今回は Azure 仮想マシンのインスタンス サイズを垂直スケール(スケールアップ / スケールダウン)するための Runbook をご紹介したいと思います。 はじめに 突然ですが、お使いの Azure 仮想マシンは、トラフィックが少なくなる夜間や休日などの間、無駄に強力なパワーで稼働していませんか? 同じインスタンス サイズで静的に固定された仮想マシンは、ワークロードが少ない時間帯が来るとコンピューティング リソースが余ってしまいます。それだけでなく、ワークロードが増加する時間帯にはリソースが枯渇し、サーバーダウンにつながる恐れもあります。 この手の問題に対処する一番シンプルな方法は、想定される最大の負荷に耐えられるインスタンス サイズにあらかじめ設定しておくことですが、これは費用の観点から見るとベストな方法といえないこともあります。なぜなら、耐えられる負荷の量が大きくなると、掛かるコストも高くなるからです。 「負荷がかかる時間になれば自動的にスケールアップし、負荷が少ない時にはスケールダウンする」といったインスタンス サイズの動的スケーリングは、コスト最適化を実現する上では必ず考慮すべき対策のひとつです。 与えられたワークロードに必要な分のコンピューティング リソースだけを割り当て続けることが出来れば、必要最低限の出費だけで済みますよね。:) この記事では、そんな動的スケーリングを実現するための Runbook を紹介したいと思います! スケールアップ / ダウン後のインスタンス サイズの取得 まずは、インスタンス サイズを与えると、スケールアップ(スケールダウン)した後のインスタンス サイズを返す PowerShell の関数から紹介します。 後のセクションでこの関数を使った Runbook を説明しますので、「とにかく速く動的な垂直スケールを実現したい!」という方はこのセクションを飛ばして頂いても構いません。 関数中のデフォルトのスケール セット $Default_VerticalScaleTable は、本記事執筆時における東日本 / 西日本リージョンで利用可能なすべてのインスタンス サイズに対応しています。しかしながら、インスタンス サイズ名や利用可能なインスタンス サイズは、今後変更される可能性もございますのでご注意ください。 PowerShell スクリプト Function Get-UpOrDownScaledVmSize { Param ( [Parameter(Mandatory…


Azure Automation : try / catch を利用した Runbook のリトライ処理

こんにちは、Azure サポートチームの山口です。 本記事では、Azure Automation の PowerShell Runbook に、try / catch 構文を利用したリトライ処理を実装する方法を紹介したいと思います。 はじめに 『複数の仮想マシンを一斉起動する Runbook をスケジュールしていて、時間になって確認してみると一台の仮想マシンだけ起動に失敗していた、、、』といったお問い合わせを最近多く頂きます。Azure にアクセスするタイミングによっては、コマンドレットやパラメータの指定は正しいのに、Azure 内部が起因となるエラーが偶に生じてしまいます。このような不運なエラーが起きる原因は、排他制御など様々な要因がありますが、Azure Automation の観点から可用性を高めるためには、Runbook 内でのリトライ処理が非常に有効となります。本記事で紹介するリトライ処理を実装すると、成功するまで Runbook を繰り返し実行するので、上記のようなエラーを回避することが出来ます。 リトライ処理の実装には、PowerShell v2.0 からサポートされている try / catch 構文を使用します。try / catch (/ finally) に関する詳細は、MS 公式ブログ An Introduction to Error Handling in PowerShell (英語) などのサイトを参考にしていただけたらと思います。 リトライ処理のテンプレート 早速、リトライ処理を実現する PowerShell スクリプトのテンプレートを紹介したいと思います。 このスクリプトは、Azure Automation での PowerShell Runbook 環境だけでなく、通常の PowerShell…


Azure to Azure の DR 対策でフェールオーバー後に再保護を実施する際、 Azure 仮想マシンが削除されない機能改善について

こんにちは、Azure サポート チームの伊東です。 Azure Site Recovery を用いて Azure 仮想マシンを Azure リージョン間でレプリケーション、フェールオーバーする機能 (Azure to Azure) のプレビュー版が先日公開されました。 本機能について、フェールオーバー後に再保護を実施しても仮想マシンが削除されないよう機能改善が実装されましたのでご案内いたします。 DR対策として Azure to Azure の機能を用いる際、下記手順を実施いただいております。 Recovery Services コンテナーから対象の仮想マシンについて、レプリケーションを有効化する。 必要時にフェールオーバーを実施する。 フェールオーバーが完了後、コミットを行い復旧ポイントを確定する。 フェールオーバー後にセカンダリ リージョンに作成された仮想マシンを再保護する。 フェールバックを行う際は、セカンダリ リージョンに作成された仮想マシンに対してフェールオーバーを実施する。   上記手順を実施した際、4 の再保護の動作中にプライマリ リージョンにあるフェールオーバー元の仮想マシンは今までは削除されておりました。しかし、先日発表された “Update Rollup 20 for Azure Site Recovery” により、再保護を実施しても仮想マシンは削除されないように機能が改善されました。こちらは、フェールバックした際に対象の仮想マシンを再利用することを目的とした機能改善でございます。 Azure Site Recovery の機能自体には影響はございませんので、ご安心ください。   – 参考 <Update Rollup 20 for Azure Site Recovery>…


Azure Automation: PowerShell Runbook で Azure VM の起動 / 停止(割り当て解除)

こんにちは、Azure サポートチームの山口です。 今回は Azure Automation を使用して、Azure 仮想マシンを起動 / 停止(割り当て解除)する PowerShell Runbook を紹介したいと思います。 本記事は、主にスクリプトコードの紹介となります。ポータル上での Runbook の作成方法やスケジュール設定については、以下の記事を参考にしてください。 Azure Automation で VM を自動停止する https://blogs.technet.microsoft.com/jpaztech/2017/09/01/azure-automation-%E3%81%A7-vm-%E3%82%92%E8%87%AA%E5%8B%95%E5%81%9C%E6%AD%A2%E3%81%99%E3%82%8B/ Runbook 以下は、Azure 仮想マシンを起動 / 停止(割り当て解除)する PowerShell Runbook のスクリプトコードです。 PowerShell Runbook Param ( [Parameter(Mandatory=$false)] [String] $SubscriptionNameOrId, [Parameter(Mandatory=$false)] [String] $ResourceGroupName, [Parameter(Mandatory=$false)] [String] $VMName, [Parameter(Mandatory=$false)] [Bool] $StartVM = $true ) Function Get-AzureRmVMPowerState { Param ( [Parameter(Mandatory=$true)] [Object]…


Azure Site Recovery を用いてレプリケーションを有効化する際に Azure VM のターゲットの場所が選択出来ず、 [The selected target location ‘リージョン名’ is not enabled for VM creation in your subscription.] というエラーが生じる不具合について

こんにちは、Azure サポート チームの伊東です Azure Site Recovery を用いて Azure VM を別リージョンの Azure VM へ (Azure to Azure) レプリケーションする機能のプレビュー版が先日公開されましたが、現在レプリケーション有効化の際にエラーが生じるというお問い合わせを多くいただいております。ご迷惑をお掛けし大変恐れ入りますが、こちら Azure サービス側の原因によって不具合が生じております。本日は不具合への対処方法と機能修正の目途についてご案内いたします。 Recovery Services コンテナーから Azure Site Recovery を用いたレプリケーションを有効にする際、レプリケート対象の Azure VM をフェールオーバーする先のリージョンを [ターゲットの場所] で指定しますが、現在サポート対象のリージョンをご選択いただいても下記のエラー メッセージが生じてしまいます。 エラー メッセージ: [The selected target location ‘リージョン名’ is not enabled for VM creation in your subscription. Select a different location or contact Azure…