SNAT vs PBR pour l'équilibrage de charge du serveur

Dans une configuration SLB à un bras, SNAT est utilisé pour forcer le trafic de retour à traverser le SLB. Cela a un inconvénient: simplement que les journaux Web ne peuvent pas capturer la véritable IP du client à moins qu'ils ne soient transmis dans l'en-tête XFF (X-Forwarded-For) et que le serveur Web puisse se connecter.

Une alternative consiste à utiliser PBR (routage basé sur des règles) pour ramener le trafic de retour vers le SLB, mais j'essaie d'éviter PBR sauf s'il n'y a pas d'autre solution / meilleure Sur la plate-forme 6500E avec SUP720 / PFC3B - et je connais le particulier La version IOS peut également être un facteur - PBR ajoute-t-il une latence par rapport à SNAT en supposant que PBR est entièrement fait dans le matériel? Si le PBR est effectué dans le matériel en utilisant uniquement les commandes prises en charge par celui-ci aujourd'hui, est-il possible que la mise à niveau d'IOS à l'avenir puisse changer le PBR à effectuer dans le logiciel / processus commuté?

Aujourd'hui, nos équilibreurs de charge ont la plupart des VLAN de serveur Web directement derrière eux - par défaut g / w pointant vers SLB - et d'autres serveurs comme SQL dans les VLAN non SLB. Cependant, ce trafic web-sql transite par le SLB. Notre objectif serait d'éviter de traverser la SLB et de simplement séparer le trafic SQL, tout en conservant le vrai client dans les journaux Web. Je préférerais ne pas introduire de complexité de dépannage avec PBR et éventuellement avoir ce changement du matériel au logiciel traité à l'avenir. En deçà des XFF et SNAT mentionnés précédemment, le PBR est-il la seule option ici et quelle est la meilleure façon de maintenir le PBR étroitement configuré?

— erreur générale de réseau
source

Je ne suis pas sûr à 100% de comprendre la topologie, votre serveur a-t-il deux interfaces et vous avez besoin de SNAT pour que le serveur puisse avoir une route statique unique pour renvoyer le trafic de «production» vers l'interface face à SLB? Mais SNAT dans la configuration 1: N implique des états, qui doivent toujours être évités, PBR est sans état donc il évolue beaucoup mieux.

— ytti

Normalement, je déconseille la conception d'équilibreur de charge à un bras (ou vous pouvez l'appeler équilibreur de charge sur un bâton), et optez pour un sous-réseau frontal pour les VIP à charge équilibrée et un sous-réseau arrière pour le serveur piscines. Les serveurs par défaut via l'interface arrière sur l'équilibreur de charge. Cela élimine complètement le besoin de SNAT ou PBR.

— Mike Pennington

Mis à part mon commentaire sur les topologies d'équilibreur de charge ... pourriez-vous ajouter quelques diagrammes pour référence, car une partie de la question n'est pas claire lorsque vous n'êtes pas sûr de ce à quoi ressemble l'image plus grande.

— Mike Pennington

@ytti, la topologie actuelle a SLB en ligne avec le g / w par défaut des serveurs pointant vers SLB - NIC / serveur unique. Nous avons essentiellement ce que Mike a décrit avec les VLAN côté client et côté serveur sur deux interfaces de la SLB maintenant, mais c'est une question de passer à une topologie différente comme à un bras afin que le trafic serveur vers SQL n'ait pas à traverser le SLB et nous préférons ne pas ajouter de complexité aux serveurs tels que les doubles cartes réseau avec des routes statiques de serveur, etc. La compréhension de la latence de SNAT vs PBR est la clé ainsi que d'autres conceptions que j'ai manquées (comme le retour direct du serveur décrit dans une réponse ).

— generalnetworkerror

