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

[アーティクル]
10/14/2024

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

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

注意事項

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

前提条件

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

重要

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

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

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

是正措置を特定する

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

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

トラブルシューティングの最初の手順は、多くの場合、デバイスまたはシステムを再起動することです。再起動すると、問題の原因となっている可能性のある一時的な障害やエラーをクリアするのに役立ちます。再起動しても問題が解決しない場合は、次の手順として、デバイスまたはシステムを再イメージ化してみてください。

再イメージ化しても問題が解決しない場合、最後の手順は、障害のあるハードウェアコンポーネントを交換することです。交換は、より抜本的な対策になる可能性がありますが、問題がハードウェアの故障に関連している場合は、必要になる可能性があります。

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

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

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

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

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

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

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

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

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

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

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

重要

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

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

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

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

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

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

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

まとめ

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

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

次の方法で共有