Continuité d’activité et reprise d’activité

  • Article

Les charges de travail des applications d’entreprise et d’organisation ont des exigences en termes d’objectif de temps de récupération (RTO) et d’objectif de point de récupération (RPO). Une conception efficace de la continuité d’activité et reprise d’activité fournit des fonctionnalités au niveau de la plateforme qui répondent à ces exigences. Pour concevoir des fonctionnalités de continuité d’activité et reprise d’activité, capturez les exigences en termes de reprise d’activité de la plateforme.

Remarques relatives à la conception

Tenez compte des facteurs suivants lors de la conception de la continuité d’activité et reprise d’activité pour les charges de travail d’application :

  • Exigences en matière de disponibilité des données et des applications :

    • Exigences d’objectifs RTO et RPO pour chaque charge de travail.
    • Prise en charge des modèles de disponibilité actif/actif et actif/passif.

  • Continuité d’activité et reprise d’activité en tant que service pour les services PaaS (Platform-as-a-service) :

    • Prise en charge native des fonctionnalités de reprise d’activité et de haute disponibilité.
    • Fonctionnalités de géo-réplication et de récupération d’urgence pour les services PaaS.

  • Prise en charge des déploiements multirégions à des fins de basculement, avec proximité des composants pour des raisons de performances.

  • Réduction des fonctionnalités ou dégradation des performances des applications lors d’une interruption.

  • Adéquation de la charge de travail pour les zones de disponibilité ou les groupes à haute disponibilité :

    • Partage de données et dépendances entre zones.
    • Impact des zones de disponibilité sur les domaines de mise à jour par rapport aux groupes à haute disponibilité.
    • Pourcentage de charges de travail pouvant être en maintenance simultanément.
    • Prise en charge des zones de disponibilité pour des références SKU de machine virtuelle spécifiques. Par exemple, les disques de stockage Ultra requièrent l’utilisation de zones de disponibilité.

  • Sauvegardes cohérentes pour les applications et les données :

    • Instantanés de machine virtuelle.
    • Coffres Azure Backup Recovery Services.
    • Limites d’abonnement restreignant le nombre et la taille des coffres Recovery Services.

  • Connectivité réseau en cas de basculement :

    • Planification de la capacité de bande passante pour Azure ExpressRoute.
    • Routage du trafic en cas de panne régionale, zonale ou du réseau.

  • Basculements planifiés et non planifiés :

    • Exigences de cohérence des adresses IP et nécessité potentielle de conserver les adresses IP après le basculement et la restauration automatique.
    • Gestion des fonctionnalités de DevOps d’ingénierie.
    • Récupération d’urgence d’Azure Key Vault pour les clés, certificats et secrets d’applications.

  • Résidence des données :

    • Comprenez les conseils nationaux/régionaux en matière de résidence des données, qui précisent si celles-ci doivent être conservées à l'intérieur des frontières d'un pays ou d'une région. Ces conseils ont une incidence sur votre conception en ce qui concerne la réplication inter-région.
    • Les régions Azure qui résident dans la même zone géographique que l'ensemble qui est activé peuvent contribuer à la réplication inter-région pour répondre aux exigences en matière de résidence des données, et notamment celles de nature fiscale et juridique. Pour plus d’informations, consultez Réplication inter-régions Azure.

Recommandations de conception

Les pratiques de conception suivantes prennent en charge la continuité d'activité et reprise d'activité pour les charges de travail d’application :

  • Utilisez Azure Site Recovery dans les scénarios de reprise d’activité de machines virtuelles Azure vers Azure.

    Site Recovery utilise la réplication en temps réel et l’automatisation de la récupération pour répliquer les charges de travail entre différentes régions. Les fonctionnalités de plateforme intégrées pour les charges de travail de machine virtuelle répondent aux exigences d’objectifs RPO et RTO faibles. Vous pouvez utiliser Site Recovery pour exécuter des exercices de récupération sans affecter les charges de travail de production. Vous pouvez également utiliser Azure Policy pour activer la réplication et pour auditer la protection des machines virtuelles.

  • Utilisez les fonctionnalités de reprise d’activité PaaS natives.

    Les fonctionnalités PaaS intégrées simplifient à la fois l’automatisation de la conception et du déploiement pour la réplication et le basculement dans les architectures de charge de travail. Les organisations qui définissent les normes de service peuvent également auditer et appliquer la configuration du service via Azure Policy.

  • Utilisez les fonctionnalités de sauvegarde Azure natives.

    Le service Sauvegarde Azure et les fonctionnalités de sauvegarde PaaS natives éliminent la nécessité de gérer des logiciels et une infrastructure de sauvegarde tiers. Comme avec d’autres fonctionnalités natives, vous pouvez définir, auditer et appliquer des configurations de sauvegarde avec Azure Policy pour garantir la conformité aux exigences de l’organisation.

  • Utilisez plusieurs régions et emplacements d’appairage pour la connectivité ExpressRoute.

    Une architecture réseau hybride redondante peut aider à garantir une connectivité ininterrompue entre différents locaux en cas d’interruption affectant une région Azure ou un emplacement de fournisseur de peering.

  • Évitez d’utiliser des plages d’adresses IP qui se chevauchent dans les réseaux de production et de récupération d’urgence.

    Les réseaux de production et de récupération d’urgence qui se chevauchent nécessitent un processus de basculement qui peut compliquer et retarder le basculement d’application. Dans la mesure du possible, planifiez une architecture réseau de continuité d’activité et reprise d’activité fournissant une connectivité simultanée à tous les sites.