Allgemein

Was ist Hetzner Cloud Object Storage?

Mit unserem S3-kompatiblen Object Storage ist es möglich, Daten in einer geschlossenen Umgebung namens "Buckets" zu speichern. Für jeden Bucket kann die Sichtbarkeit individuell festgelegt werden.

Technischer Hintergrund:

Daten (z.B. Textdokumente oder Bilddateien) werden als Objekte gespeichert. Jedes Objekt besitzt die folgenden Informationen:

• Objekt-Schlüssel (eindeutige Identifikation des Objekts)
• Daten (z.B. Bild oder Textdokument)
• System-Metadaten (z.B. Dateityp, Dateigröße)
• Benutzerdefinierte Metadaten (Schlüssel-Wert-Paare, die beim Hochladen des Objekts festgelegt werden und beliebige Zusatzinformationen speichern)
• Attribute (z.B. welche Benutzer (Keys) dürfen das Objekt herunterladen oder löschen)

Das Objekt wird als Ganzes (einschließlich seiner dazugehörigen Daten, Metadaten und Attribute) unter seinem eindeutigen Schlüssel (Namen) auf der Festplatte gespeichert.

Was ist der Unterschied zwischen Buckets (Object Storage) und Cloud Volumes (Block Storage)?

Allgemeine Unterschiede:

Technische Unterschiede:

• Mit Object Storage werden die Daten als ein gesamtes Objekt gespeichert. Es ist nicht möglich, das Objekt anschließend zu bearbeiten. Bei Änderungen wird ein neues Objekt erstellt.
• Mit Block Storage werden die Daten in mehrere Blöcke geteilt, die separat gespeichert werden. Wenn man auf die Daten zugreift, werden diese zunächst wieder "zusammengesetzt". Wenn man die Daten bearbeitet, werden die betroffenen Blöcke im Dateisystem aktualisiert.

Wird Object Storage ausschließlich über die Hetzner S3 API verwaltet?

Folgende Aktionen werden über unsere Hetzner Console ausgeführt und NICHT über die S3 API:

• S3-Zugangsdaten erstellen
• Schutz Label zu einem Bucket hinzufügen

Für alles andere, also alles Bucket- oder Objekt-bezogene, muss die Hetzner S3 API genutzt werden.

Ist Object Storage an allen Cloud-Standorten verfügbar?

Nein, Object Storage ist aktuell nur in unseren Standorten innerhalb Europas verfügbar, also:

• Nürnberg
• Falkenstein
• Helsinki

Welchen Standort haben meine Daten?

Die gesamten Daten eines Buckets werden in dem von Ihnen ausgewählten Standort gespeichert. In diesem Standort werden die Daten eines Buckets innerhalb desselben Datacenters gespeichert. Die Strom- und Netzwerkinfrastruktur ist mit eingebauter Redundanz für hohe Verfügbarkeit ausgelegt.

Welche Art von Redundanz bietet Object Storage? Wie widerstandsfähig ist das Produkt gegenüber Ausfällen?

Jedes hochgeladene Datenobjekt wird in Segmente aufgeteilt, die auf mehrere Server innerhalb des Clusters verteilt werden. Mithilfe von Erasure Coding kann das System die Datenintegrität selbst dann gewährleisten, wenn bis zu drei Speicherserver ausfallen.

Wie immer kann jedes unserer Produkte nur ein Teil einer sicheren Backup-Strategie sein.

Übersicht unserer Maßnahmen:

Führen Sie irgendeine Art von Verschlüsselung durch? Wie sicher sind meine Daten?

Eine automatische Data-at-Rest-Verschlüsselung von Objekten ist nicht verfügbar. Sie können Ihre Daten beim Hochladen mittels SSE-C verschlüsseln. Dies wird im How-To "Daten mit SSE-C verschlüsseln" erklärt. Ausgetauschte Festplatten werden vor Ort physisch zerstört und verlassen unsere Standorte nie in einer Form, die eine Rekonstruktion der Daten ermöglichen würde.

Warum aktualisieren sich die Daten in der Hetzner Console bezüglich der Gesamtdateizahl und Gesamtgröße nicht sofort nach Änderungen?

Diese Daten werden nicht in Echtzeit abgerufen, daher kann es 15-20 Minuten dauern bis sich diese aktualisieren.

Warum zeigt die Dateiliste in Hetzner Console eine Fehlermeldung an?

