Équilibrage de charge dans Exchange 2016

[Cette rubrique est une documentation préliminaire et peut être modifiée dans les versions ultérieures. Des rubriques vides sont incluses comme espaces réservés. N’hésitez pas à nous transmettre vos commentaires. Envoyez-nous un e-mail à l’adresse ExchangeHelpFeedback@microsoft.com.]  

Résumé : Découvrez comment l’équilibrage de charge dans Exchange 2016 gère les connexions à extension messagerie, améliorant ainsi la disponibilité et la résilience dans votre réseau d’entreprise Exchange.

L’équilibrage de charge dans Exchange 2016 repose sur la plateforme de résilience réseau et de haute disponibilité de Microsoft. En outre, Exchange 2016 propose des améliorations apportées à l’architecture Exchange. Lorsque cela est combiné avec la disponibilité des solutions d’équilibrage de charge tierces (matériel et logiciel), il existe plusieurs options d’implémentation de l’équilibrage de charge dans votre organisation Exchange.

Les modifications apportées à l’architecture Exchange introduites dans Exchange 2013 ont instauré les rôles serveur de boîtes aux lettres et serveur d’accès au client. Comparez ceci à Exchange 2010, où l’accès au client, la boîte aux lettres, le transport hub et les messages unifiés s’exécutaient sur des serveurs séparés.

Grâce aux rôles de serveur minimaux, Exchange 2016 offre les avantages suivants :

  • Déploiement simplifié avec le serveur de boîtes aux lettres exécutant les services d’accès au client et les rôles serveur de transport Edge.

  • Flux de messagerie géré dans le pipeline de transport, c’est-à-dire l’ensemble des services, connexions, files d’attente et composants qui acheminent les messages vers le catégoriseur du service de transport sur le serveur de boîtes aux lettres.

  • Haute disponibilité en déployant des équilibreurs de charge pour distribuer le trafic du client.

La norme du protocole HTTP introduite dans Exchange 2013 signifie que l’affinité de session n’est plus requise dans Exchange 2016. L’affinité de session permet une connexion permanente pour les services de messagerie afin que l’utilisateur n’ait pas à saisir de nouveau son nom d’utilisateur et son mot de passe à plusieurs reprises.

Auparavant, Exchange 2007 et Exchange 2010 prenaient en charge RPC sur HTTP pour Outlook Anywhere. Exchange 2013 a introduit MAPI sur HTTP, même s’il n’a pas été activé par défaut. Il est désormais activé par défaut dans Exchange 2016.

Avec le protocole HTTP, tous les clients natifs se connectent à l’aide d’HTTP et HTTPs dans Exchange 2016. Grâce à ce protocole standard, l’affinité n’est plus requise. Elle l’était précédemment pour éviter d’inviter l’utilisateur à saisir de nouveau ses informations d’identification utilisateur chaque fois que l’équilibrage de charge redirigeait la connexion vers un autre serveur.

Le nombre réduit des rôles serveur pour Exchange 2016 simplifie la configuration matérielle requise et l’implémentation d’Exchange. Le nombre de rôles serveur dans Exchange 2016 passe de sept à deux : le serveur de boîtes aux lettres et le serveur de transport Edge. Le rôle serveur de boîte aux lettres inclut les services d’accès au client, tandis que le serveur de transport Edge fournit un flux de messagerie sécurisé dans Exchange 2016, tout comme dans les versions antérieures d’Exchange.

Vue d’ensemble conceptuelle du processus d’équilibrage de charge Exchange

Dans Exchange 2013, le rôle serveur d’accès au client vérifiait que lorsqu’un utilisateur tentait d’accéder à sa boîte aux lettres, le serveur retransmettait par proxy la demande au serveur de boîtes aux lettres traitant activement la boîte aux lettres de l’utilisateur. Cela signifiait que les services tels que Outlook sur le web (précédemment appelés Outlook Web App) apparaissaient pour l’utilisateur sur la boîte aux lettres elle-même, supprimant tout besoin d’affinité.

La même fonctionnalité reste dans Exchange 2016. Si deux serveurs de messagerie hébergent des boîtes aux lettres différentes, ils peuvent se transmettre le trafic par proxy lorsque cela est nécessaire. Le serveur de boîtes aux lettres qui héberge la copie active de la boîte aux lettres aide l’utilisateur en y accédant, même si l’utilisateur se connecte à un autre serveur de boîtes aux lettres.

