dsas

2012年07月06日

ログからは見えてこない高負荷サイトのボトルネック

はてなブックマークに登録

ちょうど1年前に「高負荷サイトのボトルネックを見つけるには」という記事を掲載していますが、この手のトラブルシューティングって結構大変で悩ましいですよね。はじめまして、新入りの@pandax381です。

ログからは見えてこないもの

「サイトの応答が遅い」という問題が発生した場合、その原因はどこにあるでしょうか。

  • Webアプリケーションの処理に時間が掛かっている
  • DBサーバに投げたクエリーの応答が遅い
  • サーバの処理能力を超えている

などなど、いくつもの可能性があります。通常、上に挙げているような問題は、アプリケーションやサーバのログを調査することで、原因を突き止めることができます。

一方で、こういったログの調査だけでは、その原因にたどり着くことができなかったり、相当な苦労が伴うケースもあります。

あるサイトのある日の出来事

つい先日のことですが、KLabの運営している某ソーシャルゲームにて、サイトが重くなるという問題が発生しました。具体的にはHTTPのタイムアウトが頻発していて、クライアントにエラーが返されてしまっているというものです

DSASでは、HTTPサーバがフロント側とバックエンド側の2段構成になっていて、バックエンド側のHTTPサーバが5秒以内に応答を返せない場合、フロント側のHTTPサーバがエラーを返す仕組みになっています。そのため、このケースで真っ先に疑われるのは、バックエンド側のHTTPサーバとそれに紐づくDBサーバやmemcachedサーバです。

各サーバのリソース状態を集約しているリソースモニタを見てみると、確かにバックエンド側のHTTPサーバのレスポンスタイムが大幅に悪化していることがわかりました。こうなると怪しいのはDBサーバです。アクセス集中によってDBサーバが高負荷状態になり、レスポンスに時間が掛かっている可能性があります。

ところが、DBサーバのリソースを確認しても負荷が掛かっているような様子はなく、レスポンスタイムにも問題ありませんでした。同様にmemcachedサーバを確認したところ、こちらもリソース使用率などに問題はありませんでした。

ここで疑いはアプリケーションレイヤからネットワークレイヤへと変わることになります・・・

早速パケットキャプチャ(使うツールは tcpdump ではなく、もちろん miruo です!)してみると、出るわ出るわ、バックエンド側のHTTPサーバからTCPのSYNセグメント再送が大量に発生していました。

SYNセグメントの再送が発生しているということは、TCPの接続に時間が掛かっているということになります。SYNセグメントの再送は、通常 3秒・6秒・12秒・・・という間隔で行われるため、1回目の再送をしてからすぐにSYN/ACKを受け取れればよいのですが、そうでなければ5秒を経過してしまい、フロント側のHTTPサーバから強制切断されてしまいます。

実際にネットワークを流れるパケットを確認して、ようやく原因に一歩近づきました。そして、パケットの情報から対向はmemcachedサーバということもわかりました。

しかし、memcachedサーバは先に確認して問題なかったはず・・・。念のためリソースモニタでもう一度memcachedサーバの状況を確認してみるものの、やはり問題はなさそう。CPUもほどんど使われていないし、トラフィックも100Mbps程度でまだまだ余裕があります。

っと、ここで妙な違和感が。トラフィックのグラフが奇麗に100Mbpsに張り付いているのです。ちなみに、各サーバのNICは全て1000BASE-Tのものが使われています。まさかと思い、memcachedサーバのNICの接続状況を確認するとリンクが100Mになっている・・なぜ?という思いを抱きながら更に調査を進めた結果、今回の問題の原因が判明しました。

memcachedサーバを接続しているスイッチが故障して、そのポートが100Mでリンクされてしまっていたのです。

結局、問題のスイッチを対処してこの問題は解消されましたが、ネットワーク絡みの問題は原因にたどり着くまでに手間が掛かって大変です。

もっと切り分けの手間を減らしたい

上記のようなケースでは、ネットワーク周りの情報、それもTCPレイヤで再送が発生しているかどうかの情報を早い段階で得ていれば、解決までの道のりはずっと容易だったと思います。

実際にはその情報だけでは意味を成さないこともあるでしょうが、その他の情報や起きている現象と照らし合わせて、問題の切り分けや原因を推測するには大いに役立つはずです。

というわけで作りました!

前置きが長くなりましたが、TCPレイヤで発生した再送を検出するプログラムを作りました。

 ・TCPセッションモニタ「tcpeek」

tcpeek(てぃーしーぴーく)は、TCPのセッション確立(3wayハンドシェイク)時に発生するエラーを監視・集計するネットワークモニタです。libpcapを用いたパケットキャプチャ型のプログラムで、tcpdumpなどと同様に監視したいホスト上で起動させるだけで簡単に使えます。

使い方は付属のREADMEを見てください。ちなみに、tcpeekを使うとこんなことができます。

  • エラー検出:RSTやICMPの応答を受け接続に失敗したりタイムアウトしたTCPセッションを集計できます
  • 再送検出:SYNおよびSYN/ACKセグメントの再送が発生したTCPセッションを集計できます
  • フィルタ:通信方向・IPアドレス・ポート番号の組合わせで複数のフィルタが指定でき、フィルタ毎に個別集計できます
  • データ出力:集計したデータをUNIXドメインソケット経由で出力します。スクリプトで扱いやすいJSON形式で出力します
  • gmetric経由でrrdを出力するためのスクリプト(tcpeekstat)が付属しています
  • プロミスキャスモードでも使えます
  • などなど

tcpeekを実行すると、標準エラーへTCPセッションの情報がリアルタイムで出力されます。

$ sudo ./tcpeek -i eth0
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
 TIME(s) |       TIMESTAMP       |      SRC IP:PORT            DST IP:PORT     |      RESULTS      | DUP SYN  DUP S/A
----------------------------------------------------------------------------------------------------------------------
   0.002 | 12-07-06 16:39:02.552 |   192.168.2.227:48967   192.168.2.202:80    |      success      |      0        0 
   0.002 | 12-07-06 16:39:02.559 |   192.168.2.227:48968   192.168.2.202:80    |      success      |      0        0 
   0.002 | 12-07-06 16:39:11.219 |   192.168.2.227:42031   192.168.2.202:443   |      success      |      0        0 
   0.002 | 12-07-06 16:39:11.273 |   192.168.2.227:48970   192.168.2.202:80    |      success      |      0        0 
   0.002 | 12-07-06 16:39:11.279 |   192.168.2.227:42033   192.168.2.202:443   |      success      |      0        0 
   0.002 | 12-07-06 16:39:11.309 |   192.168.2.227:48972   192.168.2.202:80    |      success      |      0        0 
   0.002 | 12-07-06 16:39:11.323 |   192.168.2.227:42035   192.168.2.202:443   |      success      |      0        0 
   0.001 | 12-07-06 16:39:11.354 |   192.168.2.227:42036   192.168.2.202:443   |      success      |      0        0 
   0.002 | 12-07-06 16:39:11.385 |   192.168.2.227:42037   192.168.2.202:443   |      success      |      0        0 
   0.001 | 12-07-06 16:39:36.254 |   192.168.2.228:62876   192.168.2.227:80    | failure (reject)  |      0        0 
   0.000 | 12-07-06 16:39:38.160 |   192.168.2.228:62877   192.168.2.227:80    | failure (reject)  |      0        0 
   0.000 | 12-07-06 16:39:44.689 |   192.168.2.227:56371   192.168.2.228:8080  | failure (reject)  |      0        0
  39.947 | 12-07-06 16:41:29.723 |   192.168.2.227:58376   192.168.2.207:8080  | failure (timeout) |      2        0 
