CCR FWS MNS & TransportDumpster.

Publié le par Teruin

(Thanks to Scott Schnoll)
La fonctionnalité CCR est une solution de haute disponibilité présente dans Exchange 2007 et qui combine la technologie cluster connue des à présent sur Exchange 2003 et la duplication de données vers un serveur passif.
La duplication de données est assurée d'une part "l'envoi" de la base de production vers le serveur passif "seeding" et d'autre part la duplication des journaux de transaction vers le serveur Passif qui rejouera ces derniers.
 
Le basculement est automatique en cas de panne du nœud actif au même titre que la solution Exchange2003 Mscs.
 
L'avantage de cette solution est de
 
  • supprimer l'ensemble des points de rupture,
  • de ne pas demander des pré-requis matériel compliqués,
  • d'éviter la mise en place d'un stockage partagé
  • de permettre l'éloignement géographique des deux serveurs.
  • de permettre la sauvegarde et la reprise d'activité.
 
La première étape dans la mise en place de la fonctionnalité CCR est l'opération de "seeding" (amorçage) qui copie l'intégralité de la base existante vers le serveur passif. Une fois cette opération effectuée la copie des journaux et leur exécution sur le nœud passif peut commencer.
Dans l'environnement CCR les fonctions de réplication sont intégrées dans le service cluster dans le but de délivrer une solution de haute disponibilité.
 
