NGINX evoluciona hacia la nube nativa, todo en OpenNJet
Sincronización de configuración
El artículo anterior presentó cómo OpenNJet implementa la configuración de alta disponibilidad. Este artículo presenta la función de sincronización de la configuración del clúster en modo de alta disponibilidad. OpenNJet tiene muchos módulos de configuración dinámica. Estas configuraciones dinámicas se pueden sincronizar entre los nodos activos y en espera utilizando nuestro módulo HA .
El nodo maestro actualiza dinámicamente la configuración a través de la interfaz de configuración dinámica ( API declarativa o API imperativa), y luego el nodo de respaldo puede sincronizar estas configuraciones a tiempo. Si el nodo maestro deja de funcionar, el nodo de respaldo actualiza dinámicamente la configuración. Después de que el nodo maestro vuelve a funcionar, la configuración actualizada se puede sincronizar a tiempo. En última instancia, se garantiza que tanto el nodo activo como el nodo en espera puedan garantizar la última sincronización de las configuraciones de cada uno.
prueba
Instrucciones de configuración
Todos los siguientes escenarios de prueba se prueban con un nodo maestro y un nodo de respaldo .
Nodo maestro: 192.168.40.136
La configuración del proceso del intermediario es la siguiente.
C++
#配置主节点监听端口和ip
listener 1883 192.168.40.136
#配置本地socket地址，用于本地worker进程通信
listener 0 /root/bug/njet1.0/data/mosquitto.sock
log_dest file logs/mosquitto.log
log_type debug
log_type information
log_type error
log_type warning
log_type notice
allow_anonymous true
persistence true
autosave_on_changes true
autosave_interval 1
persistence_location /root/bug/njet1.0/data/
nodo de respaldo : 192.168.40.91
La configuración del proceso del intermediario es la siguiente:
C++
#配置backup节点监听端口和ip
listener 1883 192.168.40.91
#配置本地socket地址，用于本地worker进程通信
listener 0 /root/bug/njet1.0/data/mosquitto.sock
#配置需要连接的主节点地址信息
connection bridge-backup
address 192.168.40.136:1883
#topic主题过滤掉get相关接口请求
topic /dyn/# both 0
topic /ins/# both 0
log_dest file logs/mosquitto.log
log_type debug
log_type information
log_type error
log_type warning
log_type notice
allow_anonymous true
persistence true
autosave_on_changes true
autosave_interval 1
persistence_location /root/bug/njet1.0/data/
Sincronización de mensajes API imperativa
Mensaje de actualización del nodo maestro, mensaje de sincronización del nodo de respaldo
Agregue una ubicación /clb al nodo principal y observe si el nodo de respaldo se agrega simultáneamente.
Agregue una ubicación al nodo principal a través de la interfaz de ubicación dinámica
Al consultar a través de la interfaz de obtención de otros módulos , puede encontrar que la ubicación del nodo maestro ya existe.
Verifique desde el nodo de respaldo y descubra que la ubicación también existe y que la sincronización se realizó correctamente.
mensaje de actualización del nodo de respaldo , mensaje de sincronización del nodo maestro
Agregue una ubicación /clb2 al nodo de respaldo y observe si el nodo principal se agrega simultáneamente.
Agregue una ubicación al nodo de respaldo a través de la interfaz de ubicación dinámica
Al consultar a través de la interfaz de obtención de otros módulos , puede encontrar que la ubicación del nodo de respaldo ya existe.
Verifique desde el nodo maestro y descubra que la ubicación también existe y que la sincronización se realizó correctamente.
Sincronización de mensajes API declarativa
Mensaje de actualización del nodo maestro, mensaje de sincronización del nodo de respaldo
Verifique modificando el número de conexiones límite en ubicación /clb
Antes de modificar el nodo maestro: el número de conexiones es 100
Modificar el valor del nodo maestro a 200
Observe el valor del nodo de respaldo y descubra que ya es 200 , lo que indica que la sincronización fue exitosa.
mensaje de actualización del nodo de respaldo , mensaje de sincronización del nodo maestro
Verifique modificando el número de conexiones límite en ubicación /clb
Cambie el punto de respaldo a 300
Observe el punto del host, que también es 300 , y la sincronización se realizó correctamente.
El nodo maestro sale y la configuración del nodo de respaldo no desaparecerá después de la recarga .
Detenga el nodo maestro y observe la configuración del nodo de respaldo .
Observe el nodo de respaldo , todavía es 300
Modifique el valor del nodo de respaldo a 400 , luego vuelva a cargar el nodo de respaldo , consígalo nuevamente y descubra que el valor sigue siendo 400.
Cuando el nodo maestro se vuelva a unir, los mensajes del nodo de respaldo se sincronizarán.
Inicie el nodo maestro y observe si la configuración del nodo maestro sincronizará la configuración dinámica del nodo de respaldo .
Reinicie el nodo maestro,
Observe el valor del nodo maestro, ya es 400 , lo que indica que la sincronización fue exitosa.
Problemas conocidos
Cuando hay API imperativas , como la ubicación de mensajes eliminados dinámicamente, la sincronización fallará.
Broadcom anunció la terminación de la actualización de la versión deepin-IDE del programa de socios de VMware existente, una nueva apariencia. WAVE SUMMIT está celebrando su décima edición. ¡Wen Xinyiyan tendrá la última divulgación! Zhou Hongyi: El nativo de Hongmeng definitivamente tendrá éxito. El código fuente completo de GTA 5 se ha filtrado públicamente. Linus: No leeré el código en Nochebuena. Lanzaré una nueva versión del conjunto de herramientas Java Hutool-5.8.24 el año que viene. Vamos a quejarnos juntos de Furion. Exploración comercial: el barco ha pasado. Wan Zhongshan, v4.9.1.15 Apple lanza un modelo de lenguaje grande multimodal de código abierto Ferret Yakult Company confirma que se filtraron datos de 95 GOpenNJet se basó por primera vez en la bifurcación básica de NGINX1.19 y evolucionó de forma independiente. Tiene las características de alto rendimiento, estabilidad y fácil expansión. También resuelve los problemas de larga data de NGINX, como la dificultad en la configuración dinámica y las funciones de administración que afectan negocio. Sitio web oficial del grupo de correo.