Session Haute-disponibilité

Présentation au sujet: "Session Haute-disponibilité"— Transcription de la présentation:

1

2 Session Haute-disponibilité
Christophe LAPORTE David BARBARIN David BAFFALEUF

3 Présentation Christophe LAPORTE David BARBARIN David BAFFALEUF
~ depuis 1997 6.5 <= SQL Server <= 2014 ~ depuis 2002 7 <= SQL Server <= 2014 ~ depuis 1999 7.0 <= SQL Server <= 2014 @conseilit @mikedavem @dbaffaleuf

4 Merci à nos sponsors

5 Agenda Des questions Les solutions 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

6 Des questions Les solutions 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

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 …

8 Mesurer la haute disponibilité

9 Cause de non disponibilité
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 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) Coupure de service non planifiée HA et DR … Ne pas confondre PCA et PRA

10 Définition d’une stratégie
Chiffre d’affaire Salaires Quantifier l’indisponibilité Datacenter -> Instance -> Groupe de bases -> Base -> Table -> Traitement Coordination des dépendances Granularité Perte maximale de données autorisée RPO Durée maximale de non disponibilité autorisée RTO 24 H / 24 , 7 J /7 Entre 8h00 et 18h00 les jours ouvrés … Période ouvrée Même niveau de performance requis ? Dégradation acceptable ? En cas de panne Stratégie

11 Des questions Les solutions 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

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

13 Avantages du FCI Tolérance de panne Instance virtuelle Granularité
Matérielle, logicielle Instance virtuelle Adresse IP et Nom réseau virtuels Granularité Instance (donc agent SQL …)

14 Points remarquables Quorum dynamique TempDB locale Témoin dynamique
Windows 2012 TempDB locale SQL 2012 Témoin dynamique Windows 2012 R2 Data sur disque CSV SQL 2014

15 Démo Ajout d’une instance sur disque CSV

16 Inconvénients Défaillance du système disque
Pas de répartition de charge Coût (cartes et switch fibre) Durée de recovery (nombre de bases) Granularité (instance)

17 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

18 GEO Cluster != Multi subnet failover cluster Résolution SPOF disque
Solutions constructeur EMC, HP, Unisys Solutions logicielles DoubleTake, DataKeeper (Démo à suivre) Solutions SQL Server Database mirroring, log shipping, réplication Groupes de disponibilité

19 Démo Ajout d’un disque cluster SIOS DataKeeper

20 Outsiders Database Mirroring Log Shipping
Réplication (transactionnelle)

21 L’union fait la force Prises indépendamment elles ne présentent que peu d’avantages par rapport aux solutions ‘reines’. Mais si on les combine toutes les trois ? FCI Virtualisation Availability Groups Database Mirroring Log Shipping Réplication (?)

22 Exemple DBM + LS + Réplication
TP Données ouvertes pour DSS Secours dormant TP TP Réplication Database Mirroring Log Shipping .trn .trn Refresh -8h contre les erreurs humaines .trn .trn Reporting

23 Démo Exemple d’une topologie combinée

24 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.

25 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

26 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).

27 SQL Server AlwaysOn Terminologie Technologie éprouvée
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 ++

28 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

29 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

30 Points remarquables Windows 2012 SQL 2012 Windows 2012 R2 SQL 2014
Quorum dynamique Windows 2012 4 réplicas secondaires SQL 2012 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 Windows 2012 R2 8 réplicas secondaires + plus forte intégration avec Azure + support Hekaton SQL 2014

31 Démo DSS TP TP Standby Backups Réplica synchrone Réplication
Read

32 Démo Exemple d’une topologie AlwaysOn avec Windows Server 2012 et SQL14

33 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 Monitoring : SCCM 2012 propose un feature pack pour AlwaysOn SQLSentry V7.5 …

34 Virtualisation Flexibilité HA DR Live storage migration Live migration
MàJ hyperviseur Mémoire dynamique Redimensionnement VHDX HA 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

35 Virtualisation Exploitation Performance 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)

36 Demo – Shared VHDX Si le temps le permet …

37 Questions / Réponses Merci à tous pour votre présence.

38

39 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 … RP

40 Définition d’une stratégie
Chiffre d’affaire Salaires Quantifier l’indisponibilité Datacenter -> Instance -> Groupe de bases -> Base -> Table -> Traitement Coordination des dépendances Granularité Perte maximale de données autorisée RPO Durée maximale de non disponibilité autorisée RTO 24 H / 24 , 7 J /7 Entre 8h00 et 18h00 les jours ouvrés … Période ouvrée Même niveau de performance requis ? Dégradation acceptable ? En cas de panne Stratégie 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.

41 Mesurer la disponibilité
Les « neufs » RP

42 Des fonctionnalités Table Database Infrastructure
Online index Operations Online LOB index Operations Table Partitioning Database Fast Recovery Partial Database Availability Online piecemeal restore Database Snapshot Infrastructure Instant File Initialization Auto page repair Hot-add CPU / Memory Resource Governor CL ou RP ???

43 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) CL