[Source] Haute disponibilité dans SQL Server (1) ---- un aperçu de la haute disponibilité

Depuis SQL Server 2005, Microsoft propose une variété de technologies à haute disponibilité pour réduire les temps d’arrêt et améliorer la protection des données professionnelles, et avec la sortie continue de SQL Server 2008, SQL Server 2008 R2 et SQL Server 2012, de nombreuses technologies de haute disponibilité dans SQL Server sont disponibles pour répondre à différents scénarios.

    Avant de commencer cet article, je vais donner un bref aperçu de ce qui détermine quelle technologie de haute disponibilité utiliser.

    De nombreuses entreprises ont besoin que toutes ou partie de leurs données soient très disponibles, comme les sites de shopping en ligne, les bases de données de produits en ligne doivent être en ligne 24h/24 et 7j/7, sinon dans un marché très concurrentiel, les arrêts signifient la perte de clients et de revenus. Par exemple, dans un centre d’appels qui dépend de SQL Server, si la base de données tombe, tous les appelants ne peuvent que répondre au client « Désolé, défaillance système », ce qui est également inacceptable.

    Bien sûr, dans un monde idéal, toutes les données critiques seraient en ligne en permanence, mais dans la réalité, il y aura diverses raisons pour lesquelles la base de données est indisponible, car il est impossible de prédire le moment et la forme de la catastrophe, il est nécessaire de prendre des mesures à l’avance pour prévenir diverses urgences, donc SQL Server propose une variété de technologies de haute disponibilité, qui incluent principalement : le clustering, la réplication, le miroirement, la livraison de journaux, les groupes de disponibilité AlwaysOn et d’autres comme la sauvegarde et la restauration par groupes de fichiers, Des technologies à haute disponibilité à instance unique telles que les index de reconstruction en ligne. L’utilisation d’une technologie à haute disponibilité ne consiste pas à choisir une technologie familière pour un usage direct, mais à considérer l’entreprise et la technologie de manière globale. Parce qu’il n’existe pas de technologie unique capable d’atteindre toutes les fonctions. La manière d’adopter ces technologies en fonction de votre entreprise et de votre budget spécifique est ce qu’on appelle une stratégie de haute disponibilité.

Lors de la conception d’une stratégie de haute disponibilité, vous devez d’abord prendre en compte les facteurs suivants :

• RTO (Objectif de temps de récupération) - c’est-à-dire l’objectif de temps de récupération, signifie combien de temps d’arrêt est autorisé, généralement exprimé par quelques 9 secondes, par exemple, une disponibilité de 99,999 % signifie pas plus de 5 minutes d’arrêt par an, une disponibilité de 99,99 % signifie un maximum de 52,5 minutes d’arrêt par an, et une disponibilité de 99,9 % signifie un maximum de 8,75 heures d’arrêt par an. Il convient de noter que la méthode de calcul de l’TO prend en compte si le système est disponible 24*365 ou simplement de 6h à 21h, etc. Il faut aussi faire attention à savoir si la fenêtre de maintenance est prise en compte comme un temps d’arrêt, et il est plus facile d’obtenir une plus grande disponibilité si la maintenance et le patching de la base de données sont autorisés pendant la période de maintenance.
• RPO (objectif point de récupération) – Également appelé objectif point de récupération, cela signifie combien de perte de données est autorisée. En général, tant que vous faites une bonne sauvegarde, vous pouvez facilement obtenir une perte de données nulle. Mais lorsqu’une catastrophe survient, selon l’étendue de la corruption de la base de données, le temps nécessaire pour restaurer les données à partir d’une sauvegarde rendra la base de données indisponible, ce qui affectera la mise en œuvre du RTO. Un exemple précoce et plus célèbre est un système bancaire en Europe et aux États-Unis, uniquement en tenant compte du RPO, il n’y a que des sauvegardes complètes et des sauvegardes de journaux dans le système, des sauvegardes complètes tous les 3 mois, des sauvegardes de journaux toutes les 15 minutes ; en cas de catastrophe, ce n’est qu’avec des sauvegardes complètes et des sauvegardes de journaux que les données peuvent restaurer, donc bien qu’il n’y ait pas de perte de données, comme la restauration des données a pris deux jours complets, le système bancaire est resté indisponible pendant 2 jours, ce qui a fait perdre un grand nombre de clients. Un autre exemple opposé est un site vidéo en ligne domestique, utilisant SQL Server comme base de données relationnelle en arrière-plan, le front-end utilise No-SQL, et importe régulièrement des données No-SQL dans la base de données relationnelle en tant que sauvegarde.
  

    Budget – RTO et RPO sont collectivement appelés SLA (Accords de Niveau de Service), et lors de la conception d’une stratégie de haute disponibilité, il faut mesurer la qualité des SLA selon votre entreprise, en fonction de votre budget et en mesurant le coût des différents SLA en cas de défaillance. De manière générale, il est difficile d’atteindre des SLA élevés avec un budget limité, et même si des SLA élevés sont obtenus grâce à des architectures complexes, ces architectures impliquent aussi des coûts élevés d’exploitation et de maintenance, il est donc nécessaire de choisir la bonne technologie dans le budget pour respecter les SLA.

