Planification d’une haute disponibilité et d’une résilience de site

Article
04/04/2023

S’applique à : Exchange Server 2013

Pendant la phase de planification, les architectes, administrateurs et autres intervenants sur le système doivent identifier les impératifs de l'entreprise et de l'architecture pour le déploiement, en particulier les exigences de haute disponibilité et de résilience de site.

Il existe des exigences générales qui doivent être remplies pour le déploiement de ces fonctionnalités, ainsi que des exigences matérielles, logicielles et réseau qui doivent également être remplies.

Conditions requises générales

Avant de déployer un groupe de disponibilité de base de données (DAG) et de créer des copies de base de données de boîtes aux lettres, assurez-vous que les recommandations suivantes à l’échelle du système sont prises en compte :

Un serveur DNS (Domain Name System) doit être exécuté. Idéalement, le serveur DNS doit accepter des mises à jour dynamiques. Si cela n'est pas possible, vous devez créer un enregistrement (A) d'hôte DNS pour chaque serveur Exchange. Dans le cas contraire, Exchange ne fonctionnera pas correctement.
Chaque serveur de boîtes aux lettres d'un groupe de disponibilité de base de données doit être un serveur membre du même domaine.
L’ajout d’un serveur de boîtes aux lettres Exchange 2013 qui est également un serveur d’annuaire à un DAG n’est pas pris en charge.
Le nom que vous attribuez au groupe de disponibilité de base de données doit être un nom d'ordinateur valide, disponible, unique et composé tout au plus de 15 caractères.

Configuration matérielle requise

En règle générale, aucune configuration matérielle n’est exigée pour les groupes de disponibilité de base de données ou les copies de bases de données de boîtes aux lettres. Les serveurs utilisés doivent répondre à toutes les exigences définies dans les rubriques relatives aux conditions préalables d’Exchange 2013 et à la configuration système requise pour Exchange 2013.

Contraintes de stockage

Il n’y a généralement pas de contrainte de stockage requise pour les groupes de disponibilité de base de données ou les copies de bases de données de boîtes aux lettres. Les groupes de disponibilité de base de données ne nécessitent pas ou n'utilisent pas le stockage partagé géré par cluster. Le stockage partagé géré par cluster est pris en charge pour une utilisation dans un DAG uniquement lorsque le DAG est configuré pour utiliser une solution qui utilise l’API de réplication tierce intégrée à Exchange 2013.

Configuration logicielle requise

Les DAG sont disponibles dans Exchange 2013 Standard et Exchange 2013 Enterprise. En outre, un DAG peut contenir une combinaison de serveurs exécutant Exchange 2013 Standard et Exchange 2013 Enterprise.

Chaque membre du DAG doit également exécuter le même système d’exploitation. Exchange 2013 est pris en charge sur les systèmes d’exploitation Windows Server 2008 R2, Windows Server 2012 et Windows Server 2012 R2. Tous les membres d’un DAG spécifique doivent exécuter le même système d’exploitation. Windows Server 2012 R2 est pris en charge uniquement pour les membres DAG qui exécutent Exchange 2013 Service Pack 1 ou version ultérieure.

En plus de remplir les conditions préalables à l’installation d’Exchange 2013, la configuration requise du système d’exploitation doit être respectée. Les DAG utilisent la technologie de clustering de basculement Windows et, par conséquent, ils nécessitent la version Entreprise ou Datacenter de Windows Server 2008 R2, ou la version Standard ou Datacenter des systèmes d’exploitation Windows Server 2012 ou Windows Server 2012 R2.

Configuration requise pour le réseau

Chaque groupe de disponibilité de base de données et chacun de leurs membres doivent remplir certaines configurations réseau spécifiques. Chaque DAG doit avoir un seul réseau MAPI, qui est utilisé par un membre DAG pour communiquer avec d’autres serveurs (par exemple, d’autres serveurs Exchange 2013 ou serveurs d’annuaire), et aucun ou plusieurs réseaux de réplication, qui sont des réseaux dédiés à la copie des journaux de transaction et à l’amorçage.