De quels serveurs s'agit-il? Sous Linux (ou * BSD), il est facile à configurer afin que le paquet soit renvoyé à l'interface d'où il vient, ce qui est utile dans les configurations SLB (nous l'utilisons pour connecter les serveurs de manière redondante à deux boîtiers SLB déconnectés, les VIP sont ECMPd donc les deux sont chauds, mais peuvent provenir de différents fournisseurs car ils ne se connaissent pas).

— ytti

Réponses:

PBR ajoute-t-il une latence par rapport à l'exécution de SNAT en supposant que PBR est entièrement fait dans le matériel?

Sup720 prend en charge PBR dans HW , la latence supplémentaire (le cas échéant) est négligeable car PBR n'ajoute pas plus de file d'attente d'interface. Je pense que le PBR rendrait les choses plus difficiles qu'elles ne devraient l'être (et je ne suis toujours pas sûr que cela fonctionnerait ... les détails de cette option ne sont pas totalement clairs)

En deçà des XFF et SNAT mentionnés précédemment, le PBR est-il la seule option ici et quelle est la meilleure façon de maintenir le PBR étroitement configuré?

PBR n'est pas la seule option. Votre option proposée n'est pas claire, mais PBR se résume normalement à rien de plus qu'une façon plus sophistiquée de faire du routage statique.

Il s'agit généralement de la meilleure topologie pour les services à charge équilibrée qui nécessitent des requêtes SQL ...

Mettez vos VIP sur un sous-réseau frontal ... 172.16.1.0/24 dans le diagramme
Placez vos pools de serveurs dans un sous-réseau arrière ... 172.16.2.0/24 dans le diagramme
Placez vos requêtes SQL sur une autre interface ... 172.16.3.0/24 dans le diagramme. Ajoutez une seconde interface à tous les serveurs qui nécessitent des requêtes SQL. Faites toutes vos requêtes SQL aux adresses de ce sous-réseau. Cette topologie fonctionne à la fois pour Unix et Windows, car vous ne comptez que sur ARP ou sur des routes d'hôtes (selon vos préférences) pour la connectivité SQL.

Diagramme:

LB avec réseau de requêtes SQL

Cette topologie présente des avantages supplémentaires:

