Partager via

Protéger des machines virtuelles déployées sur Azure Stack Hub

  • Article

Utilisez cet article comme guide pour réussir à développer une stratégie de protection des données et de reprise d’activité pour les machines virtuelles IaaS déployées par l’utilisateur sur Azure Stack Hub.

Pour assurer une protection contre la perte de données et les temps d’arrêt prolongés, implémentez un plan de sauvegarde et récupération ou de reprise d’activité pour les applications utilisateur et leurs données. Chaque application doit être évaluée dans le cadre de la stratégie complète de continuité d’activité et reprise d’activité (BCDR) de votre organisation.

Considérations relatives à la protection des machines virtuelles IaaS

Les rôles et responsabilités

Tout d’abord, veillez à bien comprendre les rôles et responsabilités attribués aux propriétaires et aux opérateurs des applications dans le contexte de la protection et de la récupération.

Les utilisateurs sont responsables de la protection des machines virtuelles. Les opérateurs sont responsables du maintien en ligne et de l’intégrité d’Azure Stack Hub. Azure Stack Hub inclut un service qui sauvegarde les données de services internes à partir de services d’infrastructure mais n’inclut aucune donnée utilisateur, comme les machines virtuelles créées par l’utilisateur, les comptes de stockage et leurs données utilisateur ou d’application, ou les bases de données utilisateur.

Propriétaire/Architecte d’application Opérateur Azure Stack Hub
- Aligner l’architecture d’application sur les principes de conception cloud.
- Moderniser les applications traditionnelles en fonction des besoins, pour les préparer à l’environnement cloud.
- Définissez un RTO et un RPO acceptables pour l’application.
- Identifiez les ressources d’application et les référentiels de données qui doivent être protégés.
- Implémentez une méthode de récupération des données et des applications qui s’aligne le mieux sur l’architecture de l’application et les exigences du client.		 - Identifiez les objectifs de continuité d’activité et de reprise d’activité du organization.
- Déployez suffisamment d’instances Azure Stack Hub pour répondre aux objectifs bc/récupération d’urgence du organization.
- Concevoir et exploiter l’infrastructure de protection des données et des applications.
- Fournir des solutions managées ou un accès en libre-service aux services de protection.
- Collaborez avec les propriétaires/architectes d’applications pour comprendre la conception des applications et recommander des stratégies de protection.
- Activer la sauvegarde de l’infrastructure pour la réparation des services et la récupération cloud.

Combinaisons source/cible

Les utilisateurs qui doivent se protéger contre une panne de centre de donnes ou de site peuvent utiliser une autre infrastructure Azure Stack Hub ou Azure pour assurer une haute disponibilité ou une récupération rapide. Avec un emplacement principal et un emplacement secondaire, les utilisateurs peuvent déployer des applications dans une configuration active/active ou active/passive dans deux environnements. Pour les charges de travail moins critiques, les utilisateurs peuvent utiliser la capacité de l’emplacement secondaire pour effectuer une restauration à la demande des applications à partir d’une sauvegarde.

Un ou plusieurs clouds Azure Stack Hub peuvent être déployés dans un centre de données. Pour survivre à un incident catastrophique, le déploiement d’au moins un cloud Azure Stack Hub dans un centre de données différent garantit la possibilité de basculer des charges de travail et de réduire les temps d’arrêt non planifiés. Si vous n’avez qu’un seul cloud Azure Stack Hub, vous devez envisager d’utiliser le cloud public Azure comme cloud de récupération. L’emplacement d’exécution de votre application est déterminé par la législation gouvernementale, les stratégies d’entreprise et les exigences de latence strictes. Vous avez la possibilité de déterminer l’emplacement de récupération approprié par application. Par exemple, vous pouvez faire en sorte que les applications d’un même abonnement sauvegardent les données dans un autre centre de données et dans un autre abonnement, en répliquant les données dans le cloud public Azure.

Objectifs de récupération d’application

Les propriétaires d’applications sont principalement responsables de la détermination de la quantité de temps d’arrêt et de perte de données que l’application et l’organisation peuvent tolérer. En quantifiant les temps d’arrêt et les pertes de données acceptables, vous pouvez créer un plan de récupération qui réduit l’impact d’un sinistre sur votre organisation. Pour chaque application, tenez compte des éléments suivants :

  • Objectif de délai de récupération (RTO)
    Le RTO est la durée maximale acceptable pendant laquelle une application peut être indisponible après un incident. Par exemple, si votre objectif RTO est de 90 minutes, vous devez être en mesure de remettre l’application en état de fonctionnement dans les 90 minutes suivant le début de la panne. Si vous avez un RTO faible, vous pouvez conserver un deuxième déploiement fonctionnant de manière continue en veille, pour vous protéger contre une panne régionale.
  • Objectif de point de récupération (RPO)
    Le RPO est la durée maximale de perte de données acceptable pendant une panne. Par exemple, si vous stockez des données dans une base de données unique qui est sauvegardée toutes les heures sans aucune réplication vers d’autres bases de données, vous risquez de perdre jusqu’à une heure de données.

