Considérations relatives aux pools de stockage cloud
Suggérer des modifications
PDF
Si vous envisagez d'utiliser un pool de stockage cloud pour déplacer les objets hors du système StorageGRID, vous devez étudier les critères de configuration et d'utilisation des pools de stockage cloud.
Considérations générales
-
En général, le stockage d'archivage dans le cloud, comme Amazon S3 Glacier ou Azure Blob Storage, est un emplacement économique pour stocker les données d'objet. Mais le coût de la récupération des données à partir du stockage d'archivage dans le cloud est relativement élevé. Pour atteindre le coût global le plus bas, vous devez savoir quand et à quelle fréquence vous accéderez aux objets dans Cloud Storage Pool. L'utilisation d'un pool de stockage cloud est recommandée uniquement pour le contenu dont vous souhaitez accéder rarement.
-
N'utilisez pas Cloud Storage pools pour les objets qui ont été ingérées par les clients Swift. Swift ne prend pas en charge les demandes DE restauration POST-objet. StorageGRID ne pourra donc pas récupérer d'objets Swift ayant été transférés vers le stockage Glacier S3 ou le Tier d'archivage du stockage Azure Blob Storage. L'émission d'une demande d'objet GET Swift pour récupérer ces objets échouera (403 interdit).
-
L'utilisation de pools de stockage cloud avec FabricPool n'est pas prise en charge en raison de la latence ajoutée pour extraire un objet de la cible du pool de stockage cloud.
Informations requises pour la création d'un pool de stockage cloud
Avant de créer un pool de stockage cloud, vous devez créer un compartiment S3 externe ou le conteneur de stockage Azure Blob externe que vous utiliserez pour le pool de stockage cloud. Lorsque vous créez le pool de stockage cloud dans StorageGRID, vous devez spécifier les informations suivantes :
-
Le type de fournisseur : stockage Amazon S3 ou Azure Blob.
-
Si vous sélectionnez Amazon S3, que le pool de stockage cloud soit utilisé avec la région secrète AWS (CAP (C2S Access Portal)).
-
Nom exact du godet ou du conteneur.
-
Le terminal de service devait accéder au compartiment ou au conteneur.
-
Pour accéder au compartiment ou au conteneur :
-
S3 : en option, une clé d'accès et une clé secrète d'accès.
-
C2S : l'URL complète pour obtenir les informations d'identification temporaires du serveur CAP; un certificat d'autorité de certification de serveur, un certificat client, une clé privée pour le certificat client, et, si la clé privée est cryptée, la phrase de passe pour le déchiffrer.
-
Stockage Azure Blob : nom de compte et clé de compte. Ces informations d'identification doivent disposer d'une autorisation complète pour le conteneur.
-
-
Un certificat d'autorité de certification personnalisé permet éventuellement de vérifier les connexions TLS avec le compartiment ou le conteneur.
Considérations relatives aux ports utilisés pour les pools de stockage cloud
Pour s'assurer que les règles ILM peuvent déplacer des objets vers et depuis le pool de stockage cloud spécifié, vous devez configurer le ou les réseaux contenant les nœuds de stockage du système. Vous devez vous assurer que les ports suivants peuvent communiquer avec le pool de stockage cloud.
Par défaut, les pools de stockage cloud utilisent les ports suivants :
-
80: Pour les URI de point final commençant par http
-
443: Pour les URI de point final qui commencent par https
Vous pouvez spécifier un autre port lorsque vous créez ou modifiez un pool de stockage cloud.
Si vous utilisez un serveur proxy non transparent, vous devez également configurer un proxy de stockage pour permettre l'envoi de messages vers des noeuds finaux externes, tels qu'un noeud final sur Internet.
Considérations relatives aux coûts
L'accès au stockage dans le cloud à l'aide d'un pool de stockage cloud requiert une connectivité réseau au cloud. Tenez compte des coûts de l'infrastructure réseau que vous utiliserez pour accéder au cloud et le provisionner de façon appropriée, en fonction de la quantité de données que vous prévoyez de déplacer entre StorageGRID et le cloud à l'aide du pool de stockage cloud.
Lorsque StorageGRID se connecte au terminal Cloud Storage Pool externe, plusieurs demandes de contrôle de la connectivité sont émises et les opérations nécessaires sont possibles. Un certain nombre de coûts supplémentaires seront associés à ces demandes, mais le coût de la surveillance d'un pool de stockage cloud ne doit être qu'une fraction du coût global du stockage d'objets dans S3 ou Azure.
Des coûts plus importants peuvent être encourus si vous devez déplacer des objets depuis un terminal externe de pool de stockage dans le cloud vers StorageGRID. Les objets peuvent être redéplacés vers StorageGRID dans l'un ou l'autre de ces cas :
-
La seule copie de l'objet se trouve dans un pool de stockage cloud et vous décidez de le stocker dans StorageGRID à la place. Dans ce cas, il vous suffit de reconfigurer les règles et les règles ILM. Lors de l'évaluation ILM, StorageGRID émet plusieurs demandes de récupération de l'objet à partir du pool de stockage cloud. StorageGRID crée ensuite le nombre spécifié de copies répliquées ou codées en local. Une fois que l'objet est de nouveau déplacé vers StorageGRID, la copie dans le pool de stockage cloud est supprimée.
-
Les objets sont perdus en raison de la défaillance du nœud de stockage. Si la seule copie restante d'un objet se trouve dans un pool de stockage cloud, StorageGRID restaure temporairement l'objet et crée une nouvelle copie sur le nœud de stockage restauré.
|
Lorsque les objets sont déplacés vers StorageGRID à partir d'un pool de stockage cloud, StorageGRID émet plusieurs requêtes vers le terminal de pool de stockage cloud pour chaque objet. Avant de déplacer un grand nombre d'objets, contactez le support technique pour obtenir de l'aide pour estimer le délai et les coûts associés. |
S3 : autorisations requises pour le compartiment de pool de stockage cloud
La politique de compartiment pour le compartiment S3 externe utilisé pour un pool de stockage cloud doit autoriser StorageGRID à déplacer un objet vers le compartiment, à obtenir l'état d'un objet et à restaurer un objet à partir du stockage Glacier, le cas échéant, et bien plus encore. Dans l'idéal, StorageGRID doit disposer d'un accès total au compartiment (s3:*) ; Cependant, si ce n'est pas possible, la politique de 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 sur le cycle de vie du compartiment externe
Le déplacement des objets entre le StorageGRID et le compartiment S3 externe spécifié dans le pool de stockage cloud est contrôlé par les règles ILM et la politique ILM active dans StorageGRID. À l'inverse, la transition des objets à partir du compartiment S3 externe spécifié dans le pool de stockage cloud 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 migrer des objets depuis le pool de stockage cloud, vous devez créer la configuration de cycle de vie appropriée sur un compartiment S3 externe. Vous devez d'autre part utiliser une solution de stockage implémentant la classe de stockage Glacier et prendre en charge l'API DE restauration POST-objet S3.
Supposons par exemple que vous souhaitiez que tous les objets déplacés d'StorageGRID vers le pool de stockage cloud soient transférés immédiatement vers le stockage Amazon S3 Glacier. Vous devez créer une configuration de cycle de vie sur le compartiment S3 externe qui spécifie une seule action (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 consiste à basculer tous les objets de compartiment vers Amazon S3 Glacier le jour de leur création (à savoir le jour où ils ont été déplacés d'StorageGRID vers le pool de stockage cloud).
|
|
Lors de la configuration du cycle de vie du compartiment externe, n'utilisez jamais les actions expiration pour définir quand les objets arrivent à expiration. Les actions d'expiration entraînent la suppression des objets expirés par le système de stockage externe. Si vous tentez par la suite d'accéder à un objet expiré à partir de StorageGRID, l'objet supprimé est introuvable. |
Pour migrer les objets du pool de stockage cloud vers l'archivage profond S3 Glacier (au lieu d'Amazon S3 Glacier), spécifiez <StorageClass>DEEP_ARCHIVE</StorageClass> pendant le cycle de vie du compartiment. Toutefois, sachez que vous ne pouvez pas utiliser le Expedited tiering pour restaurer des objets à partir d'une archive complète S3 Glacier.
Azure : considérations relatives au niveau d'accès
Lorsque vous configurez un compte de stockage Azure, vous pouvez définir le niveau d'accès par défaut sur chaud ou froid. Lorsque vous créez un compte de stockage à utiliser avec un pool de stockage cloud, vous devez utiliser le Tier actif comme niveau par défaut. Même si StorageGRID définit immédiatement le Tier sur Archive lors du déplacement d'objets vers le pool de stockage cloud, l'utilisation du paramètre par défaut de Hot garantit que vous ne serez pas facturé de frais de suppression anticipé pour les objets supprimés du Tier Cool avant le minimum de 30 jours.
Azure : gestion du cycle de vie non prise en charge
N'utilisez pas la fonctionnalité de gestion du cycle de vie du stockage Azure Blob Storage pour le conteneur utilisé avec un pool de stockage cloud. Toute interférence entre les opérations du cycle de vie du système Cloud Storage Pool.