完璧なオープンソースのタスク スケジューラ

サーバー上で信頼性と回復力を備えた方法で実行する必要がある定期的なタスクはこれまで以上に増えていますが、回復力を達成するのは信頼性よりも困難です。

Unix システムでは cron を使用して、Windows システムではタスク スケジューラを使用してスクリプトをスケジュールできますが、どちらも回復力がありません。これらの cron タスクを実行しているマシンがクラッシュすると、タスクは実行されません。

障害が発生したマシンは、比較的早くオンラインに復帰する可能性があります。また、「anacron」などの拡張 cron を実行していれば、見逃したジョブに追いつくかもしれません。しかし、1 時間ごとに実行するようにスケジュールされたタスクは、おそらく時間通りに完了しないでしょう。キャッチアップを実行すると、事態がさら​​に悪化する可能性があります。必要なのは、あるマシンに障害が発生しても、別のマシンが時間通りにタスクを実行できるようにするための、ある種のフェイルオーバーです。

私たちは、ハートビートと Disaster Recovery Block Device (DRBD) を使用して、クライアント用にこのようなシステムを 2 台の Linux マシンに実装しました。このクライアントは、これら 2 台のマシンから 2 セットのサービスを実行し、通常の状態では各マシンで 1 セットが実行されます。

1 台のマシンがサービスを停止した場合、そのサービスはもう 1 台のマシンにフェイルオーバーされます。ハートビートを使用して各マシンが他のマシンを監視できるようにし、障害が発生した場合にサービスを引き継ぐことができます。このサービス切り替えの一部には、DRBD を使用して実装された単純なクラスター ファイル システムが含まれます。

ハートビートを使用して各マシンが他のマシンを監視できるようにし、障害が発生した場合にサービスを引き継ぐことができます。このサービス切り替えの一部には、DRBD を使用して実装された単純なクラスター ファイル システムが含まれます。

通常の運用では、各マシンは各サービスのファイルの独自のコピーを読み書きし、DRBD がそれらの変更を他のマシンにコピーするため、フェイルオーバーが発生した場合、フェイルオーバーされたサービスはファイルの最新のコピーにアクセスできるようになります。 (通常、各マシンは自身のサービスのファイルのみを参照し、他のマシン上のファイルは参照できません)。

ハートビートと DRBD のこの組み合わせは、Web サービス (プライマリ アプリケーション) などのサービスにはうまく機能しますが、さまざまな通常のタスクをあるマシンから別のマシンにフェイルオーバーする必要もありました。同じ crontab を各マシンに配置することでこれを実装しました。これにより、各マシンはフェイルオーバーの場合にどのようなタスクを実行する必要があるかを認識し、ファイル システムにスクリプトを含めることができます。

次に、サービス タスクが存在するかどうかをチェックするスクリプトを各タスクの前に付けます。各マシンは通常、自分のサービスのファイルのみを参照するため、他のマシンのタスク ファイルはフェイルオーバーが進行中の場合にのみ表示されます。このかなり複雑なスキーマにより、回復力のある cron の形式を実装できますが、問題がないわけではありません。

まず第一に、このシステムは複雑であり、第二に、人間による安全性がありません。新しいタスクが必要な場合は、それを両方のマシンに忘れずに追加する必要があります。 3 番目に、障害が発生した場合、またはさらに悪いことに、障害が発生してスケジュールされたタスクの途中でサービスが「フェールバック」した場合に、実行中のタスクに何が起こるかに関して、あらゆる種類の境界条件が存在します。

最後に、これは拡張性がありません。あるノードから別のノードにサービスが失敗する可能性がありますが、複数の障害が発生する可能性がある同一のマシンからなる大規模なサーバー ファームでは機能しません。

この最後のポイントで、cron ベースのソリューションの本当の問題がわかります。 Cron とタスク スケジューラは、単一のマシン上で定期的なハウスキーピング タスクを実行するようにのみ設計されていますが、マシンのコレクションからサービスを提供する場合、すべての単一のマシンが単一障害点になります。