Datacenter/Cloud pentru stocare fisiere in cantitati mari? (o gramada de TB) - Idei?

[emm]

Please help. (Incerc sa scriu pe scurt, dar nu va iesi scurt)

Lucrez la un proiect B2B SaaS important si nu am gasit inca o solutie decenta pentru arhivarea de date user, multi TB, posibil PB pe viitor. Rezonabila ca si cost, pentru cantitati foarte mari de date. Din pacate, este un proiect dificil, cu cerinte costisitoare.

Pe partea de executie si DB avem tot ce trebuie (am ales Linode, load balancers, criptare si replicare DB). Nu avem insa o solutie buna pe storage/arhivare.

Pentru fiecare user account trebuie storage de macar 5-10GB. Vor fi si clienti cu 1TB storage fiecare, linistit. Intrucat proiectul aduna deja o gramada de cereri de signup, vor fi cateva mii de inscrieri pe luna (ne-au innebunit), si marketingul e doar semi-activ momentan, trebuie sa fim pregatiti. Mai sunt doar cateva saptamani pana la lansare. Iar problema e serioasa.

Am folosit pana acum DigitalOcean, Linode, Amazon AWS, si multi altii pentru bare metal servers. Avem destula experienta cu ei.

Problema este ca in general aceste servere sunt uzual configurate cu maximum 1TB de storage (sau mai rau, 200GB SSD) si aruncam bani pe geam pe 64 cores cu 128GB RAM (nu ne trebuie). Ne trebuie cam 10-20 TB storage per server (care e folosit mai mult ca un NAS decat ca webserver), 4 cores e destul, placa de retea buna. Si ne trebuie si ceva gen 10TB transfer minim pe luna. Cost eficient.

Avand in vedere ca vor fi multi useri, cu cat mai ieftin spatiul, cu atat mai bine. Acest gen de storage de arhiva in cantitati mari per user, este scump. Din acest motiv, inchirierea uzuala de servere neoptimizate pentru asa ceva nu merge, vom iesi in paguba. Amazon Glacier de exemplu, ne-ar ucide cu costurile. Am lucra pentru ei doar.

Singura idee (aproape functionala) pe care am gasit-o este: Sa ne facem propriul mini-datacenter in Bucuresti si sa folosim 2 conexiuni dedicate pe care le avem deja. Cu siguranta e costul cel mai mic, dar balamucul este semnificativ.

Gen cateva servere cu cat mai multe HDD legate, de cativa TB fiecare, in 2 locatii diferite (pentru replicare). Intrucat costul de data transfer prin RDS este decent, ne putem descurca binisor asa. Adica platim doar transferul de date + curentul la servere + costul initial hardware (care este relativ mic, chiar daca includem power backup de 24-48 ore). Pe ansamblu, este ieftin.

Are cineva alta idee fezabila pentru un astfel de storage, cu cost eficient?

Nota: Locatia nu e asa importanta, poate sa fie in zona Romania - Frankfurt - Londra etc. Undeva in EU.

[emm]

Corectie: Nu e vorba de "fisiere" totusi, datele sunt stocate de fapt ca BLOB in baza de date MariaDB.

[Marius Cristian]

Poți închiria un rack (sau 1/2 etc) într-un datacenter specializat și în el iti pui tu serverele configurate conform acestei cerințe.

[emm]

Poți închiria un rack (sau 1/2 etc) într-un datacenter specializat și în el iti pui tu serverele configurate conform acestei cerințe.

Multumesc. Suna logic. Vreo recomandare concreta de datacenter in RO?

[PhoeniXman]

In Cluj eu am avut colocat server la Simpliq, nu au fost probleme.

[Marius Cristian]

1. Mari: GTS, nxData, Star Storage, Omnilogic, Ines cei mai renumiti de aici Colocation Romania - Data Centers, unele date insa vad ca sunt neactualizate.
2. Unii provideri de internet, precum Teentelecom - Provider Internet fibra optica Bucuresti - ISP TeenTelecom, au propriul lor serviciu de gazduire servere (de exemplu siteul prin semnatura www.smartvps.ro)
3. Cautare pe google dupa "colocare", iti vei putea da seama destul de usor in majoritatea cazurilor cine are centrul lui de date si cine isi tine serverele in alt loc. E greu de crezut ca vei obtine discount bun de la intermediar, dar nu se stie niciodata.

[kleampa]

mi se pare slab gandita arhitectura daca trebuie sa pastrezi direct in DB atata informatie. spui ca nu ai nevoie de gb de ram dar ca sa ai un query time bun in atata informatie tot trebuie sa ai cel putin 32gb

