Mettre en œuvre un plan de reprise d’activité après un désastre est un élément essentiel de la gestion d’une production informatique. Le plan de secours est un élément indispensable mais aussi bien souvent très onéreux, d’autant plus que dans la majorité des cas, et on l’espère tous, le site de secours de sera jamais utilisé. L’idée est donc séduisante d’utiliser le Cloud Computing pour mettre en œuvre ce site de secours. Tout n’est cependant pas réalisable, et il faut être prudent dans son projet d’analyse de faisabilité et de mise en œuvre. Un nombre croissant de demandes de ce type est adressé à Microsoft pour l’analyse et le déploiement de sites de secours sur Azure, le cloud de Microsoft. Au cours de cette session, ces différents modèles de gestion d’un désastre seront expliqués, et illustrés par des cas d’usage fréquemment utilisés. Speakers :

2. Reprise et Continuité d'activité
sur le Cloud : Mythes & Réalités
Olivier Sallaberry
Consultant Cloud Computing
Microsoft
Stéphane Woillez
Consultant Cloud Computing
Microsoft
Infrastructure, communication & collaboration

3. Agenda
• Désastre : Rappels sur la reprise d’activité et la continuité d’activité
• Prévention d’un désastre : Les choix stratégiques et organisationnels
• Prévention d’un désastre : L’approche technologique
• Passons à l’opérationnel : Azure pour héberger mon site de secours
• Cas d’usage, quelques exemples d’implémentation
• Un cas particulier : Mon business tourne DEJA sur Azure
• Conclusion
#mstechdays
Infrastructure, communication & collaboration

4. Désastre : Rappels sur la reprise d’activité et la continuité d’activité
•
Planifier la reprise ou la continuité
d’activité consiste à se préparer à faire
face à un désastre et à une perte partielle
ou totale de sa production informatique
•
C’est un projet critique et stratégique
•
Il doit être adapté à la criticité des
applications et des données à traiter
•
C’est un investissement en temps et
ressources. Son cout n’est pas négligeable
•
Le plan est planifié, préparé, construit,
documenté, testé, et remis à jour
régulièrement.
#mstechdays
Infrastructure, communication & collaboration

5. Quelques définitions à retenir
•
Plan de reprise d’activité : Procédure de bascule sur un système de secours
permettant la prise en charge minimale des systèmes du SI pour assurer la survie de
l’entreprise
•
Plan de continuité d’activité : Procédure de bascule sur un système de secours
permettant d’atteindre un temps d’indisponibilité et une perte de données proches de
zéro.
•
RPO (Recovery Point Objective) / PDMA ( Perte de Données Maximale Admissible) :
Fenêtre de temps maximale pendant laquelle les données ne sont pas sauvegardées,
et seront donc perdues en cas de sinistre
•
RTO (Recovery Time Objective) / DMIA (Durée Maximale d’Interruption Admissible) :
Délai maximal d’indisponibilité du système d’information à la suite d’un sinistre
Dernière Sauvegarde
Service Opérationnel
Incident
RPO
#mstechdays
RTO
Infrastructure, communication & collaboration
T

6. SLA et couts associés
SLA
Indisponibilité Annuelle
Indisponibilité Mensuelle
99%
3.65 jours
7.20 heures
99.5%
1.83 jours
3.60 heures
99.9%
8.76 heures
43.8 minutes
99.95%
4.38 heures
21.56 minutes
99.99%
53 minutes
4.32 minutes
99.999%
5.26 minutes
25.9 secondes
Indisponibilité
1 à 5 Minutes
99,999%
99,99%
15 Minutes max
Heures
Jours
99,95%
99,9%
€
#mstechdays
€€
€€€
Infrastructure, communication & collaboration
€€€€
Cout

7. Prévention d’un désastre : Les choix stratégiques et
organisationnels
Si aucun plan de
Risques
Pour
L’entreprise
secours n’est prévu, la
survie de l’entreprise
en en jeu
• Se concentrer sur la survie de
l’entreprise
• Déterminer ses besoins
(RTO/RPO)
• Classer ses applications IT par
ordre de priorité BUSINESS
• Mettre en relation le cout du plan
de secours avec les risques
engendrés par l’interruption pour
l’entreprise
• Effectuer une analyse de risque et
une
#mstechdays analyse d’impact
Infrastructure, communication & collaboration
Le point d’inflexion de
la courbe est la zone
dans laquelle cibler son
plan de secours
Le cout du plan de
secours ultime est
inapproprié
Cout du Plan de Secours

