Vue d'ensemble
Le SLA de connectivité Cato pour le tunnel assure des performances optimales et une résilience des flux d'applications 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/descendant. L'algorithme surveille constamment les KPI’s SLA tels que la perte de paquets, la latence, la congestion, le statut des ports, le statut de la connectivité Internet, et le Socket peut déplacer les flux de manières transparentes entre les liens si une dégradation du SLA est détectée.
La performance du lien est classée comme soit acceptable, soit inacceptable en fonction des seuils de perte de paquets, 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 à un autre PoP. Comprendre comment le Socket réagit à la dégradation du SLA est essentiel pour garantir une livraison d'application fiable.
Le Socket distribue de manière optimale le trafic entre tous les liens actifs, y compris les liens avec des capacités de bande passante différentes et bande passante amont/descendant asymétriques. Le mécanisme SLA de connectivité du Socket est programmé pour réagir à tout problème de connectivité et prendre des mesures pour surmonter automatiquement le problème. Dans des situations où le SLA de connectivité devient inacceptable et qu'il ne peut pas atteindre les seuils, le Socket et le PoP prennent des mesures pour réparer la connectivité. Par exemple, le Socket active les liens passifs. Si ces actions ne résolvent pas le problème de connectivité, le Socket se connectera à un PoP différent.
Nous recommandons d'utiliser la configuration active/active pour les sites Socket pour la meilleure résilience et performance. Pour plus d'informations, voir Architecture du SLA des liens Socket Cato.
Personnalisation des seuils SLA pour les sites actifs/passifs
La page SLA de Connexion vous permet de définir des seuils SLA acceptables et inacceptables qui sont appliqués aux sites Socket dans des déploiements actifs/passifs.
Lorsqu'il y a un SLA inacceptable pour le lien principal dans un site, le Socket active le lien passif secondaire et envoie le trafic dessus au PoP. Lorsque le lien principal retrouve un SLA acceptable, le Socket rétablit les flux vers le lien principal, et le lien secondaire est désactivé.
Personnalisation des seuils SLA pour les sites actifs/actifs
La page SLA de Connexion vous permet également de définir des seuils SLA acceptables et inacceptables pour les déploiements actifs/actifs. Pour plus d'informations sur la distribution du trafic et la configuration de seuils personnalisés pour les sites actifs/actifs, voir Configurer les paramètres du SLA de Connexion pour les sites actifs/actifs.
Opération dans un SLA acceptable
Dans le SLA acceptable, le Socket utilise tous les liens actifs et sélectionne le meilleur lien pour chaque nouveau flux basé sur 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 : Interfaces et 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 un SLA acceptable
Les exemples suivants montrent des configurations de sites Socket où le seuil SLA inacceptable est fixé à une perte de paquets de 10 %. Le Lien 1 connaît une perte de paquets de 3 %, et le lien 2 a une perte de paquets de 0 %.
|
|
Opération avec des SLA inacceptables
Lorsque le Socket détermine que tous les liens actifs ne satisfont 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 des liens et les paramètres SLA de Connexion, le Socket activera un lien passif de moindre priorité, ou si aucun des liens ne répond aux seuils de SLA acceptables, il connecte tous les liens à un PoP différent.
Exemple d'actions de remède pour un SLA inacceptable
Les exemples suivants montrent des configurations de site Socket où le seuil de SLA inacceptable est fixé à une perte de paquets de 10 %. Le Lien 1 connaît une perte de paquets de 15 %, et le lien 2 a une perte de paquets de 0 %. Ces exemples sont pendant la période d'évaluation où le PoP utilise des mécanismes d'auto-guérison.
|
|
Exemple de connexion à un PoP différent pour un SLA de connectivité inacceptable
Si les actions de remédiation pendant la période d'évaluation ne résolvent pas les problèmes de connectivité, alors le Socket se connecte à un PoP différent. Par exemple, s'il y a un problème avec le fournisseur de cloud de niveau 1 pour l'emplacement PoP.
Lorsqu'un Socket se connecte à un nouveau PoP, voici le comportement :
Le Socket commence la période d'évaluation initiale du SLA de connectivité jusqu'à 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 entre 40 - 50 secondes.
Si les liens vers le PoP ont un SLA acceptable, le Socket reste connecté au PoP.
Si les liens vers le PoP ont un SLA inacceptable, le Socket se connecte à un PoP différent et répète la période d'évaluation initiale du SLA de connectivité jusqu'à 40 - 50 secondes.
Si le Socket ne peut pas localiser un PoP avec un SLA acceptable, il retourne et se connecte au PoP original.
Les exemples suivants montrent des configurations de site Socket où le seuil de SLA inacceptable est fixé à une perte de paquets de 10 %. Le Lien 1 connaît 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 tier 1. Le deuxième diagramme montre comment se connecter à un PoP différent résout le problème. Le comportement est le même pour les déploiements de site actif/actif et actif/passif.
|
|
Reconnexion au PoP original
Pour des performances optimales et une latence la plus faible, il est toujours recommandé que le Socket se connecte à l'emplacement physique 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 60 minutes. Le Socket vérifiera que le PoP préféré est disponible et fournit un bon service avant de se reconnecter à lui. 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.