Piszki Lab

Analiza przypadku w języku przodków…

VMware vSAN w domu czyli crossflashing Dell Perc H200

| 0 comments

Nie będę ukrywał, że to moje drugie podejście do vSAN w domowym labie. Pierwsze zakończyło się totalną porażką którą można podsumować zwrotem “za krótka kolejka rozkazów”. Do drugiego podejścia przygotowałem się bardziej solidnie a i technika się w międzyczasie zmieniła. Zamiast pierwszej wersji vSAN mamy vSAN 6.2 które zostało mocno przeprojektowane pod względem wydajności i generowanego na urządzenia obciążenia. W międzyczasie pojawiły się szybsze dyski SSD oparte o 3D-NAND i trochę łatwiej o kontroler z odpowiednio długą kolejką rozkazów (queue depth). W moim labie mam tylko jeden serwer (jak na razie), zdecydowałem się zbudować vSAN w oparciu o kontroler Dell Perc H200, dysk Samsung Evo 820 120GB i dysk HGST 7K1000. Kontroler H200 jest najtańszym kontrolerem który można kupić na wolnym rynku (Allegro), mimo że zszedł już z VMware vSAN HCL to nadal się świetnie nadaje do tego zadania (ma kolejkę rozkazów o długości 600 aktualna rekomendacja to nie mniej niż 256 a najlepiej 1000). Dysku Samsung EVO 840 nie muszę przedstawiać, klasa sama dla siebie, ja kupiłem 120GB (rekomendacja to 10% SSD w ogólnej puli, ale to zależy ile mamy danych typu gorącego). Dyski HGST K71000 to szybkie dyski do laptopów z 32MB cache (mam takie dwa i sprawdzają się znakomicie jako local datastore w ESXi), są ciche i nie grzeją się zbyt mocno. Pozostaje jeszcze odpowiedź na pytanie po co? Oczywiście aby zwiększyć wydajność zgodnie z rysunkiem poniżej!

vsan2

Zanim zaczniemy, krótka uwaga na temat tego co znajdziemy w Internecie. Ci bogatsi stawiają labowe klastry vSAN oparte o Intel NUC i dyski M.32, raz że koszt takiego rozwiązania jest ogromny a dwa, że to nadal sprzęt domowy z kolejką rozkazów na poziomie 32 (a czemu to ma znaczenie to poczytajcie tutaj). Dlatego zanim przystąpicie do projektowania własnego rozwiązania zastanówcie się dwa razy co robicie i ile to będzie Was kosztowało. Samo uruchomienie vSAN na poziomie vSphere nie jest trudne, oczywiście je pokażę ale tutaj chciałbym się głównie skupić na procedurze przygotowania kontrolera. Tak się składa, że możemy bez najmniejszego problemu wgrać do H200 ostatni BIOS (P20) z LSI (a właściwie to Avago Technologies) który wspiera bezpośrednie wystawianie dysków do systemu z pominięciem RAID (co jest wymagane dla vSAN ale i dla np. ZFS przy FreeNAS). Cała procedura nie jest prosta (szczególnie dla posiadaczy płyty głównej z UEFI), ale wykonalna i co ważne, powtarzalna (nie zniszczycie kontrolera).

W pierwszym kroku musicie przygotować pendrive z wgranym FreeDOS, zastosujemy oryginalny firmware P20 IT:

vsan1

Plik LSI-9211-8i.zip z wgranymi wszystkimi potrzebnymi programami i biosami pobieracie bezpośrednio ode mnie, zawartość archiwum rozpakowujecie bezpośrednio na pendrive. Posiadacze starego BIOS mają prościej i mogą pominąć część o UEFI. Posiadacze nowszych płyt głównych aby wystartować w trybie FreeDOS muszą wyłączyć Secure Boot, opis poniżej dotyczy płyt Asus ale jest równoważny dla innych producentów.

Procedura wyłączenia UEFI:

Wchodzimy do UEFI, przechodzimy do sekcji Advanced lub od razu do sekcji Boot (podłączcie do płyty wcześniej przygotowany pendrive). Przechodzimy do pozycji Secure boot, powinna być ustawiona na Windows UEFI. Przechodzimy do pozycji Key Management (Enter) i w pozycji Save Boot Keys zapisujemy klucze na pendrive. Następnie w pozycji Delete PK kasujemy klucze, robimy restart i Secure boot został wyłączony (procedurę można odwrócić).

Wgranie nowego firmware do Perc H200 sprowadza się do dwóch kroków, wymazania starego (DOS) i wgrania nowego (UEFI). Posiadacze standardowego BIOS wykonują wszystkie kroki, z pominięciem startowania w UEFI, za pomocą poleceń exe (w archiwum mamy dwa polecenie sas2flash.exe i sas2flash.efi). Posiadacze płyt z UEFI muszą w pierwszym kroku wystartować z pendrive w trybie UEFI (w UEFI BIOS w Boot options wybieramy UEFI first). Po uruchomieniu UEFI Shell wchodzimy na właściwy pendrive (USB) wskazując numer urządzenia (w moim przypadku fs3, wpisujemy fs3: enter, jak przy zmianie dysku w Windows CMD). W pierwszym kroku wydajemy polecenie sas2flash.efi –listall, wyświetli nam się lista kontrolerów (tutaj już po wgraniu firmware P20):