Wenn Sie Zugriffsrichtlinien ("access policies") anwenden, die nur ausgewählten Access Keys den Zugriff auf einen Bucket erlauben, kann unser Frontend die Objekte in diesem Bucket nicht mehr abrufen und in der Hetzner Console auflisten, was zu einer Fehlermeldung führt.

Warum sind die Gesamtdateizahl und Gesamtgröße in der Bucket-Übersicht höher als was in der Objekt-Übersicht gelistet wird?

Die Gesamtdateizahl beinhaltet alle Objekte, die Speicher verbrauchen. Es gibt zwei Sonderfälle, die Speicher verbrauchen, in der Objekt-Übersicht allerdings nicht gelistet werden:

• Alte Versionen eines Objektes

• Objekte aus einem mehrteiligen Upload (siehe Amazon S3 Dokumentation), der entweder noch nicht abgeschlossen ist oder abgebrochen wurde

  Übriggebliebene Objekte von abgebrochenen mehrteiligen Uploads können über Lifecycle-Policies automatisch gelöscht werden (siehe diesen FAQ-Eintrag).

Wenn Sie den Verdacht haben, dass die Gesamtdateizahl zu hoch ist, empfehlen wir zu prüfen, ob Ihr Bucket eventuell solche "unsichtbaren Objekte" enthält.

# Alle Versionen listen
mc ls --versions <alias_name>/<bucket_name>
aws s3api list-object-versions --bucket <bucket_name>

# Laufende oder abgebrochene mehrteilige Uploads listen
mc ls --incomplete <alias_name>/<bucket_name>
aws s3api list-multipart-uploads --bucket <bucket_name>

Die Gesamtgröße fasst den insgesamt genutzten Speicher zusammen. Das beinhaltet:

• Alle sichtbaren Objekte
• Alle "unsichtbaren" Objekte

Die Abrechnung erfolgt auf Basis der Gesamtgröße. Beachten Sie, dass bei der Abrechnung auch Metadaten berücksichtigt werden, da diese ebenfalls Speicherplatz verbrauchen.

Welche Konfigurations- und Sicherheitsfeature werden aktuell unterstützt?

Welche TLS-Protokolle und Cipher Suites werden von der API unterstützt?

*TLS Version 1.2 ist veraltet und wir werden die Unterstützung dafür in naher Zukunft einstellen. Bitte stellen Sie Ihre Anwendungen so bald wie möglich auf TLS Version 1.3 um.

Werden AWS SDKs und AWS CLI unterstützt?

Ja Sie können Ihre Buckets mit AWS CLI und AWS SDKs verwalten, wie zum Beispiel:

• AWS SDK für Python
• AWS SDK für Go
• AWS SDK für .NET

Im Getting Started "Libraries verwenden" finden Sie Beispiel-Konfigurationen für die oben genannten AWS SDKs.

Gibt es verschiedene Speicherklassen wie bei anderen Cloud-Anbietern?

Nein, bisher bieten wir keine verschiedenen Speicherklassen für spezifische Anwendungszwecke (z.B. häufiger Zugriff, seltener Zugriff, Archiv).

Zur Zeit bieten wir nur die Speicherklasse "Standard" an, die auf HDDs basiert.

Sind standortübergreifende Backup-Optionen verfügbar?

Nein es gibt keine eingebaute Funktion, um Bucket-Daten von einem Standort an einen anderen zu replizieren. Sie können die Replikation jedoch manuell einrichten, indem Sie CLI-Tools verwenden, die eine Bucket-zu-Bucket-Synchronisation unterstützen (z.B. rclone). Die Replikation können Sie mit einem Tool wie beispielsweise einem Cron-Job automatisieren.

Werden Open-Source-Projekte, die Hetzner Object Storage unterstützen, durch Credits oder auf andere Weise gewürdigt?

Ja! Wir schätzen jeden Beitrag und finden es wichtig, dass möglichst viele von bereits entwickelten Lösungen profitieren können. Aus diesem Grund finden Sie hier eine Liste an Bibliotheken von verschiedenen Entwicklern: github.com/hetznercloud/awesome-hcloud.

Hinweis: Credits werden ausschließlich an Projekte für Hetzner-spezifische Funktionen oder Erweiterungen vergeben. Unser Object Storage, zum Beispiel, verwendet die standardmäßige S3-API ohne Hetzner-spezifische Erweiterungen. Projekte für allgemeine S3-Funktionen (z. B. allgemeine S3-Clients oder SDKs) werden nicht als Hetzner-spezifisch angesehen und sind daher nicht für Hetzner Credits berechtigt.

