2つのDebianサーバーを使用して、一度に1つのサーバーでのみ呼び出すことができるcronジョブ用の強力なフェイルオーバー環境をセットアップする必要があります。
/etc/cron.d内のファイルを移動するとうまくいくはずですが、そのようなアクションを実行する簡単なHAソリューションはありますか?そして、可能であればハートビートではありません;)
2つのDebianサーバーを使用して、一度に1つのサーバーでのみ呼び出すことができるcronジョブ用の強力なフェイルオーバー環境をセットアップする必要があります。
/etc/cron.d内のファイルを移動するとうまくいくはずですが、そのようなアクションを実行する簡単なHAソリューションはありますか?そして、可能であればハートビートではありません;)
回答:
ハートビート/ペースメーカーが最良の解決策になると思います。ジョブが一度に1つのホストでのみ実行されるようにするために、多くの競合状態やフェンシングなどを処理できるからです。自分で何かを設計することは可能ですが、それらのパッケージが行うすべてのシナリオを考慮していない可能性が高く、最終的には、すべてではないにしても、ほとんどのホイールを置き換えることになります。
そのようなことを本当に気にせず、より簡単な設定が必要な場合。サーバー上のcronジョブを数分ずらすことをお勧めします。次に、ジョブがプライマリで開始すると、ジョブが操作する共有リソースにマーカーを残すことができます(これは指定しないため、意図的にあいまいにしています)。データベースの場合、テーブルのフィールドを更新したり、共有ファイルシステム上にある場合はファイルをロックしたりできます。
2番目のサーバーでジョブを実行すると、マーカーの存在を確認し、マーカーがある場合は中止できます。
要件に応じて2つの方法を使用します。どちらの場合も、cronが存在し、すべてのマシンから実行されますが、少しの妥当性チェックが含まれます。
マシンがプライマリとセカンダリ(複数のセカンダリがある場合があります)の関係にある場合、スクリプトが変更され、それらが実行されているマシンがプライマリ状態であるかどうかが確認されます。そうでない場合は、静かに終了します。現在手元にあるHB設定はありませんが、この情報についてHBに問い合わせることができると思います。
すべてのマシンが適格なプライマリーである場合(クラスター内など)、いくつかのロックが使用されます。共有データベースまたはPIDファイルを使用します。ロック状態を取得するマシンと、静かに終了しないマシンは1つだけです。
簡単に言えば、cronスクリプトをある種のクラスター対応アプリケーションに変換する必要があります。必要なだけの軽量または大容量の実装であっても、プライマリノードのフェイルオーバー後にアクションを適切に再開/再開(または状態を回復)できることが必要です。些細なケースは、それらがステートレスプログラム(または「ステートレス十分」なプログラム)であり、いつでも簡単に再起動でき、問題なく動作することです。これはおそらくあなたのケースではありません。ステートレスプログラムの場合、すべてのノードで並列に実行するだけでよいため、フェイルオーバーは必要ありません。
通常複雑なケースでは、スクリプトはクラスターの共有ストレージ上にあり、その状態をファイルに保存し、ディスクに保存された状態をアトミックにのみ変更し、起動時に検出する一時的な状態からアクションを続行できる必要があります。
実際には、この領域で満足できる解決策はありません。私たちはそれらすべてを試しました。スクリプトソリューション、ハートビート/ペースメーカーを使用したcronなど。最近まで、唯一のソリューションはグリッドソリューションでした。当然、これは、グリッドソリューションがシナリオのやり過ぎよりも少し多いように私たちが見たいものではありません。
それが私がCronBalancerプロジェクトを始めた理由です。分散、負荷分散、HA(終了時)であることを除いて、通常のcronサーバーとまったく同じように機能します。現在、最初の2つのポイントは完了しており(ベータ版)、標準のcrontabファイルで動作します。
HAフレームワークが整っています。あとは、フェイルオーバーとリカバリーのアクションを決定するために必要なシグナリングだけです。
http://sourceforge.net/projects/cronbalancer/
チャック
Nagios イベントハンドラーを単純なソリューションとして使用していました。
NRPEサーバーで:
command[check_crond]=/usr/lib64/nagios/plugins/check_procs -c 1: -C crond
command[autostart_crond]=sudo /etc/init.d/crond start
command[stop_crond]=sudo /etc/init.d/crond stop
nagios
sudoersグループにユーザーを追加することを忘れないでください:
nagios ALL=(ALL) NOPASSWD:/usr/lib64/nagios/plugins/, /etc/init.d/crond
そして無効化requiretty
:
Defaults:nagios !requiretty
Nagiosサーバーで:
services.cfg
define service{
use generic-service
host_name cpc_3.145
service_description crond
check_command check_nrpe!check_crond
event_handler autostart_crond!cpc_2.93
process_perf_data 0
contact_groups admin,admin-sms
}
commands.cfg
define command{
command_name autostart_crond
command_line $USER1$/eventhandlers/autostart_crond.sh $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$ $ARG1$
}
autostart_crond.sh
#!/bin/bash
case "$1" in
OK)
/usr/local/nagios/libexec/check_nrpe -H $4 -c stop_crond
;;
WARNING)
;;
UNKNOWN)
/usr/local/nagios/libexec/check_nrpe -H $4 -c autostart_crond
;;
CRITICAL)
/usr/local/nagios/libexec/check_nrpe -H $4 -c autostart_crond
;;
esac
exit 0
しかし、リソースが一度に1つのノードでのみ実行されることを保証する最良のソリューションであるため、PacemakerとCorosyncの使用に切り替えました。
これが私がやったことの手順です:
crond initスクリプトがLSBに準拠していることを確認します。私のCentOSでは、要件に合わせて終了ステータスを1から0に変更する必要があります(実行を開始するか、停止を停止する場合)。
start() {
echo -n $"Starting $prog: "
if [ -e /var/lock/subsys/crond ]; then
if [ -e /var/run/crond.pid ] && [ -e /proc/`cat /var/run/crond.pid` ]; then
echo -n $"cannot start crond: crond is already running.";
failure $"cannot start crond: crond already running.";
echo
#return 1
return 0
fi
fi
stop() {
echo -n $"Stopping $prog: "
if [ ! -e /var/lock/subsys/crond ]; then
echo -n $"cannot stop crond: crond is not running."
failure $"cannot stop crond: crond is not running."
echo
#return 1;
return 0;
fi
次に、以下を使用してPacemakerに追加できます。
# crm configure primitive Crond lsb:crond \
op monitor interval="60s"
crm構成ショー
node SVR022-293.localdomain
node SVR233NTC-3145.localdomain
primitive Crond lsb:crond \
op monitor interval="60s"
property $id="cib-bootstrap-options" \
dc-version="1.1.5-1.1.el5-01e86afaaa6d4a8c4836f68df80ababd6ca3902f" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
stonith-enabled="false" \
no-quorum-policy="ignore"
rsc_defaults $id="rsc-options" \
resource-stickiness="100"
CRMステータス
============
Last updated: Fri Jun 7 13:44:03 2013
Stack: openais
Current DC: SVR233NTC-3145.localdomain - partition with quorum
Version: 1.1.5-1.1.el5-01e86afaaa6d4a8c4836f68df80ababd6ca3902f
2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ SVR022-293.localdomain SVR233NTC-3145.localdomain ]
Crond (lsb:crond): Started SVR233NTC-3145.localdomain
3.145でPacemakerとCorosyncを停止してフェイルオーバーをテストします。
[root@3145 corosync]# service pacemaker stop
Signaling Pacemaker Cluster Manager to terminate: [ OK ]
Waiting for cluster services to unload:...... [ OK ]
[root@3145 corosync]# service corosync stop
Signaling Corosync Cluster Engine (corosync) to terminate: [ OK ]
Waiting for corosync services to unload:. [ OK ]
次に2.93でクラスターのステータスを確認します。
============
Last updated: Fri Jun 7 13:47:31 2013
Stack: openais
Current DC: SVR022-293.localdomain - partition WITHOUT quorum
Version: 1.1.5-1.1.el5-01e86afaaa6d4a8c4836f68df80ababd6ca3902f
2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ SVR022-293.localdomain ]
OFFLINE: [ SVR233NTC-3145.localdomain ]
Crond (lsb:crond): Started SVR022-293.localdomain