Erfahren Sie mehr über Plattformdienste für StorageGRID
Änderungen vorschlagen
PDFs
Bevor Sie Plattformservices implementieren, sollten Sie sich die Übersicht und die Überlegungen zur Verwendung dieser Services ansehen.
Informationen zu S3 finden Sie unter "S3-REST-API VERWENDEN".
Überblick über die Plattform-Services
Die StorageGRID Plattform-Services unterstützen Sie bei der Implementierung einer Hybrid-Cloud-Strategie, da Sie Ereignisbenachrichtigungen und Kopien von S3 Objekten und Objekt-Metadaten an externe Ziele senden können.
Da der Zielspeicherort für Plattformservices normalerweise außerhalb Ihrer StorageGRID-Implementierung liegt, erhalten Sie bei Plattform-Services die Leistung und Flexibilität, die sich aus der Nutzung externer Storage-Ressourcen, Benachrichtigungsservices und Such- oder Analyseservices für Ihre Daten ergibt.
Für einen einzelnen S3-Bucket kann jede beliebige Kombination von Plattformdiensten konfiguriert werden. Beispielsweise lässt sich sowohl die "CloudMirror Service" als auch die "Benachrichtigungen" auf einem StorageGRID S3-Bucket konfigurieren, sodass bestimmte Objekte in den Amazon Simple Storage Service (S3) gespiegelt werden, während gleichzeitig eine Benachrichtigung über jedes dieser Objekte an eine Drittanbieter-Überwachungsanwendung gesendet wird, um die AWS-Kosten nachzuverfolgen.
|
Die Nutzung von Plattformdiensten muss für jedes Mandantenkonto durch einen StorageGRID-Administrator aktiviert werden, der den Grid Manager oder die Grid Management API verwendet. |
Die Konfiguration von Plattform-Services
Plattformdienste kommunizieren mit externen Endpunkten, die Sie mithilfe der"Mandanten-Manager" oder die"Mandantenmanagement-API" . Jeder Endpunkt stellt ein externes Ziel dar, beispielsweise einen StorageGRID S3-Bucket, einen Amazon Web Services-Bucket, ein Amazon SNS-Thema, einen Webhook-Endpunkt oder einen Elasticsearch-Cluster, der lokal, auf AWS oder anderswo gehostet wird.
Nachdem Sie einen externen Endpunkt erstellt haben, können Sie einen Plattformdienst für einen Bucket aktivieren, indem Sie dem Bucket eine XML-Konfiguration hinzufügen. Die XML-Konfiguration identifiziert die Objekte, auf denen der Bucket handeln soll, die Aktion, die der Bucket durchführen sollte, und den Endpunkt, den der Bucket für den Service verwenden sollte.
Sie müssen für jeden Plattformdienst, den Sie konfigurieren möchten, separate XML-Konfigurationen hinzufügen. Beispiel:
-
Wenn alle Objekte, deren Schlüssel mit beginnen, in einen Amazon S3-Bucket repliziert werden sollen
/images, müssen Sie dem Quell-Bucket eine Replizierungskonfiguration hinzufügen. -
Wenn Sie auch Benachrichtigungen senden möchten, wenn diese Objekte im Bucket gespeichert sind, müssen Sie eine Benachrichtigungskonfiguration hinzufügen.
-
Wenn Sie die Metadaten für diese Objekte indizieren möchten, müssen Sie die Benachrichtigungskonfiguration für Metadaten hinzufügen, die zur Implementierung der Suchintegration verwendet wird.
Das Format für die Konfigurations-XML wird durch die S3-REST-APIs geregelt, die zur Implementierung von StorageGRID Plattform-Services verwendet werden:
| Plattform-Service | S3-REST-API | Siehe |
|---|---|---|
Replizierung von CloudMirror |
|
|
Benachrichtigungen |
|
|
Integration von Suchen |
|
Überlegungen bei der Verwendung von Plattform-Services
| Überlegungen | Details |
|---|---|
Ziel-Endpoint-Monitoring |
Sie müssen die Verfügbarkeit jedes Zielendpunkts überwachen. Wenn die Verbindung zum Zielendpunkt über einen längeren Zeitraum unterbrochen wird und ein großer Rückstand von Anfragen besteht, schlagen zusätzliche Clientanforderungen (wie Z. B. PUT-Anforderungen) an StorageGRID fehl. Sie müssen diese fehlgeschlagenen Anforderungen erneut versuchen, wenn der Endpunkt erreichbar ist. |
Drosselung des Zielendpunkts |
StorageGRID kann eingehende S3-Anfragen für einen Bucket drosseln, wenn die Rate, mit der die Anforderungen gesendet werden, die Rate übersteigt, mit der der Zielendpunkt die Anforderungen empfangen kann. Eine Drosselung tritt nur auf, wenn ein Rückstand von Anfragen besteht, die auf den Zielendpunkt warten. Der einzige sichtbare Effekt besteht darin, dass die eingehenden S3-Anforderungen länger in Anspruch nehmen. Wenn Sie die Performance deutlich schlechter erkennen, sollten Sie die Aufnahmerate reduzieren oder einen Endpunkt mit höherer Kapazität verwenden. Falls der Rückstand von Anforderungen weiterhin wächst, scheitern Client-S3-Vorgänge (wie Z. B. PUT-Anforderungen) letztendlich. CloudMirror-Anforderungen sind wahrscheinlicher von der Performance des Zielendpunkts betroffen, da diese Anfragen in der Regel mehr Datentransfer beinhalten als Anfragen zur Suchintegration oder Ereignisbenachrichtigung. |
Bestellgarantien |
StorageGRID garantiert die Bestellung von Vorgängen an einem Objekt innerhalb eines Standorts. Solange sich alle Vorgänge für ein Objekt innerhalb desselben Standorts befinden, entspricht der endgültige Objektstatus (für die Replizierung) immer dem Status in StorageGRID. StorageGRID unternimmt alle Anstrengungen, Anfragen zu bestellen, wenn die Vorgänge an verschiedenen StorageGRID Standorten durchgeführt werden. Wenn Sie beispielsweise ein Objekt zunächst an Standort A schreiben und später dasselbe Objekt an Standort B überschreiben, ist das von CloudMirror in den Ziel-Bucket replizierte Objekt nicht garantiert, dass es sich um das neuere Objekt handelt. |
ILM-gesteuerte Objektlöschungen |
Um dem Löschverhalten von AWS CRR und Amazon Simple Notification Service anzupassen, werden CloudMirror- und Ereignisbenachrichtigungsanforderungen nicht gesendet, wenn ein Objekt im Quell-Bucket aufgrund von StorageGRID-ILM-Regeln gelöscht wird. Beispiel: Es werden keine Anfragen für CloudMirror- oder Ereignisbenachrichtigungen gesendet, wenn eine ILM-Regel ein Objekt nach 14 Tagen löscht. Suchintegrationsanfragen werden dagegen gesendet, wenn Objekte aufgrund von ILM gelöscht werden. |
Kafka-Endpunkte werden verwendet |
Für die Authentifizierung von Kafka-Endpunkten werden die folgenden Authentifizierungstypen verwendet. Diese Typen unterscheiden sich von denen, die für die Authentifizierung anderer Endpunkte verwendet werden, z. B. Amazon SNS, und erfordern Benutzername und Kennwort-Anmeldeinformationen.
Hinweis: konfigurierte Speicher-Proxy-Einstellungen gelten nicht für Kafka-Plattform-Services-Endpunkte. |
Überlegungen bei der Verwendung des CloudMirror Replikationsservice
| Überlegungen | Details |
|---|---|
Replikationsstatus |
Der Header wird von StorageGRID nicht unterstützt |
Objektgröße |
Die maximale Größe für Objekte, die vom CloudMirror-Replikationsservice in einen Ziel-Bucket repliziert werden können, beträgt 5 tib. Dies ist die gleiche wie die maximal unterstützte Objektgröße. Hinweis: Die maximale recommended Größe für einen einzelnen PutObject-Vorgang beträgt 5 gib (5,368,709,120 Bytes). Wenn Sie über Objekte mit einer Größe von mehr als 5 gib verfügen, verwenden Sie stattdessen mehrteilige Uploads. |
Bucket-Versionierung und VersionIDs |
Wenn die Versionierung im S3-Quell-Bucket von StorageGRID aktiviert ist, sollten Sie auch die Versionierung für den Ziel-Bucket aktivieren. Bei Verwendung der Versionierung ist zu beachten, dass die Reihenfolge der Objektversionen im Ziel-Bucket vom CloudMirror-Dienst aufgrund von Einschränkungen des S3-Protokolls nach bestem Wissen und Gewissen erfolgt und nicht garantiert wird. Zudem behalten Ziel-Buckets ihre eigenen Einstellungen bei und bieten möglicherweise keine Versionierung an. Hinweis: Versions-IDs für den Quell-Bucket in StorageGRID hängen nicht mit den Versions-IDs für den Ziel-Bucket zusammen. |
Tagging für Objektversionen |
Der CloudMirror-Dienst repliziert keine PutObjectTagging- oder DeleteObjectTagging-Anforderungen, die aufgrund von Einschränkungen im S3-Protokoll eine Versions-ID bereitstellen. Da Versions-IDs für Quelle und Ziel nicht miteinander verknüpft sind, kann nicht sichergestellt werden, dass ein Tag-Update auf eine bestimmte Versions-ID repliziert wird. Im Gegensatz dazu repliziert der CloudMirror-Dienst PutObjectTagging-Anfragen oder DeleteObjectTagging-Anfragen, die keine Versions-ID angeben. Diese Anforderungen aktualisieren die Tags für den aktuellen Schlüssel (oder die aktuellste Version, wenn der Bucket versioniert ist). Normale Missionen mit Tags (keine Tagging-Updates) werden ebenfalls repliziert. |
Mehrteilige Uploads und |
Bei der Spiegelung von Objekten, die mittels eines mehrteiligen Uploads hochgeladen wurden, bleiben die Teile vom CloudMirror-Service nicht erhalten. Daher weicht der |
Mit SSE-C verschlüsselte Objekte (serverseitige Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln) |
Der CloudMirror-Dienst unterstützt keine Objekte, die mit SSE-C verschlüsselt sind. Wenn Sie versuchen, ein Objekt für die CloudMirror-Replikation in den Quell-Bucket aufzunehmen und die Anforderung die SSE-C-Anforderungsheader enthält, schlägt der Vorgang fehl. |
Bucket mit S3-Objektsperre aktiviert |
Wenn für den Quell-S3-Bucket in StorageGRID die S3-Objektsperre aktiviert ist, sollte die S3-Objektsperre auch für den Ziel-Bucket mit konfigurierter Standardaufbewahrung aktiviert werden. Die Replikation von Objektdaten wird für Quell- und Ziel-Buckets mit aktiviertem S3 Object Lock unterstützt. Ziel-Buckets behalten jedoch ihre eigenen Einstellungen für die Objektaufbewahrung bei und bieten möglicherweise keine Compliance oder Versionierung. |