項目説明
TIME(s)TCPセッションの確立(3wayハンドシェイク)に掛かった時間(秒)
TIMESTAMPTCPセッションが開始された時刻
SRC IP:PORTTCPセッションの始端(クライアント)のIPアドレスとポート番号
DST IP:PORT TCPセッションの終端(サーバ)のIPアドレスとポート番号
RESULTSTCPセッションの確立可否
DUP SYNSYNセグメントが再送された回数(再送が発生していなければ 0)
DUP S/ASYN/ACKセグメントが再送された回数(再送が発生していなければ 0)

出力したrrdを元に作成したグラフのイメージです

php

php

おまけ

実は、上で書いているトラブルが起きる前から「TCPの再送検知できると、こういうトラブル起きたときに早く気づけていいよね」という話が出ていました。tcpeekもその頃から作り出していて、ほぼ完成していたのですが、まだ試験中で、本番環境では動かしていなかったのです。そしてこのようなトラブルが実際に起り「tcpeekを動かしていればすぐにわかったのに!」ということになり、早々に本番環境へ投入される流れとなりそうです。


@pandax381
klab_gijutsu2 at 14:50|この記事のURLComments(2)TrackBack(0)
2011年12月22日

トラフィックが急増! ボトルネックを退治しよう〜 【設定編】

はてなブックマークに登録

KLab Advent Calendar 2011 「DSAS for Social を支える技術」 の16日目。最終日?です。 今日は、14日目の続きになります。前回は、ネットワーク通信において負荷分散機がボトルネックになっているのを解消するために、DSR構成をとるための設定項目をあげて、それぞれに関して説明したところで終わっていました。今日は具体的な設定について説明していきます。

DSR構成のレシピ

まずは、設定項目をおさらいしておきましょう。次の6つでした。
  1. LVS の負荷分散の設定をDSRに変更する(ipvs の設定)
  2. Webサーバが、DSRなリクエストパケットを扱えるようにする(iptables の設定)
  3. Webサーバを、outer VLAN に参加させる(L2 スイッチの設定)
  4. Webサーバが、outer VLAN において通信できるように設定する(VLAN 用インタフェースの追加)
  5. Webサーバにおいて、上位ルータへの通信経路を設定する(ルーティングと iptablesの設定)
  6. Webサーバが、上位ルータに対して応答パケットを送信できるように設定する(ARP エントリの設定)
それぞれの設定について、説明していきましょう。

LVS の負荷分散の設定をDSRに変更する

ipvs で負荷分散する場合、LVS マシンに到達したクライアントからのパケットを Webサーバへと転送する方法には、3種類あります。1つ目は LVS 上で NATして転送する方法、2つ目は届いた IPパケットをカプセル化して転送する方法、3つ目が DSRです。 ipvs の仮想サービスの設定で DSR を指定するには、は、ipvsadm コマンドで設定する場合でしたら --masquerading (-m)(= NAT)や --ipip (-i)(= カプセル化)の代わりに --gatewaying (-g) を指定します。 keepalived を使っているのでしたら、仮想サービスの設定で lb_kind オプションに DRを指定します。

Webサーバが、DSRなリクエストパケットを扱えるようにする

DSR 構成を採った場合、LVS から Webサーバに転送されてくるパケットは前回説明したように、送信先IPアドレスが LVSの仮想サービス用のアドレス(図では A.B.C.D)のままになっています。 packet

このパケットを、Webサーバの OSが受け取ったときに自分宛のパケットだと認識させるためには、追加の設定が必要になります。方法はいくつかありますが、DSAS for Social では Webサーバ上で NAT する方法を使っています。つまり、送信先IPアドレスが A.B.C.D であるパケットを受け採った場合、Webサーバ自身がそのパケットの送信先アドレスを自分のアドレス(ss.tt.uu.vv)に書き換えるのです。そうすれば、そのパケットは Webサーバの OSが自分宛のパケットだと理解して、Apacheなどのアプリケーションに渡してくれるようになります。

設定方法は、OSに依って変わりますが、Linux の場合、次のようにするのが簡単です。

 # iptables -t nat -A PREROUTING -p tcp --dport 80 -d A.B.C.D -j REDIRECT
これで、クライアントから LVSを経由して Webサーバに届いた宛先アドレス=A.B.C.Dなパケットが、Webサーバ自身で処理されるようになります。

Webサーバを、outer VLAN に参加させる

ここからは、Webサーバが直接上位ルータに対して応答パケットを渡すために必要となる設定になります。そのためには、まずは Webサーバが "outer VLAN" に参加しないと始まりません。その際 "inner VLAN" と "outer VLAN" が混ざらないように、どちらかの VLAN には tag VLAN として参加させる必要があります。DSAS for Social では、"outer VLAN" 側を、tag VLAN にして参加させています。

Webサーバを "outer VLAN" に属させるためには、L2 スイッチの設定が必要になります。どのような設定になるのかはスイッチによって変わってきますが、DSAS for Social で主に使っている hp社の Procurve シリーズでは、例えば次のようにします。

 # config 
 (config)# vlan 4
 (vlan-4)# tagged 10-20
これは、"outer VLAN" の VLAN番号が 4、Webサーバ(群)が接続されているポートのポート番号が 10番〜20番ポートの場合の例です。

Webサーバが、outer VLAN において通信できるように設定する

Webサーバが "outer VLAN" に対して通信するには、Webサーバ側でも追加設定が必要になってきます。というのも、先ほどのスイッチの設定において、 Webサーバは tag VLAN で "outer VLAN" に参加するようにしたので、Webサーバがスイッチと "outer VLAN" 向けのパケットをやりとりするときは、VLAN tag をつけてるようにしなければならないのです。Linux において tag VLAN を扱うためには、VLAN ID に対応した仮想的なネットワークインタフェース(NIC)を作成してやります。この仮想的な NIC は物理的な NIC にひもづけられます。仮想 NIC はどの物理 NIC に対してひもづけるかと言うと、当然ながら先ほどスイッチの設定で "outer VLAN" に参加させたポートに接続している NIC に対してになります。 NIC

Linux において、tag VLAN 用の仮想 NIC を使うためには、8021qドライバモジュールが必要となります。カーネルを手元でコンパイルする際にこのドライバを含めるには

CONFIG_VLAN_8021Q
CONFIG_VLAN_8021Q_GVRP
の2つのオプションを有効にしてください(モジュールにしても組み込みにしても、どちらでも構いません)。

