1.4 Performances

1.4.1 Caractéristiques de performances

Les performances de votre produit PlateSpin Forge dépendent de multiples facteurs, dont :

  • les profils logiciels et matériels de vos workloads sources ;

  • les profils logiciels et matériels de vos conteneurs cibles ;

  • les particularités de la bande passante, de la configuration et des conditions de votre réseau ;

  • le nombre de workloads protégés ;

  • le nombre de volumes sous protection ;

  • la taille des volumes sous protection ;

  • la densité de fichiers (nombre de fichiers par unité de capacité) dans vos volumes du workload source ;

  • les niveaux E/S sources (taux d'occupation de votre workload) ;

  • le nombre de réplications simultanées ;

  • l'activation/la désactivation du chiffrement des données ;

  • activation/désactivation de la compression des données.

Pour planifier des plans de protection de workload à grande échelle, il est recommandé de procéder à un test de protection d'un workload typique et d'utiliser les résultats comme référence, en optimisant vos mesures régulièrement tout au long du projet.

1.4.2 Évolutivité

L'évolutivité comprend (et repose sur) les caractéristiques majeures suivantes de votre produit PlateSpin Forge :

  • Workloads par serveur : le nombre de workloads par serveur PlateSpin peut varier de 10 à 50, en fonction de divers facteurs, dont vos besoins PDMA et les caractéristiques matérielles de l'hôte du serveur.

  • Protections par conteneur : le nombre maximal de protections par conteneur est lié (mais pas identique) aux spécifications de VMware se rapportant au nombre maximal de machines virtuelles prises en charge par l'hôte ESXi. D'autres facteurs comprennent les statistiques de récupération (dont les réplications et les basculements simultanés) et les spécifications du fournisseur de matériel.

Il est recommandé d'effectuer des tests, d'ajuster vos chiffres de capacité de façon incrémentielle et de les utiliser pour déterminer votre plafond d'évolutivité.

1.4.3 Serveur de base de données

PlateSpin Forge inclut Microsoft SQL Server. L'instance de base de données du serveur PlateSpin peut croître jusqu'à 0,5 Go par mois et par workload, en fonction du nombre de réplications incrémentielles planifiées.

Il est recommandé d'archiver ou de supprimer régulièrement les données de création de rapports historiques afin de libérer de l'espace pour les nouvelles données de création de rapports.

1.4.4 Spécifications RPO, RTO et TTO

Dans votre environnement de protection, vous avez des attentes différentes pour les points et temps de reprise requis pour divers workloads.

  • Perte de données maximale admissible (PDMA ou RPO – Recovery Point Objective) : le paramètre RPO décrit la quantité tolérable de perte de données, mesurée en temps dans le cas d'une panne ou interruption informatique majeure. Vous définissez le RPO avec un intervalle configurable entre les réplications incrémentielles d'un workload protégé.

    Le RPO dépend des niveaux d'utilisation actuels de PlateSpin Forge, du taux ainsi que de l'ampleur des modifications sur le workload, de la vitesse de votre réseau et de la planification de réplication choisie.

  • Délai maximal d'interruption admissible (DMIA ou RTO – Recovery Time Objective) : le paramètre RTO décrit le temps hors service tolérable d'un workload et correspond au temps nécessaire à l'exécution d'une opération de basculement. L'opération de basculement met en ligne un workload de basculement pour remplacer temporairement un workload de production protégé.

    Le RTO est influencé par le temps nécessaire à la configuration et à l'exécution de l'opération de basculement (de 10 à 45 minutes). Reportez-vous à la section Basculement.

  • Délai maximal de test admissible (DMTA ou TTO – Test Time Objective) : le TTO décrit le temps nécessaire au test de la reprise après sinistre avec un certain niveau de confiance pour la restauration du service. Il est similaire au DMIA mais inclut le temps nécessaire à l'utilisateur pour tester le workload de basculement.

    Utilisez la fonction Test de basculement pour passer en revue les différents scénarios et générer des données d'évaluation des performances. Reportez-vous à la section Utilisation de la fonction Tester le basculement.

Parmi les facteurs qui ont un impact sur le RPO, RTO et le TTO, citons le nombre d'opérations de basculement requises simultanément. Un seul workload ayant fait l'objet d'un basculement dispose de davantage de mémoire et de ressources d'UC que plusieurs workloads ayant fait l'objet d'un basculement qui partagent les ressources de leur infrastructure sous-jacente.

Lorsque vous testez la réponse du basculement, notez les valeurs réelles associées aux RPO, RTO et TTO configurés :

  • Point de récupération réel (Recovery Point Actual, RPA) : la valeur RPA est la perte de données réelle mesurée en temps et définie par l'intervalle mesuré réel entre les réplications incrémentielles d'un workload protégé qui se produit au cours d'un test de basculement. Le RPA est également appelé RPO réel (Actual Recovery Point Objective).

  • Délai de récupération réel (Recovery Time Actual, RTA) : la valeur RTA est une mesure du temps hors service réel d'un workload, défini par la durée d'une opération de basculement. Le RTA est également appelé RTO réel (Actual Recovery Time Objective).

  • Délai de test réel (Test Time Actual, TTA) : la valeur TTA est une mesure de la durée réelle du test d'un plan de reprise après sinistre. Cette mesure est similaire à la DMIA réelle, mais inclut le temps nécessaire à l'utilisateur pour tester le workload de basculement. Le TTA est également appelé TTO réel (Actual Test Time Objective).

Vous devez déterminer le nombre moyen de basculements pour les workloads dans votre environnement en effectuant des tests de basculement à des heures différentes, puis les utiliser comme données de référence dans le cadre de vos plans généraux de récupération de données. Reportez-vous à la section Génération de rapports sur les workloads et leur protection.

1.4.5 Compression des données

Si nécessaire, PlateSpin Forge peut compresser les données de workload avant de les transférer sur le réseau. Cela permet de réduire le volume global de données transférées durant les réplications.

Les taux de compression dépendent des types de fichiers dans les volumes du workload source et peuvent varier d'environ 0,9 (100 Mo de données compressées à 90 Mo) à environ 0,5 (100 Mo de données compressées à 50 Mo).

REMARQUE :la compression des données utilise la puissance du processeur du workload source.

La compression de données peut être configurée individuellement pour chaque workload ou par niveau de protection. Reportez-vous à la section Niveaux de protection.

1.4.6 Limitation de la bande passante

PlateSpin Forge permet de contrôler la quantité de bande passante réseau consommée par une communication source-cible directe pendant une protection de workload. Vous pouvez spécifier un débit pour chaque contrat de protection. Cette méthode permet d'éviter la congestion de votre réseau de production à cause du trafic de réplication, ainsi que de réduire la charge globale de votre serveur PlateSpin.

La limitation de bande passante peut être configurée pour chaque workload ou par niveau de protection. Reportez-vous à la section Niveaux de protection.