EdgeADC Build 4.2.10
Guide d'administration du EdgeADC
×

Services IP

La section Services IP de l'ADC vous permet d'ajouter, de supprimer et de configurer les différents services IP virtuels dont vous avez besoin pour votre cas d'utilisation particulier. Les paramètres et les options sont regroupés dans les sections ci-dessous. Ces sections se trouvent sur le côté droit de l'écran de l'application.
Services virtuels
Un service virtuel combine une IP virtuelle (VIP) et un port TCP/UDP sur lequel le CDA écoute. Le trafic arrivant à l'IP du service virtuel est redirigé vers l'un des serveurs réels associés à ce service. L'adresse IP du Service Virtuel ne peut pas être la même que l'adresse de gestion de l'ADC. i.e. eth0, eth1 etc...
L'ADC détermine comment le trafic est redistribué aux serveurs en fonction d'une politique d'équilibrage de charge définie dans l'onglet Basic de la section Real Servers.
Créer un nouveau service virtuel en utilisant un nouveau VIP
·     Cliquez sur le bouton Ajouter un service virtuel comme indiqué ci-dessus.
·     Vous entrerez alors dans le mode de modification de la ligne.
·     Remplissez les quatre champs mis en évidence pour continuer, puis cliquez sur le bouton de mise à jour.
Veuillez utiliser la touche TAB pour naviguer dans les champs.
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. C'est vers cette adresse IP que les utilisateurs ou les applications se tourneront 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.
 
 
Vous pouvez maintenant appuyer sur le bouton "Update" pour sauvegarder cette section et passer automatiquement à la section "Real Server" détaillée ci-dessous :
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.
Cliquez sur le bouton "Update" ou appuyez sur "Enter" pour enregistrer vos modifications.
·     Le voyant d'état devient d'abord gris, puis vert si le contrôle de santé du serveur réussit. Il devient rouge si le Real Server Monitor échoue.
·     Un serveur dont le voyant d'état est rouge ne sera pas équilibré en termes de charge.
Exemple d'un service virtuel terminé
Créer un nouveau service virtuel en utilisant un VIP existant
·     Mettez en surbrillance un service virtuel que vous souhaitez copier
·     Cliquez sur Add Virtual Service pour entrer dans le mode d'édition de la rangée
·     L'adresse IP et le masque de sous-réseau sont copiés automatiquement.
·     Entrez le numéro de port de votre service
·     Saisissez un nom de service facultatif
·     Sélectionnez un type de service
·     Vous pouvez maintenant appuyer sur le bouton "Update" pour sauvegarder cette section et passer automatiquement à la section "Real Server" ci-dessous.
·     Laissez l'option Activité du serveur en ligne, ce qui signifie qu'il sera équilibré en charge s'il passe le contrôle de santé par défaut de TCP Connect. Ce paramètre peut être modifié ultérieurement si nécessaire.
·     Entrez une adresse IP du serveur réel
·     Entrez un numéro de port pour le serveur réel
·     Saisissez un nom facultatif pour le serveur réel
·     Cliquez sur Mettre à jour pour enregistrer vos modifications
·     Le voyant d'état devient d'abord gris, puis vert si le contrôle de santé du serveur réussit. Il devient rouge si le Real Server Monitor échoue.
·     Un serveur dont le voyant d'état est rouge ne sera pas équilibré en termes de charge.
Changement de l'adresse IP d'un service virtuel
Vous pouvez modifier l'adresse IP d'un service virtuel ou d'un VIP existant à tout moment.
·     Mettez en surbrillance le service virtuel dont vous souhaitez modifier l'adresse IP.
·     Double-cliquez sur le champ de l'adresse IP de ce service
·     Changez l'adresse IP pour celle que vous souhaitez utiliser.
·     Cliquez sur le bouton Mettre à jour pour enregistrer les modifications.
Remarque : La modification de l'adresse IP d'un service virtuel entraîne la modification de l'adresse IP de tous les services associés au VIP.
Création d'un nouveau service virtuel à l'aide de Copy Service
·     Le bouton Copier le service permet de copier un service entier, y compris tous les serveurs réels, les paramètres de base, les paramètres avancés et les règles du chemin de vol qui lui sont associés.
·     Mettez en surbrillance le service que vous souhaitez dupliquer et cliquez sur "Copier le service".
·     L'éditeur de ligne apparaît avec un curseur clignotant sur la colonne Adresse IP.
·     Vous devez modifier l'adresse IP pour qu'elle soit unique, ou si vous souhaitez conserver l'adresse IP, vous devez modifier le port pour qu'il soit unique à cette adresse IP.
N'oubliez pas de modifier chaque onglet si vous changez un paramètre tel qu'une politique d'équilibrage de charge, le moniteur Real Server ou si vous supprimez une règle flightPATH.
Filtrage des données affichées
Recherche d'un terme spécifique
La boîte de recherche vous permet d'effectuer une recherche dans la table en utilisant n'importe quelle valeur, comme les octets de l'adresse IP ou le nom du service.
L'exemple ci-dessus montre le résultat de la recherche d'une adresse IP spécifique de 10.4.8.191.
Sélection de la visibilité des colonnes
Vous pouvez également sélectionner les colonnes que vous souhaitez afficher dans le tableau de bord.
·     Déplacez la souris sur l'une des colonnes
·     Vous verrez apparaître une petite flèche sur le côté droit de la colonne.
·     En cliquant sur les cases à cocher, vous sélectionnez les colonnes que vous souhaitez voir apparaître dans le tableau de bord.
Comprendre les colonnes de services virtuels
Primaire/Mode
La colonne Primary/Mode indique le rôle de haute disponibilité sélectionné pour le VIP actuel. Utilisez les options disponibles dans Système > Clustering pour configurer cette option.
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.
VIP
Cette colonne fournit un retour visuel sur l'état de chaque service virtuel. Les indicateurs sont codés par couleur et sont les suivants :
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
Activé
La valeur par défaut de cette option est Activé, et la case à cocher est cochée. Vous pouvez désactiver le service virtuel en double-cliquant sur la ligne, en décochant la case, puis en cliquant sur le bouton Actualiser.
Adresse IP
Ajoutez votre adresse IPv4 en notation décimale pointée ou une adresse IPv6. Cette valeur est l'adresse IP virtuelle (VIP) de votre service. Exemple IPv4 "192.168.1.100". Exemple Ipv6 "2001:0db8:85a3:0000:0000:8a2e:0370:7334"
Masque de sous-réseau/Préfixe
Ajoutez votre masque de sous-réseau en notation décimale pointée. Exemple "255.255.255.0". Ou pour IPv6, ajoutez votre préfixe. Pour plus d'informations sur IPv6, veuillez consulter HTTPs://en.wikipedia.org/wiki/IPv6_address
Port
Ajoutez le numéro de port associé à votre service. Le port peut être un numéro de port TCP ou UDP. Exemple TCP "80" pour le trafic Web et TCP "443" pour le trafic Web sécurisé.
Nom du service
Ajoutez un nom convivial pour identifier votre service. Exemple : "Serveurs Web de production".
Type de service
Veuillez noter qu'avec tous les types de services de "couche 4", le CDA n'interagit pas avec le flux de données et ne le modifie pas. flightPATH n'est donc pas disponible avec les types de services de couche 4. Les services de couche 4 équilibrent simplement le trafic en fonction de la politique d'équilibrage de la charge :
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 selon 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.
Serveurs réels
Il y a plusieurs onglets dans la section Real Servers du tableau de bord : Server, Basic, Advanced et flightPATH.
Serveur
L'onglet Serveur contient les définitions des serveurs dorsaux réels associés au service virtuel actuellement sélectionné. Vous devez ajouter au moins un serveur dans la section Real Servers.
Ajouter un serveur
·     Sélectionnez le VIP approprié que vous avez précédemment défini.
·     Cliquez sur Ajouter un serveur
·     Une nouvelle ligne apparaît avec le curseur clignotant dans la colonne Adresse IP.
·     Saisissez l'adresse IPv4 de votre serveur en notation décimale pointillée. Le serveur réel peut se trouver sur le même réseau que votre service virtuel, sur tout réseau local directement attaché ou sur tout réseau que votre CDA peut acheminer. Exemple "10.1.1.1".
·     Passez à la colonne Port et saisissez le numéro de port TCP/UDP de votre serveur. Ce numéro de port peut être le même que celui du service virtuel ou un autre numéro de port pour la connectivité par proxy inverse. Le CDA effectuera automatiquement la conversion vers ce numéro.
·     Passez à la section Notes pour ajouter tout détail pertinent concernant le serveur. Exemple : "IIS Web Server 1"
Nom du groupe
Lorsque vous avez ajouté les serveurs qui composent l'ensemble équilibré en charge, vous pouvez également leur attribuer un nom de groupe. Une fois que vous avez modifié ce champ, le contenu est enregistré sans qu'il soit nécessaire d'appuyer sur le bouton Update.
Voyants d'état du serveur réel
Vous pouvez voir l'état d'un serveur réel par la couleur claire dans la colonne État. Voir ci-dessous :
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
Activité
Vous pouvez modifier l'activité d'un serveur réel à tout moment en utilisant le menu déroulant. Pour ce faire, double-cliquez sur une ligne de serveur réel pour la placer en mode édition.
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.
Adresse IP
Ce champ est l'adresse IP de votre serveur réel. Exemple "192.168.1.200".
Port
Numéro du port TCP ou UDP sur lequel le serveur Real écoute le service. Exemple "80" pour le trafic Web.
Poids
Cette colonne devient éditable lorsqu'une politique d'équilibrage de charge appropriée est spécifiée.
 Le poids par défaut d'un serveur réel est de 100, et vous pouvez entrer des valeurs de 1 à 100. Une valeur de 100 signifie une charge maximale, et 1 signifie une charge minimale.
