In мы рассказали о попытках использовать Watcher и представили отчет испытаний. Такие испытания мы периодически проводим для балансировки и других критических функций большого корпоративного или операторского облака.
Высокая сложность решаемой задачи, возможно, потребует нескольких статей для описания нашего проекта. Сегодня мы публикуем вторую статью цикла, посвященную балансировке виртуальных машин в облаке.
Немного терминологии
Компания VmWare ввела утилиту DRS (Distributed Resource Scheduler) для балансировки нагрузки разработанной и предлагаемой ими среды виртуализации.
Как пишет
«VMware DRS (Планировщик распределенных ресурсов) — это утилита, которая балансирует вычислительные нагрузки с доступными ресурсами в виртуальной среде. Утилита является частью пакета виртуализации под названием VMware Infrastructure.
Mit VMware DRS legen die Benutzer Regeln für die Verteilung physischer Ressourcen zwischen virtuellen Maschinen (VM) fest. Das Tool kann entweder manuell oder automatisch konfiguriert werden. VMware-Ressourcengruppen können problemlos hinzugefügt, entfernt oder reorganisiert werden. Auf Wunsch können die Ressourcengruppen zwischen verschiedenen Geschäftseinheiten isoliert werden. Wenn die Arbeitslast einer oder mehrerer virtueller Maschinen erheblich variiert, verteilt VMware DRS die virtuellen Maschinen zwischen den physischen Servern neu. Sinkt die gesamte Arbeitslast, können einige physische Server vorübergehend abgeschaltet werden, während die Arbeitslast konsolidiert wird.
Warum ist Lastverteilung nötig?
Unserer Meinung nach ist DRS eine unverzichtbare Funktion der Cloud, auch wenn das nicht bedeutet, dass DRS immer und überall eingesetzt werden muss. Je nach Zweck und Anforderungen der Cloud können unterschiedliche Bedürfnisse an DRS und an die Methoden der Lastverteilung bestehen. Es gibt möglicherweise Situationen, in denen Lastverteilung überhaupt nicht nötig oder sogar schädlich ist.
Um besser zu verstehen, wo und für welche Kunden DRS benötigt wird, betrachten wir deren Ziele und Anforderungen. Clouds lassen sich in öffentliche und private unterteilen. Hier sind die Hauptunterschiede zwischen diesen Cloud-Arten und den Zielen der Kunden.
Private Clouds / Große Unternehmensklienten
Öffentliche Clouds / Kleine und mittlere Unternehmen, Einzelpersonen
Hauptkriterium und Ziele des Anbieters
Bereitstellung eines zuverlässigen Services oder Produkts
Senken der Kosten für Dienstleistungen im Wettbewerb auf dem Markt
Anforderungen an den Service
Zuverlässigkeit auf allen Ebenen und in allen Systemelementen
Garantierte Leistung
Priorisierung der virtuellen Maschinen in mehrere Kategorien
Informations- und physische Datensicherheit
SLA und 24/7 Support
Maximale Einfachheit beim Erhalt des Services
Relativ einfache Dienstleistungen
Die Verantwortung für die Daten liegt beim Kunden
Eine Priorisierung der VMs ist nicht erforderlich
Informationssicherheit auf dem Niveau typischer Services, die Verantwortung liegt beim Kunden
Es kann zu Ausfällen kommen
Kein SLA, die Qualität ist nicht garantiert
Support per E-Mail
Backups sind nicht zwingend erforderlich
Besonderheiten des Kunden
Sehr breites Anwendungsspektrum.
Legacy-Anwendungen, die im Unternehmen geerbt wurden.
Komplexe, maßgeschneiderte Architekturen für jeden Kunden.
Affinity-Regeln.
Softwarebetrieb rund um die Uhr im 7x24-Modus.
Backup-Lösungen „on the fly“.
Vorhersehbare zyklische Kundenlast.
Standardanwendungen – Netzwerkbalance, Apache, WEB, VPN, SQL
Eine temporäre Anwendungsunterbrechung ist möglich.
Freie Verteilung von VMs in der Cloud erlaubt.
Backup durch den Kunden.
Vorhersehbare statistisch gemittelte Last bei vielen Kunden.
Folgen für die Architektur.
Geo-Clusterbildung.
Zentralisierte oder verteilte Speicherlösungen.
Reservierbare SAN.
Lokale Datenspeicherung auf Rechenknoten.
Ziele der Lastenverteilung.
Gleichmäßige Lastverteilung.
Maximale Reaktionsfähigkeit der Anwendungen.
Minimale Verzögerungszeit bei der Lastenverteilung.
Lastenverteilung nur im Falle eines klaren Bedarfs.
Teilweise Geräte zur Wartung abziehen.
Senkung der Kosten für den Dienst und Betriebskosten.
Abschaltung von Ressourcen bei geringer Last.
Energieeinsparung.
Reduzierung der Personalkosten
Wir ziehen folgende Schlussfolgerungen:
Für private Clouds, die großen Unternehmenskunden bereitgestellt werden, kann DRS unter Berücksichtigung folgender Einschränkungen angewendet werden:
- Informationssicherheit und Berücksichtigung von Affinitätsregeln bei der Lastverteilung;
- verfügbare Backup-Ressourcen im Falle eines Ausfalls;
- Daten virtueller Maschinen befinden sich auf einer zentralisierten oder verteilten SAN;
- zeitliche Trennung von Verwaltungs-, Backup- und Lastverteilungsprozessen;
- Lastverteilung nur innerhalb des Hostaggregats des Kunden;
- Lastverteilung nur bei erheblichem Ungleichgewicht, effektivste und sicherste Migrationen von VMs (denn Migration kann scheitern);
- Lastverteilung in Bezug auf 'ruhige' virtuelle Maschinen (die Migration 'aktiver' virtueller Maschinen kann sehr lange dauern);
- Lastverteilung unter Berücksichtigung der 'Kosten' — der Last auf SAN und Netzwerk (bei maßgeschneiderten Architekturen für große Kunden);
- Lastverteilung unter Berücksichtigung der individuellen Verhaltensmerkmale jeder VM;
- Lastverteilung vorzugsweise außerhalb der Arbeitszeiten (Nacht, Wochenende, Feiertage).
Für öffentliche Clouds, die Dienstleistungen für kleine Kunden anbieten, kann DRS viel häufiger angewandt werden, mit erweiterten Möglichkeiten:
- keine Einschränkungen der Informationssicherheit und Affinitätsregeln;
- Lastverteilung innerhalb der Cloud;
- Lastverteilung zu jeder angemessenen Zeit;
- Lastverteilung beliebiger VMs;
- Lastverteilung von "lauten" virtuellen Maschinen (um andere nicht zu stören);
- Daten von virtuellen Maschinen befinden sich häufig auf lokalen Festplatten;
- Berücksichtigung der mittleren Leistung von SANs und Netzwerken (Architektur der Cloud ist einheitlich);
- Lastverteilung nach verallgemeinerten Regeln und vorhandener Statistik des Verhaltens von Rechenzentren.
Komplexität des Problems
Die Schwierigkeit der Lastverteilung liegt darin, dass DRS mit einer Vielzahl von unbestimmten Faktoren arbeiten muss:
- das Verhalten der Benutzer jeder der Informationssysteme der Kunden;
- Algorithmen, die den Betrieb von Informationssystemservern steuern;
- Verhalten der Datenbankserver;
- Belastung der Rechenressourcen, SANs, Netzwerke;
- Interaktionen zwischen den Servern im Kampf um Cloud-Ressourcen.
Die Last eines großen Volumens an virtuellen Anwendungs- und Datenbankservern auf die Cloud-Ressourcen entsteht über einen bestimmten Zeitraum. Die Auswirkungen können sich überlagern und zu unvorhersehbaren Effekten führen, die in unvorhersehbaren Zeiträumen auftreten. Selbst zur Steuerung relativ einfacher Prozesse (wie die Regelung eines Motors oder eines Heizsystems im Haus) müssen automatische Regelungssysteme anspruchsvolle Feedback-Algorithmen einsetzen.
Unsere Aufgabe ist um ein Vielfaches komplexer, und es besteht das Risiko, dass das System nicht in der Lage ist, innerhalb eines angemessenen Zeitrahmens eine Lastenbalance auf etablierte Werte zu erzielen, selbst wenn keine externen Einflüsse von den Nutzern auftreten.
Die Geschichte unserer Entwicklungen
Um dieses Problem zu lösen, haben wir uns entschieden, nicht bei null anzufangen, sondern auf der bestehenden Erfahrung aufzubauen und mit Fachleuten, die in diesem Bereich Erfahrung haben, zusammenzuarbeiten. Glücklicherweise stimmte unser Verständnis der Problematik vollständig überein.
Phase 1
Wir haben ein System auf Basis von neuronalen Netzwerken verwendet und versucht, unsere Ressourcen darauf zu optimieren.
Das Ziel dieser Phase bestand darin, eine neue Technologie zu testen, während ihre Bedeutung darin lag, einen unkonventionellen Ansatz zur Lösung des Problems anzuwenden, bei dem die Standardansätze unter gleichen Bedingungen nahezu erschöpft waren.
Wir haben das System in Betrieb genommen und die Lastverteilung begann tatsächlich zu funktionieren. Der Umfang unserer Cloud ließ uns nicht die optimistischen Ergebnisse erzielen, die die Entwickler versprochen hatten, aber es war klar, dass die Lastverteilung funktionierte.
Dabei hatten wir deutlich ernsthafte Einschränkungen:
- Für das Training des neuronalen Netzwerks ist es notwendig, dass die virtuellen Maschinen über Wochen oder Monate hinweg ohne wesentliche Änderungen betrieben werden.
- Der Algorithmus ist darauf ausgelegt, auf der Grundlage der Analyse früherer "historischer" Daten zu optimieren.
- Für das Training des neuronalen Netzwerks wird eine ausreichende Menge an Daten und Rechenressourcen benötigt.
- Die Optimierung und Lastverteilung können relativ selten durchgeführt werden – alle paar Stunden, was eindeutig nicht ausreicht.
Phase 2
Da wir mit der aktuellen Situation unzufrieden waren, entschieden wir uns, das System zu modifizieren und darauf basierend zu antworten auf die zentrale Frage – für wen entwickeln wir es?
Zunächst einmal – für Unternehmenskunden. Das bedeutet, dass wir ein System benötigen, das effizient arbeitet, mit den korporativen Einschränkungen, die die Umsetzung lediglich erleichtern.
Die zweite Frage – was bedeutet ‚effizient‘? Nach kurzer Diskussion entschieden wir, dass wir eine Reaktionszeit von 5 bis 10 Minuten als Maßstab nehmen können, um sicherzustellen, dass kurzfristige Schwankungen das System nicht durcheinanderbringen.
Die dritte Frage – wie viele Server sollten wir im Lastenausgleich anvisieren?
Diese Frage beantwortete sich von selbst. Gewöhnlich machen die Kunden ihre Serveraggregate nicht zu groß, und das entspricht den Empfehlungen, die Anzahl der Server auf 30–40 zu begrenzen.
Darüber hinaus erleichtern wir durch die Segmentierung des Serverpools den Balancing-Algorithmus.
Die vierte Frage – inwieweit ist ein neuronales Netzwerk mit seinem langen Lernprozess und den seltenen Anpassungen für uns geeignet? Wir beschlossen, darauf zu verzichten zugunsten einfacherer, effizienter Algorithmen, um Ergebnisse innerhalb von Sekunden zu erzielen.
Informationen über das System, das solche Algorithmen verwendet, und dessen Nachteile sind verfügbar.
Wir haben dieses System implementiert und gestartet und vielversprechende Ergebnisse erzielt – es analysiert nun regelmäßig die Cloud-Last und gibt Empfehlungen zur Verschiebung virtueller Maschinen, die in hohem Maße korrekt sind. Schon jetzt ist zu erkennen, dass wir 10-15 % der Ressourcen für neue virtuelle Maschinen freigeben können, während wir die Qualität der bestehenden Dienste verbessern.
Bei einem Ungleichgewicht von RAM oder CPU gibt das System Befehle an den Tionix-Planer, um die erforderlichen virtuellen Maschinen mit einer Live-Migration zu verschieben. Wie man im Monitoringsystem sieht, wurde die virtuelle Maschine von einem (oberen) auf einen anderen (unteren) Host verschoben und hat Speicherplatz auf dem oberen Host freigegeben (in gelben Kreisen hervorgehoben), während sie ihn entsprechend auf dem unteren Host belegt hat (in weißen Kreisen hervorgehoben).
Derzeit versuchen wir, die Effizienz des aktuellen Algorithmus genauer zu bewerten und suchen nach möglichen Fehlern.
Phase 3
Es scheint, als könnten wir uns beruhigen, auf die nachgewiesene Effektivität warten und das Thema abschließen.
Jedoch werden wir durch folgende klare Optimierungsmöglichkeiten zu einer neuen Phase gedrängt.
- Statistiken zeigen beispielsweise, und dass Systeme mit zwei oder vier Prozessoren hinsichtlich der Leistung erheblich hinter einstufigen Prozessoren zurückbleiben. Das bedeutet, dass alle Benutzer vonkäuflich in multiprozessorischen Systemen CPU, RAM, SSD, LAN, FC erheblich weniger Nutzen haben, im Vergleich zu einstufigen Prozessoren.
- Die Ressourcenplaner selbst können mit ernsthaften Fehlern arbeiten, zu diesem Thema informieren.
- Die von Intel und AMD angebotenen Technologien zur Überwachung von RAM und Cache ermöglichen es, das Verhalten virtueller Maschinen zu untersuchen und sie so zu platzieren, dass "laute" Nachbarn den "ruhigen" virtuellen Maschinen nicht im Weg stehen.
- Erweiterung des Parametersatzes (Netzwerk, SAN, Priorität der virtuellen Maschine, Migrationskosten, ihre Bereitschaft zur Migration).
Gesamt
Das Ergebnis unserer Arbeit zur Verbesserung der Lastenausgleichsalgorithmen war eine klare Erkenntnis: Mit modernen Algorithmen kann eine erhebliche Optimierung der Ressourcen (25-30%) in Rechenzentren erreicht werden, wodurch gleichzeitig die Servicequalität für die Kunden erhöht wird.
Ein auf neuronalen Netzwerken basierender Algorithmus ist zweifellos interessant, benötigt jedoch weitere Entwicklungen und ist aufgrund bestehender Einschränkungen nicht für Aufgaben dieser Art in der Größenordnung privater Clouds geeignet. In größeren öffentlichen Clouds hat der Algorithmus jedoch gute Ergebnisse gezeigt.
Weitere Informationen zu den Möglichkeiten von Prozessoren, Planern und hochentwickelter Lastenverteilung erhalten Sie in den folgenden Artikeln.
Quelle: habr.com
