W Opublikowaliśmy raport z prób wykorzystania Watchera. Takie testy okresowo przeprowadzamy, aby zrównoważyć oraz monitorować inne krytyczne funkcje dużego korporacyjnego lub operatorskiego chmury.
Wysoki poziom złożoności problemu, którego się podejmujemy, może wymagać kilku artykułów do szczegółowego opisania naszego projektu. Dziś publikujemy drugi artykuł z cyklu, poświęcony równoważeniu maszyn wirtualnych w chmurze.
Trochę terminologii
Firma VMware wprowadziła narzędzie DRS (Distributed Resource Scheduler) do balansowania obciążenia w opracowanym przez siebie środowisku wirtualizacji.
Jak pisze
VMware DRS (Planista Zasobów Rozproszonych) to narzędzie, które równoważy obciążenia wirtualne z dostępnymi zasobami w środowisku wirtualnym. Narzędzie to jest częścią pakietu wirtualizacji o nazwie VMware Infrastructure.
Dzięki VMware DRS użytkownicy określają zasady przydzielania zasobów fizycznych pomiędzy maszynami wirtualnymi (VM). Narzędzie może być skonfigurowane do ręcznego lub automatycznego zarządzania. Zestawy zasobów VMware można łatwo dodawać, usuwać lub reorganizować. W razie potrzeby zestawy zasobów mogą być izolowane pomiędzy różnymi jednostkami biznesowymi. Jeśli obciążenie robocze jednej lub kilku maszyn wirtualnych ulega nagłej zmianie, VMware DRS przemieszcza maszyny wirtualne pomiędzy serwerami fizycznymi. Jeśli ogólna liczba obciążenia spada, niektóre serwery fizyczne mogą zostać tymczasowo wyłączone, a obciążenie robocze skonsolidowane.
Po co jest równoważenie?
Uważamy, że DRS jest niezbędną funkcją chmury, ale nie oznacza to, że należy go używać zawsze i wszędzie. W zależności od przeznaczenia i potrzeb chmury mogą istnieć różne wymagania wobec DRS oraz metod równoważenia. Możliwe, że są sytuacje, w których równoważenie jest całkowicie zbędne, a nawet szkodliwe.
Aby lepiej zrozumieć, gdzie i dla jakich klientów DRS jest potrzebne, przyjrzyjmy się ich celom i zadaniom. Chmury można podzielić na publiczne i prywatne. Oto główne różnice między tymi chmurami a celami klientów.
Prywatne chmury / Duzi klienci korporacyjni
Publiczne chmury / Małe i średnie przedsiębiorstwa, osoby fizyczne
Główny kryterium i cele operatora
Zapewnienie niezawodnej usługi lub produktu
Obniżenie kosztów usług w walce na konkurencyjnym rynku
Wymagania dotyczące usługi
Niezawodność na wszystkich poziomach i we wszystkich elementach systemu
Gwarantowana wydajność
Priorytetyzacja maszyn wirtualnych w kilku kategoriach
Bezpieczeństwo informacji i fizyczne bezpieczeństwo danych
SLA i całodobowe wsparcie
Maksymalna prostota uzyskania usługi
Stosunkowo proste usługi
Odpowiedzialność za dane spoczywa na kliencie
Priorytetyzacja maszyn wirtualnych nie jest wymagana
Bezpieczeństwo informacji na poziomie standardowych usług, odpowiedzialność spoczywa na kliencie
Mogą wystąpić awarie
Brak SLA, jakość nie jest gwarantowana
Wsparcie mailowe
Kopie zapasowe nie są obowiązkowe
Cechy klienta
Bardzo szeroki zakres aplikacji.
Legacy aplikacje, dziedziczone w firmie.
Skomplikowane, dostosowane architektury dla każdego klienta.
Reguły atrybutów.
Działanie oprogramowania bez przestojów w trybie 7x24.
Środki do robienia kopii zapasowych „na żywo”.
Przewidywalne cykliczne obciążenie klienta.
Standardowe aplikacje – balansowanie sieci, Apache, WEB, VPN, SQL
Możliwość wstrzymania aplikacji na pewien czas
Dopuszczalne losowe rozmieszczenie maszyn wirtualnych w chmurze
Kopie zapasowe realizowane przez klienta
Przewidywalne obciążenie statystycznie uśrednione przy dużej liczbie klientów.
Konsekwencje dla architektury
Geo-klasteryzacja
Centralne lub rozproszone przechowywanie danych
Rezerwowane zasoby BBK
Lokalne przechowywanie danych na węzłach obliczeniowych
Cele balansowania
Równomierne rozłożenie obciążenia
Maksymalna responsywność aplikacji
Minimalny czas opóźnienia w balansowaniu
Balansowanie tylko w przypadku wyraźnej potrzeby
Wyłączenie części sprzętu na czas przeglądu
Obniżenie kosztów usługi i wydatków operatora
Wyłączenie części zasobów w przypadku niskiego obciążenia
Oszczędność energii elektrycznej
Zmniejszenie kosztów pracowniczych
Wyciągamy następujące wnioski:
Dla chmur prywatnych, dostarczanych dużym klientom korporacyjnym, DRS może być stosowane z uwzględnieniem ograniczeń:
- bezpieczeństwo informacji oraz uwzględnienie reguł atrybutów przy balansowaniu;
- posiadanie wystarczającej ilości zasobów w rezerwie w przypadku awarii;
- dane maszyn wirtualnych znajdują się w centralnej lub rozproszonej magazynie danych;
- rozłożenie w czasie działań administracyjnych, kopii zapasowych i balansowania;
- balansowanie tylko w obrębie grupy hostów klienta;
- balansowanie tylko w przypadku dużego dysbalansu, najbardziej efektywne i bezpieczne migracje VM (migracja może zakończyć się niepowodzeniem);
- balansowanie w odniesieniu do "spokojnych" maszyn wirtualnych (migracja "głośnych" maszyn wirtualnych może trwać bardzo długo);
- balansowanie z uwzględnieniem "kosztu" — obciążenia na macierzach dyskowych i sieci (przy dostosowanych architekturach dla dużych klientów);
- balansowanie z uwzględnieniem indywidualnych cech zachowania każdej VM;
- balansowanie najlepiej w czasie niepracującym (noc, weekendy, święta).
Dla publicznych chmur, które dostarczają usługi małym klientom, DRS może być stosowane znacznie częściej, z rozszerzonymi możliwościami:
- brak ograniczeń dotyczących bezpieczeństwa informacji i zasad affinity;
- balansowanie w obrębie chmury;
- balansowanie w każdym rozsądnym czasie;
- balansowanie każdej VM;
- balansowanie "głośnych" maszyn wirtualnych (aby nie przeszkadzać innym);
- dane maszyn wirtualnych często znajdują się na lokalnych dyskach;
- uwzględnienie uśrednionej wydajności macierzy dyskowej i sieci (architektura chmury jest jednolita);
- balansowanie według ogólnych zasad i dostępnych statystyk zachowania centrum danych.
Złożoność problemu
Złożoność balansowania polega na tym, że DRS musi działać z dużą liczbą nieokreślonych czynników:
- zachowanie użytkowników każdej z systemów informacyjnych klientów;
- algorytmy działania serwerów systemów informacyjnych;
- zachowanie serwerów DBMS;
- obciążenie zasobów obliczeniowych, macierzy dysków, sieci;
- interakcja serwerów ze sobą w walce o zasoby chmury.
Obciążenie dużej liczby wirtualnych serwerów aplikacji i baz danych na zasoby chmury rozprzestrzenia się w czasie, skutki mogą się pojawiać i nakładać na siebie w nieprzewidywalny sposób w nieprzewidywalnym czasie. Nawet do zarządzania relatywnie prostymi procesami (na przykład zarządzania silnikiem, systemem ogrzewania wodnego w domu) systemy automatycznego regulowania muszą stosować złożone algorytmy z informacją zwrotną.
Naszym zadaniem jest znacznie bardziej skomplikowane, i istnieje ryzyko, że system nie będzie w stanie przeprowadzić równoważenia obciążenia w rozsądnym czasie, nawet jeśli nie wystąpią zewnętrzne interakcje ze strony użytkowników.
Historia naszych opracowań
Aby rozwiązać ten problem, postanowiliśmy nie zaczynać od podstaw, lecz oprzeć się na istniejącym doświadczeniu i współpracować z ekspertami, którzy mają wiedzę w tej dziedzinie. Na szczęście nasze zrozumienie problematyki całkowicie się pokrywało.
Etap 1
Użyliśmy systemu opartego na technologii sieci neuronowych i spróbowaliśmy na jego podstawie zoptymalizować nasze zasoby.
Interes tego etapu polegał na przetestowaniu nowej technologii, a jego znaczenie – na zastosowaniu niestandardowego podejścia do rozwiązania problemu, gdzie w innych równych warunkach standardowe podejścia praktycznie wyczerpały się.
Uruchomiliśmy system i rzeczywiście zaczęło się równoważenie. Skala naszej chmury nie pozwoliła nam uzyskać optymistycznych wyników, które ogłosili deweloperzy, ale było widać, że równoważenie działa.
Jednocześnie mieliśmy do czynienia z dość poważnymi ograniczeniami:
- Aby wytrenować sieć neuronową, konieczne jest, aby wirtualne maszyny działały bez istotnych zmian przez tygodnie lub miesiące.
- Algorytm jest zaprojektowany do optymalizacji na podstawie analizy wcześniejszych danych 'historycznych'.
- Aby wytrenować sieć neuronową, potrzebna jest dość duża ilość danych i zasobów obliczeniowych.
- Optymalizację i równoważenie można przeprowadzać stosunkowo rzadko – raz na kilka godzin, co jest wyraźnie niewystarczające.
Etap 2
Ponieważ nie byliśmy zadowoleni z obecnego stanu rzeczy, postanowiliśmy zmodyfikować system, a w tym celu odpowiedzieć na kluczowe pytanie – dla kogo to robimy?
Na początku – dla klientów korporacyjnych. Oznacza to, że potrzebujemy systemu, który działa sprawnie, z tymi ograniczeniami korporacyjnymi, które jedynie uproszczają realizację.
Drugie pytanie – co rozumieć przez słowo 'sprawnie'? W wyniku krótkich debat postanowiliśmy, że możemy opierać się na czasie reakcji 5 – 10 minut, aby krótkoterminowe skoki nie wprowadzały systemu w rezonans.
Trzecie pytanie – jaki rozmiar równoważonej liczby serwerów wybrać?
To pytanie rozwiązało się samo. Zazwyczaj klienci nie tworzą dużych agregatów serwerów, co jest zgodne z zaleceniami zawartymi w artykule, aby ograniczyć agregaty do 30-40 serwerów.
Ponadto, segmentując pulę serwerów, ułatwiamy zadanie algorytmowi równoważenia obciążenia.
Czwarte pytanie – na ile odpowiednia jest dla nas sieć neuronowa z jej długim procesem uczenia się i rzadkimi równoważeniami? Podjęliśmy decyzję o rezygnacji z niej na rzecz prostszych algorytmów operacyjnych, aby uzyskać wyniki w ciągu sekund.
Z opisem systemu wykorzystującego takie algorytmy oraz jego wadami można się zapoznać
Zrealizowaliśmy i uruchomiliśmy ten system i uzyskaliśmy obiecujące wyniki – obecnie regularnie analizuje obciążenie chmury i daje rekomendacje dotyczące przenoszenia maszyn wirtualnych, które w dużej mierze są trafne. Już teraz widać, że możemy osiągnąć 10-15% zwolnienia zasobów dla nowych maszyn wirtualnych, poprawiając jednocześnie jakość pracy istniejących.
W przypadku wykrycia dysbalansu w RAM lub CPU system wydaje polecenia do harmonogramu Tionix w celu wykonania na żywo migracji wymaganych maszyn wirtualnych. Z systemu monitorowania widać, że maszyna wirtualna przeniosła się z jednego (górnego) na inny (dolny) host i zwolniła pamięć na górnym hoście (zaznaczone żółtymi kółkami), zajmując ją odpowiednio na dolnym (zaznaczone białymi kółkami).
Obecnie staramy się dokładniej ocenić efektywność działającego algorytmu i próbujemy znaleźć w nim możliwe błędy.
Etap 3
Wydawałoby się, że na tym można poprzestać, poczekać na udowodnioną efektywność i zamknąć temat.
Jednak nowe oczywiste możliwości optymalizacji popychają nas do przeprowadzenia nowego etapu
- Statystyka na przykład i pokazuje, że systemy dwuprocesorowe i czteroprocesorowe mają znacznie gorszą wydajność niż systemy jednoprosesorowe. Oznacza to, że wszyscy użytkownicy otrzymują znacznie gorszy zwrot z inwestycji w zakupionych w systemach wieloprocesorowych CPU, RAM, SSD, LAN, FC w porównaniu z systemami jednoprosesorowymi.
- Same harmonogramy zasobów mogą działać z poważnymi błędami, na ten temat.
- Technologie monitorowania RAM i cache oferowane przez firmy Intel i AMD pozwalają na badanie zachowania wirtualnych maszyn oraz ich rozmieszczanie w taki sposób, aby "hałaśliwi" sąsiedzi nie przeszkadzali "spokojnym" maszynom wirtualnym.
- Rozszerzenie zestawu parametrów (sieć, pamięć masowa, priorytet maszyny wirtualnej, koszt migracji, jej gotowość do migracji).
Podsumowując
Wyniki naszej pracy nad udoskonaleniem algorytmów bilansowania wskazują jednoznacznie, że dzięki nowoczesnym algorytmom można osiągnąć znaczną optymalizację zasobów (25-30%) w centrach danych, jednocześnie poprawiając jakość obsługi klientów.
Algorytm oparty na sieciach neuronowych jest z pewnością interesującym rozwiązaniem, ale wymaga dalszego rozwoju i jest z uwagi na istniejące ograniczenia nieodpowiedni do rozwiązywania tego rodzaju problemów na wolumenach charakterystycznych dla prywatnych chmur. W publicznych chmurach o znacznych rozmiarach algorytm wykazał dobre wyniki.
Więcej na temat możliwości procesorów, planistów i wysokopoziomowego bilansowania omówimy w kolejnych artykułach.
Źródło: habr.com
