タグ

DSRに関するdelegateのブックマーク (6)

  • Colorkrew Blog

    ※1年以上前の旧い記事なのでご注意ください。※ こんにちは。プラットフォームの小宮です。 今回は、ELBは高いのでスモールスタートだからLVSを構築しましょうという趣旨ですすめた記録です。 最初に書くのもなんですが、LVSでWEBもDBも負荷分散しちゃおうぜということだったんですが、結果的にはWEB側はやっぱELBにという話になりました。 (公私混同フラットNWであることを顧客に説明するのが大変だという話とSSLとかスケールとか運用の利便性等で。) 普段よりは気をつける点: ・環境がAWS(インスタンスを気軽に作り直してChange Source/Dest CheckをDisableにし忘れる等に要注意) ・クライアントがグローバル越しだとDSRできない(エッジルータでENIとIPが合わないパケットが破棄される) ・フラットなNW構成でないとDSRできない(これは普段通りだけど気をつけるポ

  • LVS+keepalived の設定 1 - interdb’s blog

    備忘録として、DSRによるLVSとkeepalivedの設定を段階的に書く。 前提は以下のとおり: LVSの転送方式はDSR ネットワークは単一セグメントで超簡単なもの OSはCentOS6.5 今回はDSRのLVSでMySQL:Slaveの負荷分散の練習。 以降の予定は: keepalived導入 LVS+keepalivedの2重化 keepalivedによる厳格なMySQL:Slave死活監視+死活管理 ネットワーク構成 今回は以下の構成。 LVSはeth0 = 192.168.1.100。さらに後々を考えてVirtualIPとしてeth0:0 = 192.168.1.10を設定。クライアントはこのアドレス(VIP)にアクセスする。 MySQL:Masterはeth0 = 192.168.1.200、ただしLVSとは関係ない。 MySQL:Slave1はeth0 = 192.168.

    LVS+keepalived の設定 1 - interdb’s blog
  • LVS/DSR + iptablesで切断したコネクションが消えなくてハマった - mikedaの日記

    LVS+DSRでMySQLサーバの参照を分散してRailsから接続してみたところ、 デプロイごとにMySQLのコネクションが増えていくという事象が発生してハマりました。 ※Railsの持続的なコネクションだとそもそもLVSで分散できねーだろ、ってツッコミは今回は無しでお願いします・・・ 結論としてはLVS が FIN を落とすに書いてるとおり、LVSサーバのiptables設定がダメだったのですが、いちおう経緯を書いておきます。 iptables無しの状態 通常、MySQLに外部から接続すると $ mysql -utest -ptest -h192.168.1.111 tmp_app_development MySQLサーバ上にESTABLISHEDなコネクションが出来て、 [root@mysql01 ~]# netstat -an | grep 3306 tcp 0 0 0.0.0.0:

    LVS/DSR + iptablesで切断したコネクションが消えなくてハマった - mikedaの日記
  • 高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ : DSAS開発者の部屋

    「こんなに簡単! Linuxでロードバランサ」のシリーズでは、 こんなに簡単! Linuxでロードバランサ (1) 〜 LVS + NATで負荷分散をしてみよう こんなに簡単! Linuxでロードバランサ (2) 〜 keepalivedでWebサーバのヘルスチェック こんなに簡単! Linuxでロードバランサ (3) 〜 VRRPでロードバランサを無停止にする こんな流れでNATによる負荷分散システムを構築してきました。 今回はこれを DSR(Direct Server Return) 方式に変更してみます。 「DSRとはなんぞや?」という方は、 ロードバランサの運用.DSRって知ってますか? L4スイッチはDSR構成にすべし こちらでわかりやすく説明されていますので参考にしてみてください。 一般的(?)に大規模システムを構築する場合は、「ネットワーク機器の整備はこの部門」、「サーバの調

    高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ : DSAS開発者の部屋
  • LVSでDSR(簡易構成) | Ore no homepage

    えー、あー、LVSに関する記事です。あんまムツカシーこと考えずに作るならこれでいいんじゃね?って記事です。趣旨としては「LVSでDSRっていうとiptables設定したり、ARPに応答しないようにごにょごにょしたり、カーネルパラメータいじったり、めんどくさいんでしょ?」→「そんなこたぁねぇ!」って言いたいだけの記事です。 環境は次の条件とします。まぁ、「検証環境にロードバランサ置きたーい。」「LVSの冗長化のテストしたーい」みたいなケースですかね。 クライアント、LVS、リアルサーバは同じセグメントにいる 全てのマシンはLANインターフェイスを1つだけ持つ(eth0のみ、もしくはbond0のみ) LVSはDSRで動かす 図に表すとこうなる↓ client 特になにもしなくてOK。 たまに「ルーティングをVIPに向ける必要がある」みたいなブログを見るんですが、上述の条件の場合は不要なんじゃな

  • LinuxでL4のロードバランサを簡単に作る手順 - Qiita

    ロードバランサは高いので、Linuxで比較的簡単にL4の負荷分散を行えるLVSは使いドコロが色々あり結構便利。 久々に作った時のメモがわりとして、今回は、LVSの構築手順と簡単なテスト結果を順に書いてみた。 構成 ちょっと特殊な要件があり、負荷分散行うLVSも実際にレスポンス返すアプリも同じ筐体で動かしたいという前提で作った。 ※最初の投稿だと、同一筐体で動かした時にBACKUP STATEのLVSがARP応答する設定になっていたので、加筆! LVS単体サーバとしても下記の手順で同じように作れる サーバはaa,bbの2台(vagrant上の仮想マシンとした) 同じ役割を持つサーバaa,bbをLVSを使って負荷分散したい LVS自身も冗長構成にして、aa,bbにやらせたい リクエスト元は、同一セグメントなのでDSR(Direct Server Return)を使う ※NATは、戻す時に直接L

    LinuxでL4のロードバランサを簡単に作る手順 - Qiita
  • 1