Apache Ignite 2.4のBaselineTopologyコンセプト

Igniteプロジェクトは、Apache Software Foundationに登場した時点で、純粋なインメモリソリューションとして位置付けられていました。アクセス時間を確保するために、従来のDBMSからメモリにデータを取り込む分散キャッシュです。 しかし、すでにリリース2.1にはビルトイン永続性（ Native Persistence ）のモジュールがあり、Igniteを完全な分散データベースとして分類できます。 それ以来、Igniteは永続的なデータストレージを提供するために外部システムに依存することをやめ、ユーザーが複数回踏み込んだ構成と管理のレーキのバンドルはなくなりました。

ただし、永続モードには独自のスクリプトと新しい質問があります。 スプリットブレインの状況で解決できないデータの競合を防ぐ方法 ノードの出力がそのデータが失われることを意味しない場合、パーティションの再バランスを拒否できますか？ クラスターのアクティブ化などの追加アクションを自動化する方法は？ 役立つベースライントポロジ。

ベースライントポロジ：最初の知り合い

概念的には、インメモリモードのクラスターは単純です。専用ノードはなく、すべて同等であり、それぞれにキャッシュパーティションを割り当てたり、計算タスクを送信したり、サービスをデプロイしたりできます。 ノードがトポロジを離れると、ユーザー要求は他のノードによって処理され、終了したノードのデータは使用できなくなります。

永続モードでは、ノードは再起動後も状態を保持します。開始プロセス中に、ノードデータがディスクから読み取られ、その状態が復元されます。 したがって、ノードを再起動しても、クラスター内の他のノードからデータを完全にコピーする必要はありません（リバランスと呼ばれるプロセス）。フォール時のデータはローカルディスクから復元されます。 これにより、ネットワークインタラクションの非常に魅力的な最適化の機会が開かれ、その結果、クラスター全体の生産性が向上します。 そのため、再起動後に他のすべてのノードから状態を維持できる多くのノードを何らかの形で区別する必要があります。 BaselineTopologyはこのタスクを提供します。

ユーザーがインメモリキャッシュと同時に永続キャッシュを使用できることに注意してください。 後者は以前と同じ寿命を続けます：すべてのノードが同等で互換性があることを考慮し、ノードが終了してデータコピーの数を維持するときにパーティションの再分散を開始します-BaselineTopologyは永続キャッシュの動作のみを規制します。

最高レベルのBaselineTopology（以降BLT）は、データを格納するように構成されたノード識別子のコレクションです。 クラスター内でBLTを作成して管理する方法については、後ほど説明しますが、実際にこれがどのような概念に役立つかを見てみましょう。

永続データ：ドライブなし

スプリットブレインとして知られる分散システムの問題は、永続性の使用がさらに潜行的になると、すでに複雑になっています。

簡単な例：クラスターと複製されたキャッシュがあります。

次の順序で簡単な操作を実行します。

1. クラスターを停止し、ノードグループAを起動します。
2. キャッシュ内のキーを更新します。
3. グループAを停止し、グループBを開始します。
4. 同じキーに対して他の更新を適用します。

Igniteはデータベースモードで動作するため、2番目のグループのノードが停止しても、更新は失われません。2番目のグループを再度開始するとすぐに利用可能になります。 そのため、クラスターの初期状態を復元した後、同じキーに対して異なるノードが異なる値を持つことができます。

ノードを単に停止および起動するだけで、あまり熱狂せずに、クラスター内のデータを未定義の状態にすることができました。これは自動的に解決することはできません。

この状況を防ぐことは、BLTのタスクの1つにすぎません。

考え方は、永続モードでは、クラスターの起動は追加の段階であるアクティベーションを経ることです。

最初のアクティベーションで、最初のBaselineTopologyが作成され、ディスクに保存されます。これには、アクティベーション時にクラスターに存在するすべてのノードに関する情報が含まれています。

この情報には、オンラインノードの識別子に基づいて計算されたハッシュも含まれます。 後続のアクティブ化中にトポロジに一部のノードが存在しない場合（たとえば、クラスターが再起動され、サービスのために1つのノードが取り出された場合）、ハッシュが再計算され、以前の値が同じBLT内のアクティブ化履歴に保存されます。

したがって、BaselineTopologyは、各アクティベーション時のクラスターの構成を記述するハッシュのチェーンを維持します。

ステージ1および3では、ノードグループを開始した後、ユーザーは明示的に不完全なクラスターをアクティブ化する必要があり、各オンラインノードはローカルにBLTを更新して新しいハッシュを追加します。 各グループのすべてのノードは同じハッシュを計算できますが、異なるグループでは異なることになります。

