0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ManabuYamamoto(Manabu Yamamoto)

Azure Local 上で VM と AKS を構築し、運用機能を確認してみた

0
Last updated at Posted at 2026-08-25

Azure Arc の Azure Local 一覧。Azure Local インスタンス、AKS クラスター、Arc VM が接続済みで表示されている

物理ハードウェアなしで Azure Local を構築し、Arc VM と AKS クラスターを Azure ポータルから一元管理できました。

はじめに

Azure Local を確認したいものの、検証用の物理ハードウェアをすぐに用意できないことがあります。そこで、Azure VM の入れ子になった仮想化を利用して Azure Local と Azure Arc を試せる Azure Arc Jumpstart LocalBox を構築しました。

本記事では、次の内容を実測結果とともに紹介します。

  • Azure Local で利用できるワークロード
  • Azure Local の運用サービス（Insights、OpenTelemetry、Defender for Cloud、更新管理、バックアップ）
  • Arc VM と AKS on Azure Local の構築の手順

注意: 本記事の内容は 2026 年 8 月 24 日時点です。Arc Jumpstart はメンテナンスモードです。また、LocalBox は検証用サンドボックスであり、物理 Azure Local システムの代替ではありません。

TL;DR（先に結論）

  • LocalBox は、1 つの Azure サブスクリプションとリソースグループ内に自己完結する検証環境です。
  • VM SKU は、今回の検証で完走した Standard_E32s_v5 を選びました。
  • Bicep による Azure 基盤のデプロイ自体は 11 分程度で完了します。
  • 本番は Bicep 完了後です。VHDX ダウンロード、入れ子 VM 構築、Arc 登録、Azure Local の検証とデプロイが数時間続きます。進捗はリソースグループの DeploymentProgress タグで追跡できます。
  • Marketplace が使えない環境でも、ローカル共有から VM イメージを作って Arc VM を立てられます。
  • OpenTelemetry メトリックを Azure Monitor ワークスペースへ収集し、PromQL で Arc VM の実データを確認できました。
  • AKS on Azure Local は約 35 分で作成できました。

1. Azure Local とは

Azure Local は、Azure の管理機能を使いながら、仮想マシンやコンテナー、データをユーザー所有の場所で実行する分散インフラストラクチャです。Azure Arc がインフラストラクチャとワークロードのコントロールプレーンになります。

1-1. 利用できる主な機能

分類 主な機能
インフラストラクチャ Windows / Linux VM、ストレージ、ネットワーク
コンテナー AKS on Azure Local、Arc 対応 Kubernetes
運用 Azure Monitor、Update Manager、Defender for Cloud、Azure Policy
エッジ / アプリ Azure IoT Operations、Azure Virtual Desktop
データ / AI SQL Server enabled by Azure Arc、Foundry Local（プレビュー）、Agentic Retrieval in Foundry Local（プレビュー、旧 Edge RAG）

Azure IoT Operations も Azure Local で利用できるワークロードの 1 つです。実際に導入する際は、Azure Local と IoT Operations のバージョン、リージョン、Kubernetes 構成など、個別サービスの前提条件を確認します。

1-2. Connected と Disconnected

Azure Local には、Azure へ定期的に接続する Connected operations と、Azure パブリッククラウドへ接続せずローカルのコントロールプレーンで運用する Disconnected operations があります。

注意: Disconnected operations の利用には、対象契約、事前承認、Standard 以上のサポートプラン、専用管理クラスターなどの条件があります。AKS と Arc 対応 Kubernetes はプレビューです。

項目 Connected Disconnected
コントロールプレーン Azure オンプレミスの専用アプライアンス
管理 Azure ポータル / Azure CLI ローカルの Azure ポータル / Azure CLI
主な運用サービス Azure Monitor、Entra ID、Key Vault、Update Manager Azure Policy、Key Vault、ローカル RBAC などのサブセット
監視 Azure Monitor SCOM、Grafana、Prometheus などを構成
ワークロード VM、AKS、IoT Operations、Virtual Desktop、AI / データサービス VM、AKS（プレビュー）、Arc 対応 Kubernetes（プレビュー）など
接続断 一時的な接続断を許容 Azure / インターネットへの継続接続が不要

