Load Balancer als virtuelle Maschine oder Bare Metal verwenden

Load Balancer als virtuelle Maschine oder Bare Metal verwenden

Wir verwenden eine Anwendung mit etwa 300 gleichzeitigen Benutzern. Jetzt ist alles virtualisiert: 1 VM als Lastenausgleich, 2 VMs als Webserver (auf diesem ESXi-Host gibt es zusätzlich +25 weitere VMs) und 1 Server (Bare Metal) als SQL Server. Wir haben einige Probleme mit der Leistung und haben beschlossen, physische Hardware zu kaufen, um sie zu steigern.

Ich bin nicht sicher, wie wir die Leistung verbessern können?:

  • Wir kaufen 1 Rack-Server-Hardware und führen ESXi mit nur allen 3 VMs oben aus.

  • wir kaufen 1-1 Rack-Server-Hardware für die Webserver und installieren den Windows-Server nur mit der Anwendung. (und lassen den Load Balancer wie zuvor – VM)

  • wir kaufen 3 Rack-Server für den Load Balancer und für die 2 Webserver.

Benutzer werden über die Weboberfläche/Desktop-App mit dem Server verbunden.

Vielen Dank für deine Hilfe, drewo

Antwort1

Bevor Sie sich für einen weiteren Weg entscheiden, sollten Sie Antworten auf einige Informationen finden:

CPU-Auslastung für die betroffenen VMs

  • Liegt die CPU-Auslastung aus Sicht des Gastbetriebssystems häufig über 80 % und/oder zeigt sie eher Plateaus als Spitzen in der Auslastung? Wahrscheinlich ist Ihre VM nicht mit ausreichend CPU ausgestattet. Fügen Sie weitere vCPUs hinzu (denken Sie jedoch an mögliche Lizenzierungsprobleme).
  • Sind einige vCPUs in Ihren Servern deutlich weniger ausgelastet als andere? Ihre Anwendung könnte ein Skalierungsproblem haben. Das einfache Platzieren von mehr vCPUs in einer einzelnen VM (oder einer physischen Maschine) wird die Situation nicht verbessern.
  • Zeigen die CPU readyZeiten an, dass der Host überlastet ist? Eine Faustregel, die man manchmal anwendet, ist, dass die durchschnittliche Bereitschaftszeit weniger als 5 % betragen sollte, aber meiner Erfahrung nach ist selbst das viel zu viel für ein System, mit dem Sie tatsächlich arbeiten. Beachten Sie, dass bei Verwendung von vCenter die angegebene Bereitschaftszeit in aggregierten Millisekunden seit der letzten Diagrammaktualisierung angegeben wird. In der „Echtzeit“-Ansicht wird das Diagramm alle 20 Sekunden (= 20.000 ms) aktualisiert, sodass der durchschnittliche Prozentsatz pro CPU für eine VM mithilfe der Formel berechnet werden kann (indicated_ready_time * 100 / 20000) / number_of_vcpu.

RAM-Nutzung

(Sollte immer innerhalb des Gastbetriebssystems überprüft werden)

  • Normalerweise über 80 %? Speicher hinzufügen.
  • Anzeichen für Speicherlecks? Reparieren Sie die Anwendung oder seien Sie darauf vorbereitet, häufiger neu zu starten.
  • Anzeichen für übermäßiges Swapping? Prüfen Sie, ob Konfigurationsprobleme vorliegen. Fügen Sie Speicher hinzu.
  • Verwenden Sie wichtige Anwendungen/Prozesse „unerklärlicherweise“ weniger als 4 GB Arbeitsspeicher? Diese müssen möglicherweise neu erstellt oder konfiguriert werden, um die 64-Bit-Adressierung nutzen zu können.

Überprüfen Sie auch die Festplatten- und Netzwerkleistung auf Latenzprobleme.

Abhängig von der Skalierung Ihrer Anwendung kann es sinnvoll sein, weitere Webserver hinzuzufügen, anstatt die Rechenleistung oder den Speicher der vorhandenen Server zu erweitern.

Sobald Sie eine Vorstellung davon haben, wo Ihre Engpässe liegen und wie Sie Ihre Hardware am besten einsetzen, können Sie mit der Ausarbeitung einer betriebswirtschaftlichen Begründung für Ihre Anschaffung beginnen.

Der Hauptvorteil virtueller Maschinen liegt darin, dass sie einfacher zu verwalten, zu sichern und im Falle eines Systemausfalls leichter zu migrieren sind. Sie ermöglichen eine bessere Auslastung Ihrer Hardware, vorausgesetzt, dass sie nicht alle Ressourcen benötigen, die Sie ihnen zuweisen können, und wenn Sie paravirtualisierte Netzwerkschnittstellen verwenden, ist die Kommunikation zwischen Maschinen auf demselben Host so schnell, wie die CPU es zulässt, und nicht auf die Geschwindigkeit physischer Netzwerkschnittstellen beschränkt.

Ein System, das direkt auf einer physischen Maschine läuft, hat aufgrund der gemeinsamen Nutzung von Ressourcen natürlich keinen Overhead. Dies ist jedoch nur dann von Vorteil, wenn Sie die verfügbare Leistung nutzen können.

Antwort2

Ohne die Ursache Ihrer Leistungsprobleme zu untersuchen und Ihre Anwendung zu kennen, können Sie nicht sagen, was die einfachste/beste Abhilfe wäre.

Falls Ihr Problem tatsächlich ein Mangel an Hardwareressourcen ist, sollte die Überwachung ziemlich deutlich machen, wo Sie jetzt an Grenzen stoßen und was Sie kaufen müssen (CPU-Kerne oder CPU-Geschwindigkeit, mehr RAM-Speicher, schnellere Festplatten) und wo Sie das zuweisen.

Meiner Erfahrung nach ließen sich mehr als die Hälfte der Leistungsprobleme mehr oder weniger leicht durch entsprechendes Tuning lösen, anstatt das Problem mit zusätzlichen Hardwareressourcen zu lösen. Die meisten Entwickler und zu viele Anbieter haben nicht die Möglichkeit oder die Ressourcen, ihre Anwendungen und Datenbank-Backends mit der gleichen Datenmenge und einer ähnlichen Belastung wie in der Produktion zu testen, und sie treffen Annahmen und Designentscheidungen, die in der Praxis nicht allzu gut skalierbar sind.

Durch sorgfältige Überwachung erhalten Sie einen Einblick in Ihre Engpässe und erfahren, was Sie möglicherweise auf Anwendungs-, Datenbank- oder Hardwareebene beheben müssen.

Bitte beachten Sie, dass Leistungsanalyse und -optimierung sowohl eine Wissenschaft als auch eine schwarze Kunst sind.

Sehr häufige Anwendungsprobleme, die leicht behoben werden können und oft erhebliche Vorteile bieten, sind

  • fehlende Indizes in einer Datenbank
  • Verbindungspooling und Abfrage-Caching
  • Feinabstimmung der Speichergrenzen, der Anzahl der Verbindungen, Sockets und gleichzeitigen Threads von Anwendungen

Schwieriger zu behebende Fehler im Anwendungsdesign liegen vor, wenn das Frontend der Anwendung zu viel Datenverarbeitungslogik enthält und Datenbankabfragen zu einfach oder ungebunden sind und zu viele Daten zurückgeben (wie etwa bei einem SELECT * from GrowingDataSet). Bei Ihrer Überwachung können die Symptome hierfür so unterschiedlich sein wie eine hohe Festplatten-E/A-Auslastung auf dem Datenbankserver, ein hoher Speicherverbrauch auf dem Anwendungsserver und gesättigte Netzwerkverbindungen. Jeder dieser Punkte kann zur Unterstützung einer anderen Kaufentscheidung für Hardware verwendet werden (Upgrade auf SSDs im Datenbankserver, Erhöhung des RAM im Anwendungsserver, Upgrade des Netzwerks). Wahrscheinlich wird keines davon benötigt, wenn die Anwendung beginnt, eine bessere Logik und Paginierung in den Abfragen anzuwenden.

verwandte Informationen