Disponibilité élevée
S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Dernière rubrique modifiée : 2009-04-01
Cette zone de contenu à haute disponibilité inclut des rubriques que vous pouvez utiliser pour concevoir, créer et utiliser un système de messagerie à haute disponibilité basé sur la version de publication (RTM) de Microsoft Exchange Server 2007 et Exchange 2007 Service Pack 1 (SP1). Cette zone inclut la documentation suivante :
Installation déléguée du serveur de boîtes aux lettres en cluster
Mise à niveau des serveurs de boîtes aux lettres en cluster vers Exchange 2007 SP1 ou SP2
Appliquer les correctifs cumulatifs Exchange 2007 aux serveurs de boîtes aux lettres en cluster
Désinstallation des serveurs de boîtes aux lettres en cluster
Il est recommandé de consulter la documentation applicable avant de concevoir ou de déployer une solution de messagerie à haute disponibilité basée sur Exchange 2007 SP1.
La documentation de cette zone a été mise à jour afin d'inclure les dernières recommandations et meilleurs pratiques relatives au déploiement d'Exchange 2007 SP1 sous Windows Server 2008 et Windows Server 2003 Service Pack 2 (SP2).
Haute disponibilité pour Exchange Server 2007
Si la configuration de disponibilité minimale varie parmi les organisations, chaque organisation souhaite atteindre un niveau élevé de disponibilité. Les organisations pour lesquelles la messagerie est critique choisissent souvent de concevoir un système de messagerie hautement disponible afin d'atteindre cette disponibilité.
Exchange 2007 RTM et Exchange 2007 SP1 incluent les fonctionnalités intégrées suivantes qui peuvent offrir une récupération rapide, une haute disponibilité et une tolérance de panne de site pour les serveurs de boîtes aux lettres Exchange 2007 :
Réplication continue locale (LCR) La LCR est une solution de serveur unique qui utilise une technologie intégrée d'envoi asynchrone de journaux pour créer et conserver une copie d'un groupe de stockage sur un deuxième ensemble de disques qui sont connectés au même serveur que le groupe de stockage de production. La LCR permet l'envoi de journaux, la relecture de journal et un basculement manuel rapide vers une copie secondaire des données.
Réplication continue en cluster (CCR) La réplication continue en cluster qui est une solution de cluster de basculement de stockage non partagé, est l'un des deux types de déploiements de serveur de boîtes aux lettres en cluster disponibles dans Exchange 2007. La réplication continue en cluster est une solution en cluster (appelée environnement de réplication continue en cluster) qui utilise une technologie d'envoi de journaux asynchrone intégrée pour créer et conserver une copie de chaque groupe de stockage sur un second serveur dans un cluster de basculement. La réplication continue en cluster est conçue pour être une solution à un ou deux centres de données, fournissant une haute disponibilité et une tolérance de panne de site. La réplication continue en cluster diffère considérablement du clustering dans les versions précédentes d'Exchange Server. Pour plus d'informations sur certaines différences, consultez les rubriques Ressources de cluster Exchange pour les serveurs de boîtes aux lettres en cluster et Comportement de récupération de réplication continue en cluster.
Réplication continue de secours (SCR) La SCR est une nouvelle fonctionnalité introduite dans Exchange 2007 SP1. 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 et permet de nouveaux scénarios de disponibilité pour les serveurs de boîtes aux lettres Exchange 2007. La SCR utilise la technologie d'envoi et de relecture des journaux utilisée par la réplication continue locale et la réplication continue en cluster afin d'offrir des options et configurations de déploiement supplémentaires en fournissant à l'administrateur la possibilité de créer des copies de groupe de stockage supplémentaires. La SCR permet de répliquer des données de serveurs de boîtes aux lettres autonomes et de serveurs de boîtes aux lettres en cluster.
Clusters à copie unique (SCC) Un SCC qui est une solution de cluster de basculement de stockage partagé, est l'un des deux types de déploiements de serveur de boîtes aux lettres en cluster disponibles dans Exchange 2007. Un cluster à copie unique est une solution de cluster qui utilise une copie unique d'un groupe de stockage pour le stockage qui est partagé entre les noeuds du cluster. Un cluster à copie unique est similaire au clustering dans les versions précédentes d'Exchange Server ; toutefois, outre de nombreuses améliorations, il apporte également des modifications importantes. Pour plus d'informations sur ces modifications, consultez les rubriques Modèle de ressources de cluster à copie unique et Comportement de récupération de cluster à copie unique.
Pour plus de détails sur d'autres fonctions et fonctionnalités de disponibilité élevée introduites dans SP1, consultez la rubrique Nouvelles fonctionnalités de haute disponibilité dans Exchange 2007 SP1.
Haute disponibilité pour les serveurs de boîtes aux lettres
La haute disponibilité pour les serveurs de boîtes aux lettres se traduit de deux façons : disponibilité de service et disponibilité de données. La disponibilité de service est assurée par l'utilisation d'un cluster de basculement Windows Server. La disponibilité de données est assurée par une fonctionnalité intégrée nommée réplication continue.
Serveurs de boîtes aux lettres en cluster
Les solutions de CCR et SCC sont déployées dans un cluster de basculement Windows Server. Seul le rôle serveur de boîtes aux lettres peut être installé dans un cluster avec basculement. Aucun autre rôle ne peut être installé dans un cluster avec basculement. Un serveur de boîtes aux lettres déployé dans un cluster de basculement est appelé serveur de boîtes aux lettres en cluster. Les serveurs de boîtes aux lettres en cluster exécutés dans un environnement de CCR sont très différents des serveurs de boîtes aux lettres en cluster exécutés dans un environnement de SCC. En outre, les serveurs de boîtes aux lettres en cluster dans Exchange 2007 RTM et Exchange 2007 SP1 sont très différents des serveurs de boîtes aux lettres en cluster dans les versions précédentes de Microsoft Exchange.
Vous pouvez utiliser Get-MailboxServer <CMSName> | fl Name, ClusteredStorageType dans l'environnement de ligne de commande Exchange Management Shell pour déterminer si un serveur de boîtes en lettres en cluster est hébergé dans un environnement de CCR ou un cluster à copie unique. La valeur NonShared indique que le serveur de boîtes aux lettres est dans un environnement de CCR et la valeur Shared indique que le serveur de boîtes aux lettres en cluster est dans un cluster à copie unique. La valeur Disabled indique que le serveur de boîtes aux lettres est un serveur autonome.
Vous pouvez également consulter Active Directory pour déterminer si un serveur de boîtes en lettres en cluster est hébergé dans un environnement de CCR ou un cluster à copie unique, en examinant la valeur de l'attribut msExchClusterStorageType de l'objet serveur de boîtes aux lettres. La valeur 1 pour l'attribut msExchClusterStorageType indique que le serveur de boîtes aux lettres en cluster est hébergé dans un environnement de CCR et la valeur 2 indique que le serveur de boîtes aux lettres en cluster est dans un cluster à copie unique. La valeur <Not Set> indique que le serveur de boîtes aux lettres est un serveur autonome.
Environnements de réplication continue en cluster
Exchange 2007 RTM et Exchange 2007 SP1 prennent en charge au maximum deux noeuds sur lesquels le rôle serveur de boîtes aux lettres est installé (un noeud actif et un noeud passif) dans un environnement de réplication continue en cluster. Un cluster de basculement à trois noeuds qui utilise un noeud votant et un quorum jeu de noeud majoritaire traditionnel est également pris en charge, mais il ne s'agit pas du modèle de cluster favori. Toutefois, il est recommandé à la plupart des clients de déployer des environnements de réplication continue en cluster n'utilisant que deux noeuds et soit un quorum de noeuds et de partages de fichiers majoritaire (Windows Server 2008), soit un quorum jeu de noeuds majoritaire avec témoin de partages de fichiers (Windows Server 2003). Ainsi, la documentation sur la réplication continue en cluster est orientée vers des clusters de basculement à deux noeuds qui utilisent un de ces modèles de quorum.
Notes
Un cluster de basculement à noeud unique déployé dans un environnement de réplication continue en cluster est également pris en charge mais n'est pas considéré comme une solution à haute disponibilité parce qu'aucune redondance n'existe dans le cluster. En cas d'utilisation d'un cluster de basculement à noeud unique déployé dans un environnement de réplication continue en cluster, vous devez utiliser un quorum jeu de noeud majoritaire (traditionnel, sans témoin de partage de fichiers).
Clusters à copie unique
Exchange 2007 RTM et Exchange 2007 SP1 prennent en charge un maximum de huit noeuds dans un cluster à copie unique. Les combinaisons valides de SCC Exchange 2007 SP1 sur des clusters de basculement Windows Server sont les suivantes :
7 actifs / 1 passif
6 actifs / 1 ou 2 passifs
5 actifs / 1, 2 ou 3 passifs
4 actifs / 1, 2, 3 ou 4 passifs
3 actifs / 1, 2, 3, 4 ou 5 passifs
2 actifs / 1, 2, 3, 4, 5 ou 6 passifs
1 actif / 0, 1, 2, 3, 4, 5, 6 ou 7 passifs
Notes
La version 64 bits de Windows Server 2008 prend en charge jusqu'à 16 noeuds dans un seul cluster de basculement ; en revanche, Exchange 2007 prend en charge un maximum de 8 noeuds dans le cluster. Le cluster de basculement peut encore contenir jusqu'à 16 noeuds mais Exchange 2007 doit être installé sur au maximum 8 noeuds dans le cluster de basculement.
Généralement, il ne faut pas plus d'un noeud passif dans le cluster pour chaque noeud actif. Par conséquent, une configuration d'un noeud actif et d'un noeud passif est préférable à des configurations d'un noeud actif et de plusieurs noeuds passifs. En cas d'utilisation d'un cluster à copie unique à noeud unique, vous pouvez utiliser un quorum de stockage partagé ou un quorum jeu de noeud majoritaire (traditionnel, sans témoin de partage de fichiers). Bien que les clusters à copie unique à noeud unique soient pris en charge, il ne sont pas considérés comme une solution à haute disponibilité parce qu'aucune redondance n'existe dans le cluster.
Cluster étendu
Un cluster étendu, également appelé cluster dispersé géographiquement, est un cluster de basculement étendu dans plusieurs centres de données physiques. Les clusters étendus peuvent être utilisés dans le cadre d'un dispositif de résilience de site pour votre organisation Exchange. Comme la CCR n'utilise pas de stockage partagé, elle peut facilement être déployée dans un cluster dispersé géographiquement, y compris un cluster étendu à plusieurs sous-réseaux sous Windows Server 2008. Un cluster à copie unique est également pris en charge dans un cluster étendu. Un cluster à copie unique étendu nécessite toutefois une technologie de réplication synchrone tierce. Pour plus d'informations sur les clusters étendus, consultez la rubrique Site Resilience Configurations.
Cluster de secours
Un autre type de cluster pris en charge par Exchange 2007 et Exchange 2007 SP1 est appelée cluster de secours. Un cluster de secours est un cluster de basculement Windows Server ne contenant pas de serveur de boîtes aux lettres en cluster, mais qui peut être rapidement configuré avec un serveur de boîtes aux lettres en cluster de remplacement en cas d'incident, d'un autre échec du cluster de basculement de production ou d'un autre scénario de récupération.
Réplication continue
La réplication continue, également appelée envoi de journaux, est le processus d'automatisation de la réplication des fichiers journaux de transactions fermés à partir d'un groupe de stockage de production sur une copie de ce groupe de stockage située sur un deuxième ensemble de disques sur l'ordinateur local ou sur un autre serveur. Après copie vers le deuxième emplacement, les fichiers journaux sont relus dans la copie de la base de données, maintenant ainsi la synchronisation des groupes de stockage avec un léger décalage de temps.
La réplication continue est disponible sous deux formes dans Exchange 2007 RTM (réplication continue locale et réplication continue en cluster) et trois formes dans Exchange 2007 SP1 (réplication continue locale, réplication continue en cluster et réplication continue de secours).
Haute disponibilité pour d'autres rôles serveur
La haute disponibilité pour les rôles serveur de transport Hub, de transport Edge, d'accès au client et de messagerie unifiée est atteinte par une combinaison de redondance de serveur, d'équilibrage de la charge réseau (NLB), d'équilibrage de charge matérielle, de tourniquet DNS (Domain Name System), ainsi qu'une gestion de serveur, de service et d'infrastructure proactive. En général, vous pouvez obtenir une haute disponibilité pour les rôles serveur d'accès au client, serveur de transport Hub, serveur de transport Edge et serveur de messagerie unifiée à l'aide des stratégies et technologies suivantes :
Transport Edge Vous pouvez déployer plusieurs serveurs de transport Edge et utiliser plusieurs enregistrements DNS MX (Mail Exchanger) pour assurer l'équilibrage de la charge sur ces serveurs. Vous pouvez également utiliser l'équilibrage de la charge réseau pour équilibrer la charge et assurer une disponibilité élevée sur les serveurs de transport Edge.
Accès au client Vous pouvez utiliser l'équilibrage de la charge réseau ou un autre périphérique matériel d'équilibrage de charge réseau tiers pour assurer une disponibilité élevée du serveur d'accès au client. Pour plus d'informations sur l'équilibrage de la charge réseau, consultez la rubrique Windows Server TechCenter.
Transport Hub Vous pouvez déployer plusieurs serveurs de transport Hub pour assurer une disponibilité élevée du transport interne. La tolérance de panne a été conçue dans le rôle serveur de transport Hub comme suit :
De serveur de transport Hub à serveur de transport Hub (intra-org.) La communication de serveur de transport Hub à serveur de transport Hub à l'intérieur d'une organisation équilibre automatiquement la charge entre les serveurs de transport Hub disponibles dans le site du service d'annuaire Active Directory cible.
De serveur de boîtes aux lettres à serveur de transport Hub (intra-site Active Directory) Le service de dépôt du courrier Microsoft Exchange sur des serveurs de boîtes aux lettres équilibre automatiquement la charge entre tous les serveurs de transport Hub disponibles dans le même site Active Directory.
De serveur de messagerie unifiée à serveur de transport Hub Le serveur de messagerie unifiée équilibre automatiquement la charge des connexions entre tous les serveurs de transport Hub disponibles dans le même site Active Directory.
De serveur de transport Edge à serveur de transport Hub Le serveur de transport Edge équilibre automatiquement la charge du trafic SMTP (Simple Mail Transfer Protocol) entrant sur tous les serveurs de transport Hub dans le site Active Directory auquel le serveur de transport Edge est abonné.
Pour assurer une redondance supplémentaire (par exemple, d'applications nécessitant un relais SMTP), vous pouvez créer un enregistrement DNS (par exemple, relais.société.com), affecter une adresse IP et utiliser un programme d'équilibrage de la charge matérielle pour rediriger cette adresse IP vers plusieurs serveurs de transport Hub. Dans Exchange 2007 SP1, vous pouvez également utiliser l'équilibrage de la charge du réseau pour les connecteurs clients sur les serveurs de transport Hub. En cas d'utilisation d'un programme d'équilibrage de la charge matérielle, vous devez vérifier qu'aucun trafic Exchange 2007 intra-org. ne croisera le programme d'équilibrage de la charge matérielle car le trafic intra-org. utilise des algorithmes d'équilibrage de charge intégrés (comme décrit précédemment). Pour plus d'informations sur l'équilibrage de charge et les serveurs de transport, consultez les rubriques Options de déploiement pour les serveurs de transport Hub et Équilibrage de charge et tolérance de panne pour les serveurs de transport.
Messagerie unifiée Les déploiements de messagerie unifiée peuvent être plus résistants en déployant plusieurs serveurs de messagerie unifiée lorsqu'il y en a deux ou plusieurs dans un seul plan de commutation des appels. Les passerelles voix sur IP (VoIP) prises en charge par la messagerie unifiée peuvent être configurées pour router des appels vers des serveurs de messagerie unifiée à la manière de tourniquets. En outre, ces passerelles peuvent récupérer la liste des serveurs d'un plan de numérotation à partir de DNS. Dans tous les cas, les passerelles voix sur IP passent un appel sur un serveur de messagerie unifiée et si l'appel n'est pas accepté, l'appel est passé sur un autre serveur, fournissant la redondance à l'heure d'établissement de l'appel.
Disponibilité élevée avec redondance de données et de service
Le principe de base de l'architecture de disponibilité élevée Exchange 2007 consiste à introduire la redondance dans le déploiement. Un échec est récupéré en utilisant les ressources informatiques restantes pour prendre en charge les services Exchange. Une fois les échecs réparés, les ressources informatiques sont de nouveau disponibles pour Exchange et ses clients. Dans ce contexte, les ressources informatiques peuvent être des ordinateurs ou une solution de stockage des boîtes aux lettres ou autres données Exchange.
La redondance peut être introduite dans un centre de données unique. Cette approche est généralement effectuée pour prévenir un échec de serveur individuel. Par exemple, l'introduction d'un deuxième serveur de transport Hub dans le centre de données principal de votre organisation active la poursuite du flux de messagerie si l'un des deux serveurs échoue.
De la même façon, la redondance peut être introduite dans un deuxième centre de données. Deux configurations de centre de données activent la continuité du service après une défaillance de centre de données. Si un serveur de transport Hub supplémentaire est introduit dans un deuxième centre de données, le deuxième serveur de transport Hub peut traiter le flux de messagerie lorsque le serveur de transport Hub est défaillant ou lorsque le centre de données de production n'est pas disponible. Si trois serveurs de transport Hub sont déployés, deux d'entre eux peuvent se trouver dans le centre de données de production et le troisième dans le centre de données secondaire.
Le point crucial du déploiement est que la redondance peut empêcher les pannes qui, sans elle, engendreraient une série de défaillances. La manière dont les ordinateurs et les services redondants sont déployés détermine les défaillances qui peuvent se produire sans affecter la disponibilité des données ou du service. Les organisations doivent comprendre leurs besoins, puis s'intéresser aux problèmes de fonctionnement pour sélectionner la solution adaptée. Par exemple, il se peut qu'une organisation veuille activer un centre de données de sauvegarde seulement 20 minutes après un échec du centre de données de production. Dans ce cas, l'organisation doit disposer des processus nécessaires en place pour valider régulièrement le fonctionnement et l'activation du centre de données de sauvegarde. Une autre organisation peut décider que la validation continue du centre de données de sauvegarde est essentielle pour sa réussite ; impliquant une configuration de déploiement différente pour cette organisation.