Il sépare les interfaces SQL du trafic Web, car les requêtes SQL sont éclatantes et peuvent entraîner une congestion du trafic Web.
Il fournit différentes MTU pour vos services à charge équilibrée (qui doivent généralement rester à 1500 ou moins, s'ils transitent sur Internet) et vos services SQL (qui favorisent les trames jumbo).

Toute topologie d'équilibrage de charge à un bras est une option moins souhaitable car vous finissez par réduire votre débit maximal de moitié en raison de la topologie à un bras.

EDIT pour une question sur la commutation HW vs SW sur Sup720

C'est un sujet profond, mais je vais donner la version résumée ... Sup720 applique une ACL dans chaque direction (entrée / sortie) et l'ACL doit tenir dans TCAM en fonction de l'algorithme de fusion choisi par la plate-forme. Le gestionnaire de fonctionnalités de Sup720 (c'est-à-dire fm) est responsable de la médiation des fonctionnalités dans TCAM et de signaler si vous avez une contiguïté punt (c'est-à-dire une commutation SW), ou si la combinaison de protocole et de direction est commutée dans HW. Pour isoler si

Tout d'abord, identifiez toutes les interfaces d'entrée et de sortie de couche 3 que le trafic PBR pourrait transiter
Ensuite, examinez la sortie de show fm fie int <L3_intf_name> | i ^Interf|Result|Flow|Config(vous devez regarder les directions d'entrée et de sortie pour toutes les interfaces à l'étape 1 ). Votre trafic sera HW commuté si les valeurs dans CAPS correspondent aux valeurs que vous voyez ci-dessous ... notez que la sortie de la commande que j'utilise est très similaire à ce que vous voyez dans show fm fie summary...

Tx.Core01#sh fm fie int Vl220 | i ^Interf|Result|Flow|Config
Interface Vl220:
 Flowmask conflict status for protocol IP : FIE_FLOWMASK_STATUS_SUCCESS      <--- in HW
 Flowmask conflict status for protocol OTHER : FIE_FLOWMASK_STATUS_SUCCESS   <--- in HW
 Flowmask conflict status for protocol IPV6 : FIE_FLOWMASK_STATUS_SUCCESS    <--- in HW
Interface Vl220 [Ingress]:
 FIE Result for protocol IP : FIE_SUCCESS_NO_CONFLICT                        <--- in HW
 Features Configured : V4_DEF   - Protocol : IP
 FIE Result for protocol OTHER : FIE_SUCCESS_NO_CONFLICT                     <--- in HW
 Features Configured : OTH_DEF   - Protocol : OTHER
 FIE Result for protocol IPV6 : FIE_SUCCESS_NO_CONFLICT                      <--- in HW
 Features Configured : V6_DEF   - Protocol : IPV6
Interface Vl220 [Egress]:
 No Features Configured
No IP Guardian Feature Configured
No IPv6 Guardian Feature Configured
No QoS Feature Configured
Tx.Core01#

L'interface ci-dessus n'affiche pas la sortie de sortie, mais ce n'est pas pertinent ... la sortie est similaire à la direction d'entrée. Ricky Micky a rédigé une explication exceptionnelle de «sh fm fie interface» si vous souhaitez plus de détails sur la dynamique des banques TCAM / résultats de la fusion.

— Mike Pennington
source

J'avais déjà éliminé cette option de conception car elle nécessite une contiguïté L2 entre le niveau frontal et le niveau principal, ainsi qu'une mauvaise mise à l'échelle pour nos multiples VLAN principaux et en raison du besoin potentiel de placer un pare-feu (non transparent ) entre les niveaux. Cependant, c'est toujours une excellente option pour ceux qui n'ont pas ces préoccupations. Bon point sur les MTU.

— generalnetworkerror

À moins de consulter la documentation de PBR pour des versions IOS spécifiques pour savoir si une fonction PBR donnée déclenche la nécessité de la faire dans le logiciel, cela peut-il être déterminé dans IOS? C'est ce que j'entendais par «étroitement configuré» pour que PBR continue de fonctionner au sein du matériel.

— generalnetworkerror

@generalnetworkerror, sur quel matériel voulez-vous faire du PBR? Si Sup720 / Sup2T, il n'est pas si difficile d'identifier si vous passez du HW au SW ... nous avons besoin de plus de détails pour vous aider. En fait, si cela ne vous dérange pas, un diagramme du fonctionnement de ce concept PBR serait vraiment utile

— Mike Pennington

SUP720 / PFC3B ... cherche à voir comment vous pouvez déterminer à partir de la CLI si une fonction PBR donnée a forcé cela à la commutation s / w

— generalnetworkerror

@generalnetworkerror, sh fm fie summary... ou lisez ma réponse pour plus d'informations ...

— Mike Pennington

Si votre équilibreur de charge le prend en charge, Direct Server Return ferait également ce que vous voulez. Il doit être pris en charge par votre équilibreur de charge et il existe des problèmes de système d'exploitation. Cela implique de mettre des interfaces de «bouclage» dans chaque serveur qui ont toutes l'adresse IP du VIP, l'équilibreur de charge tout en ayant les vraies adresses de serveur n'utilisent que l'adresse MAC du vrai serveur pour transmettre le paquet, puisque le serveur a l'interface de bouclage avec le VIP en elle, le serveur accepte le paquet.

Vous devez consulter la documentation du fournisseur LB spécifique et vos équipes de serveurs doivent être en mesure de gérer l'adaptateur virtuel (nous n'utilisons pas cette fonctionnalité car nous ne pensions pas que notre provisionnement de serveur automatisé pouvait gérer un adaptateur de bouclage MS.

Mais cela n'utilise pas NAT dans le LB et vous n'avez pas à faire de PBR.

— Fredpbaker
source