Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Avantages, inconvénients et limitations des options d'ingestion ILM dans StorageGRID

Comprendre les avantages et les inconvénients de chacune des trois options de protection des données lors de l'ingestion (Balanced, Strict ou Dual commit) peut vous aider à décider laquelle choisir pour une règle ILM.

Pour un aperçu des options d'ingestion, voir "Options d'ingestion".

Avantages des options équilibrée et stricte

Comparées à la validation double, qui crée des copies intermédiaires lors de l'ingestion, les deux options de placement synchrone peuvent offrir les avantages suivants :

  • Meilleure sécurité des données : Les données objet sont immédiatement protégées conformément aux instructions de placement de la règle ILM, qui peuvent être configurées pour se prémunir contre un large éventail de défaillances, y compris la défaillance de plus d’un emplacement de stockage. La double validation ne protège que contre la perte d’une seule copie locale.

  • Fonctionnement plus efficace de la grille : chaque objet n’est traité qu’une seule fois, lors de son ingestion. Parce que le système StorageGRID n’a pas besoin de suivre ni de supprimer les copies intermédiaires, la charge de traitement est réduite et moins d’espace de base de données est consommé.

  • (Équilibré) Recommandé : L’option Équilibré offre une efficacité ILM optimale. L’utilisation de l’option Équilibré est recommandée, sauf si un comportement d’ingestion strict est requis ou si la grille remplit tous les critères pour l’utilisation de Dual commit.

  • (Strict) Certitude quant à l'emplacement des objets : L'option Strict garantit que les objets sont immédiatement stockés conformément aux instructions de placement de la règle ILM.

Inconvénients des options équilibrée et stricte

Comparées à l'option Dual commit, les options Balanced et Strict présentent certains inconvénients :

  • Ingestion côté client plus longue : La latence d'ingestion côté client peut être plus longue. Lorsque vous utilisez les options Balanced ou Strict, un message « ingestion réussie » n'est pas renvoyé au client tant que tous les fragments à code d'effacement ou les copies répliquées n'ont pas été créés et stockés. Cependant, les données des objets atteindront très probablement leur emplacement final beaucoup plus rapidement.

  • (Strict) Taux d'échec d'ingestion plus élevés : Avec l'option Strict, l'ingestion échoue si StorageGRID ne peut pas effectuer immédiatement toutes les copies spécifiées dans la règle ILM. Vous pouvez constater des taux d'échec d'ingestion élevés si un emplacement de stockage requis est temporairement hors ligne ou si des problèmes réseau entraînent des retards dans la copie des objets entre les sites.

  • (Strict) Le placement des objets lors d'un chargement multipartie S3 peut ne pas être conforme à vos attentes dans certaines circonstances : Avec Strict, vous vous attendez à ce que les objets soient placés comme décrit par la règle ILM ou que l'ingestion échoue. Cependant, lors d'un chargement multipartie S3, l'ILM est évalué pour chaque partie de l'objet au fur et à mesure de son ingestion, puis pour l'objet dans son ensemble lorsque le chargement multipartie est terminé. Dans les circonstances suivantes, cela peut entraîner des placements différents de ceux auxquels vous vous attendez :

    • Si les règles ILM changent pendant un chargement multipartie S3 : chaque partie étant placée selon la règle active au moment de son ingestion, certaines parties de l’objet peuvent ne pas respecter les exigences ILM actuelles une fois le chargement multipartie terminé. Dans ces cas, l’ingestion de l’objet n’échoue pas. Au lieu de cela, toute partie mal placée est mise en file d’attente pour une réévaluation ILM et déplacée ultérieurement vers l’emplacement correct.

    • Lorsque les règles ILM filtrent par taille : Lors de l’évaluation ILM d’une partie, StorageGRID filtre sur la taille de la partie, et non sur celle de l’objet. Cela signifie que des parties d’un objet peuvent être stockées dans des emplacements ne répondant pas aux exigences ILM de l’objet dans son ensemble. Par exemple, si une règle spécifie que tous les objets de 10 Go ou plus sont stockés à DC1 tandis que tous les objets plus petits sont stockés à DC2, lors de l’ingestion, chaque partie de 1 Go d’un chargement multipartie en 10 parties est stockée à DC2. Lors de l’évaluation ILM de l’objet, toutes les parties de l’objet sont déplacées vers DC1.

  • (Strict) L'ingestion ne rencontre pas d'échec lorsque les balises ou les métadonnées d'un objet sont mises à jour et que les nouveaux emplacements requis ne peuvent pas être effectués : Avec Strict, vous vous attendez à ce que les objets soient soit placés comme décrit par la règle ILM, soit que l'ingestion échoue. Cependant, lorsque vous mettez à jour les métadonnées ou les balises d'un objet déjà stocké dans la grille, l'objet n'est pas réingéré. Cela signifie que toute modification de l'emplacement de l'objet déclenchée par la mise à jour n'est pas appliquée immédiatement. Les modifications d'emplacement sont effectuées lorsque l'ILM est réévalué par les processus ILM d'arrière-plan normaux. Si les modifications d'emplacement requises ne peuvent pas être effectuées (par exemple, parce qu'un nouvel emplacement requis est indisponible), l'objet mis à jour conserve son emplacement actuel jusqu'à ce que les modifications soient possibles.

Limitations du placement des objets avec les options Balanced et Strict

Les options Équilibré ou Strict ne peuvent pas être utilisées pour les règles ILM qui comportent l'une de ces instructions de placement :

  • Placement dans un Cloud Storage Pool au jour 0.

  • Placements dans un Cloud Storage Pool lorsque la règle a une date de création définie par l'utilisateur comme heure de référence.

Ces restrictions existent car StorageGRID ne peut pas effectuer de copies synchrones vers un Cloud Storage Pool, et une date de création définie par l'utilisateur peut correspondre à la date actuelle.

Comment les règles ILM et la cohérence interagissent pour affecter la protection des données

La manière dont les objets sont protégés dépend à la fois de votre règle ILM et de votre choix de cohérence. Ces paramètres peuvent interagir.

Par exemple, le comportement d'ingestion sélectionné pour une règle ILM influe sur l'emplacement initial des copies d'objets, tandis que la cohérence utilisée lors du stockage d'un objet influe sur l'emplacement initial de ses métadonnées. Étant donné que StorageGRID nécessite l'accès aux données et aux métadonnées d'un objet pour répondre aux requêtes client, le choix de niveaux de protection identiques pour la cohérence et le comportement d'ingestion permet une meilleure protection des données et des réponses système plus prévisibles.

Voici un bref résumé des valeurs de cohérence disponibles dans StorageGRID :

  • Tous : Tous les nœuds reçoivent immédiatement les métadonnées de l’objet ou la requête échouera.

  • Forte-globale : Garantit la cohérence de lecture après écriture pour toutes les requêtes client sur tous les sites. Lorsque la sémantique de quorum est configurée, les comportements suivants s’appliquent :

    • Permet une tolérance aux pannes de site pour les requêtes client lorsque les grilles comportent trois sites ou plus. Les grilles à deux sites n'ont pas de tolérance aux pannes de site.

    • Les opérations S3 suivantes ne pourront pas aboutir si l'un des sites est hors service :

      • DeleteBucketEncryption

      • PutBucketBranch

      • PutBucketEncryption

      • PutBucketVersioning

      • PutObjectLegalHold

      • PutObjectLockConfiguration

      • PutObjectRetention

  • Strong-site : les métadonnées des objets sont immédiatement distribuées aux autres nœuds du site. Garantit la cohérence lecture-après-écriture pour toutes les requêtes client au sein du site.

  • Lecture après nouvelle écriture : Garantit la cohérence en lecture après écriture pour les nouveaux objets et la cohérence éventuelle pour les mises à jour d’objets. Offre une haute disponibilité et des garanties de protection des données. Recommandé dans la plupart des cas.

  • Disponible : Garantit la cohérence éventuelle pour les nouveaux objets et les mises à jour d'objets. Pour les compartiments S3, utilisez cette fonctionnalité uniquement en cas de besoin (par exemple, pour un compartiment contenant des valeurs de journaux rarement lues, ou pour les opérations HEAD ou GET sur des clés qui n'existent pas). Non pris en charge pour les compartiments S3 FabricPool.

