Contrôles de cohérence
Suggérer des modifications
PDF
Les contrôles de cohérence assurent la reprise entre la disponibilité des objets et la cohérence de ces objets sur différents nœuds et sites de stockage, selon les besoins de votre application.
Par défaut, StorageGRID garantit la cohérence de lecture après écriture pour les nouveaux objets. Tout GET suivant un PUT réussi sera en mesure de lire les données nouvellement écrites. Les écrasements d'objets existants, les mises à jour de métadonnées et les suppressions sont cohérents. La propagation des écrasements ne prend généralement que quelques secondes ou minutes, mais peut prendre jusqu'à 15 jours.
Pour effectuer des opérations d'objet à un niveau de cohérence différent, vous pouvez définir un contrôle de cohérence pour chaque compartiment ou pour chaque opération d'API.
Contrôles de cohérence
Le contrôle de cohérence affecte la façon dont les métadonnées utilisées par StorageGRID pour suivre les objets sont distribuées entre les nœuds, et donc la disponibilité des objets pour les requêtes client.
Vous pouvez définir le contrôle de cohérence pour une opération de compartiment ou API sur l'une des valeurs suivantes :
| Contrôle de cohérence | Description |
|---|---|
tous |
Tous les nœuds reçoivent les données immédiatement, sinon la requête échoue. |
forte croissance mondiale |
Garantit une cohérence de lecture après écriture pour toutes les demandes client sur tous les sites. |
site fort |
Garantit la cohérence de lecture après écriture pour toutes les demandes client dans un site. |
lecture-après-nouvelle-écriture |
(Valeur par défaut) assure la cohérence en lecture après écriture des nouveaux objets et la cohérence des mises à jour des objets. Offre une haute disponibilité et une protection des données garanties. Correspondance avec les garanties de cohérence Amazon S3. Remarque : si votre application utilise des demandes HEAD sur des objets qui n'existent pas, vous pouvez recevoir un nombre élevé de 500 erreurs de serveur interne si un ou plusieurs nœuds de stockage ne sont pas disponibles. Pour éviter ces erreurs, définissez le contrôle de cohérence sur « disponible », sauf si vous avez besoin de garanties de cohérence similaires à Amazon S3. |
Disponible (cohérence possible pour les opérations DE TÊTE) |
Se comporte de la même manière que le niveau de cohérence « entre la date et la nouvelle écriture », mais n'assure qu'une cohérence éventuelle pour les opérations DE TÊTE. Niveaux de disponibilité supérieurs à ceux de la « nouvelle écriture » en cas d'indisponibilité des nœuds de stockage Diffère des garanties de cohérence Amazon S3 pour les opérations HEAD uniquement. |
Utilisation des contrôles de cohérence « en cas de nouvelle écriture » et « disponibles »
Lorsqu'une OPÉRATION EN TÊTE ou GET utilise le contrôle de cohérence « en cas de nouvelle écriture » ou QU'une opération GET utilise le contrôle de cohérence « disponible », StorageGRID effectue la recherche en plusieurs étapes, comme suit :
-
Il recherche tout d'abord l'objet à partir d'une faible cohérence.
-
Si cette recherche échoue, elle répète la recherche au niveau de cohérence suivant jusqu'à ce qu'elle atteigne le niveau de cohérence le plus élevé, « tous », qui nécessite la disponibilité de toutes les copies des métadonnées de l'objet.
Si une OPÉRATION HEAD ou GET utilise le contrôle de cohérence « read-after-New-write » mais que l'objet n'existe pas, la recherche d'objet atteint toujours le niveau de cohérence « All ». Comme ce niveau de cohérence requiert la disponibilité de toutes les copies des métadonnées de l'objet, vous pouvez recevoir un nombre élevé de 500 erreurs de serveur interne si un ou plusieurs nœuds de stockage sont indisponibles.
Sauf si vous avez besoin de garanties de cohérence similaires à Amazon S3, vous pouvez empêcher ces erreurs pour les opérations HEAD en définissant le contrôle de cohérence sur « disponible ». Lorsqu'une opération DE TÊTE utilise le contrôle de cohérence « disponible », StorageGRID n'offre qu'une cohérence éventuelle. Il ne réessaie pas l'échec d'une opération tant qu'elle n'atteint pas le niveau de cohérence « tous ». Il n'est donc pas nécessaire que toutes les copies des métadonnées de l'objet soient disponibles.
Spécification du contrôle de cohérence pour une opération d'API
Pour définir le contrôle de cohérence pour une opération API individuelle, les contrôles de cohérence doivent être pris en charge pour l'opération, et vous devez spécifier le contrôle de cohérence dans l'en-tête de la demande. Cet exemple définit le contrôle de cohérence sur "site de segmentation" pour une opération D'OBTENTION d'objet.
GET /bucket/object HTTP/1.1
Date: date
Authorization: authorization name
Host: host
Consistency-Control: strong-site
|
Vous devez utiliser le même contrôle de cohérence pour les opérations PLACER l'objet et OBTENIR l'objet. |
Spécification du contrôle de cohérence pour un compartiment
Pour définir le contrôle de cohérence du compartiment, vous pouvez utiliser la demande de cohérence StorageGRID PUT bucket et la demande DE cohérence GET bucket. Vous pouvez également utiliser le Gestionnaire de locataires ou l'API de gestion des locataires.
Lors du réglage des commandes de cohérence pour un godet, tenez compte des éléments suivants :
-
La configuration du contrôle de cohérence d'un compartiment détermine quel contrôle de cohérence est utilisé pour les opérations S3 effectuées sur les objets dans le compartiment ou sur la configuration du compartiment. Cela n'affecte pas les opérations du compartiment lui-même.
-
Le contrôle de cohérence d'une opération API individuelle remplace le contrôle de cohérence du compartiment.
-
En général, les compartiments doivent utiliser le contrôle de cohérence par défaut, « en cas d'écriture ultérieure ». Si les demandes ne fonctionnent pas correctement, modifiez le comportement du client de l'application si possible. Ou configurez le client afin de spécifier le contrôle de cohérence pour chaque requête d'API. Réglez le contrôle de cohérence au niveau du godet uniquement en dernier recours.
Interaction des contrôles de cohérence et des règles ILM pour la protection des données
Le contrôle de cohérence et la règle ILM de votre choix affectent la protection des objets. Ces paramètres peuvent interagir.
Par exemple, le contrôle de cohérence utilisé lorsqu'un objet est stocké affecte le placement initial des métadonnées d'objet, tandis que le comportement d'ingestion sélectionné pour la règle ILM affecte le placement initial des copies d'objet. Étant donné que StorageGRID nécessite l'accès aux métadonnées d'un objet et à ses données pour répondre aux demandes client, la sélection de niveaux de protection correspondant au niveau de cohérence et au comportement d'ingestion permet d'améliorer la protection des données initiale et de mieux prévoir les réponses du système.
Les comportements d'ingestion suivants sont disponibles pour les règles ILM :
-
Strict : toutes les copies spécifiées dans la règle ILM doivent être effectuées avant que le succès ne soit renvoyé au client.
-
Équilibré: StorageGRID tente de faire toutes les copies spécifiées dans la règle ILM à l'entrée; si ce n'est pas possible, des copies intermédiaires sont faites et le succès est renvoyé au client. Les copies spécifiées dans la règle ILM sont effectuées lorsque cela est possible.
-
Double commit: StorageGRID effectue immédiatement des copies intermédiaires de l'objet et retourne le succès au client. Les copies spécifiées dans la règle ILM sont effectuées lorsque cela est possible.
|
|
Avant de sélectionner le comportement d'entrée d'une règle ILM, lisez la description complète de ces paramètres dans les instructions de gestion des objets avec la gestion du cycle de vie des informations. |
Exemple d'interaction du contrôle de cohérence et de la règle ILM
Supposons que vous disposez d'une grille à deux sites avec la règle ILM suivante et le paramètre de niveau de cohérence suivant :
-
Règle ILM : créez deux copies d'objet, une sur le site local et une sur un site distant. Le comportement d'entrée strict est sélectionné.
-
Niveau de cohérence: "Sept-global" (les métadonnées d'objet sont immédiatement distribuées à tous les sites).
Lorsqu'un client stocke un objet dans la grille, StorageGRID effectue à la fois des copies d'objet et distribue les métadonnées aux deux sites avant de rétablir la réussite du client.
L'objet est entièrement protégé contre la perte au moment du message d'ingestion. Par exemple, si le site local est perdu peu de temps après l'ingestion, des copies des données de l'objet et des métadonnées de l'objet existent toujours sur le site distant. L'objet est entièrement récupérable.
Si vous utilisez à la place la même règle ILM et le niveau de cohérence « sept-site », le client peut recevoir un message de réussite après la réplication des données d'objet sur le site distant, mais avant que les métadonnées d'objet ne soient distribuées sur ce site. 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 de temps après l'ingestion, les métadonnées d'objet sont perdues. L'objet ne peut pas être récupéré.
L'interdépendance entre les niveaux de cohérence et les règles ILM peut être complexe. Contactez NetApp si vous avez besoin d'aide.