Azure Stack HCI バージョン 23H2 でサーバーを修復する

  • [アーティクル]

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

この記事では、Azure Stack HCI クラスター上のサーバーを修復する方法について説明します。

修復サーバーについて

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

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

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

サーバー ワークフローを修復する

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

修復サーバープロセスを示す図。

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

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

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

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

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

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

サポートされるシナリオ

サーバーを修復すると、サーバーが再イメージ化され、以前の名前と構成でクラスターに戻されます。

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

重要

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

回復性の設定

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

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

ハードウェア要件

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

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

サーバーの置き換え

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

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

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

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

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

重要

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

コンポーネントの交換

Azure Stack HCI クラスターでは、ホット スワップ不可能なコンポーネントには次のものが含まれます。

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

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

前提条件

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

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

サーバーを修復する

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

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

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

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

    Note

    クラスターでストレージ専用のネットワーク ATC インテントを使用していて、カスタム ストレージ IP を使用している場合は、Repair-Server 操作を実行する前に、ストレージ ネットワーク アダプターで IP を構成する必要があります。 クラスターでストレージとその他のトラフィックの種類 (コンピューティングや管理など) に共有ネットワーク ATC インテントを使用している場合は、サーバーの修復後に、ストレージ仮想ネットワーク アダプターで IP を手動で構成する必要があります。

  2. サーバーを Arc に登録します。 Arc を使用して登録し、アクセス許可を設定するの手順に従います。

    Note

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

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

同じ Azure Stack HCI クラスターのメンバーである別のサーバーで、次の手順に従います。

  1. サーバーを追加する前に、必ず更新された認証トークンを取得してください。 次のコマンドを実行します。

     Update-AuthenticationToken

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

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

    Note

    サーバー名は、 NetBIOS 名である必要があります。

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

Note

カスタム ストレージ IP を使用して Azure Stack HCI クラスターをデプロイした場合は、サーバーの修復後に、ストレージ ネットワーク アダプターに IP を手動で割り当てる必要があります。

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

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

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

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

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

    Get-VirtualDisk|Get-StorageJob

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

復旧のシナリオ

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

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

トラブルシューティング

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

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

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

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

    Repair-Server -Rerun

次のステップ

詳細については、 サーバーの追加を参照してください。