Utiliser Citrix ADM pour dépanner la mise en réseau native de Citrix Cloud™

Présentation

Dans ce document, nous examinons comment vous pouvez utiliser Citrix ADM pour livrer et surveiller les applications de microservices Kubernetes. Nous abordons également l’utilisation de la CLI, des graphes de services et du traçage pour permettre aux équipes de plateforme et SRE de dépanner.

Performances des applications et vue d’ensemble de la latence

Chiffrement TLS

TLS est un protocole de chiffrement conçu pour sécuriser les communications Internet. Un handshake TLS est le processus qui initie une session de communication utilisant le chiffrement TLS. Lors d’un handshake TLS, les deux parties communicantes échangent des messages pour se reconnaître, se vérifier mutuellement, établir les algorithmes de chiffrement qu’elles utilisent et convenir des clés de session. Les handshakes TLS sont un élément fondamental du fonctionnement de HTTPS.

Handshakes TLS vs. SSL

SSL, ou Secure Sockets Layer, était le protocole de chiffrement original développé pour HTTP. TLS, Transport Layer Security, a remplacé SSL il y a quelque temps. Les handshakes SSL sont maintenant appelés handshakes TLS, bien que le nom « SSL » soit encore largement utilisé.

Quand un handshake TLS se produit-il ?

Un handshake TLS a lieu chaque fois qu’un utilisateur navigue vers un site web via HTTPS et que le navigateur commence à interroger le serveur d’origine du site web. Un handshake TLS se produit également chaque fois que d’autres communications utilisent HTTPS, y compris les appels API et les requêtes DNS sur HTTPS.

Les handshakes TLS se produisent après l’ouverture d’une connexion TCP via un handshake TCP.

Que se passe-t-il pendant un handshake TLS ?

• Lors d’un handshake TLS, le client et le serveur effectuent ensemble les opérations suivantes :
  • Spécifient la version de TLS (TLS 1.0, 1.2, 1.3, etc.) qu’ils utilisent.
  • Décident des suites de chiffrement (voir la section suivante) qu’ils utilisent.
  • Authentifier l’identité du serveur via la clé publique du serveur et la signature numérique de l’autorité de certification SSL.
  • Générer des clés de session pour utiliser le chiffrement symétrique une fois que l’établissement de liaison est terminé.

Quelles sont les étapes d’un établissement de liaison TLS ?

• Les établissements de liaison TLS sont une série de datagrammes, ou messages, échangés entre un client et un serveur. Un établissement de liaison TLS implique plusieurs étapes, car le client et le serveur échangent les informations nécessaires pour achever l’établissement de liaison et rendre possible une conversation ultérieure.

Les étapes exactes d’un établissement de liaison TLS varient en fonction du type d’algorithme d’échange de clés utilisé et des suites de chiffrement prises en charge par les deux parties. L’algorithme d’échange de clés RSA est le plus souvent utilisé. Il se déroule comme suit :

1. Le message « client hello » : Le client initie l’établissement de liaison en envoyant un message « hello » au serveur. Le message inclut la version TLS prise en charge par le client, les suites de chiffrement prises en charge et une chaîne d’octets aléatoires connue sous le nom de « client random ».
2. Le message « server hello » : En réponse au message client hello, le serveur envoie un message contenant le certificat SSL du serveur, la suite de chiffrement choisie par le serveur et le « server random », une autre chaîne d’octets aléatoires générée par le serveur.
3. Authentification : Le client vérifie le certificat SSL du serveur auprès de l’autorité de certification qui l’a émis. Cela confirme que le serveur est bien celui qu’il prétend être et que le client interagit avec le propriétaire réel du domaine.
4. Le secret prémaster : Le client envoie une autre chaîne d’octets aléatoires, le « secret prémaster ». Le secret prémaster est chiffré avec la clé publique et ne peut être déchiffré qu’avec la clé privée par le serveur. (Le client obtient la clé publique à partir du certificat SSL du serveur.)
5. Clé privée utilisée : Le serveur déchiffre le secret prémaster.
6. Clés de session créées : Le client et le serveur génèrent tous deux des clés de session à partir du client random, du server random et du secret prémaster. Ils devraient arriver aux mêmes résultats.
7. Le client est prêt : Le client envoie un message « finished » qui est chiffré avec une clé de session.
8. Le serveur est prêt : Le serveur envoie un message « finished » chiffré avec une clé de session.
9. Chiffrement symétrique sécurisé réalisé : L’établissement de liaison est terminé et la communication se poursuit à l’aide des clés de session.

Tous les établissements de liaison TLS utilisent le chiffrement asymétrique (la clé publique et la clé privée), mais tous n’utilisent pas la clé privée dans le processus de génération des clés de session. Par exemple, un établissement de liaison Diffie-Hellman éphémère se déroule comme suit :

