Récupération d’urgence pour les machines virtuelles Azure Stack Hub

Cet article décrit les considérations relatives à l’architecture et à la conception d’une solution qui offre une approche optimisée de la reprise d’activité des charges de travail qui s’exécutent sur des machines virtuelles hébergées sur Azure Stack Hub.

Architecture

Téléchargez un fichier Visio de cette architecture.

Workflow

Les composants cloud de la solution proposée incluent les services suivants :

• Un abonnement Azure hébergeant toutes les ressources cloud qui font partie de cette solution

• Un locataire Microsoft Entra ID associé à l’abonnement Azure qui fournit l’authentification des principaux de sécurité Microsoft Entra pour autoriser l’accès aux ressources Azure.

• Un coffre Azure Recovery Services dans la région Azure la plus proche d’un centre de données local qui héberge le déploiement d’Azure Stack Hub

  Notes

  Le choix de la région Azure la plus proche du centre de donnée local est propre à l’exemple de scénario inclus dans cet article. Du point de vue de la reprise d’activité, il est préférable de sélectionner une région Azure plus éloignée de l’emplacement hébergeant l’environnement de production. Toutefois, la décision peut dépendre d’autres facteurs, tels que la nécessité de réduire la latence des flux de données régionaux ou de satisfaire aux exigences de résidence des données.

• Un circuit Azure ExpressRoute qui connecte les centres de données locaux à la région Azure hébergeant le coffre Azure Recovery Services, configuré avec un appairage privé et un appairage Microsoft. Le premier garantit que les exigences de latence sont satisfaites après un basculement. L’objectif de ce dernier est de réduire le temps de réplication des modifications entre les charges de travail locales et le site de basculement dans Azure

• Un compte Stockage Azure qui héberge des blobs contenant des fichiers VHD créés par la réplication du système d’exploitation et des volumes de données des machines virtuelles Azure Stack Hub protégées. Ces fichiers VHD servent de source pour les disques managés de machines virtuelles Azure qui sont provisionnés automatiquement après un basculement

• Un réseau virtuel Azure qui héberge l’environnement de reprise d’activité. Il est configuré de manière à refléter l’environnement de réseau virtuel dans Azure Stack Hub qui héberge les charges de travail de production, notamment des composants tels que des équilibreurs de charge et des groupes de sécurité réseau. Ce réseau virtuel est généralement connecté au réseau virtuel Azure Stack Hub via une connexion ExpressRoute pour faciliter la récupération au niveau de la charge de travail.

  Notes

  Parfois, une connexion VPN site à site suffit dans les scénarios où les exigences en matière de points de récupération (RPO) sont moins strictes.

• Un réseau virtuel Azure isolé destiné aux basculements tests, configuré de manière à refléter l’environnement de réseau virtuel dans Azure Stack Hub hébergeant les charges de travail de production, notamment des composants tels que des équilibreurs de charge et des groupes de sécurité réseau.

Les composants locaux de la solution proposée incluent les services suivants :

• Un système intégré Azure Stack Hub dans le modèle de déploiement connecté. Le système exécute la mise à jour actuelle (2002 à compter du 20/09) et se trouve dans le centre de données local du client

• Un abonnement Azure Stack Hub et un ou plusieurs réseaux virtuels appairés qui hébergent toutes les machines virtuelles locales pour cette solution

• Des serveurs de configuration et de traitement Azure Site Recovery qui s’exécutent sur des machines virtuelles Azure Hub Stack Windows Server 2016 ou 2012 R2. Les serveurs gèrent les communications avec le coffre Azure Recovery Services, ainsi que le routage, l’optimisation et le chiffrement du trafic de réplication

  Notes

  Par défaut, un serveur de configuration héberge un seul serveur de traitement. Vous pouvez déployer des serveurs de traitement dédiés pour prendre en charge un plus grand volume de trafic de réplication.

• Les machines virtuelles Azure Stack Hub qui doivent être protégées. Elles exécutent des versions prises en charge des systèmes d’exploitation Windows Server, CentOS et Ubuntu

• Le service Mobilité Site Recovery (également appelé agent de mobilité) qui s’exécute sur des machines virtuelles protégées. Il effectue le suivi des modifications apportées aux disques locaux, enregistre les modifications dans les journaux de réplication et réplique les journaux sur le serveur de traitement. Le serveur de traitement les route vers le compte Stockage Azure cible. Les journaux sont utilisés pour créer des points de récupération pour les disques managés implémentés à l’aide d’objets blob stockés dans le compte Stockage Azure que vous désignez.

Composants

• Microsoft Entra ID
• Réseau virtuel Azure
• Azure Recovery Services
• Azure ExpressRoute
• Stockage Blob Azure
• Azure Stack Hub

Autres solutions

La solution recommandée décrite dans cet article n’est pas la seule façon de fournir des fonctionnalités de reprise d’activité pour des charges de travail de machine virtuelle Azure Stack Hub. Les clients ont d’autres options, à savoir :

• Basculement vers un autre tampon Azure Stack Hub. Les utilisateurs qui ont besoin de se protéger contre une interruption de centre de données ou de site peuvent parfois utiliser un autre déploiement d’Azure Stack Hub pour implémenter des dispositions de récupération d’urgence. Avec des emplacements principal et secondaire, les utilisateurs peuvent déployer des applications dans une configuration active/active ou dans deux environnements. Pour les charges de travail moins critiques, il peut être acceptable d’utiliser de la capacité inutilisée dans l’emplacement secondaire pour effectuer la restauration à la demande d’applications à partir d’une sauvegarde. Vous pouvez également implémenter un site de récupération dans un autre centre de données qui, à son tour, utilise Azure Site Recovery pour provisionner un réplica du site de récupération dans Azure. Plusieurs facteurs déterminent si l’utilisation de Site Recovery avec Azure servant de site de basculement est une solution viable. Ces facteurs incluent des réglementations gouvernementales, des stratégies d’entreprise et des exigences de latence.

  Notes

  Depuis le mois de juillet 2020, Site Recovery ne prend plus en charge ce scénario, ce qui signifie que l’implémentation doit utiliser une solution partenaire ou interne.

• Sauvegarde et restauration. La sauvegarde de vos applications et jeux de données vous permet de récupérer rapidement suite à un temps d’arrêt occasionnant un endommagement ou des suppressions accidentelles de données, ou encore des pannes localisées. Pour les applications basées sur des machines virtuelles Azure Stack Hub, vous pouvez utiliser un agent dans l’invité pour protéger les données d’application, les configurations du système d’exploitation et les données stockées sur des volumes. La sauvegarde d’une machine virtuelle à l’aide d’un agent de système d’exploitation invité inclut généralement la capture des configurations du système d’exploitation, des fichiers, des dossiers, des volumes, des fichiers 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 la machine virtuelle, puis d’installer le système d’exploitation et l’agent invité. À ce stade, vous pouvez restaurer des données dans le système d’exploitation invité.

