Get best of the week

Auswertung der integrierten Serverlastmetriken

Bei einer der größten Banken des Landes musste ich mich der Aufgabe stellen, die Effizienz der Ressourcennutzung von ungefähr 16.000 Servern zu bewerten. Die Aufgabe wurde sehr einfach formuliert - es war notwendig, eine Methodik zur Bewertung der Serverlastmetriken für einen bestimmten Zeitraum zu entwickeln. Idealerweise sollte die Serverlast pro Periode anhand einer oder mehrerer (nicht mehr als 8) Zahlen geschätzt werden.

Ein paar Worte zu den Funktionen der Verwendung virtueller Server


Große Unternehmen (insbesondere Banken) verfügen über einen bunten Zoo von Legacy-Anwendungen, die mithilfe verschiedener Virtualisierungstechnologien auf verschiedenen Servern bereitgestellt werden. Eine private Cloud ist eine vielversprechende Technologie, aber in Wirklichkeit werden große Unternehmen lange Zeit verschiedene Virtualisierungsplattformen verwenden, um eine Vielzahl von Anwendungen bereitzustellen.

Während sich die Virtualisierungsplattformen weiterentwickeln, kann niemand im Unternehmen verstehen, wie effizient die Ressourcen genutzt werden. Selbst die fortschrittlichsten Überwachungstools bieten aufgrund verschiedener Servernutzungsszenarien keine Antwort auf diese Frage. Beispielsweise kann eine Abteilung über einen Berichtsserver verfügen, der nur für einen begrenzten Zeitraum vollständig geladen ist. Sagen Sie 3-4 Stunden am Ende des Monats. In realen Szenarien weist niemand solchen Servern dynamisch Ressourcen zu - dies ist technisch und organisatorisch schwierig. Ressourcen werden speziell für die maximale periodische Serverlast zugewiesen, obwohl dies selten vorkommt.

Zusammenfassend lässt sich sagen, dass in großen Organisationen die Ressourcen virtueller Farmen äußerst ineffizient eingesetzt werden.

Im Folgenden schlage ich eine Methode vor, mit der Sie die Zunahme und Abnahme der dem virtuellen Server zugewiesenen Ressourcen unabhängig vom Szenario leicht rechtfertigen können.

Methodik


Um die Ressourcenlast zu bewerten, müssen Statistiken verschiedener Zähler gesammelt werden. Um die Ressourcenlast zu bewerten, werden verschiedene Metriken verwendet. Herkömmlicherweise können Zähler in zwei Typen unterteilt werden (je nach Änderungsrate): "schnell" und "langsam". Ein gutes Beispiel für einen „schnellen“ Zähler ist der Prozessorlastzähler (% CPU). Ein Beispiel für einen langsamen Zähler ist der Prozentsatz des freien Festplattenspeichers (% FreeSpace).
Die Bewertung langsamer Zähler besteht in der Berechnung des Extremwerts (Minimum oder Maximum) der Metrik für den Zeitraum. Dieser Ansatz ermöglicht es (beispielsweise bei der Bewertung des freien Speicherplatzes), die freie Ressource zu schätzen und bei Bedarf zusätzliche Volumes zuzuweisen oder aktuelle zu reduzieren.

Für schnelle Zähler wird ein anderer Ansatz verwendet. Die Nachteile der Verwendung einfacher integraler Metriken (Durchschnitt, Maximum, Minimum und Median) zur Beurteilung der Dynamik solcher Zähler werden hier ausführlich beschrieben . Häufige Nachteile sind das Fehlen von Informationen über erhöhte Belastungen (mittel und spitz). Wenn wir den Maximalwert für den Zeitraum als integrale Metrik verwenden, liefert das Vorhandensein von Ausreißern (z. B. sofortiges Laden der CPU bis zu 100% beim Start des Programms) keine objektiven Informationen.

Im ArtikelEs wird vorgeschlagen, das Quantil 0,9 zu verwenden, um die schnelle Metrik zu schätzen (dies ist ein Wert, der das Niveau angibt, unter dem der beobachtete Wert in 90% der Proben liegt). Mit einer einheitlichen Serverlast gemäß dieser Metrik können wir die durchschnittliche Prozessorlast angemessen schätzen. Dieser Ansatz hat jedoch die gleichen Nachteile - den Mangel an Informationen über erhöhte Belastungen (mittel und spitz).

Unten zur Veranschaulichung das Wochen- und Tages-Chart des% CPU-Zählers. Der maximale Zählerwert in den Charts betrug 100%.





Die Grafik zeigt, dass während des angegebenen Zeitraums ein Laststoß auftritt, der etwa 3 Stunden dauert. Für diesen Zähler wurden verschiedene Metriken für die Woche berechnet. Abbildung 2 zeigt, dass der Median (grüne Linie, 5% -Wert), der Durchschnitt (gelb, 12% -Wert) und das 0,9-Quantil (rot, 27% -Wert) die Laständerung filtern und Informationen darüber verloren gehen.

Als Weiterentwicklung der Idee der Quantile möchte ich die Idee eines gleitenden Quantils vorschlagen. Dies ist ein Analogon zum gleitenden Durchschnitt.Das Quantil 0.9 wird jedoch als Fensterfunktion verwendet. Darüber hinaus werden wir 2 gleitende Quantile verwenden, um den Pegel des Zählers zu schätzen - schnell mit einer kurzen Zeitspanne (1 Stunde) und langsam mit einer langen Zeitspanne (24 Stunden). Ein schnelles Quantil filtert momentane Emissionen heraus und liefert Informationen zur Spitzenlast. Mit einem langsamen Quantil können Sie die durchschnittliche Belastung abschätzen.

