Serveur d'impression

Architecture d'Exchange Server 2016 – Microsoft Tech Community – Serveur d’impression

Le 9 avril 2021 - 1 minute de lecture


Exchange Server 2016 s'appuie sur l'architecture introduite dans Exchange Server 2013, avec l'objectif continu d'améliorer l'architecture pour répondre aux besoins des déploiements à toutes les échelles.

Architecture de bloc de construction

Dans Exchange Server 2016, il existe un bloc de construction unique qui fournit les services d'accès client et l'architecture haute disponibilité nécessaires à tout environnement de messagerie d'entreprise.
e16 "src =" http://techcommunity.microsoft.com/legacyfs/online/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/31/06 /metablogapi/e16_thumb_33FB2F9E.png "height =" 334 "border =" 0 "width =" 640 "/>
<span class=Figure 1: Architecture de bloc de construction
Dans notre quête permanente d’amélioration des capacités du produit et de simplification de l’architecture et de son déploiement, nous avons supprimé le rôle de serveur d’accès au client (CAS) et ajouté les services d’accès au client au rôle de boîte aux lettres. Même sans le rôle CAS, le système maintient un couplage lâche en termes de fonctionnalité, de gestion des versions, de partitionnement des utilisateurs et d'affinité géographique.
Le rôle de serveur de boîtes aux lettres maintenant:

  1. Contient la logique d'acheminement des demandes de protocole vers le point de terminaison de destination correct.
  2. Héberge tous les composants et / ou protocoles qui traitent, rendent et stockent les données.

Aucun client ne se connecte directement aux points de terminaison principaux sur le serveur de boîtes aux lettres; à la place, les clients se connectent aux services d'accès client et sont acheminés (via un proxy local ou distant) vers le serveur de boîtes aux lettres qui héberge la base de données active contenant la boîte aux lettres de l'utilisateur.
Les serveurs de boîtes aux lettres peuvent être ajoutés à un groupe de disponibilité de base de données (DAG), formant ainsi une unité de haute disponibilité qui peut être déployée dans un ou plusieurs centres de données. Les DAG d'Exchange Server 2016 présentent quelques améliorations spécifiques:

  1. DatabaseAvailabilityGroupIpAddresses n'est plus nécessaire lors de la création d'un DAG. Par défaut, le cluster de basculement sera créé sans point d'accès administratif, car il s'agit de la meilleure pratique recommandée.
  2. Replay Lag Manager est activé par défaut. (publié en CU1)
  3. La lecture retardée de la copie de la base de données peut être retardée en fonction de la latence du disque, garantissant ainsi que les utilisateurs actifs ne sont pas affectés. (publié en CU1)
  4. Les temps de basculement de la base de données sont réduits de 33% par rapport à Exchange Server 2013. (publié en CU3)

La suppression du rôle CAS séparé n'affecte pas la manière dont la communication se produit entre les serveurs. La communication entre les serveurs se produit toujours au niveau de la couche de protocole, garantissant ainsi que chaque serveur est un îlot. Pour la connectivité d'une boîte aux lettres donnée, le protocole utilisé est toujours servi par l'instance de protocole qui est locale à la copie de base de données active.
île "src =" http://techcommunity.microsoft.com/legacyfs/online/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/31/06 /metablogapi/island_thumb_74BF96B1.png "height =" 306 "border =" 0 "width =" 640 "/>
<span class=Figure 2: Communication inter-serveur dans Exchange 2016
La configuration de l'équilibreur de charge n'est pas non plus affectée par ce changement d'architecture. Du point de vue du protocole, les événements suivants se produiront:

  1. Un client résout l'espace de noms en une adresse IP virtuelle à charge équilibrée.
  2. L'équilibreur de charge affecte la session à un serveur de boîtes aux lettres dans le pool à charge équilibrée.
  3. Le serveur de boîtes aux lettres authentifie la demande et effectue une découverte de service en accédant à Active Directory pour récupérer les informations suivantes:
    1. Version de la boîte aux lettres (pour cette discussion, nous supposerons une boîte aux lettres Exchange 2016)
    2. Informations sur l'emplacement de la boîte aux lettres (par exemple, les informations de la base de données, ExternalURL valeurs, etc.)
  4. Le serveur de boîtes aux lettres prend la décision de proxy de la demande ou de rediriger la demande vers un autre serveur de boîtes aux lettres de l'infrastructure (dans la même forêt).
  5. Le serveur de boîtes aux lettres interroge une instance Active Manager responsable de la base de données pour déterminer quel serveur de boîtes aux lettres héberge la copie active.
  6. Le serveur de boîtes aux lettres envoie la demande par proxy au serveur de boîtes aux lettres hébergeant la copie active.