[emm]

mi se pare slab gandita arhitectura daca trebuie sa pastrezi direct in DB atata informatie. spui ca nu ai nevoie de gb de ram dar ca sa ai un query time bun in atata informatie tot trebuie sa ai cel putin 32gb

Putin probabil, dar o sa testam inainte de a achizitiona vreun rack. Ma indoiesc ca trebuiasca mai mult de 8G.

Cert este ca face doar write banal la fisiere destul de mari, fiecare record e un BLOB mai marisor. Nu se consuma mare RAM, conteaza mai mult I/O. Iar la select-uri, chiar nu este problema. Este o arhiva, rar ai nevoie de ea dar e important sa fie. Am ales stocarea in DB pentru ca e mai usor de accesat, iar spatiul consumat pe disc nu este cu mult mai mare decat la stocarea directa de fisiere. In schimb avem usor la meta date, iar criptarea si replicarea este foarte simpla.

Ce spui tu e valabil, dar pe partea de business logic. Acolo folosim intr-adevar si CPU's si RAM la greu.

Edit: Inca ceva, indecsii pe meta-date sunt mici si optimizati (in speta numerici). Se incarca usor in cativa zeci de MB maxim. De aici usage mic de RAM. Iar clientii care vor folosi simultan arhiva sunt putini. Se folosese mai mult la scriere. La citire, din 1000 de useri poate doar 10 vor accesa arhiva intr-o zi. Si se face mai mult write linear.

Repet, in primul rand conteaza I/O - atat pe disc cat si network throughput.

[deadworldisee]

Din experienta cel mai bine cost/performanta/mentenanta e sa mergi cu serverul custom local host. Iti iei o placa de baza cu CPU extreme(5820k destul de bun) fiindca are BUS-ul mare,o placa PCI-SATA 3 cu 10 porturi ,montezi pe unitate minim 16 harduri de minim 10TB(non - raid),16 GB ram.
Daca fisierele sunt media,cel mai bine le hostezi fisiere si daca sunt text cel mai bine le hostezi fisiere arhivate cu cale fisiere/nume indexate intr-o baza de date pe un SSD.Daca vei merge cu data in MariaDB sau orice baza de date,in momentul cand datele vor fi impartite pe mai multe harduri,vei pierde mult la I/O la scriere sau citire.Daca baza de date se va corupe(si sunt sanse sa se intample, va dura extrem de mult pt reparare pt sute de TB).Hddurile trebuie sa le pui la block size cat mai mare. In OS trebuie sa selectezi sa intre in hibernare hddurile daca nu sunt utilizate ,pentru o viata mai indelungata.
Ai putea sa mai faci o clona la server si sa se lege de primul prin thunderbolt de ex. pt viteza mare transfer la care sa se updateze prin cron la o anumita ora..

[emm]

> Din experienta cel mai bine cost/performanta/mentenanta e sa mergi cu serverul custom local host.

Sunt convins de asta. Datacenters sunt considerabil mai scumpe.

> Iti iei o placa de baza cu CPU extreme(5820k destul de bun) fiindca are BUS-ul mare,o placa PCI-SATA 3 cu 10 porturi ,montezi pe unitate minim 16 harduri de minim 10TB(non - raid),16 GB ram.

Multumesc de configuratie.

> Daca fisierele sunt media,cel mai bine le hostezi fisiere si daca sunt text cel mai bine le hostezi fisiere arhivate cu cale fisiere/nume indexate intr-o baza de date pe un SSD. Daca vei merge cu data in MariaDB sau orice baza de date,in momentul cand datele vor fi impartite pe mai multe harduri,vei pierde mult la I/O la scriere sau citire.

Vom ramane totusi pe MariaDB blob. Ne putem asigura ca datele nu se impart pe harduri diferite. MariaDB e intr-adevar mai incet decat direct file upload/download, dar avem motive serioase pentru a ramane pe blob.

> Hddurile trebuie sa le pui la block size cat mai mare.

Pentru genul asta de usage, in mod cert.

>In OS trebuie sa selectezi sa intre in hibernare hddurile daca nu sunt utilizate ,pentru o viata mai indelungata.

La asta nu ma gandisem, dar este o idee buna (depinde de usage-ul pe care il vom masura).

>Ai putea sa mai faci o clona la server si sa se lege de primul prin thunderbolt de ex. pt viteza mare transfer la care sa se updateze prin cron la o anumita ora..

Aici nu inteleg. Motivul clonarii? Read replica? Oricum vom face asta din MariaDB (fiecare server are slave-ul lui, si pentru anumite aplicatii vor fi si read replicas).