Cygnus の信頼性

コンテンツ :

永続性のリトライ

NGSI のための Cygnus は、永続化の試行が何らかの理由で失敗した場合のリトライ・メカニズムを実装しています。これは、次のパラメータに基づいています :

パラメータ 必須 デフォルト値 コメント
batch_ttl no 10 バッチを永続化できない場合のリトライ回数。リトライしない場合は 0 を、無限にリトライする場合は -1を指定してください。無限のTTL(非常に大きい値でさえ)がすべてのシンクのチャネル容量を非常に素早く消費するかもしれないと考えてください
batch_retry_intervals no 5000 永続化されていないバッチに関するリトライが行われるコンマ区切りの間隔(ミリ秒単位)のリスト。最初のリトライは、最初の値と同じ数ミリ秒後に実行され、2回目の再試行は2番目の値の後に完了します。batch_ttl が間隔の数より大きい場合、最後の間隔が繰り返されます

つまり、NGSI イベントの完全なバッチ(あるバッチに 1〜N の NGSI イベントが含まれている可能性があります)には、一定の回数のリトライまたは有効期間を設定する必要があります。さらに、リトライ頻度は設定する必要があります。一定ではなく、最初のリトライでは異なる可能性があります。

リトライのためのバッチは、使用されるチャネルのタイプに関係なくメモリに保存されます。これは、バッチ内の NGSI イベントがチャネルに再挿入されず、パフォーマンス目的でバッチとして集約されて維持されるためです。バッチは再度集計されません。これは、Cygnus が何らかの理由でシャットダウンやクラッシュすると、リトライのコンテキスト情報の候補が失われる可能性があることを意味します。いずれにしても、Cygnus のユーザには心配する必要はありません。なぜなら、永続化されたイベントは、Cygnus のようなリトライ・メカニズムなしでは失われないからです。

新しい着信 NGSI イベントおよびリトライ候補に関するディスパッチ・ポリシーは、現在ハードコードされています。リトライ(ある場合)を常に優先し、新しい着信イベント(存在する場合)を処理することに基づいています。これは、構成可能なポリシーの形で将来変更される可能性があります。いずれの場合でも、batch_retry_intervals パラメーターは、batch_ttl が -1 (常にリトライ)に設定されていても、新しい着信イベントがリトライの候補の間で常に処理されるようにします。

トップ

トラフィック・アブソープション・ピーク

Cygnus は Apache Flume を継承しているため、任意のタイプの Cygnus エージェントは、ソースとシンクを通信するチャネルの使用に基づいて内部アーキテクチャを継承します。この通信を達成することは別として、着信データのバッファとみなすことができるチャネルは、トラフィック・アブソープション・ピークのメカニズムとして機能します。

Cygnus for NGSI の特定のケースでは、これは、NGSI ソース(通常は Orion Context Broker)からの通知のピークをチャネルが吸収できることを意味し、構成済みシンクはデータの永続性を重視して動作します。もちろん、受信時間と持続時間に関するタイミングは、シンクが送信元よりも遅く動作するため)、データは失われません(一般的な consuming-producer 問題。

Cygnus 管理者は、Cygnus を含むアーキテクチャ全体の予想スループットを慎重に検討し、それを吸収するのに十分なチャネル容量を設定することによって、NGSI 通知の負荷を軽減しなければなりません。

トップ

ファイル・チャネル

ファイル・チャネルは Apache Flume の別の継承です。この種のチャネルはファイルに基づいており、メモリ・チャネルと異なり、この種のチャネル内の情報はクラッシュ間に存在します。

通知 レートが Cygnusのリカバリ時間よりも遅い場合、ファイル・チャネルを使用することは興味深いです。それから、何も失われません。そうでない場合、揮発性チャネルの代わりにファイル・チャネルを使用しても、大きな差はありません。これは、Cygnus がダウンしている間に新しい受信イベントが失われる可能性があるためです。

ファイル・チャネルは、何らかの種類の高可用性アーキテクチャを実装することが目的の場合に特に適切です。次のセクションを参照してください。

読者が想像しているように、ファイルベースのチャネルはメモリベースのチャネルよりも低速ですが、ファイルシークが遅いためです。したがって、エージェントに最適なチャネルタイプを決定する際には、信頼性とスピードの間にトレードオフがあります。

トップ

高可用性

Cygnus はそれ自体ハイアベイラビリティ(HA)メカニズムを実装していません。とにかく、Cygnus の HA を実装するのは、Cygnus の2つのインスタンスを実行し、それらと NGSI ソース(またはソース)の間にロードバランサを置くのが簡単です。もちろん、ロードバランサ自体は単一障害点です。これに対する解決策がありますが、このドキュメントの範囲外です。

                         +----------+
                         |  Cygnus  |  
                   +-----| (active) |-----+
                   |     +----------+     |
+-------+     +----+                      +---------+
| Orion |-----| LB |                      | backend |       
+-------+     +----+                      +---------+
                   |     +----------+     |
                   +-----|  Cygnus  |-----+
                         | (passive)|
                         +----------+

HA に関する重要な側面は、受動的な Cygnus エージェント(自動的にアクティブなエージェントになる)に移動する瞬間、アクティブな Cygnus エージェントのチャネル内のイベントで何が起こるかです。そのようなイベントがメモリベースのチャネル内にある場合、これらのイベントは失われ、何もできません。それにもかかわらず、チャネルがファイルに基づいている場合、イベントを回復することができます。実のところ、それらは実際には回復されませんが、同じマシンで実行されているアクティブなおよびパッシブな両方の Cygnus エージェントが同じデータとチェックポイントディレクトリを使用するように設定できるので、直接使用されます。アクティブおよびパッシブな Cygnus が共通の HA 構成である異なるマシンで実行されている場合でも、3台目のマシンがデータファイルをホストすることができます。この場合、3つのマシンに対して分散または共有ファイルシステムが構成されている場合、データファイルにアクセスできます。

                         +----------+
                         |  Cygnus  |
                   +-----| (active) |-----+
                   |     +-----+----+     |
                   |           |          |
+-------+     +----+   +-------+------+   +---------+
| Orion |-----| LB |   | channel data |   | backend |       
+-------+     +----+   | & checkpoint |   +---------+
                   |   +-------+------+   |
                   |           |          |
                   |     +-----+----+     |
                   +-----|  Cygnus  |-----+
                         | (passive)|
                         +----------+

トップ