Quel quorum de cluster choisir ? Dans quelle situation ? Je dois utiliser des réplicas en lecture seule ? Quels sont les impacts ? Que dois-je surveiller sur mon infrastructure ? Quels outils à disposition pour troubleshooter d’éventuels problèmes SQL Server AlwaysOn ou du cluster Windows ? Autant de questions auxquelles nous répondrons au cours de cette session. Session présentée lors du SQLSaturday Paris 2014
6. Agenda
Cluster Windows WSFC et interaction
avec les groups de disponibilités
Groupes de disponibilités – Réplication
Groupes de disponibilités – Réplicas
secondaires
SQLSaturday 323 – Paris 2014
7. SQL Server AlwaysOn et les groupes de
disponibilités : Architecture globale
SQLSaturday 323 – Paris 2014
8. Cluster à basculement Windows
Cluster
• Groupe indépendant d’ordinateurs travaillant ensemble pour augmenter la
disponibilité d’une application
• 2 ressources associées par défaut : un nom virtuel (VNN) et une adresse
IP virtuelle (VIP)
Ressource
• Composant physique ou logique
• Peut être mis en ligne / hors ligne
• Hébergé par un seul noeud à la fois (propriétaire)
• Dépendances de ressources
• Abstraction du service fourni gestion des ressources via des DLL
Groupes de ressources
• Collection de ressources
• Définit une unité de basculement
• Hébergé sur un noeud à la fois (propriétaire)
SQLSaturday 323 – Paris 2014
9. Cluster à basculement Windows - Quorum
Offre un mécanisme de protection contre le «split brain»
• Cluster divisé en plusieurs partitions distinctes
• Une seule partition active et arrêt des autres
Type de quorum
• Noeuds majoritaires
• Noeuds et disques majoritaires
• Noeuds et partage de fichiers majoritaires
• Aucune majorité : disque uniquement
Gestion des poids des noeuds
• Modifiable et statique à partir de Windows 2008 R2
• Dynamique depuis Windows 2012
SQLSaturday 323 – Paris 2014
Dois-je passer à
Windows Server
2012 ?
10. Cluster à basculement Windows – Sous
système d’hébergement des ressources
Groupe de disponibilité
Nom réseau
IP IP
SQL Server
hadrres.dll sp_server_diagnostics
SQLSaturday 323 – Paris 2014
RHS
Cluster Service
RCM
Communications
isAlive() / LooksAlive()
isAlive() / LooksAlive()
State / action
….
11. sp_server_diagnostics
< SQL Server 2012 @@SERVERNAME
améliore les capacités de diagnostique en cas de basculement
élimination des problèmes de connectivité
Procédure stockée interne associé à un thread préemptif à
haute priorité depuis la dll de ressources hadrres.dll
Possède sa propre réservation mémoire et non bloquant
Exécution toutes les 5 secondes (1/4 lease timeout)
Fournit des informations détaillées (system, resource,
query processing, IO subsystem, events)
Permet une plus grande flexibilité sur les règles de
basculement (5 niveaux)
SQLSaturday 323 – Paris 2014
12. Cluster à basculement Windows – RHS et
DLL de ressource SQL Server
RHS.exe (hadrres.dll)
AG1 AG2 AG3
Health
Worker
Health
Worker
SQLSaturday 323 – Paris 2014
Result Sets =
smallestTimeOut = max (5,
min (all active AAG) / 3)
sp_server_diagnostics
Dedicated thread
LOG
LeaseTimeOut
{SetEvent() / WaitForSingleObject()}
primary
13. Cluster à basculement Windows –
paramètre Lease Timeout
failover
unresponsive
AAG
responsive
Timeout
PRIMARY SEPCROIMNADRAYRY
Lease Split brain
SECONDARY
SQLSaturday 323 – Paris 2014
17. Groupes de disponibilités – réplicas
secondaires (en lecture seule)
Accès en lecture «réelle»
Redirection automatique via le listener
Snapshot isolation (SI) si réplica utilisé en lecture seule
-> impact stockage data + tempdb
Statistiques temporaires possibles
Plans de maintenance et sauvegarde
Impact d’une charge en lecture
SQLSaturday 323 – Paris 2014
18. Groupes de disponibilités et réplicas
secondaires en lecture seule – Démo
SQLSaturday 323 – Paris 2014
Notes de l'éditeur
VNN = Virtual Network Name
VIP = Virtual IP Address
DLL de ressources
Lorsque que le service de cluster effectue une requête à une ressource, le moniteur de ressources appelle la fonction d’entrée appropriée dans la dll de ressource et contrôle son état.
RCM (Resource Control Manager)
Responsable de l’implémentation des mécanismes et des règles de basculement du service cluster
Maintient l’arbre de dépendances pour chaque ressource
Gère l’état de chaque ressource (online, offline, failed, online pending, offline pending)
Actions = Move, Failover, Failback
RHS (Resource Host Manager
Héberge toutes les ressources en ligne du cluster (par défaut dans un seul processus / les ressources cores dans un processus distinct)
Exécute des routines de vérification à intervalle régulier (healthcheck IsAlive / LooksAlive spécifique à chaque type de ressource)
@@SERVERNAME vs sp_serverdiagnostics
Suppression des problèmes de connexion clients
Nouveau mécanisme utilisé des objets nommées en mémoire dans la mémoire partagée pour communiquer
sp_server_diagnostics resultset
System – Collecte les données du système tel que les spinlocks, les conditions sévères de traitement, des tâches non réalisées, fautes de pages et utilisation des processeurs
Resource – Collecte les données de ressources concernant la mémoire physique et virtuelle, les buffer pools, pages, cache et autres objets de mémoire
Query Processing – Collecte les données dans une perspective de traitement des requêtes tels que les threads de travail, les tâches, les types d’attentes, les sessions consommatrices en CPU et les tâches bloquées
IO Subsystem – Collection les données relatives aux IO.
Events – Collecte les données des erreurs enregistrées sur le serveur incluant les données détaillées des exceptions des ring buffer, brokers de mémoire, manque de mémoire, ordonnanceur, buffer pool, spinlocks, sécurité and connectivité
Niveau de basculement
1 – Serveur arrêté (service ou bail de connexion au cluster WSFC du groupe de dispo dépassé
2 - Serveur qui ne répond pas (Instance sql qui ne se connecte pas au cluster ou healthcheck timeout du groupe de dispo dépassé) + niveau 1
3 – Erreurs critiques (spinlocks orphelins, violation d’accès en écriture sévère ou génération excessive de dump) + niveau 2 niveau par défaut
4 – Erreur modéré (manque de mémoire persistent dans le pool interne SQL Server) + niveau 3
5 – N’importe quelle condition d’échec (Epuisement des threads de travail, détection d’un deadlock insoluble) + niveau 4
Execution de sp_server_diagnostics ¼ leaseTimeOut (20secondes / 4) Possibilité de modifier mais non conseillé (Bob Ward)
Correction faite par (Bob Dorr) healthchecktimeout /3 n’est plus valable
Une seule exécution de sp_server_diagnostics par instance : Smallest TimeOut = max (5, min(All Active Ags for Same SQL Server Instance) / 3) On prend la plus petite valeur de HealthCheckTimeOut / LeaseTimeOut ? et on divise par 3 pour êtee sûr d’être à moins de 5 secondes
LeaseTimeOut :
Présent uniquement sur le primaire pour s’assurer de l’état de synchronisation entre un agg et le cluster Windows
Thread dédié et préemptif au même niveau de priorité que la plupart des threads systèmes Problème lease souvent associé à un problème général système
Bail de communication avec le cluster WSFC. En cas de dépassement le bail est considéré comme expiré et l’instance SQL Server empêche toute modification (Prévention contre split brain)
Log
Informations plus détaillées : ensemble d’événements étendues, fichiers tournants dans le répertoire LOG
Inclue les résultats de sp_server_diagnostics, du cluster et des décisions prises au travers des dll de ressources
SQLDIAG.xel, sessions system_health et AlwaysOn
Healthcheck Time_Out = 30000
Intervall of sp_server_diagnostics execution = Healthcheck Time_Out / 3
Smallest TimeOut = max (5, min(All Active Ags for Same SQL Server Instance) / 3)
LeaseTimeOut = HealthcheckTimeOut / 4
LeaseTimeOut :
Connection Timeout plus utilisé comme avec le mirroring (indication d’isolation d’un serveur)
Présent uniquement sur le primaire pour s’assurer de l’état de synchronisation entre un agg et le cluster Windows
Bail de communication avec le cluster WSFC. En cas de dépassement le bail est considéré comme expiré et l’instance SQL Server empêche toute modification (Prévention contre split brain)
Always On vs Mirroring
Mirroring utilise des threads dédiés par base de données
AlwaysOn utilise une file d’attente de commandes et un pool de travail pour les traiter
Log pool
Nouvelle structure depuis SQL Server 2012 qui permet de gérer les blocs de transactions en cache
Table hash qui se base sur le block ID / Database ID géré par chaque base de données
Permet à SQL Server d’avoir accès à un ensemble de blocs qui peuvent servir à différentes technologies de réplications
HadrThreadPool
Min pool size ~= Max databases « 2 (redo ou scan per database) + au moins 1 message handle (Max databases = bases de données actives à un instant t_)
Capé à max worker threads – 40 (sp_configure) /! Tâches permanentes non comptabilisés dans ce calcul /!
Traitement d’une requête synchrone
Le réplica secondaire établit une connexion au primaire via le point de terminaison (modèle pull)
Le secondaire initie une requête au primaire, en demandant les blocs de journaux à recevoir négociation entre le secondaire et primaire sur le LSN de départ et autres infos nécessaires
Démarrage du log scanner sur le primaire qui récupère les blocs à envoyer au secondaire. Bloc peut être retrouvé depuis le log cache ou le JT le cas échéant
Le thread redo / database démarré sur le secondaire pour traiter les blocs reçus du primaire et écrit sur disque sur le secondaire
Le secondaire envoie un message de progression au primaire à intervalle régulier (toutes les 3 messages depuis le primaire ou à chaque seconde). La réponse contient des infos sur l’état d’avancement et le dernier LSN écrit sur disque sur le secondaire
PS : La ressource associée au groupe de disponibilité est l’emplacement centrale pour maintenir les états synchronisation. Les niveaux de LSN (ainsi que l’état de synchronisation …) sont également répliqués de manière atomique par le cluster dans la base de registre de la ressource de groupe de disponibilité aussi longtemps que ce dernier est utilisé en amont du protocole WAL pour maintenir l’état d’un groupe de disponibilité (les modifications de registres sont portées avec toute action effectuée sur une base de données pour garantir la synchronisation entre la base de registre)
Au commit de la transaction
Sur le primaire une requête est effectuée écrire dans le JT les enregistrements relatifs au LSN du commit (FlushToLSN) bloc de transactions écrit et prêt à être envoyé au secondaire
Le log scanner récupère le blog et l’envoi au secondaire (en passant par le log bloc cracker)
Le bloc est traité depuis le secondaire et écrit sur disque. Le redo thread rejoue les enregistrements du bloc de manière asynchrone
Une réponse est envoyée depuis le secondaire sur la progression de traitement (contient le hardened LSN + redo LSN)
Afin de terminer le commit le bloc de transaction doit être écrit à la fois sur le primaire et sur le secondaire.
Accès en lecture quasi en temps «réelle»
Latence de réplication entre le primaire et secondaire
Performance du stockage concernant l’écriture des blocs de transactions dans le JT (hardening)
Vitesse d’exécution du thread REDO sur le secondaire
Redirection via le listener
Utilisation du paramètre supplémentaire applicationIntent=readonly
Utilisation du protocole TCP
Mise en place de routes en lecture
Snapshot Isolation
Ajout de 14 bytes supplémentaires pour chaque ligne de données sur le secondaire et le primaire
Row-versionning géré dans tempdb sur le secondaire
Utilisation d’autres niveaux d’isolation de transaction sont automatiquement changés SI
Read Uncommited SI
Read Committed SI
Repeatable Read SI
Snapshot Isolation SI
Serializable SI
Hints ignorés !!
Plans de maintenance et sauvegarde
Considérations sur la vérification d’intégrité et sauvegardes sur les secondaires
Sauvegarde complète possible (avec option copy_only)
Sauvegarde différentielle non supportée
Sauvegarde du journal possible (sans l’option copy_only)
Impact d’une charge en lecture seule
Activité en lecture seule peut consommer beaucoup de ressources CPU / IO impact sur le thread redo
Requêtes DDL peuvent bloquer le thread redo qui doit acquire un verrou de schéma Sch-M sur la table