Azure Local バージョン 23H2 でノードを修復する

[アーティクル]
12/31/2024

適用対象: Azure Local 2311.2 以降

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

修復ノードについて

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

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

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

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

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

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

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

可能であれば、修復するノードをシャットダウンします。ノードの状態によっては、シャットダウンが不可能または必要な場合があります。
修復する必要があるノードを再イメージ化します。
修復ノード操作を実行します。 Azure Stack HCI オペレーティングシステム、ドライバー、ファームウェアは、修復操作の一環として更新されます。

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

サポートされるシナリオ

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

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

重要

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

回復性の設定

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

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

ハードウェア要件

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

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

ノードの置換

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

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

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

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

**記憶域スペースダイレクトで使用されているディスクには、適切なクリーニングが必要です。再フォーマットでは不十分です。 Clean ドライブをする方法を参照してください。

重要

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

コンポーネントの交換

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

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

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

前提条件

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

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

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

ノードを修復する

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

前提条件を確認してください。

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

Azure portal にAzure Stack HCI 管理者ロールのアクセス許可を使用してサインインします。
1. Azure Local インスタンスのデプロイに使用するリソースグループに移動します。リソースグループで、修復する障害のあるノードの Azure Arc マシンリソースを特定します。
2. Azure Arc マシンリソースで、[設定] [> ロック] [] に移動します。右側のウィンドウに、リソースロックが表示されます。
3. ロックを選択してから、ごみ箱アイコンを選択してロックを削除します。
4. Azure Arc マシンリソースの [概要] ページの右側のペインで、[削除] を選択します。このアクションでは、障害のあるマシンノードを削除する必要があります。
修復するノードにオペレーティングシステムと必要なドライバーをインストールします。 Azure Stack HCI オペレーティングシステムバージョン 23H2 のインストールの手順に従います。

Note

カスタムストレージ IP を使用して Azure Local インスタンスをデプロイした場合は、ノードの修復後に、ストレージネットワークアダプターに IP を手動で割り当てる必要があります。
ノードを Arc に登録します。 Arc を使用して登録し、アクセス許可を設定するの手順に従います。

Note

Arc に登録するには、既存のノードと同じパラメーターを使用する必要があります。たとえば、リソースグループ名、リージョン、サブスクリプション、テナントなどです。
修復されたノードに次のアクセス許可を割り当てます。
- Azure ローカルデバイス管理ロール
- Key Vault シークレットユーザーの詳細については、「ノードへのアクセス許可の割り当て」を参照してください。

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

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

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

システムのデプロイ時に指定したドメインユーザー資格情報を使用して、既にシステムのメンバーになっているノードにサインインします。次のコマンドを実行して、受信ノードを修復します。
```
$Cred = Get-Credential 
Repair-Server -Name "<Name of the new node>" -LocalAdminCredential $Cred
```
Note

ノード名は、 NetBIOS 名である必要があります。既定で LocalAdminCredential パラメーターは、Windows OS インストールによって作成される組み込みの管理者アカウントです。
Repair-Server コマンドによって出力される操作 ID を書き留めます。後でこれを使用して、 Repair-Server 操作の進行状況を監視します。

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

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

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

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

操作が完了すると、バックグラウンドストレージの再調整ジョブは引き続き実行されます。ストレージの再調整ジョブが完了するまで待ちます。このストレージの再調整ジョブの進行状況を確認するには、次のコマンドレットを使用します。
```
Get-VirtualDisk|Get-StorageJob
```
ストレージの再調整ジョブが完了した場合、コマンドレットは出力を返しません。

復旧のシナリオ

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

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

トラブルシューティング

ノードの修復中にエラーまたはエラーが発生した場合は、ログファイルにエラーの出力をキャプチャできます。

システムのデプロイ時に指定したドメインユーザー資格情報を使用してサインインします。ログファイル内の問題をキャプチャします。
```
Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
```
失敗した操作を再実行するには、次のコマンドレットを使用します。
```
Repair-Server -Rerun
```

次のステップ

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

次の方法で共有