Questions et réponses sur la file d'attente ExchangeÉquilibrage de la charge, transport Edge et bien plus encore

Henrik Walther

Q Plusieurs serveurs exécutant Microsoft® Office SharePoint® Server sont déployés dans notre environnement de production d'entreprise. Chacun de ces serveurs doit relayer des messages sortants via les serveurs de transport Hub (HT) dans notre infrastructure Exchange Server 2007 récemment déployée. Comme un serveur SharePoint nous permet uniquement de spécifier le nom de domaine pleinement qualifié (FQDN) d'un seul serveur SMTP (Exchange) à la page Administration Centrale | Opérations | Paramètres du courrier électronique sortant, comme illustré à la figure 1, je me demandais comment éliminer ce point de défaillance unique ?

fig01.gif

Figure 1 Paramètres du courrier électronique sortant à la page Administration centrale de SharePoint (cliquer sur l'image pour l'agrandir)

R C'est une très bonne question car de nombreuses organisations veulent une haute disponibilité et, en conséquence, n'acceptent aucun point de défaillance unique dans leurs environnements de production d'entreprise. C'est tout particulièrement vrai pour les services de messagerie et de collaboration.

Les serveurs Exchange 2007 HT sont résilients par défaut. Autrement dit, si plusieurs serveurs HT sont déployés dans un site d'Active Directory®, et qu'un serveur HT dans ce site d'Active Directory est indisponible, le serveur HT source essayant de livrer le message passe au serveur HT disponible suivant dans le site d'Active Directory. C'est exécuté grâce à des mécanismes DNS de tourniquet (si le premier serveur HT sur la liste ne répond pas, essayons le suivant).

Ainsi, pour l'ensemble des communications HT à HT et serveur de boîte aux lettres à HT (autrement dit, internes à l'organisation), il est inutile de se préoccuper d'une haute disponibilité (ou équilibrage de charge, du reste), puisqu'il s'agit d'une fonctionnalité native Exchange 2007. Toutefois, n'oubliez pas que si vous installez le rôle serveur HT sur un ordinateur sur lequel est également installé le rôle serveur de boîte aux lettres, le rôle serveur de boîte aux lettres préférera toujours le serveur HT local à tout autre serveur HT dans un site d'Active Directory (même lorsque le serveur HT local est indisponible) lorsque le service de dépôt du courrier de Microsoft Exchange soumet des messages.

La précédente information n'est pas vraiment utile en ce qui concerne les serveurs SharePoint, mais il est important de la connaître avant de poursuivre. Comme un serveur HT est résilient par défaut, l'équilibrage de charge de la communication interne à l'organisation entre les serveurs HT dans Exchange 2007 en utilisant des programmes d'équilibrage de la charge matérielle ou la fonctionnalité d’équilibrage de la charge réseau Windows® (WNLB) n'est pas pris en charge.

En fait, l'équilibrage de charge du trafic SMTP entrant vers les serveurs HT basé sur la version Exchange 2007 RTM n'était pas pris en charge. Mais Exchange 2007 SP1 change tout cela. Avec SP1, il est toujours impossible d'équilibrer en charge la communication interne à l'organisation en utilisant des programmes d'équilibrage de charge matérielle ou la fonctionnalité WNLB (et, de toutes façons, pourquoi le feriez-vous ?), mais vous pouvez équilibrer en charge le trafic SMTP entrant provenant de sources non-Exchange (telles que les serveurs SharePoint) et de clients Exchange comme les clients IMAP ou POP qui soumettent des messages sortants à l'organisation Exchange 2007 en utilisant le connecteur de réception client par défaut sur le serveur HT.

Ainsi, pour configurer un serveur SharePoint afin de relayer des messages via une organisation Exchange 2007 SP1, vous pouvez simplement créer un enregistrement DNS dans votre Active Directory DNS et l'indiquer à un programme d'équilibrage de la charge matérielle qui peut ensuite distribuer le trafic entre plusieurs serveurs HT ou utiliser la fonctionnalité WNLB à ces fins. Pour utiliser cette dernière méthode, configurez le cluster WNLB avec une adresse IP et un FQDN virtuels (comme mail.contoso.com) et ajoutez les ports 25 (trafic SMTP entrant depuis les serveurs non-Exchange) et 587 (SMTP entrant depuis les clients Exchange comme IMAP et POP) à l'onglet Règles de port. La figure 2 présente l'onglet Règles du port avec cette configuration. Vous devez également vous assurer que vous avez attribué l'adresse IP de cluster NLB virtuel spécifique aux deux règles au lieu de sélectionner toutes les adresses IP.

fig02.gif

Figure 2 Règles de port définies (Cliquer sur l'image pour l'agrandir)

Une fois le cluster NLB configuré, vous devez créer un nouveau connecteur de réception qui devrait être configuré pour écouter uniquement le port 25 et autoriser seulement les serveurs qui en ont besoin à relayer les messages en utilisant ce connecteur. De plus, assurez-vous que ce connecteur utilise l'adresse IP de cluster NLB virtuel précédemment créée.

