Le service d’appel hybride sur l’architecture du connecteur d’appel n’est plus pris en charge (FDL) , donc le service n’est plusofficiellement pris en charge. Le connecteur d’appel ne doit pas être pris en compte pour la planification Expressway capacité future des services hybrides.


Cet article ne couvre pas la planification de la capacité de l’Service de calendrier avec l’intégration Cisco TMS avec Office 365 ou Cisco TMS avec Google Agenda. Pour des informations sur la capacité, voir le Guide de déploiement pour les Service de calendrier hybride Cisco Webex.

Nous fournissons cet article pour répondre à vos questions sur la planification de la capacité et expliquer comment nous calculons l’échelle de l’utilisateur. Pour modéliser votre scénario, essayez le Calculateur de capacité des services hybrides.

Considérations de planification

Lors de la planification Expressway la capacité de votre population d’utilisateurs des services hybrides, considérez les questions suivantes :

  • De quels services hybrides avez-vous besoin ?

    L Expressway peut héberger des connecteurs pour le service d’appel hybride, le service Service de calendrier hybride et le service de message hybride.

  • Combien d’utilisateurs avez-vous, pour chaque service ?

    Plus vous avez d’utilisateurs pour chaque service, plus il est probable que vous voudrez dédier des clusters Expressway aux services. Pour les plus petites populations, l’exécution de plusieurs connecteurs sur un cluster partagé (coresidence) est un choix valide.

  • Vos besoins vont-ils changer ?

    Vous pouvez commencer petit, avec un cluster Expressway fournissant un service à un groupe d’adopteurs précoces dans votre organisation, et planifier la croissance en prévision d’un déploiement prochain. Vous pouvez migrer d’un modèle partagé vers un modèle dédié, ou mettre à l’échelle votre cluster existant, pour répondre à l’évolution de vos besoins.

Facteurs de contribution

Nous définissons la capacité d’un cluster dans les termes des variables suivantes :

  • Taille du nœud—Chaque Expressway Machine virtuelle a une « taille de MV » qui est déterminée au moment de l’installation par les ressources attribuéesà la MV. Les guides d Expressway décrivent ces exigences. Si vous avez déjà un compte Expressway, vous pouvez lire la taille de la MV sur la page Statut > Informations système de l’interface Expressway.

  • Nombre denœuds —Un cluster Expressway cluster peut avoir entre un et six nœuds. Ils doivent être de la même taille de nœud et exécuter la même version du logiciel.

  • Stratégie de continuité de service–Les services utilisent des stratégies pour assurer un service continu aux utilisateurs. Service de calendrier service de messages utilisent une stratégie de panne.

    Les stratégies sont détaillées dans le tableau Stratégies de continuité de service et Échelle des clusters dédiés.

  • Coresidence —Lorsque les connecteurs partagent un cluster Expressway, les ressources disponibles pour chaque service sont significativement plus faibles par rapport aucluster dédié.

    Il peut également y avoir d’autres services basés Expressway sur votre hôte de connecteurs, tels que l’appel d’entreprise à entreprise (B2B) ou Mobile Remote Access (MRA). Dans les scénarios limités où ce type de coresidence est pris en charge, les nombres d’échelle que nous documentons ici sont limitées à ce que nous avons testé. Au-delà de ce qui est décrit dans cet article, le cluster de l Expressway du connecteur ne doit pas être partagé avec d’autres services ; Ceci n’est pas pris en cours d’équipe.

  • Limites spécifiques au service —Par exemple, le connecteur de calendrier est destiné principalement aux utilisateurs de Microsoft Exchange et prend en charge un nombre limité d’utilisateursd’Office 365.

Calculs pour les clusters Expressway dédiés

Nous avons établi une limite fixe au nombre d’utilisateurs du service qu’un seul Expressway dédié peut gérer (un « cluster pour un »), en fonction des preuves que nous collectons au cours des tests et des essais.

Tableau 1. Limites de nombre d’utilisateurs sur des comptes Expressway
Expressway taille du nœud Échelle Service de calendrier hybride Échelle du service de message hybride
1. Petite 5000 5000
2. Moyen 10000 6500
3. Grande 15000 15000

Nous utilisons les algorithmes de continuité de service pour extrapoler les numéros de nœuds simples à des clusters de nœuds multiples, comme l’explique le tableau suivant. Si vous voulez les résultats sans l’explication, voir :

Tableau 2. Stratégies de continuité de service et échelle de clusters dédiés

Comparer

Service de calendrier hybride

Service de messagerie hybride

1. Modèle

Modèle de panne

Modèle de panne

2. Description

Nous attribuons chaque utilisateur à un seul nœud dans le cluster. Ceci répartisse les utilisateurs sur tous les nodes.

Si un nœud est en panne, nous recréons les attributions des utilisateurs à partir de ce nœud sur les autres nœuds.

Lorsque le nœud revient vers le haut, nous requilibrons les attributions des utilisateurs sur tous les nœuds actifs.

Nous attribuons chaque utilisateur à un seul nœud dans le cluster. Ceci répartisse les utilisateurs sur tous les nodes.

Si un nœud est en panne, nous recréons les attributions des utilisateurs à partir de ce nœud sur les autres nœuds.

Lorsque le nœud revient vers le haut, nous requilibrons les attributions des utilisateurs sur tous les nœuds actifs.

3. Formule

UcalN= (N-1) * Ucal1

UmsgN= (N-1) * Umsg1

4. Définitions

Où:

UcalN est le cluster de la capacité N pour Service de calendrier utilisateurs

N est le nombre de nœuds

Ucal1 est la capacité du nœud unique pour Service de calendrier utilisateurs

Où:

U msgN est le cluster de la capacité N pour les utilisateurs du service de messages

N est le nombre de nœuds

Umsg1 est la capacité du nœud unique pour les utilisateurs du service de messages

5. Notes

Si N=1, il n’y a pas de panne.

La panne est automatique et obligatoire si N>1.

Si N=2, la capacité est la même que si N=1, avec une meilleure continuité du service.

Re mesurez les avantages de N>=3 ou en utilisant une taille de nœud plus grande.

Si N=1, il n’y a pas de panne.

La panne est automatique et obligatoire si N>1.

Si N=2, la capacité est la même que si N=1, avec une meilleure continuité du service.

Re mesurez les avantages de N>=3 ou en utilisant une taille de nœud plus grande.

Calculs pour les clusters Expressway partagés

Notre algorithme suppose que les connecteurs de coresident partagent proportionnellement les ressources d’un seul nœud. Cet algorithme fixe de façon conservatrice la limite pour chaque type d’utilisateur sur le nœud.

Par exemple, le tableau suivant montre le nombre maximum d’utilisateurs pour tous les cas dédiés et les cas de coresidence sur un seul Expressway.

Tableau 3. Échelle d’un Expressway pour les scénarios dédiés ou de coresidence
Expressway d’équipe Service de calendrier utilisateurs Utilisateurs du service de messages
Dédié aux Service de calendrier

10,000

Dédié au service de message

6,500

Partagé par le Service de calendrier de l’équipe et de la message

4,000

4,000

Partagé par les services de calendrier, d’appel et de message

2,300

2,300

Nous ne listons pas de manière exhaustive tous les états de coresidence pour toutes les tailles de clusters. Au lieu de cela, vous pouvez contrôler la capacité de déploiement de vos services hybrides existants ou utiliser la calculatrice pour planifier un nouveau déploiement.


La calculatrice vous permet de choisir les connecteurs, la taille des nœuds et le nombre de nœuds, pour vous pouvoir modèler votre déploiement. Le reste de cette section explique comment il calcule les nombres d’utilisateurs à partir de votre modèle.

Tout comme nous l’avons fait pour les Expressway dédiés, nous extrapolons l’algorithme pour les Expressway partagés afin de déterminer le nombre d’utilisateurs pour plusieurs nodes. La différence avec les cas dédiés est que nous appliquons le calcul de continuité de service approprié pour obtenir l’échelle de l’utilisateur pour un service particulier sur le cluster. Nous ne pouvons pas calculer l’échelle d’utilisation du cluster car les hôtes des clusters sont des stratégies de continuité de service concurrentes, basées sur l’utilisateur.

Tableau 4. Capacité d’utilisation sur des clusters de nodes moyens

Utilité du cluster

Utilisateurs du service de message hybride pour les nodes 1,2 et 3

Dédié au service de message

6,500

6,500

13,000

Facteurs contributifs supplémentaires

Il peut y avoir des demandes concurrentes sur les ressources du cluster qui diminueront la capacité d’utilisation. Voici les exemples connus :

Service de calendrier-L’hôte du connecteur peut également servir les utilisateurs d’O365. Les chiffres et les calculs présentés ici supposent que seule votre infrastructure Exchange sur site fournit le Service de calendrier. Pour en savoir plus sur le Service de calendrier « hybride » , nous avons quelques chiffres et graphiques dans la section Service de calendrier de cetarticle.

