W dużych systemach chmurowych kwestia automatycznego równoważenia lub wyrównywania obciążenia zasobów obliczeniowych jest szczególnie dotkliwa. Tionix (deweloper i operator usług chmurowych, część grupy spółek Rostelecom) zadbał także o tę kwestię.
A ponieważ naszą główną platformą programistyczną jest Openstack, a my, jak wszyscy, jesteśmy leniwi, zdecydowano się wybrać jakiś gotowy moduł, który jest już zawarty w platformie. Nasz wybór padł na Watchera, którego postanowiliśmy wykorzystać do swoich potrzeb.
Najpierw przyjrzyjmy się terminom i definicjom.
Terminy i definicje
cel to czytelny dla człowieka, obserwowalny i mierzalny wynik końcowy, który należy osiągnąć. Istnieje jedna lub więcej strategii osiągnięcia każdego celu. Strategia to implementacja algorytmu, który jest w stanie znaleźć rozwiązanie dla danego celu.
Działanie to elementarne zadanie zmieniające aktualny stan docelowego zasobu zarządzanego klastra OpenStack, takie jak: migracja maszyny wirtualnej (migracja), zmiana stanu zasilania węzła (change_node_power_state), zmiana stanu usługi nova (change_nova_service_state ), zmiana smaku (resize), rejestracja wiadomości NOP (nop), brak akcji przez określony czas - pauza (uśpienie), transfer dysku (volume_migrate).
Plan działania - określony ciąg działań prowadzonych w określonej kolejności, aby osiągnąć konkretny Cel. Plan Działań zawiera także zmierzone globalne wyniki wraz z zestawem wskaźników efektywności. Po pomyślnym audycie Watcher generuje plan działania, w wyniku którego zastosowana strategia znajduje rozwiązanie umożliwiające osiągnięcie celu. Plan działania składa się z listy kolejnych działań.
Rewizja jest żądaniem optymalizacji klastra. Optymalizacja dokonywana jest w celu osiągnięcia jednego Celu w danym klastrze. Dla każdego zakończonego sukcesem audytu Watcher generuje Plan Działania.
Zakres audytu to zbiór zasobów, w ramach których przeprowadzany jest audyt (strefy dostępności, agregatory węzłów, pojedyncze węzły obliczeniowe lub węzły magazynowania itp.). Zakres audytu jest zdefiniowany w każdym szablonie. Jeśli zakres kontroli nie zostanie określony, audytowi zostanie poddany cały klaster.
Szablon audytu — zapisany zestaw ustawień uruchomienia audytu. Aby wielokrotnie uruchamiać audyty z tymi samymi ustawieniami, potrzebne są szablony. Szablon musi koniecznie zawierać cel audytu; jeśli nie określono strategii, wybierane są najbardziej odpowiednie istniejące strategie.
Grupa to zbiór maszyn fizycznych zapewniających zasoby obliczeniowe, magazynowe i sieciowe, zarządzanych przez ten sam węzeł zarządzania OpenStack.
Model danych klastra (CDM) jest logiczną reprezentacją bieżącego stanu i topologii zasobów zarządzanych przez klaster.
Wskaźnik wydajności - wskaźnik wskazujący, jak realizowane jest rozwiązanie stworzone przy użyciu tej strategii. Wskaźniki wydajności są specyficzne dla konkretnego celu i zazwyczaj służą do obliczenia ogólnej efektywności powstałego planu działania.
Specyfikacja skuteczności to zestaw specyficznych cech związanych z każdym Celem, który definiuje różne wskaźniki wydajności, które strategia osiągnięcia odpowiedniego Celu musi osiągnąć w swoim rozwiązaniu. Rzeczywiście, każde rozwiązanie zaproponowane w strategii zostanie sprawdzone pod kątem specyfikacji przed obliczeniem jego globalnej efektywności.
Silnik punktacji to plik wykonywalny, który ma dobrze zdefiniowane dane wejściowe i dobrze zdefiniowane dane wyjściowe i wykonuje zadanie czysto matematyczne. W ten sposób obliczenia są niezależne od środowiska, w którym są przeprowadzane – wszędzie dadzą ten sam wynik.
Planista obserwatorów - część silnika decyzyjnego Watcher. Moduł ten pobiera zestaw działań wygenerowanych przez strategię i tworzy plan przepływu pracy, który określa, w jaki sposób zaplanować te różne działania w czasie i jakie są warunki wstępne dla każdego działania.
Cele i strategie obserwatorów
cel
Strategie
Fałszywy cel
Sztuczna strategia
Sztuczna strategia wykorzystująca przykładowe silniki scoringowe
Sztuczna strategia ze zmianą rozmiaru
Oszczędzanie energii
Strategia oszczędzania energii
Konsolidacja serwerów
Podstawowa konsolidacja serwerów offline
Strategia konsolidacji obciążenia maszyny wirtualnej
Równoważenie obciążenia
Strategia migracji równoważenia obciążenia
Strategia bilansowania pojemności pamięci masowej
Stabilizacja obciążenia
Hałaśliwy sąsiad
Hałaśliwy sąsiad
Optymalizacja termiczna
Strategia oparta na temperaturze wylotowej
Optymalizacja przepływu powietrza
Jednolita strategia migracji przepływu powietrza
Konserwacja sprzętu
Migracja stref
Niesklasyfikowane
Siłownik
Fałszywy cel — zarezerwowany cel używany do celów testowych.
Powiązane strategie: Strategia fikcyjna, Strategia fikcyjna wykorzystująca przykładowe silniki punktacji i Strategia fikcyjna ze zmianą rozmiaru. Strategia fikcyjna to strategia fikcyjna używana do testowania integracji za pośrednictwem Tempest. Strategia ta nie zapewnia żadnej użytecznej optymalizacji, jej jedynym celem jest wykorzystanie testów Tempest.
Strategia fikcyjna z wykorzystaniem przykładowych silników scoringowych - strategia jest podobna do poprzedniej, jedyną różnicą jest zastosowanie przykładowego „silnika scoringowego”, który przeprowadza obliczenia z wykorzystaniem metod uczenia maszynowego.
Sztuczna strategia ze zmianą rozmiaru - strategia jest podobna do poprzedniej, jedyną różnicą jest zastosowanie zmiany smaku (migracja i zmiana rozmiaru).
Nie używany w produkcji.
Oszczędzanie energii — zminimalizować zużycie energii. Strategia oszczędzania energii tego celu, wraz ze strategią konsolidacji obciążenia maszyny wirtualnej (konsolidacja serwera), umożliwia korzystanie z funkcji dynamicznego zarządzania energią (DPM), które oszczędzają energię poprzez dynamiczną konsolidację obciążeń nawet w okresach niskiego wykorzystania zasobów: maszyny wirtualne są przenoszone do mniejszej liczby węzłów , a niepotrzebne węzły są wyłączone. Po konsolidacji strategia oferuje decyzję o włączeniu/wyłączeniu węzłów zgodnie z określonymi parametrami: „min_free_hosts_num” – liczba wolnych węzłów oczekujących na obciążenie oraz „free_used_percent” – procent wolnych hostów włączonych do liczba węzłów zajmowanych przez maszyny. Aby strategia zadziałała, musi istnieć włączono i skonfigurowano Ironic do obsługi przełączania zasilania węzłów.
Parametry strategii
parametr
Typ
domyślnie
описание
darmowy_wykorzystany_procent
Numer
10.0
stosunek liczby wolnych węzłów obliczeniowych do liczby węzłów obliczeniowych z maszynami wirtualnymi
min_free_hosts_num
Int
1
minimalna liczba wolnych węzłów obliczeniowych
Chmura musi mieć co najmniej dwa węzły. Zastosowaną metodą jest zmiana stanu zasilania węzła (change_node_power_state). Strategia nie wymaga zbierania metryk.
Konsolidacja serwerów - minimalizacja liczby węzłów obliczeniowych (konsolidacja). Ma dwie strategie: podstawową konsolidację serwerów offline i strategię konsolidacji obciążenia maszyn wirtualnych.
Strategia podstawowej konsolidacji serwerów offline minimalizuje całkowitą liczbę używanych serwerów, a także minimalizuje liczbę migracji.
Podstawowa strategia wymaga następujących wskaźników:
metryka
usługa
wtyczki
komentarz
procent węzła obliczeniowego. procesora
Żaden
cpu_util
Żaden
Parametry strategii: migracja_attempts - liczba kombinacji do wyszukiwania potencjalnych kandydatów do zamknięcia (domyślnie 0, bez ograniczeń), okres - przedział czasu w sekundach na uzyskanie agregacji statycznej ze źródła danych metrycznych (domyślnie 700).
Wykorzystane metody: migracja, zmiana stanu usługi nova (change_nova_service_state).
Strategia konsolidacji obciążenia maszyny wirtualnej opiera się na heurystyce pierwszego dopasowania, która koncentruje się na zmierzonym obciążeniu procesora i próbuje zminimalizować węzły, które mają za duże lub za małe obciążenie, biorąc pod uwagę ograniczenia pojemności zasobów. Strategia ta zapewnia rozwiązanie, które skutkuje bardziej efektywnym wykorzystaniem zasobów klastra w czterech krokach:
- Faza rozładunku – przetwarzanie nadmiernie wykorzystanych zasobów;
- Faza konsolidacji – zagospodarowanie niewykorzystanych zasobów;
- Optymalizacja rozwiązania – zmniejszenie liczby migracji;
- Wyłączanie nieużywanych węzłów obliczeniowych.
Strategia wymaga następujących wskaźników:
metryka
usługa
wtyczki
komentarz
pamięć
Żaden
rozmiar.root.dysku
Żaden
Poniższe wskaźniki są opcjonalne, ale jeśli są dostępne, poprawią dokładność strategii:
metryka
usługa
wtyczki
komentarz
pamięć.rezydent
Żaden
cpu_util
Żaden
Parametry strategii: okres — przedział czasu w sekundach, w którym należy uzyskać agregację statyczną ze źródła danych metrycznych (domyślnie 3600).
Używa tych samych metod, co poprzednia strategia. Więcej szczegółów .
Równoważenie obciążenia — zrównoważyć obciążenie pomiędzy węzłami obliczeniowymi. Cel ma trzy strategie: Strategię migracji równoważenia obciążenia, Stabilizacji obciążenia, Strategii równoważenia pojemności pamięci masowej.
Strategia migracji równoważenia obciążenia uruchamia migracje maszyn wirtualnych w oparciu o obciążenie maszyny wirtualnej hosta. Decyzja o migracji jest podejmowana zawsze, gdy procent wykorzystania procesora lub pamięci RAM węzła przekracza określony próg. W takim przypadku przeniesiona maszyna wirtualna powinna przybliżyć węzeł do średniego obciążenia wszystkich węzłów.
Wymagania
- Korzystanie z procesorów fizycznych;
- Co najmniej dwa fizyczne węzły obliczeniowe;
- Zainstalowano i skonfigurowano komponent Ceilometer – ceilometer-agent-compute, działający na każdym węźle obliczeniowym oraz interfejs API Ceilometer, a także zbierając następujące metryki:
metryka
usługa
wtyczki
komentarz
cpu_util
Żaden
pamięć.rezydent
Żaden
Parametry strategii:
parametr
Typ
domyślnie
описание
metryka
sznur
„użycie_procesora”
Podstawowymi metrykami są: „cpu_util”, „memory.resident”.
próg
Numer
25.0
Próg obciążenia dla migracji.
okres
Numer
300
Skumulowany okres czasu Ceilometr.
Stosowaną metodą jest migracja.
Stabilizacja obciążenia to strategia mająca na celu stabilizację obciążenia za pomocą migracji na żywo. Strategia opiera się na algorytmie odchylenia standardowego i określa, czy w klastrze występują przeciążenia, i reaguje na nie, uruchamiając migrację maszyn w celu ustabilizowania klastra.
Wymagania
- Korzystanie z procesorów fizycznych;
- Co najmniej dwa fizyczne węzły obliczeniowe;
- Zainstalowano i skonfigurowano komponent Ceilometer – ceilometer-agent-compute, działający na każdym węźle obliczeniowym oraz interfejs API Ceilometer, a także zbierając następujące metryki:
metryka
usługa
wtyczki
komentarz
cpu_util
Żaden
pamięć.rezydent
Żaden
Strategia równoważenia pojemności magazynowej (strategia wdrażana począwszy od Queens) - strategia transferuje dyski w zależności od obciążenia pul Cinder. Decyzja o przeniesieniu podejmowana jest zawsze, gdy stopień wykorzystania puli przekroczy określony próg. Przenoszony dysk powinien przybliżyć pulę do średniego obciążenia wszystkich pul Cinder.
Wymagania i ograniczenia
- Minimum dwie pule Cinder;
- Możliwość migracji dysku.
- Model danych klastra — moduł zbierający modele danych klastrów Cinder.
Parametry strategii:
parametr
Typ
domyślnie
описание
próg_objętości
Numer
80.0
Wartość progowa dysków do równoważenia woluminów.
Stosowaną metodą jest migracja dysku (volume_migrate).
Hałaśliwy sąsiad — zidentyfikuj i migruj „hałaśliwego sąsiada” — maszynę wirtualną o niskim priorytecie, która negatywnie wpływa na wydajność maszyny wirtualnej o wysokim priorytecie pod względem IPC poprzez nadmierne wykorzystanie pamięci podręcznej ostatniego poziomu. Własna strategia: Noisy Neighbor (używany parametr strategii to cache_threshold (wartość domyślna to 35), gdy wydajność spadnie do określonej wartości, rozpoczyna się migracja. Aby strategia zadziałała, włączona metryki LLC (Last Level Cache), najnowszy serwer Intel z obsługą CMT, a także zbieranie następujących wskaźników:
metryka
usługa
wtyczki
komentarz
pamięć podręczna procesora_l3
Żaden
Wymagany Intel .
Model danych klastra (domyślny): moduł zbierający model danych klastra Nova. Stosowaną metodą jest migracja.
Praca nad tym celem za pośrednictwem Panelu nie jest w pełni zaimplementowana w Queens.
Optymalizacja termiczna — zoptymalizować reżim temperaturowy. Temperatura wylotowa (powietrza wywiewanego) to jeden z ważnych systemów telemetrii termicznej służący do pomiaru stanu termicznego/obciążenia serwera. Cel ma jedną strategię, strategię opartą na temperaturze wylotowej, która decyduje o migracji obciążeń do hostów korzystnych termicznie (najniższa temperatura wylotowa), gdy temperatura wylotowa hostów źródłowych osiągnie konfigurowalny próg.
Aby strategia zadziałała, potrzebny jest serwer z zainstalowanym i skonfigurowanym programem Intel Power Node Manager , a także zbieranie następujących wskaźników:
metryka
usługa
wtyczki
komentarz
hardware.ipmi.node.outlet_temperature
IPMI
Parametry strategii:
parametr
Typ
domyślnie
описание
próg
Numer
35.0
Próg temperaturowy migracji.
okres
Numer
30
Przedział czasu (w sekundach), w którym należy uzyskać agregację statystyczną ze źródła danych metryki.
Stosowaną metodą jest migracja.
Optymalizacja przepływu powietrza — zoptymalizować tryb wentylacji. Własna strategia - Uniform Airflow z wykorzystaniem migracji na żywo. Strategia uruchamia migrację maszyny wirtualnej za każdym razem, gdy przepływ powietrza z wentylatora serwera przekroczy określony próg.
Aby strategia zadziałała, potrzebujesz:
- Sprzęt: węzły obliczeniowe < obsługujące NodeManager 3.0;
- Co najmniej dwa węzły obliczeniowe;
- Komponent ceilometer-agent-compute i Ceilometer API zainstalowany i skonfigurowany na każdym węźle obliczeniowym, który może z powodzeniem raportować takie wskaźniki, jak przepływ powietrza, moc systemu, temperatura na wlocie:
metryka
usługa
wtyczki
komentarz
sprzęt.ipmi.node.airflow
IPMI
temperatura.sprzętu.ipmi.node
IPMI
hardware.ipmi.node.power
IPMI
Aby strategia zadziałała, potrzebny jest serwer z zainstalowanym i skonfigurowanym oprogramowaniem Intel Power Node Manager 3.0 lub nowszym.
Ograniczenia: Koncepcja nie jest przeznaczona do produkcji.
Proponuje się stosowanie tego algorytmu przy audytach ciągłych, ponieważ w jednej iteracji planowana jest migracja tylko jednej maszyny wirtualnej.
Możliwe są migracje na żywo.
Parametry strategii:
parametr
Typ
domyślnie
описание
próg_przepływu powietrza
Numer
400.0
Próg przepływu powietrza dla jednostki migracji wynosi 0.1CFM
próg_wlot_t
Numer
28.0
Próg temperatury na wlocie dla decyzji o migracji
próg_moc
Numer
350.0
Próg mocy systemu dla decyzji o migracji
okres
Numer
30
Przedział czasu (w sekundach), w którym należy uzyskać agregację statystyczną ze źródła danych metryki.
Stosowaną metodą jest migracja.
Konserwacja sprzętu — konserwacja sprzętu. Strategią związaną z tym celem jest migracja stref. Strategia jest narzędziem do skutecznej automatycznej i minimalnej migracji maszyn wirtualnych i dysków w przypadku konieczności konserwacji sprzętu. Strategia buduje plan działania według wag: zestaw działań o większej wadze zostanie zaplanowany przed innymi. Istnieją dwie opcje konfiguracji: action_weights i równoległość.
Ograniczenia: należy skonfigurować wagi akcji i równoległość.
Parametry strategii:
parametr
Typ
domyślnie
описание
węzły_obliczeniowe
szyk
żaden
Węzły obliczeniowe na potrzeby migracji.
pule_przechowywania
szyk
żaden
Węzły magazynowania do migracji.
równolegle_łącznie
liczba całkowita
6
Całkowita liczba działań, które muszą być wykonane równolegle.
równoległy_na_węzeł
liczba całkowita
2
Liczba akcji wykonywanych równolegle dla każdego węzła obliczeniowego.
równoległy_na_pulę
liczba całkowita
2
Liczba czynności wykonywanych równolegle dla każdej puli pamięci.
priorytet
przedmiot
żaden
Lista priorytetów dla maszyn wirtualnych i dysków.
z_dołączonym_woluminem
boolean
Fałszywy
Fałsz — maszyny wirtualne zostaną przeniesione po migracji wszystkich dysków. Prawda — maszyny wirtualne zostaną przeniesione po migracji wszystkich podłączonych dysków.
Elementy macierzy węzłów obliczeniowych:
parametr
Typ
domyślnie
описание
węzeł_źródła
ciąg
żaden
Węzeł obliczeniowy, z którego migrowane są maszyny wirtualne (wymagane).
dst_node
ciąg
żaden
Oblicz węzeł, do którego migrują maszyny wirtualne.
Elementy tablicy węzła magazynowania:
parametr
Typ
domyślnie
описание
src_pool
ciąg
żaden
Pula pamięci, z której migrowane są dyski (wymagane).
dst_pool
ciąg
żaden
Pula magazynu, do której migrowane są dyski.
typ_źródła
ciąg
żaden
Oryginalny typ dysku (wymagany).
typ_dst
ciąg
żaden
Wynikowy typ dysku (wymagany).
Elementy priorytetu obiektu:
parametr
Typ
domyślnie
описание
projekt
szyk
żaden
Nazwy projektów.
węzeł_obliczeniowy
szyk
żaden
Oblicz nazwy węzłów.
pula_przechowywania
szyk
żaden
Nazwy pul pamięci.
obliczać
wyliczanie
żaden
Parametry maszyny wirtualnej [„vcpu_num”, „mem_size”, „disk_size”, „created_at”].
przechowywanie
wyliczanie
żaden
Parametry dysku [„rozmiar”, „utworzony_at”].
Stosowane metody to migracja maszyn wirtualnych, migracja dysków.
Niesklasyfikowane - cel pomocniczy, służący ułatwieniu procesu tworzenia strategii. Nie zawiera żadnych specyfikacji i można go zastosować zawsze, gdy strategia nie jest jeszcze powiązana z istniejącym celem. Cel ten może być również wykorzystany jako punkt przejściowy. Strategią powiązaną z tym celem jest Actuator.
Tworzenie nowego celu
Silnik decyzyjny obserwatora posiada interfejs wtyczki „cel zewnętrzny”, który umożliwia integrację celu zewnętrznego, który można osiągnąć za pomocą strategii.
Zanim utworzysz nowy cel, upewnij się, że żaden z istniejących celów nie odpowiada Twoim potrzebom.
Tworzenie nowej wtyczki
Aby utworzyć nowy cel należy: rozszerzyć klasę docelową, zaimplementować metodę klasy get_name() aby zwrócić unikalny identyfikator nowego celu, który chcesz utworzyć. Ten unikalny identyfikator musi być zgodny z nazwą punktu wejścia, którą zadeklarujesz później.
Następnie musisz zaimplementować metodę klasową get_display_name() aby zwrócić przetłumaczoną nazwę wyświetlaną celu, który chcesz utworzyć (nie używaj zmiennej do zwrócenia przetłumaczonego ciągu, aby mógł zostać automatycznie zebrany przez narzędzie do tłumaczenia).
Zaimplementuj metodę klasową get_translatable_display_name()aby zwrócić klucz tłumaczenia (właściwie angielską nazwę wyświetlaną) nowego celu. Zwracana wartość musi być zgodna z ciągiem przetłumaczonym na funkcję get_display_name().
Wdrażaj jego metodę get_efficiacy_specification()aby zwrócić specyfikację wydajności dla swojego celu. Metoda get_efficiacy_specification() zwraca instancję Unclassified() dostarczoną przez Watcher. Ta specyfikacja wydajności jest przydatna w procesie opracowywania celu, ponieważ odpowiada pustej specyfikacji.
→
Architektura obserwatora (więcej szczegółów) ).
Components
API obserwatora - komponent implementujący REST API udostępniany przez firmę Watcher. Mechanizmy interakcji: CLI, wtyczka Horizon, Python SDK.
Obserwator DB — Baza danych obserwatorów.
Aplikator Obserwatora — komponent implementujący wykonanie planu działania stworzonego przez komponent Watcher Decision Engine.
Silnik decyzyjny obserwatora - Komponent odpowiedzialny za obliczenie zestawu potencjalnych działań optymalizacyjnych, aby osiągnąć cel audytu. Jeżeli strategia nie jest określona, komponent samodzielnie wybiera najwłaściwszą.
Wydawca metryk obserwatorów - Komponent, który zbiera i oblicza niektóre metryki lub zdarzenia i publikuje je w punkcie końcowym CEP. Funkcjonalność komponentu może również zapewnić wydawca Ceilometer.
Silnik przetwarzania złożonych zdarzeń (CEP). — silnik do złożonego przetwarzania zdarzeń. Ze względu na wydajność może jednocześnie działać wiele instancji aparatu CEP, a każda z nich przetwarza określony typ metryki/zdarzenia. W systemie Watcher CEP uruchamia dwa typy akcji: - rejestruje odpowiednie zdarzenia/metryki w bazie danych szeregów czasowych; - wysyłaj odpowiednie zdarzenia do silnika decyzyjnego Watcher, gdy zdarzenie to może mieć wpływ na wynik bieżącej strategii optymalizacji, ponieważ klaster Openstack nie jest systemem statycznym.
Komponenty współdziałają przy użyciu protokołu AMQP.
→
Schemat interakcji z Obserwatorem
Wyniki testu obserwatora
- Na stronie Optymalizacja - Plany działania 500 (zarówno na czystym Queens, jak i na stojaku z modułami Tionix) pojawia się dopiero po uruchomieniu audytu i wygenerowaniu planu działania; pusty otwiera się normalnie.
- W zakładce Szczegóły akcji pojawiają się błędy, nie można uzyskać celu i strategii audytu (zarówno na czystych Queens jak i na stoisku z modułami Tionix).
- Audyty w celu Dummy (test) są tworzone i uruchamiane normalnie, generowane są plany działania.
- Audyty dla celu Niesklasyfikowane nie są tworzone, ponieważ cel nie jest funkcjonalny i przeznaczony jest do pośredniej konfiguracji przy tworzeniu nowych strategii.
- Audyty na potrzeby równoważenia obciążenia (strategia równoważenia pojemności pamięci masowej) są tworzone pomyślnie, ale nie jest generowany plan działania. Nie jest wymagana optymalizacja puli pamięci.
- Audyty dla celu Równoważenie obciążenia (Strategia migracji równoważenia obciążenia) są tworzone pomyślnie, ale nie jest generowany plan działania.
- Audyty równoważenia obciążenia pracą (strategia stabilizacji obciążenia) kończą się niepowodzeniem.
- Audyty dla celu Noisy Neighbor zostały utworzone pomyślnie, ale nie został wygenerowany plan działania.
- Audyty na potrzeby utrzymania sprzętu są tworzone pomyślnie, plan działań nie jest generowany w całości (generowane są wskaźniki wydajności, ale nie jest generowana sama lista działań).
- Zmiany w konfiguracjach nova.conf (w domyślnej sekcji compute_monitors = cpu.virt_driver) w węzłach obliczeniowych i kontrolnych nie korygują błędów.
- Audyty ukierunkowane na konsolidację serwerów (strategia podstawowa) również kończą się niepowodzeniem.
- Audyty na potrzeby konsolidacji serwerów (strategia konsolidacji obciążenia maszyny wirtualnej) kończą się niepowodzeniem z powodu błędu. W logach występuje błąd w pozyskaniu danych źródłowych. W szczególności omówienie błędu .
Próbowaliśmy określić Watchera w pliku konfiguracyjnym (nie pomogło - w wyniku błędu na wszystkich stronach Optymalizacji powrót do oryginalnej zawartości pliku konfiguracyjnego nie poprawia sytuacji): [watcher_strategies.basic] źródło danych = ceilometr, gnocchi - Audyty dotyczące oszczędzania energii kończą się niepowodzeniem. Sądząc po logach problemem nadal jest brak Ironic'a, bez serwisu baremetal nie będzie działać.
- Audyty optymalizacji termicznej kończą się niepowodzeniem. Śledzenie jest takie samo jak w przypadku konsolidacji serwerów (strategia konsolidacji obciążenia maszyny wirtualnej) (błąd danych źródłowych)
- Audyty mające na celu optymalizację przepływu powietrza kończą się niepowodzeniem z powodu błędu.
Występują również następujące błędy zakończenia audytu. Śledzenie w dziennikach Decision-Engine.log (stan klastra nie jest zdefiniowany).
→ Omówienie błędu
wniosek
Efektem naszych dwumiesięcznych badań był jednoznaczny wniosek, że aby uzyskać pełnoprawny, działający system równoważenia obciążenia, będziemy musieli w tej części ściśle współpracować nad dopracowaniem narzędzi dla platformy Openstack.
Watcher okazał się poważnym i szybko rozwijającym się produktem o ogromnym potencjale, którego pełne wykorzystanie będzie wymagało dużo poważnej pracy.
Ale o tym więcej w kolejnych artykułach z serii.
Źródło: www.habr.com