Architecture Exchange Server 2016 – Communauté Microsoft Tech – Bien choisir son serveur d impression

Exchange Server 2016 s'appuie sur l'architecture introduite dans Exchange Server 2013, avec pour objectif permanent 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 seul bloc constitutif qui fournit les services d'accès client et l'architecture à haute disponibilité nécessaire pour tout environnement de messagerie d'entreprise.
Figure 1: Architecture de bloc de construction
Dans notre quête permanente d’améliorer les fonctionnalités du produit et de simplifier l’architecture et son déploiement, nous avons supprimé le rôle de serveur d’accès client (CAS) et ajouté les services d’accès client au rôle de boîte aux lettres. Même sans le rôle CAS, le système conserve un couplage souple en termes de fonctionnalité, de version, de partitionnement et d'affinité géographique.
Le rôle serveur de boîtes aux lettres maintenant:

1. Abrite la logique pour acheminer les requêtes de protocole au bon point de destination.
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 d'extrémité dorsaux du serveur de boîtes aux lettres. Au lieu de cela, les clients connectent les services d’accès client et sont routé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 la base de données (DAG), formant ainsi une unité à haute disponibilité pouvant être déployée dans un ou plusieurs centres de données. Les DAG dans Exchange Server 2016 apportent 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 reproduction 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 base de données sont réduits de 33% par rapport à Exchange Server 2013. (publié en CU3)

