Caractéristiques de la plate-forme

Multilocation avec RBAC

La plate-forme CSO prend en charge la mutualisation intégrée, ce qui permet à plusieurs locataires de coexister sur le système. La mutualisation est basée sur le modèle OpenStack Keystone . Dans ce modèle, chaque objet de la base de données appartient à un locataire spécifique et se voit attribuer un ID de locataire. Lorsqu’un administrateur se voit attribuer certains rôles à un locataire spécifique, il est autorisé avec certains droits sur tous les objets appartenant à ce locataire.

Le serveur applique la mutualisation RBAC au niveau de l’API. Un utilisateur doit d’abord s’authentifier auprès du microservice IAM (Identity and Access Management) de CSO pour acquérir le jeton d’accès avant que les API CSO puissent être appelées. À chaque appel d’API, le serveur API applique la zone RBAC mutualisée en s’assurant que l’ID de locataire de l’objet correspond aux ID de locataire affectés dans le jeton d’accès, et que l’URI REST est défini dans les rôles attribués.

RBAC dans CSO est basé sur des objets. Pour simplifier l’application RBAC, CSO dispose de rôles utilisateur prédéfinis qui fournissent aux utilisateurs affectés à ces rôles un accès en lecture seule ou en lecture et écriture à des objets spécifiques. Les rôles personnalisés permettent aux administrateurs d’accorder aux utilisateurs des privilèges d’accès supplémentaires à ces objets ou à d’autres objets spécifiques.

Haute disponibilité et évolutivité

Comme indiqué ci-dessus, l’architecture d’installation CSO pour les petits environnements ne fournit pas de HA. La petite configuration comprend une instance d’une machine virtuelle centrale et une instance d’une machine virtuelle régionale ; toute défaillance de VM rend CSO non opérationnel. CSO peut également évoluer vers des environnements plus vastes, en utilisant plusieurs serveurs avec équilibrage de charge entre eux. Ces serveurs fonctionnent généralement en mode HA actif/actif, et les services sont dupliqués entre les serveurs. La perte d’un serveur n’affecte pas la fonctionnalité CSO.

Un principe clé de conception est qu’il n’y a pas d’état en mémoire. Tous les états sont transactionnels et gérés dans une base de données à l’aide d’un gestionnaire de tâches. CSO veille à ce qu’en cas de défaillance d’un nœud, le gestionnaire des tâches détecte automatiquement la tâche incomplète et affecte le processus à un autre serveur pour traitement.

Tous les services d’infrastructure CSO, tels que les services de base de données et les bus de messages, utilisent un logiciel open source éprouvé qui prend en charge le clustering multi-nœuds pour la haute disponibilité et l’évolutivité. Ces clusters de services d’infrastructure sont parfaitement conçus pour un déploiement à grande échelle. La principale base de données d’analyse et de configuration CSO repose sur Cassandra, connue pour son évolutivité et sa tolérance aux pannes sur les matériels grand public et dans les environnements cloud.

Tous les microservices CSO sont sans état et ne détiennent aucun état entre les appels d’API. Les états de l’application sont conservés dans la base de données. Les microservices communiquent entre eux uniquement via les API REST ou le bus de messages hautement disponible. Les API REST des microservices sont conçues pour être idempotentes (faire un même appel à plusieurs reprises produit le même résultat) et très tolérantes aux pannes sur le matériel de base ou les environnements cloud. Les microservices CSO sont regroupés sous forme de conteneurs Docker et orchestrés par Kubernetes. En raison de sa nature sans état et de ses API idempotentes, chaque microservice peut évoluer de manière linéaire et indépendante. Kubernetes permet à chaque microservice d’augmenter ou de diminuer automatiquement en fonction de l’utilisation du processeur. Kubernetes peut également surveiller l’intégrité des instances de microservice CSO et réparer automatiquement les instances ayant échoué.

La plateforme CSO peut être déployée sur site, dans une infrastructure cloud hybride ou publique. Lorsqu’elle est déployée sur plusieurs zones de disponibilité du cloud public ou privé, la plate-forme peut survivre aux pannes d’alimentation et de réseau dans tous les centres.

Programmabilité et intégration

