%3F%20.png)
Ich habe eine Umgebung mit Lastenausgleich in Google Cloud Platform konfiguriert. Hinter dem Lastenausgleich stehen zwei Server, die nahezu identisch konfiguriert sind. Ein Server befindet sich in der Region Ost der USA und einer in der Region Zentral der USA. Der Server in der Region Ost der USA bewältigt die gesamte Last problemlos allein und hat eine durchschnittliche CPU-Auslastung von etwa 45 %. Immer wenn ich den Server in der Region Zentral zum Lastenausgleich hinzufüge, steigt seine CPU-Auslastung plötzlich an und bleibt bei etwa 99 % Auslastung, solange er mit dem Lastenausgleich verbunden ist.
Weiterer Hintergrund: Die Server sind Windows-Server, auf denen eine ASP.NET Umbraco 7-Website läuft. Ich habe auch zwei Datenbankserver, auf denen MariaDB läuft, einen als Master und einen als Replikations-Slave. Der östliche Server verbindet sich mit dem Master (ebenfalls in der östlichen Region). Der zentrale Server verbindet sich mit dem Slave (ebenfalls in der zentralen Region).
Kann jemand eine Erklärung dafür anbieten, warum der zentrale Server Probleme hat?
Dinge, die ich versucht habe:
- Ich habe die Ausgleichsparameter optimiert, um zu versuchen, mehr Anfragen an den östlichen Server zu leiten, da ich dachte, dass dies die Belastung des zentralen Servers etwas verringern könnte.
- Ich habe versucht, den zentralen Server mit der Masterdatenbank in der östlichen Region zu verbinden.
- Ich habe eine neue Kopie der Site-Dateien hochgeladen, für den Fall, dass irgendwo eine Beschädigung ein Problem verursacht hat.
- Ich bin dem (automatisierten) Rat von Google gefolgt und habe den RAM erhöht (der von Anfang an nicht wirklich beansprucht wurde; die Auslastung lag nie über 50 %).
- Ich habe versucht, einen völlig neuen Server zu starten, ebenfalls in der zentralen Region, und ihn von Grund auf neu zu konfigurieren. Dieselben Leistungsprobleme.
Das Beste, was ich mir im Moment vorstellen kann, ist, dass der Server Probleme hat, mit den Health Checker-Pings Schritt zu halten, aber warum hat der andere Server dann keine Probleme? Liegt das Problem daran, dass Sie sich in einer anderen Region befinden?
Dinge, die ich noch ausprobieren muss. Schlagen Sie gerne eine Priorität hierfür vor:
- Verschieben des zentralen Servers in eine andere Region.
- Verschieben des zentralen Servers zusammen mit den anderen Servern in die östliche Region.
- Hinzufügen einer CPU
Letzteres versuche ich zu vermeiden, da es mir eher so vorkommt, als würde ich die Symptome behandeln, als das zugrunde liegende Problem zu finden.
Antwort1
Zunächst versuchen Google L7 Load Balancer, den Datenverkehr an das Backend zu leiten, das dem Anforderer am nächsten liegt. In Ihrem Fall wird jede Anfrage von der Ostküste an das Backend us-east weitergeleitet, während alle anderen Anfragen aus Nordamerika an us-central weitergeleitet werden. Dies ist das erwartete Verhalten.
Sie können die L7LB-Verkehrsverteilung überprüfen, indem Sie zur Verwaltungskonsole > Netzwerkdienste > Lastenausgleich gehen und auf „Erweitertes Menü“ klicken. Gehen Sie von hier aus zu „Backend-Dienste“ und klicken Sie auf Ihr LB-Backend. Sie können jetzt die RPS pro Instanz im Backend anzeigen. Wenn Sie zwei separate Backends verwenden, können Sie jedes einzeln überprüfen.
Wenn der us-central-Server ein deutlich höheres Volumen hat, ist auch die CPU-Auslastung höher.
Was die Integritätsprüfungen betrifft, haben Sie die volle Kontrolle über die Häufigkeit der Prüfungen (idealerweise sollte sie mit der des US-East-Servers übereinstimmen). Sie können Ihre Integritätsprüfungen unter Compute Engine > Integritätsprüfungen oder auf dem Bildschirm mit den Load Balancer-Details überprüfen.
Sie können die CPU-Leistung jederzeit erhöhen, ohne den Speicher zu erhöhen, da dies derzeit Ihr Problem ist. Dies behebt jedoch nur das Symptom, nicht das Problem.
Oben wird erläutert, worauf Sie auf der Google Cloud Platform achten müssen. Wenn der Datenverkehr beider Instanzen ungefähr gleich ist, beginnen Sie mit der Überwachung der Leistung Ihres Servers, um zu prüfen, was die CPU-Auslastung maximiert, um sicherzustellen, dass es tatsächlich IIS und nicht eine andere Anwendung ist.