Azure Local でノードを修復する

適用対象: Azure Local 2311.2 以降

この記事では、Azure ローカル インスタンス上のノードを修復する方法について説明します。 この記事では、各サーバーをノードと呼びます。

修復ノードについて

Azure Local は、既存のシステムからノードを修復できるハイパーコンバージド システムです。 ハードウェア障害が発生した場合は、システム内のノードの修復が必要になる場合があります。

ノードを修復する前に、ソリューション プロバイダーに確認してください。ノード上のどのコンポーネントがフィールド交換ユニット (FRU) であり、自分で交換できるコンポーネントで、どのコンポーネントを交換する必要がありますか。

ホット スワップをサポートするパーツでは、通常、マザーボードなどのホット スワップ不可能なコンポーネントとは異なり、ノードを再イメージ化する必要はありません。 ノードを再イメージ化する必要があるコンポーネントの交換を決定するには、ハードウェアの製造元に問い合わせてください。 詳細については、「 コンポーネントの置換」を参照してください。

ノードの修復ワークフロー

次のフロー図は、ノードを修復するプロセス全体を示しています。

*ノードがシャットダウンが可能または必要な状態ではない可能性があります*

既存のノードを修復するには、次の大まかな手順に従います。

1. 可能であれば、修復するノードをシャットダウンします。 ノードの状態によっては、シャットダウンが不可能または必要な場合があります。

2. 修復する必要があるノードを再イメージ化します。

3. 修復ノード操作を実行します。 Azure Stack HCI オペレーティング システム、ドライバー、ファームウェアは、修復操作の一環として更新されます。

   ストレージは、再イメージ化されたノードで自動的に再調整されます。 ストレージの再調整は優先順位の低いタスクであり、ノードの数と使用されるストレージに応じて、数日間実行できます。

サポートされるシナリオ

ノードを修復すると、ノードが再イメージ化され、以前の名前と構成でシステムに戻されます。

1 つのノードを修復すると、データ ボリュームを保持するオプションを使用して再デプロイが行われます。 システム ボリュームのみが削除され、デプロイ中に新しくプロビジョニングされます。

重要

ワークロードのバックアップが常に存在し、システムの回復性のみに依存していないことを確認します。 これは、単一ノードのシナリオで特に重要です。

回復性の設定

このリリースでは、ノードの修復操作では、デプロイ後に作成したワークロード ボリュームに対して特定のタスクは実行されません。 ノードの修復操作では、必要なインフラストラクチャ ボリュームとワークロード ボリュームのみが復元され、クラスター共有ボリューム (CSV) として表示されます。

デプロイ後に作成した他のワークロード ボリュームは引き続き保持され、 Get-VirtualDisk コマンドレットを実行してこれらのボリュームを検出できます。 ボリュームのロックを手動で解除し (ボリュームで BitLocker が有効になっている場合)、CSV を作成する必要があります (必要な場合)。

ハードウェア要件

ノードを修復するときに、システムは新しい受信ノードのハードウェアを検証し、ノードがシステムに追加される前にハードウェア要件を満たしていることを確認します。

コンポーネント	コンプライアンス チェック
CPU (中央処理装置)	新しいノードに同じ数以上の CPU コアがあることを確認します。 受信ノードの CPU コアがこの要件を満たしていない場合は、警告が表示されます。 ただし、操作は許可されます。
[メモリ]	新しいノードに同じ量以上のメモリがインストールされていることを確認します。 受信ノードのメモリがこの要件を満たしていない場合は、警告が表示されます。 ただし、操作は許可されます。
ドライブ	新しいノードに、記憶域スペース ダイレクトで使用できるデータ ドライブの数が同じであることを確認します。 受信ノード上のドライブの数がこの要件を満たしていない場合は、エラーが報告され、操作がブロックされます。

ノードの置換

ノード全体を置き換えることができます。

• 古いノードと異なるシリアル番号を持つ新しいノード。
• 再イメージ化した後、現在のノードを使用します。

ノードの交換中は、次のシナリオがサポートされます。

ノード	ディスク	サポート
新しいノード	新しいディスク	はい
新しいノード	現在のディスク	はい
現在のノード (再イメージ化)	新しいディスク	はい
現在のノード (再イメージ化)	現在のディスク	はい
現在のノード (再イメージ化)	現在のデータ ディスクの再フォーマット	いいえ

重要

ノードの修復中にコンポーネントを交換する場合、データ ドライブを交換またはリセットする必要はありません。 ドライブを交換またはリセットした場合、ノードがシステムに参加してもドライブは認識されません。

コンポーネントの交換

Azure ローカル インスタンスでは、ホット スワップ不可能なコンポーネントには次のものが含まれます。

• マザーボード/ベースボード管理コントローラー (BMC)/ビデオ カード
• ディスク コントローラー/ホスト バス アダプター (HBA)/バックプレース
• ネットワーク アダプター
• グラフィックス処理装置
• データ ドライブ (ホットスワップをサポートしないドライブ。例: PCI-e アドイン カード)

ホット スワップ不可能なコンポーネントの実際の交換手順は、OEM (オリジナルの機器メーカー) ハードウェア ベンダーによって異なります。 ホット スワップ不可能なコンポーネントにノードの修復が必要な場合は、OEM ベンダーのドキュメントを参照してください。

前提条件

ノードを修復する前に、次のことを確認する必要があります。

• AzureStackLCMUser は Active Directory でアクティブです。 詳細については、「 Active Directory の準備」を参照してください。
• AzureStackLCMUserまたは同等のアクセス許可を持つ別のユーザーとしてサインインします。
• AzureStackLCMUserの資格情報は変更されていません。