Tous les microservices CSO rendent leurs fonctionnalités accessibles via des API RESTful. Certaines de ces API sont destinées à être utilisées par d’autres microservices ou applications s’exécutant sur CSO, mais la plupart sont exposées à être consommées par des systèmes externes, tels que les applications OSS/BSS Northbound. Cela permet aux fournisseurs et aux clients finaux d’automatiser diverses tâches, processus et flux de travail en appelant ces API à partir de scripts ou de systèmes backend. Toutes les API de microservices sont générées à partir de descriptions de modèles de données dans YANG et peuvent être classées à un niveau élevé comme suit :

• API CRUD pour créer, lire, mettre à jour et supprimer des ressources dans le système. Il s’agit d’API synchrones qui renvoient l’état et les détails à l’aide de HTTP. L’appelant peut définir une topologie de locataire, ajouter ou supprimer des sites à cette topologie, activer l’activation sans intervention des appareils sur le site du client, configurer les connexions réseau définies dans la topologie, activer la configuration des appareils locaux par l’utilisateur final, surveiller l’état des appareils et des liaisons, etc.

• API RPC (Remote Procedure Call) pour effectuer des opérations sur ces ressources. Il s’agit généralement d’API asynchrones qui renvoient l’état d’achèvement et les résultats à l’aide de notifications AMQP (Advanced Message Queuing Protocol). L’appelant peut spécifier un échange et une clé de routage pour le message de réponse, et le microservice CSO publie la notification de résultat à cet échange à l’aide de la clé de routage spécifiée.

Les microservices CSO publient également divers messages sur certains échanges documentés créés dans le serveur AMQP, y compris divers événements et alertes de changement d’état des ressources. Les systèmes externes peuvent consommer ces messages et effectuer diverses tâches, ce qui leur permet de créer des tâches d’automatisation basées sur les événements. On peut configurer de nouvelles règles dans le microservice FMPM pour générer des alertes spécifiques et aussi poster des alertes sur différents bus de messages comme Kafka.

Les API exposées par CSO peuvent être classées comme indiqué dans le tableau 1.

Tableau 1 : API CSO

Gestion des catalogues	API pour gérer les descripteurs de service réseau et les VNF
Gestion VIM/POP	API pour créer, définir et gérer les datacenters VIM et POP
Gestion de la topologie	API pour insérer et gérer une topologie de service CPE de bout en bout (logique)
Création de site/client	API pour gérer les objets client/site et leur association aux nœuds de topologie de service.
API de conception de réseau	API pour définir les services virtualisés et les chaînes de services
Site Activation	API pour notifier le déploiement, la topologie et le placement des services des appareils vCPE/uCPE.
Gestion des identités	API pour gérer les identités des utilisateurs d’entreprise et de fournisseurs de services
Bootstrap Service	API pour le service d’activation des appareils de configuration et de gestion
Placement/instanciation du service	API pour positionner et gérer les chaînes de services dans la topologie client
Surveillance des appareils et des services	API pour surveiller l’état des équipements, des services réseau et de la topologie des services
Analyse/dépannage des causes racines	Moteur de suivi et de corrélation des API pour les événements, les alarmes et les journaux
Zero touch et gestion des appareils	API pour l’activation, le provisionnement et la gestion de NFX/SRX
Gestion des images	API pour gérer les images logicielles NFX, SRX, EX et EX VC
SD-WAN	API pour le provisionnement de liaisons, auto-VPN, discover-VPN, routage distribué
Routage abstrait	API pour la création de chaînes de services L2/L3
Infrastructure à clé publique (PKI)	API pour exploiter les fonctionnalités de sécurité PKI

Pour obtenir la liste détaillée des API, reportez-vous à Référence des API Contrail Service Orchestration.

Extensibilité et personnalisation

CSO est conçu de manière à faciliter l’extension et la personnalisation de ses microservices. Ces fonctionnalités peuvent être classées en trois blocs de construction principaux :

• Plugin-based architecture: Divers microservices, tels que EMS, FMPM, VNFM, Flex, etc., ont une architecture basée sur des plugins pour permettre d’étendre et de personnaliser leur comportement à l’aide de plugins qui peuvent être créés et installés sans nécessiter de modifications de code dans le microservice lui-même. Ces microservices sont livrés avec un certain ensemble de plugins, et de nouveaux plugins peuvent être créés et ajoutés sur le terrain.

