Cluster dynamique CommuniGate Pro

Le cluster dynamique Communigate Pro implémente une architecture dans laquelle tous les nœuds sont "actifs". De nombreuses autres solutions se contentent des programmes de récupération après une perte ou pour un remplacement urgent (redondance à chaud), mais pas dans le cluster dynamique où tous les systèmes fonctionnent de concert comme une seule entité logique et tous les nœuds prennent leur part de la charge. Parallèlement, il est possible de retirer à tout moment chaque nœud ou en ajouter un nouveau dans n'importe quel rôle. Ainsi, le cluster dynamique permet de fournir n'importe quel membre et d'augmenter (ou réduire) les capacités utilisées directement lors du fonctionnement sans interrompre les services.

Les principaux avantages du Cluster dynamique dont nous parlerons en détail ci-dessous sont les suivants :

• Maintenance technique des nœuds sans arrêt du service
• Système unifié
• Utilisation efficace des serveurs
• Scalabilité prévisible à faible coût
• Haute disponibilité des services

Maintenance technique des nœuds sans arrêt du service

Les mises à jour du logiciel et du matériel sur les nœuds peuvent nuire considérablement à la disponibilité du système de communications. Ces empêchements sont souvent appelés des " arrêts planifiés " dans le domaine de l'informatique corporatif. Malheureusement, ces pannes sont totalement inacceptables dans le domaine des solutions SaaS du niveau opérateur. Imaginez si un téléphone fixe était débranché chaque samedi pour raison de maintenance.

Pour éviter la nécessité de débrancher, le cluster dynamique dispose d'un mécanisme de mises à jour successives. Ce mécanisme de mises à jour permet à l'administrateur du cluster de désactiver le nœud en répartissant les connexions ouvertes sur d'autres membres du cluster tant que le nœud n'est pas complètement rétabli. Ensuite, il sera disponible pour le service, puis il pourra être renvoyé dans le cluster.

Système unifié

Le Cluster Dynamique CommuniGate Pro permet à l'opérateur de traiter l'ensemble du système comme une seule entité, même si elle se compose de plus de 40 serveurs. Ainsi, la gestion d'une infrastructure à grande échelle est beaucoup plus facile que les systèmes de niveau corporatif.

Les fournisseurs SaaS offrant des services aux petites entreprises et aux entrepreneurs individuels nécessitent un système facilement évolutif. Par conséquent, pour nos clients utilisant le Cluster dynamique, le service le plus commun est le cloud qui supporte plus de 20 000 petites (5-30 utilisateurs finaux) entreprises.

Parallèlement, pour les solutions IP PBX et la messagerie électronique qui ne sont pas conçues pour être utilisées comme une plate-forme SaaS, la gestion devient beaucoup plus compliquée avec le développement de la base d'utilisateurs. Ceci est dû au fait que le nombre de parties séparées augmente : les serveurs proxy, les bases de données, les serveurs LDAP, les passerelles média, etc.

Le Cluster dynamique est une solution élégante qui évolue sans coûts supplémentaires avec votre base d'utilisateurs.

Efficacité

La plate-forme CommuniGate Pro utilise de manière très efficace les ressources matérielles. Par conséquent, le fournisseur peut obtenir une densité plus importante d'utilisateurs sur chaque serveur en fonction des solutions corporatives. La densité d'utilisateurs est critique dans les centres de traitement de données, car elle permet de réduire considérablement les frais d'administration, d'électricité et de refroidissement.

CommuniGate Pro peut atteindre 90 000 sessions par système sur la plupart des systèmes de classe d'opérateur 64 bits (Solaris, Linux, BSD) . Des configurations ont également été testées pour plus de 450 000 utilisateurs finaux dans un même système.

Scalabilité prévisible

Le Cluster dynamique est un système avec une surcharge minimale pour la scalabilité. Pour augmenter la capacité du système, il suffit de simples serveurs à bas prix de format 1U ou de serveurs lames. Contrairement aux autres architectures aux exigences élevées en matière de capacités de calcul pour CommuniGate Pro, il est recommandé de ne pas utiliser de serveurs trop puissants (tels que 8-way). Par exemple, il est préférable d'avoir un cluster dynamique 4x4 à serveurs 2-processeurs que 2x2 à serveurs 4-processeurs, car dans le premier cas, la charge spécifique agissant sur un seul serveur est beaucoup plus faible.

Sachant que le code source de CommuniGate Pro est bien parallélisé, les ressources de calcul et la mémoire sont utilisées aussi efficacement que possible et l'estimation du volume des ressources nécessaires en cas d'augmentation de la base d'utilisateurs est transparente et proche d'une fonction linéaire. Tous les nœuds du cluster CommuniGate Pro utilisent le même fichier exécutable, il n'existe donc aucune différence de performances des nœuds, typiques aux architectures hétérogènes.

