> Data > Synchronisation à  la demande

Synchronisation à  la demande

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Gary Zaika - Mis en ligne le 05/04/2006 - Publié en Février 2005

Après l’attaque du World Trade Center, le 11 septembre 2001, nombre d’organisations ont reconsidéré leur approche de la gestion et de la protection des données d’entreprise stratégiques. La mise en place d’un centre de traitement distant avec un deuxième ensemble de bases de données et de serveurs d’applications est devenue une pratique courante. Les entreprises ont accepté de supporter le coût du personnel et des centres de traitement supplémentaires, ainsi que des modifications dans la conception des applications afin de pouvoir basculer les opérations rapidement vers un autre emplacement en cas de sinistre. Par exemple, après les attaques du 11 septembre, une grande banque pour laquelle j’ai travaillé récemment comme consultant Microsoft Consulting Services a commencé à demander la configuration suivante, à savoir la possibilité d’exécuter toutes les applications cruciales à partir de l’un ou l’autre de deux sites distants de plusieurs centaines de kilomètres, sans induire une interruption du fonctionnement supérieure à 2 heures.Ces exigences économiques plus strictes constituent un défi pour les architectes de bases de données. La majorité des bases de données des organisations ne cessent de croître, mais les fenêtres admissibles pour la maintenance et les interruptions de fonctionnement sont réduites au minimum. Les bases de données doivent offrir une disponibilité maximale et être prêtes à fonctionner dans des environnements distribués, et les données des bases de données principales (l’éditeur ou publisher) et secondaires (l’abonné ou subscriber) doivent rester synchronisées en permanence.

Plusieurs solutions prennent en charge la haute disponibilité pour les bases de données SQL Server 2000 réparties sur différents sites, notamment l’envoi des journaux, les solutions matérielles et logicielles tierce partie telles que les clusters géographiques ou la solution de réplication distante du stockage SRDF d’EMC, ou encore la réplication transactionnelle. Dans la plupart des solutions de haute disponibilité, l’abonné est partiellement ou complètement indisponible pendant la synchronisation des données. Par exemple, dans le cas de l’envoi des journaux, la base de données de l’abonné est accessible en lecture seule uniquement si aucun nouveau journal des transactions n’est appliqué. Avec la solution matérielle SRDF onéreuse, la base de données de l’abonné n’est jamais disponible ; elle ne le devient que pour la restauration des données en cas d’arrêt de la base de données de l’éditeur. Seule la réplication transactionnelle permet d’utiliser pleinement la base de données de l’abonné en permanence. Cette solution est disponible dans toutes les éditions de SQL Server, d’où la possibilité d’éviter les dépenses supplémentaires liées à l’achat de logiciels tierce partie, tout en exploitant au maximum les plates-formes matérielles en place. C’est la raison pour laquelle de nombreuses entreprises ont retenu la réplication transactionnelle comme solution de haute disponibilité.

Néanmoins, cette approche ne résout pas automatiquement le problème de la synchronisation des données. La mise en place et la gestion de cette solution requiert des processus métier performants et une équipe de DBA particulièrement compétents. Nous allons, dans cet article, examiner le problème de disponibilité élevée auquel la banque pour laquelle j’ai travaillé a été confrontée lors de la mise en oeuvre de la réplication transactionnelle et de la synchronisation permanente des données. Nous verrons également comment j’ai résolu le problème en employant une nouvelle méthode que j’ai appelée « réplication forcée ».

Synchronisation à  la demande

L’utilisation de la réplication pour les bases de données extrêmement volumineuses est loin d’être simple, dès lors qu’une entreprise souhaite pouvoir basculer ses opérations vers un deuxième site dans des délais très brefs. Le personnel chargé des bases de données doit être certain que les données sont synchronisées en permanence et ils ont généralement très peu de temps pour résoudre tous les problèmes survenant lors d’un sinistre.

Plusieurs scénarios possibles dans la réplication transactionnelle sont susceptibles d’entraîner une désynchronisation des données entre l’éditeur et l’abonné, ce qui peut s’avérer problématique pour l’entreprise en cas de sinistre. Par exemple, le distributeur distant (le serveur qui stocke les métadonnées et les données d’historique et conserve temporairement les transactions répliquées) peut se bloquer et, pour des raisons économiques, l’entreprise ne peut pas arrêter immédiatement l’entrée de nouvelles données sur l’éditeur (comme c’est le cas avec notre banque). L’éditeur continuera alors d’accumuler de nouvelles données et les bases de données sur celui-ci et sur l’abonné seront désynchronisées. Autre possibilité, un abonnement peut expirer, pour une raison ou une autre (par exemple, en cas de défaillance de l’agent de réplication), auquel cas les modifications sur l’éditeur ne seront pas propagées vers l’abonné.

Enfin, un utilisateur peut, par inadvertance ou intentionnellement, exécuter une commande DELETE sur l’abonné et supprimer les données déjà propagées. Dans ce cas, l’abonné aura quelques enregistrements de moins que l’éditeur. Si vous employez la réplication transactionnelle, vous avez probablement déjà rencontré au moins une fois cette situation.