Traitement desappels—L’hôte du connecteur peut également traiter la signalisation d’appel et les médias. Il s’agit en fait d’une intégration « d’entreprise à entreprise » entre votre organisation et le Cloud Webex. Ceci réduit la capacité décrite dans Coresidency avec Autres solutions Expresswayl’équipe .

Vous pouvez utiliser Control Hub pour afficher un pourcentage de la capacité d’utilisation actuelle de chacun de vos services hybrides Expressway ressources. Une barre de couleurs indique si la capacité est dans les limites acceptables. Cet affichage vous permet d’évaluer l’état du déploiement de votre service hybride et vous guide en vous rappelant quand vous avez besoin de plus d’Expressways.

  • Vert–Vos Expressways sont dans les limites de capacité acceptables. (1%–60%)

  • Ambre–Vous avez assez d’Expressways mais vous êtes à proche des limites de capacité. (61%–90%)

  • Rouge–Vous n’avez pas assez d’Expressways et vous devez en ajouter d’autres. (91 % et plus)


    Si vos Expressways sont dans un groupe de ressources, l’indicateur de capacité s’affiche sous une vue filtrée des clusters dans le groupe de ressources.

  • Pour les déploiements sans groupes de ressources (par défaut) :

    1. À partir de l’affichage du client dans , allez à Services > Hybride , puis faites défiler jusqu’aux cartes de service hybride pour afficher le pourcentage de capacité utilisé sur les ressources Expressway pour https://admin.webex.com chaque service.

  • Pour les déploiements avec des groupes de ressources :

    1. À partir de l’affichage du client dans , allez à Services > hybride , faites défiler jusqu’aux cartes https://admin.webex.com de service hybride, puis sous Ressources cliquez Afficher tout .

      La barre de capacité indique uniquement la capacité des clusters en dehors des groupes de ressources. Si tous les clusters font partie d’un ou plusieurs groupes de ressources ou que le service n’a pas de clusters configurés, la barre de capacité n’est pas affichée.

    2. Si la valeur de la capacité est N/A , choisissez un groupe de ressources à partir de Filtre pour revoir les groupes de ressources & la capacité.

      La valeur se met à jour pour afficher le pourcentage de la capacité qui est utilisé pour les clusters dans ce groupe de ressources et le codage de couleurs pour indiquer l’état de santé.

À retenir :

  • La capacité du cluster varie en fonction de la taille du nœud, du nombre de nœuds dans le cluster Expressway, du nombre de services en cours d’exécution sur le cluster et de la stratégie de haute disponibilité ou de panne. Pour plus d’informations, voir les sections de l’échelle du calendrier et des messages.

  • La coresidence réduit l’échelle de l’utilisateur pour les services existants ; l’algorithme de capacité suppose que tous les utilisateurs utilisent tous les services.


    Nous vous recommandons la coresidence lorsque vous essayez plusieurs services, ou si vous avez un déploiement à petite échelle. Pour les services en production, ou pour les déploiements à grande échelle, nous vous recommandons d’exécuter les différents services hybrides sur des clusters Expressway dédiés.

Ce qu’il faut faire ensuite

Pour ajouter d’autres Expressways pour les services hybrides, utilisez les étapes du guide de déploiement pour enregistrer les hôtes des connecteurs dans le Cloud et les ajouter aux clusters existants :

La capacité d’un cluster Expressway pour les utilisateurs de l’Service de calendrier hybride dépend principalement de la taille et du nombre de clusters et de la stratégie de continuité du service. Le tableau suivant montre la capacité totale d’utilisation maximale que le cluster peut gérer au mesure que vous augmentez le nombre de nœuds (ou la taille de l’OVA du nœud) sur un seul cluster dédié.


Dans un environnement Exchange hybride avec les utilisateurs d’Office 365, il y a une limite de 1 000 utilisateurs d’Office 365 par cluster, indépendamment du nombre ou de la taille des nœuds du cluster. Le service basé sur le Cloud est la méthode préférée de gestion des utilisateurs d’Office 365. Nous vous recommandons vivement d’héberger uniquement temporairement les utilisateurs d’Office 365 Expressway.

Cette limite découle de l’interaction avec le service Microsoft sur le Cloud et non de l’échelle du déploiement de l’Expressway sur site. Par exemple, si vous avez un seul petit nœud Expressway, votre capacité est limitée à 1 000 utilisateurs d’Office 365 et 4 000 utilisateurs Microsoft Exchange. Si vous avez un cluster de 6 petits nodes, votre capacité est limitée à 1 000 utilisateurs d’Office 365 plus 24 000 utilisateurs Microsoft Exchange.