Dans les versions précédentes d'Exchange, nous recommandions l'utilisation d'au moins deux réseaux (un réseau MAPI et un réseau de réplication) pour les groupes de disponibilité de bases de données. Dans Exchange 2013, plusieurs réseaux sont pris en charge, mais notre recommandation dépend de votre topologie de réseau physique. Si vous avez plusieurs réseaux physiques entre les membres du DAG qui sont physiquement séparés les uns des autres, l’utilisation d’un réseau MAPI et d’un réseau de réplication distincts offre davantage de redondance. Si vos différents réseaux sont partiellement séparés physiquement, mais qu'ils convergent vers un seul réseau physique (par exemple, un lien WAN unique), il est recommandé de n'utiliser qu'un seul réseau (de préférence de type 10 Gigabit Ethernet) pour le trafic MAPI et le trafic de réplication. Cette approche offre une simplicité pour le réseau et le chemin d’accès réseau.

Tenez compte des facteurs suivants lors de la conception de l’infrastructure réseau pour votre DAG :

Chaque membre du groupe de disponibilité de base de données doit avoir au moins une carte réseau capable de communiquer avec tous les autres membres du groupe de disponibilité de base de données. Si vous disposez d'un chemin d'accès réseau unique, nous vous recommandons d'utiliser au minimum la technologie 1 Gigabit Ethernet, avec toutefois une préférence pour le 10 Gigabit Ethernet. En outre, lorsque vous utilisez une carte réseau unique dans chaque membre du groupe de disponibilité de base de données, nous vous recommandons de concevoir la solution générale tout en gardant à l'esprit la carte et le chemin d'accès réseau unique.
L'utilisation de deux cartes réseau dans chaque membre du groupe de disponibilité de base de données vous procure un réseau MAPI et un réseau de réplication, et entraîne une redondance du réseau de réplication, ainsi que les comportements de récupération suivants :
- Si une défaillance affecte le réseau MAPI, un basculement de serveur se produit (en supposant qu’il existe des copies de base de données de boîtes aux lettres saines qui peuvent être activées).
- Si une défaillance affecte le réseau de réplication, si le réseau MAPI n’est pas affecté par l’échec, les opérations de copie des journaux de transaction et d’amorçage sont rétablies pour utiliser le réseau MAPI, même si la propriété ReplicationEnabled du réseau MAPI est définie sur False. Lorsque le réseau de réplication défaillant est à nouveau en bon état et prêt à poursuivre l'envoi de journaux et les opérations d'amorçage, vous devez passer manuellement au réseau de réplication. Pour passer de la réplication sur le réseau MAPI à un réseau de réplication restauré, vous pouvez soit interrompre et reprendre la réplication continue en utilisant les cmdlets Suspend-MailboxDatabaseCopy et Resume-MailboxDatabaseCopy, soit redémarrer le service de réplication Microsoft Exchange. Nous recommandons l'utilisation des opérations d'interruption et de reprise pour éviter la brève interruption provoquée par le redémarrage du service de réplication Microsoft Exchange.
Chaque membre du groupe de disponibilité de base de données doit posséder le même nombre de réseaux. Par exemple, si vous envisagez d'utiliser une carte réseau unique dans un membre du groupe de disponibilité de base de données, tous les membres de ce groupe doivent aussi utiliser une carte réseau unique.
Chaque groupe de disponibilité de base de données ne doit avoir qu'un seul réseau MAPI. Le réseau MAPI doit offrir une connectivité à d'autres serveurs et services Exchange, tels que Active Directory et DNS.
D’autres réseaux de réplication peuvent être ajoutés, selon les besoins. Vous pouvez aussi empêcher les points de défaillance uniques d'une carte réseau unique en utilisant une collaboration de cartes réseau ou une technologie similaire. Toutefois, même lors de l’utilisation de l’association, cette technologie n’empêche pas le réseau lui-même d’être un point de défaillance unique. De plus, une collaboration de cartes réseau complique inutilement le DAG.
Chaque réseau sur chaque serveur membre du groupe de disponibilité de base de données doit se trouver sur son propre sous-réseau. Chaque serveur du groupe de disponibilité de base de données peut se trouver sur un autre sous-réseau, mais les réseaux MAPI et de réplication doivent pouvoir être routés et offrir une connectivité de manière à ce que :
- Chaque réseau de chaque serveur membre du groupe de disponibilité de base de données soit sur son propre sous-réseau, séparé du sous-réseau utilisé par chacun des autres réseaux sur le serveur.
- Chaque réseau MAPI de serveur membre du DAG puisse communiquer avec tout autre réseau MAPI membre du DAG.
- Chaque réseau de réplication de serveur membre du DAG puisse communiquer avec tout autre réseau de réplication membre du DAG.
- Aucun routage direct ne permet la transmission de signaux de pulsation du réseau de réplication d'un serveur membre du DAG vers le réseau MAPI d'un autre membre du DAG, ou l'inverse, ou entre plusieurs réseaux de réplication au sein du groupe de disponibilité de base de données.
Quel que soit son emplacement géographique par rapport aux autres membres du DAG, chaque membre du DAG doit avoir une latence réseau aller-retour ne dépassant pas 500 millisecondes entre les autres membres. À mesure que la latence aller-retour entre deux serveurs de boîtes aux lettres hébergeant des copies d’une base de données augmente, le risque de non-mise à jour de la réplication augmente également. Quelle que soit la latence de la solution, les clients doivent vérifier que les réseaux entre tous les membres du DAG sont capables de répondre aux objectifs de protection et de disponibilité des données du déploiement. Les configurations présentant des valeurs de latence plus élevées peuvent exiger un réglage spécial des paramètres du groupe de disponibilité de base de données, de la réplication et du réseau (tel que l'augmentation du nombre de bases de données ou la réduction du nombre de boîtes aux lettres par base de données) pour atteindre les objectifs escomptés.
Les exigences de latence aller-retour peuvent ne pas être les exigences de bande passante réseau et de latence les plus strictes pour une configuration multi-centres de données. Évaluez la charge réseau totale, qui inclut l’accès au client, Active Directory, le transport, la réplication continue et d’autres trafics d’application, afin de déterminer la configuration réseau requise pour votre environnement.
Les réseaux de groupes de disponibilité de base de données prennent en charge les protocoles Internet IPv4 et IPv6. Le protocole IPv6 n'est pris en charge que lorsque le protocole IPv4 est aussi utilisé ; un environnement exclusivement IPv6 n'est pas pris en charge. L'utilisation d'adresses IPv6 et de plages d'adresses IP n'est prise en charge que si les protocoles IPv6 et IPv4 sont activés sur cet ordinateur et si le réseau prend en charge les deux versions d'adresse IP. Si Exchange 2013 est déployé dans cette configuration, tous les rôles serveur peuvent envoyer des données à des appareils, des serveurs et des clients qui utilisent des adresses IPv6 et en recevoir des données.
APIPA (Automatic Private IP Addressing) est une fonctionnalité d'Windows qui attribue automatiquement les adresses IP quand aucun serveur DHCP (Dynamic Host Configuration Protocol) n'est disponible sur le réseau. Les adresses APIPA (y compris les adresses affectées manuellement à partir de la plage d’adresses APIPA) ne sont pas prises en charge pour une utilisation par les DAG ou par Exchange 2013.

Conditions requises pour le nom et l’adresse IP des groupes de disponibilité de base de données

Lors de la création, chaque groupe de disponibilité de base de données reçoit un nom unique, et est soit affecté à une ou plusieurs adresses IP statiques soit configuré pour l’utilisation de DHCP. Que vous utilisiez des adresses statiques ou dynamiques, toute adresse IP affectée au groupe de disponibilité de base de données doit se trouver sur le réseau MAPI.

Chaque DAG exécuté sous Windows Server 2008 R2 ou Windows Server 2012 nécessite au minimum une adresse IP sur le réseau MAPI. Un DAG nécessite davantage d’adresses IP lorsque le réseau MAPI est étendu sur plusieurs sous-réseaux. Les groupes de disponibilité de base de données exécutés sur Windows Server 2012 R2 créés sans point d'accès administratif de cluster ne nécessitent pas d'adresse IP.

L'illustration suivante représente un groupe de disponibilité de base de données dans lequel tous les nœuds ont le réseau MAPI sur le même sous-réseau.

DAG sur un seul sous-réseau.

Dans cet exemple, le réseau MAPI dans chaque membre DAG se trouve sur le sous-réseau 172.19.18.*x_. Par conséquent, le groupe de disponibilité de base de données exige une adresse IP unique sur ce sous-réseau.

La figure suivante illustre un DAG qui a un réseau MAPI qui s’étend sur deux sous-réseaux : 172.19.18.*x_ et 172.19.19.*x_.

DAG étendu sur plusieurs sous-réseaux.

Dans cet exemple, le réseau MAPI de chaque membre du groupe de disponibilité de base de données se trouve sur un sous-réseau distinct. Par conséquent, le groupe de disponibilité de base de données exige deux adresses IP, une pour chaque sous-réseau sur le réseau MAPI.

Chaque fois que le réseau MAPI du DAG est étendu sur un autre sous-réseau, une adresse IP supplémentaire pour ce sous-réseau doit être configurée pour le DAG. Chaque adresse IP configurée pour le groupe de disponibilité de base de données est affectée au cluster de basculement sous-jacent du groupe de disponibilité de base de données et utilisée par celui-ci. Le nom du groupe de disponibilité de base de données est aussi utilisé comme nom pour le cluster de basculement sous-jacent.

À n'importe quel moment spécifique, le cluster du groupe de disponibilité de base de données n'utilisera qu'une des adresses IP affectées. La fonction de clustering avec basculement Windows enregistre cette adresse IP dans le DNS quand l'adresse IP du cluster et les ressources de nom du réseau sont mises en ligne. En plus de l'utilisation d'une adresse IP et d'un nom de réseau, un objet nom de cluster (CNO) est créé dans Active Directory. Le nom, l'adresse IP et le CNO du cluster sont utilisés en interne par le système pour sécuriser le groupe de disponibilité de base de données et à des fins de communication interne. Les administrateurs et les utilisateurs finaux n'ont pas besoin d'interface ni de connexion avec le nom du groupe de disponibilité de base de données ni avec l'adresse IP.

Remarque

Bien que l’adresse IP et le nom réseau du cluster soient utilisés en interne par le système, il n’existe aucune dépendance matérielle dans Exchange 2013 selon laquelle ces ressources soient disponibles. Même si le point d’accès administratif du cluster sous-jacent (par exemple, son adresse IP et ses ressources de nom réseau) est hors connexion, la communication interne se produit toujours au sein du DAG à l’aide des noms de serveur des membres du DAG. Cependant, nous vous recommandons de contrôler périodiquement la disponibilité de ces ressources afin de vous assurer qu'elles ne sont pas hors ligne pendant plus de 30 jours. Si le cluster sous-jacent est hors ligne pendant plus de 30 jours, le compte de CNO peut être invalidé par le mécanisme de nettoyage de la mémoire dans Active Directory.

Configuration de la carte réseau pour les groupes de disponibilité de base de données

Chaque carte réseau doit être correctement configurée selon l’usage prévu. La configuration d'une carte réseau destinée à un réseau MAPI n'est pas la même que celle d'une carte réseau destinée à un réseau de réplication. Pour configurer correctement chaque carte réseau, vous devez configurer l'ordre de connexion au réseau dans Windows de manière à ce que le réseau MAPI se connecte en premier. Pour savoir comment modifier l'ordre de connexion au réseau, consultez la rubrique relative à la modification de l'ordre des liaisons du protocole.

Configuration de la carte du réseau MAPI

Une carte réseau destinée à l’utilisation par un réseau MAPI doit être configurée comme décrit dans le tableau suivant.

Fonctionnalités de mise en réseau	Paramètres
Client pour les réseaux Microsoft	Activé
Planificateur de paquets QoS	Éventuellement activé
Partage de fichiers et d'imprimantes pour les réseaux Microsoft	Activé
Internet Protocol Version 6 (TCP/IP v6)	Activé
Internet Protocol Version 4 (TCP/IP v4)	Activé
Pilote E/S Mappage de découverte de couche liaison	Activé
Répondeur de découverte de couche de liaison	Activé

Les propriétés TCP/IP v4 d'une carte de réseau MAPI sont configurées de la manière suivante :

L'adresse IP du réseau MAPI d'un membre du groupe de disponibilité de base de données peut être affectée ou configurée manuellement pour utiliser le protocole DHCP. Dans ce cas, nous vous recommandons d'utiliser les réservations persistantes pour l'adresse IP du serveur.
Le réseau MAPI utilise généralement une passerelle par défaut, bien que ce ne soit pas obligatoire.
Au moins une adresse de serveur DNS doit être configurée. Pour la redondance, il est recommandé d'utiliser plusieurs serveurs DNS.
La case Enregistrer les adresses de cette connexion dans le serveur DNS doit être cochée.

Configuration de la carte du réseau de réplication

Une carte réseau destinée à l’utilisation par un réseau de réplication doit être configurée comme décrit dans le tableau suivant.

Fonctionnalités de mise en réseau	Paramètres
Client pour les réseaux Microsoft	Désactivé
Planificateur de paquets QoS	Éventuellement activé
Partage de fichiers et d'imprimantes pour les réseaux Microsoft	Désactivé
Internet Protocol Version 6 (TCP/IP v6)	Activé
Internet Protocol Version 4 (TCP/IP v4)	Activé
Pilote E/S Mappage de découverte de couche liaison	Activé
Répondeur de découverte de couche de liaison	Activé

Les propriétés TCP/IP v4 d'une carte de réseau de réplication sont configurées de la manière suivante :

L'adresse IP du réseau de réplication d'un membre du groupe de disponibilité de base de données peut être affectée ou configurée manuellement pour utiliser le protocole DHCP. Dans ce cas, nous vous recommandons d'utiliser les réservations persistantes pour l'adresse IP du serveur.
Les réseaux de réplication n'ont généralement pas de passerelle par défaut et, si le réseau MAPI en a une, aucun autre réseau ne doit avoir de passerelle par défaut. Le routage du trafic réseau sur un réseau de réplication peut être configuré à l'aide de routes persistantes et statiques au réseau correspondant sur d'autres membres du groupe de disponibilité de base de données utilisant des adresses de passerelle qui peuvent effectuer le routage entre les réseaux de réplication. Tout autre trafic ne correspondant pas à cette route sera traité par la passerelle par défaut configurée sur la carte du réseau MAPI.
Les adresses de serveur DNS ne doivent pas être configurées.
La case à cocher Enregistrer les adresses de cette connexion dans le serveur DNS ne doit pas être activée.

Configuration requise pour le serveur témoin

Un serveur témoin est un serveur extérieur au groupe de disponibilité de base de données qui sert à obtenir et maintenir le quorum quand le groupe de disponibilité de base de données a un nombre de membres pair. Les groupes de disponibilité de base de données ayant un nombre de membres impair n’utilisent pas de serveur témoin. Tout groupe de disponibilité de base de données ayant un nombre de membres pair doit utiliser un serveur témoin. Le serveur témoin peut être n'importe quel ordinateur exécutant Windows Server. Il n'est pas nécessaire que la version du système d'exploitation Windows Server du serveur témoin corresponde au système d'exploitation utilisé par les membres du groupe de disponibilité de base de données.

Le quorum est géré au niveau du cluster, sous le groupe de disponibilité de base de données. Un DAG a quorum lorsque la plupart de ses membres sont en ligne et peuvent communiquer avec les autres membres en ligne du DAG. Cette notion de quorum est un aspect du concept de quorum dans le clustering de basculement Windows. Parmi les aspects liés et nécessaires au quorum dans les clusters de basculement se trouve la ressource quorum. La ressource quorum est une ressource située dans un cluster de basculement, fournissant un moyen d’arbitrage conduisant à l’état de cluster et aux décisions d’appartenance. La ressource quorum fournit également un stockage permanent pour le stockage des informations de configuration. La ressource de quorum est accompagnée du journal de quorum qui est une base de données de configuration pour le cluster. Il contient des informations telles que les serveurs membres du cluster, les ressources installées dans le cluster et l’état de ces ressources (par exemple, en ligne ou hors connexion).

Il est essentiel que chaque membre du DAG ait une vue cohérente de la façon dont le cluster sous-jacent du DAG est configuré. Le quorum agit comme le référentiel définitif pour toutes les informations de configuration relatives au cluster. Le quorum est utilisé pour départager les nœuds afin d’éviter le syndrome Split-Brain. Le syndrome Split-Brain est une situation qui se produit lorsque les membres du groupe de disponibilité de base de données ne peuvent pas communiquer entre eux bien qu’ils soient opérationnels. Le syndrome de fractionnement du cerveau est évité en exigeant toujours que la plupart des membres du DAG (et si les DAG ont un nombre pair de membres, le serveur témoin du DAG) soit disponible et interagissent pour que le DAG soit opérationnel.

Planification de résilience de site

Chaque jour, un nombre croissant d’entreprises reconnaît que l’accès à un système de messagerie fiable et disponible est essentiel à leur réussite. Pour de nombreuses organisations, le système de messagerie fait partie des plans de continuité d'activité et la résilience du site doit être conçue dans leur déploiement de service de messagerie. Fondamentalement, de nombreuses solutions de résilience de site impliquent le déploiement de matériel dans un deuxième centre de données.

En définitive, la conception générale d'un groupe de disponibilité de base de données, y compris le nombre de membres du groupe de disponibilité de base de données et le nombre de copies de base de données de boîtes aux lettres, dépendra des accords de niveau du service de récupération (SLA) de chaque organisation pour traiter divers scénarios d'échec. Pendant la phase de planification, les architectes et administrateurs du système identifient les besoins du déploiement, y compris les exigences de résilience de site. Ils déterminent les emplacements à utiliser et les cibles SLA requises pour la récupération. L'accord SLA déterminera les deux éléments spécifiques qui doivent être la base de la conception d'une solution de haute disponibilité et de résilience de site : l'objectif de temps de récupération et l'objectif de point de récupération. Ces deux valeurs sont mesurées en minutes. L'objectif de temps de récupération correspond au temps nécessaire à la restauration du service. L'objectif de point de récupération correspond à l'actualité des données après l'opération de récupération. Un accord SLA peut aussi être défini pour restaurer le centre de données principal pour qu'il fonctionne complètement une fois les problèmes résolus.

Les architectes et administrateurs de la solution identifieront aussi les ensembles d'utilisateurs qui requièrent une protection de résilience de site et détermineront si la solution multi-site doit être une configuration actif/passif ou actif/actif. Dans une configuration actif/passif, aucun utilisateur n'est normalement hébergé dans le centre de données de secours. Dans une configuration actif/actif, les utilisateurs sont hébergés aux deux emplacements, et un certain pourcentage du nombre total de bases de données dans le cadre de cette solution a un emplacement actif préféré dans un deuxième centre de données. Quand le service est défaillant pour les utilisateurs d'un centre de données, ces utilisateurs sont activés dans l'autre centre de données.

L'élaboration des contrats de niveau de service appropriés requiert souvent de répondre aux questions de base suivantes :

Quel niveau de service est requis suite à un échec du centre de données principal ?
Les utilisateurs ont-ils besoin de leurs données ou uniquement des services de messagerie ?
À quelle fréquence les données sont-elles requises ?
Combien d'utilisateurs doivent être pris en charge ?
Comment les utilisateurs accèderont-ils à leurs données ?
Qu'est-ce que le SLA d'activation de centre de données en mode veille ?
Comment le service est-il ramené vers le centre de données principal ?
Les ressources sont-elles dédiées à la solution de résilience de site ?

En répondant à ces questions, vous commencez à donner forme à une conception de résilience de site pour votre solution de messagerie. Une exigence clé en relation avec la récupération suite à une défaillance de site consiste à créer une solution permettant de récupérer les données nécessaires dans un centre de données de sauvegarde hébergeant le service de messagerie de sauvegarde.

Planification de certificat

Il n’y a pas de considération de conception spéciale ou unique pour les certificats lors du déploiement d’un groupe de disponibilité de base de données dans un centre de données unique. Toutefois, lorsque vous étendez un groupe de disponibilité de base de données sur plusieurs centres de données dans une configuration de résilience de site, il y a quelques considérations spécifiques en matière de certificats. En règle générale, la conception de votre certificat dépend des clients utilisés et des exigences de certificat des autres applications qui utilisent des certificats. Certaines recommandations et meilleures pratiques doivent être observées en ce qui concerne le type et le nombre de certificats.

Il est recommandé de réduire le nombre de certificats que vous utilisez pour vos serveurs Exchange et d'inverser les serveurs proxy. Il est recommandé d'utiliser un certificat unique pour tous ces points finaux de service dans chaque centre de données. Cette approche minimise le nombre de certificats nécessaires, ce qui réduit à la fois le coût et la complexité de la solution.

Pour les clients Outlook Anywhere, il est recommandé d'utiliser un seul certificat SAN (autre nom d'objet) par centre de données, en incluant plusieurs noms d'hôtes dans le certificat. Pour assurer la connectivité d'Outlook Anywhere après un basculement de base de données, de serveur ou de centre de données, vous devez utiliser le même nom de principal pour chaque certificat et paramétrer l'objet configuration de fournisseur OutlookActive Directory avec le même nom de principal dans le formulaire Microsoft-Standard (msstd). Par exemple, si vous utilisez le nom de principal de certificat mail.contoso.com, vous configurez les attributs de la manière suivante :

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Certaines applications qui s’intègrent à Exchange ont des exigences de certificat spécifiques qui peuvent nécessiter l’utilisation de certificats supplémentaires. Exchange 2013 peut coexister avec Office Communications Server (OCS). OCS nécessite des certificats avec des certificats 1024 bits ou plus qui utilisent le nom du serveur OCS pour le nom du principal du certificat. Étant donné que l’utilisation d’un nom de serveur OCS pour le nom du principal de certificat empêche Outlook Anywhere de fonctionner correctement, vous devez utiliser un certificat supplémentaire et distinct pour l’environnement OCS.

