Vipnet Failover暗号ゲートウェイまたはフォールトトレランスを実装しない方法

約3年間、私はInfotex製品の統合に従事していました。 この間、私はその製品のほとんどに精通しており、一般的に、それらはロシアでそのような幅広い流通を受けたに値すると信じています。 主な利点としては、FSBおよびFSTEC証明書の存在、ソフトウェアとソフトウェアおよびハードウェアソリューションの両方を含む幅広い製品、簡単で便利なスケーリングとネットワーク管理、優れた技術サポート、便利なライセンス、インストールと設定の容易さ、そしてもちろんアナログと比較した価格。 もちろん不利な点もありますが、だれが持っていないのでしょうか？ しかし、私の意見では、ライン全体で最も失敗した製品はViPNet Failoverフェールオーバークラスターであり、その理由については後で説明します。



ドキュメントにあるように、ホットスタンバイクラスターモードは、最初のサーバーに障害が発生した場合に、ViPNetソフトウェアを備えたサーバーの機能を別のサーバーとホットスワップするように設計されています。 ホットスタンバイサーバークラスターは相互接続された2台のコンピューターで構成され、1台（アクティブ）はViPNetサーバー（コーディネーター）として機能し、もう1台（パッシブ）はスタンバイモードです。 アクティブサーバー上のViPNetソフトウェアのパフォーマンスにとって重要な障害の場合（主にネットワークまたはネットワーク機器の誤動作の場合）、パッシブサーバーはアクティブモードに切り替わり、負荷を引き受けて、障害を記録したサーバーの代わりにコーディネーターとして機能します。 ホットスタンバイクラスターモードで作業している場合、障害保護システムはシングルモードとしても機能します。つまり、ViPNet Coordinator Linuxソフトウェアの一部であるメインサービスの継続的な動作を保証します。



Vipnet Coordinator Linux自体は悪くなく、ホットスペアスキーム自体がすべてを損なうことに注意してください。



ネットワーク上の他のコンピューターの観点から見ると、クラスター全体のネットワークインターフェイスごとに1つのIPアドレスがあります。 このアドレスには、現在アクティブモードになっているサーバーがあります。 パッシブモードのサーバーには、クラスターとの通信に他のコンピューターが使用しない別のIPアドレスがあります。 アクティブモードアドレスとは異なり、パッシブモードでは、各サーバーは各インターフェイスに独自のアドレスを持ちます; 2つのサーバーのこれらのアドレスは一致しません。



failover.ini構成には、3種類のパラメーターセクションが含まれています。 [channel]セクションは、予約済みインターフェースのIPアドレスについて説明しています。

[channel] device= eth1 activeip= 192.168.10.50 passiveip= 192.168.10.51 testip= 192.168.10.1 ident= if-1 checkonlyidle= yes
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

[ネットワーク]セクションでは、バックアップオプションについて説明します。

 [network] checktime= 10 timeout= 2 activeretries= 3 channelretries= 3 synctime= 5 fastdown= yes
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

[sendconfig]には、2番目のサーバーのネットワークインターフェイスのアドレスが書き込まれます。このアドレスで、クラスター操作が同期されます。

 [sendconfig] device= eth0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

繰り返しますが、私はドキュメントからバックアップアルゴリズムを提供します：

アクティブサーバーで作業するためのアルゴリズムは次のとおりです。 checktime秒ごとに、構成にリストされている各インターフェースのヘルスがチェックされます。 checkonlyidleパラメーターがyesに設定されている場合、インターフェースを通過する着信および発信ネットワークトラフィックが分析されます。 間隔の開始と終了の間のパケット数の差が正の場合、インターフェイスは正常に機能していると見なされ、このインターフェイスの障害カウンタがリセットされます。 この間隔中にパケットが送受信されなかった場合、追加の検証メカニズムがアクティブになります。これは、最も近いルーターにpingを送信することです。 checkonlyidleパラメーターがnoに設定されている場合、メインチェックメカニズムの代わりに追加のチェックメカニズムが使用されます。つまり、checktime秒ごとにパケットがtestipアドレスに送信されます。 次に、タイムアウト時間中に、応答が期待されます。 インターフェイスのtestipアドレスから応答がない場合、そのエラーカウンターが増加します。 少なくとも1つのインターフェイスで障害カウンタがゼロでない場合、新しいパケットはすべてのtestipにすぐに送信され、タイムアウト以内に応答が期待されます。 失敗カウンタがゼロに等しくないインターフェイスへの新しい送信のプロセスで、応答が到着すると、失敗カウンタはリセットされます。 送信後にすべてのインターフェイスの障害カウンターがゼロになった場合、メインループに戻り、チェックタイム中に新しい待機が発生します。 特定の数の新しいパッケージの後に、少なくとも1つのインターフェイスの障害カウンターがchannelretries値に達すると、完全なインターフェイス障害が検出され、システムの再起動が開始されます。 したがって、障害保護システムが終了するまでにインターフェイスが動作しない最大時間は、 checktime +（timeout * channelretries）です。