Tableau 5. Capacité d Service de calendrier la capacité d’utilisation du service hybride pour un cluster dédié

Expressway taille du nœud

1 ou 2 nodes*

3 nodes

4 nodes

5 nodes

6 nodes

1. Petite

5 K

10 K

15 K

20 K

25 K

2. Moyen

10 K

20 K

30 K

40 K

50 K

3. Grande

15 K

30 K

45 K

60 K

75 K

* Notez que la capacité d’utilisation est la même pour un cluster d’un nœud et pour un cluster de deux nœuds. La raison est que Service de calendrier utilise le fail-over pour améliorer la continuité du service. Tous les utilisateurs sont attribués à un seul nœud lorsqu’il y a deux nœuds dans le cluster ; l’autre nœud est une sauvegarde redondante. Voir Programmation de la capacité du cluster Expressway pour les utilisateurs des services hybrides pour une explication détaillée.

Attribution des utilisateurs entre les organisateurs et les clusters

Par défaut, l’Service de calendrier attribue et distribue automatiquement les utilisateurs dans tous les connecteurs de calendrier d’un cluster. L’attribution est dynamique en fonction de la disponibilité et l’administrateur n’a aucun contrôle sur le nœud particulier auquel un utilisateur individuel est affecté.

Dans le cas où une organisation dispose de plusieurs clusters, la distribution des utilisateurs est basée sur plusieurs facteurs, y compris la disponibilité des clusters, l’affectation actuelle (pour réduire la tâche de récupération après échec) et un ordre de tri basé sur la préférence des clusters les plus élevées. L’administrateur a également la possibilité d’attribuer un utilisateur ou un groupe d’utilisateurs à un groupe de ressources. Les groupes de ressources sont spécifiques aux clusters, donc ils permettent aux administrateurs de contraintr l’attribution d’ensembles particuliers d’utilisateurs à un cluster spécifique.

Avec cette compréhension de base de attribution de l’utilisateur et la prise en compte des prérequis du connecteur de calendrier Expressway , un administrateur peut déployer la capacité appropriée à l’échelle pour son organisation. Prenons un exemple d’organisation de 126 000 utilisateurs à activer pour les Service de calendrier hybrides, compte tenu des paramètres suivants :

  • Expressway clusters de 6 nœuds en utilisant le grand modèle OVA (limite de 15 000 utilisateurs par nœud)

  • Aucun groupe de ressources n’est requis

La formule de capacité pour un seul cluster, UcalN= (N-1) * U cal1 où N=6 et U cal1 =15 000 (en utilisant le modèle OVA grand) donne un maximum de75 000 utilisateurs. Avec un total de 126 000 utilisateurs dans le déploiement du service de calendrier, plusieurs clusters d’hôtes du Connecteur de calendrier sont requis. Les utilisateurs seront également distribués comme le montre la figure suivante :

Figure 1. Affectation
Deux clusters de 6 nodes chacun ; Le cluster A héberge 12 500 utilisateurs par nœud pour un total de 75 000 utilisateurs, le cluster B héberge 8500 utilisateurs par nœud pour un total de 51 000 utilisateurs. Ensemble, 126 000 utilisateurs sont affectés aux Service de calendrier.

L’Service de calendrier ajoute les utilisateurs au cluster A tout d’abord jusqu’à ce que le cluster atteigne la capacité de 75 000 utilisateurs, puis attribue les utilisateurs restants au cluster B. Les utilisateurs sont aléatoirement et également répartis sur tous les nodes du cluster. Cet exemple montre une distribution égale des hôtes du connecteur de calendrier (dans chacun des deux clusters) entre les centres de données RTP &PDX. Chaque nœud utilise le même modèle OVA et suit les instructions de haute Expressway haute disponibilité. Le Connecteur de calendrier utilise la logique Expressway de mise en cluster dans un modèle de redondance 5+1 pour permettre des scénarios de haute disponibilité.

Avec tous les utilisateurs affectés à un connecteur de calendrier, examinons maintenant ce qui se passe en cas de panne dans un cluster. La figure suivante montre une panne d’un seul nœud. Les utilisateurs qui ont été affectés au nœud qui a échoué, 5A dans le cluster A, ont maintenant échoué sur les nœuds restants dans ce cluster. La capacité d’un seul nœud permet d’accueillir jusqu’à 15 000 utilisateurs et chaque nœud restant dans le cluster A ajoute 2500 utilisateurs qui étaient initialement affectés sur le nœud 5A. Il n’y a aucun changement ou impact sur le cluster B ou les utilisateurs affectés sur le cluster B.

