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é?

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:

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

1. Tout d'abord, identifiez toutes les interfaces d'entrée et de sortie de couche 3 que le trafic PBR pourrait transiter
2. 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.

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.