Lastenausgleich in OpenStack

In großen Cloud-Systemen ist die automatisierte Lastenverteilung oder -ausgleichung auf Rechenressourcen besonders wichtig. Auch Tionix (Entwickler und Betreiber von Cloud-Diensten, Teil der Gruppe Rostelecom) hat sich mit dieser Frage beschäftigt.

Und da unsere Hauptentwicklungsplattform OpenStack ist und wir, wie alle Menschen, faul sind, wurde beschlossen, ein fertiges Modul auszuwählen, das bereits Teil der Plattform ist. Unsere Wahl fiel auf Watcher, den wir für unsere Bedürfnisse nutzen werden.

Zunächst klären wir die Begriffe und Definitionen.

Begriffe und Definitionen

Ziel — das ist ein messbares, beobachtbares und greifbares Endresultat, das erreicht werden soll. Für jedes Ziel gibt es eine oder mehrere Strategien. Eine Strategie ist die Implementierung eines Algorithmus, der in der Lage ist, eine Lösung für das jeweilige Ziel zu finden.

Aktion (Action) — das ist eine elementare Aufgabe, die den aktuellen Zustand der verwalteten Ressource im OpenStack-Cluster ändert, wie z.B.: Migration einer virtuellen Maschine (migration), Änderung des Stromzustands eines Knotens (change_node_power_state), Änderung des Zustands des nova-Dienstes (change_nova_service_state), Änderung des Flavors (resize), Registrierung einer NOP-Nachricht (nop), keine Aktion über einen bestimmten Zeitraum — Pause (sleep), Übertragung eines Volumes (volume_migrate).

Aktionsplan (Action Plan) — ein spezifischer Handlungsablauf, der in einer bestimmten Reihenfolge durchgeführt wird, um ein bestimmtes Ziel zu erreichen. Der Aktionsplan enthält auch eine bewertbare globale Effizienz mit einem Satz von Leistungsindikatoren. Der Aktionsplan wird von Watcher nach einem erfolgreich durchgeführten Audit generiert, bei dem die verwendete Strategie eine Lösung zur Erreichung des Ziels findet. Der Aktionsplan besteht aus einer Liste aufeinanderfolgender Aktionen.

Audit (Audit) — das ist eine Anfrage zur Optimierung des Clusters. Die Optimierung erfolgt mit dem Ziel, ein Ziel in diesem Cluster zu erreichen. Für jedes erfolgreiche Audit generiert Watcher einen Aktionsplan.

Auditbereich (Audit Scope) — dies ist ein Satz von Ressourcen, innerhalb dessen ein Audit durchgeführt wird (Zugriffszone(n), Knotenaggregatoren, einzelne Rechenknoten oder Speicherknoten usw.). Der Auditbereich ist in jeder Vorlage definiert. Wenn der Auditbereich nicht angegeben ist, wird das gesamte Cluster auditiert.

Auditvorlage (Audit Template) — ein gespeichertes Set von Einstellungen zum Starten eines Audits. Vorlagen sind notwendig, um Audits mit denselben Einstellungen mehrfach durchzuführen. Die Vorlage muss unbedingt das Ziel des Audits enthalten; wenn keine Strategien angegeben sind, werden die am besten geeigneten bestehenden Strategien ausgewählt.

Cluster (Cluster) — das ist eine Gruppe von physischen Maschinen, die Rechenressourcen, Speicherressourcen und Netzwerkressourcen bereitstellen und von demselben OpenStack-Managementknoten verwaltet werden.

Cluster-Datenmodell (Cluster Data Model, CDM) — dies ist eine logische Darstellung des aktuellen Zustands und der Topologie der von dem Cluster verwalteten Ressourcen.

Effizienzindikator (Efficacy Indicator) — ein Indikator, der angibt, wie gut eine Lösung, die mit dieser Strategie erstellt wurde, abschneidet. Effizienzindikatoren sind spezifisch für ein bestimmtes Ziel und werden normalerweise verwendet, um die globale Effizienz des endgültigen Aktionsplans zu berechnen.

