Wir verwenden TCP Google Cloud Loadbalancer für einen unserer Dienste.
Die Architektur ist die folgende: Es gibt einen TCP-Load Balancer, auf dem im Frontend eine Reihe von Ports zulässig sind, und seine Backend-Instanzen sind verbunden, und die Dienste dieser Instanzen laufen auf demselben Port, der im LB geöffnet ist.
Beispiel: LB IP -1.1.1.1:(100-200)Mehrere Ports sind offen. Jetzt laufen auf dem Backend drei Instanzen und ihre Dienste laufen auf den Ports 100, 101 und 103.
Wenn Sie als Benutzer auf den Dienst zugreifen möchten, der auf Port 100 läuft, müssen Sie LB IP:100 verwenden, um auf die Dienste zuzugreifen. Seit einigen Tagen wird die Anfrage jedoch abgebrochen. Wenn Sie jedoch versuchen, eine direkte Verbindung mit der Instanz IP:100 herzustellen, funktioniert der Dienst einwandfrei. Daher kann ich die genaue Ursache nicht herausfinden. Die Anfragen sind auch TCP-basiert, warum bricht LB sie dann ab?
Bitte machen Sie mir einige Vorschläge. Hinweis: Gibt es eine Möglichkeit, die LB-Protokolle von der GCloud oder Konsole aus zu überprüfen???
Antwort1
Zur besseren Sichtbarkeit poste ich die eigene Antwort des OP:
Mein Problem lag nicht an LB.
Mein LB verwendet einen Round-Robin-Algorithmus und hat die Anfrage einfach weitergeleitet, ohne den Status des Back-End-Servers zu überprüfen. Nur einer meiner Server lief, daher wurde die Hälfte der Anfragen verworfen.
Ich habe gerade eine weitere Instanz unter demselben LB konfiguriert und das Problem wurde behoben.
Diese Art von Lösung ist die „primitivste“ und bietet keinerlei Ausfallsicherheit. Wenn ein Server ausfällt, werden einige Anfragen gelöscht und der Dienst wird herabgestuft.
Die einfachste Lösung, dies zu vermeiden, wäre die Erstellung einesverwaltete Instanzgruppeund VerwendungGesundheitschecksum zu überprüfen, ob alle VMs laufen und dann erstellen Sie eineLastenausgleicher.