• Sauvegarde des captures instantanées de disque. Il est possible d’utiliser des captures instantanées pour capturer une configuration de machine virtuelle Azure Stack Hub et les disques qui sont attachés à une machine virtuelle arrêtée. Ce processus requiert des produits de sauvegarde qui s’intègrent avec les API Azure Stack Hub pour capturer la configuration des machines virtuelles et créer des captures instantanées de disque.

  Notes

  Depuis juillet 2020, l’utilisation d’instantanés de disque pour les machines virtuelles en cours d’exécution n’est pas prise en charge. La création d’un instantané d’un disque attaché à une machine virtuelle en cours d’exécution peut dégrader les performances ou affecter la disponibilité du système d’exploitation ou de l’application dans la machine virtuelle.

• Sauvegardez et restaurez les machines virtuelles à l’aide d’une solution de sauvegarde externe située dans le même centre de données, puis répliquez les sauvegardes vers un autre emplacement. De cette façon, vous pouvez restaurer des machines virtuelles Azure Stack Hub sur la même instance Azure Stack Hub, ou sur une autre instance, ou sur Azure.

Détails du scénario

Azure Stack Hub comprend une fonctionnalité de réparation spontanée, qui fournit une correction automatique dans une série de scénarios impliquant des défaillances localisées de ses composants. Toutefois, des défaillances à grande échelle, notamment des interruptions qui affectent des racks de serveurs ou des sinistres au niveau du site, nécessitent des considérations supplémentaires. Ces considérations doivent faire partie de la stratégie de continuité d’activité et de récupération d’urgence pour les charges de travail utilisateur basées sur des machines virtuelles. Cette stratégie doit également tenir compte de la récupération de l’infrastructure Azure Stack, qui est distincte de la récupération de la charge de travail.

La configuration des solutions de récupération de charges de travail locales traditionnelles est complexe, leur maintenance est coûteuse et laborieuse, et leur automatisation est difficile, en particulier lorsque vous utilisez un autre emplacement local comme site de basculement. Microsoft recommande une solution alternative reposant sur une combinaison de composants cloud et locaux pour fournir des moyens résilients, basés sur les performances, hautement automatisés et simples pour établir, gérer et sécuriser une stratégie de reprise d’activité rentable. L’élément fondamental de cette solution est Site Recovery, avec le site de basculement résidant dans Azure.

Cas d’usage potentiels

Site Recovery avec Azure comme site de basculement élimine tous les inconvénients mentionnés ci-dessus. Vous pouvez utiliser ses fonctionnalités pour protéger les serveurs physiques et virtuels, y compris ceux qui s’exécutent sur des plateformes de virtualisation Microsoft Hyper-V ou VMware ESXi. Vous pouvez également utiliser les mêmes fonctionnalités afin de faciliter la récupération des charges de travail qui s’exécutent sur des machines virtuelles Azure Stack Hub.

Principales fonctionnalités

Site Recovery est une solution de reprise d’activité qui facilite la protection des ordinateurs physiques et virtuels en fournissant deux ensembles de fonctionnalités :

• Réplication des modifications sur les disques d’ordinateur situés entre les emplacements de production et de reprise d’activité
• Orchestration du basculement et de la restauration automatique entre ces deux emplacements

Site Recovery offre trois types de basculements :

• Basculement test. Ce basculement vous donne la possibilité de valider votre configuration Site Recovery dans un environnement isolé, sans perte de données ou impact sur l’environnement de production.
• Basculement planifié. Ce basculement vous donne la possibilité d’initier une récupération d’urgence sans perte de données, généralement dans le cadre d’un temps d’arrêt planifié.
• Basculement non planifié. Ce basculement fait office de dernier recours en cas d’interruption non planifiée affectant la disponibilité du site principal, et susceptible d’entraîner une perte de données.

Site Recovery prend en charge plusieurs scénarios, tels que le basculement et la restauration automatique entre deux sites locaux ou deux régions Azure, et la migration à partir de clouds de fournisseurs tiers. Toutefois, dans le contexte de cet article, nous nous concentrons sur la réplication des disques locaux des machines virtuelles Azure Stack Hub vers le service Stockage Azure, ainsi que sur le basculement et la restauration automatique des machines virtuelles entre une pile Azure Stack Hub et une région Azure.

Les détails de l’architecture de Site Recovery et de ses composants dépendent de plusieurs critères, à savoir :

• Types d’ordinateurs à protéger (physiques ou virtuels).
• Pour les environnements virtualisés, le type d’hyperviseur hébergeant les machines virtuelles à protéger (Hyper-V et VMware ESXi).
• Pour les environnements Hyper-V, l’utilisation de System Center Virtual Machine Manager (SCVMM) pour la gestion des hôtes Hyper-V.

Avec Azure Stack Hub, l’architecture correspond à celle applicable aux ordinateurs physiques. Cela n’est pas particulièrement étonnant car, dans les deux cas, Site Recovery ne peut pas bénéficier d’un accès direct à un hyperviseur. Au lieu de cela, le mécanisme qui effectue le suivi et la réplication des modifications sur les disques locaux est implémenté au sein du système d’exploitation protégé.

Pour ce faire, Site Recovery s’appuie sur le service Mobilité Site Recovery (également appelé agent de mobilité), qui est déployé automatiquement sur chaque machine virtuelle lorsque vous les inscrivez dans l’étendue de la protection basée sur Site Recovery. Sur chaque machine virtuelle protégée, l’instance installée localement de l’agent Mobilité surveille et transfère en permanence les modifications apportées au système d’exploitation et aux disques de données sur le serveur de traitement. Toutefois, pour optimiser et gérer le flux de trafic de réplication provenant des machines virtuelles protégées, Site Recovery implémente un ensemble supplémentaire de composants s’exécutant sur une machine virtuelle distincte, appelée serveur de configuration.

Le serveur de configuration coordonne les communications avec le coffre Site Recovery, et gère la réplication des données. En outre, le serveur de configuration héberge un composant appelé serveur de traitement faisant office de passerelle qui reçoit les données de réplication, les optimise via une mise en cache et une compression, les chiffre, puis les transfère au service Stockage Azure. En fait, le serveur de configuration fonctionne comme point d’intégration entre Site Recovery et les machines virtuelles protégées s’exécutant sur Azure Stack Hub. Vous implémentez cette intégration en déployant le serveur de configuration et en l’inscrivant auprès du coffre Azure Recovery Services.

Dans le cadre de la configuration de Site Recovery, vous définissez l’environnement de reprise d’activité souhaité, notamment les composants d’infrastructure tels que les réseaux virtuels, les équilibreurs de charge ou les groupes de sécurité réseau, de manière à refléter l’environnement de production. La configuration inclut également une stratégie de réplication qui détermine les fonctionnalités de récupération et comprend les paramètres suivants :

