🥇Lastverteilung in Openstack

In großen Cloud-Systemen ist die automatische Lastverteilung oder -ausgleichung der Rechenressourcen von entscheidender Bedeutung. Dies haben auch wir bei Tionix (Entwickler und Betreiber von Cloud-Diensten, Teil der Gruppe Rostelekom) erkannt.

Da unsere Hauptentwicklungsplattform OpenStack ist und wir, wie alle Menschen, faul sind, entschieden wir uns, ein bereits vorhandenes Modul zu verwenden, das Teil der Plattform ist. Unsere Wahl fiel auf Watcher, den wir für unsere Bedürfnisse nutzen wollten.

Zunächst betrachten wir die Begriffe und Definitionen.

Begriffe und Definitionen

Ziel – das ist ein messbares, beobachtbares und nachvollziehbares Endergebnis, das erreicht werden soll. Für jedes Ziel gibt es eine oder mehrere Strategien. Eine Strategie ist die Umsetzung eines Algorithmus, der in der Lage ist, eine Lösung für das festgelegte Ziel zu finden.

Aktion (Action) — ist eine grundlegende Aufgabe, die den aktuellen Zustand der Zielressource im OpenStack-Cluster ändert, wie z.B.: Migration einer virtuellen Maschine (migration), Änderung des Stromzustands des 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 Aktionen über einen bestimmten Zeitraum — Pause (sleep), Verschieben eines Volumes (volume_migrate).

Aktionsplan (Action Plan) — ist ein spezifischer Handlungsablauf, der in einer bestimmten Reihenfolge durchgeführt wird, um ein konkretes Ziel zu erreichen. Der Aktionsplan enthält auch eine bewertete globale Effizienz mit einer Reihe 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 von aufeinanderfolgenden Maßnahmen.

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

Auditbereich (Audit Scope) — ist eine Sammlung von Ressourcen, innerhalb derer eine Überprüfung durchgeführt wird (Verfügbarkeitszone(n), Knotengruppen, einzelne Rechenknoten oder Speicherorte usw.). Der Überprüfungsbereich ist in jeder Vorlage definiert. Wenn der Überprüfungsbereich nicht angegeben ist, wird das gesamte Cluster überprüft.

Überprüfungsvorlage (Audit Template) — ist eine gespeicherte Sammlung von Einstellungen zur Durchführung einer Überprüfung. Vorlagen sind notwendig, um wiederholt Überprüfungen mit denselben Einstellungen durchzuführen. Die Vorlage muss unbedingt das Ziel der Überprüfung enthalten; wenn Strategien nicht angegeben sind, werden die am besten geeigneten vorhandenen Strategien ausgewählt.

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

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

Effizienzindikator (Efficacy Indicator) — ein Indikator, der anzeigt, wie gut eine Lösung, die mit dieser Strategie erstellt wurde, funktioniert. Die Leistungskennzahlen sind spezifisch für ein bestimmtes Ziel und werden in der Regel verwendet, um die globale Effektivität des endgültigen Aktionsplans zu berechnen.

Wirksamkeitsspezifikation (Efficacy Specification) — ist eine Reihe spezifischer Merkmale, die mit jedem Ziel verbunden sind und die verschiedenen Leistungskennzahlen definieren, die die Strategie, die die Erreichung des entsprechenden Ziels gewährleistet, in ihrer Lösung erfüllen muss. Tatsächlich wird jede von der Strategie vorgeschlagene Lösung an der Spezifikation gemessen, bevor ihre globale Effektivität berechnet wird.

„Scoring Engine“ (Bewertungsmaschine) — ist eine ausführbare Datei, die klar definierte Eingaben, klar definierte Ausgaben hat und eine rein mathematische Aufgabe ausführt. Daher ist die Berechnung unabhängig von der Umgebung, in der sie ausgeführt wird – sie liefert überall dasselbe Ergebnis.

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

Ziele und Strategien von Watcher

Ziel
Strategien

Dummy-Ziel
Dummy-Strategie

Dummy-Strategie mit Beispielen von Bewertungsmaschinen

Dummy-Strategie mit Größenänderung

Energieeinsparung
Energieeinsparungsstrategie

Serverkonsolidierung
Grundlegende Offline-Serverkonsolidierung

Strategie zur Konsolidierung von VM-Arbeitslasten

Arbeitslastausgleich
Strategie zur Migration des Arbeitslastausgleichs

