La capacité d'un cluster Expressway pour servir les utilisateurs du service de calendrier hybride dépend de la taille des nœuds Expressway-C constituants, du nombre de nœuds dans le cluster Expressway et de la stratégie de continuité du service.

Le tableau suivant indique le nombre maximum d’utilisateurs sur un seul Expressway dédié aux différents environnements de calendrier hybride.

_{* Pour éviter cette limite d’échelle, nous vous recommandons d’utiliser le Service de calendrier basé sur le Cloud au lieu du connecteur sur site. Pour le calendrier hybride basé sur Expressway, la limite de la capacité des utilisateurs d'Office 365 à 1 000 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 sur site d'Expressway.}

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. C’est parce que le service de calendrier utilise le basculement 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.

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é.

_{* 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 Programmer 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, U_calN= (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 :

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.

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.

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.

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.

La capacité d'un cluster Expressway à servir les utilisateurs de messages hybrides dépend de la taille des nœuds Expressway constituants, du nombre de nœuds dans le cluster et de la stratégie de continuité du service.

Le tableau suivant indique le nombre maximum d’utilisateurs sur un seul Expressway qui est utilisé pour le message hybride.

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 le calendrier hybride (en utilisant votre système Exchange sur site), l'appel hybride et le service de messagerie hybride.

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 scénario, un connecteur de calendrier hybride de cluster Expressway à deux nœuds. 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).

_{† 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 le calendrier hybride basé sur Expressway, la limite de la capacité des utilisateurs d'Office 365 à 1 000 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 sur site d'Expressway.}

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.