• Seuil d’objectif de point de récupération. Ce paramètre représente l’objectif de point de récupération que vous souhaitez implémenter, et détermine la fréquence à laquelle Site Recovery génère des captures instantanées de points de récupération cohérents avec les incidents. Sa valeur n’affecte pas la fréquence de réplication, car la réplication est continue. Site Recovery génère une alerte et, éventuellement, une notification par e-mail, si l’objectif de point de récupération effectif actuel fourni par Site Recovery dépasse le seuil que vous spécifiez. Site Recovery génère des captures instantanées de points de récupération cohérents avec les incidents toutes les cinq minutes.

  Notes

  Un instantané de cohérence en cas d’incident capture les données qui se trouvaient sur le disque lorsque l’instantané a été pris. Elle n’inclut pas le contenu de la mémoire. En effet, une capture instantanée de cohérence en cas d’incident ne garantit pas la cohérence des données pour le système d’exploitation ou des applications installées localement.

• Rétention des points de récupération. Ce paramètre représente la durée (en heures) de la fenêtre de rétention de chaque capture instantanée de point de récupération. Les machines virtuelles protégées peuvent être récupérées à n’importe quel point de récupération au sein d’une fenêtre de rétention. Site Recovery prend en charge jusqu’à 24 heures de rétention pour les machines virtuelles répliquées sur des comptes Stockage Azure avec le niveau de performance Premium. Une limite de rétention de 72 heures est utilisée lors de l’utilisation de comptes Stockage Azure avec le niveau de performances Standard.

• Fréquence de cohérence des applications. Ce paramètre détermine la fréquence (en heures) à laquelle Site Recovery génère des captures instantanées cohérentes avec les applications. Une capture instantanée de cohérence des applications représente un instantané à un point dans le temps des applications s’exécutant sur une machine virtuelle protégée. Il existe une limite de 12 captures instantanées cohérentes avec les applications. Pour des machines virtuelles exécutant Windows Server, Site Recovery utilise le service VSS (Volume Shadow Copy Service). Site Recovery prend également en charge les captures instantanées cohérentes avec les applications pour Linux, mais celle-ci requièrent l’implémentation de scripts personnalisés. Les scripts sont utilisés par l’agent Mobilité lors de l’application d’une capture instantanée de cohérence des applications.

  Notes

  Pour plus d’informations sur l’implémentation de captures instantanées cohérentes avec les applications sur des machines virtuelles Azure Stack Hub exécutant Linux, consultez Questions générales sur Site Recovery.

Pour chaque disque d’une machine virtuelle Azure Stack Hub protégée que vous désignez, les données sont répliquées sur un disque managé correspondant du service Stockage Azure. Le disque stocke la copie du disque source et l’ensemble des captures instantanées de cohérence en cas d’incident de point de récupération et de cohérence des applications. Dans le cadre d’un basculement, vous choisissez une capture instantanée de cohérence en cas d’incident de point de récupération et de cohérence des applications qui doit être utilisée lors de l’attachement du disque managé à la machine virtuelle Azure qui sert de réplica de la machine virtuelle Azure Stack Hub protégée.

Pendant des opérations d’entreprise régulières, les charges de travail protégées s’exécutent sur des machines virtuelles Azure Stack Hub, les modifications apportées à leurs disques étant répliquées en continu via des interactions entre l’agent Mobilité, le serveur de traitement et le serveur de configuration sur le compte de stockage Azure désigné. Lorsque vous lancez un basculement de test, planifié ou non planifié, Site Recovery provisionne automatiquement les machines virtuelles Azure à l’aide des réplicas de disques des machines virtuelles Azure Stack Hub correspondantes.

Vous avez la possibilité d’orchestrer un basculement en créant des plans de récupération contenant des étapes manuelles et automatisées. Pour implémenter ces dernières, vous pouvez utiliser des runbooks Azure Automation, qui se composent de scripts PowerShell personnalisés, de workflows PowerShell ou de scripts Python 2.

Lorsque le site principal redevient disponible, Site Recovery prend en charge l’inversion de la direction de la réplication, ce qui vous permet d’effectuer une restauration automatique avec un temps d’arrêt minimal et sans perte de données. Toutefois, avec Azure Stack Hub, cette approche n’est pas disponible. Au lieu de cela, pour effectuer une restauration automatique, il est nécessaire de télécharger les fichiers de disque de machine virtuelle Azure, de les charger dans Azure Stack Hub et de les joindre à des machines virtuelles existantes ou nouvelles.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Azure Stack Hub permet d’augmenter la disponibilité des charges de travail grâce à une résilience inhérente à son infrastructure. Cette résilience offre une haute disponibilité pour les machines virtuelles Azure Stack Hub protégées par Site Recovery, ainsi que pour les composants essentiels de l’infrastructure Site Recovery locale, dont les serveurs de configuration et de traitement.

De même, vous avez la possibilité d’utiliser la résilience des composants basés sur le cloud de l’infrastructure Site Recovery. Par défaut, Azure Recovery Services est géoredondant, ce qui signifie que sa configuration est automatiquement répliquée vers une région Azure qui fait partie d’une paire de régions prédéfinie. Vous avez la possibilité de modifier les paramètres de réplication « À redondance locale » si cela suffit à vos besoins en matière de résilience. Notez que vous ne pouvez pas modifier cette option si le coffre contient des éléments protégés. La même option de résilience est disponible pour tous les comptes de stockage Azure avec le niveau de performance standard, bien qu’il soit possible de la changer à tout moment.

Vous pouvez encore améliorer le degré de résilience en concevant et en implémentant des solutions qui augmentent l’étendue de la protection des charges de travail. Il s’agit de la valeur ajoutée fournie par Site Recovery. Dans le contexte de Site Recovery s’exécutant sur Azure Stack Hub, il existe deux aspects majeurs de la disponibilité des charges de travail à explorer de plus près :

• Basculement vers Azure
• Restauration automatique sur Azure Stack Hub

Vous devez prendre en compte les deux lorsque vous développez une stratégie de récupération d’urgence conduite par des objectifs de point de récupération (RPO) et des objectifs de temps de récupération (RTO). Les RTO et RPO constituent des exigences de continuité stipulées par des fonctions métier individuelles au sein d’une organisation. Le RPO désigne une période de temps représentant une perte de données maximale acceptable à la suite d’un incident qui a affecté la disponibilité de ces données. Le RTO désigne le temps maximal acceptable que peut prendre le rétablissement des fonctions métier à la suite d’un incident qui a affecté la disponibilité de ces fonctions.

Basculement vers Azure

Le basculement vers Azure est au cœur des considérations de disponibilité dans le contexte de la protection basée sur Site Recovery des machines virtuelles Azure Stack Hub. Pour optimiser la disponibilité des charges de travail, la stratégie de basculement doit répondre à la nécessité de réduire les pertes de données potentielles (RPO) et réduire le temps de basculement (RTO).