1. Client hello : Le client envoie un message client hello avec la version du protocole, le client random et une liste de suites de chiffrement.
2. Server hello : Le serveur répond avec son certificat SSL, sa suite de chiffrement sélectionnée et le serveur random. Contrairement à la poignée de main RSA décrite dans la section précédente, dans ce message, le serveur inclut également les éléments suivants (étape 3).
3. Signature numérique du serveur : Le serveur utilise sa clé privée pour chiffrer le client random, le serveur random et son paramètre DH*. Ces données chiffrées fonctionnent comme la signature numérique du serveur, établissant que le serveur possède la clé privée qui correspond à la clé publique du certificat SSL.
4. Signature numérique confirmée : Le client déchiffre la signature numérique du serveur avec la clé publique, vérifiant que le serveur contrôle la clé privée et qu’il est bien celui qu’il prétend être. Paramètre DH du client : Le client envoie son paramètre DH au serveur.
5. Le client et le serveur calculent le secret prémaster : Au lieu que le client génère le secret prémaster et l’envoie au serveur, comme dans une poignée de main RSA, le client et le serveur utilisent les paramètres DH qu’ils ont échangés pour calculer séparément un secret prémaster correspondant.
6. Clés de session créées : Maintenant, le client et le serveur calculent les clés de session à partir du secret prémaster, du client random et du serveur random, tout comme dans une poignée de main RSA.
   • Le client est prêt : Identique à une poignée de main RSA
   • Le serveur est prêt
   • Chiffrement symétrique sécurisé réalisé

   *Paramètre DH : DH signifie Diffie-Hellman. L’algorithme Diffie-Hellman utilise des calculs exponentiels pour arriver au même secret prémaster. Le serveur et le client fournissent chacun un paramètre pour le calcul, et lorsqu’ils sont combinés, ils aboutissent à un calcul différent de chaque côté, avec des résultats égaux.

Pour en savoir plus sur le contraste entre les poignées de main Diffie-Hellman éphémères et d’autres types de poignées de main, et comment elles atteignent la confidentialité persistante, consultez cette documentation du protocole TLS.

Qu’est-ce qu’une suite de chiffrement ?

• Une suite de chiffrement est un ensemble d’algorithmes de chiffrement utilisés pour établir une connexion de communication sécurisée. (Un algorithme de chiffrement est un ensemble d’opérations mathématiques effectuées sur des données pour les faire apparaître aléatoires.) Il existe diverses suites de chiffrement largement utilisées, et une partie essentielle de la poignée de main TLS consiste à convenir de la suite de chiffrement utilisée pour cette poignée de main.

Pour commencer, consultez la Référence : Documentation du protocole TLS.

Tableau de bord SSL de Citrix Application Delivery Management

Citrix Application Delivery Management (ADM) rationalise désormais tous les aspects de la gestion des certificats pour vous. Grâce à une console unique, vous pouvez établir des politiques automatisées pour garantir le bon émetteur, la force de clé et les algorithmes corrects, tout en gardant un œil attentif sur les certificats inutilisés ou bientôt expirés. Pour commencer à utiliser le tableau de bord SSL de Citrix ADM et ses fonctionnalités, vous devez comprendre ce qu’est un certificat SSL et comment vous pouvez utiliser Citrix ADM pour suivre vos certificats SSL.

A Secure Socket Layer (SSL) certificate, which is a part of any SSL transaction, is a digital data form (X509) that identifies a company (domain) or an individual. The certificate has a public key component that is visible to any client that wants to initiate a secure transaction with the server. The corresponding private key, which resides securely on the Citrix Application Delivery Controller™ (ADC) appliance, is used to complete asymmetric key (or public key) encryption and decryption.

Vous pouvez obtenir un certificat et une clé SSL de l’une des manières suivantes :

• Auprès d’une autorité de certification (CA) autorisée
• En générant un nouveau certificat et une nouvelle clé SSL sur l’appliance Citrix ADC

Citrix ADM offre une vue centralisée des certificats SSL installés sur toutes les instances Citrix ADC gérées. Sur le tableau de bord SSL, vous pouvez afficher des graphiques qui vous aident à suivre les émetteurs de certificats, les forces de clé, les algorithmes de signature, les certificats expirés ou inutilisés, etc. Vous pouvez également voir la distribution des protocoles SSL qui s’exécutent sur vos serveurs virtuels et les clés qui y sont activées.

Vous pouvez également configurer des notifications pour vous informer lorsque des certificats sont sur le point d’expirer et inclure des informations sur les instances Citrix ADC qui utilisent ces certificats.

Vous pouvez lier les certificats d’une instance Citrix ADC à un certificat CA. Cependant, assurez-vous que les certificats que vous liez au même certificat CA ont la même source et le même émetteur. Une fois que vous avez lié les certificats à un certificat CA, vous pouvez les délier.

