E-S de données et chiffrement

La taille de l'objet peut avoir un impact significatif sur les performances de IBM Cloud® Object Storage. Choisissez la bonne approche pour votre charge de travail.

Transferts multiparties

Dans des conditions typiques, les téléchargements en plusieurs parties sont une méthode très efficace pour diviser les transferts en plusieurs transactions parallèles. En fonction de la taille de l'objet, une taille de partie de 100MB est généralement recommandée. Dans tous les cas, il est plus efficace de définir la taille de la partie sur un multiple de 4MiB afin d'optimiser l'ingestion et la sortie des données de COS.

Comme avec AWS S3, l'utilisation de transferts multiparties offre les avantages suivants:

Amélioration de la capacité de traitement-Vous pouvez télécharger des parties en parallèle pour améliorer la capacité de traitement.
Reprise rapide en cas de problèmes réseau-La taille de la partie plus petite minimise l'impact du redémarrage d'un téléchargement ayant échoué en raison d'une erreur réseau.
Mettre en pause et reprendre les téléchargements d'objet-Transférer des parties d'objet au fil du temps. Une fois qu'un téléchargement à plusieurs parties est lancé, il n'y a pas d'expiration ; il doit être explicitement terminé ou le téléchargement à plusieurs parties doit être abandonné.
Commencez un téléchargement avant que la taille d'objet finale ne soit connue-Un objet peut être téléchargé lors de sa création.

En raison de la complexité supplémentaire des transferts multiparties, il est recommandé d'utiliser les bibliothèques, outils ou logiciels SDK S3 appropriés qui offrent une prise en charge des transferts multiparties gérés:

Bien qu'il n'existe pas d'API dédiée pour un téléchargement à plusieurs parties, il est possible d'utiliser un en-tête Range dans une demande GET pour lire uniquement une partie spécifique d'un objet, et de nombreuses lectures de plage de valeurs peuvent être émises en parallèle, tout comme lors du téléchargement de parties. Une fois que toutes les parties ont été téléchargées, elles peuvent être concaténées et l'intégrité de l'objet complet peut être vérifiée. Comme indiqué précédemment, l'utilisation de logiciels SDK ou d'autres outils est recommandée pour éviter les complexités de la gestion manuelle de ces transferts.

Les flux de travaux qui doivent stocker un grand nombre de très petits objets peuvent être mieux servis en agrégeant les petits fichiers dans une structure de données plus grande, telle que [Parquet].

Pour les objets dont la taille est supérieure à 200mb, en particulier dans les réseaux moins stables ou sur de très longues distances où la perte de paquets est un problème, Aspera High-Speed Transfer peut offrir d'excellentes performances. Les transferts Aspera peuvent également transférer efficacement des structures de répertoire imbriquées au sein d'une même demande.

Régulation des suppressions par lots

L'API S3 fournit un mécanisme permettant de supprimer jusqu'à 1000 objets avec une seule demande de suppression par lots. Il est recommandé de réguler ces demandes côté client afin de réduire les risques de performances dérogatoires au sein du système COS. Lorsque le nombre de suppressions émises est trop élevé pour le système, le client reçoit des erreurs HTTP 503 avec un message d'erreur indiquant un "ralentissement".

Impacts de la cohérence

IBM Cloud Object Storage System garantit une cohérence immédiate pour toutes les opérations d'objet, ce qui inclut les écritures d'objet, les écrasements, les suppressions, les opérations multiparties et les modifications de liste de contrôle d'accès. La création de compartiment est également immédiatement cohérente. Les métadonnées et la configuration des compartiments sont finalement cohérentes, comme c'est le cas avec d'autres systèmes de stockage d'objets, ce qui signifie que les modifications sur un système hautement distribué peuvent ne pas être synchronisées pendant une courte période. Cela se produit en raison de la mise en cache des métadonnées qui offre des avantages significatifs en termes de performances, et protège également contre la possibilité d'attaques par déni de service.

Certaines applications écraseront le même objet, ou supprimeront et réécriront le même objet de manière répétée pendant une courte période de temps. Cela peut provoquer des conflits dans les index du système COS et doit être évité. Dans les rares cas où l'écrasement de données avec la même clé d'objet (nom) à une fréquence très élevée et sur de longues périodes est un aspect critique d'une conception d'application, une plateforme de stockage différente (fichier, bloc, noSQL, etc.) peut être un meilleur choix.

Vérifications de l'existence

Les applications peuvent vouloir vérifier si un objet existe ou a été modifié avant de l'écrire. Cela entraîne souvent une logique d'application inefficace qui envoie une demande HEAD suivie d'une demande PUT ou GET. Cet anti-pattern entraîne un gaspillage des ressources de réseau et de serveur, et doit être déconseillé.

Au lieu d'utiliser une demande HEAD comme vérification d'existence dans une fonction, utilisez un en-tête de demande conditionnel. Ces en-têtes HTTP standard comparent les hachages ou les horodatages MD5 pour déterminer si l'opération de données doit se poursuivre ou non. Pour plus d'informations, voir Demandes conditionnelles.

