トラブルシューティングの極意―達人に訊く問題解決のヒント

第1回 [サーバ・インフラ・ネットワーク編]設計・運用者が陥りやすい認識違いや思い込みに起因するトラブル

この記事を読むのに必要な時間:およそ 4 分

トラシュー事例(上級編)
「監視サーバをリニューアルしたらデータベースサーバとつながらなくなってしまった」

システム管理者が詳細を聞いてみると,サービスの状態を監視する監視サーバを入れ替えた途端,監視サーバから今までアクセスできていたデータベース(以後DB)サーバへ接続しようとしてもタイムアウトしてつながらないとのことです。

まずDBサーバにログインし,データベースプロセスが起動しているかどうか確認しました。問題ありません。次に監視サーバとDBサーバとの疎通を確認するためDBサーバから新しい監視サーバへpingを実行すると正常にレスポンスが返ってきます。

OSのiptablesとデータベースのセキュリティフィルタで監視システムのIPアドレスがブロックされていないかどうかを確認すると,これも該当するIPアドレスからのアクセスはすべて許可されています。ネットワーク的疎通に問題があるようには思えません。

データベースのログをチェック

データベースのログを見ると,監視サーバからの接続要求を受け取ってはいますが,接続が確立されぬままタイムアウトでクローズしています。そこで,netstatで確認してみるとインターフェースにいくつものSYN_RECVセッションがありました。これは監視サーバからのSYN要求が正常に処理されておらず,OSレベルでもTCPセッションが確立できていないことを示しています。監視サーバからのSYN要求は届いているので,問題はDBサーバがSYN_ACKを返していないか,監視サーバがSYN_ACKに対するACKを返していないかのどちらかです。

そこで,tcpdumpを使ってDBサーバのネットワークインターフェースをパケットトレースすると,DBサーバは監視サーバのSYN要求にSYN_ACKを返していません。するとDBインスタンスか,OSのTCP/IPドライバのどちらかに問題があると考えられますが,監視サーバ以外のホストとは問題なくTCPセッションを確立できているので,DBにもOSにも問題があるとは思えません。監視サーバとの間に限ってTCPセッションが確立されないという不可思議な現象です。

問題を切り分けして原因を特定する

障害対応は暗礁に乗り上げてしまいましたが,このままにしておくわけにも行かないので,管理者は再び障害の切り分け作業を繰り返しました。DBサーバから監視サーバにpingをすると,問題なくレスポンスが返ってきます。念のため監視サーバのアカウントをもらい,監視サーバからDBサーバにpingを実行してみると,レスポンスが戻ってきません。つまりpingの送信方向によっては接続の疎通が取れない状態となっています。

問題を整理すると,

  • (1)DBサーバが監視サーバへSYN_ACKを返していない
  • (2)DBサーバから監視サーバへの疎通はあるが,逆方向の疎通はない

ということです。(1)の原因はわかりませんが,(2)の問題はサーバ間の経路が非対称となっていて,それが原因なのではないかと想像できます。DBサーバのネットワークインターフェースを「netstat -i」で確認するとプライマリとセカンダリという2つのインターフェースによってマルチホーム接続をしていました。そこでDBサーバのセカンダリインターフェースに対してtcpdumpを実行し,監視サーバから接続要求を出してみると,DBサーバはたしかにセカンダリインターフェースからSYN_ACKを返しています。しかし,監視サーバではそのSYN_ACKを受け取っていません。

SYN_ACKがネットワークの途中で消失しているのでしょうか? しかしそれはちょっと考えにくい現象です。そこで,監視サーバが接続されているスイッチポートをミラーし,別のサーバをミラーポートに接続して監視サーバのポートまでSYN_ACKが届いているかどうかを確認してみると,SYN_ACKはたしかに監視サーバのポートまで届いています。つまり,監視サーバはDBサーバからのSYN_ACKを受け取っても,OSのTCP/IPレイヤで破棄しているのです。

再び,DBサーバのインターフェースアドレスを確認すると,セカンダリインターフェースのIPセグメントは監視サーバのIPセグメントと同じアドレス空間でした。つまりサーバ間のネットワークは図1のような状態にあるわけです。

