Les performances de votre produit PlateSpin Protect 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 profils logiciels et matériels de l'hôte du serveur PlateSpin ;
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.
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é.
La perte de données maximale admissible est affectée par les niveaux d'utilisation actuels de PlateSpin Protect, la fréquence et l'étendue des changements au niveau du workload, la vitesse de votre réseau et 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 influant sur le RPO, le RTO et le TTO figure le nombre d'opérations de basculement simultanées requises. En effet, un workload de basculement unique dispose de davantage de mémoire et de ressources d'UC que plusieurs workloads de basculement, lesquels 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.
Si nécessaire, PlateSpin Protect 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.
PlateSpin Protect permet de contrôler la quantité de bande passante consommée par une communication source-cible directe lors d'une protection de workload. Vous pouvez définir 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.
L'évolutivité comprend (et repose sur) les caractéristiques majeures suivantes de votre produit PlateSpin Protect :
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é.
PlateSpin Protect inclut l'édition Microsoft SQL Server Express. Les fonctionnalités de SQL Server Express sont suffisantes pour un serveur PlateSpin unique qui protège jusqu'à 50 workloads (voir Section 1.4.5, Évolutivité).
REMARQUE :Microsoft SQL Server Express a une limite de taille de base de données de 10 Go et ne peut utiliser qu'un seul noyau de processeur à la fois. Pour plus d'informations sur la configuration requise pour SQL Server Express et ses restrictions, consultez la documentation de Microsoft SQL Server Express 2014.
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.
Dans une grappe VMware DRS, veillez à équilibrer les cibles de protection sur plusieurs hôtes de la grappe pour optimiser les performances.
Nous vous recommandons de configurer le serveur PlateSpin pour qu'il utilise une instance de base de données sur votre serveur de base de données existant utilisant l'édition standard ou entreprise de Microsoft SQL Server dans les environnements suivants :
Déploiement de plusieurs serveurs PlateSpin qui utilisent le même serveur de base de données Microsoft SQL Server distant pour leurs instances de base de données
Déploiements pour lesquels la conservation de tout l'historique des données de rapports est important
Bien que plusieurs serveurs PlateSpin puissent utiliser le même serveur de base de données distant, chaque serveur nécessite une instance de base de données séparée.
Afin de configurer une instance de base de données distante pour votre serveur PlateSpin, reportez-vous à la section Configuration de votre serveur de base de données Microsoft SQL Server distant
du Guide d'installation et de mise à niveau de PlateSpin Protect.