La structure élégante du Cluster dynamique permet aux prestataires de services d'analyser et de prévoir leurs coûts de manière très précise, que ce soit pour un serveur ou pour un entrepôt de données.

Haute accessibilité

L'une des propriétés et des objectifs de développement principaux du cluster dynamique est d'atteindre le niveau zéro en termes de durée de mise hors service. Tous les nœuds du cluster sont actifs et, en cas de la faillite de l'un d'entre eux, les autres membres du cluster prendront la charge d'utilisateurs.

Architecture du cluster dynamique

Les principaux éléments de l'architecture du cluster de CommuniGate Pro comprennent :

• Équilibreur de charge
• Topologie du réseau
• Front-end
• Back-end
• Stockage commun de type NFS/CFS

Équilibreur de charge

Le cluster est constitué de plusieurs serveurs, donc pour permettre aux utilisateurs d'accéder à l'une adresse URL ou IP, il est nécessaire d'avoir un équilibreur de charge. Il existe de nombreux clusters dynamiques en fonctionnement à travers le monde qui utilisent divers équilibreurs. Nous recommandons d'utiliser uniquement des appareils L4 de haute qualité avec un bon débit de transmission de Cisco, F5, Foundry. Pour de plus amples informations sur la configuration des équilibreurs, veuillez vous référer au manuel.

De plus, les front-ends sur Linux peuvent eux-mêmes effectuer les fonctions d'équilibreurs à l'aide du noyau intégré IPVS.

Topologie du réseau

Pour l'organisation d'un cluster dynamique, on utilise au moins 4 réseaux distincts et plusieurs commutateurs à grande vitesse pour obtenir une performance optimale. Nous recommandons Cisco, F5, Foundry, HP, ou d'autres commutateurs de niveau similaire fournissant une vitesse de gigaoctets. Par conséquent, il devra s'agit de dispositifs simples et fiables tels que la série Cisco Catalyst 2960 que nous citons à titre d'exemple.

Chaque serveur du cluster doit avoir au moins trois interfaces de réseau. Voici l'ensemble de configurations de réseau nécessaire pour un bon fonctionnement du cluster dynamique :

• Le réseau public est un réseau externe avec des adresses IP autorisées. En général, chaque front-end dispose d'une telle adresse (avec enregistrements DNS) et l'équilibreur disposant d'une ou de plusieurs adresses. Exemple :
  
  Équilibreur , 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


• Les utilisateurs finaux n'utilisent que uc.domain.com dans leurs applications client. Quant à l'équilibreur, il répartit les demandes aux front-ends actifs. Les enregistrements DNS pour front-ends sont nécessaires pour apporter aux administrateurs plus de commodité.
• Le réseau pour l'échange inter-cluster est un réseau d'adresses IP privées utilisé pour transférer des informations entre les nœuds d'un cluster, aucun autre trafic n'est autorisé, c'est pourquoi les front-ends utilisent pour ce réseau une interface (seconde) indépendante.
• Le réseau pour stockage est un réseau interne utilisé par les back-ends pour communiquer avec l’entrepôt principal. Il doit s'agir d'un réseau à haut débit, de fibre optique ou Ethernet 10 Go.
• Le réseau de gestion est un réseau fermé. Il s'agit généralement du réseau d'un fournisseur local. Il est destiné aux administrateurs, ainsi que pour appeler la facturation API, les plug-ins et d'autres tâches nécessaires pour la gestion du cluster.

Front-ends

Dans un cluster, les front-ends réalisent les fonctions suivantes :

• Volume de messages via le protocole SMTP avec d'autres serveurs.
• Organisation de la signalisation SIP et exécution des applications PBX (cette fonction est synchronisée entre les nœuds et ces clusters sont également nommés des fermes SIP, SIP Farm)
• Fonctions de protection : RBL, compteurs d'erreurs et volume d'informations reçues d'une adresse, listes noires/blanches des adresses IP et DNS, etc.
• Organisation des connexions client-serveur (IMAP, POP, HTTP, XIMSS, etc.). Après l’établissement de la connexion, le front-end appellera le back-end uniquement pour demander des données.
• Gestion des connexions SSL.

Back-ends

Les back-ends du cluster dynamique forment le noyau de la plateforme.

Il sont responsables de :

• Paramètres de domaine
• Paramètres des comptes
• Messages et autres objets créés par les utilisateurs
• Données supplémentaires pour le cluster
• Gestion de cluster
• Authentification
• Génération de pages HTML selon WSSP