図1 非対称経路

図1 非対称経路

システム管理者は監視サーバをインストールした担当者に詳しく聞いたところ,監視サーバはDBサーバのプライマリインターフェースに紐付いたホスト名でサーバへの接続を行っているとのことです。

パケットの追跡

ここでパケットの流れを追跡してみましょう。監視サーバはDBサーバへの接続要求をsdb01というホスト名で行おうとしています。sdb01はhostsファイルで192.168.1.1/24であり,これはDBサーバのプライマリインターフェースのアドレスです。したがってsdb01への接続要求パケットは,監視サーバの192.168.2.2/24のインターフェースからデフォルトルータの192.168.2.254に対して送られ,ルータは受け取ったパケットを192.168.1.254インターフェースからDBサーバの192.168.1.1/24へ向けてパケットを転送します。DBサーバは受け取ったパケットを解釈してSYN_RECVモードになり,SYN_ACKを192.168.2.1/24のセカンダリインターフェースから監視サーバへ送り返します。なぜなら,監視サーバのIP セグメントはセカンダリと同じなので,プライマリではなくセカンダリから直接配送できるからです。しかし,監視サーバはそのセカンダリから送られたパケットを破棄しています。

OSアップデートの落とし穴

再び管理者は監視サーバ担当者にアップデートする前と後で何か変更したことはないかを尋ねると,アプリケーションをアップデートする前にサーバOSのメジャーバージョンを1つ上げているとのことです。ここで管理者の脳裏には,非対称経路におけるセキュリティ問題が浮かび上がりました。そこで管理者がOSのリリースノートを確認すると,新しいOSリリースでは非対称経路で送られてきたパケットをセキュリティ上の処置として破棄する,となっています。逆に古いOSリリースでは非対称経路パケットはデフォルトで受信するという仕様です。結局原因はネットワークのトポロジーとサーバ運用とがミスマッチであった(同セグメントリンクがあるにもかかわらず,ルータ経由のホスト名で接続していた)ことと,監視アプリケーションのインストールに伴い,OSもアップグレードしたことによるセキュリティ障害でした。

ネットワークのトポロジ設計と,サーバとアプリケーションの運用が,連携せずに別々に行うことによる障害はよく発生します。システム開発設計と運用設計と運用作業を別々のチームで別々に考えるのではなく,これらは「安定したサービスを継続して提供する」という同じ目的を実現するための同じチーム内における作業分担にすぎないという認識が必要なのかもしれません。

まとめ

トラブルシューティングは単に机上の理論や知識だけではなく,実際の環境で起こり得るさまざまな原因に対処するための経験や担当者間の情報伝達,チームワーク,コミュニケーション力など属人的要素が大きく影響します。筆者が主宰する学生を対象としたICTトラブルシューティングコンテストや,Webシステムのチューニング技術を競うISUCONなど,現実問題に対処するコンテストやセミナーなどに積極的に参加し,トラブルシューティング力を上げることを心がけたいものです。

Software Design

本誌最新号をチェック!
Software Design 2017年12月号

2017年11月18日発売
B5判/176ページ
定価(本体1,220円+税)

  • 第1特集
    ITエンジニアと数学
    数学プログラミング入門
  • 第2特集
    AIやディープラーニングで注目される
    気になるGPU超入門
  • 特別付録
    IIJ謹製「インターネット便利帳」

著者プロフィール

伊勢幸一(いせこういち)

さくらインターネット株式会社取締役。

室蘭工業大学卒,日立系設備会社,ベンチャー系SIerを経て1996年にスクウェア(現スクウェア・エニックス)に入社し,その後北米にてフルCGのハリウッド映画製作に参加。2000年以後PlayOnline/FF11プロジェクトに参画しシステムネットワークの統括を担う。2005年,ライブドアに入社。2012年データホテル(2014年テコラスに社名変更),2016年2月退社。2016年7月,さくらインターネット取締役に就任。弊誌にもサーバ・インフラ・ネットワーク等の寄稿多数。

バックナンバー

トラブルシューティングの極意―達人に訊く問題解決のヒント

バックナンバー一覧

コメント

コメントの記入