Effizienzspezifikation (Efficacy Specification) — dies ist eine Reihe spezifischer Merkmale, die mit jedem Ziel verbunden sind und verschiedene Effizienzindikatoren definieren, die die Strategie, die zur Erreichung des entsprechenden Ziels beitragen soll, in ihrer Lösung bieten muss. Tatsächlich wird jede von der Strategie vorgeschlagene Lösung an der Spezifikation gemessen, bevor ihre globale Effizienz berechnet wird.

„Zählenden“ Motor (Scoring Engine) — dies ist eine ausführbare Datei, die klar definierte Eingaben und Ausgaben hat und eine rein mathematische Aufgabe erfüllt. Somit hängt die Berechnung nicht von der Umgebung ab, in der sie ausgeführt wird — sie liefert überall das gleiche Ergebnis.

Watcher-Planer (Watcher Planner) — Teil des Entscheidungsmechanismus von Watcher. Dieses Modul nimmt eine Menge von Aktionen an, die von der Strategie generiert wurden, und erstellt einen Arbeitsablaufplan, der definiert, wie diese verschiedenen Aktionen zeitlich geplant werden und welche Voraussetzungen für jede Aktion bestehen.

Ziele und Strategien von Watcher

Ziel
Strategien

Dummy-Ziel
Dummy-Strategie 

Dummy-Strategie unter Verwendung von Beispiel-Bewertungs-Engines

Dummy-Strategie mit Resize

Energieeinsparung
Strategie zur Energieeinsparung

Serverkonsolidierung
Grundlegende Offline-Serverkonsolidierung

VM-Arbeitslastkonsolidierungsstrategie

Arbeitslastausbalancierung
Strategie zur Migration der Arbeitslastbalance

Strategie zur Balance der Speicherkapazität

Stabilisierung der Arbeitslast

Lärmender Nachbar
Lärmender Nachbar

Thermische Optimierung
Strategie auf Basis der Outlet-Temperatur

Luftstromoptimierung
Strategie zur gleichmäßigen Luftstrommigration

Hardware-Wartung
Zonenmigration

Unklassifiziert
Aktuator

Dummy-Ziel — reserviertes Ziel, das zu Testzwecken verwendet wird.

Verwandte Strategien: Dummy-Strategie, Dummy-Strategie unter Verwendung von Beispiel-Bewertungs-Engines und Dummy-Strategie mit Resize. Dummy-Strategie ist eine fiktive Strategie, die für Integrationstests mit Tempest verwendet wird. Diese Strategie bietet keine nützliche Optimierung; ihr einziges Ziel ist die Nutzung von Tempest-Tests.

Dummy-Strategie unter Verwendung von Beispiel-Bewertungs-Engines — diese Strategie ist ähnlich der vorherigen, unterscheidet sich jedoch durch die Verwendung eines Beispiels für einen 'Bewertungs-Engin', der mit maschinellem Lernen zählt.

Dummy-Strategie mit Resize — diese Strategie ist ähnlich der vorherigen, unterscheidet sich jedoch durch die Verwendung von Flavour-Änderungen (Migration und Resize).

Wird nicht im Produktionsbetrieb verwendet.

Energieeinsparung — Energieverbrauch minimieren. Die Strategie dieses Ziels, die Strategie zur Energieeinsparung, kann zusammen mit der Strategie zur VM-Arbeitslastkonsolidierung (Serverkonsolidierung) dynamisches Energiemanagement (DPM) durchführen, das Strom spart, indem Arbeitslasten dynamisch konsolidiert werden, selbst in Zeiten mit geringer Ressourcenauslastung: Virtuelle Maschinen werden auf eine geringere Anzahl von Knoten verschoben, und nicht benötigte Knoten werden ausgeschaltet. Nach der Konsolidierung schlägt die Strategie Entscheidungen über das Ein- und Ausschalten von Knoten gemäß den festgelegten Parametern vor: „min_free_hosts_num“ — die Anzahl der freien eingeschalteten Knoten, die auf eine Arbeitslast warten, und „free_used_percent“ — das prozentuale Verhältnis freier eingeschalteter Knoten zur Anzahl der Knoten, die von Maschinen in Anspruch genommen werden. Für den Betrieb der Strategie muss Ironic aktiviert und konfiguriert sein, um das Ein- und Ausschalten der Stromversorgung an den Knoten zu ermöglichen.

