Communications
Protection des données et récupération après incident pour Exchange Server 2007
Lee Benjamin
Vue d'ensemble:
- Sauvegarde et restauration de base
- Continuité des données
- Technologies de réplication
- Solutions alternatives
Microsoft Exchange Server a été conçu en gardant à l’esprit la sauvegarde. Les organisations doivent sauvegarder leurs données de messagerie et pouvoir également restaurer ces informations. Pour répondre à ces besoins, Microsoft a créé une gamme complète d’options de protection des informations, de la
sauvegarde et la restauration traditionnelle au bas de l’échelle, en passant par la continuité opérationnelle, jusqu’aux véritables solutions de continuité d’entreprise qui fournissent les niveaux les plus élevés de disponibilité et de récupération après incident. Dans cet article, je décrirai ces options et vous aiderai à décider comment implémenter la meilleure solution de récupération d’Exchange pour votre organisation.
NIVEAU 1 : SAUVEGARDE ET RESTAURATION DE BASE
Vous pouvez sauvegarder les fichiers Exchange en mettant ses bases de données hors ligne, mais également les sauvegarder pendant qu’elles s’exécutent. En fait, cette dernière option est souvent la méthode recommandée pour sauvegarder Exchange. Mais Exchange est plus qu’un ensemble de fichiers. C’est une banque d’informations avec de gros fichiers de base de données et journaux de transactions. Les messages envoyés à Exchange sont immédiatement enregistrés dans les journaux de transactions et lorsque le système dispose de quelques cycles disponibles (habituellement juste quelques millisecondes plus tard), les messages sont copiés dans la base de données. En plaçant les informations sur disque aussi rapidement que possible, Exchange fournit un niveau très élevé de récupérabilité. La disponibilité des deux ensembles d’informations est essentielle à la restauration d’Exchange. En cas d’échec de votre système, c’est la combinaison d’une sauvegarde précédente, avec toutes les transactions depuis ce point, qui vous permet de restaurer Exchange avec les informations les plus récentes. Notez que, en cas de nécessité, Exchange réexécute automatiquement les transactions d’une base de données restaurée.
Les programmes de sauvegarde accèdent aux informations de la base de données Exchange par le biais de l’API de sauvegarde du moteur de stockage extensible (ESE) ou des dernières solutions de VSS, dont je parlerai plus tard. Lorsqu’une sauvegarde ESE est mise en route, Exchange interrompt temporairement toutes les écritures dans ses bases de données. Tandis qu’ESE place temporairement la base de données en mode de lecture seule, ce qui lui donne la possibilité d’être copié dans une sauvegarde complète, il utilise également une base de données temporaire pour le stockage des nouvelles transactions qui surviennent pendant la sauvegarde. Lorsque la sauvegarde est terminée, ESE remet la base de données en mode de lecture/écriture normal et applique les transactions accumulées dans sa base de données temporaire. La sauvegarde purge également les vieux journaux de transactions à la fin d’un processus de sauvegarde réussi.
Bien que ce processus de sauvegarde soit direct et transparent pour les utilisateurs qui ouvrent une session au milieu de la nuit pendant la progression de la sauvegarde, l’exécution d’ESE peut nécessiter une durée très longue, en particulier parce que la taille des bases de données Exchange peut s’échelonner de quelques gigaoctets, jusqu’à 30 à 50, ou même encore 100 Go, ce qui devient quasi impossible à sauvegarder pendant la nuit en utilisant des technologies standard. Pour avoir une idée des options disponibles lors de l’utilisation de NTBackup.exe, examinez la figure 1.
Figure 1** Utilisation de l’utilitaire NTBackup **
Meilleures pratiques pour Exchange
Si vous voulez pouvoir rapidement effectuer une récupération après les échecs système et matériels courants, des sauvegardes complètes d’Exchange doivent être effectuées chaque nuit. Pour améliorer la performance et la récupérabilité lorsqu’un serveur Exchange utilise des disques locaux, il est important que vous utilisiez des baies RAID distinctes pour enregistrer les bases de données d’Exchange et les journaux de transactions d’Exchange. Ainsi, si un contrôleur de baie RAID tombe en panne, ou si plus d’un disque de la baie tombe en panne et que par conséquent les disques restants ne peuvent plus reconstruire les données agrégées, vous pourrez tout de même effectuer la récupération. Si vous perdez vos journaux de transactions, vous aurez toujours des bases de données Exchange à jour sur les autres lecteurs, qui vous permettront de poursuivre des activités normales avec de nouveaux journaux de transactions. Si vous perdez les lecteurs de base de données, votre stratégie de récupération consiste à revenir à votre sauvegarde complète de la nuit précédente pour les bases de données Exchange et d’appliquer ensuite les journaux de transactions du jour pour les mettre à jour.
Il est important que vous limitiez la taille de vos bases de données Exchange pour que chacune puisse être sauvegardée (et plus important encore, restaurée) en un temps raisonnable. Pour la plupart des organisations, cela signifie conserver une taille de bases de données comprise entre 30 et 50 Go. Lorsqu’une base de données croît au-delà de cette taille, il est conseillé de la fractionner en bases de données multiples pour que la restauration puisse être gérable.
Continuum de sauvegarde et restauration
Le placement des bases de données et des journaux de transactions est très important, non seulement pour les performances de la sauvegarde, mais également pour la vitesse de récupération. Aujourd’hui, tous les serveurs prennent en charge divers niveaux de redondance de lecteur de disque, ce qui porte le nom de RAID. RAID permet essentiellement la défaillance d’un lecteur de disque sans arrêt du système, bien que les performances du système soient plus réduites jusqu’à ce que le disque ait été remplacé et reconstruit. Jusqu’à ce stade, le contrôleur de baie doit reconstruire les données à partir des disques restants « à la volée », pour chaque requête d’accès disque. Pour plus d’informations sur la conception du stockage de serveur de boîtes aux lettres, voir l’article Microsoft IT Showcase « Passage aux 64 bits avec Exchange Server 2007 ».
L’une des fonctionnalités essentielles d’Exchange est sa conception de base de données à instance unique. Ceci signifie que dans une base de données Exchange, seule une copie d’un message spécifique est enregistrée, avec une seule pièce jointe (si elle existe). Si le message a été envoyé à plusieurs destinataires de la même banque d’informations, des pointeurs supplémentaires vers les objets (message, pièce jointe) sont créés, mais les objets ne sont pas dupliqués. C’est non seulement un grand avantage d’efficacité de remise, mais également une grande économie d’espace pour Exchange, sur disque comme sur bande.
Bien qu’Exchange soit doué pour la récupération de la base de données entière, la restauration des boîtes aux lettres individuelles, des dossiers ou des messages nécessite de récupérer d’abord la bande entière. Il n’est pas surprenant que les utilisateurs aient exigé des capacités de restauration plus détaillées. L’instance unique sur bande complique énormément ceci. Les fournisseurs de sauvegardes ont répondu à ce besoin avec la « Sauvegarde de niveau brique » (que je ne recommande pas). Après avoir terminé une sauvegarde complète de la base de données Exchange en utilisant l’API de sauvegarde ESE approuvée, les produits de sauvegarde ajoutent ensuite chaque boîte aux lettres à la bande de sauvegarde. Puisque l’API de sauvegarde ne fournit pas de méthode d’extraction des données des boîtes aux lettres individuelles, MAPI est utilisé. Par conséquent, la bande de sauvegarde est considérablement plus longue car vous dupliquez tous ces messages et pièces jointes.
Microsoft a apporté quelques améliorations qui répondent partiellement à ce problème. Par exemple, la corbeille à papier (ou Benne) conserve les éléments pendant une certaine période après leur suppression par les utilisateurs, au cas où ils seraient nécessaires. En outre, il n’est plus nécessaire de garder un serveur disponible comme forêt de récupération Exchange. Les groupes de stockage de récupération permettent à un administrateur de monter partiellement les bases de données restaurées qui ont été récupérées à partir de la bande et de copier ou fusionner des données au niveau des boîtes aux lettres.
Essayer pour réussir
De nombreuses organisations découvrent, lorsqu’il est trop tard, que quel que soit le niveau de sauvegarde et de récupération qu’elles ont décidé d’adopter, les procédures de support de sauvegarde et de récupération doivent être régulièrement testées. Trop d’administrateurs déterminent uniquement après une urgence si leur technologie de sauvegarde et les procédures de restauration fonctionnent réellement ou non. Le meilleur moment pour le test est le lendemain de la mise en place et de la configuration de votre tout nouveau serveur, lorsqu’il est opérationnel dans votre organisation Exchange mais seulement utilisé par quelques utilisateurs. Vous devriez alors exécuter une sauvegarde complète d’Exchange, une sauvegarde ordinaire de vos lecteurs et capturer l’état du Système, qui inclut les fichiers critiques sur votre disque système ainsi que la métabase IIS (où se situe la configuration de routage d’Exchange). Ensuite, reformatez calmement le nouveau serveur et recommencez, en mettant à jour les notes que vous avez prises lorsque vous avez initialement mis en place le serveur. Vous devriez pouvoir restaurer des paramètres de l’état du système, mais également disposer d’une documentation suffisante pour remettre en œuvre manuellement les paramètres de configuration du système.
Le temps que vous passerez sur cet exercice réduira de manière significative votre temps de récupération à l’avenir. Répétez régulièrement ce processus. Pendant que vous y êtes, chronométrez le temps nécessaire à la récupération des bandes hors site. Ceux qui ont eu à souffrir de cette attente paraissant interminable commencent alors souvent à réfléchir plus sérieusement à l’importance des sauvegardes disque vers disque pour leur stratégie de sauvegarde et restauration, même si le stockage sur bande hors site continue à constituer leur solution ultime pour la récupération après incident.
Défis de la sauvegarde de bande
La restauration à partir d’une bande est trop longue. Exchange est aujourd’hui si essentiel aux organisations qu’utilisateurs et administrateurs s’attendent à ce qu’il soit disponible en permanence. Lorsqu’un problème sérieux survient, la plupart des organisations sont prises au dépourvu. Personne n’est prêt à entendre qu’il faudra huit heures pour restaurer 75 Go de base de données d’une bande (et cela n’inclut même pas le temps nécessaire pour obtenir les bandes depuis l’installation de stockage hors site ou la réinstallation du système d’exploitation).
Qui plus est, la récupération de la base de données correcte depuis la bande constitue en soi un défi. Au cours des 10 années écoulées depuis la première version d’Exchange, le coût du stockage sur disque et des réseaux étendus a considérablement chuté. Par conséquent, de nombreuses organisations peuvent se permettre des méthodes de sauvegarde et de restauration plus rapides. Il est possible pour ces organisations de profiter de technologies qui leur permettent de bénéficier de continuité opérationnelle et de récupération après incident pour leur infrastructure Exchange.
NIVEAU 2 : CONTINUITÉ OPÉRATIONNELLE
La continuité opérationnelle est un ensemble de processus et de technologies ayant pour but la récupération, aussi rapide que possible, pour réduire au minimum le temps d’indisponibilité inattendue. La continuité opérationnelle offre un RTO (Objectif de temps de récupération) et un RPO (Objectif de point de récupération) améliorés par rapport à la bande, pour la récupération locale. Elle s’efforce d’éliminer, dans la mesure du possible, le temps nécessaire pour remettre les bandes en ligne. Examinez la figure 2 pour comparer la continuité fonctionnelle pour la sauvegarde et la restauration et la récupération après incident.
Figure 2** Continuum de récupération **(Cliquer sur l'image pour l'agrandir)
Ce diagramme illustre le continuum de récupération et de disponibilité depuis lent et bon marché dans le coin inférieur gauche jusqu’à rapide et onéreux dans le coin supérieur droit, avec une transition floue délibérée entre la continuité opérationnelle et les solutions de récupération après incident.
Le graphique vous donne une idée des compromis entre coûts, temps de récupération et disponibilité au travers de ces approches. Dans cet article, j’effectue volontairement une distinction nette entre les processus de continuité locaux et la récupération après incident. La récupération après incident est toujours indiquée comme distante, l’objectif principal étant l’obtention des données hors site. La distance introduit des obstacles supplémentaires et est généralement beaucoup plus coûteuse mais, pour la récupération après incident, la poursuite des activités après urgence est l’objectif principal. Je couvrirai ceci avec plus de détails plus tard.
Un peu d’histoire
Lorsque Exchange est devenu un élément encore plus vital de l’infrastructure et que davantage d’informations ont commencé à être enregistrées dans ses bases de données, il est devenu évident que les temps de sauvegarde et de restauration nécessitaient d’être réduits. En collaboration avec Microsoft, certaines grandes organisations ont proposé une approche offrant un retour au fonctionnement partiel nettement amélioré. Si une organisation pouvait recevoir et envoyer de nouveaux messages électroniques depuis et vers le monde extérieur, il semblerait que rien ne s’est passé. Après tout, l’apparence a de l’importance.
Pour implémenter cette restauration de la « tonalité d’appel » pour Exchange, une nouvelle base de données vide était mise en place en remplacement de celle endommagée. Exchange et Active Directory® créaient alors de nouvelles boîtes aux lettres avec les autorisations appropriées et les utilisateurs pouvaient envoyer et recevoir. Une fois la bande de sauvegarde obtenue et les données récupérées, elle pouvait être montée de manière administrative. L’administrateur Exchange fusionnait alors les boîtes aux lettres restaurées aux boîtes aux lettres de « tonalité d’appel ». La priorité des boîtes aux lettres pouvait être décidée en fonction des nécessités. Bien que constituant une amélioration, cette procédure complexe et longue utilisait à l’origine EXMERGE et a ensuite été adaptée aux groupes de stockage de récupération. Notez toutefois que la restauration complète des données après un scénario de récupération de « tonalité d’appel » peut constituer une tâche ardue et compliquée (surtout si l’on considère que jusqu’à 50 groupes de stockage peuvent être disponibles dans Exchange 2007). Si vous envisagez d’implémenter un scénario de récupération de type tonalité d’appel, veillez à vous assurer que les avantages surpasseront l’effort requis.
Services Cliché instantané des volumes
Pour profiter des disques moins onéreux et supprimer la surcharge pour le processeur des serveurs Exchange de production, une nouvelle API de sauvegarde a été développée pour Microsoft® Windows Server® 2003 et Exchange. Le service Cliché instantané des volumes (VSS) a été créé pour faire une copie cohérente des données à un point déterminé dans le temps. Ces instantanés sont des copies rapides en lecture seule des données d’Exchange incluant uniquement les données modifiées successivement. Les copies pointent habituellement vers un autre serveur avec espace disque disponible ou vers un réseau de stockage SAN. Plusieurs instantanés peuvent être conservés, des sauvegardes étant effectuées sur bande. Par conséquent, le serveur Exchange de production n’a plus à souffrir de l’impact sur les performances du logiciel de sauvegarde et de la surcharge due à la copie de la bande.
Il y a plusieurs avantages à l’utilisation de VSS pour la protection des données d’Exchange. Tout d’abord, la charge sur les performances des opérations de sauvegarde de bande peut être supprimée de votre serveur Exchange. Bien que la sauvegarde sur bande doive toujours être effectuée, elle peut utiliser une copie des données d’Exchange et n’influe pas sur les performances de l’utilisateur. Deuxièmement, il devient possible d’effectuer des instantanés plus fréquemment qu’une fois par nuit. Et, qui plus est, vous pouvez conserver plusieurs instantanés sur le serveur secondaire ou un autre stockage local.
Il existe sur le marché plusieurs produits de sociétés tierces capables de tirer parti des capacités d’instantanés de VSS. Certains réduisent simplement le temps nécessaire pour la sauvegarde et la restauration des bases de données Exchange, tandis que d’autres ajoutent des capacités de récupération plus détaillées que celles incluses de manière native par Exchange, afin que vous puissiez effectuer une restauration au niveau des boîtes aux lettres. Bien que personne n’apprécie de telles sauvegardes de « briques », nous souhaitons tous avoir la possibilité de restaurer des dossiers spécifiques ou même certains messages particuliers.
Technologies de réplication
Le basculement d’Exchange géré par logiciel est une option proposée par certains fournisseurs de solutions de réplication. Cette option fait en sorte qu’un serveur Exchange en mode d’attente devienne actif et indique ensuite à Active Directory que toutes les boîtes aux lettres des utilisateurs ont été déplacées. Il existe deux façons d’accomplir ceci, qui nécessitent toutes deux certaines personnalisations des environnements Exchange et Windows. La première oblige à jouer quelques tours au serveur DNS pour que le serveur en mode d’attente s’approprie le nom et l’adresse IP du serveur ayant échoué. Cette approche a l’avantage d’être facile sur les postes de travail clients puisque Outlook® pense qu’il utilise toujours le même serveur.
La deuxième approche utilise un serveur en mode d’attente exécutant Exchange et qui contient les copies des bases de données mais sur lequel rien n’a été monté. En cas de défaillance, le serveur en mode d’attente informe Active Directory que toutes les boîtes aux lettres d’utilisateurs ont été transférées vers lui. Un script est ensuite exécuté ou une stratégie de groupe distribuée, indiquant aux clients qu’ils sont sur un serveur de messagerie différent. Outlook 2007 fonctionne avec Active Directory, ce qui rend le processus plus facile car il effectuera automatiquement ces mappages par lui-même.
Mise en clusters locale avec MSCS
Microsoft Cluster Services (MSCS) se situe à un niveau plus élevé dans le continuum de disponibilité. Exchange est une application qui fonctionne avec les clusters. La mise en clusters partage les informations entre deux ordinateurs ou plus afin que, si l’un de ceux-ci échoue, les autres prennent le relais. De nos jours, la plupart des clusters Exchange se composent de deux ou quatre nœuds, alors que jusqu’à huit nœuds peuvent être utilisés. Un nœud est toujours désigné comme passif (fonctionnel, avec Windows Server en cours d’exécution et Exchange Server installé, mais sans qu’aucune boîte aux lettres ne soit active). Il était possible d’utiliser un cluster à deux nœuds actif/actif dans Exchange 2003, mais en raison de surcharges des performances, cette solution est maintenant déconseillée et ne sera pas prise en charge avec Exchange 2007.
Comme avec la configuration de clusters pour Exchange 2003, les clusters Exchange 2007 qui incluent un nœud passif peuvent toujours utiliser une baie de stockage partagée unique. Bien que le stockage de niveau de qualité de cluster comporte habituellement plusieurs fonctionnalités de redondance pour résister à de nombreux types de défaillances, il fournit toujours uniquement une copie des données, ce qui laisse une opportunité de vulnérabilité. C’est pourquoi ces clusters portent le nom de clusters à copie unique (SCC), pour les distinguer de l’étape suivante de protection des données qui comporte des clusters à copie multiple (MCC) dans Exchange 2007. Nous aborderons les MCC plus en détail lorsque nous examinerons la récupération après incident.
Réplication continue locale
La réplication continue locale (LCR) est une nouvelle fonctionnalité d’Exchange 2007 fournissant une méthode améliorée pour le maintien d’une deuxième copie des bases de données et des journaux de transactions Exchange sur un même serveur. Celle-ci ajoute une couche de redondance à la pratique recommandée consistant à disposer de la base de données Exchange sur une baie RAID et des journaux de transactions sur une autre : la LCR donne la possibilité d’enregistrer une copie secondaire des journaux sur la baie qui abrite la copie principale de la base de données et d’enregistrer ensuite une copie secondaire de la base de données sur la baie qui abrite la copie principale des journaux (voir la figure 3). En cas de défaillance du contrôleur RAID ou de la baie, vous disposez toujours de votre base de données et des journaux de transactions sur l’autre baie. Ainsi, votre installation peut continuer à fonctionner (bien qu’avec un peu d’hésitation et des performances affaiblies), jusqu’à ce que vous puissiez reconstruire la baie en panne.
Figure 3** Configuration de LCR **
LCR est une solution de continuité opérationnelle locale, non une solution de sauvegarde, et vous aurez donc toujours besoin d’une stratégie de sauvegarde complète. Avec LCR, les performances sont également affectées, car votre serveur effectue deux copies de la base de données et des journaux de transactions. De plus, dans une mise en œuvre d’Exchange 2007, il existe certaines restrictions qui font que LCR est uniquement adapté aux organisations de petite taille en raison de sa prise en charge d’une seule base de données dans un groupe de stockage et d’une seule base de données de dossier public dans une organisation.
Le basculement avec une récupération LCR n’est pas instantané, un informaticien professionnel expérimenté devra exécuter des scripts pour qu’Exchange soit à nouveau opérationnel. Le processus nécessite l’exécution de commandes d’Exchange Management Shell, opération effectuée hors de la console de gestion Exchange.
Alors qu’Exchange Server 2003 Enterprise Edition permettait à une organisation d’utiliser jusqu’à 20 bases de données Exchange (quatre groupes de stockage possédant jusqu’à cinq bases de données chacun), Exchange 2007 Enterprise Edition permet jusqu’à 50 groupes de stockage, chacun possédant sa propre base de données. Les journaux des transactions ont été également réduits en taille, de 5 Mo dans Exchange 2003 à 1 Mo dans Exchange 2007. Ces deux modifications sont prévues pour prendre en charge LCR, ainsi que la réplication continue en cluster (CCR), qui sera abordée sous peu.
Petites et moyennes entreprises utiliseront la LCR afin d’améliorer la protection des données pour leur exploitation d’Exchange. La LCR est facile à implémenter mais implique tout de même une intervention manuelle. En tant que solution « même serveur/disque local », la LCR est seulement la première étape vers une continuité opérationnelle améliorée. Bien qu’elle assure la protection contre les défaillances d’une baie RAID et de contrôleurs RAID, les incidents de disque ou défaillances de contrôleur RAID multiples et simultanées sont relativement rares. La plupart du temps, les scénarios de défaillance impliquent l’écroulement du serveur entier, ce qui nous mène à l’étape suivante de la protection d’Exchange.
Réplication locale hors hôte de fournisseur tiers
Pour accroître les capacités de récupération d’Exchange, des fournisseurs tiers ont développé des produits qui tirent parti de la réplication « hors hôte » utilisant les fichiers journaux d’Exchange pour conserver une copie en mode d’attente de la base de données Exchange sur un autre ordinateur. Dans ce cas, la solution de protection ou d’archivage des informations exécute une sauvegarde ESE complète d’Exchange sur un ordinateur différent et extrait ensuite les journaux de transactions dès qu’Exchange les ferme. Elle insère ces transactions dans sa copie de base de données Exchange afin qu’elle soit toujours à jour. Comme je l’ai fait remarquer, ces journaux sont de taille relativement réduite (5 Mo dans Exchange 2003 et 1 Mo dans Exchange 2007) de sorte qu’une fois la sauvegarde complète effectuée, il n’y a presque pas de surcharge sur le serveur Exchange lors de la copie des fichiers journaux vers le serveur hors hôte.
NIVEAU 3 : RÉCUPÉRATION APRÈS INCIDENT ET HAUTE DISPONIBILITÉ
La récupération après incident est la capacité à revenir en mode d’exploitation lorsque le centre de données majeur devient indisponible. Exchange mérite de disposer de la récupération après incident car les fonctions de messagerie électronique et de calendrier sont aujourd’hui la force vitale de nombreuses organisations.
Certaines entreprises s’imaginent que leurs bandes de sauvegarde traditionnelles enregistrées hors site constituent une forme de récupération après incident mais, si votre centre de données unique est détruit par le feu ou une inondation, vos bobines de bande n’auront que peu d’intérêt. La récupération après incident implique nécessairement le déplacement de vos données vers un autre emplacement, mais également la technologie et les processus qui permettront à l’application de redevenir opérationnelle. Pour être efficace, la récupération après incident repose sur la séparation des systèmes primaires et secondaires par une certaine distance. L’éloignement des sites dépend de la magnitude du désastre que vous avez pour objectif de surmonter. Si vous vous souciez des incendies, peut-être qu’un autre bâtiment sur votre campus offrira un éloignement suffisant. Cependant, les désastres d’infrastructure impliquant trains ou avions peuvent affecter un rayon d’un kilomètre et demi, voire davantage. De nombreux désastres sont régionaux : inondations, orages de grêle, tremblements de terre et même pannes de courant. Les communications peuvent devoir faire face à leurs propres calamités, qu’il s’agisse d’une pelleteuse coupant le lien qui vous relie à votre fournisseur d’accès à Internet, d’attaques de déni de service ou d’attaques de déni de service Internet visant le commerce en général.
D’un point de vue pratique, si votre organisation dispose de plus d’un site avec personnel informatique, l’un de ces sites pourrait répondre à vos critères de continuité opérationnelle à distance, en fonction des types de désastres contre lesquels vous vous défendez. L’utilisation de vos propres équipements et de votre propre personnel sera nettement moins onéreuse que la sous-traitance auprès d’un fournisseur de récupération après incident ou la location d’espace à un nouvel emplacement.
En fin de compte, la récupération après incident est une question d’apparence : donner aux clients la confirmation que vous êtes toujours en activité. Les gens font preuve de compréhension lorsqu’un désastre frappe une ville ou une région, mais si votre entreprise n’est pas en ligne au bout de quelques jours voire une semaine, il est probable que clients et fournisseurs craindront le pire ; de nombreuses entreprises échouent pour cette raison. Pour le client, votre installation doit avoir l’air de récupérer afin de l’assurer que vos activités se poursuivent. L’avis des clients diffèrera en ce qui concerne le délai de récupération : ils sont, et c’est compréhensible, naturellement moins patients en ce qui concerne les pannes de courant des sociétés qui assurent leurs services financiers qu’avec, par exemple, les pannes de courant subies par leurs fournisseurs de meubles de bureau.
Exigences de la récupération après incident
Le retour en ligne d’Exchange après une urgence requiert la réplication de ses données sur le site secondaire et l’utilisation de technologies de réplication prêtes à présenter les données à un serveur Exchange en cours d’exécution et prêtes à s’exécuter avec celles-ci, pour ensuite notifier les clients Outlook que leurs boîtes aux lettres ont été déplacées.
Exchange est une application exigeante en ce qui concerne la réplication, en particulier sur de longues distances. En tant que véritable base de données transactionnelle, l’ordre de chaque écriture est d’une importance suprême. Pour compliquer cette tâche, le protocole de transport qu’Exchange utilise pour communiquer toutes les transactions et informations système entre les serveurs est SMTP, un protocole connu pour sa gourmandise en termes de bande passante. Qui plus est, avec les clusters Exchange, une pulsation doit être maintenue entre systèmes toutes les 500 millisecondes. Si un nœud secondaire ne reçoit pas cette pulsation, il peut déclencher le démarrage d’un basculement.
La complexité de gestion de tels défis peut constituer la raison pour laquelle Microsoft effectue seulement maintenant son entrée dans ce domaine, avec Exchange 2007. En l’absence de Microsoft, plusieurs solutions de fournisseurs tiers ont été développées pour répliquer les données à l’aide d’une réplication basée sur l’hôte ou sur la baie.
Les fournisseurs se sont rendu compte qu’ils pourraient étendre un cluster en dispersant des nœuds à des emplacements différents. On appelle ces clusters des « clusters distants ». Aujourd’hui, la méthode la plus courante pour la mise en œuvre de clusters distants consiste à utiliser les produits polyvalents de réplication de données de fournisseurs tiers ou ceux s’adressant plus particulièrement à l’extension de nœuds Exchange. Vous pouvez effectuer ceci avec MSCS, mais les exigences en termes de sous-réseau posent un défi sur un réseau étendu. L’utilisation de clusters et les complexités de fourniture d’une connectivité haute bande passante fiable aux centres de données distants augmentent le coût et l’effectif nécessaire pour la mise en place, la maintenance et le test périodique du système de récupération après incident.
Réplication continue en cluster
Microsoft a étendu sa prise en charge des clusters avec la réplication continue en cluster dans Exchange 2007. CCR étend la capacité de LCR à maintenir deux copies d’une base de données et des journaux de transactions Exchange pour mettre en application la même idée sur deux nœuds de cluster. La récupération après incident implique la séparation géographique des systèmes primaire et secondaire, et les clusters multicopies Microsoft (MCC) ne pourront pas couvrir de distances significatives avant que Windows Server 2008, d’ancien nom de code « Longhorn », ne rende possibles les clusters distants.
La technologie qui permet aux nœuds MCC de disposer de copies séparées des données porte le nom de jeu de nœuds majoritaire (MNS), qui fait référence au processus d’élection mené par deux nœuds ou plus pour déterminer celui abritant la copie directe des données. Lorsqu’une défaillance survient, les nœuds restants organisent une nouvelle élection pour déterminer celui qui prendra le relais en tant que nouveau serveur principal de traitement/données. Cette démocratie technique s’appuie sur CCR, qui s’assure que chaque nœud dispose d’une base de données à jour. Les clusters Exchange 2007 utilisant CCR sont limités à deux nœuds seulement.
Dans les plus grandes configurations, les serveurs Exchange configurent généralement le disque système local sur le serveur même et se connectent ensuite à la base de données Exchange sur un réseau de zone de stockage avec baies de disques SCSI, fibre optique ou iSCSI. Avec un cluster MCC/MNS, il est intéressant de se demander si le stockage Exchange haut de gamme reviendra à l’utilisation de baies RAID locales pour chaque nœud. Si le but d’un cluster MNS est de permettre à chaque nœud d’avoir son propre stockage séparé, est-il toujours judicieux de faire pointer chaque nœud vers un réseau de zone de stockage dont le but principal est de fournir un stockage commun ?
Un scénario de cluster MCC/MNS modéré consisterait en un nœud principal avec stockage sur le réseau de zone de stockage et un nœud de cluster secondaire avec des disques locaux ou un réseau de zone de stockage iSCSI à moindre coût. Ce nœud secondaire pourrait être distant par rapport au centre de données principal, dans un emplacement ne disposant pas d’infrastructure de réseau de zone de stockage.
Quel qu’en soit le résultat, MCC utilisant MNS et CCR constitue une étape positive dans la hiérarchie de redondance et améliore la disponibilité car plusieurs ordinateurs sont capables d’effectuer le basculement et les données sont répliquées sur des éléments de stockage séparés. Ceci se limite toutefois toujours à un centre de données unique, jusqu’à ce que Windows Server 2008 soit disponible. Windows Server 2008 prendra en charge de manière native les clusters distants, permettant ainsi aux nœuds d’un cluster MNS d’être aussi géographiquement éloignés que voulu, pourvu que la latence entre les nœuds soit fiable et inférieure à 500 ms. Jusque là (et également après), la technologie de cluster de fournisseurs tiers peut s’ajouter à Microsoft MNS et CCR pour fournir la séparation géographique nécessaire aux clusters distants pour constituer une solution de récupération après incident efficace.
La mise en clusters se situe en fin de processus de récupération après incident. La réplication continue en cluster devient alors une fonctionnalité haute disponibilité d’Exchange. Et bien que cette combinaison induise un supplément en matière de coût comme d’effectif, elle promet d’être une solution haut de gamme intéressante pour les clients qui veulent travailler dans un environnement Microsoft homogène.
Continuité fonctionnelle distante de fournisseurs tiers
Il ne fait aucun doute que la solution de Microsoft et les extensions des fournisseurs tiers occuperont l’extrémité du continuum de récupération lorsqu’elle sera disponible. Un basculement automatique en quelques secondes : il est difficile d’obtenir mieux. Pourtant, toutes les entreprises ne nécessitent pas un tel niveau de disponibilité et de continuité commerciale, et ne sont pas non plus prêtes à investir les centaines de milliers d’euros nécessaires à leur mise en place. Pour beaucoup d’entreprises, une solution fiable restaurant complètement Exchange en quelques minutes offrira toute la continuité fonctionnelle qu’elles nécessitent.
Par exemple, Mimosa Systems, Inc. étend la continuité opérationnelle dans un centre de données unique à la continuité à distance. Dans un emplacement distant, la récupération après incident de Mimosa abrite une copie d’Exchange, la conserve à jour avec les journaux de transactions envoyés par le serveur Exchange principal et est toujours prêt à mettre cette copie directe à la disposition de votre serveur Exchange en mode d’attente. Le serveur Exchange distant utilise un matériel de serveur standard et, tout comme pour la mise en œuvre avec centre de données unique, vous le conservez toujours en cours d’exécution et prêt à être activé en cas d’urgence. En cas d’urgence, un opérateur du site distant démarre le basculement et l’exécute, y compris en montant les fichiers de base de données en mode d’attente et en remappant les boîtes aux lettres et profils Outlook. Il est toutefois à noter que de telles solutions de fournisseurs tiers sont soumise aux limites de support décrites dans l’article de la base de connaissances ayant trait à la stratégie de support de Microsoft pour les produits modifiant ou extrayant le contenu des bases de données Exchange.
Conclusion
La protection des informations d’Exchange est disponible sous la forme d’un continuum de technologies et de procédures qui peut être découpé en trois niveaux en fonction du coût et des capacités. Lorsque vous commencez à réfléchir à leurs exigences pour la protection des informations d’Exchange, vous devez prendre en compte le temps d’inactivité que vos preneurs de décisions sont capables de tolérer. De meilleures performances et une récupération plus rapide auront un coût plus élevé, les options haut de gamme s’élevant à plusieurs centaines de milliers d’euro. Des solutions plus abordables existent qui approchent les plus hauts niveaux de disponibilité sans les atteindre tout à fait. Les choix que vous effectuez doivent refléter les besoins véritables de votre organisation.
Service Pack 1 pour Exchange 2007
Actuellement soumis à des tests bêta, le Service Pack 1 (SP1) pour Exchange 2007 est prévu pour inclure plusieurs fonctionnalités qui manquaient aux administrateurs, dont des améliorations d’OWA, des capacités d’interface utilisateur graphique supplémentaires dans la Console et bien plus encore.
Revêtant un intérêt particulier pour les administrateurs planifiant les solutions de récupération, Exchange 2007 SP1 inclut également une troisième solution de disponibilité pour accompagner LCR et CCR : la réplication continue secondaire (SCR). Il s’agit d’une approche intermédiaire et Microsoft s’attaque avec celle-ci au sujet épineux de la récupérabilité importante, sans la complexité de la "haute disponibilité" complète.
La SCR permettra la réplication de la base de données Exchange et de ses journaux des transactions sur un serveur Exchange différent de celui sur lequel vos boîtes aux lettres résident habituellement. La cible de SCR peut être locale ou distante et peut être un serveur Exchange placé en attente ou un cluster. Cependant, SCR ne nécessite pas de cluster à l’un de ces emplacements et diffère de CCR en ceci que la cible est un environnement placé en mode d’attente et que le basculement est un processus manuel. Notez que vous devez toujours transférer une première copie de taille importante sur le réseau : pour simplifier, une sauvegarde complète. Vous pouvez avoir besoin d’effectuer cette réplication conséquente de temps à autres et devez être conscient de l’impact sur votre réseau, comme avec les solutions CCR et de fournisseurs tiers. Je pense que SCR et CCR seront adoptés par une grande majorité, tout comme les produits complémentaires offrant des capacités similaires et parfois supérieures.
Lee Benjamin dirige ExchangeGuy Consulting Services. Il travaille directement avec les clients et conseille les partenaires Microsoft. Lee est président du plus grand groupe d’utilisateurs d’Exchange au monde, ExchangeServerBoston, et l’un des directeurs du BostonUserGroups. Lee est également MVP Exchange, Microsoft Certified Trainer et orateur régulier aux conférences de l’industrie.
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.