Planification de la capacité à l’aide d’Azure Site Recovery
En tant que organization, 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 à partir 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, la disponibilité des applications et les 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 s’exécute à nouveau, vous pouvez y revenir automatiquement. 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 :
- Tampon Azure Stack Hub sur lequel les machines virtuelles clientes sont en cours d’exécution.
-
Environnement cible :
- Emplacement d’exécution du fournisseur de ressources Azure Site Recovery.
La planification de la capacité est un élément essentiel pour la réussite d’un plan de continuité d’activité et de reprise d’activité. Lors de 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.
- Quelle est la quantité de données générées ou supprimées ?
- À quoi ressemble la conception de l’application et bien plus encore ?
Les tailles de machine virtuelle, le nombre de disques et la 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 de vastes implications lors de l’élaboration d’un plan BCDR.
Les sections suivantes répertorient les points main à 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 la machine virtuelle Azure Site Recovery Appliance. 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 en avez besoin un ou plusieurs, selon le plan global.
Stockage pour l’Appliance de machine virtuelle Azure Site Recovery :
La machine virtuelle Azure Site Recovery Appliance elle-même a les exigences en matière de données définies par sa taille de machine virtuelle.
Lors de la planification de la capacité, assurez-vous que la machine virtuelle Appliance dispose de suffisamment de stockage pour exercer les mécanismes de restauration automatique et de reprotéger.
Notes
S’il existe des limitations de stockage, la restauration automatique et la reprotéger peuvent échouer avec une erreur Un message d’erreur interne s’est produit . Les utilisateurs doivent case activée les journaux des événements sur le Appliance pour confirmer l’erreur Resource Manager Azure 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 à la cible
Dans l’environnement cible, il y a deux éléments à prendre en compte pour la planification de la capacité :
Les 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 des charges de travail protégées.
L’environnement cible nécessite la création d’un coffre Azure Site Recovery pour chaque Site Recovery Appliance, afin de protéger les machines virtuelles de la source (un Appliance par coffre). Bien qu’il ne s’agisse pas d’une limitation du point de vue de la capacité, elle doit être prise en considération lors de la planification de la conception de l’environnement global.
Ressources Azure Site Recovery RP
L’installation d’Azure Site Recovery sur Azure Stack Hub nécessite l’installation du fournisseur de ressources Site Recovery .
Notes
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 pour 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 | 12 | 42 Go | 1,4 To |
Notes
Ces ressources sont des services Azure Stack Hub du côté de l’administration d’Azure Stack Hub. Une fois installées, 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 complète et doit être traitée comme un point de départ :
Taille de la machine virtuelle, nombre de disques, taille du disque, IOPS, attrition 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, que les Site Recovery Azure peuvent obtenir à partir de l’environnement source.
- Nombre de machines virtuelles à traiter par lot à la fois. Ce nombre est basé sur la bande passante estimée pour effectuer la réplication initiale dans un laps de temps donné.
- RPO qui peut être atteint pour une bande passante donnée.
- Effet sur le RPO souhaité si une bande passante inférieure est provisionnée.
Considérations relatives au stockage :
- Quantité de données requises pour la réplication initiale.
- Combien de points de récupération sont conservés et comment les données augmentent, 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 de 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 utilisateur 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. n’est consommée sur l’environnement cible. Ces ressources deviennent pertinentes uniquement pendant un processus de basculement tel que le 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 de 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 * 250s). Le compte de stockage de 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 entière.
Important
Si certaines parties d’Azure Site Recovery ne fonctionnent pas, mais que d’autres fonctionnent, il peut y avoir au plus un jour de difflog 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.
- Le disque entier doit être copié sur le compte de stockage de cache pour que la machine virtuelle cible s’applique, car la cible est un disque vide.
- Les données associées sont supprimées une fois copiées, mais elles sont susceptibles de connaître un pic d’utilisation 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 ces informations pour obtenir une base de référence pour votre propre application, mais chaque charge de travail diffère :
Configuration
| 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ésultats
| Nombre de disques pris en charge | Débit total | Total OPS | Bottleneck |
|---|---|---|---|
| 68 | 136 Mo/s | 68 | storage |
| 60 | 120 Mo/s | 2 048 | storage |
| 28 | 28 Mo/s | 3584 | Processeur et mémoire Azure Site Recovery |
| 16 | 32 Mo/s | 4096 |
Notes
8 Ko est la plus petite taille de bloc de données prise en charge par Azure Site Recovery. Toute modification inférieure à 8 Ko est traitée comme 8 Ko.
Pour tester davantage, nous avons généré un type de charge de travail cohérent ; par exemple, les modifications de stockage cohérentes dans les blocs de 8 Ko qui totalissent jusqu’à 1 Mo/s par disque. Ce scénario n’est probablement pas dans une charge de travail réelle, étant donné que des 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 le 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 les 120 machines virtuelles avec une charge faible à moyenne sur les services Azure Site Recovery.
Notes
Ces nombres doivent être utilisés comme base de référence uniquement. Ils ne sont pas nécessairement mis à l’échelle linéairement. L’ajout d’un autre lot du même nombre de machines virtuelles peut avoir moins d’impact que le lot 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 certaines exigences en matière d’objectif de temps de récupération (RTO) et d’objectif de point de récupération (RPO). La conception efficace de la continuité d’activité et de la reprise d’activité (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 plateforme et tenez compte de tous ces facteurs dans votre conception :
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.
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.
Notes
L’application peut savoir s’exécuter en mode natif ou avoir certains composants capables de 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 ne disposent pas de cette fonctionnalité ; par exemple, une solution de type front-end ou back-end, dans laquelle vous pouvez déployer les serveurs frontaux dans des 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 l’historique des signets de disque se produit. Cette allocation n’est pas une augmentation de 2 fois, car elle inclut uniquement les modifications apportées aux données. En fonction du type de données et des modifications attendues, ainsi que des stratégies de réplication ayant un stockage de 1,5x à 2x plus sur la cible, veillez à ce que les processus de basculement n’introduisent aucun problème.
- Vous pouvez envisager d’avoir l’environnement Azure Stack Hub cible comme cible pour plusieurs sources Azure Stack Hub. Dans ce cas, vous réduisez le coût global, mais vous devez planifier ce qui se passe lorsque certaines charges de travail tombent en panne ; par exemple, quelle source doit être hiérarchisé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 de développement/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 des ressources suffisantes sont disponibles pour démarrer les machines virtuelles protégées.
Vous devez tester le BCDR et le valider régulièrement. Pour ce faire, utilisez des processus de test de basculement ou déplacez les charges de travail entières pour valider les flux de bout en bout.