Paragon Insights時系列データベース(TSDB)

歴史的背景

HealthBotリリース3.0.0より前のリリースでは、Paragon Insightsをシングルノードとして実行したか、マルチノード(Docker Ccompose)インストールとして実行したかに関係なく、TSDBインスタンスは1つでした。 図 1 に、これの概要を示します。

この配置では、TSDBのスケーリングや冗長性の余地はありませんでした。冗長性がなければ、高可用性(HA)はありません。障害が発生すると、操作を続行したり、不足しているデータを復元したりする方法がなくなりました。このトポロジーにDocker Composeノードを追加しても、TSDBのパフォーマンスを犠牲にして、Paragon Insightsの処理能力が高まるだけです。

TSDB の改善

これらの問題に対処し、TSDBの高可用性(HA)を提供するために、HealthBotリリース3.0.0に3つの新しいTSDB要素が導入され、他のParagon Insightsマイクロサービス用のParagon Insightsノード*のクラスターも導入されます。

• – TSDBのデータを保存し、Paragon Insightsを拡張するために利用できるサーバーまたはノードはいくつですか?

• –データのコピーをいくつ保持しますか?

• – TSDBからデータはどのように読み書きされますか?問題が発生した場合はどうなりますか?

メモ：

*Paragon Insightsは、Dockerベースのマイクロサービスを複数の物理サーバーまたは仮想サーバー(ノード)にクラスター化するためにKubernetesを使用しています。Kubernetesクラスターは、プライマリノードと複数のワーカーノードで構成されます。 healthbot setup Paragon Insightsマルチノードのインストール中に、インストーラはKubernetesプライマリノードとワーカーノードのIPアドレス(またはホスト名)を尋ねます。TSDB データベースに必要なレプリケーション係数に基づいて、必要な数のワーカー ノードをセットアップに追加できます。デプロイするノードの数は、少なくともレプリケーション係数と同じである必要があります。(詳細については、以下のセクションを参照してください)。

この説明では、KubernetesワーカーノードをParagon Insightsノードと呼びます。プライマリ ノードは、この説明では考慮されません。

データベースシャーディング

データベースシャーディングとは、特定のノードにデータを選択的に格納することです。選択したノードにデータを書き込むこの方法では、使用可能なTSDBノード間でデータが分散され、各TSDBインスタンスがデバイスからの時系列データの一部のみを処理するため、より大きなスケーリングが可能になります。

シャーディングを実現するために、Paragon Insightはデバイスグループ/デバイスペアごとに1つのデータベースを作成し、結果のデータベースを1つ(または複数)のParagon InsightsノードでホストされているTSDBの特定の(システムによって決定された)インスタンスに書き込みます。

たとえば、D1 と D2 の 2 つのデバイスと、G1 と G2 の 2 つのデバイス グループがあるとします。D1 がグループ G1 と G2 に存在し、D2 がグループ G2 にのみ存在する場合、G1:D1、G2:D1、G2:D2 の 3 つのデータベースが作成されます。各データベースは、下の 図2 に示すように、個別のParagon Insightsノードにある独自のTSDBインスタンスに保存されます。新しいデバイスがオンボーディングされ、デバイスグループ内に配置されると、Paragon Insightsはそのデバイス/デバイスグループのデータを保存するTSDBデータベースインスタンスを選択します。

上の図2は、3つのParagon Insightsノードを示しており、それぞれにTSDBインスタンスと他のParagon Insightsサービスが実行されています。

メモ：

• TSDBインスタンスは、特定のParagon Insightsノード上で最大1つまで許可されます。そのため、Paragon Insightsノードは、いつでも0個または1個のTSDBインスタンスを持つことができます。

• Paragon Insightsノードは、TSDB機能の実行専用にすることができます。これが完了すると、そのノードで他のParagon Insights関数は実行されなくなります。これにより、他のParagon Insights機能がリソースのTSDBインスタンスを枯渇させるのを防ぎます。

• 最高のパフォーマンスを提供するために、ノードを TSDB 専用にすることをお勧めします。

• Paragon InsightsおよびTSDBノードは、Paragon Insights CLIを使用して、実行中のシステムに追加できます。

データベース レプリケーション

他のデータベース システムと同様に、レプリケーションとは、複数のノード上の複数のインスタンスにデータを格納することを指します。Paragon Insightでは、必要なデータベースのコピー数を決定するためのレプリケーション係数を設定します。

レプリケーション係数が 1 の場合、データのコピーは 1 つだけ作成されるため、HA は提供されません。複数のParagon Insightsノードが使用可能で、レプリケーション係数が1に設定されている場合、シャーディングのみが達成されます。

レプリケーション係数によって、必要なParagon Insightsノードの最小数が決まります。レプリケーション係数が3の場合、データのコピーが3つ作成され、少なくとも3つのParagon Insightsノードが必要で、HAが提供されます。レプリケーション係数が高いほど、HAが強くなり、Paragon Insightsノードに関するリソース要件が高くなります。システムをさらに拡張したい場合は、レプリケーション係数の正確な倍数、または3、6、9などでParagon Insightsノードを追加する必要があります。

前述のデバイス/デバイスグループのペアに基づいて、Paragon Insightsが20個のデータベースを作成した例を考えてみましょう。問題のParagon Insightsシステムのレプリケーション係数は2で、4つのノードがTSDBを実行しています。これに基づいて、2 つの TSDB レプリケーション グループが作成されます。この例では、TSDBグループ1とTSDBグループ2です。以下の図 3 では、データベース 1 から 10 からのデータが、TSDB グループ 1 の TSDB インスタンス 1 および 2 に書き込まれています。データベース 11 から 20 からのデータは、TSDB グループ 2 の TSDB インスタンス 3 および 4 に書き込まれます。TSDB インスタンスの周囲のアウトラインは、TSDB レプリケーショングループを表します。レプリケーショングループのサイズは、レプリケーション係数によって決まります。

