CentOS 6.3をHyper-V (2008R2)にインストールしたよ…Hyper-V統合サービスで躓いたからメモするよ。
前回は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
前回までで、 複数のWebサーバにロードバランスする というところまではできました。 これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。 このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。 というわけで今回は冗長化のお話、 リアルサーバのヘルスチェック を紹介したいと思います。 今回はkeepalivedを使います。 おおざっぱにいうと、keepalivedは2つの機能を提供します。 1. ヘルスチェック機構と連携したIPVSでのリアルサーバの管理 (--check) 前回ipvsadmコマンドを使って行ったような、バーチャルIPアドレス (VIP) やリアルサーバの管理を設定ファイルに記述す
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
最近注目されている開発支援ツール「Vagrant」は、テスト用の仮想マシン作成やその環境設定などを自動化するツールだ。これを利用することで、仮想環境の作成からセットアップ、そして破棄までを、簡単なコマンドを実行するだけで行える。今回はこのVagrantの概要と基本的な使い方を紹介する。 仮想マシンの作成や環境構築、仮想マシンの破棄までを自動化するツール「Vagrant」 近年、Web開発の分野ではPC上に構築した仮想マシン上にテスト用の環境を作成し、そこで開発やテストを行う、というスタイルが一般的になっている。その場合に問題になるのが、本番環境とテスト/開発環境が同一になっていない、というケースだ。また、複数人の開発者が関わるプロジェクトでは開発者がそれぞれ自身のマシン上に仮想環境を構築して開発するという例も多いが、この場合開発者ごとのテスト/開発環境がそろっていないという問題も発生しうる
前回は 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
インフラ系のエンジニアじゃないけど、ロードバランサ周りのことも知っておかないとなーって最近思う。 そこで、今回は 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
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
こんにちは、インフラの担当をしております平野です。 当社では意味の分からないカードゲームが流行っているようですが、 私は「ダム」に行くともらえる「ダムカード」集めにはまっております。 大きなダムを上から覗いたときに感じる怖さからのお尻のむずむず感がたまりません。 先日、新しいサービス・アーキテクチャのインフラ構築をする際にしくじったことがあったので 記事にしたいと思いました。 1) ipvs環境化でのコネクションプーリングでMySQLがmax_connectionsに到達問題 MySQLレプリケーション機能を利用し、参照のみを利用するクエリ向けにスレーブ機を複数台並べ、 ロードバランスさせる構成を取っていました。 ロードバランサはipvs(lvs)、アプリはコネクションプール機能の利用を前提としていました。 ある程度稼働させたところ、 ・負荷が大してかかってない ・サーバ上のMySQLのコ
vi でファイルを開いたら、 ↓カーソルでファイルの末尾まで行く キーボードの「o」で現在のカーソル行の下に空行を作りそこにテキストを挿入できる文字入力モードになるので、下記を追加 <code>SU_WHEEL_ONLY yes</code> {esc}キーを押してコマンドモードに切り替え、「:wq」で保存して終了 これで、wheel グループのみ su コマンドが使えるようになりました。 次に、一時的に root になれる sudo コマンドですが、初期状態ではこのコマンドは使用できない設定ですので、wheelグループのユーザーのみ sudoコマンドを使える設定にします。 <code>[root@ ~]# visudo</code> ファイルを編集します。 下記のコメントアウトになっている部分の「#」を削除します。 コマンドモードで「#」にカーソルを持って行き「x」で削除します。 #%w
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く