Merci pour votre commentaire.
Limites de capacité utilisateur pour les services hybrides basés sur les autoroutes
Un commentaire ?Le service d' appel hybride sur l'architecture Call Connector est en fin de vie , il n'est donc plus officiellement pris en charge. Call Connector ne devrait pas être pris en compte lors de la planification future de la capacité des autoroutes pour les services hybrides.
Cet article ne traite pas de la planification des capacités pour l'intégration du service de calendrier hybride Cisco TMS à Office 365 ou de l'intégration de Cisco TMS à Google Calendar. Pour plus d'informations sur les capacités, consultez le guide de déploiement du service de calendrier Cisco Webex hybride.
Nous proposons cet article pour répondre à vos questions sur la planification des capacités et pour expliquer comment nous calculons l'échelle utilisateur. Pour modéliser votre scénario, essayez le calculateur de capacité des services hybrides.
Considérations relatives à la planification
Lorsque vous planifiez la capacité des autoroutes pour les utilisateurs de vos services hybrides, posez-vous les questions suivantes :
-
De quels services hybrides avez-vous besoin ?
L'Expressway peut héberger des connecteurs pour le service d'appels hybride, le service de calendrier hybride et le service de messagerie hybride.
-
Combien d'utilisateurs avez-vous pour chaque service ?
Plus vous avez d'utilisateurs pour chaque service, plus il est probable que vous souhaitiez dédier des clusters Expressway aux services. Pour les petites populations, gérer plusieurs connecteurs sur un cluster partagé (co-résidence) est un choix judicieux.
-
Vos besoins vont-ils changer ?
Vous devriez peut-être commencer modestement, avec un cluster Expressway fournissant des services à un groupe de premiers utilisateurs de votre organisation, et planifier la croissance pour un futur déploiement. Vous pouvez passer d'un modèle partagé à un modèle dédié, ou adapter votre cluster existant à l'évolution de vos besoins.
Facteurs contributifs
Nous définissons la capacité d'un cluster en fonction des variables suivantes :
-
Taille des nœuds : chaque machine virtuelle Expressway possède une « taille de machine virtuelle » qui est déterminée au moment de l'installation en fonction des ressources attribuées à la machine virtuelle. Les guides d'installation de l'autoroute décrivent ces exigences. Si vous possédez déjà un Expressway, vous pouvez consulter la taille de la machine virtuelle sur la page de l'interface Expressway.
-
Nombre de nœuds : un cluster Expressway peut comporter entre un et six nœuds. Ils doivent avoir la même taille de nœud et exécuter la même version du logiciel.
-
Stratégie de continuité des services — Les services utilisent des stratégies pour garantir un service continu aux utilisateurs. Le service de calendrier et le service de messagerie utilisent une stratégie de basculement.
Les stratégies sont détaillées dans le tableau Stratégies de continuité de service et échelle des clusters dédiés.
-
Corésidence — Lorsque les connecteurs partagent un cluster Expressway, les ressources disponibles pour chaque service sont nettement inférieures à celles du cluster dédié.
Il existe peut-être également d'autres services basés sur Expressway sur votre connecteur hôte, comme les appels interentreprises (B2B) ou les services mobiles et Remote Access (MRA). Dans les scénarios limités où ce type de co-résidence est pris en charge, les chiffres d'échelle que nous documentons ici sont limités à ceux que nous avons testés. Au-delà de ce qui est décrit dans cet article, le cluster Expressway qui héberge le connecteur ne doit pas être partagé avec d'autres services ; cela n'est pas pris en charge.
-
Limitations spécifiques aux services : par exemple, le Calendar Connector est principalement destiné aux Microsoft Exchange utilisateurs et prend en charge un nombre limité d'utilisateurs d'Office 365.
Calculs pour les clusters d'autoroutes dédiés
Nous avons fixé une limite stricte au nombre d'utilisateurs des services qu'une seule autoroute dédiée peut gérer (un « cluster d'un »), sur la base des preuves que nous collectons lors de tests et d'essais.
| Taille du nœud de l'autoroute | Barème de service de calendrier hybride | Échelle de service de messagerie hybride |
|---|---|---|
| 1. Petit | 5000 | 5000 |
| 2. Moyenne | 10000 | 6500 |
| 3. Grand | 15000 | 15000 |
Nous utilisons les algorithmes de continuité de service pour extrapoler les numéros de nœuds uniques à plusieurs clusters de nœuds, comme expliqué dans le tableau suivant. Si vous voulez les résultats sans explication, voir :
|
Comparez |
Service de calendrier hybride |
Service de messagerie hybride |
|---|---|---|
|
1. Mannequin |
Modèle de basculement |
Modèle de basculement |
|
2. Description |
Nous affectons chaque utilisateur à un nœud du cluster. Cela permet de répartir les utilisateurs sur tous les nœuds. Si un nœud tombe en panne, nous recréons les attributions des utilisateurs depuis ce nœud sur les autres nœuds. Lorsque le nœud revient, nous rééquilibrons les attributions des utilisateurs sur tous les nœuds actifs. |
Nous affectons chaque utilisateur à un nœud du cluster. Cela permet de répartir les utilisateurs sur tous les nœuds. Si un nœud tombe en panne, nous recréons les attributions des utilisateurs depuis ce nœud sur les autres nœuds. Lorsque le nœud revient, nous rééquilibrons les attributions des utilisateurs sur tous les nœuds actifs. |
|
3. Formule |
U calN = (N-1) * U cal1 |
U msGn = (N-1) * U msg1 |
|
4. Définitions |
Où : U CalN est le cluster de capacité N pour les utilisateurs du service de calendrier N est le nombre de nœuds U cal1 est la capacité d'un seul nœud pour les utilisateurs du service de calendrier |
Où : U mSgn est le cluster de capacité N pour les utilisateurs du service de messagerie N est le nombre de nœuds U msg1 est la capacité d'un seul nœud pour les utilisateurs du service de messagerie |
|
5. Remarques |
Si N=1, il n'y a pas de basculement. Le basculement est automatique et obligatoire si N>1. Si N=2, la capacité est la même que si N=1, avec une meilleure continuité de service. L'échelle bénéficie de N>=3 ou de l'utilisation d'un nœud plus grand. |
Si N=1, il n'y a pas de basculement. Le basculement est automatique et obligatoire si N>1. Si N=2, la capacité est la même que si N=1, avec une meilleure continuité de service. L'échelle bénéficie de N>=3 ou de l'utilisation d'un nœud plus grand. |
Calculs pour les clusters d'autoroutes partagés
Notre algorithme part du principe que les connecteurs co-résidents partagent proportionnellement les ressources d'un seul nœud. Cet algorithme fixe la limite de manière prudente pour chaque type d'utilisateur sur le nœud.
Par exemple, le tableau suivant indique le nombre maximum d'utilisateurs pour tous les dossiers dédiés et les cas de co-résidence sur une seule autoroute de taille moyenne.
| Objectif de l'autoroute | Utilisateurs du service de calendrier | Utilisateurs du service de messagerie |
|---|---|---|
|
| ||
| Dédié au service des calendriers |
10,000 |
— |
|
Dédié au service de messagerie |
— |
6,500 |
|
Partagé par Calendar Service et Message Service |
4,000 |
4,000 |
|
Partagé par les services de calendrier, d'appel et de messagerie |
2,300 |
2,300 |
Nous ne listons pas de manière exhaustive tous les États de corésidence, quelle que soit la taille des clusters. Vous pouvez plutôt surveiller la capacité de votre déploiement de services hybrides existant, ou utiliser le calculateur pour planifier un nouveau déploiement.
Le calculateur vous permet de choisir les connecteurs, la taille et le nombre de nœuds, afin de modéliser votre déploiement. Le reste de cette section explique comment le nombre d'utilisateurs est calculé à partir de votre modèle.
Comme nous l'avons fait pour l'Expressway dédiée, nous extrapolons l'algorithme des voies express partagées afin de déterminer le nombre d'utilisateurs de plusieurs nœuds. La différence par rapport aux cas dédiés, c'est que nous appliquons le calcul de continuité de service approprié pour obtenir l'échelle d'utilisateurs pour un service en particulier sur le cluster. Nous ne pouvons pas calculer l'échelle d'utilisateurs pour le cluster car celui-ci héberge des stratégies de continuité de service concurrentes, basées sur les utilisateurs.
|
Objectif du cluster |
Utilisateurs du service de messagerie hybride pour 1, 2 et 3 nœuds | ||
|---|---|---|---|
|
Dédié au service de messagerie |
6,500 |
6,500 |
13,000 |
Facteurs contributifs supplémentaires
Il se peut que les ressources du cluster soient sollicitées de manière concurrente, ce qui réduira la capacité des utilisateurs. Voici les exemples connus :
Service de calendrier : l'hôte du connecteur peut également proposer des services aux utilisateurs d'O365. Les chiffres et les calculs présentés ici supposent que seule votre infrastructure Exchange locale fournit le service de calendrier. Pour en savoir plus sur le service de calendrier « hybride », vous trouverez quelques chiffres et graphiques dans la section Service de calendrier de cet article.
Traitement des appels — L'hôte du connecteur peut également traiter la signalisation des appels et les médias. Il s'agit en fait d'une intégration « interentreprises » entre votre organisation et le cloud Webex. Cela réduit la capacité, comme décrit dans Coresidency with Other Expressway Solutions.
Vous pouvez utiliser Control Hub pour consulter le pourcentage de la capacité utilisateur actuelle de chacune de vos ressources Hybrid Services Expressway. Une barre de couleur indique si la capacité se situe dans les limites acceptables. Cette vue vous permet d'évaluer l'état de vos déploiements de services hybrides et vous indique quand vous avez besoin de plus d'autoroutes.
-
Vert — Vos autoroutes se situent dans des limites de capacité acceptables. (1%–60%)
-
Amber — Vous avez suffisamment d'autoroutes mais vous êtes sur le point d'atteindre la limite de capacité. (61%–90%)
-
Rouge — Vous n'avez pas assez de voies rapides et vous devez en ajouter d'autres. (91 % et plus)
Si vos autoroutes font partie d'un groupe de ressources, l'indicateur de capacité apparaît dans une vue filtrée des clusters du groupe de ressources.
-
Pour les déploiements sans groupes de ressources (par défaut) :
-
Depuis la page client sur https://admin.webex.com, accédez à , puis accédez aux cartes de service hybrides pour voir le pourcentage de capacité utilisée sur les ressources de l'autoroute pour chaque service.
-
-
Pour les déploiements avec des groupes de ressources :
-
Si la valeur de capacité est N/A, choisissez un groupe de ressources dans Filter pour passer en revue les groupes de ressources et leur capacité.
La valeur est mise à jour pour indiquer le pourcentage de capacité utilisé pour les clusters de ce groupe de ressources et un code couleur indique leur état de santé.
-
Points à garder à l'esprit
-
La capacité du cluster varie en fonction de la taille des nœuds, du nombre de nœuds du cluster Expressway, du nombre de services exécutés sur le cluster et de la stratégie de haute disponibilité ou de basculement. Pour plus d'informations, consultez les sections individuelles du calendrier et de l'échelle des messages.
-
La corésidence réduit le nombre d'utilisateurs pour les services existants ; l'algorithme de capacité part du principe que chaque utilisateur utilise tous les services.
Nous vous recommandons la co-résidence 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 de gérer les différents services hybrides sur des clusters Expressway dédiés.
Que faire ensuite
Pour ajouter d'autres Expressways for Hybrid Services, suivez les étapes du guide de déploiement pour enregistrer des hôtes de connecteurs dans le cloud et les ajouter à des clusters existants :
La capacité d'un cluster Expressway à répondre aux besoins des utilisateurs du service de calendrier hybride dépend de la taille des nœuds Expressway-C constitutifs, du nombre de nœuds du cluster Expressway et de la stratégie de continuité du service.
Le tableau suivant indique le nombre maximum d'utilisateurs sur une seule autoroute dédiée aux différents environnements de calendrier hybride.
|
Environnement de calendrier |
Petite autoroute |
Autoroute de taille moyenne |
Grande autoroute |
|---|---|---|---|
|
Exchange sur site uniquement |
5 000 utilisateurs |
10 000 utilisateurs |
15 000 utilisateurs |
|
Office 365 seulement* |
1 000 utilisateurs |
1 000 utilisateurs |
1 000 utilisateurs |
|
Exchange et Office 365* sur site (déploiements d'Exchange hybrides) |
1 000 utilisateurs d'Office 365 au maximum sur un total de 5 000 utilisateurs |
Maximum de 1 000 utilisateurs d'Office 365 sur un total de 10 000 utilisateurs |
1 000 utilisateurs d'Office 365 au maximum sur un total de 15 000 utilisateurs |
* Pour éviter cette limite d'échelle, nous vous recommandons d'utiliser le service de calendrier basé sur le cloud au lieu du connecteur local. Pour le calendrier hybride basé sur Expressway, la limite de la capacité d'accueil d'Office 365 à 1 000 utilisateurs par cluster est indépendante de la taille ou du nombre de nœuds du cluster ; cette limitation provient de l'interaction avec le service cloud Microsoft et non de l'ampleur du déploiement d'Expressway sur site.
Notez que la capacité utilisateur est la même pour un cluster d'un nœud et pour un cluster de deux nœuds. Cela est dû au fait que Calendar Service utilise le basculement pour améliorer la continuité du service. Tous les utilisateurs sont affectés à un nœud lorsqu'il y en a deux dans le cluster ; l'autre nœud est un nœud de sauvegarde redondant. Voir Planning Expressway Cluster Capacity for Hybrid Services Users for Hybrid Services Users pour une explication détaillée.
La capacité d'un cluster Expressway pour les utilisateurs du service de calendrier hybride dépend principalement de la taille et du nombre de nœuds du cluster, ainsi que de la stratégie de continuité du service. Le tableau suivant indique la capacité utilisateur totale maximale que le cluster peut gérer à mesure que vous augmentez le nombre de nœuds (ou leur taille OVA) sur un seul cluster dédié.
Dans un environnement Exchange hybride avec des utilisateurs d'Office 365, il y a une limite de 1 000 utilisateurs 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 pour gérer les utilisateurs d'Office 365. Nous vous recommandons vivement de n'héberger que temporairement des utilisateurs d'Office 365 sur Expressway.
Cette limite est due à l'interaction avec le service cloud de Microsoft et non à l'ampleur du déploiement d'Expressway sur site. Par exemple, si vous possédez un seul petit nœud Expressway, votre capacité est limitée à 1 000 utilisateurs Office 365 et 4 000 Microsoft Exchange utilisateurs. Si vous possédez un cluster de 6 petits nœuds, votre capacité est limitée à 1 000 utilisateurs d'Office 365 plus 24 000 Microsoft Exchange utilisateurs.
|
Taille du nœud de l'autoroute |
1 ou 2 nœuds * |
3 nœuds |
4 nœuds |
5 nœuds |
6 nœuds |
|---|---|---|---|---|---|
|
1. Petit |
5K |
10K |
15K |
20K |
25K |
|
2. Moyenne |
10K |
20K |
30K |
40K |
50K |
|
3. Grand |
15K |
30K |
45K |
60K |
75K |
* Notez que la capacité utilisateur est la même pour un cluster d'un nœud et pour un cluster de deux nœuds. Cela est dû au fait que Calendar Service utilise le basculement pour améliorer la continuité du service. Tous les utilisateurs sont affectés à un nœud lorsqu'il y en a deux dans le cluster ; l'autre nœud est un nœud de sauvegarde redondant. Voir Planning Expressway Cluster Capacity for Hybrid Services Users for Hybrid Services Users pour une explication détaillée.
Affectation des utilisateurs sur les hôtes et les clusters
Par défaut, le service de calendrier hybride attribue et répartit automatiquement les utilisateurs de manière uniforme sur 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 auquel un utilisateur est affecté.
Dans les cas où une organisation possède plusieurs clusters, la répartition des utilisateurs est basée sur de multiples facteurs, notamment la disponibilité des clusters, leur attribution en cours (pour réduire les battements en cas de panne) et un ordre de tri basé sur la préférence de cluster la plus élevée. L'administrateur a également la possibilité d'affecter un utilisateur ou un groupe d'utilisateurs à un groupe de ressources. Les groupes de ressources sont spécifiques à un cluster, ils permettent donc aux administrateurs de limiter l'affectation de certains groupes d'utilisateurs à un cluster spécifique.
Grâce à cette compréhension de base de l'attribution des utilisateurs et en tenant compte des prérequis d'Expressway Calendar Connector, un administrateur peut déployer la capacité appropriée à grande échelle pour son organisation. Prenons l'exemple d'une organisation de 126 000 utilisateurs à activer pour le service de calendrier hybride, en fonction des paramètres suivants :
-
Clusters Expressway de 6 nœuds 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, U calN = (N-1) * U cal1 où N=6 et U cal1 =15 000 (en utilisant le grand modèle OVA), donne un maximum de 75 000 utilisateurs. Avec 126 000 utilisateurs au total participant au déploiement du service de calendrier, plusieurs clusters hôtes Calendar Connector sont nécessaires. Les utilisateurs seraient répartis de manière égale, comme le montre la figure suivante :
Le service de calendrier hybride ajoute d'abord des utilisateurs au cluster A jusqu'à ce que le cluster atteigne la capacité de 75 000 utilisateurs, puis affecte les utilisateurs restants au cluster B. Les utilisateurs sont répartis de manière aléatoire et égale sur tous les nœuds du cluster. Cet exemple montre une répartition égale des nœuds hôtes Calendar Connector (au sein de chacun des deux clusters) entre les centres de données RTP et PDX. Chaque nœud utilise le même modèle OVA et suit les directives de haute disponibilité d'Expressway. Le Calendar Connector utilise la logique de clustering Expressway dans un modèle de redondance 5+1 afin de permettre des scénarios de haute disponibilité.
Tous les utilisateurs étant affectés à un connecteur de calendrier, voyons maintenant ce qui se passe en cas de panne dans un cluster. La figure suivante montre une défaillance d'un seul nœud. Les utilisateurs qui étaient affectés au nœud défaillant, 5A dans le cluster A, sont maintenant passés aux autres nœuds de 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 2 500 utilisateurs qui étaient initialement affectés au nœud 5A. Il n'y a aucun changement ni aucun impact sur le groupe B ou sur les utilisateurs assignés au cluster B.
Le cluster A atteint toujours sa capacité maximale, et chacun des nœuds opérationnels du cluster atteint désormais sa capacité maximale, 15 000 utilisateurs/nœud. Par conséquent, si un autre nœud du cluster A devient indisponible, comme le nœud 4A dans la figure suivante, le cluster B sera désormais chargé de prendre en charge la charge utilisateur supplémentaire. Les 15 000 utilisateurs du nœud 4A sont désormais réaffectés au cluster B et répartis de manière égale sur tous les nœuds du cluster B.
Lorsque les nœuds 4A et 5A seront restaurés, les utilisateurs du cluster A seront redistribués sur les nœuds du cluster. Les utilisateurs qui ont basculé vers le cluster B restent sur le cluster B pendant cette phase de restauration afin d'éviter des assignations d'utilisateurs inutiles entre les clusters, comme le montre la figure suivante.
L'un des éléments clés à prendre en compte lors de la planification d'un déploiement à grande échelle d'un service de calendrier hybride est de comprendre l'impact d'un échec s'il devait survenir lors du déploiement. Si nous utilisons le même déploiement de 126 000 utilisateurs mais que nous perdons tout un centre de données, il est possible que les utilisateurs ne soient pas affectés à un nœud Calendar Connector. Pour éviter une panne de service dans ce type de scénario, le client aurait besoin d'un troisième cluster pour redistribuer et gérer les utilisateurs concernés.
La capacité d'un cluster Expressway à répondre aux besoins des utilisateurs d'Hybrid Message dépend de la taille des nœuds Expressway constitutifs, du nombre de nœuds du cluster et de la stratégie de continuité du service.
Le tableau suivant indique le nombre maximum d'utilisateurs sur une seule autoroute utilisée pour le message hybride.
|
Petite autoroute |
Autoroute de taille moyenne |
Grande autoroute |
|---|---|---|
|
5 000 utilisateurs |
6 500 utilisateurs |
15 000 utilisateurs |
Les numéros d'utilisateur sont les mêmes pour un cluster d'un nœud et pour un cluster de deux nœuds. Cela est dû au fait que Message Service utilise le basculement pour améliorer la continuité du service. Les utilisateurs sont répartis de manière égale sur les différents nœuds du cluster : si l'un des nœuds tombe en panne, les utilisateurs de ce nœud sont affectés aux autres nœuds.
Ce sujet concerne le partage d'un connecteur hôte Expressway entre les connecteurs de plusieurs services hybrides, y compris le service de calendrier et le service de messagerie. L'hôte du connecteur n'est pas partagé avec d'autres solutions basées sur Expressway, telles que MRA et B2B.
La capacité du cluster hôte de connecteurs dépend de la taille des nœuds Expressway constitutifs, du nombre de nœuds, des connecteurs qui fonctionnent sur le cluster et de la stratégie de continuité de service. Voir Planning Expressway Cluster Capacity for Hybrid Services Users for Hybrid Services Users pour une explication détaillée de ces facteurs.
Il existe également un calculateur qui vous permet de modéliser différents clusters d'hôtes de connecteurs et de voir combien d'utilisateurs de chaque service peut prendre en charge par le cluster que vous proposez.
En général, nous recommandons la co-résidence uniquement pour les déploiements de petite taille comportant jusqu'à deux nœuds. Si votre déploiement dépasse la capacité de deux nœuds, vous devez déplacer les connecteurs vers des clusters Expressway dédiés à chaque service hybride spécifique.
Exemple : Connector Host Scale avec trois connecteurs corésidents
Le tableau suivant montre un exemple d'échelle et de corésidence. Il indique le nombre maximum d'utilisateurs par cluster, pour chaque service, avec des spécifications différentes en ce qui concerne le cluster hôte du connecteur. Le cluster est partagé entre Hybrid Calendar (en utilisant votre Exchange local), Hybrid Call et Hybrid Message Service.
|
Service |
Deux petits nœuds |
Deux nœuds de taille moyenne |
Deux grands nœuds |
|---|---|---|---|
|
Utilisateurs du service de calendrier |
1,300 |
2,300 |
3,000 |
|
Utilisateurs du service de messagerie |
1,300 |
2,300 |
3,000 |
Présentation
Ce sujet concerne le partage d'un connecteur hôte Expressway avec d'autres solutions basées sur Expressway. Lorsque vous choisissez d'héberger des connecteurs sur une autoroute que vous utilisez à d'autres fins, les mises en garde importantes suivantes s'appliquent :
-
Nous ne pouvons pas accepter le modèle d'évolutivité qui s'applique à un connecteur dédié hôte Expressway. Les numéros d'utilisateur que vous obtenez en lisant les autres sujets de cet article ou en utilisant 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 de connecteurs de services hybrides décrites dans cet article, ainsi que les numéros d'utilisateur 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.
Service de calendrier basé sur Expressway avec connecteur d'appel et traversée du service d'appel
Dans ce scénario, un cluster Expressway à deux nœuds, des connecteurs de calendrier hybride. Le cluster gère également la transmission des appels pour d'autres solutions d'appel Cisco (signalisation SIP et médias).
Le tableau présente les différents environnements de calendrier que vous pouvez utiliser avec le connecteur basé sur Expressway. Le connecteur Calendar basé sur Expressway n'est pas pris en charge sur les clusters de plus de deux nœuds. Utilisez le connecteur basé sur le cloud pour accéder à Office 365 (voir Calendar Service Scale).
|
Service |
Cluster à deux petits nœuds |
Cluster à deux nœuds de taille moyenne |
Cluster à deux grands 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 d'Exchange) |
500 utilisateurs maximum pour les deux |
1 000 utilisateurs maximum pour les deux |
1 000 utilisateurs maximum pour les deux | |
|
Call Traversal |
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 d'échelle, nous vous recommandons d'utiliser le service de calendrier basé sur le cloud au lieu du connecteur local. Pour le calendrier hybride basé sur Expressway, la limite de la capacité d'accueil d'Office 365 à 1 000 utilisateurs par cluster est indépendante de la taille ou du nombre de nœuds du cluster ; cette limitation provient de l'interaction avec le service cloud Microsoft et non de l'ampleur du déploiement d'Expressway sur site.
Calendrier avec téléphone portable et Remote Access
Dans ce scénario, un cluster MRA composé d'une ou deux petites machines virtuelles Expressway héberge le Calendar Connector. Ce scénario part du principe que le cluster est uniquement utilisé pour le MRA et les deux connecteurs. Le cluster est limité à un ou deux petits nœuds.
|
Objectif de l'autoroute |
Groupe d'une petite autoroute C |
Ensemble de deux petites autoroutes C |
|---|---|---|
|
Utilisateurs du service de calendrier (connecteur local vers Exchange) |
500 utilisateurs |
500 utilisateurs |
|
Mobile et Remote Access utilisateurs |
100 |
100 |