Pour commencer, consultez la documentation du tableau de bord SSL suivante.

Intégrations tierces

La latence des applications est mesurée en millisecondes et peut indiquer l’une des deux choses en fonction de la métrique utilisée. La manière la plus courante de mesurer la latence est appelée « temps d’aller-retour » (ou RTT). Le RTT calcule le temps qu’il faut à un paquet de données pour voyager d’un point à un autre sur le réseau, et pour qu’une réponse soit renvoyée à la source. L’autre mesure est appelée « temps jusqu’au premier octet » (ou TTFB), qui enregistre le temps qu’il faut à partir du moment où un paquet quitte un point du réseau jusqu’au moment où il arrive à sa destination. Le RTT est plus couramment utilisé pour mesurer la latence car il peut être exécuté à partir d’un seul point sur le réseau et ne nécessite pas l’installation d’un logiciel de collecte de données sur le point de destination (contrairement au TTFB).

En surveillant l’utilisation de la bande passante et les performances de votre application en temps réel, le service ADM facilite l’identification des problèmes et la résolution préventive des problèmes potentiels avant qu’ils ne se manifestent et n’affectent les utilisateurs de votre réseau. Cette solution basée sur les flux suit l’utilisation par interface, application et conversation, vous donnant des informations détaillées sur l’activité de votre réseau.

Utilisation des outils Splunk

Les performances de l’infrastructure et des applications sont interdépendantes. Pour avoir une vue d’ensemble, SignalFx offre une corrélation transparente entre l’infrastructure cloud et les microservices qui s’y exécutent. Si votre application se comporte mal en raison d’une fuite de mémoire, d’un conteneur voisin bruyant ou de tout autre problème lié à l’infrastructure, SignalFx vous en informe. Pour compléter le tableau, l’accès contextuel aux journaux et événements Splunk permet un dépannage plus approfondi et une analyse des causes profondes.

Pour plus d’informations sur SignalFx Microservices APM et le dépannage avec Splunk, consultez les informations Splunk for DevOps.

Prise en charge de MongoDB

MongoDB stocke les données dans des documents flexibles, de type JSON. Cela signifie que les champs peuvent varier d’un document à l’autre et que la structure des données peut être modifiée au fil du temps.

Le modèle de document correspond aux objets de votre code d’application, ce qui facilite le travail avec les données.

Les requêtes à la demande, l’indexation et l’agrégation en temps réel offrent des moyens puissants pour accéder à vos données et les analyser.

MongoDB est une base de données distribuée à la base, de sorte que la haute disponibilité, la mise à l’échelle horizontale et la distribution géographique sont intégrées et faciles à utiliser.

MongoDB est conçu pour répondre aux exigences des applications modernes grâce à une base technologique qui vous permet de :

• Le modèle de données de document – vous offrant la meilleure façon de travailler avec les données.
• Une conception de systèmes distribués – vous permettant de placer intelligemment les données où vous le souhaitez.
• Une expérience unifiée qui vous donne la liberté de fonctionner n’importe où – vous permettant de pérenniser votre travail et d’éliminer le verrouillage propriétaire.

Grâce à ces capacités, vous pouvez construire une Plateforme de Données Opérationnelles Intelligente, soutenue par MongoDB. Pour plus d’informations, consultez Documentation MongoDB.

Comment équilibrer la charge du trafic Ingress vers une application basée sur TCP ou UDP

Dans un environnement Kubernetes, un Ingress est un objet qui permet d’accéder aux services Kubernetes depuis l’extérieur du cluster Kubernetes. Les ressources Ingress Kubernetes standard supposent que tout le trafic est basé sur HTTP et ne prennent pas en charge les protocoles non basés sur HTTP tels que TCP, TCP-SSL et UDP. Par conséquent, les applications critiques basées sur des protocoles L7 tels que DNS, FTP, LDAP ne peuvent pas être exposées à l’aide d’un Ingress Kubernetes standard.

La solution Kubernetes standard consiste à créer un service de type LoadBalancer. Consultez Type de service LoadBalancer dans Citrix ADC pour plus d’informations.

La deuxième option consiste à annoter l’objet ingress. Le contrôleur d’entrée Citrix vous permet d’équilibrer la charge du trafic Ingress basé sur TCP ou UDP. Il fournit les annotations suivantes que vous pouvez utiliser dans votre définition de ressource Ingress Kubernetes pour équilibrer la charge du trafic Ingress basé sur TCP ou UDP :

• ingress.citrix.com/insecure-service-type: L’annotation active l’équilibrage de charge L4 avec TCP, UDP ou ANY comme protocole pour Citrix ADC.
• ingress.citrix.com/insecure-port: L’annotation configure le port TCP. L’annotation est utile lorsque l’accès au micro-service est requis sur un port non standard. Par défaut, le port 80 est configuré.

Pour plus d’informations, consultez Comment équilibrer la charge du trafic Ingress vers une application basée sur TCP ou UDP

Surveiller et améliorer les performances de vos applications basées sur TCP ou UDP

Les développeurs d’applications peuvent surveiller de près l’état des applications basées sur TCP ou UDP grâce à des moniteurs riches (tels que TCP-ECV, UDP-ECV) dans Citrix ADC. Les moniteurs ECV (validation de contenu étendue) aident à vérifier si l’application renvoie le contenu attendu ou non.

De plus, les performances des applications peuvent être améliorées en utilisant des méthodes de persistance telles que l’adresse IP source. Vous pouvez utiliser ces fonctionnalités de Citrix ADC via les Annotations intelligentes dans Kubernetes. Voici un exemple :

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: mongodb
    annotations:
        ingress.citrix.com/insecure-port: “80”
        ingress.citrix.com/frontend-ip: “192.168.1.1”
        ingress.citrix.com/csvserver: ‘{“l2conn”:”on”}’
        ingress.citrix.com/lbvserver: ‘{“mongodb-svc”:{“lbmethod”:”SRCIPDESTIPHASH”}}’
        ingress.citrix.com/monitor: ‘{“mongodbsvc”:{“type”:”tcp-ecv”}}’
Spec:
    rules:
    - host: mongodb.beverages.com
      http:
        paths:
        - path: /
          backend:
            serviceName: mongodb-svc
            servicePort: 80
<!--NeedCopy-->

Service Citrix Application Delivery Management (ADM)

Le service Citrix ADM offre les avantages suivants :

• Agile – Facile à utiliser, à mettre à jour et à consommer. Le modèle de service de Citrix ADM Service est disponible via le cloud, ce qui facilite l’utilisation, la mise à jour et l’exploitation des fonctionnalités fournies. La fréquence des mises à jour, combinée à la fonction de mise à jour automatisée, améliore rapidement votre déploiement Citrix ADC.
• Délai de rentabilisation plus rapide – Atteinte plus rapide des objectifs commerciaux. Contrairement au déploiement traditionnel sur site, vous pouvez utiliser votre service Citrix ADM en quelques clics. Vous économisez non seulement du temps d’installation et de configuration, mais vous évitez également de gaspiller du temps et des ressources sur des erreurs potentielles.
• Gestion multi-site – Vue d’ensemble unique pour les instances réparties sur plusieurs centres de données. Avec le service Citrix ADM, vous pouvez gérer et surveiller les Citrix ADC qui se trouvent dans différents types de déploiements. Vous disposez d’une gestion centralisée pour les Citrix ADC déployés sur site et dans le cloud.
• Efficacité opérationnelle – Méthode optimisée et automatisée pour atteindre une productivité opérationnelle plus élevée. Avec le service Citrix ADM, vos coûts opérationnels sont réduits en économisant votre temps, votre argent et vos ressources sur la maintenance et la mise à niveau des déploiements matériels traditionnels.

Service Graph pour les applications Kubernetes

En utilisant la fonctionnalité de service graph pour les applications cloud-native dans Citrix ADM, vous pouvez :

• Assurer la performance globale de l’application de bout en bout
• Identifier les goulots d’étranglement créés par l’interdépendance des différents composants de vos applications
• Recueillir des informations sur les dépendances des différents composants de vos applications
• Surveiller les services au sein du cluster Kubernetes
• Surveiller quel service rencontre des problèmes
• Vérifier les facteurs contribuant aux problèmes de performance
• Afficher une visibilité détaillée des transactions HTTP de service
• Analyser les métriques HTTP, TCP et SSL

En visualisant ces métriques dans Citrix ADM, vous pouvez analyser la cause première des problèmes et prendre les mesures de dépannage nécessaires plus rapidement. Le graphique de service affiche vos applications dans divers services composants. Ces services exécutés au sein du cluster Kubernetes peuvent communiquer avec divers composants à l’intérieur et à l’extérieur de l’application.

Pour commencer, consultez Configuration du graphique de service.

Graphique de service pour les applications Web à 3 niveaux

À l’aide de la fonctionnalité de graphique de service du tableau de bord de l’application, vous pouvez afficher :

• Détails sur la façon dont l’application est configurée (avec un serveur virtuel de commutation de contenu et un serveur virtuel d’équilibrage de charge)
  • Pour les applications GSLB, vous pouvez afficher le centre de données, l’instance ADC, les serveurs virtuels CS et LB
