La planification et le déploiement d'un plan de haute disponibilité et de reprise après sinistre qui respecte tous les accords de niveau de service est une entreprise non négligeable et nécessite une compréhension très claire des forces et des faiblesses natives de SQL Server. Lors de la mise en correspondance des exigences avec une combinaison de fonctionnalités, certains des détails critiques peuvent être passés sous silence, et dans cet article, je vais passer en revue quelques distorsions courantes et de mauvaises hypothèses qui peuvent se glisser dans une solution - nous faisant finalement rater la cible sur nos objectifs de point de récupération et de temps de récupération. Certains des exemples de distorsions ou d'auto-illusions que je détaille ici peuvent être généralisés à différentes fonctionnalités et certains sont spécifiques à une fonctionnalité.
"Nous avons testé notre plan de reprise après sinistre lorsque nous avons lancé notre projet pour la première fois et nous savons qu'il fonctionnera"
J'ai travaillé avec des clients qui ont en effet réussi leur approche de reprise après sinistre - une fois. Mais une fois que tout le monde s'est senti confiant dans l'efficacité de la solution, aucun autre exercice de reprise après sinistre n'a été effectué à nouveau. Bien sûr, entre-temps, le niveau de données et l'application ne cessent de changer au fil du temps. Ces changements introduisent de nouveaux objets et processus qui sont critiques pour l'application. Et même si tout reste statique après le lancement, vous devez toujours tenir compte du roulement du personnel et des compétences variables. Le personnel d'aujourd'hui peut-il réussir un exercice de reprise après sinistre ? Et même le meilleur personnel a besoin d'une pratique continue.
"Nous n'aurons aucune perte de données car nous utilisons la mise en miroir synchrone de la base de données"
Supposons que vous utilisiez la mise en miroir de base de données synchrone entre deux instances SQL Server, chaque instance se trouvant dans un centre de données distinct. Dans cet exemple, supposons que la latence de transaction est acceptable bien qu'il s'agisse d'une session de mise en miroir de base de données synchrone avec quelques kilomètres entre les centres de données. Vous n'avez pas de témoin dans le mélange car vous souhaitez contrôler manuellement le basculement du miroir de base de données.
Supposons maintenant que votre centre de données de reprise après sinistre disparaisse, mais que votre centre de données principal soit toujours disponible. Votre base de données principale est déconnectée de la base de données miroir, mais elle accepte toujours les connexions et les modifications de données. Qu'en est-il maintenant de l'exigence « aucune perte de données » ? Si les transactions s'exécutent sur le principal déconnecté pendant une heure supplémentaire, quel est votre plan si le centre de données principal est également perdu ?
"Le propriétaire de notre entreprise dit que nous pouvons perdre jusqu'à 12 heures de données"
Il est important de poser certaines questions plus d'une fois et à plus d'une personne dans une organisation. Si quelqu'un vous dit que "12 heures de perte de données sont acceptables", demandez-lui à nouveau ou demandez-lui quelle serait la conséquence de cette perte de données. Demandez également à d'autres personnes. Ils pourraient vous donner une exigence beaucoup plus stricte. J'ai constaté que les objectifs de point de récupération nécessitent quelques négociations et plus que quelques discussions réfléchies et délibérées.
"Nous utilisons [la mise en miroir de bases de données ou des groupes de disponibilité] et nous sommes donc couverts pour ce dont nous avons besoin en cas de sinistre"
La mise en miroir de bases de données et les groupes de disponibilité peuvent certainement être utilisés pour vous protéger au niveau de la base de données, mais qu'en est-il de tout le reste ? Qu'en est-il de vos identifiants ? Forfaits SSIS ? Emplois? Bases de données de modèle de récupération non COMPLÈTE ? Serveurs liés ?
"Nous utilisons la fonctionnalité XYZ de SQL Server, nous ne perdrons donc aucune transaction en cours"
Non désolé. Bien que certaines fonctionnalités permettent une redirection transparente, ce n'est pas la même chose que de conserver et de conserver les transactions ouvertes au moment du basculement. Aucune fonctionnalité SQL Server ne fournit cette fonctionnalité aujourd'hui.
"L'équipe prenant en charge le niveau de données pour cette application déteste la fonctionnalité XYZ de SQL Server, mais nous allons de l'avant car c'est ce qui nous a été recommandé par un consultant externe"
Bien qu'il serait bien que les gens ne développent pas de préjugés spécifiques autour des fonctionnalités de SQL Server, ce n'est souvent pas le cas. Si vous essayez d'imposer des solutions à un personnel qui n'est pas d'accord avec eux, vous courez le risque d'un échec prédéterminé. Dans le cadre des exercices HA/DR auxquels j'ai participé par le passé, je suis toujours intéressé à connaître les expériences passées des gens avec des fonctionnalités spécifiques. Par exemple, certaines entreprises exploitent très bien des centaines d'instances de cluster de basculement, tandis que d'autres les évitent en raison des mauvaises expériences des versions précédentes. Lors de la planification d'une solution, vous ne pouvez pas ignorer l'historique ou les prédispositions du personnel qui sera finalement responsable du déploiement et du support de la solution recommandée.
"En tant qu'administrateur de base de données, je décide de la technologie HA/DR à utiliser pour le niveau de données, nous allons donc utiliser des groupes de disponibilité à l'avenir"
Un administrateur de base de données peut potentiellement configurer la mise en miroir de bases de données avec peu ou pas d'implication avec d'autres équipes. Désormais, avec les groupes de disponibilité, même si un administrateur de base de données pouvait tout faire par lui-même, il pourrait être imprudent de le faire. Après tout, si vous déployez des groupes de disponibilité à des fins de reprise après sinistre, vous souhaiterez que toutes les personnes impliquées dans une opération de reprise après sinistre connaissent votre solution et les exigences nécessaires pour réussir à se remettre en ligne et à récupérer les données. Avec les groupes de disponibilité, vous devrez penser au cluster de basculement Windows Server, aux configurations de quorum, aux votes des nœuds, à l'écouteur du groupe de disponibilité, etc. Si vous avez besoin d'autres personnes pour faciliter une solution, assurez-vous qu'elles sont impliquées dans la recommandation initiale.
"Nous utilisons des groupes de disponibilité afin d'avoir une disponibilité en lecture seule en cas de panne de notre réplique en lecture-écriture"
Ceci n'est qu'un exemple d'un scénario « et si ». Avec toute implémentation de fonctionnalité, vous voudrez imaginer les différentes manières dont une défaillance peut se produire, puis assurez-vous de la tester pour vous assurer que vos exigences sont toujours satisfaites. Par exemple, si vous pensez que les réplicas en lecture seule asynchrones de votre groupe de disponibilité SQL Server 2012 seront disponibles lorsque le réplica en lecture-écriture ne sera pas disponible, vous serez désagréablement surpris de voir le Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections message en production.
"Nous avons testé la fonctionnalité XYZ de SQL Server et le basculement a été rapide, nous avons donc établi que nous pouvons facilement atteindre nos objectifs de temps de récupération"
Supposons que vous décidiez d'utiliser la mise en miroir de bases de données pour une haute disponibilité au niveau de la base de données utilisateur. Vous voulez un basculement rapide (mesuré en secondes), et vous voyez en effet un basculement rapide pendant les tests. Mais était-ce un test réaliste ? Poussiez-vous une charge de travail importante? Dans l'exemple de la mise en miroir de bases de données, la partie la plus longue de votre opération de basculement peut concerner les opérations de rétablissement. Si vous ne gérez pas des charges de travail réalistes, vous ne pouvez pas vraiment dire que votre basculement sera réellement "rapide".
"Si nous avons une catastrophe et que nous devons récupérer et réconcilier les données, nous nous en occuperons le moment venu"
Ceci est une question difficile. Supposons que vous subissiez un sinistre et que vous deviez rendre votre centre de données secondaire opérationnel. Vous décidez de forcer le service pour les bases de données les plus critiques dans le centre de données secondaire et vous avez maintenant une division dans la lignée des modifications de données (certaines lignes non rapprochées dans le centre de données principal, et maintenant de nouvelles modifications dans le centre de données secondaire). Finalement, votre centre de données principal est mis en ligne, mais vous avez maintenant des données qui doivent être récupérées et réconciliées avant de pouvoir rétablir la solution HA/DR globale. Que fais-tu? Que pouvez-vous faire? Cette discussion est rarement facile à avoir et peut dépendre de plusieurs facteurs tels que les progiciels que vous avez achetés, la complexité de la couche de données et les outils de convergence des données à votre disposition. En fait, la discussion est généralement si difficile que les gens ne l'ont pas du tout. Mais si les données sont suffisamment critiques pour que vous ayez mis en place un centre de données secondaire, une partie clé de la discussion devrait inclure la meilleure façon de récupérer les données et de les réconcilier après une catastrophe.
Résumé
Cet article ne comprenait que quelques exemples de la façon dont nous pouvons nous leurrer en pensant qu'une solution répond pleinement à leurs exigences. Bien qu'il soit dans la nature humaine de le faire - en ce qui concerne la perte de données et la continuité des activités, nos emplois dépendront de notre capacité à tester plus agressivement nos propres croyances et hypothèses.
