W dużych systemach chmurowych szczególnie istotne jest zagadnienie automatycznego bilansowania lub wyrównywania obciążenia na zasobach obliczeniowych. Tą kwestią zajmują się również w Tioniksie (deweloper i operator usług chmurowych, część grupy kapitałowej Rostelekom).
A ponieważ naszą główną platformą deweloperską jest OpenStack, a my, jak wszyscy ludzie, jesteśmy leniwi, postanowiono znaleźć jakiś gotowy moduł, który już jest w składzie platformy. Nasz wybór padł na Watcher, którego postanowiliśmy użyć do naszych potrzeb.
Na początek przyjrzyjmy się terminom i definicjom.
Terminy i definicje
Cel — to wynik, który jest czytelny dla człowieka, obserwowalny i dający się zmierzyć, który ma być osiągnięty. W celu realizacji każdego celu istnieje jedna lub więcej strategii. Strategia to wdrożenie algorytmu, który jest w stanie znaleźć rozwiązanie dla danego celu.
Działanie (Action) — to podstawowe zadanie, które zmienia bieżący stan kontrolowanego zasobu klastra OpenStack, takie jak: migracja maszyny wirtualnej (migration), zmiana stanu zasilania węzła (change_node_power_state), zmiana stanu usługi nova (change_nova_service_state), zmiana rozmiaru (resize), rejestracja wiadomości NOP (nop), brak działań przez określony czas — pauza (sleep), migrowanie dysku (volume_migrate).
Plan działania (Action Plan) — to specyficzny ciąg działań, wykonywanych w określonej kolejności w celu osiągnięcia konkretnego celu. Plan działania zawiera także ocenianą globalną skuteczność z zestawem wskaźników efektywności. Plan działania jest generowany przez Watcher po pomyślnym audycie, w wyniku którego zastosowana strategia znajduje rozwiązanie dla osiągnięcia celu. Plan działania składa się z listy kolejnych działań.
Audyt (Audit) — to zapytanie o optymalizację klastra. Optymalizacja jest przeprowadzana w celu osiągnięcia jednego celu w danym klastrze. Dla każdego pomyślnego audytu Watcher generuje plan działania.
Zakres audytu (Audit Scope) — to zestaw zasobów, w ramach którego przeprowadza się audyt (strefa(y) dostępności, agregatory węzłów, poszczególne węzły obliczeniowe lub węzły przechowywania itp.). Zakres audytu jest określony w każdym szablonie. Jeżeli nie wskazano zakresu audytu, audyt obejmuje cały klaster.
Szablon audytu (Audit Template) — zapisany zestaw ustawień do przeprowadzenia audytu. Szablony są potrzebne, aby wielokrotnie uruchamiać audyty z tymi samymi ustawieniami. Szablon musi zawierać cel audytu, a jeżeli strategie nie są podane, wybierane są najbardziej odpowiednie z istniejących strategii.
Klaster (Cluster) — to zestaw fizycznych maszyn, które dostarczają zasoby obliczeniowe, zasoby pamięci i zasoby sieciowe oraz są zarządzane przez ten sam węzeł zarządzający OpenStack.
Model danych klastra (Cluster Data Model, CDM) — to logiczna reprezentacja obecnego stanu i topologii zarządzanych przez klaster zasobów.
Wskaźnik efektywności (Efficacy Indicator) — wskaźnik, który pokazuje, jak realizowane jest rozwiązanie stworzone za pomocą danej strategii. Wskaźniki efektywności są specyficzne dla konkretnego celu i zwykle używane są do obliczania globalnej efektywności końcowego planu działania.
Specyfikacja efektywności (Efficacy Specification) — to zestaw specyficznych cech związanych z każdym celem, który definiuje różne wskaźniki efektywności, które strategia, zapewniająca osiągnięcie danego celu, musi zapewniać w swoim rozwiązaniu. Każde rozwiązanie zaproponowane przez strategię będzie weryfikowane pod kątem zgodności ze specyfikacją, zanim obliczy się jego globalną efektywność.
Silnik obliczeniowy (Scoring Engine) — to plik wykonywalny, który ma wyraźnie określone dane wejściowe, wyraźnie określone dane wyjściowe i wykonuje czysto matematyczne zadanie. W ten sposób, obliczenia nie zależą od środowiska, w którym są wykonywane — dadzą ten sam rezultat w każdym miejscu.
Planista Watcher (Watcher Planner) — część mechanizmu podejmowania decyzji Watcher. Ten moduł przyjmuje zestaw działań generowanych przez strategię i tworzy plan roboczy, który określa, jak w czasie planować te różne działania oraz jakie są warunki wstępne dla każdego działania.
Cele i strategie Watcher
Cel
Strategie
Dummy goal
Dummy Strategy
Dummy Strategy using sample Scoring Engines
Dummy strategy with resize
Oszczędzanie energii
Strategia oszczędzania energii
Konsolidacja serwerów
Podstawowa konsolidacja serwerów offline
Strategia konsolidacji obciążenia VM
Zrównoważenie obciążenia
Strategia migracji równowagi obciążenia
Strategia równowagi pojemności magazynowej
Stabilizacja obciążenia
Noisy Neighbor
Noisy Neighbor
Optymalizacja termalna
Strategia oparta na temperaturze wylotu
Optymalizacja przepływu powietrza
Strategia migracji z jednolitym przepływem powietrza
Konserwacja sprzętu
Migracja strefy
Niezdefiniowane
Siłownik
Dummy goal — zarezerwowana cel, który jest używany do testowania (reserved goal that is used for testing purposes).
Powiązane strategie: Dummy Strategy, Dummy Strategy using sample Scoring Engines oraz Dummy strategy with resize. Dummy strategy — to fikcyjna strategia używana do testowania integracyjnego przez Tempest. Strategia ta nie zapewnia żadnej użytecznej optymalizacji, jej jedynym celem jest wykorzystanie testów Tempest.
Dummy strategy using sample Scoring Engines — strategia podobna do poprzedniej, różni się tylko wykorzystaniem próbki „silnika oceny”, który przeprowadza obliczenia przy użyciu metod uczenia maszynowego.
Dummy strategy with resize — strategia podobna do poprzedniej, różni się tylko wykorzystaniem zmiany flavor (migracja i resize).
Nie używane w produkcji.
Oszczędzanie energii — minimalizować zużycie energii. Strategia tego celu, Saving Energy Strategy, wspólnie ze strategią VM Workload Consolidation Strategy (Konsolidacja serwerów) jest w stanie realizować funkcje dynamicznego zarządzania zasilaniem (DPM), co pozwala oszczędzać energię elektryczną poprzez dynamiczną konsolidację obciążeń nawet w okresach niskiego wykorzystania zasobów: maszyny wirtualne są przenoszone na mniejszą liczbę węzłów, a niepotrzebne węzły są wyłączane. Po konsolidacji strategia proponuje rozwiązanie dotyczące włączania/wyłączania węzłów w zależności od określonych parametrów: “min_free_hosts_num” — liczba wolnych włączonych węzłów oczekujących na obciążenie oraz “free_used_percent” — procentowe współczesne wolnych włączonych węzłów do liczby węzłów zajętych przez maszyny. Aby strategia mogła działać, Ironic musi być włączony i skonfigurowany do pracy z włączaniem/wyłączaniem zasilania na węzłach.
Parametry strategii
parametr
typ
domyślnie
opis
free_used_percent
Liczba
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
W chmurze musi być co najmniej dwa węzły. Używana metoda to zmiana stanu zasilania węzła (change_node_power_state). Zbieranie metryk strategia nie wymaga.
Konsolidacja serwerów — minimalizacja liczby węzłów obliczeniowych (konsolidacja). Ma dwie strategie: Podstawowa Konsolidacja Offline Serwera oraz Strategia Konsolidacji Obciążenia Maszyn Wirtualnych.
Strategia Podstawowej Konsolidacji Offline Serwera minimalizuje całkowitą liczbę używanych serwerów oraz minimalizuje liczbę migracji.
Podstawowa strategia wymaga następujących metryk:
metrykę
usługa
wtyczki
komentarz
compute.node.cpu.percent
none
cpu_util
none
Parametry strategii: migration_attempts — liczba kombinacji do wyszukiwania potencjalnych kandydatów do wyłączenia (domyślnie, 0, bez ograniczeń), period — interwał czasu w sekundach do uzyskania statycznej agregacji z źródła danych metryki (domyślnie, 700).
Używane metody: migracja, zmiana stanu usługi nova (change_nova_service_state).
Strategia Konsolidacji Obciążenia Maszyn Wirtualnych opiera się na heurystycznym algorytmie pierwszego dopasowania (first-fit), który skupia się na zmierzonej obciążeniu CPU i stara się minimalizować węzły, które mają zbyt duże lub zbyt małe obciążenie z uwzględnieniem ograniczeń pojemności zasobów. Ta strategia oferuje rozwiązanie, które prowadzi do bardziej efektywnego wykorzystania zasobów klastra, stosując następujące cztery etapy:
- Faza odciążania — przetwarzanie przekroczonych zasobów;
- Faza konsolidacji — przetwarzanie niewystarczająco wykorzystywanych zasobów;
- Optymalizacja rozwiązania — skrócenie liczby migracji;
- Wyłączanie niewykorzystywanych węzłów obliczeniowych.
Strategia wymaga następujących metryk:
metrykę
usługa
wtyczki
komentarz
memory
none
disk.root.size
none
Następujące metryki nie są obowiązkowe, ale zwiększają dokładność strategii, jeśli są dostępne:
metrykę
usługa
wtyczki
komentarz
memory.resident
none
cpu_util
none
Parametry strategii: period — interwał czasu w sekundach do uzyskania statycznej agregacji z źródła danych metryki (domyślnie, 3600).
Stosuje te same metody, co poprzednia strategia. Więcej informacji .
Zrównoważenie obciążenia — zbalansować obciążenie wśród węzłów obliczeniowych. Cel ma trzy strategie: Strategia Migracji Balansowania Obciążenia, Stabilizacja Obciążenia, Strategia Balansowania Pojemności Magazynowej.
Strategia migracji zrównoważenia obciążenia uruchamia migracje maszyn wirtualnych na podstawie obciążenia maszyn wirtualnych w węzłach. Decyzja o przeniesieniu jest podejmowana za każdym razem, gdy % użycia CPU lub RAM w węźle przekracza określony próg. Przenoszona maszyna wirtualna musi przybliżyć węzeł do średniego obciążenia wszystkich węzłów.
Wymagania
- Użycie procesorów fizycznych;
- Minimum dwa fizyczne węzły obliczeniowe;
- Zainstalowany i skonfigurowany komponent Ceilometer — ceilometer-agent-compute, działający na każdym węźle obliczeniowym, oraz API Ceilometer, a także zbieranie następujących metryk:
metrykę
usługa
wtyczki
komentarz
cpu_util
none
memory.resident
none
Parametry strategii:
parametr
typ
domyślnie
opis
metrics
String
‘cpu_util’
Metryki, które stanowią podstawę: ‘cpu_util’, ‘memory.resident’.
threshold
Liczba
25.0
Próg obciążenia do migracji.
okres
Liczba
300
Całkowity okres czasu Ceilometer.
Używana metoda — migracja.
Stabilizacja obciążenia — strategia mająca na celu stabilizację obciążenia za pomocą migracji na żywo. Strategia opiera się na algorytmie odchylenia standardowego i określa, czy występuje przeciążenie w klastrze, a także reaguje na nie poprzez uruchomienie migracji maszyn w celu stabilizacji klastra.
Wymagania
- Użycie procesorów fizycznych;
- Minimum dwa fizyczne węzły obliczeniowe;
- Zainstalowany i skonfigurowany komponent Ceilometer — ceilometer-agent-compute, działający na każdym węźle obliczeniowym, oraz API Ceilometer, a także zbieranie następujących metryk:
metrykę
usługa
wtyczki
komentarz
cpu_util
none
memory.resident
none
Strategia zrównoważenia pojemności pamięci masowej (strategia wdrożona od wersji Queens) — strategia przenosi dyski w zależności od obciążenia pul Cinder. Decyzja o przeniesieniu jest podejmowana za każdym razem, gdy współczynnik wykorzystania puli przekracza określony próg. Przenoszony dysk musi przybliżyć pul do średniego obciążenia wszystkich pul Cinder.
Wymagania i ograniczenia
- Minimum dwa pule Cinder;
- Możliwość migracji dysków.
- Model danych klastra — model danych klastra Cinder.
Parametry strategii:
parametr
typ
domyślnie
opis
volume_threshold
Liczba
80.0
Wartość progowa dysków do zrównoważenia objętości.
Używana metoda — migracja dysku (volume_migrate).
Noisy Neighbor — identyfikacja i przeniesienie “hałaśliwego sąsiada” — maszyny wirtualnej o niskim priorytecie, która negatywnie wpływa na wydajność maszyny wirtualnej o wysokim priorytecie z punktu widzenia IPC, nadmiernie wykorzystując ostatni poziom pamięci podręcznej. Własna strategia: Noisy Neighbor (używany parametr strategii — cache_threshold (domyślna wartość — 35), gdy wydajność spada do określonej wartości, rozpoczyna się migracja. Aby strategia działała, muszą być załączone metryki LLC (Last Level Cache), ostatni serwer Intel z obsługą CMT, a także zbieranie następujących metryk:
metrykę
usługa
wtyczki
komentarz
cpu_l3_cache
none
Wymagany Intel .
Model danych klastra (domyślnie): Nova model danych klastera. Stosowana metoda to migracja.
Praca z tym celem przez Dashboard nie została w pełni zrealizowana w wersji Queens.
Optymalizacja termalna — optymalizować temperaturę. Temperatura na wyjściu (powietrze wylotowe) jest jednym z ważnych systemów telemetrii cieplnej do pomiaru stanu obciążenia cieplnego/roboczego serwera. Dla tego celu istnieje jedna strategia — strategia oparta na temperaturze wyjścia, która podejmuje decyzje o przeniesieniu obciążeń na węzły z korzystnym trybem temperaturowym (najniższa temperatura na wyjściu), kiedy temperatura na wyjściu hostów źródłowych osiąga ustawiony próg.
Dla działania strategii wymagany jest serwer z zainstalowanym i skonfigurowanym Intel Power Node Manager. , a także zbieranie następujących metryk:
metrykę
usługa
wtyczki
komentarz
hardware.ipmi.node.outlet_temperature
IPMI
Parametry strategii:
parametr
typ
domyślnie
opis
threshold
Liczba
35.0
Próg temperatury dla migracji.
okres
Liczba
30
Interwał czasu w sekundach na uzyskanie statystycznej agregacji z źródła danych metrycznych.
Używana metoda — migracja.
Optymalizacja przepływu powietrza — optymalizować tryb wentylacji. Własna strategia — Uniform Airflow using live migration. Strategia uruchamia migrację maszyny wirtualnej, gdy przepływ powietrza z wentylatora serwera przekracza ustalony próg.
Aby strategia działała, wymagane są:
- Sprzęt: węzły obliczeniowe <z obsługą NodeManager 3.0;
- Minimum dwa węzły obliczeniowe;
- Zainstalowany i skonfigurowany na każdym węźle obliczeniowym komponent ceilometer-agent-compute oraz API Ceilometer, które może z powodzeniem raportować takie metryki jak przepływ powietrza, moc systemu, temperatura na wejściu:
metrykę
usługa
wtyczki
komentarz
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Do działania strategii wymagany jest serwer z zainstalowanym i skonfigurowanym Intel Power Node Manager 3.0 lub nowszą wersją.
Ograniczenia: Koncepcja nie jest przeznaczona do środowiska produkcyjnego.
Zaleca się używanie tego algorytmu z ciągłymi audytami, ponieważ w jednej iteracji planowana jest migracja tylko jednej maszyny wirtualnej.
Możliwe są migracje na żywo.
Parametry strategii:
parametr
typ
domyślnie
opis
threshold_airflow
Liczba
400.0
Próg przepływu powietrza dla migracji. Jednostka to 0.1CFM.
threshold_inlet_t
Liczba
28.0
Próg temperatury na wejściu dla decyzji o migracji.
threshold_power
Liczba
350.0
Próg mocy systemu dla decyzji o migracji.
okres
Liczba
30
Interwał czasu w sekundach na uzyskanie statystycznej agregacji z źródła danych metrycznych.
Używana metoda — migracja.
Obsługa sprzętu — obsługa sprzętu. Strategia związana z tym celem to migracja stref. Strategia ta jest narzędziem do skutecznej, automatycznej i minimalnej migracji maszyn wirtualnych oraz dysków w przypadku konieczności przeprowadzenia konserwacji sprzętu. Strategia buduje plan działań zgodnie z wagami: zestaw działań, który ma większą wagę, zostanie zaplanowany wcześniej niż inne. Istnieją dwa parametry konfiguracyjne: wagi działań (action_weights) oraz równoległość (parallelization).
Ograniczenia: wymagana jest konfiguracja wag działań oraz równoległości.
Parametry strategii:
parametr
typ
domyślnie
opis
węzły obliczeniowe
array
Brak
Węzły obliczeniowe do migracji.
pule pamięci
array
Brak
Węzły pamięci do migracji.
całkowita_równoległość
liczba całkowita
6
Łączna liczba działań, które powinny być wykonywane równolegle.
równolegle_na_węzeł
liczba całkowita
2
Liczba działań wykonywanych równolegle dla każdego węzła obliczeniowego.
równolegle_na_puli
liczba całkowita
2
Liczba działań wykonywanych równolegle dla każdej puli pamięci.
priority
obiekt
Brak
Lista priorytetów dla maszyn wirtualnych i dysków.
z_dołączonym_woluminem
boolean
Fałsz
Fałsz — maszyny wirtualne będą przenoszone po przeniesieniu wszystkich dysków. Prawda — maszyny wirtualne będą przenoszone po migracji wszystkich podłączonych dysków.
Elementy tablicy węzłów obliczeniowych:
parametr
typ
domyślnie
opis
src_node
string
Brak
Węzeł obliczeniowy, z którego przenoszone są maszyny wirtualne (obowiązkowo).
dst_node
string
Brak
Węzeł obliczeniowy, na który migracji podlegają maszyny wirtualne.
Elementy tablicy węzłów pamięci:
parametr
typ
domyślnie
opis
src_pool
string
Brak
Pula pamięci, z której przenoszone są dyski (obowiązkowo).
dst_pool
string
Brak
Pula pamięci, na którą przenoszone są dyski.
src_type
string
Brak
Typ dysku źródłowego (obowiązkowo).
dst_type
string
Brak
Typ dysku docelowego (obowiązkowo).
Elementy priorytetu obiektów:
parametr
typ
domyślnie
opis
projekt
array
Brak
Nazwy projektów.
węzeł_obliczeniowy
array
Brak
Nazwy węzłów obliczeniowych.
pula_pamięci
array
Brak
Nazwy pul pamięci.
obliczenie
enum
Brak
Parametry maszyny wirtualnej [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
magazyn
enum
Brak
Parametry dysków [“size”, “created_at”].
Wykorzystywane metody — migracja maszyn wirtualnych, migracja dysków.
Niezdefiniowane — pomocniczy cel, który ułatwia proces opracowania strategii. Nie zawiera specyfikacji i może być wykorzystywany za każdym razem, gdy strategia nie jest jeszcze powiązana z istniejącym celem. Cel ten może być również używany jako etap przejściowy. Strategia związana z tym celem to Actuator.
Tworzenie nowego celu
Silnik Decyzyjny Watcher ma interfejs wtyczki 'cele zewnętrzne', który umożliwia integrację zewnętrznych celów, które można osiągnąć za pomocą strategii.
Zanim stworzysz nowy cel, upewnij się, że żaden z istniejących celów nie odpowiada twoim potrzebom.
Tworzenie nowej wtyczki
Aby utworzyć nowy cel, musisz: rozszerzyć klasę celu, zaimplementować metodę klasy get_name () aby zwrócić unikalny identyfikator nowego celu, który chcesz stworzyć. Ten unikalny identyfikator powinien odpowiadać nazwie punktu wejścia, którą zadeklarujesz później.
Następnie musisz zaimplementować metodę klasy get_display_name () aby zwrócić przetłumaczoną nazwę wyświetlaną celu, który chcesz utworzyć (nie używaj zmiennej do zwracania przetłumaczonego ciągu, aby mogła ona automatycznie być zbierana przez narzędzie tłumaczenia.).
Zaimplementuj metodę klasy get_translatable_display_name (), aby zwrócić klucz tłumaczenia (faktycznie angielską nazwę wyświetlaną) twojego nowego celu. Zwracana wartość powinna odpowiadać ciągowi przetłumaczonemu w get_display_name ().
Zaimplementuj jego metodę get_efficacy_specification (), aby zwrócić specyfikację efektywności dla twojego celu. Metoda get_efficacy_specification () zwraca instancję Unclassified (), dostarczoną przez Watcher. Ta specyfikacja efektywności jest przydatna w procesie rozwoju twojego celu, ponieważ odpowiada pustej specyfikacji.
→
Architektura Watcher (więcej informacji ).
Składniki
API Watcher — komponent implementujący REST API, dostarczane przez Watcher. Mechanizmy interakcji: CLI, wtyczka Horizon, Python SDK.
Baza Danych Watcher — baza danych Watcher.
Wykonawca Watcher — komponent, który realizuje plan działania stworzony przez komponent Silnika Decyzyjnego Watcher.
Silnik Decyzyjny Watcher — komponent odpowiedzialny za obliczenie zestawu potencjalnych działań optymalizacyjnych do wykonania celu audytu. Jeśli strategia nie zostanie określona, komponent samodzielnie wybiera najbardziej odpowiednią.
Publikator Metryk Watcher — komponent, który zbiera i oblicza niektóre metryki lub wydarzenia i publikuje je w punkcie końcowym CEP. Funkcjonalność komponentu może być również dostarczana przez publikatora Ceilometer.
Silnik Przetwarzania Złożonych Wydarzeń (CEP) — silnik kompleksowej obróbki zdarzeń. Z powodów wydajności może działać wiele instancji CEP Engine, z których każda obsługuje określony typ metryki / zdarzenia. W systemie Watcher CEP uruchamia dwa typy akcji: — zapisywanie odpowiednich zdarzeń / metryk w bazie danych szeregów czasowych; — wysyłanie odpowiednich zdarzeń do komponentu Watcher Decision Engine, gdy zdarzenie może wpłynąć na wynik aktualnej strategii optymalizacji, ponieważ klaster Openstack nie jest statycznym systemem.
Interakcja komponentów odbywa się za pośrednictwem protokołu AMQP.
→
Schemat interakcji z Watcherem
Wyniki testowania Watchera
- Na stronie Optymalizacja — Plany działań występuje błąd 500 (zarówno na czystym Queens, jak i na teście z modułami Tionix), pojawia się tylko po uruchomieniu audytu i wygenerowaniu planu działań, a pusta strona otwiera się normalnie.
- Na zakładce Szczegóły akcji występują błędy, nie można uzyskać celu i strategii audytu (zarówno na czystym Queens, jak i na teście z modułami Tionix).
- Audyty z celem Dummy (testowe) są tworzone i uruchamiane normalnie, plany działań są generowane.
- Audyty z celem Unclassified nie są tworzone, ponieważ cel nie jest funkcjonalny i służy do wstępnej konfiguracji podczas tworzenia nowych strategii.
- Audyty z celem Workload Balancing (strategia równoważenia pojemności przechowywania) są tworzone z powodzeniem, jednak plan działań nie jest generowany. Nie jest wymagana optymalizacja pul przechowywania.
- Audyty z celem Workload Balancing (strategia migracji obciążenia) są tworzone z powodzeniem, jednak plan działań nie jest generowany.
- Audyty z celem Workload Balancing (strategia stabilizacji obciążenia) kończą się błędem.
- Audyty z celem Noisy Neighbor są tworzone z powodzeniem, jednak plan działań nie jest generowany.
- Audyty z celem Utrzymania sprzętu są tworzone z powodzeniem, plan działań jest generowany nie w pełnym zakresie (generowane są wskaźniki wydajności, ale sam wykaz działań nie jest generowany).
- Zmienione konfiguracje w nova.conf (w domyślnej sekcji compute_monitors = cpu.virt_driver) na węzłach obliczeniowych i sterujących nie naprawiają błędów.
- Audyty z celem Konsolidacja serwera (strategia Podstawowa) również kończą się błędem.
- Audyty z celem Konsolidacja serwera (strategia konsolidacji obciążenia VM) kończą się błędem. W logach błąd uzyskiwania danych źródłowych. Dyskusja na temat błędu, w szczególności, .
Próbowaliśmy wskazać w pliku konfiguracyjnym Watcher (nie pomogło - w rezultacie błędy na wszystkich stronach Optymalizacji, powrót do pierwotnej treści pliku konfiguracyjnego nie naprawia sytuacji):[watcher_strategies.basic]
datasource = ceilometer, gnocchi - Audyty mające na celu oszczędzanie energii kończą się błędem. Sądząc po logach, problem tkwi w braku Ironic, nie będzie działać bez usługi baremetal.
- Audyty mające na celu optymalizację cieplną kończą się błędem. Traceback jest ten sam, co dla Konsolidacji serwera (strategia konsolidacji obciążenia VM) (błąd danych źródłowych)
- Audyty mające na celu optymalizację przepływu powietrza kończą się błędem.
Pojawiają się także następujące błędy zakończenia audytu. Traceback w logach decision-engine.log (stan klastra nieokreślony).
→ Dyskusja o błędzie
Podsumowanie
Wynikiem naszych dwumiesięcznych badań jest jednoznaczny wniosek, że aby uzyskać pełnoprawny, działający system równoważenia obciążenia, musimy w tej części intensywnie zająć się rozwojem narzędzi dla platformy Openstack.
Watcher pokazał się jako poważny i szybko rozwijający się produkt z ogromnym potencjałem, do pełnego wykorzystania którego wymagana będzie duża i poważna praca.
Ale o tym w następnych artykułach cyklu.
Źródło: habr.com