Pour plus d’informations sur les modifications de rôle serveur dans Exchange 2016, consultez la rubrique Architecture d’Exchange 2016.

 

Rôle de serveur

Services

Serveur de boîtes aux lettres

Utilise EdgeSync pour gérer la réplication unidirectionnelle des informations de configuration et de réception d’Active Directory à l’instance AD LDS sur le serveur de transport Edge.

Copie uniquement les informations nécessaires pour permettre au transport Edge de bloquer le courrier indésirable et d’activer le flux de messagerie de bout en bout.

Transport Edge

Gère tout le flux de messagerie Internet entrant et sortant à l’aide de :

  • relais de messagerie

  • hébergement actif

  • agents qui fournissent un service de blocage du courrier indésirable supplémentaire

  • agents qui appliquent le transport pour contrôler le flux de messagerie

Pas un membre de la forêt Active Directory

Même si cela n’est pas obligatoire, le serveur de transport Edge se trouve dans le réseau de périmètre, comme dans les versions d’Exchange précédentes, pour garantir un flux de messagerie entrant et sortant sécurisé pour votre organisation Exchange.

Pour plus d’informations sur le service de transport, consultez la rubrique Présentation du service de transport sur les serveurs de transport Edge.

À partir de Exchange 2016, tous les clients Exchange natifs utilisent le protocole HTTP pour se connecter à un service désigné, avec des cookies HTTP fournis à l’utilisateur lors de la connexion qui sont chiffrés à l’aide du certificat SSL des services d’accès au client. Un utilisateur connecté peut reprendre la session sur un autre serveur de boîtes aux lettres exécutant les services d’accès au clients sans s’authentifier à nouveau. Les serveurs qui utilisent le même certificat SSL peuvent déchiffrer le cookie d’authentification du client.

HTTP permet d’utiliser les contrôles d’intégrité du service ou de l’application dans votre réseau Exchange. Selon votre solution d’équilibrage de charge, vous pouvez implémenter des sondes d’intégrité sur différents composants de votre système.

L’accès à HTTP uniquement pour les clients résulte en un équilibrage de charge plus simple. Si vous le souhaitez, vous pouvez utiliser DNS pour effectuer un équilibrage de charge de votre trafic Exchange. Il vous suffit de fournir l’adresse IP de chaque serveur de boîtes aux lettres au client, et le client HTTP gère les tâches. Si un serveur Exchange échoue, le protocole tente de se connecter à un autre serveur. L’équilibrage de charge via DNS présente néanmoins des inconvénients, décrits dans la section suivante Options d’équilibrage de charge dans Exchange 2016.

Pour plus d’informations sur HTTP et Exchange 2016, consultez la rubrique MAPI sur HTTP dans Exchange 2016.

Dans l’exemple présenté ici, plusieurs serveurs configurés dans un groupe de disponibilité de base de données (DAG) hébergent les serveurs de messagerie qui exécutent les services d’accès au client. Cela offre une haute disponibilité avec une empreinte serveur Exchange minimale. Le client se connecte à l’équilibreur de charge plutôt que directement aux serveurs Exchange. Il n’existe aucune condition requise pour les paires d’équilibreurs de charge, mais nous vous recommandons de déployer dans des clusters pour améliorer la résilience du réseau.

Connexions client à des équilibreurs de charge qui distribuent des demandes au DAG

N’oubliez pas que les DAG utilisent les services de cluster Microsoft. Ces services ne peuvent pas être activés sur le même serveur que l’Équilibrage de la charge réseau (NLB) Windows. Ainsi, l’Équilibrage de la charge réseau (NLB) Windows n’est pas une option lorsque vous utilisez des DAG. Il existe des logiciels tiers et des solutions de dispositif virtuel dans ce cas.

L’utilisation du système DNS est l’option la plus simple pour l’équilibrage de charge de votre trafic Exchange. Avec l’équilibrage de charge DNS, il vous suffit de fournir l’adresse IP de chaque serveur de boîtes aux lettres à vos clients. Ensuite, le tourniquet DNS distribue ce trafic à vos serveurs de messagerie. Le client HTTP est suffisamment intelligent pour se connecter à un autre serveur en cas d’échec complet d’un serveur Exchange.

