> Mobilité > Dossier Exchange Server : Introduction à  Microsoft Exchange 2010 Server (3/4)

Dossier Exchange Server : Introduction à  Microsoft Exchange 2010 Server (3/4)

Mobilité - Par Christophe Leroux - Publié le 02 novembre 2010
email

Avant ces vacances d’été bien méritées, je vous avais présenté les premiers changements qui vont apparaître dans Exchange 2010 : restructuration de la base de données afin d’utiliser des disques SATA (réduction des coûts) et remplacement de l’ensemble des dispositifs de haute disponibilité existants (SCC, CCR, SCR, LCR) par le DAG (Database Availibility Group).

Rien qu’avec l’annonce de ces deux nouveautés, nous constatons déjà un engouement important de la part des entreprises pour Exchange 2010 alors que le produit n’est pas encore disponible. Mais Exchange 2010 ne s’arrête pas là et nous allons donc continuer, au cours de cette seconde partie, à nous plonger dans cette version majeure du produit.

Dossier Exchange Server : Introduction à  Microsoft Exchange 2010 Server (3/4)


Redondance des messages sur le HUB

Avec les versions actuelles, quand un message est envoyé par un serveur HUB vers un autre HUB ou un serveur SMTP externe, le serveur émetteur ne se préoccupe pas de savoir ce que devient le message qu’il vient d’expédier. Si le message reste bloqué sur le serveur de routage destinataire, le message ne sera jamais remis à l’utilisateur tant que ce serveur de routage n’aura pas trouvé un moyen d’envoyer le message.

Exchange 2010 introduit une notion de cache et de redondance sur le routage des messages.

Voici le principe de fonctionnement :

1) Lorsqu’un serveur HUB que l’on appellera HUB1, envoie un message à un serveur distant appelé HUB2 (un autre HUB, EDGE ou autre serveur SMTP), il commence par vérifier que ce serveur distant connaît le verbe d’extension SMTP : XSHADOW. Si le serveur HUB2 connaît ce verbe SMTP, le serveur HUB1 garde une copie du message qu’il envoie en marquant qu’il a envoyé le message au serveur HUB2.

2) Le serveur HUB2 fait de même avec le serveur suivant. Si l’envoi s’est effectué correctement, le serveur HUB2 marque le message comme envoyé.

3) Après 300 secondes par défaut (configurable), le serveur HUB1 établit une communication avec le serveur HUB2 en lui envoyant un verbe SMTP : XQDISCARD. Ce verbe a pour but de demander au HUB2, la liste des mes- sages qui ont été transmis au serveur suivant. Le HUB1 reçoit alors cette liste de messages et les supprime de son cache.

4) Si le serveur HUB1 n’arrive pas à contacter le HUB2 pour obtenir la liste des messages envoyés, il va réessayer 3 fois (15 minutes au total). Ce nombre d’essais est également configurable. Après ces trois tentatives, si le contact est toujours infructueux, le serveur HUB1 va considérer que les messages qu’il avait envoyés au serveur HUB2 n’ont pas été délivrés correctement. Il va donc les extraire de son cache pour les délivrer à un autre serveur SMTP.

5) Si jamais le serveur HUB2 avait finalement réussi à envoyer les messages sans le signaler au serveur HUB1 et que donc, le serveur HUB1 a décidé de les renvoyer à un autre serveur, le serveur destinataire final va les recevoir en double. Ceci ne posera pas de problème dans la majorité des cas. En effet, les messageries majeures du marché savent gérer les doublons de messages afin de n’en délivrer qu’une seule copie aux utilisateurs si le message est reçu en plusieurs exemplaires. Le serveur délivre le premier message à l’utilisateur et s’il le reçoit à nouveau, le supprime. Si jamais la messagerie destinataire ne sait pas gérer les doublons, l’utilisateur recevra deux fois le message. C’est un moindre mal. En effet, le but de cette nouvelle fonctionnalité de cache des messages d’Exchange 2010 est d’assurer une remise des messages. Il est donc préférable de recevoir un message en double dans le pire des cas plutôt que de ne pas le recevoir du tout.

En plus d’assurer une redondance de routage des messages, cette nouvelle fonction d’Exchange 2010 a d’autres conséquences qui permettent de diminuer le coût de l’infrastructure Exchange 2010 :

  • Il n’y a plus besoin de mettre les files d’attente sur des disques configurés en RAID car même si les files d’attente sont perdues, il existe une copie des messages sur un autre serveur. Exchange 2010 nécessite donc deux fois moins de disques sur les serveurs HUB en comparaison des versions précédentes.
  • L’impact sur les disques est moins important car les HUB d’Exchange 2010 consomme 50 % d’entrées/ sorties en moins sur les disques des files d’attente.


Mesure du temps de remise des messages

Quand un message passe par un serveur HUB Exchange 2010, le serveur place des indications de temps dans l’entête du message. Ceci permet de mesurer le temps de remise entre chaque passage sur les serveurs Exchange 2010. Ainsi, à l’aide de compteurs de performances Windows installés par Exchange 2010, il est possible de mesurer le temps mo – yen de remise des messages. Il est par exemple, possible de demander à connaître le temps moyen de remise de 90% des messages de la journée, ce qui jusqu’à maintenant était impossible à réaliser.
 

Téléchargez gratuitement cette ressource

Le XDR au service de la Sécurité IT

Le XDR au service de la Sécurité IT

Découvrez comment mettre à profit le Machine Learning et un traitement analytique orienté sécurité pour corréler les événements, tout en automatisant et en accélérant les processus de détection et de réponse.

Mobilité - Par Christophe Leroux - Publié le 02 novembre 2010