8. Prévention d’un désastre : L’approche technologique
•
Le choix du modèle de secours dépend du
RTO envisagé
•
La définition précise du contexte menant à
la décision de bascule est impérative
•
•
•
La bande passante réseau entre les deux
sites est à estimer avec précision
Un plan de secours non testé est un échec
assuré
Il faut aussi penser à tester la procédure de
retour sur le site primaire…
#mstechdays
Collaborateurs
Sécurité physique, Urgence, Transport
Business Process
Procédures d’urgence, Tests
Clients Applicatifs
Retry, Re-route, Reconnexion
Applications Serveur
Backup, log shipping, réplication
Operating System
Backup, replication, snapshots, etc.
Stockage
Backup, replication, snapshots, etc.
Réseau
Load balancing, Routage, Failover
Hardware
Réplication sur le site secondaire
Infrastructure, communication & collaboration

9. Passons à l’opérationnel : Le cloud pour héberger mon site de
secours
Disponibilité et SLA entreprise
•
•
Chacun des services Azure offre un SLA entreprise de disponibilité >= 99.9% avec pénalités.
La disponibilité des services est consultable via le service dashboard :
http://www.windowsazure.com/en-us/support/service-dashboard/
Azure Traffic Manager offre un SLA de 99.99%
http://www.windowsazure.com/en-us/support/legal/sla/
Scalabilité et continuité de service
•
Atteindre une limite de scalabilité impacte la continuité de service
La plateforme Azure pour mon site de secours:
•
•
Une opportunité pour déployer un site de secours avec SLA de disponibilité
Une opportunité à qualifier techniquement comme pour une migration
A titre d’exemple , prévoir un capacity planning incluant les IOPS
http://msdn.microsoft.com/en-us/library/windowsazure/dn197896.aspx
#mstechdays
Infrastructure, communication & collaboration

10. Passons à l’opérationnel : Le cloud pour héberger mon site de
secours
http://msdn.microsoft.com/library/windowsazure/dn197896.aspx

11. Passons à l’opérationnel : fonctionnement du stockage REST
Azure
http://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/windows-azure-storage-architecture-overview.aspx
#mstechdays
Infrastructure, communication & collaboration

12. Passons à l’opérationnel : stockage REST Azure , quelques
chiffres
« Scalability targets » par compte de stockage
(compte créé après le 7 Juin 2012)
Cible
Transactions
20000 entités/ messages/ Blobs
par seconde
Bande passante pour un compte géo-redondant
Ingress : 5 Go/s
Egress : 10 Go/s
Bande passante pour un compte localement redondant
Ingress : 10 Go/s
Egress : 15 Go/s
« Scalability targets » par
partition
Clef de partition
Cible
Queue
Queue Name
2000 messages/s
Table
Partition Key
2000 entités/s
Blob
Container Name + Blob Name
60 Mo/s par blob
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx
#mstechdays
Infrastructure, communication & collaboration

13. Passons à l’opérationnel : Le cloud pour reconstruire mon site de
secours
Scenarios « cross premise »
• Données
–
–
–
–
Windows Azure backup intégré avec SC DPM 2012 SP1 ET WS2012
Backups natifs de SQL Server 2012 SP1 vers le stockage REST Azure (full ou différentiel)
Custom Backup vers le stockage Azure : localement triplement redondé et optionnellement
géo redondé (API , PowerShell , Client Tools )
Appliance StorSimple
#mstechdays
Infrastructure, communication & collaboration

14. Passons à l’opérationnel : Le cloud pour reconstruire mon site de
secours
Scenarios « cross premise »
• Compute
Plateforme de secours déployée dans Azure et bascule
Exemple : avec Office 365 et ADFS dans Azure:
http://technet.microsoft.com/en-us/library/dn509537.aspx
-
Orchestration du DRP private cloud avec Azure
-
-
HyperV Recovery Manager
Quelques points relatifs à l’implémentation:
-
Vérifier la supportabilité des logiciels : http://support.microsoft.com/kb/2721672
Prévoir le capacity planning
Usage possible du VPN Site à Site Azure pour connection sécurisée IPSEC , si nécessaire..
Possibilités de copie de blobs hors VPN avec Shared Access Signature et https (ex: AzCopy)
Tester la bascule..
AzCopy: http://blogs.msdn.com/b/windowsazurestorage/archive/2013/09/07/azcopy-transfer-data-withre-startable-mode-and-sas-token.aspx
#mstechdays
Infrastructure, communication & collaboration

15. Passons à l’opérationnel : Hyper V Recovery Manager
Orchestration du DRP de clouds privés
Microsoft System Center 2012 Service Pack 1 and System Center 2012 R2 Virtual Machine Manager (VMM)
Guide de planification & prérequis : http://msdn.microsoft.com/en-us/library/windowsazure/dn469074.aspx
#mstechdays
Infrastructure, communication & collaboration