Disconnected は、データ主権、規制、遠隔地など Azure へ接続できない明確な要件がある環境向けです。ローカルのコントロールプレーンや監視基盤も自組織で運用するため、接続できる環境では Connected の方が管理コンポーネントを少なくできます。

出典: Connected operations overview、Disconnected operations for Azure Local、Monitor disconnected operations for Azure Local

1-3. LocalBox の構成

Azure Arc Jumpstart LocalBox の公式アーキテクチャ図

1 台の Azure VM 上に、2 ノードの Azure Local 環境を入れ子で構築します。

Azure Local は、Azure Arc を統合コントロールプレーンとして利用し、Azure の管理機能をユーザー所有環境へ拡張する分散インフラストラクチャ ソリューションです。

LocalBox は、Azure 上の LocalBox-Client VM で Hyper-V を有効化し、その中に次の仮想マシンを構築します。

レイヤー 主なリソース 役割
Azure LocalBox-Client 入れ子になった仮想化を実行する外側の VM
入れ子 VM AzLHOST1、AzLHOST2 2 ノードの Azure Local インスタンス
入れ子 VM AzLMGMT 管理用 Hyper-V ホスト
AzLMGMT 内 ドメインコントローラー、ルーター Active Directory と検証用ネットワーク

出典: Azure Local とは、Evaluating Azure Local with LocalBox

2. 検証環境と前提条件

2-1. 今回の構成

項目 値
Azure リージョン Australia East
Azure Local 登録リージョン Australia East
VM SKU Standard_E32s_v5
Spot VM 無効
Azure Bastion 無効
Azure Local 自動デプロイ 有効
Azure Local 自動アップグレード 無効
Arc Jumpstart commit 027b9554b2534af190271bd7443d8556da745d3e
構築された Azure Local 12.2604.1003.1006（Azure Stack HCI OS 24H2）
構築された AKS Kubernetes 1.33.5
Azure CLI 2.84.0
Bicep CLI 0.46.1
使用した CLI 拡張機能 customlocation / stack-hci-vm / aksarc

3. 検証手順

3-1. LocalBox をデプロイする

今回は次の主要パラメーターを指定しました。

パラメーター 値 理由
location australiaeast クォータと SKU 制限を確認済み
azureLocalInstanceLocation australiaeast Azure Local のサポート対象リージョン
vmSize Standard_E32s_v5 今回の検証で完走した構成
enableAzureSpotPricing false 長時間の自動構成中の退避を避ける
autoDeployClusterResource true Azure Local の検証とデプロイを自動化
autoUpgradeClusterResource false 初回検証ではアップグレードを分離
governResourceTags true Microsoft 内部ラボテナント向けの要件

Azure リソースグループを作成し、Bicep を実行します。

# リソースグループを作成し、準備したパラメーターファイルでデプロイします。
az group create --name '<resource-group-name>' --location australiaeast
az deployment group create --resource-group '<resource-group-name>' --parameters localbox.bicepparam

今回の Bicep デプロイ結果は次のとおりです。

項目 結果
ARM デプロイ Succeeded
所要時間 約 11 分
Azure 基盤リソース 17 件、すべて Succeeded
LocalBox-Client VM running
Bootstrap 拡張 Succeeded

3-2. 構築結果を確認する

Azure Local インスタンスがポータルに登録され、ノード 2 台が接続されています。

Azure Local インスタンスの概要画面

マシン一覧では、両ノードが 接続済みで OS バージョンまで見えます。

Azure Local のマシン一覧

各ノードには Azure Local 専用の拡張機能が 4 種導入されます。

Arc 対応サーバーの拡張機能一覧

カスタムの場所も作成されており、これが Arc VM 管理の入り口になります。

カスタムの場所と Arc Resource Bridge

4. Azure Local の運用サービスを整理する

構築が終わると、次は「どう運用するか」です。Azure Local の運用サービスは数が多く分かりにくいので、インスタンス自身とその上のワークロードの 2 層に分けて整理します。

4-1. 一覧

