Installation de Sylius 2.0 et découverte du nouveau backoffice en Bootstrap
Tout sur les solutions de haute disponibilité et disaster recovery de sql server et windows azure sql database
1. • HA : Rappels
• HA : options et solutions
• SQL Server 2012 : AlwaysON
– Failover Cluster Instance
– Availability Groups
• Migration
– DBM -> AAG
– Cluster Windows 2008R2 -> Windows 2012
• Combinaisons d’architecture
Agenda
2. • 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 …
Rappels : haute disponibilité
3. Définition d’une stratégie
•Chiffre d’affaire
•SalairesQuantifier 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éeRTO
• 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
5. 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
Les sources d’indisponibilités
6. Des fonctionnalités
Table
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
7. • Log Shipping
• Failover Cluster
• Database Mirroring
• Réplication
• Windows Azure SQL Databases / Federation
• Virtualisation
– On Premise (Hyper-V)
– Off Premise (Windows Azure)
Des solutions connues
9. • Windows Azure SQL Databases
• Disponibilité de 99,9 % mensuelle (43,2 minutes …)
• Windows Azure VMs
• Disponibilité de 99,9%
• Etendre les groupes de disponibilité pour le PRA
• Perte de données < 30mn
Azure
10. • Création d’une VM Windows Azure
• Connexion RDP
• Connexion SQL Azure
Azure - Demos
11. VM sur Windows Server 2012 - Hyper-V 3.0
• Live migration
• Live storage migration
• P2V
• DR site distant
• RPO 5 minutes
• VMs en haute disponibilité
• Cluster 64 nœuds
• SMB 3.0
• RAM 1TB
• Architecture NUMA
• 64 vCPUs
• Fichiers VHDX 4KB
• Disques PassThrough
• Cartes FC
• NIC Teaming
Haute
performance
Haute
disponibilité
Migrations
facilitées
Réplicas
Hyper-V
13. • 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
• Sauvegarde vers Windows Azure Blob Storage
– Externalisation des sauvegardes
– Transfert entre OnPremise et Windows Azure
SQL Server 2012 : des améliorations
15. AlwaysOn : une marque !
AlwaysOn
Cluster de
basculement
( FCI )
Groupe de
disponibilité
( AAG )
16. Versions antérieures
Granularité instance
Stockage centralisé
VIP
Pas de modification chaines de connexion
SQL Server 2012
Stratégies de basculement flexible
Réseaux multiples
Predictable Recovery Time
Changement de quorum (votes)
TEMPDB Stockage Local
Le cluster de basculement (FCI)
18. 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
Le cluster de basculement (FCI)
19. • 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é
Indirect Checkpoint
21. Geo-Cluster Multi Site
App A
App B
App A
IP1
Cluster
WAN
App B
App A
App A
IP2
Site 1 – VLAN 1 Site 2 – VLAN 2
Synchronisation
TEMPDB TEMPDB
Fonctions Clefs
• Tempdb stocage local
• Support Multi Vlan
22. Les groupes de disponibilité
• Listeners (Routing lists)
• RO Secondaires
• Sauvegardes déportées
• Réplicas asynchrones
• Stats en TempDB
• Compression des Flux
• 3 Réplicas synchrones
• Failover auto (2 réplicas)
• Auto page repair
• Listeners (dispo
applicative)
• Réplica asynchrone
• DataCenter distant
• Failover auto / manuel
• Flexibilité (déploiement)
• Cloud Public pour DR
DR HA
Répartition
de charge
Performance
23. •Création du cluster
•Activation de AlwaysOn
WSFC
•Création des EndPoints
•Sauvegarde des bases
•Création du groupe de
disponibilité
Primary
•Création des EndPoints
•Restauration des bases
•Ajout du nœud
•Ajout des bases
Secondaire(s)
•Création du listener
•Création des routing list
Listener
Mise en place d’un groupe de disponibilité
24. PowerShell
• Backup-SqlDatabase
• Restore-SqlDatabase
• New-SqlHadrEndpoint
• New-SqlAvailabilityGroup
• Join-SqlAvailabilityGroup
• Add-SqlAvailabilityDatabase
• New-SqlAvailabilityGroupListener
• Switch-SqlAvailabilityGroup
T-SQL
• Backup Database
• Restore Database
• Create Endpoint
• Create Availability Group
• Alter Availability Group Join
• Alter Database Set hadr Availability
• Alter Availability Group Add Listener
• Alter Availability Group Failover
Mise en place d’un groupe de disponibilité
25. • 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 …
Démo : création d’un groupe de disponibilié
26. • 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é
Démo : Migration d’un Database Mirroring
29. Primary Data Center
Disaster Recovery
Data Center
SQL Server
Primary
SQL Server
Secondary
Windows Server Failover Cluster (single WSFC crossing two data centers)
Availability Group
Synchronous
Asynchronous
SQL Server
Secondary
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
• Upgrade DBM Witness
• Upgrade DBM Mirror
• Upgrade DMB Principal
• Create WSFC cluster
• Configure AAG
30. • Décharge le Primaire des lectures
– ApplicationIntent = ReadOnly
– Définition d’une liste de routage
– Redirection automatique
Démo : Read Only Routing
Primaire SecondaireSecondaire
ApplicationIntent= Readonly
Win2012srv1 Win2012srv2 Win2012srv3
31. HA et DR SQL Server solution
Potential Data
Loss (RPO)
Potential
Recovery
Time (RTO)
Automatic
Failover
Scope
Readable
Secondaries
NB
replicas
AlwaysOn Availability Group - synchronous-commit Zero Secondes Oui DB(s) 0 - 2 2
AlwaysOn Availability Group - asynchronous-commit Secondes Minutes Non DB(s) 0 - 4 4
AlwaysOn Failover Cluster Instance NA(5) Secondes
-> minutes
Oui Inst NA
Database Mirroring - High-safety (sync + witness) Zero Seconds Non DB NA 1
Database Mirroring - High-performance (async) Secondes Secondes Non DB NA 1
Log Shipping Minutes Minutes
-> Heures
Non DB Hors
restauration
n
Backup / Restore Heures Heures
->Jours
Non DB Hors
restauration
NA
Comparaison des solutions
32. • AG HA + DR sur site distant
Différentes architectures
v
Primaire SecondaireSecondaire
Synchrone
Asynchrone
Data center principal Data center Secours
Windows Server Failover Cluster (WSFC)
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é
33. • AG HA + redondance dans le cloud
Différentes architectures
v
Primaire SecondaireSecondaire
Synchrone
Asynchrone
Data center principal
Windows Server Failover Cluster (WSFC)
Availibility Group
34. • FCI pour HA et AG+FCI
Différentes architectures
vv
SQLFCIAInst1
Synchrone/
Asynchrone
Primaire
Data center principal Data center Secours
Windows Server Failover Cluster (WSFC)
Availibility Group
SQLFCIBInst2
Secondaire
• 2 instances FCI stockage SAN
• Configuration HA avec Bascule manuelle, redirection automatique
• Configuration DR avec Bascule manuelle, redirection automatique
35. • 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
Quorum Configuration
36. Availibility Group HA et DR
Modèle de Quorum - Votes
v
SQL Server
Primaire
SQL Server
Secondaire
SQL Server
Secondaire
Synchrone
Asynchrone
Data center principal Data center Secours
Windows Server Failover Cluster (WSFC)
Availibility Group
File Share
Vote Vote
Vote
Vote
37. v
Failover Cluster + Availibility Group
Modèle de Quorum - Votes
v
SQLFCIAInst1
Synchrone/
Asynchrone
Primaire
Data center principal Data center Secours
Windows Server Failover Cluster (WSFC)
Availibility Group
File Share
Vote
Vote
Vote
SQLFCIBInst2
Secondaire
VoteVote
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
CL
ou 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 ???