Les exigences en matière de stockage et de bande passante réseau peuvent augmenter lors de l'utilisation des commandes trim/unmap du système d'exploitation invité avec vSphere Replication. Vous pouvez également observer des violations de RPO.
Synchronisation incrémentielle après l'utilisation des commandes trim/unmap du SE invité
L'appel des commandes trim/unmap peut augmenter la consommation de stockage sur le site cible.
Après l'utilisation des commandes trim/unmap sur le disque du site source, l'espace libre disponible sur le disque est ajouté aux blocs de données que vSphere Replication transfère vers le site cible lors du cycle d'objectif de point de récupération suivant. Par conséquent, lorsque le disque du site source est moins plein, la taille des blocs modifiés transférés vers le site cible est supérieure.
Par exemple, si le disque du site source est de 10 To et que seul 1 To est alloué, l'appel des commandes trim/unmap entraîne un transfert d'au moins 9 To vers le site cible.
Le disque du site source est de 10 To, dont 9 To sont alloués et si vous supprimez 2 To de données, l'appel des commandes trim/unmap entraîne un transfert d'au moins 3 To de données vers le site cible.
En raison de la synchronisation incrémentielle et selon la configuration RAID définie par la stratégie de stockage de machine virtuelle sur le site cible, la consommation de stockage de la machine virtuelle répliquée peut être plus de deux fois plus élevée que la consommation de la machine virtuelle source.
Vous ne pouvez pas voir la consommation de stockage de la machine virtuelle répliquée sur le site cible. Vous pouvez uniquement voir la consommation globale de la banque de données vSAN dans son ensemble. Par conséquent, vous ne pouvez pas suivre l'espace de stockage récupéré au niveau du disque de machine virtuelle, mais vous pouvez le suivre en examinant l'espace libre global restant sur la banque de données vSAN.
Violations de l'objet de point de récupération après l'utilisation des commandes trim/unmap sur la machine virtuelle source
Vous pouvez appeler les commandes trim/unmap manuellement ou elles peuvent être appelées par le système d'exploitation invité à certains intervalles de temps. Dans les deux cas, la synchronisation après la commande peut prendre un certain temps.
L'utilisation des commandes trim/unmap pour récupérer l'espace inutilisé sur la machine virtuelle source peut générer un grand nombre de blocs de disque modifiés. La synchronisation de ces modifications peut prendre plus de temps que l'objectif de point de récupération configuré et vSphere Replication commence à signaler des violations de l'objectif de point de récupération.
Étant donné que la réplication se trouve derrière la planification de l'objectif de point de récupération, pour synchroniser les blocs de disque modifiés, une nouvelle synchronisation incrémentielle commence dès que la synchronisation de l'instance précédente se termine. Ce processus de synchronisations incrémentielles immédiates se poursuit jusqu'à ce que vSphere Replication crée une instance de réplica qui répond à la planification de l'objectif de point de récupération et ne signale pas de violation de l'objectif de point de récupération. L'état de réplication devient OK.
Utiliser le mode de gestion de la suppression du mappage du pilote de filtre de vSphere Replication
Sur ESXi 7.0 Update 3 ou version ultérieure, par défaut, le pilote de filtre vSphere Replication échoue pour les commandes SCSI UNMAP lors d'une opération de synchronisation, si ces commandes remplacent le contenu qui est transféré vers le site cible. Le système d'exploitation invité retentera la commande ultérieurement sans affecter les applications qui s'exécutent dans la machine virtuelle. Certains systèmes d'exploitation invités n'aiment pas ce comportement du pilote de filtre et peuvent cesser de répondre alors que l'opération de synchronisation est en cours.
Sur ESXi 7.0 Update 2 ou version antérieure, il existe un mode différent de gestion de la suppression du mappage du hbr_filter, dans lequel les commandes UNMAP sont adaptées en préservant le contenu transféré. Certains systèmes d'exploitation invités se comportent mieux dans ce mode, même si la méthode présente certains inconvénients :
- Des opérations de lecture et d'écriture supplémentaires pour préserver les régions qui se chevauchent sur un stockage lent peuvent entraîner des retards inattendus. Ces retards peuvent entraîner des réinitialisations du périphérique par certains SE invités pendant l'opération de synchronisation.
- Augmentation temporaire de la consommation d'espace de stockage par le contenu du disque conservé.
Conditions préalables
- Sur ESXi 7.0 Update 3 ou version ultérieure, vous pouvez revenir au comportement précédent en utilisant le paramètre avancé ESXi