物理NICに紐づいた tag VLAN 用の仮想 NIC を作成するには、vconfig コマンドを使います。

 # vconfig add eth0 4
 # ip link set eth0.4 up
これで、Webサーバが "outer VLAN" 上でパケットをやりとりする準備が整いました。tcpdump などで eth0.4 を観察すれば、broadcast パケットなどが流れる様子が観察できるはずです。

Webサーバにおいて、上位ルータへの通信経路を設定する

Web サーバが直接上位ルータとパケットをやりとりするための環境は整いました。しかしこれだけでは OS は Webサーバの応答パケットを上位ルータに渡してはくれません。ルーティングを設定する必要があります。そして、前回の要件であげたように、default gateway を変更すること無く、DSRしたいパケットだけ上位ルータに対してルーティングするように設定する必要があります。

これを実現するためには、Linux のポリシールーティング機能を使います。これは、様々な条件に基づいてルーティング設定を切り替える機能で、Linux の他の機能の例に漏れず非常に柔軟な設定をすることができます。今回は Netfilter の mangle テーブル上で DSRしたいパケットに対してマーキングを行い、そのマーキングしたパケットに対してのみ適用する DSR専用のルーティングテーブルを、通常のルーティングテーブルとは別に作成しすることで、DSRを実現します。

Netfilter の mangle テーブルと、ポリシールーティング機能を使うためには、それぞれカーネルの機能を有効にする必要があります。mangle テーブルを使うには、モジュールがすでにある場合は iptable_mangleモジュールを読み込みます(iptables コマンドで mangleテーブルを触れば自動的にロードされます)。無ければ CONFIG_IP_NF_MANGLEを有効にして、カーネルを作り直してください。ポリシールーティング機能はカーネルモジュールにはできず、組込みにしなければなりません。お使いのカーネルの config を見て、CONFIG_IP_MULTIPLE_TABLESy になっているか、確認してください。y になってなければ、カーネルを作り直す必要があります。 DSR

カーネルの機能を有効にしたら設定していきましょう。まずは、DSRしたいパケットに対してマーキングをします。

 # iptables -t mangle -A OUTPUT -s A.B.C.D -j MARK  --set-mark 4
-s オプションで DSRしたいパケット=ソースアドレスが A.B.C.D のものを指定します。そして -j MARK --set-mark 4 でマーキングを施します。最後の 4 は DSRしたいパケットにつける識別ID になります。この後に設定するポリシールーティングにおいて、どのパケットに対して DSR用のルーティングテーブルを適用するのかを、この IDを使って指定します。

ポリシールーティングのための設定は、次の様になります。

 # ip route add H.I.J.K/32 dev eth0.4 table 100
 # ip route add default via H.I.J.K table 100
 # ip rule add prio 100 fwmark 4 table 100
 # ip route add H.I.J.K/32 dev eth0.4
まず、デフォルトのルーティングテーブルとは別の、DSR用のルーティングテーブルを作成します。このテーブルの名前をここでは "100" にしています。最初の2行はこの "100" というルーティングテーブルに対して、ルーティング情報を追加しています。つまり、上位ルータ(アドレス=H.I.J.K)とは eth0.4 という NICを通じてやりとりできることを示し(1行目)、インターネットに対してパケットを送信するときは、その上位ルータを中継すればよいことを指定(2行目)します。

3行目は、先ほど Netfilter の mangle テーブルにて DSRしたいパケットに対してマーキングした 4というIDを手がかりにして(fwmark 4 の部分です)、新しく作った "100" というルーティングテーブルを参照するよう、指示しています。つまり、mangle テーブルで 4 という ID を付与されたパケットは、3行目の指示にしたがって、1,2行目で新しく作った特別なルーティングテーブルを参照して、行き先が決定されるようになります。

Webサーバが、上位ルータに対して応答パケットを送信できるように設定する

さて最後に、上位ルータと Webサーバがパケットをやりとりする上で必要な、ちょっとした設定を追加します。先ほどは、IP上での(L3的)上位ルータとのやりとりする経路の設定をしました。通常はこれだけで問題なく上位ルータと Webサーバはやりとりができるのですが、今回の設定例では Webサーバの VLAN インタフェースに IPアドレスを振らなかったため、ちょっとした小細工が必要になります。

どういうことかというと、上位ルータの MACアドレス=Ethrnetのアドレスが、このままでは Webサーバには分からないのです。通常は通信相手の MACアドレスは、 ARPプロトコルを使って自動的に取得されるのですが、Webサーバは上位ルータと直接通信するために必要な、同一のサブネットに属したIPアドレスを持っていないので、ARPプロトコルが使えないのです。しかたがないので、上位ルータの MAC アドレスは、人間が手動で与えてやることにします。やり方は、上位ルータの MACアドレスが hh:ii:jj:kk:ll:mm だとすれば

 # arp -s -i eth0.4 H.I.J.K hh:ii:jj:kk:ll:mm 
となります。

以上で、Webサーバが DSRするための設定が完成しました。これでもう負荷分散機がボトルネックになることはありません。

klab_gijutsu2 at 23:40|この記事のURLComments(0)TrackBack(0)
2011年12月20日

トラフィックが急増! ボトルネックを退治しよう〜

はてなブックマークに登録

KLab Advent Calendar 2011 「DSAS for Social を支える技術」 の14日目です。

このシリーズも、初めは専らアプリケーション寄りの話題でしたが、ここ二回ほどはインフラ寄りの話題でした。今日はさらに(OSIの7階層モデルにあてると)下寄りの話題になります…。できるだけ分かりやすく書くつもりですので、お付き合い頂ければと思います。

負荷分散機がボトルネック

さて、DSAS for Social ではいくつかのアプリケーションが動いているわけですが、では1つのアプリケーションがピーク時に使う帯域はどれくらいになるか、皆さん想像がつきますでしょうか。答えはもちろんアプリケーションによって全く変わるのですが、今まで記録した中での最大値は、2Gbps を越えました。これは、サーバに搭載されている NIC の能力を越えています。もちろん、1台の web サーバでこのトラフィックを全て捌いたわけじゃないのですが、実は DSAS の構成上、どうしてもこのトラフィックが集中する箇所があります。それは、負荷分散機の部分です。

なぜ負荷分散機がボトルネックになるのか

DSAS for Social では、負荷分散機に、Linux 上に実装された L4 負荷分散システムである、IPVS を使っています(以下、この IPVS が動作するマシンのことを、LVSマシンと呼びます)。そして LVS マシンは、DSAS for Social におけるルータの役割を兼用しています。つまりどういうことかというと、DSAS for Social における外部との相互通信は、全て LVS マシンを経由する、ということです。図で書くと、次のようになります。 L3-1

LVS マシンは、負荷分散機だからと言って、特別なマシンを使っているわけではありません。Webサーバと同じものを使っています。これは LVS マシンがこわれた場合、隣に並んでいる Webサーバを使って LVS マシンの代わりをさせることができるように、という考えに基づいてこうしています。ですので、LVS マシンに搭載されている NIC(Network Interface Card) も、普通の 1Gbps のものです。DSAS for Social 以前の DSAS では、LVS が捌かなければならない帯域が 1Gbps を越えることは無く問題にはなりませんでした。しかしながら冒頭にも書いたように、DSAS for Social では 1つのアプリケーションが 2Gbps の帯域を消費するケースも出てきます。そのため、LVS がネットワーク通信に置いてボトルネックになってしまいました。

