Comprendre les SLA acceptables et inacceptables pour les sites

Le SLA de connectivité Cato pour le dernier kilomètre assure performance optimale et résilience des flux d'applications du site. Le Socket et le PoP connecté utilisent des algorithmes de sélection de chemin basés sur le SLA en temps réel pour choisir le lien optimal pour chaque flux dans les directions amont et aval. L'algorithme surveille en permanence les indicateurs clés de performance SLA tels que la perte de paquets, la latence, la congestion, l'état des ports, la connectivité Internet, et le Socket peut déplacer sans interruption les flux entre les liens si une dégradation du SLA est détectée.

Les performances du lien sont classées comme acceptables ou inacceptables en fonction des seuils de perte de paquets, de latence et d'autres métriques. Cette classification détermine quand le Socket utilise le lien WAN actif, active un lien de secours ou initie une connexion avec un autre PoP. Comprendre comment le Socket réagit à la dégradation du SLA est essentiel pour garantir une distribution fiable des applications.

Le Socket répartit de manière optimale le trafic entre tous les liens actifs, y compris les liens ayant différentes capacités de bande passante et bande passante asymétrique en amont/aval. Le mécanisme SLA de connectivité du Socket est programmé pour réagir à tout problème de connectivité et prendre des mesures pour le surmonter automatiquement. Dans les situations où le SLA de connectivité devient inacceptable et ne peut pas satisfaire les seuils, le Socket et le PoP prennent des mesures pour réparer la connectivité. Par exemple, le Socket activera les liens passifs. Si ces actions ne résolvent pas le problème de connectivité, le Socket se connectera à un autre PoP.

Nous recommandons d'utiliser la configuration active/active pour les sites Socket afin d'assurer une résistance et une performance optimales. Pour plus d'informations, voir Architecture du lien SLA du Socket Cato.

Dans le cadre du SLA acceptable, le Socket utilise tous les liens actifs et sélectionne le meilleur lien pour chaque nouveau flux en fonction d'un score de santé calculé en temps réel. Ces métriques KPI SLA incluent : perte de paquets, latence, gigue, congestion, et plus. Pour plus d'informations, voir Partie 1 : Les interfaces et la priorité du Socket.

Pour les configurations actives/passives, les liens passifs restent inactifs tant qu'il y a au moins un lien actif avec un SLA acceptable.

Exemple de perte de paquets dans le cadre du SLA acceptable

Les exemples suivants montrent des configurations de site Socket où le seuil de SLA inacceptable est fixé à 10% de perte de paquets. Le lien 1 subit une perte de paquets de 3 %, et le lien 2 n'a aucune perte de paquets.

Pour les nouveaux flux, le Socket ou PoP choisit le lien de meilleure qualité Dans l'exemple ci-dessus, de nouveaux flux s'ouvriraient sur le lien 2 avec aucune perte de paquets

Le lien 2 (le lien passif) n'est pas activé car le lien 1 respecte le seuil de SLA acceptable. Tous les flux continuent d'utiliser le lien actif.

Lorsque le Socket détermine que tous les liens actifs ne respectent pas le SLA sur la plage de temps, cela est considéré comme un SLA inacceptable, et le Socket prend automatiquement des mesures pour remédier aux problèmes de connectivité. Selon la configuration du lien et les paramètres SLA de connexion, le Socket activera un lien passif de moindre priorité, ou si aucun des liens ne respecte les seuils de SLA acceptables, il connecte tous les liens à un autre PoP.

Exemple d'actions de remédiation pour un SLA inacceptable

Les exemples suivants montrent des configurations de site Socket où le seuil de SLA inacceptable est fixé à 10% de perte de paquets. Le lien 1 subit une perte de paquets de 15 % et le lien 2 n'a aucune perte de paquets. Ces exemples sont durant la période d'évaluation où le PoP utilise des mécanismes d'auto-guérison.

Pour les nouveaux flux, le Socket ou PoP choisit le lien de meilleure qualité Pour les flux existants, le Socket déplace progressivement les flux vers le lien de meilleure qualité Dans l'exemple ci-dessus, les flux se déplaceraient vers le lien 2 avec aucune perte de paquets

Le lien passif (lien 2) est activé La Socket fonctionne maintenant en configuration active/active Les nouveaux flux utilisent le lien 2 Les flux existants se déplacent progressivement du lien 1 vers le lien 2 Pour les configurations où le lien 2 est un lien de dernier recours, le minuteur de grâce commence à compter Le temps de grâce donne un temps supplémentaire pour résoudre les problèmes de connectivité avant d'activer le lien cellulaire Si un SLA acceptable n'est pas rétabli sur le lien 1 durant le temps de grâce, alors le lien 2 (le lien de dernier recours) est activé

Exemple de connexion à un autre PoP pour un SLA de connectivité inacceptable

Si les actions de remédiation durant la période d'évaluation ne résolvent pas les problèmes de connectivité, alors le Socket se connecte à un autre PoP. Par exemple, s'il y a un problème avec le fournisseur de cloud de niveau 1 pour l'emplacement du PoP.

Lorsqu'une Socket se connecte à un nouveau PoP, voici le comportement :

1. Le Socket démarre la période d'évaluation initiale du SLA de connectivité d'une durée maximale de 40 à 50 secondes.

   La période d'évaluation du SLA est de 40 secondes, et elle est vérifiée toutes les 10 secondes, cela signifie que le temps total de la période d'évaluation est compris entre 40 et 50 secondes.

   1. Si les liens au PoP ont un SLA acceptable, le Socket reste connecté au PoP.

   2. Si les liens au PoP ont un SLA inacceptable, le Socket se connecte à un autre PoP et répète la période d'évaluation initiale du SLA de connectivité d'une durée maximale de 40 à 50 secondes.

2. Si le Socket ne peut pas localiser un PoP avec un SLA acceptable, il retourne et se connecte au PoP d'origine.

Les exemples suivants montrent des configurations de site Socket où le seuil de SLA inacceptable est fixé à 10% de perte de paquets. Le lien 1 subit une perte de paquets de 20 %, et le lien 2 a une perte de paquets de 15 % en raison de problèmes de connectivité avec le fournisseur de niveau 1. Le deuxième diagramme montre comment la connexion à un autre PoP résout le problème. Le comportement est le même pour les déploiements de sites actifs/actifs et actifs/passifs.

Après la période d'évaluation, il y a un SLA inacceptable (plus de 10% de perte de paquets) sur tous les liens actifs Par exemple, la perte de paquets liée au fournisseur de services de niveau 1

La Socket se connecte au prochain meilleur PoP Après 40 à 50 secondes, le Socket confirme que les liens respectent le SLA acceptable Un événement de reconnexion est généré

Pour obtenir des performances optimales et une latence minimale, il est toujours recommandé que le Socket se connecte à l'emplacement physique du PoP le plus proche. Si le Socket se déplace vers un emplacement PoP différent, en raison de problèmes de SLA avec le PoP principal, il tentera automatiquement de se reconnecter à l'emplacement PoP préféré (le PoP le plus proche du site) dans les 60 minutes. Le Socket vérifiera que le PoP préféré est disponible et offre un bon service avant de s'y reconnecter. Vous pouvez également choisir de reconnecter manuellement le Socket au PoP préféré, voir Définir un PoP préféré pour un site.