Kas yra Garage S3 ir kam jo reikia?
Jei kada nors bandėte susikurti savo debesų saugyklą arba tiesiog ieškojote alternatyvos AWS S3, tikriausiai susidūrėte su problema: dauguma sprendimų arba per daug sudėtingi, arba reikalauja ištisų serverių parko. Čia į sceną įžengia Garage S3 – self-hosted objektų saugykla, kuri nuo pat pradžių buvo kuriama su mintimi, kad ne visi turime Google ar Amazon resursus.
Garage yra atviro kodo projektas, kuris įgyvendina S3 API protokolą. Tai reiškia, kad bet kuri programa, kuri moka dirbti su Amazon S3, be jokių pakeitimų veiks ir su Garage. Tai gana didelis privalumas, nes nereikia perašinėti aplikacijų ar keisti deployment procesų.
Projektas gimė iš praktinio poreikio – Deuxfleurs kolektyvas (prancūzų entuziastų grupė) norėjo turėti patikimą saugyklą savo paslaugoms, bet neturėjo nei biudžeto dideliems serveriams, nei noro prižiūrėti sudėtingus Ceph ar MinIO klasterius. Taip atsirado Garage – sistema, kuri puikiai veikia net su senais kompiuteriais, Raspberry Pi ar pigiais VPS serveriais.
Architektūra be galvos skausmo
Vienas įdomiausių Garage aspektų – jo architektūra. Kūrėjai atsisakė tradicinio master-slave modelio ir pasirinko pilnai decentralizuotą peer-to-peer struktūrą. Kiekvienas Garage node’as yra lygiavertis, nėra jokio „pagrindinio” serverio, kurio gedimas paralyžuotų visą sistemą.
Sistema naudoja consistent hashing algoritmą duomenų paskirstymui tarp node’ų. Kai įkeliamas failas, jis automatiškai replikuojamas į kelis node’us (pagal numatytus nustatymus – tris). Bet čia įdomiausia dalis: Garage naudoja conflict-free replicated data types (CRDTs) metaduomenims saugoti. Tai reiškia, kad net jei du node’ai vienu metu atnaujina tą patį objektą, sistema gali automatiškai išspręsti konfliktą be žmogaus įsikišimo.
Tokia architektūra leidžia Garage veikti net su nestabiliais tinklo ryšiais. Jei vienas node’as atsijungia ir vėliau prisijungia atgal, sistema automatiškai susinchronizuoja. Tai ypač naudinga, kai kuriate geografiškai paskirstytą saugyklą arba naudojate namų interneto ryšį su dinaminiu IP.
Diegimas: paprasčiau nei tikėjotės
Vienas dalykas, kuris maloniai nustebino – Garage diegimas tikrai nėra raketų mokslas. Sistema parašyta Rust kalba, o tai reiškia vieną statiškai sukompiliuotą binary failą be jokių priklausomybių. Tiesiog atsisiunčiate, suteikiate vykdymo teises ir paleidžiate.
Štai kaip atrodo bazinė konfigūracija:
„`toml
metadata_dir = „/var/lib/garage/meta”
data_dir = „/var/lib/garage/data”
replication_mode = „3”
rpc_bind_addr = „[::]:3901”
rpc_public_addr = „192.168.1.10:3901”
rpc_secret = „jūsų-labai-slaptas-raktas”
[s3_api]
s3_region = „garage”
api_bind_addr = „[::]:3900”
[s3_web]
bind_addr = „[::]:3902”
root_domain = „.web.garage.localhost”
„`
Konfigūracija gana aiški. metadata_dir ir data_dir nurodo, kur saugoti duomenis. replication_mode = "3" reiškia, kad kiekvienas objektas bus saugomas trijuose skirtinguose node’uose. RPC nustatymai reikalingi node’ų tarpusavio komunikacijai, o S3 API sekcija apibrėžia, kaip aplikacijos galės prisijungti prie saugyklos.
Paleidus pirmą node’ą, galite pridėti daugiau serverių paprasčiausiai nurodant tą patį rpc_secret ir paleisdami Garage kitose mašinose. Sistema automatiškai aptiks naujus node’us ir pradės paskirstyti duomenis.
Kaip tai veikia realiame gyvenime
Teorija teorija, bet kaip Garage elgiasi praktikoje? Testavau sistemą su trimis skirtingais scenarijais: vieno serverio setup’u, trimis VPS serveriais skirtinguose duomenų centruose ir hibridine konfigūracija su vienu dedikuotu serveriu ir dviem Raspberry Pi.
Vieno serverio variantas veikia puikiai backup’ams ar asmeniniam naudojimui, bet prarandate visus distributed storage privalumus. Jei serveris nukrista – prarandate prieigą prie duomenų. Nors Garage ir leidžia tokį setup’ą, tai prieštarauja visos sistemos filosofijai.
Trijų VPS variantas parodė geriausią stabilumą. Serveriai buvo Vokietijoje, Prancūzijoje ir Olandijoje, kiekvienas su 2GB RAM ir 50GB SSD. Latency buvo priimtinas – maždaug 50-100ms tarp node’ų. Failų įkėlimas ir parsisiuntimas veikė sklandžiai, o kai vienas serveris buvo išjungtas maintenance’ui, sistema toliau veikė be jokių problemų.
Hibridinis variantas su Raspberry Pi buvo įdomus eksperimentas. Nors Pi 4 su 4GB RAM puikiai susidoroja su Garage, namų interneto upload greitis tapo bottleneck’u. Bet kaip geografiškai paskirstytos backup sistemos dalis – veikia puikiai.
Našumo klausimai ir optimizavimas
Garage nėra greičiausias objektų saugojimo sprendimas rinkoje. Ir tai normalu – sistema optimizuota ne maksimaliam throughput’ui, o stabilumui ir paprastumui. Bet tai nereiškia, kad ji lėta.
Vieno failo įkėlimo greitis priklauso nuo kelių faktorių: tinklo greičio tarp node’ų, diskų greičio ir replication mode. Su replication_mode = "3" failas turi būti įrašytas į tris skirtingas vietas, todėl greitis bus apribotas lėčiausio node’o. Jei naudojate SSD diskus ir gerą tinklą, galite tikėtis 50-100 MB/s greičio.
Smulkių failų (mažesnių nei 1MB) apdorojimas yra šiek tiek lėtesnis nei didelių. Tai būdinga daugumai distributed sistemų dėl metadata overhead’o. Jei planuojate saugoti daug smulkių failų, apsvarstykite galimybę juos supakuoti į archyvus prieš įkeliant.
Vienas praktiškų patarimų – naudokite SSD diskus metadata directory. Metadata operacijos vyksta dažnai, ir HDD latency gali tapti problema. Patiems duomenims HDD puikiai tinka, ypač jei saugote didelius failus kaip video ar backup’us.
Saugumo aspektai
Garage palaiko standartinę S3 autentifikaciją su access key ir secret key. Tai reiškia, kad visos įprastos S3 bibliotekos ir įrankiai veiks iš karto. Galite sukurti kelis raktu poras skirtingiems naudotojams ar aplikacijoms ir suteikti jiems prieigą tik prie konkrečių bucket’ų.
Duomenų šifravimas yra jūsų atsakomybė. Garage pats duomenų nediskinėje nešifruoja – jie saugomi tokia forma, kokia buvo įkelti. Jei norite šifravimo, turite arba naudoti client-side encryption (užšifruoti prieš įkeliant), arba pasikliauti disk encryption sprendimais kaip LUKS.
TLS/SSL palaikymui rekomenduoju naudoti reverse proxy kaip Nginx ar Caddy. Garage gali dirbti su HTTPS tiesiogiai, bet praktikoje paprasčiau ir lankstičiau yra turėti proxy, kuris tvarko sertifikatus ir galite lengvai pridėti rate limiting ar kitas apsaugos priemones.
Vienas svarbus security aspektas – rpc_secret raktas. Jis naudojamas node’ų tarpusavio autentifikacijai. Jei kas nors sužinos šį raktą, galės pridėti savo node’ą į jūsų klasterį. Todėl pasirinkite stiprų atsitiktinį raktą ir saugokite jį kaip root slaptažodį.
Integracijos ir ekosistema
Kadangi Garage implementuoja S3 API, jis veikia su didžiule ekosistema įrankių ir bibliotekų. AWS CLI, boto3 (Python), aws-sdk (JavaScript), Cyberduck, rclone – visa tai veikia iš karto arba su minimaliomis konfigūracijos korekcijomis.
Pavyzdžiui, rclone konfigūracija atrodo taip:
„`ini
[garage]
type = s3
provider = Other
access_key_id = jūsų_access_key
secret_access_key = jūsų_secret_key
endpoint = http://jūsų-serveris:3900
„`
Ir viskas. Dabar galite naudoti rclone sync, rclone mount ar bet kurią kitą rclone komandą su Garage.
Ypač įdomus use case – naudoti Garage kaip backend’ą Nextcloud External Storage. Tai leidžia atskirti failų saugojimą nuo Nextcloud logikos, o Garage klasteris pasirūpina replikacija ir atsparumu gedimams.
Kitas populiarus scenarijus – static website hosting. Garage palaiko S3 static website funkciją, todėl galite hostainti statinius puslapius tiesiogiai iš bucket’ų. Tai puikus variantas Jekyll, Hugo ar kitų static site generatorių output’ui.
Kai kas negerai: troubleshooting
Nors Garage yra gana stabilus, kartais kyla problemų. Dažniausia – node’ai neaptinka vienas kito. Paprastai tai tinklo konfigūracijos problema: firewall’ai blokuoja 3901 portą arba rpc_public_addr nurodytas neteisingai.
Patikrinti node’ų būseną galite su garage status komanda. Ji parodys visus klasterio node’us, jų būsenas ir duomenų paskirstymą. Jei matote node’ą su „Unavailable” statusu, bet žinote, kad jis veikia – tikrinkite tinklo ryšį.
Kita dažna problema – duomenų balansas. Kai pridedamas naujas node’as, duomenys automatiškai nepersiskirsto. Reikia rankiniu būdu paleisti rebalansavimą su garage layout assign ir garage layout apply komandomis. Tai gali užtrukti, priklausomai nuo duomenų kiekio.
Jei node’as visiškai žlunga ir nebepasiekiamas, galite jį pašalinti iš klasterio su garage layout remove. Sistema automatiškai perreplikuos duomenis į likusius node’us. Bet atminkite: jei prarandate daugiau node’ų nei leidžia replication mode, prarasite duomenis. Su replication_mode = "3" galite prarasti du node’us ir vis dar turėti visus duomenis.
Ar Garage jums tinka?
Po kelių mėnesių naudojimo galiu pasakyti, kad Garage yra puikus sprendimas tam tikroms nišoms. Jei ieškote paprastos, patikimos objektų saugyklos, kuri veikia su pigiais serveriais ar namų įranga – Garage tikrai vertas dėmesio. Tai ypač aktualu hobistams, mažoms organizacijoms ar tiems, kas nori išvengti vendor lock-in su dideliais cloud provideriais.
Tačiau Garage nėra universalus sprendimas. Jei jums reikia maksimalaus našumo ar labai specifinių S3 funkcijų, galbūt turėtumėte žiūrėti į MinIO ar net tikrą AWS S3. Garage API palaikymas yra geras, bet ne 100% – kai kurios retesnės S3 funkcijos nepalaikomos.
Projektas aktyviai vystomas, dokumentacija yra gera (nors galėtų būti daugiau praktinių pavyzdžių), o community, nors ir nedidelė, yra draugiška ir nori padėti. Jei susiduriate su problema, GitHub issues paprastai sulaukia atsakymo per kelias dienas.
Galiausiai, Garage filosofija – paprastumas ir patikimumas virš maksimalaus našumo – yra gaivus vėjo gūsis šiuolaikinėje technologijų erdvėje, kur viskas tampa vis sudėtingiau. Kartais jums tikrai nereikia Kubernetes klasterio su 50 mikroservisų, kad saugotumėte failus. Kartais pakanka trijų pigių serverių ir Garage.
