keepalived の HTTP ヘルスチェックを改良してみた | Carpe Diem
keepalived で、HTTP ヘルスチェックしているとき、今まではあまり特に考えず、次のようなシンプルな形になっていた。 virtual_server group HTTP { delay_loop 3 lvs_sched wrr lvs_method DR protocol TCP virtualhost status.server.example.com real_server 192.168.0.1 80 { weight 1 inhibit_on_failure HTTP_GET { url { path / status_code 200 } connect_port 80 connect_timeout 5 } … } これでしばらく運用していると、１台だけリアルサーバをメンテナンスしたいとき、高トラフィックなサイトなのでプログラムをデプロイしたいときウォームアップするた
'[Keepalived-devel] Problem with vrrp_script child process not being' thread - MARC
Search: [] List [] Subjects [] Authors [ ] Bodies (must pick a list first) Set Page Width: [ 80 ] [ 90 ] [ 100 ] [ 120 ] Viewing messages in thread '[Keepalived-devel] Problem with vrrp_script child process not being' keepalived-devel 1. 2007-11-01 Re: [Keepalived-devel] Problem with vrrp_script child keepalive Alexandre Cassen 2. 2007-11-01 Re: [Keepalived-devel] Problem with vrrp_script child k
DSAS開発者の部屋:keepalivedの運用ノウハウお見せします 〜 設定ファイルを同期する
keepalivedはLinuxで冗長構成を組む道具としてとても便利ですが、運用面に関する配慮に物足りなさを感じることがあります。例えばIncludeがないとかIncludeがないとかIncludeがないとか（笑） naoyaの日記でnaoyaさんも悩んでいるようですが、設定ファイルをうまく保守する仕組みをどう作るかが導入する際の大きな鍵になると思います。今回は、DSASではどのようにして2台のkeepalivedを運用しているかを少しだけご紹介させて頂きたいと思います。 1) マスターで設定ファイルを編集する 2) バックアップに設定ファイルを転送する 3) バックアップで設定を反映する 4) マスターとバックアップの差分を確認する 5) マスターで設定を反映する 具体的にはどのようにしているかというと、、、 lv1:# vi 設定ファイル lv1:# lvs-sync -ine lv1
keepalived講習会 | feedforce Engineers' blog
ゴール VRRPによる仮想IP持ち回りの仕組みを理解する keepalivedを利用したHAクラスタが構築できる LVS周りはナシで。 基礎知識編 基本的な資料 keepalived 本家 こんなに簡単！ Linuxでロードバランサ (2) - DSAS開発者の部屋 あとは昔まとめた社外秘の資料 keepalivedって何スか LinuxにおけるVRRPの実装のひとつ。HAクラスタを実現するデーモン。 HAクラスタのマスタ機とバックアップ機の両方で動作させることで簡単にHAクラスタができる。 またLVSを利用した負荷分散クラスタの稼動をサポートする機能もある。 VRRP 仮想IPを複数機器で共有し、一番プライオリティの高い機器がそのIPを持つ仕組み。 本来はルータ冗長化のためのプロトコルだが、サーバの冗長化にも使用できる。 つまりHAクラスタが作成可能。 参考 : Virtual Rout
そなーブログ » Blog Archive » MySQLレプリケーション+keepalived
linux, サーバー関連 2010年6月19日, 地味にみなさんがどういう設定をしてるかが気になるところですが 正直何の知識もない僕が仕事で 「DB2台でレプリケーションよろしく」といわれて試行錯誤で構築した軌跡です。 他の人たちがどのように構築しているかがすごく気になるところですねぇ･･･ 目的 すでに構築されているWEBとDBの構成のもの。 DBを１台増やすから「１台が落ちても２台目がホットスタンバイしてて即座に切り替わる構成」 としてほしいというのが依頼。 構成的にはこんな感じにDBが１台増える感じ。 こんな風に普段はWEBはDB1を参照するけど、DB1に障害が起きた場合は！ こんな形でDB2を参照するようにしちゃう。 こういった風に代替サーバーが役割を引き継ぐ事をフェイルオーバーって言うらしいよ！ これを可能にするにはDB1とDB2の間で以下の事がないと成立できない 例えばDB1
keepalived, lighttpdのログ出力
普段考えている事やら、何やら特定のトピックは設定せずに、将来読み返す自分に向けて何か書いてゆくためのスペースです。 とはいえ書くからには再利用しやすいものを目指します。 コメントは各記事への投稿か、Google Groups "Yasundial/Yadiary Forum"へどうぞ 前回のWebクラスタの投稿で、keepalivedとlighttpdの挙動を確認する必要がありました。 その時に気がついた事をまとめていきます。 keepalivedのログ出力機構 keepaliedとsyslogについて keepalivedの詳細なログ出力について 出力されるdetailログ virtual_router_idの範囲について lighttpdのログ出力 Proxyモジュールのログ出力 まとめ keepalivedのログ出力機構 マニュアルによれば基本的なロギングとしてsyslogが使われて
DSAS開発者の部屋:知っていても損はしないkeepalivedの話 〜 MISC_CHECKの注意点
keepalived では様々なヘルスチェック方式がサポートされています。 HTTP_GET SSL_GET SMTP_CHECK TCP_CHECK これらの使い方はなんとなく想像がつくと思いますが、これら以外のサービスのヘルスチェックをするにはどうすればいいのでしょうか。 例えば DNS とか FTP とかあれとかこれとか・・・ FTP は最悪 TCP_CHECK でお茶を濁すって手もありますが、FTP サーバがポートをオープンしたまま応答不能になることも考えられるので、あまりお勧めできません。また、DNS をチェックする機能は keepalived にはありません。 そんな時に使うのが MISC_CHECK です。今回は MISC_CHECK を利用する上での注意点や設定のサンプルを紹介したいと思います。 指定したプログラムを実行して、その終了コードによってリアルサーバを UP した
同一セグメントでのLVS
LinuxでLVSを利用してロードバランサを構築しています。 構成1： LB[keepalived(192.168.1.1)]仮想(192.168.0.3) A[Apache(192.168.0.1)] B[Apache(192.168.0.2)] 構成2： A[Apache+keepalived(192.168.0.1)]仮想(192.168.0.3) B[Apache(192.168.0.2)] DSASのページなどを参考にしているのですが、構成1の3台構成NATであれば問題なく動きます。しかし構成2の同一セグメントでサーバそのものに仮想を持たせるとうまくいきません。どうもAが仮想を持った際に192.168.0.2への振り分けが発生しても、自身で処理しようとしているのか失敗してしまいます。設定は以下の通りです。何が足りないのか教えて頂けると助かります。尚、問題切り分けとしてvrrpは片
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Keepalived | less;;blog
linuxでロードバランサに引き続き、VRRPで構築した時のメモ。 VMware esxiを使用して上記図のように、ロードバランサ２台・webサーバ3台、計5台の仮想サーバを作成。 ロードバランサのN/W設定 ■アクティブ機 eth0:10.11.1.110 eth1:192.168.11.110 ■スタンバイ機 eth0:10.11.1.115 eth1:192.168.11.115 keepalived.confに以下を追記。 内容としては、vrrp_instanceをEXTとINの2つを作成。 EXTにはeth1を設定し、192.168.11.120と192.168.11.150のVIPを設定。 INにはeth0を設定し、10.11.1.120のVIPを設定。 ・ロードバランサ(アクティブ) vrrp_instance EXT { state MASTER inter
keepalivedでフェイルバック無効(nopreempt)にしたときの挙動 - よかろうもん！
keepalivedについて以前にいくつかのエントリでご紹介しました。 keepalivedを利用する際に気をつけておくこと bondingとkeepalivedを組み合わせる これら2つのエントリで紹介したkeepalivedの技術を組み合わせた構成で、各サーバでのkeepalivedのstatusをBACKUPにし、フェイルバック無効(nopreempt)にしたときの挙動について調査しました。 なぜ調査をしたかといいますと、keepalivedのフェイルバックの動作で疑問に感じることがあったためです。 今回のシステム構成は以下の図のように、eth0とeth2でbonding(Active-Backup)を組んでおき、さらにbond0に2つの仮想IPアドレスを、eth1に1つの仮想IPアドレスを割り当てます。 keepalivedの設定はこちらの設定内容とほぼ同じで、vrrp_insta
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Repositories - people/alex/keepalived.git/blob - keepalived/vrrp/vrrp_track.c
クックパッドのLVSについて - クックパッド開発者ブログ
lab.klab.org - KLab技術者サイト
Repositories - people/alex/keepalived.git/summary
http://lab.klab.org/wiki/LVS
Dual-master MySQL replication setup | WSU Linux Users Group
gcharriere.com
gcharriere.com
OSDIR