Prévision de la bande passante pour client Exchange – le problème de fuseau horaire…

Article d’origine publié le mercredi 20 juin 2012

Mise à jour le 22/06/12 - Cet article et le téléchargement associé ont été mis à jour.

La dernière version du calculateur de bande passante réseau pour client Exchange comprend plusieurs mises à jour, la principale étant sans aucun doute la prise en charge des fuseaux horaires. Cela fait maintenant 12 mois que je me penche sur le problème lié au fuseau horaire et il m’aura fallu un bon moment pour parvenir à une solution pratique. Tout d’abord, voyons un peu de quel problème il s’agit.

Qu’est-ce que ce problème de fuseau horaire ?

Je vais supposer que tout le monde sait ce que sont les fuseaux horaires et pourquoi ils existent, mais pour ceux qui souhaitent en savoir plus, je recommande la lecture de l’article Wikipedia suivant.

https://en.wikipedia.org/wiki/Time_zone

D’un point de vue de la prévision de la bande passante réseau, le problème avec les fuseaux horaires est que nous essayons de modéliser des charges de travail d’utilisateurs qui se trouvent dans différentes parties du monde et qui partagent la même connexion réseau ou le même service de terminaison. Cela pose un problème car les horaires d’utilisation de pointe pour la plupart des utilisateurs sont relatifs à leur fuseau horaire.

Par exemple, si l’on examine une journée de travail normale pour une organisation moyenne comptant 1000 utilisateurs, on observe généralement deux pointes, une dans la matinée aux environs de 10 heures, d’une durée de deux heures, et une autre dans l’après-midi aux environs de 14 heures, d’une durée de quatre heures. Cela nous donne le graphique suivant.

Imaginons maintenant que nous modélisons les exigences pour cinq emplacements différents, prenant chacun en charge 1000 utilisateurs qui accèdent à une ressource partagée située à New York. À ce stade, supposons que cette ressource partagée est un système d’équilibrage de la charge frontal pour Exchange 2010 local (pour une fois, je me suis dit qu’il valait mieux choisir un exemple local).

• Londres (GMT) = 1000 utilisateurs
• Varsovie (GMT+1) = 1000 utilisateurs
• Jakarta (GMT+7) = 1000 utilisateurs
• Redmond (GMT-8) = 1000 utilisateurs
• New York (GMT-5) = 1000 utilisateurs

Si l’on modélise cela à l’aide de notre technique héritée consistant à prévoir la pointe pour chaque ensemble d’utilisateurs et à additionner les pointes, on obtient le graphique suivant.

Ce graphique nous montre que chaque site de 1000 utilisateurs requiert une pointe d’environ 1,56 Mbits/sec de bande passante chaque jour. Si l’on additionne les pointes afin de prendre en compte tous les utilisateurs qui partagent le système d’équilibrage de la charge situé à New York, on obtient une exigence de pointe de 7,81 Mbits/sec. C’est comme cela que nous avons traditionnellement géré la planification de bande passante pour les utilisateurs distribués : prévision des exigences de pointe, insertion dans un tableau, puis addition des différentes valeurs.

Le problème, ici, c’est qu’au moment où les utilisateurs en Europe repartent chez eux, ceux de Redmond se lèvent et ceux de Jakarta sont bien au chaud dans leur lit !

Si l’on prend en compte le fuseau horaire de ces sites, le graphique prend une tout autre apparence.

Ce graphique montre que les charges de travail, une fois combinées, formeraient un profil d’utilisation très différent de celui que nous aurions traditionnellement prévu. Ce qui est très intéressant ici, c’est que notre charge de travail de pointe est maintenant beaucoup moins élevée, à seulement 3,78 Mbits/sec (notre prévision initiale était de 7,81 Mbits/sec). Le profil d’utilisation est également très différent de celui de notre prévision initiale.

Comment gérer ce problème ?

Comme vous l’aurez peut-être deviné en observant les graphiques ci-dessus, nous avons étendu le calculateur réseau afin de vous permettre d’inclure des détails sur les fuseaux horaires.

Nous avons pour cela abandonné l’idée de prévoir uniquement la charge de travail de pointe ; au lieu de cela, nous prévoyons désormais l’utilisation de la bande passante selon l’heure de la journée, en fonction des modèles d’utilisation fournis (horaires de pointe du matin et de l’après-midi, etc.). Cela permet au calculateur non seulement de savoir quand aura lieu votre utilisation de pointe, mais également quelle sera l’utilisation pendant le reste de la journée. Une fois que nous connaissons cette courbe, il est possible d’additionner les données en prenant en compte les fuseaux horaires.