Wenn Sie an einem Open-Source-Projekt arbeiten, das unseren S3-kompatiblen Object Storage unterstützt oder künftig unterstützen soll, könnten Sie Anspruch auf einen einmaligen Credit von bis zu 50 € bekommen. Kontaktieren Sie uns über die Support-Seite in der Hetzner Console und teilen Sie uns Folgendes mit:

• Den Namen des Projekts, an dem Sie arbeiten
• Eine kurze Beschreibung des Projekts
• Link zur Projekt-Website oder dem Repository, wo das Projekt gehostet wird
• Zugehörigkeit zu / Rolle im Projekt (z. B. Maintainer des Projeks)
• Link zu bisherigen Open-Source-Projekten von Ihnen (falls vorhanden)

Wo kann ich eine Support-Anfrage stellen?

Zu Themen, die sich direkt auf unser Object Storage Produkt beziehen, können Sie Support-Anfragen über die Hetzner Console erstellen. Beachten Sie, dass wir für das Konfigurieren einzelner Anwendungen keinen Support bieten. Wenn Sie einen Fehler oder ein Problem bezüglich unseres Produkts melden möchten, geben Sie bitte folgende Informationen an, damit wir das Problem bestmöglich prüfen können:

• Für Probleme in der Hetzner Console: ein Screenshot der entsprechenden Seite.
• Für Probleme mit Anwendungen oder CLI-Tools wie s3cmd, mc, usw.: einen Auszug aus der Debug-Ausgabe mit relevanten Fehlermeldungen, evtl. Logdateieinträge, die uns helfen könnten, den Fehler einzugrenzen.
• Bei Problemen mit bestimmten Buckets: die Bucket-ID (nicht den Namen!) — diese finden Sie in der URL der Hetzner Console: wählen Sie innerhalb Ihres Projektes "Object Storage" aus und klicken Sie anschließend auf den Namen Ihres Buckets, um den Bucket-Überblick zu öffnen. Die URL in der Adressleiste des Browsers enthält die Bucket-ID:

  https://console.hetzner.com/projects/<project-id>/buckets/<bucket-id>/overview

• Zur Meldung von Bandbreiten- oder Latenzproblemen: die Ausgabe von den Befehlen, die unter dem Troubleshooting-Eintrag "Bandbreiten- oder Latenzprobleme" erklärt werden.
• Für Test-API-Anfragen, die das Problem reproduzieren: Logeinträge mit Zeitstempel (einschließlich Zeitzone), Quell-IP, vollständiger Anfrage-URI, HTTP-Statuscode und - falls verfügbar - die Antwortzeit.

Wo kann ich allgemeine Fragen diskutieren?

Allgemeine Fragen und Themen, die sich auf unser Object Storage beziehen, können Sie in diesem Forum diskutieren:

• Object Storage

Bitte teilen Sie keine persönlichen Daten. Wenn Sie einen Screenshot teilen, anonymisieren Sie persönliche Daten wie Ihre Kundennummer bitte bevor Sie den Screenshot posten.

Posten Sie aus Sicherheitsgründen niemals Ihren Access Key oder Secret Key!

Kann ich Objekte über HTTP auch für eine große Anzahl von Clients direkt bereitstellen?

Object Storage unterstützt das Teilen von Daten direkt über öffentliche URLs, was sich für kleinere Anwendungsfälle eignet. Für größere Anwendungsfälle, in welchen die Daten über HTTP direkt an tausende Clients ausgeliefert werden, sind Buckets allerdings nicht geeignet, da sie nicht die benötigte niedrige Latenz und globale Abdeckung bieten.

Für Anwendungsfälle wie die Bereitstellung von Bildern, Videos oder anderen statischen Inhalten an ein großes Publikum empfehlen wir die Verwendung eines Content Delivery Network (CDN) vor dem Object Storage.

Ein CDN speichert Objekte im Cache von Edge-Servern, die über verschiedene geografische Standorte verteilt sind, sodass Clients Inhalte von Standorten in ihrer Nähe abrufen können. Dies verbessert die Latenz erheblich, reduziert die Last auf dem Object Storage Bucket und sorgt insgesamt für bessere Leistung. In diesem Setup fungiert der Object Storage Bucket als "Origin", und das CDN ruft die Objekte bei Bedarf von dort ab.

Weitere Informationen bezüglich Content Delivery Network (CDN) finden Sie in diesem Docs-Eintrag.

Vereinfachte Beispiel-Visualisierung:

Warum schlagen meine Uploads fehl? Warum ist Object Storage manchmal langsam oder reagiert nicht?

Da es sich bei unserem Object Storage um ein Produkt mit gemeinsam genutzten Ressourcen handelt, können die Nutzungsmuster einzelner Kunden Auswirkungen auf den gesamten Cluster haben. Insbesondere ressourcenintensive Workloads (zum Beispiel mit einer hohen Anzahl gleichzeitiger Anfragen, einer konstant hohen Auslastung oder ungewöhnlichen Zugriffsmustern) können zu Engpässen führen. Diese können wiederum lange Antwortzeiten oder Zeitüberschreitungsfehler zur Folge haben.

In unserer FAQ "In welchen Anwendungsfällen und für welche Workloads ist Object Storage besonders gut geeignet?" finden Sie Hinweise zu geeigneten Anwendungen und Workloads sowie zu den Nutzungsmustern, die vermieden werden sollten.

Unsere Speichercluster sind in den letzten Monaten schneller gewachsen als ursprünglich geplant. Wir reagieren auf dieses Wachstum, indem wir an jedem Standort zusätzliche Speichercluster in Betrieb nehmen. Neu erstellte Buckets werden dort abgelegt, während bestehende Buckets weiterhin auf den bestehenden Clustern wachsen.

Um zu vermeiden, dass kritische Auslastungsgrenzen überschritten werden, migrieren wir regelmäßig Buckets zwischen den Clustern. Eine Überschreitung dieser Grenzen kann zu Leistungseinbußen und Problemen wie Zeitüberschreitungen führen.

Da Bucket-Migrationen aufgrund des Datenvolumens einige Zeit in Anspruch nehmen, werden Verbesserungen nach der Aktivierung eines neuen Clusters nicht sofort spürbar sein.

Unser Hauptaugenmerk liegt darauf, an allen Standorten so schnell wie möglich weitere Cluster in Betrieb zu nehmen, um die Auslastung wieder auf ein stabiles Niveau zu bringen.

Wir haben einige vorübergehende Maßnahmen ergriffen und arbeiten zudem an einer Reihe von zukünftigen Verbesserungen, um die Situation zu entschärfen.

Als kurzfristige Maßnahme haben wir in NBG vorübergehende Beschränkungen eingeführt, die sowohl die maximale Upload-Geschwindigkeit als auch die Anzahl gleichzeitiger Anfragen reduzieren. Werden diese Grenzen überschritten, gibt der Cluster einen 503-Fehler zurück. S3-Clients ohne Wiederholungslogik brechen den Upload an dieser Stelle ab.

Wir arbeiten außerdem daran, in Zukunft die Möglichkeit zu schaffen, Limits mit einer feineren Granularität festzulegen. So können wir einzelne Buckets mit unverhältnismäßig hoher Auslastung gezielt begrenzen, ohne andere Kunden im selben Cluster zu beeinträchtigen.

Wir entwickeln einen Mechanismus, der Vorgänge, die den Cluster besonders stark belasten (z. B. Uploads, Löschungen und hohe Anfragemengen), priorisiert in Warteschlangen einordnet, damit diese bei Spitzenauslastung ohne Zeitüberschreitungen oder Fehler verarbeitet werden können.

Darüber hinaus gibt es eine lange Liste weiterer Maßnahmen, z. B. Verbesserungen bei der Überwachung, um Probleme einfacher und schneller zu beheben, sowie eine noch stärkere Automatisierung der Betriebsabläufe.

In welchen Anwendungsfällen und für welche Workloads ist Object Storage besonders gut geeignet?

Unser Object-Storage-Dienst ist eine hochskalierbare und kostengünstige Lösung für die Speicherung großer Datenmengen. Der Zugriff erfolgt über eine S3-kompatible Schnittstelle, wodurch eine umfassende Kompatibilität mit modernen Anwendungen und Tools gewährleistet ist.

Obwohl S3 für vielfältige Anwendungsfälle weit verbreitet ist, eignet sich unsere spezifische Implementierung nicht für alle Szenarien. Dies liegt in erster Linie an der HDD-basierten Architektur unserer Speichercluster, die sich von schnelleren Flash-basierten Systemen unterscheidet.

Object Storage eignet sich am besten für:

• Backups und Archivierung: Die langfristige Aufbewahrung von Daten, auf die nur selten zugegriffen wird, wie z. B. Datenbank-Backups, Log-Archive oder Snapshots.
• Speicherung statischer Inhalte: Bilder, Videos, Dokumente oder andere Mediendateien, die von einer Anwendung in mäßigem Umfang gespeichert und abgerufen werden.
• Softwareverteilung: Container-Images, Binärdateien oder Update-Pakete, die regelmäßig hochgeladen und bei Bedarf heruntergeladen werden.
• Cold- und Warm-Storage: Daten, die nicht in Echtzeit benötigt werden, aber jederzeit zugänglich bleiben sollen.
• Disaster Recovery: Sekundärer Speicher für Replikations- und Wiederherstellungszwecke, um die Datenverfügbarkeit im Falle eines Ausfalls sicherzustellen.

Object Storage eignet sich weniger für:

• Anwendungen mit häufigen Lese- und Schreibvorgängen, die pro Sekunde Tausende kleiner Dateien schreiben oder lesen (z. B. Datenbanken, Transaktionssysteme). Diese sollten stattdessen Block- oder Dateispeicher verwenden.
• Große Mengen sehr kleiner Dateien: Das häufige Speichern vieler kleiner Dateien ist ineffizient und belastet den Dienst unverhältnismäßig stark.
• Latenzempfindliche Anwendungen: Object Storage ist nicht für Anwendungen ausgelegt, die Antwortzeiten im einstelligen Millisekundenbereich erfordern.
• Direkte Datenbanknutzung: Object Storage ersetzt keine relationale oder NoSQL-Datenbank und sollte nicht als primärer Datenspeicher für Anwendungen verwendet werden.

Dieser Dienst ist kein CDN

Unser Object-Storage-Dienst ist in erster Linie für die Speicherung und den Abruf von Daten optimiert. Er ist nicht dafür ausgelegt, als Content Delivery Network (CDN) zu fungieren. Die Bereitstellung großer Mengen statischer Inhalte direkt an Endnutzer über Object Storage führt zu einer schlechten Leistung und kann die Infrastruktur überlasten. Um Inhalte mit geringer Latenz an ein großes Publikum bereitzustellen, nutzen Sie bitte einen dedizierten CDN-Dienst vor Ihrem Object-Storage-Bucket.

Empfehlungen für eine optimale Nutzung

Um eine stabile Leistung für alle Nutzer zu gewährleisten, empfehlen wir folgende Nutzungsmuster:

• Dateigrößen: Der Dienst ist für Dateien ab ca. 1 MB optimiert. Wenn möglich, sollten sehr kleine Dateien gebündelt oder als Archive hochgeladen werden.
• Zugriffshäufigkeit: Kontinuierliche, hochfrequente Massenzugriffe sollten vermieden werden. Ideal ist ein gleichmäßiges und moderates Zugriffsmuster anstelle kurzer Spitzen mit extremer Auslastung.
• Multipart-Upload: Für Dateien, die größer als 100 MB sind, empfehlen wir dringend die Verwendung von Multipart-Uploads. Dies verbessert die Übertragungsgeschwindigkeit und die Zuverlässigkeit des Uploads erheblich.
• Lebenszyklusrichtlinien: Verwenden Sie Lebenszyklusregeln, um veraltete oder nicht mehr benötigte Daten automatisch zu löschen. Dies hält Ihren Speicher übersichtlich und hilft, unnötige Kosten zu vermeiden.
• Parallelität: Bevorzugen Sie mehrere moderate parallele Anfragen anstelle einiger weniger sehr großer sequenzieller Anfragen. Dies nutzt die zugrunde liegende Infrastruktur effizienter und führt zu einer besseren Gesamtleistung.

Kurz gesagt

Object Storage bietet die beste Leistung, wenn Daten geschrieben und abgerufen werden, und nicht, wenn sie ständig geändert oder in Echtzeit verarbeitet werden. Wenn Sie sich dieser Unterscheidung bewusst sind, können Sie einen zuverlässigen, skalierbaren und kostengünstigen Speicherdienst optimal nutzen, der auch langfristig leistungsfähig bleibt.