SystemLink Enterprise est une application avec une architecture orientée service. Les microservices hébergés par Kubernetes constituent l’architecture. SystemLink Enterprise est évolutif, tolérant aux pannes et hautement disponible. Le tableau suivant résume les principaux éléments de l'architecture SystemLink Enterprise.

Architecture SystemLink Enterprise

Le diagramme associé décrit les composants de l'architecture SystemLink Enterprise.

Remarque Ce chapitre fournit des liens vers les diagrammes pour référence, mais les diagrammes peuvent ne pas convenir à tous les cas d'utilisation. Personnalisez l’architecture en fonction des exigences spécifiques et de l’infrastructure de votre organisation.

Reportez-vous au diagramme SystemLink Enterprise Kubernetes Architecture pour consulter un exemple de référence de déploiement de SystemLink Enterprise.

Cluster Kubernetes de SystemLink Enterprise

SystemLink Enterprise Kubernetes Cluster est un cluster Linux Kubernetes qui héberge les pods qui constituent les SystemLink Enterprise. Le cluster se compose de :

  • Services Web SystemLink : microservices back-end qui fournissent des API REST pour les capacités SystemLink fondamentales. Les services Test Monitor, File Ingestion, Asset et Tag en sont des exemples.
  • Applications Web SystemLink: Composants d'interface utilisateur frontaux avec lesquels les utilisateurs interagissent via un navigateur Web.
  • Salt Master : gère les connexions sécurisées aux cibles, aux paramètres de la cible et aux configurations. Active les workflows d'installation de logiciels.
  • Infrastructure de support : composants tels que RabbitMQ, Redis, Dremio et Jupyter pour la messagerie, la mise en cache, les requêtes de données et l'exécution de notebooks.

Pour obtenir des informations sur la configuration du groupe de nœuds afin d'optimiser les performances et l'isolation des ressources, reportez-vous à Configuration du groupe de nœuds.

Dépendances externes

SystemLink Enterprise requiert les systèmes externes suivants pour le stockage des données, l'authentification et les capacités de recherche.

Tableau 1. SystemLink EnterpriseDépendances externes
Composant Description
Elasticsearch Elasticsearch est un moteur de recherche. SystemLink utilise Elasticsearch pour améliorer les capacités de recherche. SystemLink fournit un diagramme Helm de démarrage facultatif pour exécuter Elasticsearch dans le même cluster que SystemLink Enterprise. Pour en savoir plus sur la configuration d'Elasticsearch, reportez-vous à Configurer Elasticsearch.
Fournisseur d'identité Le fournisseur d ' identité est le service utilisé par SystemLink pour authentifier et connecter les utilisateurs à l ' application Web SystemLink. SystemLink Enterprise ne prend en charge que les fournisseurs d ' identité OpenID Connect. Pour en savoir plus sur la manière de connecter votre fournisseur à SystemLink, reportez-vous à Identity and Access Management.
MongoDB MongoDB est une base de données documentaire. SystemLink utilise MongoDB Wire Protocol pour communiquer avec l'instance MongoDB. Pour en savoir plus sur la configuration de MongoDB, reportez-vous à Configurer la base de données MongoDB.
Stockage d'objets Stockage d'objets fait référence au système de stockage Amazon S3, compatible S3 ou Azure Blob utilisé par les services SystemLink qui nécessitent un stockage de fichiers en bloc.
PostgreSQL PostgreSQL est une base de données relationnelle. SystemLink utilise PostgreSQL pour le stockage de données. Pour en savoir plus sur la configuration de PostgreSQL, reportez-vous à PostgreSQL.

Infrastructure SystemLink Enterprise

Les composants d'infrastructure suivants sont requis pour le déploiement et l'accès aux SystemLink Enterprise.