Cependant, la simplicité a un prix. Dans ce cas, le tourniquet DNS n’effectue pas réellement l’équilibrage de charge du trafic, car il n’existe pas de moyen, par programme, de vérifier que chaque serveur obtient une part équitable du trafic. En outre, il n’existe aucune surveillance du niveau de service pour que, lorsqu’un seul service échoue, les clients ne soient pas automatiquement redirigés vers un service disponible. Par exemple, si Outlook sur le web est en mode d’échec, une page d’erreur s’affiche pour les clients.

L’équilibrage de charge DNS requiert des adresses IP externes supplémentaires lorsque vous publiez en externe. Cela signifie que chaque serveur Exchange de votre organisation requiert une adresse IP externe.

Il existe des solutions plus élégantes pour effectuer l’équilibrage de charge de votre trafic, comme par exemple le matériel qui utilise la couche de transport de niveau 4 ou la couche d’application de niveau 7 pour distribuer le trafic client. Les équilibreurs de charge surveillent chaque service côté client Exchange et, en cas d’échec du service, peuvent diriger le trafic vers un autre serveur et déconnecter le serveur posant problème. En outre, un certain niveau de distribution de charge permet de garantir qu’aucun serveur de boîtes aux lettres ne transmet par proxy la majorité des accès au client.

Les services d’équilibrage de charge peuvent utiliser les couches de niveau 4 ou de niveau 7, ou une combinaison des deux, pour gérer le trafic. Chaque solution présente des avantages et des inconvénients.

  • Les équilibreurs de charge de couche de niveau 4 fonctionnent au niveau de la couche de transport afin de rediriger le trafic sans examiner le contenu.

    Étant donné qu’ils n’examinent pas le contenu du trafic, les équilibreurs de charge de couche de niveau 4 gagnent du temps en transit. Toutefois, ceci a un prix. Les équilibreurs de charge de couche de niveau 4 connaissent uniquement l’adresse IP, le protocole et le port TCP. Ne connaissant qu’une seule adresse IP, l’équilibreur de charge ne peut surveiller qu’un seul service.

    L’équilibrage de charge de couche de niveau 4 présente les avantages suivants :

    • Nécessite moins de ressources (aucun examen du contenu).

    • Distribue le trafic sur la couche de transport.

    Le risque avec une solution de couche de niveau 4 est que si un service échoue mais qu’un serveur est toujours disponible, les clients risquent de se connecter au service ayant échoué. Cela signifie qu’une implémentation de couche de niveau 4 résiliente requiert plusieurs adresses IP configurées avec des espaces de noms HTTP séparés par service (owa.contoso.com, eas.contoso.com, mapi.contoso.com, par exemple) pour permettre de surveiller le niveau de service.

  • Les équilibreurs de charge de couche de niveau 7 fonctionnent au niveau des applications et peuvent inspecter le contenu du trafic et le diriger en conséquence.

    Les équilibreurs de charge de couche de niveau 7 renoncent aux avantages de performances brutes de l’équilibrage de charge de couche de niveau 4 pour la simplicité d’un espace de noms (par exemple, mail.contoso.com) et la surveillance par service. Les équilibreurs de charge de couche de niveau 7 comprennent le chemin d’accès HTTP, tel que /owa or /Microsoft-Server-ActiveSync, or /mapi, et peuvent diriger le trafic vers des serveurs de travail sur la base des données de surveillance.

    L’équilibrage de charge de couche de niveau 7 présente les avantages suivants :

    • Nécessite une seule adresse IP.

    • Examine le contenu et peut diriger le trafic.

    • Fournit une notification d’échec de service pouvant être consultée hors connexion.

    • Gère l’arrêt de SSL de l’équilibreur de charge.

    • Distribue le trafic sur la couche des applications et comprend l’URL de destination.

SSL doit s’arrêter à l’équilibreur de charge car ceci offre un emplacement centralisé pour corriger les attaques SSL.

Les ports sur lesquels un équilibrage de charge doit être effectué comprennent ceux pour IMAP4 ou POP3, par exemple, qui ne sont peut-être pas utilisés dans votre organisation Exchange.

 

Port TCP Rôles Utilise

25

Boîte aux lettres

SMTP entrant

110

Boîte aux lettres