20161106_131934

Następnie poleceniem sas2flash.efi –c 0 –list wyświetlamy szczegóły karty. W tym momencie musicie sobie spisać numer SAS Address który zostanie wymazany i trzeba będzie go ustawić ponownie.

20161106_132017

W tym momencie robimy reboot i startujemy z pendrive w trybie FreeDOS (w UEFI w sekcji boot wymieramy USB i Standard boot). Procedurę wymazania starego firmware wykonuje się poleceniem megarec.exe poleceniami:

megarec.exe –writesbr o sbrempty.bin (o nie zero)

megarec.exe –cleanflash o  (o nie zero)

20161106_130850

W przypadku problemów, zawsze możecie ponowić wymazanie i wgranie nowego firmware. Po poprawnym wymazaniu starego firmware robimy reboot i przechodzimy do trybu UEFI. Wbrew pozorom, aby dopełnić procedurę musimy trzykrotnie wgrać różne “biosy”. Zaczynamy od polecenia:

sas2flash.efi –o –f 6GBPSAS.FW (o nie zero)

20161106_131124

Następnie wgrywamy nowy firmware poleceniem:

sas2flash.efi –o –f 2118it.bin (o nie zero)

20161106_131442

W kolejnym kroku przywracamy adres SAS poleceniem sas2flash.efi –o –sasadd “zapisany numer”:

20161106_131832

W tym momencie mamy w pełni funkcjonalny kontroler którym możemy zarządzać z CLI (Linux i Windows), jeśli jednak chcielibyśmy mieć dostęp do standardowego BIOS kontrolera to musimy go dograć trzecim poleceniem:

sas2flas.efi –o –b mptsas2.rom

Wykonujemy reboot i możemy wejść do BIOS karty, jak widać wgrany jest firmware 20-IT, wszystkie podłączone dyski powinny być widoczne bez problemu.

20161106_134821

Jak już pisałem, mam tylko jeden serwer, aby poprawnie uruchomić vSAN w takiej konfiguracji należy zmodyfikować odpowiednie parametry z poziomu esxcli:

vsan1

Z poziomu vSphere Web Client dla wybranego klastra (zawierającego pojedynczy ESXi) konfigurujemy vSAN. Widać tutaj dwa dyski podpięte do kontrolera H200 (SSD jako Cache i HDD jako Capacity).

vsan2

Tworzę pulę hybrydową dlatego nie mam włączonej deduplikacji i kompresji.

vsan3

W ostatnim kroku musimy stworzyć własną politykę dyskową, domyślna nie jest dostosowana do funkcjonowania na pojedynczym nodzie. Nie ma sensu np. duplikowanie danych przy pojedynczym HDD, rezerwacja 1% na cache da gwarancję, że każda maszyna będzie miała swój udział w puli cache (unikniemy sytuacji w której bardzie gadatliwa maszyna wypchnie np. kontroler domeny). Oczywiście tutaj dużo zależy od Waszej pomysłowości.

vsan8

Pozostaje odpowiedź na ostatnie pytanie, czy w takich warunkach to ma sens i czy to w ogóle działa? Nie będę ukrywał, że mnie osobiście dręczyła ostatnio ogólna niewydolność podsystemu dyskowego, w pewnym momencie ciężko cokolwiek robić gdy stałe opóźnienie na dyskach nie spada poniżej 70 milisekund. W rozwiązaniu takim jak vSAN do większości operacji frontendem jest dysk SSD w podziale 70% dla odczytu i 30% dla zapisu i muszę przyznać że to działa. Szczególnie widoczne jest to przy operacjach zapisu które trafiają w 100% w SSD, cache odczytu buduje się powoli (można tym trochę sterować za pomocą polityki). Osobnym problemem przy vSAN zawsze był moment przebudowy i kopiowania danych pomiędzy SSD a HDD, w vSAN 6.2 dane są zbierane i kopiowane ciągłym strumieniem (a nie tak jak było przy pierwszych wersjach, w zasadzie randomowo co zarzynało dyski). Mimo to można obserwować spore opóźnienia (krótkotrwałe) w momencie przesuwania danych, na szczęście całe środowisko zachowuje się stabilnie, nie zapycha się i pracuje wydajnie, ja jestem zadowolony jak na razie.

Tak wyglądała dotychczasowa praca lokalnego Datastore (jak widać, tragedia):

vsan4

vsan5

A tak po migracji wszystkich maszyn na vSAN (SSD+HDD, w planie mam dołożenie kolejnego HDD więc będzie jeszcze lepiej):

vsan6

vsan7

Oceń ten artykuł:
[Głosów:1    Średnia:5/5]

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.