Wie Sie den Grafiken entnehmen können, sind sich bewegende Quantile von 0,9 dynamische Eigenschaften (braun - schnell, lila - langsam). Zur Vereinfachung wird der Status des Zählers als Metrik bewertet, deren Verwendung vorgeschlagen wird:

  • der maximale Quantilwert mit einem Zeitraum von 1 Stunde, der die maximale kontinuierliche Serverlast für den Zeitraum anzeigt,
  • Der durchschnittliche Quantilwert mit einem Zeitraum von 24 Stunden, der die durchschnittliche Serverlast für den Zeitraum angibt.

In der Grafik ist der Maximalwert des schnellen Quantils die schwarze Linie bei 85%, der Durchschnittswert des langsamen Quantils ist die rosa Linie bei 30%.

Wenn wir also bei der Analyse der Auslastung der Serverressourcen (gemäß dem% CPU-Zähler) den Durchschnitt des Monats (12%) als Metrik verwenden, können wir eine fehlerhafte Entscheidung treffen, um die zugewiesenen Ressourcen zu reduzieren. Die doppelte schnell / langsam bewegende Quantilmetrik (85 und 30%) zeigt, dass genügend Ressourcen zugewiesen sind, aber keine Überschüsse.

Entscheidung


Die Durchführung der Bewertung der Effizienz der Ressourcennutzung hat sich in drei Aufgaben unterteilt:

  1. Datensammlung
  2. Entwicklung der Bewertungsmethode
  3. Implementierung der Methodik in der aktuellen Architektur

Oben habe ich Aufgabe 2 dieser Implementierung untersucht, unten werden wir ein wenig über die dritte Aufgabe sprechen.

Die Daten wurden in der ClickHouse-Datenbank gesammelt. Diese Spalte DBMS ist ideal zum Speichern von Zeitreihendaten. Dies wurde beim ClickHouse Meetup am 5. September 2019 ausführlich besprochen . Einen Vergleich von ClickHouse mit anderen Zeitreihen-DBMS finden Sie hier .
Als Ergebnis der Datenerfassung haben wir mehrere Tabellen gebildet, in denen die Daten zeilenweise organisiert waren (die Werte jedes Zählers wurden in eine separate Zeile geschrieben). Und natürlich gab es Probleme mit Rohdaten.

Das erste Problem ist die Ungleichmäßigkeit der Intervalle zwischen den Zählereinträgen. Wenn beispielsweise die Standardaufzeichnungszeit für Zähler 5 Minuten betrug, gab es manchmal Lücken und die nächste Aufzeichnung war mehr als 5 Minuten (bis zu 20 Minuten) von der vorherigen entfernt.

Das zweite Problem ist, dass die Zählerdaten manchmal zwei- oder mehrmals (mit unterschiedlichen Werten) mit demselben Zeitstempel vorliegen.

Und das dritte Problem - ClickHouse hat keine Fensterfunktionen.

Um das erste Problem zu lösen, können Sie ASOF JOIN verwenden. Die Idee ist ganz einfach: Für jeden Zähler jedes Servers wird eine Tabelle mit gleichmäßig gefüllten Zeitintervallen gleichmäßig erstellt. Mit ASOF JOIN können die Werte in der neuen Tabelle mit den nächstgelegenen Werten aus der Rohdatentabelle gefüllt werden (Fülloptionen ähnlich wie ffill und bfill können konfiguriert werden).

Die Lösung für das zweite Problem ist die Aggregation mit der Wahl des Maximalwerts zu einem bestimmten Zeitpunkt.

Um das dritte Problem zu lösen, wurden mehrere Lösungen in Betracht gezogen. Erstens wurde das Python-Skript aufgrund unzureichender Leistung abgelehnt. Die zweite Lösung - das Kopieren von Rohdaten in eine MSSQL-Datenbank, das Berechnen von Metriken und das Zurückkopieren - schien zu kompliziert für die Implementierung. MSSQL verfügt auch über Fensterfunktionen, es wird jedoch keine Aggregatfunktion benötigt. Man könnte verwirrt sein und seine eigene SQL CLR-Funktion schreiben. Diese Option wurde jedoch aufgrund übermäßiger Komplexität abgelehnt.

Eine funktionierende Lösung könnte ein SQL-Skript für ClickHouse sein. Ein Beispiel für dieses Skript finden Sie unten. Der Einfachheit halber habe ich nur das schnelle Quantil für einen einzelnen Zähler für mehrere Server berechnet. Die Lösung sieht nicht sehr einfach und nicht sehr praktisch aus, funktioniert aber.

Als Ergebnis wurde in PowerBI ein Testbericht erstellt, um die Methodik zu demonstrieren.





Fazit


Abschließend möchte ich über die Entwicklung der Lösung spekulieren. Wenn Sie die Lösung aus Sicht von Data Warehouses betrachten, sehen Sie, dass auf diese Weise die Aufgabe gelöst wird, ein Data Warehouse (Data Warehouse) aus einer Rohdatenebene (Staging Area) zu erstellen. Sie können die Architektur diskutieren, aber für ClickHouse als Spaltendatenbank ist die Normalisierung nicht kritisch (oder sogar schädlich).

Die Weiterentwicklung des Repositorys wird in der Erstellung von Aggregattabellen (Tag \ Woche \ Monat) mit unterschiedlichen Lebensdauern (TTL) gesehen. Dadurch wird eine übermäßige Schwellung des Speichers vermieden.
Der nächste Schritt könnte darin bestehen, Daten für prädiktive Analysen zu verwenden.

PS

Der Code und die Daten zum Testen sind hier veröffentlicht .

More articles:


All Articles