Un exemple pour trois serveurs peut ressembler à ceci :
·     Serveur 1 Poids = 100
·     Serveur 2 Poids = 50
·     Serveur 3 Poids = 50
Si l'on considère que la politique d'équilibrage de la charge est définie sur le principe des moindres connexions, et qu'il y a 200 connexions clients au total ;
·     Le serveur 1 recevra 100 connexions simultanées
·     Le serveur 2 recevra 50 connexions simultanées
·     Le serveur 3 recevra 50 connexions simultanées
Si nous devions utiliser le Round Robin comme méthode d'équilibrage de la charge, qui fait tourner les demandes à travers l'ensemble des serveurs équilibrés, la modification des pondérations affecte la fréquence à laquelle les serveurs sont choisis comme cible.
Si nous pensons que la politique d'équilibrage de charge la plus rapide utilise le temps le plus court pour obtenir une réponse, l'ajustement des poids modifie le biais de la même manière que pour les Connexions les plus faibles.
Poids calculé
Le poids calculé de chaque serveur peut être visualisé dynamiquement. Il est calculé automatiquement et n'est pas modifiable. Ce champ indique la pondération réelle que le CDA utilise en tenant compte de la pondération manuelle et de la politique d'équilibrage de la charge.
Notes
Saisissez dans le champ Notes toute note particulière utile à la description de l'entrée définie. Exemple : "IIS Server1 - London DC".
ID
Le champ ID est utilisé dans le cadre de la politique d'équilibrage des charges des cookies. Le numéro d'identification placé ici est utilisé pour identifier
Base
Politique d'équilibrage des charges
La liste déroulante vous indique les politiques d'équilibrage de charge actuellement prises en charge et disponibles. Une liste des politiques d'équilibrage de charge, accompagnée d'une explication, est présentée ci-dessous.
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 en utilisant l'algorithme des moindres connexions.
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 vers 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'adresse 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 une liste d'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.
Surveillance des serveurs
Votre ADC contient six méthodes standard de surveillance du serveur réel, énumérées ci-dessous.
Choisissez la méthode de surveillance que vous souhaitez appliquer au service virtuel (VIP).
Il est essentiel de choisir le bon moniteur pour le service. Par exemple, si le serveur réel est un serveur RDP, un moniteur 200OK n'est pas pertinent. Si vous n'êtes pas sûr du moniteur à choisir, la connexion TCP par défaut est un excellent point de départ.
Vous pouvez choisir plusieurs moniteurs en cliquant tour à tour sur chaque moniteur que vous souhaitez appliquer au service. Les moniteurs sélectionnés s'exécutent dans l'ordre dans lequel vous les avez sélectionnés ; commencez donc par les moniteurs des couches inférieures. Par exemple, la définition des moniteurs Ping/ICMP Echo, Connexion TCP et 200OK s'affichera dans les événements du tableau de bord comme l'image ci-dessous :
Nous pouvons voir que la couche 3 Ping et la couche 4 TCP Connect ont réussi si nous regardons la ligne supérieure, mais que la couche 7 200OK a échoué. Ces résultats de surveillance fournissent suffisamment d'informations pour indiquer que le routage est correct et qu'un service fonctionne sur le port correspondant, mais le site Web ne répond pas correctement à la page demandée. Il est maintenant temps de regarder le serveur Web et la section Library > Real Server Monitor pour voir les détails du moniteur défaillant.
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 au serveur réel une demande HTTP. 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 de 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 au serveur réel en mode DICOM, et une "demande d'association" Echoscu est faite au serveur réel lors de la connexion. Une conversation comprenant une " Associate Accept " du serveur de contenu, un transfert d'une petite quantité de données suivi d'une " Release Request ", puis d'une " 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.
Stratégie de mise en cache
Par défaut, la stratégie de mise en cache est désactivée et réglée sur Off. Si votre type de service est HTTP, vous pouvez appliquer deux types de stratégie de mise en cache.
Veuillez vous reporter à la page Configurer le cache pour configurer les paramètres détaillés du cache. Notez que lorsque la mise en cache est appliquée à un VIP avec le type de service "HTTP" accéléré, les objets compressés ne sont pas mis en cache.
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.
Accélération
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.
Remarque : Si l'objet peut être mis en cache, le CDA stocke une version compressée et la sert de manière statique (à partir de la mémoire) jusqu'à ce que le contenu expire et soit revalidé.
Certificat SSL de service virtuel (chiffrement entre le client et l'ADC)
Par défaut, le paramètre est No SSL. Si votre type de service est "HTTP" ou "Layer4 TCP", vous pouvez sélectionner un certificat dans la liste déroulante pour l'appliquer au service virtuel. Les certificats qui ont été créés ou importés apparaîtront dans cette liste. Vous pouvez mettre en évidence plusieurs certificats à appliquer à un service. Cette opération activera automatiquement l'extension SNI pour autoriser un certificat basé sur le "Nom de domaine" demandé par le client.
Indication du nom du serveur
Cette option est une extension du protocole de réseau TLS grâce à laquelle le client indique le nom d'hôte auquel il tente de se connecter au début du processus d'établissement de la liaison. Ce paramètre permet au CDA de présenter plusieurs certificats sur la même adresse IP virtuelle et le même port TCP.
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é.
Certificat SSL du serveur réel (cryptage entre l'ADC et le serveur réel)
Le paramètre par défaut de cette option est No SSL. Si votre serveur nécessite une connexion cryptée, cette valeur doit être différente de No SSL. Les certificats qui ont été créés ou importés apparaissent dans cette liste.
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.
Avancé
Connectivité
Votre service virtuel est configurable avec différents types de connectivité. Veuillez sélectionner le mode de connectivité à appliquer au service.
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 nécessite 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 reporter à 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.
Options de chiffrement
Le chiffrement constitue la base de la cryptographie SSL et est extrêmement important pour une diffusion réussie et sécurisée du contenu web et des applications.
Le CDA contient un ensemble intégré de Ciphers par défaut, comprenant les plus récents et les plus sûrs disponibles pour l'utilisation.
Il y a des occasions où l'utilisateur souhaite annoncer la disponibilité d'un ensemble particulier de Ciphers, et l'ADC permet la création de tels Ciphers par le biais de jetPACKS écrits par l'utilisateur. Les jetPACKS écrits par les utilisateurs peuvent être importés dans l'ADC par le biais de Configuration > Software, puis rendus disponibles pour le choix en utilisant le menu Options de Cipher.
Les options de chiffrement sont spécifiques à chaque VIP, offrant ainsi une flexibilité et une sécurité élevées.
Pour plus d'informations sur les options de chiffrement, veuillez consulter : Options de chiffrement
Renégociation SSL du client
Cochez cette case si vous souhaitez autoriser la renégociation SSL à l'initiative du client. Désactivez la renégociation SSL du client pour éviter toute attaque DDOS possible contre la couche SSL en décochant cette option.
Reprise SSL du client
Cochez cette case si vous souhaitez activer la reprise des sessions du serveur SSL ajoutées au cache de session. Lorsqu'un client propose la réutilisation d'une session, le serveur essaie de réutiliser la session si elle est trouvée. Si la case Reprise n'est pas cochée, aucune mise en cache de session n'a lieu pour le client ou le serveur.
Certificat SNI par défaut
Lors d'une connexion SSL avec le SNI côté client activé, si le domaine demandé ne correspond à aucun des certificats attribués au service, l'ADC présentera le certificat SNI par défaut. Le paramètre par défaut est Aucun, ce qui aurait pour effet d'interrompre la connexion en l'absence de correspondance exacte. Choisissez l'un des certificats installés dans la liste déroulante pour le présenter en cas d'échec de la correspondance exacte du certificat SSL.
Journal de sécurité
La valeur par défaut est 'On'. Elle permet au service de consigner les informations d'authentification dans les journaux du W3C. En cliquant sur l'icône de la roue dentée, vous accédez à la page Système > Journalisation, où vous pouvez vérifier les paramètres de la journalisation du W3C.
Délai de connexion
Le délai de connexion par défaut est de 600 secondes ou 10 minutes. Ce paramètre permet d'ajuster le délai d'expiration de la connexion en cas d'inactivité. Réduisez cette valeur pour le trafic Web sans état de courte durée, qui est généralement de 90 secondes ou moins. Augmentez ce chiffre pour les connexions avec état telles que RDP à quelque chose comme 7200 secondes (2 heures) ou plus, en fonction de votre infrastructure. L'exemple du délai d'attente RDP signifie que si un utilisateur a une période d'inactivité de 2 heures ou moins, les connexions resteront ouvertes.
Paramètres de surveillance
Ces paramètres concernent les moniteurs de serveur réel dans l'onglet Basic. Il existe des entrées globales dans la configuration pour compter le nombre de surveillances réussies ou échouées avant que le statut d'un serveur soit marqué en ligne ou en échec.
Intervalle
L'intervalle est le temps en secondes entre les moniteurs. L'intervalle par défaut est de 1 seconde. Bien que 1s soit acceptable pour la plupart des applications, il peut être bénéfique d'augmenter cet intervalle pour d'autres ou pendant les tests.
Délai de surveillance
La valeur du délai d'attente est le temps pendant lequel l'ADC attendra qu'un serveur réponde à une demande de connexion. La valeur par défaut est de 2s. Augmentez cette valeur pour les serveurs occupés.
Suivi du nombre d'entrées
La valeur par défaut de ce paramètre est 2. La valeur 2 indique que le serveur Real doit passer deux contrôles de santé réussis avant d'être mis en ligne. En augmentant ce chiffre, vous augmentez la probabilité que le serveur puisse servir le trafic, mais la mise en service prendra plus de temps en fonction de l'intervalle. En diminuant cette valeur, le serveur sera mis en service plus rapidement.
Surveillance du nombre de sorties
La valeur par défaut de ce paramètre est 3, ce qui signifie que le moniteur Real Server doit échouer trois fois avant que l'ADC n'arrête d'envoyer du trafic au serveur et que celui-ci soit marqué RED et Unreachable. En augmentant ce chiffre, vous obtiendrez un service meilleur et plus fiable, au détriment du temps nécessaire à l'ADC pour arrêter d'envoyer du trafic à ce serveur.
Passage en mode hors ligne en cas de défaillance
Lorsque cette case est cochée, les serveurs réels qui échouent à leur contrôle de santé sont mis hors ligne et ne peuvent être remis en ligne que manuellement.
Max. Connexions
Limite le nombre de connexions simultanées au serveur réel et est défini par service. Par exemple, si vous configurez cette limite à 1000 et que vous avez deux serveurs réels, l'ADC limite chaque serveur réel à 1000 connexions simultanées. Vous pouvez également choisir de présenter une page "Server too busy" (Serveur trop occupé) une fois que cette limite est atteinte sur tous les serveurs, afin d'aider les utilisateurs à comprendre pourquoi une absence de réponse ou un retard s'est produit. Laissez ce champ vide pour des connexions illimitées. Ce que vous définissez ici dépend des ressources de votre système.
flightPATH
flightPATH est un système conçu par Edgenexus et disponible exclusivement au sein de l'ADC. Contrairement aux moteurs à base de règles d'autres fournisseurs, flightPATH ne fonctionne pas via une ligne de commande ou une console de saisie de script. Au lieu de cela, il utilise une interface graphique pour sélectionner les différents paramètres, conditions et actions à effectuer pour obtenir ce dont ils ont besoin. Ces caractéristiques rendent flightPATH extrêmement puissant et permettent aux administrateurs réseau de manipuler le trafic HTTPS de manière très efficace.
flightPATH est uniquement disponible pour une utilisation avec des connexions HTTPS, et cette section n'est pas visible lorsque le type de service virtuel n'est pas HTTP.
Vous pouvez voir dans l'image ci-dessus ; il y a une liste des règles disponibles sur la gauche et les règles appliquées au service virtuel sur la droite.
Ajoutez une règle disponible en la faisant glisser et en la déposant du côté gauche vers le côté droit ou en mettant en surbrillance une règle et en cliquant sur la flèche droite pour la déplacer vers le côté droit.
L'ordre d'exécution est essentiel et commence par la règle supérieure exécutée en premier. Pour modifier l'ordre d'exécution, mettez la règle en surbrillance et déplacez-vous vers le haut et le bas à l'aide des flèches.
Pour supprimer une règle, faites-la glisser et déposez-la à nouveau dans l'inventaire des règles sur la gauche ou mettez la règle en surbrillance et cliquez sur la flèche gauche.
Vous pouvez ajouter, supprimer et modifier les règles flightPATH dans la section Configurer flightPATH de ce guide.