Pour réduire les pertes de données potentielles, vous pouvez envisager les approches suivantes :

• Maximisation du débit et minimisation de la latence du trafic de réplication en suivant les considérations relatives à la scalabilité et aux performances. Pour plus d’informations, consultez la section suivante de cet article.
• Amélioration de la fréquence des points de récupération de cohérence des applications pour les charges de travail de base de données (jusqu’au maximum d’un point de récupération par heure). Les points de récupération de cohérence des applications sont créés à partir d’instantanés de cohérence des applications. Les instantanés de cohérence des applications capturent les données d’application sur disque et en mémoire. Bien que cette approche minimise la perte de données potentielle, elle présente un inconvénient majeur. Les captures instantanées de cohérence des applications requièrent l’utilisation du service de cliché instantané des volumes, ou Service VSS (Volume Shadow Copy Service), sur Windows, ou de scripts personnalisés sur Linux, pour suspendre des applications installées localement. Le processus de capture peut nuire aux performances, en particulier si l’utilisation des ressources est élevée. Nous déconseillons d’utiliser une fréquence faible pour les captures instantanées cohérentes avec les applications en lien avec les charges de travail autres que de bases de données.

La méthode principale de minimisation du temps de basculement implique l’utilisation de plans de récupération Site Recovery. Un plan de récupération orchestre un basculement entre les sites principal et secondaire, en définissant l’ordre dans lequel les serveurs protégés basculent. Vous pouvez personnaliser un plan en ajoutant des instructions manuelles et des tâches automatisées. Son objectif est de rendre le processus cohérent, précis, reproductible et automatisé.

Lorsque vous créez un plan de récupération, vous affectez des serveurs protégés à des groupes de récupération à des fins de basculement. Les serveurs de chaque groupe basculent ensemble. Cela vous permet de diviser le processus de basculement en unités plus petites et plus faciles à gérer, représentant des jeux de serveurs qui peuvent basculer sans s’appuyer sur des dépendances externes.

Pour réduire le temps de basculement, dans le cadre de la création d’un plan de récupération, vous devez :

• définir des groupes de machines virtuelles Azure Stack Hub qui doivent basculer ensemble ;
• définir des dépendances entre des groupes de machines virtuelles Azure Stack Hub pour déterminer la séquence optimale d’un basculement ;
• automatiser les tâches de basculement, si possible ;
• inclure des actions manuelles personnalisées, si nécessaire.

Vous définissez un plan de récupération et créez des groupes de récupération pour capturer des propriétés spécifiques de l’application. À titre d’exemple, prenons une application classique à trois niveaux avec un back-end basé sur SQL Server, un composant intergiciel (middleware) et un front-end web. Lors de la création d’un plan de récupération, vous pouvez contrôler l’ordre de démarrage des serveurs dans chaque niveau, avec d’abord la mise en ligne des serveurs exécutant les instances SQL Server, suivie de ceux qui se trouvent au niveau middleware, rejoints ensuite par les serveurs hébergeant le front-end web. Cette séquence garantit que l’application fonctionne au moment du démarrage du dernier serveur. Pour l’implémenter, vous pouvez simplement créer un plan de récupération avec trois groupes de récupération, contenant des serveurs aux niveaux respectifs.

En plus de contrôler le basculement et l’ordre de démarrage, vous avez la possibilité d’ajouter des actions à un plan de récupération. En général, il existe deux types d’actions :

• Automatisées. Ces actions sont basées sur des runbooks Azure Automation, ce qui implique l’un des deux types de tâches suivants :
  • Approvisionnement et configuration des ressources Azure, notamment par la création d’une adresse IP publique et l’association de celle-ci à l’interface réseau attachée à une machine virtuelle Azure.
  • Modification de la configuration du système d’exploitation et des applications s’exécutant dans une machine virtuelle Azure approvisionnée à la suite d’un basculement.
• Manuelles. Ces actions ne prennent pas en charge l’automatisation et sont incluses dans un plan de récupération, principalement à des fins de documentation.

Restauration automatique sur Azure Stack Hub

Dans les scénarios basés sur Site Recovery, la restauration automatique, si elle est correctement implémentée, n’implique pas de perte de données. Cela signifie que la stratégie de basculement doit se focaliser sur la minimisation du temps de restauration automatique (RTO). Toutefois, comme mentionné précédemment, lors de la restauration automatique sur Azure Stack Hub, vous ne pouvez pas compter sur vos plans de récupération. Au lieu de cela, la restauration automatique implique la séquence d’étapes suivante :

1. Arrêtez et désallouez des machines virtuelles Azure dans l’environnement de récupération d’urgence.
2. Identifiez le paramètre URI de chaque disque managé attaché aux machines virtuelles que vous souhaitez télécharger.
3. Téléchargez dans votre environnement local les fichiers de disque dur virtuel (VHD) identifiés par les paramètres URI que vous avez identifiés à l’étape précédente.
4. Chargez les fichiers VHD sur Azure Stack Hub.
5. Attachez les disques durs virtuels téléchargés à des machines virtuelles Azure Stack Hub nouvelles ou existantes.
6. Démarrez les machines virtuelles Azure Stack Hub.

L’approche optimale pour minimiser le temps de restauration automatique consiste à l’automatiser.

Considérations spécifiques de la charge de travail

Site Recovery s’intègre avec les applications et rôles basés sur Windows Server, à savoir SharePoint, Exchange, SQL Server et AD DS (Active Directory Domain Services). Cela vous permet d’utiliser les fonctionnalités suivantes pour implémenter la protection et la récupération au niveau de l’application :

• intégration avec les technologies de réplication au niveau de l’application, telles que les groupes de disponibilité SQL Server AlwaysOn, les groupes de disponibilité de base de données Exchange (DAG) et la réplication AD DS ;
• captures instantanées de cohérence des applications pour les applications uniques ou multiniveaux ;
• bibliothèque d’automatisation riche qui fournit des scripts spécifiques d’application prêts pour la production, qui peuvent être téléchargés et intégrés avec des plans de récupération.

Vous avez également la possibilité d’utiliser des mécanismes de réplication spécifiques de la charge de travail pour fournir une résilience au niveau du site. Il s’agit d’une option couramment utilisée lors de l’implémentation de la récupération d’urgence pour les contrôleurs de domaine AD DS, SQL Server ou Exchange, qui prennent tous en charge en mode natif la réplication. Bien que cette solution nécessite l’approvisionnement de machines virtuelles Azure hébergeant ces charges de travail dans l’environnement de récupération d’urgence, contribuant ainsi à augmenter le coût, elle offre les avantages suivants :

• réduit le temps nécessaire pour le basculement et la restauration automatique ;
• simplifie le basculement au niveau de la charge de travail et les scénarios dans lesquels un basculement au niveau du site n’est pas requis.

