13

クラウド (AWS、Heroku、またはセルフマネージド VMS) で大規模なノード クラスターを実行したいと考えています。そのクロックは、事前に定義された許容範囲を念頭に置いて同期する必要があります。おそらく200ミリ秒の許容範囲を探しています。つまり、250 個のノードがある場合、250 個のノード間の最大クロック差が 200 ミリ秒を超えることはありません。世界に対する実際の日付/時刻はあまり気にしません。ソリューションはフォールト トレラントでなければならず、どのシステムのクロックの精度にも依存する必要はありません。実際、どのクロックもそれほど正確ではない可能性があります。

要件は十分に強く、何らかの理由で特定のノードのクロック同期が信頼できないと判断された場合、クロックの非同期化のためにクラスターからノードを削除することをお勧めします。そのため、障害が疑われる場合は、そのノードのある種の制御されたシャットダウンを実行できるようにしたいと考えています。

NTP のようなものを使いたいのですが、NTP の既知の問題 twikiによると:

NTP は、仮想マシン内で実行するようには設計されていません。これには、高精度で処理されるクロック割り込みへの応答時間を備えた、高分解能のシステム クロックが必要です。これらの要件を満たすことができる既知の仮想マシンはありません。

そして、同じ twiki が状況に対処するためのさまざまな方法 (ホスト OS で ntp を実行するなど) を説明していますが、AWS または horoku を使用して環境を十分に変更して準拠することができるとは思いません。回避策。

私が VM で実行していなかったとしても、ntp を実行してきた長年の経験を持つ信頼できる運用管理者は、時々ローカル クロックのずれが原因で、ntp が同期をドロップする可能性があり、ドロップする (または単純に時刻を間違える) ことを教えてくれます。頻繁に発生するわけではありませんが、実際に発生します。マシンを増やすと、これが発生する可能性が高くなります。私の知る限り、自分がどれだけ離れているかを検出するには、ntpd を停止し、クエリ モード コマンドを実行して、再度起動する必要があり、応答を得るまでに長い時間がかかる場合があります。

要約すると、主な目標は次のとおりであるクロック同期が必要です。

  • 運用制御が制限されている VM (つまり、「クラウド サービス プロバイダー」) で適切に実行されます。
  • すべての参加者間で約 200 ミリ秒のクラスター内の時間許容誤差
  • 不良ノードを検出し、積極的に対応する機能
  • 耐障害性 (単一障害点なし)
  • スケーラブル (ノードを追加しても倒壊することはありません。n^2 は絶対に避けてください)
  • 何百ものノードをサポートできます
  • どのノードも、他のどのノードよりも優れた時間の概念を持っていると見なされるべきではありません
  • 一斉にドリフトする限り、クラスター全体が (合理的な範囲内で) ドリフトしても問題ありません。

説明からすると、ここではBerkeley Algorithmが正しい選択のように思えますが、それは既に実装されていますか?

あると便利:

  • 最小限の構成 (参加するノードの自動登録) -- 新しいノードを起動するために重要
  • クロック同期に参加しているノードと相対時間オフセットをレポートする HTML ダッシュボードまたは (REST?) API
  • きれいなグラフ？
4

2 に答える 2

2

NTP の FAQ には、NTP 時刻同期が仮想マシンで「正しく」機能しない理由が具体的に記載されているため、おそらく克服できない問題です。

ほとんどのマシンにはRTC（リアルタイムクロック）があり、PCでは時間を保存する方法があるため、ntpが利用できない場合の時間について「大まかな」推測ができます。システムがロードされると、「より高い解像度である目盛りの時計-それがNTPの設定です。

ティックは正しい間隔で発生する場合と発生しない場合があるため、そのティック クロックは仮想マシンのドリフトの影響を受けます。使用しようとするメカニズムは常にそのドリフトの影響を受けます。

マシン A と B に 200 ミリ秒のデルタがあり、マシン B と C に 200 ミリ秒のデルタがある場合、仮想マシンで ntp 同期を強制しようとするのはおそらく最適ではない設計です。C は A から 400 ミリ秒離れている可能性があります。それを制御することはできません。

zeromq のような集中型メッセージング システムを使用して全員をジョブ キューと同期させた方がよいでしょう。オーバーヘッドは大きくなりますが、システムのティック タイムに依存するのは危険な作業です。あらゆる種類の信頼できるメカニズムを使用してクラスターへの参加を説明する多くのクラスタリング ソリューションがあり、全員が同期していることを確認し、corosync やスプレッドを確認します。2 フェーズ コミットなどについては、既に解決済みです。

ちなみに、ドリフトが高すぎる場合の ntp の「放棄」は、時間を「スルー」ではなく新しい値に「スラム」するように指示することで回避できます。デフォルトでは、ntp は「リアルタイム」からのずれを考慮して、システム時間を段階的に更新します。ntpd でこれを構成する方法を忘れましたが、ntpdate を使用する場合、フラグは -B です

-B      Force the time to always be slewed using the adjtime(2) system call, even if the measured 
offset is greater than +-128 ms.  The default is to step the time using settimeofday(2) if the offset 
is greater than +-128 ms.  Note that, if the offset is much greater than +-128 ms in this case, it
can take a long time (hours) to slew the clock to the correct value.  During this time, the host 
should not be used to synchronize clients.
于 2012-01-05T13:23:37.547 に答える