Figure 2. Un nœud dans le cluster A devient indisponible

Le cluster A est toujours à sa capacité maximale et chacun des nœuds opérationnels du cluster est maintenant à sa capacité maximale, 15 000 utilisateurs/nœud. Donc, si un autre nœud du cluster A devient indisponible, tel que le nœud 4A dans la figure suivante, le cluster B sera désormais responsable du chargement de l’utilisateur supplémentaire. Les 15 000 utilisateurs du nœud 4A sont maintenant réasignés au cluster B et répartis de manière égale sur tous les nœuds du cluster B.

Figure 3. Deux nodes dans le cluster A deviennent indisponibles

Lorsque les nodes 4A et 5A sont récupérés, les utilisateurs du cluster A sont redistribués entre les nodes du cluster. Les utilisateurs qui sont restés sur le cluster B restent sur le cluster B au cours de cette phase de récupération pour éviter les attributions inutiles des utilisateurs entre les clusters, comme le montre la figure suivante.

Figure 4. Récupération et redistribution des utilisateurs entre les nodes actifs

Un élément clé à savoir lors de la planification d’un déploiement de l’Service de calendrier hybride à grande échelle consiste à comprendre l’impact d’une panne si elle se produit dans le déploiement. Si nous utilisons le même déploiement de 126 000 utilisateurs mais que nous perdons l’intégralité d’un centre de données, il existe un potentiel pour les utilisateurs qui ne sont pas affectés à un nœud de connecteur de calendrier. Pour éviter une panne du service dans ce type de scénario, le client aura besoin d’un troisième cluster pour redistribuer et gérer les utilisateurs impactés.

Figure 5. Impact de la perte du centre de données

La capacité d’un cluster Expressway pour servir les utilisateurs du service de message hybride dépend de la taille des Expressway constituants, du nombre de nodes dans le cluster et de la stratégie de continuité du service.

Le tableau suivant montre le nombre maximum d’utilisateurs sur une seule Expressway qui est utilisé pour le service de message hybride.

Tableau 6. Capacité d’utilisation du service de message hybride sur un seul Expressway

Petit Expressway

Expressway moyen

Grand Expressway

5 000 utilisateurs

6 500 utilisateurs

15 000 utilisateurs

Figure 6. Échelle d’utilisation du service de messages hybrides sur les clusters dédiés de l’hôte du connecteur. Ce diagramme montre les niveaux maximum de l’échelle utilisateur lorsque vous augmentez le nombre de nodes sur un cluster dédié pour le service de message hybride

Les numéros d’utilisateur sont les mêmes pour un cluster d’un nœud et pour un cluster de deux nœuds. C’est parce que le service de message utilise leover (de panne) pour améliorer la continuité du service. Les utilisateurs sont distribués de manière égale sur les plusieurs nodes du cluster : Si un nœud tombe en panne, les utilisateurs de ce nœud sont affectés aux autres nœuds.

Figure 7. Exemple de coresidence : Le service de message hybride et Service de calendrier à l’échelle de l’utilisateur par type de cluster. Ce diagramme montre le maximum d’utilisateurs du service de message et Service de calendrier utilisateurs par cluster, pour différents types de clusters hébergeant à la fois les connecteurs de messages et de calendriers.

Ce sujet a pour objectif le partage d’un hôte de connecteur Expressway entre les connecteurs de plusieurs services hybrides, y compris Service de calendrier et le service de message. L’hôte du connecteur n’est pas partagé Expressway autres solutions basées sur l’Expressway telles que MRA et B2B.

La capacité du cluster hôte du connecteur dépend de la taille des hôtes Expressway constituants, du nombre de connecteurs, des connecteurs qui s’exécutent sur le cluster et de la stratégie de continuité du service. Reportez-vous à la section Programmation de la capacité du cluster Expressway pour les utilisateurs des services hybrides pour obtenir une explication détaillée de ces facteurs.

Il existe également une calculatrice pour vous aider à modéliser différents clusters d’hôtes du connecteur et voir combien d’utilisateurs de chaque service votre cluster proposé peut prendre en charge.

En général, nous recommandons la coresidence uniquement pour les déploiements de plus petite taille de deux nodes. Si votre déploiement dépasse la capacité d’une paire de connecteurs, vous devez déplacer les connecteurs vers Expressway clusters qui sont dédiés à chaque service hybride spécifique.