Il existe une autre métrique, le temps moyen de récupération (MTTR), qui correspond à la durée moyenne nécessaire à la restauration de l’application après une défaillance. Il s’agit d’une valeur empirique pour le système. Si la métrique MTTR dépasse celle de l’objectif RTO, une défaillance du système entraîne une interruption inacceptable des opérations, car il n’est pas possible de restaurer le système au sein de l’objectif RTO défini.

Options de protection

Sauvegarde-restauration

La sauvegarde de vos applications et jeux de données vous permet de récupérer rapidement après un temps d’arrêt dû à une altération des données, à des suppressions accidentelles ou à des sinistres. Pour les applications basées sur des machines virtuelles IaaS, vous pouvez utiliser un agent dans l’invité pour protéger les données d’application, la configuration du système d’exploitation et les données stockées sur les volumes.

Sauvegarder à l’aide d’un agent dans l’invité

La sauvegarde d’une machine virtuelle à l’aide d’un agent de système d’exploitation invité inclut généralement la capture de la configuration du système d’exploitation, des fichiers/dossiers, des disques, des binaires d’application ou des données d’application.

La récupération d’une application à partir d’un agent nécessite de recréer manuellement la machine virtuelle, d’installer le système d’exploitation et d’installer l’agent invité. À ce stade, les données peuvent être restaurées dans le système d’exploitation invité ou directement dans l’application.

Sauvegarde à l’aide d’un instantané de disque pour les machines virtuelles arrêtées

Certains produits de sauvegarde peuvent protéger la configuration des machines virtuelles IaaS et les disques attachés à une machine virtuelle arrêtée. Utilisez des produits de sauvegarde qui s’intègrent aux API Azure Stack Hub pour capturer la configuration des machines virtuelles et créer des captures instantanées de disque. Si un temps d’arrêt planifié est possible pour l’application, vérifiez que la machine virtuelle est arrêtée avant de démarrer le workflow de sauvegarde.

Sauvegarde à l’aide d’un instantané de disque les machines virtuelles en cours d’exécution

Important

L’utilisation d’instantanés de disque à partir du portail n’est actuellement pas prise en charge pour la machine virtuelle en cours d’exécution. La création d’un instantané d’un disque attaché à une machine virtuelle en cours d’exécution peut dégrader les performances ou avoir un impact sur la disponibilité du système d’exploitation ou de l’application dans la machine virtuelle. Il est recommandé d’utiliser une solution de fournisseur de sauvegarde qui s’intègre à la fonctionnalité de instantané incrémentielle rp de stockage ou à un agent invité pour protéger l’application si un temps d’arrêt planifié n’est pas une option.

Machines virtuelles dans un groupe identique ou dans un groupe à haute disponibilité

Les machines virtuelles incluses dans un groupe identique ou un groupe de disponibilité considérées comme des ressources éphémères ne doivent pas être sauvegardées au niveau de la machine virtuelle, particulièrement si l’application est sans état. Pour les applications avec état déployées dans un groupe identique ou un groupe à haute disponibilité, envisagez de protéger les données d’application (par exemple une base de données ou un volume dans un pool de stockage).

Réplication/basculement manuel

Pour les applications qui nécessitent une perte de données minimale ou un temps d’arrêt minimal, la réplication des données peut être activée au niveau de l’application ou du système d’exploitation invité pour répliquer les données à un autre emplacement. Certaines applications, comme Microsoft SQL Server, prennent en charge la réplication de façon native. Si l’application ne prend pas en charge la réplication, vous pouvez utiliser un logiciel dans le système d’exploitation invité pour répliquer des disques ou une solution partenaire qui s’installe en tant qu’agent dans le système d’exploitation invité.

Avec cette approche, l’application est déployée dans un cloud et les données sont répliquées dans l’autre cloud local ou sur Azure. Quand un basculement est déclenché, l’application située dans la cible doit être démarrée et attachée aux données répliquées pour pouvoir commencer à traiter les demandes.

Haute disponibilité/basculement automatique

Pour les applications sans état qui ne peuvent tolérer que quelques secondes ou minutes de temps d’arrêt, envisagez une configuration à haute disponibilité. Les applications à haute disponibilité sont conçues pour être déployées à plusieurs emplacements dans une topologie active/active dans laquelle toutes les instances peuvent traiter des demandes. Pour les pannes matérielles locales, l’infrastructure Azure Stack Hub implémente la haute disponibilité dans le réseau physique à l’aide de deux commutateurs TOR (Top of Rack). Pour les pannes au niveau du calcul, Azure Stack Hub utilise plusieurs nœuds dans une unité d’échelle et bascule automatiquement une machine virtuelle. Au niveau de la machine virtuelle, vous pouvez utiliser des groupes identiques ou des machines virtuelles dans un groupe à haute disponibilité pour garantir que les pannes des nœuds n’interrompent pas votre application. La même application doit alors être déployée sur un emplacement secondaire dans la même configuration. Pour rendre l’application active/active, un équilibreur de charge ou un système DNS peuvent être utilisés pour diriger les demandes vers toutes les instances disponibles.

