9. 動作確認 基本情報 ● クライアント - curl ○ dagon - 10.0.214.215 ● keepalived+LVS ○ cthulhu(MASTER) - 10.0.214.216 ○ hastur(BACKUP) - 10.0.214.217 ● バックエンド - httpd ○ nyar - 10.0.214.218 ○ yog - 10.0.214.219 ● VIP ○ 192.168.200.16 10. 動作確認 事前準備 ● LVS・バックエンドのENIのSource/Dest Check をdisabledにする ● バックエンドでiptablesの設定 sudo iptables -t nat -A PREROUTING -d 192.168.200.16 -j REDIRECT 12. 動作確認 - keepalived.cnf(cthulhu)
KLab Advent Calendar 2011 「DSAS for Social を支える技術」 の16日目。最終日?です。 今日は、14日目の続きになります。前回は、ネットワーク通信において負荷分散機がボトルネックになっているのを解消するために、DSR構成をとるための設定項目をあげて、それぞれに関して説明したところで終わっていました。今日は具体的な設定について説明していきます。 DSR構成のレシピ まずは、設定項目をおさらいしておきましょう。次の6つでした。 LVS の負荷分散の設定をDSRに変更する(ipvs の設定) Webサーバが、DSRなリクエストパケットを扱えるようにする(iptables の設定) Webサーバを、outer VLAN に参加させる(L2 スイッチの設定) Webサーバが、outer VLAN において通信できるように設定する(VLAN 用インタフェースの
KLab Advent Calendar 2011 「DSAS for Social を支える技術」 の14日目です。 このシリーズも、初めは専らアプリケーション寄りの話題でしたが、ここ二回ほどはインフラ寄りの話題でした。今日はさらに(OSIの7階層モデルにあてると)下寄りの話題になります…。できるだけ分かりやすく書くつもりですので、お付き合い頂ければと思います。 負荷分散機がボトルネック さて、DSAS for Social ではいくつかのアプリケーションが動いているわけですが、では1つのアプリケーションがピーク時に使う帯域はどれくらいになるか、皆さん想像がつきますでしょうか。答えはもちろんアプリケーションによって全く変わるのですが、今まで記録した中での最大値は、2Gbps を越えました。これは、サーバに搭載されている NIC の能力を越えています。もちろん、1台の web サーバでこの
大規模サイトではL4スイッチをDSR(Direct Server Return)構成で組むことはもはや常識です。しかし国内には大規模サイトが少ないためかDSR構成についての情報が不足しているのが現状です。L4スイッチを扱っているベンダーさんもDSR構成でネットワークを構築したという例をほとんど聞かないとのことです。そこで今回はDSR構成の紹介とメリット＆デメリットをご紹介します。 【一般的な構成とDSR構成の違い】 一般的な構成ではスイッチとサーバの間にL4スイッチを挟み込む構成を取ります。それに対してDSR構成ではスイッチに直接L4スイッチを接続します。 これを踏まえてパケットの流れを見てみましょう。一般的な構成では行きのパケットがL4スイッチを流れサーバに到達し、帰りのパケットもL4スイッチを流れていきます。それに対してDSR構成では行きのパケットはL4スイッチを通りますが、帰りのパケ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く