あなたはすでに次に何が起こるかを推測できました。 ノードが「外部」グループに参加しようとすると、このグループのノードに関係なくノードがアクティブ化されていると判断され、アクセスが拒否されます。

この検証メカニズムは、スプリットブレイン状況での競合に対する完全な保護を提供しないことに注意してください。 クラスターの半分以上にパーティションのコピーが少なくとも1つ残るようにクラスターが2つの半分に分割され、半分が再アクティブ化されない場合、同じデータの競合する変更が半分になって到着する可能性があります。 BLTはCAP定理に反論しませんが、明らかな管理エラーとの競合を防ぎます。

パン

データの競合を防ぐことに加えて、BLTでは、いくつかのオプションではあるが素晴らしいオプションを実装できます。

お団子1-マイナス1つの手動アクション。 上記のアクティベーションは、クラスターを再起動するたびに手動で実行する必要がありました。 「すぐに使える」自動化ツールはありませんでした。 BLTが存在する場合、クラスターはアクティブ化を個別に決定できます。

Igniteクラスターは弾力性のあるシステムであり、ノードを動的に追加および表示できますが、BTLはデータベースモードではユーザーが安定したクラスター構成を維持するという概念に基づいています。

クラスターが最初にアクティブ化されると、新しく作成されたBaselineTopologyは、トポロジに存在するノードを記憶しています。 再起動後、各ノードは他のBLTノードのステータスを確認します。 すべてのノードがオンラインになるとすぐに、クラスターが自動的にアクティブになります。

Bun No. 2-ネットワークの節約。 この考え方は、トポロジが長期間安定したままになるという前提に基づいています。 以前は、ノードが10分間トポロジーを終了しても、キャッシュパーティションのリバランスが開始され、バックアップの数が維持されていました。 しかし、ノードの問題が数分以内に解決され、再びオンラインになる場合、ネットワークリソースを浪費し、クラスターの速度を低下させる理由は何ですか。 BaselineTopologyはこの動作を最適化します。

現在、デフォルトのクラスターは、問題のあるノードがすぐにサービスに戻ると想定しています。 この期間中の一部のキャッシュは、より少ないバックアップで機能しますが、これによりサービスの中断や速度低下は発生しません。

ベースライントポロジ管理

さて、すでに1つの方法を知っています。BaselineTopologyは、クラスターの最初のアクティブ化時に自動的に作成されます。 同時に、アクティベーション時にオンラインであったすべてのサーバーノードがBLTに含まれます。

BLTの手動管理は、Igniteディストリビューションの制御スクリプトを使用して実行されます。詳細については、クラスターのアクティベーションに関するドキュメントページをご覧ください 。

このスクリプトは非常に単純なAPIを提供し、ノードの追加、ノードの削除、新しいBaselineTopologyのインストールの3つの操作のみをサポートします。

さらに、ノードの追加が特別なトリックのない非常に単純な操作である場合、BLTからアクティブノードを削除することはより微妙なタスクです。 負荷がかかった状態での実行には、最悪の場合、クラスター全体の凍結というレースが伴います。 したがって、削除には追加の条件が伴います。削除されたノードはオフラインでなければなりません。 オンラインノードを削除しようとすると、制御スクリプトはエラーを返し、操作は開始されません。

したがって、BLTからノードを削除する場合、ノードの停止という1つの手動操作が依然として必要です。 ただし、このユースケースは明らかに主なものではないため、追加の人件費はそれほど大きくありません。

BLTを管理するためのJavaインターフェースはさらにシンプルであり、ノードのリストからBaselineTopologyをインストールする1つの方法を提供するだけです。

Java APIを使用してBaselineTopologyを変更する例：

Ignite ignite = /* ... */; IgniteCluster cluster = ignite.cluster(); //  BaselineTopology. Collection<BaselineNode> curBaselineTop = cluster.baselineTopology(); for (ClusterNode node : cluster.topology(cluster.currentTopologyVersion())) { //   ,      BaselineTopology // (shouldAdd(ClusterNode) -  ) if (shouldAdd(node) curTop.add(node); } //  BaselineTopology cluster.setBaselineTopology(curTop);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

データの整合性を確保することは、データウェアハウスが解決しなければならない最も重要なタスクです。 Apache Igniteを含む分散DBMSの場合、この問題の解決策は非常に複雑になります。

BaselineTopologyの概念により、データの整合性が損なわれる可能性のある実際のシナリオのいくつかを閉じることができます。

Igniteのもう1つの優先事項はパフォーマンスです。ここで、BLTはリソースを大幅に節約し、システムの応答時間を改善できます。

ネイティブパーシステンス機能はごく最近プロジェクトに登場し、間違いなく開発され、信頼性が高まり、生産性が向上し、使いやすくなります。 それに伴い、BaselineTopologyの概念も発展します。