Dotaz: Jaký objektový storage?

[Max]

Ahoj,
potřebujeme ukládat relativně velké množství dat (včetně metadat). Aktuální stav je asi 20 milionů souborů různé velikosti. Většinou mají soubory pár MiB, ale začínají se objevovat i ty, co mají i přes GiB. Celková velikost DB (soubory jsou v ní) je 10TB. Lze tedy předpokládat velikost raw dat cca 6TB. Objem dat samozřejmě roste čím dál víc rychleji,

Opravdu jde čistě o ukládání a čtení dat a metadat. Nic víc.
Myslím si, že objektová storage je na toto přesně dělaná. Zatím jsem v režimu průzkumu. Má někdo nějaké reálné zkušenosti s něčím podobným? Mohl by někdo nějaké řešení objektového storage doporučit?

Někdo třeba poradí Ceph, ale to mi trochu přijde jako zbytečně big řešení. Myslel jsem, že bychom si do začátku úplně v klidu vystačili s něčím, co jede active-pasive. Prostě jeden primár a jedna replika. V případě Cephu bych musel udržovat minimálně 4 nody, spíše více. To je podle mně asi overkill.
Díval jsem se i na další řešení (např. OpenStack Swift), ale jak člověk nemá zkušenosti, tak testovat vše mi přijde zbytečně časově náročné.
Pokud tedy máte někdo zkušenosti, tak bych byl vděčný za tip/info.
Díky
Zdar Max

Odpovědi

[Josef Kufner]

Napadá mne Gitaly, ale nemám s tím žádnou zkušenost a možná se to vůbec nebude hodit. Gitlab to používá na ukládání repozitářů a dat tam také mají celkem hodně.

[Heron]

Osobně mám nejlepší zkušenosti s PostgreSQL a typem BYTEA. Ano, má to limit na 1GB per záznam, takže pro větší soubory je potřeba to vhodně ošetřit, což není problém. Ukládám unikátní objekty (podle sha512). V produkci máme něco podobného, jen z historických důvodů v BLOBech (proti tomu bych měl pár poznámek). Na nic lepšího jsem nepřišel.

Měl jsem ještě v todo se mrknout na MongoDB, které má interní GridFS. Mongo by mělo jít snadněji replikovat a shardovat, než ten PG (kde je celkem jednoduché nastavit klasickou master-slave replikaci, ale nic moc složitějšího, pokud nad tím není proxy, která si to řeší sama). Jenže Mongo mezitím změnilo licenci, takže tím to pro mě padá.

Jinak záleží, na co to chcete. Jestli jen na vkládání souborů (spisů) do db s metadaty pro vyhledávání, tak bych fakt nehledal nic složitého a nechal si to napsat od vývojářů nad nějakou DB. To už nejspíš máš. Ošetřit věci jako omezenou velikost záznamu je totiž většinou jednodušší, než se prát s něčím jako je ceph.

[Max]

My to teď máme taky v DB a v BLOBech (Oracle), ale je to docela pomalý. Navíc je to řešení, které opět psala nějaká firma a asi už ukončili i vývoj.
A nějak si nejsem jist, zda by taková db šla nějak dobře škálovat do budoucna. Teď máme sice jen 20mega souborů v 6TB, ale to neznamená, že za dva roky to nebude třeba už dvojnásobek.
A ty hotové řešení mají většinou i nějaké standardizované API (S3 apod.).
Rád bych šel nějakým systémovým řešením a nesnažil se vymýšlet kolo.
Zdar Max

[Heron]

Ok, píšu jen svoje zkušenosti, nic nevnucuju. Jaký problém s rychlostí? PG nemá problém saturovat disk a limitujícím faktorem je spíše síť (pokud nemáte 100GbE nebo 40GbE síť, tak disky jsou vždy rychlejší). Navíc PG to automaticky komprimuje LZO (rychlé), takže ta db je na disku menší než je velikost těch souborů (tím je efektivně ještě lepší rychlost / menší zatížení disků). Jak jsem psal, na produkci jsme nepoužívali pro soubory nic jiného. Velikost prakticky odpovídá, kolem těch 6TB to už bude (není to ale jedna db, ale desítky menších). Počet souborů, já tam mám soukromě:

add=# select count(*) from file;
   count
-----------
 106407926

A ty hotové řešení mají většinou i nějaké standardizované API (S3 apod.).

Tomu naprosto rozumím. Myslím si, že nejlepší varianta je CEPH, ale ten je zase náročnej z hlediska konfigurace a správy. (Tj pokud k tomu nemáš oddělení adminů, tak to není dobrý nápad.) O ostatních projektech nějak není ani slyšet. Občas někdo něco na konferenci kecne, ale většinou je to ve smyslu: migrovali jsme z něčeho na něco. Zatímco já už 12let používám PG a furt to funguje, tak některé jiné projekty mají pátý storage. Někdy se ten konzervatismus vyplácí. Akorát to teda nemá standardní storage API no.

[Max]

Rozumím ti a vzpomínám si i na info o tvé zkušenosti s Cephem.
V našem případě je možná ta db rychlá, většinou ta jejich web služba kydá timeouty. Reálně těžko říci, kde je problém (je to uzavřený bazmek, zdroje serveru jsou nevyužity atd.).
Zdar Max

[trekker.dk]

pokud k tomu nemáš oddělení adminů

...nebo rozpočet na support

[rich]

My to teď máme taky v DB a v BLOBech (Oracle), ale je to docela pomalý.

a udelali jste neco aby to bylo rychlejsi?

[Max]

Je to 3rd řešení, které už se nevyvíjí. A jako backend to má OracleDB (licence na db se váže na tu aplikační část, na nic jiného použít nejde).
A udělali jsme to, že se s DMS přechází na jiné řešení a pro využívání odkladiště souborů vypadá rozumněji ten objektový storage.
Jinak já pro zrychlení současného systému udělal to, že jsem zkontroloval nastavení té OracleDB a dostupnost zdrojů pro celé řešení. Byl tam i nějaký pokus řešit to s podporou, ale údajně neúspěšný.
Zkoumat strukturu ukládání dat / tabulek a jak funguje ta aplikační část, na to u končícího řešení dlabu.
Zdar Max

[rich]

Tak ze uz to neni podporovane je smutne, ale mel jsem na mysli tu cast, kde mluvis o pomalych LOBech. To je ulozene v db a ma to nejake parametry, ktere mohou ovlivnit vykon. Uz jen treba presunutim LOB segmentu na rychlejsi disky.
V tomto svetle docela jinak vyznivaji vety jako:

je to docela pomalý.

nebo

Zkoumat strukturu ukládání dat / tabulek a jak funguje ta aplikační část, na to u končícího řešení dlabu.

Z tohoto uhlu pohledu je celkem jasne proc je to pomale

[Max]

Pomalá je podle mně ta aplikační část, na db to podle mně nevázne. A ta aplikační část je nějaký java blob nad starou javou a starým oc4j connectorem v nějaké standalone verzi.
Myslím si, že nemá cenu se v tom nějak pitvat.
Zdar Max

[JirkaH]

https://github.com/EMCECS/ECS-CommunityEdition

[Nikola Ciprich]

Já bych použil ten CEPH, minimálně z následujících důvodů: - prakticky neomezená škálovatelnost - můžete klidně začít na těch 2 uzlech (byť bych doplnil ještě třetí jako quorum, ale to může být nějaký malý VM nebo něco malého) - pokročilé funkce, pokud využijete - cache tiering, snapshoty, volitelná úroveň redundance, při více uzlech K,N kódování (tzn efektivnější využití kapacity) a spousta dalších

má samozřejmě i negativa, kvůli kterým nemůžu zase jednoznačně doporučit: - dost strmá učící křivka - na malá řešení opravdu může být overkill - pro malé řešení může dávat slabý výkon (síla cephu se projevuje až u větších clusterů, navíc vyladit to není úplně jednoduché)

toť asi vše co mě teď v kostce napadá.. ať se podaří..

[Petr K.]

My ted migrujeme z nenazraneho Swiftu na Minio - https://min.io/

[Max]