L'environnement CCR permet d'effectuer des arrêts programmés et des bascules (au même titre que l'environnement 2003 cluster) vers le nœud passif. Le déplacement du serveur virtuel Exchange est assuré par la commande Move-clusterMailbox via l'invite de commande Exchange. L'utilisation de cette commande permet de s'assurer avant le déplacement que toutes les conditions sont requises pour effectuer une bascule rapide.
 
L'architecture CCR
Les fonctionnalités CCR présent les fonctionnalités suivantes
  • Fonctionnalités de bascule et de visualisation via l'offre Cluster Microsoft
  • Réplication et réexécution de journaux de transaction
  • File d'attente des messages au niveau du Hub transport
 
 
Les fonctionnalités cluster sont basées sur l'utilisation des services Windows Cluster mais inclut un autre modèle de quorum de type Majority Node Set (MNS) incluant un témoin de partage de fichiers.
 
Le quorum MNS
Dans Windows 2003 serveur, Microsoft inclut un autre type de Quorum appelé MNS. Une des particularités est que contrairement au quorum traditionnellement rencontré jusqu'alors, chaque serveur possède le sien localement. Cette fonctionnalité permet d'envisager des clusters séparés par de longues distances jusqu'ici difficilement envisageable avec l'ancienne technologie. Malgré tout si ce type de quorum permet de faire des clusters étirés elle comporte un certain nombre de limitation que vous devriez connaitre.
Le fait de posséder un Quorum localement implique qu'à chaque changement ces données doivent être synchronisées. L'accomplissement de cette synchronisation, sera considéré comme réalisée si plus de la moitié des bases ont été mises à jour. Si votre cluster possède 5 nœuds, 3 nœuds seront considérés comme étant une majorité.
 
Une autre particularité du Quorum MNS est liée aux contraintes de démarrage. Une majorité de nœud doit être en ligne pour que le serveur virtuel soit démarré. Si cela n'est pas le cas alors le cluster précisera qu'il n'a pas le quorum nécessaire.
 
Autre particularité est la présence obligatoire dans un environnement MNS d'au moins trois nœuds. Car la majorité est, dans un cluster 3 nœuds, de 2 nœuds. Dans un scénario de 2 nœuds la perte d'un serveur entrainera l'arrêt complet du cluster car le seul restant s'arrêtera par absence de quorum.
 
Alors une question vient subitement a l'esprit. Comment fait-on si l'on veut déployer les fonctionnalités CCR sur uniquement deux serveurs. La, rentre en scène la fonctionnalité "File Share Witness".
 
Le témoin de partage de fichiers
Comme je le précisais plus haut, un cluster MNS ne saurait être efficace que si vous installez trois nœuds a minima. Dans le cas d'Exchange, Microsoft a ajouté un tiers qui est un partage de fichier qu'il est préférable, on le verra plus tard de stocker sur un serveur HubTransport. A quoi sert-il ?
 
La fonctionnalité File Share Witness sert tout simplement à éviter sur un cluster 2 nœuds que le serveur restant s'arrête par absence de quorum car comme nous l'avons rappelé plus haut, un cluster 2 nœuds, basé sur un quorum MNS s'arrête si un nœud stoppe par manque de majorité.
 
Le tableau suivant précise selon le type de cluster le nombre de nœud qui peuvent s'arrêter.
Nombre de nœud de cluster 
Nombre de nœud pouvant s'arreter
2
0 (1 avec MNS FSW)
3
1
4
1
5
2
6
2
7
3
8
3
 
La fonctionnalité FSW agit comme un témoin de l'activité du cluster. Ce partage de fichier est utilisé par les 2 nœuds pour inscrire qui détient le contrôle du cluster.
Ce partage de fichier est donc requis uniquement si les deux serveurs ne peuvent plus communiquer entre eux.
Dans le cas d'un cluster a deux nœuds N1 et N2, si N1 peut prendre le contrôle sur le partage de fichier alors il prendra le contrôle sur le cluster et "montera" le serveur mailbox. Si N2 est en ligne et n'est pas capable de communiquer avec N1, il essayera de prendre le contrôle du FSW mais n'y parviendra pas. Par conséquent il n'essayera pas de "monter" le cluster Mailbox.
 
Dans le cas d'un fonctionnement normal ou les deux nœuds communiquent le FSW peut être éventuellement arrêté.
D'une façon générale, le FSW ne sert qu'à remplir la fonction décrite ci-dessus. Toutes les informations de configuration du cluster sont échangées directement entre les nœuds du cluster. Ceci est très important car cela implique que si N1 est en ligne et N2 indisponible, N2 ne peut pas être opérationnel tant qu'il n'as pas communiqué avec N1 même si il peut communiquer avec le FSW qui je rappelle, ne contient pas de données de configuration.
Les serveurs en place dans le quorum vérifient régulièrement l'accès au FSW. Si cela n'est pas possible, alors un événements est généré et doit être pris en compte par les équipes internes, surtout si vous n'avez que deux nœuds ! Car rappelez-vous si l'un s'arrête l'autre aussi dans ce cas.
L'accès des serveurs au FSW se produit dans les cas suivant
  • Lorsque qu'un nœud "monte" et que seulement un nœud du cluster est en ligne
  • Lorsqu'un problème de connexion apparait
  • lorsqu'un nœud quitte le cluster
  • Périodiquement pour validation de l'accès. (note vous pouvez paramétrer la fréquence)
Dans la pratique la charge induit par la gestion d'un FSW est très réduite et un serveur Windows peut largement supporter plusieurs FWS pour plusieurs Cluster. Mais… est ce vraiment souhaitable ? Pas forcement surtout si tout vos clusters sont de 2 nœuds.
Réplication des journaux
Un autre aspect est basé sur la réplication des journaux vers la base passive. Chaque changement d'état de la base active est matérialisé par la création de journaux de transaction de taille fixe de 1 Mb. La fonctionnalité de réplication copie de façon asynchrone le journal sur le nœud passif. Une fois ce dernier copié il est vérifier afin de s'assurer qu'il ne soit pas corrompu et il est "rejoué" sur la base passive. De cette façon la base passive est sensiblement la même que la base active.
Dans le cas d'un arrêt programmé ou d'une panne soudaine d'un des deux nœuds et si le FSW est en ligne dans le cas d'un cluster deux nœuds, alors le server virtuel va basculer sur le serveur encore en ligne.
Dans l'environnement CCR, le journal des transactions sur le nœud actif est partagé via un simple partage Windows. Le GUID du groupe de stockage est utilisé comme nom de partage auxquel on ajoute le suffixe $. Le service de réplication sur le nœud passif se connecte sur le partage et récupère les journaux. Le protocole utilisé est tout simplement SMB. Pour information le trafic de duplication n'est pas crypté. C'est le cas également lorsque vous amorcez la base passive.
Cependant il se peut et cela risque d'être le cas, que sur un arrêt non prévu les bases active et passives ne soient pas identiques et que par conséquent des messages soient perdus lorsque la base passive sera activée. C'était sans compter sur la fonctionnalité Transport Dumpster.
Transport Dumpster.
Cette fonctionnalité est présente sur le Hub transport. Cette fonctionnalité, est un composant requis dans l'environnement CCR. Les serveurs HB transport maintiennent un espace des messages récemment délivrés. Lorsque qu'un basculement se produit, la fonctionnalité CCR présent sur le serveur Mailbox redemande à l'ensemble des "hub transport" du site de représenter les mails récemment délivrés. La Banque d'information se charge quand à elle de supprimer les doublons éventuels et de re-délivrer les messages perdus.
Cette fonctionnalités est uniquement disponible sur le cluster CCR et ne sont concernés que les messages (mail), sont exclus pas conséquent les rendez-vous, les mise à jour de contacts, mise à jour des tâches etc.
Alors que faut-il savoir si l'on envisage de déployer un cluster CCR ?
Tout d'abord il faut prendre en compte le fait que sur un cluster CCR seule une seule et unique base de données peut exister par groupe de stockage, et qu'il existe certaine limitation au niveau des dossiers public,
·         Qu'il est préférable que les serveurs appartiennent à la même zone DNS que celle utilisée par l'Active Directory.
·         Que tous les serveurs du cluster doivent appartenir au même domaine
·         Que les noms de serveurs ne doivent dépasser 15 caractères.
·         Que le cluster Exchange ne doit  pas contenir d'Exchange 2003/2000 et aucune version de Microsoft Sql Server
·         Que le répertoire utilisé pour installer Exchange est vide.
·         Que les emplacements de bases et de journaux (lettre et chemin) soient les mêmes.
·         Quel seul le rôle Mailbox Server est installable en CCR
·         Que tout les serveurs fonctionnent avec Windows 2003 SP1 Entreprise X64
·         Que chaque nœud doit posséder au moins deux cartes réseaux.
·         Que tous les nœuds doivent être dans le même réseau IP
·         Que les journaux de transaction et les bases Exchange ne peuvent pas être positionné à la racine d'une unité
·         Que vous devez prévoir un réseau Heartbit
·         Que le compte utilisé par le service cluster doit possèder le rôle Exchange Server Administrateur
 
Voila vous en savez un peu plus désormais. Messieurs. à vos maquettes !
Cordialement
Laurent Teruin
 
                                       
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


Publié dans Exchange 2007

Commenter cet article