Ce test détermine si toutes les opérations de base (par exemple GET/PUT/delete) de l'API du magasin d'objets fonctionnent bien selon les besoins du stockage hiérarchisé. C'est un test de base que chaque service de magasin d'objets devrait s'attendre à passer avant les tests suivants. C'est un test d'assurance qui réussit ou échoue.

Ce test détermine si la fonctionnalité de stockage à plusieurs niveaux fonctionne correctement avec un test assertif qui réussit ou échoue. Le test crée un sujet de test qui est configuré par défaut avec le Tiering activé et une taille de groupe de signets très réduite. Il produit un flux d'événements vers le nouveau sujet de test créé, il attend que les courtiers archivent les segments dans le magasin d'objets, puis il utilise le flux d'événements et valide que le flux consommé correspond au flux produit. Le nombre de messages produits au flux d'événements est configurable, ce qui permet à l'utilisateur de générer une charge de travail suffisamment importante en fonction des besoins du test. La taille réduite du hot set garantit que les fetches du consommateur en dehors du segment actif ne sont servies qu'à partir du magasin d'objets ; cela permet de tester l'exactitude du magasin d'objets pour les lectures. Nous avons effectué ce test avec et sans injection de défaut dans le magasin d'objets. Nous avons simulé une panne des nœuds en arrêtant le service Service Manager dans l'un des nœuds de StorageGRID et en validant que la fonctionnalité de bout en bout fonctionne avec le stockage objet.

Ce test a validé les performances de lecture du stockage d'objets hiérarchisés et vérifié les demandes de lecture de plage en charge lourde à partir des segments générés par le banc d'essai. Dans ce banc d'essai, confluent a développé des clients personnalisés pour traiter les demandes d'extraction de niveau.

Ce test a généré indirectement le workload d'écriture sur le magasin d'objets via l'archivage de segments. Le workload de lecture (segments lus) a été généré à partir du stockage objet lorsque les groupes de consommateurs ont extrait les segments. Ce workload a été généré par le script de test. Ce test a vérifié les performances de lecture et d'écriture sur le stockage objet dans les threads parallèles. Nous avons testé avec et sans injection de panne dans le magasin d'objets, comme nous l'avons fait pour le test d'exactitude de la fonctionnalité de Tiering.

Ce test a permis de vérifier les performances de suppression d'un magasin d'objets sous un workload de conservation des rubriques lourd. La charge de travail de rétention a été générée à l'aide d'un script de test qui produit de nombreux messages en parallèle à un sujet de test. La rubrique de test était configurée avec un paramètre de conservation basé sur la taille et le temps agressif qui a provoqué la purge continue du flux d'événements du magasin d'objets. Les segments ont ensuite été archivés. Cela a entraîné de nombreuses suppressions dans le stockage objet par le courtier et la collecte des performances des opérations de suppression du magasin d'objets.