В rozmawialiśmy o naszych próbach użycia Watchera i przedstawiliśmy raport z testów. Okresowo przeprowadzamy takie testy pod kątem równoważenia i innych krytycznych funkcji dużej chmury przedsiębiorstwa lub operatora.
Duża złożoność rozwiązywanego problemu może wymagać kilku artykułów opisujących nasz projekt. Dziś publikujemy drugi artykuł z serii, poświęcony równoważeniu maszyn wirtualnych w chmurze.
Trochę terminologii
Firma VmWare wprowadziła narzędzie DRS (Distributed Resource Scheduler), aby zrównoważyć obciążenie opracowanego i oferowanego przez siebie środowiska wirtualizacyjnego.
Według
„VMware DRS (Distributed Resource Scheduler) to narzędzie, które równoważy obciążenie obliczeniowe z dostępnymi zasobami w środowisku wirtualnym. Narzędzie jest częścią pakietu wirtualizacyjnego o nazwie VMware Infrastructure.
Dzięki VMware DRS użytkownicy definiują zasady dystrybucji zasobów fizycznych pomiędzy maszynami wirtualnymi (VM). Narzędzie można skonfigurować do sterowania ręcznego lub automatycznego. Pule zasobów VMware można łatwo dodawać, usuwać i reorganizować. W razie potrzeby pule zasobów można odizolować między różnymi jednostkami biznesowymi. Jeśli obciążenie jednej lub większej liczby maszyn wirtualnych zmieni się radykalnie, VMware DRS redystrybuuje maszyny wirtualne na serwerach fizycznych. Jeśli ogólne obciążenie spadnie, niektóre serwery fizyczne mogą zostać tymczasowo przełączone w tryb offline, a obciążenie skonsolidowane.”
Dlaczego potrzebne jest równoważenie?
Naszym zdaniem DRS jest funkcją niezbędną w chmurze, chociaż nie oznacza to, że należy z niej korzystać zawsze i wszędzie. W zależności od przeznaczenia i potrzeb chmury mogą obowiązywać różne wymagania dotyczące DRS i metod równoważenia. Mogą zaistnieć sytuacje, w których balansowanie nie będzie w ogóle potrzebne. Albo nawet szkodliwe.
Aby lepiej zrozumieć, gdzie i dla jakich klientów potrzebny jest DRS, rozważmy ich cele i zadania. Chmury można podzielić na publiczne i prywatne. Oto główne różnice między tymi chmurami a celami klientów.
Chmury prywatne / Klienci dla dużych przedsiębiorstw
Chmury publiczne / Średnie i małe firmy, ludzie
Główne kryterium i cele operatora
Zapewnienie niezawodnej usługi lub produktu
Obniżenie kosztów usług w walce na konkurencyjnym rynku
Wymagania serwisowe
Niezawodność na wszystkich poziomach i we wszystkich elementach systemu
Gwarantowana wydajność
Podziel priorytety maszyn wirtualnych na kilka kategorii
Bezpieczeństwo informacji i danych fizycznych
SLA i wsparcie XNUMX/XNUMX
Maksymalna łatwość odbioru usługi
Stosunkowo proste usługi
Odpowiedzialność za dane ponosi Klient
Nie jest wymagane ustalanie priorytetów maszyn wirtualnych
Bezpieczeństwo informacji na poziomie standardowych usług, odpowiedzialność po stronie klienta
Mogą występować usterki
Brak umowy SLA, jakość nie gwarantowana
Wsparcie emailowe
Kopia zapasowa nie jest konieczna
Funkcje klienta
Bardzo szeroki zakres zastosowań.
Starsze aplikacje dziedziczone w firmie.
Złożone niestandardowe architektury dla każdego klienta.
Zasady powinowactwa.
Oprogramowanie działa bez przerwy w trybie 7x24.
Narzędzia do tworzenia kopii zapasowych w locie.
Przewidywalne cykliczne obciążenie klientów.
Typowe zastosowania – równoważenie sieci, Apache, WEB, VPN, SQL
Aplikacja może zostać na chwilę zatrzymana
Umożliwia dowolną dystrybucję maszyn wirtualnych w chmurze
Kopia zapasowa klienta
Przewidywalne, statystycznie uśrednione obciążenie przy dużej liczbie klientów.
Implikacje dla architektury
Geoklastrowanie
Scentralizowane lub rozproszone przechowywanie
Nadmiarowy IBS
Lokalne przechowywanie danych w węzłach obliczeniowych
Równoważenie celów
Równomierny rozkład obciążenia
Maksymalna responsywność aplikacji
Minimalny czas opóźnienia dla równoważenia
Równowaga tylko wtedy, gdy jest to wyraźnie konieczne
Wyniesienie części sprzętu do konserwacji zapobiegawczej
Obniżenie kosztów usług i kosztów operatora
Wyłączenie niektórych zasobów w przypadku niskiego obciążenia
Oszczędność energii
Obniżenie kosztów personelu
Sami wyciągamy następujące wnioski:
Do chmur prywatnychudostępniany dużym klientom korporacyjnym, DRS może być używany z zastrzeżeniem następujących ograniczeń:
- bezpieczeństwo informacji i uwzględnienie zasad powinowactwa przy bilansowaniu;
- dostępność wystarczających zasobów w rezerwie na wypadek wypadku;
- dane maszyny wirtualnej znajdują się w scentralizowanym lub rozproszonym systemie przechowywania;
- oszałamiające procedury administracyjne, tworzenie kopii zapasowych i równoważenie w czasie;
- równoważenie tylko w obrębie zbioru hostów klienckich;
- równoważenie tylko przy silnym braku równowagi, najbardziej efektywne i bezpieczne migracje maszyn wirtualnych (w końcu migracja może się nie udać);
- równoważenie stosunkowo „cichych” maszyn wirtualnych (migracja „hałaśliwych” maszyn wirtualnych może zająć bardzo dużo czasu);
- równoważenie z uwzględnieniem „kosztu” – obciążenia systemu magazynowania i sieci (przy architekturach dostosowanych do potrzeb dużych klientów);
- równoważenie z uwzględnieniem indywidualnych cech zachowania każdej maszyny wirtualnej;
- Równoważenie najlepiej wykonywać w godzinach wolnych od pracy (noce, weekendy, święta).
Dla chmur publicznychświadcząc usługi dla małych klientów, DRS może być stosowany znacznie częściej, dzięki zaawansowanym możliwościom:
- brak ograniczeń bezpieczeństwa informacji i zasad powinowactwa;
- balansowanie w chmurze;
- bilansowanie w dowolnym rozsądnym czasie;
- równoważenie dowolnej maszyny wirtualnej;
- równoważenie „hałaśliwych” maszyn wirtualnych (aby nie przeszkadzać innym);
- dane maszyny wirtualnej często znajdują się na dyskach lokalnych;
- uwzględnienie średniej wydajności systemów i sieci pamięci masowej (architektura chmury jest ujednolicona);
- równoważenie zgodnie z ogólnymi zasadami i dostępnymi statystykami zachowania centrum danych.
Złożoność problemu
Trudność w zrównoważeniu polega na tym, że DRS musi działać z dużą liczbą niepewnych czynników:
- zachowania użytkowników każdego z systemów informatycznych Klientów;
- algorytmy działania serwerów systemów informatycznych;
- zachowanie serwerów DBMS;
- obciążenie zasobów obliczeniowych, systemów pamięci masowej, sieci;
- współdziałanie serwerów ze sobą w walce o zasoby chmury.
Obciążenie dużej liczby wirtualnych serwerów aplikacji i baz danych na zasobach chmurowych następuje z biegiem czasu, konsekwencje mogą się ujawnić i nałożyć na siebie z nieprzewidywalnym skutkiem w nieprzewidywalnym czasie. Nawet do sterowania stosunkowo prostymi procesami (na przykład sterowaniem silnikiem, systemem podgrzewania wody w domu) automatyczne systemy sterowania muszą wykorzystywać złożone Algorytmy ze sprzężeniem zwrotnym.
Nasze zadanie jest o wiele rzędów wielkości bardziej złożone i istnieje ryzyko, że system nie będzie w stanie w rozsądnym czasie zbilansować obciążenia do założonych wartości, nawet jeśli nie będzie żadnych zewnętrznych wpływów ze strony użytkowników.
Historia naszych realizacji
Aby rozwiązać ten problem, postanowiliśmy nie zaczynać od zera, ale wykorzystać istniejące doświadczenia i zaczęliśmy współpracować ze specjalistami mającymi doświadczenie w tej dziedzinie. Na szczęście nasze rozumienie problemu całkowicie się pokrywało.
Krok 1
Zastosowaliśmy system oparty na technologii sieci neuronowych i w oparciu o nią staraliśmy się optymalizować nasze zasoby.
Zainteresowanie tym etapem polegało na testowaniu nowej technologii, a jego znaczenie polegało na zastosowaniu niestandardowego podejścia do rozwiązania problemu, w przypadku którego, przy założeniu niezmienionych warunków, standardowe podejścia praktycznie się wyczerpały.
Uruchomiliśmy system i naprawdę zaczęliśmy równoważyć. Skala naszej chmury nie pozwoliła uzyskać optymistycznych wyników deklarowanych przez twórców, ale widać było, że balansowanie działa.
Jednocześnie mieliśmy dość poważne ograniczenia:
- Aby wytrenować sieć neuronową, maszyny wirtualne muszą działać bez znaczących zmian przez tygodnie lub miesiące.
- Algorytm przeznaczony jest do optymalizacji w oparciu o analizę wcześniejszych danych „historycznych”.
- Uczenie sieci neuronowej wymaga dość dużej ilości danych i zasobów obliczeniowych.
- Optymalizację i balansowanie można przeprowadzać stosunkowo rzadko – raz na kilka godzin, co zdecydowanie nie wystarczy.
Krok 2
Ponieważ nie byliśmy zadowoleni ze stanu rzeczy, postanowiliśmy zmodyfikować system i w tym celu odpowiedzieć główne pytanie – dla kogo to robimy?
Po pierwsze – dla klientów korporacyjnych. Oznacza to, że potrzebujemy systemu, który będzie działał szybko, z tymi korporacyjnymi ograniczeniami, które tylko upraszczają wdrożenie.
Drugie pytanie – co rozumiesz przez „niezwłocznie”? W wyniku krótkiej debaty zdecydowaliśmy, że możemy zacząć od czasu reakcji 5–10 minut, aby krótkotrwałe przepięcia nie wprowadzały systemu w rezonans.
Trzecie pytanie – jaką wielkość zrównoważonej liczby serwerów wybrać?
Ten problem rozwiązał się sam. Zazwyczaj klienci nie tworzą bardzo dużych agregacji serwerów, co jest zgodne z zaleceniami artykułu dotyczącymi ograniczenia agregacji do 30–40 serwerów.
Dodatkowo segmentując pulę serwerów upraszczamy zadanie algorytmu równoważenia.
Czwarte pytanie – jak odpowiednia jest dla nas sieć neuronowa ze względu na długi proces uczenia się i rzadkie równoważenie? Postanowiliśmy porzucić to na rzecz prostszych algorytmów operacyjnych, aby uzyskać wyniki w ciągu kilku sekund.
Można znaleźć opis systemu wykorzystującego takie algorytmy i jego wady
Wdrożyliśmy i uruchomiliśmy ten system i otrzymaliśmy zachęcające wyniki - obecnie regularnie analizuje obciążenie chmury i wydaje rekomendacje dotyczące przenoszenia maszyn wirtualnych, które w dużej mierze są słuszne. Już teraz widać, że uda nam się osiągnąć 10-15% uwolnienia zasobów dla nowych maszyn wirtualnych, jednocześnie poprawiając jakość pracy już istniejących.
W przypadku wykrycia braku równowagi w pamięci RAM lub procesorze system wydaje polecenia programowi planującemu Tionix w celu przeprowadzenia migracji na żywo wymaganych maszyn wirtualnych. Jak widać z systemu monitorowania, maszyna wirtualna została przeniesiona z jednego (wyższego) na inny (niższy) host i zwolniła pamięć na górnym hoście (zaznaczonym w żółtych kółkach), zajmując ją odpowiednio na dolnym (zaznaczonym na biało kółka).
Teraz staramy się dokładniej ocenić skuteczność obecnego algorytmu i znaleźć w nim możliwe błędy.
Krok 3
Wydawać by się mogło, że można się w tej kwestii uspokoić, poczekać na udowodnioną skuteczność i zamknąć temat.
Jednak następujące oczywiste możliwości optymalizacji popychają nas do przeprowadzenia nowego etapu
- Statystyka np. и pokazuje, że systemy dwu- i czteroprocesorowe mają znacznie niższą wydajność niż systemy jednoprocesorowe. Oznacza to, że wszyscy użytkownicy otrzymują znacznie mniej mocy wyjściowej z procesora, pamięci RAM, dysku SSD, sieci LAN, FC zakupionych w systemach wieloprocesorowych w porównaniu do systemów jednoprocesorowych.
- Same planery zasobów mogą zawierać poważne błędy, na ten temat.
- Technologie oferowane przez Intel i AMD do monitorowania pamięci RAM i pamięci podręcznej umożliwiają badanie zachowania maszyn wirtualnych i umieszczanie ich w taki sposób, aby „hałaśliwi” sąsiedzi nie zakłócali „cichych” maszyn wirtualnych.
- Rozbudowa zestawu parametrów (sieć, system przechowywania, priorytet maszyny wirtualnej, koszt migracji, jej gotowość do migracji).
Razem
Efektem naszej pracy nad udoskonaleniem algorytmów równoważących był jednoznaczny wniosek, że stosując nowoczesne algorytmy można osiągnąć znaczną optymalizację zasobów centrum danych (25-30%) i jednocześnie poprawić jakość obsługi klienta.
Algorytm oparty na sieciach neuronowych jest z pewnością rozwiązaniem ciekawym, jednak wymagającym dalszego rozwoju i ze względu na istniejące ograniczenia nie nadaje się do rozwiązywania tego typu problemów na wolumenach typowych dla chmur prywatnych. Jednocześnie algorytm wykazał dobre wyniki w chmurach publicznych znacznych rozmiarów.
Więcej o możliwościach procesorów, planistów i równoważeniu wysokiego poziomu dowiemy się w kolejnych artykułach.
Źródło: www.habr.com