La mise en production est une période charnière où la nouvelle infrastructure doit faire l’objet d’une attention toute particulière. Afin de limiter ce que l’on conviendra d’appeler les risques inhérents aux premiers décollages, certaines batteries de vérification doivent être entreprises.
La manipulation doit donc être transparente et ne souffrir d’aucun problème lié aux processus d’authentification.
. Le basculement des services de transport se fait généralement brutalement, soit un simple changement d’enregistrement MX soit par une simple redirection de routage sur les équipements amont de type Firewall, Routeur ou autre dispositif de protection (Ironport, Brightmail, IMSS Trend Micro etc..).
Là encore, vous devriez impérativement tester la capacité de votre serveur à supporter la charge et vérifier la correcte livraison des messages vers d’autres environnements concernés s’il y a lieu (Ancien système de messagerie, site distant etc..).
Pourquoi alors ne pas utiliser des outils de mailbombing capables d’envoyer en masse des messages de tailles parfois imposantes et y inclure des faux virus de type EIcar pour s’assurer de la correcte réactivité de vos dispositifs anti-viraux ? Ainsi vous pourrez vérifier la charge CPU induite et peut être, corriger la configuration de certains services, ou simplement rassurer votre comité de pilotage !
Cependant une disposition particulière peut complexifier les tests et notamment les environnements possédant plusieurs rôles identiques. Dans certains environnements, il n’est pas rare de trouver plusieurs serveurs de transport (Hub) ou périmétre (Edge) mutualisés par l’utilisation d’une adresse IP virtuelle gérée soit par le NLB Windows soit par un répartiteur de charge dédié.
Or, il n’est pas possible de cloner ces serveurs, il vous faudra donc vérifier et comparer pour chacun l’ensemble des paramètres retenus. Certes, powershell facilite cette comparaison mais selon le nombre de serveurs dont vous disposerez cette tâche peut s’avérer relativement longue et pour être franc.. quelque peu rébarbative.
Si votre environnement dispose de plusieurs serveurs de transport je vous engage à procéder à des tests unitaires en arrêtant les machines ainsi regroupées. De cette façon, vous serez en mesure de détecter des comportements différents selon les configurations et ainsi procéder à une harmonisation. Une fois passée en production et regroupée via une répartition de charge, l’identification d’un comportement spécifique d’un serveur s’avérera beaucoup plus complexe à identifier.
Le processus de recette doit par conséquent comporter des validations unitaires par configuration puis une validation de l’ensemble des services regroupés. La connaissance comportementale des dispositifs de répartition de charge concoure ainsi à l’acquisition de la maturité technique par les équipes d’exploitation qui en cas d’incident réduiront les temps d’indisponibilité par une meilleure connaissance de ces infrastructures.
Comment capitaliser sur son existant tout en bénéficiant, dès à présent, des promesses de flexibilité et de scalabilité du cloud ? Découvrez les bonnes pratiques pour répondre aux défis de simplification du Cloud dans ce nouveau TOP 5.
