Storage

Úvod

Storage je rychlé blokové úložiště: pevně velký disk na lokálním NVMe SSD, nezávislý na životním cyklu jednotlivých instancí serverletu — bez síťového skoku, bez sdíleného souborového systému, prostě rychlost lokálního disku.

Patří k projektu, stejně jako serverlet nebo cron, a slouží na data, která musí přežít instanci — instance se běžně obměňují při rolling update nebo škálování, takže cokoliv zapíšete jen na disk instance, nepřežije.

Pod kapotou je to jeden diskový obraz, ať už k němu přistupujete jakkoliv — připojením jako blokové zařízení, nebo přes jeden z protokolů níže. Neexistuje samostatný produkt „blokové” a „objektové” úložiště, jen jedna kapacita dostupná různými cestami.

Vlastnosti

• Změna velikosti — pevná kapacita, nastavená při vytvoření a později změnitelná, až do 256 GiB. Zvětšení proběhne online bez restartu; zmenšení vyžaduje restart a jde jen na aktuálně využitou velikost.
• Veřejná vs. privátní — ve výchozím stavu privátní: dostupná jen z cloud konzole nebo ze serverletu, do kterého je připojená, nikdy přes obyčejné HTTP. Veřejná povolí anonymní čtení přes HTTP; zápis a výpis vždy vyžadují autentizaci. Viz Servírování přes HTTP.
• Připojení do serverletů — připojí se jako blokové zařízení na zvolenou cestu, rychlostí lokálního NVMe, bez síťového skoku. Stejnou storage lze připojit do víc serverletů a instancí zároveň, na stejném i různých serverech v regionu; každý server má vlastní lokální repliku.
• Replikace a konzistence — vždy replikovaná, minimálně dvě instance, jedna na každém serveru, kde je připojená, každá active-active.
  • Multi-writer, multi-reader — master-master, žádný leader.
  • Atomické lokálně — zápis proběhne celý, nebo vůbec, na svém serveru.
  • Asynchronní napříč clusterem — ostatní instance dohánějí s krátkým odstupem.
  • Eventuálně konzistentní — téměř současné zápisy se vyřeší deterministicky (vyhraje pozdější); zpožděná instance na okamžik servíruje starší data.
  • Sebeopravné — konflikty i zpoždění se vyřeší a dohoní samy, bez zásahu.
• Chytré odkládání (smart offloading) — nečinná storage se na pozadí přesune z NVMe na levnější HDD, stále se dvěma kopiemi; často používané soubory zůstávají v cache. Opětovným připojením se plynule vrátí na NVMe.

Protokoly

Ke stejnému disku se dá přistupovat přes několik protokolů — soubor zapsaný jedním způsobem je okamžitě vidět i přes ostatní, s výhradou replikace výše.

• Připojené blokové zařízení — běžný souborový systém přímo z kódu aplikace. Viz Připojení do serverletů.
• Webové rozhraní — procházení, upload, download a správa souborů v administraci.
• Futrou Storage API — vlastní souborové API Futrou.
• Futrou S3 API — S3-kompatibilní endpoint pro existující S3 nástroje a SDK.

Futrou Storage API

Vlastní souborové API Futrou, na /v2/storages/:name/files/..., používá správce souborů v administraci a lze ho volat i přímo:

• Výpis a hledání souborů a složek, s podporou stránkování a hloubky zanoření.
• Download souboru, nebo získání jeho metadat jako JSON.
• Upload nebo přepsání souboru — surové tělo požadavku, multipart/form-data, nebo po částech přes Content-Range.
• Vytvoření složky, přesun nebo přejmenování souboru, smazání souboru nebo složky (na požádání i rekurzivně).

S3-kompatibilní API

Stejný disk je dostupný i jako S3 bucket — namiřte na něj libovolný standardní S3 SDK nebo nástroj pomocí endpointu storage, API tokenu jako access key a jeho secretu jako secret key. Podporováno je AWS Signature Version 4 jak pro požadavky podepsané v hlavičce, tak pro presigned URL, takže nástroje postavené na S3 obvykle fungují beze změny.

Podporované akce:

• ListObjectsV2 — výpis objektů v kořeni bucketu.
• GetBucketLocation
• GetBucketVersioning — vždy vrací verzování jako nezapnuté; viz níže.
• PutBucketVersioning — pro Suspended proběhne jako no-op; Enabled odmítne (viz Nepodporováno).
• ListObjectVersions — každý objekt se objeví jednou, jako svá jediná (null) verze.
• HeadObject, GetObject (včetně Range a podmíněných hlaviček If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since)
• PutObject, CopyObject, DeleteObject, DeleteObjects (hromadné mazání)
• GetObjectAttributes
• CreateMultipartUpload, UploadPart, UploadPartCopy, ListParts, ListMultipartUploads, CompleteMultipartUpload
• Vlastní akce Futrou pro přejmenování (PUT s ?renameObject) — není součástí standardního S3 API, slouží k přesunu objektu bez nutnosti kopírovat a pak mazat.
• ETagy počítané z obsahu objektu a ověření uploadu přes Content-MD5.
• Podepsaná (AWS4-HMAC-SHA256) i presigned-URL autentizace.

Nepodporováno:

• PutBucketAcl / GetBucketAcl, PutObjectAcl / GetObjectAcl — ACL na úrovni bucketu i objektu (NotImplemented).
• PutBucketPolicy / GetBucketPolicy — bucket policies (NotImplemented).
• PutBucketEncryption / GetBucketEncryption — konfigurace server-side šifrování (NotImplemented).
• PutBucketLifecycleConfiguration a lifecycle pravidla objektů (expirace, přechody mezi třídami) — není kam přecházet, protože storage je pod kapotou blokové úložiště, ne vrstvené objektové úložiště.
• PutBucketVersioning s Status=Enabled — každý PUT nahradí aktuální verzi; historie verzí k zapnutí, výpisu ani obnově neexistuje (NotImplemented).

Metadata a hlavičky

Každý objekt si nese metadata vedle vlastního obsahu — pevnou sadu systémových hlaviček: Content-Type, Cache-Control, Content-Disposition, Content-Encoding, Content-Language a Expires, nastavených při uploadu a vracených při každém dalším GET/HEAD. Libovolné uživatelské hlavičky x-amz-meta-* se nezachytávají ani neukládají.

Tato metadata, spolu s cachovaným ETagem a velikostí každého objektu, se ukládají jako malé sidecar soubory ve složce .metadata v kořeni storage, kopírující strukturu objektů — při připojení storage jako blokového zařízení nebo procházení ve webovém rozhraní tuto složku uvidíte vedle svých souborů.

Pokud je .metadata smazána — třeba přímo na připojeném svazku — strukturálně se nic neztratí: každý záznam se znovu vytvoří na požádání, při dalším přečtení daného objektu. ETag a velikost se vždy správně dopočítají ze skutečného obsahu objektu. Vlastní hlavičky nastavené při uploadu tímto způsobem obnovit nelze, protože ze samotného souboru odvodit nejdou — po smazání .metadata tak objekty spadnou na odhadnutý Content-Type a bez vlastních hlaviček, dokud nejsou znovu nahrány nebo dokud jim metadata nejsou nastavena znovu.

Servírování přes HTTP

Veřejnou storage (viz Veřejná vs. privátní) lze připojit přímo k proxy a servírovat přes HTTP rovnou ze storage — bez serverletu v cestě požadavku. Proxy ji servíruje jako statický hosting souborů, se stejnými konvencemi jako S3 static website hosting:

• index.html / index.json — požadavek na cestu adresáře servíruje jeho index.html, pokud existuje, jinak index.json.
• 404.html — vlastní chybová stránka v kořeni storage se servíruje (se stavem 404) pro jakýkoliv chybějící objekt místo syrové chyby API.
• Vlastní hlavičky z metadat — systémové hlavičky výše se posílají s každou odpovědí, takže assety si nesou vlastní cache a content hlavičky.

Díky tomu se storage přirozeně hodí na hosting statického webu nebo servírování statických assetů (obrázky, soubory ke stažení, sestavené frontend buildy) přímo, bez serverletu běžícího jen kvůli servírování souborů.

Případy užití

Data aplikace

Připojte storage do svého serverletu a používejte ji jako normální lokální disk pro cokoliv, co vaše aplikace potřebuje ukládat trvale — uploady, generované soubory, session data, cache, fronty. Toto je běžný případ a výchozí replikovaný režim (dvě a více instancí, asynchronní replikace) je pro něj správnou volbou: zápisy jdou okamžitě na lokální NVMe a data se napříč replikami s krátkým odstupem sjednotí, bez nutnosti replikaci cokoliv spravovat ručně.

Statické weby a assety

Nastavte storage jako veřejnou a připojte ji k proxy, abyste přes ni servírovali statický web nebo statické assety (obrázky, soubory ke stažení, frontend buildy) přímo přes HTTP — vůbec bez serverletu v cestě požadavku. Viz Servírování přes HTTP.

Databáze

Pro vlastní datový adresář databáze replikaci Futrou storage nepoužívejte. Replikace storage je asynchronní a eventuálně konzistentní na blokové úrovni — databázový engine, který zapisuje své soubory, očekává od vlastního úložiště okamžitou, přísnou konzistenci, a dvě nezávisle zapisující repliky stejných databázových souborů se místo bezpečného sloučení navzájem poškodí.

Pro databázi místo toho připojte storage v lokálním režimu: jedna instance, žádná replikace na úrovni storage vůbec. Pokud potřebujete redundanci databáze, řešte ji na úrovni databáze — spusťte vlastní primary/replica (master-slave) replikaci databáze napříč dvěma serverlety, každý s vlastní oddělenou lokální storage, a nechte konzistenci vlastních dat řídit databázový engine.

Oprávnění

Vytvoření, změna velikosti a smazání storage vyžaduje minimálně roli Developer ve workspace; prohlížení a používání dat existující storage je dostupné každé roli, která má přístup do projektu. Co která role umí, viz Role.