高可用性ロードバランサーを nginx + heartbeat で作る

ロードバランサーの可用性を高めるために、アクティブスタンバイ構成で、アクティブ系が落ちたらスタンバイ系に引き継げるようにする。

構築環境

  • サーバー機
    • NIC × 2 枚 (推奨 4 枚)
    • RAID: 1, (推奨 0 + 1)
    • 電源ボード × 2 (予算があれば)
    • 仮想化ソフトウェア: VMWare ESXi 4.0
  • 仮想化ソフトウェア (VMWare ESXi 4.0) の設定
    • NIC は 2 枚 1 組でフェイルオーバーするように設定
    • ネットワーク × 2 (NIC 2 枚構成の場合は VLANを作成)
      • VM Network: 既存 (デフォルト)
      • HA Network: 新規追加
  • ロードバランサー用ゲストOS (Ubuntu Server 9.10: 各サーバに1 台ずつ追加)
    • ディスク: 4G程度 (Ubuntu Server の最小ハードウェア要件は 1G)
    • コア数: 2
    • メモリ: 4G
    • ネットワーク × 2
      • VM Network に接続された NIC
      • HA Network に接続された NIC
ネットワーク アクティブ (lb01) スタンバイ (lb02)
eth0 (heartbeat 監視用) 192.168.0.2 192.168.0.3
eth1 (管理用) 172.16.0.2 172.16.0.3
サービス用 172.16.0.1 (実際にサービスを提供する IP)

インストールと設定

  1. パッケージ類のインストール (nginx と heartbeat)
    ロードバランサーとして利用する nginx と、クラスタリングするための heartbeat をインストールする 
    sudo aptitude install nginx heartbeat
  2. nginx の自動起動をやめる
    sysv-rc-conf などを利用し、各ランレベルでの自動起動を停止しておく
    ※ sysv-rc-conf をインストールしていない場合は以下でインストールできる 
    sudo sptitude install sysv-rc-conf
  3. hosts ファイルに各サーバを登録する 
    sudo vi /etc/hosts

    192.168.0.2 lb01
192.168.0.3 lb02
    ※ お互い ping 試験
  4. /etc/ha.d/ha.cf の作成
    テンプレートがあるので、作業用ディレクトリーに複製、及び編集
    監視対象を指定 
    sudo cp /usr/share/doc/heartbeat/ha.cf.gz .
sudo gzip -d ha.cf.gz
sudo vi ha.cf
    コメントを外したり、記入したりなどする 
    keepalive 2
deadtime 30
warntime 10
initdead 120
udpport 694
ucast eth0 192.168.0.[2-3] # 相手のIPアドレス
auto_failback on
node lb01
node lb02
use_logd yes
    /etc/ha.d/ へ配置する 
    sudo cp ha.cf /etc/ha.d/
  5. /etc/ha.d/haresources の作成
    これもテンプレートから
    アクティブ系、IP、サービス名を指定 
    sudo cp /usr/share/doc/heartbeat/haresources.gz .
sudo gzip -d haresources.gz
sudo vi haresources

    lb01 IPaddr::172.16.0.1/24 nginx
    /etc/ha.d/ へ配置する 
    sudo cp haresources /etc/ha.d/
  6. /etc/ha.d/authkeys の作成
    これもテンプレートから 
    sudo cp /usr/share/doc/heartbeat/authkeys .
sudo vi authkeys

    auth 3
3 md5 Hello!
    /etc/ha.d/ へ配置し、root ユーザからのアクセスのみ許可するようにする (これしてなくて heartbeat 起動時に怒られた) 
    sudo cp authkeys /etc/ha.d/
chmod 600 /etc/ha.d/authkeys
  7. lb01 -> lb02 の順で heartbeat を起動 
    sudo /etc/init.d/heartbeat start
  8. フェイルオーバーの試験とか
    ifconfig とかでeth1:0 に サービス IP 172.16.0.1　が引き継がれていれば成功。

コメント

コメントを投稿

このブログの人気の投稿

Python から Win32 API 経由で印刷する

Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制御したい場合はライブラリを作成する必要があります。これについては、ドライバマニュアルとにらめっこしながら ctypes.windll でがんばります・・・。プリンタ接続、用紙切れ、ミスフィード等のプリントエラーを制御する必要がなければ、書く必要はありません (排他制御が必要なプリンタを除く)。プリンタドライバ毎に変わる部分は置いといて、太字の Win32 API の部分の覚書です。 プリンタデバイスコンテキストを作成する import win32ui import win32con PRINTER_NAME = '[コンパネ -> プリンタとFAX -> に登録しているプリンター名]' PIXELS_PER_INCH = 1440 # 1 インチ毎のピクセル数 INCH_PER_POINT = 72 # 1 インチ毎のポイント数 SCALE_FACTOR = int(PIXELS_PER_INCH / INCH_PER_POINT) #　わざわざ計算せず 20 と指定する場合が多い dc = win32ui.CreateDC() dc.CreatePrinterDC(PRINTER_NAME) # 指定したプリンタ名のプリンタデバイスコンテキストを作成する self.dc.SetMapMode(win32con.MM
続きを読む

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？
続きを読む

Django と Python 3 - #python_adv

Django-ja の方からきました。こんにちわ。さて、昨日の Ian 先生のブログ にも書いてある通り、ついに Django にも本格的に Python 3 の足音が近づいてきました。ただし現在 alpha 版が公開されている 1.5 では "実験的" なサポートで、1.6 以降で正式にサポートする予定となっています。あくまでも "実験的" であり、プロダクションでの利用は "非推奨" となっています。Django コミュニティでは、この 1.5 でサポートをテストしてもらい、そのフィードバックを呼びかけています。なのでプロダクションでの利用は 1.6 まで待ちでしょうね。また Python 3 サポートと同時に、Django 1.4 では Python 2.4 がサポートから外れ、1.5 では Python 2.5 がサポートから外れます。これで 1.7 以降から django.utils 配下が軽くなっていくんでしょうかね (現在は 3 サポートのためにさらに増えてる)。 バージョン 下位互換 Python サポート 2.5 2.6 2.7 3.2 3.3 Django 1.4 > 1.2 ○ ○ ○ - - Django 1.5 > 1.3 - >= 2.6.5 ○ >= 2.7.3 △ 実験的 △ 実験的 Django 1.6 > 1.4 - >= 2.6.5 ○ >= 2.7.3 ○ ○ Python 2.5 系を利用している場合は、1.6 のリリースまで (2013 後半ぐらい?) に Python 2.6.5 以上 (2.7.3 以上を強く推奨) への移行が必要です。1.5 は今月 (2012/12) 中にリリース予定とのことなので、今のうちに Python 3 へ移行方法を抑えときたいなと。以下 Django ドキュメントの翻訳作業がてら " Porting to Python 3 " を元にご紹介。さすが
続きを読む