- Why Edgenexus?
- Essayer
- Products
- Solutions
- Applications
- Resources
COMPARE
READ
WATCH
SEE
Alliances and Partners
- Support
Load Balancer/ADC ALB-X Test drive Tutorial
(ADC Application Delivery Controller)
Faites un essai routier ici
Table des matières
Nous espérons que vous apprécierez votre expérience avec l'équilibreur de charge ALB-X et nous aimerions que vous disposiez d'une configuration réaliste pour jouer avec.
-
Dans le cadre de ce test, nous avons pré-configuré quelques exemples de services pour vous permettre de démarrer.
-
Nous hébergeons cette configuration sur Azure mais ne vous inquiétez pas, vous n'avez pas besoin d'avoir un compte Azure et en plus c'est GRATUIT.
-
Vous pouvez reconfigurer l'appliance pour l'essayer sur vos propres serveurs.
Voici quelques mots pour vous aider à naviguer dans l'interface utilisateur et à tirer le meilleur parti de votre essai routier, alors attachez votre ceinture....
Une fois que vous vous êtes inscrit à votre essai ALB-X, vous recevrez votre propre URL unique pour accéder à l'interface graphique d'ALB-X à partir de votre navigateur Web. Si possible, nous vous recommandons d'utiliser le navigateur Google Chrome.
- Notez que l'accès à l'interface graphique se fait par un port non standard :27376 afin que le port HTTPS standard :443 soit disponible pour l'allocation en tant que service à charge équilibrée.
- Ne vous inquiétez pas si vous recevez un avertissement concernant la sécurité SSL - c'est parce que la connexion de gestion est sécurisée par défaut à l'aide d'un certificat local.
Pour un déploiement en direct, vous êtes libre de télécharger votre propre certificat pour confirmer l'authenticité de la connexion de gestion.
Lorsque vous y êtes invité, saisissez votre nom d'utilisateur et votre mot de passe uniques pour cette session d'essai (ils vous ont été envoyés par courrier électronique).
Configuration de l'essai Azure
- Azure utilise le mappage de port NAT 1:1 pour permettre l'accès de l'espace d'adresses IP publiques d'Internet à l'adresse IP privée interne.
-
L'adresse IP configurée automatiquement sur l'équilibreur de charge utilise une adresse IP privée Azure.
-
Vous pouvez bien sûr configurer Azure pour qu'il ouvre et NAT d'autres ports pour des services supplémentaires.
-
Seuls les ports 80, 443 et 27376 (pour l'interface graphique) ont été ouverts pour cette démo.
ALB-X Test Drive Services pré-remplis
Comme il s'agit d'un test personnalisé, nous avons pré-rempli les services IP avec quelques services que vous pouvez essayer immédiatement. Pour les besoins du test, nous avons mis à disposition le contenu de serveurs réels sur deux serveurs web accessibles au public :
- L'ALB-X est capable d'utiliser le DNS pour résoudre les noms en adresses IP publiques. Chacun de ces sites comporte un texte ou une image indiquant quel site a servi le contenu, ce qui permet de voir le processus d'équilibrage de la charge en action.
Nous avons mis en place 4 services de démonstration pour vous :
|
Nom
|
Port
|
Accessibilité
|
|---|---|---|
|
Équilibrage de la charge des connexions HTTP les moins nombreuses
|
80
|
http://yoururl
|
|
HTTPS Offload
|
443
|
https://yoururl
|
|
Persistance basée sur les cookies
|
601
|
http://yoururl/601/
|
|
Réécriture du test corporel
|
602
|
http://yoururl/?602
|
Service sur le port 80 - Équilibrage de la charge des connexions HTTP les moins nombreuses
Le premier service est un équilibreur de charge de serveur web de base sur le port 80 qui utilise notre politique d'équilibrage de charge "moins de connexions" vers deux "vrais serveurs".
- Utilisez votre navigateur pour ouvrir une connexion HTTP à la même adresse IP publique que celle utilisée pour l'accès à la gestion de l'ALB-X et vous devriez obtenir quelque chose de similaire à ce qui suit.
Service sur le port 443 - SSL Offloading
Le deuxième service est sur le port 443. Dans ce cas, c'est l'équilibreur de charge qui se charge du cryptage, parfois appelé "délestage" du SSL.
- Nous avons utilisé le certificat SSL par défaut pour le test de démonstration. Vous obtiendrez donc la même alerte de sécurité dans votre navigateur lorsque vous vous connecterez à ce canal.
N'hésitez pas à télécharger votre propre certificat SSL et à l'appliquer au service, voir les instructions plus loin. Une fois que vous avez franchi l'exception de sécurité, vous verrez le même contenu s'afficher dans votre navigateur.
Redirection HTTP vers HTTPS
La première chose que nous pouvons regarder et qui utilise flightPATH est la redirection HTTP vers HTTPS.
Il s'agit d'une fonction souvent utilisée pour garantir que le trafic web est desservi par une connexion sécurisée.
- Nous avons préconfiguré une règle flightPATH et l'avons appliquée au canal HTTP du port 80 pour rechercher les demandes dont la chaîne de requête est la suivante : /?secure
/?secure
Si flightPATH voit cette "condition", il agira sur le trafic et renverra une redirection 302 au navigateur pour lui dire d'effectuer une autre requête GET vers HTTPS://votre.original.request.location qui, dans ce cas, sera la même adresse IP publique du service, mais sur le canal 443.
Vous pouvez maintenant jeter un coup d'œil à la configuration de la règle flightPATH.
Pour ce faire, cliquez sur l'onglet Bibliothèque à gauche et sélectionnez flightPATH.
Cliquez sur l'entrée "Force HTTPS - when query string is secure" et vous verrez l'écran suivant
- "Condition" est Chaîne d'interrogation ne contient pas de sécurité
OU
- "Action" est Redirect 302 https://$host$$path$$querystring$ ($ sont des variables utiles que vous pouvez utiliser dans les actions des règles)
Persistance des cookies et utilisation du serveur en fonction du chemin d'accès
Comme vous avez pu le constater, les connexions ont été réparties sur les deux serveurs réels – c’est pourquoi les images renvoyées proviennent à la fois du serveur 1 et du serveur 2. En effet, la politique d’ équilibrage de charge par défaut est « moins de connexions », ce qui permet de maintenir un nombre égal de connexions à tous les serveurs configurés pour un service.
- RAPPEL : Tous les objets d'une page web, tels que les images, les vidéos, les JS, feront chacun l'objet d'une requête GET distincte auprès du serveur web. Ce comportement peut ne pas être compatible avec l'application, qui peut avoir besoin de "persistance" ou d'"adhérence".
Pour les services HTTP, cela peut être réalisé en appliquant un cookie de session spécial que le navigateur présentera lors de toutes les demandes ultérieures à ce service, normalement pour la durée de la "session".
- Pour le démontrer, nous avons configuré le service 601 "interne" pour l'équilibrage de charge basé sur les cookies de session ALB. Comme nous l'avons dit, le service 601 n'étant pas directement accessible depuis l'extérieur du réseau Azure, nous avons utilisé une règle flightPATH pour diriger le trafic vers ce service.
La règle flightPATH examine le chemin demandé et s'il s'agit de /601/, elle envoie le trafic au service fonctionnant sur le port 601. Voici les détails de cette règle flightPATH.
Cette règle flightPATH montre comment le trafic peut être envoyé à un autre service en fonction du chemin, ce qui constitue un outil puissant pour la manipulation du trafic ou l'orientation du contenu.
Nous pouvons voir la configuration du VIP sur le port 601 :
- Essayez maintenant d'ajouter le chemin /601/ à l'IP publique "http://myurl/601/", vous devriez obtenir un résultat comme celui-ci :
http://myurl/601/
Vous pouvez voir ici que tout le contenu est servi par le serveur 1 - vous pouvez vérifier les outils de développement de votre navigateur et vous verrez qu'un cookie appelé jnAccel= a été défini.
Réécriture de chemin et évaluation de RegEx
Comme le serveur réel n'a pas de contenu sous le chemin /601/ , nous devions le supprimer de la requête, faute de quoi nous obtiendrions une erreur 404 (que nous pouvons également masquer à l'aide de flightPATH).
- Pour ce faire, nous avons appliqué une autre règle flightPATH appelée "Remove Path 601" au service fonctionnant sur le port :601.
Ici, nous recherchons à nouveau 601 dans le chemin d'accès comme condition de déclenchement de cette règle.
- Dans ce cas, nous utilisons la fonction d'évaluation qui fait appel à l'expression régulière pour permettre la création d'une nouvelle variable en manipulant une variable système existante, en l'occurrence la valeur originale du chemin d'accès que nous avons vue.
Nous créons donc le NewPath en extrayant simplement les données situées après le préfixe de chemin d'accès /601/.
L'action consiste à réécrire le chemin en utilisant le $NewPath1$ et le $querystring$ s'ils sont présents.
Remplacement du texte du corps du texte HTML
Dans l'autre exemple de service utilisant le port :602 , nous montrons comment vous pouvez également manipuler le contenu HTML et pas seulement l'en-tête HTTP.
- Au lieu d'utiliser un chemin pour diriger le trafic arrivant sur le port 80 vers le service 602, nous avons utilisé la chaîne de caractères /?602. - "http://myurl/?602"
http://myurl/?602
Si vous entrez l'adresse IP publique de votre ALB-X de test dans votre navigateur et ajoutez /?602 , vous devriez obtenir le résultat suivant.
Vous pouvez voir une ligne de texte supplémentaire en orange indiquant que -
- "Ce texte a été ajouté par flightPATH"
Pour ce faire, deux règles flightPATH sont appliquées.
La règle suivante appliquée au port:80 recherche une valeur de chaîne de requête de 602 et envoie toutes les requêtes correspondantes au service fonctionnant sur le port 602.
Appliquée au service fonctionnant sur le port :602, une règle flightPATH exécute une fonction "Body Replace Last" (remplacement du corps en dernier) à la recherche de la balise de fermeture du corps.
</body>
et en le remplaçant par
<font face=’Arial’ size=’6′ color=’orange’><center>This text has been added by flightPATH</center></font></body>
Aucune condition ou évaluation n'étant requise dans ce cas, la fonction s'appliquera à l'ensemble du trafic passant par le service.
J'espère que vous pouvez voir comment ces fonctions peuvent être combinées pour effectuer des manipulations astucieuses du trafic HTTP et ce n'est que la partie émergée de l'iceberg de ce que flightPATH peut faire.
N'hésitez pas à en faire l'expérience et nous serons heureux de connaître vos besoins spécifiques.
Contrôles réels de la santé des serveurs
Nous allons maintenant nous pencher sur le contrôle de l'état réel du serveur. Il est essentiel que le bon type de contrôle de santé soit appliqué à un service pour permettre une détection fiable de la santé du ou des serveurs dorsaux afin de garantir que le trafic des clients n'est envoyé qu'à des serveurs opérationnels.
Lors de la création d'un nouveau service, nous devons définir un ensemble de paramètres par défaut. Pour la surveillance du serveur, nous utilisons le contrôle de santé de la connexion TCP. L'option Surveillance du serveur se trouve sous l'onglet Basique du service en cours de configuration.
Bien qu'il s'agisse d'un point de départ raisonnable, il est fortement recommandé de configurer et d'appliquer un contrôle de santé plus fiable à un service, et nous avons rendu très facile la création de contrôles de santé HTTP personnalisés.
- Le bilan de santé se trouve dans la rubrique "Bibliothèque / Moniteurs de serveurs réels".
Dans le Test Drive, nous avons ajouté un troisième Real Server Monitor pour montrer un exemple de contrôle de santé d'une réponse HTTP.
HTTP 200 OK Méthode de surveillance
Le 200OK utilise une requête HTTP GET vers l'emplacement de la page configuré pour le contrôle et s'assure qu'une réponse d'état 200OK est renvoyée.
Il ne recherche pas de contenu spécifique, mais vérifie simplement qu'un serveur web fonctionne sur le port et qu'il est en mesure de servir la page demandée.
- Il s'agit d'un meilleur contrôle que la connexion TCP, car il opère au niveau 7 et vérifie que l'application est en cours d'exécution, mais il ne vérifie pas si une réponse spécifique a été renvoyée.
Nous avons appliqué ce moniteur, comme vous pouvez le voir ci-dessus, au service fonctionnant sur le port:601.
Méthode de surveillance des réponses HTTP
Le moniteur NLS configuré dans le Test Drive utilise le contrôle de réponse HTTP.
Pour cela, vous définissez l'emplacement spécifique de la page (il peut s'agir de l'URL complète lorsque des en-têtes d'hôte sont nécessaires) et vous définissez le contenu (une chaîne de texte) qui doit être présent dans les données renvoyées par le serveur / l'application.
Il s'agit d'un bien meilleur test car la page doit être présente et le contenu spécifique doit être disponible.
- Lorsque l'application fait face à une base de données dorsale, il est judicieux de faire en sorte que l'état du contenu récupéré sur la page du bilan de santé dépende des réponses en direct de la base de données plutôt que d'un simple contenu statique sur le serveur frontal du web.
Vous pouvez voir que nous avons appliqué ce moniteur au service fonctionnant sur le port:602.
Vous pouvez modifier le texte dans le champ Contenu requis pour ce bilan de santé et vous verrez les serveurs passer au rouge pour indiquer qu'ils n'ont pas réussi le bilan de santé. Remettez le contenu requis à la bonne valeur et les serveurs reviendront au vert OK.
Intervalle de surveillance
Sous l'onglet "Avancé", vous pouvez manipuler la fréquence, le délai, etc. de l'opération de contrôle de santé pour ce service.
Pour l'essai routier, nous avons réglé l'intervalle de surveillance sur 3 secondes avec un délai de 2 secondes.
Le nombre de sorties de surveillance est fixé à 3, de sorte qu'il ne doit pas obtenir 3 réponses consécutives avant de marquer le serveur comme inaccessible.
- Avec un compte d'entrée en surveillance de 2, il doit y avoir deux réponses consécutives réussies avant que le serveur ne soit remis en service. Ces valeurs sont raisonnables dans la plupart des cas.
HTTPS et certificats SSL
De plus en plus de sites web utilisent le HTTPS et, au début de l'année 2017, le pourcentage a basculé en faveur du HTTPS.
La plupart des applications d'entreprise nécessitent une protection par cryptage, il y a donc fort à parier que vous devrez utiliser des certificats sur l'ALB-X. Le déploiement d'un équilibreur de charge avec HTTPS est un moyen rapide et facile de sécuriser l'accès à des applications non cryptées.
- L'ALB-X a un certificat privé installé par défaut, appelé "default", qui est utilisé pour permettre la connectivité HTTPS à l'interface graphique de gestion. Nous avons appliqué ce certificat au service Test Drive :443 HTTPS configuré du côté du service virtuel ou du client.
Le service est configuré pour le délestage SSL et donc le côté Real Server est configuré pour No SSL.
Téléchargement/importation de certificats
Vous pouvez télécharger vos propres certificats signés dans l'ALB-X en utilisant le menu Certificats SSL dans la section Bibliothèque.
Comme indiqué dans les champs de saisie, le certificat doit être au format PKCS#12 pour être importé dans l'ALB-X.
- Ce type de certificat contient la clé privée et est sécurisé par un mot de passe qui est exigé au moment de l'importation.
Le nom (qui ne doit pas contenir d'espaces) que vous donnez au certificat lors de l'importation sera celui qui apparaîtra dans les menus déroulants de sélection des certificats dans l'onglet Service IP de base.
Recryptage du serveur réel
Si les serveurs réels nécessitent un recryptage SSL/TLS, l'option la plus judicieuse à sélectionner est "Any" dans le menu déroulant Real Server SSL Certificate.
- Cela signifie que l'ALB-X acceptera tout certificat présenté par les serveurs réels comme étant valide.
SNI (Server Name Indication)
Avec la rareté des adresses IP publiques et le fait qu'un seul VIP peut être configuré dans Azure, il est utile de pouvoir supporter plusieurs domaines sécurisés / URL hôtes à travers un seul service virtuel et cela est possible sur ALB-X car nous supportons SNI.
- Pour utiliser SNI, il suffit de sélectionner tous les certificats nécessaires dans la liste déroulante des certificats SSL du service virtuel. Chaque clic permet de sélectionner ou de désélectionner le certificat dans la liste SNI.
Du côté du serveur réel, si les services sont recryptés et hébergés sur des serveurs communs, ils auront besoin de SNI pour l'identification et la négociation correctes du service, SNI doit donc être sélectionné comme option dans le menu déroulant du certificat SSL du serveur réel.
Applications
ALB-X permet de déployer des caractéristiques et des fonctionnalités supplémentaires en achetant et en téléchargeant des applications à partir de notre App Store pour les déployer dans l'environnement conteneurisé d'ALB-X.
- Les deux premiers modules complémentaires disponibles sont un Web Application Firewall et un Global Server Load Balancing pour la redondance automatisée du centre de données et le basculement / l'équilibrage de charge du cloud hybride.
Nous avons mis en place deux tests distincts dans Azure où vous pouvez voir cette fonctionnalité en fonctionnement, alors n'hésitez pas à les consulter si vous êtes intéressé.
Authentification
ALB-X supporte la préauthentification en conjonction avec un serveur MS AD (Microsoft Active Directory ) / LDAP.
- Vous êtes libre d'explorer cette fonctionnalité si vous avez accès à un serveur MS AD / LDAP accessible au public (utiliser les LDAP). Le guide de l'utilisateur en ligne de l'ALB-X décrit la configuration de cette fonction.
Cette fonctionnalité remplace avantageusement le produit TMG de Microsoft, qui n'est plus utilisé.
Surveillance de l'utilisation des appareils et des connexions
La section Affichage du menu vous permet de voir l'état de la connexion et l'état réel du serveur, soit en temps réel (État), soit sous forme de tendance dans le temps (Historique).
- C'est également à cet endroit que vous trouverez les journaux du W3C et du système. Vous pouvez également créer vos propres widgets personnalisés à afficher sur le tableau de bord. Nous vous encourageons à examiner les différentes options proposées dans cette section.
Système
C'est ici que vous trouverez les options de configuration qui s'appliquent aux fonctions du système, telles que le réglage de l'heure et de la date, l'activation des alertes par courrier électronique, l'octroi de licences pour le produit, le choix du mode de journalisation et de l'endroit où les journaux sont envoyés, le redémarrage et la remise en marche de l'appareil, la configuration du protocole SNMP et l'ajout d'autres utilisateurs de gestion, etc.
Avancé
Dans le menu avancé, vous pouvez sauvegarder et restaurer la configuration et également télécharger des configurations de modèles jetPACK.
- Vous pouvez modifier le comportement du protocole HTTP, effectuer des mises à jour logicielles et télécharger d'autres logiciels à partir de la bibliothèque en nuage.
Enfin, il existe une section de dépannage dans laquelle nous avons facilité le téléchargement d'un fichier d'assistance groupé, l'exécution d'un PING réseau et la réalisation de diverses traces du système et de captures de paquets réseau.
Nous vous remercions.
- Nous espérons que vous apprécierez votre essai de l'ALB-X.
Nous serions heureux de répondre à vos questions à l'adresse suivante : pre-sales@edgenexus.io
Ne nous croyez pas sur parole, faites un essai gratuit.
Matériel, logiciel ou même votre propre image en ligne avec un environnement de test complet.
Faites-nous savoir ce dont vous avez besoin ici
MAGASIN D’APPLICATIONS
Copyright © 2021 Edgenexus Limited.