Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Mode sans échec du contrôleur NorthStar

La base de données Cassandra est un composant clé du fonctionnement du contrôleur NorthStar, avec ou sans haute disponibilité. La perte de connectivité à la base de données Cassandra entraîne une interruption de service pour les utilisateurs de l’interface NorthStar vers le nord, car l’interface utilisateur Web et l’API REST deviennent indisponibles. Dans ce cas, NorthStar passe en mode de sécurité intégrée qui permet aux utilisateurs de conserver une visibilité du réseau via NorthStar et d’activer les fonctions de base de NorthStar jusqu’à ce que le problème de la base de données Cassandra puisse être corrigé.

Note:

Étant donné qu’Apache Cassandra est un logiciel open source, les stratégies de dépannage de Cassandra sont bien documentées ailleurs. Voici quelques exemples de sites Web :

Dans le cas d’une simple perte de connectivité à la base de données Cassandra, les processus NorthStar sont en fait toujours en cours d’exécution, et il n’y a pas d’interruption de service pour les LSP contrôlés par NorthStar ou pour les LSP nouvellement délégués créés sur les routeurs. Toutefois, lorsque vous tentez d’accéder à l’interface utilisateur Web de NorthStar, un message d’erreur s’affiche :

Lorsque cette erreur est détectée par le serveur Web (nodejs), il passe en mode sans échec afin que les utilisateurs puissent avoir un accès en lecture seule.

La perte de connectivité à Cassandra peut être aggravée par le redémarrage des processus pour tenter de résoudre le problème. Le redémarrage des processus NorthStar peut sembler être une étape de dépannage naturelle à suivre lorsque vous ne pouvez pas accéder à l’interface utilisateur Web ou à l’API REST. Mais si l’interface utilisateur Web et l’API REST ne sont pas disponibles en raison d’une perte de connectivité à Cassandra, le redémarrage de Toposerver et du serveur Web ne peut pas réussir. Il en résulte une interruption de service pour les prestataires de services linguistiques contrôlés par NorthStar. De plus, le redémarrage des processus NorthStar ne résout pas le problème de connectivité Cassandra.

Dans ce cas, le serveur Web et le Toposerver passent en mode de sécurité intégrée, offrant un accès en lecture seule. Toposerver charge la topologie du réseau à partir du dernier instantané réseau enregistré dans le système de fichiers.

Fonctionnalité du mode sans échec

Le déclencheur du mode sans échec est que la base de données Cassandra n’est pas disponible. En l’absence de Cassandra, le mode sans échec ne peut pas émuler toutes les fonctionnalités de NorthStar, mais il offre les fonctionnalités suivantes :

  • Le serveur PCEP et le serveur de calcul de chemin (PCS) continuent de fonctionner. Le serveur Web (nodejs), Toposerver et task_scheduler restent en cours d’exécution, mais en mode de sécurité intégrée.

  • Même si la base de données Cassandra a été corrompue, le mode sans échec fonctionne.

  • Même si un seul serveur d’un cluster NorthStar est opérationnel, le mode sans échec fonctionne.

  • Une page d’accueil en mode sans échec est fournie dans l’interface utilisateur Web de NorthStar. Une connexion d’utilisateur administrateur est requise pour accéder à la page de destination. La figure 1 montre la page d’accueil du mode sans échec. Notez le changement de couleur de la barre de menu supérieure et la notation (Safe Mode), dans le coin supérieur droit.

    Figure 1 : page Fail-Safe Mode Landing Page d’accueil du mode sans échec

  • En mode de sécurité intégrée, les LSP délégués existants ou initiés par PCE peuvent être réacheminés par le PCS en cas de panne de réseau.

  • Toposerver n’utilise pas la base de données Cassandra pour charger le modèle de réseau. Au lieu de cela, il charge le modèle de réseau en fonction du dernier instantané réseau collecté par le système de fichiers NorthStar. Pendant le fonctionnement normal de NorthStar, le système de fichiers collecte et stocke des instantanés réseau toutes les heures (par défaut).

  • Si le basculement HA se produit alors que Cassandra est inaccessible, l’agent HA est toujours en mesure d’élire un nœud actif dans le cadre du mode de sécurité intégrée. Les processus NorthStar à partir du nouveau nœud actif démarrent en mode de sécurité lorsqu’ils découvrent que Cassandra n’est pas disponible.

  • En mode de sécurité intégrée, l’état du cluster NorthStar s’affiche pour tous les utilisateurs via une bannière dans l’interface utilisateur Web. La fonction de rapports sur l’intégrité de NorthStar signale également l’état des nuds, même lorsqu’ils sont en panne.

Limites du mode sans échec

Le mode sans échec est destiné à une utilisation temporaire jusqu’à ce que la base de données Cassandra puisse être restaurée, et présente donc les limitations suivantes :

  • Vous ne pouvez pas provisionner, ajouter ou supprimer de nouveaux LSP.

  • Il n’y a aucune garantie qu’un instantané du réseau soit disponible. Si un instantané n’est pas disponible (peut-être en raison de la synchronisation de la création d’instantanés toutes les heures et des activités de basculement HA), seules les données en direct peuvent être visualisées dans le contrôleur NorthStar. Aucune propriété définie par l’utilisateur ne peut être chargée et prise en compte par NorthStar.

  • Une fois que vous avez restauré le cluster en fonctionnement normal, vous devez quitter manuellement le mode de sécurité intégrée en redémarrant nodejs (infra :web), Toposerver et task_scheduler :