reprise et continuité d’activité sur le cloud : mythes & réalités

Infrastructure, communication & collaboration

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

#mstechdays Infrastructure, communication & collaboration

• 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

Agenda


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

Désastre : Rappels sur la reprise d’activité et la continuité d’activité


• 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

Quelques définitions à retenir

TIncident

RPO RTO

Dernière Sauvegarde Service Opérationnel


SLA et couts associésSLA 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é

Cout€€€ €€€ €€€€

99,9%

99,99%

99,95%

99,999%

Jours

Heures

15 Minutes max

1 à 5 Minutes


• 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 analyse d’impact

Prévention d’un désastre : Les choix stratégiques et

organisationnels

Cout du Plan de Secours

RisquesPour

L’entreprise

Si aucun plan de secours n’est prévu, la survie de l’entreprise en en jeu

Le cout du plan de secours ultime est

inapproprié

Le point d’inflexion de la courbe est la zone dans laquelle cibler son plan de secours


• 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…

Prévention d’un désastre : L’approche technologique

Sécurité physique, Urgence, TransportCollaborateurs

Procédures d’urgence, TestsBusiness Process

Retry, Re-route, ReconnexionClients Applicatifs

Backup, log shipping, réplicationApplications Serveur

Backup, replication, snapshots, etc.Operating System

Backup, replication, snapshots, etc.Stockage

Load balancing, Routage, FailoverRéseau

Réplication sur le site secondaireHardware


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

Passons à l’opérationnel : Le cloud pour héberger mon site de

secours








http://www.windowsazure.com/en-us/support/legal/sla/











Passons à l’opérationnel : Le cloud pour héberger mon site de

secours

http://msdn.microsoft.com/library/windowsazure/dn197896.aspx






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













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

http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx

« 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






















• 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

Passons à l’opérationnel : Le cloud pour reconstruire mon site de

secours

Scenarios « cross premise »


• ComputePlateforme 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-with-re-startable-mode-and-sas-token.aspx

Passons à l’opérationnel : Le cloud pour reconstruire mon site de

secours

Scenarios « cross premise »







http://support.microsoft.com/kb/2721672

http://support.microsoft.com/kb/2721672

http://blogs.msdn.com/b/windowsazurestorage/archive/2013/09/07/azcopy-transfer-data-with-re-startable-mode-and-sas-token.aspx



























Passons à l’opérationnel : Hyper V Recovery ManagerOrchestration 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








• 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

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

Passons à l’opérationnel : Le cloud pour reconstruire mon serveur

SQL

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

http://azurespeedtest.azurewebsites.net/







http://msdn.microsoft.com/en-us/library/windowsazure/jj870962.aspx



http://msdn.microsoft.com/en-us/library/hh710077.aspx




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

Demos


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

Un cas particulier : Mon business tourne DEJA sur

Azure

Traffic

Manager

Hosted

Service

Hosted

Service

Hosted

Service

• Load-

balancing

• Endpoint

monitoring

www.foo.com

foo.trafficmgr.cloudapp.net

CNAME

Policies

Geo Replication

Du Stockage

North

Europe

West

Europe

North

Europe

West

EuropeFailover

Azure

DNSGeo Failover

Sync

SQL

Database

Application

Synchronisatio

n

des bases

De données


• 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 TechnicalGuidance : 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/en-us/library/windowsazure/jj853352.aspx

Conclusion




















Questions ?


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 !

Donnez votre avis !

http://notes.mstechdays.fr/

Digital is

business

reprise et continuité d’activité sur le cloud : mythes & réalités

Technology