Strategie zum Ausgleich der Speicherkapazität

Stabilisierung der Arbeitslast

Lauscher-Nachbar
Lauscher-Nachbar

Thermische Optimierung
Strategie basierend auf der Ausgangstemperatur

Luftstromoptimierung
Strategie zur einheitlichen Migration des Luftstroms

Hardwarewartung
Zonenmigration

Unklassifiziert
Aktuator

Dummy-Ziel — Ziel, das für Testzwecke reserviert ist.

Verwandte Strategien: Dummy-Strategie, Dummy-Strategie mit Beispielen von Bewertungsmaschinen und Dummy-Strategie mit Größenänderung. Die Dummy-Strategie ist eine fiktive Strategie, die für Integrationstests über Tempest verwendet wird. Diese Strategie bietet keine nützliche Optimierung, ihr einziges Ziel ist es, Tempest-Tests durchzuführen.

Dummy-Strategie mit Beispiel-Skor engines — diese Strategie ist ähnlich der vorherigen, unterscheidet sich jedoch einzig durch die Verwendung eines Beispiels "Bewertungs-Engines", die Berechnungen mit Methoden des maschinellen Lernens durchführt.

Dummy-Strategie mit Resize — diese Strategie ähnelt der vorherigen, besteht jedoch ausschließlich aus der Anpassung des Flavors (Migration und Resize).

Wird nicht in der Produktion eingesetzt.

Energieeinsparung — den Energieverbrauch minimieren. Die Strategie für dieses Ziel, die Saving Energy Strategy, in Kombination mit der VM Workload Consolidation Strategy (Server Consolidation), kann Funktionen des dynamischen Energiemanagements (DPM) übernehmen, die Strom sparen durch dynamische Konsolidierung von Workloads, selbst in Zeiten niedriger Ressourcenauslastung: Virtuelle Maschinen werden auf eine geringere Anzahl von Knoten verschoben, und nicht benötigte Knoten werden deaktiviert. Nach der Konsolidierung schlägt die Strategie eine Lösung zum Ein-/Ausschalten von Knoten entsprechend den festgelegten Parametern vor: „min_free_hosts_num“ — die Anzahl der freien, eingeschalteten Knoten, die auf Last warten, und „free_used_percent“ — das prozentuale Verhältnis freier, eingeschalteter Knoten zur Anzahl der Knoten, die von Maschinen belegt sind. Um die Strategie zu betreiben, muss Ironic aktiviert und konfiguriert sein, um die Stromversorgung an den Knoten zu steuern.

Strategieparameter

Parameter
Typ
standardmäßig verwendet
Beschreibung

free_used_percent
Zahl
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

Im Cloud sollten mindestens zwei Knoten vorhanden sein. Die verwendete Methode ist das Ändern des Stromstatus des Knotens (change_node_power_state). Für das Sammeln von Metriken ist keine Strategie erforderlich.

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

Die Basic Offline Server Consolidation-Strategie minimiert die Gesamtanzahl der verwendeten Server sowie die Anzahl der Migrationen.

Die Basisstrategie erfordert folgende Metriken:

Metrik
Dienst
Plugins
ein Kommentar

compute.node.cpu.percent
ceilometer
keine

cpu_util
ceilometer
keine

Strategieparameter: migration_attempts – die Anzahl der Kombinationen, um potenzielle Kandidaten für das Ausschalten zu finden (Standardwert: 0, keine Einschränkungen), period – der Zeitintervall in Sekunden für die statische Aggregation aus der Datenquelle der Metrik (Standardwert: 700).

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

Die VM Workload Konsolidierungsstrategie basiert auf einem heuristischen First-Fit-Algorithmus, der sich auf die gemessene CPU-Auslastung konzentriert und versucht, Knoten zu minimieren, die entweder überlastet oder unterlastet sind, unter Berücksichtigung der Kapazitätsbeschränkungen. Diese Strategie bietet eine Lösung, die zu einer effizienteren Ressourcennutzung im Cluster führt, indem sie die folgenden vier Phasen umfasst:

Entlastungsphase — Bearbeitung überbeanspruchter Ressourcen;
Konsolidierungsphase — Bearbeitung untergenutzter Ressourcen;
Optimierungslösung — Reduzierung der Anzahl von Migrationen;
Deaktivierung ungenutzter Rechenknoten.

Die Strategie erfordert folgende Metriken:

Metrik
Dienst
Plugins
ein Kommentar