ボトルネックを解消するには

このボトルネックを解消するには、いくつかの方法があります。例えば NIC をもっと広帯域のものに変える、あるいは複数の NIC を束ねて帯域を太くする、などです。しかし、いずれの方法でもハードウェア的な変更が必要となるため、LVS用マシンが特別なマシンとなり、故障時に web サーバを代わりに充てる、ということが手軽にできなくなってしまいます。ということで、ハードウェアを拡張すること無く、どうにかできる方法を考えてみました。

DSAS for Social における L2ネットワークは、どうなっているのか

さて先ほどの図は DSAS for Social の IP ネットワーク = L3 ネットワークの図でした。これがどのような Ethernet のネットワーク = L2 ネットワークの上に載っているかというと、次のようになっています。
L2-1
インターネットの回線=上位ルータ(データセンタが管理している)は、直接 LVS に接続せずに一旦 L2 スイッチに収容しています(これも、Webサーバを LVSマシンの代替機にし得るようにするための工夫の1つです)。このスイッチには Webサーバや DBサーバも接続されているため、内部のネットワークと外部のネットワークが混在しないように、VLANを使って分離しています。LVS は両方の VLAN に接続し、それぞれの間を IP レベル(L3レベル)で橋渡し(ルーティング)しています。

クライアントからの Webサーバに対する通信は、次のような経路を通ることになります。 L2-2
つまり、外部のネットワークから送られてくるパケットは、図にある outer のVLANを通って LVS に到達し、LVS が Web サーバへと渡します。Webサーバからの応答パケットは、この逆順をたどります。

この図を見ていると、何となく、Webサーバからの応答パケットが LVS を経由してクライアントへと送信されいていることが、無駄なように思えてきます。なぜわざわざ LVS を経由させているかというと、外部との通信が全て LVS を経由するこの形であれば、通信でトラブルが発生した場合でも、LVS 上で全ての状況を観察できるため、運用上都合がよいからです。

どうすれば、ボトルネックを解消できるか

しかしながら、どうしても LVSの部分が通信のボトルネックになってしまいます。ですので DSAS for Social では、トラフィックの多い一部のアプリケーションに関しては、次の図のように、Webサーバからの応答パケットが LVS を経由しないような通信経路に切り替えることにしました。いわゆる、DSR(Direct Server Return)構成というやつです。 L2-3

これでもまだクライアントからのリクエストパケットは、LVSを経由しているので、ここがボトルネックになるんじゃないかと思われるかもしれません。しかしながら Webアプリケーションにおいて、そのトラフィックのほとんどは Webサーバからの応答パケットによるものです。クライアントからのリクエストパケットに要する帯域は応答パケットのものに比べると微々たるものです。冒頭で紹介した最大 2Gbpsを記録したトラフィックも、応答パケットのものです。ですので、今回の問題はこの構成で解決できるのです。

解決策のまとめ

以上、長い前フリが終わったところで、要件をまとめておきましょう。

  1. ipvs の設定と Webサーバの動作を、DSR 構成にする
  2. HTTP リクエスト以外の通信に関しては、これまでどおり LVS を経由して通信する
2つ目の要件はどういうことかというと、例えば Webアプリケーションが外部のサーバへ問い合わせをするときなどには、これまでどおり LVSを経由して通信する、ということです。というのも、WebサーバはグローバルIPアドレスを持っていませんので、そのままでは外部のサーバと直接通信できないのです。そのためどこかで NATする必要があるのですが、これは LVSマシンのルータとしての役割の1つなので、どうしても LVSマシンを経由するようにしておく必要があります。

DSAS for Social におけるDSR構成の作り方

では要件が明確になったところで、次に設定するべき項目をあげていきましょう。

  1. LVS の負荷分散の設定をDSRに変更する(ipvs の設定)
  2. Webサーバが、DSRなリクエストパケットを扱えるようにする(iptables の設定)
  3. Webサーバを、outer VLAN に参加させる(L2 スイッチの設定)
  4. Webサーバが、outer VLAN において通信できるように設定する(VLAN 用インタフェースの追加)
  5. Webサーバにおいて、上位ルータへの通信経路を設定する(ルーティングと iptablesの設定)
  6. Webサーバが、上位ルータに対して応答パケットを送信できるように設定する(ARP エントリの設定)
となります。(この記事で説明する設定は、あくまで DSAS for Social の実状に合わせた設定になります。DSR構成をとる上で、設定方法はここで説明する方法だけではなく、他にもいろいろな方法が考えられます。ここで説明する方法はどちらかといえば特殊な設定方法になると思います。)

それぞれどういうことか、簡単に説明していきましょう。

DSR 構成をとるためには

まず DSR な負荷分散構成を採る場合、Webサーバに届くリクエストパケットは、負荷分散機などにおいて何も手を加えられてないものになります。どういうことかというと、(Webサーバに届いた)リクエストパケットに記述されている送信先IPアドレスは、いわゆる仮想サービス用のアドレスになります。つまり、LVS へとパケットが届けられたときに送信先アドレスとして使われたグローバルアドレスそのままです。これはWebサーバに割り振られた(プライベート)IPアドレスとは別物です。Webサーバはこのパケットを受け入れて、かつ、応答を返信する際は送信元アドレスとして同じグローバルアドレスを記述して送信しなければいけません。これを解決するのが (b) の設定になります。

(c) と (d) に関しては特に難しい問題は孕んでいません。ちょっと変わっている点は、(d) で作る VLAN 用のインタフェースに、IPアドレスを設定しないことくらいです。しかし、IPアドレスを振らずにすませるために1つ小細工が必要になります。それが (f) です。

(e) は、要件の 2 を実現するための設定です。今回 Webサーバのルーティングテーブルに設定するデフォルトゲートウェイのアドレスは、LVS のIPアドレスのまま変更しません。その上で DSR の応答パケットのみルーティングを切り替えて、上位ルータに渡すようにしたいのです。そのための小細工が必要になります。

さて、ではいよいよ設定です… といきたいところですが、紙面がつきました(笑)ので、続きは明日に…

klab_gijutsu2 at 23:30|この記事のURLComments(0)TrackBack(0)
2011年12月19日

DSAS環境でのDNS活用法2 〜tinydns-get活用術〜

はてなブックマークに登録

KLab Advent Calendar 2011 「DSAS for Social を支える技術」 の13日目です。

先週に引き続き、DSAS 環境での DNS 活用法を紹介します。

スクリプト中でのゾーン参照方法

DSAS で使用している各種スクリプト内で、DNS の情報を参照する際に使ってるコードを紹介します。

# 設定情報用のゾーン(.dsas)を検索
mzone () 
{ 
    R="$1";
    ( cd $INTERNALZONE 2> /dev/null;
    _zone TXT $R.dsas )
}