• Transactions de bout en bout du client au service
• L’emplacement depuis lequel le client accède à l’application
• Le nom du centre de données où les requêtes client sont traitées et les métriques Citrix ADC du centre de données associées (uniquement pour les applications GSLB)
• Détails des métriques pour le client, le service et les serveurs virtuels
• Si les erreurs proviennent du client ou du service
• L’état du service tel que Critique, À réviser et Bon. Citrix ADM affiche l’état du service en fonction du temps de réponse du service et du nombre d’erreurs.
  • Critique (rouge) - Indique lorsque le temps de réponse moyen du service > 200 ms ET le nombre d’erreurs > 0
  • À réviser (orange) - Indique lorsque le temps de réponse moyen du service > 200 ms OU le nombre d’erreurs > 0
  • Bon (vert) - Indique aucune erreur et un temps de réponse moyen du service < 200 ms
• L’état du client tel que Critique, À réviser et Bon. Citrix ADM affiche l’état du client en fonction de la latence du réseau client et du nombre d’erreurs.
  • Critique (rouge)- Indique lorsque la latence moyenne du réseau client > 200 ms ET le nombre d’erreurs > 0
  • À réviser (orange) - Indique lorsque la latence moyenne du réseau client > 200 ms OU le nombre d’erreurs > 0
  • Bon (vert) - Indique aucune erreur et une latence moyenne du réseau client < 200 ms
• L’état du serveur virtuel tel que Critique, À réviser et Bon. Citrix ADM affiche l’état du serveur virtuel en fonction du score de l’application.
  • Critique (rouge) - Indique lorsque le score de l’application < 40
  • À réviser (orange) - Indique lorsque le score de l’application est compris entre 40 et 75
  • Bon (vert) - Indique quand le score de l’application est > 75

Points à noter :

• Seuls les serveurs virtuels d’équilibrage de charge, de commutation de contenu et GSLB sont affichés dans le graphique de service.
• Si aucun serveur virtuel n’est lié à une application personnalisée, les détails ne sont pas visibles dans le graphique de service pour l’application.
• Vous pouvez afficher les métriques pour les clients et les services dans le graphique de service uniquement si des transactions actives se produisent entre les serveurs virtuels et l’application web.
• Si aucune transaction active n’est disponible entre les serveurs virtuels et l’application web, vous ne pouvez afficher les détails dans le graphique de service que sur la base des données de configuration telles que l’équilibrage de charge, la commutation de contenu, les serveurs virtuels GSLB et les services.
• Les mises à jour de la configuration de l’application peuvent prendre 10 minutes pour se refléter dans le graphique de service.

Pour plus d’informations, consultez Graphique de service pour les applications.

Pour commencer, consultez Documentation du graphique de service.

Dépannage pour les équipes Citrix ADC

Examinons certains des attributs les plus courants pour le dépannage de la plateforme Citrix ADC et comment ces techniques de dépannage s’appliquent aux déploiements de niveau 1 pour les topologies de microservices.

Le Citrix ADC dispose d’une interface de ligne de commande (CLI) qui affiche les commandes en temps réel et est utile pour déterminer les configurations d’exécution, les statistiques et la configuration des politiques. Ceci est facilité via la commande « SHOW ».

SHOW - effectuer des opérations CLI ADC :

>Show running config (-summary -fullValues)

 Ability to search (grep command)
>“sh running config | -i grep vserver”

Check the version.
>Show license
  “sh license"
<!--NeedCopy-->

Afficher les statistiques SSL

>Sh ssl
        System
        Frontend
        Backend
        Encryption
<!--NeedCopy-->

Le Citrix ADC dispose d’une commande pour énumérer les statistiques de tous les objets basées sur un intervalle de compteur de sept (7) secondes. Ceci est facilité via la commande « STAT ».

Télémétrie L3-L7 très granulaire par Citrix ADC

• Niveau système : Utilisation du CPU et de la mémoire de l’ADC.
• Protocole HTTP : #Requêtes/Réponses, répartition GET/POST, erreurs HTTP pour N-S et E-O (pour service mesh lite uniquement, sidecar bientôt).
• SSL : #Sessions et #Négociations pour le trafic N-S et E-O pour service mesh lite uniquement.
• Protocole IP : #Paquets reçus/envoyés, #Octets reçus/envoyés, #Paquets tronqués et #Recherche d’adresse IP.
• Citrix ADC AAA : #Sessions actives
• Interface : #Paquets multicast totaux, #Octets transférés totaux et #Paquets Jumbo reçus/envoyés.
• Serveur virtuel d’équilibrage de charge et serveur virtuel de commutation de contenu : #Paquets, #Accès et #Octets reçus/envoyés.

STAT - effectuer des opérations CLI ADC :

>Statistics
“stat ssl”
<!--NeedCopy-->

Le Citrix ADC dispose d’une structure d’archive de journaux qui permet la recherche de statistiques et de compteurs lors du dépannage d’erreurs spécifiques via la commande « NSCONMSG ».

NSCONMSG - fichier journal principal (format de données ns)

    Cd/var/nslog

    “Mac Moves”
    nsconmsg -d current -g nic_err
<!--NeedCopy-->

