• Les données codées sont déplacées depuis les nœuds de stockage qui occupent moins d'espace
disponible vers les nœuds de stockage qui occupent davantage d'espace disponible.
• Les valeurs utilisées (%) peuvent rester différentes entre les nœuds de stockage, car la procédure de
rééquilibrage EC ne déplace pas les copies d'objet répliquées.
• Les données protégées des objets avec code d'effacement restent les mêmes.
Lors de l'exécution de la procédure de rééquilibrage EC, les performances des opérations ILM et les
opérations des clients S3 et Swift sont susceptibles d'être affectées. Pour cette raison, vous ne devez effectuer
cette procédure que dans des cas limités.
Lorsqu'il ne doit pas effectuer de rééquilibrage EC
Par exemple lorsque vous n'avez pas besoin d'effectuer un rééquilibrage EC, prenez en compte les points
suivants :
• StorageGRID s'exécute sur un seul site, qui contient trois nœuds de stockage.
• La règle ILM utilise une règle de code d'effacement 2+1 pour tous les objets de plus de 0.2 Mo et une règle
de réplication à 2 copies pour les objets plus petits.
• Tous les nœuds de stockage sont complètement pleins et l'alerte stockage d'objets bas a été déclenchée
au niveau de gravité principal. L'action recommandée est d'effectuer une procédure d'extension pour
ajouter des nœuds de stockage.
Pour développer le site dans cet exemple, il est recommandé d'ajouter au moins trois nœuds de stockage.
StorageGRID a besoin de trois nœuds de stockage pour le codage d'effacement 2+1. Ainsi, il peut placer les
deux fragments de données et le fragment de parité sur différents nœuds.
Une fois les trois nœuds de stockage ajoutés, les nœuds de stockage d'origine restent pleins, mais les objets
peuvent continuer à être ingérées sur le schéma de codage d'effacement 2+1 sur les nouveaux nœuds.
L'exécution de la procédure de rééquilibrage EC n'est pas recommandée dans ce cas : l'exécution de la
procédure réduit temporairement les performances, ce qui risque d'affecter les opérations client.
2101