Im haben wir über die Versuche berichtet, den Watcher zu nutzen und den Testbericht vorgestellt. Solche Tests führen wir regelmäßig zur Lastverteilung und für andere kritische Funktionen einer großen Unternehmens- oder Betreiber-Cloud durch.
Die hohe Komplexität der zu lösenden Aufgabe erfordert möglicherweise mehrere Artikel zur Beschreibung unseres Projekts. Heute veröffentlichen wir den zweiten Artikel der Reihe, der sich mit der Lastverteilung von virtuellen Maschinen in der Cloud beschäftigt.
Ein wenig Terminologie
Das Unternehmen VmWare hat das DRS-Tool (Distributed Resource Scheduler) zur Lastverteilung für ihre entwickelte und angebotene Virtualisierungsumgebung eingeführt.
Wie auf
„VMware DRS (Distributed Resource Scheduler) ist ein Tool, das die Rechenlast mit den verfügbaren Ressourcen in einer virtuellen Umgebung ausgleicht. Das Tool ist Teil eines Virtualisierungspakets mit dem Namen VMware Infrastructure.
Mit VMware DRS legen Benutzer Regeln für die Verteilung der physischen Ressourcen zwischen virtuellen Maschinen (VMs) fest. Das Tool kann auf manuelle oder automatische Verwaltung eingestellt werden. VMware-Ressourcengruppen können problemlos hinzugefügt, entfernt oder reorganisiert werden. Auf Wunsch können Ressourcengruppen zwischen verschiedenen Geschäftseinheiten isoliert werden. Wenn die Arbeitslast einer oder mehrerer virtueller Maschinen stark schwankt, verteilt VMware DRS die virtuellen Maschinen zwischen den physischen Servern. Wenn die gesamte Arbeitslast abnimmt, können einige physische Server vorübergehend abgeschaltet und die Arbeitslast konsolidiert werden.
Warum ist Lastverteilung notwendig?
Wir sind der Meinung, dass DRS eine erforderliche Funktion der Cloud ist, auch wenn dies nicht bedeutet, dass DRS immer und überall verwendet werden muss. Je nach Zweck und Bedürfnissen der Cloud können unterschiedliche Anforderungen an DRS und die Lastverteilungsmethoden bestehen. Es gibt möglicherweise Situationen, in denen Lastverteilung überhaupt nicht notwendig ist oder sogar schädlich ist.
Um besser zu verstehen, wo und für welche Kunden DRS benötigt wird, betrachten wir deren Ziele und Aufgaben. Clouds können in öffentliche und private unterteilt werden. Hier sind die wichtigsten Unterschiede zwischen diesen Clouds und den Zielen der Kunden.
Private Clouds / Große Unternehmensklienten
Öffentliche Clouds / Kleine und mittlere Unternehmen, Privatpersonen
Hauptkriterium und Ziele des Betreibers
Bereitstellung eines zuverlässigen Dienstes oder Produkts
Senken der Kosten der Dienstleistungen im Wettbewerb
Anforderungen an den Service
Zuverlässigkeit auf allen Ebenen und in allen Systemelementen
Garantierte Leistung
Priorisierung von virtuellen Maschinen in mehrere Kategorien
Informations- und physische Sicherheit der Daten
SLA und 24/7-Support
Maximale Einfachheit beim Erhalt des Dienstes
Relativ einfache Dienstleistungen
Die Verantwortung für die Daten liegt beim Kunden
Eine Priorisierung von VMs ist nicht erforderlich
Informationssicherheit auf Ebene der standardmäßigen Dienste, Verantwortung liegt beim Kunden
Es können Ausfälle auftreten
Kein SLA, Qualität nicht garantiert
Unterstützung per E-Mail
Backup ist nicht obligatorisch
Besonderheiten des Kunden
Sehr breites Spektrum an Anwendungen.
Legacy-Anwendungen, die im Unternehmen geerbt wurden.
Komplexe, maßgeschneiderte Architekturen für jeden Kunden.
Affinity-Regeln.
Betrieb der Software ohne Unterbrechung im 7x24-Modus.
Backup-Mittel "on-the-fly".
Vorhersehbare zyklische Last des Kunden.
Standardanwendungen – Netzwerkbalancierung, Apache, WEB, VPN, SQL
Anwendung kann für kurze Zeit gestoppt werden
Willkürliche Verteilung von VMs in der Cloud ist erlaubt
Backup durch den Kunden
Vorhersehbare statistisch gemittelte Last bei einer großen Anzahl von Kunden.
Folgen für die Architektur
Geoklusterung
Zentralisierte oder verteilte Speicherlösung
Reservierbares Rechenzentrum
Lokale Datenspeicherung auf Rechenknoten
Ziele der Lastverteilung
Gleichmäßige Verteilung der Last
Maximale Reaktionsfähigkeit der Anwendungen
Minimale Verzögerungszeit bei der Lastverteilung
Lastverteilung nur bei ausdrücklicher Notwendigkeit
Teile der Hardware zur Wartung abziehen
Kostenreduzierung des Dienstes und der Betriebskosten
Abschaltung von Ressourcen bei geringer Last
Einsparung von Elektrizität
Reduzierung der Personalkosten
Wir ziehen folgende Schlussfolgerungen:
Für private Clouds, die großen Unternehmensauftraggebern bereitgestellt werden, kann DRS unter Berücksichtigung folgender Einschränkungen angewendet werden:
- Informationssicherheit und Berücksichtigung von Affinitätsregeln bei der Lastverteilung;
- Vorhandensein eines ausreichenden Ressourcenpools für den Fall einer Katastrophe;
- Die Daten der virtuellen Maschinen befinden sich auf einer zentralen oder verteilten SAN;
- Zeitversetzte Durchführung von Administrations-, Backup- und Balancierungsvorgängen;
- Balancierung nur innerhalb des Host-Aggregats des Kunden;
- Balancierung nur bei starkem Ungleichgewicht, die wirkungsvollsten und sichersten VM-Migrationen (da die Migration auch fehlschlagen kann);
- Balancierung in Bezug auf «ruhige» virtuelle Maschinen (die Migration «lauter» virtueller Maschinen kann sehr lange dauern);
- Balancierung unter Berücksichtigung der «Kosten» — Lasten auf SAN und Netzwerk (bei kundenspezifischen Architekturen für große Kunden);
- Balancierung unter Berücksichtigung der individuellen Verhaltensmerkmale jeder VM;
- Balancierung idealerweise in der Freizeit (Nacht, Wochenenden, Feiertage).
Für öffentliche Clouds, die Dienste für kleine Kunden anbieten, kann DRS viel häufiger eingesetzt werden, mit erweiterten Möglichkeiten:
- Keine Einschränkungen hinsichtlich der Informationssicherheit und Affinitätsregeln;
- Balancierung innerhalb der Cloud;
- Balancierung zu jeder angemessenen Zeit;
- Balancierung jeder VM;
- Balancierung «lauter» virtueller Maschinen (um andere nicht zu stören);
- Die Daten der virtuellen Maschinen befinden sich oft auf lokalen Festplatten;
- Berücksichtigung der durchschnittlichen Leistung von SAN und Netzwerk (die Architektur der Cloud ist einheitlich);
- Balancierung nach allgemeinen Regeln und bestehenden Statistiken zum Verhalten des Rechenzentrums.
Die Komplexität des Problems
Die Herausforderung der Balancierung liegt darin, dass DRS mit einer Vielzahl von unbestimmten Faktoren arbeiten muss:
- Das Verhalten der Benutzer jeder der Informationssysteme der Kunden;
- Die Algorithmen für den Betrieb der Informationssystemserver;
- Das Verhalten der DB-Server;
- Die Last auf die Rechenressourcen, SAN, Netzwerk;
- Die Interaktion der Server untereinander im Wettkampf um die Ressourcen der Cloud.
Die Last vieler virtueller Anwendungs- und Datenbankserver auf die Ressourcen der Cloud entfaltet sich über die Zeit, die Folgen können sich zeitlich überlagern und sich mit unvorhersehbaren Effekten über unvorhersehbare Zeiträume zeigen. Selbst für die Verwaltung vergleichsweise einfacher Prozesse (z.B. für die Steuerung eines Motors, eines Heizsystems im Haus) müssen automatische Regelsysteme komplexe Strukturen verwenden. Algorithmen mit Rückkopplung.
Unsere Aufgabe ist um ein Vielfaches komplexer, und es besteht das Risiko, dass das System in angemessener Zeit das Lastenausgleich nicht auf die etablierten Werte bringen kann, selbst wenn es keine externen Einflüsse vonseiten der Benutzer gibt.
Die Geschichte unserer Entwicklungen
Um dieses Problem zu lösen, beschlossen wir, nicht bei Null anzufangen, sondern uns auf bestehende Erfahrungen zu stützen und mit Fachleuten zu interagieren, die in diesem Bereich bereits Erfahrung haben. Zum Glück stimmte unser Verständnis der Problematik vollständig überein.
Etappe 1
Wir haben ein auf der Technologie neuronaler Netze basierendes System verwendet und versucht, unsere Ressourcen auf dieser Grundlage zu optimieren.
Das Interesse dieser Etappe bestand darin, eine neue Technologie auszuprobieren, und ihre Bedeutung lag in der Anwendung eines unkonventionellen Ansatzes zur Lösung der Aufgabe, wo unter sonst gleichen Bedingungen die Standardansätze praktisch erschöpft waren.
Wir haben das System gestartet, und tatsächlich begann die Balance zu funktionieren. Der Umfang unserer Cloud erlaubte es uns nicht, die optimistischen Ergebnisse zu erzielen, die die Entwickler versprochen hatten, aber es war zu erkennen, dass das Lastenausgleich funktioniert.
Dabei hatten wir ziemlich erhebliche Einschränkungen:
- Für das Training des neuronalen Netzes ist erforderlich, dass virtuelle Maschinen wochen- oder monatelang ohne wesentliche Änderungen arbeiten.
- Der Algorithmus ist auf Optimierung auf der Grundlage der Analyse früherer "historischer" Daten ausgelegt.
- Für das Training des neuronalen Netzes wird ein ausreichend großes Volumen an Daten und Rechenressourcen benötigt.
- Die Optimierung und der Lastenausgleich können relativ selten durchgeführt werden – alle paar Stunden, was offensichtlich nicht ausreichend ist.
Etappe 2
Da uns die Situation nicht zufriedenstellte, beschlossen wir, das System zu modifizieren, und um dies zu tun, mussten wir auf die Hauptfrage antworten – für wen machen wir es?
Zunächst für Unternehmenskunden. Das bedeutet, dass wir ein System benötigen, das operativ arbeitet und die unternehmerischen Einschränkungen berücksichtigt, die die Implementierung nur vereinfachen.
Die zweite Frage lautet: was verstehen wir unter dem Wort "operativ"? Nach einigen kurzen Debatten beschlossen wir, dass man von einer Reaktionszeit von 5 bis 10 Minuten ausgehen kann, damit kurzfristige Schwankungen das System nicht in Resonanz bringen.
Die dritte Frage – welche Größe der balancierten Serveranzahl sollte gewählt werden?
Diese Frage hat sich von selbst gelöst. In der Regel machen die Kunden die Serveraggregate nicht sehr groß, und das entspricht den Empfehlungen aus dem Artikel, die Aggregate auf 30-40 Server zu beschränken.
Darüber hinaus vereinfachen wir, indem wir den Pool der Server segmentieren, die Aufgabe des Lastenausgleichsalgorithmus.
Vierte Frage – wie gut passt uns ein neuronales Netzwerk mit seinem langen Lernprozess und den seltenen Balancierungen? Wir haben beschlossen, darauf zu verzichten zugunsten einfacher operativer Algorithmen, um Ergebnisse in Sekunden zu erhalten.
Eine Beschreibung des Systems, das solche Algorithmen verwendet, und seiner Nachteile kann eingesehen werden.
Wir haben dieses System implementiert und in Betrieb genommen und ermutigende Ergebnisse erzielt – es analysiert jetzt regelmäßig die Last im Cloud-Bereich und gibt Empfehlungen zur Verschiebung virtueller Maschinen, die größtenteils korrekt sind. Sogar jetzt ist zu sehen, dass wir 10-15% der Ressourcen für neue virtuelle Maschinen freisetzen können, während gleichzeitig die Qualität der bestehenden Arbeit verbessert wird.
Bei der Erkennung eines Ungleichgewichts bei RAM oder CPU gibt das System Befehle an den Tyonix-Planer zur Durchführung einer Live-Migration der erforderlichen virtuellen Maschinen. Wie aus dem Monitoringsystem ersichtlich ist, wurde die virtuelle Maschine von einem (oberen) auf einen anderen (unteren) Host verschoben und hat den Speicher auf dem oberen Host freigegeben (in gelben Kreisen hervorgehoben) und ihn entsprechend auf dem unteren Host eingenommen (in weißen Kreisen hervorgehoben).
Jetzt versuchen wir, die Effizienz des bestehenden Algorithmus genauer zu bewerten und mögliche Fehler darin zu finden.
Schritt 3
Es schien, als könnte man sich nun beruhigen, auf die bewiesene Effizienz warten und das Thema abschließen.
Aber wir werden durch die folgenden offensichtlichen Optimierungsmöglichkeiten dazu gedrängt, eine neue Phase durchzuführen.
- Statistiken zeigen zum Beispiel, und dass Systeme mit zwei oder vier Prozessoren in ihrer Leistung erheblich unter Einprozessorsystemen liegen. Das bedeutet, dass alle Benutzer von CPUs, RAM, SSD, LAN, FC, die in multiprozessorfähigen Systemen gekauft wurden, im Vergleich zu Einprozessorsystemen deutlich weniger zurückbekommen.
- Die Ressourcenplaner selbst können mit erheblichen Fehlern arbeiten, zu diesem Thema.
- Die von den Unternehmen Intel und AMD angebotenen Technologien zur Überwachung von RAM und Cache ermöglichen es, das Verhalten von virtuellen Maschinen zu analysieren und sie so zu platzieren, dass "laute" Nachbarn den "ruhigen" virtuellen Maschinen nicht im Weg stehen.
- Erweiterung der Parameter (Netzwerk, Speicher, Priorität der virtuellen Maschine, Migrationskosten, Bereitschaft zur Migration).
Insgesamt
Das Ergebnis unserer Arbeit zur Verbesserung der Lastenausgleichsalgorithmen ist die eindeutige Feststellung, dass durch moderne Algorithmen eine signifikante Optimierung der Ressourcen (25-30%) von Rechenzentren erzielt werden kann, während gleichzeitig die Servicequalität für die Kunden verbessert wird.
Der Algorithmus, der auf neuronalen Netzen basiert, ist ohne Zweifel interessant, benötigt jedoch eine Weiterentwicklung und ist aufgrund bestehender Einschränkungen nicht für derartige Aufgaben in Volumen geeignet, die für private Clouds charakteristisch sind. In öffentlichen Clouds signifikanten Umfangs hat der Algorithmus jedoch gute Ergebnisse gezeigt.
In den nächsten Artikeln werden wir ausführlicher über die Möglichkeiten von Prozessoren, Planern und hochgradigem Lastenausgleich sprechen.
Quelle: habr.com
