Propriétés clés de la couche Platform

Services de base

Pour remplir son rôle de base consistant à fournir l'infrastructure de base pour déployer des services cloud sur site, la plate-forme s'appuie sur un ensemble de services internes fondamentaux à part entière.

Gestion du matériel

Lorsqu'un système est initialisé, les composants de plate-forme de bas niveau orchestrent le provisionnement du cluster de noeuds de gestion et des noeuds de calcul. Au cours de ce processus, tous les noeuds, y compris les contrôleurs de ZFS Storage Appliance, sont connectés aux réseaux d'administration et de données requis. Lorsque des noeuds de calcul supplémentaires sont installés ultérieurement, le même mécanisme de provisionnement intègre le nouveau noeud dans la configuration système globale. Des tiroirs de disques supplémentaires sont également automatiquement intégrés par les contrôleurs de stockage.

La première étape de la gestion du matériel consiste à créer un inventaire des composants du rack. L'inventaire est une base de données distincte qui contient les spécifications et les détails de configuration des composants installés dans le rack. Il conserve un historique de tous les composants qui ont déjà été présentés au système et est mis à jour en permanence avec les dernières informations capturées à partir des composants du système actifs.

La couche des services et plusieurs composants système ont besoin des détails de l'inventaire matériel pour pouvoir interagir avec le matériel. Par exemple, un processus de mise à niveau de composant ou de déploiement de service doit envoyer des instructions à la couche matérielle et recevoir des réponses. De même, lorsque vous créez une instance de calcul, vous devez effectuer une série d'opérations au niveau des noeuds de calcul, des composants réseau et de l'appliance de stockage pour faire apparaître l'instance, ainsi que les ressources de stockage et de réseau associées.

Toutes les instructions destinées à la couche matérielle sont centralisées dans un service de gestion du matériel, qui sert de passerelle vers la couche matérielle. Le service de gestion du matériel utilise l'API de plate-forme dédiée et hautement sécurisée pour exécuter les commandes requises sur les composants matériels : ILOM du serveur, contrôleurs de stockage ZFS, etc. Cette API est exécutée directement sur le système d'exploitation du noeud de gestion. Il est séparé de l'environnement d'orchestration de conteneurs dans lequel les microservices sont déployés.

Déploiement de service

Private Cloud Appliance suit un modèle de développement granulaire basé sur les services. La fonctionnalité est logiquement divisée en microservices distincts, qui existent dans les couches architecturales et représentent une vue verticale du système. Les services ont des fonctions internes et externalisées, et ils interagissent les uns avec les autres dans des couches différentes.

Ces microservices sont déployés dans des conteneurs Kubernetes. L'environnement d'exécution de conteneur ainsi que le registre sont hébergés sur le cluster de gestion à trois noeuds. Oracle Cloud Native Environment constitue la base de l'orchestration de conteneurs, qui inclut le déploiement, la configuration et le démarrage automatisés des conteneurs de microservices. Par conception, tous les microservices sont constitués de plusieurs instances réparties sur différents noeuds et pods Kubernetes. Outre la haute disponibilité, la conception Kubernetes offre également un équilibrage de charge entre les instances de chaque microservice.

La mise en conteneur simplifie les mises à niveau de service et les améliorations fonctionnelles. Les services sont étroitement intégrés mais pas monolithiques, permettant des mises à niveau individuelles à condition que les exigences de compatibilité soient respectées. Une nouvelle version d'un microservice est publiée dans le registre de conteneurs et propagée automatiquement vers les noeuds et pods Kubernetes.

Composants de service communs

Certains composants et mécanismes opérationnels sont requis par tout ou partie des services, il est donc plus efficace de les intégrer dans la plate-forme. Les microservices peuvent utiliser ces composants communs et leurs fonctionnalités essentielles lorsqu'ils sont déployés sur la plate-forme.

• Transport de message

  Tous les composants et services sont connectés à une couche de transport commune. Il s'agit d'un broker de messages qui permet aux composants d'envoyer et de recevoir des messages écrits dans un format standardisé. Ce service de transport de messages est déployé en tant que cluster de trois instances pour la haute disponibilité et le débit, et utilise TLS pour l'authentification et le cryptage du trafic.

