Introduction #
Parmi les quatre types de traduction d'adresses réseau(NAT) pris en charge dans RELIANOID ADC, nous avons NAT source (NAT), NAT dynamique (ADNT), Retour direct au serveur (DSR) et DNAT sans état. Dans cet article, nous approfondirons les subtilités du Direct Server Return (DSR), en explorant son architecture, ses avantages et ses obstacles potentiels. Nous configurerons également DSR dans Reliianoid ADC.
DSR se produit lorsque les serveurs d'applications principaux répondent directement aux demandes du client lors de la réception et du traitement d'une demande. Mais, comment cela fonctionne-t-il ? Voici comment la communication circule entre les serveurs et les clients Web.
Flux de communication DSR #
Demande du client : Un client lance une demande, par exemple l'accès à des fichiers multimédias diffusables ou l'envoi de données à des serveurs d'applications via Reliianoid ADC.
Interaction de l'équilibreur de charge : Dès réception de la demande, Reliianoid ne modifie pas le contenu de la demande à l'exception du Adresse MAC de destination. L'adresse MAC modifiée est celle du serveur principal pour traiter la requête. L'équilibreur de charge transmet ensuite la demande au serveur principal approprié en fonction de l'algorithme d'équilibrage de charge défini.
Serveur d'applications principal : Lors de la réception de la demande, le serveur principal traite la demande et génère une réponse.
Réponse directe: Le serveur Backend envoie ensuite la réponse directement à l'appareil client, complétant ainsi la boucle de communication.
NOTE IMPORTANTE
- Reliianoid répond généralement aux requêtes ARP au nom des serveurs backend pour préserver la communication client-serveur d'origine. Par conséquent, des configurations ARP appropriées sont cruciales pour garantir un routage correct des paquets.
- Il faut soigneusement planifier le schéma d'adressage IP pour éviter les conflits et assurer une bonne communication entre les clients et les serveurs principaux. Nous configurons généralement les serveurs principaux pour qu'ils aient des adresses IP similaires à l'adresse IP virtuelle (VIP) utilisée par la ferme L4xNAT, mais les principaux peuvent ne pas l'annoncer dans les appels ARP pour éviter les conflits.
Pourquoi utiliser DSR pour votre infrastructure réseau #
DSR est devenu extrêmement important dans l'infrastructure réseau d'aujourd'hui en raison de sa capacité à gérer des quantités massives de données sans provoquer de goulots d'étranglement majeurs. Ceci, ici, est un gros problème. Outre l'évolutivité, la polyvalence, la haute disponibilité et la tolérance aux pannes, les principales raisons pour lesquelles DSR se démarque sont les suivantes :
Performances turbocompressées : En éliminant les sauts supplémentaires introduits par les méthodes de routage traditionnelles, DSR réduit considérablement la latence et la perte de paquets. Nous pourrions utiliser cette configuration dans les jeux et le streaming vidéo, où la livraison efficace de blocs de données substantiels est cruciale.
Par exemple, dans les jeux multijoueurs, DSR permet une communication directe entre les clients de jeu et les serveurs de jeu sans que l'équilibreur de charge n'intervienne dans chaque paquet de données. Cette communication directe permet une transmission plus rapide et plus efficace des données liées au jeu, telles que les mouvements des joueurs, les actions et les mises à jour. En conséquence, le DSR réduit la latence, améliore l'expérience de jeu et contribue à un gameplay plus fluide.
De même, dans le streaming vidéo, lorsqu'un client demande un flux vidéo, les serveurs principaux peuvent transmettre directement les données vidéo au client sans les acheminer via l'équilibreur de charge. En supprimant l'équilibreur de charge dans le chemin des données, nous minimisons les goulots d'étranglement potentiels, garantissant une expérience de streaming transparente pour les téléspectateurs. Ceci est particulièrement avantageux pour le contenu vidéo de haute qualité ou haute résolution, où la gestion efficace de gros blocs de données est essentielle pour une lecture ininterrompue.
Charge réduite sur l'équilibreur de charge : Avec DSR, nous soulageons l'équilibreur de charge qui gère le trafic de retour du serveur principal. Ce déchargement réduit considérablement la charge de traitement de l'équilibreur de charge, lui permettant de se concentrer sur la distribution efficace des demandes entrantes. En conséquence, l'équilibreur de charge gérera un volume de trafic plus élevé et atteindra une meilleure évolutivité globale.
Pas besoin de maintenir une table de routage : Le routage peut être complexe, en particulier dans les réseaux à grande échelle avec plusieurs sous-réseaux et des politiques de routage complexes. En ne conservant pas de table de routage pour le trafic de retour, l'équilibreur de charge évite d'avoir à gérer et à gérer des configurations de routage complexes, réduisant ainsi les risques de mauvaises configurations ou de problèmes liés au routage.
Configurations Reliianoid pour les serveurs backend Linux et Windows #
Pour activer DSR, vous devez d'abord configurer un serveur virtuel de couche 4 ou une ferme L4xNAT. Lire ceci. article pour en créer un.
Exigences pour DSR: #
- L' IP virtuelle et les backends doivent être dans le même réseau.
- L' Port virtuel et les ports principaux doivent être les mêmes.
- Il faut configurer les backends loopback interfaces avec la même adresse IP que le VIP configuré dans l'équilibreur de charge et désactiver ARP dans cette interface.
Serveurs dorsaux Linux #
# ifconfig lo:0 192.168.0.99 masque de réseau 255.255.255.255 -arp up
Avec cette commande, nous créons une interface réseau virtuelle bas : 0 avec l'adresse IP 192.168.0.99 et un masque de sous-réseau de 255.255.255.255.
L' -arp L'indicateur désactive le protocole ARP (Address Resolution Protocol) sur cette interface.
Désactivation des réponses ARP non valides dans le backend. #
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
Cette commande définit la valeur de arp_ignore sur 1 dans le /proc/sys/net/ipv4/conf/all déposer. Ce paramètre détermine comment le noyau répond aux requêtes ARP. Le définir sur 1 signifie que le système doit ignorer les requêtes ARP pour les adresses IP non configurées sur l'interface réseau.
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
Cette commande modifie le paramètre arp_announce sur les serveurs principaux. Dans les configurations DSR, définir arp_announce sur 2 garantit que lorsque les serveurs principaux répondent aux requêtes ARP, ils utilisent l'adresse IP de destination de la requête comme adresse IP source dans la réponse ARP. Cela maintient une communication correcte entre les serveurs principaux et le client, car le client s'attend à recevoir la réponse de l'adresse IP à laquelle il a envoyé la demande.
Serveurs principaux Windows #
- Commencer->Paramètres->Panneau de configuration->Connexions réseau et accès à distance.
- Faites un clic droit sur votre adaptateur réseau et cliquez sur Propriétés.
- Plus que Protocole Internet doit être sélectionné (Désélectionnez « Client pour les réseaux MS » et « Partage de fichiers et d'imprimantes »)
- Propriétés TCP/IP-> Entrez l'adresse IP du VIP dans la ferme Reliianoid ADC. La passerelle par défaut est facultative. Entrez le masque 255.255.255.255
- Définissez la métrique d'interface sur 254. Cette configuration est nécessaire pour arrêter de répondre à toute réponse ARP au VIP
- Presse OK et enregistrez les modifications.
Ensuite, configurez le modèle de sécurité de l'hôte pour accepter le trafic de Reliianoid ADC sur l'interface NIC. De plus, autorisez Reliianoid ADC à envoyer et recevoir du trafic via l’interface NIC par défaut. Ouvrez CMD en tant qu'administrateur et exécutez les trois commandes fournies.
interface netsh ipv4 définir l'interface NIC lowhostreceive = activé interface netsh ipv4 définir le bouclage de l'interface lowhostreceive = activé interface netsh ipv4 définir le bouclage de l'interface lowhostsend = activé
NOTE IMPORTANTE
Modifiez la carte réseau et revenez aux noms d'interface par défaut de votre ordinateur Windows.
Défis de l'utilisation de DSR #
Bien que le retour direct au serveur (DSR) offre de nombreux avantages, il peut parfois présenter des défis potentiels que les organisations doivent prendre en compte et résoudre. Comprendre ces défis aidera à planifier et à mettre en œuvre efficacement la DSR. Voici quelques défis courants associés à la DSR :
Routage asymétrique : Cela signifie que les chemins aller et retour empruntent des itinéraires différents. Bien que cela puisse avoir des avantages, le routage asymétrique peut compliquer le dépannage et la surveillance du réseau car le flux de trafic n'est pas symétrique.
Compatibilité serveur : Tous les serveurs ne prennent pas en charge DSR avec tous les types d'applications. Par exemple, nous ne pouvons effectuer du DSR qu'avec des serveurs Linux ou Windows lorsque nous utilisons Reliianoid.
Opérations avec état : Pour les opérations avec état qui reposent sur la maintenance des informations de session, DSR peut poser des problèmes. Lors de l'utilisation d'autres types de NAT, les équilibreurs de charge gèrent toutes les formes de persistance de session, mais avec DSR, le routage direct contourne ces intermédiaires. Une façon de contourner cela consiste à utiliser l'adresse IP source au niveau 4 et l'insertion de cookie au niveau 7 pour la persistance de la session.
Visibilité et surveillance du réseau : Le DSR peut avoir un impact sur la visibilité et la surveillance du réseau puisque le trafic contourne les équilibreurs de charge ou les proxys inverses. Les outils et systèmes de surveillance qui s'appuient sur l'inspection ou l'interception du trafic au niveau de ces intermédiaires peuvent ne pas capturer l'image complète du trafic réseau. Les organisations peuvent mettre en œuvre des solutions de surveillance alternatives pour assurer la visibilité du trafic circulant sur les chemins DSR.
Complexité du déploiement : L'implémentation de DSR peut introduire une complexité supplémentaire lors du déploiement et de la configuration. Une planification, une conception et des tests appropriés sont essentiels pour assurer une mise en œuvre en douceur. Par exemple, vous devrez peut-être configurer chaque serveur principal pour effectuer le déchargement et la journalisation SSL.
Considérations de sécurité : DSR peut introduire des problèmes de sécurité, en particulier lorsque le trafic contourne directement les mesures de sécurité mises en œuvre au niveau des équilibreurs de charge. Parfois, vous devrez peut-être modifier les détails des en-têtes de réponse, ce qui est impossible avec les configurations DSR.
En s'attaquant de manière proactive à ces défis, les organisations peuvent mettre en œuvre avec succès la DSR et tirer parti de ses avantages tout en minimisant les inconvénients potentiels.
Conclusion #
Direct Server Return (DSR) présente une approche captivante d'équilibrage de charge avec le potentiel d'enrichir votre infrastructure avec des avantages significatifs. En déchargeant le trafic de retour des serveurs principaux et en leur permettant d'envoyer des réponses directement aux clients, DSR réduit la charge sur l'équilibreur de charge et améliore l'évolutivité globale du système.
Un autre avantage pourrait être une latence réseau plus faible, car les réponses empruntent un chemin plus direct vers les clients, en contournant l'équilibreur de charge. Cela peut être particulièrement avantageux pour les applications sensibles à la latence, garantissant une diffusion plus rapide du contenu et une meilleure expérience utilisateur.
Cependant, évaluez soigneusement les exigences spécifiques de votre architecture réseau et les besoins de vos applications avant de mettre en œuvre DSR. Tenez compte de facteurs tels que la topologie du réseau, les protocoles de routage, le besoin de persistance de session et les défis potentiels associés.
En tirant parti des avantages de DSR, vous pouvez optimiser votre infrastructure pour gérer des charges de trafic croissantes et offrir une expérience utilisateur transparente.
