DSAS開発者の部屋

keepalivedの設定ファイルは、以下のようなエントリをひたすら並べなくてはいけないので、規模が大きくなるほど可読性が落ちます。

virtual_server_group SITE1 {

  a.b.c.d 80

}



virtual_server group SITE1 {

  delay_loop 3

  lb_algo   wlc

  lb_kind   DR

  nat_mask  255.255.252.0

  protocol  TCP

  persistence_timeout 0

  real_server 192.168.8.1 80 {

    weight 1

    inhibit_on_failure

    HTTP_GET {

      url {

        path /s/health.jsp

        status_code 200

      }

      connect_port      80

      connect_timeout    5

      nb_get_retry       1

      delay_before_retry 2

  }

  real_server 192.168.8.2 80 {

    weight 1

    inhibit_on_failure

    HTTP_GET {

      url {

        path /s/health.jsp

        status_code 200

      }

      connect_port      80

      connect_timeout    5

      nb_get_retry       1

      delay_before_retry 2

  }

}

RealServerが10台以上もあるような大きなサイトだと、ひとつのサーバグループの設定だけでも1画面に収まり切らないほどの量になってしまうんです。こんな巨大な設定ファイルを人間が書き換えなければならないなんてとてもとても我慢できません。サイトを増やそうとしてどっかの設定をコピペしたままうっかり書き換え忘れるような事故が起きることは容易に想像がつきます。

DSASの特徴のひとつとして、「サーバの増減が容易である」というものがあります。
その実体が 「keepalived.confの編集」だと「どこが容易やねん！」という突っ込みが入ることは目に見えていますよね（笑

DSASでは、設定ファイルの編集ミスによる事故を防止するためと、管理者の負担を軽くするために、様々な工夫をしています。

続きを読む

keepalivedはLinuxで冗長構成を組む道具としてとても便利ですが、運用面に関する配慮に物足りなさを感じることがあります。例えばIncludeがないとかIncludeがないとかIncludeがないとか（笑）
naoyaの日記でnaoyaさんも悩んでいるようですが、設定ファイルをうまく保守する仕組みをどう作るかが導入する際の大きな鍵になると思います。今回は、DSASではどのようにして2台のkeepalivedを運用しているかを少しだけご紹介させて頂きたいと思います。

続きを読む

「こんなに簡単！ Linuxでロードバランサ」のシリーズでは、

こんなに簡単！ Linuxでロードバランサ (1) 〜 LVS + NATで負荷分散をしてみよう
こんなに簡単！ Linuxでロードバランサ (2) 〜 keepalivedでWebサーバのヘルスチェック
こんなに簡単！ Linuxでロードバランサ (3) 〜 VRRPでロードバランサを無停止にする

こんな流れでNATによる負荷分散システムを構築してきました。
今回はこれを DSR(Direct Server Return) 方式に変更してみます。

「DSRとはなんぞや？」という方は、

ロードバランサの運用.DSRって知ってますか?
L4スイッチはDSR構成にすべし

こちらでわかりやすく説明されていますので参考にしてみてください。

続きを読む

前回までで、

• 複数のWebサーバにロードバランスする
  

というところまではできました。

これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。

このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。

というわけで今回は冗長化のお話、

• リアルサーバのヘルスチェック
  

を紹介したいと思います。
続きを読む

DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。

安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね)

また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。

ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、

• なんか難しそう
  
• ちゃんと動くか不安
  
• 性能が出ないんじゃないか
  

等々の不安の声も聞きます。

そこでこれから数回に渡って、How toスタイルでLinuxでロードバランサを作ってみたいと思います。

今回は初回ということで、ごくごく基本的な

• 複数のWebサーバにロードバランスする
  

というところまでやってみたいと思います。

では、はじまりはじまり〜
続きを読む

DSASはいかにして可用性を高めているか、ちょっと紹介したいと思います。

今回は概略ということでざざざっと説明します。個別の構成についてはまた回を改めて紹介したいと思います。
続きを読む

前回の後半で、dot-qmailで実行したコマンドの終了コードによって、次の配送を行うかどうかを制御できると書きました。

今回は、この仕組みを活用した例を2つ紹介したいと思います。
続きを読む

前回に引き続き届いたメールの処理の仕方を解説します。

今回のテーマは、届いたメールをプログラムに処理させるにはどうすればよいか、です。
続きを読む

qmailではdot-qmailと呼ばれるファイルで届いたメールの処理を制御できます。典型的なdot-qmailファイルは、ユーザのホームディレクトリの下の~/.qmailや~/.qmail-XXXですね。

今回は、dot-qmailを使う上で知っておきたいことをTIPSを交えて紹介したいと思います。
続きを読む

レイヤを問わず (ethernet から HTTP や SMTP まで) 、ネットワーク絡みのトラブルシューティングや挙動の確認をするときにパケットの流れが見られると非常に有益です。

開眼すると「パケットの流れが目で見える」そうですが、私などはまだまだ修行が足りず裸眼では見えないので、tcpdump というツールを使って見ています。

tcpdump はその名前があまりよくないと私は思っていて、"tcp" だけでなく udp やICMP や ethernet フレームまで覗ける超強力ツールです。

というわけで tcpdump の簡単な説明を書いてみます。

tcpdumpについて

tcpdump は UNIX 系の OS で使えるツールなのですが、Windows 用にはWinDumpという CUI のツールがあり、tcpdump と同じように使えます。

GUI がお好みの方は、後でも紹介するEtherealがおすすめです。UNIX 系でも Windows でも使えます。

Ethereal には CUI 版の tethereal というのもあります。

ちなみに tcpdump のほかには sniffit というがあったり、Solaris には snoop というのがついてきたります。

あと、tcpdump を使うには root 権限が必要です。

まずはオプション

-i

パケットを拾うネットワークインターフェースをデバイス名 (Linux だと eth0 とか) で指定します。Linux の kernel 2.2 以上の場合は、"any" で全てのインターフェースのパケットをキャプチャできます。

windump の場合は少し違っていて、まず、windump -D で有効なデバイスの一覧を表示させて、キャプチャするデバイスを確認します。デバイスの指定は tcpdump と同じように -i オプションなのですが、windump -D で表示された番号か名前で指定します。名前は長いので番号で指定した方がよいでしょう。

-n

IP アドレスやポート番号を名前に変換せずに数値のまま表示します。このオプションを指定しないと、いちいち IP アドレスを DNS に問い合わせるので表示が遅くなります。

-x

パケットの中身を 16 進で表示してくれます。

-X

パケットの中身で ASCII で表示可能なものを ASCII で表示してくれます。

-s 長さ

-x や -X を指定した場合、パケットの先頭数十バイトだけが表示されますが、-s オプションでダンプ表示する長さを指定できます。ethernet 上でパケットダンプする際は -s 1600 で十分でしょう。

-e

ethernet フレームのヘッダを表示します。

典型的なオプションの組み合わせとしては、パケットの流れを追えればよいときは -n か -ne 、パケットの中身 (HTTP のリクエスト/レスポンスとか) まで見たいときは -nxXs 1600 といったところでしょうか。

こんなときどーする?

続いてよく使いそうなレシピ集です。

Debin GNU/Linux (sarge) の tcpdump (tcpdump-3.8.3+libpcap-0.8.3) での動作です。

HTTP を見たい

tcpdump -i eth0 -n tcp port 80

これで HTTP リクエストとレスポンスのパケットが見られます。

特定のホストとのやりとりだけ見たい場合は、

tcpdump -i eth0 -n host 210.253.244.195 and tcp port 80

のようにします。

ポート番号 (80) を変えれば、他のプロトコルにも適用できます。例えば、DNS のやり取りを見たい場合は、

tcpdump -i eth0 -nxXs 1600 port 53

で再帰問い合わせの様子を眺めたりできます。

TCP のハンドシェイクを見たい

TCP は 3way ハンドシェイクを経てコネクションが確立するわけですが、その流れをみてみましょう。

tcpdump -i eth0 -n host 10.10.0.2 and port 80

とした状態で、

telnet 10.10.0.2 80

してみると、

SYN パケットを相手に送って、        ↓ココの "S" が SYN

  IP 10.10.2.4.56708 > 10.10.0.2.80: S 3693760150:3693760150(0) win 5840 



SYN+ACK が返ってきて、              ↓ココの "S" と ココの "ack"↓

  IP 10.10.0.2.80 > 10.10.2.4.56708: S 3033576079:3033576079(0) ack 3693760151 win 5792 



最後に ACK を返している                ↓ココの "ack"

  IP 10.10.2.4.56708 > 10.10.0.2.80: . ack 1 win 1460 

のがわかります。

ネットワーク組んだのになぜか TCP が通らない場合は、こうやってどの段階までハンドシェイクが行われているか確認したりします。

icmp を見たい

  tcpdump -i eth0 -n icmp

or

  tcpdump -i eth0 -n ip proto \\icmp

arp を見たい

  tcpdump -i eth0 -n  arp

or

  tcpdump -i eth0 -n  ether proto \\arp

or

  tcpdump -i eth0 -ne arp

vrrp を見たい

このへんから古い tcpdump だとエラーになったりするかもしれません。

  tcpdump -i eth0 -n vrrp

or

  tcpdump -i eth0 -n ip proto \\vrrp

or

  tcpdump -i eth0 -n ip proto 112

マルチキャストを見たい

tcpdump -i eth0 -n ip multicast

tcpdump -i eth0 -n multicast だと、ether multicast つまり IPv4 のブロードキャストなどもダンプされちゃいます。

stp を見たい

tcpdump -i eth0 -n stp

IPv6を見たい

tcpdump -i eth0 -n ip6

ポートを限定するときは、"and"で条件を連結します。

tcpdump -i eth0 -n ip6 and port 80

やっぱり GUI が好き

冒頭でも紹介したEtherealがおすすめです。Windows でも使えます。

表示するフィルタのルールがメニューから選択できて必要なものだけ見られますし、ポート番号、プロトコル種別、MAC の OUI (メーカ固有番号) を名前で表示してくれたりもします。あと、パケットダンプを ethernet ヘッダ、IPヘッダなどでハイライトしてくれるのも見やすいですね。

Ethereal 単体でもパケットキャプチャはできますが、tcpdump でキャプチャしたデータを Ethereal で読み込んで見ることもできます。

例えば、

# tcpdump -i eth0 -n -s 1600 -w ~/test.dmp

で適当なころあいで ^C で tcpdump を終了して、できた test.dmp をEthereal で開きます。もちろん、tcpdump -w するときにフィルタルールを指定して、

# tcpdump -i eth0 -n -s 1600 -w ~/test.dmp port 80

などとすることもできます。

この方法は、遠隔のサーバで tcpdump した結果を、手元の PC でじっくり鑑賞するときなどに便利でしょう。

(ひ)