Speicher
ceilometer
keine

disk.root.size
ceilometer
keine

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

Metrik
Dienst
Plugins
ein Kommentar

memory.resident
ceilometer
keine

cpu_util
ceilometer
keine

Strategieparameter: period — Zeitintervall in Sekunden zur statischen Aggregation aus der Metrikdatenquelle (standardmäßig 3600).

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

Arbeitslastausgleich — die Arbeitslast zwischen den Rechenknoten ausbalancieren. Ziel erreicht man mit drei Strategien: Workload Balance Migration Strategy, Workload Stabilization und Storage Capacity Balance Strategy.

Die Workload Balance Migration Strategy initiiert Migrationsprozesse für virtuelle Maschinen basierend auf der Arbeitslast der Knoten. Die Entscheidung über die Verschiebung wird getroffen, sobald die CPU- oder RAM-Auslastung eines Knotens den festgelegten Schwellenwert überschreitet. Dabei muss die zu verschiebende virtuelle Maschine den Knoten näher an die durchschnittliche Arbeitslast aller Knoten bringen.

Anforderungen

Verwendung physischer Prozessoren;
Mindestens zwei physische Rechenknoten;
Installiertes und konfiguriertes Ceilometer-Komponenten - ceilometer-agent-compute, betrieben auf jedem Rechenknoten, und das Ceilometer API, sowie die Sammlung folgender Metriken:

Metrik
Dienst
Plugins
ein Kommentar

cpu_util
ceilometer
keine

memory.resident
ceilometer
keine

Strategieparameter:

Parameter
Typ
standardmäßig verwendet
Beschreibung

metrics
für einfache Datentypen und Debugging.
'cpu_util'
Metriken, die zugrunde liegen: 'cpu_util', 'memory.resident'.

Schwellenwert
Zahl
25.0
Schwellenwert der Arbeitslast für die Migration.

Zeitraum
Zahl
300
Gesamtzeitraum für Ceilometer.

Verwendete Methode — Migration.

Workload-Stabilisierung – eine Strategie, die darauf abzielt, die Arbeitslast durch Live-Migration zu stabilisieren. Diese Strategie basiert auf einem Standardabweichungsalgorithmus und bestimmt, ob es eine Überlastung im Cluster gibt, und reagiert darauf, indem sie Migrationen startet, um den Cluster zu stabilisieren.

Anforderungen

Verwendung physischer Prozessoren;
Mindestens zwei physische Rechenknoten;
Installiertes und konfiguriertes Ceilometer-Komponenten - ceilometer-agent-compute, betrieben auf jedem Rechenknoten, und das Ceilometer API, sowie die Sammlung folgender Metriken:

Metrik
Dienst
Plugins
ein Kommentar

cpu_util
ceilometer
keine

memory.resident
ceilometer
keine

Speicherkapazitätsausgleichsstrategie (ab Queens implementiert) – diese Strategie verschiebt Festplatten in Abhängigkeit von der Auslastung der Cinder-Pools. Die Entscheidung zur Verschiebung wird jedes Mal getroffen, wenn der Nutzungssatz eines Pools den festgelegten Schwellenwert übersteigt. Die verschobene Festplatte sollte dazu beitragen, den Pool der durchschnittlichen Last aller Cinder-Pools näher zu bringen.

Anforderungen und Einschränkungen

Mindestens zwei Cinder-Pools;
Möglichkeit zur Migration von Festplatten.
Datenmodell des Clusters – Cinder-Cluster-Datenmodell-Sammler.

Strategieparameter:

Parameter
Typ
standardmäßig verwendet
Beschreibung

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

Verwendetes Verfahren – Festplattentransfer (volume_migrate).