Est-ce qu’il y a vraiment des utilisateurs qui effectuent cette consolidation ?

Eh bien oui ; de nombreuses organisations consolident le plus possible les charges de travail. Les équipes de conception doivent par conséquent planifier les charges de travail de service pour des utilisateurs répartis géographiquement, ayant souvent des profils différents et opérant dans différents fuseaux horaires. Ceci est particulièrement fréquent lorsque la charge de travail est déplacée vers le nuage, car Office 365 fournit uniquement des emplacements de clients régionaux ; une organisation internationale utilisant Office 365 devra donc planifier le fait qu’une grande partie de ses utilisateurs accèderont au service dans une région et un fuseau horaire totalement différents, bien souvent par le biais d’une infrastructure partagée.

De nombreux clients avec lesquels je travaille consolident également de petits centres de données en une quantité réduite de centres de données de taille plus importante. Ces sites consolidés doivent être capables de gérer la charge de travail des utilisateurs précédemment distribués. Comme il arrive souvent que ces utilisateurs opèrent dans différents fuseaux horaires, nous devons trouver un moyen de savoir comment leurs charges de travail se combineront à d’autres charges de travail distribuées.

Il est évident que si tous vos utilisateurs se trouvent dans le même fuseau horaire, tout ceci ne vous concerne pas ; il vous suffit d’utiliser le calculateur normalement.

Utilisation de la nouvelle fonctionnalité de fuseau horaire

Votre scénario nécessite la prise en charge des fuseaux horaires. Comment tirer parti de cette nouvelle fonctionnalité ?

Tout d’abord, nous devons configurer la table de configuration TimeZone sur la fiche de saisie. Les paramètres entrés ici contrôlent la forme de la courbe d’utilisation utilisée pour combiner les charges de travail. Les valeurs doivent refléter les modèles d’utilisation moyens au sein de votre organisation. Pour créer ces valeurs, j’observe généralement les données de performances lors de l’exécution des serveurs Exchange et je demande au client quels sont les schémas de travail de ses employés et quels sont selon lui les horaires de pointe.

Une fois la fiche de saisie remplie, nous passons à la fiche Client Mix, qui contient deux nouvelles zones pour configurer les données de fuseaux horaires.

Tout d’abord nous avons le fuseau horaire modèle (Model Timezone), qui représente le fuseau horaire de la ressource pour laquelle nous effectuons une planification (par exemple la liaison réseau ou le système d’équilibrage de la charge). Dans cet exemple, j’ai choisi le fuseau horaire modèle GMT-5 pour New York, qui correspond à l’emplacement de notre système d’équilibrage de la charge.

Ensuite, nous avons une nouvelle colonne intitulée TimeZone. Elle représente le fuseau horaire de chaque site par rapport à l’heure GMT.

La prévision obtenue est indiquée dans un graphique sous le tableau de combinaisons de clients, comme illustré plus haut. Les valeurs de ce tableau sont exprimées en Mbits/sec et représentent l’utilisation réseau prévue à chaque heure de la journée.

Un petit bonus

Le calculateur propose également un tableau qui peut être copié dans le Calculateur de rôle de boîte aux lettres pour faciliter la prévision de la réplication réseau DAG.

Si vous regardez à droite du graphique de prévision (feuille Client Mix) dans le Calculateur réseau, vous verrez un tableau qui indique le pourcentage de changement par heure de la journée… si vous copiez cela dans votre Presse-papiers…

Ensuite, naviguez jusqu’en bas de la fiche de saisie dans le Calculateur de rôle de serveur de boîte aux lettres, où vous trouverez un tableau pour la configuration de la réplication des journaux. Collez les chiffres du calculateur réseau dans ce tableau.

Et voilà ; le Calculateur de rôle de boîte aux lettres peut désormais prévoir les exigences de bande passante pour la réplication DAG, en prenant en compte à la fois les données de votre organisation et la configuration des fuseaux horaires.

Conclusion

J’espère que cette nouvelle fonctionnalité vous aidera à prévoir de manière plus précise vos exigences en matière de bande passante réseau. Elle n’est pas nécessaire pour tous les déploiements, mais les architectes de grande entreprise la trouveront sans doute d’une aide précieuse.

Continuez à nous faire part de vos commentaires, aussi bien positifs que négatifs, à l’adresse netcalc@microsoft.com. Nous adorons les lire !

Neil Johnson
Consultant senior, MCS R.-U.

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Exchange Client Bandwidth Prediction – the time zone problem…