[Case Study] Cluster shared volume – ile dysków? O to jest pytanie...

Każdy kto zarządzał przestrzenią dyskową w klastrach serwerowych spotkał się z problemem jej skalowania. Zapotrzebowanie biznesu rośnie, a za nim musi nadążać technologia i jej możliwości. Podobnie było w moim przypadku.

Więcej i więcej przestrzeni!

Środowisko naszego klienta oparte o technologię Hyper-v złożone było z 8-nodowego klastra, który przez wiele lat rozwijał się w tempie rosnącego zapotrzebowania. Liczba maszyn wirtualnych praktycznie stale rosła, a razem z nią wzrastało zapotrzebowanie na przestrzeń dyskową.

Na początku do klastra podłączona była jedna macierz z dyskami talerzowymi. Z czasem jednak, potrzeby zaczęły dynamicznie rosnąć, więc pojawiła się druga macierz. Niewiele później to również okazało się niewystarczające, więc pojawiły się dodatkowe półki dyskowe. Proces trwał do momentu, kiedy klaster składał się z:

• Macierzy z trzema półkami dyskowymi,
• Macierzy z dwoma półkami dyskowymi.

Kolejne przebudowy polegały na dokładaniu kolejnych dysków lub wymianie aktualnie obsługiwanych na większe. W pewnym momencie doszliśmy do punktu, w którym do klastra podpiętych było 18 wolumenów dyskowych o różnej wielkości, wahającej się od kilkuset GB do 10TB. Klaster w tym czasie obsługiwał już 115 maszyn wirtualnych pochłaniających od kilkudziesięciu GB do 20TB przestrzeni dyskowej każda.

Więcej zasobów oznacza więcej problemów.

Ta kombinacja macierzy, dysków i maszyn wirtualnych pokryła potrzeby biznesowe klienta i można by powiedzieć, że praca została wykonana i skończona. Jednak, tak duże rozproszenie zasobów pomiędzy kolejne wolumeny i maszyny wirtualne, poskutkowało większą ilością dodatkowych problemów.

Nieustannie zaczęły pojawiać się utrudnienia związane z brakiem dostępnej przestrzeni dyskowej, czy spadkami wydajności. To natomiast napędziło spiralę migracji maszyn wirtualnych pomiędzy wolumenami, aby zoptymalizować działanie klastra i macierzy.

Na tym etapie, skalowanie systemu w pogoni za wymaganiami biznesowymi napędziło problemów z utrzymaniem jego stabilności i dostępności dla użytkowników. Trzeba było temu zaradzić.

Dzień, w którym zmieniło się wszystko.

Zasugerowaliśmy klientowi wymianę macierzy na nowoczesne rozwiązanie, jakim jest macierz Flash NVMe. To miało oznaczać definitywny koniec z problemami z przestrzenią dyskową i wydajnością. Teraz jeden duży wolumen obsłuży wszystkie maszyny wirtualne, a dodatkowo mechanizmy deduplikacji i kompresji po stronie macierzy zminimalizują zajętość macierzy. Znaleźliśmy rozwiązanie wszystkich problemów za pomocą jednego rozwiązania!

Od tego momentu ścieżka była już prosta i wiodła przez wykonanie szybkiej, maksymalnie kilkudniowej, migracji danych z macierzy z dyskami talerzowymi na nową SUPERWYDAJNĄ macierz z dyskami flash. Proste!

Kiedy lepiej, niekoniecznie znaczy lepiej...

Jak się okazuje nie do końca. Szybko okazało się, że maszyny wirtualne łapią „freezy”, coś jakby wszystko na raz się zawieszało. Mało tego, nawet użytkownicy łączący się za pomocą VPNa mają problem i udaje im się to za drugim lub trzecim razem (timeouty przy autoryzacji). Więcej! Backup maszyn wirtualnych zajmuje ponad dwa razy więcej czasu niż wcześniej! O co chodzi? Przecież miało być lepiej...

Nawet praca klastra musi mieć dyrektora.

Rozwiązanie zagadki pod tytułem “czemu miało być lepiej, a nie jest” leży u podstaw działania Cluster Shared Volume i tylko ich zrozumienie pozwala odkryć o co tutaj chodzi.

Otóż, w takim klastrze każdy fizyczny serwer (tzw. nod klastra) ma dostęp do wszystkich dysków klastra, a tym samym wirtualne maszyny pracujące na tym klastrze mogą działać na dowolnych nodach klastra.

Pytanie w takiej sytuacji brzmi, jak takie zachowanie znosi system plików (NTFS, czy ReFS). Czy takie działanie klastra sprawia, że wszystkie nody klastra jednocześnie zapisują i odczytują dane ze wszystkich wolumenów dyskowych?

Odpowiedź brzmi: nie. Jednoczesny zapis i odczyt danych przez różne systemy mógłby zagrozić integralności systemu plików, a co za tym idzie spowodować awarię pracujących maszyn wirtualnych.

O ile odczyt danych nie jest problemem w tym przypadku, o tyle ich zapis wymaga szczególnej uwagi. Dlatego w klastrze wykorzystującym mechanizm CSV dla każdego wolumenu dyskowego jeden z nodów jest tzw. koordynatorem zapisu.

Aby odnaleźć nod, który koordynuje zapis danych, należy spojrzeć do konsoli zarządzania dyskami. Tam, szybko można się zorientować, że każdy dysk ma swojego “właściciela”, który odpowiada za wszystkie operacje zapisu.

Co więc stało się podczas migracji na SUPERWYDAJNĄ macierz? Wszystkie 115 maszyn wirtualnych zaczęło wykonywać operacje zapisu danych w oparciu o jeden fizyczny serwer. Pozostałe serwery w tym czasie udostępniały jedynie swoje zasoby: CPU, RAM, sieć. Co więcej, pozostałe serwery odczytywały dane z dysku CSV, ale proces zapisu przetwarzany był przez Ten jeden serwer i to nie mogło działać sprawnie.

Nie ma problemów nie do rozwiązania.

Od razu przeszliśmy do działania. Do klastra podłączyliśmy dodatkowo 8 wolumenów dyskowych z tej samej macierzy. Było to możliwe dzięki mechanizmowi Thin Provisioning, który zniwelował problem znacznego przekroczenia wielkości przydzielonej przestrzeni do danej macierzy.

Dodając kolejne wolumeny dyskowe do klastra mechanizm Failover Clustering automatycznie definiuje właściciela dla każdego kolejnego dysku i rozkłada tę funkcję pomiędzy nodami klastra.

W następnym kroku przeprowadziliśmy migrację wirtualnych maszyn na te wolumeny i...

Wszystkie problemy ustąpiły! Wreszcie w pełni zobaczyliśmy wydajność nowej macierzy, skończyły się „freezy”, a użytkownicy znów zaczęli łączyć się za pośrednictwem VPNów. Co więcej, znacznie spadł czas potrzebny na przeprowadzenie backupu wszystkich wirtualnych maszyn.  

Z każdego działania trzeba wyciągnąć wnioski.

Na podstawie tego wdrożenia nasuwa mi się jeden, najistotniejszy wniosek. Jeśli ktokolwiek, kiedykolwiek zapyta mnie, jak podzielić przestrzeń dyskową w klastrze CSV, to odpowiem: “Podziel na tyle ile jest nodów w klastrze, bo niekoniecznie lepiej, oznacza lepiej.”