Dieser Test ermittelt, ob alle grundlegenden Vorgänge (z. B. Get/Put/Delete) der Objektspeicher-API entsprechend den Anforderungen des mehrstufigen Speichers gut funktionieren. Es handelt sich um einen grundlegenden Test, den jeder Objektspeicherdienst vor den folgenden Tests bestehen sollte. Es handelt sich um einen Aussagetest, der entweder bestanden oder nicht bestanden wird.

Dieser Test ermittelt mit einem Assertivtest, der entweder erfolgreich ist oder fehlschlägt, ob die End-to-End-Tiered-Storage-Funktionalität gut funktioniert. Der Test erstellt ein Testthema, das standardmäßig mit aktiviertem Tiering und stark reduzierter Hotset-Größe konfiguriert ist. Es erzeugt einen Ereignisstrom zum neu erstellten Testthema, wartet darauf, dass die Broker die Segmente im Objektspeicher archivieren, verbraucht dann den Ereignisstrom und überprüft, ob der verbrauchte Strom mit dem erzeugten Strom übereinstimmt. Die Anzahl der an den Ereignisstrom gesendeten Nachrichten ist konfigurierbar, sodass der Benutzer je nach Testbedarf eine ausreichend große Arbeitslast generieren kann. Die reduzierte Hotset-Größe stellt sicher, dass die Abrufe des Verbrauchers außerhalb des aktiven Segments nur aus dem Objektspeicher erfolgen. Dies hilft beim Testen der Richtigkeit des Objektspeichers für Lesevorgänge. Wir haben diesen Test mit und ohne Fehlerinjektion im Objektspeicher durchgeführt. Wir haben einen Knotenausfall simuliert, indem wir den Service Manager-Dienst in einem der Knoten in StorageGRID gestoppt und überprüft haben, ob die End-to-End-Funktionalität mit dem Objektspeicher funktioniert.

Dieser Test validierte die Leseleistung des mehrstufigen Objektspeichers und überprüfte die Range-Fetch-Leseanforderungen unter hoher Last von Segmenten, die durch den Benchmark generiert wurden. In diesem Benchmark hat Confluent benutzerdefinierte Clients entwickelt, um die Tier-Fetch-Anfragen zu erfüllen.

Dieser Test erzeugte durch die Archivierung von Segmenten indirekt eine Schreiblast im Objektspeicher. Die Lesearbeitslast (gelesene Segmente) wurde aus dem Objektspeicher generiert, als Verbrauchergruppen die Segmente abgerufen haben. Diese Arbeitslast wurde durch das Testskript generiert. Dieser Test überprüfte die Leistung beim Lesen und Schreiben im Objektspeicher in parallelen Threads. Wir haben mit und ohne Fehlerinjektion im Objektspeicher getestet, wie wir es für den Korrektheitstest der Tiering-Funktionalität getan haben.

Dieser Test prüfte die Löschleistung eines Objektspeichers unter einer hohen Themenaufbewahrungslast. Der Aufbewahrungsaufwand wurde mithilfe eines Testskripts generiert, das viele Nachrichten parallel zu einem Testthema produziert. Das Testthema war die Konfiguration mit einer aggressiven größen- und zeitbasierten Aufbewahrungseinstellung, die dazu führte, dass der Ereignisstrom kontinuierlich aus dem Objektspeicher gelöscht wurde. Anschließend wurden die Segmente archiviert. Dies führte zu einer großen Anzahl von Löschungen im Objektspeicher durch den Broker und zur Erfassung der Leistung der Löschvorgänge im Objektspeicher.