分類 サービス 対象 追加設定
監視 Insights インスタンス 必要
監視 Metrics / Logs / Workbooks / Alerts インスタンス 一部必要
セキュリティ セキュリティ既定値・ドリフト制御 インスタンス 既定で有効
セキュリティ Application Control（WDAC） インスタンス 既定で有効
セキュリティ BitLocker 暗号化 インスタンス 既定で有効
セキュリティ Defender for Cloud（Foundational CSPM） インスタンス 必要・無償
セキュリティ Defender for Servers マシン / Arc VM 必要・有償
更新 Azure Update Manager インスタンス 統合済み
バックアップ Azure Backup（MABS 経由） ホスト / VM 必要
災害復旧 Azure Site Recovery（プレビュー） VM 必要
可観測性 Observability / Remote Support インスタンス 既定で有効

4-2. 監視: Azure Local Insights と VM insights

Insights は Azure Monitor エージェント（AMA）とデータ収集ルール（DCR）を自動構成し、ノード・ドライブ・ボリュームの正常性をブックで可視化します。

前提はマネージド ID が有効であることです。

# Insights の前提となるマネージド ID を確認します。
az resource show --ids "/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.AzureStackHCI/clusters/<cluster-name>" `
  --api-version 2024-04-01 --query "{identityType:identity.type,principalId:identity.principalId}" -o json

ポータルで Azure Local リソース → 監視 → 分析情報 → 開始する、と進みます。

Insights の構成画面。データ収集ルールを選択する

既存の DCR がなければ「新規作成」から作ります。データ収集エンドポイントも同時に作成されます。

新しいデータ収集ルールの作成画面

確認画面では、パフォーマンスカウンター 5 種と Windows イベントログ 2 種が含まれていることが分かります。

Insights の確認画面

自作 DCR は非推奨です。 Insights が作る DCR には専用のデータストリームが含まれるため、公式ドキュメントも既定の DCR を使うよう明記しています。作成される DCR には AzureStackHCI- 接頭辞が自動で付きます。

有効化後に作られるリソースと適用結果です。

項目 内容
データ収集エンドポイント 新規作成
データ収集ルール AzureStackHCI-<任意の名前>
収集内容 パフォーマンスカウンター 5 種・Windows イベントログ 2 種
Azure Monitor エージェント 全ノードへ自動インストール
DCR 関連付け ノードごとに 1 件自動作成

適用結果は CLI で確認できます。

# AMA の導入状態と DCR 関連付けを確認します。
foreach ($m in @('<node1>', '<node2>')) {
    az connectedmachine extension show --machine-name $m -g $rg -n AzureMonitorWindowsAgent `
      --query "{machine:'$m',state:properties.provisioningState,version:properties.typeHandlerVersion}" -o json
}

データが出るまで通常は最大 15 分ほどかかります。今回は約 15 分で正常性タブとノードタブの両方にデータが表示されました。公式のトラブルシューティング手順では、表示されない場合は最大 1 時間待つよう案内されています。

Insights の正常性タブ

ノードタブでは CPU・メモリ・ネットワークの推移と、ドメインや稼働時間も見えます。

Insights のノードタブ

出典: Monitor a single Azure Local system with Insights

ここで一度ハマりました。Insights を有効化したのに、Arc 対応サーバーの Monitor 画面では「メトリックは検出されませんでした」のままでした。

名前が似ていますが、この 2 つは別の機能です。

項目 Azure Local Insights VM insights
対象 Azure Local クラスター全体 Arc 対応サーバー個々のマシン
見るもの ノード・ドライブ・ボリュームの正常性 CPU・メモリ・ディスクの詳細メトリック
保存先 Log Analytics の Perf / Event Azure Monitor ワークスペース（OTel）または Log Analytics の InsightsMetrics（クラシック）
DCR AzureStackHCI- 接頭辞 監視方式ごとに作成
有効化 Azure Local リソースの分析情報 マシンの Monitor 画面

1 台のマシンに複数の DCR を関連付けられるため、両方を共存させられます。

VM insights の DCR には 2 系統あります。新規環境では OpenTelemetry 方式が推奨で、ログベース（クラシック）はポータルの従来の画面を有効にする互換用途です。

方式 ストリーム 送信先 位置づけ
OpenTelemetry メトリック Microsoft-OtelPerfMetrics Azure Monitor ワークスペース 新規デプロイの推奨
ログベース（クラシック） Microsoft-InsightsMetrics Log Analytics ワークスペース 従来のポータル画面を有効化

