Aperçu de l’ensemble du projet : architecture de la plate-forme

Aperçu de l’ensemble du projet : architecture de la plate-forme

Ceci est le deuxième blog de ma série Project Ensemble Preview. Si vous avez manqué le premier, où j’ai couvert la première approche API que nous adoptons avec GraphQL, assurez-vous de le vérifier également. Si vous n’êtes pas familier avec Project Ensemble, veuillez prendre le temps de lire le blog d’annonce. En bref, Project Ensemble cherchera à unifier et à simplifier les services et les données de gestion du cloud dans un modèle de données commun, en ajoutant des informations commerciales intelligentes et exploitables axées sur des vues centrées sur les applications et personnalisées pour les personnes qui prennent en charge ces applications.

Avant de plonger, veuillez garder à l’esprit que tout ce qui est discuté ici est sujet à changement et peut ne pas se rendre au service final. Sur ce, je partage notre clause de non-responsabilité.

“Ce blog peut contenir des caractéristiques ou des fonctionnalités de produits en cours de développement. Cet aperçu des technologies émergentes ne représente pas un engagement de VMware à rendre ces fonctionnalités disponibles dans les produits généralement disponibles. Les caractéristiques sont sujettes à modification et ne peuvent être incluses dans aucun contrat, achat, commande ou accord de vente de quelque nature que ce soit. La faisabilité technique et la demande du marché affecteront la livraison finale. Le prix et l’emballage de toute nouvelle fonctionnalité/fonctionnalité/technologie discutée ou présentée n’ont pas encore été déterminés.”

pochettes d’information

Toutes les organisations informatiques sont confrontées à un problème universel ; Les outils de gestion sont spécialisés et ne parlent pas un langage commun. C’est un défi même lorsque les outils sont fournis par le même fournisseur.

Pour le praticien individuel dans un domaine informatique (réseau, sécurité, développement, etc.), ce manque de points communs n’est pas toujours un obstacle aux opérations quotidiennes. Cependant, pour la productivité inter-équipes, un accès rapide et une compréhension des informations au niveau du domaine sont essentiels pour réduire le temps passé à détecter, diagnostiquer et résoudre les problèmes de performances et de disponibilité des applications.

Pensez à une application comme un système CRM. Ceux-ci peuvent être des mastodontes complexes avec des centaines de services interconnectés et interdépendants. De même, plusieurs équipes prennent en charge cette application et ses composants – et chacune des équipes dispose probablement de plusieurs outils pour surveiller les performances, la disponibilité, la sécurité, la capacité, etc. de l’application.

Il y a donc des informations précieuses qui doivent être recueillies dans une situation d’urgence et rassemblées de manière significative. Traditionnellement, cela débouche sur la fameuse « ligne de pont » ou « salle de situation » dans laquelle un gestionnaire d’incidents rassemble les experts de toutes les équipes qu’il juge nécessaires d’impliquer, juste pour rassembler et analyser ces données éparses. Beaucoup de temps a déjà été perdu entre le début du problème et le début de la résolution du problème.

Imaginez maintenant un monde où les équipes entretiennent leurs propres outils et où personne n’a à apprendre à travailler différemment. Au lieu de cela, les différents pools de données sont combinés en un seul service. Ce service permettrait :

  1. Faites des inventaires de tous les outils et normalisez-les sous un modèle fédéré

  2. Récupérer un minimum de données pour comprendre les informations clés de chaque outil sur l’entité

  3. Obtenez des informations supplémentaires si nécessaire ou demandez des actions appropriées à chaque outil

  4. Découvrir et documenter les relations entre les entités comme source de vérité

  5. Fournir une API fédérée à tout outil pour demander des informations à tout autre outil

Une telle plate-forme libère le potentiel de tant d’autres services et fonctionnalités. Et c’est l’idée derrière Project Ensemble. Initialement prévu pour être inclus dans l’offre vRealize Cloud Universal, il unifiera tous les services vRealize d’une manière qui n’était pas possible auparavant.

Un modèle de données fédéré

Project Ensemble est proposé en tant que service et repose sur un cadre d’application de microservices moderne. Il n’hérite d’aucune construction ou limitation héritée qui limiterait ou empêcherait l’intégration avec n’importe quel outil de gestion du cloud.

Au cœur de la plate-forme se trouve une technologie éprouvée utilisée par VMware CloudHealth Secure State, Entity Data Service (EDS). Il s’agit d’une base de données de graphes qui peut s’adapter aux grands clients avec plus de 200 millions de machines virtuelles et des objets associés (environ 1 milliard d’entités de graphes).

