5. Agenda
• Des questions
–
–
–
–
Pourquoi la haute disponibilité
La non disponibilité
Définition d’une stratégie
Problèmes et limitations
• Les solutions
– Des plus anciennes aux plus récentes
#JSS2013
6. • Des questions
–
–
–
–
Pourquoi la haute disponibilité
La non disponibilité
Définition d’une stratégie
Problèmes et limitations
• Les solutions
– Des plus anciennes aux plus récentes
#JSS2013
7. Pourquoi la haute disponibilité
• Définition basique
– Etre capable d’accéder à une donnée lorsque l’on en a besoin
dans un laps de temps acceptable !
• BD point central dans le SI
– Sharepoint, sites Web de paris ou commerce en ligne
– Progiciels (RH, Compta, production, CRM)
– Logiciels « maison »
• La non disponibilité a un coût
– Chiffre d’affaire …
– Coût en temps
– Salaires d’employés …
#JSS2013
9. Cause de non disponibilité
Coupure de service planifiée
• Création / Reconstruction d’index non cluster : éventuellement pas de modifications
sur la table
• Création / Reconstruction d’index cluster : éventuellement pas de lecture et
modifications sur la table
• Changement de matériel, application de Service Packs
Coupure de service non planifiée
• Perte du Datacenter (électricité, réseau, catastrophe naturelle, incendie)
• Perte du serveur (alimentation, CPU, mémoire, réseau, OS crash)
• Problème disque (corruption d’I/O, panne contrôleur disque, panne disque, panne
carte RAID)
Ne pas confondre PCA et PRA
• HA et DR …
#JSS2013
10. Définition d’une stratégie
Granularité
RPO
RTO
•Chiffre d’affaire
•Salaires
•Datacenter -> Instance -> Groupe de bases -> Base > Table -> Traitement
•Coordination des dépendances
• Perte maximale de données autorisée
• Durée maximale de non disponibilité
autorisée
Période ouvrée
• 24 H / 24 , 7 J /7
• Entre 8h00 et 18h00 les jours ouvrés …
En cas de panne
Stratégie
Quantifier
l’indisponibilité
• Même niveau de performance requis ?
• Dégradation acceptable ?
#JSS2013
11. • Des questions
–
–
–
–
Pourquoi la haute disponibilité
La non disponibilité
Définition d’une stratégie
Problèmes et limitations
• Les solutions
– Des plus anciennes aux plus récentes
#JSS2013
12. Cluster de basculement SQL
Terminologie
• Cluster, nœud, quorum, SAN, LUN, groupe
de ressources, dépendance, instance virtuelle
Technologie éprouvée
• Couche cluster Windows
#JSS2013
13. Avantages du FCI
Tolérance de panne
• Matérielle, logicielle
Instance virtuelle
• Adresse IP et Nom réseau virtuels
Granularité
• Instance (donc agent SQL …)
#JSS2013
14. Points remarquables
Windows 2012
SQL 2012
Windows 2012 R2
SQL 2014
• Quorum dynamique
• TempDB locale
• Témoin dynamique
• Data sur disque CSV
#JSS2013
16. Inconvénients de la solution
Défaillance du système disque
• SPOF
Répartition de charge impossible
• Un seul nœud actif à la fois
Coût
• Cartes, switch, fibres, SAN …
Durée de recovery
• Nombre de bases
Granularité
• Protection de niveau instance
#JSS2013
20. L’union fait la force
• Prises indépendamment elles ne présentent que peu d’avantages
par rapport aux solutions ‘reines’.
FCI
Database
Mirroring
Virtualisation
Log
Shipping
Availability
Groups
Réplication
(?)
• Mais si on les combine toutes les trois ?
#JSS2013
21. Exemple DBM + LS + Réplication
Données
ouvertes
pour DSS
Secours
dormant
Réplication
Database Mirroring
Log Shipping
.trn
.trn
.trn
.trn
Reporting
Refresh -8h
contre les
erreurs
humaines
#JSS2013
23. Intérêts de la solution
Perte de la machine principale, perte du
stockage local, problème OS, corruption…
• On bascule sur le miroir
• Qui est aussi paramétré pour reprendre le rôle d’éditeur
et de source du LS
Moins d’indisponibilité sur les plages de
maintenance.
#JSS2013
24. Réplication vs réplicas readonly, avantages
Volumétrie:
• On n’est pas obligé de dupliquer toute la volumétrie
Indexes DSS:
• On peut créer des indexes custom DSS sur les bases abonnées
Store & forward
• Perte de la connexion avec l’abonné, la base distribution joue le rôle de tampon. Pas d’impact sur le journal de transactions
primaire.
Coût:
• Pas besoin d’avoir toutes les instances en édition Enterprise.
Scale-out
• En ajoutant des abonnés, pas de limitation à 2 réplicas.
Contrainte AD:
• Moins d’adhérence avec un domaine
#JSS2013
25. Inconvénients de la solution
Réactivité:
• Pas de bascule automatisée (sauf avec witness)
DBM et reporting?
• db snapshot pas très pratique quand même
Complexité
• Plusieurs systèmes à maintenir au lieu d’un seul.
Point d’entrée unique:
• Pas de détection d’intention pour la lecture seule (ApplicationIntent)
Conflits en mise à jour:
• L’abonné est ouvert en lecture /écriture donc pas de garde-fou contre le conflit en mise à jour.
Paramétrage manuel :
• La bascule est transparente pour la réplication, mais pas pour le log shipping (paramétrage manuel).
#JSS2013
26. SQL Server AlwaysOn
Terminologie
• Groupe de
disponibilités, réplicas, cluster, nœud, quorum, stockage
asymétrique, réplication synchrone et asynchrone
Technologie éprouvée
• Couche cluster Windows, mirroring ++
#JSS2013
27. Avantages des groupes de disponibilité
Tolérance de panne
• Matérielle, logicielle, corruption physique des données
Connexion unique via point d’accès client (listener)
• Adresse IP et Nom réseau virtuel
Granularité
• Groupe de base de données
#JSS2013
28. Avantages des groupes de disponibilité
Rentabilisation des serveurs secondaires standby
• Répartition de charge avec utilisation en lecture seule en temps réel, sauvegardes
Stockage
• Indépendance vis-à-vis d’un stockage partagé,
• Stockage asymétrique avec disaster recovery sur site distant
Complexité
• Une seule fonctionnalité pour gérer la haute disponibilité et les situations de
désastre
#JSS2013
29. Points remarquables
Windows 2012
SQL 2012
Windows 2012 R2
SQL 2014
• Quorum dynamique
• 4 réplicas secondaires
• Quorum amélioré (témoin dynamique, résilience du quorum, arbitrage des votes)
• Support CSV
• Déploiement de cluster sans dépendance d’objets dans l’active directory
• 8 réplicas secondaires + plus forte intégration avec Azure + support Hekaton
#JSS2013
31. Démo
• Exemple d’une topologie AlwaysOn avec
Windows Server 2012 et SQL14
#JSS2013
32. Inconvénients de la solution
Coût
• Nécessite une édition Enterprise de SQL Server 2012 avec licence par cœur logique
• Chaque serveur secondaire actif (backup ou lecture seule) doit être licencié
Limite du nombre de réplicas synchrones
• Limite à 3 réplicas
Lecture / écriture sur un seul point d’entrée
• Pas de possibilité d’avoir plusieurs réplicas primaires en même temps
Répartition de charge en lecture seule impossible via les listeners
• L’algorithme de redirection des connexions en intention de lecture seule sont toujours redirigés vers le même réplica
Paramétrage
• Certains paramétrages s’effectuent depuis la GUI alors que d’autres ne sont disponibles que par T-SQL ou PowerShell
Monitoring
• Pas forcément évident en utilisant les divers axes de troubleshooting en natif avec SQL Server
• Pas de solution réelle de monitoring fournie en natif
#JSS2013
33. Virtualisation
Flexibilité
• Live storage migration
• Live migration
• MàJ hyperviseur
• Mémoire dynamique
• Redimensionnement VHDX
HA
• Live migration
• Storage live migration
• Host cluster
• Guest cluster
• Peu ou pas de coupure de service
• Scénario supporté (KB956893)
DR
• Hyper-V replica (30 secs, 5 mins, 15 mins))
• Attention compatibilité avec autres solutions
#JSS2013
34. Virtualisation
Exploitation
• Rapidité déploiement
• Export et clonage de VM à chaud
• Cluster Aware Updating
Performance
•
•
•
•
•
Quasi similaire (6% – 7%)
VHDX secteurs 4KB, max 64 TB
Storage tiering
Storage QoS
Offloaded Data Transfer (ODX)
#JSS2013
35. Demo – Shared VHDX
• Si le temps le permet …
#JSS2013
38. Rappels : haute disponibilité
• Définition basique
– Etre capable d’accéder à une donnée lorsque l’on en a
besoin dans un laps de temps acceptable !
• BD point central dans le SI
– Sharepoint, sites Web de paris ou commerce en ligne
– Progiciels (RH, Compta, production, CRM)
– Logiciels « maison »
• La non disponibilité a un coût
– Chiffre d’affaire …
– Salaires d’employés …
#JSS2013
39. Définition d’une stratégie
Granularité
RPO
RTO
•Chiffre d’affaire
•Salaires
•Datacenter -> Instance -> Groupe de bases -> Base -> Table ->
Traitement
•Coordination des dépendances
• Perte maximale de données autorisée
• Durée maximale de non disponibilité
autorisée
Période ouvrée
• 24 H / 24 , 7 J /7
• Entre 8h00 et 18h00 les jours ouvrés …
En cas de panne
Stratégie
Quantifier
l’indisponibilité
• Même niveau de performance requis ?
• Dégradation acceptable ?
#JSS2013
41. Des fonctionnalités
Table
Database
Infrastructure
Online index Operations
Fast Recovery
Instant File Initialization
Online LOB index Operations
Partial Database Availability
Auto page repair
Table Partitioning
Online piecemeal restore
Hot-add CPU / Memory
Database Snapshot
Resource Governor
#JSS2013
42. Des solutions connues
•
•
•
•
•
•
Log Shipping
Failover Cluster
Database Mirroring
Réplication
Windows Azure SQL Databases / Federation
Virtualisation
– On Premise (Hyper-V)
– Off Premise (Windows Azure)
#JSS2013
Notas do Editor
Monitoring :SCCM 2012 propose un feature pack pour AlwaysOnSQLSentry V7.5…
RP
RP Read-only and deferred operations. During a maintenance window, or during a phased disaster recovery, data retrieval is still possible, but new workflows and background processing may be temporarily halted or queued. Data latency and application responsiveness. Due to a heavy workload, a processing backlog, or a partial platform failure, limited hardware resources may be over-committed or under-sized. User experience may suffer, but work may still get done in a less productive manner. Partial, transient, or impending failures. Robustness in the application logic or hardware stack that retries or self-corrects upon encountering an error. These types of issues may appear to the end user as data latency or poor application responsiveness. Partial end-to-end failure. Planned or unplanned outages may occur gracefully within vertical layers of the solution stack (infrastructure, platform, and application), or horizontally between different functional components. Users may experience partial success or degradation, depending upon the features or components that are affected.