Présentation et considérations relatives aux services de la plateforme
Avant d’implémenter les services de plateforme, consultez la présentation et les considérations relatives à l’utilisation de ces services.
Pour plus d'informations sur S3, voir"Utiliser l'API REST S3" .
Aperçu des services de la plateforme
Les services de la plateforme StorageGRID peuvent vous aider à mettre en œuvre une stratégie de cloud hybride en vous permettant d'envoyer des notifications d'événements et des copies d'objets S3 et de métadonnées d'objets vers des destinations externes.
Étant donné que l'emplacement cible des services de plateforme est généralement externe à votre déploiement StorageGRID , les services de plateforme vous offrent la puissance et la flexibilité qui découlent de l'utilisation de ressources de stockage externes, de services de notification et de services de recherche ou d'analyse pour vos données.
N’importe quelle combinaison de services de plateforme peut être configurée pour un seul compartiment S3. Par exemple, vous pouvez configurer à la fois le"Service CloudMirror" et"notifications" sur un bucket StorageGRID S3 afin que vous puissiez mettre en miroir des objets spécifiques sur Amazon Simple Storage Service (S3), tout en envoyant une notification sur chacun de ces objets à une application de surveillance tierce pour vous aider à suivre vos dépenses AWS.
|
L'utilisation des services de plateforme doit être activée pour chaque compte de locataire par un administrateur StorageGRID à l'aide de Grid Manager ou de l'API Grid Management. |
Comment les services de la plateforme sont configurés
Les services de plateforme communiquent avec des points de terminaison externes que vous configurez à l'aide de l'"Gestionnaire de locataires" ou le"API de gestion des locataires" . Chaque point de terminaison représente une destination externe, telle qu'un bucket StorageGRID S3, un bucket Amazon Web Services, une rubrique Amazon SNS ou un cluster Elasticsearch hébergé localement, sur AWS ou ailleurs.
Après avoir créé un point de terminaison externe, vous pouvez activer un service de plateforme pour un bucket en ajoutant une configuration XML au bucket. La configuration XML identifie les objets sur lesquels le bucket doit agir, l'action que le bucket doit entreprendre et le point de terminaison que le bucket doit utiliser pour le service.
Vous devez ajouter des configurations XML distinctes pour chaque service de plateforme que vous souhaitez configurer. Par exemple:
-
Si vous voulez tous les objets dont les clés commencent par
/images
pour être répliqué vers un compartiment Amazon S3, vous devez ajouter une configuration de réplication au compartiment source. -
Si vous souhaitez également envoyer des notifications lorsque ces objets sont stockés dans le bucket, vous devez ajouter une configuration de notifications.
-
Si vous souhaitez indexer les métadonnées de ces objets, vous devez ajouter la configuration de notification de métadonnées utilisée pour implémenter l'intégration de la recherche.
Le format du XML de configuration est régi par les API REST S3 utilisées pour implémenter les services de la plateforme StorageGRID :
Service de plateforme | API REST S3 | Se référer à |
---|---|---|
Réplication CloudMirror |
|
|
Notifications |
|
|
Intégration de la recherche |
|
Considérations relatives à l'utilisation des services de plateforme
Considération | Détails |
---|---|
Surveillance du point de terminaison de destination |
Vous devez surveiller la disponibilité de chaque point de terminaison de destination. Si la connectivité au point de terminaison de destination est perdue pendant une période prolongée et qu'un important arriéré de demandes existe, les demandes client supplémentaires (telles que les demandes PUT) adressées à StorageGRID échoueront. Vous devez réessayer ces demandes ayant échoué lorsque le point de terminaison redevient accessible. |
Limitation du point de terminaison de destination |
Le logiciel StorageGRID peut limiter les requêtes S3 entrantes pour un bucket si la vitesse à laquelle les requêtes sont envoyées dépasse la vitesse à laquelle le point de terminaison de destination peut recevoir les requêtes. La limitation se produit uniquement lorsqu'il existe un arriéré de requêtes en attente d'être envoyées au point de terminaison de destination. Le seul effet visible est que les requêtes S3 entrantes prendront plus de temps à s’exécuter. Si vous commencez à détecter des performances nettement plus lentes, vous devez réduire le taux d’ingestion ou utiliser un point de terminaison avec une capacité supérieure. Si l’arriéré des demandes continue de croître, les opérations S3 du client (telles que les demandes PUT) finiront par échouer. Les requêtes CloudMirror sont plus susceptibles d’être affectées par les performances du point de terminaison de destination, car ces requêtes impliquent généralement plus de transfert de données que les requêtes d’intégration de recherche ou de notification d’événements. |
Garanties de commande |
StorageGRID garantit l'ordre des opérations sur un objet au sein d'un site. Tant que toutes les opérations sur un objet se déroulent sur le même site, l'état final de l'objet (pour la réplication) sera toujours égal à l'état dans StorageGRID. StorageGRID fait de son mieux pour ordonner les demandes lorsque des opérations sont effectuées sur les sites StorageGRID . Par exemple, si vous écrivez initialement un objet sur le site A, puis écrasez ultérieurement le même objet sur le site B, il n'est pas garanti que l'objet final répliqué par CloudMirror vers le bucket de destination soit l'objet le plus récent. |
Suppressions d'objets pilotées par ILM |
Pour correspondre au comportement de suppression d'AWS CRR et d'Amazon Simple Notification Service, les demandes de notification d'événements et CloudMirror ne sont pas envoyées lorsqu'un objet dans le compartiment source est supprimé en raison des règles StorageGRID ILM. Par exemple, aucune demande de notification CloudMirror ou d’événement n’est envoyée si une règle ILM supprime un objet après 14 jours. En revanche, les demandes d’intégration de recherche sont envoyées lorsque des objets sont supprimés en raison de l’ILM. |
Utilisation des points de terminaison Kafka |
Pour les points de terminaison Kafka, le protocole TLS mutuel n'est pas pris en charge. Par conséquent, si vous avez L’authentification des points de terminaison Kafka utilise les types d’authentification suivants. Ces types sont différents de ceux utilisés pour l’authentification d’autres points de terminaison, tels qu’Amazon SNS, et nécessitent des informations d’identification de nom d’utilisateur et de mot de passe.
Remarque : les paramètres de proxy de stockage configurés ne s’appliquent pas aux points de terminaison des services de la plateforme Kafka. |
Considérations relatives à l'utilisation du service de réplication CloudMirror
Considération | Détails |
---|---|
État de réplication |
StorageGRID ne prend pas en charge le |
Taille de l'objet |
La taille maximale des objets pouvant être répliqués vers un bucket de destination par le service de réplication CloudMirror est de 5 Tio, ce qui correspond à la taille maximale de l'objet pris en charge. Remarque : la taille maximale recommandée pour une seule opération PutObject est de 5 Gio (5 368 709 120 octets). Si vous avez des objets dont la taille est supérieure à 5 Gio, utilisez plutôt le téléchargement en plusieurs parties. |
Gestion des versions de bucket et identifiants de version |
Si le contrôle de version est activé pour le bucket S3 source dans StorageGRID , vous devez également activer le contrôle de version pour le bucket de destination. Lorsque vous utilisez le contrôle de version, notez que l'ordre des versions d'objet dans le compartiment de destination est le meilleur effort et n'est pas garanti par le service CloudMirror, en raison des limitations du protocole S3. Remarque : les ID de version du bucket source dans StorageGRID ne sont pas liés aux ID de version du bucket de destination. |
Balisage des versions d'objet |
Le service CloudMirror ne réplique aucune requête PutObjectTagging ou DeleteObjectTagging qui fournit un ID de version, en raison des limitations du protocole S3. Étant donné que les ID de version de la source et de la destination ne sont pas liés, il n'existe aucun moyen de garantir qu'une mise à jour de balise vers un ID de version spécifique sera répliquée. En revanche, le service CloudMirror réplique les requêtes PutObjectTagging ou DeleteObjectTagging qui ne spécifient pas d'ID de version. Ces requêtes mettent à jour les balises de la dernière clé (ou de la dernière version si le bucket est versionné). Les ingestions normales avec des balises (pas de mises à jour de balisage) sont également répliquées. |
Téléchargements en plusieurs parties et |
Lors de la mise en miroir d'objets téléchargés à l'aide d'un téléchargement en plusieurs parties, le service CloudMirror ne conserve pas les parties. En conséquence, le |
Objets chiffrés avec SSE-C (chiffrement côté serveur avec clés fournies par le client) |
Le service CloudMirror ne prend pas en charge les objets chiffrés avec SSE-C. Si vous tentez d'ingérer un objet dans le bucket source pour la réplication CloudMirror et que la requête inclut les en-têtes de requête SSE-C, l'opération échoue. |
Bucket avec verrouillage d'objet S3 activé |
La réplication n'est pas prise en charge pour les buckets source ou de destination avec le verrouillage d'objet S3 activé. |