Original Ohhahali 360 Cloud Computing 2020-07-08
Heldin Erklärung
Der Text behandelt den Fehlerbehebungsprozess und die Lösungen des Problems des langsamen Zugriffs auf die Octavia-API-Schnittstelle sowie die relevanten Wissenspunkte, die am Fehlerbehebungsprozess beteiligt sind. Ich hoffe, dass Sie in Zukunft aus ähnlichen Problemen lernen und auf diese verweisen können.
PS: Reichhaltige First-Line-Technologie, eine breite Palette von Formen, alles in " 3 60 Cloud Computing " Anlass zur Sorge Oh!
Überlegungen zur Untersuchung des langsamen Problems der Octavia-API-Schnittstelle
1
Problemhintergrund
Octavia ist eine hochverfügbare Lastausgleichslösung für Openstack-Cluster. Sie bietet externe REST-APIs zum Erstellen von VIPs für den Geschäftszugriff. Das Backend verwendet Haproxy + LVS, um Lastausgleichsdienste bereitzustellen, und verteilt Geschäftsanforderungen automatisch an reale Server.
Bei unserer tatsächlichen Verwendung variiert die Antwortzeit für den Zugriff auf die von Octavia bereitgestellte REST-API-Schnittstelle stark zwischen 0,2 und 50 Sekunden, sodass VIPs nicht normal erstellt und abgefragt werden können.
Octavia-Servicearchitektur
Die obige Abbildung zeigt den Bereitstellungsmodus, der von unserem Octavia-Dienst verwendet wird. Eine hohe Verfügbarkeit wird durch Keepalived vrrp erreicht, und mehrere Octavia-API-Dienstknoten werden im Backend von Haproxy bereitgestellt.
2
Fehlerbehebungsprozess
Erfassung
Der Zugriff auf die API-Schnittstelle ist langsam. Zunächst müssen Sie wissen, in welchem Schritt die Anforderungszeit verbracht wird. Erfassen Sie die Zugriffsanforderung der Schnittstelle und beobachten Sie die Übertragung des Datenpakets während der Anforderung. Aufgrund der großen Anzahl von Schnittstellenanforderungen werden die Anforderungen durch Hinzufügen benutzerdefinierter Headerinformationen unterschieden, und der http-Header wird zum Filtern der Paketerfassungsergebnisse verwendet. Es wird festgestellt, dass die zeitaufwändige Anforderung lang ist und es ein Phänomen der erneuten Übertragung von Datenpaketen gibt.
Analyse
1) Zeitverbrauch
Aus der Perspektive der Paketerfassung erhält der Zugriff des Clients auf Haproxy schnell eine Antwort, und der Zeitaufwand liegt ausschließlich in der Interaktion zwischen Haproxy und Octavia-API, wodurch das Problem der Haproxy beseitigt wird.
2) Physische Hardware / Maschinenlast / Netzwerkjitter
Stellen Sie sicher, dass auf der Servernetzwerkkarte kein Paketverlust oder -fehler vorliegt. Haproxy und Octavia-API gehören zum selben Netzwerksegment, und es gibt keinen Netzwerkjitter, der einen Paketverlust verursacht. Überprüfen Sie, ob die Last der drei Octavia-API-Computer gleich ist nicht hoch und die Anzahl der Verbindungen ist nicht abnormal.
3) Anwendungsebene
Aus Sicht der Paketerfassung reagiert octavia-api nicht auf syn oder ack. Überprüfen Sie den Verbindungsstatus von Port 9876.
netstat -s |grep -i listen #发现两个数值都在增长1173805 times the listen queue of a socket overflowed1175909 SYNs to LISTEN sockets dropped
Die beiden erhöhten Werte beziehen sich auf die beiden Warteschlangen auf der Serverseite während des Verbindungsaufbaus:
Halbverbindungswarteschlange (Syn-Warteschlange): Wird zum Speichern von Anforderungen in den Zuständen SYN_SENT und SYN_RECV verwendet.
Warteschlangengröße: max_qlen = 2 ^ max_qlen_log (linux-3.10.0)
Vollständig verbundene Warteschlange (Warteschlange akzeptieren): Wird zum Speichern der Anforderung verwendet, die sich im festgelegten Status befindet, aber die Anwendungsschicht ruft nicht accept auf, um sie zu entfernen.
Warteschlangengröße: min (Rückstand, net.core.somaxconn)
Wenn der Server das vom Client während des Verbindungsaufbaus gesendete Syn- oder Bestätigungspaket empfängt, muss er beurteilen, ob die Akzeptanzwarteschlange überläuft, und ein Überlauf führt dazu, dass die beiden oben genannten Werte zunehmen.
Der Schnittstellendruck der Bereitstellungsumgebung ist nicht hoch. Warum läuft die Akzeptanzwarteschlange über? Verwenden Sie den Befehl ss, um die Größe der Akzeptanzwarteschlange anzuzeigen, die dem aktuellen Server entspricht.
ss -ntlp|grep 9876LISTEN 6 5 10.145.69.9:9876 *:* users:(("octavia-api",pid=10209,fd=4))
6 und 5 stellen Recv-Q bzw. Send-Q dar. Recv-Q stellt den Socket dar, den die Akzeptanzwarteschlange darauf wartet, dass der Benutzer akzeptiere, um den 3-Wege-Handshake abzuschließen, und Senden-Q repräsentiert die tatsächliche Größe des Akzeptierens Warteschlange. Aus dem Wert ist ersichtlich, dass die Akzeptanzwarteschlange auf der Serverseite überläuft.
Wie geht der Server nach dem Überlaufen der Warteschlange mit der zu diesem Zeitpunkt empfangenen Synchronisierung oder Bestätigung um? Bestimmt durch die folgenden Kernelparameter:
/ proc / sys / net / ipv4 / tcp_abort_on_overflow
0 bedeutet, dass die Bestätigung direkt verworfen wird und der Client erneut sendet. Die Anzahl der erneuten Übertragungen wird durch den Kernelparameter tcp_synack_retries bestimmt. 1 bedeutet, dass zuerst rst gesendet wird, um die Verbindung zu trennen.
Nachdem der Wert in der Testumgebung auf 1 geändert wurde, wurde die Anforderung sofort getrennt, was beweist, dass die Warteschlange des Neuübertragungsservers übergelaufen ist.
3
Lösung
Nachdem festgestellt wurde, dass die Serververbindungswarteschlange überläuft und die erneute Übertragung verursacht, muss die Größe der Akzeptanzwarteschlange geändert werden, um das Problem zu lösen.
In Teil 2 sehen wir, dass die Länge der Akzeptanzwarteschlange gleich 5 ist und der Standardwert für somaxconn 128 ist. Dies bedeutet, dass der beim Erstellen des Octavia-API-Server-Listen übergebene Backlog-Wert 5 beträgt. Der Wert ist zu klein, wodurch die Akzeptanzwarteschlange leicht überläuft.
Woher kommt also der Rückstandswert von Octavia? Wir müssen uns die spezifische Implementierung des Codes ansehen, um die Antwort zu finden.
Die Startlogik von octavia-api verwendet die Methode make_server in simple_server.py der Bibliothek wsgiref, um einen WSGI-Server zu erstellen. Die spezifische Logik lautet wie folgt:
simple_server.make_server (Host, Port, App) -> WSGIServer () -> server_bind -> BaseHTTPServer.HTTPServer.server_bind -> SocketServer.TCPServer.server_bind
In der Abbildung sehen Sie, dass die von der Listen-Funktion der server_activate-Methode in der SocketServer.TCPServer-Klasse übergebene self.request_queue_size einen festen Wert von 5 hat, der die Quelle des Octavia-API-Backlog-Werts ist. Um den Wert zu ändern, müssen Sie daher die Größe des Werts request_queue_size ändern.
4
Frage Follow-up
Überprüfen Sie nach dem Überprüfen und Bestätigen und Ändern des Werts von request_queue_size, ob der Backlog-Wert von octavia-api 128 beträgt. Beim Besuch von octavia-api wurde festgestellt, dass keine erneute Übertragung von Datenpaketen und kein Überlauf der Akzeptanzwarteschlange erfolgt, die Zugriffsgeschwindigkeit jedoch noch nicht wesentlich verbessert wurde.
Erfassen Sie das Paket erneut und stellen Sie fest, dass die Verbindung normal ist, das Octavia-API-Antwortpaket jedoch langsam ist, was durch die Anforderungsverarbeitung auf Anwendungsebene verursacht werden sollte. octavia-api hat nur eine einzige Prozessverarbeitungsanforderung und kann nicht auf viele Schnittstellenaufrufe antworten.
Ändern Sie in Kombination mit den Verarbeitungsmethoden anderer Openstack-Projekte die Erstellungsmethode des Octavia-API-WSGI-Servers. Verwenden Sie nicht mehr die wsgiref-Bibliothek, verwenden Sie die openstack-Bibliothek oslo_service, um den WSGI-Server zu erstellen, erhöhen Sie den Parameter für die Anzahl der Prozesse, um die Anzahl der Octavia-API-Prozesse festzulegen (der Standardwert entspricht der Anzahl der CPU-Prozesse) und den WSGI Der Standard-Backlog-Wert des Servers von oslo_service ist 128. Nach dieser Änderung wurde die Antwortgeschwindigkeit der Schnittstelle auf 1 s verbessert.
Darüber hinaus können Sie auch http_s mod_wsgi und Octavia zur Bereitstellung verwenden, um die Verarbeitungsfunktionen zu verbessern. Schließlich ist wsgiref eine offizielle einfache integrierte Python-Bibliothek, die den WSGI-Standard zu Demonstrationszwecken implementiert. Es wird nicht empfohlen, sie online bereitzustellen.