Clients POP3

143

Boîte aux lettres

Clients IMAP4

443

Boîte aux lettres

HTTPS (Outlook sur le web, découverte automatique, services web, ActiveSync, MAPI sur HTTP, RPC sur HTTP, OAB, CAE

993

Boîte aux lettres

Sécurisation de clients IMAP4

995

Boîte aux lettres

Sécurisation de clients POP3

Exchange 2016 introduit une grande flexibilité pour votre architecture d’équilibrage de charge et d’espace de noms. Avec de nombreuses options pour le déploiement de l’équilibrage de charge dans votre organisation Exchange, du DNS simple à des solutions tierces sophistiquées de couche 4 et de couche 7, nous vous recommandons de toutes les examiner en fonction des besoins de votre organisation.

Les scénarios suivants présentent des avantages et des limites et vous devez bien les comprendre pour implémenter la solution qui convient le mieux à votre organisation Exchange :

  • Scénario A Espace de noms unique, pas d’affinité de session : Couche de niveau 4 ou couche de niveau 7

  • Scénario B Espace de noms unique, pas d’affinité de session : Couche de niveau 7

  • Scénario C Espace de noms unique avec affinité de session, couche de niveau 7

  • Scénario D Plusieurs espaces de noms et pas d’affinité de session, couche de niveau 4

Scénario A Espace de noms unique, pas d’affinité de session : Couche de niveau 4 ou couche de niveau 7

Dans ce scénario de couche de niveau 4, un seul espace de noms, mail.contoso.com, est déployé pour les clients de protocole HTTP. L’équilibreur de charge ne conserve pas l’affinité de session. Comme il s’agit d’une solution de couche de niveau 4, l’équilibreur de charge est configuré pour vérifier l’intégrité d’un seul répertoire virtuel car il ne peut pas faire la distinction entre les demandes Outlook sur le web et les demandes RPC.

Du point de vue de l’équilibreur de charge dans cet exemple, l’intégrité est par serveur et non par protocole pour l’espace de noms désigné. Les administrateurs devront choisir quel répertoire ils souhaitent cibler pour la sonde d’intégrité ; nous vous conseillons de choisir un répertoire virtuel très utilisé. Par exemple, si la majorité de vos utilisateurs utilisent Outlook sur le web, choisissez le répertoire virtuel Outlook sur le web dans la sonde d’intégrité.

Dans la mesure où la sonde d’intégrité indique qu’Outlook sur le web est sain, l’équilibreur de charge conserve le serveur de boîtes aux lettres de destination dans le pool d’équilibrage de charge. Toutefois, en cas d’échec de la sonde d’intégrité d’Outlook sur le web pour une raison quelconque, l’équilibreur de charge supprime le serveur de boîtes aux lettres de destination du pool d’équilibrage de charge pour toutes les demandes associées à cet espace de noms. Cela signifie qu’en cas d’échec de la sonde d’intégrité, toutes les demandes client pour cet espace de noms sont dirigées vers un autre serveur, indépendamment du protocole.

Scénario B Espace de noms unique, pas d’affinité de session : Couche de niveau 7

Dans ce scénario de couche de niveau 7, un seul espace de noms, mail.contoso.com, est déployé pour tous les clients de protocole HTTP. L’équilibreur de charge ne conserve pas l’affinité de session. Étant donné que l’équilibreur de charge est configuré pour la couche de niveau 7, il y a arrêt de SSL et l’équilibreur de charge connaît l’URL de destination.

Nous vous recommandons cette configuration pour Exchange 2016. L’équilibreur de charge est configuré pour vérifier l’intégrité des serveurs de messagerie de destination dans le pool d’équilibrage de charge et une sonde d’intégrité est configurée sur chaque répertoire virtuel.

Par exemple, dans la mesure où la sonde d’intégrité indique qu’Outlook sur le web est sain, l’équilibreur de charge conserve le serveur de boîtes aux lettres de destination dans le pool d’équilibrage de charge d’Outlook sur le web. Toutefois, en cas d’échec de la sonde d’intégrité d’Outlook sur le web pour une raison quelconque, l’équilibreur de charge supprime le serveur de boîtes aux lettres cible du pool d’équilibrage de charge pour les demandes Outlook sur le web. Dans cet exemple, l’intégrité est par protocole, ce qui signifie que si la détection d’intégrité échoue, seul le protocole client affecté est dirigé vers un autre serveur.

Scénario C Espace de noms unique avec affinité de session, couche de niveau 7

Dans ce scénario de couche de niveau 7, un seul espace de noms, mail.contoso.com, est déployé pour tous les clients de protocole HTTP. Étant donné que l’équilibreur de charge est configuré pour la couche de niveau 7, il y a arrêt de SSL et l’équilibreur de charge connaît l’URL de destination. L’équilibreur de charge est également configuré pour vérifier l’intégrité des serveurs de messagerie cibles dans le pool d’équilibrage de charge. La sonde d’intégrité est configurée sur chaque répertoire virtuel.

Cependant, l’activation de l’affinité de session diminue la capacité et l’utilisation. Ceci est dû au fait que les options d’affinité plus complexes, l’équilibrage de charge basé sur cookie ou l’ID de session, exigent plus de traitement et de ressources. Nous vous recommandons de consulter votre fournisseur pour plus d’informations sur la façon dont l’affinité de session a une incidence sur l’évolutivité de votre équilibrage de charge.

Comme dans le scénario précédent, dans la mesure où la sonde d’intégrité indique qu’Outlook sur le web est sain, l’équilibreur de charge conserve le serveur de boîtes aux lettres de destination dans le pool d’équilibrage de charge d’Outlook sur le web. Toutefois, en cas d’échec de la sonde d’intégrité d’Outlook sur le web pour une raison quelconque, l’équilibreur de charge supprime le serveur de boîtes aux lettres cible du pool d’équilibrage de charge pour les demandes Outlook sur le web. Ici, l’intégrité est par protocole, ce qui signifie que si la détection d’intégrité échoue, seul le protocole client affecté est dirigé vers un autre serveur.

Scénario D Plusieurs espaces de noms et pas d’affinité de session

Ce dernier scénario avec plusieurs espaces de noms et pas d’affinité de session offre des contrôles d’intégrité par protocole et la puissance de la couche de niveau 4. Un espace de noms unique est déployé pour chaque client de protocole HTTP. Par exemple, vous configurez les clients du protocole HTTP sous la forme mail.contoso.com, mapi.contoso.com et eas.contoso.com.

Ce scénario permet de contrôler l’intégrité par protocole sans logique d’équilibrage de charge complexe. L’équilibreur de charge utilise la couche de niveau 4 et n’est pas configuré pour conserver l’affinité de session. L’équilibreur de charge est configuré pour vérifier l’intégrité des serveurs de messagerie de destination dans le pool d’équilibrage de charge. Dans ce paramètre, les sondes d’intégrité sont configurées pour cibler l’intégrité de chaque répertoire virtuel, car chaque répertoire virtuel a un espace de noms unique. Comme il est configuré pour la couche de niveau 4, l’équilibreur de charge ignore l’accès à l’URL, mais le résultat indique le contraire. L’intégrité étant par protocole, si la sonde d’intégrité échoue, seul le protocole client affecté est dirigé vers un autre serveur.

Il est essentiel de surveiller les serveurs et services disponibles pour les réseaux de haute disponibilité. Étant donné que certaines solutions d’équilibrage de charge ne connaissent pas l’URL cible ou le contenu de la demande, cela peut entraîner des difficultés pour les sondes d’intégrité Exchange.

Exchange 2016 comprend une solution de surveillance intégrée, appelée Disponibilité gérée. La disponibilité gérée, également appelée Surveillance active ou Surveillance active locale, est l’intégration des actions de récupération et de surveillance intégrées avec la plateforme de haute disponibilité Exchange.

La disponibilité gérée comprend un répondeur hors ligne. Lorsque le répondeur hors ligne est appelé, le protocole (ou serveur) concerné est supprimé du service.

Pour vérifier que les équilibreurs de charge n’acheminent pas le trafic vers un serveur de boîtes aux lettres que la disponibilité gérée a marqué comme étant hors ligne, des sondes d’intégrité d’équilibreur de charge doivent être configurées pour vérifier <virtualdirectory>/healthcheck.htm, par exemple, https://mail.contoso.com/owa/healthcheck.htm.

En savoir plus sur la disponibilité gérée dans Disponibilité gérée.

 
Afficher: