EC2でkeepalived+LVS(DSR)速習！論理レプリケーション ～基礎から最新動向まで～ （PostgreSQL Conference Japan 2022 発表資料） 2022年11月11日（金） NTTデータ 技術開発本部 先進コンピューティング技術センタ 鳥越 淳
RedisをKeepalivedでフェイルオーバーする構成案 - 酒日記 はてな支店
master slave 構成を取っている Redis で、master が落ちた場合に slave を昇格させてフェイルオーバーしたいという要件がありまして、Keepalived と組み合わせて構成してみました。Redis の運用経験がないのでご意見などいただければありがたいです。 Scientific Linux 6.2 keepalived-1.2.2-3 redis-2.4.10 前提 Redis のレプリケーションではマルチマスター構成を取ることができない Redis の slave は起動時に master に接続し、全データを取得してコピーを取る その後は順次 master で更新されたデータをコピーする redis-cli で slaveof コマンドを実行することで、動的に master, slave を切り替えることが可能 このような作りになっているため、2ホスト間で
ロードバランサの冗長化 - KLablabWiki
ロードバランサを冗長化する keepalivedにはVRRPという機能があります。ロードバランサを2台用意してこの機能を使うと、なんらかのトラブルで1台がダウンしても、もう1台のロードバランサが自動的に役割を引き継いでくれるようになります（この動作を「フェイルオーバ」といいます）。 この章ではkeepalivedのVRRP機能を使い、前章の構成で単一故障点だったロードバランサを冗長化する方法を紹介します。 VRRPとは 実際に使ってみる前に、VRRPとはどのようなものかを簡単に説明します。 VRRPはVirtual Router Redundancy Protocolの略で、RFC3768で定義されています。VRRPでは物理ルータ固有のIPアドレスとは別に「仮想ルータアドレス」[1]というIPアドレスを設定します。仮想ルータアドレスは、複数の物理ルータのどれか1台に割り当てられます。仮
Linux Virtual Server Tutorial
Horms（Simon Horman） - horms@valinux.co.jp VA Linux Systems Japan株式会社 - www.valinux.co.jp 2003年7月（2004年3月改訂） http://www.ultramonkey.org/ Linux Virtual Server（LVS）プロジェクトは、レイヤ4スイッチングを利用して、Webサーバやメールサーバなどのネットワーク・サービスの負荷分散を可能にします。これは非常に高速で、これらのサービスは、数万から数十万もの同時接続にまで拡張してサービスを提供できるようになります。 このチュートリアルの目的は、LVSのさまざまな機能を利用してインターネット・サービスの負荷分散を行う方法と、heartbeatやkeepalivedなどのツールを使って高可用性を実現する方法を示すことです。さらに、高可用性環境でアク
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の運用ノウハウお見せします 〜 割当管理を簡単にしたい : DSAS開発者の部屋
keepalivedの設定ファイルは、以下のようなエントリをひたすら並べなくてはいけないので、規模が大きくなるほど可読性が落ちます。 virtual_server_group SITE1 { a.b.c.d 80 } virtual_server group SITE1 { delay_loop 3 lb_algo wlc lb_kind DR nat_mask 255.255.252.0 protocol TCP persistence_timeout 0 real_server 192.168.8.1 80 { weight 1 inhibit_on_failure HTTP_GET { url { path /s/health.jsp status_code 200 } connect_port 80 connect_timeout 5 nb_get_retry 1 delay_be
高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ : DSAS開発者の部屋
「こんなに簡単！ Linuxでロードバランサ」のシリーズでは、 こんなに簡単！ Linuxでロードバランサ (1) 〜 LVS + NATで負荷分散をしてみよう こんなに簡単！ Linuxでロードバランサ (2) 〜 keepalivedでWebサーバのヘルスチェック こんなに簡単！ Linuxでロードバランサ (3) 〜 VRRPでロードバランサを無停止にする こんな流れでNATによる負荷分散システムを構築してきました。 今回はこれを DSR(Direct Server Return) 方式に変更してみます。 「DSRとはなんぞや？」という方は、 ロードバランサの運用.DSRって知ってますか? L4スイッチはDSR構成にすべし こちらでわかりやすく説明されていますので参考にしてみてください。 一般的(?)に大規模システムを構築する場合は、「ネットワーク機器の整備はこの部門」、「サーバの調
LVS - PukiWiki
LB 用マシンのセットアップ † kernel : CentOS 4.5 に標準で入っているものを使う。keepalibed のビルドのために kernel の header パッケージも入れておく。 ipvsadm : CentOS 4.5 のパッケージで用意されているものを使う。 keepalived : CentOS 4.5 にはパッケージが用意されていないので、独自ビルド。 ↑ keepalived のインストール † http://www.keepalived.org/ keepalived-1.1.15.tar.gz を入手。 configure を実行すると rpm パッケージを作成するための spec ファイル keepalived.spec が生成されるので、これを用いて rpm パッケージを作成し、 作成したパッケージをインストール。 自分の $HOME で rpm 作
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
SeeIn開発日誌 - LVSを使ったブローカーの構築：｢keepalived.conf｣についての説明
今回構築から検証までの間で説明を省略していた ｢keepalived.conf｣について私が理解している範疇で説明します。 ※誤り等あればご指摘いただけると助かります。。。 まず、説明の対象となる｢keepalived.conf｣を以下に掲載いたします。 vrrp_instance vip_mysqld { state BACKUP interface eth0 grap_master_delay 5 virtual_router_id 1 priority 100 nopreempt advert_int 1 authentication { auth_type PASS auth_pass secret } virtual_ipaddress { 10.1.100.100/24 dev eth0 } } virtual_server 10.1.100.
keepalived.confのシンタックスチェックツール「keepalived-check」「haskell-keepalived 」が凄い！ - （ひ）メモ
id:viverさんとid:maoeさんが(7月ぐらいに)やってくれてました。 http://github.com/frsyuki/keepalived-check http://github.com/maoe/haskell-keepalived ずいぶん前からkeepalived.confのシンタックスチェックをするプログラムないかなーと思ってました。個人的にはバックアップ側のkeepalivedにまず反映して問題がないならマスタにも反映する、という運用手順をとっていますが、はやりsyntax checkerがあるのとないのとでは安心感が大違いです。 また、構築フェーズでは、keepalived.confをあれやこれやといじり試行錯誤するわけですが、confの書式が間違っていてもkeepalivedは警告も出さずスッコリなかったものとして知らん顔で起動するので、「設定してるはずの通りに
Keepalivedのヘルスチェックを強化するパッチ : DSAS開発者の部屋
keepalived は MISC_CHECK を利用すると、標準の機能でサポートされていないヘルスチェックをすることができますが、MISC_CHECKの注意点でご紹介したように、安全に運用するためには結構気を使わなければいけません。また、比較的短い周期で繰り返さなければならないヘルスチェックでは「チェックの度に別プロセスを起動する」というアプローチは、できるだけ避けたいと考えるかもしれません。 というわけで、それなりにニーズがあると思われるヘルスチェック機能を keepalived-1.1.13 に組み込んでみましたのでパッチを公開します。 keepalived-extcheck.patch (46080bytes) ただしこのパッチ、まだDSASの本番環境には適用していません。 つまり稼働実績がありません。今は開発環境での試験運用中ですので、その点をご理解の上でご利用下さい。不具合報告
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 した
keepalivedのnb_get_retryの動きが不思議な#2 - （ひ）メモ
keepalivedのnb_get_retryの動きが不思議な件 の続き。 今回は keepalived 1.1.17 で試してみたす。 ヘルスチェック (HTTP_GETの場合) のループ間隔に関係ありそうな設定項目はこの3つ。 virtual_server group delay_loop (delay timer for service polling) real_server HTTP_GET nb_get_retry (number of get retry) delay_before_retry (delay before retry) コードレベルじゃなくて実験観察結果ですけど、まとめるとこんな感じ: ┌─────────┐ │ ↓ │ delay_loop │ ↓ │ CHECK (最大connect_timeout) │ Enable ↓ Disable │ <成功>──
keepalived de include - stanaka's blog
keepalivedというサーバの信頼性を高めるためには、かかせないツールがあります。 去年の秋ぐらいにちょっと話題になったツールで、はてなでも便利に活用して、「もはや、keepalivedなしでは生きていけない」と言っても、過言ではないぐらいです。 ちなみに、keepalivedがどういうツールかというと、いわゆるお手軽ロードバランサで、バックエンドにウェブサーバやDBサーバが複数ある時に、死活監視をしつつ、適切にトラフィックを分散してくれます。さらに、keepalivedを2台構成にすると、VRRPというプロトコルで障害時に論理IPを付け替えたりもしてくれます。さらにさらに機能は豊富なのですが、とても説明しきれません。もっと、分かりやすい説明は、このあたりを探れば、じゃかじゃか出てくるので、そちらを参照してください。 今回の本題は、keepalivedをヘビーに使い出すと、設定ファイル
LVS + keepalived + VRRP + DSR環境を構築する際のRed Hat Enterprise
_ [Server][Admin] LVS + keepalived + VRRP + DSR環境を構築する際のRed Hat Enterprise Linux/CentOSでのネットワーク周りの便利な設定方法 KlabのDSAS開発者さんのパソコン1台ではじめるロードバランサ体験は基本的にDebianをターゲットにされているため、Red Hat Enterprise Linux/CentOSで構築する場合固有の便利な設定方法が書かれていないのでそれを紹介したいと思います。既にDSAS開発者さんの手順で環境を作ったことがある人向けです。ここで紹介する方法で設定をしておけば、OS再起動後やネットワーク再起動も自動的に停止前と同じ状態になります。肝は/etc/rc.localを使わないこと。 上位ルータでの静的ルーティング設定 上位ルータがハードのスイッチではない + Red Hat Ente
keepalived と 当ててるパッチたち - （ひ）メモ
今使ってるのは 1.1.17 、その前に使ってたのは 1.1.15 す。 keepalived 1.1.19 1.1.19ではpidfileとnopreemptパッチは取り込まれているので、 keepalived-1.1.13-extcheck-1.0.patch だけ当てています。 keepalived 1.1.17 keepalived-1.1.13-extcheck-1.0.patch DSASさんところのヘルスチェック拡張パッチです。ふふ。DNS_CHECKとSSL_HELLOを使ってます。 ちなみに、このパッチを当てないで DNS_CHECK とか SSL_HELLO を使うと、keepalived.confにreal_serverを複数書いているにも関わらず、ipvs的には1つしか有効にならないという不思議状態になりますので、バージョンアップのときとかにはパッチ当て忘れないよう
keepalivedでフェイルバック無効にしたときの挙動〜LANケーブル障害編〜 - よかろうもん！
以前のエントリ『keepalivedでフェイルバック無効(nopreempt)にしたときの挙動』では、以下のような状況でフェイルバックするかどうかの確認をしました。 keepalivedサービスが停止し、マスタからスレーブに仮想IPが引き継がれた後に元マスタのkeepalivedサービスを起動したとき keepalivedでヘルスチェックしているインタフェースを意図的にダウンさせ、スレーブに仮想IPが引き継がれた後にインタフェースをアップさせたとき keepalivedの振る舞いとして、フェイルバック無効の設定をしている場合は、keepalivedを先に起動した側が常にマスタとなるということから、前者の場合はフェイルバックしないことが確認できました。 しかし後者の場合は、keepalivedのサービスは停止していないため、フェイルバックしてしまうことを確認することができました。 以前のエン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社TAP
クックパッドのLVSについて - クックパッド開発者ブログ
