Azure portal を使用して Azure Local バージョン 23H2 をデプロイする

適用対象: Azure Local バージョン 23H2

この記事は、Azure portal を使用して Azure ローカル インスタンスバージョン 23H2 をデプロイする際に役立ちます。

前提条件

• 完了:Azure Arc を使用してマシンを登録し、デプロイのアクセス許可を割り当てます。
• 3 ノード・システムの場合、クラスター内ストレージ・トラフィックを伝送するネットワーク・アダプターは、ネットワーク・スイッチに接続する必要があります。 このプレビューでは、スイッチなしで各マシンに直接接続されているストレージ ネットワーク アダプターを使用した 3 ノード システムのデプロイはサポートされていません。

ウィザードを起動し、基本を入力する

1. Web ブラウザーを開き、 Azure ポータルに移動します。 Azure Arc を検索します。[Azure Arc を選択し、Infrastructure |Azure Local。 [開始] タブで、[インスタンス作成を選択します。

2. このシステムのリソースを格納する Subscription Resource グループ を選択します。

   Azure サブスクリプション内のすべてのリソースはまとめて課金されます。

3. Active Directory ドメイン Services (AD DS) がこのデプロイ用に準備されたときに、この Azure ローカル インスタンスに使用Instance 名を入力します。

4. Regionを選択して、このシステムの Azure リソースを格納します。 サポートされている Azure リージョンの一覧については、Azure の要件。

   大量のデータを転送しないため、リージョンが近くない場合は問題ありません。

5. 暗号化キー、ローカル管理者資格情報、BitLocker 回復キーなどこのシステムのシークレットを安全に格納する空の Key コンテナーを作成します。

   Key Vault では、Azure ローカル サブスクリプションに加えてコストが追加されます。 詳細については、「Key Vault の価格」を参照してください。

6. この Azure ローカル インスタンスを構成するマシンを選択します。

   重要

   展開前に、マシンを Active Directory に参加させる必要はありません。

   

7. Validateを選択し、緑色の検証チェック ボックスが表示されるまで待ってから、Next: Configuration を選択します。

   検証プロセスでは、各マシンが同じバージョンの OS を実行しており、正しい Azure 拡張機能を持ち、一致する (対称的な) ネットワーク アダプターを持っていることを確認します。

展開設定を指定する

このシステムの新しい構成を作成するか、テンプレートからデプロイ設定を読み込むかを選択します。どちらの方法でも、デプロイする前に設定を確認できます。

1. 展開設定のソースを選択します。

   • 新しい構成 - このシステムを展開するすべての設定を指定します。
   • テンプレート スペック - Azure サブスクリプションに格納されているテンプレート スペックからこのシステムをデプロイするための設定を読み込みます。
   • クイック スタート テンプレート - この設定は、このリリースでは使用できません。

   

2. [次へ: ネットワーク] を選択します。

ネットワーク設定を指定する

1. マルチノード システムの場合は、記憶域ネットワーク トラフィックにネットワーク スイッチを使用するようにクラスターにケーブル接続するかどうかを選択します。

   • 記憶域用のスイッチがありません - スイッチを経由せずに 2 台のマシンを直接接続するストレージ ネットワーク アダプターを備えた 2 ノード システムの場合。
   • ストレージ トラフィックのネットワーク スイッチ - ネットワーク スイッチに接続されたストレージ ネットワーク アダプターを持つシステムの場合。 これは、記憶域を含むすべてのトラフィックの種類を伝送する集中型ネットワーク アダプターを使用するシステムにも適用されます。

2. 一連のネットワーク アダプターでグループ化するトラフィックの種類と、独自のアダプターで物理的に分離する種類を選択します。

   構成するトラフィックには、次の 3 種類があります。

   • 管理 このシステム、管理 PC、Azure の間のトラフィック。記憶域レプリカ のトラフィックも含まれます。
   • コンピューティング このシステム上の VM とコンテナーとの間のトラフィック。
   • マルチノード システム内のマシン間のストレージ (SMB) トラフィック。

   トラフィックをグループ化する方法を選択します。

   • すべてのトラフィックをグループ化 - ストレージ トラフィックにネットワーク スイッチを使用している場合は、一連のネットワーク アダプターですべてのトラフィックの種類をグループ化できます。

   • グループ管理とコンピューティング トラフィック - 専用の高速アダプターでストレージ トラフィックを分離したまま、1 セットのアダプターで管理トラフィックとコンピューティング トラフィックをグループ化します。

   • コンピューティング トラフィックとストレージ トラフィックのグループ化 - ストレージ トラフィックにネットワーク スイッチを使用している場合は、管理トラフィックを別のアダプター セットで分離したまま、高速アダプターでコンピューティング トラフィックとストレージ トラフィックをグループ化できます。

     これは、プライベート マルチアクセス エッジ コンピューティング (MEC) システムでよく使用されます。

   • カスタム構成 - これにより、各トラフィックの種類を独自のアダプターセットに配置するなど、トラフィックを異なる方法でグループ化できます。

   ヒント

   後でマシンを追加する予定の 1 台のマシンをデプロイする場合は、最終的なクラスターに必要なネットワーク トラフィックグループを選択します。 その後、マシンを追加すると、適切な設定が自動的に取得されます。

3. トラフィックの種類 ( intent と呼ばれる) のグループごとに、少なくとも 1 つの未使用のネットワーク アダプター (ただし、冗長性のために少なくとも 2 つの一致するアダプター) を選択します。

   ストレージ トラフィックを含む意図には、必ず高速アダプターを使用してください。

4. ストレージインテントについては、各ストレージネットワークに使用されるネットワークスイッチに設定VLAN IDを入力します。

   重要

   ポータルのデプロイでは、ストレージインテントに独自の IP を指定することはできません。 ただし、ストレージの IP を指定する必要があり、Network ATC の既定値を使用できない場合は、ARM テンプレートのデプロイを使用できます。 詳細については、このページを参照してください。 ストレージインテント用のCustom IP

   

5. 意図のネットワーク設定をカスタマイズするには、 [ネットワーク設定のカスタマイズ] を選択し、次の情報を指定します。

   • ストレージ トラフィックの優先順位。 これは、データ センター ブリッジング (DCB) を使用する優先順位フロー制御を指定します。
   • クラスター トラフィックの優先順位。
   • ストレージ トラフィック帯域幅の予約。 このパラメーターは、ストレージ トラフィックの帯域幅の割り当てを % で定義します。
   • アダプターのプロパティ Jumbo フレーム サイズ (バイト単位) や RDMA プロトコル (無効にできるようになりました) など。

   

6. 開始 IP と Ending IP (および関連) フィールドを使用して、管理ネットワークのサブネットに少なくとも 6 つの静的 IP アドレスの連続したブロックを割り当てます。このブロックは、マシンで既に使用されているアドレスを省略します。

   これらの IP は、Arc VM 管理と AKS ハイブリッドに必要な Azure ローカルおよび内部インフラストラクチャ (Arc Resource Bridge) によって使用されます。

   

7. [次へ: 管理] を選択します。

管理設定を指定する

1. 必要に応じて、推奨される Custom の場所名 を編集します。この名前は、VM などのリソースを作成するときにユーザーがこのシステムを識別するのに役立ちます。

2. 既存のストレージ アカウントを選択するか、クラスター監視ファイルを格納する新しいストレージ アカウントを作成します。

   既存のアカウントを選択すると、ドロップダウン リストがフィルター処理され、デプロイ用に指定されたリソース グループに含まれるストレージ アカウントのみが表示されます。 複数のクラスターで同じストレージ アカウントを使用できます。各ミラーリング監視サーバーは、1 KB 未満のストレージを使用します。

   

3. このシステムを展開する Active Directory Domain を入力します。

   これは、Active Directory ドメイン サービス (AD DS) ドメインが展開用に準備されたときに使用されるのと同じ完全修飾ドメイン名 (FQDN) である必要があります。

4. このデプロイ用に作成された OU を入力します。 例: OU=HCI01,DC=contoso,DC=com

5. デプロイ アカウント資格情報を入力します。

   このドメイン ユーザー アカウントは、ドメインがデプロイ用に準備されたときに作成されました。

6. マシンのローカル管理者資格情報を入力します。

   資格情報は、システム内のすべてのマシンで同じである必要があります。 現在のパスワードが複雑さの要件 (12 文字以上、小文字と大文字、数字、特殊文字) を満たしていない場合は、先に進む前にすべてのマシンで変更する必要があります。

   

7. [次へ: セキュリティ] を選択します。

セキュリティ レベルを設定する

1. システムのインフラストラクチャのセキュリティ レベルを選択します。

   • 推奨されるセキュリティ設定 - 最高のセキュリティ設定を設定します。
   • カスタマイズされたセキュリティ設定 - セキュリティ設定をオフにすることができます。

   

2. [次: 詳細] を選択します。

必要に応じて詳細設定を変更し、タグを適用する

1. ワークロード用のボリュームを今すぐ作成するかどうかを選択し、VM イメージのボリュームとストレージ パスの作成時間を節約します。 後でさらにボリュームを作成できます。

   • ワークロード ボリュームと必要なインフラストラクチャ ボリュームを作成する (推奨) - ワークロードが使用できるように、マシンごとに 1 つの仮想プロビジョニングボリュームとストレージ パスを作成します。 これは、クラスターごとに必要な 1 つのインフラストラクチャ ボリュームに加えて行われます。

   • 必要なインフラストラクチャ ボリュームのみを作成する - クラスターごとに必要なインフラストラクチャ ボリュームを 1 つだけ作成します。 後でワークロード ボリュームとストレージ パスを作成する必要があります。

   • 既存のデータ ドライブを使用する (単一のマシンのみ) - 記憶域スペース プールとボリュームを含む既存のデータ ドライブを保持します。

     このオプションを使用するには、1 台のマシンを使用していて、データ ドライブに 記憶域スペース プールが既に作成されている必要があります。 また、インフラストラクチャ ボリュームとワークロード ボリュームとストレージ パスがまだない場合は、後で作成する必要がある場合もあります。

   

   重要

   デプロイ中に作成されたインフラストラクチャ ボリュームは削除しないでください。

   システム内のマシンの数に基づいて作成されるボリュームの概要を次に示します。 ワークロード ボリュームの回復性設定を変更するには、インフラストラクチャ ボリュームを削除しないように注意して、それらを削除して再作成します。

   # machines	ボリュームの回復性	# インフラストラクチャ ボリューム	# ワークロード ボリューム
   1 台のマシン	双方向ミラー	1	1
   2 台のマシン	双方向ミラー	1	2
   3 台のマシン +	3 方向ミラー	1	マシンあたり 1 台

2. タグを選択します。

3. 必要に応じて、Azure の Azure ローカル リソースにタグを追加します。

   タグは、リソースの分類に使用できる名前と値のペアです。 その後、特定のタグを持つすべてのリソースの統合請求を表示できます。

4. [ 次へ: 検証 を選択します。 [検証 開始を選択します。

   

5. 検証には、1 台から 2 台のマシンのデプロイに対して約 15 分かかっており、大規模なデプロイではさらに多くの時間がかかります。 検証の進行状況を監視します。

   

システムを検証してデプロイする

1. 検証が完了したら、検証結果を確認します。

   

   検証にエラーがある場合は、実行可能な問題を解決し、 次へ: 確認と作成を選択。

   検証タスクが実行されている間は、 を再度選択しないでください このリリースでは不正確な結果が得られます。

2. 展開に使用する設定を確認し、 Review + create を選択してシステムを展開します。

展開 ページが表示され、デプロイの進行状況を監視するために使用できます。

進行状況が表示されない場合は、数分待ってから Refresh を選択します。 このページは、このリリースの問題により長期間空白として表示されることがありますが、エラーが表示されない場合は、デプロイは引き続き実行されています。

デプロイが開始されると、デプロイの最初の手順である Begin cloud deployment が完了するまでに 45 ~ 60 分かかる場合があります。 1 台のマシンのデプロイ時間の合計は約 1.5 から 2 時間で、2 ノード システムのデプロイには約 2.5 時間かかります。

デプロイが成功したことを確認する

システムとそのすべての Azure リソースが正常にデプロイされたことを確認するには

1. Azure portal で、システムをデプロイしたリソース グループに移動します。

2. Overview>Resourcesには、次の内容が表示されます。

   リソースの数	リソースの種類
   マシンあたり 1 台	マシン - Azure Arc
   1	Azure ローカル
   1	Arc リソース ブリッジ
   1	Key Vault
   1	カスタムの場所
   2*	ストレージ アカウント
   ワークロード ボリュームあたり 1	Azure ローカル ストレージ パス - Azure Arc

   * クラウド監視用に 1 つのストレージ アカウントが作成され、1 つはキー コンテナー監査ログ用に作成されます。 これらのアカウントはローカル冗長ストレージ (LRS) アカウントであり、ロックが設定されています。

展開を再実行する

デプロイが失敗した場合は、デプロイを再実行できます。 Azure ローカル インスタンスで、 Deployments に移動し 右側のウィンドウで Rerun デプロイを選択します。

デプロイ後のタスク

デプロイが完了したら、システムをセキュリティで保護し、ワークロードの準備ができていることを確認するために、追加のタスクを実行する必要がある場合があります。

RDP を有効にする

セキュリティ上の理由から、リモート デスクトップ プロトコル (RDP) は無効になり、Azure ローカル インスタンスでのデプロイの完了後にローカル管理者の名前が変更されます。 名前が変更された管理者の詳細については、「 ローカルの組み込みユーザー アカウントを参照してください。

場合によっては、RDP 経由でシステムに接続してワークロードをデプロイする必要があります。 リモート PowerShell を使用してシステムに接続し、RDP を有効にするには、次の手順に従います。

1. 管理 PC で管理者として PowerShell を実行します。

2. リモート PowerShell セッションを使用して Azure ローカル インスタンスに接続します。

   $ip="<IP address of the Azure Local machine>"
   Enter-PSSession -ComputerName $ip -Credential get-Credential
   

3. RDP を有効にします。

   Enable-ASRemoteDesktop
   

   Note

   セキュリティのベスト プラクティスに従って、不要な場合は RDP アクセスを無効のままにします。

4. RDP を無効にします。

   Disable-ASRemoteDesktop
   

次のステップ

• デプロイ中にワークロード ボリュームを作成しなかった場合は、各ボリュームのワークロード ボリュームとストレージ パスを作成します。 詳細については、「 Azure Local および Windows Server クラスターでのボリュームの作成および Azure Local のストレージ パスの作成を参照してください。
• Azure ローカル デプロイの問題のサポートを受ける。