今回は Arc VM に両方を構成しました。従来の VM insights 画面も比較するため、クラシック方式を併用しています。

まずクラシック方式です。\VmInsights\DetailedMetrics という 1 つの指定で、CPU・メモリ・ディスク・ネットワークの詳細メトリックがまとめて収集されます。

ログベース（クラシック）の DCR と関連付け（クリックで展開） 
{
  "name": "VMInsightsPerfCounters",
  "streams": ["Microsoft-InsightsMetrics"],
  "scheduledTransferPeriod": "PT1M",
  "samplingFrequencyInSeconds": 60,
  "counterSpecifiers": ["\\VmInsights\\DetailedMetrics"]
}

# DCR を作成し、Arc VM へ関連付けます。
az monitor data-collection rule create --name 'MSVMI-<name>-dcr' `
  --resource-group $rg --location <region> --rule-file 'vminsights-dcr.json'

$dcr = "/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.Insights/dataCollectionRules/MSVMI-<name>-dcr"
$machine = '<arc-vm-name>'
az monitor data-collection rule association create --name 'VMInsights-Dcr-Association' `
  --rule-id $dcr `
  --resource "/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.HybridCompute/machines/$machine"

適用後は、マシンの Monitor 画面で詳細メトリックが描画されます。

VM insights の詳細メトリック。CPU 使用率、利用可能メモリ、論理ディスクの IOPS とレイテンシが表示されている

Arc 対応サーバーの Monitor 画面。ゲスト OS 内部のメトリックがここで見えるようになります。

次に OpenTelemetry 方式です。送信先が Log Analytics ではなく Azure Monitor ワークスペースになる点が最大の違いで、先にワークスペースを作る必要があります。

OpenTelemetry メトリックの DCR と関連付け（クリックで展開） 
# 送信先となる Azure Monitor ワークスペースを作成します。
az monitor account create --name '<amw-name>' --resource-group $rg --location <region>

{
  "name": "OtelPerfCounters",
  "streams": ["Microsoft-OtelPerfMetrics"],
  "samplingFrequencyInSeconds": 60,
  "counterSpecifiers": [
    "system.cpu.time", "system.memory.usage",
    "system.disk.io", "system.disk.operations", "system.disk.operation_time",
    "system.filesystem.usage",
    "system.network.io", "system.network.dropped", "system.network.errors",
    "system.uptime"
  ]
}

# OpenTelemetry メトリック用の DCR を作成します。
$otel = "/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.Insights/dataCollectionRules/MSVMI-<name>-otel-dcr"
az rest --method put `
  --url "https://management.azure.com$otel`?api-version=2025-05-11" `
  --headers "Content-Type=application/json" `
  --body '@otel-metrics-dcr.json'

# Arc VM へ関連付けます。
$machine = '<arc-vm-name>'
az monitor data-collection rule association create --name 'OtelMetrics-Dcr-Association' `
  --rule-id $otel `
  --resource "/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.HybridCompute/machines/$machine"

クラシック方式が \VmInsights\DetailedMetrics の 1 行で済むのに対し、OpenTelemetry 方式は 収集するメトリックを個別に列挙します。裏を返せば、必要なものだけに絞り込めます。既定で収集されるメトリックは追加コストなしで、それ以外を追加すると課金対象になります。

出典: Customize OpenTelemetry metrics collection for virtual machines in Azure Monitor

結果として、Arc VM にクラシック方式と OpenTelemetry 方式の 2 つの DCR が関連付いた状態になりました。

DCR ストリーム 送信先
MSVMI-...-dcr Microsoft-InsightsMetrics Log Analytics
MSVMI-...-otel-dcr Microsoft-OtelPerfMetrics Azure Monitor ワークスペース

1 台のマシンに複数の DCR を関連付けられるため、目的別に構成を分けられます。

Azure Monitor ワークスペースでは、system.memory.usage の used と free から使用率を計算する PromQL を実行しました。Arc VM のメモリ使用率が約 24〜27% で推移する実データを確認できました。

Azure Monitor ワークスペースで OpenTelemetry のメモリ使用率を PromQL で可視化した画面