Sécurité

La gestion de la récupération d’urgence des charges de travail utilisateur basées sur des machines virtuelles dans des scénarios hybrides justifie l’énonciation de considérations relatives à la sécurité supplémentaires. Ces considérations peuvent être regroupées dans les catégories suivantes :

• Chiffrement en transit. Celui-ci comprend la communication entre les machines virtuelles Azure Stack Hub protégées, les composants de Site Recovery locaux et les composants Site Recovery basés sur le cloud :

  • L’agent Mobilité installé sur les machines virtuelles protégées communique toujours avec le serveur de traitement via le protocole TLS (Transport Layer Security) 1.2.
  • Les communications des serveurs de configuration et de traitement vers Azure peuvent utiliser les protocoles TLS 1.1 ou 1.0. Pour augmenter le niveau de sécurité de la connectivité hybride, vous devez envisager d’appliquer l’utilisation du protocole TLS 1.2.

  Notes

  Pour plus d’informations sur la configuration du chiffrement basé sur le protocole TLS 1.2, consultez Paramètres de Registre TLS et Mise à jour pour activer TLS 1.1 et TLS 1.2 en tant que protocoles sécurisés par défaut dans WinHTTP sur Windows.

• Chiffrement au repos. Celui-ci inclut le service stockage Azure et des machines virtuelles Azure sur le site de récupération d’urgence.

  • Le service Stockage Azure est chiffré au repos pour tous les comptes de stockage à l’aide du chiffrement Advanced Encryption Standard 256 bits, et est conforme à la norme FIPS (Federal Information Processing Standard) 140-2. Le chiffrement est activé automatiquement et ne peut pas être désactivé. Par défaut, le chiffrement utilise des clés gérées par Microsoft, mais les clients ont la possibilité d’utiliser leurs propres clés stockées dans un coffre de clés Azure.
  • Les disques managés des machines virtuelles Azure sont automatiquement chiffrés à l’aide d’un chiffrement côté serveur de disques managés Azure, qui s’applique également à leurs captures instantanées, en s’appuyant sur des clés de chiffrement gérées par la plateforme.

En outre, vous pouvez appliquer un accès restreint aux comptes Stockage Azure hébergeant du contenu de disques répliqués Site Recovery. Pour ce faire, activez l’identité managée pour le coffre Recovery Services, et attribuez à cette identité managée les rôles de contrôle d’accès en fonction du rôle Azure (RBAC Azure) suivants au niveau du compte de stockage Azure :

• Comptes de stockage basés sur Resource Manager (niveau de performance Standard) :
  • Contributeur
  • Contributeur aux données Blob du stockage
• Comptes de stockage basés sur Resource Manager (niveau de performances Premium) :
  • Contributeur
  • Propriétaire des données Blob du stockage

Le coffre Azure Recovery Services offre des mécanismes qui protègent davantage son contenu, dont les protections suivantes :

• RBAC Azure. Le contrôle d’accès en fonction du rôle permet la délégation et la répartition des responsabilités selon le principe du privilège minimum. Il existe trois rôles intégrés associés à Site Recovery, qui restreignent l’accès aux opérations Site Recovery :
  • Collaborateur Site Recovery. Ce rôle dispose de toutes les autorisations requises pour gérer les opérations Site Recovery dans un coffre Azure Recovery Services. Toutefois, un utilisateur titulaire de ce rôle ne peut pas créer ou supprimer le coffre ou attribuer des droits d’accès à d’autres utilisateurs. Ce rôle est tout indiqué pour des administrateurs de récupération d’urgence, qui peuvent activer et gérer la récupération d’urgence pour un locataire Azure Stack Hub.
  • Opérateur Site Recovery. Ce rôle dispose d’autorisations d’exécution et de gestion des opérations de basculement et de restauration automatique. Un utilisateur disposant de ce rôle ne peut pas activer ou désactiver la réplication, créer ou supprimer des coffres, enregistrer une nouvelle infrastructure ou affecter des droits d’accès à d’autres utilisateurs. Ce rôle est tout indiqué pour un opérateur de récupération d’urgence, qui peut basculer des machines virtuelles Azure Stack Hub lorsque des propriétaires d’application et des administrateurs informatiques le lui demandent dans une situation d’urgence réelle ou simulée.
  • Lecteur Site Recovery. Ce rôle dispose des autorisations nécessaires pour effectuer le suivi de toutes les opérations de gestion de Site Recovery. Ce rôle est tout indiqué pour le personnel informatique chargé de surveiller l’état de machines virtuelles Azure Stack Hub protégées, et de déclencher des tickets de support si nécessaire.
• Verrous de ressource Azure. Vous avez la possibilité de créer et d’attribuer des verrous de lecture seule et de suppression à un coffre Site Recovery pour réduire le risque que le coffre soit modifié ou supprimé par inadvertance ou par malveillance.
• Suppression réversible. L’objectif de la suppression réversible est de protéger le coffre et ses données contre les suppressions accidentelles ou malveillantes. Avec la suppression réversible, tout contenu supprimé est conservé pendant 14 jours supplémentaires, ce qui permet sa récupération pendant cette période. La rétention supplémentaire de 14 jours du contenu du coffre n’entraîne aucun coût. La suppression réversible est activée par défaut.
• Protection des opérations affectant la sécurité. Un coffre Azure Recovery Services vous permet d’activer une couche supplémentaire d’authentification chaque fois qu’une opération affectant la sécurité, telle que la désactivation de la protection, est tentée. Cette validation supplémentaire permet de s’assurer que les utilisateurs effectuant ces opérations sont autorisés.
• Surveillance et alertes d’activité suspecte. Azure Recovery Services offre des fonctions intégrées de surveillance et d’alerte pour des événements affectant la sécurité liés aux opérations de coffre.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Lorsque vous envisagez le coût de la solution de reprise d’activité basée sur Site Recovery décrite dans cet article, vous devez prendre en compte les composants locaux et ceux basés sur le cloud. Le modèle de tarification Azure Stack Hub détermine la tarification des composants locaux. Comme avec Azure, Azure Stack Hub propose une offre assortie d’un paiement à l’utilisation, disponible par le biais de contrats entreprise et du programme de fournisseurs de solutions cloud. Cette configuration inclut un tarif mensuel pour chaque machine virtuelle Windows Server. Si vous avez la possibilité d’utiliser des licences Windows Server existantes, vous pouvez réduire considérablement le coût de la tarification des machines virtuelles de base. Toutefois, avec Site Recovery, vous n’avez généralement besoin que d’une seule machine virtuelle Azure Stack Hub par locataire, qui est requise pour implémenter le serveur de configuration propre au locataire.

Les frais liés à Azure sont associés à l’utilisation des ressources suivantes :

• Azure Recovery Services. La tarification est déterminée par le nombre d’instances protégées. Notez que chaque instance protégée n’engendre aucun frais Site Recovery pendant les 31 premiers jours.