• Customization of site connectivity topology and activation workflows: Pour chaque site, la topologie de connexion côté WAN, ainsi que la configuration déployée(s) sur le(s) périphérique(s) local(s) lors de son activation, sont modélisées sous forme de modèles d’appareil. Ces modèles peuvent être modifiés ou créés sur le terrain pour personnaliser les workflows et les configurations d’activation en fonction des besoins uniques de chaque fournisseur de services.

Capacité de télémétrie et d’analyse

Une fonctionnalité importante de la plate-forme CSO est sa capacité à collecter des données de télémétrie à partir de différents appareils/VNF et à les utiliser pour :

• Stockez des données de séries chronologiques et rendez les données interrogeables à partir des applications Northbound et de l’interface utilisateur CSO pour les afficher sous forme de tableaux et de graphiques.

• Créez des événements auxquels les microservices peuvent réagir. Par exemple, les mesures SLA collectées sur les appareils sont publiées pour analyser les violations de SLA de lien, afin que les applications concernées puissent prendre les mesures appropriées.

• Publiez les données sélectionnées sur les applications d’écoute Northbound via Kafka et RabbitMQ.

CSO utilise les nœuds Contrail Analytics pour stocker les données de séries chronologiques. Contrail Analytics est en soi un composant évolutif horizontalement qui offre une haute disponibilité ainsi que la possibilité d’interroger des données via des API REST. Les données de la série chronologique sont exposées via les API CSO à l’interface utilisateur et aux applications Northbound.

Stratégies basées sur l’intention

L’interface utilisateur de CSO met fortement l’accent sur la simplification et l’automatisation de nombreuses fonctions principales qu’un opérateur doit exécuter. Cette simplification est rendue possible par la modélisation des objets d’entreprise et l’utilisation de stratégies basées sur l’intention pour les configurer.

Les stratégies basées sur l’intention permettent à un opérateur de configurer des stratégies à l’aide de concepts tels que des services, des sites, des groupes de sites et des groupes d’applications. La stratégie est appliquée à tous les périphériques pertinents qui correspondent aux paramètres spécifiés dans la construction correspondante ; L’opérateur n’a pas à se soucier de configurer la stratégie explicitement sur les appareils.

Les intentions peuvent être exprimées dans le cadre de différents workflows, comme décrit ci-dessous :

• Site Onboarding–Lors de l’intégration du site ou du hub, les intentions suivantes peuvent être spécifiées :

  • Lien par défaut - l’administrateur du locataire peut choisir un lien par défaut ; utilisé comme chemin de superposition par défaut pour tout le trafic pour lequel aucune politique n’indique le contraire.

  • Répartition des applications : permet aux administrateurs de site de désigner qu’une partie du trafic applicatif doit être acheminée directement vers Internet à partir du site en étoile.

  • Breakout central : permet au trafic destiné à Internet de s’acheminer directement vers Internet au niveau du hub d’entreprise.

  • Service breakout : permet aux administrateurs de site de désigner que tout le trafic destiné à Internet d’un service local spécifique soit acheminé directement vers Internet à partir du site en étoile.

  • Répartition du concentrateur : permet aux administrateurs de site de désigner que tout le trafic destiné à Internet doit être acheminé directement vers Internet à partir de l’équipement du concentrateur du fournisseur.

  • Groupe de sites : permet de déployer les mêmes stratégies sur un groupe de sites présentant des caractéristiques similaires.

  • Répartition Internet locale du site : permet aux administrateurs du site de désigner que tout le trafic destiné à Internet doit être acheminé directement vers Internet à partir du site en étoile.

  • Zscaler breakout - Permet de router tout le trafic destiné à Internet vers une implémentation Zscaler avant d’accéder à Internet. Cette répartition peut être effectuée localement, centralement ou au niveau du hub fournisseur.

  Note:

  Bien que les intentions ci-dessus puissent être spécifiées lors du processus d’intégration du site, elles ne sont appliquées qu’après le ZTP.