Le protocole utilisé à l'étape 6 dépend du protocole utilisé pour se connecter aux services d'accès client. Si la demande du client utilise HTTP, le protocole utilisé entre les serveurs est HTTP (sécurisé via SSL à l'aide d'un certificat auto-signé). Si le protocole utilisé par le client est IMAP ou POP, le protocole utilisé entre les serveurs est IMAP ou POP.
Les demandes de téléphonie sont uniques. Au lieu de transmettre par proxy la demande à l'étape 6, le serveur de boîtes aux lettres redirigera la demande vers le serveur de boîtes aux lettres hébergeant la copie active de la base de données de l'utilisateur, car les appareils de téléphonie prennent en charge la redirection et doivent établir leurs sessions SIP et RTP directement avec les services de messagerie unifiée. sur le serveur de boîtes aux lettres.
e16cc "src =" http://techcommunity.microsoft.com/legacyfs/online/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/31/06 /metablogapi/e16cc_thumb_47CF5538.png "height =" 278 "border =" 0 "width =" 640 "/>
<span class=Figure 3: Connectivité du protocole client
Maintenant, beaucoup d'entre vous pensent peut-être, attendez comment fonctionne l'authentification? Eh bien, pour les demandes HTTP, POP ou IMAP qui utilisent l'authentification de base, NTLM ou Kerberos, la demande d'authentification est transmise dans le cadre de la charge utile HTTP, de sorte que les services d'accès au client de chaque serveur MBX authentifient la demande naturellement. L'authentification basée sur les formulaires (FBA) est différente. FBA était l'une des raisons pour lesquelles l'affinité de session était requise pour OWA dans les versions précédentes d'Exchange – la raison étant que le cookie utilisait une clé par serveur pour le chiffrement; donc si un autre MBX recevait une demande, il ne pouvait pas décrypter la session. Avec Exchange 2013, nous avons cessé de tirer parti d'une clé de session par serveur et avons plutôt exploité la clé privée du certificat installé sur le serveur d'accès au client. Avec Exchange 2016, nous exploitons désormais le certificat d'organisation configuré pour la configuration des autorisations de l'organisation. Cela signifie que n'importe quel serveur Exchange 2016 peut déchiffrer le cookie.
Et oui, le rôle de serveur de transport Edge sera fourni dans Exchange Server 2016 (et à RTM, pour démarrer!). Toutes les capacités et fonctionnalités dont vous disposiez dans le rôle de serveur de transport Edge dans Exchange Server 2013 restent dans Exchange Server 2016.

Pourquoi avons-nous supprimé le rôle de serveur d'accès au client?

