Agrupación con NxFilter
NxFilter soporta clustering para balanceo de carga y a prueba de fallos. Una vez que tenga un nodo maestro puede añadir hasta 4 nodos esclavos a su cluster.
nodos esclavos a su clúster. Todos los nodos esclavos de su cluster comparten la configuración de su nodo maestro. Por lo tanto, puede controlar
todo desde tu nodo maestro.
Creando un cluster
Para crear un cluster, lo primero que debe hacer es configurar un nodo maestro. En System > Clustering,
puede hacer que una de sus instalaciones de NxFilter sea su nodo maestro. Y luego puedes añadir las otras instalaciones
instalaciones NxFilter como los nodos esclavos a su nodo mater. Es necesario reiniciar NxFilter después de
cambiar la configuración del cluster.
Iniciando cluster NxFilter
Cuando inicie el cluster NxFilter, inicie primero su nodo maestro y luego sus nodos esclavos.
Esto es porque sus nodos esclavos necesitan descargar la configuración inicial de su nodo maestro cuando arrancan.
Equilibrio de carga y a prueba de fallos
Una cosa buena sobre un filtro DNS es que ya existe una forma de balanceo de carga y a prueba de fallos.
Haga que su nodo maestro sea el servidor DNS primario y que su nodo esclavo sea el servidor DNS secundario en
su red. Entonces tienes balanceo de carga y a prueba de fallos.
Anycast para redirección de bloques
Puede tener multiples direcciones IP de redireccionamiento de bloques en System > Setup para redundancia.
Sin embargo, esto no es ideal cuando pones 4 o más nodos detrás de 2 direcciones IP usando Anycast. Si configuras esas 2 direcciones IP
en GUI, puede redirigir a sus clientes a algún lugar que no esté cerca de ellos. Con Anycast, usted quiere redirigir sus clientes bloqueados
al servidor más cercano que es el servidor que los bloqueó. Para ello, puede establecer 'block_node_ip' en cada nodo de
/nxcloud/conf/cfg.properties de cada nodo con su IP Anycast.
Por ejemplo, si quieres reenviar tus clientes bloqueados a 192.168.0.100 desde un nodo,
añada la siguiente línea en su archivo /nxcloud/conf/cfg.properties.
block_node_ip = 192.168.0.100
Cuando un nodo del cluster cae
Cuando un nodo esclavo cae, los otros nodos no se verán afectados. Cuando su nodo maestro hacia abajo, usted todavía no pierde su
filtrado a menos que reinicie su nodo esclavo antes de restaurar el nodo maestro. Sin embargo, hay varias cosas que usted necesita
tener en cuenta.
1. La redirección de inicio de sesión no funcionará
Cuando su nodo maestro cae, no podemos compartir la sesión de login entre los nodos del cluster. Esto significa que su página de inicio de sesión
no funcionará correctamente. Por lo tanto, no redirigimos a los usuarios a la página de inicio de sesión.
2. Los usuarios no autenticados serán puenteados
Si no redirigimos a los usuarios con contraseña a la página de acceso, no podrán acceder. Sin embargo, no queremos
Por lo tanto, evitamos el filtrado para estos usuarios no autenticados cuando su nodo maestro está caído.
Si no quieres evitar el filtrado para ningún usuario incluso si tu nodo maestro está caído intenta tener un usuario por defecto
que cubra todo el rango IP de su red.
3. Múltiples direcciones IP de servidor con un agente
Si usa nuestros programas agentes con multiples direcciones IP de servidor para seguridad, seguiran funcionando.
Control de acceso para un nodo esclavo
Si añade todas las direcciones IP de sus nodos esclavos en System > Clustering, cualquier intento de unirse a un nodo esclavo desde una dirección IP
desconocida será bloqueada.
Monitorización del estado de la conexión
Puede ver el estado de conexión de sus nodos esclavos en System > Clustering. Una vez que haya configurado su clúster
entonces sus nodos esclavos se mostrarán con la última hora de contacto en la página. También se muestra el estado de conexión de cada nodo
request, block, user, client-ip counting data. These counters will be set to 0 on midnight
or when you restart NxFilter.
Comprobación de la conexión del nodo maestro
En un nodo esclavo, hay un proceso de comprobación de conexión ejecutándose en backgroud.
Comprobará la conexión con su nodo maestro basándose en TCP/19003 y TCP/19004.
Cuando hay un problema de conexión o si su nodo maestro se bloquea, se le notifica con una alerta
a la dirección de correo electrónico del administrador en System > Alert.
Sin embargo, hemos encontrado que esta forma de comprobar la conexión no funciona correctamente en algunas condiciones. Su nodo esclavo
necesita ser notificado con un evento de cierre de socket desde su sistema operativo. Funciona cuando su nodo maestro se detiene o
cuando hay un problema de red mientras se ejecuta en Windows. Pero si está en sistemas Linux, no funciona bien.
funciona bien. Tu nodo esclavo estará esperando respuestas de su nodo maestro durante mucho tiempo incluso si
hay un fallo en la red.
Para resolver este problema, hemos hecho un proceso de comprobación más en el nodo esclavo. Comprobará TCP/80 de su nodo maestro.
nodo maestro. Si TCP/80 de su nodo maestro se cierra, se saltará la comunicación con su nodo maestro y
le notificará con un correo electrónico de alerta para el problema. Como esto no es para todo el mundo,
tienes que habilitarlo en tu lado esclavo. Puede añadir la siguiente línea en /nxfilter/conf/cfg.properties
archivo.
cluster_double_check = 1
Solución de problemas
Cuando no tiene una entrada para su nodo maestro en /etc/hosts archivo de su nodo esclavo, su nodo esclavo podría quedarse atascado
con el siguiente mensaje durante su proceso de arranque,
INFO [07-31 06:10:53] - MM, MasterCheck started.
Este problema es de nuestra libreria DB. Requiere un nombre de host en /etc/hosts archivo para conectarse.