# 名前解決を行う
# tinydnsのゾーンファイルのコピーがあればtinydns-getを使用
# ゾーンファイルがなければDNS問い合わせを行う
_zone () 
{ 
    if [ -r data.cdb ]; then
        DNSCMD="_zonedjb";
    else
        DNSCMD="_zonedig";
    fi;
    if [ -z "$2" ]; then
        Q="A";
        R="$1";
    else
        Q="$1";
        R="$2";
    fi;
    $DNSCMD $Q $R
}

_zonedig () 
{
    dig +short $1 $2 | sed 's/^\"\(.*\)\"$/\1/'
}

# tinydns-getを使い、カレントディレクトリのdata.cdbを検索
_zonedjb () 
{ 
    tinydns-get $1 $2
}

mzone() と呼んでいる関数では、前回紹介した TXT レコードによる設定データを参照します。
この他に、通常の内部ホスト名の名前解決を行う pzone() や、そのグローバル版の gzone() 等を定義しています。
各サーバでは、起動スクリプト中でこれらの関数等を使い、設定ファイルを生成しています。

下記に抜粋したコードでは、この関数を使い、keepalived.conf の VRRP に関する設定を生成しています。

lan=$(mzone net.private)
lan=$(pzone lvs)/${lan#*/}
wan=$(mzone net.link)
wan=$(mzone lvs.link)/${wan#*/}
cat <<EOF
vrrp_instance VI {
  state BACKUP
  interface bond0
  garp_master_delay 5
  virtual_router_id $(mzone lvs.vrid)
  priority ${PRIO}
  nopreempt  y
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass ********
  }
  virtual_ipaddress {
    ${lan} dev bond0
    ${wan} dev bond0
  }
}
EOF

パラメータ部分を DNS に逃すことで、生成スクリプトの環境依存部分を極力減らせるほか、複数のスクリプトから参照している設定情報を1箇所で管理することができるようになります。

オフライン時の内部ゾーン参照

DSAS 環境では、多くの設定ファイルを同様の方法で起動時に生成しています。
ネットワークインタフェースはもちろん、resolv.confや、全サーバのローカルで動いているDNSキャッシュサーバの設定ファイルも起動時に生成しているため、これらの生成スクリプトは、ネットワークが使えない状態でも動作出来る必要があります。

ネットワーク設定の生成にネットワークアクセス(DNS参照)が必要という矛盾した状況ですが、とても単純な方法で解決しています。
そもそも DNS 上の情報は、それほど頻繁に更新されるものではないため、サーバの起動時にゾーンファイルを転送してローカルで検索を行い、起動が完了したら DNS の参照に切り替えてやればいいのです。

先ほど紹介した、検索用の関数でも、ローカルにゾーンファイルの一時コピー(data.cdb)が存在するかをキーに動作が切り替わるようになっています。
この方法では、ゾーンファイルの一時コピーを消し忘れると、いつまでも古い情報を参照してしまう恐れがあるので、起動処理の一番最後で必ずゾーンファイルを削除するようにします。

tinydns-getの使い方

tinydns-get はカレントディレクトリの data.cdb をゾーンファイルとして読み込むため、ゾーンファイルの置かれてるディレクトリに移動して、下記のように実行します。

$ tinydns-get A www.klab.jp
1 www.klab.jp:
189 bytes, 1+1+4+4 records, response, authoritative, noerror
query: 1 www.klab.jp
answer: www.klab.jp 86400 A 211.13.209.202
authority: klab.jp 259200 NS ns1.klab.org
authority: klab.jp 259200 NS ns2.klab.org
authority: klab.jp 259200 NS ns8.klab.org
authority: klab.jp 259200 NS ns9.klab.org
additional: ns1.klab.org 14400 A 61.195.64.249
additional: ns2.klab.org 14400 A 61.195.64.247
additional: ns8.klab.org 86400 A 211.13.207.96
additional: ns9.klab.org 86400 A 211.13.207.97

「answer:」の行がクエリの結果です。
tinydns-get では、dig のような「+short」オプションがなく、自分で出力を加工する必要がある上に、TXT レコードの処理に問題があります。

'test.dsas.jp:TEST
answer: test.dsas.jp 86400 16 \004TEST

'test.dsas.jp:TEST5678901234567890123456789TEST
answer: test.dsas.jp 86400 16 !TEST5678901234567890123456789TEST

'test.dsas.jp:TEST5678901234567890123456789012345678901234567890
              12345678901234567890123456789012345678901234567890
              123456789012345678901234567TEST
answer: test.dsas.jp 86400 16 \177TEST56789012345678901234567890
                              1234567890123456789012345678901234
                              5678901234567890123456789012345678
                              90123456789012345678901234567\004T
                              EST

上記は、上段がバイナリ変換前のゾーンファイルでのレコード、下段が tinydns-get コマンドを使って検索した結果を示します。
各レコードは、1桁目がレコードの種類(TXTレコードは「'」)、続いてコロン区切りでFQDNとレコードの値が続きます。
answer行の各カラムは、検索したFQDN、TTL、レコードのタイプ値(TXTは16)、レコードの値となっています。

ご覧のとおり、レコードの値に「\004」、「!」など、元のゾーンにない文字列が混ざってしまっています。

なんと tinydns-get は、TXT レコードに対応しておらず、data.cdb ファイルに格納されている 「1バイトの文字列長 + 最大127バイトのデータ値」の繰り返しによるデータ列をそのまま表示してしまっているのです。
データにより、「\xxx」や「!」など、表示され方に差があるのは、出力時に ASCII Printable であればそのまま、制御コードなどであれば8進数表記に変換して表示しているためです。

tinydns-get-support-txtrr.patch
tinydns-get-suppress-msgs.patch

上記のパッチを当てると、tinydns-get が TXT レコードに対応し、余分な文字列を出力しなくなります。
また、少々手荒に書いたパッチですが、2つ目のパッチを当てると、検索結果に関する余分な情報が出力されなくなり、スクリプト等で使いやすくなると思います。


#dSn
klab_gijutsu2 at 16:19|この記事のURLComments(0)TrackBack(0)
2011年12月16日

DSAS環境でのDNS活用法 〜ネットワーク設定の格納にDNSを使う〜

はてなブックマークに登録

KLab Advent Calendar 2011 「DSAS for Social を支える技術」 の12日目です。

昨日までの apache の話題からガラリとかわって DNS についてお話します。

DSAS 内では、サービスに用いるドメインに関する権威サーバのほかに、システム内部の各サーバのホスト名や DB、memcache などの役割に応じた名前を登録した内部向けドメインの権威サーバやキャッシュサーバを運用しています。
システム内に、内部向けの権威サーバや、キャッシュサーバを設置するのは、珍しい構成ではありませんが、DSAS では、内部向け DNS サーバに、システムの設定情報を一部格納しています。

今回は、DSAS 環境で DNS サーバに設定情報を格納している理由や運用方法を紹介します。

ネットブートと設定ファイルの動的生成

DNS の話題に入る前に、DSAS の特徴を 1 つ紹介します。

DSAS では、マスタとなる冗長化された1組のサーバ以外、全てのサーバはネットブートによって起動します。

マスタサーバには、ロードバランサ用・Webサーバ用・DBサーバ用等の役割のサーバを構成するファイル一式が圧縮されたアーカイブが置かれていて、これをOSイメージと呼んでいます。
PXEブートにより、カーネルと initramfs がロードされて起動処理が開始されると、マスタサーバから自分の役割に応じたOSイメージ等をダウンロードして、tmpfs に展開します。
この OS イメージは、さすがに個々のサーバごとに個別に用意するわけにはいかないため、機能毎の共通ファイルとなっています。

そこで問題となるのが、個々のサーバに個別のパラメータを記述する必要がある設定ファイル類の扱いです。
DB サーバの MySQL で使用する server-id、ロードバランサやmemcacheの冗長化に使っている VRRP のルータID 等の各種デーモンの設定ファイルはもちろん、自身のネットワークインタフェースに割り当てるIPアドレスすら、起動処理内で決定する必要があります。

DSAS では、これらの設定ファイル類は、いくつかのタネになる情報を元にして、起動スクリプト内で動的に生成する仕組みを導入しています。
各デーモンや、インタフェースの設定を行う rc スクリプトの前に、設定ファイルを生成するための rc スクリプトを実行するという方法です。

そして、設定ファイルを生成するためのタネ情報を仕込む場所の1つが DNS サーバなのです。

DNSに格納するパラメータの例

DSAS 環境で DNS に登録するパラメータの一例を紹介します。

主に、ネットワークの設定を生成するために必要な情報が中心になります。

パラメータを登録するドメインとして、とあるゾーンを定義して、下記のようにTXTレコードで値を登録しています。
なお、実際の DSAS 環境では、権威サーバの実装に tinydns を使用しているため、tinydns-data フォーマットで記述しています。

private          IN  TXT  "dsas.jp"
net.private      IN  TXT  "192.168.0.0/20"
global           IN  TXT  "example.klab.jp"
net.global       IN  TXT  "XXX.XXX.XXX.XXX/xx"

net.link         IN  TYT  "YYY.YYY.YYY.0/29"
lv1.link         IN  TYT  "YYY.YYY.YYY.4"
lv2.link         IN  TYT  "YYY.YYY.YYY.5"
lvs.link         IN  TYT  "YYY.YYY.YYY.6"
gw.link          IN  TYT  "YYY.YYY.YYY.3"

lv1.vlanid.link  IN  TXT  "1"
lv2.vlanid.link  IN  TXT  "1"
lvs.vrid.link    IN  TXT  "100"

private/global/net.private/net.globalは、それぞれ内部用・外部用のドメイン名、プライベートアドレス、サービス用グローバルIPアドレスのレンジになっています。

真ん中の *.link 系のレコードは、ロードバランサが自身のネットワーク設定を行うための情報です。
データセンタ側の上位ネットワークと DSAS をつなぐセグメントのアドレスや、その中で使用するIPアドレスなどが定義されています。
( lv1、lv2というのは、冗長化された2台のロードバランサを指し、lvs は VRRP で使用する仮想IPアドレスを指します)

VRRP のルータIDや、インタフェースに設定する VLAN I Dなども登録されているので、ロードバランサのインタフェース設定に必要な情報は、殆ど DNS 内の情報を編集するだけで調整できます。

このロードバランサを含め、ほとんどのサーバが起動時に DNS 上の情報を参照して、自身のネットワーク設定を行なっています。
すると、ネットワーク設定のために DNS を参照する必要があって、それにはネットワークが必要という、鶏が先か卵が先かという問題が発生してしまいます。
次週は、この問題を解決するための方法や、使用しているdjbdnsのツールを紹介したいと思います。


#dSn
klab_gijutsu2 at 18:29|この記事のURLComments(0)TrackBack(0)
2008年11月12日

まくおをFreeBSDやMacOSXでも動くようにしました

はてなブックマークに登録

先日公開したまくおさんですが、 Linux以外の環境では全然ビルドが通らないことに公開後に気がつきました。 気になって気になって夜も寝れなかったので(笑)、手元にあったFreeBSD7.0とMacOSX10.4でも動くようにしてみました。

また、specファイルと起動スクリプトを頂きました ので同梱しておきます。
これは、とても助かります!、ありがとうございます!>Naoyaさん

というわけで、今回は「LinuxではビルドできるけどFreeBSDではエラーになる点」をいくつか紹介したいと思います。

ftimegettimeofday に変更

何を血迷っていたのか、現在時刻を取得するためにftimeを使っている箇所がありました。 マニュアルにもきちんと「この関数は古いものである。使ってはならない。秒単位の時間で十分なら、 time(2) が利用できる。 gettimeofday(2) でマイクロ秒が得られる」って書いてありますね。

tzset 後のtimezone参照をやめて localtime を使うようにした

makuosan はベースディレクトリにchrootする機能があります(-c オプション)
また、makuosan のログはsyslog に出力していますが、chrootすると/etc/localtime が見えなくなるため、syslogに記録される 時間が9時間ほどタイムスリップしてしまいます。(たしかproftpdのchroot機能などでも似たような問題があったと思います)

しかし、chroot先に/etc/localtimeを勝手にコピーするわけにもいかな いので、環境変数の"TZ"に"JST-9"のような文字列で時差を設定します。すると、/etc/localtime がなくても日本標準時で ログが記録されるようになります。

問題は、環境変数の"TZ"に設定する文字列をどのように生成するかですが、それを以下のようなコードで実装していました。
extern char *tzname[2];
extern long timezone;

void settzenv()
{
  char TZ[256];
  tzset();
  sprintf(TZ,"%s%+ld",tzname[0],timezone);
  setenv("TZ",TZ,0);
}
tzset するだけで必要な値がグローバル変数に入るので便利だなーなんて軽く考えていましたが、FreeBSDでは同名の関数が あるのでエラーになってしまいます。

そのため、localtime 関数を使ってtm 構造体をセットし、tm_gmtoff メンバとtm_zone メンバを利用して文字列を生成するようにしました。

  time_t ttime;
  struct tm *t;
  char tz[256];
    
  time(&ttime);
  tzset();
  t = localtime(&ttime);
  sprintf(tz, "%s%+ld",   t->tm_zone, -(t->tm_gmtoff/3600));
  setenv("TZ", tz, 0);


おまけ: libcryptが必要な理由

最後に少しだけ、プロジェクトサイトに書いていなかったことを書いておきます。
(もちろん後で追記しますが(^^;

makuosanではファイルの同一性をチェックする機能でmd5を使っています。

 $ msync --check

また、ネットワークに流れるデータを暗号化するためにblowfishを使っています。

 $ echo himitsu > keyfile
 $ chmod 400 keyfile
 $ makuosan -b dokka -k keyfile
これらの機能は、opensslのライブラリを利用しているので、ビルドにはopensslの ヘッダファイルとライブラリが必要です。

klab_gijutsu2 at 12:50|この記事のURLComments(0)TrackBack(0)
2008年11月06日

DSASのファイル転送システムをオープンソースで公開します

はてなブックマークに登録

DSASのファイル転送システムを、オープンソースで公開します。
その名は、makuosan(まくおさん:通称「まくお」)っていいます。
名前は冗談っぽいですが、内容はわりと真面目です(^^;

Webサイトの運用に欠かせない作業のひとつに、「デプロイ」という作業があります。 これは、新しいプログラムやデータなどをWebサーバに設置して利用できるようにす ることを指していますが、サイトの規模が大きくなってWebサーバの台数が増えると、 それに比例してファイル転送にかかる時間も長くなっていきます。

一般的な話として、サイトの規模が大きくなるほど運用コストは増大しますが、 その要因のひとつとして「デプロイ時のファイル転送に時間がかかる」という 点がありました。そこで、できるだけ運用コストを抑える(作業者の負担を減 らす)ために、独自のファイル転送システムをこしらえてみました。

「まくお」は、マルチキャストを利用して、複数のサーバへ同時にディレクト リ構造を複製するファイル転送システムです。

【まくおの特徴】
転送時間がサーバ台数に依存しない
サーバが増えても、転送にかかる時間はほとんどかわりません。10台のサーバ に転送しても、20台のサーバに転送しても、ほとんど同じ時間で完了します。 ただし、転送時間は一番応答が遅いサーバの性能に引っ張られるので、同程度 のスペックのサーバで構築された環境で利用することが望ましいです。

すべてのサーバで同時にファイルが更新される
マルチキャストを使って全サーバへ同時にファイルを転送します。そのため、 「このサーバのファイルは更新されてるけど、あのサーバのファイルはまだ 更新されていない」といったことが起こりません。

面倒な設定は不要
「まくお」のメインプログラムは、全サーバにデーモンとして常駐させます。 それぞれのサーバに常駐している「まくお」は、互いの存在を確認しあうこ とで、自動的にネットワーク上のサーバ構成を把握します。サーバを増設も しくは撤去する際においても、既設サーバの設定を変更する必要はありません。

「まくお」は、DSASの都合に合わせて仕様を決めていたので、一見意味不明 とも思えるオプションがあったり、この手のソフトでは当り前に付いている はずの機能が未実装だったりもしています。しかし、これでも誰かの役に立 てるのではないかと思い、オープンソースとして公開することにしました。

「まくお」は、DSASを運用する上で長年の懸念であった「ファイル転送の悩 み」を解消するためにこしらえました。今回は、どのような事に悩んでいて、 どう解決しようとしたのかをお話ししながら、作り始めたきっかけなどを紹 介したいと思います。

※機能の詳細や具体的な使用例などはプロ ジェクトサイトを参照してください。


負荷分散環境におけるファイル転送の悩み

 何十台ものWebサーバを負荷分散環境で運用していると、コンテンツの更新 や追加をするために、大量のファイルを複数台のサーバへ、できるだけ速く転 送する必要がでてきます。以下のようなスクリプトで、1台づつ順番に転送す るのは簡単で確実ですが、これではサーバ台数に比例して転送にかかる時間も 増えていってしまいます。

#!/bin/sh
for i in host2 host3 host4; do
  rsync -aR /var/www/ $i:/
done
  +-------+ rsync  +-------+
  | host1 |------->| host2 |
  +-------+        +-------+

  +-------+ rsync  +-------+
  | host1 |------->| host3 |
  +-------+        +-------+

  +-------+ rsync  +-------+
  | host1 |------->| host4 |
  +-------+        +-------+

また、このスクリプトのように転送先ホスト名をハードコードしてしまうと、 サーバが増えたり減ったりして構成が変わってしまった場合に、スクリプト を書き換える必要がでてきます。

サーバが故障したり増設した際に、うっかり書き換えを忘れてしまうと「フ ァイルが転送されない!」という障害に直結してしまいます。これはあまり にも危険すぎます。

この問題は、「稼働中のサーバを管理する機構」と「並列にファイル転送す る機構」を構築し、これらを組み合わせることで解決できると思います。稼 働中のサーバ一覧を取得し、下図のような論理的なツリー構造を形成してか らファイルを転送すればよいのです。

                                  +-------+
                             +--->| host4 |
                  +-------+  |    +-------+
             +--->| host2 |--+
             |    +-------+  |    +-------+
             |               +--->| host5 |
  +-------+  |                    +-------+
  | host1 |--+
  +-------+  |                    +-------+
             |               +--->| host6 |
             |    +-------+  |    +-------+
             +--->| host3 |--+
                  +-------+  |    +-------+
                             +--->| host7 |
                                  +-------+

DSASの中には、実際にこのようにして全サーバのファイルを同期をしている システムがあります。この構成は、とても転送効率はよいのですが、システ ム構成や転送プログラムの処理が必要以上に複雑になってしまう点が悩まし いところです。その結果として、以下のような別の問題を抱えることになり ます。

  • 軽微な変更や機能追加をするだけでもかなりの労力が必要
  • 転送中に発生したエラーを拾うのが大変
  • 不具合が発生したときに挙動を追うのが結構大変
  • 動作検証が超面倒

速度を求めれば構成が複雑になり、シンプルにすると遅くなるというジレン マに陥ってしまいました。


DSASにおけるファイル転送のニーズ

DSASでファイルを転送するニーズは大きく分けて二種類あります。
まずひとつめは、サーバを増設したりHDDが故障したときなどの”システム 全体のミラーリング”です。これは、1対1の転送なのでrsyncが便利です。

ふたつめは、Webアプリケーションのデプロイや、素材ファイルのアップロ ードなどの”コンテンツの転送”です。運用フェーズでは、こちらのニーズ の方が圧倒的に多いです。冒頭でお話した長年の懸念とは、このニーズを満 たすことを指しています。今までは、この作業にrsyncを利用したスクリプト を使っていました。(今でも使ってますが(^^;

このスクリプトは、htdocsやwebapps以下のファイルをrsyncで全サーバに転 送するものです。コマンド一発で簡単に転送できて便利ですが、いろいろと 問題もありました。

サイトの規模やWebアプリケーションが肥大化するとともに、ファイル構成 やアーキテクチャが複雑になってきたため、サイト毎に特殊なニーズがでて くるようになりました。たとえば、、、

  • あるタイミングで一部のファイルだけ転送したい
  • このファイルは転送したいけどこれはしたくない
  • 定期的に指定した部分だけを転送したい
  • Webアプリケーションの動作と連動して転送したい
  • あるイベントをトリガにして転送を開始したい
  • できるかぎりリアルタイムに転送したい
  • などなど

これまで使っていたスクリプトは、簡単にファイルを転送できる反面、きめ 細かなニーズに対応することが困難でした。そのため、効率よくファイルを 転送できるようにするためには、それぞれのニーズに見合ったスクリプトを 書く必要があります。しかし、実際に「rsync で全サーバに効率よくファイ ルを転送するスクリプト」を書くのはとても大変な作業です。

そこで、「全サーバに効率よくファイルを転送する」という機能をDSASの内 部に組み込んでしまい、「転送したいファイルやディレクトリのみを指定す るインターフェイス」をアプリケーション開発者に提供できれば、きめ細か なニーズに対して、簡単で柔軟に対応できるようになるのではないかと考え ました。これが「まくお」を作り始めたきっかけです。


「まくお」の仕組み

最後に、「まくお」がどのようにしてファイルを転送しているのかを簡単に 紹介します。
「まくお」では、複数のサーバへ同時にファイル転送をするために、マルチ キャストを利用しています。送信元のサーバは、マルチキャストアドレスに 対してファイルの内容を送出します。転送先のサーバはそれを拾ってローカ ルファイルを生成します。

        +-------+                +-------+ 
        | host2 |<-----+-------->| host4 |
        +-------+      |         +-------+
                       |
+-------+              |         +-------+
| HOST1 |------->(Multicast)---->| host5 |
+-------+        224.0.0.108     +-------+
                       |
                       |
         +-------+     |         +-------+
         | host3 |<----+-------->| host6 |
         +-------+               +-------+

送信元のサーバは、ひとつのファイルを何度も送りなおす必要がありません。 転送先のサーバが何台あったとしても、一度の送信ですべてのサーバへ転送 することができます。

とはいっても実際は、取りこぼしたパケットを補間するために再送処理が必 要になるので、同じデータが何度か繰り返し流れることもあります。その場 合でもファイルをまるごと再送するわけではなく、取りこぼしたパケットの みを再送するので、すべてのサーバへ一台づつ転送するよりも、ネットワー ク全体を流れるデータ量や転送時間は少なくて済んでいます。

今後の予定

現在の「まくお」には、以下のような問題(というか未実装の機能)があります。

  • 転送先のファイルを消せない(rsync --delete相当の機能がない)
  • SysVinit向けの、起動/停止スクリプトを作っていない
  • マニュアルが不十分(><)
  • ファイルの転送効率をもっと上げられるはず

これらは、今後のバージョンアップで随時対応していきたいと思います。

klab_gijutsu2 at 11:30|この記事のURLComments(0)TrackBack(1)
2008年08月11日

サーバ/インフラTech Meetingの報告+資料を公開します

はてなブックマークに登録

先週の金曜日に行われたサーバ/インフラ Tech Meetingの資料を公開します。

DSASのこれから

はてなの伊藤さん、田中さんの発表資料も既に公開されています。

また、当日の動画もニコニコ動画にアップされています。cojiさんありがとうございました!

これらの資料、動画や、当日の会場の写真などは、まとめて技評さんのサイトにもアップされると思いますので、そちらもチェックしてみてください。


スピーカ同士で発表内容の打ち合わせは全くしていなかったのですが、4人とも、自身の体験談に基づいた話の上で、「インフラは楽しい!」「インフラはクリエイティブ!」といったポイントへと繋がる話でびっくりしました。

ブログの感想エントリなども読ませてもらっているのですが、 「わくわくしてきた」 「いい刺激をうけた」 といった前向きなコメントがちらほらあり、「あぁ書籍が出せてよかったな、イベントができてよかったな」と思っています。

こんな感じで、インフラ好きが話し合う土台としてこの本を使ってもらえたらなと思ってますので、これからもよろしくお願いします。

それから、年内には次のKLab勉強会も予定しています。内容はまだ未定ですが、いつもなぜかインフラ好きが集まる傾向がありますので、興味ある方はぜひ、参加してみてください。

[24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用
作者: 安井真伸, 横川和哉, ひろせまさあき, 伊藤直也, 田中慎司, 勝見祐己
出版社/メーカー: 技術評論社
発売日: 2008/08/07
メディア: 単行本(ソフトカバー)

klab_gijutsu2 at 16:57|この記事のURLComments(0)TrackBack(2)
2008年07月22日

『サーバ/インフラを支える技術』出版と発売記念Tech Talk開催のお知らせ

はてなブックマークに登録

KLab(株)のDSASチームと(株)はてなさんのインフラチームとで書いていた本が、とうとう8/8(ごろに)発売されます!

[24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用

作者: 安井真伸, 横川和哉, ひろせまさあき, 伊藤直也, 田中慎司, 勝見祐己
出版社/メーカー: 技術評論社
発売日: 2008/08/07
メディア: 単行本(ソフトカバー)

また、発売を記念して、(株)技術評論社様の主催で、Tech Talk イベントを開催します。
詳しくは、開催のアナウンス

をご覧ください。

もちろんスピーカはこの本の執筆者陣で、インフラにまつわるお話をする予定です。

このようなサーバ/インフラ関係のTech Talkイベントは比較的少なく、苦労話やノウハウの共有もしたいなーと思っているので、休憩時間やQ&Aの時間などに気軽に声をかけてもらえるとうれしいです。イベント会場でお会いするのを楽しみに待っています!

このエントリの末尾に、長いですが書籍の目次を掲載します。この目次を眺めてもらえば、どんなことが書いてある本なのかはつかめるんじゃないかと思います。

続きを読む
klab_gijutsu2 at 08:00|この記事のURLComments(0)TrackBack(5)
2007年10月09日

特集記事『Linuxロードバランサ構築・運用ノウハウ』を公開します

はてなブックマークに登録

Linuxロードバランサ構築・運用ノウハウ』を公開します!

これはWEB+DB PRESS Vol.37の特集記事としてDSASチームが執筆したもので、技術評論社様の許可を得て今回公開するはこびとなりました。

一口でいうと、「Linux+IPVS+keepalivedを使って、冗長構成(Active/Backup)のロードバランサを作るまで」の解説記事で、

  1. サーバ負荷分散一般についてのはなし
  2. Linuxでロードバランサを作ってみる
  3. ロードバランサを冗長化

といった構成になっています。

みなさんがLinuxロードバランサを導入・構築・運用する際の一助になれば、DSASチームとしてもうれしい限りですので、是非、ご覧になってください!


klab_gijutsu2 at 00:07|この記事のURLComments(10)TrackBack(2)
2007年07月27日

今更ながら… DSASとは何か?

はてなブックマークに登録

とあるメールで,「DSAS とは何か?」という事を書く機会があったのですが,そういえばこのブログではそういう基本的な事を述べた記事がなかった,ということに気づいたので,こちらにも転載することにしました.
以下,メールに書いた文を,blog 向けに編集したものです.

続きを読む
klab_gijutsu2 at 12:06|この記事のURLComments(0)TrackBack(0)
Blog内検索
Archives
このブログについて
DSASとは、KLab が構築し運用しているコンテンツサービス用のLinuxベースのインフラです。現在5ヶ所のデータセンタにて構築し、運用していますが、我々はDSASをより使いやすく、より安全に、そしてより省力で運用できることを目指して、日々改良に勤しんでいます。
このブログでは、そんな DSAS で使っている技術の紹介や、実験してみた結果の報告、トラブルに巻き込まれた時の経験談など、広く深く、色々な話題を織りまぜて紹介していきたいと思います。
最新コメント