• 必要に応じて、修復のために特定したノードをオフラインにします。 次の手順に従います。

  1. オフラインにする前に、ノードが正常であることを確認します。
  2. ノードを一時停止してドレインします。
  3. ノードをシャットダウンします。

ノードを修復する

このセクションでは、PowerShell を使用してノードを修復し、 Repair-Server 操作の状態を監視し、問題が発生した場合のトラブルシューティングを行う方法について説明します。

前提条件を確認したかどうかを確認してください。

修復しようとしているノードで、次の手順に従います。

1. Azure Stack HCI 管理者ロールのアクセス許可を使用して Azure portal にサインインします。

   1. Azure Local インスタンスのデプロイに使用するリソース グループに移動します。 リソース グループで、修復する障害のあるノードの Azure Arc マシン リソースを特定します。

   2. Azure Arc マシン リソースで、[ 設定] > [ロック] に移動します。 右側のウィンドウに、リソース ロックが表示されます。

   3. ロックを選択してから、ごみ箱アイコンを選択してロックを削除します。

      

   4. Azure Arc マシン リソースの [概要 ] ページで、右側のウィンドウで [削除] を選択 します。 このアクションでは、障害のあるマシン ノードを削除する必要があります。

      

2. 修復するノードにオペレーティング システムと必要なドライバーをインストールします。 「Azure Stack HCI オペレーティング システムバージョン 23H2 のインストール」の手順に従います。

   注

   • バージョン 2503 以降では、既存のクラスターで実行されているのと同じソリューションの OS イメージを使用する必要があります。 OS イメージ テーブルを使用して、適切な OS イメージ バージョンを特定してダウンロードします。
   • カスタム ストレージ IP を使用して Azure Local インスタンスをデプロイした場合は、ノードの修復後に、ストレージ ネットワーク アダプターに IP を手動で割り当てる必要があります。

3. ノードを Arc に登録します。 「Arc に登録してアクセス許可を設定する」の手順に従います。

   注

   Arc に登録するには、既存のノードと同じパラメーターを使用する必要があります。たとえば、リソース グループ名、リージョン、サブスクリプション、テナントなどです。

4. 修復されたノードに次のアクセス許可を割り当てます。

   • Azure ローカル デバイス管理の役割
   • Key Vault シークレット ユーザー 詳細については、「 ノードへのアクセス許可の割り当て」を参照してください。

同じ Azure Local インスタンスのメンバーである別のノードで、次の手順に従います。

1. 2405.3 より前のバージョンを実行している場合は、次のコマンドを実行して競合するファイルをクリーンアップする必要があります。

   Get-ChildItem -Path "$env:SystemDrive\NugetStore" -Exclude Microsoft.AzureStack.Solution.LCMControllerWinService*,Microsoft.AzureStack.Role.Deployment.Service* | Remove-Item -Recurse -Force
   

2. システムのデプロイ時に指定したドメイン ユーザー資格情報を使用して、既にシステムのメンバーになっているノードにサインインします。 次のコマンドを実行して、受信ノードを修復します。

   $Cred = Get-Credential 
   Repair-Server -Name "<Name of the new node>" -LocalAdminCredential $Cred
   

   注

   ノード名は NetBIOS 名である必要があります。 既定で LocalAdminCredential パラメーターは、Windows OS インストールによって作成される組み込みの管理者アカウントです。

3. Repair-Server コマンドによって出力される操作 ID を書き留めます。 後でこれを使用して、 Repair-Server 操作の進行状況を監視します。

操作の進行状況を監視する

ノードの追加操作の進行状況を監視するには、次の手順に従います。

1. 次のコマンドレットを実行し、前の手順の操作 ID を指定します。

   $ID = "<Operation ID>" 
   Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID 
   

2. 操作が完了すると、バックグラウンド ストレージの再調整ジョブは引き続き実行されます。 ストレージの再調整作業が完了するまでお待ちください。 このストレージの再調整ジョブの進行状況を確認するには、次のコマンドレットを使用します。

   Get-VirtualDisk|Get-StorageJob
   

   ストレージの再調整ジョブが完了した場合、コマンドレットは出力を返しません。

復旧のシナリオ

次の復旧シナリオと推奨される軽減手順は、ノードを修復するために表されます。

シナリオの説明	緩和策	サポート対象?
ノードの修復操作に失敗しました。	操作を完了するには、エラーを調査します。 Repair-Server -Rerunを使用して、失敗した操作を再実行します。	はい
ノードの修復操作は部分的に成功しましたが、新しい操作システムのインストールから開始する必要がありました。	このシナリオでは、オーケストレーター (ライフサイクル マネージャーとも呼ばれます) によって、ナレッジ ストアが新しいノードで既に更新されています。 修復ノードのシナリオを使用します。	はい

トラブルシューティング

ノードの修復中に障害またはエラーが発生した場合は、ログファイルにその出力を記録できます。

• システムのデプロイ時に指定したドメイン ユーザー資格情報を使用してサインインします。 ログ ファイル内の問題をキャプチャします。

  Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
  

• 失敗した操作を再実行するには、次のコマンドレットを使用します。

  Repair-Server -Rerun
  

修復ノードの操作中に問題が発生し、Microsoft サポートからの支援が必要な場合は、「 Azure Local (プレビュー) の診断ログを収集する」 の手順に従って、診断ログを収集して Microsoft に送信できます。

修復中のノードから診断ログを提供する必要がある場合があります。 このノードから Send-DiagnosticData コマンドレットを実行していることを確認します。

次のステップ

ノードの追加方法について説明します。