Aucune récupération

Certaines applications de votre environnement peuvent ne pas avoir besoin d’être protégées contre des temps d’arrêt non planifiés ou une perte de données. Par exemple, les machines virtuelles utilisées pour le développement et le test n’ont généralement pas besoin d’être récupérées. C’est à vous de décider si vous souhaitez ou non protéger une application ou un jeu de données spécifique.

Considérations importantes pour votre déploiement Azure Stack Hub :

Recommandation Commentaires
Sauvegarder/restaurer des machines virtuelles vers une cible de sauvegarde externe déjà déployée dans votre centre de données Recommandé Tirez parti de l’infrastructure de sauvegarde existante et des capacités opérationnelles. Veillez à dimensionner l’infrastructure de sauvegarde pour qu’elle soit prête à protéger les instances de machine virtuelle supplémentaires. Assurez-vous que l’infrastructure de sauvegarde ne se trouve pas juste à côté de votre source. Vous pouvez restaurer des machines virtuelles du compte Azure Stack Hub source dans une instance secondaire Azure Stack Hub ou Azure.
Sauvegarder/restaurer des machines virtuelles vers une cible de sauvegarde externe dédiée à Azure Stack Hub Recommandé Vous pouvez acheter une nouvelle infrastructure de sauvegarde ou une infrastructure de sauvegarde dédiée à l’approvisionnement pour Azure Stack Hub. Assurez-vous que l’infrastructure de sauvegarde ne se trouve pas juste à côté de votre source. Vous pouvez restaurer des machines virtuelles du compte Azure Stack Hub source dans une instance secondaire Azure Stack Hub ou Azure.
Sauvegarder/restaurer des machines virtuelles directement vers Azure global ou un fournisseur de services fiable Recommandé Tant que vous pouvez satisfaire à vos exigences en matière de réglementation et de confidentialité des données, vous pouvez stocker vos sauvegardes dans Azure global ou un fournisseur de services fiable. Dans l’idéal, le fournisseur de services exécute également Azure Stack Hub pour que votre expérience opérationnelle soit cohérente lorsque vous effectuez une restauration.
Répliquer/basculer des machines virtuelles vers une instance Azure Stack Hub distincte Recommandé Dans le cas d’un basculement, vous devez avoir un deuxième cloud Azure Stack Hub totalement opérationnel afin d’éviter des temps d’arrêt prolongés.
Répliquer/basculer des machines virtuelles directement vers Azure ou un fournisseur de services fiable Recommandé Tant que vous pouvez satisfaire à vos exigences obligatoires et en matière de confidentialité des données, vous pouvez répliquer vos données dans Azure global ou un fournisseur de services fiable. Dans l’idéal, le fournisseur de services exécute également Azure Stack Hub pour que votre expérience opérationnelle soit cohérente après un basculement.
Déployez une cible de sauvegarde sur le même cloud Azure Stack Hub que celui qui héberge également toutes les applications protégées par la même cible de sauvegarde. Cible autonome : Non recommandé
Cible qui réplique les données de sauvegarde en externe : Recommandé		 Si vous choisissez de déployer une appliance de sauvegardes sur Azure Stack Hub (à des fins d’optimisation de la restauration opérationnelle), vous devez vous assurer que toutes les données sont copiées en continu dans un emplacement de sauvegarde externe.
Déployer l’appliance de sauvegarde physique dans le même rack que celui où la solution Azure Stack Hub est installée Non pris en charge Vous ne pouvez actuellement pas connecter d’autres appareils à des commutateurs TOR qui ne font pas partie de la solution d’origine.

Considérations relatives à une machine virtuelle IaaS restaurée

Vous devrez apporter certaines modifications à votre machine virtuelle après la restauration de la machine à partir de la sauvegarde. Il s’agit notamment des paramètres suivants :

  • Adresse MAC
    La carte réseau virtuelle obtiendra une nouvelle adresse MAC. Aucune méthode ne permet de conserver l’adresse MAC d’origine.
  • Adresse IP
    Si votre machine virtuelle possède une adresse IP statique définie en interne, l’adresse IP interne de la carte réseau virtuelle peut être configurée pour correspondre à l’adresse d’origine. Vous devrez peut-être vérifier si le réseau virtuel comporte un VPN S2S vers un environnement externe dans lequel l’adresse IP peut être en cours d’utilisation.
  • Artefacts inutiles
    Si la machine virtuelle a été sauvegardée sur une autre plateforme, par exemple VMware vSphere, vous devrez effectuer quelques étapes supplémentaires pour supprimer les artefacts inutiles de la source.

Étapes suivantes

Cet article vous a fourni des recommandations générales sur la protection des machines virtuelles utilisateur déployées sur Azure Stack Hub. Pour plus d’informations sur l’utilisation des services Azure pour protéger les machines virtuelles des utilisateurs, consultez :