• SD-WAN Intent Policy Creation–Des profils de pilotage et de breakout peuvent être créés pour être utilisés dans les stratégies SD-WAN.

  Deux types de profils sont pris en charge :

  • Profil de direction basé sur la trajectoire – l’opérateur spécifie explicitement un chemin préféré pour le trafic. Le trafic correspondant à une stratégie SD-WAN à l’aide de ce profil empruntera le chemin préféré.

  • Profil de breakout : l’opérateur spécifie un type de breakout local utilisant un réseau underlay, un backhaul utilisant des sites hubs pour le trafic breakout ou un breakout local à l’aide d’une plate-forme cloud telle que Zscaler. L’opérateur spécifie également un profil de type de trafic et un chemin préféré pour le trafic breakout. Si un type de liaison WAN correspondant au chemin préféré est disponible au CPE et activé pour la rupture, le trafic utilisera ce lien pour le trafic breakout. Si l’un est sélectionné comme chemin préféré, CSO utilisera tous les liens disponibles activés pour l’analyse en mode équilibrage de charge.

Une stratégie SD-WAN peut être créée en spécifiant les éléments suivants :

• Point(s) de terminaison(s) source(s) - groupes de sites, services

• Point(x) de terminaison(s) de destination - groupes d’applications/applications

• Action - Profil de direction ou profil de rupture

Il suffit à l’opérateur de sélectionner ces éléments de haut niveau dans les menus déroulants disponibles, puis de déployer la stratégie. CSO se charge de traduire ces intentions en configurations qui sont envoyées aux périphériques réseau concernés.

Security Intent-Based Policies

Pour créer des stratégies de pare-feu, l’opérateur n’a pas besoin de spécifier l’emplacement et les informations de connectivité des points de terminaison. Au lieu de cela, CSO utilise les informations de topologie existantes pour déterminer comment les points de terminaison pertinents sont connectés et crée les stratégies de sécurité appropriées à déployer sur les points d’application des stratégies appropriés.

Les intentions de stratégie de pare-feu peuvent être définies à l’aide des éléments suivants comme identificateurs source et destination :

• Site

• Département (zone de sécurité SRX : jusqu’à 25 départements pris en charge à partir de CSO version 4.1)

• Application (L7 : basée sur signature)

• Services (basés sur un protocole)

• Objets d’adressage représentant des hôtes, des réseaux, des plages d’adresses IP, etc.

Les intentions de pare-feu ne sont pas sensibles à l’ordre, ce qui signifie que l’opérateur n’a pas besoin d’organiser les intentions dans le bon ordre. CSO analyse toutes les intentions de pare-feu et les convertit en déclarations de stratégies de sécurité dans le bon ordre.

Mise à niveau et rétrocompatibilité

CSO prend en charge les mises à niveau transparentes à partir des versions précédentes, y compris la mise à niveau des services d’infrastructure et des microservices, la migration des données, la connectivité des appareils et la configuration.

La procédure de mise à niveau est une activité « hors ligne » ; Tous les microservices sont arrêtés pendant la mise à niveau. Toutefois, les équipements réseau (CPE, concentrateurs, etc.) et l’environnement SD-WAN dans son ensemble continuent de fonctionner normalement.

Le modèle de données CSO et les API maintiennent une compatibilité descendante de sorte que la dernière version de tous les microservices CSO prend en charge (lecture/écriture) les données créées par les versions précédentes. Des scripts de migration/workflows supplémentaires peuvent également être exécutés dans le cadre du processus de mise à niveau.

Gestion des éléments

CSO inclut un ensemble de microservices qui fournissent des capacités évolutives de gestion des éléments multifournisseurs. Ces fonctionnalités permettent de fournir des services SD-WAN en gérant, orchestrant et contrôlant les équipements réseau physiques et virtuels qui composent la solution globale.

Ces appareils peuvent généralement être placés sous la gestion des OSC de deux manières :

• Si l’appareil est déjà provisionné, il peut être découvert par CSO et placé sous sa gestion en fournissant l’adresse IP de gestion de l’appareil et les informations d’identification du compte administrateur. Un périphérique de concentrateur de fournisseur situé dans un POP de fournisseur de services est généralement détecté à l’aide de cette option.

