|
|||||||
|
|||||||
|
|
Champ
|
Description
|
|
Adresse IP
|
Saisissez une nouvelle adresse IP virtuelle qui sera le point d'entrée cible pour accéder au serveur réel. Cette adresse IP est celle vers laquelle les utilisateurs ou les applications se dirigeront pour accéder à l'application équilibrée en termes de charge.
|
|
Masque de sous-réseau/Préfixe
|
Ce champ est réservé au masque de sous-réseau correspondant au réseau sur lequel se trouve le CDA.
|
|
Port
|
Le port d'entrée utilisé pour accéder au VIP. Cette valeur ne doit pas nécessairement être la même que celle du serveur réel si vous utilisez un proxy inverse.
|
|
Nom du service
|
Le nom du service est une représentation textuelle de l'objectif du PIV. Il est facultatif, mais nous vous recommandons de le fournir pour plus de clarté.
|
|
Type de service
|
Il existe de nombreux types de services différents que vous pouvez sélectionner. Les types de service de la couche 4 ne peuvent pas utiliser la technologie FlightPATH.
|
|
Champ
|
Description
|
|
Activité
|
Le champ Activité peut être utilisé pour afficher et modifier l'état du serveur réel équilibré en charge.
En ligne - Indique que le serveur est actif et qu'il reçoit des demandes d'équilibrage de la charge.
Hors ligne - Le serveur est hors ligne et ne reçoit pas de demandes.
Drain - Le serveur a été placé en mode drain pour que la persistance puisse être vidée et que le serveur passe à un état hors ligne sans affecter les utilisateurs.
Standby - Le serveur a été placé dans un état de veille.
|
|
Adresse IP
|
Cette valeur est l'adresse IP du serveur réel. Elle doit être exacte et ne doit pas être une adresse DHCP.
|
|
Port
|
Le port cible d'accès sur le serveur réel. En cas d'utilisation d'un proxy inverse, ce port peut être différent du port d'entrée spécifié sur le VIP.
|
|
Pondération
|
Ce paramètre est généralement configuré automatiquement par l'ADC. Vous pouvez le modifier si vous souhaitez changer la pondération des priorités.
|
|
Option
|
Description
|
|
Cluster
|
Cluster est le rôle par défaut de l'ADC lors de l'installation, et la colonne Primary/Mode indique le mode dans lequel il fonctionne actuellement. Lorsque vous avez une paire d'appareils ADC HA dans votre centre de données, l'un d'entre eux sera affiché comme actif et l'autre passif.
|
|
Manuel
|
Le rôle manuel permet à la paire de CDA de fonctionner en mode actif-actif pour différentes adresses IP virtuelles. Dans ce cas, la colonne Primary contient une case à côté de chaque adresse IP virtuelle unique qui peut être cochée pour Active ou non cochée pour Passive.
|
|
Stand-Alone
|
L'ADC agit comme un dispositif autonome et n'est pas en mode haute disponibilité. En tant que tel, la colonne Primary indiquera Stand-alone.
|
|
LED
|
Signification
|
|
l
|
En ligne
|
|
l
|
Failover-Standby. Ce service virtuel est en attente à chaud
|
|
l
|
Indique qu'un "secondaire" attend un "primaire".
|
|
l
|
Service Needs attention. Cette indication peut être due au fait qu'un serveur réel a échoué à un contrôle de santé ou qu'il a été mis manuellement hors ligne. Le trafic continuera à circuler mais avec une capacité réduite du serveur réel.
|
|
l
|
Hors ligne. Les serveurs de contenu sont inaccessibles, ou aucun serveur de contenu n'est activé.
|
|
l
|
Statut de la recherche
|
|
l
|
Pas de licence ou des IP virtuelles sous licence dépassées
|
|
Type de service
|
Port/Protocole
|
Couche de service
|
Commentaire
|
|
Couche 4 TCP
|
Tout port TCP
|
Couche 4
|
L'ADC ne modifiera aucune information dans le flux de données et effectuera un équilibrage de charge standard du trafic conformément à la politique d'équilibrage de charge.
|
|
Couche 4 UDP
|
Tout port UDP
|
Couche 4
|
Comme pour le TCP de la couche 4, l'ADC ne modifiera aucune information dans le flux de données et effectuera un équilibrage de charge standard du trafic selon la politique d'équilibrage de charge.
|
|
Couche 4 TCP/UDP
|
Tout port TCP ou UDP
|
Couche 4
|
C'est l'idéal si votre service a un protocole primaire tel que UDP mais qu'il se rabat sur TCP. L'ADC ne modifiera aucune information dans le flux de données et effectuera un équilibrage de charge standard du trafic conformément à la politique d'équilibrage de charge.
|
|
DNS
|
TCP/UDP
|
Couche 4
|
Utilisé pour équilibrer la charge des serveurs DNS.
|
|
HTTP
|
Protocole HTTP ou HTTPS
|
Couche 7
|
Le CDA peut interagir, manipuler et modifier le flux de données à l'aide de flightPATH.
|
|
FTP
|
Protocole de transfert de fichiers
|
Couche 7
|
Utilisation de connexions de contrôle et de données distinctes entre le client et le serveur
|
|
SMTP
|
Protocole de transfert de courrier simple
|
Couche 4
|
À utiliser lors de l'équilibrage de la charge des serveurs de messagerie
|
|
POP3
|
Protocole de la poste
|
Couche 4
|
À utiliser lors de l'équilibrage de la charge des serveurs de messagerie
|
|
IMAP
|
Protocole d'accès aux messages Internet
|
Couche 4
|
À utiliser lors de l'équilibrage de la charge des serveurs de messagerie
|
|
RDP
|
Protocole de bureau à distance
|
Couche 4
|
À utiliser lors de l'équilibrage de la charge des serveurs Terminal Services
|
|
RPC
|
Appel de procédure à distance
|
Couche 4
|
À utiliser lors de l'équilibrage de la charge des systèmes utilisant des appels RPC.
|
|
RPC/ADS
|
Exchange 2010 RPC statique pour le service Carnet d'adresses
|
Couche 4
|
A utiliser lors de l'équilibrage de charge des serveurs Exchange
|
|
RPC/CA/PF
|
Exchange 2010 RPC statique pour l'accès client et les dossiers publics
|
Couche 4
|
A utiliser lors de l'équilibrage de charge des serveurs Exchange
|
|
DICOM
|
Imagerie numérique et communications en médecine
|
Couche 4
|
À utiliser lors de l'équilibrage de la charge des serveurs utilisant les protocoles DICOM.
|
|
LED
|
Signification
|
|
l
|
Connecté
|
|
£
|
Non surveillé
|
|
l
|
Drainage
|
|
l
|
Hors ligne
|
|
l
|
Standby
|
|
l
|
Non connecté
|
|
l
|
État des constatations
|
|
l
|
Serveurs réels non licenciés ou licenciés dépassés
|
|
Option
|
Description
|
|
En ligne
|
Tous les serveurs réels assignés en ligne recevront du trafic selon la politique d'équilibrage de charge définie dans l'onglet Basic.
|
|
Drainage
|
Tous les serveurs réels affectés au drainage continueront à servir les connexions existantes mais n'accepteront pas de nouvelles connexions. Le voyant d'état clignote en vert/bleu pendant la durée de la purge. Une fois que les connexions existantes sont naturellement fermées, les serveurs réels sont mis hors ligne et le voyant d'état est bleu fixe. Vous pouvez également visualiser ces connexions en accédant à la section Navigation > Monitor > Status.
|
|
Hors ligne
|
Tous les serveurs réels définis comme hors ligne seront immédiatement mis hors ligne et ne recevront aucun trafic.
|
|
Standby
|
Tous les serveurs réels définis comme étant en attente resteront hors ligne jusqu'à ce que TOUS les serveurs du groupe en ligne échouent dans leurs vérifications du Server Health Monitor. Le trafic est reçu par le groupe Standby conformément à la politique d'équilibrage de charge lorsque cela se produit. Si l'un des serveurs du groupe en ligne passe le contrôle de santé du serveur, ce serveur en ligne recevra tout le trafic, et le groupe en attente cessera de recevoir du trafic.
|
|
Option
|
Description
|
|
Le plus rapide
|
La politique d'équilibrage de charge la plus rapide calcule automatiquement le temps de réponse de toutes les demandes par serveur, lissé dans le temps. La colonne Poids calculé contient la valeur calculée automatiquement. La saisie manuelle n'est possible qu'en utilisant cette politique d'équilibrage de charge.
|
|
Round Robin
|
La méthode Round Robin, couramment utilisée dans les pare-feu et les équilibreurs de charge de base, est la plus simple. Chaque serveur réel reçoit une nouvelle demande dans l'ordre. Cette méthode n'est appropriée que lorsque vous devez équilibrer la charge des demandes vers les serveurs de manière uniforme ; un exemple serait les serveurs Web de recherche. Cependant, lorsque vous devez équilibrer la charge en fonction de la charge de l'application ou du serveur, ou même vous assurer que vous utilisez le même serveur pour la session, la méthode Round Robin est inappropriée.
|
|
Le moins de connexions
|
L'équilibreur de charge garde la trace du nombre de connexions actuelles à chaque serveur réel. Le serveur réel ayant le moins de connexions reçoit la nouvelle demande suivante.
|
|
IP Bound
Affinité/Persistance des sessions de la couche 3
|
Dans ce mode, l'adresse IP du client sert de base pour sélectionner le serveur réel qui recevra la demande. Cette action assure la persistance. Les protocoles HTTP et de couche 4 peuvent utiliser ce mode. Cette méthode est utile pour les réseaux internes dont la topologie est connue, et vous pouvez être sûr qu'il n'y a pas de "super proxies" en amont. Avec la couche 4 et les proxies, toutes les requêtes peuvent sembler provenir d'un seul client et, de ce fait, la charge n'est pas uniforme. Avec HTTP, l'information de l'en-tête (X-Forwarder-For) est utilisée lorsqu'elle est présente pour faire face aux proxies.
|
|
Basé sur la liste d'IP
Affinité/Persistance des sessions de la couche 3
|
La connexion au serveur réel s'initie en utilisant "Least connections" puis, l'affinité de session est réalisée sur la base de l'adresse IP du client. Une liste est maintenue pendant 2 heures par défaut, mais cela peut être modifié en utilisant un jetPACK.
|
|
Cookie de session
Affinité/Persistance des sessions de la couche 7
|
Ce mode est la méthode de persistance la plus populaire pour l'équilibrage de charge HTTP. Dans ce mode, l'ADC utilise l'équilibrage de charge basé sur la liste d'IP pour chaque première demande. Il insère un cookie dans les en-têtes de la première réponse HTTP. Ensuite, l'ADC utilise le cookie du client pour acheminer le trafic vers le même serveur dorsal. Ce cookie est utilisé pour la persistance lorsque le client doit se rendre chaque fois sur le même serveur dorsal. Le cookie expire lorsque la session est fermée.
|
|
Cookie persistant
Affinité/Persistance des sessions de la couche 7
|
Le mode d'équilibrage de charge basé sur la liste d'IP est utilisé pour chaque première demande. L'ADC insère un cookie dans les en-têtes de la première réponse HTTP. Ensuite, l'ADC utilise le cookie du client pour acheminer le trafic vers le même serveur back-end. Ce cookie est utilisé pour la persistance lorsque le client doit se rendre chaque fois sur le même serveur dorsal. Le cookie expire au bout de 2 heures, et la connexion est équilibrée en fonction d'un algorithme basé sur une liste d'adresses IP. Ce délai d'expiration est configurable à l'aide d'un jetPACK.
|
|
Cookie de session - Cookie de session ASP classique
|
Active Server Pages (ASP) est une technologie Microsoft côté serveur. Si cette option est sélectionnée, le CDA maintient la persistance de la session sur le même serveur si un cookie ASP est détecté et trouvé dans sa liste de cookies connus. Lors de la détection d'un nouveau cookie ASP, la charge sera équilibrée à l'aide de l'algorithme Least Connections.
|
|
Cookie de session - Cookie de session ASP.NET
|
Ce mode s'applique à ASP.net. Lorsque ce mode est sélectionné, le CDA maintient la persistance de la session sur le même serveur si un cookie ASP.NET est détecté et trouvé dans sa liste de cookies connus. Lors de la détection d'un nouveau cookie ASP, la charge sera équilibrée à l'aide de l'algorithme Least Connections.
|
|
Cookie de session - Cookie de session JSP
|
Java Server Pages (JSP) est une technologie Oracle côté serveur. Lorsque ce mode est sélectionné, l'ADC maintient la persistance de la session sur le même serveur si un cookie JSP est détecté et trouvé dans sa liste de cookies connus. Lors de la détection d'un nouveau cookie JSP, la charge sera équilibrée à l'aide de l'algorithme Least Connections.
|
|
Cookie de session - Cookie de session JAX-WS
|
Java web services (JAX-WS) est une technologie Oracle côté serveur. Lorsque ce mode est sélectionné, le CDA maintient la persistance de la session sur le même serveur si un cookie JAX-WS est détecté et trouvé dans sa liste de cookies connus. Lors de la détection d'un nouveau cookie JAX-WS, il équilibrera la charge à l'aide de l'algorithme Least Connections.
|
|
Cookie de session - Cookie de session PHP
|
Personal Home Page (PHP) est une technologie open-source côté serveur. Lorsque ce mode est sélectionné, le CDA maintient la persistance de la session sur le même serveur lorsqu'un cookie PHP est détecté.
|
|
Cookie de session - Persistance du cookie RDP
|
Cette méthode d'équilibrage de la charge utilise le cookie RDP créé par Microsoft et basé sur le nom d'utilisateur/domaine pour assurer la persistance de la connexion à un serveur. L'avantage de cette méthode est que le maintien d'une connexion à un serveur est possible même si l'adresse IP du client change.
|
|
Basé sur le Cookie-ID
|
Une nouvelle méthode très semblable à "PhpCookieBased" et aux autres méthodes d'équilibrage de charge, mais utilisant CookieIDBased et le cookie RegEx h=[^ ;]+.
Cette méthode utilisera la valeur définie dans le champ notes du serveur réel "ID=X ;" comme valeur de cookie pour identifier le serveur. Cela signifie donc qu'il s'agit d'une méthode similaire à CookieListBased, mais qu'elle utilise un nom de cookie différent et stocke une valeur de cookie unique, non pas l'IP brouillée, mais l'ID du serveur réel (lu au moment du chargement).
La valeur par défaut est CookieIDName="h" ; toutefois, s'il existe une valeur prioritaire dans la configuration des paramètres avancés du serveur virtuel, utilisez-la à la place. NOTE : Nous écrasons l'expression du cookie ci-dessus pour remplacer h= par la nouvelle valeur si cette valeur est définie.
Le dernier point est que si une valeur de cookie inconnue arrive et correspond à l'un des ID de serveur réel, il faut sélectionner ce serveur ; sinon, il faut utiliser la méthode suivante (déléguer.)
|
|
Basé sur la liste des IP partagées
|
Ce type de service n'est disponible que lorsque le mode de connectivité est défini sur Passerelle ou Retour direct au serveur. Il a été principalement ajouté pour la prise en charge de l'équilibrage de charge VMware.
|
|
Option
|
Description
|
|
Aucun
|
Dans ce mode, le serveur réel n'est pas surveillé et fonctionne toujours correctement. Le paramètre Aucun est utile dans les situations où la surveillance perturbe un serveur et pour les services qui ne doivent pas participer à l'action de basculement de l'ADC. Il s'agit d'une voie pour héberger des systèmes non fiables ou anciens qui ne sont pas essentiels aux opérations H/A. Utilisez cette méthode de surveillance avec n'importe quel type de service.
|
|
Ping/ICMP Echo
|
Dans ce mode, l'ADC envoie une demande d'écho ICMP à l'IP du serveur de contenu. Si une réponse d'écho valide est reçue, l'ADC considère que le serveur réel est opérationnel et le trafic vers le serveur continue. Il maintient également le service disponible sur une paire H/A. Cette méthode de surveillance est utilisable avec n'importe quel type de service.
|
|
Connexion TCP
|
Une connexion TCP est établie avec le serveur réel et immédiatement interrompue sans envoyer de données dans ce mode. Si la connexion réussit, le CDA considère que le serveur réel est opérationnel. Cette méthode de surveillance est utilisable avec tout type de service, et les services UDP ne sont actuellement pas appropriés pour la surveillance des connexions TCP.
|
|
ICMP non atteignable
|
L'ADC enverra un contrôle de santé UDP au serveur et marquera le serveur réel comme indisponible s'il reçoit un message ICMP port unreachable. Cette méthode peut être utile lorsque vous devez vérifier si un port de service UDP est disponible sur un serveur, comme le port DNS 53.
|
|
RDP
|
Dans ce mode, une connexion TCP s'initialise comme expliqué dans la méthode ICMP Unreachable. Après l'initialisation de la connexion, une connexion RDP de couche 7 est demandée. Si la liaison est confirmée, l'ADC considère que le serveur réel est opérationnel. Cette méthode de surveillance est utilisable avec n'importe quel serveur terminal Microsoft.
|
|
200 OK
|
Dans cette méthode, une connexion TCP s'initialise avec le serveur réel. Une fois la connexion établie, le CDA envoie une demande HTTP au serveur réel. Une réponse HTTP est attendue et le code de réponse "200 OK" est vérifié. Le CDA considère que le serveur réel est opérationnel si le code de réponse "200 OK" est reçu. Si l'ADC ne reçoit pas un code de réponse "200 OK" pour une raison quelconque, y compris les délais d'attente, l'échec de la connexion et d'autres raisons, l'ADC marque le serveur réel comme étant indisponible. Cette méthode de surveillance est uniquement valable pour une utilisation avec les types de service HTTP et HTTP accéléré. Si un type de service de couche 4 est utilisé pour un serveur HTTP, il est utilisable si SSL n'est pas utilisé sur le serveur réel ou s'il n'est pas géré de manière appropriée par la fonction "Content SSL".
|
|
DICOM
|
Une connexion TCP s'initialise avec le serveur réel en mode DICOM, et une "demande d'association" Echoscu est envoyée au serveur réel lors de la connexion. Une conversation comprenant un "Associate Accept" du serveur de contenu, un transfert d'une petite quantité de données suivi d'un "Release Request", puis d'un "Release Response" conclut le moniteur avec succès. Si le moniteur ne se termine pas avec succès, le serveur réel est considéré comme hors service pour une raison quelconque.
|
|
Défini par l'utilisateur
|
Tout moniteur configuré dans la section Surveillance du serveur réel apparaîtra dans la liste.
|
|
Option
|
Description
|
|
Par l'hôte
|
La mise en cache par hôte est basée sur l'application par nom d'hôte. Un cache distinct existera pour chaque domaine/nom d'hôte. Ce mode est idéal pour les serveurs web qui peuvent servir plusieurs sites web en fonction du domaine.
|
|
Par Service Virtuel
|
La mise en cache par service virtuel est disponible lorsque vous choisissez cette option. Un seul cache existera pour tous les domaines/noms d'hôtes qui passent par le service virtuel. Cette option est un paramètre spécialisé à utiliser avec plusieurs clones d'un même site.
|
|
Option
|
Description
|
|
Off
|
Désactiver la compression pour le service virtuel
|
|
Compression
|
Lorsqu'elle est sélectionnée, cette option active la compression pour le service virtuel sélectionné. Le CDA compresse dynamiquement le flux de données vers le client sur demande. Ce processus s'applique uniquement aux objets qui contiennent l'en-tête content-encoding : gzip. Les exemples de contenu incluent HTML, CSS ou Javascript. Vous pouvez également exclure certains types de contenu à l'aide de la section Exclusions globales.
|
|
Option
|
Description
|
|
Pas de SSL
|
Le trafic de la source vers le CDA n'est pas crypté.
|
|
Tous
|
Charge tous les certificats disponibles pour l'utilisation
|
|
Défaut
|
Cette option a pour effet d'appliquer un certificat créé localement, appelé "Default", au côté navigateur du canal. Utilisez cette option pour tester le SSL lorsqu'il n'a pas été créé ou importé.
|
|
AnyUseCert
|
Utilisez tout certificat présent sur le CDA que l'utilisateur a téléchargé ou généré.
|
|
Option
|
Description
|
|
Pas de SSL
|
Le trafic entre le CDA et le serveur réel n'est pas crypté. La sélection d'un certificat du côté du navigateur signifie que "No SSL" peut être choisi du côté du client pour fournir ce qui est connu comme "SSL Offload".
|
|
Tout
|
L'ADC agit comme un client et accepte tout certificat présenté par le serveur réel. Le trafic entre l'ADC et le serveur réel est crypté lorsque cette option est sélectionnée. Utilisez l'option "Any" lorsqu'un certificat est spécifié du côté du service virtuel, fournissant ce que l'on appelle un "pontage SSL" ou un "re-cryptage SSL".
|
|
SNI
|
L'ADC agit comme un client et accepte tout certificat présenté par le serveur réel. Le trafic entre l'ADC et le serveur réel est crypté si cette option est sélectionnée. Utilisez l'option "Any" lorsqu'un certificat est spécifié du côté du service virtuel, fournissant ce que l'on appelle un "pontage SSL" ou un "re-cryptage SSL". Choisissez cette option pour activer SNI du côté du serveur.
|
|
AnyUseCert
|
Tous les certificats que vous avez générés ou importés dans le CDA apparaissent ici.
|
|
Option
|
Description
|
|
Proxy inversé
|
Reverse Proxy est la valeur par défaut et fonctionne au niveau de la couche 7 avec compression et mise en cache. Et au niveau de la couche 4 sans mise en cache ni compression. Dans ce mode, votre ADC agit comme un proxy inverse et devient l'adresse source vue par les serveurs réels.
|
|
Retour direct du serveur
|
Le Direct Server Return ou DSR (DR - Direct Routing dans certains milieux) permet au serveur situé derrière l'équilibreur de charge de répondre directement au client en contournant l'ADC de la réponse. Le DSR ne peut être utilisé qu'avec l'équilibrage de charge de couche 4. Par conséquent, la mise en cache et la compression ne sont pas disponibles avec cette option choisie.
Ce mode ne peut être utilisé qu'avec les types de service TCP, UDP et TCP/UDP.
L'équilibrage de charge de la couche 7 ne fonctionne pas avec ce DSR. De plus, il n'y a pas de support de persistance autre que celui basé sur la liste d'IP. L'équilibrage de charge SSL/TLS avec cette méthode n'est pas idéal car le support de la persistance de l'IP source est le seul type disponible. Le DSR exige également que des modifications soient apportées au serveur réel. Veuillez vous reporter à la section Modifications du serveur réel.
|
|
Passerelle
|
Le mode passerelle vous permet d'acheminer tout le trafic par l'ADC, ce qui permet aux serveurs réels d'être acheminés par l'ADC vers d'autres réseaux via les machines virtuelles ou les interfaces matérielles de l'ADC. L'utilisation de l'appareil en tant que dispositif de passerelle pour les serveurs réels est idéale en cas de fonctionnement en mode multi-interface.
L'équilibrage de charge de couche 7 avec cette méthode ne fonctionne pas car il n'y a pas de support de persistance autre que celui basé sur la liste IP. Cette méthode exige que le serveur réel définisse sa passerelle par défaut à l'adresse de l'interface locale de l'ADC (eth0, eth1, etc.). Veuillez vous référer à la section Modifications du serveur réel.
Veuillez noter que le mode Gateway ne prend pas en charge le basculement dans un environnement de cluster.
|