La suppression du rôle CAS distinct n’affecte pas la façon dont la communication se produit entre les serveurs. La communication entre les serveurs a toujours lieu 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 locale à la copie de la base de données active.
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, il se passera ce qui suit:

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 situé 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 d'emplacement de boîte aux lettres (par exemple, informations de base de données, ExternalURL valeurs, etc.)
4. Le serveur de boîtes aux lettres prend la décision d'adresser la demande par proxy ou de la rediriger vers un autre serveur de boîtes aux lettres de l'infrastructure (au sein de 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 requête 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 d'envoyer la requête à l'étape 6, le serveur de boîtes aux lettres redirige 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 périphériques téléphoniques 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.
Figure 3: Connectivité du protocole client
Maintenant, beaucoup d’entre vous pensez peut-être, attendez comment l’authentification fonctionne? Pour les demandes HTTP, POP ou IMAP qui utilisent l’authentification de base, NTLM ou Kerberos, la demande d’authentification est transmise en tant que partie de la charge HTTP, de sorte que les services d’accès au client de chaque serveur MBX authentifient naturellement la demande. L'authentification basée sur les formulaires (FBA) est différente. FBA était l'une des raisons pour lesquelles une affinité de session était requise pour OWA dans les versions précédentes d'Exchange. La raison en était que le cookie utilisait une clé par serveur pour le cryptage; ainsi, si un autre MBX recevait une demande, il ne pourrait pas déchiffrer la session. Avec Exchange 2013, nous avons cessé d'utiliser une clé de session par serveur pour utiliser la clé privée du certificat installé sur le serveur d'accès au client. Avec Exchange 2016, nous exploitons maintenant le certificat d’organisation configuré pour la configuration des autorisations de l’organisation. Cela signifie que tout serveur Exchange 2016 peut décrypter le cookie.
Et oui, le rôle de serveur de transport Edge sera livré dans Exchange Server 2016 (et à RTM, pour démarrer!). Toutes les fonctionnalités que vous aviez dans le rôle serveur de transport Edge dans Exchange Server 2013 restent dans Exchange Server 2016.

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

L'architecture Exchange Server 2016 fait évoluer l'architecture de bloc 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.
Comme avec Exchange 2010 et Exchange 2013, nous continuons de recommander la colocation de 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. Avoir des rôles de serveur distincts peut entraîner des inconvénients de coût à long terme, dans la mesure où 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 de disques donné de manière très économique: lorsque vous déployez et utilisez ce nombre de disques, le coût est essentiellement nul. Toutefois, si vous déployez un rôle de serveur utilisant beaucoup moins que le nombre de disques indiqué, vous payez pour un contrôleur de disque sous-utilisé ou inutilisé.
Cette architecture est conçue pour vous permettre d'avoir moins de serveurs Exchange physiques dans votre environnement. Moins de serveurs physiques sont synonymes de réduction des coûts pour diverses raisons:

• Les coûts opérationnels sont presque toujours supérieurs aux coûts en capital. La gestion d’un serveur au cours de sa vie coûte plus cher que son achat.
• Vous achetez moins de licences de serveur Exchange. Cette architecture requiert uniquement une licence pour un serveur Exchange et un système d'exploitation, tout en séparant les rôles requis pour plusieurs licences de serveur Exchange et plusieurs licences de système d'exploitation.
• Le déploiement de moins de serveurs a un effet d'entraînement sur le reste de l'infrastructure. Par exemple, déployer moins de serveurs physiques peut réduire l'espace total de rack et de plancher requis pour l'infrastructure Exchange, ce qui réduit les coûts d'alimentation et de refroidissement.

En fin de compte, cette architecture répartit 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é. En cas d’échec, la charge sur les serveurs restants n’augmente que de façon incrémentielle, ce qui garantit que les autres fonctions exécutées par le serveur ne sont pas affectées.
• La solution peut survivre à un plus grand nombre d'échecs de rôles (ou de services) d'accès au client tout en fournissant un service, ce qui augmente la résilience.

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

Améliorations de la recherche

(Publié en CU3): La quantité de données répliquées avec chaque copie de la base de données dans les versions précédentes constituait l’un des défis les plus importants pour l’environnement sur site. Dans Exchange Server 2016, nous avons réduit les besoins en bande passante entre la copie active et une copie haute disponibilité passive. pour déterminer les économies de bande passante pour votre configuration de déploiement, vous pouvez utiliser le calculateur des exigences du rôle serveur Exchange. Cela a été accompli en permettant à l'instance de recherche locale de lire les données de sa copie de base de données locale. À la suite de cette modification, les instances de recherche de haute disponibilité passives n’ont plus besoin de se coordonner avec leurs homologues actives pour effectuer des mises à jour d’index.
Un autre domaine d’investissement dans la recherche a été la réduction du temps nécessaire pour renvoyer les résultats de la recherche, en particulier chez les clients du mode en ligne comme OWA. Pour ce faire, l'utilisateur doit effectuer plusieurs lectures sur disque asynchrone avant que le mot-clé ne soit complet. Le mot-clé est ensuite renseigné dans le cache avec les informations appropriées, ce qui permet aux clients en mode en ligne d'obtenir une latence inférieure à la seconde.

Document Collaboration

Dans les versions précédentes d'Exchange, OWA incluait l'aperçu de document pour les documents Office et PDF, ce qui évitait d'avoir un client à fidélité totale. SharePoint 2013 présentait une fonctionnalité similaire, mais il utilisait Office Web Apps Server 2013 (désormais renommé Office Online Server) pour réaliser cette fonctionnalité. Dans Office 365, nous exploitons également Office Online Server pour fournir cette fonctionnalité, en garantissant des fonctionnalités uniformes d’aperçu et d’édition des documents dans toute la suite.
Dans Exchange Server 2016, nous exploitons Office Online Server pour fournir les fonctionnalités avancées de prévisualisation et de modification de 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 dépourvus 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 gérée sur l'équilibreur de charge.
Bien qu'Exchange prenne en charge un modèle d'espace de nom indépendant, Office Online Server requiert un espace de nom lié pour chaque paire de centre de données résilient de site. Toutefois, contrairement au modèle d'espace de nom lié dans Exchange, Office Online Server ne nécessitera aucune modification d'espace de nom lors de l'activation d'un centre de données.
Figure 4: Connectivité d'Office Online Server

Extensibilité

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

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 publié vers des clients externes.

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

Coexistence avec Exchange Server 2013

Dans Exchange Server 2013, le rôle 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 en aval. 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 client Exchange Server 2013 peut envoyer par proxy les demandes de boîtes 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 nom vers la nouvelle version. De plus, vous pouvez même avoir des pools d'équilibrage de charge contenant 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'équilibreur de charge. Lorsque vous ajoutez des serveurs Exchange 2016, peut supprimer des serveurs Exchange 2013.

Topologie requise

Exchange Server 2016 sera uniquement pris en charge sur les systèmes d'exploitation Windows Server 2012, Windows Server 2012 R2 et Windows Server 2016.
Dans une perspective Active Directory, Exchange Server 2016 nécessitera:

• Windows Server 2008 ou les serveurs Active Directory ultérieurs.
• Windows Server 2008 ou version ultérieure, Mode fonctionnel Forêt et Mode fonctionnel Domaine.

Exchange Server 2016 ne prend en charge que 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 privilégiée de Microsoft pour Exchange Server 2016. Il s'agit de la meilleure pratique recommandée par l'équipe d'ingénierie Exchange pour ce que nous considérons être l'architecture de déploiement optimale pour Exchange 2016, très similaire à ce que nous déployons dans Office 365.

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

Le PA Exchange 2016 est très similaire au PA Exchange 2013. 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é également réparti entre les centres de données de la paire de résilience de site.
Cependant, le PA Exchange 2016 diffère des manières suivantes:

1. Le modèle d’espace de noms non lié d’Exchange est équilibré entre les centres de données dans une configuration de couche 7 qui n’exploite pas l’affinité de session.
2. Une batterie de serveurs Office Online Server est déployée dans chaque centre de données, chaque batterie de serveurs disposant d'un espace de nom 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 du serveur à double socket comprend 20-24 cœurs et jusqu'à 96 Go de mémoire, ainsi qu'un contrôleur de cache en écriture protégé par batterie.
5. Tous les volumes de données sont formatés avec ReFS (avec la fonctionnalité d'intégrité désactivée).

Pour plus d'informations, consultez l'article Exchange 2016 Preferred Architecture.

Sommaire

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