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 répartis 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. c'est-à-dire 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 entrez 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. Cette IP est l'endroit où les utilisateurs ou les applications pointeront pour accéder à l'application équilibrée en 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é lors de l'accès 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 Mise à jour pour enregistrer cette section et passer automatiquement à la section Serveur réel 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 équilibrées en termes de 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 précise et ne doit pas être une adresse DHCP.
Port	Le Port cible d'accès sur le serveur réel. Lors de l'utilisation d'un proxy inverse, cela 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 deviendra 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 Ajouter un service virtuel pour entrer en mode d'édition de 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 Mise à jour pour sauvegarder cette section et passer automatiquement à la section Serveur réel ci-dessous

· Laissez l'option Activité du serveur en ligne - cela 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 deviendra Rouge si le contrôle du serveur réel échoue.

· Un serveur dont le voyant d'état est rouge ne sera pas équilibré en termes de charge.

Changer 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 modifiera 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 copiera un service entier, y compris tous les serveurs réels, les paramètres de base, les paramètres avancés et les règles flightPATH 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îtra 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 le tableau 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 une petite flèche apparaître 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 indiquera 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'eux affichera 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 Primaire contiendra une case à côté de chaque IP virtuelle unique qui peut être cochée pour Active ou laissée non cochée pour Passive.
Stand-Alone	L'ADC agit en tant que 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 résulter du fait qu'un serveur réel a échoué à un contrôle de surveillance de l'état 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 apparaît comme 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 avec le TCP de 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 selon la politique d'équilibrage de charge.
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 séparées entre le client et le serveur
SMTP	Protocole de transfert de courrier simple	Couche 4	À utiliser lors de l'équilibrage de charge des serveurs de messagerie
POP3	Protocole du bureau de poste	Couche 4	À utiliser lors de l'équilibrage de charge des serveurs de messagerie
IMAP	Protocole d'accès aux messages Internet	Couche 4	À utiliser lors de l'équilibrage de charge des serveurs de messagerie
RDP	Protocole de bureau à distance	Couche 4	À utiliser lors de l'équilibrage de charge des serveurs Terminal Services
RPC	Appel de procédure à distance	Couche 4	A 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	À 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	À utiliser lors de l'équilibrage de charge des serveurs Exchange
DICOM	Imagerie numérique et communications en médecine	Couche 4	A 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 Serveurs réels du tableau de bord : Serveur, Basique, Avancé et FlightPATH.

Serveur

L'onglet Serveur contient les définitions des serveurs back-end réels appariés au service virtuel actuellement sélectionné. Vous devez ajouter au moins un serveur à la section Serveurs réels.

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îtra avec le curseur clignotant sur 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. Le numéro de port peut être le même que celui du service virtuel ou un autre numéro de port pour la connectivité de proxy inverse. L'ADC se traduira automatiquement par ce numéro.

· Passez à la section Notes pour ajouter tout détail pertinent pour 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 Mettre à jour.

Voyants d'état du serveur réel

Vous pouvez voir le statut d'un serveur réel par la couleur claire dans la colonne Statut. 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 affectés en ligne recevront du trafic selon la politique d'équilibrage de charge définie dans l'onglet Basique.
Drainage	Tous les serveurs réels assignés comme Drain continueront à servir les connexions existantes mais n'accepteront aucune nouvelle connexion. Le voyant d'état clignotera en vert/bleu pendant que le drainage est en cours. Une fois que les connexions existantes se sont naturellement fermées, les serveurs réels seront mis hors ligne et le voyant d'état sera bleu fixe. Vous pouvez également visualiser ces connexions en naviguant dans 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 Standby resteront hors ligne jusqu'à ce que TOUS les serveurs du groupe Online échouent à leurs contrôles 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 un serveur du groupe en ligne passe le contrôle du Server Health Monitor, 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 de port TCP ou UDP sur lequel le serveur Real écoute pour 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 nous considérons que la politique d'équilibrage de la charge est définie sur Connexions les plus faibles, 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 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 pondérations modifie le biais de manière similaire à celui de la politique des 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 toute note particulière utile à la description de l'entrée définie dans le champ Notes. Exemple "IIS Server1 - London DC".

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 de charge

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, se trouve 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 que lorsque vous utilisez cette politique d'équilibrage de charge.
Round Robin	Le Round Robin est couramment utilisé dans les pare-feu et les équilibreurs de charge de base et constitue la méthode 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.
Affinité/Persistance des sessions de couche 3 - Liaison IP	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 où la topologie du réseau 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 demandes peuvent sembler provenir d'un seul client et, de ce fait, la charge ne serait pas uniforme. Avec HTTP, les informations de l'en-tête (X-Forwarder-For) sont utilisées lorsqu'elles sont présentes pour faire face aux proxies.
Affinité/Persistance de session de couche 3 - basée sur la liste d'IP	La connexion au serveur Real 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.
Affinité/Persistance de session de la couche 7 - Cookie de session	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. Après cela, 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 back-end. Le cookie expire lorsque la session est fermée.
Affinité/Persistance de la session de la couche 7 - Cookie persistant	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. Après cela, 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 back-end. Le cookie expirera après 2 heures, et la connexion sera équilibrée en termes de charge selon un algorithme basé sur une liste d'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 maintiendra 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é, le CDA 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, il sera équilibré en charge à l'aide de l'algorithme Least Connections.
Cookie de session - Cookie de session JAX-WS	Les services Web Java (JAX-WS) sont 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. Avec ce mode 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 charge utilise le cookie RDP créé par Microsoft et basé sur le nom d'utilisateur/domaine pour assurer la persistance à 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. REMARQUE : Si cette valeur est définie, nous écrasons l'expression du cookie ci-dessus pour remplacer h= par la nouvelle valeur. Enfin, si une valeur de cookie inconnue arrive et correspond à l'un des ID de serveur réel, elle doit sélectionner ce serveur ; sinon, utilisez la méthode suivante (delegate.)

