Azure Operator Nexus サーバーの問題のトラブルシューティング

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

この記事では、Azure Operator Nexus ベアメタルマシン (BMM) での再起動、再イメージ化、交換の各アクションを使用して、サーバーの問題をトラブルシューティングする方法について説明します。メンテナンス上の理由から、これらのアクションをサーバーで実行することが必要になる場合があります。これにより、特定の BMM が短時間中断されます。

これらの各アクションの完了に必要な時間は同程度です。再起動は最も高速ですが、置換には少し時間がかかります。 3 つのアクションはすべて、トラブルシューティングのためのシンプルで効率的な方法です。

注意事項

Microsoft サポート担当者と最初に相談することなく、管理サーバーに対してアクションを実行しないでください。これを行うと、Operator Nexus Cluster の整合性に影響する可能性があります。

前提条件

BMM アクションを確認して、本記事で参照されている機能について理解します。
次の情報を集めます。
- BMM の管理対象リソースグループの名前
- ライフサイクル管理操作を必要とする BMM の名前
- サブスクリプション ID

重要

Kubernetes コントロールプレーン (KCP) ノードに対する中断を伴うコマンド要求は、別の KCP ノードに対して既に実行されている別の中断を伴うアクションコマンドがある場合、または KCP 全体が使用できない場合は拒否されます。

再起動、再イメージ化、交換はすべて中断を伴うアクションと見なされます。

この確認が行われるのは、Nexus インスタンスの整合性を維持し、同時の中断を伴うアクションが原因で複数の KCP ノードが一度にダウンしないようにするためです。複数のノードがダウンすると、Kubernetes コントロールプレーンの正常なクォーラムのしきい値を満たさなくなります。

是正措置を特定する

BMM の障害のトラブルシューティングを行い、最善の是正措置を決定する場合は、使用可能なオプションを理解することが重要です。 BMM の再起動または再イメージ化は、問題を解決したり、既知の適切な状態にソフトウェアを復元したりするための効率的で効果的な方法です。サーバーで 1 つ以上のハードウェアコンポーネントに障害が発生した場合は、BMM を完全に交換する必要が生じている可能性があります。この記事では、3 つの各アクションのベストプラクティスについて概説します。

技術的な問題のトラブルシューティングには、体系的なアプローチが必要です。効果的な方法の 1 つは、最も影響の少ないソリューションから始めて、必要に応じて、より複雑で抜本的な対策を試す方法です。

トラブルシューティングの最初の手順は、デバイスまたはシステムを再起動することです。再起動すると、問題の原因となっている可能性のある一時的な障害やエラーをクリアするのに役立ちます。

再起動しても問題が解決しない場合は、次の手順として、デバイスまたはシステムを再イメージ化してみてください。

再イメージ化しても問題が解決しない場合、最後の手順は、障害のあるハードウェアコンポーネントを交換することです。交換はより重大な手段となりますが、問題がハードウェアの欠陥に起因する場合は必要になることがあります。

これらのトラブルシューティング方法は必ずしも効果的であるとは限らず、その他の要因には別のアプローチが必要になる場合があることに注意してください。

再起動アクションを使用したトラブルシューティング

BMM の再起動は、単純な API 呼び出しを使用してサーバーを再起動するプロセスです。このアクションは、ホスト上のテナント仮想マシンが応答しない場合や、応答が途中で停止している場合の問題のトラブルシューティングに役立ちます。

通常、再起動は問題を軽減するための開始点です。

次の Azure CLI コマンドによって、指定した bareMetalMachineName のpower-offされます。

az networkcloud baremetalmachine power-off \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

次の Azure CLI コマンドによって、指定した bareMetalMachineName のstartされます。

az networkcloud baremetalmachine start \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

次の Azure CLI コマンドによって、指定した bareMetalMachineName のrestartされます。

az networkcloud baremetalmachine restart \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

再イメージ化アクションを使用したトラブルシューティング

BMM の再イメージ化は、テナントデータに影響を与えずに OS ディスクにイメージを再配置するために使用するプロセスです。このアクションは、同じ識別子を持つクラスターに再び参加する手順を実行します。

再イメージ化アクションは、OS を既知の正常な動作状態に復元することで、問題のトラブルシューティングに役立ちます。再イメージ化によって解決できる一般的な原因としては、ホストの整合性の可能性、セキュリティ侵害の可能性、または確認済みの侵害、または "緊急の" 書き込みアクティビティなどからの回復があります。