Tableau 2. Composants de l'infrastructure SystemLink Enterprise
Composant Description
Dépôt d'artefacts Registre Open Container Initiative (OCI) avec les conteneurs SystemLink et les charts Helm. Vous pouvez utiliser le dépôt d'artefacts NI ou des conteneurs de scènes et des graphiques Helm dans votre propre dépôt. Pour en savoir plus, reportez-vous à Configuring SystemLink Repositories.
Interfaces réseau

SystemLink utilise trois interfaces réseau dans son fonctionnement normal :

  • Application Web
  • API
  • Salt
Ces interfaces correspondent à trois noms d'hôtes. Les utilisateurs utilisent l'application Web ingress et host pour accéder à l'application Web SystemLink. Les cibles et les applications utilisent l'API ingress et host pour accéder aux données et aux ressources via l'API SystemLink REST. L'entrée Salt et l'hôte connectent les cibles au maître Salt SystemLink Enterprise hébergé. Pour en savoir plus sur la configuration de ces noms d'hôtes, reportez-vous à Couche 7 (Application) Ingress et Couche 4 (TCP) Ingress.

Systèmes de test SystemLink Enterprise

SystemLink Enterprise se connecte et gère les systèmes de test appelés cibles.

Tableau 3. Systèmes de test SystemLink Enterprise
Composant Description
Cibles

Les cibles sont des systèmes de test connectés en toute sécurité que SystemLink gère. Les cibles téléchargent vers SystemLink les résultats, l'état et les données d'état des tests. Ces systèmes peuvent utiliser des systèmes d'exploitation Windows ou NI Linux Real-Time.

Les cibles communiquent avec SystemLink via les protocoles TCP SaltStack et HTTPS. Les systèmes de test initient toutes les communications vers le serveur, indépendamment du protocole. Consultez Configuration d'un client SystemLink pour obtenir des informations sur l'ajout d'une cible à votre serveur SystemLink.

SystemLink communique des tags, des fichiers, des ressources et des résultats de test via HTTPS. Les jobs et pillars Salt sont communiqués via protocole TCP Salt crypté par AES. Les jobs Salt sont utilisés pour installer les logiciels et modifier la configuration des cibles depuis le serveur SystemLink. Lorsque vous utilisez des certificats d'autorités de certification privées, Salt transmet les certificats SystemLink. Cette transmission garantit que les cibles peuvent établir une confiance avec SystemLink . Les cibles ne nécessitent pas de gestion manuelle de ces certificats. Pour en savoir plus sur le protocole de transport TCP Salt, reportez-vous à la documentation de SaltStack.

Lorsqu'un utilisateur autorisé approuve une cible dans SystemLink, la cible devient un système géré. SystemLink transfère ensuite en toute sécurité la configuration, les certificats et les informations d'identification nécessaires à l'authentification de la cible avec SystemLink. Les API SystemLink Client Python et LabVIEW incluent des fonctions de configuration automatique qui consomment automatiquement ces informations d'identification. Il n'est pas nécessaire d'inclure de secrets (comme des identifiants) dans le code de votre application de test.

Configuration du groupe de nœuds

Pour des performances optimales et une isolation optimale des ressources, configurez les composants suivants pour qu'ils s'exécutent dans leurs propres groupes de nœuds et pools dédiés :

  • Services Web SystemLink et applications Web
  • Exécution de Jupyter Notebook et notebook
  • Data Frame Service et sa dépendance, Dremio

Pour consulter un exemple de fichier YAML pour configurer les sélecteurs de nœuds, reportez-vous à node-selectors.yaml.

Architecture spécifique au fournisseur de cloud

Reportez-vous aux diagrammes AWS SystemLink Enterprise Kubernetes Architecture Diagram et Azure SystemLink Enterprise Kubernetes Architecture Diagram pour consulter des exemples de déploiements AWS et Azure.

Remarque Les diagrammes liés sont des exemples de référence pour le déploiement de SystemLink Enterprise sur AWS et Azure. Votre déploiement réel peut varier en fonction des exigences spécifiques, des politiques de sécurité et de l’infrastructure existante de votre organisation.