SQL Server AlwaysOn 
Groupes de disponibilités en détail 
SQLSaturday 323 – Paris 2014
Rejoignez la communauté SQL Server 
Webcasts, Conférences, Afterworks 
Session donnée lors du 
http://GUSS.pro 
@GUSS_FRAN...
> whoami 
~ depuis 2002 
6.5 <= SQL Server <= 2014 
mikedavem1@hotmail.com / david.barbarin@dbi-services.com 
http://blog....
Sponsors Gold 
SQLSaturday 323 – Paris 2014
Sponsors Silver et Bronze 
SQLSaturday 323 – Paris 2014
Agenda 
Cluster Windows WSFC et interaction 
avec les groups de disponibilités 
Groupes de disponibilités – Réplication 
G...
SQL Server AlwaysOn et les groupes de 
disponibilités : Architecture globale 
SQLSaturday 323 – Paris 2014
Cluster à basculement Windows 
Cluster 
• Groupe indépendant d’ordinateurs travaillant ensemble pour augmenter la 
disponi...
Cluster à basculement Windows - Quorum 
Offre un mécanisme de protection contre le «split brain» 
• Cluster divisé en plus...
Cluster à basculement Windows – Sous 
système d’hébergement des ressources 
Groupe de disponibilité 
Nom réseau 
IP IP 
SQ...
sp_server_diagnostics 
 < SQL Server 2012  @@SERVERNAME 
 améliore les capacités de diagnostique en cas de basculement ...
Cluster à basculement Windows – RHS et 
DLL de ressource SQL Server 
RHS.exe (hadrres.dll) 
AG1 AG2 AG3 
Health 
Worker 
H...
Cluster à basculement Windows – 
paramètre Lease Timeout 
failover 
unresponsive 
AAG 
responsive 
Timeout 
PRIMARY SEPCRO...
Cluster à basculement Windows – Démo 
SQLSaturday 323 – Paris 2014
Groupes de disponibilités et type de 
réplication 
1 
2 
2 
Log block 
3 
hardened LSN 
SQLSaturday 323 – Paris 2014 
5 
4...
Groupes de disponibilités et réplication – 
Démo 
SQLSaturday 323 – Paris 2014
Groupes de disponibilités – réplicas 
secondaires (en lecture seule) 
 Accès en lecture «réelle» 
 Redirection automatiq...
Groupes de disponibilités et réplicas 
secondaires en lecture seule – Démo 
SQLSaturday 323 – Paris 2014
Prochain SlideShare
Chargement dans…5
×

SQLSaturday Paris 2014 - SQL Server AlwaysOn et les groupes de disponibilités en détail

533 vues

Publié le

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

Publié dans : Données & analyses
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
533
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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
  • SQLSaturday Paris 2014 - SQL Server AlwaysOn et les groupes de disponibilités en détail

    1. 1. SQL Server AlwaysOn Groupes de disponibilités en détail SQLSaturday 323 – Paris 2014
    2. 2. Rejoignez la communauté SQL Server Webcasts, Conférences, Afterworks Session donnée lors du http://GUSS.pro @GUSS_FRANCE /GUSS /GUSS.FR
    3. 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. 4. Sponsors Gold SQLSaturday 323 – Paris 2014
    5. 5. Sponsors Silver et Bronze SQLSaturday 323 – Paris 2014
    6. 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. 7. SQL Server AlwaysOn et les groupes de disponibilités : Architecture globale SQLSaturday 323 – Paris 2014
    8. 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. 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. 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. 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. 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. 13. Cluster à basculement Windows – paramètre Lease Timeout failover unresponsive AAG responsive Timeout PRIMARY SEPCROIMNADRAYRY Lease Split brain SECONDARY SQLSaturday 323 – Paris 2014
    14. 14. Cluster à basculement Windows – Démo SQLSaturday 323 – Paris 2014
    15. 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. 16. Groupes de disponibilités et réplication – Démo SQLSaturday 323 – Paris 2014
    17. 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. 18. Groupes de disponibilités et réplicas secondaires en lecture seule – Démo SQLSaturday 323 – Paris 2014

    ×