Remarque Avant de choisir une valeur de cohérence, "lire la description complète de la cohérence". Vous devez comprendre les avantages et les limites avant de modifier la valeur par défaut.

Exemple de la façon dont la cohérence et les règles ILM peuvent interagir

Supposons que vous ayez une grille à trois sites avec la règle ILM suivante et la cohérence suivante :

  • Règle ILM : Créez trois copies de l’objet, une sur le site local et une sur chaque site distant. Utilisez le comportement d’ingestion strict.

  • Cohérence : Forte et globale (les métadonnées de l’objet sont immédiatement distribuées à plusieurs sites).

Lorsqu'un client stocke un objet dans la grille, StorageGRID effectue trois copies de l'objet et distribue les métadonnées à plusieurs sites avant de renvoyer un message de succès au client.

L'objet est intégralement protégé contre toute perte dès la confirmation de son ingestion. Par exemple, si le site local est perdu peu après l'ingestion, des copies des données de l'objet et des métadonnées de l'objet existent toujours sur les sites distants. L'objet est entièrement récupérable depuis les autres sites.

Si vous utilisiez la même règle ILM et la cohérence forte des sites, le client pourrait recevoir un message de succès après la réplication des données d'objet sur les sites distants, mais avant la distribution des métadonnées d'objet. Dans ce cas, le niveau de protection des métadonnées d'objet ne correspond pas au niveau de protection des données d'objet. Si le site local est perdu peu après l'ingestion, les métadonnées d'objet sont perdues. L'objet ne peut pas être récupéré.

L'interaction entre la cohérence et les règles ILM peut être complexe. Contactez NetApp si vous avez besoin d'assistance.