出典: Collect and customize OpenTelemetry metrics for virtual machines

マップ（依存関係図）には Dependency Agent が別途必要です。メトリック表示だけなら AMA のみで動きます。

出典: Enable VM monitoring in Azure Monitor

4-3. セキュリティ

Azure Local は 300 以上のセキュリティ設定が既定で有効な secure-by-default 製品です。以下は追加設定なしで動いています。

機能 内容
セキュリティ既定値・ドリフト制御 90 分ごとに設定を再適用し、望ましい状態から外れたら自動修復。CIS ベンチマークと DISA STIG に対応
Application Control（WDAC） 許可リスト方式でコード実行を制限。既定は Enforcement モード
BitLocker 暗号化 OS ボリュームと CSV を暗号化。デプロイ時に自動実行
シークレットローテーション 内部証明書・シークレットの自動更新

実際、デプロイのステップ一覧にも Encrypt CSVs と Encrypt the OS volume が含まれており、明示的な操作なしに暗号化まで完了しています。

追加で有効化するのが Microsoft Defender for Cloud です。Azure Local 向けはプレビューで、2 段階に分かれます。

手順 プラン 費用 得られるもの
1 Foundational CSPM 無償 Azure Local のセキュリティ態勢評価と推奨事項
2 Defender for Servers 有償（Plan 1 / Plan 2） 個々のマシンと Arc VM のセキュリティアラート、脆弱性評価、エンドポイント保護

まず無償の Foundational CSPM だけ有効にして推奨事項を眺める、という進め方ができます。

Azure Local リソースには Defender for Cloud のブレードが統合されており、カバー状況と Azure Local 固有の推奨事項を確認できます。今回は、ボリューム暗号化と Application Control が重要度 High、Secured-core とホスト／VM ネットワーク保護が重要度 Low として表示されました。

Azure Local の Defender for Cloud 画面。ボリューム暗号化、Application Control、Secured-core、ネットワーク保護の推奨事項と重大度が表示されている

今回のサブスクリプションでは Foundational CSPM と Defender for Servers Plan 2 が既に有効になっており、作成した Arc VM も自動的に保護対象に入りました。ただしこれは サブスクリプション側でプランが有効になっているから であって、Arc VM だから常に自動保護されるわけではありません。プランの有効化状態は次で確認できます。

# Defender プランの有効化状態を確認します。
az security pricing list --query "value[?name=='VirtualMachines' || name=='CloudPosture'].{name:name,tier:pricingTier,plan:subPlan}" -o json

出典: Security features for Azure Local、Manage system security with Microsoft Defender for Cloud (preview)

4-4. 更新管理

Azure Local のソリューション更新には、OS、コアエージェント、サービスが含まれます。ハードウェアベンダーが Solution Builder Extension（SBE）へ統合している場合は、ドライバーとファームウェアも同じ更新フローで管理できます。Azure Update Manager から複数インスタンスを管理できます。

状態は CLI からも確認できます。

# 現在のバージョンと利用可能な更新を確認します。
$base = "/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.AzureStackHCI/clusters/<cluster-name>"
az rest --method get --url "https://management.azure.com$base/updateSummaries?api-version=2024-04-01"
az rest --method get --url "https://management.azure.com$base/updates?api-version=2024-04-01"

今回のインスタンスはデプロイ直後の時点で既に累積更新が 4 件提示されました。ポータル上は最新の累積更新のみが推奨として表示されます。適用はノードを 1 台ずつ再起動しながら進むため数時間かかります。

Azure Local の更新プログラム画面

出典: About updates for Azure Local、Use Azure Update Manager to update Azure Local

4-5. バックアップと災害復旧

ここは Azure VM と考え方が異なるので注意が必要です。

サービス 対象 構成上の注意
Azure Backup ホストの System State / BMR、ゲスト VM Microsoft Azure Backup Server（MABS）v3 UR2 以降が別途必要。WDAC Enforcement モードでエージェントを導入・更新する場合は MABS v4 UR2 と補足ポリシーを使用
Azure Site Recovery（プレビュー） ゲスト VM Azure Local から Azure への継続レプリケーションとフェールオーバー

Azure VM のようなエージェントレスの直接バックアップではなく、MABS を経由する構成になります。