La technologie de synchronisation utilisée au niveau du compte dans les back-ends garantit qu'un seul serveur aura accès à tout moment (intervalles de 6 secondes) aux fichiers du compte. Le cluster CommuniGate Pro évite ainsi de recourir au verrouillage des fichiers au niveau du système de fichiers (à l'exception d'un seul : heartbeat.data, verrouillé par le contrôleur du cluster). Comme le cluster ne repose pas sur des mécanismes de verrouillage du système de fichiers, la performance de NFS est 5 à 7 fois supérieure.

Le cluster dynamique supporte la mise à jour en séquence des nœuds et la récupération automatique et à tout moment après une panne d'un nœud. La configuration recommandée dans ce cas est un cluster de 3x3 (3 front-ends, 3 back-ends). Mais pour un débranchement planifié, il est recommandé d'utiliser un arrêt " soft " : paramètre " Make Not-Ready " dans l'interface WebAdmin sur la page Monitors> Clusters.

Installation du cluster

La partie la plus critique du cluster dynamique est l'entrepôt de données.

Nous recommandons d'utiliser des solutions NAS ou SAN en fonction de votre système d'exploitation et des fonctionnalités disponibles telles que les protocoles NFS et les différents systèmes de fichiers (CFS).

L'installation est réalisée selon les étapes suivantes :

• Configuration du réseau
• Configuration du système d'exploitation
• Choix du système de fichiers et de l'entrepôt de données
• Exécution des exigences au système d'exploitation
• Configuration de CommuniGate Pro.

Configuration du réseau

Le cluster CommuniGate Pro permet une certaine flexibilité des paramètres du réseau. Il est possible de :

• Ajouter tous les sous-réseaux du cluster via NAT
• Utiliser des adresses WAN directes
• Les réseaux de type mixte, les front-ends se trouvent donc dans le réseau DMZ et les back-ends dans un réseau sécurisé.

CommuniGate Pro peut gérer des centaines d'adresses IP et les attribuer aux domaines spécifiques qu'il dessert.

Les administrateurs peuvent parfois obtenir de meilleures performances à partir d'un nœud de clusters par une simple reconfiguration du système d'exploitation. Réglages classiques soumis à des ajustements :

• Limitation du nombre de fichiers ouverts
• Limitation du nombre de processus en cours activés par le même utilisateur
• Tampons et mémoire cache de réseau
• Configuration des principaux éléments du système d'exploitation contrôlant le réseau
• Paramètres de la mémoire cache du système de fichiers

Les paramètres et les valeurs de réglage spécifiques sont différents dans chaque cas.

Toujours vérifier auprès du fournisseur du système d'exploitation les effets secondaires des réglages.

Choix du système de fichiers

Le choix du système de fichiers dépend du système d'exploitation et du système d'accès aux données. Ceci dit, le système de fichiers doit :

• Supporter des opérations simultanées sur les fichiers d'un dossier, effectuées par différents nœuds du cluster
• Gérer des millions de petits fichiers
• Gérer environ 10 000 fichiers dans un dossier
• Gérer un chemin d'accès à un fichier supérieur à 255 octets
• Gérer les caractères multi-octets dans les noms de fichiers et de dossiers

Exigences du système d'exploitation

• Le nom du serveur doit correspondre au nom du domaine principal de la clé de licence (par exemple, pour la licence : * .domain.com et pour le serveur : frontend1.domain.com)
• Toutes les adresses IP utilisées pour l'administration sont configurées avant l'installation de CommuniGate Pro
• Aucun autre serveur de messagerie n'a été installé dans le système d'exploitation
• Des serveurs DNS opérationnels se trouvent dans la configuration du système d'exploitation
• Lors de l'installation du système, il n'existe pas de pare-feu (ils peuvent être installés ultérieurement)

En plus des éléments susmentionnés, il est vivement recommandé de vérifier soigneusement la performance des back-ends avant d'installer CommuniGate Pro et de monter l'entrepôt.

Exemples pratiques de sélection du matériel (hardware).

Le choix du matériel dépend bien entendu de plusieurs facteurs. Les exemples de cette section sont basés sur l'utilisation de deux versions standards du cluster pour permettre d'avoir une idée générale du fonctionnement (stable et optimale dans la pratique) des équipements et de l'architecture. Les paramètres suivants affectent le calcul de la capacité requise et la performance du hardware :

