News
ZurückObject Storage: Preissenkung und Praktisches
Bei cloudscale steht pro Standort seit Langem ein S3-kompatibler Object Storage zur Verfügung. Die Kosten richten sich dabei einzig nach der tatsächlichen Belegung und Benutzung des Storage – und sinken per 01.02.2025 spürbar. Erfahre zudem mehr über die technischen Hintergründe und die optimale Nutzung des Object Storage.
Günstigerer Speicherplatz ab 01.02.2025
Die Kosten für den Object Storage werden einmal täglich kurz nach Mitternacht (Zeitzone von Zürich) deinem Guthaben belastet. Dabei setzen sie sich aus drei Komponenten zusammen, nämlich der Anzahl der API-Requests (CHF 0.005 pro 1000 Requests), dem ausgehenden Datenverkehr (CHF 0.02 pro GB, eingehender Traffic ist kostenlos) sowie dem belegten Speicherplatz, wobei hier über den Tag hinweg ein Durchschnittswert ermittelt wird.
Die Komponente für den Speicherplatz macht in den meisten Fällen den grössten Anteil an den Gesamtkosten aus. Der belegte Speicherplatz kostet ab dem 01.02.2025 nur noch CHF 0.001 pro GB und Tag und damit 66% weniger als bisher. Damit wird unser Object Storage noch attraktiver, z.B. für Offsite Backups deiner wichtigen Daten. Wie bisher werden übrigens die drei Kostenkomponenten präzise einzeln berechnet, dann addiert und erst zuletzt auf ganze Rappen aufgerundet, bevor sie deinem Guthaben belastet werden.
Einblicke in die technischen Details
Für unsere Storage-Cluster setzen wir bei cloudscale auf Ceph, dessen S3-kompatible HTTPS-API du direkt unter *.objects.rma|lpg.cloudscale.ch
erreichst – z.B. für den Up- und Download von Objects. Für die Abrechnung konnten wir hingegen nicht auf Ceph-Features zurückgreifen, weshalb wir hier einen eigenen Microservice namens "rgw-metrics" entwickelt haben. rgw-metrics sammelt die Nutzungsdaten unserer Ceph Storage-Cluster und ermöglicht so einerseits die exakte, nutzungsabhängige Abrechnung und andererseits die Anzeige von aktuellen und vergangenen Nutzungsdaten in unserem Cloud Control Panel und via die API.
rgw-metrics läuft unabhängig von der Software, die das Control Panel und die API bereitstellt, und speichert die gesammelten Nutzungsdaten als einen Zeitreihendatensatz. Vor Kurzem haben wir rgw-metrics einem Rewrite unterzogen: Neben einem Wechsel von Flask zu Django, das wir auch anderweitig einsetzen, setzen wir neu auf ein containerisiertes Setup. Ziel der Umstellung ist zudem nicht zuletzt mehr Effizienz. Mehr Einblicke rund um rgw-metrics gibt dir Julian in unserem Engineering Blog.
Nützliche Features des Object Storage
Im einfachsten Fall erstellst du einen Bucket und benutzt dann eines der zahlreichen S3-fähigen Tools, um Objects hoch- und herunterzuladen und am Ende wieder zu löschen. Unser Object Storage eignet sich aber auch für anspruchsvolle Setups, denn Ceph unterstützt eine Vielzahl an S3-Features wie ACLs, Versioning und Policies für individuelle Zugriffsrechte.
Beispiel 1: Zusätzlicher "read-only" Zugang zu deinem Bucket
Um für eine Person oder Anwendung Lesezugriff auf deinen Bucket (z.B. "my-bucket") einzurichten, erstelle via Control Panel oder API einen zusätzlichen Objects User und achte auf die angezeigte "User ID" (z.B. "11111111...88888888"). Erstelle dann eine Datei wie folgt und speichere sie lokal ab, z.B. unter policy.json
:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam:::user/1111111122222222333333334444444455555555666666667777777788888888"},
"Action": ["s3:ListBucket","s3:GetObject"],
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
]
}]
}
Füge nun diese Policy zu deinem Bucket hinzu, z.B. mithilfe des Tools s3cmd
:
s3cmd setpolicy policy.json s3://my-bucket
Der zusätzliche Objects User kann jetzt mit seinen eigenen Credentials (Access Key und Secret Key) die Objects in "my-bucket" auflisten und lesen, nicht jedoch ändern und löschen.
Beispiel 2: CORS-Header konfigurieren
Du kannst Objects öffentlich zugänglich machen, z.B. mittels:
s3cmd --acl-public setacl s3://my-bucket/my-font.woff2
Das Object ist danach – ohne Authentifizierung mit Access Key und Secret Key – direkt abrufbar unter https://my-bucket.objects.lpg.cloudscale.ch/my-font.woff2
.
Beim Einbinden in eine Website – z.B. unter https://www.example.com – kann es aber sein, dass der Browser die Datei aufgrund der "Same-Origin-Policy" nicht lädt. In diesem Fall helfen CORS-Header ("Cross-Origin Resource Sharing"), die du auf deinem Bucket konfigurierst. Erstelle dazu eine Datei wie folgt und speichere sie lokal ab, z.B. unter cors.xml
:
<CORSConfiguration>
<CORSRule>
<AllowedOrigin>https://www.example.com</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
</CORSRule>
</CORSConfiguration>
Übertrage diese Konfiguration dann z.B. mittels s3cmd auf deinen Bucket:
s3cmd setcors cors.xml s3://my-bucket
Bei einem Besuch auf https://www.example.com wird der Browser "testweise" auf https://my-bucket.objects.lpg.cloudscale.ch/my-font.woff2 zugreifen und dabei den HTTP-Header
Origin: https://www.example.com
mitschicken. Stimmt die mitgeschickte URL mit der auf dem Bucket konfigurierten überein, dann fügt der Object Storage in seiner Antwort die Header
access-control-allow-origin: https://www.example.com
access-control-allow-methods: GET
hinzu und signalisiert dem Browser damit, dass das Laden der Datei im Kontext dieser Website erlaubt ist.
Unser Object Storage deckt die unterschiedlichsten Anwendungsfälle ab, als Ablage für deine Offsite Backups genauso wie als Storage-Backend deiner Applikationen oder zum Teilen von Dateien. Ab 01.02.2025 profitierst du zudem von deutlich günstigerem Speicherplatz. Was will man mehr?
"Objekt-orientiert" im besten Sinne,
Dein cloudscale-Team