先日、何人かのユーザと議論をしていたときに、Stratus VS シリーズのシステムがネットワークアダプタに関してどのような状況で自宅に電話をかけるのかを理解していないことが明らかになりました。この誤解により、システムはネットワーク接続を失うことになった。彼らが理解していないのであれば、私も理解していない人がいると思うので、このブログでは、ネットワークアダプタに関してシステムがどのような場合に帰宅するのかを説明することにしたいと思います。
簡単な答えは、ネットワークアダプタが故障したことを検出すると、システムが家に電話をかけてくるということです。灰色の領域は、何が失敗したのかを意味します。アダプタが壊れたり、システムによって壊れたりした場合は、一連の診断が実行され、アダプタが合格した場合はサービスに戻されます。短すぎる時間間隔で何度も破損した場合、アダプタは MTBF (Mean Time Between Failure) のしきい値を超えてしまい、サービスが停止したままになります。このような場合は、アダプタに関してシステムがホームコールを行います。診断を実行して失敗した場合、アダプタはサービスを停止したままとなり、システムは帰宅を求めます。
アクティブ・ネットワーク・アダプタとスタンバイ・ネットワーク・アダプタの間で渡される sdlmux テスト・メッセージがパートナー・アダプタで受信できなかった場合、システムはスタンバイ・カードを壊してテストし、サービスに復帰させます。テストメッセージをブロックした原因が何であれ解決されない場合、カードが MTBF しきい値を超えるまでこのパターンが繰り返され、システムは帰宅します。ここで、問題はアダプタではなくネットワークにあるかもしれないことに注意してください。
リンクが落ちて、1 つのアダプタがネットワークに接続されなくなった場合、システムは必要に応じてネットワークアダプタをフェイルオーバーし、それ以外は何もしません。自宅に電話をかけてくることはありません。この理由は、リンクが落ちる理由が多すぎて、そのほとんどすべてがアダプタの外部にあるからです。22 年前の VOS リリース 8.0 では、オリジナルの Stratus Ethernet の実装は、リンクが失われたときに帰宅するようになっていた。それは、彼らがスイッチを再起動したり、ケーブルを削除したことを知っていたので、我々はそれらを呼び戻したときにちょうど人々を悩ませている、開かれている多くの問題をもたらした。その時に、リンクが失われたことは障害とはみなされないと判断されました。なお、前項で述べた sdlmux のテストメッセージは、両方のアダプタがネットワークへのリンクを持っていないと送信されません。
では、冒頭で述べたユーザーはどうなったのでしょうか?約1ヶ月前、彼らは1つのアダプタへのリンクを失いました。システムには接続性に問題がなかったので、彼らはこのことに気づいていませんでした。それから数日前にもう一つのリンクを失い、その時点でネットワークから外れていました。このシナリオは、システム上のアダプタがネットワークに接続されていることを確認するために、システム上のアダプタを監視することが重要である理由を示しています。定期的に監視することで、最初のアダプタのリンクの問題を特定し、2 番目のアダプタのリンクの問題が発生する前に修正することができました。
コマンドマクロ monitor_sdlmux_adapter_status (図1) は、定期的にすべての sdlmux パートナリングされたアダプタを監視する。選択されたユーザに25行目のメッセージを送信し、syserr_logにエントリを追加する。syserr_log エントリはリンクが最初に失われたときに作成されますが、monitor_sdlmux_adapter_status マクロはチェックするたびにエントリを追加し、見られる可能性を高めます (図 2)。このマクロは、sdlmux デバイスのリストを取得するために analyze_system を呼び出すので、-privileged を yes に設定して起動されたプロセスとして実行する必要があります。
マクロはまた、アダプタの1つが"DOWN"であるかどうかをチェックし、それがドロップリンクを報告するのと同じ方法でそれを報告します。システムは家に電話をかけるべきでしたが、チェックを追加するのは簡単で、余分な通知は痛くないと考えました。
25行目とsyserr_logメッセージは、monitor_sdlmux_adapter_statusマクロを実行している人のホームディレクトリにあるcheck_adaptersファイルを参照しています。このファイルは、システム上のすべてのsdlmuxパートナーシップに対して実行されたdlmux_admin sdlmux_statusコマンドの出力から構成されています(図3)。問題のある特定のアダプタを特定するために、このファイルを確認する必要があります。
このマクロは sdlmux と連携しているアダプタのみを監視します。パートナーになっていないアダプタの問題はすぐに明らかになるため、追加の監視は不要である。Stratus は、すべてのネットワークアダプタを sdlmux とパートナーにすることを推奨する。
& monitor_sdlmux_adapter_status begins here |
図 1 - monitor_sdlmux_adapter_status コマンドマクロ
d >system>syserr_log.10-05-24 -match check_adapters %phx_vos#m16_mas>system>syserr_log.10-05-24 10-05-25 08:27:29 mst . . . . . . . . . |
図 2 - syserr_log メッセージ
d check_adapters
%phx_vos#m16_mas>SysAdmin>Noah_Davids>check_adapters 10-05-24 19:57:43 mst
************************************************** --------------- 10-05-24.19:56:47 ---------------- **************************************************
************************************************** Group Name: #sdlmuxA.m16.10-5-0.11-5-0 Device Name: %phx_vos#enetA.m16.11-5-0 Adapter State: ACTIVE UP Partner: %phx_vos#enetA.m16.10-5-0 Partner State: UP (network connection lost)
************************************************** Group Name: #sdlmuxA.m16.10-5-1.11-5-1 Device Name: %phx_vos#enetA.m16.10-5-1 Adapter State: ACTIVE UP Partner: %phx_vos#enetA.m16.11-5-1 Partner State: UP
************************************************** Group Name: #sdlmux.m16.11-2 Device Name: %phx_vos#enet.m16.11.11-2 Adapter State: ACTIVE UP Partner: %phx_vos#enet.m16.10.11-2 Partner State: UP
************************************************** Group Name: #sdlmux.m16.11-3 Device Name: %phx_vos#enet.m16.10.11-3 Adapter State: ACTIVE UP Partner: %phx_vos#enet.m16.11.11-3 Partner State: UP
ready 19:57:43 |
図 3 - #enetA.m16.10-5-0 がリンクを失ったことを示す check_adapters ファイルの出力