データベースの読み取りと書き込み

図2に示すように、Paragon Insightsでは分散型メッセージングキューを利用できます。特定のTSDBインスタンス内でパフォーマンスの問題またはエラーが発生した場合、これにより、データベースへの書き込みを順次実行して、すべてのデータが適切な時間順序で書き込まれるようにすることができます。

すべてのParagon Insightsマイクロサービスは、標準化されたデータベースクエリ(読み取り)および書き込み関数を使用します。この関数は、将来のある時点で基盤となるデータベースシステムが変更されても使用することができます。これにより、成長と将来の変更に柔軟性を持たせることができます。データベースシステムのその他の読込および書込機能には、以下のものがあります。

• 通常の操作では、データベース書き込みは TSDB グループ内のすべての TSDB インスタンスに送信されます。

• データベースの書き込みは、TSDB インスタンスあたり最大 1GB までバッファリングできるため、失敗した書き込みは成功するまで再試行できます。

• 問題が解決せず、バッファーがいっぱいになると、最も古いデータが削除され、新しいデータが使用されます。

• バッファリングがアクティブな場合、データベースの書き込みは順番に実行されるため、前の書き込み試行が成功するまで新しいデータを書き込むことはできません。

• データベースクエリ(読み取り)は、過去5分間に最も少ない書き込みエラーを報告したTSDBインスタンスに送信されます。すべてのインスタンスが同じように実行されている場合、クエリは必要なグループ内のランダムな TSDB インスタンスに送信されます。

Paragon Insights GUIでのTSDB設定の管理

Paragon Insights GUIを使用して、時系列データベース(TSDB)の設定を構成できます。

TSDB 設定を構成するには:

警告：

TSDBノードの選択、削除、または専用化は、一部のサービスが再起動され、Paragon InsightsGUIが応答しなくなる可能性が高いため、メンテナンス期間中に行う必要があります。

1. [ 設定 ] > [システム] を選択します。

   [システム設定] ページが表示されます。

2. [ 時系列データベース] をクリックします。

   TSDB 設定 ページが表示されます。

3. TSDB設定ページから、次のことができます。

   1. TSDB ノードとして使用するノードを ( TSDB ノード・ リストから) 1 つ以上選択します。

      (TSDBノードリストには、 TSDBノード として選択できるParagon Insightsインストールで使用可能なノードが表示されます。デフォルトでは、Paragon Insightsは1つのノードをTSDBノードとして自動的に選択します。)

   2. レプリケーション係数を設定するには、[ レプリケーション係数] テキスト ボックスに値を入力します (または矢印を使用して値を指定します)。

      (レプリケーション係数によって、必要なデータベースのコピー数が決まります。レプリケーション係数はデフォルトで 1 に設定されています)。

   3. ノードを TSDB ノードとして専用にするには、[ 専用 ] トグルをクリックしてオンにします。

      TSDB ノードでは、複数のマイクロサービスが実行されている場合があります。ただし、ノードを TSDB ノードとして専用にすると、そのノードは TSDB マイクロサービスのみを実行し、他のすべてのマイクロサービスの実行を停止します。

      メモ：

      • ノードが永続ボリューム (クラスター内のストレージ) に関連付けられている場合、そのノードを専用の TSDB ノードとして使用することはできません。

      • フェイルセーフメカニズムにより、すべてのParagon InsightsノードをTSDBノードとして専用にすることはできません。

   4. システムエラー(Paragon Insightsから障害が発生したTSDBノードを削除または交換する場合)を無視するには、[ 強制 ]トグルをクリックしてオンにします。

      例えば、TSDB ノードに障害が発生し、そのノードの複製係数が 1 に設定されている場合、そのノードの TSDB データは失われます。このシナリオでは、障害が発生したTSDBノードをParagon Insightsから削除する必要があります。ただし、障害が発生したノードを新しいノードに交換しようとすると、レプリケーション係数が 1 に設定されているため、ノードのバックアップがシステム エラーで失敗します。ノードの交換を続行する場合は、[ 強制 ] トグルをオンにする必要があります。

   5. TSDB ノードの名前の横にある [X ] をクリックして、以前に TSDB ノードとして割り当てたノードを削除します。このノードは、新しい構成変更をデプロイすると、TSDB ノードとして削除されます。

4. 次のいずれかの操作を行います。

   • 「 保存 」をクリックして、TSDB ノードに変更を適用せずに、構成の変更のみをデータベースに保存します。

     設定の変更は、後でコミット(またはロールバック)する必要があります。詳細については、 Paragon Insightsの設定変更のコミットまたはロールバックを参照してください。

   • 「保存 & デプロイ」をクリックして、構成の変更をデータベースに保存し、変更を TSDB ノードに適用します。

5. 表示されるポップアップで、[ OK ]をクリックして確認します。

   「TSDB 設定」ページに戻ります。

Paragon Insights CLI設定オプション

Paragon Insights CLIは、システムからTSDBノードを追加およびシステムから削除し、結果としてレプリケーション係数を変更する手段を提供します。

TSDBノードをParagon Insightsに追加する

または

レプリケーション係数の管理

レプリケーション係数を、システムに存在する TSDB ノードの数の倍数に設定します。TSDB ノードが 2 つある場合は、レプリケーション係数を 2、4、6 などに設定します。

Usage Notes

• Paragon Insightsはpingを実行して、新しいノードが到達可能かどうかを判断します。ping が失敗すると、警告が表示されます。

• 専用オプションは、TSDB ノードが TSDB 機能のみを実行するかどうかを指定します。