Noisy Neighbor — identifizieren und verschieben Sie den „lauten Nachbarn“ — eine virtuelle Maschine mit niedriger Priorität, die die Leistung einer virtuellen Maschine mit hoher Priorität negativ beeinflusst, indem sie den Last Level Cache übermäßig nutzt. Eigene Strategie: Noisy Neighbor (verwendeter Strategieparameter — cache_threshold (Standardwert — 35), Migration wird initiiert, wenn die Leistung den angegebenen Wert erreicht. Für das Funktionieren der Strategie sind aktivierte LLC (Last Level Cache) Metriken, der neueste Intel-Server mit CMT-Unterstützung, sowie das Sammeln der folgenden Metriken erforderlich:

Metrik
Dienst
Plugins
ein Kommentar

cpu_l3_cache
ceilometer
keine
Benötigt Intel CMT.

Cluster-Datenmodell (Standard): Nova Cluster Datenmodell-Sammler. Zugewandte Methode — Migration.

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

Thermische Optimierung — den Temperaturhaushalt optimieren. Die Austrittstemperatur (Abluft) ist eines der wichtigen Wärme-Überwachungssysteme zur Messung des Zustands der thermischen / Arbeitslast des Servers. Zu diesem Zweck gibt es eine Strategie – die Outlet-Temperatur-basierte Strategie, die Entscheidungen über die Verlagerung von Arbeitslasten auf Knoten mit günstigen Temperaturbedingungen (die niedrigste Austrittstemperatur) trifft, wenn die Austrittstemperatur der ursprünglichen Hosts einen einstellbaren Schwellenwert erreicht.

Für das Funktionieren der Strategie ist ein Server mit installiertem und konfiguriertem Intel Power Node Manager erforderlich. 3.0 oder höher, sowie das Sammeln der folgenden Metriken erforderlich:

Metrik
Dienst
Plugins
ein Kommentar

hardware.ipmi.node.outlet_temperature
ceilometer
IPMI

Strategieparameter:

Parameter
Typ
standardmäßig verwendet
Beschreibung

Schwellenwert
Zahl
35.0
Temperaturschwelle für die Migration.

Zeitraum
Zahl
30
Zeitintervall in Sekunden zur statistischen Aggregation aus der Quelle der Metrik.

Verwendete Methode — Migration.

Luftstromoptimierung — den Lüftungsmodus optimieren. Die eigene Strategie – Uniform Airflow using live migration. Diese Strategie startet die Migration der virtuellen Maschine, sobald der Luftstrom des Serverventilators den angegebenen Schwellenwert überschreitet.

Für das Funktionieren der Strategie sind erforderlich:

Hardware: Rechenknoten < mit Unterstützung für NodeManager 3.0;
Mindestens zwei Rechenknoten;
Installierte und konfigurierte Komponenten wie ceilometer-agent-compute und die Ceilometer-API auf jedem Rechenknoten, die erfolgreich Metriken wie Luftstrom, Systemleistung und Eingangstemperatur melden können:

Metrik
Dienst
Plugins
ein Kommentar

hardware.ipmi.node.airflow
ceilometer
IPMI

hardware.ipmi.node.temperature
ceilometer
IPMI

hardware.ipmi.node.power
ceilometer
IPMI

Für die Strategie wird ein Server benötigt, auf dem Intel Power Node Manager 3.0 oder eine neuere Version installiert und konfiguriert ist.

Einschränkungen: Das Konzept ist nicht für den Produktionseinsatz gedacht.

Es wird empfohlen, diesen Algorithmus mit kontinuierlichen Audits zu verwenden, da in einer Iteration nur eine virtuelle Maschine migriert werden soll.

Live-Migrationen sind möglich.

Strategieparameter:

Parameter
Typ
standardmäßig verwendet
Beschreibung

threshold_airflow
Zahl
400.0
Luftstromschwelle für die Migration Einheit ist 0.1 CFM

threshold_inlet_t
Zahl
28.0
Eingangstemperaturschwelle für die Migrationsentscheidung

threshold_power
Zahl
350.0
Systemleistungs-Schwelle für die Migrationsentscheidung

Zeitraum
Zahl
30
Zeitintervall in Sekunden zur statistischen Aggregation aus der Quelle der Metrik.

Verwendete Methode — Migration.

Hardwarewartung — Hardware Maintenance. Die betreffende Strategie ist die Zonenmigration. Diese Strategie dient als Werkzeug für eine effektive, automatische und minimalinvasive Migration von virtuellen Maschinen und Festplatten, falls eine technische Wartung der Hardware erforderlich ist. Die Strategie legt einen Aktionsplan anhand von Gewichten fest: Handlungen mit höherem Gewicht werden priorisiert. Es gibt zwei Konfigurationsparameter: Aktionsgewichte (action_weights) und Parallelisierung (parallelization).

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

Strategieparameter:

Parameter
Typ
standardmäßig verwendet
Beschreibung

compute_nodes
array
None
Rechnerknoten für Migration.

storage_pools
array
None
Speicherpools für Migration.

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

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

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

Priorität
Objekt
None
Prioritätenliste für virtuelle Maschinen und Festplatten.

with_attached_volume
boolean
False
Falsch — virtuelle Maschinen werden nach dem Transfer aller Festplatten migriert. Wahr — virtuelle Maschinen werden nach der Migration aller angeschlossenen Festplatten übertragen.

Elemente des Arrays von Rechenknoten:

Parameter
Typ
standardmäßig verwendet
Beschreibung

src_node
string
None
Der Rechenknoten, von dem die virtuellen Maschinen übertragen werden (erforderlich).

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

Elemente des Arrays von Speicherpools:

Parameter
Typ
standardmäßig verwendet
Beschreibung

src_pool
string
None
Der Speicherpool, aus dem die Festplatten übertragen werden (erforderlich).

dst_pool
string
None
Der Speicherpool, auf den die Festplatten übertragen werden.

src_type
string
None
Der ursprüngliche Typ der Festplatte (erforderlich).

dst_type
string
None
Der endgültige Typ der Festplatte (erforderlich).

Elemente der Priorisierung von Objekten:

Parameter
Typ
standardmäßig verwendet
Beschreibung

project
array
None
Namen der Projekte.

compute_node
array
None
Namen der Rechenknoten.

storage_pool
array
None
Namen der Speicherpools.

compute
enum
None
Parameter der virtuellen Maschinen [“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 — eine unterstützende Zielsetzung, die den Entwicklungsprozess der Strategie erleichtert. Sie enthält keine spezifischen Vorgaben und kann eingesetzt werden, wenn die Strategie noch nicht mit einem bestehenden Ziel verknüpft ist. Dieses Ziel kann auch als Übergangsstufe genutzt werden. Die mit diesem Ziel verbundene Strategie ist – Actuator.

Neues Ziel erstellen

Watcher Decision Engine verfügt über ein Plugin-Interface für 'externe Ziele', das die Integration eines externen Ziels ermöglicht, welches durch die Strategie erreicht werden kann.

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

Neues Plugin erstellen

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

Sie müssen außerdem die Klassenmethode get_display_name () Um den übersetzten Anzeigenamen des Ziels zurückzugeben, das Sie erstellen möchten (verwenden Sie keine Variable, um die übersetzte Zeichenfolge zurückzugeben, damit sie automatisch vom Übersetzungstool gesammelt werden kann.).

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

Implementieren Sie seine Methode get_efficacy_specification (), um die Effizienzspezifikation für Ihr Ziel zurückzugeben. Die Methode get_efficacy_specification () gibt eine Instanz von Unclassified () zurück, die von Watcher bereitgestellt wird. Diese Effizienzspezifikation ist nützlich im Entwicklungsprozess Ihres Ziels, da sie mit einer leeren Spezifikation übereinstimmt.

→ Weitere Informationen finden Sie hier

Die Architektur von Watcher (mehr dazu hier).

Komponenten

Watcher API — ein Bestandteil, der die von Watcher bereitgestellte REST API implementiert. Interaktionsmechanismen: CLI, Horizon-Plugin, Python SDK.

Watcher DB — die Datenbank von Watcher.

Watcher Applier — ein Bestandteil, der die Ausführung des vom Watcher Decision Engine erstellten Aktionsplans implementiert.

Watcher Decision Engine — eine Komponente, die dafür verantwortlich ist, eine Reihe potenzieller Optimierungsmaßnahmen zur Erreichung des Audit-Ziels zu berechnen. Wenn keine Strategie angegeben ist, wählt die Komponente eigenständig die am besten geeignete aus.

Watcher Metrics Publisher — eine Komponente, die bestimmte Metriken oder Ereignisse sammelt und berechnet und diese an einen Endpunkt von CEP veröffentlicht. Die Funktionalität dieser Komponente kann auch vom Ceilometer-Publisher bereitgestellt werden.

Complex Event Processing (CEP) Engine — der Engine für komplexe Ereignisverarbeitung. Aus Leistungsgründen kann es mehrere Instanzen des CEP-Engines geben, die gleichzeitig arbeiten, wobei jede für einen bestimmten Typ von Metrik / Ereignis zuständig ist. In der Watcher-System führt CEP zwei Arten von Aktionen aus: — die entsprechenden Ereignisse / Metriken in einer Zeitreihe-Datenbank zu protokollieren; — die entsprechenden Ereignisse an die Komponente Watcher Decision Engine zu senden, wenn dieses Ereignis das Ergebnis der aktuellen Optimierungsstrategie beeinflussen könnte, da der OpenStack-Cluster kein statisches System ist.

Die Kommunikation zwischen den Komponenten erfolgt über das AMQP-Protokoll.

→ Konfiguration des Watchers

Schema der Interaktion mit dem Watcher

Testergebnisse des Watchers

Auf der Seite Optimierung — Aktionspläne gibt es einen 500-Fehler (sowohl auf reinem Queens als auch auf der Testumgebung mit TioniX-Modulen), der nur auftritt, nachdem das Audit gestartet und der Aktionsplan generiert wird; eine leere Seite öffnet sich normal.
Auf der Registerkarte Aktionsdetails gibt es Fehler; das Ziel und die Strategie des Audits können nicht abgerufen werden (sowohl auf reinem Queens als auch auf der Testumgebung mit TioniX-Modulen).
Audits mit dem Ziel Dummy (Testfälle) werden erfolgreich erstellt und gestartet, Aktionspläne werden generiert.
Audits mit dem Ziel Unclassified werden nicht erstellt, da das Ziel nicht funktionsfähig ist und für die Zwischenkonfiguration beim Erstellen neuer Strategien gedacht ist.
Audits mit dem Ziel Workload Balancing (Strategie zur Balance der Speicherkapazität) werden erfolgreich erstellt, jedoch wird kein Aktionsplan generiert. Es ist keine Optimierung der Speicherpools erforderlich.
Audits mit dem Ziel Workload Balancing (Strategie zur Migration des Workloads) werden erfolgreich erstellt, jedoch wird kein Aktionsplan generiert.
Audits mit dem Ziel Workload Balancing (Strategie zur Stabilisierung des Workloads) enden mit einem Fehler.
Audits mit dem Ziel Noisy Neighbor werden erfolgreich erstellt, jedoch wird kein Aktionsplan generiert.
Audits zur Hardware-Wartung werden erfolgreich erstellt, der Aktionsplan wird jedoch nicht vollständig generiert (Leistungskennzahlen werden generiert, aber die Liste der Maßnahmen wird nicht erstellt).
Änderungen in den Konfigurationen von nova.conf (in der Default-Sektion compute_monitors = cpu.virt_driver) beheben die Fehler auf den Rechen- und Kontrollknoten nicht.
Audits zur Server-Konsolidierung (Basic-Strategie) enden ebenfalls mit einem Fehler.
Audits zur Server-Konsolidierung (Strategie der VM-Arbeitslastkonsolidierung) enden mit einem Fehler. In den Protokollen wird ein Fehler beim Abrufen der Rohdaten angezeigt. Fehlerdiskussion, insbesondere. hier.
Wir haben versucht, in der Konfigurationsdatei von Watcher anzugeben (hat nicht geholfen – in Folge traten Fehler auf allen Seiten der Optimierung auf, eine Rückkehr zum ursprünglichen Inhalt der Konfigurationsdatei behebt die Situation nicht):
[watcher_strategies.basic]
datasource = ceilometer, gnocchi
Audits zur Energieeinsparung enden mit einem Fehler. Anhand der Protokolle scheint das Problem tatsächlich im Fehlen von Ironic zu liegen, ohne Baremetal-Service funktioniert es nicht.
Audits zur thermischen Optimierung enden mit einem Fehler. Der Traceback ist derselbe wie bei der Server-Konsolidierung (Strategie der VM-Arbeitslastkonsolidierung) (Fehler bei den Rohdaten).
Audits zur Optimierung des Airflows enden mit einem Fehler.

Es treten auch die folgenden Fehler im Abschlussbericht auf. Der Traceback in den decision-engine.log (Zustand des Clusters nicht definiert).

→ Fehlerdiskussion hier

Fazit

Das Ergebnis unserer zweimonatigen Untersuchungen ist die klare Erkenntnis, dass wir für eine vollfunktionsfähige, operative Lastverteilung in diesem Bereich aktiv an der Entwicklung der Werkzeuge für die OpenStack-Plattform arbeiten müssen.

Watcher hat sich als ein ernstzunehmendes, schnell wachsendes Produkt mit großem Potenzial erwiesen, für dessen vollständige Nutzung jedoch eine umfassende und gründliche Arbeit erforderlich ist.

Doch dazu mehr in den nächsten Artikeln der Reihe.

Quelle: habr.com