Strategieparameter

Parameter
Typ
standardmäßig
Beschreibung

free_used_percent
Nummer
10.0
Verhältnis der Anzahl freier Rechenknoten zur Anzahl der Rechenknoten mit virtuellen Maschinen

min_free_hosts_num
Int
1
minimale Anzahl freier Rechenknoten

Es sollten mindestens zwei Knoten in der Cloud vorhanden sein. Die verwendete Methode ist das Ändern des Stromzustands des Knotens (change_node_power_state). Die Strategie erfordert keine Metrikermittlung.

Server-Konsolidierung – die Anzahl der Rechenknoten zu minimieren (Konsolidierung). Es gibt zwei Strategien: Basic Offline Server Consolidation und VM Workload Consolidation Strategy.

Die Strategie Basic Offline Server Consolidation minimiert die Gesamtzahl der verwendeten Server und auch die Anzahl der Migrationen.

Die Basisstrategie erfordert folgende Metriken:

Metrik
Dienst
erlauben Plugins, die Funktionen von K9s zu erweitern. Ich habe in der Praxis nur eines davon verwendet —
Kommentar

compute.node.cpu.percent
ceilometer
none
 

cpu_util
ceilometer
none
 

Strategieparameter: migration_attempts – Anzahl der Kombinationen zur Suche nach potenziellen Kandidaten zum Abschalten (Standardwert: 0, keine Einschränkungen), period – Zeitpunkt in Sekunden zur Erfassung der statischen Aggregation aus der Quelle der Metrikdaten (Standardwert: 700).

Verwendete Methoden: Migration, Änderung des Status des Nova-Dienstes (change_nova_service_state).

Die Strategie VM Workload Consolidation Strategy basiert auf einem heuristischen Algorithmus, der zuerst passende (first-fit) Entscheidungen trifft, sich auf die gemessene CPU-Auslastung konzentriert und versucht, Knoten mit zu hoher oder zu niedriger Auslastung unter Berücksichtigung der Ressourcenkapazitätsbeschränkungen zu minimieren. Diese Strategie bietet eine Lösung, die zu einer effizienteren Ressourcennutzung im Cluster führt, unter Verwendung der folgenden vier Phasen:

1. Entlastungsphase – Verarbeitung von Überlastungen der Ressourcen;
2. Konsolidierungsphase – Verarbeitung von ungenutzten Ressourcen;
3. Optimierungslösung – Reduzierung der Anzahl der Migrationen;
4. Abschaltung ungenutzter Rechenknoten.

Die Strategie erfordert folgende Metriken:

Metrik
Dienst
erlauben Plugins, die Funktionen von K9s zu erweitern. Ich habe in der Praxis nur eines davon verwendet —
Kommentar

memory
ceilometer
none
 

disk.root.size
ceilometer
none
 

Die folgenden Metriken sind nicht zwingend erforderlich, erhöhen jedoch die Genauigkeit der Strategie, sofern sie verfügbar sind:

Metrik
Dienst
erlauben Plugins, die Funktionen von K9s zu erweitern. Ich habe in der Praxis nur eines davon verwendet —
Kommentar

memory.resident
ceilometer
none
 

cpu_util
ceilometer
none
 

Strategieparameter: period – Zeitraum in Sekunden zur Erfassung der statischen Aggregation aus der Quelle der Metrikdaten (Standardwert: 3600).