• Stockage Azure. La tarification reflète une combinaison des facteurs suivants :

  • Niveau de performance
  • Volume de données stocké
  • Volume de transfert de données sortantes
  • Quantité et types des opérations effectuées (uniquement pour le niveau de performance Standard)
  • Redondance des données (uniquement pour le niveau de performance Standard)

• Azure ExpressRoute. La tarification est basée sur l’un des deux modèles suivants :

  • Données illimitées. Ce modèle inclut un tarif mensuel incluant tous les transferts de données entrants et sortants.
  • Données limitées. Ce modèle est assorti d’une redevance mensuelle incluant tous les transferts de données entrants gratuits, les transferts de données sortants étant facturés par Go.

  Notes

  Cette évaluation n’inclut pas les coûts des connexions physiques fournies par des fournisseurs de connectivité tiers.

• Machines virtuelles Azure. La tarification des machines virtuelles Azure reflète une combinaison de deux composants :

  • Coût de calcul. La taille de la machine virtuelle, son temps d’activité et le modèle de licence de son système d’exploitation déterminent le coût.
  • Coût de disque managé. La taille du disque et le niveau de performance déterminent le coût.

  Notes

  Il est important de noter que l’hydratation élimine la nécessité d’exécuter des machines virtuelles Azure pendant des opérations métier régulières, avec des charges de travail s’exécutant sur Azure Stack Hub, ce qui réduit considérablement les coûts de calcul des implémentations basées sur Site Recovery, en particulier par rapport aux solutions de reprise d’activité traditionnelles.

  Notes

  Les prix des ressources varient selon les régions Azure.

  Notes

  Pour plus d’informations sur la tarification, consultez Tarification Azure.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

Les principales considérations relatives à la facilité de gestion de la reprise d’activité basée sur Site Recovery des machines virtuelles Azure Stack Hub sont les suivantes :

• Implémentation de Site Recovery sur Azure Stack Hub
• Procédures de basculement et de restauration automatique
• Délégation de rôles et de responsabilités
• DevOps

Implémentation de Site Recovery sur Azure Stack Hub

Pour implémenter Site Recovery sur Azure Stack Hub dans un environnement à locataire unique de taille petite ou moyenne, vous pouvez suivre le processus de provisionnement manuel piloté par l’interface graphique du coffre Recovery Services dans le portail Azure. Pour des implémentations mutualisées, vous pouvez envisager d’automatiser certaines parties du processus d’implémentation, car vous devrez généralement configurer une machine virtuelle de serveur de configuration et un coffre Recovery Services distincts pour chaque locataire. Vous avez également la possibilité d’automatiser le déploiement de l’agent Mobilité en suivant la procédure décrite dans Préparer la machine source pour l’installation Push de l’agent de mobilité.

Procédures de basculement et de restauration automatique

Pour simplifier la gestion du basculement, envisagez d’implémenter des plans de récupération pour toutes les charges de travail protégées. Pour plus d’informations, consultez la section Fiabilité plus haut dans cet article. Vous trouverez également des recommandations pour l’optimisation de la gestion de la procédure de restauration automatique.

Délégation de rôles et de responsabilités

La planification et l’implémentation de la reprise d’activité des charges de travail basées sur des machines virtuelles Azure Stack Hub à l’aide de Site Recovery impliquent généralement l’interaction entre des parties prenantes :

• Des opérateurs Azure Stack Hub gèrent l’infrastructure Azure Stack , garantissant une disponibilité suffisante des ressources de calcul, de stockage et de réseau nécessaires pour l’implémentation d’une solution de récupération d’urgence complète et la mise à disposition de ces ressources pour les locataires. Ils collaborent également avec les propriétaires d’applications et de données pour aider à déterminer l’approche optimale pour déployer leurs charges de travail sur Azure Stack Hub.
• Les administrateurs Azure gèrent les ressources Azure nécessaires pour implémenter des solutions hybrides de récupération d’urgence.
• Des administrateurs Microsoft Entra gèrent les ressources Microsoft Entra, y compris les objets utilisateur et groupe utilisés pour approvisionner, configurer et gérer les ressources Azure.
• Le personnel informatique du locataire Azure Stack Hub conçoit, implémente et gère Site Recovery, y compris le basculement et la restauration automatique.
• Les utilisateurs d’Azure Stack Hub doivent fournir des exigences de RPO et de RTO, et soumettre des demandes d’implémentation de la récupération d’urgence pour leurs charges de travail.

Veillez à bien comprendre les rôles et responsabilités attribués aux propriétaires et opérateurs d’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 de l’état opérationnel de l’infrastructure Azure Stack Hub.

DevOps

Si la configuration de la récupération au niveau de la machine virtuelle à l’aide de Site Recovery relève principalement de la responsabilité des opérations informatiques, certaines considérations propres à DevOps doivent être intégrées dans une stratégie de reprise d’activité complète. Azure Stack Hub facilite l’implémentation de l’infrastructure en tant que code (IaC), qui intègre le déploiement automatisé d’une variété de charges de travail, y compris des applications et services basés sur des machines virtuelles. Vous pouvez utiliser cette fonctionnalité pour simplifier le provisionnement de scénarios de reprise d’activité basés sur Site Recovery, ce qui simplifie la configuration initiale dans les scénarios à plusieurs locataires.

Par exemple, vous pouvez utiliser les mêmes modèles Azure Resource Manager pour approvisionner toutes les ressources réseau nécessaires à la prise en charge des charges de travail basées sur des machines virtuelles dans un tampon Azure Stack Hub pour votre application dans une seule opération coordonnée. Vous pouvez utiliser le même modèle pour approvisionner un ensemble de ressources correspondant dans Azure afin d’approvisionner un site de récupération d’urgence. Pour tenir compte des différences entre les deux environnements, vous pouvez simplement spécifier différentes valeurs de paramètres de modèle dans chaque cas.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Lorsque vous prévoyez de déployer Site Recovery sur Azure Stack Hub, vous devez tenir compte de la quantité de ressources de traitement, de stockage et de réseau allouées aux serveurs de configuration et de traitement. Il se peut que vous deviez ajuster le dimensionnement estimé de la machine virtuelle Azure Stack Hub hébergeant les composants Site Recovery après le déploiement afin de répondre aux besoins de traitement ou de stockage. Vous avez trois options de base pour ajuster le dimensionnement :

