> Tech > 1) Changements apportés au rôle MBX (2)

1) Changements apportés au rôle MBX (2)

Tech - Par iTPro - Publié le 24 juin 2010
email

b. Transport dumpster
Bien que cette fonction soit liée au rôle HUB, le transport dumpster est directement lié au fonctionnement du rôle MBX. Le transport dumpster permet de stocker l’ensemble des messages transitant par les serveurs HUB, dans la limite des paramétrages MaxDumpster SizePerStorageGroup et MaxDumpster Time, afin

1) Changements apportés au rôle MBX  (2)

d’être capable de les rejouer en cas de problème sur les serveurs MBX configuré en CCR (pour la RTM d’Exchange 2007), présents sur le même site Windows que les serveurs HUB. Cette fonction transport dumpster est étendue à la configuration LCR depuis le SP1 d’Exchange 2007. De plus, il est maintenant possible de configurer la durée et la taille de la rétention des messages sur les rôles HUB au travers de l’interface graphique de la MMC ce qui n’était uniquement possible par commande PowerShell avec la version initiale du produit.

c. SCR
Le SCR (Standby Cluster Recovery) est une nouvelle fonction liée à la haute disponibilité d’Exchange 2007. Avant d’aborder le principe de fonctionnement, il est temps de signaler que l’application du SP1 nécessite une mise à jour du schéma. Pourquoi en parler uniquement maintenant ? : simplement parce que la majorité des nouvelles extensions de schéma d’Exchange 2007 SP1 est liée justement à cette nouvelle fonctionnalité SCR.

Cette extension est obligatoire avant toute application du SP1 même s’il est appliqué pour la première fois sur un serveur ayant un autre rôle que celui de MBX. La version initiale d’Exchange 2007 apportait la possibilité de disposer d’une réplique de base soit sur le serveur local (LCR) soit sur un autre noeud d’un cluster (CCR). Le SCR permet désormais de disposer d’une ou plusieurs copies du même groupe de stockage sur des machines différentes. La source et la destination peuvent être des serveurs membres ou des clusters, mais dans le cas d’un cluster, le serveur source et destination ne doivent pas être membres du même cluster.

Vous pouvez donc combiner la haute disponibilité d’un cluster de type SCC (cluster avec stockage partagé) ou CCR (réplication de base entre les deux noeuds du cluster) sur un site principal et une copie d’un SCR sur un site distant en cas de problème important sur le site principal. Il n’y a pas de limite du nombre de réplication d’une base. Cependant, pour des raisons de montée en charge du serveur source, il n’est pas recommandé de configurer plus de 4 répliques de la même base, ce qui laisse largement de quoi couvrir l’ensemble des scénarii de haute disponibilité. Un même serveur de secours peut recevoir des répliques de bases venant de serveurs sources différents.

Mais la limite du nombre de 5 groupes de stockage pour la version standard et de 50 groupes de stockage pour la version entreprise doit toujours être respectée. Le temps de réplication des fichiers de logs entre la source et les destinations du SCR peut être ajusté. Ceci permet de mieux contrôler les problèmes éventuels liés à la désynchronisation des fichiers de log et donc l’éventuelle nécessité de restaurer la base. Voir Figure 2.

Le SCR se distingue particulièrement du CCR sur deux points :

1) Les bases de destination du SCR ne peuvent pas être utilisées pour les sauvegardes du système de messagerie. La sauvegarde doit être réalisée depuis la base source.

2) Le démarrage d’une copie de base SCR est une opération manuelle. La mise en place d’une configuration SCR n’est pas destinée à démarrer dès qu’il y a un incident mineur sur le serveur source. Par exemple, si vous devez redémarrer le serveur Exchange source pour appliquer un service pack de l’OS, vous avez la possibilité en disposant d’un CCR, de basculer la ressource Exchange sur l’autre noeud afin de réduire au maximum, le temps d’indisponibilité. Par contre, si vous disposez d’un SCR, le basculement vers le serveur de copie ne sera pas automatique et trop lourd pour une opération aussi temporaire que l’application d’un service pack. Le démarrage d’une copie de SCR se réalise quand on sait que l’indisponibilité du serveur de production sera longue. Sur un serveur autonome, la reprise se fait en exécutant la commande Setup /m :RecoverServer. Si le serveur de secours est un noeud d’un cluster, la commande de reprise d’activité est la suivante : Setup /RecoverCMS.

3) La gestion de la suppression des fichiers de log a été modifiée pour les clusters SCR. Sur un cluster CCR, un fichier de logs ne peut être supprimé sur la source (par un backup par exemple) que si le fichier a été intégré à la base de réplication du CCR. Dans le cas d’une mise en oeuvre du SCR, un fichier de logs peut être supprimé sur le serveur source dès lors qu’il a été inspecté sur l’ensemble des serveurs de destinations. Qui dit « inspecté » ne dit pas « intégré à la base ». L’inspection d’un fichier de logs consiste uniquement en une vérification que le fichier arrivé sur le serveur destination n’est pas corrompu.

Ce fonctionnement a été modifié pour les SCR afin de pouvoir rejouer les logs en différés (le temps de délai pour rejouer les fichiers de logs peut être ajusté) sur les serveurs destinations sans pour autant pénaliser la sauvegarde sur le serveur source. Dans le cas du SCR, le transport dumpster ne fonctionne pas. Donc, si des logs n’ont pas été répliqués lors de la perte du site de production, ces messages ne pourront pas être récupérés automatiquement par le serveur SCR de secours.

Téléchargez gratuitement cette ressource

Cybersécurité sous contrôle à 360°

Cybersécurité sous contrôle à 360°

Avec Cloud in One, les entreprises ne gagnent pas uniquement en agilité, en modernisation et en flexibilité. Elles gagnent également en sécurité et en résilience pour lutter efficacement contre l’accroissement en nombre et en intensité des cyberattaques. Découvrez l'axe Cybersécurité de la solution Cloud In One.

Tech - Par iTPro - Publié le 24 juin 2010