Verwendet die gleichen Methoden wie die vorherige Strategie. Weitere Informationen hier.

Arbeitslastausbalancierung – die Arbeitslast zwischen den Rechenknoten ausbalancieren. Ziel hat drei Strategien: Workload Balance Migration Strategy, Workload Stabilisierung, Storage Capacity Balance Strategy.

Die Workload-Balance-Migrationsstrategie startet Migrationen von virtuellen Maschinen basierend auf der Arbeitslast der Knotenmaschinen. Die Entscheidung zur Migration wird getroffen, wenn die CPU- oder RAM-Auslastung eines Knotens den festgelegten Schwellenwert überschreitet. Dabei sollte die migrierte virtuelle Maschine den Knoten der durchschnittlichen Arbeitslast aller Knoten näherbringen.

Anforderungen

• Physische Prozessoren verwenden;
• Mindestens zwei physische Rechenknoten;
• Installierte und konfigurierte Ceilometer-Komponente — ceilometer-agent-compute, die auf jedem Rechenknoten läuft, und Ceilometer API, sowie das Sammeln der folgenden Metriken:

Metrik
Dienst
erlauben Plugins, die Funktionen von K9s zu erweitern. Ich habe in der Praxis nur eines davon verwendet —
Kommentar

cpu_util
ceilometer
none
 

memory.resident
ceilometer
none
 

Strategieparameter:

Parameter
Typ
standardmäßig
Beschreibung

Metriken
String
‘cpu_util’
Die zugrunde liegenden Metriken sind: ‘cpu_util’, ‘memory.resident’.

Schwellenwert
Nummer
25.0
Der Arbeitslastschwellenwert für die Migration.

Zeitraum
Nummer
300
Der kumulierte Zeitraum von Ceilometer.

Verwendetes Verfahren — Migration.

Workload-Stabilisierung — eine Strategie zur Stabilisierung der Arbeitslast mithilfe von Live-Migration. Die Strategie basiert auf einem Standardabweichungsalgorithmus und bestimmt, ob eine Überlastung im Cluster vorliegt, und reagiert darauf, indem Migrationen von Maschinen gestartet werden, um den Cluster zu stabilisieren.

Anforderungen

• Physische Prozessoren verwenden;
• Mindestens zwei physische Rechenknoten;
• Installierte und konfigurierte Ceilometer-Komponente — ceilometer-agent-compute, die auf jedem Rechenknoten läuft, und Ceilometer API, sowie das Sammeln der folgenden Metriken:

Metrik
Dienst
erlauben Plugins, die Funktionen von K9s zu erweitern. Ich habe in der Praxis nur eines davon verwendet —
Kommentar

cpu_util
ceilometer
none
 

memory.resident
ceilometer
none
 

Strategie zur Speicherkapazitätsbalance (die Strategie ist ab Queens implementiert) — die Strategie migriert Festplatten je nach Auslastung der Cinder-Pools. Die Entscheidung zur Migration wird getroffen, wenn der Auslastungsgrad des Pools den festgelegten Schwellenwert überschreitet. Die zu migrierende Festplatte sollte den Pool der durchschnittlichen Last aller Cinder-Pools näherbringen.

Anforderungen und Einschränkungen

• Mindestens zwei Cinder-Pools;
• Möglichkeit der Migration von Festplatten.
• Modell des Cluster-Datenmodells — Cinder-Cluster-Datenmodell-Sammler.

Strategieparameter:

Parameter
Typ
standardmäßig
Beschreibung

volume_threshold
Nummer
80.0
Schwellenwert der Festplatten für die Volumenbalance.

Verwendetes Verfahren — Datenträgermigration (volume_migrate).

