5. Exchange Server 2007 SP1 et la Haute Disponibilité
Microsoft Exchange Server 2007 apportait déjà, par rapport à ses versions antérieures, de grandes avancées sur les méthodes liées à la Haute Disponibilité. Microsoft, par son Service Pack 1, répond encore plus à cette demande, de plus en plus croissante sur les systèmes d'information, où les systèmes de messagerie électronique deviennent prépondérants et indispensables. Pour une organisation, il serait dorénavant inconcevable d'envisager une quelconque perte de données, ni même une interruption de ces services.
Afin de perfectionner les principes de Haute Disponibilité existant sous Exchange Server 2007, le Service Pack 1 apporte une nouvelle fonctionnalité qui permet de dissocier la disponibilité des données, de la résilience de sites (ou continuité de services) que cette partie de l'article tentera de développer au mieux.
5.1 Un nouveau principe pour la Haute Disponibilité : La SCR
La SCR (Standby Continuous Replication) est une nouvelle fonctionnalité apportée par le Service Pack 1 et va permettre de mettre en œuvre, dans une organisation, un système de Réplication Continue de Secours.
Ce système est une évolution des principes de Haute Disponibilité déjà existants sous Exchange Server 2007 ( LCR, SCC, CCR ) qui met à disposition un système basé sur des sources et des cibles, qu'un administrateur pourra, à tout moment, manuellement substituer en cas de défaillance majeur d'un système principal.
C'est un véritable complément de Haute Disponibilité que nous apporte le Service Pack 1 par la SCR, puisqu'elle pourra être couplée, au besoin de l'organisation, aux systèmes de Haute Disponibilité déjà préexistants.
5.1.1 Le principe de fonctionnement :
Tout comme pour les systèmes de LCR et de CCR, la SCR se base sur un principe de copies actives et passives, où les termes sources et cibles seront conventionnellement utilisés.
La source de données d'un système de SCR pourra être différente et recevoir n'importe lequel de ces groupes de stockage :
- Un rôle de Boite aux Lettres Autonomes.
- Un Clustering de Boite aux Lettres dans un Cluster à Copie Unique (SCC).
- Un Clustering de Boite aux Lettres dans un Cluster à Réplication Continue (CCR).
Il en sera de même quant aux cibles qui pourront être basées sur différentes configurations :
- Un rôle de serveur de Boite aux Lettres Autonome sans LCR activé sur les groupes de stockage.
Sur un rôle de Boite aux Lettres présent sur un nœud passif d'un Cluster à Basculement.
Informations :
- Les groupes de stockage de réplication ne s'appliquent pas à la SCR.
- Les groupes de stockage SCR ne peuvent pas contenir plus d'une base de données.
- Dans tous les cas, une cible SCR doit impérativement posséder un rôle de serveur de Boite aux Lettres.
- Il est possible d'associer à une source une quantité illimitée de cibles, bien que le nombre conseillé soit de quatre par source.
- De même, une cible peut posséder plusieurs sources distinctes.
- Les sources et cibles doivent impérativement être équipées du Service Pack 1.
- Les chemins d'installation du produit Exchange doivent être identiques sur l'ensemble des systèmes visés par la SCR.
- Vous ne pouvez effectuer des sauvegardes SCR que sur les systèmes sources.
De prime abord, la SCR pourrait être assimilée à la LCR ou encore la CCR, mais celle-ci possède des caractéristiques qui lui sont propres et qui sont dénombrées ci-dessous :
- Alors que la LCR et la CCR prennent en charge une seule cible de réplication par groupe de stockage, la SCR est capable d'en assimiler plusieurs.
- Un administrateur système pourra définir un délai de relecture de la base de données active, de manière à prévenir une corruption de données logiques sur la source et ainsi permettre qu'elle ne se réplique pas immédiatement sur les cibles SCR.
- La gestion de la SCR se fait uniquement depuis le Management Shell d'Exchange.
5.1.2 De nouveaux scénarios possibles :
Utilisation de la SCR avec des systèmes autonomes
Ce premier scenario montre l'utilisation de la SCR sur un système autonome. La SCR permet la réplication de plusieurs groupes de stockage d'un dispositif serveur à un autre. Si une défaillance se présente, il sera alors possible d'effectuer une récupération des données grâce à la portabilité de la base de données, ou encore grâce à la commande setup.com /RecoverServer
Cas d'utilisation des fonctionnalités SCR et CCR
Dans cet exemple, il y a utilisation de la technologie CCR sur un premier site physique, alors que sur le deuxième, se trouve un cluster de secours. Si un problème se présente sur la source, il devient alors possible de précéder à la récupération des groupes de stockage présents sur la cible à l'aide de la commande setup.com /RecoverCMS. Il est également possible, comme dans le premier exemple, de ne récupérer qu'un groupe de stockage spécifique et, pour se faire, il sera alors nécessaire d'utiliser les principes de portabilité de la base de données. Voici donc un cas concret où le fait de combiner les solutions de la CCR et de la SCR, permet de séparer physiquement la disponibilité des données et la continuité de services sur deux systèmes distincts.
Cas d'utilisation de CCR avec des cibles multiples SCR
Ce principe d'utilisation montre qu'il est également possible, pour la réplication continue de secours, d'effectuer une réplication avec plusieurs cibles, situées sur des sites physiques distants. Dans le cas d'une utilisation de sources CCR multiples, l'utilisation de la commande setup.com /RecoverCMS ne vous sera pas permise, seule la portabilité de la base de données restera effective.
Cas d'utilisation des fonctionnalités SCR et SCC
Il est bien évidement également possible d'utiliser la réplication continue de secours avec la mise en cluster à copie unique. De la même manière que vu précédemment, le groupe de stockage est répliqué vers l'ensemble des cibles SCR. L'utilisation de la commande setup.com /RecoverCMS est disponible pour vous permettre de récupérer les groupes de stockage des cibles.
Pour résumer, on peut se rendre compte que la technologie SCR, couplée avec des serveurs autonomes, en cluster à réplication continue, ou encore en cluster à copie unique, permet de séparer les aspects de la disponibilité des données et des services avec la continuité des services. Plus concrètement, alors que la CCR créée des réplications continues de groupes de stockage et que la SCC permet l'utilisation de groupes de stockage à de multiples cibles, la SCR permet de répliquer, à distance et dans un deuxième centre de données, ces informations.
Rappels pour l'activation des cibles en cas de défaillance de la source :
- Utilisation de la portabilité de la base de données
- Utilisation de la commande setup.com /RecoverServer dans le cas d'un serveur autonome.
- Utilisation de la commande setup.com /RecoverCMS dans le cas d'un serveur en cluster.
5.1.3 Mise en œuvre de la SCR :
Pour permettre la mise en œuvre de la fonctionnalité SCR, le Service Pack 1 apporte des modifications aux cmdlet du Management Shell d'Exchange. Entres autres, on voit apparaitre le paramètre StandbyMachine à plusieurs commandes, qui permet de spécifier le nom d'un serveur cible pour une SCR. Les commandes qui s'en trouvent affectées sont les suivantes :
- Suspend-StorageGroupCopy
- Resume-StorageGroupCopy
- Update-StorageGroupCopy
- Restore-StorageGroupCopy
- Get-StorageGroup
- Get-StorageGroupCopyStatus
L'activation de la SCR sur un système se réalise par le biais de la commande Enable-StorageGroupCopy. L'exemple ci-dessous présente une mise en œuvre de la solution SCR sur des serveurs de boites aux lettres autonomes.
Comme présenté précédemment, pour que la SCR puisse répliquer les fichiers journaux des transactions, il est nécessaire que cela se fasse sur un groupe de stockage (noté GS sur le schéma) avec une seule base de données (MBX.edb). Les groupes de stockage GSp serviront uniquement pour effectuer des opérations de portabilité de la base de données.
L'activation de la SCR passe par la commande :
Enable-StorageGroupCopy SOURCE\GS -StandbyMachine CIBLE
Il vous est ensuite possible, à tout moment, de vérifier le lien SCR entre les deux machines grâce à la commande :
Get-StorageGroupCopyStatus SOURCE\GS -StandbyMachine CIBLE
En cas d'erreur critique sur la base de données de la source, vous aurez la possibilité d'activer manuellement la base de données située sur la cible SCR. Pour ce faire, il est au préalable nécessaire de démonter la base de données située sur la source.
Dismount-Database SOURCE\GS\MBX.edb
Ensuite, il faut indiquer que la base de données de la cible SCR est opérationnelle et qu'il est possible de la monter. Pour ce faire :
Restore-StorageGroupCopy SOURCE\GS -StandbyMachine CIBLE
Dans certain cas, il est nécessaire d'ajouter à cette commande le paramètre Force, si et seulement si les fichiers journaux du groupe de stockage ne sont plus disponibles sur la source.
Vous devez vous assurer, après l'exécution de la commande Restore-StorageGroupCopy, que la base de données de la cible SCR soit arrêtée correctement et sans erreur. Si tel n'est pas le cas, reportez-vous à l'utilisation de l'utilitaire Eseutil.
L'opération suivante est celle qui va permettre de modifier la configuration Active Directory pour qu'elle reçoive les nouveaux paramètres d'accès aux fichiers de groupe de stockage et de la base de données.
Move-StorageGroupPath CIBLE\GSp -SystemFolderPath C:\EXCH\GS -LogFolderPath C:\EXCH\GS -ConfigurationOnly
Move-DatabasePath CIBLE\GSp\MBXp -EdbFilePath C:\EXCH\GS\MBXp.ebd -ConfigurationOnly
Puis, MBXp étant une base de données temporaire, il est nécessaire de préciser au système qu'elle peut être écrasée par une restauration. Vous pouvez utiliser le Management Shell ou utiliser la commande suivante :
Set-MailboxDatabase CIBLE\SGp\MBXp -AllowFileRestore:$true
Ensuite, vous pouvez monter votre nouvelle base de données.
Mount-Database CIBLE\SGp\MBXp
L'étape finale consistera à rapatrier les boites aux lettres utilisateurs de la source vers la cible en utilisant la commande suivante :
Get-Mailbox -Database SOURCE\GS\MBX | where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}|?Move-Mailbox?-ConfigurationOnly -TargetDatabase CIBLE\GSp\MBXp
Cette modification, avant qu'elle soit rendue disponible pour les clients (donc véritablement opérationnelle) dépend du temps de latence qu'il existe entre la réplication de l'ensemble de vos services Active Directory.
Lorsque vos clients accéderont à nouveau à leur boite aux lettres, il vous sera alors possible d'envisager de passer l'ancienne source à cible. Pour cela, il est nécessaire de supprimer son groupe de stockage GS, sa base de données MBX et leurs fichiers relatifs, puis d'activer à nouveau la SCR dans le sens inverse.
Pour combiner la réplication continue de secours (SCR) à un cluster à réplication continue (CCR), ou encore à un cluster en copie unique (SCC), vous pouvez vous aider de l'article suivant, consacré à la mise en œuvre des services de clustering sous environnement Windows Server (http://www.laboratoire-microsoft.org/articles/cluster-mscs-exchange-2003/) et de procéder ensuite, conventionnellement, à l'installation des rôles de clustering Exchange Server 2007 SP1 en fonction de la configuration que vous souhaitez.
5.2 Les autres avancées en termes de Haute disponibilité :
Le Service Pack 1 du produit Exchange Server 2007, apporte également quelques autres améliorations, plus ou moins significatives.
5.2.1 Network Load Balancing :
Il vous sera désormais possible d'effectuer des opérations d'équilibrage de charge (NLB : Network Load Balancing) sur vos serveurs hébergeant les rôles Hub Transport d'Exchange, afin d'améliorer encore plus les capacités de Haute Disponibilité du produit. Pour information, le principe de NLB était déjà rendu possible depuis la version RTM d'Exchange Server 2007 pour le rôle Client Access.
5.2.2 Transport Dumpster :
Parallèlement, toujours pour la fonctionnalité Transport du produit Exchange Server 2007, le SP1 améliore les fonctionnalités liées aux Dumpsters, qui les rendent disponibles pour la réplication locale en continue (LCR). Il sera également possible d'effectuer des statistiques sur l'état de ces Dumpsters pour chaque groupe de stockage. Le principe des Dumpsters des rôles Hub Transport permet de mémoriser un espace de messages récemment délivrés, de manière à ce que lorsqu'un basculement se présente dans une solution de clustering, la fonctionnalité CCR, et maintenant LCR avec le Service Pack 1, puisse interroger l'ensemble des services de Transport Hub de l'organisation afin de récupérer le contenu des Dumpsters. Puis, grâce à des comparaisons avec la banque d'informations Exchange, les doublons seront supprimés et les messages perdus réintégrés puis redistribués.
Cette fonctionnalité est de base activée, mais il est conseillé de la configurer au besoin de votre organisation. Pour cela, vous pouvez soit utiliser EMC ou exécuter la commande suivante :
Set-TransportConfig -MaxDumpsterSizePerStorageGroup -MaxDumpsterTime
Pour la valeur size il est conseillé d'allouer 1,5 fois la taille maximale que peuvent prendre vos messages. Ainsi, si vous avez fixé une limite de 15MB par courriel, le paramètre MaxDumpsterSizePerStorageGroup devrait recevoir 22,5MB
Pour la valeur timespan, le paramètre MaxDumpsterTime attend une durée de rétention des messages mémorisés sous la forme dd.HH:MM:SS Par exemple, si vous désirez garder dix jours la file des messages mémorisés, il vous faudra saisir 10.00:00:00
En conclusion pour cette partie, nous pouvons constater que Microsoft montre véritablement sa volonté à faire de l'un de ses produits phare, un système de plus en plus sûr, tout en permettant de garantir à une organisation une très grande fiabilité.
Le Service Pack 1 d'Exchange Server 2007 apporte également quelques modifications au produit en vue de son intégration futur sur des systèmes Windows Server 2008, notamment avec le support de nouvelles fonctionnalités liées à la Haute Disponibilité comme le support de l'IPv6, mais encore le support du protocole DHCP pour l'IPv4.
Avec Windows Server 2008 et Exchange Server 2007 SP1, il est à noter que les fonctionnalités de CCR et de SCC pourront fonctionner sur des environnements à plusieurs sous-réseaux et que le modèle de Quorum des services de clustering sera remanié, afin, entres autres, d'éviter les problèmes liés au spliting (séparation de Cluster).
 Sommaire
