Share via

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

  • [アーティクル]

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

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

修復サーバーについて

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

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

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

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

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

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

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

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

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

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

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

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

注意

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

サポートされるシナリオ

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

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

重要

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

回復性の設定

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

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

ハードウェア要件

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

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

サーバーの置き換え

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

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

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

サーバー ディスク サポートされています
新しいサーバー 新しいディスク Yes
新しいサーバー 現在のディスク Yes
現在のサーバー (再イメージ化) 現在のディスクの再フォーマット * いいえ
現在のサーバー (再イメージ化) 新しいディスク Yes
現在のサーバー (再イメージ化) 現在のディスク Yes

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

重要

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

コンポーネントの交換

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

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

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

前提条件

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

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

サーバーを修復する

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

前提条件を確認していることを確認 します。

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

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

    注意

    必要な Windows ロールもインストールする必要があります。

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

    注意

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

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

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

     Update-AuthenticationToken

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

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

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

注意

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

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

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

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

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

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

    Get-VirtualDisk|Get-StorageJob

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

復旧のシナリオ

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

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

トラブルシューティング

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

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

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

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

    Repair-Server -Rerun

次の手順

サーバーを追加する方法の詳細については、こちらを参照してください。