AKIBA.AWS 第6回 基礎編 基礎編 - VPNとDirectConnect -にて発表の資料です。 AWSのハードウェアVPN接続について、BPGの基礎からVPC、VGWのルーティング仕様まで網羅的に解説します。
![EC2でkeepalived+LVS(DSR)](https://cdn-ak-scissors.b.st-hatena.com/image/square/ddc663979ce0f9136059a95ed69aa79bd01f3d40/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fec2keepalivedlvsdsr-130517102641-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
今までずっと LVS DSR で、リアルサーバでは iptables に、次のようなルールを追加した REDIRECT していましたが、iptables のオーバーヘッドが気になったので、lo:0 を定義するように変更してみました。 *nat : PREROUTING ACCEPT [0:0] : OUTPUT ACCEPT [0:0] : POSTROUTING ACCEPT [0:0] -A PREROUTING -d VIP -j REDIRECT COMMIT 1.lo:0 を定義する $ sudo vi /etc/sysconfig/network-scripts/ifcfg-lo:0 DEVICE=lo:0 IPADDR=VIP NETMASK=255.255.255.255 ONBOOT=yes 2. lo:0 を起動する $ sudo ifup lo:0 3. sysctl
構成 [appサーバ] -> [lvs] -> [MySQL]群 DRでMySQLのスレーブ群にロードバランス appサーバはDBコネクションのプーリング、永続化をしている 問題の現象 DBサーバ上ではmysqldへのコネクションが存在するのに、appサーバ上ではコネクションが存在しない。(netstat調べ) →無用なコネクションが残留するせいで、MySQLのmax_connectionsに達してしまう。 原因 MySQLの世界の無通信時のコネクションのタイムアウトはデフォルトで 28800秒 (8時間)。一方、IPVSの世界の無通信時のタイムアウトはESTABLISHEDなコネクションで900秒 (15分)。 # ipvsadm -Ln --timeout Timeout (tcp tcpfin udp): 900 120 300なので、DBコネクションの永続化等でコネクションを張りっ
みなさんどうもこんにちは。CTOの馬場です。 最近DELLのサーバ(R410)で、CentOS6.3を使ってLVS+keepalivedなロードバランサを構築したら 見事にハマったりしたので記念ポスト。 ちょっと長いので、一番のドハマリだけ見たい方は最後の「通信速度が著しく遅い件」だけでも見ていただけるとよろしいかと思います。かしこ。 eth0、eth1がない件 いやー。びびった。まじでびびった。 インターフェース名がem1、em2になってます。きもい。 このあたりを参考に対応します。 Getting back to using eth0 in Fedora 15 /boot/grub/grub.conf に biosdevname=0 追記 /etc/udev/rules.d/70-persistent-net.rules の NAME を変更 /etc/sysconfig/networ
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 サーバでこの
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか つっこみどころが満載スギなのは脇においておいて、金をかけないなら、DNSラウンドロビンじゃなくて、せめて、件の記事でも紹介されている Apache 2.2のmod_proxy_balancer か、Apache 2.2じゃなくても使えるreverse proxy系の実装たち、 POUND mod_backhand Perlbal を使うべきでしょう。 んで、「L7ロードバランサ(要はreverse proxy)なんていらねっす。セッション? んなのmemcachedでシェアすりゃいいんじゃん。その方がスケールアウトしやすいしー」という向きには、LinuxでL4のロードバランサするのをオススメでします。まともなL4ロードバランサが手に入るのに、金銭的コストはゼロですってよ、オクサン! Linux Virtual Serve
『Linuxロードバランサ構築・運用ノウハウ』を公開します! これはWEB+DB PRESS Vol.37の特集記事としてDSASチームが執筆したもので、技術評論社様の許可を得て今回公開するはこびとなりました。 一口でいうと、「Linux+IPVS+keepalivedを使って、冗長構成(Active/Backup)のロードバランサを作るまで」の解説記事で、 サーバ負荷分散一般についてのはなし Linuxでロードバランサを作ってみる ロードバランサを冗長化 といった構成になっています。 みなさんがLinuxロードバランサを導入・構築・運用する際の一助になれば、DSASチームとしてもうれしい限りですので、是非、ご覧になってください! 第1章 サーバ負荷分散概論 特集のはじめに なぜサーバ負荷分散をするのか? サーバ負荷分散の実現方法 ロードバランサのいる構成 ロードバランサはなにを元に分散す
ライブドアテクノロジーセミナーに行ってきましたよ。 id:naoyaさんは LVS++という話 でしたが、自分も 1年ほど前に、某サイトの負荷分散を LVS + Ultra Monkey (heartbeat + ldrectord) でやったので、社内 Wiki に書いてたメモを晒しておきます。 # 今なら heartbeat じゃなくて keepalived が普通なのかも知れず、情報が古めの可能性はあります LVS の Director を 2台で HA 兼 Real Server (httpd) + Real Server 1台 (httpd) DB Server 1台 という構成。 LVS と Real Server を別にするのはちょっとコスト的にもったいなかったため、Director と Real Server を同一マシンに乗せる形に。http://ultramonkey.
DSASはいかにして可用性を高めているか、ちょっと紹介したいと思います。 今回は概略ということでざざざっと説明します。個別の構成についてはまた回を改めて紹介したいと思います。 │ │ ┌┴┐ ┌┴┐ │ │ │ │ISPの上位ルータ └┬┘ └┬┘ │ │ 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 責任分解点 │ │ ┌┴┐ ┌┴┐ │ ├─[ lb(active) ]─┤ │ │ ├─[ lb(backup) ]─┤ │ │ │ │ │ │L2├─[ Web ]─┤L2│ │SW├─[ Web ]─┤SW│ │ ├─[ Web ]─┤ │ │ │ │ │ │ ├─[ SMTP ]─┤ │ │ ├─[ SMTP ]─┤ │ │ │ │ │ │ ├─[ D B ]─┤ │ │ ├─[ D B ]─┤ │ │ │ │ │ │ ├─[ NFS ]─┤ │ │ ├─[ NFS ]─┤ │ │ │ │ │
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く