Nstcpdump

Vous pouvez utiliser nstcpdump pour le dépannage de bas niveau. nstcpdump collecte des informations moins détaillées que nstrace. Ouvrez l’interface de ligne de commande (CLI) de l’ADC et tapez shell. Vous pouvez utiliser des filtres avec nstcpdump mais vous ne pouvez pas utiliser de filtres spécifiques aux ressources ADC. La sortie du dump peut être visualisée directement dans l’écran de la CLI.

CTRL + C – Appuyez simultanément sur ces touches pour arrêter un nstcpdump.

nstcpdump.sh dst host x.x.x.x – Affiche le trafic envoyé à l’hôte de destination.

nstcpdump.sh -n src host x.x.x.x – Affiche le trafic provenant de l’hôte spécifié et ne convertit pas les adresses IP en noms (-n).

nstcpdump.sh host x.x.x.x – Affiche le trafic vers et depuis l’adresse IP de l’hôte spécifié.

NSTRACE - fichier de trace de paquets

NSTRACE est un outil de débogage de paquets de bas niveau pour le dépannage des réseaux. Il vous permet de stocker des fichiers de capture que vous pouvez analyser plus en détail à l’aide des outils d’analyse. Deux outils courants sont Network Analyzer et Wireshark.

Une fois le fichier de capture NSTRACE créé dans /var/nstrace sur l’ADC, vous pouvez importer le fichier de capture dans Wireshark pour la capture de paquets et l’analyse réseau.

SYSCTL - Informations détaillées sur l’ADC (Description, Modèle, Plateforme, CPU, etc.)

    sysctl -a grep hw.physmem

    hw.physmem: 862306304
    netscaler.hw_physmem_mb: 822
<!--NeedCopy-->

aaad.debug - Ouvrir le canal pour les informations de débogage d’authentification

Pour plus d’informations sur la façon de dépanner les problèmes d’authentification via ADC ou ADC Gateway avec le module aaad.debug, consultez cet article de support aaad.debug.

Il est également possible d’obtenir directement des statistiques de performance et des journaux d’événements pour l’ADC. Pour plus d’informations à ce sujet, consultez ce document de support ADC.

Dépannage pour les équipes SRE et Plateformes

Flux de trafic Kubernetes

Nord/Sud :

• Le trafic nord/sud est le trafic circulant de l’utilisateur vers le cluster, via l’ingress.

Est/Ouest :

• Le trafic est/ouest est le trafic circulant au sein du cluster Kubernetes : de service à service ou de service à base de données.

Comment Citrix ADC CPX équilibre la charge du trafic Est-Ouest dans un environnement Kubernetes

Après avoir déployé le cluster Kubernetes, vous devez l’intégrer à ADM en fournissant les détails de l’environnement Kubernetes dans ADM. ADM surveille les modifications des ressources Kubernetes, telles que les services, les points de terminaison et les règles Ingress.

Lorsque vous déployez une instance ADC CPX dans le cluster Kubernetes, elle s’enregistre automatiquement auprès d’ADM. Dans le cadre du processus d’enregistrement, ADM apprend l’adresse IP de l’instance CPX et le port sur lequel elle peut atteindre l’instance pour la configurer à l’aide des API REST NITRO.

La figure suivante montre comment ADC CPX équilibre la charge du trafic est-ouest dans un cluster Kubernetes.

Dans cet exemple,

Le nœud 1 et le nœud 2 des clusters Kubernetes contiennent des instances d’un service frontal et d’un service dorsal. Lorsque les instances ADC CPX sont déployées dans le nœud 1 et le nœud 2, les instances ADC CPX sont automatiquement enregistrées auprès d’ADM. Vous devez intégrer manuellement le cluster Kubernetes à ADM en configurant les détails du cluster Kubernetes dans ADM.

Lorsqu’un client demande le service frontal, la ressource d’entrée équilibre la charge de la requête entre les instances du service frontal sur les deux nœuds. Lorsqu’une instance du service frontal a besoin d’informations des services back-end du cluster, elle dirige les requêtes vers l’instance ADC CPX de son nœud. Cette instance ADC CPX équilibre la charge des requêtes entre les services back-end du cluster, assurant un flux de trafic est-ouest.

Graphique de service ADM pour les applications

La fonctionnalité de graphique de service dans Citrix ADM vous permet de surveiller tous les services sous forme de représentation graphique. Cette fonctionnalité fournit également une analyse détaillée et des métriques utiles. Vous pouvez afficher les graphiques de service pour :

• Applications configurées sur toutes les instances Citrix ADC
• Applications Kubernetes
• Applications Web à 3 niveaux

Pour commencer, consultez les détails du graphique de service.

Afficher les compteurs d’applications de microservices

Le graphique de service affiche également toutes les applications de microservices appartenant aux clusters Kubernetes. Passez le pointeur de la souris sur un service pour afficher les détails des métriques.