• Types de services proposés (messagerie électronique, VoIP, synchronisation avec appareils mobiles, Pronto! (client Flash pour serveur), nombre envisagé de conférences audio, volume de données stockées par les utilisateurs, etc.)
• Pour les services VoIP, IM, Presence, la redirection/le transcodage du flux média utilisera des ressources. La situation idéale serait que tous les flux de médias passent directement d'un utilisateur à l'autre, mais le réseau présente une topologie complexe et un décalage des codecs audio induisent souvent au fait que le flux de médias doit être traité par le serveur.
• Nombre d'utilisateurs, repartis selon les types de services qu'ils utilisent.
• Le pourcentage de la charge est le nombre de sessions actives par rapport au nombre total de comptes aux heures de pointe, divisé par le total des types de connexion.
• Les modèles d'utilisation des services (différents utilisateurs peuvent varier considérablement selon le nombre de clients de messagerie, des appels mobiles par unité de temps).

Tous ces facteurs doivent être pris en considération pour établir les exigences matérielles. Sur cette base et d'après l’expérience pratique du déploiement de plusieurs clusters dynamiques, l'équipe de CommuniGate Systems offre son aide pour choisir la plate-forme et ses paramètres.

Exemples :

1. Service de messagerie avec les notifications Push et la messagerie instantanée

Taux du trafic prévu :

Le nombre prévu d'utilisateurs connectés simultanément : 4 000.

Architecture recommandée :

Cluster dynamique 3х3.

Front-ends

HP DL380G6 X5550
CPU : 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8Mo L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Mémoire : 12 Go
Contrôleurs de réseau : 2 x HP NC382i Dual Port Multifunction Gigabit Server Adapters
Contrôleur de stockage : HP Smart Array P410i/512 Mo, BBWC
Système d'exploitation : SuSE or Redhat Linux 64bit

Back-ends

HP ProLiant DL580G5 X7460 16 Go (4P)
CPU : Intel® Xeon® X7460 (6 core, 2,67 GHz, 16 MB L3, 130W)
Mémoire : 16 Go
Contrôleurs de réseau : 1GbE NC373i Multifunction 2 Ports
Contrôleur de stockage : Smart Array P400i/512MB, BBWC
Système d'exploitation : SuSE or Redhat Linux 64bit

En cas d'augmentation du nombre d'utilisateurs jusqu'à 100 000, il est nécessaire de renforcer la configuration avec un front-end (4x3). En cas d'augmentation jusqu'à 200 000 : avec 6 front-ends et 4 back-ends.

3. Service VoIP avec Pronto! comme softphone, Audio HD avec conversion des flux de média

Relation des types de trafic :

Nombre total d'appels simultanés : 9 000.

Nombre se sessions d'utilisateurs ouvertes simultanément : 90 000.

Architecture recommandée :

Cluster dynamique 3х3.

Front-ends

DELL PowerEdge R710
CPU : 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8Mo L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Mémoire : 24 Go
Contrôleurs de réseau : 2 x HP NC382i Dual Port Multifunction Gigabit Server Adapters
Contrôleur de stockage : HP Smart Array P410i/512 Mo with BBWC
Système d'exploitation : SuSE or Redhat Linux 64bit

Back-ends

DELL PowerEdge R710
CPU : 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8Mo L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Mémoire : 16 Go
Contrôleurs de réseau : 1GbE NC373i Multifunction 2 Ports
Contrôleur de stockage : Smart Array P400i/512MB BBWC
Système d'exploitation : SuSE or Redhat Linux 64bit

Conseils pour configurer l'entrepôt de données pour le cluster

Dans le domaine cluster, tous les comptes d'utilisateurs devraient être accessibles à tous les back-ends. Nous recommandons d'utiliser pour l'organisation du stockage NAS avec le protocole NFS, car le cluster CommuniGate Pro n'utilise pas le verrouillage des fichiers au niveau du système de fichiers, le protocole NFS est donc le plus approprié dans ce cas.

Plusieurs points d'accès et plusieurs serveurs NFS peuvent être utilisés dans le même cluster. Exemples de solutions utilisées :

NETAPP FAS2000	EMC Celerra NS-120	SUN Storage 7110

Structure des fichiers dans le cluster

Les comptes dans le domaine public sont sauvegardés dans des dossiers comme suit :

SharedDomains/domainName/accountName.macnt/

Exemple :

SharedDomains/company.com/aivanov.macnt/

