La cantidad de datos que generamos hoy en todos los dominios está explotando con millones de dispositivos # conectado a Internet a diario. Cada aplicación IoT necesita manejar Terabytes de datos diariamente. El manejo de un gran volumen de datos no es factible con un servidor de un solo nombre. A pesar de que MQTT correta en el mercado está bien escalado para el rendimiento, entornos de producción a gran escala requieren alta disponibilidad MQTT clusters para satisfacer las demandas con eficacia.
La era SaaS de la nube ha redefinido la forma en que los servidores se despliegan para una alta disponibilidad del sistema. Las aplicaciones construidas antes de Internet de las Cosas fueron soluciones basadas en HTTP donde el 99% de las solicitudes fueron servidos en un solo servidor (o una ruta de servidores). MQTT alta disponibilidad plantea un conjunto diferente de retos para la coherencia de los datos. El protocolo hace obligatorio que los mensajes que aterrizan en nodo de servidor particular en el MQTT Cluster debe ser puesto a disposición de todos los nodos en el cluster para hacerlo disponible para el cliente conectado a este sistema de manera más rápida y fiable. Habiendo dicho que el MQTT Cluster también debe poner los datos disponibles para los usuarios a través de REST o los otros modos que también son parte de los ecosistema general de datos IoT/IIoT.
MQTT Cluster Architecture
Protocolo MQTTLa especificación no admite el almacenamiento de los datos. Sin embargo, el grupo de alta disponibilidad necesita un almacenamiento claro de datos para los datos transitorios para asegurarse de que la entrega de datos esté garantizada segúnMQTT QoS Levelsinstrucciones en los paquetes de MQTT. El almacenamiento puede no ser necesario cuando hay un solo Nodo implementación como los datos pueden estar en memoria transitoria. Así que MQTT Broker Clusters necesitan más componentes más allá de los Aplicación de MQTT. A un nivel alto, el almacenamiento de datos para los datos transitorios es necesario en los siguientes casos:
- Cuando un nuevoMQTT Brokerse une al grupo
- Cuando un MQTT Broker descansa debido al reinicio físico o funcional.
Cuando todos los corredores están funcionando bien, hay una necesidadInter Broker communication (IBC):
- Para enviar datos al otroMQTT Serveren el grupo temático
- Para recibir datos de las otras instancias del MQTT en el grupo
Equilibrio de carga es algo obligatorio en todos los despliegues de alta disponibilidad independientemente del protocolo utilizado para la comunicación entre los clientes y el servidor. juega un papel importante en la creación del MQTT Cluster y distribución de datos a través de los nodos MQTT en el clúster y también servicio las API REST a través de ellos. Hay dos modos en los que se puede desplegar el grupo MQTT. El soporte de equilibrio de carga juega un importante papel en estas configuraciones.
Modo activo-pasivo
En este set up, habrá dos MQTT Brokers desplegados detrás de un balanceador de carga. Uno de los Los nodos MQTT se configurarán como Activos y servirán a la solicitud. El nodo secundario mantendrá el estado y los datos en sincronización con la primaria y estarán en modo stand-by. Cada vez que hay un funcional o físico falla en el servidor primario, el servidor secundario se hará cargo.
Esta configuración es ideal para escenarios de intercambio de datos moderados y donde un solo nodo MQTT puede Maneja la carga. También puede conservar la energía y el costo manteniendo el nodo secundario en un mínimo configuración.
Modo Multi Maestro
Cuando el requisito tiene más intercambio de datos donde un solo nodo no puede manejar la carga de datos de producción, nosotros necesidad de desplegar varios maestros detrás del balanceador de carga y todos los MQTT Brokers estarán sirviendo a los clientes en paralelo. Puesto que es un protocolo basado en TCP, independientemente de la configuración, los clientes serán pegajosos el servidor MQTT al que se conecta. La configuración se puede hacer un Round Robin ponderado para distribuir el Carga de una manera mejor.
¿Cómo mantienen la consistencia de los datos los equipos MQTT?
MQTT Broker tiene soporte para un mecanismo de intercambio de datos incorporado que llamamos Inter Broker Communication Motor (IBC). IBC está habilitado en cada nodo MQTT en el cluster para enviar y recibir los datos de los otros nudos del grupo MQTT. Todos los nodos almacenan datos en paralelo a la base de datos, asegurando redundancia y habilitar la recuperación de datos en caso de fracaso.
MQTT Broker Redundancy
Como se indicó anteriormente, la especificación del Protocolo del MQTT y laAplicaciones IoTconstruido sobre MQTT tienen un diversificado conjunto de requisitos para hacerlo más escalable y fiable en términos de consistencia de datos en M2M y la integración con las plataformas de análisis de datos que se están convirtiendo en parte inherente de cada despliegue realizado hoy. Siempre pedimos a nuestros clientes que almacenen los datos detrás del corredor y no como suscriptor. Esto ayudará reducen los costos de ancho de banda, así como el tamaño de sus despliegues.
Redundación física
La redundancia física MQTT ayuda cuando uno o dos nodos fallan y hasta el momento en que usted proporciona un nuevo servidor o el mismo servidor físico vuelve vivo, el cluster debe ser totalmente funcional.
Redundación funcional
Más que el monitoreo físico de los nodos, el monitoreo funcional es crucial para el soporte de los racimos SLA. Cada nodo debe ser monitoreado para todosMQTTlas funciones y la capacidad de respuesta nodos. Estos cheques deben hacerse tanto a nivel de los grupos como a todo.
Cuando implementamos grandes MQTT Clusters, debemos tener la configuración general de tal manera que cada nodo servidor 60 al 70% de la carga general. Esto garantiza que la salud del cluster MQTT sea óptima. Más allá del 80% causará fallo en racimo cuando uno o dos nodos fallen durante la producción.
La configuración HA es flexible y se puede desplegar en cualquier nube o en servidores de premisa con un conjunto diversificado deAlmacenamiento de datosy opciones de balanceador de carga. La configuración en el balanceador de carga depende de cómo Es necesario equilibrar las conexiones y los datos. Sin embargo, tomar la mejor opción también depende de cómo El grupo está siendo desplegado.
Asegurar su instalación MQTT
Garantizar la seguridad de su instalación MQTT es crucial para proteger datos sensibles y mantener la integridad de sus aplicaciones. Sólo es eficazMQTT Seguridadmedidas, podemos no sólo salvaguarda nuestros datos contra el acceso no autorizado, sino que también puede garantizar la integridad de los datos en todas partes todo el proceso de comunicación. Este enfoque proactivo es inevitable para mitigar las amenazas potenciales y garantizar una operación sin problemas en el ecosistema IoT.
A continuación se presentan las estrategias clave para mejorar la seguridad de su instalación MQTT :
- Use TLS/SSL Encryption- EjecuciónTLS/SSL(Transport Layer Security/Secure Sockets Layer) para cifrar el datos en tránsito entre los clientes y los corredores, evitando escuchas y manipulaciones.
- Implementar la autenticación- Verificar la identidad de los clientes que conectan al corredor mediante la aplicación fuerteMQTT autenticaciónmecanismos tales como nombre de usuario/password, OAuth, autenticación basada en token, etc.
- Controles de Autorización- Asegurar que sólo los usuarios autorizados puedan publicar o suscribirse a temas específicos estableciendo listas de control de acceso granular (LAC) para restringir al cliente permisos basados en roles.
- Asegure el Balanceador de carga- Salvaguardar el balanceador de carga contra no autorizado acceso y ataques por incorporando medidas de seguridad como las normas de blanqueamiento IP y cortafuegos.
- Limitar las conexiones de cliente- Restringir el número de conexiones simultáneas y la tasa de mensaje publicación para mitigar el riesgo de ataques de denegación de servicio (DOS).
- Monitor Network Traffic- Seguimiento y análisis del tráfico de MQTT para inusual patrones o acceso no autorizado intentos utilizando herramientas de monitoreo de red.
- Safeguard Internal Communication- Establecer una red privada virtual (VPN) para asegurar la seguridad interna comunicaciones entre corredores de MQTT y clientes, agregando una capa adicional de protección.
MQTT Clustering on Cloud
Grupo MQTT en AWS
Amazon Web Services proporcionó un buen conjunto de opciones para los casos de hardware (EC2) para dirigiendo su MQTT nodos del grupo. AWS EC2 viene con un conjunto de direcciones IP internas que necesitan ser utilizadas para comunicarse internamente. El balance de carga elástica tiene una opción para redirigir la carga TCP en el puerto 1883 o 8883 (para TLS).
Elastic Load Balancer ( ELB) del AWS debe ser utilizado para el balanceo de carga. De los 4 tipos de opciones ELB ofrece, para MQTT el balanceador de carga de red necesita ser configurado. El balanceador de carga de red apoya TCP. BevywiseMQTT Broker( CrystalMQ) admite el Usuario interfaz también que necesita ser configurado a través del balanceador de carga de Aplicación. Sin embargo, puede utilizar el mismo balanceador de carga de red para elIoT Dashboardtambién.
MQTT Alta disponibilidad en Azure
Azure Cloud ofrece un gran conjunto de herramientas que le ayudan a configurar el MQTT Broker en un altamente redundante redundante arquitectura. Como AWS, hay VMs, servicios de bases de datos fiables y Equilibrio de carga de Azure que se pueden utilizar para configurar los Clusters MQTT más asequibles en la nube de Azure en la región de su elección. Azure, como AWS, proporciona precios de descuento a largo plazo basados en compromisos para ahorrar costos en los servidores.
Instrucciones detalladas paso a paso para configurar elAzure IoT High disponibilidadaplicación se puede utilizar para preparar tu producción de aplicaciones.
Alta disponibilidad Clustering in DigitalOcean
Hemos estado usando el Océano Digital por un par de años para todo nuestro alojamiento. NuestroCloud Hosted MQTT BrokerLos despliegues apoyan el Océano Digital además de AWS. Tenemos un gran tiempo trabajando con ellos. Océano Digital proporciona las gotitas más rentables ( equivalente a EC2) para desplegar MQTT Broker en su preferido OS. El conjunto del servidor MQTT es el mismo que todos los demás servidores. El balanceador de carga de Red de Océano Digital soporta la distribución de carga L3 / TCP entre los servidores MQTT detrás de ellos.
En general, si usted está buscando en las implementaciones basadas en la nube, recomendaríamos un Ubuntu o Redhat servidores basados para ejecutar sus instancias MQTT y ejecutar el MySQL o PostgreSQL en un servidor separado o servicio como RDS donde se cuida la redundancia de la capa de datos.
MQTT High Disponibilidad en premisa
Windows NLB Configuración:
La mayoría de las empresas ejecutan todas sus cargas de trabajo en un entorno basado en Windows. Si eres uno de los tal empresa, entonces la combinación del Windows Server y el Balanceador de carga de red (NLB) debe ayudar a crear un robusto MQTT Grupo para su entorno de producción.
NLB funciona como parte integral de todas las instancias del servidor de Windows. No hay necesidad de un conjunto separado de servidores para ejecutar los balanceadores de carga. Sin embargo, hay que hacer alguna configuración especial de Windows NLB en Interruptor / Router que utiliza para asegurar el intercambio de datos suave con todo el Windows MQTT Broker corriendo en el cluster. Como se ha indicado anteriormente, MySQL o MSSQL deben ejecutarse en un conjunto separado de servidores en cualquiera de los dos Modo Master-Slave o Multi Master. Si se ejecuta en multi master, es posible que necesite mantener los ids únicos con el configuración impar-even en las dos instancias DB.
Ubuntu Nginx Setup:
En el entorno Linux, necesitamos servidores adicionales para ejecutar el balanceador de carga. El balanceador necesita para ser configurado en modo fail over para garantizar la fiabilidad. Nginx es la carga más confiable y basada en TCP aplicación de equilibrio. Hacer referencia al detalleConfiguración Nginx manualpara configurar los equipos de MQTT.
Configuración de bases de datos:
A pesar del número de MQTT Brokers que estamos corriendo, debemos tener la capacidad de almacenar el datos a un singe base de datos a la que se conectará todo el Broker. La base de datos almacenará todo el tráfico de datos entrantes todos los nodos, lo que hace que sea más fácil sincronizar los datos dentro de los corredores. El beneficio clave de este almacenamiento centralizado es que, independientemente de la conexión del cliente con cualquier corredor de MQTT, ayuda en Pasando datos a todos los corredores disponibles con la ayuda de IBC para suavizar el flujo public-subscribe.
Por ejemplo, considere un conjunto agrupado con 2 MQTT Brokers conectados al balanceador de carga y base de datos. 'A' cliente, un editor está conectado con el cliente Broker 1 y 'B', un suscriptor, está conectado con el Broker 2 a través de balanceador de carga. Ahora 'A' cliente publica datos en el tema mqtt1, y 'B' se suscribe a Es. Según la configuración, MQTT Brokers puede hablar entre sí y compartir datos de la base de datos a través de IBC. La base de datos permitirá a Broker 2 obtener los datos recibidos en Broker 1 y enviarlo al cliente suscrito 'B'. Por lo tanto, permitir a todos los corredores recibir y enviar datos independientemente de quién es el cliente conectado?
Por cierto, no es obligatorio tener sólo almacenamiento centralizado. Aplicación de un Master/Slave preparado para su almacenamiento de datos también añadirá peso basado en el requisito.
Al seleccionar su base de datos deseada puede considerar la elección de MySQL o PSQL ya que puede muy bien escala para tan agrupada alta disponibilidad. En general, la arquitectura distribuida proporcionará un más robusto y red confiable para manejar el tráfico de un gran número de clientes.
Mantener la coherencia de los datos y garantizar una comunicación fluida entre los nodos distribuidos crucial para implementaciones de IoT a gran escala. Sólo una robusta arquitectura de racimo MQTT puede proporcionar la confianza manejar el tráfico de datos altos, mantener el tiempo de trabajo y entregar datos en tiempo real sin interrupciones. Con esto en mente, hemos diseñado nuestraMQTT Broker(CrystalMQ) para permanecer resistente, altamente disponible y fiable bajo todas las circunstancias. Ya sea que usted está escalando o afinando para aplicaciones críticas de la misión, le tenemos cubierto!
Dale nuestro MQTT ¡Probar hoy y experimentar la conectividad perfecta para sus implementaciones de IoT!