Accueil > Exchange, Microsoft > Exchange 2007 CCR en cas de crash

Exchange 2007 CCR en cas de crash

Aujourd’hui nous allons voir ce qui se passe vraiment en cas de crash d’un node d’un cluster CCR dans notre infrastructure Exchange !!

Rappel :
1 cluster CCR est constitué de :
2 Node en Cluster MSCS (1 instance CMS)
1 Quorum en FSW (File Share Witness) hébergé sur un serveur (préconisation Microsoft, sur un CAS) de type Majoritaire.

Prenons une infrastructure volontairement imposante pour bien voir ce qui se passe :
2 salles reliées par de la fibre.
6 serveurs hébergeant chacun le rôle HUB et CAS formant une ferme NLB (Unicast, 2 NIC):
3 dans chaque salle
8 serveurs Mailbox formant 4 Cluster CCR :
4 dans chaque salle

Ma maquette représentant le tout à plus petite échelle …

MaquetteCCR
HyperV R2 comme hyperviseur
1 Contrôleur de domaine / DNS / DHCP / GC
2 serveurs HUBCAS en NLB (Unicast, 2 NIC)
2 serveurs MailBox en Cluster CCR
(Le serveur Edge n’est pas utilisé, l’infra a été reconfiguré pour ne plus s’en servir)
1 routeur pour simuler les connexions internet

L’infra
Infra
Salle1 Salle2
3x HUBCAS 3x HUBCAS
4x Node 4x Node
FSW représente le Quorum utilisé par un cluster CCR
Dans notre infra nous avons 4 share FSW

Présentation des 3 scenarios testés !
Scenario 1 : cas 1 qu’est ce qui se passe quand la salle1 tombe
Scenario1Cas1
Scenario 1 : Cas 1
Résultat : Aucune bascule ne se produit, il faut intervenir sur la salle2 (à distance) pour redémarrer les serveurs Mailbox. (Interruption de services, intervention manuelle)
Car nous avons 2 des 3 membres du cluster qui sont absents.
Les serveurs HUBCAS en NLB eux fonctionnent correctement, les services sont toujours distribués.

Scenario 1 : cas 2 qu’est ce qui se passe quand la salle2 tombe
Scenario1Cas2
Scenario 1 : Cas 2
Résultat : tout fonctionne correctement. (Aucune interruption de services)

Scenario 2 : cas 1 qu’est ce qui se passe quand la salle1 tombe
Ce scenario test le comportement du cluster si le FSW (Quorum) est situé dans la salle2
Scenario2Cas1
Scenario 2 : Cas 1
Résultat : La bascule automatique se produit, la salle2 reprend les dabatases des Mailbox. (Interruption de services, bascule automatique)
Les serveurs HUBCAS en NLB eux fonctionnent correctement, les services sont toujours distribués.

Scenario 2 : cas 2 qu’est ce qui se passe quand la salle2 tombe
Ce scenario test le comportement du cluster si le FSW (Quorum) est situé dans le salle2
Scenario2Cas2
Résultat : La salle1 étant pourtant en production, du fait de l’absence de + de la majorité des partenaires du cluster, s’arrête. (Interruption de services, intervention manuelle)
Il faut intervenir sur la salle1 (à distance) pour redémarrer les serveurs Mailbox.
Les serveurs HUBCAS en NLB eux fonctionnent correctement, les services sont toujours distribués.

Scenario 3 : reprise d’activité lorsque l’on se trouve dans la situation du scenario 1 cas 1 (le salle1 tombe)
Ce scenario reprend le scenario 1 et applique la procédure de Microsoft pour la reprise d’activité (intervention manuelle).
Procédure disponible ici :
http://msexchangeteam.com/archive/2008/04/03/448615.aspx

J’ai fait tous les scripts pour automatiser chaque étape de la procédure.

Note finale :
On optera pour le scenario 1 respectant l’esprit d’un PRA (la salle 2 étant le site de reprise avec des performances dégradées)
Attention les 4 Quorum FSW doivent être configurés sur la salle 1 (1 serveur HUBCAS en portera donc 2…)

Dans le prochain poste je vous presenterez tous les scripts pour automatiser le plus possible la reprise de service.

Pour toutes questions n’hésitez pas.
Bonne lecture :)

Anthony Exchange, Microsoft , , , , ,

  1. Pas encore de commentaire
  1. Pas encore de trackbacks