Sauvegarder des dizaines de milliers de comptes dans le même répertoire est difficile (la plupart des systèmes de fichiers ouvrent lentement les dossiers comportant un grand nombre d'objets). Par conséquent, nous avons inventé le mécanisme de " Account-level foldering " (" Dossiers au niveau du compte "). Il consiste à faire en sorte que les comptes soient stockés dans un ensemble de sous-dossiers :

SharedDomains/company.com/a.sub/aivanov.macnt/

ou

SharedDomains/company.com/a.sub/i.sub/aivanov.macnt/

ou

SharedDomains/company.com/ai.sub/v.sub/aivanov.macnt/

Si un cluster comporte un grand nombre de domaines (environ 5 000), il est logique d'utiliser la méthode de " Domain-level foldering " (" Dossiers au niveau du domaine ") :

SharedDomains/c.sub/company.com/aivanov.macnt/
SharedDomains/c.sub/o.sub/company.com/aivanov.macnt/

Ou en cas d'un nombre important de domaines :

SharedDomains/c.sub/company.com/a.sub/i.sub/aivanov.macnt/

Il est préférable de choisir un moyen de répartition en dossiers dès que vous connaissez le nombre d'utilisateurs et de domaines. Ceci dit, il est possible de modifier ces paramètres pendant le fonctionnement du cluster.

Optimisation du stockage via SSD

CommuniGate Pro dispose d'une fonction qui peut être utilisée afin d'optimiser le stockage via SSD.

Chaque compte dispose de fichiers account.setting account.info dans le dossier. Ces fichiers sont lus chaque fois qu'un utilisateur entre dans ce compte, et le fichier .info est modifié chaque fois que les métadonnées du compte sont changées (par exemple, lors de l'enregistrement d'un dispositif SIP).

Pour améliorer l'efficacité globale du stockage, il est possible de sauvegarder séparément ces fichiers sur un support plus onéreux et efficace (SSD). Pour 1 million de comptes, la taille totale de tous ces fichiers sera de 5 à 20 Go.

Par exemple, supposons que les fichiers avec une configuration par défaut du cluster soient stockés dans le dossier :

SharedDomains/company.com/a.sub/aivanov.macnt/account.settings
SharedDomains/company.com/a.sub/aivanov.macnt/account.info

Si vous décidez de recourir à " Fast Storage Type " (" Type de stockage rapide ") (mettre une valeur non nulle, par exemple, à 1), le chemin d'accès aux fichiers .info et .settings sera comme suit :

SharedDomains/company.com/fast/a.sub/aivanov.settings
SharedDomains/company.com/fast/a.sub/aivanov.info

Ainsi, il est possible de configurer un stockage rapide selon le chemin d'accès suivant :

SharedDomains/company.com/fast/,

et tous les fichiers .settings et .info seront sauvegardés dans celui-ci.

Cluster dynamique symétrique

CommuniGate Cluster Pro peut être configuré de sorte que chaque ensemble fonctionne comme un front-end et back-end. Ceci s'appelle une configuration symétrique :

Super Cluster (cluster de clusters)

Cette configuration est utilisée lorsqu'il est nécessaire d'assurer :

Répartition régionale des capacités pour une meilleure qualité de connexion et un accès local pour les utilisateurs.

Service pour un nombre important d'utilisateurs (plus de 15 millions de comptes) afin de répartir la charge sur plusieurs clusters dynamiques.

Cluster dynamique dans une configuration SIP Farm

SIP Farm est une technologie de la société CommuniGate Systems pour la clustérisation VoIP et l'obtention d'une disponibilité de service de 99,999 %, d'une marge de sécurité et de scalabilité.

Un cluster dynamique habituel et un Super Cluster peuvent être configurés comme une SIP Farm (dans ce cas, une partie des nœuds est affectée à la SIP Farm).

Les paquets entrants SIP UDP ou les connexions TCP sont généralement distribués via les équilibreurs de charge. Le serveur ayant reçu un paquet, détermine si ce dernier doit être traité dans un autre membre de SIP Farm (si c'est une réponse ou un accusé de réception pour une requête existante, ou un paquet pour une tâche créée sur un serveur particulier), et le transfère si nécessaire.

Les paquets non destinés à des nœuds spécifiques, seront répartis entre les membres de la SIP Farm selon des algorithmes intraclusters en fonction de la charge et de la disponibilité des nœuds de la SIP Farm.

Conclusions

Le Cluster dynamique est considéré à juste titre comme le produit phare de toutes les configurations possibles du serveur CommuniGate Pro. Historiquement, ce sont les " use cases " (" cas d'usage ") tels que ceux indiqués dans l'article qui sont des services de haute performance, destinés à une utilisation de masse. Ils ont toujours été la base de la conception des produits.

Pour toute question sur le produit, veuillez nous contacter à euro@communigate.ru. Pour toute question technique complexe, veuillez nous contacter à support@communigate.ru

Il est possible de télécharger la version gratuite (jusqu'à 5 utilisateurs, sans clustérisation) de notre site Web.