Monitorowanie środowiska czy to wirtualnego czy też fizycznego jest dla wielu organizacji kluczowe. Tym o to zdaniem można zacząć każdą prezentacje produktu, który posiada taką funkcjonalność. No dobrze, ale zapytacie zapewne do czego dążysz? Jako osoba zajmująca się głównie rozwiązaniami VMware odpowiem – dążę do tego abyście poznali rozwiązania właśnie tego producenta, ponieważ w ich portfolio jest również system do monitorowania, o którym powiem słów kilka. Tym rozwiązaniem jest VMware vRealize Operations od wersji 8.
Monitorowanie środowiska czy to wirtualnego czy też fizycznego jest dla wielu organizacji kluczowe. Tym o to zdaniem można zacząć każdą prezentacje produktu, który posiada taką funkcjonalność. Dalej można dodać, że dynamiczny wzrost środowisk wymaga takiego narzędzia. Dzięki niemu możemy na żywo śledzić stan naszych serwerów, przełączników, macierzy i wielu innych elementów. Wszystko się zgadza, ale musimy jeszcze tam od czasu do czasu zajrzeć albo popatrzeć na powiadomienia, które tonami spływają do nas na maila czy inne komunikatory. Pomijając kwestie operacyjne, takie rozwiązanie powinno być intuicyjne i nie skomplikowane na tyle aby nie trzeba było monitorować środowiska do monitowania środowiska, bo ma tyle elementów oraz na tyle zaawansowane, aby sprostało naszym wymaganiom. Nie będę poruszał wyglądu takich narzędzi, bo każdy ma swoje przyzwyczajenia i z tym trudno dyskutować. Komuś się coś podoba a innej osobie już nie.
No dobrze, ale zapytacie zapewne do czego dążysz? Jako osoba zajmująca się głównie rozwiązaniami VMware odpowiem – dążę do tego abyście poznali rozwiązania właśnie tego producenta, ponieważ w ich portfolio jest również system do monitorowania, o którym powiem słów kilka. Tym rozwiązaniem jest VMware vRealize Operations od wersji 8. Od wersji 8, ponieważ na przestrzeni czasu nazwa się zmieniała.
Trochę historii i zmian oraz wersji
Wcześniej był to
- VMware vRealize Operations manager,
- a jeszcze wcześniej VMware vCenter Operations Manager.
- Jeszcze jest vRealize Operations Cloud i jak sama nazwa wskazuje nie władamy nim w pełni, a jedynie dostajemy to rozwiązanie w formie SaaS.
Jak wspomniałem jest wersja SaaS oraz on-premises. Jak chyba każdy produkt VMware jest w różnych wersjach. Wersja Standard, Advanced, Enterprise oraz SaaS. W zależności od wersji licencjonowania produkt ten się różni – w wersji Standard mamy licencjonowanie na VM/CPU w Advanced i Enterprise to już jest OSI/CPU i w SaaS to subskrypcja na 1,2,3,4 lub 5 lat. Produkt jest też oferowany w ramach paczki vRealize Suite. Najniższa wersja posiada ograniczoną funkcjonalność Advanced potrafi więcej, a Enterprise to już wszystko umie i wie najlepiej lub prawie wszystko 😉. Oprogramowanie posiada sporo funkcji i możecie sobie zerknąć na nie tutaj
Ogólna architektura
Teraz bardziej albo mniej płynnie przechodzimy do ogólnej architektury rozwiązania. W środowisku lokalnym mamy przygotowany specjalny appliance, który uruchamiamy w ramach środowiska VMware. W zależności od ilości monitorowanych obiektów oraz metryk, które ma przetwarzać wybieramy odpowiednią jego wielkość różniącą się ilością vCPU i RAM. Po uruchomieniu pojedynczej maszyny mamy już tak naprawdę działający system do monitorowania. Wystarczy podpiąć go do vCenter lub innego wpieranego oprogramowania lub urządzenia. Oczywiście to nie wszystko, ponieważ vRealize Operations wspiera różne tryby działania tj. HA oraz Continuous Availability.
Wyższa dostępność
Zaczynając od trybu wysokiej dostępność (HA) w klastrze mamy Master Node i Replica Node. To one tworzą wysoką dostępność usługi. Wszystkie dane trafiające na Master Node są replikowane na Replica Node. Przy włączonym HA musi się również uruchamiać dodatkowy Data Node. W przypadku większej liści takich nodów dane mogą być składowane i replikowane do nich.
Należy jednak pamiętać, że tylko Replica Node może przejąć funkcjonalność Mastera, a Data Nody stanowią moc obliczeniową. Jak widzimy w tym przypadku HA nie jest mechanizmem Disaster Recovery i należy o tym pamiętać. Przełączenie węzółów twa około 2-3 minuty i proces zbierania metryk jest wznawiany. Dane zapisywane są do bazy danych, dlatego też w przypadku HA opóźnienie pomiędzy węzłami musi być odpowiednio niskie. W przypadku nodów jest to 5ms RTT (Round Trip Time) a gdy posiadamy zdalne kolektory (Remote Collector) do zbierania danych to opóźnienie nie powinno przekraczać 200ms RTT. Dla Cloud Proxy (CP) to już 500ms.
Jak widzimy nie jest tak źle, ale 5ms powoduje problem rozłożenia maszyn wirtualnych w „większych odległościach” od siebie. Należy również pamiętać, że w takim trybie rozwianie jest odporne na awarię jednego węzła, czyli nawet gdy awarii ulegną dwa Data Node w tym samym czasie, będziemy mieli problem.
Dodatkowo ze względu na replikacje bazy danych wydajność rozwiązania spada o połowę, ponieważ musimy mieć pewność, że dane znajdują się również na drugim serwerze. Warto też wspomnieć o tym, że w przypadku braku możliwości separacji nodów nie powinno się uruchamiać vROps’a w HA.
- Dlatego reguły anti-affinity są tutaj przydatne.
- Wielkość uruchamianych nodów musi również być identyczna.
- Nie możemy ich mieszać.
Sam vRealize Operations wpiera do 8 węzłów o wielkości extra-large czyli na sam system monitoringu możemy przeznaczyć nawet 1TB RAM i ponad 190vCPU. Życzę wszystkim, aby posiadali takie zasoby tylko na usługę monitorowania 😉.
Zasoby – ile ich potrzebujemy?
Teraz możemy się zastanowić nad tymi zasobami. Nie każdy potrzebuje tak dużego rozwiązania, więc trzeba oszacować, ile tych zasobów w rzeczywistości potrzeba. Tutaj z pomocą przychodzi „kalkulator” .
Wybieramy wersje, rodzaj skalowania i wpisujemy odpowiednie wartości i mamy to – odpowiedni sizing maszyn wirtualnych. A jak wygląda ogólna architektura vROps w klastrze HA zerknijcie na poniższy diagram.
Czas na „ciągłą dostępność”
Wiemy coś o wysokiej dostępności teraz przychodzi czas na „ciągłą dostępność”. Polega ona na niczym więcej jak stworzeniem dwóch domen awarii, gdzie w przypadku problemu z jedną nie tracimy danych ani nie mamy przerwy działaniu rozwiązania. Najlepiej, aby domeny awarii były rozciągnięte pomiędzy dwa niezależne klastry vSphere. Przypomina to do streach cluster w vSANie. Oczywiście jak w przypadku vSANu dochodzi kolejny element, czyli świadek (witness). Nie zbiera i nie przechowuje żadnych danych. Działa tylko po to aby w ramach domen awarii nie pojawił się tzw. efekt Split-brain. W Continous Availabilty dane przechowywane są w Master Node w pierwszej domenie awarii, następnie 100% danych jest synchronizowana do Replica Node w drugiej domenie awarii. Jeżeli chcemy mieć więcej niż jeden węzeł w klastrze musimy posiadać wielokrotność tych nodów czyli 2,4,6,8,10,12,14 lub 16. Wszystkie jednakowej wielkości, a wygląda to jak poniżej.
Integracje
Na koniec tego opasłego wpisu trochę o integracjach. Domyślnie rozwiązanie wspiera vSphere, vSAN, NSX-T, obiekty w chmurze AWS, Azure czy GCP.
Oczywiście możemy zainstalować sobie Management Packi, które rozszerza funkcjonalność. Dostarczane są one przez samego VMware, ale również przez producentów rozwiązań. Takie rozszerzenia można zainstalować dla F5 BIG-IP, HPE, Cisco HyperFlex, Cisco UCS, IBM, Hyper-V, Cohesity, Docker, Kubernetes, SAP HANA, NetApp, Oracle, Palo Alto, Juniper itd.
Możemy również wysyłać dane z urządzeń po SNMP. Oprócz monitorowania vROps potrafi przewidywać przyszłość pod kątem zasobów klastra i przyrostu danych, automatyzować kilka elementów np. usuwanie snapshotów maszyn wirtualnych. O tych i o innych funkcjach więcej w kolejnej części. Aaa, zapomniałem o jednym – posiadać monitoring a z niego aktywnie korzystać to dwie rożne rzeczy.
PS. W międzyczasie VMware zmienił nazwę vRealize Operations na Aria Operations, ale więcej o tym może w drugiej części.