出典: Back up Azure Local virtual machines with Azure Backup Server、Protect VM workloads with Azure Site Recovery on Azure Local (preview)

4-6. 可観測性とサポート

デプロイ時に自動構成されるため、利用者が意識する場面は多くありません。Arc 対応サーバーに入る 4 つの拡張機能がこの層を担っています。

拡張機能 役割
AzureEdgeLifecycleManager 更新・ライフサイクル管理
AzureEdgeDeviceManagement デバイス構成管理
AzureEdgeRemoteSupport Microsoft サポートによるリモート診断
AzureEdgeTelemetryAndDiagnostics テレメトリ・診断データの収集

出典: Hybrid capabilities with Azure services in Azure Local、What is Azure Local monitoring?

5. Arc VM を試す

Azure Local の主目的のひとつが、Azure ポータルからオンプレミスの Azure Local VM を管理することです。本記事では、検証時の CLI とリソース名に合わせて「Arc VM」と表記します。今回は VM イメージをローカル共有から作成しました。

# 手順 今回の方式
1 VM イメージ ローカル共有（ガイドは Azure Marketplace）
2 論理ネットワーク LocalBox 同梱スクリプト
3 ネットワークインターフェイス Azure CLI
4 Arc VM Azure CLI

5-1. ローカル共有から VM イメージを作る

LocalBox は Windows Server 2022 の汎用化済み VHDX（C:\LocalBox\VHD\GUI.vhdx、18.3 GB）を持っています。これをクラスター共有ボリュームへ配置すればイメージ化できます。

コピーは PowerShell Direct セッション経由が確実でした。

# LocalBox-Client から所有ノードへ VHDX をコピーします。
$session = New-PSSession -VMName 'AzLHOST1' -Credential $cred
Copy-Item -Path 'C:\LocalBox\VHD\GUI.vhdx' `
  -Destination 'C:\ClusterStorage\UserStorage_1\Images\ws2022-gui.vhdx' `
  -ToSession $session -Force

18.25 GB の転送に 37 分 51 秒かかりました。入れ子仮想化環境なので実機よりは遅いはずです。

コピー後は --image-path にクラスター上のパスを渡すだけです。

az stack-hci-vm image create `
  --resource-group $rg --custom-location $customLocationId --location <region> `
  --name 'ws2022-gui-local' --os-type 'Windows' `
  --image-path 'C:\ClusterStorage\UserStorage_1\Images\ws2022-gui.vhdx'

VHDX が既にクラスター上にあれば、イメージ登録自体は 35 秒で完了しました。

VM イメージ一覧。ソースがカスタマー マネージドになっている

ポータルの ソース列が カスタマー マネージド になっており、Marketplace 由来でないことが分かります。

5-2. 論理ネットワークを作る

LocalBox には 192.168.200.0/24 を VLAN 200 でタグ付けしたネットワークが用意されており、Arc VM 用の論理ネットワークとして登録します。専用スクリプトが同梱されています。

項目 値
サブネット 192.168.200.0/24
ゲートウェイ 192.168.200.1
VLAN ID 200
DNS 192.168.1.254 
# LocalBox 同梱のスクリプトを pwsh で実行します。
& 'C:\Program Files\PowerShell\7\pwsh.exe' -NoProfile -ExecutionPolicy Bypass `
  -File 'C:\LocalBox\Configure-VMLogicalNetwork.ps1'

論理ネットワークのリソース画面

5-3. Arc VM を作る

ネットワークインターフェイスを作ってから VM を作成します。

注意: 管理者パスワードをコマンドへ直接書くとシェル履歴にも残ります。以下はリテラルを履歴やファイルへ残しませんが、Azure CLI 実行中は平文がプロセス引数へ一時的に渡ります。共有端末では実行中のプロセス閲覧権限にも注意してください。

NIC と Arc VM を作成する（クリックで展開） 
# ネットワークインターフェイスを作成します。
az stack-hci-vm network nic create `
  --resource-group $rg --custom-location $customLocationId --location <region> `
  --name 'arcvm-ws2022-nic' --subnet-id $logicalNetworkId

