Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
En tant qu’organisation, il est impératif d’adopter une stratégie de continuité d’activité et de récupération d’urgence (BCDR) qui protège vos données, les applications disponibles et les charges de travail en ligne pendant les pannes planifiées et non planifiées.
Grâce à la réplication des charges de travail de machines virtuelles d’un site principal vers un emplacement secondaire, Azure Site Recovery sur Azure Stack Hub fournit des services qui peuvent prendre en charge la sécurité des données organisationnelles, de la disponibilité des applications et des charges de travail pendant les pannes. Par exemple, lorsqu’une panne se produit sur votre site principal, vous basculez vers un emplacement secondaire pour accéder à vos applications. Dès que le site principal est de nouveau fonctionnel, vous pouvez effectuer une restauration automatique vers celui-ci. Pour plus d’informations, consultez À propos de Site Recovery.
Pour activer la réplication de machines virtuelles sur deux tampons Azure Stack Hub, vous configurez deux environnements :
- Environnement source :
- Le tampon Azure Stack Hub où s'exécutent les machines virtuelles clientes.
- Environnement cible :
- Où s’exécute le fournisseur de ressources Azure Site Recovery.
Un élément essentiel pour la réussite d’un plan de continuité d’activité et de reprise d’activité est la planification de la capacité. Pendant la planification de la capacité, il existe quelques facteurs à prendre en compte :
Objectifs de temps de récupération (RTO) et objectifs de point de récupération (RPO) pour les charges de travail spécifiques que vous souhaitez protéger.
Charges de travail et caractéristiques de l’application :
- Fréquence à laquelle les données changent dans la machine virtuelle respective.
- Combien de données sont générées ou supprimées ?
- À quoi ressemble la conception de l'application et bien plus encore ?
Tailles de machine virtuelle, nombre de disques et façon dont chaque machine virtuelle est liée à d’autres machines virtuelles.
- Pour les solutions qui nécessitent plusieurs machines virtuelles, comprenez dans quel ordre ces machines virtuelles doivent être démarrées.
Bande passante réseau entre les environnements source et cible. Ce composant peut affecter les RPO.
Chacun de ces points est important et a des implications générales lors de la création d’un plan BCDR.
Les sections suivantes répertorient les points principaux à prendre en compte du point de vue d’Azure Site Recovery. Chaque plan BCDR est différent et est basé sur les spécificités des charges de travail que vous prévoyez de protéger. Par conséquent, cette liste n’est pas complète.
Considérations relatives à la source
Dans l’environnement source, Azure Stack Hub exécute l’appliance de machine virtuelle Azure Site Recovery. La machine virtuelle est une machine virtuelle Standard_DS4_v2 (8 processeurs virtuels, 28 Go de mémoire, 32 disques de données) qui s’exécute dans l’abonnement utilisateur Azure Stack Hub.
Dans l’environnement source, tenez compte des domaines suivants :
Quota:
- Vous devez disposer d’un quota suffisant pour créer l’appliance de machine virtuelle Azure Site Recovery. Vous avez besoin d’un ou plusieurs, selon le plan global.
Stockage pour l’appliance de machine virtuelle Azure Site Recovery :
L’appliance de machine virtuelle Azure Site Recovery elle-même a les exigences de données définies par sa taille de machine virtuelle.
Lors de la planification de la capacité, assurez-vous que la machine virtuelle de l’appliance dispose d’un stockage suffisant pour activer les mécanismes de repli et de restauration.
Remarque
S’il existe des limitations de stockage, la restauration automatique et la reprotection peuvent échouer avec un message d’erreur Une erreur interne s’est produite. Les utilisateurs doivent vérifier les journaux des événements sur l’appliance pour confirmer l’erreur Azure Resource Manager réelle. Pour plus d’informations, consultez Problèmes connus pour Azure Site Recovery.
Bande passante :
- La réplication initiale génère une utilisation élevée de la bande passante.
- Les modifications sur chaque machine virtuelle sont répliquées, en fonction des stratégies de réplication et de chaque type d’application.
Considérations relatives aux cibles
Dans l’environnement cible, il existe deux éléments à prendre en compte pour la planification de la capacité :
Exigences du service Azure Site Recovery : quantité consommée pour exécuter Azure Site Recovery, sans nécessairement protéger les charges de travail.
Exigences relatives aux charges de travail protégées.
L’environnement cible nécessite qu’un coffre Azure Site Recovery soit créé pour chaque appliance Site Recovery afin de protéger les machines virtuelles de la source (une appliance par coffre). Bien que cela ne soit pas une limitation du point de vue de la capacité, il doit être pris en compte lors de la planification de la conception de l’environnement global.
Ressources RP Azure Site Recovery
L’installation d’Azure Site Recovery sur Azure Stack Hub nécessite l’installation du fournisseur de ressources Site Recovery (RP).
Remarque
Avec Microsoft.SiteRecovery-1.2301.2216.2287, Azure Site Recovery sur Azure Stack Hub ne nécessite pas Event Hubs comme dépendance.
Ce service est créé sur l’abonnement administrateur Azure Stack Hub et géré par Azure Stack Hub lui-même. Par conséquent, aucune configuration n’est requise. Toutefois, comme avec n’importe quel service, ces ressources consomment de la mémoire, du stockage et ont certains processeurs virtuels alloués :
| Service | vCore | Mémoire | Taille du disque |
|---|---|---|---|
| Azure Site Recovery (Récupération de site Azure) | 18 | 64 Go | 384 Go |
Remarque
Ces ressources sont des services Azure Stack Hub côté administration d’Azure Stack Hub. Une fois installée, la plateforme gère ces ressources.
Charges de travail protégées
Lors de la création du plan BCDR, tenez compte de tous les aspects des charges de travail protégées. La liste suivante n’est pas terminée et doit être traitée comme un point de départ :
Taille de machine virtuelle, nombre de disques, taille de disque, IOPS, évolution des données et nouvelles données créées.
Considérations relatives à la bande passante réseau :
- Bande passante réseau requise pour la réplication delta.
- Quantité de débit, sur l’environnement cible, qu’Azure Site Recovery peut obtenir à partir de l’environnement source.
- Nombre de machines virtuelles à regrouper en une seule fois. Ce nombre est basé sur la bande passante estimée pour terminer la réplication initiale dans un délai donné.
- RPO qui peut être atteint pour une bande passante donnée.
- Effet sur le RPO souhaité si la bande passante inférieure est provisionnée.
Considérations relatives au stockage :
- Quantité de données requises pour la réplication initiale.
- Nombre de points de récupération conservés et augmentation des données, pour chaque machine virtuelle protégée, pendant ces intervalles.
- Nombre de quotas à affecter aux abonnements utilisateur Azure Stack Hub cibles afin que les utilisateurs disposent d’une allocation suffisante.
- Compte de stockage du cache pour la réplication.
Considérations relatives au calcul :
- Lorsque le basculement se produit, les machines virtuelles sont démarrées sur les abonnements utilisateurs Azure Stack Hub cibles Une allocation de quota suffisante doit être en place pour pouvoir démarrer ces ressources de machine virtuelle.
- Pendant la protection de la machine virtuelle, lorsque la machine virtuelle protégée est active sur l’environnement source, aucune ressource liée à la machine virtuelle comme le processeur virtuel, la mémoire, etc. sont consommées sur l’environnement cible. Ces ressources ne deviennent pertinentes que pendant un processus de basculement, comme lors d'un test de basculement.
Pour l’étendue d’Azure Site Recovery sur Azure Stack Hub, voici un point de départ pour les calculs, en particulier pour le compte de stockage du cache utilisé :
En cas de basculement, pendant les opérations normales, multipliez le nombre de disques répliqués par le RPO moyen. Par exemple, vous pouvez avoir (2 Mo * 250 s). Le compte de stockage du cache est normalement de quelques Ko à 500 Mo par disque.
En cas de basculement, dans le pire des cas, multipliez le nombre de disques répliqués par le RPO moyen sur une journée complète.
Importante
Si certaines parties d’Azure Site Recovery ne fonctionnent pas, mais que d’autres fonctionnent, il peut y avoir au maximum un jour dedifflog dans le compte de stockage avant qu’Azure Site Recovery décide d’expirer.
Restauration automatique vers la nouvelle machine virtuelle. Calculez la somme de la taille des disques de chaque lot.
- L'intégralité du disque doit être copiée dans le compte de stockage de cache pour que la machine virtuelle cible puisse l’utiliser, car le disque cible est vide.
- Les données associées sont supprimées une fois copiées, mais il est probable qu’elles voient une utilisation maximale avec la somme de toutes les tailles de disque.
Créez le plan BDCR en fonction des spécificités de la solution que vous essayez de protéger.
Le tableau suivant est un exemple de tests exécutés dans nos environnements. Vous pouvez utiliser cet insight pour obtenir une base de référence pour votre propre application, mais chaque charge de travail diffère :
Paramétrage
| Taille de bloc | Débit/disque |
|---|---|
| 2 Mo | 2 Mo/s |
| 64 Ko | 2 Mo/s |
| 8 Ko | 1 Mo/s |
| 8 Ko | 2 Mo/s |
Résultat
| Nombre de disques pris en charge | Débit total | Total Unité centrale | Bottleneck |
|---|---|---|---|
| 68 | 136 Mo/s | 68 | storage |
| soixante | 120 Mo/s | 2048 | storage |
| 28 | 28 Mo/s | 3584 | Processeur et mémoire Azure Site Recovery |
| 16 | 32 Mo/s | 4096 |
Remarque
8 Ko est la plus petite taille de bloc de données prise en charge par Azure Site Recovery. Toutes les modifications inférieures à 8 Ko sont traitées comme 8 Ko.
Pour tester davantage, nous avons généré un type cohérent de charge de travail ; Par exemple, les modifications de stockage cohérentes dans les blocs de 8 Ko qui totalisent jusqu’à 1 Mo/s par disque. Ce scénario n’est probablement pas dans une charge de travail réelle, étant donné que les modifications peuvent se produire à différents moments de la journée, ou dans des pics de différentes tailles.
Pour répliquer ces modèles aléatoires, nous avons également testé des scénarios avec :
- 120 machines virtuelles (80 Windows, 40 Linux) protégées via la même appliance de machine virtuelle Azure Site Recovery.
Chaque machine virtuelle générant à intervalles aléatoires, au moins deux fois par heure, des blocs aléatoires totalisant 5 Go de données sur cinq fichiers.
La réplication a réussi sur toutes les 120 machines virtuelles avec une charge faible à moyenne sur les services Azure Site Recovery.
Remarque
Ces nombres doivent être utilisés en tant que base de référence uniquement. Ils ne croissent pas nécessairement de façon linéaire. L’ajout d’un autre lot du même nombre de machines virtuelles peut avoir moins d’impact que celui initial. Les résultats dépendent fortement du type de charge de travail utilisé.
Comment planifier et tester
Les applications et les charges de travail de solution ont certains objectifs de temps de récupération (RTO) et d’objectif de point de récupération (RPO). Une conception efficace de continuité d’activité et de récupération d’urgence (BCDR) tire parti des fonctionnalités au niveau de la plateforme qui répondent à ces exigences, car nous utilisons les mécanismes spécifiques à la solution. Pour concevoir des fonctionnalités BCDR, capturez les exigences de récupération d’urgence de la plateforme et prenez en compte tous ces facteurs dans votre conception :
Exigences en matière de disponibilité des données et des applications :
- Exigences de RTO et de RPO pour chaque charge de travail.
- Prise en charge des modèles de disponibilité actif/actif et actif/passif.
Prise en charge des déploiements multirégions à des fins de basculement, avec proximité des composants pour des raisons de performances. Vous pouvez rencontrer des opérations d’application avec des fonctionnalités réduites ou des performances dégradées lors d’une panne.
Remarque
L’application peut savoir s’exécuter en mode natif ou avoir certains composants qui peuvent s’exécuter dans plusieurs environnements Azure Stack Hub. Dans ce cas, vous pouvez utiliser Azure Site Recovery pour répliquer uniquement les machines virtuelles avec les composants qui n’ont pas cette fonctionnalité ; par exemple, une solution front-end ou back-end, où vous pouvez déployer les front-ends dans les environnements Azure Stack Hub.
É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.
Dimensionnement de vos environnements cibles :
- Si vous utilisez la source et la cible de manière 1:1, allouez un peu plus de stockage sur votre environnement cible. Cela est dû à la façon dont se déroule l’historique des signets du disque. Cette allocation n’est pas une augmentation 2x, car elle inclut uniquement les modifications apportées aux données. Selon le type de données et les modifications attendues, et avec des stratégies de réplication nécessitant 1,5 à 2 fois plus de stockage sur la cible, on s'assure que les processus de basculement ne posent aucun problème.
- Vous pouvez envisager de considérer l’environnement Azure Stack Hub cible comme destination pour plusieurs sources Azure Stack Hub. Dans ce cas, vous réduisez le coût global, mais vous devez prévoir ce qui se passera lorsque certaines charges de travail diminueront ; par exemple, quelle source doit être priorisée.
- Si votre environnement cible est utilisé pour exécuter d’autres charges de travail, le plan BCDR doit inclure le comportement de ces charges de travail. Par exemple, vous pouvez exécuter les machines virtuelles Dev/Test sur l’environnement cible et, si un problème se produit avec votre environnement source, vous pouvez désactiver toutes les machines virtuelles sur la cible pour vous assurer que les ressources suffisantes sont disponibles pour démarrer les machines virtuelles protégées.
Vous devez tester le BCDR et valider régulièrement. Pour ce faire, vous pouvez utiliser des processus de test de basculement ou en déplaçant l’ensemble des charges de travail pour valider les flux de bout en bout.