Site Resilience Configurations

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2007-10-29

Ces dernières années, davantage d'entreprises ont reconnu que la messagerie est essentielle pour leur réussite. Pour de nombreuses organisations, le système de messagerie doit faire 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 d'un matériel de sauvegarde dans un deuxième centre de données. Cela aboutit souvent 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 ?

• Quel est le contrat de niveau de service pour l'activation de centre de données auxiliaire ?

• 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 commencer à donner forme à votre solution de messagerie de résilience. 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 de messagerie nécessaires dans un centre de données de sauvegarde hébergeant le service de messagerie.

Cette rubrique fournit des détails sur plusieurs configurations de résilience de site pour la version de publication (RTM) de Microsoft Exchange Server 2007 et d'Exchange 2007 Service Pack 1 (SP1). Avant d'envisager des solutions de résilience de site, il est recommandé de se familiariser avec les éléments suivants :

• Cluster étendu   Également appelé cluster dispersé géographiquement, il s'agit d'une configuration dans laquelle les noeuds du cluster se trouvent dans plusieurs centres de données.

• Portabilité de base de données   Tâche administrative permettant de recibler des boîtes aux lettres sur un serveur différent en cas de déplacement de leur base de données hôte.

• Site Active Directory étendu   Site Active Directory contenant des ordinateurs de plusieurs centres de données (par exemple, un site Active Directory qui s'étend sur plusieurs emplacements physiques).

• Appartenance au site Active Directory   Membre d'un site Active Directory spécifique en fonction de l'adresse IP principale de l'ordinateur. La modification de l'adresse IP ou du site Active Directory contenant cette adresse IP modifie l'appartenance au site Active Directory de l'ordinateur.

• Centre de données de production   Centre de données hébergeant les serveurs actifs d'un service et de l'infrastructure qui y est associée.

• Centre de données de sauvegarde instantanée   Centre de données de sauvegarde immédiatement prêt à prendre possession du service et continuer sa fourniture. Aucune configuration particulière n'est requise pour exécuter le service à cet emplacement.

• Centre de données de sauvegarde à chaud   Centre de données de sauvegarde ayant des serveurs disponibles pour prendre possession du service pour le centre de données de production. L'activation du service dans ce centre de données requiert une intervention manuelle.

• Centre de données de sauvegarde à froid   Centre de données de sauvegarde ayant la capacité et potentiellement l'infrastructure nécessaires pour prendre possession du service. Un effort conséquent est requis pour rendre le service opérationnel dans le centre de données.

• Dédié   Serveurs désignés pour ne prendre en charge que les utilisateurs du centre de données principal.

• Non dédié   Serveurs qui prennent en charge les utilisateurs du centre de données principal, ainsi que des utilisateurs dans d'autres emplacements.

Des termes tels que production, chaud et dédié peuvent être combinés pour décrire un déploiement de résilience de site. Par exemple, un centre de données de production sauvegardé par un centre de données de sauvegarde dédié et largement configuré serait appelé Production:chaud (dédié).

Fonctionnalités prenant en charge la résilience de site

Plusieurs fonctionnalités d'Exchange 2007 permettent de créer une solution de résilience de site. Il s'agit des fonctionnalités suivantes :

• Clusters étendus qui peuvent être utilisés pour répliquer des données ou simplifier l'activation du centre de données de sauvegarde.

• Portabilité de base de données, qui peut être utilisée pour activer des données répliquées.

• Sites Active Directory étendus qui peuvent être utilisés pour prendre en charge des clusters étendus ou activer un centre de données de sauvegarde.

• Modification de l'appartenance au site Active Directory d'un ordinateur, qui peut être effectuée dans le cadre de l'activation d'un centre de données de sauvegarde.

• Sauvegardes sur bandes régulières combinées à un stockage hors site, qui peuvent être utilisées pour récupérer des données de boîte aux lettres dans le centre de données de sauvegarde.

En outre, des produits tiers offrent une réplication de données, qui peuvent être utilisés pour transférer des données vers un centre de données de sauvegarde. Ces produits peuvent être utilisés en association avec des serveurs autonomes, des clusters de récupération ou un cluster à copie unique (SCC) étendu. Dans ces configurations, les données du serveur ou cluster principal sont répliquées sur une seconde configuration de serveur ou de cluster dans un second centre de données. En cas de défaillance de site, le cluster ou le serveur du second centre de données est activé manuellement.

Dans Exchange 2007 SP1, une nouvelle fonctionnalité nommée réplication continue de secours (SCR) a été ajoutée ; elle est spécialement conçue pour les scénarios de résilience de site. Comme son nom l’indique, la SCR est conçue pour les scénarios utilisant ou activant l’utilisation des serveurs de récupération de secours. La SCR étend les fonctionnalités de réplication continue existantes d'Exchange 2007 RTM et permet de nouveaux scénarios de disponibilité pour les serveurs de boîtes aux lettres exécutant Exchange 2007 SP1. La SCR utilise la même technologie d’envoi et de relecture des journaux utilisée par la réplication continue locale (LCR) et la réplication continue en cluster (CCR) afin d'offrir des options et configurations de déploiement supplémentaires.

La SCR permet de séparer la haute disponibilité (constituée par la disponibilité des données et services) de la résilience de site. Par exemple, la SCR peut être combinée à la CCR pour répliquer des groupes de stockage localement dans un centre de données principal (à l'aide de la CCR pour la haute disponibilité) et à distance dans un centre de données secondaire ou de sauvegarde (à l'aide de la SCR pour la résilience de site). Le centre de données secondaire pourrait contenir un noeud passif dans un cluster avec basculement qui héberge les cibles de SCR. Ce type de cluster est appelé cluster de secours parce qu’il ne contient aucun serveur de boîtes aux lettres en cluster mais peut être configuré rapidement avec un serveur de boîtes aux lettres en cluster de remplacement dans un scénario de récupération. En cas de défaillance ou de perte du centre de données principal, les cibles de SCR hébergées dans ce cluster de secours peuvent être rapidement activées.

Pour plus d'informations sur la SCR, consultez la rubrique Réplication continue de secours.

Solutions pour l'obtention d'une résilience de site

Une organisation peut envisager de se doter de plusieurs solutions de résilience de site. Le reste de cette rubrique fournit des informations concernant les solutions de résilience de site suivantes :

• Production:froid (dédié)

• Production:chaud (dédié)

• Production:chaud (non dédié) avec deux sites Active Directory

• Production:production (non dédié) avec un site Active Directory unique

Les solutions décrites dans cette rubrique supposent une perte totale de l'infrastructure de messagerie en cas de défaillance du centre de données de production. Le centre de données de sauvegarde doit disposer d'une connectivité Internet et de tous les services nécessaires pour héberger Exchange. En outre, vos processus d'activation doivent être programmés à l'aide de scripts et testés régulièrement.

Production:froid (dédié)

La solution de résilience de site de messagerie la plus élémentaire est celle où l'organisation dispose de contrats portant sur du matériel et des équipements mais ne dispose pas d'un centre de données de sauvegarde actif. Toutes les données de boîte aux lettres sont régulièrement sauvegardées et déplacées hors site. Les données d'Active Directory sont gérées de la même manière. L'activation de la solution de résilience de site requiert l'acquisition et le déploiement de matériel. Pour raccourcir le temps d'interruption global, l'organisation peut disposer de contrats de fourniture rapide avec des fournisseurs de matériel pour les éléments matériels critiques.

Une variante de cette solution consiste à établir la relation avec un fournisseur de solution de récupération d'urgence capable de mettre le matériel à disposition à partir d'un pool qu'il maintient. Ce type de relation peut permettre la tenue à jour des données de sauvegarde chez le fournisseur pour raccourcir le temps de récupération. Un stockage dédié chez le fournisseur peut servir de cibles de réplication pour les données de boîte aux lettres et d'Active Directory.

Par souci de simplicité, il est probable que les configurations déployées finissent par ressembler à l'environnement de production ou au moins à une partie de celui-ci. Dans le cadre d'un processus de récupération tel que celui-ci, il est préférable de travailler avec une technologie et des dépendances aussi familières que possible.

Production:chaud (dédié)

Dans un modèle de récupération Production:chaud (dédié), le centre de données de production dispose d'un centre de données de sauvegarde désigné doté d'un équipement dédié. L'équipement dédié est utilisé lorsque le centre de données de production devient indisponible. Comme mentionné précédemment, le centre de données de sauvegarde n'est pas activé automatiquement. L'administrateur doit déclencher son activation manuellement. Une fois déclenchée, l'activation reconfigure l'équipement et l'infrastructure de sauvegarde dédiés pour fournir le service de messagerie. La figure suivante illustre une configuration Production:chaud (dédié).

Exemple de déploiement Production:chaud (dédié)

La figure précédente présente le centre de données de production (A) hébergeant des rôles serveur de transport Edge, serveur de transport Hub, serveur d'accès au client et serveur de boîtes aux lettres. Le centre de données de sauvegarde à chaud (B) dispose de serveurs de sauvegarde dédiés pour chaque rôle et pour Active Directory. La figure montre qu'une simple redondance est utilisée pour tous les rôles serveur à l'exception du rôle serveur de boîtes aux lettres. La redondance de boîte aux lettres est assurée par une configuration de cluster ou de serveur de secours associée à une solution de réplication appropriée.

Les solutions de redondance de boîte aux lettres possibles sont les suivantes :

• Réplication continue en cluster (CCR) dans une configuration de cluster étendu   La CCR utilise une technologie d'envoi des journaux pour créer et gérer une deuxième copie des données de boîte aux lettres. Ainsi, le cluster à deux noeuds de la CCR dispose d'un noeud dans chaque centre de données. Dans cette configuration, le service de cluster Windows requiert des sous-réseaux étendus entre deux emplacements. Le cluster étendu permet au serveur de boîtes aux lettres en cluster de basculer simplement en réinscrivant l'adresse IP qui lui a été affectée sur le noeud dans l'autre centre de données.

• Cluster à copie unique (SCC) avec réplication de partenaire synchrone   La réplication de partenaire permet au système d'avoir deux copies des données du serveur de boîtes aux lettres. Comme avec la CCR, un sous-réseau étendu est requis pour que le basculement de cluster réussisse.

• Cluster de secours avec réplication de partenaire   Les données de boîte aux lettres sont répliquées sur un deuxième cluster dans le centre de données de sauvegarde et le processus de récupération d'urgence du serveur est utilisé pour restaurer la service. La réplication peut être synchrone ou asynchrone. Aucun cluster n'est requis, ni aucun sous-réseau étendu.

• Serveur de secours avec réplication de partenaire   Les données de boîte aux lettres sont répliquées sur un deuxième serveur du centre de données de sauvegarde et le processus de portabilité de base de données ou de récupération d'urgence du serveur est utilisé pour restaurer la service. La réplication peut être synchrone ou asynchrone. Aucun cluster n'est requis, ni aucun sous-réseau étendu.

• Réplication continue locale (LCR) avec une deuxième copie hébergée dans un deuxième centre de données   Il ne s'agit pas d'une solution préconisée mais elle peut suffire pour certaines organisations. Dans cette configuration, un stockage iSCSI (Internet SCS) est utilisé pour stocker la copie passive des données. Les caractéristiques réseau de la connexion doivent permettre à la copie passive de rester raisonnablement cohérente par rapport à la copie active. Dans cette configuration, la LCR est indisponible pour une activation locale rapide parce qu'il est improbable que la latence du réseau et la bande passante prennent en charge l'accès au client.

La figure précédente illustre l'utilisation de l'une des solutions de cluster. Cela est dû au fait que le serveur de boîtes aux lettres est présenté sur le site Active Directory du centre de données de production. Dans une solution de cluster, les réseaux sur chaque noeud du cluster doivent figurer dans le même sous-réseau. Dans une solution sans cluster, un sous-réseau unique n'est pas requis mais recommandé. Si nécessaire, vous pouvez utiliser un autre sous-réseau.

En cas d'utilisation d'une solution de cluster, le cours normal des opérations serait le suivant :

1. Tous les messages Internet entrants transitent par le serveur de transport Edge dans le Centre de données A.

2. Tous les messages destinés à des serveurs de boîtes aux lettres dans le site Active Directory Redmond-Prod seraient traités par les serveurs de transport Hub de Redmond-Prod.

3. Les serveurs de boîtes aux lettres en cluster du site Active Directory Redmond-Prod seraient hébergés sur leurs noeuds configurés dans les noeuds du Centre de données A ou B. Les noeuds A et B font partie de Redmond-Prod et sont desservis par les serveurs de transport Hub et d'accès au client de Redmond-Prod.

4. Comme la CCR prend en charge deux noeuds, le deuxième doit se trouver dans le Centre de données B. Cela signifie qu'une défaillance de noeud actif dans le Centre de données A force au déplacement du serveur de boîtes aux lettres en cluster vers le Centre de données B ; dans ce cas, il est desservi par les serveurs de transport Hub et serveurs d'accès au client du Centre de données A.

5. Il est possible de configurer un cluster à copie unique avec trois serveurs et deux copies des données de façon à ce qu'une défaillance ait pour effet de maintenir le serveur de boîtes aux lettres en cluster dans le Centre de données A au lieu de basculer vers le Centre de données B. Toutefois, si la défaillance est en relation avec le stockage, il reste encore à activer le noeud passif dans le Centre de données B.

Les besoins en bande passante réseau entre les deux centres de données sont déterminés par trois facteurs :

• Besoins de latence du service de cluster   Le service de cluster requiert un temps de parcours circulaire maximum entre les noeuds de cluster d'une demi-seconde.

• Besoins de bande passante pour la réplication   La CCR requiert moins de bande passante que la plupart des solutions de réplication tierces car la réplication de CCR est basée sur l'envoi des journaux et pas sur la copie de base de données. La bande passante requise pour une solution de CCR dépend d'une série de facteurs qui sont généralement propres à chaque environnement et les besoins incluent de la bande passante pour ce qui suit :

  • l'envoi de journaux ;

  • les notifications du système de fichiers qui permettent au service de réplication Microsoft Exchange de savoir quand un nouveau fichier journal est prêt pour envoi ;

  • le trafic du serveur d'annuaire ;

  • le trafic client si les clients ne se trouvent pas dans le même emplacement physique que le serveur de boîtes aux lettres en cluster ;

  • le trafic d'interrogations du cluster ;

  • les mises à jour de base de données du cluster ;

  • toute autre application utilisant le réseau.

• Le serveur de transport Hub et le serveur d'accès au client requièrent une communication LAN entre eux et les serveurs de boîtes aux lettres qu'ils desservent   Pour les serveurs d'accès au client, cette exigence est plus importante parce qu'ils desservent des utilisateurs connectés. L'accès de boîte aux lettres à des contrôleurs de domaine peut déborder une connexion de réseau étendu (WAN) et sa latence peut affecter l'accès MAPI en mode connexion.

Les besoins de latence et de bande passante peuvent diminuer en cas de déploiement d'une solution sans cluster. Les besoins réseau pour la réplication subsistent et sont conséquents. En revanche, la majorité des autres besoins sont absents à moins que vous n'envisagiez d'activer le serveur de boîtes aux lettres de sauvegarde sans attendre une défaillance complète du Centre de données A.

En cas de défaillance du centre de données de production, l'administrateur peut restaurer le flux de messagerie et les services de messagerie en :

• déplaçant les serveurs de boîtes aux lettres vers le centre de données de sauvegarde du site Active Directory Redmond-DR ;

• déplaçant les serveurs de transport Hub, d'accès au client et d'annuaire vers le centre de données de sauvegarde du site Active Directory Redmond-Prod.

La deuxième option est la stratégie recommandée car elle minimise l'impact sur d'autres parties de l'environnement. Par exemple, les serveurs Exchange de toutes les succursales ne doivent pas modifier le routage perçu pour les messages en file d'attente. Ils se connectent simplement lorsque les serveurs appropriés sont opérationnels et disponibles.

L'activation du Centre de données B s'effectue selon les étapes de niveau supérieur suivantes :

1. L'infrastructure réseau est connectée.

2. L'infrastructure Active Directory est connectée.

3. Le serveur de boîtes aux lettres restant est connecté. Cette étape peut inclure d'obliger le cluster à se connecter à l'unique serveur restant.

4. Le site Active Directory Redmond-Prod est mis à jour à l'aide des adresses IP des serveurs de transport Hub, d'accès au client et d'annuaire de Redmond-DR.

5. L'enregistrement MX des domaines de l'organisation est mis à jour avec l'adresse IP du serveur de transport Edge du Centre de données B.

6. Le serveur d'accès au client déplacé est ajouté à la configuration d'équilibrage de charge (NLB) du réseau.

7. Le service de messagerie du Centre de données A est restauré dans le Centre de données B.

Lorsque le Centre de données A est disponible, il est possible de désactiver le Centre de données B en suivant les étapes de niveau supérieur suivantes :

1. Les serveurs individuels du Centre de données A sont connectés. Ils participeront à la fourniture du service, sauf si les services Exchange sont arrêtés ou désactivés manuellement. Lors de la migration en sens inverse, autorisez les serveurs du Centre de données A à se connecter.

2. Autorisez les serveurs de transport Hub du Centre de données B à purger leurs files d'attente, puis déconnectez-les.

3. Retirez les serveurs d'accès au client du Centre de données B de la configuration d'équilibrage de charge du réseau. Les clients se connectent alors via les serveurs du Centre de données A.

4. L'enregistrement MX des domaines de l'organisation est mis à jour avec l'adresse IP du serveur de transport Edge du Centre de données A.

5. Effectuez toutes les mises à jour d'infrastructure réseau requises.

6. Déplacez les serveurs de boîtes aux lettres en cluster vers le Centre de données A.

7. Mettez à jour le site Active Directory Redmond-DR à l'aide des adresses IP des serveurs déplacés durant l'activation.

8. Le service de messagerie du Centre de données A est restauré.

Comme pour toute solution de défaillance de site, l'activation du centre de données de production et de sauvegarde doit être programmée à l'aide de scripts et testée régulièrement. L'utilisation d'une solution de cluster pour le serveur de boîtes aux lettres réduit les temps d'activation pour le centre de données de sauvegarde. D'autres solutions peuvent nécessiter une réplication DNS (Domain Name System) et Active Directory, susceptible d'affecter le moment où le flux de messagerie reprend et où les clients peuvent accéder à leur boîte aux lettres.

La solution Production:chaud (dédié) présente l'avantage que les ordinateurs dédiés offrent un niveau de service prévisible.

Production:chaud (non dédié) avec deux sites Active Directory

Dans la configuration Production:chaud (dédié), les serveurs de transport Edge, de transport Hub et d'accès au client dans le centre de données de sauvegarde sont dédiés comme ressources de secours pour le Centre de données A. Cette configuration implique un investissement matériel conséquent qui reste partiellement inutilisé. Un modèle alternatif est présenté dans la figure suivante.

Exemple de déploiement Production:chaud (non dédié)

La solution Production:chaud (non dédié) requiert de l'administrateur qu'il déclenche manuellement l'activation du centre de données de sauvegarde. Une fois déclenché, le processus d'activation reconfigure certains éléments de l'équipement et de l'infrastructure du centre de données de sauvegarde afin de reprendre le service de messagerie pour les utilisateurs du Centre de données A.

Comme la solution Production:chaud (dédié), la solution Production:chaud (non dédié) implique deux sites Active Directory. En revanche, à la différence de la solution Production:chaud (dédié), les deux sites Active Directory s'étendent sur l'autre centre de données. Les ressources dédiées du centre de données de sauvegarde sont devenues des serveurs redondants pour une configuration de production différente dans le centre de données de sauvegarde. Cette approche rend ces ressources disponibles pour un usage normal, créant ainsi deux centres de données de production assurant une sauvegarde efficace l'un de l'autre.

Par exemple, comme l'illustre la figure Exemple de déploiement Production:chaud (non dédié), en cas de défaillance du Centre de données A, un serveur de transport Hub 4, un serveur d'accès au client 4 et un serveur de catalogue global 4 sont ajoutés au site Active Directory Redmond, qui, conjointement avec le Noeud B de Redmond, desservent les utilisateurs du Centre de données A en relation avec le service de messagerie. En cas de défaillance du site, les deux environnements de production fonctionnent à capacité et redondance réduites par rapport à leur état normal. En supposant que leur charge en cours puisse être prise en charge, cette configuration est acceptable. Par exemple, des messages Internet transitent par le serveur de transport Edge du Centre de données B. Pour prendre en charge une interruption de centre de données prolongée, l'entreprise peut avoir conclu des contrats avec un fournisseur qui lui fournit rapidement du matériel supplémentaire à la demande. Le matériel ainsi ajouté permet alors de restaurer la redondance ou d'augmenter la capacité.

L'opération normale de déploiement des sites Active Directory de Redmond et de Dublin serait identique car ils optent tous deux pour la solution Production:chaud (dédié). De même, la bande passante réseau entre les deux emplacements serait déterminée par les mêmes facteurs, sauf que les serveurs de Redmond et Dublin doivent être pris en charge simultanément.

L'activation du centre de données de sauvegarde peut se faire en :

• déplaçant le noeud actif et le serveur de boîtes aux lettres en cluster vers le site Active Directory du centre de données opérationnel ;

• déplaçant les serveurs de transport Hub, d'accès au client et d'annuaire du centre de données de sauvegarde vers le site Active Directory du centre de données défaillant.

La solution d'activation recommandée consiste à déplacer les serveurs de transport Hub et d'accès au client vers le site Active Directory du centre de données défaillant. Cette solution constitue le mode d'activation le plus simple et le plus rapide.

Dans cette solution, la récupération du centre de données A s'accomplit à l'aide des étapes de niveau supérieur suivantes :

1. L'infrastructure réseau est connectée. Il est possible qu'aucune modification d'infrastructure réseau ne soit requise parce que le Centre de données B reçoit déjà des messages Internet.

2. L'infrastructure Active Directory du Centre de données A est connectée (Site Active Directory Redmond).

3. Le serveur de boîtes aux lettres restant est connecté. Cette étape peut inclure d'obliger le cluster à se connecter à l'unique serveur restant.

4. Le site Active Directory Redmond est mis à jour à l'aide des adresses IP des serveurs de transport Hub 4, d'accès au client 4 et de catalogue global 4.

5. Le serveur d'accès au client 3 est ajouté à la configuration d'équilibrage de charge du réseau pour Redmond.

6. Le service de messagerie du Centre de données A est restauré.

Lorsque le Centre de données A est disponible, il est possible de restaurer sa configuration normale en suivant les étapes de niveau supérieur suivantes :

1. Les serveurs individuels du Centre de données A sont connectés. Ils participeront à la fourniture du service, sauf si les services Exchange sont arrêtés ou désactivés manuellement. Lors de la migration en sens inverse, autorisez les serveurs du Centre de données A à se connecter.

2. Autorisez le serveur de transport Hub 4 à purger ses files d'attente, puis déconnectez-le.

3. Retirez le serveur d'accès au client 4 de la configuration d'équilibrage de charge du réseau. Les clients peuvent encore se connecter aux serveurs du Centre de données A.

4. Effectuez toutes les mises à jour d'infrastructure réseau requises.

5. Déplacez le serveur de boîtes aux lettres en cluster vers le Centre de données A.

6. Mettez à jour le site Active Directory Dublin à l'aide des adresses IP des serveurs déplacés durant l'activation.

7. La condition d'origine des deux centres de données est restaurée.

Comme pour toute solution de défaillance de site, l'activation du centre de données de production et de sauvegarde doit être programmée à l'aide de scripts et testée régulièrement. L'utilisation d'une solution de cluster pour le serveur de boîtes aux lettres réduit les temps d'activation pour le centre de données de sauvegarde. D'autres solutions de boîte aux lettres peuvent nécessiter une réplication DNS et Active Directory, susceptible d'affecter le moment où le flux de messagerie reprend et où les clients peuvent accéder à leur boîte aux lettres.

Cette solution permet de consacrer les serveurs utilisés pour la résilience de site au fonctionnement normal. Cette solution peut réduire le coût de la solution de résilience de site mais avec le risque de ne pas pouvoir soutenir une charge système totale en cas de besoin. Par exemple, si la charge des serveurs de transport Hub du Centre de données B atteint une utilisation de 80 pour cent de la capacité, l'activation du centre de données de sauvegarde pour A entraîne un dépassement de la capacité de transport Hub. Avec cette solution, les administrateurs doivent suivre attentivement l'utilisation du système dans le temps pour s'assurer que la solution reste viable. Si la charge augmente, vous devez acquérir et déployer du matériel supplémentaire.

Production:production (non dédié) avec un seul site Active Directory

Les organisations qui ont besoin d'une solution capable de prendre en charge une activation automatique d'un site de sauvegarde doivent déployer une solution Production:Production (non dédié). Cette solution déploie des serveurs redondants dans un site Active Directory unique s'étendant sur deux centres de données, comme illustré dans la figure suivante.

Exemple de déploiement Production:production (non dédié)

Cette solution déploie les ressources des deux centres de données dans un site Active Directory unique. Toute ressource du site peut être utilisée pour servir quasiment tout demande. Par exemple, un serveur de transport Edge du Centre de données A peut utiliser un serveur de transport Hub du Centre de données B pour remettre un message à un utilisateur dont la boîte aux lettres se trouve sur un serveur de boîtes aux lettres en cluster hébergé par le Centre de données A. De même, par défaut, il n'y a pas de localité de référence pour le trafic Active Directory. C'est pourquoi cette solution n'est pas recommandée.

L'activation du centre de données de sauvegarde est similaire à la récupération de plusieurs défaillances de serveur. La récupération de l'activation requiert simplement la restauration du service sur les serveurs défaillants. Comme pour les solutions non dédiées présentées précédemment, une mauvaise gestion de la capacité peut avoir pour effet que la charge dépasse la capacité du service en cas de défaillance d'un centre de données. Les administrateurs doivent s'assurer que la solution peut prendre en charge la charge prévue en cas de défaillance d'un centre de données. L'absence de gestion de capacité appropriée peut entraîner une défaillance complète du service de messagerie en cas de défaillance d'un seul centre de données.