Ainsi, en général, le cadre large pour une haute disponibilité peut être déterminé par plusieurs questions de prise d’ordre :

• Quel est le temps d’arrêt que les actionnaires sont prêts à accepter ?
• Quels temps d’arrêt sont acceptables pour les managers ?
• Quel est le budget prévu pour un scénario à haute disponibilité ?
• Quelle est la perte par heure due aux temps d’arrêt ?
  

• Sauvegarde à froid : Le serveur de veille est configuré pour accepter les données du serveur principal et, en cas de défaillance, restaurer manuellement les données dans la base de données principale, ou reconfigurer la chaîne de connexion ou les permissions du programme pour mettre en ligne la base de données de sauvegarde.
• Sauvegarde chaude : Les données du serveur principal transmettront continuellement des journaux au serveur de sauvegarde (à des intervalles irréguliers, cela peut être 15 minutes, 30 minutes, 1 minute, etc.), de cette façon, le serveur principal vers le serveur de sauvegarde est généralement mis à jour de manière asynchrone, de sorte que les données du serveur principal et du serveur de sauvegarde ne peuvent pas être garanties. De plus, ce schéma ne met généralement pas en œuvre la surveillance automatique des pannes ni le basculement automatique.
• Sauvegarde à chaud : Les données du serveur principal sont automatiquement synchronisées sur le serveur de sauvegarde, et dans la plupart des cas, la surveillance automatique des pannes et le basculement sont inclus, garantissant la cohérence des données entre le serveur principal et le serveur de sauvegarde.
  

    Avec les sauvegardes froides à chaudes et chaudes, les coûts explosent.

    Les fonctionnalités de haute disponibilité prises en charge par SQL Server sont étroitement liées à la version, et l’édition Enterprise prend en charge toutes les fonctionnalités de haute disponibilité, y compris :

• Cluster de basculement
• L Image de la base de données
• l Transmission du journal de transaction
• L Instantanés de bases de données
• Améliorations de haute disponibilité
• L Mémoire de charge chaude
• l Opérations d’indexation en ligne
• L Base de données partiellement en ligne (seuls le groupe de fichiers maîtres ou groupe de fichiers maîtres et les fichiers NDF supplémentaires sont restaurés)
  

    Pour des versions spécifiques dont la haute disponibilité est proposée, voir :http://msdn.microsoft.com/zh-cn/library/cc645993.aspxIl convient de noter que la version Express gratuite peut servir de serveur témoin pour la mise en miroir de base de données, ce qui permet d’économiser des coûts.

Cluster de basculement

    Les clusters de basculement offrent un support de haute disponibilité pour l’ensemble de l’instance SQL Server, ce qui signifie qu’une instance SQL Server sur un nœud du cluster bascule vers d’autres nœuds du cluster en raison d’erreurs matérielles, de systèmes d’exploitation, etc. La haute disponibilité est assurée par le partage d’un ou plusieurs disques par plusieurs serveurs (nœuds), et les clusters de basculement apparaissent dans le réseau de la même manière qu’un seul ordinateur, mais avec des caractéristiques de haute disponibilité. Il est important de noter que, puisque les clusters de basculement sont basés sur des disques partagés, il existe un point unique de défaillance du disque, donc des protections supplémentaires telles que la réplication SAN doivent être déployées au niveau du disque. Le cluster de basculement le plus courant est un cluster de basculement à deux nœuds, incluant le maître et l’esclave.

Transmission du journal de transaction

    L’expédition des journaux de transaction offre une protection de haute disponibilité au niveau de la base de données. La journalisation est utilisée pour maintenir une ou plusieurs bases de données de veille (appelées « bases de données secondaires ») de la base de données de production correspondante (appelée « base de données primaire »). Avant qu’un basculement ne se produise, la base de données secondaire doit être entièrement mise à jour en appliquant manuellement toutes les sauvegardes de journaux non restaurées. La livraison de journaux offre la flexibilité de prendre en charge plusieurs bases de données de secours. Si plusieurs bases de données alternatives sont nécessaires, la livraison de journaux peut être utilisée séparément ou en complément du miroir de base de données. Lorsque ces solutions sont utilisées ensemble, la base de données principale de la configuration actuelle de miroir de base de données est également la base de données principale de la configuration actuelle de transport de journaux.

    La livraison des journaux de transactions peut être utilisée pour effectuer des sauvegardes à froid et à chaud.

Mise en miroir de base de données

    Le miroir de base de données est en réalité une solution logicielle qui offre également une protection au niveau de la base de données, offrant un basculement quasi instantané pour améliorer la disponibilité de la base de données. Un miroir de base de données peut être utilisé pour maintenir une base de données de secours unique (ou « base de données miroir ») pour la base de données de production correspondante (appelée « base de données principale »).
Comme la base de données miroir est toujours en état de restauration, mais que la base n’est pas restaurée, la base de données miroir ne peut pas être accessible directement. Cependant, pour les chargements en lecture seule comme les rapports, vous pouvez utiliser la base de données miroir indirectement en créant un instantané de la base de données miroir. Les instantanés de base de données offrent aux clients un accès en lecture seule aux données de la base lors de la création de l’instantané. Chaque configuration de miroir de base de données implique un « serveur principal » qui contient la base de données principale, et aussi un serveur miroir qui contient la base de données miroir. Le serveur miroir met à jour en continu la base de données miroir avec la base de données principale.
    Le miroir de base de données s’exécute en fonctionnement synchrone en mode haute sécurité ou en fonctionnement asynchrone en mode haute performance. En mode haute performance, les transactions n’ont pas besoin d’attendre que le serveur miroir écrive les journaux sur le disque avant de pouvoir être soumises, ce qui maximise les performances. En mode haute sécurité, les transactions engagées sont engagées par les deux partenaires, mais le délai de transaction est prolongé. La configuration la plus simple de miroir de base de données implique uniquement le serveur principal et le serveur miroir. Dans cette configuration, si le serveur principal est perdu, le serveur miroir peut être utilisé comme serveur de secours, mais cela peut entraîner une perte de données. Le mode haute sécurité prend en charge la configuration en veille, le mode haute sécurité avec basculement automatique. Cette configuration implique une instance de serveur tiers appelée « serveur témoin » qui permet au serveur miroir d’être utilisé comme serveur de sauvegarde à chaud. Le basculement de la base de données principale vers la base miroir prend généralement quelques secondes.

    Le miroirement de base de données peut être utilisé aussi bien pour les sauvegardes à chaud qu’à chaud.

copier

    La réplication n’est pas strictement une fonctionnalité conçue pour une haute disponibilité, mais elle peut s’appliquer à une haute disponibilité. La réplication offre une protection au niveau de l’objet de la base de données. La réplication utilise un modèle publie-abonnement, où les données sont publiées par le serveur principal, appelé l’éditeur, à un ou plusieurs abonnés secondaires. La réplication offre une disponibilité et une scalabilité en temps réel entre ces serveurs. Il prend en charge le filtrage pour fournir un sous-ensemble de données aux abonnés, tout en prenant en charge les mises à jour des partitions. L’abonné est en ligne et disponible pour des rapports ou d’autres fonctions sans récupération de requête. SQL Server propose quatre types de réplication : la réplication instantanée, la réplication transactionnelle, la réplication pair-à-pair et la réplication par fusion.

AlwaysOnGroupe d’utilisabilité

    AlwaysOn Availability Groups est une nouvelle fonctionnalité introduite dans SQL Server 2012. Une protection au niveau de la base de données est également fournie. Elle étend également la limite selon laquelle le miroir de base de données ne peut être qu'1:1, de sorte qu’une réplique primaire peut correspondre à jusqu’à 4 réplices secondaires (dans SQL Server 2014, cette limite est étendue à 8), dont 2 réplices secondaires peuvent être synchronisées en sauvegardes à chaud et répliques primaires en temps réel, et les deux autres réplices secondaires asynchrones peuvent être utilisées comme sauvegardes à chaud. De plus, les répliques secondaires peuvent être configurées en lecture seule et peuvent être utilisées pour prendre en charge la charge des sauvegardes.

    À cause de cela, le miroir de base de données est marqué comme « obsolète » dans SQL Server 2012.

    Après avoir compris les concepts de base de la haute disponibilité et les technologies de haute disponibilité fournies dans SQL Server, examinons la conception d’une stratégie de haute disponibilité. La planification d’une stratégie de haute disponibilité peut être divisée en quatre phases :

Exigences de récolte

    La première étape pour choisir une stratégie de haute disponibilité est sans aucun doute de rassembler les besoins métier pour établir des SLA. Le RTO et le RPO sont les parties les plus critiques, et sur cette base, il faut établir des attentes réalistes concernant les besoins de disponibilité et établir une stratégie de haute disponibilité réaliste basée sur ces attentes.

Limites d’évaluation

    Les limites d’évaluation ne se limitent pas seulement aux limitations des différentes technologies de haute disponibilité dans SQL Server, mais aussi à celles qui ne sont pas techniques. Si vous n’avez qu’un budget de dizaines de milliers de yuans, mais que vous souhaitez proposer une solution haute disponibilité basée sur des centres de données hors site et la réplication SAN, c’est sans aucun doute un rêve ingenu. Une autre limitation non technique est le niveau du personnel des opérations, et souvent, des architectures complexes signifient un personnel opérationnel plus qualifié. D’autres limitations non techniques incluent la disponibilité de l’espace disque dans le centre de données, la capacité de l’alimentation électrique et de la climatisation à répondre aux besoins, ainsi que le temps nécessaire pour mettre en œuvre la stratégie de disponibilité.

    Les limitations techniques incluent différentes fonctions et limitations de haute disponibilité, des fonctions prises en charge par différentes versions de SQL Server, le nombre de processeurs et la taille de la mémoire. Il est fortement recommandé de vous référer d’abord aux limitations des différentes versions et fonctionnalités de SQL Server sur le site MSDN de Microsoft avant de mettre en place une politique de haute disponibilité.

Technologie sélectionnée

    Après avoir rassemblé les exigences et évalué les contraintes, l’étape suivante consiste à sélectionner les technologies ou la combinaison de technologies décrites précédemment dans cet article pour répondre aux exigences de la LS. Si la technologie sélectionnée ne respecte pas le SLA, il est facile de signaler quelles limitations ne respectent pas le SLA, ce qui vous permet de demander des ressources manquantes ou de compromettre le SLA.

Tester, valider et documenter

    Les politiques de haute disponibilité doivent être rigoureusement testées et validées dès le départ afin de garantir que les politiques de disponibilité actuelles respectent les SLA. Cependant, lorsqu’une stratégie de haute disponibilité est lancée, il est également nécessaire de la tester et de la valider régulièrement afin de s’assurer que la politique actuelle peut toujours respecter les SLA malgré la croissance des données, les changements d’activité ou les besoins. En même temps, la configuration de la solution de disponibilité, la méthode de basculement et le plan de reprise après sinistre doivent être documentés en même temps afin de pouvoir être tracés en cas de défaillance ou d’ajustement futur de la stratégie de haute disponibilité.

Cet article explique les concepts de base de haute disponibilité, le concept de SLA, les différents types de fonctionnalités de haute disponibilité prises en charge par SQL Server, ainsi que les étapes nécessaires pour concevoir une stratégie de haute disponibilité. Il convient de noter que, bien que cet article ne parle que de haute disponibilité au niveau de la base de données, la haute disponibilité n’est pas seulement une question de DBA, mais inclut aussi la collaboration de différents rôles tels que le personnel d’exploitation et de maintenance système, les administrateurs réseau, les développeurs et les managers pour mieux respecter les SLA.