• Pour les appareils qui doivent être automatiquement mis en ligne et provisionnés, CSO utilise un mécanisme zero-touch pour placer l’appareil sous sa gestion. En fournissant le numéro de série de l’équipement attendu sur chaque site, CSO crée dans sa base de données un objet équipement correspondant à chaque équipement et prépare l’image et la configuration qui doivent lui être livrées. Lorsque l’appareil arrive sur le site et qu’il est accumulé et sous tension, il contacte le service de redirection Juniper (https://redirect.juniper.net) pour savoir comment joindre son instance CSO régionale. Lorsque le serveur CSO est contacté, l’appareil reçoit une image logicielle et une configuration initiale. Une fois opérationnel, CSO effectue d’autres actions sur l’appareil, telles que la mise en place des machines virtuelles requises, le provisionnement des tunnels de superposition, l’installation d’un agent de télémétrie, etc.

CSO interagit avec les périphériques réseau à l’aide de sessions NETCONF ou CLI via SSH, garantissant ainsi que toutes les communications de gestion utilisent un canal sécurisé et crypté. CSO prend en charge l’authentification par mot de passe ainsi que l’authentification basée sur les clés SSH de l’appareil.

La figure 1illustre les différents microservices qui fonctionnent ensemble pour fournir les capacités de gestion des éléments CSO et la manière dont ils sont distribués sur les serveurs centraux et régionaux.

Microservice	Description
Service d’activation	Prend en charge l’activation sécurisée sans contact des périphériques CPE via draft-ietf-netconf-zerotouch.
Service de gestion des périphériques	Gère le cycle de vie des appareils ; Les appareils comprennent les VNF, les PNF, les CPE, les PE, les concentrateurs IPsec, etc.
Service de gestion des configurations	Gère le cycle de vie des objets de configuration, y compris leur gestion des versions ainsi que leur déploiement sur les appareils.
Service de gestion d’images	Gère un référentiel d’images d’appareils et d’autres progiciels, et gère leur déploiement et leur installation sur les appareils.
Service d’inventaire	S’occupe de la découverte et de la gestion des ressources d’inventaire physique et logique sur les appareils.
Service de modèles	Gère tous les modèles intégrés au système et fournit des API pour les rendre à l’aide de différents moteurs de modèles via des plugins ; Les modèles peuvent être utilisés pour générer des commandes de configuration ou opérationnelles.
Service du fournisseur FMPM	Service centralisé qui gère toutes les données FM et PM et fournit des API pour la collecte et l’interrogation des données.
Service de collecte FMPM	Service distribué responsable de la collecte des données FM et PM auprès des entités gérées.
Service de configuration	Fournit des API pour exécuter des commandes sur les appareils gérés et sert de passerelle entre tous les microservices et les appareils gérés ; dispose d’une architecture basée sur des plugins pour prendre en charge plusieurs protocoles de gestion, tels que NETCONF/SSH, CLI/SSH et REST/HTTP.
Service de connectivité des appareils	Prend en charge l’établissement de la connexion de transport et l’authentification entre CSO et les appareils gérés.

CSO Behind NAT

CSO peut être installé derrière une passerelle NAT. Lorsqu’ils sont utilisés, les appareils gérés peuvent atteindre CSO via une adresse IP exposée publiquement. Cette option est spécifiée lors de l’installation initiale de CSO et nécessite une configuration manuelle supplémentaire des règles NAT une fois l’installation terminée.

CSO in the Cloud

Bien que CSO soit souvent installé sur le réseau du fournisseur de services, il peut également être installé dans le cloud, selon les exigences de conception.

CSO in Public Cloud

La figure 2 montre CSO situé dans un VPC AWS et accessible via une connexion privée. C’est ce qu’on appelle un déploiement CSO hébergé dans le cloud. CSOaaS est basé sur ce modèle.

Caractéristiques de mise en œuvre :

• L’installation CSO utilise l’adressage IP privé.

• La passerelle NAT fournit une adresse IP publique pour CSO.

• La connexion entre CSO et l’appareil hub utilise un réseau MPLS ou une connexion Internet privée, telle qu’AWS Direct Connect.

• L’équipement du concentrateur doit utiliser une adresse IP publique pour OAM.

• L’adresse IP du hub doit être directement accessible depuis CSO.

• Le périphérique spoke initie sa connexion à CSO à l’aide de l’adresse IP publique sur la passerelle NAT.

CSO on Internet

La figure 3 montre CSO situé à un autre emplacement sur Internet, par exemple dans un cloud privé, et accessible directement sur Internet.

Caractéristiques de mise en œuvre :

• L’installation CSO utilise l’adressage IP privé.

• La passerelle NAT fournit une adresse IP publique pour CSO.

• La connexion entre CSO et l’équipement hub utilise l’Internet public.

• L’équipement du concentrateur doit utiliser une adresse IP publique pour OAM.

• L’adresse IP du hub doit être directement accessible depuis CSO.

• Le périphérique spoke initie sa connexion à CSO à l’aide de l’adresse IP publique sur la passerelle NAT.

Interface utilisateur CSO

Le logiciel CSO offre une interface utilisateur Web unique pour créer, configurer et surveiller les locataires, les sites, les appareils, les topologies de réseau, ainsi que les politiques de sécurité et SD-WAN. Un exemple de capture d’écran du tableau de bord est illustré à la Figure 4.

Web UI Architecture

CSO Web UI utilise un framework léger pour créer des interfaces utilisateur à interface unique de manière découplée. L’interface utilisateur permet de créer dynamiquement des workflows à partir de plug-ins développés et déployés indépendamment, ce qui permet d’étendre dynamiquement l’interface utilisateur dans un environnement client sans aucun impact sur les fonctionnalités existantes.

L’architecture de l’interface utilisateur prend en charge un tableau de bord unique et unifié qui héberge les widgets de surveillance. Une vue miniature des widgets est fournie par l’infrastructure, et l’opérateur peut glisser-déposer les widgets pour composer des vues de surveillance personnalisées. L’interface utilisateur inclut une API de « préférences » qui peut être utilisée pour lire et écrire les préférences utilisateur liées à l’interface utilisateur, telles qu’un ordre de tri préféré ou un sous-ensemble visible de colonnes pour une instance de grille. Ces préférences sont conservées d’une session utilisateur à l’autre.

Personas

Il existe deux personnages principaux dans l’interface utilisateur Web :

• Service Provider admin—un accès mondial à toutes les sociétés d’exploitation, à tous les locataires et à tous les clients ; accéder à CSO via le portail d’administration

• Tenant admin—accès spécifique au client ; accéder à CSO via le portail client

Operating Companies (OpCos)

CSO version 4.0 et ultérieure prend en charge les sociétés d’exploitation (OpCo) dans un environnement de fournisseur de services.

Lorsqu’un fournisseur de services mondial est tenu d’avoir des entités commerciales régionales pour gérer les clients sur une base régionale (pour des raisons réglementaires, de facturation ou opérationnelles), la structure OpCo permet au fournisseur de services d’étendre sa plate-forme CSO pour permettre à chaque entité régionale d’offrir indépendamment des services SD-WAN à ses propres locataires et clients.

Lors de la prise en charge des OpCos, la hiérarchie mutualisée CSO comporte trois niveaux :

• Global service provider: contient une ou plusieurs sociétés d’exploitation et leurs locataires, gère les ressources au niveau du fournisseur de services et partage des ressources communes avec les sociétés d’exploitation et les locataires.

  Note:

  Dans CSOaaS, il n’y a pas d’accès utilisateur au rôle/à la hiérarchie Global Service Provider.

• Operating company: fournisseur de services spécifique à une région capable de gérer ses locataires et de leur fournir des services. Les locataires gérés par une OpCo sont isolés des locataires d’une autre OpCo.

• Tenant: utilise les ressources fournies par le fournisseur de services global ou OpCo.

La figure 5 montre la relation entre le fournisseur de services mondial, les sociétés d’exploitation et les locataires.

Pour plus d’informations sur les portails CSO, les types d’utilisateurs et les personas, consultez le Guide de l’utilisateur du portail d’administration CSO et le Guide de l’utilisateur du portail client CSO pour la version 5.0.