SQLSaturday Paris 2014 - SQL Server AlwaysOn et les groupes de disponibilités en détail
•
1 j'aime•743 vues
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
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à SQLSaturday Paris 2014 - SQL Server AlwaysOn et les groupes de disponibilités en détail
Similaire à SQLSaturday Paris 2014 - SQL Server AlwaysOn et les groupes de disponibilités en détail (20)
Plus de GUSS
Plus de GUSS (20)
Dernier
Dernier (6)
SQLSaturday Paris 2014 - SQL Server AlwaysOn et les groupes de disponibilités en détail
- 1. SQL Server AlwaysOn Groupes de disponibilités en détail SQLSaturday 323 – Paris 2014
- 2. Rejoignez la communauté SQL Server Webcasts, Conférences, Afterworks Session donnée lors du http://GUSS.pro @GUSS_FRANCE /GUSS /GUSS.FR
- 3. > whoami ~ depuis 2002 6.5 <= SQL Server <= 2014 mikedavem1@hotmail.com / david.barbarin@dbi-services.com http://blog.developpez.com/mikedavem http://www.dbi-services.com/index.php/blog/dbi-bloggers/blogger/ listings/dab @mikedavem SQLSaturday 323 – Paris 2014
- 4. Sponsors Gold SQLSaturday 323 – Paris 2014
- 5. Sponsors Silver et Bronze SQLSaturday 323 – 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
- 14. Cluster à basculement Windows – Démo SQLSaturday 323 – Paris 2014
- 15. Groupes de disponibilités et type de réplication 1 2 2 Log block 3 hardened LSN SQLSaturday 323 – Paris 2014 5 4 6 6 Ok – I’m ready
- 16. Groupes de disponibilités et réplication – Démo 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