Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’APPLIQUE À :
2016 2019
L’équilibrage de charge dans Exchange 2016 et versions ultérieures s’appuie sur la plateforme microsoft de haute disponibilité et de résilience réseau fournie dans Exchange 2013. Lorsque cela est combiné à la disponibilité de solutions d’équilibrage de charge tierces (matérielles et logicielles), il existe plusieurs options pour implémenter l’équilibrage de charge dans votre organization 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.
À l’aide de rôles serveur minimaux, Exchange 2016 et 2019 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, qui est la collection de services, de connexions, de files d’attente et de composants qui acheminent les messages vers le catégorisateur 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 de protocole HTTP introduite avec Exchange 2013 signifie que l’affinité de session n’est plus requise dans Exchange 2016 et Exchange 2019. L’affinité de session permet une connexion persistante pour les services prenant en charge la messagerie afin qu’un utilisateur n’ait pas à réentrecier son nom d’utilisateur et son mot de passe plusieurs fois.
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 et Exchange 2019.
Une fois le protocole HTTP utilisé, tous les clients natifs se connectent à l’aide de HTTP et de HTTPs dans Exchange Server. Ce protocole standard supprime le besoin d’affinité, qui était auparavant nécessaire pour éviter une nouvelle invite d’informations d’identification de l’utilisateur chaque fois que l’équilibrage de charge redirigeait la connexion vers un autre serveur.
Rôles de serveur dans Exchange Server
Le nombre réduit de rôles serveur pour Exchange 2016 et Exchange 2019 simplifie l’implémentation d’Exchange et la configuration matérielle requise. Le nombre de rôles serveur dans Exchange 2016 et 2019 est réduit de sept à deux : le serveur de boîtes aux lettres et le serveur de transport Edge. Le rôle serveur de boîtes 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 et Exchange 2019, comme dans les versions antérieures d’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é.
Les mêmes fonctionnalités restent dans Exchange 2016 et Exchange 2019. 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 changements de rôle de serveur dans Exchange Server, consultez l’article architecture Exchange Server.
| 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 d’effectuer un anti-courrier indésirable et activer le flux de courrier de bout en bout. |
| Transport Edge | Gère tout le flux de messagerie Internet entrant et sortant à l'aide de :
Non membre de la forêt Active Directory. |
Bien qu’il ne soit pas obligatoire, le serveur de transport Edge se trouve dans le réseau de périmètre, comme dans les versions antérieures d’Exchange, pour fournir un flux de courrier entrant et sortant sécurisé pour votre organization Exchange.
Pour plus d’informations sur le service de transport, consultez l’article Présentation du service de transport sur les serveurs de transport Edge.
Protocoles dans Exchange Server
À compter d’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. Vous devez fournir au client l’adresse IP de chaque serveur de boîtes aux lettres, et le client HTTP gérerait les tâches. Si un serveur Exchange échoue, le protocole tente de se connecter à un autre serveur. Toutefois, l’équilibrage de charge dans DNS présente des inconvénients, décrits dans la section suivante Options d’équilibrage de charge dans Exchange Server.
Pour plus d’informations sur HTTP et Exchange Server, consultez l’article MAPI sur HTTP dans Exchange Server.
Options d’équilibrage de charge dans Exchange Server
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’est pas nécessaire d’utiliser des paires d’équilibreurs de charge, mais nous vous recommandons de déployer dans des clusters pour améliorer la résilience du réseau.
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 de 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.
La simplicité a un prix, mais dans ce cas, le tourniquet DNS n’équilibre pas vraiment la charge du trafic, car il n’existe pas de moyen par programmation de s’assurer que chaque serveur obtient une part équitable du trafic. En outre, il n’y a pas de surveillance du niveau de service, de sorte qu’en cas d’échec d’un seul service, les clients ne sont 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 de défaillance du service, les équilibreurs de charge peuvent diriger le trafic vers un autre serveur et mettre le serveur à problème hors connexion. 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.
Les avantages de l’équilibrage de charge de couche 4 sont les 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.
Les avantages de l’équilibrage de charge de la couche 7 sont les 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 |
| 587 | Boîte aux lettres | SMTP entrant pour les clients |
| 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, EAC) |
| 993 | Boîte aux lettres | Sécurisation de clients IMAP4 |
| 995 | Boîte aux lettres | Sécurisation de clients POP3 |
Scénarios de déploiement d’équilibrage de charge dans Exchange Server
Exchange 2016 a 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 4, l’équilibreur de charge est configuré pour case activée l’intégrité d’un seul répertoire virtuel, car il ne peut pas distinguer Outlook sur le web requêtes des requêtes 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é.
Tant que la réponse de la sonde d’intégrité Outlook sur le web est saine, l’équilibreur de charge conserve le serveur de boîtes aux lettres de destination dans le pool d’équilibrage de charge. Toutefois, si la sonde d’intégrité Outlook sur le web échoue 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 requêtes associées à cet espace de noms. Cela signifie qu’en cas d’échec de la sonde d’intégrité, toutes les demandes du client pour cet espace de noms sont dirigées vers un autre serveur, quel que soit le 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 7, il existe une terminaison SSL et l’équilibreur de charge connaît l’URL de destination.
Nous vous recommandons cette configuration pour Exchange 2016 et Exchange 2019. L’équilibreur de charge est configuré pour case activée l’intégrité des serveurs de boîtes aux lettres 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, tant que la réponse de la sonde d’intégrité Outlook sur le web est saine, l’équilibreur de charge conserve le serveur de boîtes aux lettres de destination dans le pool d’équilibrage de charge Outlook sur le web. Toutefois, si la sonde d’intégrité Outlook sur le web échoue pour une raison quelconque, l’équilibreur de charge supprime le serveur de boîtes aux lettres cible du pool d’équilibrage de charge pour Outlook sur le web demandes. 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 case activée l’intégrité des serveurs de boîtes aux lettres 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. En effet, les options d’affinité les plus impliquées, l’équilibrage de charge basé sur les cookies ou l’ID de session SSL (Secure Sockets Layer), nécessitent davantage de traitement et de ressources. Nous vous recommandons de case activée avec votre fournisseur sur la façon dont l’affinité de session affecte votre scalabilité de l’équilibrage de charge.
Comme dans le scénario précédent, tant que la réponse de la sonde d’intégrité Outlook sur le web est saine, l’équilibreur de charge conserve le serveur de boîtes aux lettres de destination dans le pool d’équilibrage de charge Outlook sur le web. Toutefois, si la sonde d’intégrité Outlook sur le web échoue pour une raison quelconque, l’équilibreur de charge supprime le serveur de boîtes aux lettres cible du pool d’équilibrage de charge pour Outlook sur le web demandes. 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 4 et n’est pas configuré pour maintenir l’affinité de session. La configuration de l’équilibreur de charge vérifie l’intégrité des serveurs de boîtes aux lettres 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.
Équilibrage de charge et disponibilité managée dans Exchange Server
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 requête, cela peut introduire des complexités pour les sondes d’intégrité Exchange.
Exchange 2016 et Exchange 2019 incluent une solution de supervision intégrée, appelée Disponibilité managée. La disponibilité managée, également appelée supervision active ou supervision active locale, est l’intégration d’actions intégrées de surveillance et de récupération à 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 garantir que les équilibreurs de charge n’acheminent pas le trafic vers un serveur de boîtes aux lettres marqué comme hors connexion par la disponibilité managée, les sondes d’intégrité de l’équilibreur de charge doivent être configurées pour case activée <virtualdirectory>/healthcheck.htm, par exemple. <https://mail.contoso.com/owa/healthcheck.htm>
Pour en savoir plus sur la disponibilité managée, consultez Disponibilité managée.