Jo, také jsem se na něj díval. A zkušenosti/pocity z nasazení?
Díky
Zdar Max

[Filip Jirsák]

Co použít S3 protokol? Dnes ho implementue kde kdo, pro on-premise lze použít např. MinIO.

[Max]

Ano, to je cílem. A objektové storage většinou S3 podporují. Díval jsem se hlavně na Ceph, Swift, MinIO a ještě OpenIO. Pak vím, že GlusterFS má nějakou nadstavbu.
Řešeních by bylo spousta, o Cephu vím nejvíc, ale raději bych měl ještě nějaké info z reálného nasazení.
Zdar Max

[Jezekus]

Mám za sebou několik CEPH clusterů (návrh, implementace, operation), jeden z nich aktuálně 2 roky v produkci pořád aktivně opracováván (pridavani nodu, tiering, OSD, pridavani funkcionalit), většina slouží jako backend storage pro OpenStack nebo K8s.

Pokud něřešíš storage spolu s HW - například přechod od centrální storage k SDS, případně nepredikovatelný růst tak CEPH není úplně vhodný a přiklonil bych se k výše zmíněnému MinIO a S3.

V případě náhrady central storage za SDS pak CEPH je skvělá volba s tím, že čím větší cluster je tím lépe a vlastně to trpí pokud není cluster dost velký (počet nodů, počet OSD)

[Max]

Náhradu centrálního storage neřeším. Teď jedem dva storage s async replikací. Výkon už přestává dostačovat, takže plánuji co nejdříve nasadit aktuální železo, čistě SSD pole. Opět dvě s async replikací. Nějak mi přijde, že ty pole a nasazení není tak velké, abych řešil ceph s 5 a více nody. Aktuálně má centrální storage sežráno 20TiB + pár věcí je bokem mimo centrální storage (nějaké archivační systémy, to DMS, které tu zmiňuji a testovací servery, celkem tedy asi 20TiB mimo). Ty VM na centrálním storage společně generují ve špičkách asi přes 6000 IOPS a datový tok je relativně malý. Stále si tedy tak nějak říkám, že na Ceph je to ještě malé nasazení.
Zdar Max

[Jezekus]

Souhlas, 20TB je málo.

Clustery, o kterých se bavím, že už dosahují rozumné velikosti, mají přes 9 nodů, cca 180 OSD (disků) a kapacitně přes 400TB RAW kapacity.

[Max]

Jo, tam už to smysl rozhodně dává. U nás mám největší storage 100TB na zálohy (ZFS). Skoro to i vypadá, že co nevidět budeme upgradovat na 150TB + ještě jeden 150TB pro zálohování zálohovacího storage :).
Zdar Max

[Mirek]

Doporučuji CEPH. Pokud se nechceš učit tak si jej nainstaluj a spravuj v PROXMOXU. Default instalace je sice na 3 nody, ale když ohneš konfigurák, tak to rozjedeš na 2 nodech. Vysloveně "klikačka" je přidání management a monitor nodu, prima funguje cluster... Nevím kdo ti poradil 4+ nodu. Klidně si dej 3 nody , do každého pro CEPH třeba 4 disky a kapacity máš dostatek. Je sice fakt, že PROXMOX po instalaci nemá přímo cluster ani ceph, ale stačí parkrát kliknout, být připojen na net a vše se dotáhne. Také doporučuji druhou sítovku pro cluste - ceph. Asi nej je 10GB, ale nouzově přežiješ i GB. Postupně to můžeš "zlatit" tj přidávat další nody či OSD disky, hrát si s flash ap. Stačí ?

[Ivan]

Zalezi na tom jak moc se do toho chces ponorit. S3 umi napr NetApp diskova pole.

[Mirek]

Příloha:

• OS.png (153624 bytů)

Ceph na 4+ nodech je pro něj moc, ale NetApp pole ne ?

[Mirek]

Ale může si vybrat, v obrázku výše je rozložení používaných

[Max]

V rámci NetAppu nám stále stačí ta nejnižší řada, kde je cena celkem příznivá. Nic víc bych v tom nehledal.
Zdar Max