Vous pouvez afficher :

• Le nom du service
• Le protocole utilisé par le service, tel que SSL, HTTP, TCP, SSL sur HTTP
• Requêtes – Le nombre total de requêtes reçues par le service
• Temps de réponse du service – Le temps de réponse moyen du service. (Temps de réponse = RTT client + dernier octet de la requête – premier octet de la requête)
• Erreurs – Le nombre total d’erreurs, telles que 4xx, 5xx, etc.
• Volume de données – Le volume total de données traitées par le service
• Espace de noms – L’espace de noms du service
• Nom du cluster – Le nom du cluster où le service est hébergé
• Erreurs de serveur SSL – Le total des erreurs SSL provenant du service

Ces compteurs spécifiques et journaux de transactions peuvent être extraits via le Citrix Observability Exporter (COE) en utilisant une gamme de points de terminaison pris en charge. Pour plus d’informations sur le COE, consultez les sections suivantes.

Exportateur pour les statistiques Citrix ADC

Il s’agit d’un serveur simple qui récupère les statistiques Citrix ADC et les exporte via HTTP vers Prometheus. Prometheus peut ensuite être ajouté en tant que source de données à Grafana pour afficher graphiquement les statistiques Citrix ADC.

Pour surveiller les statistiques et les compteurs des instances Citrix ADC, citrix-adc-metric-exporter peut être exécuté en tant que conteneur ou script. L’exportateur collecte les statistiques Citrix ADC telles que le nombre total d’accès à un serveur virtuel, le taux de requêtes HTTP, le taux de chiffrement-déchiffrement SSL, etc., à partir des instances Citrix ADC et les conserve jusqu’à ce que le serveur Prometheus récupère les statistiques et les stocke avec un horodatage. Grafana peut ensuite être configuré pour pointer vers le serveur Prometheus afin de récupérer les statistiques, de les tracer, de définir des alarmes, de créer des cartes thermiques, de générer des tableaux, et ainsi de suite, selon les besoins pour analyser les statistiques Citrix ADC.

Les détails sur la configuration de l’exportateur pour fonctionner dans un environnement tel que présenté dans la figure sont fournis dans les sections suivantes. Une note sur les entités/métriques Citrix ADC que l’exportateur récupère par défaut et comment les modifier est également expliquée.

Pour plus d’informations sur l’exportateur pour Citrix ADC, consultez le Metrics Exporter GitHub.

Traçage distribué du service ADM

Dans le graphique de service, vous pouvez utiliser la vue de traçage distribué pour :

• Analyser les performances globales du service.
• Visualiser le flux de communication entre le service sélectionné et ses services interdépendants.
• Identifier quel service indique des erreurs et dépanner le service erroné
• Afficher les détails des transactions entre le service sélectionné et chaque service interdépendant.

Prérequis pour le traçage distribué ADM

Pour afficher les informations de trace du service, vous devez :

• Assurez-vous qu’une application maintient les en-têtes de trace suivants lors de l’envoi de trafic est-ouest :

• Mettez à jour le fichier YAML CPX avec NS_DISTRIBUTED_TRACING et la valeur YES. Pour commencer, consultez Traçage distribué.

Analyse de Citrix Observability Exporter (COE)

Citrix Observability Exporter est un conteneur qui collecte les métriques et les transactions des Citrix ADC et les transforme en formats appropriés (tels que JSON, AVRO) pour les points de terminaison pris en charge. Vous pouvez exporter les données collectées par Citrix Observability Exporter vers le point de terminaison souhaité. En analysant les données exportées vers le point de terminaison, vous pouvez obtenir des informations précieuses au niveau des microservices pour les applications mises en proxy par les Citrix ADC.

Pour plus d’informations sur COE, consultez le GitHub de COE.

COE avec Elasticsearch comme point de terminaison de transaction

Lorsque Elasticsearch est spécifié comme point de terminaison de transaction, Citrix Observability Exporter convertit les données au format JSON. Sur le serveur Elasticsearch, Citrix Observability Exporter crée des index Elasticsearch pour chaque ADC sur une base horaire. Ces index sont basés sur la date, l’heure, l’UUID de l’ADC et le type de données HTTP (http_event ou http_error). Ensuite, Citrix Observability Exporter télécharge les données au format JSON sous les index de recherche Elastic pour chaque ADC. Toutes les transactions régulières sont placées dans l’index http_event et toutes les anomalies sont placées dans l’index http_error.

Prise en charge du traçage distribué avec Zipkin

Dans une architecture de microservices, une seule requête d’utilisateur final peut s’étendre sur plusieurs microservices, ce qui rend le suivi d’une transaction et la correction des sources d’erreurs difficiles. Dans de tels cas, les méthodes traditionnelles de surveillance des performances ne peuvent pas identifier avec précision où les défaillances se produisent et quelle est la raison des mauvaises performances. Vous avez besoin d’un moyen de capturer des points de données spécifiques à chaque microservice traitant une requête et de les analyser pour obtenir des informations significatives.

