Valider son infrastructure (fin)

de migration d’infrastructure.

A coté, la migration des boites aux lettres entre deux infrastructures est une plaisanterie. Dans le cas d’une migration portant sur une montée de version d’Exchange (Ex : 2000 vers 2007), il sera nécessaire de conserver les habitudes clients.

La migration des serveurs d’accès clients est dans la majorité des cas, la première opération que vous aurez à entreprendre. Elle comprend principalement la substitution des accès Outlook Web Access (OWA),Outlook Any where (RpcOver Http), Windows Mobile (ActiveSync), Pop, Imap, qui devront continuer de « servir » les boites aux lettres sur l’ancienne plateforme Exchange.

L’adjonction des webservices dans l’environnement est impactant dans votre système d’information et devra être anticipé et mesuré. Vous devrez tester, la aussi de façon unitaire l’ensemble des services associés aux technologies concernées. L’accès via OWA Ou RpcOverHttp 2007 à une boite aux lettres Exchange 2000, le fonctionnement des services Web de vos clients Outlook 2007 qui ne manqueront pas de les utiliser dès que les boîtes aux lettres seront déplacées sur l’infrastructure 2007.

Les tests de charges quant à eux, sont difficiles à réaliser dans l’environnement des serveurs d’accès clients. Aussi vous devrez mettre en place avant migration des compteurs de charge associé à l’utilisation des CPU, des latences RPCoverHtpp etc. qui vous permettront d’afficher des indices de performances et d’ajuster éventuellement les configurations pour assurer un meilleur niveau de service. Voir Figure 2.

Afin de faciliter le repérage des serveurs Outlook Web Access, nous préconisons une personnalisation discrète des interfaces permettant d’identifier en cas d’opération de dépannage sur quel serveur votre système de répartition de charge vous à positionné. Gardez à l’esprit que si vous modifiez éventuellement une image de type logo OWA celle-ci a de très fortes chances d’être écrasée lors de l’application d’un service pack.

Vérification des serveurs de boîtes aux lettres La recette des serveurs de boîtes aux lettres est encore une histoire différente. La tendance est définitivement à la mise en place d’infrastructures présentant des options de tolérance de panne (Cluster, Serveur de secours, réplication de données etc.).

Naturellement, vous devrez tester à blanc et en situation réelle ces différents dispositifs pour vous assu- rer que le niveau de service et les fonctionnalités de secours sont d’une part présentes et d’autre part parfaitement maitrisées par les équipes internes. Concernant les clusters SCC et CCR nous vous conseillons de procéder régulièrement aux basculements des services et de faire fonctionner les services Exchange alternativement sur les différents noeuds. Vérification des entrées sorties.

La vérification des I/O disques de votre infrastructure est une validation impérative qui doit être réalisée avec succès (Pass). L’outil Jetstress dont la figure ci-dessous illustre un résultat de test, vous permettra de simuler la charge Utilisateur. Les tests de charge une fois l’infrastructure préparée durent à minima deux heures. Comptez environ 4 à 5 heures pour mener à bien un test Jetstress. Voir Figure 3.

Concernant la préparation des tests de charges nous vous invitons à placer la barre un peu plus haute que prévu notamment en nombre d’utilisateurs afin de vous assurer que vous disposerez d’une relative marge de manoeu – vre. Si vous disposez de plusieurs serveurs de boites aux lettres reposant sur la même infrastructure disque, vous devriez exécuter simultanément ces tests de charges afin de vérifier l’incidence cumulative.

D’une façon générale et si vous avez correctement planifié vos infrastructures, vous ne devriez pas rencontrer de problèmes particuliers. Si dans la version 2003 les Entrées/ Sorties constituaient un point névralgique, l’avènement des systèmes 64 Bits 2007, l’usage de plus en plus répandu du mode cache Outlook 2007 mais également la performance des matériels réduit petit à petit cette problématique.

La version 2010 devrait apporter sur ce point une réduction significative des I/O. Vérification des opérations de sauvegarde et restauration. La mise en place de serveurs de secours associés à des dispositifs de réplication (Microsoft ou autre) ne fait pas tout. Avant la mise en production les opérations de sauvegarde et de restauration des données et des systèmes doivent être également validées.

Les scénarios de perte d’un noeud de cluster, de rétablissement de ce dernier, doivent là aussi, concourir à obtenir une maturité technique des équipes internes. La figure 4 résume la liste des opérations de contrôles nécessaires avant toute mise en production.