2008年12月アーカイブ

書き込みはこちら↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
http://www.axisnetworks.biz/cgi/mt41/

-----------------------------------------------------------
その他:社内ブログ
http://www.axisnetworks.biz/blog/

ログイン名axis
パスワードnetworks

SolarisにはIPMPという機能があります。通常、ネットワークに接続するインタフェースは1つのネットワークに対して1つですすが、IPMPでは1つのネットワークに対して複数のインタフェースを接続する事を可能にし、インタフェースやNIC、接続先とのパス障害などにも切れない構成を可能にする技術です。

そんなIPMPを担当システムのサーバで実装していますが、最近この設定上に問題が見つかって対応しております。他の現場でも利用している方・これから触れるがいるかも知れませんので、簡単にですが内容を紹介致します。

・代表的なIPMP構成例としては、次の2つ

  1.2つのI/Fを同一ネットワークに接続し、片方のI/Fを稼動系とし、もう片方はスタンバイとする。

  2.2つのI/Fを同一ネットワークに接続し、両方のI/Fとも利用(ロードバランス)する。

・IPMPによる障害検出は検査信号ベースで行われる。検査信号はICMPによるエコー応答で、 IPMPのデーモンによって決められたターゲットに対して送出して応答有無を判断し、特定の条件の下で障害と判断された場合にはパスが切り替えられる。

・検査信号を送出するためには検査用のIPアドレスが必要で、サブインタフェースとして割り当てる必要がある。ターゲットへのICMPは、この検査用IPアドレスを利用して実施される。

・IPMPを構成した場合、実I/FのIPアドレスは検査用IPアドレスでアクセス先となるIPアドレスはIPMPの代表IPとなる。(ifconfigなどで見た場合、アクセス先となるIPアドレスは実I/FのIPアドレスのように見えるが、障害時に待機系のI/Fへ移動する)

・検査用のターゲットは、接続先ネットワークと同一ネットワーク上にデフォルトルータやホストルーティングが存在する場合は、それらのホストがターゲットとして選定される。存在しない場合は、マルチキャスト224.0.0.1を送出してターゲットを選定する。

・Solaris10からはNIC自体が生きているかどうかを判断する事が可能となった。ただし、NICのドライバがサポートしている必要がある。

 

上記だけではなんだかよくわからないと思いますが一応参考情報としてあげておきました。

なお、システムでトラぶった内容は、ターゲットとして選定されていたデフォルトルータが保守作業で停止した影響でサーバの通信ができなくなってしまったとういう問題でした。このデフォルトルータはHSRPを構成しているので、なぜ保守作業で両系とも停止する必要があったのか?のほうが疑問でしたが、こまかく仕様から調べて行ってようやく原因が見つかりました。

現場でのトラブル事例その2 製品のバグでRSTパケットが送出される

 

担当システムでF5社のロードバランサーを扱っていますが、こいつの製品バグが発覚して影響を調べる対応がありました。そのバグは、TCPのWindowSizeが0のパケットをロードバランサーが送出した後にコネクションをクローズしようとすると、誤ったシーケンス番号のRSTパケットが送出されてしまう、という問題でした。

問題自体はシステムへの影響はないという結論で片付きましたが、この件の調査でTCPについての仕組みを改めて見直すよい機会となりました。フロー制御の話などは、さまざまなIT資格の中で出題される部分だったりしますが、いざトラブルに向き合って見ると、以外と頭に入っていないものです。RSTパケットなんかは完全に頭からなくなっていましたし。。。

TCPの仕様は、ネットワークに関与する業務では必ず必要になってくると思いますので、この記事を読んで自分もやばいかもと思った方は、是非基本的なことを見直してみて下さい。

・どんなシーケンスでやりとりされているのか。

・どんな種類のデータがヘッダとして含まれているのか。

・UDPとの違いは?

・TCPにする事によるメリットとデメリット

・TCPのデータ解析をするには?

前回掲載したSSLの件もそうですが、WireShark(旧Ethereal)などのパケットキャプチャツールを利用して見てみる(勉強する)事をお勧めします。

なお、とてもえらそうな事を書いていてますが、決して自分も全てを抑えている訳ではありませんので、ご了承下さい。

現場でのトラブル事例紹介 その1 SSL通信に関するトラブル

 

現在開発を担当しているシステムで、クライアント~Webサーバ間でSSLを利用している部分があります。クライアント側のAPを開発する部門(客先)から、SSLのクローズ要求(close_notify)をWebサーバへ送出してコネクションを閉じようとしているが、Webサーバー側から一向に要求が帰ってこないためコネクションが閉じられないというクレームがきました。

結果としては、RFCの仕様上、Webサーバからclose_notifyを応答しない事はあり得る事で、Webサーバ側の仕様で応答しないためどうしようもない問題という事がわかりました。

close_notifyって何?というレベルからの調査でしたので、SSLについて何も知らなかったんだなぁという事を実感させられました。皆さんはSSLについてはどのように理解されているでしょうか。

SSLは誰もが特に意識する事なく利用しているものだと思いますので、次の視点から一度調べてみる事をお勧め致します。

・SSLってどのレイヤのプロトコル?

・そもそも何のために利用するものなのか?

・SSLを実装するには何が必要なのか?

・SSLによる通信はどのようなシーケンスなのか?

・暗号化されるデータの範囲は?

・トラブル時の解析方法はどんなものがあるのか?

 

ちなみに、本件の問題ではコネクションがクローズされないという話を記載しておりますが、実際にはTCPのタイムアウトで強制的にコネクションはクローズされます。

このアーカイブについて

このページには、2008年12月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年11月です。

次のアーカイブは2009年1月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 4.1