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.

Comment l'API REST StorageGRID S3 équilibre la disponibilité et la cohérence

La cohérence assure un équilibre entre la disponibilité des objets et leur cohérence sur différents nœuds de stockage et sites. Vous pouvez modifier la cohérence selon les besoins de votre application.

Par défaut, StorageGRID garantit la cohérence en lecture après écriture pour les objets nouvellement créés. Toute requête GET suivant une requête PUT réussie pourra lire les données nouvellement écrites. Les écrasements d'objets existants, les mises à jour de métadonnées et les suppressions sont finalement cohérents.

Si vous souhaitez effectuer des opérations sur les objets avec un niveau de cohérence différent, vous pouvez :

  • Spécifiez une cohérence pour chaque compartiment.

  • Spécifiez une consistance pour chaque opération API.

  • Modifiez la cohérence globale par défaut de la grille en effectuant l'une des tâches suivantes :

    • Dans le Gestionnaire de grille, accédez à Configuration > Système > Paramètres de stockage > Cohérence par défaut des compartiments.

    • .

      Remarque Une modification de la cohérence globale de la grille s'applique uniquement aux compartiments créés après la modification du paramètre. Pour connaître les détails d'une modification, consultez le journal des audits situé à /var/local/log (recherchez consistencyLevel).

Valeurs de cohérence

La cohérence influe sur la manière dont les métadonnées que StorageGRID utilise pour le suivi des objets sont distribuées entre les nœuds. La cohérence influe sur la disponibilité des objets pour les requêtes client.

Vous pouvez définir la cohérence d'un compartiment ou d'une opération d'API sur l'une des valeurs suivantes :

  • 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.

Utilisez la cohérence « Lecture après nouvelle écriture » et « Disponible »

Lorsqu'une opération HEAD ou GET utilise la cohérence « Read-after-new-write », StorageGRID effectue la recherche en plusieurs étapes, comme suit :

  • Il commence par rechercher l'objet avec un niveau de cohérence faible.

  • Si cette recherche échoue, elle est répétée à la valeur de cohérence suivante jusqu'à atteindre une cohérence équivalente au comportement pour strong-global.

Si une opération HEAD ou GET utilise la cohérence « Lecture après nouvelle écriture » mais que l'objet n'existe pas, la recherche d'objet atteindra toujours un niveau de cohérence équivalent à celui du comportement pour strong-global. Parce que cette cohérence nécessite que plusieurs copies des métadonnées de l'objet soient disponibles sur chaque site, vous pouvez recevoir un nombre élevé d'erreurs 500 Internal Server Error si deux nœuds de stockage ou plus du même site sont indisponibles.

Sauf si vous exigez des garanties de cohérence similaires à celles d'Amazon S3, vous pouvez éviter ces erreurs pour les opérations HEAD et GET en définissant la cohérence sur « Disponible ». Lorsqu'une opération HEAD ou GET utilise la cohérence « Disponible », StorageGRID assure uniquement une cohérence éventuelle. Il ne retente pas une opération ayant échoué en cas de cohérence croissante, il n'est donc pas nécessaire que plusieurs copies des métadonnées de l'objet soient disponibles.

Spécifiez la cohérence pour l'opération API

Pour définir la cohérence d'une opération API individuelle, les valeurs de cohérence doivent être prises en charge pour l'opération, et vous devez spécifier la cohérence dans l'en-tête de la requête. Cet exemple définit la cohérence sur « Strong-site » pour une opération GetObject.

GET /bucket/object HTTP/1.1
Date: date
Authorization: authorization name
Host: host
Consistency-Control: strong-site
Remarque Vous devez utiliser la même cohérence pour les opérations PutObject et GetObject.

Spécifiez la cohérence du compartiment

Pour définir la cohérence d'un compartiment, vous pouvez utiliser la requête "Cohérence PUT Bucket" StorageGRID. Ou vous pouvez "modifier la cohérence d'un bucket" depuis le Tenant Manager.

Lors du réglage de la consistance d'un bucket, tenez compte des points suivants :

  • La configuration de la cohérence d'un compartiment détermine le type de cohérence utilisé pour les opérations S3 effectuées sur les objets contenus dans le compartiment ou sur la configuration du compartiment. Elle n'affecte pas les opérations sur le compartiment lui-même.

  • La cohérence d'une opération API individuelle prime sur la cohérence du compartiment.

  • En règle générale, les buckets doivent utiliser la cohérence par défaut « Lecture après nouvelle écriture ». Si les requêtes ne fonctionnent pas correctement, modifiez le comportement du client applicatif si possible. Ou, configurez le client pour spécifier la cohérence pour chaque requête API. Définissez la cohérence au niveau du bucket uniquement en dernier recours.

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

Le niveau de cohérence choisi et la règle ILM influent tous deux sur la manière dont les objets sont protégés. Ces paramètres peuvent interagir.

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

Les "options d'ingestion"règles ILM suivantes sont disponibles :

Double engagement

StorageGRID crée immédiatement des copies intermédiaires de l'objet et renvoie la confirmation au client. Les copies spécifiées dans la règle ILM sont effectuées lorsque cela est possible.

Strict

Toutes les copies spécifiées dans la règle ILM doivent être effectuées avant que la réussite ne soit renvoyée au client.

Équilibré

StorageGRID tente de créer toutes les copies spécifiées dans la règle ILM lors de l'ingestion ; si cela s'avère impossible, des copies intermédiaires sont créées et un message de succès est renvoyé au client. Les copies spécifiées dans la règle ILM sont créées dès que possible.

Exemple de la façon dont la cohérence et la règle 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.