パッシブサーバーでは、アルゴリズムはわずかに異なります。 checktime秒に1回、すべてのactiveipのシステムARPテーブルのエントリが削除されます。 次に、すべてのインターフェイスからのUDP要求がactiveipアドレスに送信されます。その結果、システムは最初にARP要求を送信し、応答を受信した場合にのみUDP要求を受信します。 タイムアウト応答間隔が経過すると、システムARPテーブル内の各activeipのARPレコードの存在が確認され、その存在によって、アクティブサーバー上の対応するインターフェイスの操作性について結論が下されます。 インターフェースから応答を受信しなかった場合、障害カウンター（すべてのインターフェースで唯一のカウンター）が増加します。 少なくとも1つのインターフェイスから応答を受信した場合、失敗カウンターはゼロにリセットされます。 障害カウンターがactiveretriesの値に達すると、アクティブモードに切り替わります。 アクティブサーバーを再起動してからパッシブサーバーがこの事実を検出するまでに経過する最大時間は、 checktime +（timeout * activeretries）に等しくなります。



クラッシュ中のシステムの合計稼働時間は、 checktime * 2 + timeout *（channelretries + activeretries）よりわずかに長い場合があります。 これは、障害が発生したサーバーの再起動の開始後、システムがすぐにではなく、他のサブシステムが停止した後、しばらくしてからインターフェイスをアイドル状態にするためです。 したがって、たとえば、2つのインターフェイスがチェックされ、1つだけが失敗した場合、2番目のインターフェイスのアドレスはしばらく使用可能になり、その間にパッシブサーバーは応答を受信します。 通常、再起動の開始からインターフェイスのシャットダウンまでの時間は30秒を超えませんが、コンピューターの速度とそこで実行されるサービスの数に大きく依存します。

アクティブなサーバーに問題が発生するとすぐに、すべてが正しくなり、アクティブなサーバーが再起動し、パッシブになります。 実際には何がありますか？

• もちろん、管理されていないスイッチを介して保護されたリソース（1Cサーバーなど）をファイラーに取り込んで接続することはできませんが、より正確にはもちろんできますが、この場合、保護されたリソース自体のアドレスをテストIPとして指定する必要があります。 その結果、たとえば、定期的なメンテナンスやソフトウェアの更新のために1Cサーバーを再起動すると、ファイラーも削減されます。 もちろん、これへのアクセスを保護することが唯一のタスクであれば問題ありませんが、ほとんどの場合はそうではありません。
• ファイラーのフォールトトレランスは、各テストアドレスのフォールトトレランスに依存し、ネットワークインターフェイスを追加するたびに小さくなります。 私の練習では、データセンターの従業員がテストノードとして機能するスイッチを電源から誤って切断した場合、クラスターは連続的な再起動サイクルに入りました。これは、Vipnetクライアントを備えたローカルマシンがドメインに接続できず、作業が麻痺したためです。データセンターに入ることが許可されるまで。

ファイラーのフォールトトレランスは、ネットワークインフラストラクチャ全体が障害なく動作する球状の真空でのみ可能です。 誰かがこれは必要な対策であると言うかもしれませんが、サーバーの1つに何かが起こった場合、たとえばネットワークインターフェイスがクラッシュした場合、再起動し、機能が復元され、バックアップアルゴリズムがその有用性を証明します。 ただし、実際には、ファイラーのインターフェースの1つが実際にクラッシュし、上記のスキームに従ってリブートを開始する場合がありましたが、リブート後の問題はなくなりませんでした。 グリッチを取り除くには、手動で電源をオフにする必要があったため、この場合、フォールトトレランスは紙にしか表示されません。



アルゴリズムにもう1つの条件が含まれていれば、これはすべて修正できます。パッシブサーバーがオフになっている場合、アクティブサーバーは再起動しません。 実際のフォールトトレランスを提供する単純な条件は、開発者によって追加されたことはないようです。 これは、カーネルとその再認証を変更する必要があるためだと推測できます。



稼働中のネットワーク環境とサーバー機器の場合、サーバーのアップタイムはほぼ連続していました。 私がインストールしなければならなかった最初のファイラーの1つは3年間働いていましたが、この間、ホットバックアップスキームはソフトウェアの近代化中またはデータセンターでの一般的な技術作業によってのみ機能しました。 一般に、このようなスキームの本当の利点は、クラスターノードの1つでハードウェア障害が発生した場合にのみ可能です。私の実務ではまだ発生していません。



Vipnet Cluster Windowsには希望がありましたが、残念ながらInfotexはそれをマスターできませんでした。バックアップスキームが非常に有望だったのは残念です。



一般に、私のアドバイスは、ティックにフォールトトレラントな暗号ゲートウェイが必要ない場合は、ファイラーを気にせず、通常のVipnet Linuxコーディネーターを使用することをお勧めします。特に触れない場合は、それ自体で非常に信頼性が高いです;）