-
Gérer et surveiller à l'aide de Citrix Application Delivery Management
-
Accélération sécurisée du trafic
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Règles de transfert
Par défaut, le propriétaire d’une connexion en mode groupe est défini par un hachage des adresses IP source et destination. Chaque appliance du groupe utilise le même algorithme pour déterminer quel membre du groupe possède une connexion donnée. Cette méthode ne nécessite aucune configuration. Le propriétaire peut éventuellement être spécifié via des règles configurables par l’utilisateur.
Étant donné que le hachage en mode groupe n’est pas identique à celui utilisé par les équilibreurs de charge, environ la moitié du trafic a tendance à être transféré à l’appliance propriétaire dans un groupe à deux appareils. Dans le pire des cas, le transfert entraîne le doublement de la charge sur l’interface côté LAN, ce qui réduit de moitié le taux de transfert maximal de l’appliance pour le trafic WAN réel.
Cette pénalité de vitesse peut être réduite si les ports Ethernet principal ou Aux1 sont utilisés pour le trafic entre les membres du groupe. Par exemple, si vous disposez d’un groupe de deux appliances, vous pouvez utiliser un câble Ethernet pour connecter les ports principaux des deux unités, puis spécifier le port principal sur la page Mode groupe de chaque unité. Toutefois, les performances maximales sont atteintes si la quantité de trafic transférée entre les membres du mode groupe est réduite au minimum.
Le propriétaire peut éventuellement être défini selon des règles IP/port spécifiques. Ces règles doivent être identiques sur toutes les appliances du groupe. Chaque membre du groupe vérifie que sa configuration en mode groupe est identique aux autres. Si toutes les configurations ne sont pas identiques, aucune des appliances membres n’entre en mode groupe.
Si le trafic arrive en premier sur l’appliance propriétaire de la connexion, il est accéléré et transmis normalement. S’il arrive d’abord à une autre appliance du groupe, il est transmis à son propriétaire via un tunnel GRE, ce qui l’accélère et la renvoie à l’appliance d’origine pour qu’elle soit transférée. Ainsi, le mode groupe laisse la sélection de lien du routeur inchangée.
L’utilisation de règles de transfert explicites basées sur IP peut réduire la quantité de transfert en mode groupe. Ceci est particulièrement utile dans les scénarios de lien primaire/lien de sauvegarde, où chaque lien gère une plage particulière d’adresses IP, mais peut servir de sauvegarde lorsque l’autre lien est en panne.
Figure 1. Sélection de propriétaire basée sur IP
Les règles de transfert peuvent garantir que les membres du groupe traitent uniquement leur trafic « naturel ». Dans de nombreuses installations, où le trafic est généralement acheminé sur sa liaison normale et ne traverse que rarement l’autre, ces règles peuvent réduire considérablement les frais généraux.
Les règles sont évaluées dans l’ordre, de haut en bas, et la première règle de correspondance est utilisée. Les règles sont mises en correspondance par rapport à une paire optionnelle d’adresse IP/masque (comparée aux adresses source et de destination) et par rapport à une plage de ports facultative.
Quel que soit l’ordre des règles, si l’appliance partenaire n’est pas disponible, le trafic n’y est pas transféré, qu’une règle corresponde ou non.
Par exemple, dans la figure ci-dessous, le membre 172.16.1.102 est le propriétaire de tout le trafic vers ou depuis son propre sous-réseau (172.16.1.0/24), tandis que le membre 172.16.0.184 est le propriétaire de tout autre trafic.
Si un paquet arrive à l’unité 172.16.1.102 et qu’il n’est pas adressé vers/depuis net 172.16.1.0/24, il est transmis à 172.16.0.184.
Toutefois, si l’unité 172.16.0.184 échoue, l’unité 172.16.1.102 ne transmet plus les paquets. Il tente de gérer le trafic lui-même. Ce comportement peut être inhibé en cliquant sur Ne pas accélérer lorsque l’échec du membre est détecté dans l’onglet Mode de groupe.
Dans une configuration avec une liaison WAN principale et une liaison WAN de sauvegarde, écrivez les règles de transfert pour envoyer tout le trafic vers l’appliance sur la liaison principale. Si la liaison WAN principale échoue, mais que l’appliance principale ne le fait pas, le routeur WAN échoue et envoie du trafic sur la liaison secondaire. L’appliance sur la liaison secondaire transfère le trafic vers la solution matérielle-liaison principale, et l’accélération se poursuit sans perturbations. Cette configuration maintient les connexions accélérées après le basculement de liaison.
Figure 2. Règles de transfert
Partager
Partager
Dans cet article
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.