Dans cet épisode, je vais montrer et expliquer certaines subtilités de la configuration d'un serveur CMS en mode cluster résilient.
ThéorieIl existe trois types de déploiement d'un serveur CMS :
- Single Combined(Uniquement combiné), c'est-à-dire qu'il s'agit d'un seul serveur sur lequel tous les services nécessaires sont exécutés. Dans la plupart des cas, ce type de déploiement est applicable uniquement pour l'accès des clients internes et dans de petits environnements où les limitations de scalabilité et la redondance d'un seul serveur ne posent pas de problème critique, ou dans des situations où le CMS ne remplit que certaines fonctions, comme des conférences spéciales sur Cisco UCM.
Schéma de fonctionnement approximatif :
- Single Split(Uniquement séparé) élargit le type de déploiement précédent en ajoutant un serveur distinct pour l'accès externe. Dans les déploiements obsolètes, cela signifiait déployer un serveur CMS dans la zone démilitarisée (DMZ), où les clients externes pouvaient y accéder, et un serveur CMS dans le cœur du réseau, où les clients internes accédaient au CMS. Ce modèle de déploiement est maintenant remplacé par le type dit Single Edge, qui consiste en des serveurs Cisco Expressway, qui ont ou auront bon nombre des capacités de contournement du pare-feu, de sorte que les clients n'ont pas besoin d'ajouter un serveur de frontière CMS dédié.
Schéma de fonctionnement approximatif :
- Scalable and Resilient(Scalable et résilient) ce type comprend une redondance pour chaque composant, permettant au système de croître avec vos besoins jusqu'à la capacité maximale, tout en garantissant la redondance en cas de défaillance. Il utilise également le concept de Single Edge pour assurer un accès externe sécurisé. C'est le type que nous allons examiner dans cet épisode. Si nous comprenons comment déployer un cluster de ce type, nous ne comprendrons pas seulement les autres types de déploiement, mais nous pourrons également comprendre comment créer des clusters de serveurs CMS en tenant compte de la croissance potentielle des besoins.
Avant de passer au déploiement, il est important de comprendre certaines notions de base, à savoir
Les principaux composants logiciels du CMS :
- Base de données: permet de regrouper certaines configurations, telles que le groupe d'abonnés, les espaces utilisateurs et les utilisateurs eux-mêmes. Il prend en charge la mise en cluster uniquement pour une haute disponibilité (un maître).
- Call Bridge: un service pour les conférences audio et vidéo, offrant un contrôle complet sur la gestion et le traitement des appels et des processus multimédias. Prend en charge la mise en cluster pour une haute disponibilité et scalabilité.
- serveur XMPP: est responsable de l'enregistrement et de l'authentification des clients utilisant l'application Cisco Meeting Application et/ou WebRTC (communication en temps réel, simplement dans le navigateur), ainsi que la signalisation inter-composants. Ne peut être mis en cluster que pour garantir une haute disponibilité.
- Web Bridge: permet l'accès des clients via WebRTC.
- Loadbalancer: fournit un point d'accès unique pour les applications Cisco Meeting App en mode Single Split. Écoute l'interface externe et le port pour les connexions entrantes. De manière égale, le répartiteur de charge accepte les connexions TLS entrantes depuis le serveur XMPP, à travers lequel il peut rediriger les connexions TCP des clients externes.
Dans notre scénario, il ne sera pas nécessaire. - TURN server: offre une technologie de contournement des pare-feux, permettant
d'exposer notre CMS derrière un pare-feu ou NAT pour connecter des clients externes utilisant l'application Cisco Meeting App ou des dispositifs SIP. Dans notre scénario, il ne sera pas nécessaire. - Web Admin: interface administrative et accès à l'API, y compris pour les conférences spéciales Unified CM.
Modes de configuration
Contrairement à la plupart des autres produits Cisco, Cisco Meeting Server prend en charge trois méthodes de configuration, permettant de déployer n'importe quel type de déploiement.
- Ligne de commande (CLI): Interface de ligne de commande, connue sous le nom de MMP, pour les tâches de configuration initiale et de certificats.
- Web Administrator: principalement pour la configuration liée à CallBridge, en particulier lors de la configuration d'un serveur non clusterisé.
- API REST: utilisé pour les tâches de configuration les plus complexes et les tâches liées à la base de données en cluster.
En plus de ce qui précède, utilise le protocole SFTP pour le transfert de fichiers — généralement des licences, certificats ou journaux — vers et depuis le serveur CMS.
Dans les guides de déploiement de Cisco, il est clairement spécifié qu'un cluster doit être déployé avec un minimum de trois serveurs (nœuds) dans le contexte des bases de données. Car seul un nombre impair de nœuds exécutera le mécanisme de sélection d'un nouveau maître de base de données, et en général, le maître de base de données a un lien avec la majorité de la base de données du serveur CMS.
Et comme la pratique le montre, deux serveurs (nœuds) ne sont effectivement pas suffisants. Le mécanisme de sélection s'applique lors du redémarrage du Master, le serveur Slave devient Master uniquement après le redémarrage du serveur. Cependant, si dans un cluster de deux serveurs, le serveur Master « s'éteint », le serveur Slave ne deviendra pas Master ; et si le Slave est « éteint », le serveur Master restant deviendra un Slave.
En revanche, dans le contexte de XMPP, il est nécessaire de constituer un cluster de trois serveurs, car si, par exemple, le service XMPP est désactivé sur l'un des serveurs dont le statut est Leader, l'autre serveur restera en statut Follower et les connexions de CallBridge à XMPP seront perdues, car CallBridge se connecte uniquement à XMPP avec le statut Leader. C’est critique, car aucun appel ne passera.
De plus, ces guides de déploiement montrent un cluster avec un seul serveur XMPP.
Et compte tenu de ce qui précède, il devient clair pourquoi : cela fonctionne en mode de basculement.
Dans notre cas, le serveur XMPP sera présent sur les trois nœuds.
On suppose que nos trois serveurs sont opérationnels.
Enregistrements DNS
Avant de commencer la configuration des serveurs, il est nécessaire de créer des enregistrements DNS Un et SRV types :
Veuillez noter que dans nos enregistrements DNS, il y a deux domaines example.com et conf.example.com. Example.com est le domaine que tous les abonnés de Cisco Unified Communication Manager peuvent utiliser pour leurs URI, qui est probablement présent dans votre infrastructure ou sera très certainement présent. Ou le domaine example.com correspond au même domaine que les utilisateurs utilisent pour leurs adresses électroniques. Ou bien le client Jabber sur votre ordinateur portable peut avoir une URI user@example.com. Le domaine conf.example.com est celui qui sera configuré pour les utilisateurs de Cisco Meeting Server. Le domaine de Cisco Meeting Server sera conf.example.com, donc pour le même utilisateur Jabber, pour se connecter à Cisco Meeting Server, il faudra utiliser l'URI user@conf.example.com.
Configuration de base
Tous les paramètres décrits ci-dessous sont affichés sur un seul serveur, mais doivent être appliqués sur chaque serveur du cluster.
QoS
Puisque le CMS génère en temps réel Le trafic sensible aux délais et à la perte de paquets nécessite généralement la mise en place de la qualité de service (QoS). Pour ce faire, le CMS prend en charge le marquage des paquets avec des codes de services différenciés (DSCP) qu'il génère. Bien que la priorisation du trafic basée sur DSCP dépende de la manière dont le trafic est traité par les composants réseau de votre infrastructure, dans notre cas, nous configurerons notre CMS avec une distribution typique des priorités DSCP fondée sur les meilleures pratiques QoS.
Nous allons entrer ces commandes sur chaque serveur.
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1AAinsi, tout le trafic vidéo est marqué AF41 (DSCP 0x22), tout le trafic vocal est marqué EF (DSCP 0x2E), les autres types de trafic à faible latence, tels que SIP et XMPP, utilisent AF31 (DSCP 0x1A).
Vérifions :
NTP
Le protocole réseau de temps (NTP) est crucial non seulement pour fournir des horodatages précis pour les appels et les conférences, mais aussi pour la vérification des certificats.
Ajoutons les serveurs NTP à votre infrastructure avec une commande comme celle-ci.
ntp server add Dans notre cas, il y a deux serveurs, donc il y aura deux commandes.
Vérifions :
Et définissons le fuseau horaire pour notre serveur.
DNS
Nous ajoutons des serveurs DNS au CMS avec une commande comme :
dns add forwardzone Dans notre cas, il y a deux serveurs, donc il y aura deux commandes.
Vérifions :
Configuration de l'interface réseau.
Nous configurons l'interface avec une commande comme :
ipv4 add / Vérifions :
Nom du serveur (Hostname)
Nous définissons le nom du serveur avec une commande comme :
hostname Et nous redémarrons.
Ainsi, la configuration de base est terminée.
Certificats
ThéorieLe Cisco Meeting Server nécessite une communication cryptée entre différents composants, et par conséquent, des certificats X.509 sont requis pour toutes les déploiements du CMS. Ils aident à assurer la confiance envers les services/serveur d'autres serveurs/services.
Un certificat est requis pour chaque service, cependant, la création de certificats distincts pour chaque service peut entraîner de la confusion et une complexité inutile. Heureusement, nous pouvons générer une paire de clés publique et privée de certificat, puis les réutiliser pour plusieurs services. Dans notre cas, le même certificat sera utilisé pour le Call Bridge, le serveur XMPP, le Web Bridge et le Web Admin. Ainsi, il faut créer une paire de clés publique et privée de certificat pour chaque serveur du cluster.
La clusterisation de la base de données a toutefois des exigences particulières concernant les certificats et nécessite donc ses propres certificats, différents de ceux des autres services. Le CMS utilise un certificat de serveur similaire à ceux utilisés par d'autres serveurs, mais il y a également un certificat client utilisé pour les connexions à la base de données. Les certificats de la base de données sont utilisés à la fois pour l'authentification et le chiffrement. Au lieu de fournir un nom d'utilisateur et un mot de passe pour connecter le client à la base de données, il présente un certificat client auquel le serveur fait confiance. Chaque serveur du cluster de bases de données utilisera la même paire de clés publique et privée. Cela permet à tous les serveurs du cluster de chiffrer les données de manière à ce qu'elles ne puissent être déchiffrées que par d'autres serveurs utilisant également la même paire de clés.
Pour que la redondance fonctionne, les clusters de bases de données doivent se composer d'au moins 3 serveurs, mais pas plus de 5, avec un temps de propagation maximal de 200 ms dans les deux sens entre les membres du cluster. Cette limite est plus restrictive que pour la clusterisation de Call Bridge, ce qui en fait souvent un facteur limitant dans les déploiements géographiquement distribués.
Le rôle de la base de données pour le CMS a un certain nombre d'exigences uniques. Contrairement à d'autres rôles, il nécessite un certificat client et serveur, où le certificat client possède un champ CN spécifique qui est présenté au serveur.
Le CMS utilise une base de données postgres avec un serveur principal et plusieurs répliques entièrement identiques. À tout moment, il n'existe qu'une seule base de données primaire (« serveur de base de données »). Les autres membres du cluster sont des répliques ou des « clients de base de données ».
Un certificat de serveur dédié et un certificat client sont requis pour le cluster de bases de données. Ils doivent être signés par des certificats, généralement par une autorité de certification privée interne. Étant donné que n'importe quel membre du cluster de base de données peut devenir principal, les paires de certificats du serveur de base de données et du client (contenant les clés publiques et privées) doivent être copiées sur tous les serveurs afin qu'ils puissent accepter l'identité du client ou du serveur de base de données. De plus, le certificat racine CA doit être chargé pour garantir que les certificats client et serveur peuvent être vérifiés.
Nous formons donc une demande de certificat qui sera utilisée par tous les services du serveur, à l'exception de database (pour laquelle il y aura une demande séparée) avec la commande suivante :
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
Dans CN, nous écrivons le nom générique de nos serveurs. Par exemple, si les hostname de nos serveurs server01, server02, server03, alors le CN sera server.example.com
Nous faisons de même sur les deux autres serveurs, avec la différence que les commandes correspondront aux « hostname » respectifs.
Nous formons deux demandes pour les certificats qui seront utilisés par le service database avec les commandes suivantes :
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresoù dbclusterserver et dbclusterclient les noms de nos demandes et futurs certificats, hostname1(2)(3) les noms des serveurs correspondants.
Cette procédure ne doit être effectuée que sur un seul serveur(!), et les certificats ainsi que les fichiers .key correspondants seront chargés sur les autres serveurs.
Activation du mode de certificat client dans AD CS
Il faut également fusionner en un seul fichier les certificats pour chaque serveur.Sous *NIX :
cat server01.cer server02.cer server03.cer > server.cerSous Windows/DOS :
copy server01.cer + server02.cer + server03.cer server.cer Et charger sur chaque serveur :
1. Le certificat « individuel » du serveur.
2. Le certificat racine (avec les intermédiaires s'il y en a).
3. Les certificats pour la base de données (« serveur » et « client ») et les fichiers avec l'extension .key, qui ont été générés lors de la création de la demande pour le certificat « serveur » et le certificat « client » de la base de données. Ces fichiers doivent être identiques sur tous les serveurs.
4. Le fichier de tous les trois certificats « individuels ».
En fin de compte, il devrait y avoir une structure de fichiers similaire sur chaque serveur.
Cluster de Base de Données
Maintenant que vous avez tous les certificats chargés sur les serveurs CMS, vous pouvez configurer et activer la mise en cluster de la base de données entre trois nœuds. La première étape consiste à choisir un serveur comme nœud principal du cluster de base de données et à le configurer complètement.
Base de données principale
La première étape pour configurer la réplication de la base de données est de spécifier les certificats qui seront utilisés pour la base de données. Cela se fait via une commande de type :
database cluster certsMaintenant, indiquons au CMS quel interface utiliser pour la mise en cluster des bases de données avec la commande :
database cluster localnode aEnsuite, nous initialisons la base de données du cluster sur le serveur principal avec la commande :
database cluster initialize
Nœuds de base de données client
Nous effectuons exactement la même procédure, mais au lieu de la commande database cluster initialize nous entrons une commande de type :
database cluster joinoù est l'adresse IP du serveur CMS sur lequel l'initialisation du cluster a été effectuée, simplement le Master.
Nous vérifions comment fonctionne notre cluster de base de données sur tous les serveurs avec la commande :
database cluster status
Nous faisons la même chose sur le troisième serveur restant.
Au final, notre premier serveur est le Master, les autres sont des Slaves.
Service d'administration web
Nous activons le service d'administration web :
webadmin listen a 445Le port 445 est choisi car le port 443 est utilisé pour l'accès des utilisateurs au client web.
Nous configurons le service Web Admin avec les fichiers de certificats à l'aide d'une commande de type :
webadmin certsEt nous activons Web Admin avec la commande :
webadmin enable 
Si tout va bien, nous recevrons des lignes SUCCESS indiquant que Web Admin est correctement configuré pour le réseau et le certificat. Nous vérifions le bon fonctionnement du service à l'aide d'un navigateur web et saisissons l'adresse de l'administration web, par exemple : :445
Cluster de passerelle d'appel
Call Bridge est le seul service présent dans chaque déploiement CMS. Call Bridge est le principal mécanisme de conférence. Il fournit également une interface SIP, de sorte que les appels puissent être routés vers ou depuis celui-ci, par exemple avec Cisco Unified CM.
Les commandes décrites ci-dessous doivent être exécutées sur chaque serveur avec les certificats appropriés.
Donc :
Nous associons les certificats au service Call Bridge avec une commande de type :
callbridge certs []Nous relions les services CallBridge à l'interface requise avec la commande :
callbridge listen aEt redémarrons le service avec la commande :
callbridge restart 
Maintenant que nous avons configuré les Call Bridges, nous pouvons configurer le clustering des Call Bridges. Le clustering des Call Bridges diffère du clustering de bases de données ou XMPP. Un cluster de Call Bridges peut soutenir de 2 à 8 nœuds sans aucune restriction. Il assure non seulement la redondance, mais aussi la répartition de la charge, permettant ainsi aux conférences d'être activement réparties entre les serveurs Call Bridge grâce à une répartition intelligente des appels. Le CMS dispose de fonctionnalités supplémentaires, de groupes de Call Bridges et de fonctions associées qui peuvent être utilisées pour une gestion plus poussée.
Le clustering des Call Bridges se configure principalement via l'interface web d'administration.
La procédure décrite ci-dessous doit être effectuée sur chaque serveur du cluster.
Alors,
1. Accédez via le web à Configuration > Cluster.
2. Dans l'identité Call Bridge entrez un nom unique callbridge[01,02,03] correspondant au nom du serveur. Ces noms sont arbitraires, mais doivent être uniques pour ce cluster. Ils sont descriptifs, car ils indiquent qu'il s'agit des identifiants des serveurs [01,02,03].
3. Dans Call Bridges Clusterisés entre les URLs de l'interface web d'administration de nos serveurs dans le cluster, [01,02,03].example.com:445, dans le champ Adresse. Veuillez spécifier le port. Vous pouvez laisser le domaine Peer link SIP vide.
4. Ajoutez au CallBridge de chaque serveur le certificat, dont le fichier contient tous les certificats de nos serveurs que nous avons fusionnés dans ce fichier au tout début, avec une commande de type :
callbridge trust clusterEt redémarrons le service avec la commande :
callbridge restart 
Au final, chaque serveur devrait afficher ceci :
Cluster XMPP
Le service XMPP dans le CMS est utilisé pour gérer tout l'enregistrement et l'authentification pour les applications Cisco Meeting (CMA), y compris le client web CMA WebRTC. Le Call Bridge lui-même agit également comme client XMPP à des fins d'authentification et doit donc être configuré comme les autres clients. La résilience XMPP est une fonctionnalité prise en charge dans les environnements de production à partir de la version 2.1.
Les commandes décrites ci-dessous doivent être exécutées sur chaque serveur avec les certificats appropriés.
Donc :
Nous relions les certificats au service XMPP avec une commande de type :
xmpp certs []Définissez ensuite l'interface d'écoute avec la commande :
xmpp listen aUn domaine unique est requis pour le service XMPP. C'est le login des utilisateurs. En d'autres termes, lorsque l'utilisateur essaie de se connecter via l'application CMA (ou à travers le client WebRTC), il saisit userID@logindomain. Dans notre cas, cela sera userid@conf.example.com. Pourquoi cela ne peut-il pas être simplement example.com ? Dans notre déploiement spécifique, nous avons choisi notre domaine Unified CM, que les utilisateurs de Jabber utiliseront dans Unified CM, comme example.com, donc nous avons besoin d’un autre domaine pour les utilisateurs CMS afin de router les appels vers CMS et depuis CMS à travers les domaines SIP.
Configurez le domaine XMPP avec une commande de la forme :
xmpp domainEt nous activons le service XMPP avec la commande :
xmpp enableDans le service XMPP, il est nécessaire de créer des identifiants pour chaque Call Bridge, qui seront utilisés lors de l'enregistrement dans le service XMPP. Ces noms sont arbitraires (et ne sont pas liés aux noms uniques que vous avez configurés pour la clustering des ponts d'appel). Sur un serveur XMPP, il est nécessaire d'ajouter trois ponts d'appel, puis d’entrer ces identifiants sur les autres serveurs XMPP dans le cluster, puisque cette configuration ne se range pas dans la base de données du cluster. Plus tard, nous configurerons chaque Call Bridge pour utiliser ce nom et ce secret pour s'enregistrer dans le service XMPP.
Nous allons maintenant configurer le service XMPP sur le premier serveur avec trois Call Bridges : callbridge01, callbridge02 et callbridge03. À chaque compte seront attribués des mots de passe aléatoires. Plus tard, ceux-ci seront saisis sur les autres serveurs Call Bridge pour se connecter à ce serveur XMPP. Nous entrons les commandes suivantes :
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Nous vérifions ensuite ce que nous avons obtenu avec la commande :
xmpp callbridge list 
La même situation doit se retrouver sur les autres serveurs après les actions décrites ci-dessous.
Ensuite, nous ajoutons sur les deux autres serveurs exactement les mêmes paramètres, seulement avec les commandes
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Ajoutez le Secret très soigneusement, afin de ne pas inclure par exemple des espaces supplémentaires.
En fin de compte, chaque serveur doit avoir la même configuration :
Ensuite, sur tous les serveurs du cluster, nous indiquons dans la confiance le fichier contenant les trois certificats, créé précédemment avec une commande de la forme :
xmpp cluster trustNous activons le mode xmpp cluster sur tous les serveurs du cluster avec la commande :
xmpp cluster enableSur le premier serveur du cluster, nous lançons la création du cluster XMPP avec la commande :
xmpp cluster initializeSur les autres serveurs, nous ajoutons au cluster XMPP avec une commande du type :
xmpp cluster joinNous vérifions sur chaque serveur le succès de la création du cluster XMPP avec les commandes :
xmpp status
xmpp cluster statusPremier serveur :
Deuxième serveur :
Troisième serveur :
Connexion du Call Bridge à XMPP
Maintenant que le cluster XMPP est en marche, nous devons configurer les services Call Bridge pour se connecter au cluster XMPP. Cette configuration se fait via le web administrateur.
Nous accédons à chaque serveur dans Configuration > Général et dans le champ Nom unique du Call Bridge nous écrivons des noms uniques de Call Bridge correspondants aux serveurs callbridge[01,02,03]. Dans le champ Domaine conf.example.ru et les mots de passe correspondants, que l'on peut voir
sur n'importe quel serveur du cluster avec la commande :
xmpp callbridge list 
Le champ « Serveur » reste vide, Callbridge effectuera une recherche DNS SRV pour _xmpp-component._tcp.conf.example.com, afin de trouver un serveur XMPP disponible. Les adresses IP de connexion des callbridges à XMPP peuvent différer sur chaque serveur, cela dépend des valeurs retournées pour la requête sur l'enregistrement _xmpp-component._tcp.conf.example.com callbridge, ce qui dépend lui-même des priorités de configuration pour cet enregistrement DNS.
Ensuite, nous allons dans Status > Général pour nous assurer que le service Call Bridge est bien connecté au service XMPP.
Web Bridge
Nous activons le service Web Bridge sur chaque serveur du cluster avec la commande :
webbridge listen a:443Nous configurons le service Web Bridge avec les fichiers de certificats avec la commande de type :
webbridge certsWeb Bridge supporte HTTPS. Il redirigera HTTP vers HTTPS, si configuré pour utiliser « http-redirect ».
Pour activer la redirection HTTP, utilisez la commande suivante :
webbridge http-redirect enablePour que Call Bridge indique à Web Bridge qu'il peut faire confiance aux connexions provenant de Call Bridge, utilisez la commande :
webbridge trustoù il s'agit du fichier contenant tous les trois certificats de chaque serveur dans le cluster.
Cette image doit être sur chaque serveur du cluster.
Nous devons maintenant créer un utilisateur avec le rôle « appadmin », nécessaire pour configurer notre cluster (!), et non pas chaque serveur du cluster de manière individuelle, ainsi les configurations s'appliqueront de manière identique sur chaque serveur en effectuant le processus une fois.
Pour la configuration ultérieure, nous utiliserons .
Pour l'authentification, sélectionnez Basic dans la section Autorisation.
Pour envoyer correctement des commandes vers les serveurs CMS, il est nécessaire de définir l'encodage approprié.
Nous indiquons les Webbridges avec la commande POST avec le paramètre url et la valeur
Dans le Webbridge lui-même, nous indiquons les paramètres nécessaires : accès invité, accès sécurisé, etc.
Groupes de Call Bridge
Par défaut, le CMS n'utilise pas toujours de manière optimale les ressources disponibles pour la conférence.
Par exemple, pour une réunion avec trois participants, chaque participant peut se trouver sur trois Call Bridges différents. Pour que ces trois participants puissent communiquer entre eux, les Call Bridges établissent automatiquement des connexions entre tous les serveurs et clients dans le même espace, de sorte qu'il semble que tous les clients soient sur le même serveur. Malheureusement, l'inconvénient de cela est qu'une conférence de 3 personnes nécessitera maintenant 9 ports médias. C'est manifestement une utilisation inefficace des ressources. De plus, lorsque le Call Bridge est réellement surchargé, le mécanisme par défaut consiste à continuer d'accepter des appels et à fournir des services de qualité inférieure à tous les abonnés de ce Call Bridge.
Ces problèmes sont résolus grâce à la fonction de Call Bridge Group. Cette fonction a été introduite dans la version 2.1 du logiciel Cisco Meeting Server et a été étendue pour prendre en charge l'équilibrage de charge tant pour les appels entrants que sortants, ainsi que pour Cisco Meeting App (CMA), y compris les participants WebRTC.
Pour résoudre le problème de la reconnexion, trois limites de charge personnalisables ont été introduites pour chaque Call Bridge :
LoadLimit est la charge numérique maximale pour un Call Bridge spécifique. Chaque plateforme a une valeur limite de charge recommandée, par exemple 96000 pour CMS1000 et 1,25 GHz par processeur virtuel pour la machine virtuelle. Différents appels consomment un certain nombre de ressources en fonction de la résolution et du cadre participant.
NewConferenceLoadLimitBasisPoints (par défaut 50 % de loadLimit) - définit la limite de charge du serveur, au-delà de laquelle de nouvelles conférences sont rejetées.
ExistingConferenceLoadLimitBasisPoints (par défaut 80 % de loadLimit) - valeur de la charge du serveur, au-delà de laquelle les participants rejoignant une conférence existante seront rejetés.
Alors que cette fonctionnalité a été conçue pour distribuer les appels et équilibrer la charge, d'autres groupes, tels que les serveurs TURN, les serveurs Web Bridge et les dispositifs d'enregistrement, peuvent également être assignés à des groupes de pont d'appel, afin qu'ils puissent également être correctement groupés pour une utilisation optimale. Si l'un de ces objets n'est pas assigné à un groupe d'appel, il est supposé qu'ils sont accessibles à tous les serveurs sans priorité particulière.
Ces paramètres sont configurés ici : :445/api/v1/system/configuration/cluster
Ensuite, nous spécifions à chaque pont d'appel à quel groupe de pont d'appel il appartient :
Premier pont d'appel
Deuxième pont d'appel
Troisième pont d'appel
Ainsi, nous avons configuré le groupe Call Bridge pour une utilisation plus efficace des ressources du cluster Cisco Meeting Server.
Importation des utilisateurs depuis Active Directory
Le service Web Admin dispose d'une section de configuration LDAP, mais elle ne fournit pas de paramètres de configuration complexes, et les informations ne sont pas sauvegardées dans la base de données du cluster, donc la configuration devra être effectuée soit manuellement sur chaque serveur via l'interface Web, soit via l'API, et pour éviter de 'se lever trois fois', nous allons quand même saisir les données via l'API.
Utiliser l'URL pour accéder :445/api/v1/ldapServers nous créons l'objet LDAP Server en spécifiant des paramètres tels que :
- Adresse IP du serveur
- numéro de port
- nom d'utilisateur
- mot de passe
- secure
Secure — vrai ou faux selon le port, 389 — non sécurisé, 636 — sécurisé.
Affichons les paramètres LDAP source sur les attributs dans Cisco Meeting Server.
Le mappage LDAP associe les attributs dans le répertoire LDAP avec les attributs dans CMS. Les attributs sont les suivants :
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Description des attributsJID représente l'identifiant de connexion de l'utilisateur dans CMS. Étant donné qu'il s'agit d'un serveur LDAP Microsoft Active Directory, le JID CMS est associé à sAMAccountName dans LDAP, qui est essentiellement l'identifiant de connexion de l'utilisateur dans Active Directory. Notez également que vous prenez sAMAccountName et y ajoutez le domaine conf.pod6.cms.lab à la fin, car c'est le login que vos utilisateurs utiliseront pour se connecter à CMS.
nameMapping associe ce qui se trouve dans le champ displayName d'Active Directory au champ de nom de l'utilisateur dans CMS.
coSpaceNameMapping crée un nom de l'espace de la CMS basé sur le champ displayName. Cet attribut, avec l'attribut coSpaceUriMapping, est nécessaire pour créer un espace pour chaque utilisateur.
coSpaceUriMapping définit la partie utilisateur de l'URI associée à l'espace personnel de l'utilisateur. Certains domaines peuvent être configurés pour être enregistrés dans l'espace. Si la partie utilisateur correspond à ce champ pour l'un de ces domaines, l'appel sera dirigé vers l'espace de cet utilisateur.
coSpaceSecondaryUriMapping définit un second URI pour atteindre l'espace. Cela peut être utilisé pour ajouter un pseudonyme numérique pour router les appels vers l'espace d'un utilisateur importé, en alternative à l'URI alphanumérique défini dans le paramètre coSpaceUriMapping.
Le serveur LDAP et le mappage LDAP sont configurés. Il est maintenant nécessaire de les lier ensemble en créant une source LDAP.
Utiliser l'URL pour accéder :445/api/v1/ldapSource nous créons un objet LDAP Source, en spécifiant des paramètres tels que :
- serveur
- mapping
- baseDn
- filter
Maintenant que la configuration LDAP est terminée, nous pouvons effectuer une opération de synchronisation manuelle.
Nous faisons cela soit dans l'interface Web de chaque serveur en cliquant sur Synchroniser maintenant dans la section Active Directory
soit via l'API en utilisant la commande POST utilisant l'URL pour accéder :445/api/v1/ldapSyncs
Conférences Ad-Hoc
Qu'est-ce que c'est ?Dans le sens traditionnel, une conférence est lorsque deux participants parlent l'un à l'autre, et l'un des participants (utilisant un appareil enregistré dans Unified CM) appuie sur le bouton « Conférence », appelle une autre personne et après avoir parlé avec ce troisième participant, appuie à nouveau sur le bouton « Conférence » pour rejoindre tous les participants à la conférence à trois.
La conférence Ad-Hoc se distingue d'une conférence planifiée dans la CMS en ce sens qu'il ne s'agit pas simplement d'un appel SIP pour la CMS. Lorsque l'initiateur de la conférence appuie sur le bouton « Conférence » pour inviter tout le monde à la même réunion, Unified CM doit effectuer un appel API à la CMS pour créer une conférence « à la volée », à laquelle tous les appels sont ensuite transférés. Tout cela se produit sans que les participants s'en aperçoivent.
Cela signifie que le Unified CM doit configurer les informations d'identification API et l'adresse / port WebAdmin du service, ainsi que la liaison SIP directement sur le serveur CMS pour continuer l'appel.
Si nécessaire, CUCM peut créer dynamiquement des espaces dans la CMS, afin que chaque appel puisse atteindre la CMS et répondre à la règle des appels entrants qui est destinée aux espaces.
Intégration avec CUCM s'configure de la même manière que décrit dans l'article à l'exception du fait que trois trunks doivent être créés pour le CMS dans Cisco UCM, trois Conference Bridges, indiquer trois Subject Names dans le SIP Security Profile, pour le Route Group, Route List, Media Resource Group et Media Resource Group List, et ajouter quelques règles de routage dans le Cisco Meeting Server.
SIP Security Profile:
Trunks:
Chaque trunk ressemble à ceci :
Conference Bridge
Chaque Conference Bridge ressemble à ceci :
Route Group
Route List
Media Resource Group
Media Resource Group List
Règles d'appel
Contrairement aux systèmes de gestion d'appels plus avancés, tels que Unified CM ou Expressway, pour les nouveaux appels, le CMS ne consulte le domaine que dans le champ SIP Request-URI. Ainsi, si le SIP INVITE est destiné à sip: user@domain.com, le CMS ne s'occupe que de domain.com. Le CMS suit ces règles pour déterminer où acheminer l'appel :
1. D'abord, le CMS tente de faire correspondre le domaine SIP avec les domaines configurés dans les règles de traitement des appels entrants. Ensuite, ces appels peuvent être dirigés vers des espaces 'cibles' ou des utilisateurs spécifiques, des IVR internes ou directement vers des destinataires intégrés Microsoft Lync/Skype pour entreprise (S4B).
2. Si aucune correspondance n'est trouvée dans les règles de traitement des appels entrants, le CMS tentera de faire correspondre le domaine configuré dans le tableau de redirection des appels. Si une correspondance est établie, la règle peut explicitement rejeter l'appel ou le rediriger. À ce moment-là, le CMS peut réécrire le domaine, ce qui est parfois utile pour les appels vers des domaines Lync. Vous pouvez également choisir la transmission, ce qui signifie qu'aucun des champs ne sera modifié, ou utiliser le groupe d'abonnés internes du CMS. Si aucune correspondance n'est trouvée dans les règles de redirection des appels, le rejet d'appel par défaut sera utilisé. Gardez à l'esprit que dans le CMS, bien qu'un appel soit 'redirigé', la multimédia reste attachée au CMS, ce qui signifie qu'elle sera dans le chemin du trafic de signalisation et multimédia.
Alors, seuls les appels redirigés sont soumis aux règles des appels sortants. Ces paramètres définissent les destinataires vers lesquels diriger les appels, le type de ligne de connexion (que ce soit un nouvel appel Lync ou SIP standard) et toute conversion qui peut être effectuée si la transmission n'est pas sélectionnée dans la règle de redirection des appels.
Voici le log de ce qui se passe lors d'une conférence Ad-Hoc
Sur la capture d'écran, c'est difficile à voir (je ne sais pas comment faire mieux), donc je vais écrire le log comme suit:
Info 127.0.0.1:35870: L'utilisateur API "api" a créé un nouvel espace 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info appel de création échoué pour trouver le coSpace -- tentative de récupération depuis la base de données
Info API "001036270012" GUID de l'espace : 7986bb6c-af4e-488d-9190-a75f16844e44 GUID de l'appel : 93bfb890-646c-4364-8795-9587bfdc55ba GUID du corrélateur d'appel : 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 G interne
Info 127.0.0.1:35872: L'utilisateur API "api" a créé un nouvel appel 93bfb890-646c-4364-8795-9587bfdc55ba
Info appel 7 : appel SIP entrant de "sip:672@172.x.x.x" à l'URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info lég de l'appel API bc0be45e-ce8f-411c-be04-594e0220c38e dans l'appel 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (appel API 93bfb890-646c-4364-8795-9587bfdc55ba)
Info la conférence 434f88d0-8441-41e1-b6ee-6d1c63b5b098 a un GUID de contrôle/média : fb587c12-23d2-4351-af61-d6365cbd648d
Info la conférence 434f88d0-8441-41e1-b6ee-6d1c63b5b098 nommée "001036270012"
Info appel 7 : configuré - lég de l'appel API bc0be45e-ce8f-411c-be04-594e0220c38e avec l'ID d'appel SIP "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"
Info appel 7 : configuration de la session RTP UDT pour DTLS (média et contrôle combinés)
Info la conférence "001036270012" : des jambes d'appel non chiffrées sont maintenant présentes
Info le participant "672@172.x.x.x" a rejoint l'espace 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info le participant "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) a rejoint la conférence 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info appel 8 : appel SIP entrant de "sip:690@172.x.x.x" à l'URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info lég de l'appel API db61b242-1c6f-49bd-8339-091f62f5777a dans l'appel 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (appel API 93bfb890-646c-4364-8795-9587bfdc55ba)
Info appel 8 : configuré - lég de l'appel API db61b242-1c6f-49bd-8339-091f62f5777a avec l'ID d'appel SIP "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"
Info appel 8 : configuration de la session RTP UDT pour DTLS (média et contrôle combinés)
Info appel 9 : appel SIP entrant de "sip:673@172.x.x.x" à l'URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info lég de l'appel API 37a6e86d-d457-47cf-be24-1dbe20ccf98a dans l'appel 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (appel API 93bfb890-646c-4364-8795-9587bfdc55ba)
Info appel 9 : configuré - lég de l'appel API 37a6e86d-d457-47cf-be24-1dbe20ccf98a avec l'ID d'appel SIP "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"
Info appel 9 : configuration de la session RTP UDT pour DTLS (média et contrôle combinés)
Info appel 8 : compensation pour le fait que l'extrémité distante ne correspond pas aux types de trames
Info le participant "690@172.x.x.x" a rejoint l'espace 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info le participant "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) a rejoint la conférence 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info appel 7 : compensation pour le fait que l'extrémité distante ne correspond pas aux types de trames
Info appel 8 : mode des types de trames non correspondants 1/0
Info appel 8 : réponse à l'offre dans le mode des types de trames non correspondants
Info appel 8 : offre unique de codec de suivi reçue
Info appel 8 : mode des types de trames non correspondants 1/0
Info appel 8 : réponse à l'offre dans le mode des types de trames non correspondants
Info appel 8 : envoi de la réponse à l'offre de codec unique supplémentaire
Info appel 9 : compensation pour le fait que l'extrémité distante ne correspond pas aux types de trames
Info le participant "673@172.x.x.x" a rejoint l'espace 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info le participant "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) a rejoint la conférence 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info appel 9 : BFCP (rôle client) maintenant actif
Info appel 9 : envoi de salutation BFCP en tant que client après réception de salutation lorsque BFCP n'était pas actif
Info appel 9 : BFCP (rôle client) maintenant actif
Info appel 7 : fin ; fermeture SIP distante - connecté pendant 0:13
Info appel 7 : destruction de la lég de l'appel API bc0be45e-ce8f-411c-be04-594e0220c38e
Info le participant "672@x.x.x" a quitté l'espace 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info appel 9 : en attente
Info appel 9 : mode des types de trames non correspondants 1/0
Info appel 9 : réponse à l'offre dans le mode des types de trames non correspondants
Info appel 8 : en attente
Info appel 8 : offre unique de codec de suivi reçue
Info appel 8 : mode des types de trames non correspondants 1/0
Info appel 8 : réponse à l'offre dans le mode des types de trames non correspondants
Info appel 8 : envoi de la réponse à l'offre de codec unique supplémentaire
Info appel 9 : fin ; fermeture SIP distante - connecté pendant 0:12La conférence Ad-Hoc elle-même :
Règles des appels entrants
La configuration des paramètres des appels entrants est nécessaire pour pouvoir recevoir des appels dans le CMS. Comme vous l'avez vu dans la configuration LDAP, tous les utilisateurs ont été importés avec le domaine conf.pod6.cms.lab. Ainsi, au minimum, vous souhaitez que les appels à ce domaine soient destinés aux espaces. Vous devrez également définir des règles pour tout ce qui est destiné au nom de domaine complet (et peut-être même à l'adresse IP) de chacun des serveurs CMS. Dans notre contrôle d'appels externe, Unified CM, des passerelles SIP seront configurées pour chacun des serveurs CMS individuellement. En fonction de savoir si la destination de ces passerelles SIP est une adresse IP ou si le nom de domaine complet du serveur déterminera si le CMS doit être configuré pour accepter des appels dirigés vers son adresse IP ou son nom de domaine complet.
Le domaine ayant la règle de trafic entrant avec la plus haute priorité est utilisé comme domaine pour tous les espaces utilisateurs. Lorsque les utilisateurs se synchronisent via LDAP, le CMS crée automatiquement des espaces, mais uniquement la partie utilisateur de l'URI (coSpaceUriMapping), par exemple, user.space. La partie de l'URI complet est créée sur la base de cette règle. En fait, si vous vous connectiez à Web Bridge à ce stade, vous verriez que l'URI de l'espace n'a pas de domaine. En définissant cette règle comme ayant la plus haute priorité, vous déterminez le domaine des espaces générés comme conf.example.com.
Règles des appels sortants
Pour permettre aux utilisateurs de passer des appels sortants vers le cluster Unified CM, il est nécessaire de configurer les règles de connexions sortantes. Le domaine des points de terminaison enregistrés dans Unified CM, tels que Jabber, est example.com. Les appels à ce domaine doivent être acheminés comme des appels SIP standard vers les nœuds de traitement des appels Unified CM. Le serveur principal est cucm-01.example.com, et le second cucm-02.example.com.
La première règle décrit la routage simple des appels entre les serveurs du cluster.
Champ Local from domain détermine ce qui sera affiché dans le SIP-URI de l'appelant chez la personne appelée après le symbole « @ ». Si nous laissons ce champ vide, l'adresse IP du CUCM par lequel cet appel passe apparaîtra après le symbole « @ ». Si nous spécifions un domaine, ce domaine apparaîtra après le symbole « @ ». Cela est nécessaire pour permettre un rappel, sinon il sera impossible de rappeler via SIP-URI nom@adresse-IP.
Appel lorsqu'il est spécifié Local from domain
Appel lorsque NON soit désigné Local from domain
Assurez-vous de spécifier explicitement Encrypted ou Unencrypted pour les appels sortants, car avec le paramètre Auto, rien ne fonctionne.
Enregistrement
L'enregistrement des vidéoconférences est effectué par le serveur Record. Le Recorder est exactement le même que le Cisco Meeting Server. Le Recorder ne nécessite pas d'installations de licences. Les licences d'enregistrement sont nécessaires pour les serveurs sur lesquels les services CallBridge sont exécutés, c'est-à-dire que la licence d'enregistrement doit être appliquée au composant CallBridge, et non au serveur où le Recorder est exécuté. Le Recorder fonctionne comme un client du protocole de messagerie et de présence extensible (XMPP), donc le serveur XMPP doit être activé sur le serveur où CallBridge est hébergé.
Puisque nous avons un cluster et que la licence doit être "étendue" à tous les trois serveurs du cluster. Il suffit donc d'associer (ajouter) les adresses MAC des interfaces a de tous les serveurs CMS inclus dans le cluster dans le cabinet personnel sous les licences.
Et c'est l'image que chaque serveur du cluster devrait avoir.
Il existe en fait plusieurs scénarios pour le déploiement du Recorder, mais nous allons nous en tenir à celui-ci :
Avant de configurer le Recorder, il est nécessaire de préparer l'emplacement où les vidéoconférences seront enregistrées. Voilà donc. , comment configurer l'intégralité de l'enregistrement. Je vais souligner les points importants et les détails :
1. Il est préférable de fournir le certificat du premier serveur du cluster.
2. L'erreur « Recorder unavailable » peut survenir parce qu'un mauvais certificat est spécifié dans le Recorder Trust.
3. L'enregistrement peut ne pas se faire si le répertoire racine spécifié dans NFS n'est pas le bon.
Parfois, il est nécessaire d'enregistrer automatiquement la conférence d'un utilisateur ou d'un espace spécifique.
Pour cela, deux CallProfile sont créés :
Avec la fonction d'enregistrement désactivée
Et avec la fonction d'enregistrement automatique
Ensuite, nous "attachons" le CallProfile avec la fonction d'enregistrement automatique à l'espace souhaité.
Dans un CMS, il est établi que si un CallProfile est clairement associé à des espaces, alors ce CallProfile ne fonctionne que pour ces espaces spécifiques. Si un CallProfile n'est associé à aucun espace, il s'applique par défaut aux espaces auxquels aucun CallProfile n'est explicitement lié.
La prochaine fois, j'essaierai de décrire les différentes façons d'accéder au CMS en dehors du réseau interne de l'organisation.
Sources :
Source : habr.com