• Service secret

  Les clés secrètes utilisées par programmation dans l'ensemble du système, telles que les informations d'identification et les certificats, sont gérées de manière centralisée par le service de clés secrètes. Tous les composants et services sont des clients du service de clé secrète : après une authentification réussie, le client reçoit un jeton à utiliser avec chaque opération qu'il tente d'exécuter. Les stratégies définies dans le service de clé secrète déterminent les opérations qu'un client est autorisé à effectuer. Les clés secrètes ne sont pas stockées de manière statique ; elles ont une durée de vie limitée et sont créées et gérées de manière dynamique.

  Au cours de l'initialisation du système, le service secret est descellé et préparé pour utilisation. Il est déployé en tant que cluster actif/de secours sur les noeuds de gestion, dans un conteneur au niveau de la couche de plate-forme, mais en dehors de l'environnement de microservices Kubernetes. Cela permet au service secret d'offrir ses fonctionnalités à la couche de plate-forme au démarrage, avant que les microservices ne soient disponibles. Tous les composants de plate-forme et les microservices doivent établir leur relation de confiance avec le service secret avant d'être autorisés à exécuter des opérations.

• Journalisation

  La plate-forme fournit une journalisation unifiée sur l'ensemble du système. À cette fin, tous les services et composants s'intègrent au collecteur de données Fluentd. Fluentd collecte des données à partir d'un ensemble préconfiguré de fichiers journaux et les stocke dans un emplacement central. Les journaux sont capturés à partir des composants système, de la couche de plate-forme et de l'environnement de microservices, et mis à disposition via le système d'agrégation de journaux Loki pour la traçabilité et l'analyse.

• Surveillance

  À des fins de surveillance, la plate-forme s'appuie sur Prometheus pour collecter des données de mesure. Prometheus étant déployé dans l'environnement Kubernetes, il dispose d'un accès direct aux mesures des microservices. Les composants en dehors de Kubernetes, tels que les composants matériels et les instances de calcul, fournissent leurs données de mesure à Prometheus via le réseau interne et l'équilibreur de charge. Les noeuds de gestion et Kubernetes eux-mêmes peuvent communiquer directement avec Prometheus.

• Analyses

  Les données de journalisation et de surveillance sont destinées aux administrateurs d'infrastructure. Ils peuvent consulter les données via l'interface utilisateur Web de service, où un certain nombre de requêtes intégrées pour les paramètres d'état et de performances sont visualisées sur un tableau de bord. Des alertes sont envoyées lorsqu'un seuil de clé est dépassé, afin que les contre-mesures appropriées puissent être prises.

• Base de données

  Tous les services et composants stockent les données dans une base de données centrale commune. Il s'agit d'une base de données de cluster MySQL avec des instances déployées sur les trois noeuds de gestion et exécutées sur Bare Metal. La disponibilité, l'équilibrage de charge, la synchronisation des données et le clustering sont tous contrôlés par les composants internes du cluster MySQL. Pour des performances optimales, le stockage des données est fourni par des LUN sur ZFS Storage Appliance, directement connectés à chacun des noeuds de gestion. L'accès à la base de données est strictement contrôlé par le service secret.

• Equilibrage de charge

  Les noeuds de gestion forment un cluster de trois noeuds actifs, ce qui signifie qu'ils sont tous capables de recevoir simultanément des connexions entrantes. Le trafic entrant est contrôlé par un équilibreur de charge configuré de manière statique qui écoute sur une adresse IP flottante et distribue le trafic sur les trois noeuds de gestion. Une instance de l'équilibreur de charge est exécutée sur chacun des noeuds de gestion.

  De la même manière, tous les microservices en conteneur s'exécutent en tant que plusieurs pods au sein de l'environnement d'orchestration de conteneurs sur le cluster de noeuds de gestion. Kubernetes fournit l'équilibrage de charge pour le trafic entrant vers les microservices.