Parce que l’inventaire est collecté auprès de chaque service de fournisseur (vRealize Operations, vRealize Automation, vRealize Network Insight, etc.) et crée un modèle impartial d’inventaire cloud. Permettez-moi de préciser que “pas à mon avis” signifie qu’EDS ne fait aucune hypothèse et n’indique pas comment les choses devraient être. EDS n’est pas limité aux constructions d’architecture VMware. Il peut consommer l’inventaire du cloud public natif (et le fait dans l’état sécurisé CloudHealth). Il n’y a pas de limite pratique à l’extensibilité.

Les entités dans EDS se voient attribuer un identifiant de ressource unique et canonique qui intègre l’emplacement, le type et l’identité d’instance de la ressource gérée sous-jacente. Ce format permet à EDS et à ses collecteurs de normaliser les différents modèles de données de différents fournisseurs et de fusionner les différentes vues obtenues de différents fournisseurs, en réunissant ces espaces de noms de produits distincts dans une entité commune dans EDS. La capture d’écran suivante montre un exemple d’identifiant de machine virtuelle.

Bien qu’EDS fournisse une organisation de type CMDB de l’infrastructure et des charges de travail cloud, il existe d’autres services qui améliorent ces données. Plus important encore, la couche de présentation (par exemple, l’interface utilisateur graphique) est exploitée et augmentée par d’autres produits de gestion, de migration et de gouvernance du cloud.

[Link]

Services de plateforme notables

Je ne couvrirai pas tous les composants architecturaux de ce blog, mais le schéma ci-dessus devrait aider à comprendre où se trouvent les services dont j’ai parlé au sein de la plate-forme.

  • Service statistique et service de données dérivées : Le service Stats permet aux fournisseurs d’intégrer leurs propres données de métriques de séries chronologiques pour chaque entité. Les données de métrique ne sont ni copiées ni stockées dans EDS, mais sont récupérées via les API des fournisseurs selon les besoins. Le service de statistiques offre également certaines fonctions de prévision. Le service de données dérivé écoute les événements, les alertes et les notifications des fournisseurs. Il peut également créer des métriques spécifiques à la plate-forme qui sont stockées dans le magasin de données de Project Ensemble. Essentiellement, ces deux services fonctionnent ensemble pour fournir des métriques et observations basées sur les tendances et les prévisions pour alimenter le service Business Insights.
  • Service d’informations commerciales : Ce service fédère les observations généré à partir du service de données dérivées via un cadre basé sur un modèle connaissances. Les informations identifient l’impact des observations sur les performances, la capacité, le coût, la sécurité, la disponibilité et la connectivité. Plus important encore, ces informations tiennent compte de l’étendue du problème et des entités connexes susceptibles d’être touchées. Je discuterai de Business Insights plus en détail dans un futur blog de cette série, car il s’agit d’une fonctionnalité importante de Project Ensemble.
  • bus de données: En tant qu’autoroute pour l’échange de données, le bus de données piloté par les événements prend non seulement en charge l’ingestion d’inventaire, d’alertes, d’événements, de métriques, etc., mais fournit également des flux de données pour les mises à jour des différents modèles. Cela peut être exploité par l’utilisateur via l’API GraphQL pour s’abonner aux flux de modifications sélectionnés en temps réel.
  • La gestion du cycle de vie: Je n’entrerai pas dans les détails de ce blog, mais ce service prend en charge l’intégration (et la désintégration) pour les clients afin de fournir un retour sur investissement très rapide en déployant et en configurant les services vRealize pour tirer parti de la plate-forme avec des données d’inventaire à alimenter.

Architecture de base pour le futur

L’architecture de Project Ensemble est moderne, évolutive et extensible. Il offre une base de données graphique indépendante pour normaliser les données d’inventaire, ainsi que des services supplémentaires pour décorer ces données avec des informations commerciales exploitables.

Restez à l’écoute de mon prochain blog pour un aperçu de plus de fonctionnalités de Project Ensemble.

Vous voulez en savoir plus sur Project Ensemble ?

Si vous souhaitez être pris en considération pour la version bêta afin de fournir une contribution VMware, veuillez nous en informer ici (https://www.vmware.com/learn/1243700_REG.html) et faites-nous savoir que votre éligibilité est vérifiée.

Leave a Comment