Noisy Neighbor — identifizieren und migrieren Sie den „lauten Nachbarn“ — eine virtuelle Maschine mit niedrigem Prioritätsniveau, die sich negativ auf die Leistung einer hochpriorisierten virtuellen Maschine in Bezug auf IPC auswirkt, indem sie den Last Level Cache übermäßig nutzt. Eigene Strategie: Noisy Neighbor (verwendeter Strategiewert — cache_threshold (Standardwert — 35), bei Leistungsabfall auf den angegebenen Wert wird eine Migration gestartet. Für die Funktion der Strategie sind aktivierte LLC (Last Level Cache) Metriken, der letzte Intel-Server mit CMT-Unterstützung, sowie das Sammeln der folgenden Metriken:

Metrik
Dienst
erlauben Plugins, die Funktionen von K9s zu erweitern. Ich habe in der Praxis nur eines davon verwendet —
Kommentar

cpu_l3_cache
ceilometer
none
Benötigt Intel CMT.

Das Datenmodell des Clusters (Standard): Nova-Cluster-Datenmodell-Sammler. Verwendete Methode – Migration.

Die Arbeit mit diesem Ziel über das Dashboard ist in Queens nicht vollständig implementiert.

Thermische Optimierung — den Temperaturregime optimieren. Die Temperatur am Ausgang (Abluft) ist eines der wichtigen thermischen Telemetriesysteme zur Messung des Zustands der Wärme-/Arbeitslast des Servers. Für das Ziel gibt es eine Strategie – Outlet-Temperatur-basierte Strategie, die Entscheidungen über das Verschieben von Arbeitslasten auf Knoten mit günstigerem Temperaturregime (die niedrigste Temperatur am Ausgang) trifft, wenn die Temperatur am Ausgang der Ursprungs-Hosts den konfigurierbaren Schwellenwert erreicht.

Für den Betrieb der Strategie ist ein Server mit installiertem und konfiguriertem Intel Power Node Manager erforderlich. 3.0 oder eine neuere Version, sowie das Sammeln der folgenden Metriken:

Metrik
Dienst
erlauben Plugins, die Funktionen von K9s zu erweitern. Ich habe in der Praxis nur eines davon verwendet —
Kommentar

hardware.ipmi.node.outlet_temperature
ceilometer
IPMI
 

Strategieparameter:

Parameter
Typ
standardmäßig
Beschreibung

Schwellenwert
Nummer
35.0
Temperaturgrenze für die Migration.

Zeitraum
Nummer
30
Zeitintervall in Sekunden zur Erfassung statistischer Aggregationen aus der Datenquelle für Metriken.

Verwendetes Verfahren — Migration.

Luftstromoptimierung — den Belüftungsmodus optimieren. Eigene Strategie – Uniform Airflow using live migration. Die Strategie initiiert die Migration der virtuellen Maschine jedes Mal, wenn der Luftstrom vom Serverlüfter den angegebenen Schwellenwert überschreitet.

Für den Betrieb der Strategie erforderlich:

• Hardware: Compute Nodes <unterstützen NodeManager 3.0;>
• Mindestens zwei Compute Nodes;
• Installierte und konfigurierte Komponenten auf jedem Compute Node: ceilometer-agent-compute und Ceilometer API, die erfolgreich solche Metriken wie Luftstrom, Systemleistung, Eingangstemperatur berichten können:

Metrik
Dienst
erlauben Plugins, die Funktionen von K9s zu erweitern. Ich habe in der Praxis nur eines davon verwendet —
Kommentar

hardware.ipmi.node.airflow
ceilometer
IPMI
 

hardware.ipmi.node.temperature
ceilometer
IPMI
 

hardware.ipmi.node.power
ceilometer
IPMI
 

Für den Betrieb der Strategie ist ein Server mit installiertem und konfiguriertem Intel Power Node Manager 3.0 oder einer neueren Version erforderlich.

Einschränkungen: Das Konzept ist nicht für den produktiven Einsatz geeignet.

Es wird empfohlen, diesen Algorithmus mit kontinuierlichen Audits zu verwenden, da bei einer Iteration die Migration nur einer virtuellen Maschine geplant ist.

Lebende Migrationen sind möglich.

Strategieparameter:

Parameter
Typ
standardmäßig
Beschreibung

threshold_airflow
Nummer
400.0
Luftstromschwellenwert für die Migration Einheit ist 0.1CFM

threshold_inlet_t
Nummer
28.0
Eingangstemperaturgrenze für die Entscheidungsfindung zur Migration

threshold_power
Nummer
350.0
Systemleistungsgrenze für die Entscheidungsfindung zur Migration

Zeitraum
Nummer
30
Zeitintervall in Sekunden zur Erfassung statistischer Aggregationen aus der Datenquelle für Metriken.

Verwendetes Verfahren — Migration.

Hardware-Wartung — Wartung von Hardware. Die Strategie, die sich auf dieses Ziel bezieht, ist die Zonenmigration. Diese Strategie ist ein Werkzeug für eine effektive, automatisierte und minimale Migration von virtuellen Maschinen und Festplatten, wenn eine Wartung der Hardware erforderlich ist. Die Strategie entwickelt einen Aktionsplan basierend auf Gewichten: Aktionen mit höherem Gewicht werden früher als andere geplant. Es gibt zwei Konfigurationsparameter: Aktionsgewichte (action_weights) und Parallelisierung (parallelization).

Einschränkungen: Es ist eine Konfiguration der Aktionsgewichte und der Parallelisierung erforderlich.

Strategieparameter:

Parameter
Typ
standardmäßig
Beschreibung

compute_nodes
array2
None
Rechenknoten für die Migration.

storage_pools
array2
None
Speicherknoten für die Migration.

parallel_total
integer
6
Die Gesamtanzahl der Aktionen, die parallel ausgeführt werden sollen.

parallel_per_node
integer
2
Anzahl der Aktionen, die parallel für jeden Rechenknoten ausgeführt werden.

parallel_per_pool
integer
2
Anzahl der Aktionen, die parallel für jeden Speicherpool ausgeführt werden.

priority
object
None
Liste von Prioritäten für virtuelle Maschinen und Festplatten.

with_attached_volume
boolean
Falsch
False — Virtuelle Maschinen werden nach dem Transfer aller Festplatten übertragen. True — Virtuelle Maschinen werden nach der Migration aller angeschlossenen Festplatten übertragen.

Elemente des Arrays von Rechenknoten:

Parameter
Typ
standardmäßig
Beschreibung

src_node
string
None
Rechenknoten, von dem die virtuellen Maschinen migriert werden (verpflichtend).

dst_node
string
None
Rechenknoten, auf den die virtuellen Maschinen migriert werden.

Elemente des Arrays von Speichergrößen:

Parameter
Typ
standardmäßig
Beschreibung

src_pool
string
None
Speicherpool, aus dem die Festplatten migriert werden (verpflichtend).

dst_pool
string
None
Speicherpool, auf den die Festplatten migriert werden.

src_type
string
None
Ursprünglicher Festplattentyp (verpflichtend).

dst_type
string
None
Ziel-Festplattentyp (verpflichtend).

Elemente der Prioritätsobjekte:

Parameter
Typ
standardmäßig
Beschreibung

projekt
array2
None
Projektbezeichnungen.

compute_node
array2
None
Namen der Rechenknoten.

storage_pool
array2
None
Namen der Speicherpools.

compute
enum
None
Parameter der virtuellen Maschine ["vcpu_num", "mem_size", "disk_size", "created_at"].

storage
enum
None
Parameter der Festplatten ["size", "created_at"].

Verwendete Methoden — Migration von virtuellen Maschinen, Migration von Festplatten.

Unklassifiziert — Hilfsziel, das verwendet wird, um den Prozess der Strategieentwicklung zu erleichtern. Enthält keine Spezifikationen und kann jedes Mal verwendet werden, wenn die Strategie noch nicht mit einem bestehenden Ziel verbunden ist. Dieses Ziel kann auch als Übergangsstufe verwendet werden. Die mit diesem Ziel verbundene Strategie ist der Aktuator.   

Erstellung eines neuen Ziels

Watcher Decision Engine hat eine Plugin-Schnittstelle „externes Ziel“, die die Integration eines externen Ziels ermöglicht, das mit der Strategie erreicht werden kann.

Bevor Sie ein neues Ziel erstellen, sollten Sie sicherstellen, dass keines der bestehenden Ziele Ihren Bedürfnissen entspricht.

Erstellung eines neuen Plugins

Um ein neues Ziel zu erstellen, müssen Sie: die Zielklasse erweitern, die Klassenmethode get_name () implementieren, um die eindeutige Kennung des neuen Ziels zurückzugeben, das Sie erstellen möchten. Diese eindeutige Kennung muss mit dem Namen des Einstiegspunktes übereinstimmen, den Sie später deklarieren.

Als nächstes müssen Sie die Klassenmethode get_display_name () implementieren, um den übersetzten Anzeigennamen des Ziels zurückzugeben, das Sie erstellen möchten (verwenden Sie keine Variable, um den übersetzten String zurückzugeben, damit er automatisch vom Übersetzungstool gesammelt werden kann.).

Implementieren Sie die Klassenmethode get_translatable_display_name (), um den Übersetzungsschlüssel (tatsächlich den englischen Anzeigennamen) Ihres neuen Ziels zurückzugeben. Der Rückgabewert sollte mit der Zeichenkette übereinstimmen, die in get_display_name () übersetzt wurde.

Implementieren Sie seine Methode get_efficacy_specification (), um die Effizienzspezifikation Ihres Ziels zurückzugeben. Die Methode get_efficacy_specification () gibt eine Instanz von Unclassified () zurück, die von Watcher bereitgestellt wird. Diese Effizienzspezifikation ist während der Entwicklungsphase Ihres Ziels nützlich, da sie der leeren Spezifikation entspricht.

→ Mehr dazu hier

Architektur von Watcher (mehr hier).

Komponenten

Watcher API — eine Komponente, die das von Watcher bereitgestellte REST API implementiert. Interaktionsmechanismen: CLI, Plugin Horizon, Python SDK.

Watcher DB — die Datenbank von Watcher.

Watcher Applier — eine Komponente, die die Ausführung des von der Komponente Watcher Decision Engine erstellten Aktionsplans implementiert.

Watcher Decision Engine — eine Komponente, die für die Berechnung einer Reihe potenzieller Optimierungsmaßnahmen zur Erfüllung des Prüfziels verantwortlich ist. Wenn keine Strategie angegeben ist, wählt die Komponente selbstständig die am besten geeignete aus.

Watcher Metrics Publisher — eine Komponente, die einige Metriken oder Ereignisse sammelt und berechnet und sie am Endpunkt CEP veröffentlicht. Die Funktionalität der Komponente kann auch vom Ceilometer-Publisher bereitgestellt werden.

Complex Event Processing (CEP) Engine — Motor für die umfassende Ereignisverarbeitung. Aus Leistungsgründen können mehrere Instanzen des CEP-Engines gleichzeitig betrieben werden, wobei jede eine bestimmte Art von Metrik / Ereignissen verarbeitet. Im Watcher-System löst der CEP zwei Arten von Aktionen aus: — entsprechende Ereignisse / Metriken in die Zeitreihendatenbank schreiben; — entsprechende Ereignisse an die Komponente Watcher Decision Engine senden, wenn dieses Ereignis das Ergebnis der aktuellen Optimierungsstrategie beeinflussen könnte, da der Openstack-Cluster kein statisches System ist.

Die Interaktion der Komponenten erfolgt über das AMQP-Protokoll.

→ Konfiguration des Watchers

Schema der Interaktion mit dem Watcher

Testergebnisse des Watchers

1. Auf der Seite Optimization – Action Plans tritt der Fehler 500 auf (sowohl bei reinem Queens als auch auf dem Stand mit den Tionix-Modulen), dieser erscheint nur nach dem Start eines Audits und der Generierung eines Aktionsplans, die leere Seite öffnet sich normal.
2. Im Tab Action Details gibt es Fehler, es kann kein Ziel und keine Auditsstrategie abgerufen werden (sowohl bei reinem Queens als auch auf dem Stand mit den Tionix-Modulen).
3. Audits mit dem Ziel Dummy (Test-Audits) werden normal erstellt und gestartet, Aktionspläne werden generiert.
4. Audits mit dem Ziel Unclassified werden nicht erstellt, da das Ziel nicht funktional ist und für die vorübergehende Einrichtung beim Erstellen neuer Strategien gedacht ist.
5. Audits mit dem Ziel Workload Balancing (Strategie Storage Capacity balance) werden erfolgreich erstellt, jedoch wird kein Aktionsplan generiert. Eine Optimierung der Speichervorräte ist nicht erforderlich.
6. Audits mit dem Ziel Workload Balancing (Strategie Workload Balance Migration Strategy) werden erfolgreich erstellt, jedoch wird kein Aktionsplan generiert.
7. Audits mit dem Ziel Workload Balancing (Strategie Workload Stabilization Strategy) enden mit einem Fehler.
8. Audits mit dem Ziel Noisy Neighbor werden erfolgreich erstellt, jedoch wird kein Aktionsplan generiert.
9. Audits mit dem Ziel Hardware maintenance werden erfolgreich erstellt, der Aktionsplan wird jedoch nicht vollständig generiert (Leistungskennzahlen werden generiert, jedoch nicht die Liste der Maßnahmen).
10. Änderungen in den Konfigurationen nova.conf (im Default-Bereich compute_monitors = cpu.virt_driver) auf den Compute- und Control-Node beheben die Fehler nicht.
11. Audits mit dem Ziel Server Consolidation (Strategie Basic) enden ebenfalls mit einem Fehler.
12. Audits mit dem Ziel Server Consolidation (Strategie VM workload consolidation) enden mit einem Fehler. In den Logs gibt es einen Fehler beim Abrufen der Quelldaten. Diskussion über den Fehler, insbesondere, hier.
    Wir haben versucht, die Konfigurationsdatei von Watcher zu ändern (hat nicht geholfen – aufgrund der Fehler auf allen Seiten der Optimierung hilft das Zurücksetzen auf den ursprünglichen Inhalt der Konfigurationsdatei nicht):

    [watcher_strategies.basic]
    datasource = ceilometer, gnocchi

13. Audits zur Energieeinsparung enden mit einem Fehler. Laut den Logs liegt das Problem tatsächlich im Fehlen von Ironic, es funktioniert nicht ohne den Baremetal-Dienst.
14. Audits zur thermischen Optimierung enden mit einem Fehler. Der Traceback ist derselbe wie bei der Serverkonsolidierung (Strategie VM-Workload-Konsolidierung) (Fehler bei den Quelldaten).
15. Audits zur Luftstromoptimierung enden mit einem Fehler.

Es treten auch folgende Fehler beim Abschluss des Audits auf. Der Traceback in den Logs decision-engine.log (Zustand des Clusters nicht definiert).

→ Diskussion des Fehlers hier

Fazit

Das Ergebnis unserer zweimonatigen Untersuchungen ist die klare Erkenntnis, dass wir zur Schaffung eines voll funktionsfähigen, zuverlässigen Lastenausgleichssystems hier intensiv an der Weiterentwicklung der Werkzeuge für die OpenStack-Plattform arbeiten müssen.

Watcher hat sich als ein ernstzunehmendes und schnell wachsendes Produkt mit großem Potenzial erwiesen, dessen vollwertige Nutzung jedoch erhebliche und umfassende Arbeit erfordert.

Aber dazu – in den nächsten Artikeln der Reihe.

Quelle: habr.com