Surveillance du serveur

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 Real 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 sélectionnez ; 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 permet d'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 débit du 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	Dans ce mode, une connexion TCP est établie avec le serveur réel et immédiatement interrompue sans envoyer de données. 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. Les services UDP sont les seuls qui ne conviennent pas actuellement à la surveillance des connexions TCP.
ICMP Unreachable	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, le CDA 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 vérifiée pour le code de réponse "200 OK". Si le code de réponse "200 OK" est reçu, le CDA considère que le serveur réel est opérationnel. 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 est traité 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 qui comprend 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 avec succès le moniteur. Si, pour une raison quelconque, le moniteur ne se termine pas avec succès, le serveur réel est considéré comme hors service.
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 Host	La mise en cache par hôte est basée sur l'application par nom d'hôte. Un cache séparé 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
Par défaut	Cette option a pour effet d'appliquer un certificat créé localement et 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	Utiliser tout certificat présent sur le CDA que l'utilisateur a téléchargé ou généré

Certificat SSL de Real Server (chiffrement entre l'ADC et Real Server)

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 apparaîtront 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 côté navigateur signifie que "No SSL" peut être choisi côté client pour fournir ce que l'on appelle "SSL Offload".
Tout	Le CDA agit comme un client et accepte tout certificat présenté par le serveur réel. Le trafic entre le CDA 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 le CDA 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 quatre types de connectivité différents. Veuillez sélectionner le mode de connectivité à appliquer au service.

Option	Description
Reverse Proxy	Reverse Proxy est la valeur par défaut et fonctionne au niveau de la couche 7 avec compression et mise en cache. Et à 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 cercles) permet au serveur derrière l'équilibreur de charge de répondre directement au client en contournant l'ADC sur 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. 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 la prise en charge de la persistance 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'intermédiaire de l'ADC, ce qui permet au trafic des serveurs réels d'être acheminé 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 lorsqu'il fonctionne en mode multi-interface. L'équilibrage de charge de la 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 Real définisse sa passerelle par défaut à l'adresse de l'interface locale (eth0, eth1, etc.) de l'ADC. 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.

Options de chiffrement

Vous pouvez définir les ciphers au niveau de chaque service, et cela n'est pertinent que pour les services avec SSL/TLS activé. Le CDA effectue un choix automatique du chiffrement, et vous pouvez ajouter différents chiffrement en utilisant des jetPACKS. En ajoutant le jetPACK approprié, vous pouvez définir les options de chiffrement par service. L'avantage est que vous pouvez créer plusieurs services avec différents niveaux de sécurité. Sachez que les anciens clients ne sont pas compatibles avec les nouveaux ciphers ; plus le service est sécurisé, plus le nombre de clients est réduit.

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 empêcher toute attaque DDOS éventuelle 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 pour le client ou le serveur n'a lieu.

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 Cog, vous accédez à la page Système > Journalisation, où vous pouvez vérifier les paramètres de la journalisation 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 ce chiffre pour le trafic Web sans état de courte durée, qui est généralement de 90s 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 se rapportent aux Moniteurs du serveur réel dans l'onglet Basique. Il existe des entrées globales dans la configuration pour compter le nombre de moniteurs réussis ou échoués 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 cette valeur 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 surveillance de santé réussis avant d'être mis en service. 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.

Comptage des sorties de surveillance

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 qu'il soit marqué RED et Unreachable. En augmentant ce chiffre, vous obtiendrez un service de meilleure qualité 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 placés hors ligne et ne peuvent être remis en ligne que manuellement.

Max. Connexions

Limite le nombre de connexions simultanées du serveur réel et est défini par service. Par exemple, si vous le configurez sur 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 "Serveur trop occupé" une fois cette limite atteinte sur tous les serveurs, afin d'aider les utilisateurs à comprendre la raison d'une absence de réponse ou d'un retard. 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 basés sur des 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 sur 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.