16. Passons à l’opérationnel : Le cloud pour reconstruire mon serveur
SQL
•
Scénarios
Always On (réplication asynchrone cross VPN )
Database Mirroring (« high performance » , hors VPN avec certificats)
Log Shipping (cross VPN car file sharing et DC replica) Backups natifs de SQL Server 2012 vers le stockage REST
Azure
#mstechdays
Infrastructure, communication & collaboration

17. Passons à l’opérationnel : Le cloud pour reconstruire mon serveur
SQL
Points relatifs à la mise en œuvre:
-
-
Chaque disque d’une VM Azure IaaS = 1 page blob Azure
Stripping potentiel pour SQL Server (performances ou bonne pratiques)
La géo réplication des blobs est parallélisée et indépendante (non synchronisée)
Data et Logs sur 2 disques géo répliqués impliquent une perte d’intégrité transactionnelle
La bande passante servie par un compte de stockage non géo répliqué est supérieure
=> préférer le backup vers un compte de stockage Azure géo répliqué.
Le VPN Site à Site passe par internet (voir http://azurespeedtest.azurewebsites.net/ )
- s’attendre donc à des latences et effectuer un capacity planning
- Eviter en hybride le mode synchrone (Always On) et le mode high safety (Mirroring)
Always On (HA on Azure) et Mirroring ne peuvent être associés :
=> Dans Azure : Always On pour HA + Backups vers le stockage REST Azure pour le
DRP
References :
• guide de performance de SQL Server sur VMs Azure IaaS: http://msdn.microsoft.com/en-us/library/windowsazure/dn248436.aspx
• HA et DR avec SQL Server sur VM Azure IaaS : http://msdn.microsoft.com/en-us/library/windowsazure/jj870962.aspx
• Always On Availability groups Interoperabilité: http://msdn.microsoft.com/en-us/library/hh710077.aspx
#mstechdays
Infrastructure, communication & collaboration

18. Demos
1. Compte de stockage Azure géo répliqué avec access en read only
au réplica secondaire
2. Azure Traffic Manager en fail over
3. Windows Azure backup
4. Backup de base SQL Server vers compte de stockage géo repliqué
5. Vue des fichiers du réplica secondaire
#mstechdays
Infrastructure, communication & collaboration

19. Un cas particulier : Mon business tourne DEJA sur
Azure
•
•
•
•
Azure est construit sur de
multiples systèmes de
redondances et de continuité de
services.
Des composants de réplications,
intégrés dans l’infrastructure, et
activés par les utilisateurs,
mettent les services de base en
DR
C’est à moi en tant qu’utilisateur,
de mettre mon application en
haute disponibilité
L’infrastructure permet de faire
de la continuité de service, autant
en profiter.
#mstechdays
www.foo.com
Traffic
Manager
Azure
DNS
Geo Failover
CNAME
foo.trafficmgr.cloudapp.net
•
Policies
•
Hosted
Service
North
Europe
Failover
Loadbalancing
Endpoint
monitoring
Hosted
Service
Hosted
Service
West
Europe
Synchronisatio
n
Application
des bases
De données
SQL
Database
Sync
Infrastructure, communication & collaboration
Geo Replication
Du Stockage
North
Europe
West
Europe

20. Conclusion
•
Disaster Recovery ET Business Continuity au sein d’Azure simples à mettre en
œuvre et peu couteux. Il faut privilégier la Business Continuity.
•
Disaster Recovery du Privé/Privatif vers Azure possible mais sous certaines
conditions
•
Plus facile pour les environnements virtualisés que pour les infrastructures
physiques
•
Le Cloud est une option à étudier absolument pour des raisons évidentes de couts
•
Pour en savoir plus, la référence absolue : Windows Azure Business Continuity Technical
Guidance : http://msdn.microsoft.com/en-us/library/hh873027.aspx
•
Disaster Recovery and High Availability for Windows Azure Applications :
http://msdn.microsoft.com/en-us/library/windowsazure/dn251004.aspx
•
Failsafe : Guidance for Resilient Cloud Architectures : http://msdn.microsoft.com/enus/library/windowsazure/jj853352.aspx
#mstechdays
Infrastructure, communication & collaboration

21. Questions ?
#mstechdays
Infrastructure, communication & collaboration

22. Donnez votre avis !
Depuis votre smartphone sur :
http://notes.mstechdays.fr
De nombreux lots à gagner toutes les heures !!!
Claviers, souris et jeux Microsoft…
Merci de nous aider à améliorer les Techdays !
#mstechdays
Infrastructure, communication & collaboration

23. Digital is
business