Exigences et limites des Cloud Storage Pool dans StorageGRID
Suggérer des modifications
PDF
Si vous prévoyez d'utiliser un Cloud Storage Pool pour déplacer des objets hors du système StorageGRID, vous devez examiner les considérations relatives à la configuration et à l'utilisation des Cloud Storage Pools.
Considérations générales
-
En général, le stockage d'archives cloud, tel que Amazon S3 Glacier ou Azure Blob storage, est un endroit peu coûteux pour stocker des données d'objets. Cependant, les coûts pour récupérer des données depuis le stockage d'archives cloud sont relativement élevés. Pour obtenir le coût global le plus bas, vous devez prendre en compte quand et à quelle fréquence vous accéderez aux objets dans le Cloud Storage Pool. L'utilisation d'un Cloud Storage Pool est recommandée uniquement pour le contenu auquel vous prévoyez d'accéder rarement.
-
L'utilisation de pools de stockage cloud avec FabricPool n'est pas prise en charge en raison de la latence supplémentaire nécessaire pour récupérer un objet depuis la cible du pool de stockage cloud.
-
Les objets avec le verrouillage d'objet S3 activé ne peuvent pas être placés dans des Cloud Storage Pools.
-
Les combinaisons suivantes de plateforme, d'authentification et de protocole avec S3 Object lock ne sont pas prises en charge pour les Cloud Storage Pools :
-
Plateformes : Google Cloud Platform et Azure
-
Types d'authentification : Accès anonyme
-
Protocole : HTTP
-
Considérations relatives aux ports utilisés pour les pools de stockage cloud
Pour que les règles ILM puissent déplacer des objets vers et depuis le Cloud Storage Pool spécifié, vous devez configurer le ou les réseaux contenant les Storage Nodes de votre système. Vous devez vous assurer que les ports suivants peuvent communiquer avec le Cloud Storage Pool.
Par défaut, les pools de stockage cloud utilisent les ports suivants :
-
80 : Pour les URI de point de terminaison qui commencent par http
-
443 : Pour les URI de point de terminaison qui commencent par https
Vous pouvez spécifier un port différent lors de la création ou de la modification d'un Cloud Storage Pool.
Si vous utilisez un serveur proxy non transparent, vous devez également "configurer un proxy de stockage" autoriser l'envoi de messages vers des points de terminaison externes, tels qu'un point de terminaison sur Internet.
Considérations relatives aux coûts
L'accès au stockage dans le cloud à l'aide d'un Cloud Storage Pool nécessite une connectivité réseau au cloud. Vous devez prendre en compte le coût de l'infrastructure réseau que vous utiliserez pour accéder au cloud et la dimensionner de manière appropriée, en fonction de la quantité de données que vous prévoyez de transférer entre StorageGRID et le cloud à l'aide du Cloud Storage Pool.
Lorsque StorageGRID se connecte au point de terminaison du Cloud Storage Pool externe, il émet diverses requêtes pour surveiller la connectivité et s'assurer qu'il peut effectuer les opérations requises. Bien que ces requêtes engendrent des coûts supplémentaires, le coût de la surveillance d'un Cloud Storage Pool ne devrait représenter qu'une faible fraction du coût total du stockage d'objets dans S3 ou Azure.
Des coûts plus importants peuvent s'appliquer si vous devez déplacer des objets d'un point de terminaison de Cloud Storage Pool externe vers StorageGRID. Les objets peuvent être déplacés vers StorageGRID dans l'un ou l'autre des cas suivants :
-
L'unique copie de l'objet se trouve dans un Cloud Storage Pool et vous décidez de stocker l'objet dans StorageGRID à la place. Dans ce cas, vous reconfigurez vos règles et votre politique ILM. Lors de l'évaluation ILM, StorageGRID effectue plusieurs requêtes pour récupérer l'objet depuis le Cloud Storage Pool. StorageGRID crée ensuite localement le nombre spécifié de copies répliquées ou à codage d'effacement. Après que l'objet a été déplacé vers StorageGRID, la copie dans le Cloud Storage Pool est supprimée.
-
Des objets sont perdus suite à une panne d'un nœud de stockage. Si la seule copie restante d'un objet se trouve dans un Cloud Storage Pool, StorageGRID restaure temporairement l'objet et crée une nouvelle copie sur le nœud de stockage récupéré.
|
Lorsque des objets sont déplacés vers StorageGRID depuis un pool de stockage cloud, StorageGRID envoie plusieurs requêtes au point de terminaison du pool de stockage cloud pour chaque objet. Avant de déplacer un grand nombre d'objets, veuillez contacter le support technique pour obtenir une estimation du délai et des coûts associés. |
S3 : Autorisations requises pour le compartiment Cloud Storage Pool
Les politiques du compartiment S3 externe utilisé pour un Cloud Storage Pool doivent accorder à StorageGRID l'autorisation de déplacer un objet vers le compartiment, de consulter le statut d'un objet, de restaurer un objet depuis le stockage Glacier si nécessaire, et plus encore. Idéalement, StorageGRID devrait disposer d'un accès complet au compartiment(s3:* ; cependant, si cela n'est pas possible, la politique du compartiment doit accorder les autorisations S3 suivantes à StorageGRID :
-
s3:AbortMultipartUpload -
s3:DeleteObject -
s3:GetObject -
s3:ListBucket -
s3:ListBucketMultipartUploads -
s3:ListMultipartUploadParts -
s3:PutObject -
s3:RestoreObject
S3 : Considérations relatives au cycle de vie du compartiment externe
Le déplacement d'objets entre StorageGRID et le compartiment S3 externe spécifié dans le Cloud Storage Pool est contrôlé par les règles ILM et les politiques ILM actives dans StorageGRID. En revanche, la transition des objets du compartiment S3 externe spécifié dans le Cloud Storage Pool vers Amazon S3 Glacier ou S3 Glacier Deep Archive (ou vers une solution de stockage implémentant la classe de stockage Glacier) est contrôlée par la configuration du cycle de vie de ce compartiment.
Si vous souhaitez transférer des objets depuis le Cloud Storage Pool, vous devez créer la configuration de cycle de vie appropriée sur le compartiment S3 externe et utiliser une solution de stockage qui implémente la classe de stockage Glacier et prend en charge l’API S3 RestoreObject.
Par exemple, supposons que vous souhaitiez que tous les objets déplacés de StorageGRID vers le Cloud Storage Pool soient immédiatement transférés vers le stockage Amazon S3 Glacier. Vous créeriez alors une configuration de cycle de vie sur le compartiment S3 externe spécifiant une action unique (Transition) comme suit :
<LifecycleConfiguration>
<Rule>
<ID>Transition Rule</ID>
<Filter>
<Prefix></Prefix>
</Filter>
<Status>Enabled</Status>
<Transition>
<Days>0</Days>
<StorageClass>GLACIER</StorageClass>
</Transition>
</Rule>
</LifecycleConfiguration>
Cette règle transférerait tous les objets du compartiment vers Amazon S3 Glacier le jour de leur création (c'est-à-dire le jour où ils ont été déplacés de StorageGRID vers le Cloud Storage Pool).
|
Lors de la configuration du cycle de vie du compartiment externe, n'utilisez jamais les actions Expiration pour définir la date d'expiration des objets. Les actions d'expiration entraînent la suppression des objets expirés par le système de stockage externe. Si vous tentez ultérieurement d'accéder à un objet expiré depuis StorageGRID, l'objet supprimé sera introuvable. |
Si vous souhaitez transférer des objets du Cloud Storage Pool vers S3 Glacier Deep Archive (au lieu d’Amazon S3 Glacier), spécifiez <StorageClass>DEEP_ARCHIVE</StorageClass> dans le cycle de vie du compartiment. Cependant, notez que vous ne pouvez pas utiliser le niveau Expedited pour restaurer des objets depuis S3 Glacier Deep Archive.
Azure : Considérations relatives au niveau d’accès
Lors de la configuration d'un compte de stockage Azure, vous pouvez définir le niveau d'accès par défaut sur Hot ou Cool. Lors de la création d'un compte de stockage destiné à être utilisé avec un Cloud Storage Pool, vous devez utiliser le niveau Hot comme niveau par défaut. Même si StorageGRID définit immédiatement le niveau sur Archive lorsqu'il déplace des objets vers le Cloud Storage Pool, l'utilisation du niveau Hot par défaut garantit que vous ne serez pas facturé de frais de suppression anticipée pour les objets retirés du niveau Cool avant la période minimale de 30 jours.
Azure : la gestion du cycle de vie n’est pas prise en charge
N’utilisez pas la gestion du cycle de vie du stockage Blob Azure pour le conteneur utilisé avec un Cloud Storage Pool. Les opérations de cycle de vie pourraient interférer avec les opérations du Cloud Storage Pool.