1. Installation de Microsoft Exchange Server 2007 Service Pack 1
1.1 Les pré-requis fonctionnels
1.2 Cas d'une nouvelle installation
1.3 Cas de la mise à jour d'un produit Exchange Server 2007
1.4 Cas d'une mise à jour depuis une version antérieur à Exchange Server 2007
1.5 Les mises à jour du Schéma Active Directory
2. Généralités sur les nouveautés apportées par le Service Pack 1
2.1 Le support de Microsoft Windows Server 2008
2.2 Le support de l'IPv6
2.3 Outils d'administration compatibles avec Microsoft Windows Vista
2.4 Les améliorations portées à Outlook Web Access (OWA)
2.5 Les améliorations relatives à la Messagerie Unifiée
3. Les modifications apportées au Transport des messages
3.1 Back Pressure amélioré
3.2 La priorité des messages
3.3. L'agent RMS
3.4 Les règles de Transport applicables à la Messagerie Unifiée
4. Les nouveaux outils de Gestion
4.1 La gestion des périphériques mobiles
4.1.1 Les stratégies ActiveSync étendues
4.1.2 L'effacement d'un périphérique (notifications, confirmations)
4.2 La gestion des dossiers publics
4.2.1 Depuis EMC ou EMS
4.2.2 Le principe du Referral
4.2.3 La segmentation des accès
5. Exchange Server 2007 SP1 et la Haute Disponibilité
5.1 Un nouveau principe pour la Haute Disponibilité : La SCR
5.1.1 Le principe de fonctionnement
5.1.2 De nouveaux scénarios possibles
5.1.3 Mise en œuvre de la SCR
5.2 Les autres avancées en termes de Haute disponibilité
5.2.1 Network Load Balancing
5.2.2 Transport Dumpster
6. La gestion des boites aux lettres
6.1 L'importation et l'exportation en fichier .pst
6.2 La création en bloc d'utilisateurs
6.3 La validation des destinataires
|
|
 |
 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|
Exchange Server 2007: Les nouveautés du Service Pack 1