L'architecture d'Exchange Server 2016 fait évoluer l'architecture des blocs de construction qui a été affinée au cours des dernières versions. Avec cette architecture, tous les serveurs de l'environnement Exchange (à l'exception du transport Edge) sont exactement les mêmes: le même matériel, la même configuration, etc. Cette uniformité simplifie la commande du matériel, ainsi que la maintenance et la gestion des serveurs.
À l'instar d'Exchange 2010 et d'Exchange 2013, nous continuons de recommander la co-implantation des rôles en tant que meilleure pratique. Du point de vue des coûts, l'objectif global est de s'assurer que l'architecture est équilibrée pour le processeur et le disque. Le fait d'avoir des rôles de serveur séparés peut entraîner des inconvénients de coût à long terme, car vous pouvez acheter plus de ressources de processeur, de disque et de mémoire que vous n'en utiliserez réellement. Par exemple, considérons un serveur qui héberge uniquement le rôle de serveur d'accès au client. De nombreux serveurs vous permettent d'ajouter un nombre donné de disques de manière très économique. Lorsque vous déployez et utilisez ce nombre de disques, le coût est pratiquement nul. Mais si vous déployez un rôle de serveur qui utilise beaucoup moins que le nombre de disques indiqué, vous payez pour un contrôleur de disque qui est sous-utilisé ou pas du tout utilisé.
Cette architecture est conçue pour vous permettre d'avoir moins de serveurs Exchange physiques dans votre environnement. Moins de serveurs physiques signifie des coûts inférieurs pour diverses raisons:

  • Les coûts d'exploitation sont presque toujours plus élevés que les coûts d'investissement. La gestion d'un serveur au cours de sa durée de vie coûte plus cher que son achat.
  • Vous achetez moins de licences de serveur Exchange. Cette architecture ne nécessite qu'une licence pour un serveur Exchange et un système d'exploitation, tandis que la répartition des rôles nécessitait plusieurs licences de serveur Exchange et plusieurs licences de système d'exploitation.
  • Déployer moins de serveurs a un effet d'entraînement sur le reste de l'infrastructure. Par exemple, le déploiement de moins de serveurs physiques peut réduire l'espace total de rack et de plancher requis pour l'infrastructure Exchange, ce qui à son tour réduit les coûts d'alimentation et de refroidissement.

Cette architecture répartit finalement la charge sur un plus grand nombre de serveurs que le déploiement de serveurs à rôle unique, car tous les serveurs de boîtes aux lettres gèrent également l'accès client car:

  • Vous répartissez la charge sur un plus grand nombre de machines physiques, ce qui augmente l'évolutivité. Lors d'un événement de panne, la charge sur les serveurs restants n'augmente que de manière incrémentielle, ce qui garantit que les autres fonctions exécutées par le serveur ne sont pas affectées de manière négative.
  • La solution peut survivre à un plus grand nombre d'échecs de rôle (ou de service) d'accès au client tout en fournissant un service, ce qui augmente la résilience.

Exchange Server 2016 comprend également un certain nombre d'améliorations architecturales, au-delà de la consolidation des rôles de serveur, notamment des améliorations de la recherche, des améliorations de la collaboration de documents, etc.

Améliorations de la recherche

(Sortie en CU3): L'un des problèmes de l'environnement sur site était la quantité de données répliquées avec chaque copie de base de données dans les versions précédentes. Dans Exchange Server 2016, nous avons réduit les besoins en bande passante entre la copie active et une copie HA passive; pour déterminer les économies de bande passante pour votre configuration de déploiement, vous pouvez tirer parti du calculateur d'exigences de rôle Exchange Server. Cela a été accompli en permettant à l'instance de recherche locale de lire les données à partir de sa copie de base de données locale. Suite à ce changement, les instances de recherche HA passive n'ont plus besoin de se coordonner avec leurs homologues actifs pour effectuer des mises à jour d'index.
Un autre domaine d'investissement dans la recherche a consisté à réduire le temps nécessaire pour renvoyer les résultats de la recherche, en particulier chez les clients en mode en ligne comme OWA. Ceci est accompli en effectuant plusieurs lectures de disque asynchrones avant que l'utilisateur ne termine le terme de recherche, qui remplit le cache avec les informations pertinentes, fournissant une latence de requête de recherche inférieure à une seconde pour les clients en mode en ligne.

Collaboration de documents

Dans les versions précédentes d'Exchange, OWA incluait l'aperçu des documents pour les documents Office et PDF, réduisant ainsi le besoin d'avoir un client de fidélité totale. SharePoint 2013 avait une fonctionnalité similaire, mais il utilisait Office Web Apps Server 2013 (désormais rebaptisé Office Online Server) pour accomplir cette fonctionnalité. Dans Office 365, nous exploitons également Office Online Server pour fournir cette fonctionnalité, garantissant une prévisualisation et une capacité d'édition uniformes des documents dans toute la suite.
Dans Exchange Server 2016, nous tirons parti d'Office Online Server pour fournir les fonctionnalités riches de prévisualisation et de modification des documents pour OWA. Bien qu'il s'agisse d'un changement nécessaire pour garantir une expérience homogène dans toute la suite Office Server, cela introduit une complexité supplémentaire pour les environnements qui ne disposent pas d'Office Online Server.
La prochaine génération d'Office Online Server ne sera pas prise en charge pour la colocation avec Exchange. Par conséquent, vous devez déployer une infrastructure de batterie de serveurs distincte. Cette infrastructure nécessitera des espaces de noms uniques et nécessitera que l'affinité de session soit maintenue au niveau de l'équilibreur de charge.
Alors qu'Exchange prend en charge un modèle d'espace de noms indépendant, Office Online Server nécessitera un espace de noms lié pour chaque paire de centres de données résilients de site. Cependant, contrairement au modèle d'espace de noms lié dans Exchange, Office Online Server ne nécessitera aucune modification d'espace de noms lors d'une activation de centre de données.
oos "src =" http://techcommunity.microsoft.com/legacyfs/online/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/31/06 /metablogapi/oos_thumb_51CE0667.png "height =" 480 "border =" 0 "width =" 499 "/>
<span class=Figure 4: Connectivité Office Online Server

Extensibilité

(prévu pour une future CU): Office 365 a introduit les API REST (API de messagerie, de calendrier et de contact), et maintenant ces API sont disponibles dans Exchange Server 2016. Les API REST simplifient la programmation par rapport à Exchange en fournissant une syntaxe familière conçue avec ouverture (par exemple, prise en charge des normes ouvertes JSON, OAUTH, ODATA) et la flexibilité (par exemple, autorisation granulaire et étroitement limitée pour accéder aux données utilisateur). Ces API permettent aux développeurs de se connecter à partir de n'importe quelle plate-forme, qu'elle soit Web, PC ou mobile. Des SDK existent pour.NET, iOS, Android, NodeJS, Ruby, Python, Cordova et CORS pour une utilisation dans des applications Web JavaScript à page unique.
Qu'en est-il des services Web Exchange (EWS)? Toutes les applications existantes qui exploitent EWS continueront de fonctionner avec Exchange Server 2016. Nous concentrons cependant les nouveaux investissements de plate-forme sur les API REST et le modèle d'extensibilité des applications pour Office. Nous prévoyons de faire beaucoup moins d'investissements dans EWS afin de pouvoir concentrer nos ressources sur l'investissement dans une seule API moderne qui, au fil du temps, permettra la plupart des scénarios que nos partenaires utilisent actuellement EWS.

Connectivité Outlook

Introduit dans Exchange Server 2013 Service Pack 1, MAPI / HTTP est la nouvelle norme de connectivité pour Outlook. Dans Exchange Server 2016, MAPI / HTTP est activé par défaut. En outre, Exchange Server 2016 introduit un contrôle par utilisateur sur ce modèle de connectivité, ainsi que la possibilité de contrôler si le protocole (et Outlook Anywhere) est annoncé aux clients externes.

Noter: Exchange Server 2016 ne prend pas en charge la connectivité via la bibliothèque MAPI / CDO. Les produits tiers (et les solutions personnalisées développées en interne) doivent passer aux services Web Exchange (EWS) ou aux API REST pour accéder aux données Exchange.

Coexistence avec Exchange Server 2013

Dans Exchange Server 2013, le rôle de serveur d'accès au client est simplement un proxy intelligent qui n'effectue aucun traitement / rendu du contenu. Ce principe architectural a porté ses fruits en termes de coexistence vers l'avant. Lorsque vous introduisez Exchange Server 2016, vous n'avez pas besoin de déplacer l'espace de noms. C'est vrai, l'infrastructure d'accès au client Exchange Server 2013 peut envoyer par proxy les demandes de boîte aux lettres aux serveurs Exchange 2016 hébergeant la copie de base de données active! Pour la toute première fois, vous décidez quand vous déplacez l'espace de noms vers la nouvelle version. Et pas seulement cela, vous pouvez même faire en sorte que les pools d'équilibrage de charge contiennent un mélange d'Exchange Server 2013 et d'Exchange Server 2016. Cela signifie que vous pouvez effectuer un échange un pour un dans le pool d'équilibrage de charge – lorsque vous ajoutez des serveurs Exchange 2016, vous peut supprimer les serveurs Exchange 2013.

Exigences de topologie

Exchange Server 2016 ne sera pris en charge que sur les systèmes d'exploitation Windows Server 2012, Windows Server 2012 R2 et Windows Server 2016.
Du point de vue d'Active Directory, Exchange Server 2016 nécessitera:

  • Serveurs Active Directory Windows Server 2008 ou version ultérieure.
  • Windows Server 2008 ou supérieur Mode fonctionnel de la forêt et mode fonctionnel du domaine.

Exchange Server 2016 prend uniquement en charge la coexistence avec Exchange Server 2010 SP3 RU11 et Exchange Server 2013 CU10.

L'architecture préférée

Au cours de ma session chez Microsoft Ignite, j'ai révélé l'architecture préférée de Microsoft (PA) pour Exchange Server 2016. Le PA est la recommandation des meilleures pratiques de l'équipe d'ingénierie d'Exchange pour ce que nous pensons être l'architecture de déploiement optimale pour Exchange 2016, et qui est très similaire à ce que nous déployons dans Office 365.

Bien qu'Exchange 2016 offre une grande variété de choix architecturaux pour les déploiements sur site, cette architecture est la plus étudiée à ce jour. Bien qu'il existe d'autres architectures de déploiement prises en charge, elles ne sont pas recommandées.

Exchange 2016 PA est très similaire à Exchange 2013 PA. Un DAG symétrique est déployé sur une paire de centres de données avec des copies de base de données actives réparties sur tous les serveurs physiques du DAG. Les copies de base de données sont déployées sur le stockage JBOD, avec quatre copies par disque. L'une des copies est une copie de base de données retardée. Les clients se connectent à un espace de noms unifié qui est également réparti entre les centres de données de la paire résiliente de site.
Cependant, Exchange 2016 PA diffère des manières suivantes:

  1. Le modèle d'espace de noms indépendant d'Exchange est équilibré dans les centres de données dans une configuration de couche 7 qui ne tire pas parti de l'affinité de session.
  2. Une batterie de serveurs Office Online Server est déployée dans chaque centre de données, chaque batterie ayant un espace de noms unique (modèle lié). L'affinité de session est gérée par l'équilibreur de charge.
  3. Le DAG est déployé sans point d'accès administratif.
  4. La plate-forme matérielle de serveur à double socket de base contient 20 à 24 cœurs et jusqu'à 96 Go de mémoire, et un contrôleur de cache d'écriture alimenté par batterie.
  5. Tous les volumes de données sont formatés avec ReFS (avec la fonction d'intégrité désactivée).

Pour plus d'informations, consultez l'article sur l'architecture préférée d'Exchange 2016.

Résumé

Exchange Server 2016 poursuit les investissements introduits dans les versions précédentes d'Exchange en réduisant la complexité de l'architecture des rôles de serveur, en s'alignant sur les principes de conception de l'architecture préférée et d'Office 365 et en améliorant la coexistence avec Exchange Server 2013.
Ces modifications simplifient votre déploiement Exchange, sans diminuer la disponibilité ou la résilience du déploiement. Et dans certains scénarios, par rapport aux générations précédentes, le PA augmente la disponibilité et la résilience de votre déploiement.
Ross Smith IV
Gestionnaire principal de programme
Expérience client Office 365

Mises à jour

  • 08/05/15: Ajout d'une section sur les exigences de topologie.
  • 08/07/15: Exigences de topologie mises à jour.
  • 01/10/15: Mis à jour pour RTM.
  • 10/12/15: Ajout du lien Preferred Architecture.
  • 15/03/16: Mise à jour avec la prise en charge de la lecture différée dans CU1.
  • 21/09/16: Mise à jour avec lecture à partir du support passif dans CU3.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.