Technologieaustausch

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

LVS-DR (Linux Virtual Server – Direct Routing) ist ein Arbeitsmodus des virtuellen Linux-Servers und wird häufig zur Implementierung von Lastausgleichsclustern verwendet.
So funktioniert LVS-DR:
Der Director-Server (Load Balancer) dient als Zugangseingang zum Cluster, jedoch nicht als Gateway. Um auf den Zugriff auf den gesamten Cluster reagieren zu können, müssen sowohl der Director-Server als auch der reale Server (realer Server) mit einer VIP (virtuellen IP-Adresse) konfiguriert sein und sich im selben Netzwerk befinden Der Client muss nicht über den Director-Server gehen. Der Client sendet eine Anfrage an die Ziel-VIP. Nachdem der Load Balancer diese empfangen hat, wählt er den realen Server des Backends gemäß dem Load Balancing-Algorithmus aus. Er modifiziert oder kapselt das IP-Paket nicht, ändert jedoch die MAC-Adresse der Daten Frame an die MAC-Adresse des realen Servers des Backends senden und ihn dann über das LAN senden. Der Back-End-Realserver empfängt diesen Frame, entkapselt ihn und stellt fest, dass die Ziel-IP mit dem lokalen Computer übereinstimmt (VIP ist im Voraus gebunden), sodass er die Nachricht verarbeitet, die Nachricht dann erneut kapselt und die Antwortnachricht an den übermittelt Anschließend wird die physische Netzwerkkarte über die lo-Schnittstelle gesendet und der Client erhält die Antwortnachricht. Der Client geht davon aus, dass er einen normalen Dienst erhalten hat, und weiß nicht, welcher Server ihn verarbeitet hat. Überquert es ein Netzwerksegment, wird das Paket über das Internet über den Router an den Benutzer zurückgesendet.

Zu den Funktionen von LVS-DR gehören:
1. Director Server und Real Server müssen sich im selben physischen Netzwerk befinden.
2.Real Server kann private Adressen oder öffentliche Netzwerkadressen verwenden. Wenn Sie eine öffentliche Netzwerkadresse verwenden, können Sie über das Internet direkt auf RIP zugreifen.
3. Der Director-Server dient als Zugangseingang zum Cluster, jedoch nicht als Gateway.
4. Alle Anforderungsnachrichten werden über den Director-Server weitergeleitet, Antwortantwortnachrichten können jedoch nicht über den Director-Server weitergeleitet werden.
5. Das Gateway des realen Servers darf nicht auf die IP des Director-Servers verweisen, d. h. die vom realen Server gesendeten Datenpakete dürfen den Director-Server nicht passieren.
6. Konfigurieren Sie die IP-Adresse des VIP auf der lo-Schnittstelle auf dem Real Server.

ARP-Probleme und Lösungen in LVS-DR:
Im LVS-DR-Lastausgleichscluster sind der Lastausgleichsdienst und der Knotenserver mit derselben VIP-Adresse konfiguriert, was zu Störungen der ARP-Kommunikation führt. Wenn ein ARP-Broadcast an den Cluster gesendet wird, empfangen ihn sowohl der Load Balancer als auch der Knotenserver. So beheben Sie dieses Problem:
Behandeln Sie den Knotenserver so, dass er nicht auf ARP-Anfragen für VIPs antwortet. Sie können die virtuelle Schnittstelle lo:0 verwenden, um die VIP-Adresse zu übertragen, und den Kernel-Parameter arp_ignore = 1 festlegen, sodass das System nur auf ARP-Anfragen antwortet, deren Ziel-IP die lokale IP ist.
Wenn der echte Server eine Nachricht zurückgibt (die Quell-IP ist VIP) und sie über den Router weiterleitet, verwendet Linux standardmäßig die Quell-IP-Adresse des IP-Pakets (d. h. VIP) als Quell-IP-Adresse im ARP-Anforderungspaket Verwenden der IP-Adresse der sendenden Schnittstelle. Dies führt möglicherweise dazu, dass der Router ARP-Einträge aktualisiert, wodurch die VIP des Director ungültig wird. Die Lösung besteht darin, den Knotenserver zu verarbeiten und den Kernel-Parameter arp_announce = 2 festzulegen, sodass das System nicht die Quelladresse des IP-Pakets verwendet, um die Quelladresse der ARP-Anforderung festzulegen, sondern die IP-Adresse der sendenden Schnittstelle auswählt.