Q Notre infrastructure de messagerie est basée sur Exchange Server 2007. Pour rendre nos serveurs de boîtes aux lettres Exchange 2007 redondants aux niveaux du matériel et du stockage, il s'agit de serveurs de boîtes aux lettres en clusters basés sur la technologie Réplication continue en cluster (CCR). Les nœuds actif et passif dans chaque cluster CCR sont situés dans le même centre de données physique. Maintenant que nos serveurs Exchange 2007 ont été mis à niveau à la version SP1, nous voulons optimiser la disponibilité du service et des données en copiant les bases de données de boîte aux lettres vers les serveurs de boîtes aux lettres dans un deuxième site en utilisant la nouvelle technologie Réplication continue de secours (SCR) incluse à Exchange 2007 SP1.

Nous savons que les sources SCR peuvent être les serveurs de boîtes aux lettres autonomes Exchange 2007 SP1 ou des serveurs de boîtes aux lettres en clusters (CMS) en fonction de la technologie CCR ou Cluster à copie unique (SCC). Mais qu'en est-il des serveurs cibles SCR ?

R Les serveurs cibles SCR (également appelés points de terminaison SCR) doivent être un serveur de boîtes aux lettres autonome sans la Réplication locale continue (LCR) activée pour des groupes de stockage ou un nœud passif dans un cluster de basculement Windows (autrefois appelé Microsoft Cluster Server) avec le rôle de serveur de boîtes aux lettres installé. Cela signifie que vous pouvez former votre cluster de basculement puis installer le rôle de serveur de boîtes aux lettres sur un nœud passif dans ce cluster de basculement, mais que vous ne pouvez pas utiliser un serveur de boîtes aux lettres en clusters comme cible SCR.

Q Notre organisation utilise Exchange 2007 comme plate-forme de messagerie. Nous avons même décidé de remplacer notre ancienne solution anti-spam/antivirus dans le réseau de périmètre par une solution basée sur les serveurs Exchange 2007 Edge Transport avec Forefront™ Security pour Exchange installé afin de pouvoir profiter de multiples couches de sécurité et de protection des messages. Nous prévoyons de déployer au moins deux autres serveurs de transport Edge dans un proche avenir.

D'où ma question. Comment ferons-nous pour équilibrer en charge les connexions SMTP entrantes vers notre solution de protection des messages basée sur Exchange 2007 - Edge Transport et ainsi distribuer la charge et la rendre entièrement redondante ?

R Si les serveurs de transport Edge dans votre réseau de périmètre sont les serveurs SMTP orientés Internet, vous pouvez utiliser une approche similaire à celle utilisée dans le groupe Microsoft Information Technology (Microsoft IT). Microsoft IT a déployé six serveurs de transport Edge (trois à Redmond et trois dans la Silicon Valley) qui gèrent plus de 16 millions de messages entrants par jour (et plus de 13 millions de messages sont filtrés comme des spams).

Microsoft IT compte au total trois enregistrements Mail Exchange (MX) pour le domaine Microsoft.com. Il s’agit de : maila.microsoft.com, mailb.microsoft.com et mailc.microsoft.com (voir la figure 3). Chaque enregistrement MX a été configuré avec une préférence de 10, de sorte qu'il sera prélevé au hasard en utilisant une technique de tourniquet DNS. De plus, deux adresses IP (hôtes de messagerie) sont associées à chaque enregistrement MX.

fig03.gif

Figure 3 Enregistrements MX et hôtes de messagerie Internet pour Microsoft.com (Cliquer sur l'image pour l'agrandir)

Pourquoi deux adresses IP par enregistrement MX ? Parce que certains agents de transfert de messages (MTA) prendraient toujours le même enregistrement MX, quel que soit le nombre d'enregistrements MX configurés pour un domaine. En ce qui concerne Exchange Server, ce n'est plus un problème depuis des années (depuis Exchange 2000), mais malheureusement il existe encore des MTA qui ont ce défaut de conception. Ainsi, quel que soit le MTA qui essaie de livrer un message à une adresse Microsoft.com, toutes les connexions SMTP sont distribuées en utilisant une combinaison de tourniquet DNS et d'équilibrage de charge.

Q Notre domaine Active Directory est basé sur les contrôleurs de domaine (DC) Windows Server® 2003. Nous sommes en train de planifier le passage de nos contrôleurs de domaine Windows Server 2003 à Windows Server 2008 et de notre environnement de messagerie Exchange 2003 à Exchange Server 2007. Pouvons-nous faire passer notre domaine Active Directory à Windows Server 2008 en mettant à niveau tous les serveurs exécutant Windows Server 2003 vers Windows Server 2008, avant de faire passer l'environnement de messagerie d'Exchange Server 2003 à Exchange 2007 ?

R Oui, Exchange Server 2003 SP2 est entièrement pris en charge dans un domaine Active Directory consistant intégralement en des DC Windows Server 2008. Vous pouvez poursuivre votre travail. N'oubliez pas que si vous voulez utiliser les contrôleurs de domaine en lecture seule (RODC) de Windows Server 2008, vous ne devriez pas configurer le Service de mise à jour des destinataires (RUS) d'Exchange pour utiliser un RODC.

Henrik Walther est un architecte certifié Microsoft : messagerie (apprenti) et MVP Exchange, avec plus de 14 ans d'expérience dans le domaine informatique. Il travaille comme architecte technologique pour Interprise Consulting et comme rédacteur technique pour Biblioso Corp.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.