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
こんなに簡単！ 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をお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
【MySQLウォッチ】第7回 大規模システムを支えるMySQLのレプリケーション機能：ITpro
このところ楽天をはじめとして，MySQLを活用した大規模な事例が増えている（関連記事）。このような大規模，かつサービス停止の許されないシステムを支えているのが，MySQLのレプリケーション機能である。 「レプリケーション」とは，対象物とまったく同じ物を製作する処理だ。同じような意味に「ミラー」があるが，意味するところは物理的なコピーである。「レプリケーション」は，論理的な複製であり，対象物の全体や一部といった範囲を限定できる点が異なる。 このような機能は，大がかりな準備と高度な技術が必要と考えている方も多いだろう。しかし，MySQLのレプリケーション機能は，非常に簡単に利用することができる。今回は，現行バージョンでも利用可能なレプリケーション機能を解説する。 Masterの更新がSlaveに反映される MySQLのレプリケーション機能は，MasterとSlaveに役割が分かれる（図1[拡大
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
