Retour d’expérience sur ‘TFS Online’ (VSTS) dans une solution industrielle (c...
Tout sur les solutions de Haute Disponibilité et Disaster Recovery de SQL Server et Windows Azure SQL Database
1. Tout sur les solutions de Haute
Disponibilité et Disaster Recovery de
SQL Server et Windows Azure SQL
Database (DAT305)
Christophe LAPORTE Richard PRADE
•SQL Server MCM / MVP Senior Consultant SQL/BI
•Consultant Indépendant Microsoft Services
• Blog : http://conseilit.wordpress.com/
• Twitter : @Conseilit
• Email : christophe_laporte@hotmail.fr
Serveurs / Entreprise / Réseaux / IT
2. Agenda
• Haute disponibilité
– Rappels
– Options et solutions
• SQL Server 2012 : AlwaysON
– Failover Cluster Instance
– Availability Groups
• Migration
– Database Miroring -> Availibility Group
• Combinaisons d’architecture
3. Rappels : haute disponibilité
• Définition basique
– Garantir la disponibilité d’un service, d’un accès aux
données
• 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 …
4. Définition d’une stratégie
•Chiffre d’affaire
Quantifier l’indisponibilité •Salaires
•Datacenter -> Instance -> Groupe de bases -> Base -
Granularité > Table -> Traitement
•Coordination des dépendances
Stratégie
• Perte maximale de données autorisée
RPO
• Durée maximale de non disponibilité
RTO autorisée
• 24 H / 24 , 7 J /7
Période ouvrée
• Entre 8h00 et 18h00 les jours ouvrés …
• Même niveau de performance requis ?
En cas de panne
• Dégradation acceptable ?
6. Les sources d’indisponibilités
Indisponibilité pendant les interruptions planifiées
• Installation des correctifs / Service Pack
• Mise à jour matérielle / logicielle
• Maintenance des bases de données
• Mise à jour applicative
Protection contre les interruptions non planifiées
• Erreur humaine (le plus courant)
• Désastre sur un site
• Défaillance matérielle
• Corruption de donnée
• Crash logiciel
7. 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
8. 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)
10. Windows Azure
• Windows Azure SQL Databases
• Disponibilité de 99,9 % mensuelle (43,2 minutes …)
• Windows Azure VMs IaaS
• Disponibilité de 99,9%
• Etendre les groupes de disponibilité pour le PRA
• Perte de données < 30mn
11. Azure - Demos
• Création d’une VM Windows Azure
• Connexion RDP
• Connexion SQL Azure
12. VM sur Windows Server 2012 - Hyper-V 3.0
• RAM 1TB • VMs en haute disponibilité
• Architecture NUMA • Cluster 64 nœuds
• 64 vCPUs • SMB 3.0
• Fichiers VHDX 4KB
• Disques PassThrough
• Cartes FC Haute Haute
• NIC Teaming performance disponibilité
Réplicas Migrations
Hyper-V facilitées
• DR site distant • Live migration
• RPO 5 minutes • Live storage migration
• P2V
14. SQL Server 2012 : des améliorations
• Nouvelles opérations en ligne supportées
– Reconstruction en ligne d’index de type :
varchar(max), nvarchar(max), varbinary(max), ou XML
– Ajout de colonne avec une valeur par défaut
• Migration Windows 2008R2 Vers Windows 2012 SP1
– Migration en s’appuyant sur une architecture Availability Group
• Sauvegarde vers Windows Azure Blob Storage SP1 CU2
– Externalisation des sauvegardes
– Transfert entre OnPremise et Windows Azure
15. Solutions incomplètes Redondance et
RPO=0 Unité de protection RTO réutilisation
Pas de perte de données
Protection automatique
Multiples secondaires
Instance SQL Server
Base de données
Ecriture possible
Lecture
Table
Solutions SQL Server
Log Shipping
synchrone
Database Mirroring
avec témoin
synchrone
sans témoin
asynchrone
Windows Failover Cluster
Réplication transactionelle
Réplication Peer-to-Peer
16. AlwaysOn : une marque !
Cluster de Groupe de
basculement disponibilité
( FCI ) ( AAG )
AlwaysOn
17. Le cluster de basculement (FCI)
Versions antérieures SQL Server 2012
Granularité instance Stratégies de basculement flexible
Stockage centralisé Réseaux multiples
VIP Predictable Recovery Time
Pas de modification chaines de connexion Changement de quorum (votes)
TEMPDB Stockage Local
19. Le cluster de basculement (FCI)
Flexible Failover Policy
• Bascule en fonction d’un niveau de diagnostic
• Personnalisable en fonction du niveau d’erreur
• Default – Niveau 3 – Fréquence 60 sec
20. Indirect Checkpoint
• Précédent checkpoints mode
– Variation du temps de bascule
– Variation de la charge IO
• Nouveau en SQL Server 2012 :
– checkpointing en tâche de fond
– charge IO lissée
– Temps de bascule plus prédictibles
– Configurable par base de données
– Par défaut désactivé
21. Geo-Cluster Multi Site
Fonctions Clefs
• Tempdb stocage local WAN
• Support Multi Vlan
App A
App A
Cluster IP2
IP1 App B
TEMPDB TEMPDB
App A
App A Synchronisation App B
Site 1 – VLAN 1 Site 2 – VLAN 2
23. Les groupes de disponibilité
• Réplica asynchrone • 3 Réplicas synchrone
• DataCenter distant • Failover auto (2 réplicas)
• Failover auto / manuel • Auto page repair
• Flexibilité (déploiement) • Listeners (dispo
• Cloud Public pour DR applicative)
DR HA
Répartition
Performance
de charge
• Réplicas asynchrones • Listeners (Routing lists)
• Stats en TempDB • RO Secondaires
• Compression des Flux • Sauvegardes déportées
24. Mise en place d’un groupe de disponibilité
Primary Listener
• Création du cluster • Création des EndPoints
• Activation de AlwaysOn • Restauration des bases
• Création des EndPoints • Ajout du nœud • Création du listener
•Sauvegarde des bases • Ajout des bases •Création des routing list
• Création du groupe de
disponibilité
WSFC Secondaire(s)
25. Mise en place d’un groupe de disponibilité
PowerShell T-SQL
• Backup-SqlDatabase • Backup Database
• Restore-SqlDatabase • Restore Database
• New-SqlHadrEndpoint • Create Endpoint
• New-SqlAvailabilityGroup • Create Availability Group
• Join-SqlAvailabilityGroup • Alter Availability Group Join
• Add-SqlAvailabilityDatabase • Alter Database Set hadr Availability
• New-SqlAvailabilityGroupListener • Alter Availability Group Add Listener
• Switch-SqlAvailabilityGroup • Alter Availability Group Failover
26. Démo : creation d’un groupe de dispo
• Déjà vu !
– Interface graphique
– T-SQL
• Challenges
– En PowerShell
– Migration depuis un DBM
– Avec des gants de boxe
• Désolé, le timing est un peu short …
27. Démo : Migration d’un Database Mirroring
• Existant
– 2 serveurs
– Session de mise en miroir créée
• 2 réplicas synchrones
• Pas de témoin (pour gagner du temps)
• Scénario de le démo
– Création de cluster Windows
– Création du groupe de disponibilité
– Ajout de la base DBM dans le groupe de disponibilité
Developpement
30. Documentation : Migration Depuis un DBM + LS
– SQL Server AlwaysOn team blog :
http://blogs.msdn.com/b/sqlalwayson/archive/2012/10/16/how-to-migrate-to-alwayson-
alwayson-from-prior-deployments-combining-database-mirroring-and-log-shipping-part-
1.aspx
• Upgrade Secondary LS Primary Data Center
Disaster Recovery
Data Center
• Upgrade DBM Witness Windows Server Failover Cluster (single WSFC crossing two data centers)
SQL Server
• Upgrade DBM Mirror SQL Server SQL Server
Upgrade DMB Principal
Primary Secondary
• Secondary
Synchronous
• Create WSFC cluster Asynchronous
• Configure AAG Availability Group
31. Démo : Read Only Routing
• Décharge le Primaire des lectures
– ApplicationIntent = ReadOnly
– Définition d’une liste de routage
– Redirection automatique
ApplicationIntent= Readonly
Primaire Secondaire Secondaire
Win2012srv1 Win2012srv2 Win2012srv3
33. Différentes architectures
• AG HA + DR sur site distant
Data center principal Data center Secours
Windows Server Failover Cluster (WSFC)
Primaire Secondaire Secondaire
v
Synchrone
Asynchrone
Availibility Group
• Stockage Local non partagé
• Configuration HA avec Bascule Automatique , redirection automatique
• Configuration DR avec Bascule manuelle, redirection automatique
• Les 2 secondaires accessibles en lecture seule : besoin BI , Scalabilité
34. Différentes architectures
• AG HA + redondance dans le cloud
Data center principal
Windows Server Failover Cluster (WSFC)
Primaire Secondaire Secondaire
v
Synchrone
Asynchrone
Availibility Group
• Extension de la solution vers le Cloud Windows Azure Iaas
• Mise en place d’un VPN
• Configuration DR / externalisation des données
35. Différentes architectures
• FCI pour HA et AG+FCI
Data center principal Data center Secours
Windows Server Failover Cluster (WSFC)
SQLFCIAInst1 SQLFCIBInst2
v Synchrone/ v
Asynchrone
Availibility Group
Primaire Secondaire
• 2 instances FCI stockage SAN
• Configuration HA avec Bascule manuelle, redirection automatique
• Configuration DR avec Bascule manuelle, redirection automatique
36. Quorum Configuration
• Le quorum est géré par le service WSFC indépendamment
du nombre d’instance SQL FCI ou Standalone
• Objectif : S’assurer que l’indisponibilité du site de DR ou la
connectivité n’impacte pas le quorum du WSFC
• 2 leviers :
– Affectation de droit de vote aux nœuds
Hotfix pour Windows 2008 /2008 R2 : http://support.microsoft.com/kb/2494036
– Le modèle de quorum
37. Modèle de Quorum - Votes
Availibility Group HA et DR
Data center principal Data center Secours
Windows Server Failover Cluster (WSFC)
SQL Server
SQL Server Vote Secondaire Vote SQL Server Vote
Primaire Secondaire
v
Synchrone
Asynchrone
Availibility Group
Vote
File Share
38. Modèle de Quorum - Votes
Failover Cluster + Availibility Group
Data center principal Data center Secours
Windows Server Failover Cluster (WSFC)
SQLFCIAInst1 SQLFCIBInst2
Vote Vote Vote Vote
Synchrone/
v Asynchrone v
Primaire Secondaire
Availibility Group
Vote
File Share
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.
RP
RP
CLou RP ???
CL
CL
CL ou RP ??
CL ou RP ???
CL
CL
RP
RP
RP
RP
RP
RP
RP
RP
RP
CL
CL
CL
CL
CL
CL
CL
RP ??CL ??Est-ce que tu veux le faire ou bien je continue avec du powershell ???