Xenを実行している仮想化ホストで制御する必要があるものの短いリスト。 本格的な読書には向いていませんが、Xenで作業する人には役立ちます。 追加と説明を歓迎します。
注は、ホスト自体を監視することに関するものであり、ホストで実行されている仮想マシンまたはそのサービスに関するものではありません。
それでは、簡単なものから始めましょう。
- ホストへのping、アクセシビリティ管理ssh。 コメントは不要です。
- メッセージipmi / ilo別の管理システム。 MCE(プロセッサ、マザーボードのハードウェアの誤動作)、メモリエラー、電源の故障、ファン、ケースを開けるいたずらな遊び心のあるペンなどをキャッチします。 ホスト上のipmitool selリストも同様に行いますが、外部IPMIインターフェイスで監視することをお勧めします。
- 状態dom0(通常):
- LA(その過剰は問題を示し、通常のdom0 laでは0.1を超えてはならず、2〜3以上-問題)
- CPUの使用。 監視は通常、不快であり(測定間隔が必要なため)、ほとんどの場合、zabbix / cacti / muninを介して実装されます
- ログのあるセクションの空き領域。 たとえば、XenServerは、場所が/ varでなくなると「ビープ音」モードになり、デフォルトで4GBのすべてがそこにあります
- 空きメモリ(dom0自体)。 dom0からのアプリケーションがスワップに移動すると、すべての仮想マシンに問題が発生します
- 開いているネットワーク接続の数。 値自体は実験的に選択されますが、過度にならないようにしてください
- RAIDアレイとハードドライブの状態。 ホスト上のディスクの障害または劣化は、たとえそれらがルート(つまり、仮想マシンのデータのみ)に「のみ」使用される場合でも、抑制/ var /ログが神経を損なう可能性があります。 ハードウェアRAIDの場合は特に注意が必要です。ベンダーユーティリティを見つけて使用する必要があります。 ソフトウェアraidは、メール用に構成されている場合、mdadmを完全に処理します。 ドライブ自体は、smartmontoolsまたはベンダーの何かによって制御されます。
- Xenの状態:
- ドメインの数-特定の数を超えると、次の仮想マシンを起動するときに問題が発生します。 ループ、tapdiskのマイナー番号、lvm、iscsiなどが使い果たされています。
- 忘れられたドメインの存在。 一部のツールスタックは、ステータスが「s」(シャットダウン)のドメインを忘れる場合があります。このようなドメインがドメインのリストで1〜3秒以上ハングした場合、何かが間違っています。
- ゾンビドメインの存在。 ドメインにdフラグとsフラグが同時に1秒以上ある場合、ホストは非常に不良です。dom0とドメインの間に共有メモリページがあり、ハイパーバイザーに与えられていません。つまり、ドメインを強制終了できません。 私の練習では、ほとんどの場合「不良」なタップディスクでした。
- ハイパーバイザーの空きメモリ。 シャドウページとホストからのライブマイグレーションを使用できるようにするには、ハイパーバイザー用に少なくとも100〜200 MBのメモリを予約する必要があります。 このタスクは「ロードバランシング」とは異なることに注意してください。これは、ホスト自体の事前の緊急事態であるため、独立して監視する必要があるためです。
- uuid 00000000-0000-0000-0000-000000000000(ドメイン初期化エラー)またはdeadbeaf-dead-beaf- ...で始まるuuidを持つドメインのホスト(1秒以上)の存在(xapiの失敗の兆候。あなたがそれを必要とします))。
- Xenaのコンソールリングに無関係な(新しい)メッセージが存在する。 通常、何かの存在は、ゲストとの問題または乱交を示します(たとえば、MSRを記録しようとする)
- サービスステータスdom0
- ntpdと参照の不一致。 0.2秒を超える不一致(ネットワークの品質に応じて選択する数値)は問題を示しており、クロールする時間もあるゲストに直接影響する可能性があります。
- arpテーブルのサイズ。 大きすぎると、SANのパフォーマンスが大幅に低下し、ARPの再要求が常に発生する可能性があります。つまり、ゲストディスクの遅延です。
- 管理/ sanに使用されるネットワークインターフェイスの負荷。 特定の制限を超えている場合(SANの場合-30〜40%を超える場合)、これはブレーキの潜在的な原因を示しています。 約10〜20Gです。ギガビットでは、インターフェースが何らかの形で定期的にそのギガビットにつまずくからです。
- すべてのSSL証明書の関連性。 「ああ、サーバーAPIは利用できません」とは異なり、このチェックでは「警告、1か月以内に証明書が破損します」と言うことができます。
- キュー深度(xapi)をサポートするツールスタックの場合-このキューのサイズ。 通常、30〜50行のタスクは問題の兆候です。 同時に、このようなチェックは、スレーブとマスターの接続性もチェックします-つまり 検証はスレーブで行うのが最適です。
- dmesgの監視。 ほとんどの場合、これはgrepによって行われ、ホストではなく外部で行われます。 syslogとnetconsoleを介してログを送信してdmesgを送信することは必須です。 Grepの監視はしっかりしているようには見えませんが、figメッセージは、問題をアーキテクチャ的に完全に抑制するよりも優れています。
- カーネルトレース。 理由は異なります-ほとんどの場合、OOM、IOによるプラグインなどです。 ゲストdmesgのトレースの外観は、問題の明確な兆候です
- セグメンテーション障害。 dom0内にはユーザープログラムは存在できず、クラッシュしたプログラムは障害または将来の悪用です。
- フリップ(リンクダウン/リンクアップ)ネットワークインターフェイスの症状。 インターフェイスがフラップし始めた場合は、緊急に動作を停止し、誰が責任を負うかを見つける必要があります。 フロップは、誰にも検出されないまま長時間続くことがあり、この時点で問題は進行します。 ケーブルが詰まっているか、SFPまたはネットワークカードが死んでいる可能性があります。
- NFS / ISCSIタイムアウト、マルチパスパススイッチング(またはSANで使用するもの)に関するメッセージ。 タイムアウトの一部は「ソフト」です。つまり、ゲストに到達しません。 しかし、あなたはそれらについて知る必要があります。 メッセージの正確なタイプは実験的に検出されます(テストストレージを消去して見ます)
- ストレージ設定の監視。 この領域は「Xen」をはるかに超えているため、xenのメンテナンスに関連する最小限の名前のみを示します(つまり、ディスクモニタリング、アレイステータス、インターコネクト、SASループクロージャなどについては説明しません)。
- エクスポートされた衛星/ボリューム/カタログの遅延監視。 合理的なライン(5〜10ミリ秒)を設定して監視します-95%パーセンタイル(つまり、リクエストの5%)がこのラインに沿って忍び寄るとすぐに-これは将来の問題の明確な兆候
- IOPSの監視。 最大値がマスターのビジネスであるかどうかを監視するが、最小値を監視する必要があることは明白です。 25k IOPSのストレージシステムの負荷が200 IOPSに低下した場合、その理由を明確に見つける必要があります。
- ホストからのアクティブな接続の数。 技術的な作業やホストの入力/出力が動作しない状態でこの値を変更することは、問題の兆候です(おそらく、ホストはまだ疑っていません)
- 処分場。 シンプロビジョニング、オーバーサブスクリプション、重複排除、圧縮、およびスペースを節約するためのその他のテクノロジーを備えたゲームは、約束の履行をフォローアップしないと害を及ぼす可能性があります。