Le traçage distribué relève ce défi en offrant un moyen de suivre une transaction de bout en bout et de comprendre comment elle est gérée à travers plusieurs microservices.

OpenTracing est une spécification et un ensemble standard d’API pour la conception et la mise en œuvre du traçage distribué. Les traceurs distribués vous permettent de visualiser le flux de données entre vos microservices et aident à identifier les goulots d’étranglement dans votre architecture de microservices.

Citrix Observability Exporter implémente le traçage distribué pour Citrix ADC et prend actuellement en charge Zipkin en tant que traceur distribué.

Actuellement, vous pouvez surveiller les performances au niveau de l’application à l’aide de Citrix ADC. En utilisant Citrix Observability Exporter avec Citrix ADC, vous pouvez obtenir des données de traçage pour les microservices de chaque application proxifiée par votre Citrix ADC CPX, MPX ou VPX.

Pour commencer, consultez le GitHub Observability Exporter.

Zipkin pour le débogage d’applications

Zipkin est un système de traçage distribué open source basé sur le document de Dapper de Google. Dapper est le système de Google pour son traçage distribué en production. Google l’explique dans son document : « Nous avons créé Dapper pour fournir aux développeurs de Google plus d’informations sur le comportement des systèmes distribués complexes ». L’observation du système sous différents angles est essentielle lors du dépannage, surtout lorsqu’un système est complexe et distribué.

Les données de trace Zipkin suivantes identifient un total de 5 spans et 5 services liés à l’application exemple Watches. Les données de trace montrent les données de span spécifiques à travers les 5 microservices.

Pour commencer, consultez le Zipkin suivant.

Exemple de span Zipkin montrant la latence de l’application pour la requête de chargement initial de la page :

Kibana pour la visualisation des données

Kibana est une interface utilisateur ouverte qui vous permet de visualiser vos données Elasticsearch et de naviguer dans l’Elastic Stack. Faites tout, du suivi de la charge des requêtes à la compréhension du flux des requêtes dans vos applications.

Que vous soyez analyste ou administrateur, Kibana rend vos données exploitables en offrant les trois fonctions clés suivantes :

• Une plateforme d’analyse et de visualisation open source. Utilisez Kibana pour explorer vos données Elasticsearch, puis créez de superbes visualisations et tableaux de bord.
• Une interface utilisateur pour gérer l’Elastic Stack. Gérez vos paramètres de sécurité, attribuez des rôles d’utilisateur, prenez des instantanés, regroupez vos données, et bien plus encore — le tout depuis la commodité d’une interface utilisateur Kibana.
• Un hub centralisé pour les solutions d’Elastic. De l’analyse des journaux à la découverte de documents en passant par le SIEM, Kibana est le portail pour accéder à ces capacités et à d’autres.

Kibana est conçu pour utiliser Elasticsearch comme source de données. Considérez Elasticsearch comme le moteur qui stocke et traite les données, avec Kibana en surcouche.

Depuis la page d’accueil, Kibana offre ces options pour ajouter des données :

• Importez des données à l’aide du visualiseur de données de fichier.
• Configurez un flux de données vers Elasticsearch à l’aide de nos tutoriels intégrés. Si un tutoriel n’existe pas pour vos données, consultez la présentation de Beats pour en savoir plus sur les autres expéditeurs de données de la famille Beats.
• Ajoutez un jeu de données d’exemple et testez Kibana sans charger les données vous-même.
• Indexez vos données dans Elasticsearch avec les API REST ou les bibliothèques clientes.

Kibana utilise un modèle d’index pour lui indiquer quels index Elasticsearch explorer. Si vous téléchargez un fichier, exécutez un tutoriel intégré ou ajoutez des données d’exemple, vous obtenez un modèle d’index gratuitement et vous êtes prêt à commencer l’exploration. Si vous chargez vos propres données, vous pouvez créer un modèle d’index dans Stack Management.

Étape 1 : Configurer le modèle d’index pour Logstash

Étape 2 : Sélectionnez l’index et générez du trafic pour le remplir.

Étape 3 : générer une application à partir des données non structurées des flux de journaux.

Étape 4 : Kibana formate l’entrée Logstash pour créer des rapports et des tableaux de bord.

• Plage horaire
• Vue tabulaire
• Nombre de requêtes basé sur l’application.
  • Heure IP, Agent, Machine.OS, Code de réponse (200), URL
  • Filtrer sur les valeurs

Étape 5 : Visualiser les données dans un rapport d’agrégations.

• Agrégation des résultats dans un rapport graphique (circulaire, graphique, etc.)