Exemple : Hôte du connecteur à l’échelle avec trois connecteurs de coresident

Le tableau suivant montre un exemple d’échelle et de coresidence. Il donne le nombre maximum d’utilisateurs par cluster , pour chaque service, avec des spécifications différentes du cluster hôte du connecteur. Le cluster est partagé entre hybrid Service de calendrier (en utilisant votre Exchange sur site), le service d’appel hybride et le service de message hybride.

Tableau 7. Exemple : Hôte du connecteur à l’échelle avec deux connecteurs de coresident

Service

Deux petits nodes

Deux nodes moyens

Deux grands nodes

Service de calendrier utilisateurs

1,300

2,300

3,000

Utilisateurs du service de messages

1,300

2,300

3,000

Introduction

Ce sujet a pour objectif le partage d’un hôte de connecteur Expressway d’autres solutions Expressway base de données. Lorsque vous choisissez d’héberger des connecteurs sur un Expressway que vous utilisez pour d’autres fins, les avertissements importants suivants s’appliquent :

  • Nous ne pouvons pas prendre en charge le modèle d’évolutivité qui s’applique à un hôte de connecteur dédié Expressway. Les numéros d’utilisateurs que vous découlez de la lecture des autres sujets de cet article, ou de l’utilisation de la calculatrice, ne s’appliquent pas lorsque l’hôte du connecteur est partagé avec d’autres services Expressway.

  • Les combinaisons de services basés sur Expressway et connecteurs de services hybrides décrits dans cet article, et les nombres d’utilisateurs associés, sont les seuls scénarios pris en charge. Nous n’avons pas testé d’autres scénarios et vous ne pouvez pas vous attendre à ce qu’ils fonctionnent dans votre environnement.

Expressway basé sur Service de calendrier avec connecteur d’appel et traversée de service d’appel

Dans ce cas, un nœud deux nœuds se Expressway cluster connecteurs Service de calendrier hybrides. Le cluster fait également la traversée d’appel pour d’autres solutions d’appel Cisco (Signalisation SIP et média).

Le tableau montre les différents environnements de calendrier que vous pouvez utiliser avec Expressway connecteur basé sur le réseau. Le Expressway basé sur le réseau n’est pas pris en charge sur les clusters ayant plus de deux nodes. Utilisez le connecteur basé sur le Cloud pour une plus grande échelle avec Office 365 (voir Service de calendrier Scale).

Tableau 8. Échelle utilisateur pour les Service de calendrier avec traversée d’appel

Service

Deux petits clusters de nœuds

Deux clusters de nœuds moyens

Deux grands clusters de nœuds

Service de calendrier

Exchange sur site

500 Utilisateurs

1 000 utilisateurs

1 000 utilisateurs

Office 365

500 Utilisateurs

1 000 utilisateurs

1 000 utilisateurs

Exchange et Office 365 sur site (Déploiements hybrides Exchange)

Maximum 500 utilisateurs pour les deux

Maximum 1 000 utilisateurs pour les deux

Maximum 1 000 utilisateurs pour les deux

Traversée d'appel

200 sessions audio

100 sessions vidéo

200 sessions audio

100 sessions vidéo

1 000 sessions audio

500 sessions vidéo

† pour éviter cette limite à l’échelle, nous vous recommandons d’utiliser l’Service de calendrier basée sur le Cloud au lieu du connecteur sur site. Pour l’Service de calendrier hybride basé sur Expressway , la limite de la capacité d’utilisation d’Office 365 à 1 000 utilisateurs par cluster est indépendante de la taille ou du nombre de nœuds du cluster ; cette limite découle de l’interaction avec le service Microsoft sur le Cloud et non de l’échelle du déploiement Expressway sur site.

Calendrier avec Mobile et Remote Access

Dans ce scénario, un cluster MRA d’une ou deux petites MV Expressway la MV héberge le connecteur de calendrier. Ce scénario suppose que le cluster est utilisé uniquement pour MRA et les deux connecteurs. Le cluster est limité à un ou deux petits nodes.

Tableau 9. Calendar Connector Scale sur le petit MRA Expressway-C

Expressway d’équipe

Cluster d’un petit Expressway-C

Cluster de deux petits Expressway-Cs

Service de calendrier utilisateurs (connecteur sur site pour Exchange)

500 Utilisateurs

500 Utilisateurs

Utilisateurs de téléphones Remote Access mobile

100

100