• Implémenter une mise à l’échelle verticale. Cela implique la modification de la quantité et du type de processeur, de mémoire et de ressources de disque de la machine virtuelle Azure Stack Hub hébergeant le serveur de configuration incluant le serveur de traitement. Pour estimer les besoins en ressources, vous pouvez utiliser les informations du tableau suivant :

  Tableau 1 : Exigences de dimensionnement des serveurs de configuration et de traitement

  UC	Mémoire	Disque cache	Taux de modification des données	Ordinateurs protégés
  8 processeurs virtuels avec 2 sockets * 4 cœurs cadencés à 2,5 GHz	16 Go	300 Go	500 Go ou moins	< 100 machines
  12 processeurs virtuels avec 2 sockets * 6 cœurs cadencés à 2,5 GHz	18 Go	600 Go	500 Go à 1 To	100 à 150 machines
  16 processeurs virtuels avec 2 sockets * 8 cœurs cadencés à 2,5 GHz	32 Go	1 To	1 à 2 To	Entre 150 et 200 machines

• Implémenter une mise à l’échelle horizontale. Cela implique l’approvisionnement ou l’annulation de l’approvisionnement de machines virtuelles Azure Stack Hub avec le serveur de traitement installé pour répondre aux demandes de traitement des machines virtuelles Azure Stack Hub protégées. En général, si vous devez mettre à l’échelle votre déploiement au-delà de 200 machines sources, ou si vous avez un taux de variation quotidien total supérieur à 2 To, vous avez besoin de serveurs de traitement supplémentaires pour gérer le trafic de réplication. Pour estimer le nombre et la configuration des serveurs de traitement supplémentaires, consultez Recommandations de taille pour le serveur de processus.

• Modifier la stratégie de réplication. Cela implique de modifier les paramètres de la stratégie de réplication, en se concentrant sur les captures instantanées de cohérence des applications.

Du point de vue de la mise en réseau, il existe différentes méthodes pour ajuster la bande passante disponible pour le trafic de réplication :

• Modifier la taille de machine virtuelle. La taille des machines virtuelles Azure Stack Hub détermine la bande passante réseau maximale. Toutefois, il est important de noter qu’il n’existe aucune garantie de bande passante. Au lieu de cela, les machines virtuelles peuvent utiliser la quantité de bande passante disponible jusqu’à la limite déterminée par leur taille.

• Remplacer les commutateurs de liaison montante. Les systèmes Azure Stack Hub prennent en charge un vaste éventail de commutateurs matériels, proposant plusieurs options de vitesse de liaison montante. Chaque nœud de cluster Azure Stack Hub a deux liaisons montantes vers les commutateurs TOR pour la tolérance de panne. Le système alloue la moitié de la capacité de liaison montante pour l’infrastructure critique. Le reste est une capacité partagée pour les services Azure Stack Hub et tout le trafic utilisateur. Les systèmes déployés avec des vitesses plus rapides ont davantage de bande passante disponible pour le trafic de réplication.

  Notes

  Bien qu’il soit possible de séparer le trafic réseau en attachant une deuxième carte réseau à un serveur, avec des machines virtuelles Azure Stack Hub, tout le trafic de machine virtuelle vers Internet partage la même liaison montante. Une deuxième carte réseau virtuelle ne sépare pas le trafic au niveau du transport physique.

• Modifier le débit de la connexion réseau à Azure. Pour prendre en charge de grands volumes de trafic de réplication, vous pouvez utiliser Azure ExpressRoute avec l’appairage Microsoft pour les connexions entre les réseaux virtuels Azure Stack Hub et le service Stockage Azure. Azure ExpressRoute étend les réseaux locaux au cloud de Microsoft via une connexion privée assurée par un fournisseur de connectivité. Vous pouvez acheter des circuits ExpressRoute pour un vaste éventail de bandes passantes, de 50 mégabits par seconde (Mbits/s) à 100 gigabits par seconde.

  Notes

  Pour plus d’informations sur l’implémentation d’Azure ExpressRoute dans des scénarios Azure Stack Hub, consultez Connecter Azure Stack Hub à Azure à l’aide d’Azure ExpressRoute.

• Modifier la limitation du trafic de réplication sur le serveur de traitement. Vous pouvez contrôler la quantité de bande passante utilisée par le trafic de réplication sur les machines virtuelles qui hébergent des serveurs de traitement à partir de l’interface graphique de l’agent de Microsoft Azure Recovery Services. Les fonctionnalités prises en charge incluent la définition des limites pour les heures de travail et les heures chômées, les valeurs de bande passante allant de 512 kilobits par seconde à 1 023 Mbits/s. Vous pouvez également appliquer la même configuration à l’aide de la cmdlet PowerShell Set-OBMachineSetting.

• Modifier la bande passante réseau allouée par machine virtuelle protégée sur le serveur de traitement. Pour ce faire, modifiez la valeur de l’entrée UploadThreadsPerVM dans la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication. Par défaut, la valeur est définie sur 4, mais vous pouvez l’augmenter à 32 si la bande passante réseau disponible est suffisante.

Déployer ce scénario

Prérequis

L’implémentation de la solution recommandée est subordonnée à la satisfaction des conditions préalables suivantes :

• Accès à un abonnement Azure, avec des autorisations suffisantes pour provisionner et gérer tous les composants cloud des composants Site Recovery, à savoir :

  • Coffre Azure Recovery Services dans la région Azure désignée comme site de récupération d’urgence pour l’environnement de production Azure Stack Hub.
  • Compte de stockage Azure hébergeant le contenu de disques répliqués de machines virtuelles Azure Stack Hub.
  • Réseau virtuel Azure représentant l’environnement de récupération d’urgence auquel les machines virtuelles Azure hydratées seront connectées à la suite d’un basculement planifié ou non.
  • Réseau virtuel Azure isolé représentant l’environnement de test auquel les machines virtuelles Azure hydratées seront connectées à la suite d’un basculement test.
  • Connexion Azure ExpressRoute entre l’environnement local, les réseaux virtuels Azure et le compte de stockage Azure utilisé pour héberger des copies des fichiers VHD avec le contenu répliqué de disques de machines virtuelles protégées Azure Stack Hub.

• Abonnement utilisateur Azure Stack Hub. Toutes les machines virtuelles Azure Stack Hub protégées par un serveur de configuration Site Recovery individuel doivent appartenir au même abonnement utilisateur Azure Stack Hub.

• Réseau virtuel Azure Stack Hub. Toutes les machines virtuelles protégées doivent disposer d’une connexion directe aux machines virtuelles hébergeant le composant serveur de traitement (il s’agit par défaut de la machine virtuelle du serveur de configuration).

• Machine virtuelle Windows Server dans Azure Stack Hub qui hébergera le serveur de configuration et un serveur de traitement. La machine virtuelle doit appartenir au même abonnement et être attachée au même réseau virtuel que les machines virtuelles Azure Stack Hub à protéger. En outre, la machine virtuelle doit :

  • Satisfaire aux exigences matérielles et logicielles du serveur de configuration Site Recovery.
  • Satisfaire aux exigences réseau en matière de connectivité externe.

  Notes

  Des considérations supplémentaires concernant le stockage et les performances des serveurs de configuration et de traitement figurent plus loin dans cette architecture.

  • Satisfaire aux exigences de connectivité interne. en particulier, les machines virtuelles Azure Stack Hub que vous souhaitez protéger doivent être en mesure de communiquer avec :

    • Le serveur de configuration via le port TCP 443 (HTTPS) entrant pour la gestion de la réplication.
    • Le serveur de traitement via le port TCP 9443 pour fournir les données de réplication.

    Notes

    Vous pouvez modifier le port utilisé par le serveur de traitement pour la connectivité externe et interne dans le cadre de sa configuration lors de l’exécution de l’installation unifiée de Site Recovery.