Planification de réseau

En plus des exigences de mise en réseau spécifiques qui doivent être satisfaites pour chaque DAG et pour chaque serveur membre d’un DAG, certaines exigences et recommandations sont spécifiques aux configurations de résilience de site. Comme avec tous les groupes de disponibilité de base de données, que les membres soient déployés dans un seul ou plusieurs sites, la latence en boucle du réseau entre les membres du groupe de disponibilité de base de données ne doit pas dépasser 500 millisecondes. En outre, certains paramètres spécifiques de configuration sont recommandés pour les groupes de disponibilité de base de données étendus sur plusieurs sites :

Les réseaux MAPI doivent être isolés des réseaux de réplication : les stratégies réseau Windows, les stratégies de pare-feu Windows ou les listes de contrôle d’accès de routeur (ACL) doivent être utilisées pour bloquer le trafic entre le réseau MAPI et les réseaux de réplication. Cette configuration est nécessaire pour empêcher la pulsation de réseau inter-conversation.
Les enregistrements DNS orientés client doivent avoir une valeur de durée de vie (TTL) de 5 minutes : la durée de temps d’arrêt des clients dépend non seulement de la vitesse à laquelle un basculement peut se produire, mais également de la rapidité avec laquelle la réplication DNS se produit et de la requête des clients pour obtenir des informations DNS mises à jour. Les enregistrements DNS pour tous les services clients Exchange, y compris Outlook Web App, Exchange ActiveSync, services Web Exchange, Outlook Anywhere, SMTP, POP3 et IMAP4 dans les serveurs DNS internes et externes doivent être définis avec une durée de vie de 5 minutes.
Utiliser des itinéraires statiques pour configurer la connectivité entre les réseaux de réplication : pour fournir une connectivité réseau entre chacune des cartes réseau de réplication, utilisez des itinéraires statiques persistants. Ce processus est une configuration rapide et ponctuelle effectuée sur chaque membre DAG lors de l’utilisation d’adresses IP statiques. Si vous utilisez un protocole DHCP pour obtenir des adresses IP pour vos réseaux de réplication, vous pouvez aussi vous en servir pour affecter des routages statiques à la réplication et ainsi simplifier le processus de configuration.

