관련링크

SDNネットワーク仮想化障害

SDN 参考リンク

: https://www.juniper.net/kr/kr/solutions/sdn/what-is-sdn/

現象

システム配達の構築中にソリューション障害が頻繁に受け取られる事例が発生し、原因分析に着手するようになりました。

表面的に露出される事項は、アプリケーションの通信不能による大量のログ、Tomcat/Mqtt/MariaDB/ElasticSearch/WhaTap Server Monitoring Agentのネットワーク切断現象が観測されていました。

モニタリング状況

サーバモニタリングで確認された直後は、モニタリングデータが受信されず、データの空白区間の発生が確認されました。

分析

表面的にはサーバーモニタリングエージェントの異常動作を疑うことがありますが、システムチェックの結果、ICMPプロトコルへの通信パケットの損失などが観測され、ネットワーク仮想化運営チームにこれを報告することになりました。

ただし、ネットワーク仮想化チームは関連する兆候を検出できないという回答を受けました。

アクション

問題の状況が解消されない状態が持続し、ネットワーク仮想化チームとの協議を進め、仮想化サーバーのイーサネットリセットとネットワーク仮想化帯域をシステムが安定して稼働している帯域に変更する作業が進められました。

これにより、すべての顧客システムが正規化され、運用を開始しました。

示唆点

モニタリングは、状況に関する情報を歪めることなく客観的に公開することができなければなりません。サーバーモニタリングエージェントの場合、OS上にインストールされるため、OS外で発生するインフラレベルの情報を取得できない制約があります。これらの制約にもかかわらず、システム全体の複数の機器に同時に発生する異常の兆候は、個々のサーバーのモニタリングにも現れる可能性があります。本ケースの場合、モニタリングの立場ではデータ欠落という結果として現れたケースとなります。

データの欠落を検出することで、インフラレベルの障害の兆候を検出するための用途にも活用できることが証明されたケースです。

Disk仕様変更

現象

その中で開発チームの課題管理ツールを運用するためのサーバーのリソース使用率が高く現れる現象が観測されました。

モニタリング状況

サーバーモニタリングのリソースボードを通じて、可用量に比べてDisk IOの高い機器の現状が露出されていました。

分析

表面にさらされた情報に基づいて、同じ機器で発生した障害履歴を調べたところ、次のような異常が発生したことが確認されました。

• 速度低下現象3回
• インデックスファイルの破損5回
• Disk fullログ1回

アクション

ディスクIO問題を解決するための最も簡単な代替手段として、高価な機器の導入とHDDをSSDで検討することを検討し、ディスク容量を自由に運用するための考慮も必要でした。TCOを考慮して高価な機器導入案は廃棄し、SSDは導入するが大容量で導入しにくい部分はNASスナップショットバックアップを活用することにして行ないました。

示唆点

サーバーモニタリングのリソースボードは、サーバー全体の状況情報を要約して提供します。CPU問題が存在するサーバーの台数と推移を同時に検出するためのメインチャートとOSモニタリングの主な要素別トップ5のリストを通じて、問題発生可能性の高い対象リソースを公開し、サーバーで発生した通知履歴を最新順に表示 しています。

モニタリング対象リソース規模が少ない状況では、サーバー単位の詳細情報を把握しやすい機能が必要となりますが、大規模なシステムを監視する必要がある場合には、重要な情報を簡潔にして課題中心に見るためのダッシュボードが必要になります。

このケースは、WhaTapのリソースボードを活用して、システムの主な問題を手間のかからないように検出した事例で見ることができます。

推奨仕様でスペックアップ

現象

お客様の環境へのソリューション構築後、ユーザーアクセス不可による障害分析および措置要請が受け付けられました。本お客様社環境には当初ソリューション構築時に提示した推奨仕様未達サーバーとして構築されたことがあります。

モニタリング状況

対処前のディスクモニタリングの詳細を確認した結果、DISK IOが100％に達する状況が継続的に観測され、Disk Read / Writeの発生による負荷状況が観測されました。

リソースボードで確認したCPU、Disk IO、メモリ使用率の状況は次のとおりです。

分析

本サイトに設置されたオンサイトバックアップソリューションを停止した状況とのDISK IO負荷差を確認することで、バックアップソリューションの実行中に現れた現象として確認されました。ただし、本現象は推奨仕様に満たない基準のサーバでシステムを構築することによるものと最終確認されました。

アクション

① バックアップを実行してDisk IOとCPUを過剰に使用する場合は、”ionice”コマンドを使用して優先順位を調整する方法を適用することもあります。 ionice 参考リンク: https://linux.die.net/man/1/ionice

② 推奨仕様に基づいてサーバーのSSD交換作業を行いました。また、先行(pro active)対応の一環として、推奨仕様に従ってCPU増設作業も進めました。その後の使用率は、CPU使用率とDisk IOが著しく低くなった結果として現れました。

示唆点

サーバー詳細モニタリングの詳細ビュー機能は、CPU、メモリ、ディスク、ネットワークのカテゴリ別に詳細な情報を提供します。各カテゴリーの詳細な指標の長期的な推移を確認することで、ユーザーはその後どのような措置を講じるべきかという客観的な根拠を築くことができます。

このケースは、Disk I/O 使用率に加えて、IOPS 観点とBps観点の Disk Read/Write 推移を通じて、特定の時点で実行されたプログラムが OS に与える影響を確認し、これに対する措置方案を設けた事例とみることができます。

お礼のことば

上記事例は、DouZone Bizonのユンホミン次長がDouZone Bizonに構築されたWhaTapモニタリングを通じて顧客にサービスを提供する過程で活用した資料を提供していただいて、作成しました。

貴重な文を提供してくださった、ユンホミン次長にお礼を申し上げます。