CentOSでロードバランサーを実験してみた


この記事の所要時間: 356

実験なのでCentOS 6.3最小構成で構築しました。全部仮想マシンです。
ルーティングが大変だった。もっと勉強しなければ。
ロードバランサー1つ、Webサーバー3つ(うち1つは過負荷時に表示されるページを用意)構成。
クライアントはUbuntu。(特に意味はない)
KLabさんにはお世話になりました。

仮想マシンそのまま複製するとネットに繋がらなくなるので注意が必要です。
仮想マシンCentOSを複製したらネットに繋がらなくなった(eth0が消えた)件について | ユニキャストラボ

導入

keepalivedはデフォルトリポジトリに存在しないので、epelリポジトリ有効にしておきましょう。
よーし、パパ CentOS 6.0 で EPEL リポジトリ使えるようにしちゃうぞー | ユニキャストラボ

インストール。

IPVSのバージョン確認。

構成

  • クライアント:192.168.10.10
  • ロードバランサー:(VIP)192.168.100.100, (eth0)192.168.10.1, (eth1) 192.168.31.1
  • Webサーバー1,2,3:192.168.31.100, 192.168.31.101, 192.168.31.102(※102がリアルサーバーが落ちた時のサーバー)

Webサーバーのドキュメントルートには死活管理用のhealth.htmlという空ファイルを置いておきます。
また、わかりやすいようにドキュメントルートにサーバーの番号とかを書いたindex.htmlも置いておいたほうがわかりやすいとおもいます。

ロードバランサー側の設定

eth0からeth1に受け流す。

クライアント側の設定

192.168.31.0/24へのルーティングを設定します。

これで192.168.31.0/24の各サーバにアクセスできるようになりました。
仮想IPアドレスで負荷分散するんだから必要ないのですが、単独でベンチマークかけた場合との違いを見てみたいと思います。

ロードバランサーを設定する

keepalivedの設定

バージョンによって書き方が変わってるみたいで苦労しました。
結果的に以下の設定で動きました。

keepalived起動

設定がちゃんと反映されているか確認します。

クライアントから実際に確認してみる

仮想IPへのルーティングを設定する。

動作確認します。

ラウンドロビンでちゃんと動いているみたいです。
なお、今のままの設定だと192.168.100.100へpingを打っても反応しないみたいです。
さっそくベンチマーク。

2319.62から2723.27に捌ける件数が上がっていることがわかります。

現在の通信状況を確認する

いじめてみました。

両方共サーバーをダウンさせたらどうなるか

100と101のサーバのhealth.htmlをchmod -r health.htmlすればそのサーバーはダウンしたものとみなされます。

DSRはまた今度・・・ルーティングの勉強したほうがいいなあ。

参考

投稿者紹介

株式会社ユニキャスト
私たちは、テクノロジに魅せられた個性あふれるメンバーによって構成された茨城県日立市に本社を構えるベンチャー企業です。
”テクノロジを通して「驚き」と「感動」を創造し、人々の「夢」と「笑顔」を支えます。” の経営理念をモットーに明るい未来を描き、ワクワクする企画提案を続けて参ります。

人気の記事

コメント

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

PAGE TOP