LVS + keepalivedで冗長構成のロードバランサを作る - カメニッキ
前提 以下でやりました。 LB1/2 192.168.33.81 192.168.33.85 (VIP)192.168.33.253 web1/web2 192.168.33.82 192.168.33.83 client 192.168.33.84 DSRでやります。 手順 ★LB1/2 # 二台とも同じようにやります [vagrant@localhost ~]$ sudo yum install ipvsadm epel-release keepalived [vagrant@localhost ~]$ ̧sudo vi /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { # このホストを識別する値。通知メールなどに載ってくる router_id lvs01_alert #
CentOS 6.5 で LVS (IPVS) の Direct Server Return (DSR) を試してみる
インフラ系のエンジニアじゃないけど、ロードバランサ周りのことも知っておかないとなーって最近思う。 そこで、今回は LVS (IPVS) を DSR で試してみた。 構成はなるべく小さくシンプルにしたいので、ロードバランサ 1 台と Web サーバ 2 台にする。 そして 3 台のサーバは全て同じセグメントに設置する。 本来はロードバランサを冗長化すべきなんだろうけど、まずはシンプルに。 LVS 用のホストをセットアップする 必要なパッケージをインストールする。 $ sudo yum -y install ipvsadm パケットを各サーバに転送する必要があるので IPv4 のフォワーディングを有効にする。 $ sudo sysctl -w net.ipv4.ip_forward=1 $ sudo sed -i.bak -e "s:^net.ipv4.ip_forward = .*$:net
lvsでsession persistence(セッションパーシステンス) - うまいぼうぶろぐ
調べてみると、現状lvsではsource IP addressでのpersistence処理しかないみたいですね。L4だから当然なのか。 ipvsadmでの設定 ipvsadmで設定するときに-pオプションをつけるだけ。 お好みでtimeoutの秒数も設定できる。 ipvsadm -A -t www.example.com:80 -p keepalived.confでの設定 virtual_server groupの設定に persistence_timeout 300を設定する。 persistenceするときの注意 persistenceを有効にする場合はkeepalived.confにinhibit_on_failureを設定してはいけない模様。 inhibit_on_failure realserverが落ちた際に、設定から削除せずweightを0にする inhibit_on_fa
IPVS-NATでリアルサーバーから応答がない事象の解決方法 – 「きまぐれほげほげひろば」のTOPICS
○ 事象 IPVS(LVS)(NAT/マスカレード構成)環境にて、端末からサービスＩＰにアクセスするとサーバーからの応答がない。 tcpdumpで調べると、応答パケットがリアルサーバーからアクセス元端末に戻っておらず、さらに調べると、IPVSを構築しているサーバーで応答パケット（戻りの通信）が破棄（遮断）されている。 □ アクセス端末 ↓｜ ■×IPVS・ファイアーウォール ↓｜↑ □ リアルサーバー ○原因 ファイアーウォールがIPVSを経由した応答パケットを認識していない！ ファイアウォールのルールが iptables -P FORWARD DROP で iptables -A INPUT -i eth0 -p tcp –dport 80 -j ACCEPT iptables -A FORWARD -i eth0 -p tcp –dport 80 -j ACCEPT iptables
LVS+ldirectorを使ってMySQLをロードバランスをしてみる - sanonosa システム管理コラム集
今回はLVSを使ってMySQLのslaveサーバをロードバランシングする方法を記してみます。LVSは単に振り分けしかやってくれませんので、リアルサーバの生存確認やLVSの作動管理のためにldirectorも導入しています。 LVSだけだとLVSの設定を入れ込まなければなりませんが、ldirectorを使うとldirectorの設定ファイルに書いておくことでLVSの設定をldirectorが自動生成して反映してくれるので楽ちんです。 ※世の中にはLVS+keepalivedの組み合わせが多いようですが、検証してみたところldirectorのほうが導入も運用も簡単なのでこちらを採用しました。 前提条件 VIP: 10.0.2.10 DB1: 10.0.0.101 DB2: 10.0.0.102 ロードバランサーとなるサーバへのインストール方法 【インストール】 # yum install ip
LVS(DSR方式)でロードバランサー
■LVSとは LVS(Linux Virtual Server)は、Linuxサーバにおいて、 HPC、HA、ロードバランサの機能を動作させるソフトウェア群とのことです。 ・IPアドレスに届いたパケットを必要に応じて、リアルサーバーに転送する。 ・転送先のリアルサーバーを複数指定できる。 ・パケットの転送では、各リアルサーバーに均等に分散することや、重み付けをして分散も出来る。 転送方法には、NAT(Network Address Translation)、ダイレクト・ルーティング（DSR方式）、IP-IPカプセル化（トンネリング）がある。 ■パケットの転送方法の違いについて ・NAT(Newtwork Address Translation) エンドユーザーからパケットを受け取ると、送信先とIPアドレスが、選択されたリアルサーバーのものに置き換えられる。 返信パケットが通る際にも置き換え
こんなに簡単！ Linuxでロードバランサ (3) : DSAS開発者の部屋
前回はkeepalivedを使ってWebサーバを冗長化してみました。 今回はkeepalivedのもう一つの機能であるVRRPを使って、ロードバランサ自身を冗長構成にしてみたいと思います。 ┌─────┐ │ client │ └──┬──┘ │[10.10.31.200] │ ━━━━━━━┯━━━━┷━━━━━┯━━━━━━━━━ 10.10.31.0/24 │ │ │ │ │ ←(10.10.31.10) → │ │ ←{10.10.31.100}→ │ [10.10.31.11]│ │[10.10.31.12] ┌─┴─┐ ┌─┴─┐ │ lv1 │ │ lv2 │ └─┬─┘ └─┬─┘ [192.168.31.11]│ │[192.168.31.12] │ ←(192.168.31.10)→│ │ │ ━━━━━━┯┷━━━━━━━━━━┷┯━━━━━━━━ 192.168.3
こんなに簡単！ Linuxでロードバランサ (2) : DSAS開発者の部屋
前回までで、 複数のWebサーバにロードバランスする というところまではできました。 これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。 このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。 というわけで今回は冗長化のお話、 リアルサーバのヘルスチェック を紹介したいと思います。 今回はkeepalivedを使います。 おおざっぱにいうと、keepalivedは2つの機能を提供します。 1. ヘルスチェック機構と連携したIPVSでのリアルサーバの管理 (--check) 前回ipvsadmコマンドを使って行ったような、バーチャルIPアドレス (VIP) やリアルサーバの管理を設定ファイルに記述す
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
CentOS 6.5 で LVS (IPVS) を keepalived で冗長化してみる
前回は ipvsadm コマンドを直接使って LVS を冗長化せずに使ってみた。 今回は keepalived を通して LVS を冗長化して使ってみる。 構成は前回と同様、方式は DSR でバランスアルゴリズムは rr を使う。 ただし LVS の IP アドレスは 192.168.33.{11,12} で Web サーバの IP アドレスは 192.168.33.{101,102} に変更している。 LVS 用のホストをセットアップする x2 まずは必要なパッケージをインストールする。 $ sudo yum -y install keepalived ipvsadm インストールできたら keepalived のコンフィグを編集する。 keepalived は LVS をラップする機能がデフォルトで組み込まれているので、コンフィグを変更するだけで動作する。 $ sudo cp /etc
CentOS 6.5 で LVS (IPVS) の Direct Server Return (DSR) を試してみる
インフラ系のエンジニアじゃないけど、ロードバランサ周りのことも知っておかないとなーって最近思う。 そこで、今回は LVS (IPVS) を DSR で試してみた。 構成はなるべく小さくシンプルにしたいので、ロードバランサ 1 台と Web サーバ 2 台にする。 そして 3 台のサーバは全て同じセグメントに設置する。 本来はロードバランサを冗長化すべきなんだろうけど、まずはシンプルに。 LVS 用のホストをセットアップする 必要なパッケージをインストールする。 $ sudo yum -y install ipvsadm パケットを各サーバに転送する必要があるので IPv4 のフォワーディングを有効にする。 $ sudo sysctl -w net.ipv4.ip_forward=1 $ sudo sed -i.bak -e "s:^net.ipv4.ip_forward = .*$:net
naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
MySQLの参照ロードバランスで最近困った２つのこと
こんにちは、インフラの担当をしております平野です。 当社では意味の分からないカードゲームが流行っているようですが、 私は「ダム」に行くともらえる「ダムカード」集めにはまっております。 大きなダムを上から覗いたときに感じる怖さからのお尻のむずむず感がたまりません。 先日、新しいサービス・アーキテクチャのインフラ構築をする際にしくじったことがあったので 記事にしたいと思いました。 1) ipvs環境化でのコネクションプーリングでMySQLがmax_connectionsに到達問題 MySQLレプリケーション機能を利用し、参照のみを利用するクエリ向けにスレーブ機を複数台並べ、 ロードバランスさせる構成を取っていました。 ロードバランサはipvs(lvs)、アプリはコネクションプール機能の利用を前提としていました。 ある程度稼働させたところ、 ・負荷が大してかかってない ・サーバ上のMySQLのコ
「Linux Virtual Server」と「Keepalived」で作る冗長化ロードバランサ | さくらのナレッジ
多数のクライアントがアクセスするような負荷の高いサービスや停止させられないサービスを運用する場合、複数のサーバーを使ってサービスの負荷分散や冗長化を行うのが一般的だ。本記事では、「Linux Virtual Server（LVS）」を使ってこのような構成を実現する方法について紹介する。 Linuxサーバーをロードバランサにする「Linux Virtual Server」（LVS） 最近では多数のCPUコアを持つサーバーが安価で利用できるようになり、サーバー1台の処理能力は飛躍的に向上している。しかし、リクエストの処理に多くのリソースを使用するようなサービスや、短時間に多数のリクエストを処理する必要があるサービスでは、1台のサーバーだけでは処理能力が不足する場合がある。このような場合、複数台のサーバーで同じサービスを運用し、ロードバランサを使ってリクエストを振り分けることで負荷の分散を図るこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
