Reprise et Continuité d'activité
sur le Cloud : Mythes & Réalités
Olivier Sallaberry
Consultant Cloud Computing
Microsoft
...
Agenda
• Désastre : Rappels sur la reprise d’activité et la continuité d’activité

• Prévention d’un désastre : Les choix ...
Désastre : Rappels sur la reprise d’activité et la continuité d’activité
•

Planifier la reprise ou la continuité
d’activi...
Quelques définitions à retenir
•

Plan de reprise d’activité : Procédure de bascule sur un système de secours
permettant l...
SLA et couts associés
SLA

Indisponibilité Annuelle

Indisponibilité Mensuelle

99%

3.65 jours

7.20 heures

99.5%

1.83 ...
Prévention d’un désastre : Les choix stratégiques et
organisationnels
Si aucun plan de
Risques
Pour
L’entreprise

secours ...
Prévention d’un désastre : L’approche technologique
•

Le choix du modèle de secours dépend du
RTO envisagé

•

La définit...
Passons à l’opérationnel : Le cloud pour héberger mon site de
secours
Disponibilité et SLA entreprise
•

•

Chacun des ser...
Passons à l’opérationnel : Le cloud pour héberger mon site de
secours

http://msdn.microsoft.com/library/windowsazure/dn19...
Passons à l’opérationnel : fonctionnement du stockage REST
Azure

http://blogs.msdn.com/b/windowsazurestorage/archive/2010...
Passons à l’opérationnel : stockage REST Azure , quelques
chiffres
« Scalability targets » par compte de stockage
(compte ...
Passons à l’opérationnel : Le cloud pour reconstruire mon site de
secours
Scenarios « cross premise »

• Données
–
–
–
–

...
Passons à l’opérationnel : Le cloud pour reconstruire mon site de
secours
Scenarios « cross premise »
• Compute
Plateforme...
Passons à l’opérationnel : Hyper V Recovery Manager
Orchestration du DRP de clouds privés
Microsoft System Center 2012 Ser...
Passons à l’opérationnel : Le cloud pour reconstruire mon serveur
SQL

•

Scénarios
Always On (réplication asynchrone cros...
Passons à l’opérationnel : Le cloud pour reconstruire mon serveur
SQL
Points relatifs à la mise en œuvre:
-

-

Chaque dis...
Demos
1. Compte de stockage Azure géo répliqué avec access en read only
au réplica secondaire
2. Azure Traffic Manager en ...
Un cas particulier : Mon business tourne DEJA sur
Azure
•

•

•

•

Azure est construit sur de
multiples systèmes de
redon...
Conclusion
•

Disaster Recovery ET Business Continuity au sein d’Azure simples à mettre en
œuvre et peu couteux. Il faut p...
Questions ?
#mstechdays

Infrastructure, communication & collaboration
Donnez votre avis !
Depuis votre smartphone sur :
http://notes.mstechdays.fr
De nombreux lots à gagner toutes les heures !...
Digital is
business
Reprise et Continuité d’activité sur le Cloud : Mythes & Réalités
Prochain SlideShare
Chargement dans…5
×

Reprise et Continuité d’activité sur le Cloud : Mythes & Réalités

752 vues

Publié le

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 :

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
752
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
69
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Modèles de secours : Salle Blanche, Salle Noire, Site Chaud, Site Froid, Site tiède
  • Reprise et Continuité d’activité sur le Cloud : Mythes & Réalités

    1. 1. 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
    2. 2. 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
    3. 3. 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
    4. 4. 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
    5. 5. 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
    6. 6. 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
    7. 7. 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
    8. 8. 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
    9. 9. Passons à l’opérationnel : Le cloud pour héberger mon site de secours http://msdn.microsoft.com/library/windowsazure/dn197896.aspx
    10. 10. 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
    11. 11. 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
    12. 12. 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
    13. 13. 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
    14. 14. 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
    15. 15. 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
    16. 16. 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
    17. 17. 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
    18. 18. 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
    19. 19. 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
    20. 20. Questions ? #mstechdays Infrastructure, communication & collaboration
    21. 21. 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
    22. 22. Digital is business

    ×