• Machines virtuelles Azure Stack Hub à protéger, exécutant l’un des systèmes d’exploitation pris en charge. Pour protéger les machines virtuelles Azure Stack Hub qui exécutent des systèmes d’exploitation Windows Server, vous devez :

  • Créer un compte Windows avec des droits d’administration. Vous pouvez spécifier ce compte lorsque vous activez Site Recovery sur ces machines virtuelles. Le serveur de traitement utilise ce compte pour installer le service Mobilité Site Recovery. Dans un environnement de groupe de travail, veillez à désactiver le contrôle d’accès des utilisateurs distants sur les systèmes d’exploitation Windows Server cibles en définissant la valeur de l’entrée de Registre DWORDLocalAccountTokenFilterPolicy dans la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System sur 1.
  • Activer le partage de fichiers et d’imprimantes, ainsi que les règles de Windows Management Instrumentation dans le pare-feu Microsoft Defender.

• Pour protéger des machines virtuelles Azure Stack Hub exécutant des systèmes d’exploitation Linux, vous devez effectuer les opérations suivantes :

  • Créer un compte d’utilisateur racine. Vous pouvez spécifier ce compte lorsque vous activez Site Recovery sur ces machines virtuelles. Le serveur de traitement utilise ce compte pour installer le service Mobilité Site Recovery.
  • Installer les packages openssh, openssh-server et openssl les plus récents.
  • Activer et exécutez le port Secure Shell (SSH) 22.
  • Activer le sous-système FTP sécurisé et l’authentification par mot de passe.

Étapes d’implémentation générales

À un niveau général, l’implémentation de la reprise d’activité Site Recovery sur Azure Stack Hub se compose des étapes suivantes :

1. Préparer les machines virtuelles Azure Stack Hub que Site Recovery doit protéger. Vérifier que les machines virtuelles satisfont aux prérequis de Site Recovery énoncées dans la section précédente.

2. Créer et configurer un coffre Azure Recovery Services Configurez un coffre Azure Recovery Services et spécifiez ce que vous souhaitez répliquer. Les composants et les activités de Site Recovery sont configurés et gérés à l’aide du coffre.

3. Configurez l’environnement de réplication source. Provisionner un serveur de configuration et un serveur de traitement Site Recovery en exécutant les fichiers binaires d’installation unifiée de Site Recovery, et les inscrire auprès du coffre.

   Notes

   Vous pouvez réexécuter l’installation unifiée de Site Recovery pour implémenter des serveurs de traitement supplémentaires sur des machines virtuelles Azure Stack Hub.

4. Configurer l’environnement de réplication cible. Créez ou sélectionnez un compte de stockage Azure existant et un réseau virtuel Azure dans la région Azure qui hébergera le site de récupération d’urgence. Pendant la réplication, le contenu des disques pour les machines virtuelles Azure Stack Hub protégées est copié vers le compte de stockage Azure. Pendant le basculement, Site Recovery provisionne automatiquement des machines virtuelles Azure faisant office de réplicas de machines virtuelles Azure Stack Hub protégées, et il les connecte au réseau virtuel Azure.

5. Activez la réplication. Configurez le paramètre de réplication, et activez la réplication pour les machines virtuelles Azure Stack Hub. Le service Mobilité est installé automatiquement sur chaque machine virtuelle Azure Stack Hub pour laquelle la réplication est activée. Site Recovery lance la réplication de chaque machine virtuelle Azure Stack Hub, en fonction des paramètres de stratégie que vous avez définis.

6. Exécution d’un basculement de test. Une fois la réplication établie, vérifiez que le basculement fonctionne comme prévu en effectuant un basculement test.

7. Effectuez un basculement planifié ou non planifié. Après un basculement test réussi, vous êtes prêt à effectuer un basculement planifié ou non planifié vers Azure. Vous avez la possibilité de désigner les machines virtuelles Azure Stack Hub à inclure dans le basculement.

8. Effectuez une restauration automatique. Lorsque vous êtes prêt à effectuer une restauration automatique, arrêtez les machines virtuelles Azure correspondant aux machines virtuelles Azure Stack Hub en échec, téléchargez leurs fichiers de disque dans un stockage local, chargez-les dans Azure Stack Hub, puis attachez-les à une machine virtuelle existante ou nouvelle.

Résumé

En conclusion, Azure Stack Hub est une offre unique, qui diffère par de nombreux aspects des autres plateformes de virtualisation. En tant que tel, il justifie une prise en considération spéciale de la stratégie de continuité d’activité pour ses charges de travail. En utilisant des services Azure, vous pouvez simplifier la conception et l’implémentation de cette stratégie. Dans cet article de référence sur l’architecture, nous avons exploré l’utilisation de Microsoft Site Recovery pour la protection des charges de travail basées sur des machines virtuelles Azure Stack Hub dans le modèle de déploiement connecté. Cette approche permet aux clients de bénéficier de la résilience et de la facilité de gestion d’Azure Stack Hub, ainsi que de l’hyperscale et de la présence mondiale du cloud Azure.

Il est important de noter que la solution de récupération d’urgence décrite ici se concentre exclusivement sur des charges de travail d’Azure Stack Hub basées sur des machines virtuelles. Il s’agit uniquement d’une partie d’une stratégie globale de continuité d’activité qui doit tenir compte d’autres types de charges de travail Azure Stack Hub et des scénarios qui affectent leur disponibilité.

Étapes suivantes

Documentation du produit :

• À propos de Site Recovery
• Vue d’ensemble d’Azure Stack Hub
• Qu’est-ce que Microsoft Entra ID ?
• Qu’est-ce que le stockage d’objets blob Azure ?
• Qu’est-ce qu’Azure ExpressRoute ?
• Qu’est-ce que le réseau virtuel Azure ?

Modules Microsoft Learn :

• Azure Stack Hub
• Configurer Microsoft Entra ID
• Configurer des comptes de stockage
• Configurer des réseaux virtuels
• Concevoir et implémenter Azure ExpressRoute
• Concevoir votre solution de récupération de site dans Azure

Ressources associées

• Conception d’une architecture hybride
• Sauvegarder des fichiers et des applications sur Azure Stack Hub
• Connexions hybrides
• Partage de fichiers hybride avec reprise d’activité pour les travailleurs des succursales distantes et locales