Microsoft Exchange Server 2010 : Stratégies de disponibilité élevée
Les stratégies que Microsoft propose pour la création de boîtes aux lettres Microsoft Exchange hautement disponibles ont évolué au fil des ans.
Extrait de le « Échange 2010 – A Practical Approach, » publié par Red Gate Books (2009).
Jaap Wesselius
Depuis Exchange Server 5.5, Microsoft a proposé le Clustering Windows en option pour la création d'un environnement hautement disponible de boîte aux lettres Exchange. Il existe deux nœuds de serveur dans un environnement de cluster de stockage partagé typique. Tous les deux exécutent Exchange Server et les serveurs sont connectés à une solution de stockage partagé.
Dans les premiers jours, ce stockage partagé a été construit sur un bus SCSI partagé. Par la suite il généralement utilisé des réseaux de zone de stockage (San) avec une connexion réseau Fibre Channel ou iSCSI. La partie importante est le stockage partagé où se trouvaient les bases de données Exchange Server.
Nœud qu'un seul serveur est « propriétaire » des données partagées. Ce nœud fournit le service à la clientèle. Il est également connu sous le nom du nœud actif. L'autre nœud n'est pas en mesure d'accéder à ces données et est donc le nœud passif. Un réseau privé entre les nœuds de deux serveur est utilisé pour les communications intra-cluster comme un signal de pulsation. Cela permet les deux nœuds de déterminer l'état du cluster et de s'assurer que les autres nœuds sont encore en vie.
En plus de deux nœuds, il crée un « serveur virtuel Exchange » comme une ressource de cluster. Cela n'a rien à voir avec les machines virtuelles. Il s'agit de la ressource à laquelle les clients Outlook se connecteront afin d'accéder à leurs boîtes aux lettres. Lorsque le nœud actif échoue, le nœud passif reprend le serveur virtuel Exchange, qui continue de s'exécuter. Bien que les utilisateurs remarqueront un court temps d'arrêt durant le basculement, c'est une expérience transparente dans le cas contraire. Aucune action n'est requise de l'utilisateur.
Bien que cette solution offre la redondance, il est encore un point de défaillance unique — la base de données partagée du serveur Exchange. Dans un environnement typique, cette base de données est stockée sur un réseau SAN. Par sa nature même, un SAN est un environnement hautement disponible. Quand quelque chose arrive à la base de données, telles qu'un problème de logique, la base de données est indisponible pour les deux nœuds. Il en résulte une indisponibilité totale.
Réplication de base de données Exchange
Avec Exchange Server 2007, Microsoft offre une nouvelle solution pour la création d'environnements Exchange hautement disponibles : réplication de base de données. La réplication de base de données crée une copie d'une base de données, résultant en redondance de base de données. Cette technologie était disponible en trois saveurs :
- **Réplication continue locale (LCR) :**Cette approche crée une copie de la base de données sur le même serveur.
- **Réplication continue en cluster (CCR) :**Cette opération crée une copie de la base de données sur un autre nœud dans un cluster de basculement Windows (il ne peut exister deux nœuds dans un cluster CCR).
- **En attente de réplication continue (SCR) :**Ceci est venu avec Exchange Server 2007 SP1. Il crée une copie d'une base de données sur un autre serveur Exchange (pas nécessairement dans le cluster). Ce n'est pas conçu pour une haute disponibilité (HA) ; C'est davantage pour la reprise après sinistre.
C'est comment la réplication de base de données fonctionne dans un environnement en cluster CCR. Exchange Server 2007 est installé sur un cluster de basculement Windows Server 2008 ou de Windows Server 2003. Il n'y a pas de stockage partagé en usage au sein du cluster. Chaque nœud possède son propre espace de stockage. Cela peut être soit sur un réseau SAN (Fibre Channel ou iSCSI) ou stockage en attachement direct (DAS) — des disques physiques locaux.
Le nœud actif dans les demandes de client de services de cluster et Exchange Server utilise la technologie standard de base de données avec une base de données, fichiers journaux et un fichier de contrôle. Lorsque Exchange Server est terminé avec un fichier journal, il est immédiatement envoyé au nœud passif du cluster. Cela peut être via une connexion normale ou via un réseau de réplication dédié.
Le nœud passif reçoit le fichier journal et il vérifie les erreurs. S'il ne trouve aucun, les données contenues dans le fichier journal sont relayés vers la copie passive de la base de données. Il s'agit d'un processus asynchrone, ce qui signifie que la copie passive est toujours un couple de fichiers journaux derrière la copie active, donc information est « manquante » dans la copie passive.
Dans ce contexte, tous les messages, même les messages internes — sont envoyées via un serveur de Transport Hub. Le serveur de Transport Hub effectue le suivi de ces messages dans un environnement de CCR. Il peut donc envoyer manquante (que le nœud passif demande effectivement) informations sur la copie passive du cluster dans le cas d'un basculement de cluster. C'est ce qu'on appelle « La benne de Transport » dans un serveur de Transport Hub.
Ce type de réplication fonctionne très bien. La réplication CCR est tout à fait fiable, mais il y a deux inconvénients potentiels :
- Un environnement de CCR d'Exchange Server 2007 s'exécute sur Windows Server 2003 ou Windows Server 2008 gestion de clusters. Pour beaucoup, d'ajouter trop de complexité de l'environnement.
- Windows Server 2003 en cluster dans un environnement à plusieurs sous-réseaux est presque impossible, même si cela s'est amélioré (mais n'est toujours pas parfait) dans Windows Server 2008 failover clustering.
- Résilience de site n'est pas sans faille.
- Mise en cluster CCR n'est possible dans un environnement à deux nœuds.
- Les trois types de réplication (LCR, CCR et SCR) sont gérées différemment.
Pour surmonter ces problèmes, Microsoft a considérablement amélioré la technologie de réplication. Il a également réduit la charge administrative. Il a obtenu cela en masquant complètement les composants de cluster derrière la mise en œuvre d'Exchange Server 2010. Les composants de cluster sont toujours là, mais l'administration est faite entièrement avec la Console de gestion Exchange (EMC) ou le Exchange Management Shell (EMS).
Réplication continue DAG
Dans Exchange Server 2010, Microsoft a introduit le concept d'un groupe de disponibilité de base de données (DAG). Il s'agit d'une unité logique de serveurs de boîtes aux lettres Exchange Server 2010. Tous les serveurs de boîtes aux lettres d'un DAG peut répliquer des bases de données les unes aux autres. Un DAG unique peut contenir jusqu'à 16 serveurs de boîtes aux lettres et jusqu'à 16 copies d'une base de données.
L'idée de plusieurs copies de base de données dans une organisation Exchange est appelée Exchange Mobility. Il y a une base de données sur plusieurs serveurs, chaque instance de qui est identique à 100 % et a donc le même GUID.
Avec un DAG en place, les clients se connectent à une base de données active. C'est la base de données où toutes les données a été stockée initialement. Nouveaux messages SMTP, soit à partir de l'extérieur ou à l'intérieur de l'organisation, sont tout d'abord stockées dans cette base de données.
Lorsque le serveur Exchange a fini de traiter les informations contenues dans le fichier journal de la base de données, il réplique les fichiers vers d'autres serveurs. Vous pouvez assigner les serveurs qui reçoivent une copie de la base de données. Le fichier journal est inspecté à la réception et si tout va bien, les informations contenues dans le fichier journal sont supprimés dans la copie locale de la base de données.
Dans Exchange Server 2010, tous les clients se connectent au serveur d'accès Client, y compris tous les clients de Messaging Application Programming Interface ou MAPI, tel que Microsoft Outlook. Les clients Outlook pris en charge dans Exchange Server 2010 incluent Outlook 2003, Outlook 2007 et Outlook 2010.
Si le client Outlook se connecte au serveur d'accès Client, qui se connecte ensuite à la boîte aux lettres dans la copie active de la base de données. Malheureusement, cela vaut uniquement pour les bases de données de boîtes aux lettres. Lorsqu'un client Outlook doit accéder à une base de données de dossiers publics, le client accède toujours au serveur de boîtes aux lettres directement.
Lors de la copie active d'une base de données ou le serveur tombe en panne, l'un des exemplaires de la base de données passives devient actif. Vous pouvez configurer l'ordre de basculement au cours du processus de configuration de copie de base de données. Le serveur d'accès Client avis le basculement automatiquement et commence à utiliser la nouvelle base de données active. Parce que le client Outlook est connecté au serveur d'accès au Client et non pas directement à la base de données, un basculement de la base de données est entièrement transparent. Messages tels que "la connexion au serveur a été perdue", et « la connexion au serveur est restaurée, » tout simplement ne s'affichent plus.
Lorsque vous créez un environnement de serveur de boîtes aux lettres hautement disponibles dans un DAG, il est inutile de créer un cluster de basculement à l'avance. Vous pouvez ajouter des serveurs de boîtes aux lettres supplémentaires pour le DAG à la volée. Toutefois, pour le DAG fonctionne correctement, vous utilisez toujours certains composants de clustering avec basculement. Ceux-ci sont installés au cours de la configuration du DAG. Vous faites toute la gestion exemplaire DAG et base de données via la console ou les EMS. Vous n'avez plus à utiliser le gestionnaire de Cluster Windows.
DAG avec des copies de base de données est la seule technologie HA qu'utilise Exchange Server 2010. Les technologies plus anciennes telles que le SCR, CCR et SCR ne sont plus disponibles. Le cluster exemplaire unique traditionnels avec stockage partagé n'est plus supporté, soit.
Configuration d'un DAG n'est donc plus limitée à un serveur qui détient seulement le rôle serveur de boîtes aux lettres. Il est possible de créer une situation de deux serveurs de Transport Hub, accès au Client et rôles serveur de boîtes aux lettres sur les deux serveurs, puis créez un DAG et configurer les copies de base de données.
Toutefois, il n'est pas une configuration HA pour les serveurs d'accès au Client ou de Transport Hub à moins que vous avez mis les équilibreurs de charge en face d'eux. Vous ne pouvez pas utiliser la valeur par défaut Windows Network Load Balancing en combinaison avec les composants gestion de clusters avec basculement. Néanmoins, c'est une grande amélioration pour les petits déploiements d'Exchange Server 2010 où HA est toujours requis.
.jpg)
Jaap Wesselius est le fondateur de DM Consultants, une société avec un fort accent sur les solutions de messagerie et de collaboration. Après avoir travaillé chez Microsoft depuis huit ans, Wesselius a décidé de s'engager plus de temps à la communauté d'échange aux pays-bas, résultant dans un Exchange Server MVP award en 2007. Il est aussi un collaborateur régulier chez le groupe néerlandais Unified Communications utilisateur et un auteur ordinaire pour Simple-Talk.
En savoir plus sur « Échange 2010 – A Practical Approach » à red-gate.com/our-company/about/book-store.