Dorado – deduplikacja – kompresja

W naszej serwerowni korzystamy z macierzy Huawei Dorado 3000 – bardzo wydajnej macierz NVME. Przy instalacji i uruchomieniu macierzy nie wgraliśmy licencji na Deduplikację i kompresję, dlatego też dla utworzonych LUNów ta funkcjonalność nie działała. Po przeniesieniu części danych okazało się, że zajmują one ok. 2,5TB i jak widać redukcja wynosi zero (1:1).

Ilość danych dość szybko zaczęła puchnąć. Nasze kilkadziesiąt wirtualek służących w dużej mierze jako dev-ops/test powoli zjadało dostępne 15T miejsca. W ciągu 2 miesięcy doszliśmy do ponad 5T, co stanowiło ponad 1/3 macierzy.

Szybko okazało się, że wynika to z dwóch problemów:

• Wymienionej wcześniej deduplikacji i kompresji, która nie była włączona.
• VMFS5 na jednym z Lunów niestety nie wspierał tzw. Space Reclaim, czyli automatycznego procesu zwalniania bloków ze storage pomimo, że w filesystemie są oznaczone jako nie używane.

Space Reclaim

Na początek postanowiliśmy szybko uruchomić ręcznie space reclaim na naszym klastrze Vsphere. Na szczęście nie jest to żaden problem. Z cli jednego z hostów uruchomiłem polecenie.

I poczekałem 30 minut ? W tym czas co 100ms ESXi zwalniał po 200 bloków na macierzy Hauwei. W logach bardzo szybko przybywało wpisów:

2022-06-07T08:41:37.391Z info hostd[2101929] [Originator@6876 sub=Libs opID=esxcli-d2-cef6 user=root] Unmap: Async Unmapped 200 blocks from volume 6228940e-0048cbe2-599c-9457a563dc40 Total 3132400 of 10313569 free blocks. Progress=3

2022-06-07T08:41:37.491Z info hostd[2101929] [Originator@6876 sub=Libs opID=esxcli-d2-cef6 user=root] Unmap: Async Unmapped 200 blocks from volume 6228940e-0048cbe2-599c-9457a563dc40 Total 3132600 of 10313569 free blocks. Progress=3

Pozostało nam po tej procedurze ponad 3T danych. Czas na…

Deduplikację i kompresję

Co nam to daje? Przede wszystkim deduplikacja to unikanie zapisu takich samych ciągów binarnych na macierzy. Jak mamy 20 takich samych VMek z Debianem – to umówmy się kilkaset GB systemu jest taka sama. Deduplikacja powoduje, że macierz nie zapisuje 20 razy tych samych danych – zapisuje je tylko raz, a potem generalnie zamiast je zapisać – wskazuje gdzie już były zapisane.

Kompresja to akurat generalnie kompresowanie danych ala ZIP czy RAR.

Większość producentów macierzy stosuje te mechanizmy, ale zobaczmy jak efektywnie działają na Huawei. Zastosowane algorytmy i logika jest przecież różna, więc łatwo jest porównać wydajność danej implementacji.

Na Dorado nie wystarczy wgrać licencje oraz uruchomić dla konkretnego LUNa mechanizmy kompresji i deduplikacji. Działają one tylko w momencie zapisu nowych danych – macierz nie analizuje kilku czy kilkuset T już zapisanych – robi to w locie podczas nowych zapisów.

Wystarczyło utworzyć nowy LUN i Datastore i Vcenter uruchomić storage Vmotion dla naszych maszyn. Po jakimś czas uzyskaliśmy efekt!

Dane z 3.2T zostały zoptymalizowane do 1,2T. Dobry wynik – szczególnie, że nie mamy takich samych maszyn i jest to jeden wielki devops! Nasza macierz po kilku miesiącach miała zajętość ponad 30% a po dwóch prostych optymalizacjach, użycie spadło do 7%.

W dokumentacji możemy znaleźć informacje o współczynnikach redukcji, których możemy się spodziewać w zależności od danych:

Huawei mówi o średnim wyniku na poziomie 3:1, który jest gwarantowany przy opcji zakupu pojemności efektywnej.

Z ciekawostek – w sytuacji gdybyśmy chcieli poprawić wyniki Dorado możemy zastosować Huawei  Ocean Protect, który jest dedykowanym deduplikatorem i daje jeszcze lepsze efekty.

Myślisz o wymianie macierzy – zadzwoń lub napisz i porozmawiajmy