Le concept principal du réseau défini par logiciel (SDN) est "le découplage du système qui prend les décisions sur l‘endroit où le trafic est envoyé (le plan de contrôle) des systèmes sous-jacents qui transmettent le trafic vers la destination sélectionnée (le plan de données)". L‘Open Networking Foundation définit l‘architecture SDN comme suit:
- Programmation directe
- Agile
- Gestion centralisée
- Configuré par programme
- Basé sur des normes ouvertes et indépendant des fournisseurs
Comme nous l‘avons souligné dans ce livre blanc techniquele SnapLogic Integration Cloud est architecturé sur des concepts SDN et construit avec un ensemble spécifique de valeurs à l‘esprit. Le "plan de contrôle" contrôle où et comment les données sont traitées en fonction de la configuration et des préférences de l‘utilisateur. Le "plan de données" (aka le Snaplex) effectue le traitement réel des données selon les instructions reçues du plan de contrôle. Aucune donnée n‘est stockée dans le SnapLogic Integration Cloud, mais les données sont transmises entre les systèmes via le Snaplex. Dans ce billet, nous donnerons un aperçu du plan de données SnapLogic. Vous pouvez en savoir plus sur le plan de contrôle ici et sur les Snaps ici. Nous nous pencherons sur la sécurité dans le prochain article.
Snaplex : Le plan de données
Un Snaplex est le composant de traitement des données de l‘intégration SnapLogic Cloud. C‘est le "plan de données". Les clients peuvent déployer un ou plusieurs Snaplex selon leurs besoins pour exécuter des pipelines et traiter des données. Un Snaplex se compose d‘un ou de plusieurs nœuds et se présente sous deux formes : sur site (alias " Groundplex ") et sur le site cloud (alias " Cloudplex ").
- Cloudplex : Tous les Cloudplex s‘exécutent dans l‘intégration SnapLogic Cloud. Les clients utilisent le gestionnaire et le tableau de bord de surveillance pour administrer leur Cloudplex. L‘équipe SnapLogic DevOps administre les indicateurs clés de performance (KPI) de l‘infrastructure, tels que le temps de disponibilité, etc. Les clients qui ont besoin d‘exécuter des intégrations qui orchestrent les applications cloud (par exemple Salesforce, ServiceNow, Workday) sans connexions sur site n‘auront besoin d‘aucun logiciel à exécuter derrière leur pare-feu.
- Groundplex : Les clients qui ont besoin d‘une connectivité sur site (par exemple SAP, Oracle, Microsoft Dynamics AX, etc.) auront besoin d‘un Groundplex, qui fonctionne derrière le pare-feu. Bien qu‘ils fonctionnent dans des centres de données privés ou virtuels, les Groundplex sont gérés à distance par leplan de contrôle SnapLogic Integration Cloud (par exemple, surveillance des battements de cœur, mises à niveau logicielles, etc.)
Le Snaplex peut s‘étendre et se contracter de manière élastique en fonction du trafic de données qui le traverse. L‘unité d‘extensibilité à l‘intérieur de Snaplex est une machine virtuelle Java (JVM), appelée "nœud". Le plan de contrôle est doté d‘une "intelligence" intégrée qui permet d‘étendre ou de réduire automatiquement la taille du Snaplex afin de gérer des charges de trafic variables. Par exemple, chaque Snaplex est initialisé avec un nombre minimum configurable de nœuds (disons un, par exemple). Une fois que l‘utilisation de ce nœud
atteint un certain seuil configurable (par exemple un certain nombre de pipelines en cours d‘exécution ou un certain pourcentage d‘utilisation de l‘unité centrale ou de la mémoire par nœud) en raison d‘un pic de trafic, un nouveau nœud est automatiquement mis en marche pour gérer la charge de travail supplémentaire. Une fois que le trafic de données excédentaire a été traité et que le deuxième nœud est inactif, il est "démantelé" pour ramener le Snaplex à sa taille d‘origine.
Pour plus d‘informations sur l‘architecture SnapLogic Integration Cloud et son fonctionnement, téléchargez ce livre blanc technique.