Utilisation de demandes conditionnelles

Lors d'une demande de lecture ou d'écriture de données, il est possible de définir des conditions sur cette demande afin d'éviter des opérations inutiles. Cette opération est effectuée à l'aide des en-têtes HTTP pré-conditionnels suivants: If-Match, If-None-Match, If-Modified-Since et If-Unmodified-Since.

Il est généralement préférable d'utiliser If-Match car la granularité de la valeur Last-Modified n'est qu'en secondes et peut ne pas être suffisante pour éviter des conditions d'indétermination dans certaines applications.

Utilisation de l'option If-Match

Sur une demande PUT, HEAD ou GET d'objet, l'en-tête If-Match vérifie si un Etag fourni (hachageMD5 du contenu de l'objet) correspond à la valeur Etag fournie. Si cette valeur correspond, l'opération se poursuit. Si la correspondance échoue, le système renvoie une erreur 412 Precondition Failed.

If-Match est le plus souvent utilisé avec les méthodes de changement d'état (par exemple, POST, PUT, DELETE) pour éviter les écrasements accidentels lorsque plusieurs agents utilisateur peuvent agir en parallèle sur la même ressource (c'est-à-dire pour éviter le problème de "mise à jour perdue").

Utilisation de l'option If-None-Match

Sur une demande PUT, HEAD ou GET d'objet, l'en-tête If-None-Match vérifie si un Etag fourni (hachageMD5 du contenu de l'objet) correspond à la valeur Etag fournie. Si cette valeur ne correspond pas, l'opération se poursuit. Si la correspondance aboutit, le système renvoie une erreur 412 Precondition Failed sur un PUT et un 304 Not Modified sur GET ou HEAD.

If-None-Match est principalement utilisé dans les demandes GET conditionnelles pour permettre des mises à jour efficaces des informations mises en cache avec un minimum de temps système de transaction. Lorsqu'un client souhaite mettre à jour une ou plusieurs réponses stockées comportant des balises d'entité, le client DOIT générer un champ d'en-tête If-None-Match contenant une liste de ces balises d'entité lors d'une demande GET. Cela permet aux serveurs destinataires d'envoyer une réponse 304 (Non modifiée) pour indiquer quand l'une de ces réponses stockées correspond à la représentation sélectionnée.

Utilisation de If-Modified-Since

Sur une demande HEAD ou GET d'objet, l'en-tête If-Modified-Since vérifie si la valeur Last-Modified de l'objet (par exemple Sat, 14 March 2020 19:43:31 GMT) est plus récente qu'une valeur fournie. Si l'objet a été modifié, l'opération se poursuit. Si l'objet n'a pas été modifié, le système renvoie un 304 Not Modified.

If-Modified-Since est généralement utilisé à deux fins distinctes: pour permettre des mises à jour efficaces d'une représentation en cache qui n'a pas de Etag et pour limiter la portée d'une traversée Web aux ressources qui ont récemment été modifiées.

Utilisation de If-Unmodified-Since

Sur une demande PUT, HEAD ou GET d'objet, l'en-tête If-Unmodified-Since vérifie si la valeur Last-Modified de l'objet (par exemple, Sat, 14 March 2020 19:43:31 GMT) est égale ou antérieure à une valeur fournie. Si l'objet n'a pas été modifié, l'opération se poursuit. Si la valeur Last-Modified est plus récente, le système renvoie une erreur 412 Precondition Failed sur un PUT et un 304 Not Modified sous GET ou HEAD.

If-Unmodified-Since est le plus souvent utilisé avec les méthodes de changement d'état (par exemple, POST, PUT, DELETE) pour éviter les écrasements accidentels lorsque plusieurs agents utilisateur peuvent agir en parallèle sur une ressource qui ne fournit pas de balises d'entité avec ses représentations (c'est-à-dire pour éviter le problème de "mise à jour perdue"). Il peut également être utilisé avec des méthodes sécurisées pour abandonner une requête si la représentation sélectionnée ne correspond pas à une requête déjà stockée (ou partiellement stockée) d'une requête antérieure.

Stratégie de relance

Alors que la plupart des bibliothèques et des logiciels SDK traitent automatiquement la logique de relance, il faut être prudent lors de l'écriture du logiciel qui utilise l'API directement pour gérer correctement les erreurs transitoires. Plus important encore, il est essentiel de fournir une logique de relance appropriée qui implémente un retour à l'arrêt exponentiel lors de la réception d'erreurs 503.

Optimisation du chiffrement

IBM COS prend en charge une variété de paramètres de chiffrement pour chiffrer les données en transit. Tous les paramètres de chiffrement ne génèrent pas les mêmes performances de niveau et l'utilisation de TLS en général entraîne une légère dégradation des performances. Les paramètres de chiffrement suivants sont recommandés (par ordre de priorité décroissant):

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA