Clúster dinámico CommuniGate Pro
El clúster dinámico CommuniGate Pro implementa una arquitectura, en la que todos los nodos del clúster son "activos". Muchas otras soluciones se contentan con esquemas de recuperación después de una caída o de un cambio en caliente, pero no el Clúster Dinámico; en el todos los sistemas funcionan juntos como una entidad lógica y todos los nodos asumen su parte de la carga. Al mismo tiempo, cada nodo en cualquier momento se puede extraer del clúster o añadir uno nuevo en cualquier formato. Por lo tanto el Clúster Dinámico permite hacer el servicio de cualquiera de sus miembros y aumentar (o reducir) las potencias activas directamente durante el funcionamiento sin interrupciones en la prestación de servicios.
Algunas de las ventajas claves del Clúster Dinámico, sobre las que vamos a hablar más adelante, son:
- Mantenimiento de nodos sin necesidad de detener el servicio
- Sistema unificado
- Uso eficiente de los servidores
- Escalabilidad predicible con bajos costes generales
- Alta disponibilidad de los servicios
Mantenimiento de nodos sin necesidad de detener el servicio
La actualización del hardware y software en los nodos pueden empeorar drásticamente el tiempo de disponibilidad del sistema de comunicaciones. Estos problemas son llamados a menudo "interrupciones programadas" en el mundo de las TI empresarial Por desgracia, estas interrupciones son totalmente inadmisibles en el ámbito de soluciones SaaS a nivel de operador Imagine una situación, en la que el teléfono de cable se desconectara los sábados por mantenimiento.
Para eliminar la necesidad de interrupciones, en el Clúster Dinámico se ha implementado el mecanismo de actualizaciones consecutivas. Este mecanismo de actualización permite al administrador de clúster desactivar un nodo, al mismo tiempo repartiendo las conexiones abiertas a otros miembros del clúster, hasta que el nodo no desaparezca completamente de la línea. Después de eso está disponible para el servicio y en el futuro podrá ser devuelto al clúster.
Sistema unificado
El clúster Dinamico CommuniGate Pro permite al operador considerar todo el sistema como una entidad única, incluso si consta de más de 40 servidores. Por lo tanto, la administración de la infraestructura de gran escala es mucho más fácil que en el caso de los sistemas de nivel empresarial.
Los proveedores SaaS que prestan servicios para las pequeñas empresas y los empresarios individuales necesitan un sistema fácilmente escalable. Y para nuestros clientes que utilizan el Clúster Dinamico son comunes las nubes, que prestan servicio a más de 20,000 pequeñas empresas (de 5 a 30 usuarios finales).
Al mismo tiempo, en el caso de IP ATC y soluciones de correo electrónico que no han sido diseñadas con la mirada puesta en su uso como plataforma SaaS, la gestión se complica con el crecimiento de la base de usuarios porque la cantidad de partes separadas aumenta: proxy servidores, bases de datos, servidores LDAP, puertas de enlace de medios, etc.
El cluster dinámico es una solución elegante que sin costes extra crece junto con su base de usuarios.
Efectividad
La plataforma CommuniGate Pro de forma efectiva utiliza los recursos de aparatos. Como consecuencia de ello, el proveedor puede alcanzar la mayor densidad de usuarios en cada servidor en comparación con las soluciones empresariales. La densidad de usuarios es vital en centros de datos, ya que permite reducir fuertemente los costos de administración, electricidad, refrigeración.
En la mayoría de los sistemas operativos de 64 bits (Solaris, Linux, BSD) CommuniGate Pro puede alcanzar 90.000 sesiones en un sistema. También, según ha demostrado la práctica, trabajan en configuración para más de 450.000 usuarios finales en el mismo sistema.
Escalabilidad predecible
El cluster dinámico es un sistema con un mínimo de gastos generales en escalado. Para aumentar la capacidad del sistema es suficiente tener servidores simples y baratos de forma-factor 1U o servidores blade. A diferencia de otras arquitecturas con altas exigencias en capacidades de procesamiento, para CommuniGate Pro no es necesario el uso de servidores demasiado potentes (como 8-way). Por ejemplo, Clúster Dinamico de 4x4, con servidores de doble procesador es mejor que 2х2 con servidores de 4 procesadores, ya que en el primer caso la carga específica en un servidor es mucho menor.
Como el código fuente CommuniGate Pro está bien paralelizado, los recursos informáticos y la memoria se utilizan de forma más efectiva y la previsión del volumen de recursos necesarios al aumentar la base de usuarios es transparente y cercana a la dependencia lineal. Todas las unidades del clúster CommuniGate Pro usan el mismo fichero ejecutable, y por lo tanto no existen diferencias en la productividad de unidades específicas para arquitecturas heterogéneas.
La elegante estructura del Clúster Dinámico permite a los proveedores analizar y predecir sus gastos con alta precisión, ya sean servidores o depósitos de datos.
Alta disponibilidad
Una de las características básicas y objetivos del desarrollo del Clúster Dinamico es reducir a cero el tiempo de ausencia del servicio. Todos los nodos de clúster son activos, y en caso de caída de uno de ellos otros miembros del clúster asumen la carga de usuarios.
Arquitectura del Clúster Dinamico
Los principales elementos de la arquitectura del clúster CommuniGate Pro incluyen:
- El equilibrador de carga
- La topología de la red
- Frontend
- Backend
- El depósito general de tipo NFS/CFS
El equilibrador de carga
El clúster incluye varios servidores, por lo tanto para que los usuarios puedan acceder a él desde una URL o desde la dirección IP, se necesita un equilibrador de carga. En el mundo hay muchos Clústeres Dinámicos y en ellos se usan los distintos equilibradores. Recomendamos usar sólo dispositivos L4 de alta calidad con buena capacidad de tráfico de Cisco, F5, Foundry. La información más detallada sobre la configuración de equilibradores está disponible en el manual.
Además los frontends en Linux, pueden cumplir la función de equilibradores a través de la tecnología incorporada en el núcleo IPVS.
La topología de la red
En la organización del Clúster Dinamico se utilizan por lo menos 4 redes independientes y varios switch de alta velocidad para lograr una productividad óptima. Recomendamos Cisco, F5, Foundry, HP o otros switch de nivel similar que proporcionan velocidad de gigabit. Deben ser los aparatos más sencillos y fiables; para dar un ejemplo indicamos la serie Cisco Catalyst 2960.
Cada servidor en el clúster debe tener por lo menos tres interfaces de red. El siguiente conjunto de configuraciones de red es necesario para el funcionamiento correcto del Clúster Dinamico:
- Una red pública es una red externa con direcciones IP blancas. Normalmente cada frontend tiene un conjunto de estas direcciones (junto con DNS registros) y los equilibradores tienen una o más. Por ejemplo:
Equilibrador, 64.10.1.1, uc.domain.com
frontend1.domain.com ->64.10.1.11
frontend2.domain.com ->64.10.1.12
frontend3.domain.com ->64.10.1.13 - Los usuarios finales en sus aplicaciones de cliente sólo utilizan uc.domain.com. Y el equilibrador, a su vez, envía solicitudes por activos frontends. Los DNS registros DNS para frontends se necesitan para la comodidad de los administradores.
- La red para el intercambio entre clústeres es una red interna de direcciones IP grises que se utiliza para la transmisión de información entre las unidades del clúster, ningún otro tráfico está permitido, por lo tanto, en frontends para esta red se usa una separada (segunda) interfaz.
- La red para el almacenamiento interno de la red, que se utiliza para la comunicación de backends con el depósito debe ser una red de alta velocidad , fibra óptica o Ethernet de 10 gigabytes.
- La red de gestión es una red cerrada , generalmente, es una red local del proveedor. Está diseñado para los administradores, así como para la llamada de la facturación API, plugins y otras tareas de gestión de clúster.
Frontends
En el clúster los frontends realizan las siguientes funciones:
- Intercambio de correo SMTP por protocolo con otros servidores.
- La organización de alarma SIP y la ejecución de PBX aplicaciones (esta función está sincronizada entre las unidades, y estos clústeres podemos llamarlos SIP granjas, SIP-farm).
- Las funciones de protección, RBL, contadores de errores y de la cantidad de la información aceptada de una dirección, listas negras/blancas por direcciones IP y DNS, y otros...
- La organización de conexiones cliente-servidor (IMAP, POP, HTTP, XIMSS, ...). Después de la organización de la conexión el frontend se dirige al backend ya sólo por los datos.
- Procesamiento de conexiones SSL.
Backends
En el Clúster Dinamico los backends son el núcleo de la plataforma.
Son responsables de:
- La configuración de dominio
- La configuración de las cuentas de usuario
- Los mensajes y otros objetos creados por los usuarios
- Los datos auxiliares para el clúster
- La gestión del clúster
- Autenticación
- La generación de páginas HTML por la tecnología WSSP
La tecnología de sincronización a nivel de cuenta de usuario utilizada en backends asegura que sólo un servidor tiene acceso a los ficheros de la cuenta en cada momento del tiempo (intervalos de 6 segundos). El clúster CommuniGate Pro por lo tanto elimina la necesidad en el bloqueo de los ficheros a nivel del sistema de ficheros (excepto uno, heartbeat.data, cuyo bloqueo realiza el Controlador de Clúster). Debido al hecho de que el clúster no cuenta con los mecanismos de bloqueo en el sistema de ficheros, la productividad NFS aumenta en de 5 a 7 veces.
El cluster dinámico apoya la renovación por turno de unidades y la recuperación automática después de la caída de cualquier unidad en cualquier momento, la configuración recomendada en este caso, el clúster de 3x3 (3 frontends, 3 backends). Pero para la desconexión programada se recomienda utilizar la desconexión "suave". La configuración "Make Not-Ready" en la interfaz WebAdmin en la página Monitors->Clusters.
Instalación del clúster
La parte más crítica del clúster es el depósito de datos.
Se recomienda utilizar soluciones NAS o SAN dependiendo del sistema operativo y de las oportunidades disponibles tales como protocolos NFS y diferentes sistemas de ficheros (CFS).
El proceso de instalación consiste en los siguientes pasos:
- Configuración de la red
- Configuración del sistema operativo
- Elección del sistema de ficheros y de almacenamiento de datos
- Cumplimiento de los requisitos del sistema operativo
- Configuración de CommuniGate Pro.
Configuración de la red
El clúster CommuniGate Pro permite una cierta flexibilidad en la configuración de la red. Existe la posibilidad de:
- Colocar todas las subredes de clúster detrás del NAT
- Utilizar direcciones WAN directas
- En las redes de tipo mixto, frontends están en DMZ y backends en la red protegida
CommuniGate Pro puede manejar cientos de direcciones IP y apropiarlos a sus determinados dominios a los que sirve.
A veces el administrador puede lograr una mayor productividad de la unidad del clúster simplemente ajustando un poco el sistema operativo. La configuración típica que debe ser corregida:
- Límite en el número de ficheros abiertos
- Límite en el número de procesos en ejecución de un usuario
- Búferes de red y cachés
- La configuración de partes del núcleo del sistema operativo que manejan la red
- Configuración de la memoria caché del sistema de ficheros
La configuración específica y los valores son diferentes en cada caso.
Siempre póngase en contacto con el proveedor de sistema operativo para obtener información sobre la configuración.
Elección del sistema de ficheros
La elección del sistema de ficheros depende de la elección del sistema operativo y del sistema de acceso a los datos. Pero en cualquier caso el sistema de ficheros debe:
- Mantener operaciones simultáneas con los ficheros de una carpeta realizadas por las distintas unidades del clúster
- Lidiar con millones de ficheros pequeños
- Manejar alrededor de 10.000 ficheros en una carpeta
- Mantener la ruta al fichero de más de 255 bytes
- Mantener los caracteres multibyte en los nombres de ficheros y carpetas
Requisitos del sistema operativo
- El nombre del servidor debe corresponder al nombre del dominio principal en la clave de licencia (por ejemplo, la licencia — *.domain.com, servidor — frontend1.domain.com)
- Todas las direcciones IP utilizadas en la administración se configuran antes de la instalación de CommuniGate Pro
- En el sistema operativo no están instalados otros servidores de correo
- En la configuración del sistema operativo hay servidores DNS que funcionan
- En el momento de la instalación en el sistema no hay firewalls (pueden instalarse más tarde)
Además de lo mencionado se recomienda revisar cuidadosamente la productividad de los backends antes de la instalación de CommuniGate Pro y el montaje del depósito.
Ejemplos prácticos de selección de hardware
La selección de hardware depende, por supuesto, de muchos factores. Los ejemplos de esta sección se basan en dos versiones estándares del uso de clúster con el fin de formar una idea general sobre qué hardware y arquitectura son óptimos y trabajan de forma estable en la práctica. Los siguientes parámetros influyen en el cálculo de la capacidad y productividad necesarias del "hierro":
- Tipos de servicios prestados (correo electrónico, VoIP, sincronización con dispositivos móviles, Pronto! (Flash cliente al servidor), el número esperado de conferencias de audio, el volumen de datos que almacenan los usuarios, ...)
- En el caso de servicios VoIP, IM o Presence el uso de la redirección\transcodificación del flujo de medios va a ocupar recursos. La opción ideal sería si todos los flujos de medios van de un usuario a otro directamente, pero las redes con topología compleja y la no coincidencia de los códecs de audio a menudo provocan que ese flujo de medios deba ser procesado por el servidor.
- El número de usuarios divididos por tipos de servicios que utilizan.
- El porcentaje de la carga es el número de sesiones activas por número total de las cuentas en las horas máximas divididas por tipo de conexión.
- Los patrones de utilización de servicios (diferentes usuarios pueden diferir significativamente en la cantidad de clientes de correo electrónico, móviles y llamadas por unidad de tiempo).
Todos estos factores deben ser evaluados para la formación de requisitos de hardware. En base a ellos y en la práctica de implementación de la multitud de Clusters Dinámicos, el equipo CommuniGate Systems puede ayudar con la selección de la plataforma y de sus parámetros.
Ejemplos:
1. El servicio de correo con notificaciones Push y mensajería instantánea
| El tipo del usuario | El número de usuarios |
| Totale | 70.000 |
| POP | 70.000 |
| IMAP/MAPI | 70.000 |
| WebMail & Pronto! (Flash) | 70.000 |
| Sincronización con dispositivos móviles | 5.000 |
| Mensajes (XMPP/SIP) y estados (Presence) | 70.000 |
2. El tráfico previsto en la proporción:
| Protocolo | El porcentaje de tráfico (%) |
| POP | 20 |
| IMAP | 20 |
| MAPI | 5 |
| WebMail | 35 |
| Señales (XMPP/SIP) | 20 |
La cantidad de usuarios simultáneos conectados: 4.000.
Arquitectura recomendada:
Clúster Dinámico 3x3.
Frontends
HP DL380G6 X5550
CPU: 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8MB L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Memoria: 12 GB
Controladores de red: 2 x HP NC382i Dual Port Multifunction Gigabit Server Adapters
Controlador de depósito: HP Smart Array P410i/512MB, BBWC
Sistema operativo: SuSE o Redhat Linux 64bit
Backends
HP ProLiant DL580G5 X7460 16GB (4P)
CPU: Intel® Xeon® X7460 (6 core, 2.67 GHz, 16 MB L3, 130W)
Memoria: 16 GB
Controladores de red: 1GbE NC373i Multifunction 2 Ports
Controlador de depósito: Smart Array P400i/512MB, BBWC
Sistema operativo: SuSE o Redhat Linux 64bit
Al aumentar el número de usuarios hasta 100.000 la configuración debe reforzarse por un frontend (4x3). Con el aumento hasta 200.000 - 6 frondends y 4 backends.
3. El servicio VoIP con Pronto! como softphone, Audio HD con la conversión de los flujos de media
| Tipo de usuarios | Número de usuarios |
| Total | 2.000.000 |
| VoIP | 90.000 |
Relación de tipos de tráfico:
| Protocolo | El porcentaje de tráfico (%) |
| RTP | 80% |
| XIMSS (Pronto! — el sistema de alarma, correo electrónico, calendarios) | 20% |
El número total de llamadas simultáneas: 9.000.
El número de sesiones de usuario abiertas al mismo tiempo: 90.000.
Arquitectura recomendada:
Clúster dinámico 3х3.
Frontends
DELL PowerEdge R710
CPU: 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8MB L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Memoria: 24 GB
Controladores de red: 2 x HP NC382i Dual Port Multifunction Gigabit Server Adapters
Controlador de depósito: HP Smart Array P410i/512MB, BBWC
Sistema operativo: SuSE o Redhat Linux 64bit
Backends
DELL PowerEdge R710
CPU: 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8MB L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Memoria: 16 GB
Controladores de red: 1GbE NC373i Multifunction 2 Ports
Controlador de depósito: Smart Array P400i/512MB, BBWC
Sistema operativo: SuSE o Redhat Linux 64bit
Consejos para la configuración del depósito de datos para el clúster
En un dominio de clúster de todas las cuentas de usuario deben estar disponibles para todos backends. Recomendamos para la organización del depósito NAS con el protocolo NFS, porque el clúster CommuniGate Pro no utiliza el bloqueo de ficheros en el nivel del sistema de ficheros, NFS es el mejor protocolo para él.
Varios puntos de acceso y varios servidores NFS se pueden utilizar en el mismo clúster. Ejemplos de las soluciones utilizadas:
| NETAPP FAS2000 | EMC Celerra NS-120 | SUN Storage 7110 |
 |
 |
 |
La estructura de ficheros en el clúster
Cuentas de usuario en el dominio compartido se guardan en las carpetas con la ruta similar:
SharedDomains/domainName/accountName.macnt/
Por ejemplo:
SharedDomains/company.com/aivanov.macnt/
Mantener decenas de miles de cuentas en el mismo directorio es incómodo (la mayoría de sistemas de ficheros abren las carpetas con grandes cantidades de objetos lentamente). Por lo tanto, fue inventado el mecanismo "Account-level foldering", cuando las cuentas de usuario se guardan en un conjunto de subcarpetas:
SharedDomains/company.com/a.sub/aivanov.macnt/
o
SharedDomains/company.com/a.sub/i.sub/aivanov.macnt/
o
SharedDomains/company.com/ai.sub/v.sub/aivanov.macnt/
Si en un clúster se colocan muchos dominios (alrededor de 5.000), tiene sentido utilizar "Domain-level foldering":
SharedDomains/c.sub/company.com/aivanov.macnt/
SharedDomains/c.sub/o.sub/company.com/aivanov.macnt/
O en el caso de un gran número de grandes dominios:
SharedDomains/c.sub/company.com/a.sub/i.sub/aivanov.macnt/
Es mejor seleccionar un método de dividir en carpetas, una vez que se conoce el número de usuarios y dominios. Pero cambiar esta configuración se puede y en el proceso de funcionamiento del clúster.
Optimización de almacenamiento con SSD
CommuniGate Pro tiene una característica que puede utilizarse para optimizar el almacenamiento con SSD.
Cada cuenta de usuario en la carpeta tiene ficheros account.setting и account.info. Estos ficheros se leen cada vez que un usuario entra en esta cuenta de usuario, y el fichero.info cambia cada vez que cambian los metadatos de la cuenta (por ejemplo, al registrar el aparato SIP).
Para mejorar la eficiencia general de almacenamiento se puede guardar estos ficheros por separado en un soporte más caro y eficaz (SSD). Para 1 millón de cuentas de usuario el tamaño total de todos estos ficheros será de 5 a 20 Gb.
Por ejemplo, supongamos que con una configuración estándar de clúster, los ficheros se almacenan en la carpeta:
SharedDomains/company.com/a.sub/aivanov.macnt/account.settings
SharedDomains/company.com/a.sub/aivanov.macnt/account.info
Si activamos el uso de "Fast Storage Type" (lo establecemos en un valor distinto de cero, por ejemplo, 1), entonces la ruta de acceso a .info y .settings de los archivos será:
SharedDomains/company.com/fast/a.sub/aivanov.settings
SharedDomains/company.com/fast/a.sub/aivanov.info
Por lo tanto, se puede instalar un depósito rápido en la dirección
SharedDomains/company.com/fast/,
y todos ficheros .settings y .info estarán almacenados en él.
Cluster Simétrico Dinámico
El clúster CommuniGate Pro se puede configurar de tal manera que cada unidad funcione como un frontend, y como backend. Esto se denomina configuración simétrica:
Super Clúster (clúster de clústeres)
Esta configuración se aplica cuando hay que proveer:
La distribución regional de capacidades para mejorar la calidad de comunicación y el acceso local para los usuarios.
Servicio para una gran cantidad de usuarios (más de 15 millones de cuentas de usuario) para dividir la carga entre varias Clústers Dinámicos.
El Cluster Dinamico en la configuración SIP granja
Granja SIP es una tecnología de la empresa CommuniGate Systems para la agrupación en clústeres de VoIP y para alcanzar el tiempo de disponibilidad del servicio con una reserva de seguridad y escalabilidad del 99,999%.
Un Clúster Dinamico normal y un Super Clúster pueden ser configurados como SIP granja (en este caso decimos que una parte de unidades están separadas en granjas SIP).
Los paquetes SIP UDP entrantes o TCP conexiones se distribuyen, como de costumbre, a través de equilibradores de carga. El servidor que ha recibido el paquete determina si no debe procesarse en otro miembro de SIP granja (si es la respuesta o ACK para una solicitud existente o un paquete para la tarea creada en un determinado servidor) y lo envía si es necesario.
Los paquetes no destinados para unidades concretas se distribuyen entre los miembros de la granja por algoritmos de clústeres de acuerdo con la carga y la disponibilidad de las unidades en en la granja SIP.
Resultados
El Clúster Dinámico está considerado el mejor entre todas las posibles configuraciones de servidor CommuniGate Pro. Históricamente, es decir en "use cases" similares a los mencionados en el artículo, son servicios de alta productividad diseñados para el consumo masivo que siempre han sido la base del diseño del producto.
Si Usted tiene alguna pregunta sobre el producto, no dude en ponerse en contacto por el correo electrónico russia@communigate.ru. Para preguntas technicas dificiles— support@communigate.ru
Descargue la versión gratis (hasta 5 usuarios, sin clúster) en nuestro sitio web.