On Tue, Nov 7, 2023 at 4:39 PM Petru Rațiu <rpe...@gmail.com> wrote:
>
>
> O sa incerc sa dezvolt intr-un alt mail, dar pe scurt mi se pare un
> proiect care n-a depasit conceptele relativ simpliste si de
> homeuser/developer cu care pornise, chiar daca privind din afara suna fancy
> si scalabil. Multe din deciziile pe care le iei cand faci initial clusterul
> raman batute in cuie si nu scapi de ele decat cu export/import (lucru
> sugerat inclusiv de suport la orice problema mai complexa).
>
>
Bun, o sa incerc sa fac un rezumat al peripetiilor. De notat ca usecase-ul
meu s-ar putea sa fie mai special, desi ai zice ca la prima vedere se
preteaza perfect pe ce promite: am de stocat o arhiva cu ~multe pdf-uri (am
ajuns pe la 15 milioane si e in crestere), dimensiunea medie a obiectului e
~ 1MB, ma apropii de 18 TB date utile (ceva mai mult raw storage, mai multe
despre asta mai tarziu). Cand ma bagasem in ciorba curenta (prin 2019)
proiectul era inca in faza de development si se facuse deja trecerea de la
seaweedfs (care probabil n-ar fi supravietuit pana acum) la minio (care nu
e exclus sa fi fost si alegerea mea la momentul respectiv, cred ca era si
atunci cea mai promitatoare clona de S3 on-prem).
A fost nevoie de o trecere relativ rapida in productie si n-am apucat sa
fac suficient de multe teste operationale, dar vazusem ca stie clustering
si parea sa faca zgomotele potrivite in directia asta, asa ca am zis ca
da-i ca merge (la momentul respectiv nu parea o componenta atat de
importanta a arhitecturii, am zis ca e important sa aiba oarece redundanta
si promisiuni de scalabilitate ulterioara). Am inceput prin a face ca orice
om normal care face un cluster minimal 3 VM-uri (cum facusem si la
kubernetes, la elasticsearch, la mongodb, etc). Cand am ajuns sa-i dau
drumul am constatat ca ce sa vezi, daca vreau sharding de-ala de redundanta
trebuie minim 4 discuri. Nu era timp sa mai fac al patrulea vm si parea
deja overkill, am zis fuck it, punem cate un /data1 si /data2 pe fiecare si
o sa aiba 6 discuri pe 3 masini fizice. Slaps roof, beculeste, trecem mai
departe. Bzzt, wrong, dar urma sa aflu mai tarziu.
In timp, pe masura ce cresteau datele am tot redimensionat storage-ul
vm-urilor pana am ajuns la limita intrinseca a vmware de 2TB. Mbon, e
momentul sa mai adaugam noduri, ia sa vedem care e schema. Well, turns out
ca in clusterul de minio poti adauga cate un singur pool deodata si toate
poolurile trebuie sa aiba aceeasi geometrie (posibil sa fie obsolete
aceasta informatie, n-am mai facut source dive prin minio de vreun an, dar
nu mi-a sarit nimic in ochi prin changelog care sa dea semne ca s-ar fi
schimbat chestia asta). Asa ca decizia mea semi-retardata de a face 3x2
initial mi-a ramas mostenire si a trebuit mereu sa adaug cate 3 servere cu
2 discuri de fiecare data.
Btw, motivul pentru care face asta e putin stupizel. Sa ziceam ca aia ca un
pool nu-si schimba geometria si fiecare disc e mereu in aceeasi pozitie are
cumva sens ca simplifica o gramada de probleme de shard placement, insa din
cate mi-am dat seama nu e nici un motiv tehnic sa n-ai pooluri de
configuratii diferite, in afara de faptul ca geometria clusterului se
specifica via command line sub forma server{1...3}/data{1...2}
server{4...6}/data{1...2} samd. Alte fun facts care decurg din aceasta
minunat detaliu de design este ca schimbarile de geometrie implica complete
cluster restart (ca fiecare daemon sa plece cu noul cmdline) si ca numele
masinilor trebuie sa se poata grupa lexicografic in stilul ala. Mai am
niste sechele de la un quest care m-a facut sa intru foarte in detaliu in
formatul on-disk al metadatelor dar am un lapsus.
Alta consecinta fun a geometriei batuta in cuie este ca redundanta este
data de parametrii de erasure coding, care sunt per pool, nu pe intreg
clusterul,iar la pooluri foarte mici nu prea ai cum sa faci eficienta (eu
sunt basically stuck cu factor 2x de data usage, si storage-ul era deja
nesimtit de scump). Singura iesire din situatia asta e facut un alt cluster
de minim aceeasi dimensiune utila si migrat complet datele.
Ah, alta chestie surprinzatoare este ca nu poti controla pe ce pool ajunge
un anumit obiect, este amplasat automat printr-un soi de weighted
round-robin ajustat cu procentele de disk usage de pe fiecare pool. A fost
relativ de curand introdusa o operatie in care pot fi migrate datele de pe
un pool in vederea decomisionarii lui, dar e implementata la modul ca se
marcheaza poolul pt decomisionare si migreaza el datele pana fie se goleste
fie ramane fara spatiu in alta parte si da eroare. Cu alte cuvinte nu prea
ai cum sa ai noduri "hot" si "cold" in cluster.
Alta chestie care mi-a scos peri albi este ca pe de o parte te bazaie sa
fie totul TLS (nu mai stiu, parca erau functionalitati care nu voiau sa
mearga fara), dar asta se face punand certificat si cheie in caile
hardcodate ~minio/.minio/certs/{public.crt,private.key} . Consecinta
subtila a acestui detaliu este ca majoritatea pe care-i gasesti pe net fie
au certificate de-alea mickey mouse emise pe 99 de ani, fie ruleaza totul
cu flaguri gen --ignore-tls-errors.
All in all, mi se pare ca in continuare e tratat ca scula de local
development cu date care nu conteaza chiar atat de tare, chiar daca i-au
lipit mai cu ciocanul niste features de-astea mai enterprise. Recunosc ca
nu m-am uitat foarte in detaliu la minio operator de k8s, doar am vazut ca
foloseste acelasi binar pe post de server, deci probabil are cel putin
toate hibele de mai sus deeply hidden. Imi tot fac curaj sa fac migrarea
aia de cluster si parca-parca as face-o pe altceva daca promite ca suge mai
putin. Ceph m-a intimidat putin initial dar daca e gandit ground up sa
rezolve mai bine probleme de-astea ar putea sa merite bataia de cap.
Mbine, rant off, mai intreaba punctual daca mai e ceva, mai erau un numar
de rahateluri in care n-am mai intrat.
--
P.
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