再イメージ化アクションは、BMM の整合性を確保するにあたり運用上のリスクを最小限に抑えるベストプラクティスです。

ベストプラクティスとして、reimage コマンドを実行する前に、退避に "True" を指定した cordon コマンドを使用して BMM のワークロードがドレインされていることを確認します。

ワークロードが BMM で現在実行されているかどうかを確認するには、次のコマンドを実行します。

Virtual Machines の場合:

az networkcloud baremetalmachine show -n <nodeName> /
--resource-group <resourceGroup> /
--subscription <subscriptionID> | jq '.virtualMachinesAssociatedIds'

Nexus Kubernetes クラスターノードの場合: (Nexus Kubernetes クラスターへのログインが必要)

kubectl get nodes <resourceName> -ojson |jq '.metadata.labels."topology.kubernetes.io/baremetalmachine"'

次の Azure CLI コマンドによって、指定した bareMetalMachineName のcordonされます。

az networkcloud baremetalmachine cordon \
  --evacuate "True" \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

次の Azure CLI コマンドによって、指定した bareMetalMachineName のreimageされます。

az networkcloud baremetalmachine reimage \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

次の Azure CLI コマンドによって、指定した bareMetalMachineName のuncordonされます。

az networkcloud baremetalmachine uncordon \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

交換アクションを使用したトラブルシューティング

サーバーには、時間の経過と同時にフェールオーバーする可能性のある多くの物理コンポーネントが含まれています。どの物理的な修復で BMM 交換が必要なのか、およびいつ BMM 交換が推奨されるかを理解することが重要です。

OS イメージを配置する前に物理ホストの整合性を確保するために、ハードウェア検証プロセスが呼び出されます。再イメージ化アクションと同様に、交換中にテナントデータは変更されません。

重要

2024-07-01 GA API バージョン以降、BMM の交換中に RAID コントローラーがリセットされ、サーバーの仮想ディスクからすべてのデータがワイプされます。 BMM の交換中にトリガーされたベースボード管理コントローラー (BMC) 仮想ディスクのアラートは、その他の物理ディスクや RAID コントローラーのアラートがない限りは無視できます。

ベストプラクティスとして、最初に cordon コマンドを発行してワークロードのスケジュールからベアメタルマシンを排除してから、物理的な修復の前に BMM をシャットダウンします。

次の Azure CLI コマンドによって、指定した bareMetalMachineName のcordonされます。

az networkcloud baremetalmachine cordon \
  --evacuate "True" \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

物理ホットスワップ可能な電源装置の修復を実行する場合、BMM ホストは修復後も正常に機能し続けるので、交換アクションは必要ありません。

次の物理的な修復を実行する場合、交換アクションは、BMM を復旧するために必須ではありませんが推奨されます。

CPU
デュアルインラインメモリモジュール (DIMM)
換気扇
拡張ボードライザー
トランシーバー
イーサネットまたはファイバーケーブルの交換

次の物理的な修復を実行する場合は、BMM を復旧するために交換アクションが必要です。

バックプレーン
システムボード
SSD ディスク
PERC/RAID アダプター
Mellanox ネットワークインターフェイスカード (NIC)
Broadcom 埋め込み NIC

物理的な修復が完了したら、置換アクションを実行します。

次の Azure CLI コマンドによって、指定した bareMetalMachineName のreplaceされます。

az networkcloud baremetalmachine replace \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --bmc-credentials password=<IDRAC_PASSWORD> username=<IDRAC_USER> \
  --bmc-mac-address <IDRAC_MAC> \
  --boot-mac-address <PXE_MAC> \
  --machine-name <OS_HOSTNAME> \
  --serial-number <SERIAL_NUM> \
  --subscription <subscriptionID>

次の Azure CLI コマンドによって、指定した bareMetalMachineName の切断が解除されます。

az networkcloud baremetalmachine uncordon \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

まとめ

再起動、再イメージ化、および交換は、技術的な問題に対処するために使用できる効果的なトラブルシューティング方法です。ただし、抜本的な対策を試す前に、体系的なアプローチを採用し、他の要因を考慮することが重要です。 BMM アクションの詳細については、 BMM アクションの記事を参照してください。

さらに不明な点がある場合は、サポートにお問い合わせください。サポートプランの詳細については、Azure サポートプランに関するページを参照してください。

次の方法で共有