Кластеризация с помощью NxFilter
NxFilter поддерживает кластеризацию для балансировки нагрузки и обеспечения отказоустойчивости. После установки ведущего узла вы можете добавить до 4 ведомых
узлов в свой кластер. Все подчиненные узлы в кластере используют настройки своего главного узла. Таким образом, вы можете контролировать
все на своем главном узле.
Создание кластера
Чтобы создать кластер, первое, что вам нужно сделать, это установить главный узел. На сайте System > Clustering,
вы можете сделать одну из ваших установок NxFilter главным узлом. Затем вы можете добавить другие
NxFilter в качестве ведомых узлов к вашему главному узлу. Вам необходимо перезапустить NxFilter после
изменения настроек кластера.
Запуск кластера NxFilter
При запуске кластера NxFilter сначала запускается главный узел, а затем подчиненные узлы.
Это связано с тем, что при запуске ведомым узлам необходимо загрузить начальную настройку с ведущего узла.
Балансировка нагрузки и защита от сбоев
Одна из положительных сторон DNS-фильтра заключается в том, что уже существует способ балансировки нагрузки и обеспечения отказоустойчивости.
Пусть ваш ведущий узел будет основным DNS-сервером, а подчиненный узел - вторичным DNS-сервером в
вашей сети. Тогда у вас будет балансировка нагрузки и отказоустойчивость.
Anycast для повтора блока
Вы можете иметь несколько IP-адресов для перенаправления блоков System > Setup для избыточности.
Однако это не идеально, когда вы размещаете 4 или более узлов за 2 IP-адресами, использующими Anycast. Если вы установите эти 2 IP-адреса
в графическом интерфейсе, вы можете перенаправить своих клиентов куда-то не туда, где они находятся. При использовании Anycast вы хотите перенаправить заблокированных клиентов
на ближайший сервер, который является сервером, который их заблокировал. Для этого вы можете установить параметр 'block_node_ip' на каждом узле в файле
/nxcloud/conf/cfg.properties файл с его Anycast 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.
Однако мы обнаружили, что этот способ проверки соединения не работает должным образом при некоторых условиях. Ваш ведомый узел
должен получать уведомление о событии закрытия сокета от своей ОС. Это работает, когда ваш ведущий узел останавливается или
при проблемах с сетью, когда он работает под Windows. Но если он работает в системах Linux, это не
работает плохо. Ваш ведомый узел будет просто ждать ответов от своего ведущего узла в течение длительного времени, даже если
даже если произойдет сбой в сети.
Чтобы решить эту проблему, мы сделали еще один процесс проверки на ведомом узле. Он будет проверять 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 файл для подключения.
