NxFilterによるクラスタリング
NxFilter はロードバランシングとフェイルセーフのためにクラスタリングをサポートします。マスターノードがあれば、スレーブノードを4台まで追加できます。
スレーブノードを追加できます。クラスタ内のすべてのスレーブノードはマスターノードの設定を共有します。そのため
マスターノード上ですべてを制御できます。
クラスタの作成
クラスタを作成するには、まずマスターノードを設定します。その際 System > Clustering,
で、インストールした NxFilter の一つをマスターノードにします。そして他の
をスレーブノードとして追加することができます。クラスタの設定を変更した後は NxFilter を再起動する必要があります。
を再起動する必要があります。
NxFilter クラスタの開始
NxFilterクラスタを起動するときは、まずマスターノードを起動し、次にスレーブノードを起動します。
これは、スレーブノードが起動時にマスターノードから初期設定をダウンロードする必要があるためです。
ロードバランシングとフェイルセーフ
DNSフィルターの良い点は、ロードバランシングとフェイルセーフの方法がすでに存在することです。
マスターノードをプライマリDNSサーバーにし、スレーブノードをセカンダリDNSサーバーにします。
セカンダリDNSサーバーにすることだ。そうすれば、ロードバランシングとフェイルセーフができる。
ブロック再割り当てのためのエニーキャスト
複数のブロックリダイレクトIPアドレスを System > Setup 冗長性のため。
ただし、Anycastを使用して2つのIPアドレスの後ろに4つ以上のノードを置く場合、これは理想的ではありません。これらの 2 つの IP アドレスを
をGUIで設定すると、クライアントを近くにない場所に転送する可能性があります。エニーキャストでは、ブロックされたクライアントをサーバである最も近いサーバ
ブロックしたサーバに最も近いサーバにリダイレクトします。この目的のために、各ノードの
/nxcloud/conf/cfg.propertiesファイルに、そのエニーキャストIPで'block_node_ip'を設定できます。
例えば、ブロックされたクライアントをノードから192.168.0.100に転送したい場合、
の /nxcloud/conf/cfg.properties ファイルに次の行を追加します。
block_node_ip = 192.168.0.100
クラスタノードがダウンした場合
スレーブノードがダウンした場合、他のノードは影響を受けません。マスターノードがダウンしても、スレーブノードを再起動しない限り、フィルタリングは失われません。
マスターノードをリストアする前にスレーブノードを再起動しない限り、フィルタリングは失われません。ただし
があります。
1.ログインリダイレクトが機能しない
マスターノードがダウンした場合、クラスタノード間でログインセッションを共有できません。つまり、ログインページ
が正しく動作しないことを意味します。そのため、ユーザをログインページにリダイレクトしません。
2.認証されていないユーザはバイパスされる
もし「パスワードユーザ」をログインページにリダイレクトしなければ、彼らはログインできない。しかし
そこで、マスターノードがダウンしているときに、これらの認証されていないユーザーのフィルタリングをバイパスします。
マスターノードがダウンしても、どのユーザーに対してもフィルタリングをバイパスしたくない場合は、ネットワークの全IP範囲をカバーするデフォルトユーザー
を設定してみてください。
3.エージェントで複数のサーバ IP アドレス
フェイルセーフのために複数のサーバIPアドレスを持つエージェントプログラムを使用しても、それらは動作します。
スレーブノードのアクセス制御
すべてのスレーブノードのIPアドレスを System > Clusteringに追加すると、不明な送信元IPアドレスからスレーブノードに参加しようとする試みはブロックされます。
スレーブノードに参加しようとする試みはブロックされます。
接続状態の監視
でスレーブノードの接続状態を表示できます。 System > Clustering.クラスタを設定すると
を設定すると、スレーブノードの最終接触時間が表示されます。また、各ノードの
request, block, user, client-ip counting data. These counters will be set to 0 on midnight
or when you restart NxFilter.
マスターノード接続チェック
スレーブノードでは、backgroudで接続チェックプロセスが実行されています。
TCP/19003とTCP/19004に基づいてマスターノードとの接続をチェックします。
接続に問題があったり、マスターノードがクラッシュしたりすると、次のようなアラートメールが通知されます。
の管理者メールアドレスに通知されます。 System > Alert.
しかし、この接続チェック方法は、いくつかの条件下で正しく動作しないことがわかりました。スレーブノード
スレーブノードはOSからソケットクローズのイベントを受け取る必要があります。これは、マスターノードが停止した時や
Windowsで動作中にネットワークに問題が発生した場合などです。しかし、Linuxではうまく動作しません。
うまく動作しない。スレーブノードは、ネットワーク障害が発生しても、マスターノードからの応答を長時間待つことになります。
スレーブノードはマスターノードからの応答を長時間待つことになります。
この問題を解決するために、スレーブノードにもう1つのチェックプロセスを作成しました。これはマスターノードのTCP/80をチェックします。
をチェックします。マスターノードのTCP/80がクローズされた場合、マスターノードとの通信をバイパスして
アラートメールで通知します。これは誰にでも使えるものではありません、
スレーブ側で有効にする必要があります。以下の行を/nxfilter/conf/cfg.propertiesファイルに追加します。
ファイルに追加します。
cluster_double_check = 1
トラブルシューティング
マスターノードのエントリが /etc/hosts スレーブノードのファイルにマスターノードのエントリがない場合、スレーブノードは起動中に以下のメッセージでスタックすることがあります。
スレーブノードが起動中に次のメッセージでスタックすることがあります、
INFO [07-31 06:10:53] - MM, MasterCheck started.
この問題はDBライブラリに起因しています。これは /etc/hosts 接続するにはファイルが必要です。
