高可用性cronジョブ
情報
現在、PHPを実行する（Centos 7上の）NGINX用の高可用性クラスターを作成しています。ほとんどの構成はマップされており、クラスター環境でうまく機能するはずです。
残念ながら、クラスタリングでニースをプレイするために理解できない唯一のことはcronジョブです（cronジョブはPHPコードを実行します）。私の知る限り、cronジョブは各ホストで個別に実行されます。これは、次のいずれかを意味します。
- 完全な高可用性環境がないようにしてください。単一サーバーに障害が発生すると、別のサーバーが引き継ぎ、すべてが以前と同じように動作します（低速ですが）。
- 各cronジョブを実行し、結果をデータベースに保存して、すでに実行されているかどうかを判断します。 一部のcronジョブは実行に数時間かかる可能性があるため、これは実行可能なソリューションではありません。これらのジョブは、翌営業日の前に実行する必要があります。
- 高可用性cronジョブの実行を可能にする何らかのソリューションが見つかります。
研究
solution 3が高可用性環境を維持するのにどのように役立つか、つまりを推奨メソッド。残念ながら、私たちはこれらのソリューションの一部についてはあまり詳しくありません。そのため、私たちのニーズに適したソリューションを見つけるのを手助けする専門知識を求めています。私たちはLinuxマシンにあまり慣れておらず（環境全体はNGINXサーバーを除いてWindowsです）、これらのマシンでの作業についてはほとんど知りません（ただし、これまでにそれを理解することはできました）。
オプション
- Dkron
- このソリューションは簡単なセットアップを提供しているようで、まともな製品のようです
- クロノス
- これは他の複数のユーティリティを使用して、実際のデータベースを含めて動作します（理想的ではありませんが、機能する可能性があります）
- Rundeck
- 多くの機能を提供しているようで、このリストで最高の製品である可能性があります
- Rcron
- Golangベースであることを除いて、私はこれについてあまりよく知りません。
- カスタムスクリプト： cronjobsを高可用性にする方法
- 他に何も機能しない場合、これは「他のすべてが失敗した場合」のアプローチです...
- 別のオプション？？？ -見つかった場合は他のオプションを提供してください。ここに含めます。
ご質問
- さまざまなオプションに対する専門家の意見や推奨事項は何ですか？
- さまざまなオプション（長所/短所）を使用して、どのような経験をしましたか？
- インフラストラクチャでどのオプションを使用することを検討しますか？ （インフラストラクチャに関する追加情報が必要な場合は、お知らせください）
ノート
これに関するどんな助けでも大歓迎です。
この質問が尋ねられたと思います before 、それはかなり古くなっているようですが（2011）、それ以来多くの新しいソリューションが作成されました。
RHEL/CentOS 7のcrondには、クラスタリングのサポートが含まれています。それは実際にはcronieであり、由緒あるvixie-cronのフォークです。以下は、manページの詳細です。
クラスター化のサポート
このバージョンのCronでは、ホストのクラスター全体でネットワークにマウントされた共有の/ var/spool/cronを使用し、一度に1つのホストのみがこのディレクトリでcrontabジョブを実行するように指定できます。これは、-cオプションを使用してCronを起動し、/ var/spool/cron/.cron.hostnameファイルに、クラスター内のホストがジョブを実行する必要があるホストのホスト名を表す1行だけを含めることで行われます。このファイルが存在しない場合、またはファイル内のホスト名がgethostname（2）によって返されるホスト名と一致しない場合、このディレクトリ内のすべてのcrontabファイルは無視されます。これは、/ etc/crontabファイルで指定されたcronジョブまたは/etc/cron.dディレクトリ内のファイルには影響しません。これらのファイルは常に実行され、ホスト固有と見なされます。
/var/spool/cron/.cron.hostnameを直接編集するのではなく、crontab（1）の-nオプションを使用してホストを指定します。
クラスター内のすべてのホストと、それらが共有crontabディレクトリーをマウントするファイルサーバーが、例えばntpd（8）を使用して、クロックが厳密に同期していることを確認する必要があります。そうしないと、結果が非常に予測不可能になります。
実際には、このアプローチには以下が必要です。
- すべてのクラスター化システムの/ var/spool/cronにマウントされた共有ファイルシステム。
- すべてのクラスター化システムは
crondを-cフラグで開始します（/ etc/sysconfig/crondにCRONDARGS=-cを配置）。そして - 何らかのトリガー。これにより、cronジョブを担当するシステムが失敗したときに、別のシステムが
crontab -nを実行して引き継ぎます。
警告に注意してください：このソリューションは、/ var/spool/cron内のcronジョブのみをクラスター化します（つまり、crontab -eで設定）。すべてのノードは引き続き/ etc/crontabまたは/etc/cron.dで個別のジョブを実行します。
なぜあなたのオプション（2）ではありませんが、実行中にフラグを作成します。 cronジョブはすべてのマシンで開始されますが、ローカルタイミングのわずかな変動により、最初にフラグが作成されます。その後、他のユーザーはフラグが設定され、救済されるのを確認します。
フラグの設定/チェックの原子性に注意を払う必要があります（NFSもここではオプションであり、ロックファイルを使用します）。ただし、これを最小限に保つために、どちらかに値がある場合もあります。
- 各cronジョブの開始時に小さなランダムスリープを設定して、少しずつ展開するか、
- 特定のジョブの開始時間をサーバー間で少なくとも1分ずつ変化させます。つまり、サーバー1は7:02に、サーバー2は7:03にジョブを開始します。通常、サーバー1はすべての作業を行いますが、サーバー1がダウンしている場合、サーバー2が7:03に開始したときにフラグが表示されません。