Bonnes pratiques en matière de mise en réseau et de VLAN des appliances NetScaler
Une appliance NetScaler utilise des VLAN pour déterminer quelle interface doit être utilisée pour quel trafic. De plus, l’appliance NetScaler ne participe pas à Spanning Tree. Sans une configuration VLAN appropriée, l’appliance NetScaler n’est pas en mesure de déterminer l’interface à utiliser et peut fonctionner davantage comme un HUB que comme un commutateur ou un routeur. En d’autres termes, l’appliance NetScaler peut utiliser toutes les interfaces pour chaque conversation.
Symptômes d’une mauvaise configuration du VLAN
Les problèmes de configuration d’un VLAN peuvent se manifester sous de nombreuses formes, notamment des problèmes de performances, l’impossibilité d’établir des connexions, des sessions déconnectées de manière aléatoire et, dans des situations graves, des perturbations du réseau apparemment sans rapport avec l’appliance NetScaler elle-même. L’appliance NetScaler peut également signaler des déplacements MAC, des interfaces muettes et/ou des dépassements de mémoire tampon émis ou reçus par l’interface de gestion, en fonction de la nature exacte de l’interaction avec votre réseau.
MAC Moves (counter nic_tot_bdg_mac_moved) : ce problème indique que l’appliance NetScaler utilise plusieurs interfaces pour communiquer avec le même appareil (adresse MAC), car elle n’a pas pu déterminer correctement quelle interface utiliser.
Interfaces désactivées (counter nic_err_bdg_muted) : ce problème indique que l’appliance NetScaler a détecté qu’elle créait une boucle de routage en raison de problèmes de configuration du VLAN et qu’elle a donc arrêté une ou plusieurs des interfaces problématiques afin d’éviter une panne réseau.
Dépassements de mémoire tampon d’interface, qui font généralement référence aux interfaces de gestion (counter nic_err_tx_overflow) : Ce problème peut survenirsi trop de trafic est transmis via une interface de gestion. Les interfaces de gestion de l’appliance NetScaler ne sont pas conçues pour gérer de gros volumes de trafic, ce qui peut résulter d’erreurs de configuration du réseau et du VLAN incitant l’appliance NetScaler à utiliser une interface de gestion pour le trafic de données de production. Cela se produit souvent parce que l’appliance NetScaler n’a aucun moyen de différencier le trafic sur le VLAN/sous-réseau du NSIP (NSVLAN) du trafic de production normal. Il est fortement recommandé que le NSIP se trouve sur un VLAN et un sous-réseau distincts de tous les appareils de production tels que les postes de travail et les serveurs.
ACK orphelins (counter tcp_err_orphan_ack) : ce problème indique que l’appliance NetScaler a reçu un paquet ACK auquel elle ne s’attendait pas, généralement sur une interface différente de celle d’où provenait le trafic ACK. Cette situation peut être due à des erreurs de configuration du VLAN dans lesquelles l’appliance NetScaler transmet via une interface différente de celle que la machine cible utilise habituellement pour communiquer avec l’appliance NetScaler (souvent associée à des déplacements de MAC)
Taux élevés de retransmissions ou d’abandons de retransmission (compteurs : tcp_err_retransmit_giveups, tcp_err_7th_retransmit, divers autres compteurs de retransmission) : l’appliance NetScaler tente de retransmettre un paquet TCP au total 7 fois avant qu’il n’abandonne et ne mette fin à la connexion. Bien que cette situation puisse être due à des problèmes de réseau, elle est souvent le résultat d’une mauvaise configuration du VLAN et de l’interface.
Cerveau divisé en haute disponibilité : lecerveau divisé est une condition dans laquelle les deux nœuds de haute disponibilité pensent qu’ils sont principaux, ce qui entraîne la duplication des adresses IP et la perte des fonctionnalités de l’appliance NetScaler. Cela se produit lorsque les deux nœuds de haute disponibilité ne peuvent pas communiquer entre eux à l’aide de Heartbeats à haute disponibilité sur le port UDP 3003 à l’aide du NSIP, sur n’importe quelle interface. Cela est généralement dû à des erreurs de configuration du VLAN, dans lesquelles le VLAN natif sur les interfaces de l’appliance NetScaler n’est pas connecté entre les appliances NetScaler.
Meilleures pratiques pour les configurations VLAN et réseau
-
Chaque sous-réseau doit être associé à un VLAN.
-
Plusieurs sous-réseaux peuvent être associés au même VLAN (selon la conception de votre réseau).
-
Chaque VLAN doit être associé à une seule interface (aux fins de cette discussion, un canal LA compte comme une interface unique).
-
Si vous avez besoin que plusieurs sous-réseaux soient associés à une interface, les sous-réseaux doivent être balisés.
-
Contrairement à la croyance populaire, la fonctionnalité de transfert basé sur Mac (MBF) de l’appliance NetScaler n’est pas conçue pour atténuer ce type de problème. Le MBF est principalement conçu pour le mode DSR (Direct Server Return) de l’appliance NetScaler, qui est rarement utilisé dans la plupart des environnements (il est conçu pour permettre au trafic de contourner délibérément l’appliance NetScaler sur le chemin de retour depuis les serveurs principaux). Le MBF peut masquer des problèmes de VLAN dans certains cas, mais il ne faut pas s’y fier pour résoudre ce type de problème.
-
Chaque interface de l’appliance NetScaler nécessite un VLAN natif (contrairement à Cisco, où les VLAN natifs sont facultatifs), bien que le paramètre TagAll d’une interface puisse être utilisé de manière à ce qu’aucun trafic non balisé ne quitte l’interface en question.
-
Le VLAN natif peut être balisé si nécessaire pour la conception de votre réseau (il s’agit de l’option TagAll pour l’interface).
-
Le VLAN du sous-réseau du NSIP de votre appliance NetScaler constitue un cas particulier. C’est ce qu’on appelle le NSVLAN. Les concepts sont les mêmes mais les commandes permettant de le configurer sont différentes et les modifications apportées au NSVLAN nécessitent un redémarrage de l’appliance NetScaler pour prendre effet. Si vous tentez de lier un VLAN à un SNIP qui partage le même sous-réseau que le NSIP, le message « Opération non autorisée » s’affiche. Cela est dû au fait que vous devez utiliser les commandes NSVLAN à la place. De plus, sur certaines versions du microprogramme, vous ne pouvez pas définir un NSVLAN si ce numéro de VLAN existe à l’aide de la commande.
add VLANSupprimez simplement le VLAN, puis reconfigurez le NSVLAN. -
Les Heartbeats à haute disponibilité utilisent toujours le VLAN natif de l’interface correspondante (éventuellement étiqueté si l’option TagAll est définie sur l’interface).
-
Il doit y avoir une communication entre au moins un ensemble de VLAN natifs sur les deux nœuds d’une paire haute disponibilité (cela peut être direct ou via un routeur). Les VLAN natifs sont utilisés pour les pulsations cardiaques à haute disponibilité. Si les appliances NetScaler ne peuvent pas communiquer entre les VLAN natifs sur n’importe quelle interface, cela peut entraîner des basculements en haute disponibilité et éventuellement une situation de division du cerveau dans laquelle les deux appliances NetScaler pensent qu’elles sont les principales (ce qui entraîne des adresses IP dupliquées, entre autres choses).
-
L’appliance NetScaler ne participe pas à Spanning Tree. Il n’est donc pas possible d’utiliser Spanning Tree pour fournir une redondance d’interface lors de l’utilisation d’une appliance NetScaler. Utilisez plutôt une forme d’agrégation de liens (LACP ou LAG manuel) à cette fin.
Remarque : Si vous souhaitez disposer d’une agrégation de liens entre plusieurs commutateurs physiques, vous devez configurer les commutateurs en tant que commutateurs virtuels, à l’aide d’une fonctionnalité telle que Switch Stack de Cisco.
-
La synchronisation à haute disponibilité et la propagation des commandes utilisent par défaut le NSIP/NSVLAN. Pour les séparer dans un autre VLAN, vous pouvez utiliser l’option SyncVLAN de la commande.
set HA node -
Rien n’est intégré à la configuration par défaut de l’appliance NetScaler qui indique qu’une interface de gestion (0/1 ou 0/2) est limitée au trafic de gestion uniquement. Cette restriction doit être appliquée par l’utilisateur final via la configuration du VLAN. Les interfaces de gestion ne sont pas conçues pour gérer le trafic de données. La conception de votre réseau doit donc tenir compte de ce point. Les interfaces de gestion, contenues sur la carte mère de l’appliance NetScaler, ne disposent pas de diverses fonctionnalités de déchargement, telles que le déchargement CRC, des tampons de paquets plus importants et d’autres optimisations, ce qui les rend beaucoup moins efficaces pour gérer de gros volumes de trafic. Pour séparer les données de production du trafic de gestion, le NSIP ne doit pas se trouver sur le même sous-réseau/VLAN que votre trafic de données.
-
Si vous souhaitez utiliser une interface de gestion pour transporter le trafic de gestion, il est préférable que l’itinéraire par défaut se trouve sur un sous-réseau autre que le sous-réseau du NSIP (NSVLAN).
Dans de nombreuses configurations, la route par défaut est utilisée pour les communications entre postes de travail (dans un scénario Internet). Si l’itinéraire par défaut se trouve sur le même sous-réseau que le NSIP, l’appliance ADC peut utiliser l’interface de gestion pour envoyer et recevoir du trafic de données. Cette utilisation du trafic de données peut surcharger l’interface de gestion.
-
De plus, un SDX, la SVM, XenServer et tous les NSIP d’instance NetScaler doivent se trouver sur le même VLAN et le même sous-réseau. L’appliance SDX ne contient aucun panneau arrière permettant la communication entre les instances SVM/XEN/. S’ils ne se trouvent pas sur le même VLAN/sous-net/interface, le trafic entre eux doit quitter le matériel physique, être acheminé sur votre réseau et revenir.
Cette configuration peut entraîner des problèmes de connectivité évidents entre les instances et la SVM et n’est donc pas recommandée. Cela se manifeste souvent par un indicateur jaune de l’état de l’instance dans la SVM pour l’instance VPX en question et par l’impossibilité d’utiliser la SVM pour reconfigurer une instance VPX.
-
Si certains VLAN sont liés à des sous-réseaux et d’autres non, lors d’un basculement en haute disponibilité, les paquets GARP ne sont envoyés pour aucune adresse IP sur les sous-réseaux qui ne sont pas liés à un VLAN. Cette configuration peut entraîner des interruptions de connexion et des problèmes de connectivité lors de basculements en haute disponibilité. Ce problème est dû au fait que l’appliance NetScaler ne peut pas notifier la modification des adresses IP de propriété MAC du réseau sur les appliances NetScaler non configurées par VMAC.
Cela se traduit par le fait que pendant ou après un basculement en haute disponibilité, le compteur ip_tot_floating_ip_err s’incrémente sur l’ancienne appliance NetScaler principale pendant plus de quelques secondes, ce qui indique que le réseau n’a pas reçu ni traité de paquets GARP et que le réseau continue de transmettre des données à la nouvelle appliance NetScaler secondaire.