Einführung #
Zu den vier Typen von Network Address Translation (NAT), die in RELIANOID ADC, Wir haben Quell-NAT (NAT), Dynamisches NAT (DNAT), Direkte Serverrückgabe (DSR)und zustandsloses DNAT. In diesem Artikel werden wir uns mit den Feinheiten von Direct Server Return (DSR) befassen und dessen Architektur, Vorteile und mögliche Hürden untersuchen. Wir werden DSR auch in Relianoid ADC einrichten.
DSR bedeutet, dass Backend-Anwendungsserver direkt auf die Anfragen des Clients antworten, nachdem sie eine Anfrage empfangen und verarbeitet haben. Aber wie funktioniert das? So läuft die Kommunikation zwischen den Servern und Webclients ab.
DSR-Kommunikationsfluss #
Kundenanfrage: Ein Client initiiert eine Anforderung, beispielsweise den Zugriff auf streambare Mediendateien oder das Senden von Daten an Anwendungsserver über Relianoid ADC.
Load Balancer-Interaktion: Nach Erhalt der Anfrage ändert Relianoid den Inhalt der Anfrage nicht, außer Ziel-MAC-Adresse. Die geänderte MAC-Adresse ist die des Backend-Servers, der die Anforderung verarbeitet. Der Load Balancer leitet die Anforderung dann basierend auf dem eingestellten Load Balancing-Algorithmus an den entsprechenden Backend-Server weiter.
Backend-Anwendungsserver: Nach Erhalt der Anfrage verarbeitet der Backend-Server die Anfrage und generiert eine Antwort.
Direkte Antwort: Der Backend-Server sendet dann die Antwort direkt an das Client-Gerät und schließt so die Kommunikationsschleife.
Wichtiger Hinweis
- Relianoid antwortet normalerweise im Namen der Backend-Server auf ARP-Anfragen, um die ursprüngliche Client-Server-Kommunikation aufrechtzuerhalten. Daher sind geeignete ARP-Konfigurationen entscheidend, um eine ordnungsgemäße Paketweiterleitung sicherzustellen.
- Das IP-Adressschema muss sorgfältig geplant werden, um Konflikte zu vermeiden und eine ordnungsgemäße Kommunikation zwischen Clients und Backend-Servern sicherzustellen. Normalerweise konfigurieren wir Backend-Server so, dass sie IP-Adressen haben, die der von der L4xNAT-Farm verwendeten virtuellen IP (VIP) ähneln. Die Backends geben diese jedoch möglicherweise nicht in ARP-Aufrufen bekannt, um Konflikte zu vermeiden.
Warum Sie DSR für Ihre Netzwerkinfrastruktur verwenden sollten #
DSR ist in der heutigen Netzwerkinfrastruktur äußerst wichtig geworden, da es große Datenmengen verarbeiten kann, ohne größere Engpässe zu verursachen. Das ist hier eine große Sache. Neben Skalierbarkeit, Vielseitigkeit, hoher Verfügbarkeit und Fehlertoleranz sind die Hauptgründe, warum DSR sich von der Konkurrenz abhebt, folgende:
Turbolader-Leistung: Durch die Eliminierung der zusätzlichen Hops, die durch herkömmliche Routing-Methoden entstehen, reduziert DSR Latenz und Paketverlust erheblich. Wir könnten dieses Setup beim Gaming und Video-Streaming verwenden, wo die effiziente Übermittlung großer Datenmengen von entscheidender Bedeutung ist.
Beispielsweise ermöglicht DSR bei Multiplayer-Spielen die direkte Kommunikation zwischen Spieleclients und Spieleservern, ohne dass der Load Balancer jedes Datenpaket vermitteln muss. Diese direkte Kommunikation ermöglicht eine schnellere und effizientere Übertragung spielbezogener Daten wie Spielerbewegungen, Aktionen und Updates. Dadurch reduziert DSR die Latenz, verbessert das Spielerlebnis und trägt zu einem flüssigeren Gameplay bei.
Ähnlich verhält es sich beim Videostreaming: Wenn ein Client einen Videostream anfordert, können die Backend-Server die Videodaten direkt an den Client übertragen, ohne sie über den Load Balancer leiten zu müssen. Indem wir den Load Balancer aus dem Datenpfad entfernen, minimieren wir potenzielle Engpässe und gewährleisten ein nahtloses Streaming-Erlebnis für die Zuschauer. Dies ist insbesondere bei qualitativ hochwertigen oder hochauflösenden Videoinhalten von Vorteil, bei denen die effiziente Handhabung großer Datenmengen für eine unterbrechungsfreie Wiedergabe unerlässlich ist.
Reduzierte Belastung des Load Balancers: Mit DSR entlasten wir den Load Balancer bei der Verarbeitung des Rückverkehrs vom Backend-Server. Diese Entlastung reduziert die Verarbeitungslast des Load Balancers erheblich, sodass er sich auf die effiziente Verteilung eingehender Anfragen konzentrieren kann. Dadurch kann der Load Balancer ein höheres Verkehrsaufkommen bewältigen und eine bessere Gesamtskalierbarkeit erreichen.
Es ist nicht erforderlich, eine Routing-Tabelle zu pflegen: Das Routing kann komplex sein, insbesondere in großen Netzwerken mit mehreren Subnetzen und komplizierten Routing-Richtlinien. Da der Load Balancer keine Routing-Tabelle für den Rückverkehr verwaltet, muss er keine komplexen Routing-Konfigurationen handhaben und verwalten. Dadurch verringert sich die Wahrscheinlichkeit von Fehlkonfigurationen oder routingbezogenen Problemen.
Relianoid-Konfigurationen für Linux- und Windows-Backend-Server #
Um DSR zu aktivieren, müssen Sie zunächst einen virtuellen Layer-4-Server oder eine L4xNAT-Farm konfigurieren. Lesen Sie fehlen uns die Worte. Artikel, um einen zu erstellen.
Anforderungen für DSR: #
- Die virtuelle IP und Backends müssen sich im selben Netzwerk befinden.
- Die Virtueller Port und die Backend-Ports müssen identisch sein.
- Man muss die Backends konfigurieren Loopback Schnittstellen mit der gleichen IP-Adresse wie die im Load Balancer konfigurierte VIP und deaktivieren ARP in dieser Schnittstelle.
Linux-Backend-Server #
# ifconfig lo:0 192.168.0.99 Netzmaske 255.255.255.255 -arp up
Mit diesem Befehl erstellen wir eine virtuelle Netzwerkschnittstelle ich:0 mit der IP-Adresse 192.168.0.99 und eine Subnetzmaske von 255.255.255.255.
Die -arp Flag deaktiviert das Address Resolution Protocol (ARP) auf dieser Schnittstelle.
Deaktivieren ungültiger ARP-Antworten im Backend. #
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
Dieser Befehl setzt den Wert von arp_ignore auf 1 in England, /proc/sys/net/ipv4/conf/all Datei. Dieser Parameter bestimmt, wie der Kernel auf ARP-Anfragen reagiert. Wenn er auf 1 gesetzt wird, ignoriert das System ARP-Anfragen für IP-Adressen, die nicht auf der Netzwerkschnittstelle konfiguriert sind.
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
Dieser Befehl ändert den Parameter arp_announce auf den Backend-Servern. In DSR-Konfigurationen wird arp_announce auf 2 stellt sicher, dass die Backend-Server bei der Beantwortung von ARP-Anfragen die Ziel-IP-Adresse der Anfrage als Quell-IP-Adresse in der ARP-Antwort verwenden. Dadurch wird eine ordnungsgemäße Kommunikation zwischen den Backend-Servern und dem Client gewährleistet, da der Client erwartet, die Antwort von der IP-Adresse zu erhalten, an die er die Anfrage gesendet hat.
Windows-Backend-Server #
- Start->Einstellungen ->Systemsteuerung->Netzwerk- und DFÜ-Verbindungen.
- Klicken Sie mit der rechten Maustaste auf Ihren Netzwerkadapter und klicken Sie auf Eigenschaften im Vergleich.
- Nur Internet-Protokoll muss ausgewählt sein (Deaktivieren Sie „Client für MS-Netzwerke“ und „Datei- und Druckerfreigabe“)
- TCP/IP-Eigenschaften-> Geben Sie die IP-Adresse des VIP in der Relianoid ADC-Farm ein. Das Standard-Gateway ist optional. Geben Sie die Maske ein 255.255.255.255
- Stellen Sie die Schnittstellenmetrik auf 254. Diese Konfiguration ist erforderlich, um keine ARP-Antworten an den VIP mehr zu beantworten.
- Presse OK und speichern Sie die Änderungen.
Konfigurieren Sie anschließend das Host-Sicherheitsmodell so, dass es Datenverkehr von Relianoid ADC über die NIC-Schnittstelle akzeptiert. Erlauben Sie Relianoid ADC außerdem, Datenverkehr über die Standard-NIC-Schnittstelle zu senden und zu empfangen. Öffnen Sie CMD als Administrator und führen Sie die drei bereitgestellten Befehle aus.
Netsh-Schnittstelle IPv4, Schnittstelle NIC festlegen, weakhostreceive=aktiviert, Netsh-Schnittstelle IPv4, Schnittstelle Loopback festlegen, weakhostsend=aktiviert, Netsh-Schnittstelle IPv4, Schnittstelle Loopback festlegen, weakhostsend=aktiviert
Wichtiger Hinweis
Ändern Sie die Netzwerkkarte und kehren Sie zu den Standardschnittstellennamen Ihres Windows-Computers zurück.
Herausforderungen bei der Verwendung von DSR #
Obwohl Direct Server Return (DSR) zahlreiche Vorteile bietet, kann es manchmal auch potenzielle Herausforderungen mit sich bringen, die Unternehmen berücksichtigen und bewältigen müssen. Das Verständnis dieser Herausforderungen hilft dabei, DSR effektiv zu planen und umzusetzen. Hier sind einige häufige Herausforderungen im Zusammenhang mit DSR:
Asymmetrisches Routing: Dies bedeutet, dass die Vorwärts- und Rückwärtspfade unterschiedliche Routen nehmen. Dies kann zwar Vorteile haben, asymmetrisches Routing kann jedoch die Netzwerkfehlerbehebung und -überwachung erschweren, da der Datenfluss nicht symmetrisch ist.
Serverkompatibilität: Nicht alle Server unterstützen DSR mit allen Arten von Anwendungen. Beispielsweise können wir DSR nur mit Linux- oder Windows-Servern durchführen, wenn wir Relianoid verwenden.
Zustandsbehaftete Operationen: Bei zustandsbehafteten Vorgängen, die auf der Aufrechterhaltung von Sitzungsinformationen beruhen, kann DSR eine Herausforderung darstellen. Bei Verwendung anderer NAT-Typen verarbeiten Load Balancer alle Formen der Sitzungspersistenz, aber mit DSR umgeht das direkte Routing diese Vermittler. Eine Möglichkeit, dies zu umgehen, besteht darin, für die Sitzungspersistenz die Quell-IP-Adresse auf Ebene 4 und Cookie Insert auf Ebene 7 zu verwenden.
Netzwerktransparenz und -überwachung: DSR kann die Netzwerktransparenz und -überwachung beeinträchtigen, da der Datenverkehr Load Balancer oder Reverse-Proxys umgeht. Überwachungstools und -systeme, die auf Verkehrsinspektion oder -abfang bei diesen Vermittlern beruhen, erfassen möglicherweise nicht das vollständige Bild des Netzwerkverkehrs. Unternehmen können alternative Überwachungslösungen implementieren, um die Transparenz des Datenverkehrs zu gewährleisten, der über DSR-Pfade fließt.
Bereitstellungskomplexität: Die Implementierung von DSR kann während der Bereitstellung und Konfiguration zusätzliche Komplexität mit sich bringen. Um eine reibungslose Implementierung zu gewährleisten, sind eine ordnungsgemäße Planung, Entwicklung und Prüfung von entscheidender Bedeutung. Beispielsweise müssen Sie möglicherweise jeden Backend-Server so einrichten, dass er SSL-Offloading und -Protokollierung durchführt.
Sicherheitsüberlegungen: DSR kann Sicherheitsprobleme mit sich bringen, insbesondere wenn der Datenverkehr die in Load Balancern implementierten Sicherheitsmaßnahmen direkt umgeht. Manchmal müssen Sie möglicherweise die Details der Antwortheader ändern, was mit DSR-Setups nicht möglich ist.
Indem Unternehmen diese Herausforderungen proaktiv angehen, können sie DSR erfolgreich implementieren, seine Vorteile nutzen und gleichzeitig potenzielle Nachteile minimieren.
Fazit #
Direct Server Return (DSR) ist ein überzeugender Lastausgleichsansatz, der Ihre Infrastruktur um erhebliche Vorteile bereichern kann. Indem der Rückverkehr von Backend-Servern abgeladen wird und diese Antworten direkt an die Clients senden können, reduziert DSR die Belastung des Lastausgleichs und verbessert die Skalierbarkeit des gesamten Systems.
Ein weiterer Vorteil könnte eine geringere Netzwerklatenz sein, da Antworten einen direkteren Weg zu den Clients nehmen und den Load Balancer umgehen. Dies kann insbesondere für latenzempfindliche Anwendungen von Vorteil sein und eine schnellere Bereitstellung von Inhalten und ein verbessertes Benutzererlebnis gewährleisten.
Bewerten Sie jedoch sorgfältig die spezifischen Anforderungen Ihrer Netzwerkarchitektur und Anwendungsanforderungen, bevor Sie DSR implementieren. Berücksichtigen Sie Faktoren wie Netzwerktopologie, Routingprotokolle, die Notwendigkeit der Sitzungspersistenz und mögliche damit verbundene Herausforderungen.
Indem Sie die Vorteile von DSR nutzen, können Sie Ihre Infrastruktur optimieren, um steigende Verkehrslasten zu bewältigen und ein nahtloses Benutzererlebnis zu bieten.
