In großen Cloud-Systemen ist die Frage des automatischen Ausgleichs oder der Nivellierung der Belastung der Rechenressourcen besonders akut. Auch Tionix (ein Entwickler und Betreiber von Cloud-Diensten, Teil der Rostelecom-Unternehmensgruppe) hat sich um dieses Problem gekümmert.
Und da unsere Hauptentwicklungsplattform Openstack ist und wir, wie alle Menschen, faul sind, wurde beschlossen, ein vorgefertigtes Modul auszuwählen, das bereits in der Plattform enthalten ist. Unsere Wahl fiel auf Watcher, den wir für unsere Zwecke nutzen wollten.
Schauen wir uns zunächst die Begriffe und Definitionen an.
Begriffe und Definitionen
Ziel ist ein für Menschen lesbares, beobachtbares und messbares Endergebnis, das erreicht werden muss. Für jedes Ziel gibt es eine oder mehrere Strategien, um es zu erreichen. Eine Strategie ist die Implementierung eines Algorithmus, der in der Lage ist, eine Lösung für ein gegebenes Ziel zu finden.
Aktion ist eine elementare Aufgabe, die den aktuellen Status der verwalteten Zielressource des OpenStack-Clusters ändert, wie zum Beispiel: Migration einer virtuellen Maschine (Migration), Ändern des Energiestatus eines Knotens (change_node_power_state), Ändern des Status des Nova-Dienstes (change_nova_service_state). ), Geschmacksänderung (Resize), Registrierung von NOP-Meldungen (nop), fehlende Aktion für eine bestimmte Zeitspanne – Pause (sleep), Festplattenübertragung (volume_migrate).
Aktionsplan – ein spezifischer Ablauf von Aktionen, die in einer bestimmten Reihenfolge ausgeführt werden, um ein bestimmtes Ziel zu erreichen. Der Aktionsplan enthält auch eine gemessene globale Leistung mit einer Reihe von Leistungsindikatoren. Nach einem erfolgreichen Audit erstellt Watcher einen Aktionsplan, in dessen Ergebnis die verwendete Strategie eine Lösung zur Zielerreichung findet. Ein Aktionsplan besteht aus einer Liste aufeinanderfolgender Aktionen.
Prüfung ist eine Anfrage zur Optimierung des Clusters. Die Optimierung wird durchgeführt, um ein Ziel in einem bestimmten Cluster zu erreichen. Für jedes erfolgreiche Audit erstellt Watcher einen Aktionsplan.
Prüfungsumfang ist eine Reihe von Ressourcen, innerhalb derer die Prüfung durchgeführt wird (Verfügbarkeitszone(n), Knotenaggregatoren, einzelne Rechenknoten oder Speicherknoten usw.). Der Prüfumfang wird in jeder Vorlage definiert. Wenn kein Prüfumfang angegeben ist, wird der gesamte Cluster geprüft.
Audit-Vorlage — ein gespeicherter Satz von Einstellungen zum Starten eines Audits. Um Audits mehrmals mit denselben Einstellungen durchführen zu können, werden Vorlagen benötigt. In der Vorlage muss unbedingt der Zweck des Audits enthalten sein; wenn keine Strategien angegeben sind, werden die am besten geeigneten vorhandenen Strategien ausgewählt.
Cluster ist eine Sammlung physischer Maschinen, die Rechen-, Speicher- und Netzwerkressourcen bereitstellen und von demselben OpenStack-Verwaltungsknoten verwaltet werden.
Cluster-Datenmodell (CDM) ist eine logische Darstellung des aktuellen Status und der Topologie der vom Cluster verwalteten Ressourcen.
Effizienzindikator – ein Indikator, der angibt, wie die mit dieser Strategie erstellte Lösung umgesetzt wird. Leistungsindikatoren sind spezifisch für ein bestimmtes Ziel und werden typischerweise zur Berechnung der globalen Wirksamkeit des resultierenden Aktionsplans verwendet.
Wirksamkeitsspezifikation ist eine Reihe spezifischer Merkmale, die jedem Ziel zugeordnet sind und die verschiedenen Leistungsindikatoren definieren, die eine Strategie zur Erreichung des entsprechenden Ziels in ihrer Lösung erreichen muss. Tatsächlich wird jede von der Strategie vorgeschlagene Lösung anhand der Spezifikation überprüft, bevor ihre globale Wirksamkeit berechnet wird.
Scoring-Engine ist eine ausführbare Datei, die über wohldefinierte Eingaben und wohldefinierte Ausgaben verfügt und eine rein mathematische Aufgabe ausführt. Auf diese Weise ist die Berechnung unabhängig von der Umgebung, in der sie durchgeführt wird – sie liefert überall das gleiche Ergebnis.
Watcher-Planer - Teil der Watcher-Entscheidungsmaschine. Dieses Modul verwendet eine Reihe von Aktionen, die durch eine Strategie generiert werden, und erstellt einen Arbeitsablaufplan, der angibt, wie diese verschiedenen Aktionen zeitlich geplant werden und welche Voraussetzungen für jede Aktion gelten.
Beobachterziele und -strategien
Ziel
Strategie
Scheinziel
Dummy-Strategie
Dummy-Strategie mit Beispiel-Scoring-Engines
Dummy-Strategie mit Größenänderung
Energie sparen
Energiesparstrategie
Serverkonsolidierung
Grundlegende Offline-Serverkonsolidierung
Strategie zur VM-Workload-Konsolidierung
Workload-Balancing
Migrationsstrategie zur Workload-Balance
Strategie zur Ausgewogenheit der Speicherkapazität
Stabilisierung der Arbeitsbelastung
Lauter Nachbar
Lauter Nachbar
Thermische Optimierung
Auslasstemperaturbasierte Strategie
Luftstromoptimierung
Einheitliche Luftstrom-Migrationsstrategie
Hardware-Wartung
Zonenmigration
Nicht klassifiziert
Actuator
Scheinziel — reserviertes Ziel, das zu Testzwecken verwendet wird.
Verwandte Strategien: Dummy-Strategie, Dummy-Strategie mit Beispiel-Scoring-Engines und Dummy-Strategie mit Größenänderung. Die Dummy-Strategie ist eine Dummy-Strategie, die für Integrationstests durch Tempest verwendet wird. Diese Strategie bietet keine sinnvolle Optimierung, ihr einziger Zweck besteht darin, Tempest-Tests zu verwenden.
Dummy-Strategie unter Verwendung von Beispiel-Scoring-Engines – die Strategie ähnelt der vorherigen, der einzige Unterschied besteht in der Verwendung einer Beispiel-„Scoring-Engine“, die Berechnungen mithilfe von Methoden des maschinellen Lernens durchführt.
Dummy-Strategie mit Größenänderung – die Strategie ähnelt der vorherigen, der einzige Unterschied besteht in der Verwendung der Änderung des Flavors (Migration und Größenänderung).
Wird nicht in der Produktion verwendet.
Energie sparen — Minimierung des Energieverbrauchs. Die Saving Energy Strategy dieses Ziels ist zusammen mit der VM Workload Consolidation Strategy (Server Consolidation) in der Lage, Dynamic Power Management (DPM)-Funktionen bereitzustellen, die Energie sparen, indem Arbeitslasten auch in Zeiten geringer Ressourcenauslastung dynamisch konsolidiert werden: Virtuelle Maschinen werden auf weniger Knoten verschoben und unnötige Knoten werden deaktiviert. Nach der Konsolidierung bietet die Strategie eine Entscheidung über das Ein-/Ausschalten von Knoten gemäß den angegebenen Parametern: „min_free_hosts_num“ – die Anzahl der frei aktivierten Knoten, die auf das Laden warten, und „free_used_percent“ – der Prozentsatz der frei aktivierten Hosts Anzahl der Knoten, die von Maschinen belegt sind. Damit die Strategie funktioniert, muss sie vorhanden sein Ironic wurde aktiviert und konfiguriert, um das Aus- und Einschalten von Knoten zu bewältigen.
Strategieparameter
Parameter
тип
Default
описание
free_used_percent
Nummer
10.0
Verhältnis der Anzahl freier Rechenknoten zur Anzahl Rechenknoten mit virtuellen Maschinen
min_free_hosts_num
Int
1
Mindestanzahl freier Rechenknoten
Die Cloud muss mindestens zwei Knoten haben. Die verwendete Methode besteht darin, den Energiezustand des Knotens zu ändern (change_node_power_state). Die Strategie erfordert keine Erfassung von Kennzahlen.
Serverkonsolidierung – Minimieren Sie die Anzahl der Rechenknoten (Konsolidierung). Es gibt zwei Strategien: Grundlegende Offline-Serverkonsolidierung und VM-Workload-Konsolidierungsstrategie.
Die Strategie „Basic Offline Server Consolidation“ minimiert die Gesamtzahl der verwendeten Server und minimiert auch die Anzahl der Migrationen.
Die Grundstrategie erfordert die folgenden Metriken:
Metriken
Service
Plugins
Kommentar
berechnen.node.cpu.percent
keine
cpu_util
keine
Strategieparameter: migration_attempts – Anzahl der Kombinationen, um nach potenziellen Kandidaten für das Herunterfahren zu suchen (Standard: 0, keine Einschränkungen), Zeitraum – Zeitintervall in Sekunden, um eine statische Aggregation aus der Metrikdatenquelle zu erhalten (Standard: 700).
Verwendete Methoden: Migration, Änderung des Nova-Service-Status (change_nova_service_state).
Die VM-Workload-Konsolidierungsstrategie basiert auf einer First-Fit-Heuristik, die sich auf die gemessene CPU-Auslastung konzentriert und versucht, Knoten zu minimieren, die aufgrund von Ressourcenkapazitätsbeschränkungen zu viel oder zu wenig Auslastung haben. Diese Strategie bietet eine Lösung, die mithilfe der folgenden vier Schritte zu einer effizienteren Nutzung von Clusterressourcen führt:
- Entladephase – Verarbeitung überbeanspruchter Ressourcen;
- Konsolidierungsphase – Umgang mit nicht ausgelasteten Ressourcen;
- Optimierung der Lösung – Reduzierung der Anzahl der Migrationen;
- Deaktivieren nicht verwendeter Rechenknoten.
Die Strategie erfordert die folgenden Metriken:
Metriken
Service
Plugins
Kommentar
Erinnerung
keine
disk.root.size
keine
Die folgenden Metriken sind optional, verbessern jedoch die Strategiegenauigkeit, sofern verfügbar:
Metriken
Service
Plugins
Kommentar
Speicherresident
keine
cpu_util
keine
Strategieparameter: Zeitraum – Zeitintervall in Sekunden, um eine statische Aggregation aus der Metrikdatenquelle zu erhalten (Standard: 3600).
Verwendet die gleichen Methoden wie die vorherige Strategie. Mehr Details .
Workload-Balancing – Ausgleich der Arbeitslast zwischen den Rechenknoten. Das Ziel besteht aus drei Strategien: Workload-Balance-Migrationsstrategie, Workload-Stabilisierung, Speicherkapazitäts-Balance-Strategie.
Die Workload-Balance-Migrationsstrategie führt Migrationen virtueller Maschinen basierend auf der Arbeitslast der virtuellen Host-Maschine durch. Eine Migrationsentscheidung wird immer dann getroffen, wenn die prozentuale CPU- oder RAM-Auslastung eines Knotens den angegebenen Schwellenwert überschreitet. In diesem Fall sollte die verschobene virtuelle Maschine den Knoten näher an die durchschnittliche Arbeitslast aller Knoten bringen.
Bedarf
- Einsatz physischer Prozessoren;
- Mindestens zwei physische Rechenknoten;
- Installierte und konfigurierte die Ceilometer-Komponente – ceilometer-agent-compute, die auf jedem Rechenknoten ausgeführt wird, und die Ceilometer-API sowie die Erfassung der folgenden Metriken:
Metriken
Service
Plugins
Kommentar
cpu_util
keine
Speicherresident
keine
Strategieparameter:
Parameter
тип
Default
описание
Metriken
Schnur
'cpu_util'
Die zugrunde liegenden Metriken sind: „cpu_util“, „memory.resident“.
Schwelle
Nummer
25.0
Arbeitslastschwelle für die Migration.
Zeit
Nummer
300
Kumulativer Zeitraum Ceilometer.
Die verwendete Methode ist Migration.
Die Workload-Stabilisierung ist eine Strategie, die darauf abzielt, die Workload mithilfe der Live-Migration zu stabilisieren. Die Strategie basiert auf einem Standardabweichungsalgorithmus und ermittelt, ob im Cluster eine Überlastung vorliegt, und reagiert darauf, indem sie eine Maschinenmigration auslöst, um den Cluster zu stabilisieren.
Bedarf
- Einsatz physischer Prozessoren;
- Mindestens zwei physische Rechenknoten;
- Installierte und konfigurierte die Ceilometer-Komponente – ceilometer-agent-compute, die auf jedem Rechenknoten ausgeführt wird, und die Ceilometer-API sowie die Erfassung der folgenden Metriken:
Metriken
Service
Plugins
Kommentar
cpu_util
keine
Speicherresident
keine
Storage Capacity Balance Strategy (Strategie, die ab Queens implementiert wird) – die Strategie überträgt Festplatten abhängig von der Auslastung der Cinder-Pools. Eine Übertragungsentscheidung wird immer dann getroffen, wenn die Poolauslastung einen bestimmten Schwellenwert überschreitet. Die verschobene Festplatte sollte den Pool näher an die durchschnittliche Auslastung aller Cinder-Pools bringen.
Anforderungen und Einschränkungen
- Mindestens zwei Cinder-Pools;
- Möglichkeit der Festplattenmigration.
- Cluster-Datenmodell – Cinder-Cluster-Datenmodell-Kollektor.
Strategieparameter:
Parameter
тип
Default
описание
volume_threshold
Nummer
80.0
Schwellenwert der Festplatten für den Volume-Ausgleich.
Die verwendete Methode ist die Festplattenmigration (volume_migrate).
Noisy Neighbor – Identifizieren und migrieren Sie einen „Noisy Neighbor“ – eine virtuelle Maschine mit niedriger Priorität, die sich negativ auf die Leistung einer virtuellen Maschine mit hoher Priorität in Bezug auf IPC auswirkt, indem sie den Last Level Cache überbeansprucht. Eigene Strategie: Noisy Neighbor (der verwendete Strategieparameter ist cache_threshold (Standardwert ist 35), wenn die Leistung auf den angegebenen Wert sinkt, wird die Migration gestartet. Damit die Strategie funktioniert, aktiviert LLC-Metriken (Last Level Cache), Neuester Intel-Server mit CMT-Unterstützung, sowie das Sammeln der folgenden Metriken:
Metriken
Service
Plugins
Kommentar
cpu_l3_cache
keine
Intel erforderlich .
Cluster-Datenmodell (Standard): Nova-Cluster-Datenmodell-Kollektor. Die verwendete Methode ist Migration.
Die Umsetzung dieses Ziels über das Dashboard ist in Queens nicht vollständig implementiert.
Thermische Optimierung — Optimieren Sie das Temperaturregime. Die Auslasstemperatur (Ablufttemperatur) ist eines der wichtigen thermischen Telemetriesysteme zur Messung des thermischen/Auslastungsstatus eines Servers. Das Ziel verfügt über eine Strategie, die auf der Auslasstemperatur basierende Strategie, die entscheidet, Arbeitslasten auf thermisch günstige Hosts (niedrigste Auslasstemperatur) zu migrieren, wenn die Auslasstemperatur der Quellhosts einen konfigurierbaren Schwellenwert erreicht.
Damit die Strategie funktioniert, benötigen Sie einen Server, auf dem Intel Power Node Manager installiert und konfiguriert ist , sowie das Sammeln der folgenden Metriken:
Metriken
Service
Plugins
Kommentar
hardware.ipmi.node.outlet_temperature
IPMI
Strategieparameter:
Parameter
тип
Default
описание
Schwelle
Nummer
35.0
Temperaturschwelle für Migration.
Zeit
Nummer
30
Das Zeitintervall in Sekunden, um die statistische Aggregation aus der Metrikdatenquelle zu erhalten.
Die verwendete Methode ist Migration.
Luftstromoptimierung — Optimieren Sie den Lüftungsmodus. Eigene Strategie – Gleichmäßiger Luftstrom durch Live-Migration. Die Strategie löst die Migration der virtuellen Maschine immer dann aus, wenn der Luftstrom vom Serverlüfter einen bestimmten Schwellenwert überschreitet.
Damit die Strategie funktioniert, benötigen Sie:
- Hardware: Rechenknoten <, die NodeManager 3.0 unterstützen;
- Mindestens zwei Rechenknoten;
- Die Ceilometer-Agent-Compute- und Ceilometer-API-Komponente ist auf jedem Rechenknoten installiert und konfiguriert und kann Metriken wie Luftstrom, Systemleistung und Einlasstemperatur erfolgreich melden:
Metriken
Service
Plugins
Kommentar
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Damit die Strategie funktioniert, benötigen Sie einen Server, auf dem Intel Power Node Manager 3.0 oder höher installiert und konfiguriert ist.
Einschränkungen: Das Konzept ist nicht für die Produktion gedacht.
Es wird vorgeschlagen, diesen Algorithmus bei kontinuierlichen Audits zu verwenden, da nur eine virtuelle Maschine pro Iteration migriert werden soll.
Live-Migrationen sind möglich.
Strategieparameter:
Parameter
тип
Default
описание
Schwellenwert_Luftstrom
Nummer
400.0
Der Luftstromschwellenwert für die Migrationseinheit beträgt 0.1 CFM
Schwellenwert_Einlass_t
Nummer
28.0
Eintrittstemperaturschwelle für Migrationsentscheidung
Schwellenwertleistung
Nummer
350.0
Schwellenwert für die Systemleistung für die Migrationsentscheidung
Zeit
Nummer
30
Das Zeitintervall in Sekunden, um die statistische Aggregation aus der Metrikdatenquelle zu erhalten.
Die verwendete Methode ist Migration.
Hardware-Wartung - Hardware-Wartung. Die mit diesem Ziel verbundene Strategie ist die Zonenmigration. Die Strategie ist ein Tool zur effektiven automatischen und minimalen Migration virtueller Maschinen und Festplatten im Falle einer Hardwarewartung. Die Strategie erstellt einen Aktionsplan entsprechend der Gewichtung: Eine Reihe von Aktionen, die mehr Gewicht haben, werden vor anderen geplant. Es gibt zwei Konfigurationsoptionen: action_weights und parallelization.
Einschränkungen: Aktionsgewichte und Parallelisierung müssen konfiguriert werden.
Strategieparameter:
Parameter
тип
Default
описание
compute_nodes
Array
Andere
Rechenknoten für die Migration.
storage_pools
Array
Andere
Speicherknoten für die Migration.
parallel_total
ganze Zahl
6
Die Gesamtzahl der Aktivitäten, die parallel ausgeführt werden müssen.
parallel_per_node
ganze Zahl
2
Die Anzahl der Aktionen, die für jeden Rechenknoten parallel ausgeführt werden.
parallel_per_pool
ganze Zahl
2
Die Anzahl der Aktionen, die für jeden Speicherpool parallel ausgeführt werden.
Prioritätsliste
Objekt
Andere
Prioritätenliste für virtuelle Maschinen und Festplatten.
with_attached_volume
boolean
falsch
Falsch – virtuelle Maschinen werden migriert, nachdem alle Festplatten migriert wurden. True – virtuelle Maschinen werden migriert, nachdem alle verbundenen Festplatten migriert wurden.
Elemente des Arrays von Rechenknoten:
Parameter
тип
Default
описание
src_node
Schnur
Andere
Der Rechenknoten, von dem die virtuellen Maschinen migriert werden (erforderlich).
dst_node
Schnur
Andere
Berechnen Sie den Knoten, auf den die virtuellen Maschinen migrieren.
Elemente des Speicherknoten-Arrays:
Parameter
тип
Default
описание
src_pool
Schnur
Andere
Der Speicherpool, aus dem die Datenträger migriert werden (erforderlich).
dst_pool
Schnur
Andere
Der Speicherpool, in den Datenträger migriert werden.
src_type
Schnur
Andere
Ursprünglicher Datenträgertyp (erforderlich).
dst_type
Schnur
Andere
Der resultierende Festplattentyp (erforderlich).
Objektprioritätselemente:
Parameter
тип
Default
описание
Projekt
Array
Andere
Projektnamen.
compute_node
Array
Andere
Knotennamen berechnen.
storage_pool
Array
Andere
Speicherpoolnamen.
berechnen
enum
Andere
Parameter der virtuellen Maschine [„vcpu_num“, „mem_size“, „disk_size“, „created_at“].
Lagerung
enum
Andere
Festplattenparameter [„size“, „created_at“].
Die verwendeten Methoden sind die Migration virtueller Maschinen und die Migration von Festplatten.
Nicht klassifiziert - ein Hilfsziel zur Erleichterung des Strategieentwicklungsprozesses. Enthält keine Vorgaben und kann immer dann verwendet werden, wenn die Strategie noch keinem bestehenden Ziel zugeordnet ist. Dieses Ziel kann auch als Übergangspunkt genutzt werden. Eine verwandte Strategie zu diesem Ziel ist Actuator.
Ein neues Ziel schaffen
Watcher-Entscheidungs-Engine verfügt über eine „Externes Ziel“-Plugin-Schnittstelle, die es ermöglicht, ein externes Ziel zu integrieren, das mit einer Strategie erreicht werden kann.
Bevor Sie ein neues Ziel erstellen, sollten Sie sicherstellen, dass keine vorhandenen Ziele Ihren Anforderungen entsprechen.
Erstellen eines neuen Plugins
Um ein neues Ziel zu erstellen, müssen Sie: die Zielklasse erweitern, eine Klassenmethode implementieren get_name() um die eindeutige ID des neuen Ziels zurückzugeben, das Sie erstellen möchten. Dieser eindeutige Bezeichner muss mit dem Namen des Einstiegspunkts übereinstimmen, den Sie später deklarieren.
Als nächstes müssen Sie die Klassenmethode implementieren 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 erfasst werden kann.).
Implementieren Sie eine Klassenmethode get_translatable_display_name()um den Übersetzungsschlüssel (eigentlich den englischen Anzeigenamen) Ihres neuen Ziels zurückzugeben. Der Rückgabewert muss mit der in get_display_name() übersetzten Zeichenfolge übereinstimmen.
Implementieren Sie seine Methode get_efficacy_specification()um die Effizienzspezifikation für Ihr Ziel zurückzugeben. Die Methode get_efficacy_pecification() gibt die von Watcher bereitgestellte Unclassified()-Instanz zurück. Diese Leistungsspezifikation ist bei der Entwicklung Ihres Ziels hilfreich, da sie der leeren Spezifikation entspricht.
→
Watcher-Architektur (weitere Details) ).
Komponenten
Watcher-API – eine Komponente, die die von Watcher bereitgestellte REST-API implementiert. Interaktionsmechanismen: CLI, Horizon-Plugin, Python SDK.
Watcher DB – Watcher-Datenbank.
Watcher-Anwender – eine Komponente, die die Ausführung eines Aktionsplans implementiert, der von der Watcher Decision Engine-Komponente erstellt wurde.
Watcher-Entscheidungs-Engine – Die Komponente, die für die Berechnung einer Reihe potenzieller Optimierungsmaßnahmen zur Erreichung des Prüfziels verantwortlich ist. Wenn keine Strategie angegeben ist, wählt die Komponente selbstständig die am besten geeignete aus.
Herausgeber von Watcher Metrics – Eine Komponente, die einige Metriken oder Ereignisse sammelt und berechnet und sie am CEP-Endpunkt veröffentlicht. Die Funktionalität der Komponente kann auch vom Ceilometer-Herausgeber bereitgestellt werden.
Engine für komplexe Ereignisverarbeitung (CEP). — Engine für die Verarbeitung komplexer Ereignisse. Aus Leistungsgründen können mehrere CEP Engine-Instanzen gleichzeitig ausgeführt werden, wobei jede eine bestimmte Art von Metrik/Ereignis verarbeitet. Im Watcher-System löst CEP zwei Arten von Aktionen aus: - Aufzeichnung der entsprechenden Ereignisse/Metriken in der Zeitreihendatenbank; - Senden Sie entsprechende Ereignisse an die Watcher Decision Engine, wenn dieses Ereignis das Ergebnis der aktuellen Optimierungsstrategie beeinflussen kann, da der Openstack-Cluster kein statisches System ist.
Die Komponenten interagieren über das AMQP-Protokoll.
→
Schema der Interaktion mit Watcher
Ergebnisse des Watcher-Tests
- Auf der Seite „Optimierung – Aktionspläne 500“ (sowohl auf reinen Queens als auch auf einem Stand mit Tionix-Modulen) erscheint sie erst, nachdem das Audit gestartet und ein Aktionsplan erstellt wurde; die leere Seite wird normal geöffnet.
- Auf der Registerkarte „Aktionsdetails“ sind Fehler aufgetreten. Es ist nicht möglich, das Prüfungsziel und die Prüfungsstrategie abzurufen (sowohl bei reinen Queens als auch bei einem Stand mit Tionix-Modulen).
- Audits mit dem Zweck Dummy (Test) werden normal erstellt und gestartet, Aktionspläne werden generiert.
- Audits für das Ziel „Nicht klassifiziert“ werden nicht erstellt, da das Ziel nicht funktionsfähig ist und für die Zwischenkonfiguration bei der Erstellung neuer Strategien vorgesehen ist.
- Audits zum Zweck des Workload-Balancings (Strategie zum Ausgleich der Speicherkapazität) werden erfolgreich erstellt, es wird jedoch kein Aktionsplan erstellt. Keine Optimierung des Speicherpools erforderlich.
- Audits für das Workload-Balancing-Ziel (Workload-Balance-Migrationsstrategie) werden erfolgreich erstellt, es wird jedoch kein Aktionsplan generiert.
- Audits zum Workload-Balancing (Workload-Stabilisierungsstrategie) schlagen fehl.
- Audits für das Ziel „Noisy Neighbor“ werden erfolgreich erstellt, es wird jedoch kein Aktionsplan erstellt.
- Audits zum Zweck der Hardwarewartung werden erfolgreich erstellt, der Aktionsplan wird nicht vollständig generiert (Leistungsindikatoren werden generiert, aber die Liste der Aktionen selbst wird nicht generiert).
- Änderungen in den nova.conf-Konfigurationen (im Standardabschnitt „compute_monitors = cpu.virt_driver“) auf den Rechen- und Steuerknoten beheben die Fehler nicht.
- Auch Prüfungen zur Serverkonsolidierung (Basisstrategie) schlagen fehl.
- Audits zum Zweck der Serverkonsolidierung (VM-Workload-Konsolidierungsstrategie) schlagen mit einem Fehler fehl. In den Protokollen ist ein Fehler beim Abrufen der Quelldaten aufgetreten. Insbesondere Diskussion des Fehlers .
Wir haben versucht, Watcher in der Konfigurationsdatei anzugeben (es hat nicht geholfen – aufgrund eines Fehlers auf allen Optimierungsseiten behebt die Rückkehr zum ursprünglichen Inhalt der Konfigurationsdatei die Situation nicht): [watcher_strategies.basic] Datenquelle = Ceilometer, Gnocchi - Audits zum Energiesparen scheitern. Den Protokollen nach zu urteilen, ist das Problem immer noch das Fehlen von Ironic; ohne Bare-Metal-Service wird es nicht funktionieren.
- Audits zur thermischen Optimierung schlagen fehl. Der Traceback ist derselbe wie bei der Serverkonsolidierung (VM-Workload-Konsolidierungsstrategie) (Quelldatenfehler).
- Audits zum Zweck der Luftstromoptimierung schlagen mit einem Fehler fehl.
Außerdem sind die folgenden Prüfungsabschlussfehler aufgetreten. Traceback in Decision-Engine.log-Protokollen (Clusterstatus ist nicht definiert).
→ Diskussion des Fehlers
Abschluss
Das Ergebnis unserer zweimonatigen Recherche war die eindeutige Schlussfolgerung, dass wir in diesem Teil eng an der Weiterentwicklung der Tools für die Openstack-Plattform arbeiten müssen, um ein vollwertiges, funktionierendes Lastausgleichssystem zu erhalten.
Watcher hat sich als seriöses und sich schnell entwickelndes Produkt mit enormem Potenzial erwiesen, dessen volle Nutzung eine Menge ernsthafter Arbeit erfordert.
Aber mehr dazu in den nächsten Artikeln der Serie.
Source: habr.com