RedisをPacemakerで冗長化する
本稿では、Pacemaker/Corosyncを使用してRedisのクラスタを構成する方法をご紹介します。 RedisはSentinelでマスター・スレーブ構成の管理を行うことができますが、最低3個のSentinelが必要になります。また、仮想IPについては自前でスクリプトを作成するなどの工夫が必要になります。 2ノードで完結させたい場合や、その他のリソースもあわせて管理したい場合はPacemaker/Corosyncを使用するのが便利です。Pacemakerには標準でRedisのリソースエージェントが含まれているため、比較的容易にRedisのクラスタを構築することができます。 前提 以下の環境を前提とします。今回はOS標準のPacemakerを使用します。 OS: CentOS 7.4 パッケージ: redis-5.0.5-1.el7.remi pacemaker-1.1.19-8.el
EC2とEIPで冗長構成のApache Load Balancerを構築する(Pacemaker) - YOMON8.NET
ELBはオートスケールで可用性も高く、ミドルウェアの心配しないでいいので便利なのですが、IP固定できないなど課題があるのと、障害時の調査がブラックボックスすぎて大変なため、Pacemakerを利用して冗長化構成のLoadBalancerを構築してみました。 CDPで言うFloating IPになります。 CDP:Floating IPパターン - AWS-CloudDesignPattern 利用するEC2 LB構築 Pacemaker導入 Pacemakerリソースエージェントデプロイ クラスタの構築 クラスタ設定 クラスタリソースの登録 Failover挙動確認 リソースhttpdの停止 failcountの確認とリセット （補足）Failover時の通知 (補足)failcountをクリアしてもリソース移動できないとき （補足）pcsコマンドはタブ補完が効きます （補足）Cluste
[CentOS7] Pacemaker のリソースを登録する（Apacheのクラスタ）
以前書いた記事で、CentOS7にPacemaker+Corosyncをインストールしました。 今回は、下記のリソースを使用して、Apacheのクラスタ（Active/Standby) を試してみます。 VIPCheck 一番最初に起動させてVIPに疎通できるかチェックし、疎通できた場合は後続のリソースを起動しないようにします。（スプリットブレインの防止） IPaddr2 仮想IPアドレス（VIP)を作成します。 apache apache を起動します。 ping ネットワークを監視して、デフォルトGWに疎通できるサーバでリソースが起動するようにします。 ping 以外のリソースは同一グループ（WebGroup）に所属させることで、一緒に行動するようにします。VIPCheck/IPaddr2/apacheは常に同じサーバ（Active）で動くようにします。 ping は Active/S
zabbix-server+pcs+corosyncでHAクラスタを構築する検証 - Qiita
CentOS7からcrmが使えなくなるのでpcsでzabbixサーバの冗長構成をがんばってみようという記録です。 監視サーバが長時間監視できなくって復旧に時間がかかるとか割とありえないというか、もし主系がしんでも待機系がすぐ生き返るようにしたいし深夜早朝に時間のかかる復旧に借り出されたら超いやだしミスると危ないから自動化不可避という認識です。 もはや手動運用でカバーとか筋肉運用とかムリなお年頃ですみません。寝ないと寿命がちぢみそう。健康超だいじ。 ・ホスト名を付け直す（set-hostnameを指定すると再起動後も反映される） # hostnamectl set-hostname monitor-mng-cent7-test-komi01 # hostnamectl set-hostname monitor-mng-cent7-test-komi02 # vi /etc/hosts 127
PostgreSQL Automatic Failover - Home
High-Availibility for Postgres, based on Pacemaker and Corosync. PostgreSQL Automatic Failover Intro Thanks to Pacemaker and Corosync, PostgreSQL Automatic Failover (aka. PAF) is able to: detect a failure of your PostgreSQL instance recover your primary instance… … or failover to another node Select the best available standby on failover (with the smallest lag) switchover roles in your cluster bet
Pacemaker のリソースフェイルオーバーについて - NETWORK ENGINEER BLOG
2021-02-23 Pacemaker で想定される故障は、start［起動失敗］, monitor［監視による検出］, stop［停止失敗］の3パターンがあります。故障が発生した際は、on-fail の設定に応じた動作を行います。on-fail を指定しない場合は、デフォルトの restart が適用されます。on-fail で指定可能な設定値は下記のとおりです。 ignore : 何の処理も行わない。 block : 故障したリソースの管理を停止し、待機する。 fence : リソース故障が発生したサーバーを STONITH によって再起動し、フェイルオーバーする。 restart : 故障したリソースを、他のサーバへフェイルオーバーする。（デフォルト） 以前書いた記事の環境を使って、あらためてフェイルオーバーをテストしてみます。 リソースフェイルオーバーの確認 pm01 の設定を確
Pacemakerを利用したHAクラスタの構築
pacemaker_document.md Pacemakerを利用したHAクラスタの構築 このドキュメントでは2ノードでのクラスタリング設定方法を説明します。 シェルの表記について # 1台目のみに対して設定する場合 [root@sv1 ~] $ some command # 両方のサーバに対して設定する場合 $ some command サーバ構成 OS CentOS7 x 2 ホスト名:IPアドレス sv1:192.168.33.11 sv2:192.168.33.12 初期設定 ノード間の疎通確認 ホストファイルの設定 名称解決できるようにhostsファイルを設定します。 $ vi /etc/hosts 192.168.33.11 sv1 sv1.localdomain 192.168.33.12 sv2 sv2.localdomain 疎通確認 お互いに通信できるか確認します。
Pacemakerを使ってPostgreSQLのアクティブ・スタンバイ(1+1構成)を試してみた · hnakamur's blog
2016-08-21 はじめに STONITH無し、quorum無しのアクティブ・スタンバイ(1+1構成)がとりあえず動くところまでは来たので、一旦メモです。 参考資料 以下の資料と連載記事がわかりやすくて非常に参考になりました。ありがとうございます！ JPUG 第23回しくみ+アプリケーション勉強会 セミナー資料公開 « Linux-HA Japan HAクラスタでPostgreSQLを高可用化(前編) ～Pacemaker入門編～(PDF) PostgreSQLを高可用化(後編) 〜レプリケーション編〜(PDF) OSC 2013 Tokyo/Spring 講演資料公開 « Linux-HA Japan Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築＠OSC 2013 Tokyo/Spring Pacemakerでかんたんクラスタリング体
Create new page · t-matsuo/resource-agents Wiki
Attach files by dragging & dropping, selecting or pasting them. Loading Uploading your files… We don’t support that file type. Try again with a GIF, JPEG, JPG, MOV, MP4, PNG, SVG or WEBM. Attaching documents requires write permission to this repository. Try again with a GIF, JPEG, JPG, MOV, MP4, PNG, SVG or WEBM. We don’t support that file type. Try again with a GIF, JPEG, JPG, MOV, MP4, PNG, SVG
PG-REXで学ぶPacemaker運用の実例
2015.10.3 にOSC2015 Fukuoka(＠九州産業大学）で講演した資料です。 PacemakerとPostgreSQLのレプリケーション機能を組み合わせた「PG-REX」(*)は、共有ディスクを使用しない安価な構成で、商用運用にも耐える可用性を実現することができます。 このPG-REXを含むPacemakerによるクラスタ構成は初期構築後、実際の故障が発生した際にその効果を発揮しますが、ログやコマンドが複雑で、フェイルオーバの原因を突き止めたり、 その後に正しい状態に復旧する方法がわからない、といった問い合わせを受けることが多々あります。 そこで、デモでも使用しているPG-REXを例として、故障内容によるPacemakerの挙動の違い、および原因解析方法、復旧方法を、実例を挙げながら網羅的にご説明します。 * PG-REXのコミュニティも立ち上げ、普及に努めています。 コミュ
PostgreSQL Automatic Failover
PostgreSQL Automatic Failover High-Availibility for Postgres, based on industry references Pacemaker and Corosync. **!!WARNING!!** The PAF project official repository has moved to the ClusterLabs organization. The ClusterLabs organization is managed by the Pacemaker community. website: https://clusterlabs.github.io/PAF/ sources: https://github.com/ClusterLabs/PAF FAQ: https://clusterlabs.github.io
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RHEL 7 – Pacemaker – Define the Resource Behaviour – Part 9 - UnixArena
High availability cluster in linux | Homer's Blog
CentOS7 2台でレプリケーション - Qiita
https://blog.enokawa.co/2016/10/27/set-specific-resource-the-migration-threshold-of-pcs/
ocf_heartbeat_redis: Redis server | resource-agents Miscellanea | Man Pages | ManKier
PostgreSQL9.1 同期レプリケーションと Pacemaker による高可用クラスタ化の紹介
7.3. 接続状態が変化したためリソースの移動を行う Red Hat Enterprise Linux 6 | Red Hat Customer Portal
Clusters from Scratch
PowerPoint プレゼンテーション