# パスワードは対話入力し、リテラルをコマンド履歴に残しません。
$secure = Read-Host -Prompt 'Admin password' -AsSecureString
$bstr = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($secure)
$plain = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($bstr)

try {
    az stack-hci-vm create `
      --resource-group $rg --custom-location $customLocationId --location <region> `
      --name 'arcvm-ws2022' --computer-name 'arcvm-ws2022' `
      --image 'ws2022-gui-local' `
      --admin-username '<user>' --admin-password $plain --authentication-type all `
      --nics 'arcvm-ws2022-nic' `
      --hardware-profile memory-mb=8192 processors=2 `
      --storage-path-id $storagePathId --enable-agent true
}
finally {
    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($bstr)
    Remove-Variable plain -ErrorAction SilentlyContinue
}

作成された VM は Azure Local VM として管理されます。今回は --enable-agent true でゲスト管理も有効化したため、ゲスト OS に Connected Machine Agent が入り、Arc 対応サーバーとしての投影も作成されます。

Arc VM の概要画面

仮想マシンの種類 が Azure Local になっており、イメージ名・カスタムの場所・論理ネットワーク・割り当てられた IP アドレスまで Azure 側から見えます。ゲスト OS には Arc エージェントが入り、拡張機能の管理も可能です。

Azure Local インスタンス側の仮想マシン一覧にも表示されます。

Azure Local の仮想マシン一覧

注意: この一覧に出るのは Arc Resource Bridge 経由で作成した VM だけです。クラスター上に直接作った Hyper-V VM は表示されません。

5-4. 構築後の全体像

Azure Arc の Azure Local 一覧では、親となる Azure Local インスタンスの下に AKS クラスターと Arc VM が表示されます。いずれも接続済みで、Azure Local 上の基盤とワークロードを 1 画面で確認できます。

Azure Arc の Azure Local 一覧。Azure Local インスタンス、AKS クラスター、Arc VM が接続済みで表示されている

出典: Virtual machine provisioning with Azure Arc in your LocalBox、Create Azure Local VM image using images in a local share

6. AKS on Azure Local を試す

Azure Local には AKS enabled by Azure Arc が既定で含まれており、追加のインストールなしで Kubernetes クラスターを作れます。LocalBox にも専用スクリプトが同梱されています。

6-1. AKS 用の論理ネットワークを作る

今回は LocalBox の構成に合わせ、Arc VM 用（VLAN 200）とは別に AKS 用の論理ネットワークを作成しました。公式には Arc VM と AKS で論理ネットワークを共有する構成も選べます。AKS のノード VM には静的 IP を割り当てるため、IP プールの指定が必須です。

項目 値
サブネット 10.10.0.0/24
ゲートウェイ 10.10.0.1
VLAN ID 110
IP プール 10.10.0.101 〜 10.10.0.199
コントロールプレーン IP 10.10.0.5 
az stack-hci-vm network lnet create `
  --resource-group $rg --custom-location $customLocationId --location <region> `
  --name 'localbox-aks-lnet-vlan110' --vm-switch-name '"ConvergedSwitch(compute_management)"' `
  --ip-allocation-method 'static' `
  --ip-pool-start '10.10.0.101' --ip-pool-end '10.10.0.199' `
  --address-prefixes '10.10.0.0/24' --gateway '10.10.0.1' --dns-servers '192.168.1.254' `
  --vlan 110

AKS 用論理ネットワークの詳細

出典: Create logical networks for Kubernetes clusters on Azure Local

6-2. AKS クラスターを作る

az aksarc create `
  --name 'localbox-aks' --resource-group $rg --location <region> `
  --custom-location $customLocationId --vnet-ids $aksLogicalNetworkId `
  --control-plane-ip '10.10.0.5' --generate-ssh-keys

入れ子仮想化環境で 約 35 分かかりました。完成後の姿です。

AKS クラスターの概要画面

項目 値
状態 Connected / Succeeded
Kubernetes 1.33.5
ノード数 合計 2 台（コントロールプレーン 1 台、nodepool1 のワーカーノード 1 台）
ディストリビューション Workload
インフラストラクチャ Azure Local
親クラスター localboxcluster
ネットワークポリシー calico

インフラストラクチャが Azure Local になっており、通常の AKS や他の Arc 対応 Kubernetes と区別されます。親クラスターとして Azure Local インスタンスの ID が入るのも特徴です。

最終的なリソースグループはこうなりました。Arc マシン、Arc VM、Kubernetes、論理ネットワーク、カスタムの場所が 1 つのリソースグループに収まっています。

リソースグループ全体の構成

まとめ

  • LocalBox により、物理ハードウェアを用意せず Azure Local と Azure Arc の構成を試せます。
  • 運用サービスは「インスタンス自身」と「ワークロード」の 2 層で整理すると理解しやすいです。 セキュリティ既定値・WDAC・BitLocker・可観測性は既定で有効です。Insights、Defender for Cloud、バックアップは追加構成が必要で、更新管理は Azure Local に統合されています。
  • Connected は Azure の運用サービスを利用し、Disconnected はローカルのコントロールプレーンと監視基盤を運用します。 接続要件と運用責任が選択軸です。
  • Azure Local Insights と VM insights は別機能です。 OpenTelemetry メトリックは Azure Monitor ワークスペースへ保存され、PromQL で Arc VM の実データを確認できました。
  • ローカル共有から Arc VM イメージを作成し、AKS on Azure Local まで構築できました。

参考: デプロイ前後の補助手順

本文の流れから外した事前確認と補助手順をまとめます。

参考-1. 権限とクォータを確認する

LocalBox の公式 FAQ では、対象サブスクリプションに条件の付いていない Owner ロールが必要です。また、VM ファミリとリージョン全体の両方に 32 vCPU 以上の空きが必要です。

$subscriptionId = '<subscription-id>'
$location = 'australiaeast'
az vm list-usage --subscription $subscriptionId --location $location `
  --query "[?contains(name.localizedValue, 'ESv5') || name.value=='cores'].{Name:name.localizedValue,Current:currentValue,Limit:limit}" -o table

今回の ESv5 ファミリとリージョン全体の上限はいずれも 100 vCPU、使用中は 0 vCPU でした。

参考-2. VM SKU と必須プロバイダーを確認する

az vm list-skus --subscription $subscriptionId --location $location `
  --resource-type virtualMachines --size Standard_E32s_v5 `
  --query "[?name=='Standard_E32s_v5'].{Name:name,Zones:locationInfo[0].zones,Restrictions:restrictions}" -o json

LocalBox が使う主なリソースプロバイダーは、Microsoft.HybridCompute、Microsoft.AzureStackHCI、Microsoft.Kubernetes、Microsoft.ExtendedLocation、Microsoft.ResourceConnector、Microsoft.HybridContainerService、Microsoft.Insights です。未登録のものを az provider register --namespace <namespace> で登録し、Registered になってからデプロイします。

参考-3. Arc Jumpstart を取得する

git clone --depth 1 --filter=blob:none --sparse https://github.com/microsoft/azure_arc.git azure_arc
Set-Location azure_arc
git sparse-checkout set azure_jumpstart_localbox
git rev-parse HEAD

参考-4. パスワードをファイルへ保存しない

.bicepparam では環境変数を読み込みます。

param windowsAdminPassword = readEnvironmentVariable('LOCALBOX_ADMIN_PASSWORD')

PowerShell で Read-Host -AsSecureString からプロセス環境変数へ渡し、デプロイ後は Remove-Item Env:LOCALBOX_ADMIN_PASSWORD で削除します。

参考-5. 後続自動化を監視する

Bicep 完了後も VM 内の自動化が数時間続きます。完了条件は DeploymentProgress=Completed かつ DeploymentStatus の Tests failed: 0 です。

az group show -n '<resource-group-name>' `
  --query "{Progress:tags.DeploymentProgress,Status:tags.DeploymentStatus}" -o json
az deployment group list -g '<resource-group-name>' `
  --query "[?starts_with(name, 'localcluster')].{Name:name,State:properties.provisioningState}" -o table

出典: LocalBox FAQ、Deploy LocalBox infrastructure with Azure Bicep、Azure portal でクォータの増加を要求する、Bicep パラメーターファイルの関数

参考リンク

本記事は GitHub Copilot および Microsoft Foundry を活用して作成されています。内容の正確性については各公式ドキュメントをご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?