Planification générale de résilience de site

En plus des exigences répertoriées ci-dessus pour la haute disponibilité, il existe d’autres recommandations pour le déploiement d’Exchange 2013 dans une configuration résiliente de site (par exemple, l’extension d’un DAG sur plusieurs centres de données). Ce que vous faites pendant la phase de planification conditionnera directement la réussite de votre solution de résilience de site. Par exemple, une conception d'espace de noms médiocre peut entraîner des complications avec les certificats et une configuration de certificat incorrecte peut empêcher les utilisateurs d'accéder aux services.

Afin de minimiser le temps que prend l'activation d'un deuxième centre de données et de permettre à celui-ci d'héberger des points finaux de service d'un centre de données défaillant, il faut effectuer la planification de façon appropriée. Voici quelques exemples :

Vos objectifs SLA pour la solution de résilience de site doivent être bien compris et bien documentés.
Les serveurs du deuxième centre de données doivent disposer d'une capacité suffisante pour héberger la population d'utilisateurs des deux centres de données.
Tous les services fournis dans le centre de données principal doivent être activés dans le deuxième centre de données (à moins que le service ne soit pas inclus dans le cadre de l'accord SLA de résilience de site). Ces services incluent Active Directory, l’infrastructure réseau (par exemple, DNS ou TCP/IP), les services de téléphonie (si la messagerie unifiée est utilisée) et l’infrastructure de site (comme l’alimentation ou le refroidissement).
Pour que certains services puissent fonctionner à partir du centre de données défaillant, les certificats de serveur appropriés doivent être configurés. Certains services ne permettent pas l'instanciation (par exemple, POP3 et IMAP4) et ne permettent l'utilisation que d'un seul certificat. Dans ces cas, soit il doit s'agir d'un certificat SAN (autre nom d'objet) incluant plusieurs noms, soit les différents noms doivent être suffisamment similaires pour permettre le recours à un certificat générique (à condition que les stratégies de sécurité de l'organisation autorisent l'utilisation de certificats génériques).
Les services nécessaires doivent être définis dans le deuxième centre de données. Par exemple, si le premier centre de données a trois destinations SMTP différentes sur différents serveurs de transport, la configuration appropriée doit être définie dans le deuxième centre de données pour permettre à au moins un serveur de transport (sinon les trois) d’héberger la charge de travail.
La configuration de réseau nécessaire doit être en place pour prendre en charge le basculement de centre de données. Cette exigence peut signifier s’assurer que les configurations d’équilibrage de charge sont en place, que le DNS global est configuré et que la connexion Internet est activée avec le routage approprié configuré.
La stratégie d'activation des changements du DNS nécessaires au basculement de centre de données doit être comprise. Les changements DNS spécifiques, dont leurs paramètres de durée de vie, doivent être définis et documentés pour prendre en charge le SLA en vigueur.
Une stratégie de test de la solution doit aussi être établie et prise en compte dans l'accord SLA. La validation périodique du déploiement représente la seule manière de garantir que la qualité et la viabilité du déploiement ne se dégradent pas avec le temps. Après la validation du déploiement, nous vous recommandons de documenter explicitement la partie de la configuration affectant directement la réussite de la solution. En outre, nous vous recommandons aussi d'améliorer vos processus de gestion des changements liés à ces segments du déploiement.

Partager via