Pour éviter la désynchronisation des données, la banque m’a demandé de développer un mécanisme de synchronisation des données en ligne pour le système bancaire qui réplique deux bases de données extrêmement volumineuses (d’une taille combinée de près de 500 Go) d’un serveur situé à New York vers un autre implanté dans l’Etat du Delaware, comme l’illustre la figure 1. Par ailleurs, chaque site comporte des serveurs de reporting contenant les mêmes données de reporting, à savoir un sous-ensemble des données des deux grandes bases de données. Dans les situations d’urgence, la banque doit pouvoir basculer le chargement des données du serveur de New York vers celui du Delaware et inverser le flux des données de réplication entre les deux serveurs OLTP (à savoir, du serveur du Delaware vers celui de New York). Dans le plan de réplication d’origine de la banque, une tâche planifiée s’exécute toutes les heures afin de comparer le nombre d’enregistrements dans les tables correspondantes de l’éditeur et de l’abonné.

Naturellement, l’algorithme de la tâche prend en compte la latence de livraison. Si la tâche détecte une incohérence dans les bases de données, la banque doit immédiatement synchroniser les données.

Pour accomplir cette synchronisation rapide, je ne pouvais pas me servir des techniques classiques telles que l’application de captures instantanées de réplication, la technique de sauvegarde et restauration traditionnelle, ou encore l’utilisation de DTS (Data Transformation Services). Comme une capture instantanée requiert la copie de toutes les données et non seulement de la partie dont vous avez besoin, la préparation et l’application de captures instantanées pour des bases de données volumineuses au moyen de l’Agent de capture instantanée de la console SQL Server Enteprise Manager peut prendre des heures, voire plusieurs jours et c’est un luxe que la banque ne peut pas se permettre. Celle-ci doit synchroniser uniquement les données qui ont changé depuis la dernière exécution réussie de la tâche planifiée, ce qui correspond à seulement quelques heures de nouvelles informations. La préparation d’une capture instantanée spéciale des tables concernées, lesquelles contiennent des centaines de milliers de lignes, constituerait également un gaspillage de temps et de ressources.

La technologie de sauvegarde et restauration traditionnelle serait tout aussi inefficace car elle remplacerait l’intégralité de la base de données de l’abonné par les informations de l’éditeur, ce qui serait inapproprié dans le cas du serveur de reporting. En effet, les serveurs de reporting de la banque ne contiennent qu’un sous-ensemble des tables répliquées des serveurs OLTP, avec quelques tables supplémentaires pour le reporting. Une autre raison pour laquelle je ne pouvais pas utiliser cette approche tient au fait qu’une telle restauration nécessite un accès exclusif à l’abonné. Si l’éditeur acceptait de nouvelles données pendant la restauration, Cela entraînerait une nouvelle désynchronisation immédiate des données. Mais la banque ne pouvait pas se permettre d’arrêter l’éditeur.

Nous ne pouvions pas non plus recourir à l’Assistant Importation/exportation DTS (DTS Import/Export Wizard). Ce dernier donne la possibilité d’utiliser une requête pour spécifier les données à transférer, afin de copier vers l’abonné un ensemble des données de l’éditeur. Dans ce cas, vous devez toutefois recréer les tables de destination, sinon DTS ajoute les données que vous restaurez aux tables existantes. L’ajout de lignes peut créer des doublons sur l’abonné si la requête ne définit pas exactement toutes les lignes manquantes. Par ailleurs, avec DTS, vous devez spécifier une requête pour chaque table et cette tâche peut s’avérer énorme si la synchronisation concerne de nombreuses tables. De même, la tâche peut devenir encore moins conviviale si vous avez plusieurs abonnés (ce qui est le cas de notre banque) et l’assistant doit s’exécuter plusieurs fois. Tous ces facteurs justifiaient la nécessité d’une nouvelle approche pour la banque.

C’est pourquoi j’ai élaboré et mis en oeuvre avec succès une méthode que j’ai dénommée « réplication forcée ». Cette technique permet de synchroniser les données entre des articles sélectionnés sans avoir à arrêter les opérations en ligne sur l’éditeur et les abonnés, et vous pouvez planifier la réplication forcée afin qu’elle s’exécute quand bon vous semble. Cette méthodologie peut être appliquée à n’importe quel système de base de données qui utilise la réplication transactionnelle, mais elle est tout particulièrement avantageuse pour les applications qui fonctionnent avec des bases de données volumineuses (100 Go ou supérieures) et qui nécessiteraient trop de temps pour la synchronisation des données au moyen de captures d’instantanés ou d’autres méthodes de sauvegarde et restauration.

Téléchargez gratuitement cette ressource

Comment cerner la maturité digitale de votre entreprise ?

Comment cerner la maturité digitale de votre entreprise ?

Conçu pour les directions IT et Métiers, ce guide vous permettra d'évaluer précisément vos processus de communication client, d'identifier vos lacunes et points d'inflexion pour établir un plan d’actions capable de soutenir durablement votre évolution. Bénéficiez maintenant d'une feuille de route complète.

Data - Par iTPro.fr - Publié le 24 juin 2010