Start/Stop VMs v2 の概要
Start/Stop VMs v2 機能を使うと、複数のサブスクリプションにまたがる Azure 仮想マシンを開始または停止することができます。 ユーザー定義のスケジュールで仮想マシンを開始または停止し、Azure Application Insights を使用して分析情報を提供し、アクション グループを使用してオプションの通知を送信することができます。 Start/Stop VM を使うと、ほとんどのシナリオで、Azure Resource Manager と非推奨である Azure Service Manager (クラシック) の両方によってデプロイおよび管理されている仮想マシンを管理できます。
この新しいバージョンの Start/Stop VMs v2 により、VM のコストを最適化する必要がある顧客向けに、分散型の低コストなオートメーション オプションが提供されます。 これは Azure Automation で使用できる元のバージョンと同じ機能をすべて提供しますが、より新しい Azure のテクノロジを活用するように設計されています。 Start/Stop VMs v2 は、Mutiple Azure サービスに依存しており、デプロイおよび使用されるサービスに基づいて課金されます。
重要な Start/Stop VMs v2 の更新
Start/Stop VMs v2 関数アプリ リソースが Azure Functions バージョン 4.x を使用するように更新されているため、マーケットプレースから Start/Stop VMs v2 をインストールすると、既定ではこのバージョンが取得されます。 既存の顧客は、自動更新機能を使用して、Functions バージョン 3.x からバージョン 4.x に移行する必要があります。 この機能では、TriggerAutoUpdate タイマー関数を手動で 1 回実行するか、またはスケジュール (有効になっている場合) の実行を待機することによって最新バージョンを取得します。
Start/Stop VMs v2 ソリューションに、信頼性が向上したオファリングを有効にするためのプラン (AZ - 可用性ゾーン) が追加されました。 デプロイを開始する前に、従量課金プランと可用性ゾーン プランのどちらかを選択できるようになりました。 ほとんどの場合、可用性ゾーン プランの月額コストは、従量課金プランと比較すると高くなります。
自動更新機能は、2022 年 4 月 28 日に導入されました。 この新しい自動更新機能は、ソリューションの最新バージョンを維持するのに役立ちます。 この機能は、新しいインストールを実行するときに既定で有効になります。
この日付より前にソリューションをデプロイした場合は、GitHub リポジトリから最新バージョンに再インストールできます。
概要
Start/Stop VMs v2 は再設計されており、以前のバージョンで必要な Azure Automation および Azure Monitor のログに依存していません。 このバージョンは、VM の開始および停止の実行を処理するために Azure Functions を利用します。
マネージド ID が、この Azure Functions アプリケーション用に Microsoft Entra ID で作成されます。これにより、Start/Stop VMs v2 がロジック アプリや Azure VM などの Microsoft Entra で保護された他のリソースに簡単にアクセスできます。 Microsoft Entra ID のマネージド ID について詳しくは、「Azure リソースのマネージド ID とは」をご覧ください。
次の表に示す HTTP トリガー関数エンドポイントが、この機能に含まれるスケジュールおよびシーケンスのシナリオをサポートするために作成されます。
| 名称 | トリガー | 説明 |
|---|---|---|
| スケジュール済み | HTTP | この関数が対象とするシナリオは、スケジュール設定とシーケンス設定の両方です (ペイロード スキーマによって区別されます)。 これは、ロジック アプリから呼び出されたエントリ ポイント関数であり、VM の開始または停止の操作を処理するペイロードを取得します。 |
| AutoStop | HTTP | この関数では、ロジック アプリから呼び出されるエントリ ポイント関数である AutoStop シナリオがサポートされています。 |
| AutoStopVM | HTTP | この関数は、アラート条件が true である場合に VM アラートによって自動的にトリガーされます。 |
| VirtualMachineRequestOrchestrator | キュー | この関数は、Scheduled 関数からペイロード情報を取得し、VM の開始と停止の要求を調整します。 |
| VirtualMachineRequestExecutor | キュー | この関数は、VM で実際の開始および停止の操作を実行します。 |
| CreateAutoStopAlertExecutor | キュー | この関数は、AutoStop 関数からペイロード情報を取得して、VM に関するアラートを作成します。 |
| HeartBeatAvailabilityTest | タイマー | この関数は、プライマリ HTTP 関数の可用性を監視します。 |
| CostAnalyticsFunction | Timer | この関数は、お客様全体の Start/Stop V2 の集計コストを見積もる際に Microsoft が使用します。 この関数は、Start/Stop V2 の機能には影響しません。 |
| SavingsAnalyticsFunction | Timer | この関数は、お客様全体の Start/Stop V2 の集計削減額を見積もる際に Microsoft が使用します。 この関数は、Start/Stop V2 の機能には影響しません。 |
| VirtualMachineSavingsFunction | キュー | この関数は、Start/Stop V2 ソリューションによって実現される VM で実際の節約額の計算を実行します。 |
| TriggerAutoUpdate | タイマー | この関数は、アプリケーション設定 "EnableAutoUpdate=true" に基づいて自動更新プロセスを開始します。 |
| UpdateStartStopV2 | キュー | この関数は、実際の自動更新実行を実行し、現在のバージョンを使用可能なバージョンで検証し、最終的なアクションを決定します。 |
たとえば、Scheduled HTTP トリガー関数は、スケジュールと シーケンスのシナリオを処理するために使用されます。 同様に、AutoStop HTTP トリガー関数によって、自動停止シナリオが処理されます。
この機能をサポートするには、キューベースのトリガー関数が必要です。 すべてのタイマーベースのトリガーは、可用性テストの実行と、システムの正常性の監視に使用されます。
Azure Logic Apps は、JSON ペイロードを使用して関数を呼び出すことにより、VM の開始と停止のスケジュールを構成および管理するために使用されます。 これは既定で、最初のデプロイ中に、次のシナリオ向けに合計 5 つの Logic Apps を作成します。
Scheduled - 開始と停止のアクションは、Azure Resource Manager やクラシック VM に対して指定するスケジュールに基づきます。 ststv2_vms_Scheduled_start と ststv2_vms_Scheduled_stop により、スケジュール設定された開始と停止が構成されます。
Sequenced - 開始と停止のアクションは、事前に定義されたシーケンス処理タグの付いた VM を対象とするスケジュールに基づきます。 サポートされているのは、
sequencestartおよびsequencestopの 2 つの名前付きタグのみです。 ststv2_vms_Sequenced_start と ststv2_vms_Sequenced_stop により、シーケンスされた開始と停止が構成されます。シーケンス機能を使用するための適切な方法として、順番に開始する各 VM で
sequencestartという名前のタグを作成します。 このタグの値は、対応するスコープ内の各 VM に対して 1 から N までの整数である必要があります。 このタグは省略可能であり、存在しない場合、その VM は単純にシーケンス処理に参加しません。 停止する VM にも同じ条件が適用されますが、タグ名だけが異なり、この場合はsequencestopを使用します。 開始と停止のアクションを使用するには、各 VM で両方のタグを構成する必要があります。 複数の VM が同じタグ値を共有している場合、それらの VM は同時に開始または停止されます。たとえば次の表を見ると、開始アクションと停止アクションがどちらも、タグの値の昇順で処理されることがわかります。
Note
このシナリオでサポートされるのは、Azure Resource Manager の VM のみです。
AutoStop - この機能は、それぞれの CPU 使用率に基づいて Azure Resource Manager とクラシック VM の両方に対して停止アクションを実行するためにのみ使用されます。 また、これは、スケジュールに基づいた "アクションの実行" にもなり得ます。これにより、VM に関するアラートが作成され、条件に基づいて、停止アクションを実行するためにアラートがトリガーされます。 ststv2_vms_AutoStop により、自動停止機能が構成されます。
開始と停止の各アクションでは、1 つ以上のサブスクリプション、リソース グループ、または VM の一覧の割り当てがサポートされています。
Functions で必要とされる Azure Storage アカウントも、次の 2 つの目的で Start/Stop VMs によって使用されます。
Azure Table Storage を使用して、実行操作のメタデータ (つまり、VM の開始または停止アクション) を格納する。
Azure Queue Storage を使用して、Azure Functions キューベースのトリガーをサポートする。
関数アプリの実行によるすべてのトレース ログ データは、接続されている Application Insights インスタンスに送信されます。 Application Insights に格納されている利用統計情報は、共有 Azure ダッシュボードに表示される事前定義済みの視覚化のセットから表示できます。
また、VM で実行されたアクションの結果として電子メール通知が送信されます。
新しいリリース
Start/Stop VMs v2 の新しいバージョンがリリースされると、手動で再デプロイしなくてもインスタンスは自動更新されます。
サポートされているスコープのオプション
サブスクリプション
サブスクリプションに対するスコープは、サブスクリプション全体のすべての VM で開始および停止アクションを実行する必要がある場合に使用できます。また、必要に応じて複数のサブスクリプションを選択できます。
除外する VM の一覧を指定することもでき、それらはアクションから無視されます。 また、ワイルドカード文字を使用して、同時に無視できるすべての名前を指定することもできます。
Resource group
リソース グループに対するスコープは、1 つ以上のサブスクリプションにわたって、1 つ以上のリソース グループ名を指定することで、そのすべての VM で開始および停止アクションを実行する必要がある場合に使用できます。
除外する VM の一覧を指定することもでき、それらはアクションから無視されます。 また、ワイルドカード文字を使用して、同時に無視できるすべての名前を指定することもできます。
VMList
VM の一覧の指定は、複数のサブスクリプションにわたって、特定の仮想マシンのセットに対して開始および停止アクションを実行する必要がある場合に使用できます。 このオプションでは、除外する VM の一覧の指定はサポートされていません。
前提条件
アクティブなサブスクリプションを含む Azure アカウントが必要です。 無料でアカウントを作成できます。
このソリューションをデプロイするには、サブスクリプションで所有者アクセス許可がアカウントに付与されている必要があります。
Start/Stop VMs v2 は、Azure Functions の「リージョン別の利用可能な製品」ページに示されている Azure グローバルおよび米国政府機関のクラウドのリージョンすべてで利用できます。
次のステップ
この機能をデプロイするには、Start/Stop VM2 のデプロイに関する記事を参照してください。