Ce document décrit les modèles d'architecture permettant de rechercher et de collecter des informations sur les composants de Google Cloud, d'autres plates-formes cloud et sur site à l'aide de ServiceNow Cloud Discovery. Ce document est destiné aux équipes chargées de l'architecture ou des opérations cloud qui connaissent bien la gestion des opérations informatiques (ITOM), la bibliothèque d'infrastructure des technologies de l'information (ITIL), les services Google Cloud tels que Compute Engine, Google Kubernetes Engine (GKE) et Cloud Asset Inventory et ServiceNow Cloud Discovery.
Présentation
De nombreuses grandes entreprises utilisent un déploiement d'infrastructure informatique hybride qui combine Google Cloud, d'autres plates-formes cloud et une infrastructure sur site. Un tel déploiement hybride est généralement l'itération initiale d'une stratégie de migration vers le cloud. Les services informatiques de ces entreprises doivent découvrir et suivre tous les éléments de leur écosystème technique, qui peuvent potentiellement se compter par millions. Les services IT doivent créer un système de gestion de la configuration qui lie ces éléments aux services techniques qu'ils fournissent. Ce système doit également surveiller les éléments et les services d'une manière compatible avec les bonnes pratiques de gestion des opérations informatiques (ITOM) et de gestion des services informatiques (ITSM).
Pour les clients Google Cloud, une architecture courante utilise la découverte de ressources cloud ServiceNow pour rechercher et collecter des informations sur les éléments dans Google Cloud, sur d'autres plates-formes cloud et sur site. ServiceNow propose une large gamme d'outils pour automatiser les workflows IT de gestion des ressources sur plusieurs fournisseurs de services cloud. Des outils tels que l'espace de travail Cloud Operations permettent aux services informatiques de créer des tableaux de bord de ressources multicloud et de gérer les configurations complexes via une interface unifiée (parfois appeléevue centralisée). Ce document présente un ensemble de modèles d'architecture pour ce scénario, une présentation de ses composants de haut niveau et une discussion sur les considérations de conception générales.
Composants de ServiceNow pour cette architecture
Les composants de la plate-forme ServiceNow dans ces modèles d'architecture incluent les éléments suivants :
- Une instance ServiceNow contenant une base de données de gestion de configuration (CMDB) d'éléments de configuration (CI). Chaque CI représente les composants de votre environnement opérationnel qui sont impliqués dans la livraison de services numériques. Un CI possède plusieurs attributs qui contiennent des métadonnées spécifiques sur le composant et ses relations avec d'autres CI.
- Un ou plusieurs serveurs de gestion, d'instrumentation et de découverte ServiceNow (MID), exécutés dans votre projet Google Cloud. Les serveurs MID collectent les métadonnées des CI et les stockent dans la base de données de gestion des configurations.
Ces modèles d'architecture définissent certaines pratiques courantes pour importer les données de l'inventaire des éléments Google Cloud dans la découverte de l'inventaire des éléments Google Cloud Platform de ServiceNow.
Modèles d'architecture pour l'intégration à Google Cloud
Ce document traite des modèles d'architecture suivants pour l'intégration de Google Cloud à ServiceNow:
Ces exemples de modèles d'architecture sont conçus pour un déploiement hybride qui inclut une partie de l'infrastructure dans Google Cloud et une autre dans le cloud ServiceNow. Elles montrent comment ServiceNow fonctionne dans Google Cloud entre l'infrastructure gérée par Google et l'infrastructure gérée par le client. Les serveurs MID ServiceNow interrogent l'ensemble de l'infrastructure gérée par Google en appelant les API Google Cloud. Pour en savoir plus sur les API appelées, consultez la section API Google Cloud Platform utilisées par les applications ITOM.
Dans chacun des modèles suivants, les composants de l'architecture interagissent dans le processus de découverte de l'inventaire des éléments Google Cloud Platform pour collecter les informations sur l'inventaire des éléments cloud requises par l'application ServiceNow Discovery et les outils associés.
Modèle de découverte Google Cloud
Le modèle d'architecture de découverte cloud de base de ServiceNow utilise des serveurs MID ServiceNow pour appeler l'inventaire des éléments Google Cloud et d'autres API Google Cloud afin de collecter des données sur les ressources, par exemple :
- Instances de VM
- Tags (clés/valeurs)
- Volumes de stockage et mappage de stockage
- Ressources de centre de données, y compris les types de matériel
- Réseaux, sous-réseaux et passerelles cloud
- Images
- Équilibreurs de charge cloud et zones de disponibilité
- Bases de données cloud et clusters de bases de données
- Conteneurs (GKE)
- Mappage de service basé sur les étiquettes de ressources
Dans ce modèle, les serveurs MID n'ont pas besoin d'identifiants, car ils ne se connectent pas aux VM pour collecter des données. Cela limite la capacité du processus de découverte à collecter des informations supplémentaires. Toutefois, ce modèle impose moins de coûts opérationnels, car il élimine le besoin de gérer et d'alterner les identifiants du serveur MID.
Cette architecture est décrite dans le schéma suivant.
La partie Google Cloud de ce modèle se compose des éléments suivants :
- Un projet Google Cloud (projet de service A dans le diagramme), qui se compose de deux équilibreurs de charge Google Cloud, d'une ou plusieurs instances de VM, d'une instance GKE et d'un ou plusieurs serveurs MID ServiceNow. Chaque serveur MID s'exécute sur sa propre VM.
- Un deuxième projet Google Cloud (projet de service B dans le diagramme), qui consiste en des serveurs MID exécutés dans leurs propres VM.
- Un troisième projet Google Cloud (projet hôte C dans le diagramme), qui comprend l'interconnexion partenaire.
- Des services gérés supplémentaires tels que les API Cloud, BigQuery et Cloud Storage.
- Des routes réseau configurées à partir des serveurs MID vers les API Google Cloud.
La partie ServiceNow se compose de l'instance ServiceNow, qui capture les métadonnées des serveurs MID et les stocke dans la CMDB.
Modèle de découverte basé sur l'adresse IP sans agent Google Cloud
Ce modèle d'architecture ajoute la détection basée sur l'adresse IP au modèle de découverte cloud de base à l'aide d'une tâche par lot et d'un compte de service Google Cloud pour vous connecter aux VM et collecter des informations supplémentaires. Ce modèle implique davantage de charge opérationnelle pour gérer le serveur MID que le modèle de base, car il nécessite la gestion et la rotation des identifiants du serveur MID. Toutefois, il étend le processus de découverte au-delà des données fournies par Cloud Asset Inventory pour inclure des données supplémentaires, comme les suivantes :
- Gestion des identifiants d'OS et sécurité
- Visibilité améliorée, comme la recherche basée sur des fichiers et la recherche de licences
- Détails d'OS
- Processus en cours d'exécution
- Connexions TCP
- Logiciels installés
Dans ce modèle d'architecture, un ou plusieurs serveurs MID ServiceNow se trouvent dans Google Cloud, tandis que l'instance ServiceNow est hébergée sur la plate-forme cloud ServiceNow. Les serveurs MID sont connectés à l'instance ServiceNow via la file d'attente du canal de communication externe (ECC) du serveur MID (non illustrée). Cette architecture est illustrée par le schéma suivant.
La partie Google Cloud de ce modèle se compose des éléments suivants :
- Projet de service A, composé de deux équilibreurs de charge Google Cloud, d'une ou de plusieurs VM, d'une instance GKE et d'un ou plusieurs serveurs MID ServiceNow. Chaque serveur MID s'exécute sur sa propre VM.
- Projet de service B, qui consiste en des serveurs MID exécutés dans leurs propres VM.
- Projet hôte C, qui comprend l'interconnexion partenaire.
- Des services gérés supplémentaires tels que les API Cloud, BigQuery et Cloud Storage.
- Détection de ServiceNow Kubernetes sur l'infrastructure GKE.
- Des routes réseau configurées à partir des serveurs MID vers les API Google Cloud.
- Les comptes de service permettant aux serveurs MID de se connecter aux VM Google Cloud nécessitant la découverte d'adresses IP sans serveur.
- Des routes réseau configurées à partir des serveurs MID vers des VM Google Cloud nécessitant la découverte d'adresses IP sans serveur.
La partie ServiceNow se compose de l'instance ServiceNow, qui capture les métadonnées des serveurs MID et les stocke dans la CMDB.
Découverte Google Cloud avec le modèle Client Collector de l'agent
Ce modèle d'architecture comprend les éléments suivants :
- Découverte initiale dans le cloud.
- Un ou plusieurs serveurs MID.
Un agent ServiceNow supplémentaire, le collecteur de clients Agent, que vous installez sur vos VM. Ces agents se connectent directement aux serveurs MID et transmettent les informations supplémentaires suivantes à ServiceNow:
- Détection basée sur le push en quasi-temps réel
- Mesure des logiciels
- Vue en direct du CI
- Automatisation des workflows sur les serveurs
Cette architecture est décrite dans le schéma suivant.
La partie Google Cloud de ce modèle se compose des éléments suivants :
- Projet de service A, composé de deux équilibreurs de charge Google Cloud, d'une ou plusieurs instances de VM, d'une instance GKE et d'un ou plusieurs serveurs MID ServiceNow. Chaque serveur MID s'exécute sur sa propre VM.
- Projet de service B, qui consiste en des serveurs MID exécutés dans leurs propres VM.
- Projet hôte C, qui comprend l'interconnexion partenaire.
- Détection de ServiceNow Kubernetes sur l'infrastructure GKE.
- Des services gérés supplémentaires tels que les API Cloud, BigQuery et Cloud Storage.
- Des routes réseau configurées à partir des serveurs MID vers les API Google Cloud.
- Des routes réseau configurées à partir des serveurs MID vers des VM Google Cloud sur lesquelles des agents de découverte ServiceNow sont installés.
La partie ServiceNow comprend les éléments suivants :
- L'instance ServiceNow, qui capture les métadonnées des serveurs MID et les stocke dans la base de données CMDB.
- Agents de détection ServiceNow installés sur des VM Google Cloud gérées par le client.
Workflow de détection d'éléments cloud
Les sections suivantes traitent du workflow de détection d'éléments Google Cloud. Ce workflow s'applique aux trois modèles d'architecture décrits dans ce document.
Installer et configurer les composants ServiceNow
- Activez les API Cloud Asset Inventory.
- Installez le collecteur de clients Agent sur vos VM. Pour en savoir plus, consultez la section Installation du collecteur de clients Agent.
- Allouez des ressources pour les ordinateurs qui hébergent les serveurs MID.
- Configurez des règles de pare-feu pour autoriser les connexions sur le port 443 entre votre instance de VM et les ordinateurs qui hébergent les serveurs MID.
- Configurez la connectivité réseau du serveur MID.
- Installez les serveurs MID.
- Configurez les serveurs MID pour qu'ils appellent les API Google Cloud appropriées. Assurez-vous que les serveurs MID disposent d'une route réseau valide pour appeler les API Google Cloud.
Workflow
- Cloud Asset Inventory compile une base de données de tous les types d'éléments compatibles dans l'environnement Google Cloud. ServiceNow utilise l'inventaire des éléments cloud en tant que source pour récupérer des informations supplémentaires afin de mettre à jour la CMDB.
- Les serveurs MID ServiceNow interrogent la base de données Cloud Asset Inventory pour obtenir des informations sur tous les éléments de l'environnement Google Cloud.
- Les serveurs MID stockent les informations sur les éléments cloud dans un bucket Cloud Storage.
- Les informations requises ne peuvent pas toutes être obtenues à partir de la base de données Cloud Asset Inventory. Dans le modèle sans agent, les informations de VM n'incluent pas la version actuelle du correctif du système d'exploitation. Pour obtenir ce niveau de détail, les serveurs MID effectuent une découverte approfondie en procédant comme suit :
- Les serveurs MID créent une tâche par lot basée sur les adresses IP des VM nécessitant une découverte approfondie.
- Dans la tâche par lot, les serveurs MID se connectent à chaque VM et interrogent le système d'exploitation pour gérer les versions de correctifs et obtenir d'autres informations.
- Si des collecteurs de clients Agent sont installés, les données qu'ils capturent sont transmises directement aux serveurs MID au lieu d'être stockées dans la base de données Cloud Asset Inventory. Pour en savoir plus, consultez les pages Préparation de la mise en réseau et Configuration du serveur MID.
- Après avoir collecté les données de découverte des composants, les serveurs MID les stockent dans la CMDB comme suit :
- Les serveurs MID créent des CI dans la CMDB pour représenter les fonctionnalités opérationnelles fournies par chaque élément.
- Les serveurs MID détectent automatiquement les étiquettes de Google Cloud et les stockent dans la CMDB. Ces libellés sont automatiquement mappés aux CI et sont utiles pour créer des mappages de service.
Le processus de workflow doit être répété périodiquement, si nécessaire. En fonction de l'échelle et de la configuration de votre déploiement, vous pouvez choisir une découverte basée sur des événements ou sur une planification. Pour en savoir plus, consultez la section "Gérer le cycle de vie du CI" dans le Guide de conception d'un CMDB.
Considérations de conception
Les sections suivantes fournissent des conseils de conception pour la mise en œuvre des modèles d'architecture décrits dans ce document.
Emplacement de l'instance ServiceNow
Dans la plupart des cas, nous vous recommandons de déployer les serveurs MID dans Google Cloud. De cette façon, les instances sont proches des éléments cloud sur lesquelles elles effectuent une découverte approfondie.
Les modèles d'architecture décrits dans ce document supposent que votre CMDB stocke des données de découverte pour toutes vos ressources cloud et pour toutes les ressources sur site, et pas seulement pour vos éléments Google Cloud. La CMDB peut être située dans le cloud ServiceNow, dans Google Cloud ou sur site. La décision finale concernant l'emplacement de la CMDB dans votre environnement dépend de vos exigences spécifiques.
Décider d'utiliser des agents MID Server
Un autre élément à prendre en compte lors de la conception est de savoir si vous souhaitez utiliser des agents et des comptes de service MID Server. Si votre processus de découverte doit collecter des informations au-delà des métadonnées fournies par l'inventaire des éléments cloud, vous devez utiliser une infrastructure de serveur MID avec des comptes de service ou, à la place, un serveur MID avec le collecteur de clients Agent. Ces deux approches peuvent avoir une incidence sur les coûts d'assistance opérationnelle, que vous devez prendre en compte dans votre conception. L'approche à utiliser dépend des données que vous devez capturer et de la manière dont vous allez les utiliser. Le coût opérationnel de la capture des données peut être supérieur à la valeur qu'elles apportent.
Compatibilité multirégionale avec les serveurs MID
Si votre entreprise a besoin d'une compatibilité multirégionale de l'infrastructure de serveur MID, vous devez planifier de déployer chaque serveur MID dans au moins deux zones de disponibilité et le répliquer dans une autre région.
Implications en termes de coûts
Lorsque vous choisissez où déployer les composants ServiceNow pour la découverte d'éléments Google Cloud, vous devez prendre en compte le coût de sortie et le coût de calcul.
Coût de sortie
Des frais de sortie sont facturés chaque fois que des données sont transférées hors de Google Cloud. Pour cette raison, vous devez analyser le coût de sortie de votre cas d'utilisation afin de déterminer la meilleure option pour localiser vos composants ServiceNow. En règle générale, les serveurs MID qui effectuent une découverte approfondie enregistrent des coûts de sortie inférieurs s'ils s'exécutent dans Google Cloud que s'ils s'exécutent sur un autre cloud ou sur site.
Coût de calcul
Les composants ServiceNow exécutés dans Google Cloud entraînent des coûts de calcul que vous devez analyser pour déterminer la meilleure valeur pour votre entreprise.
Par exemple, vous devez prendre en compte le nombre de serveurs MID que vous déployez dans des instances Google Cloud Compute Engine. Le déploiement de serveurs MID supplémentaires accélère le processus de découverte des éléments. Toutefois, cela augmente les coûts de calcul, car chaque serveur MID est déployé dans sa propre instance de VM. Pour savoir si vous devez déployer un ou plusieurs serveurs MID, consultez Installer plusieurs serveurs MID sur un même système.
Considérations relatives à la compatibilité opérationnelle
Votre déploiement comprend probablement des contrôles de sécurité réseau tels que des pare-feu, des systèmes de protection contre les intrusions, des systèmes de détection des intrusions et une infrastructure de mise en miroir de paquets. S'il existe des contrôles de sécurité réseau étendus entre Google Cloud et l'environnement dans lequel les serveurs MID sont déployés, ils peuvent créer des problèmes de compatibilité opérationnelle. Pour éviter ces problèmes, nous vous recommandons d'héberger les serveurs MID dans Google Cloud ou aussi près que possible de l'infrastructure Google Cloud qu'une découverte approfondie interrogera.
Sécuriser les serveurs MID
Nous vous recommandons d'appliquer les pratiques de sécurité suivantes pour vos instances de serveur MID:
- Assurez-vous que les serveurs MID sont isolés pour garantir que seuls les administrateurs de confiance peuvent s'y connecter.
- Assurez-vous que les serveurs MID sont protégés contre la suppression.
- Assurez-vous que les rôles IAM sont appliqués afin de limiter les capacités de modification aux seules modifications approuvées via des processus ITIL ou un pipeline CI/CD.
Sécuriser des comptes de service
Nous vous recommandons de respecter les bonnes pratiques de sécurité suivantes pour gérer les comptes de service :
- Assurez-vous que les serveurs MID utilisent un compte de service qui ne dispose que des rôles et autorisations IAM absolument nécessaires à la découverte des composants. Pour en savoir plus, consultez la section Bonnes pratiques pour l'utilisation des comptes de service.
- L'authentification ServiceNow nécessite de copier le contenu d'une clé de compte de service dans l'interface utilisateur de ServiceNow. Les clés de compte de service constituent un risque pour la sécurité si elles ne sont pas gérées correctement. Vous êtes responsable de la sécurité de la clé privée et des autres opérations décrites dans la section Bonnes pratiques de gestion des clés de compte de service. Si vous ne parvenez pas à créer une clé de compte de service, la création de clé de compte de service peut être désactivée pour votre organisation. Pour en savoir plus, consultez la page Gérer les ressources d'organisation sécurisées par défaut.
Structure des dossiers et des projets
Les dossiers et les projets sont des nœuds dans la hiérarchie des ressources Google Cloud. Pour permettre la découverte d'éléments, la structure de vos dossiers et projets doit refléter la structure de votre application et des environnements dans lesquels elle est déployée. En structurant vos ressources de cette manière, ServiceNow peut également mapper vos composants aux services techniques qu'ils fournissent.
Tenez compte de toutes les modifications que vous apportez à la structure des dossiers et des projets pour assurer la découverte ServiceNow. Le rôle principal de la structure des dossiers et des projets est de soutenir la facturation et l'accès IAM. Par conséquent, toutes les modifications que vous apportez à l'assistance ServiceNow doivent prendre en charge et s'aligner sur la structure de facturation Google Cloud de votre organisation. Pour connaître les bonnes pratiques en matière de structure de l'organisation, des dossiers et des projets Google Cloud, consultez les pages Hiérarchie des ressources et Créer et gérer des organisations.
Le diagramme suivant présente un exemple de hiérarchie des ressources Google Cloud sous forme complète. Dans cet exemple, la structure des dossiers définit l'application, et chaque projet définit un environnement.
Étiquetage
Les libellés sont des paires clé-valeur que vous pouvez attribuer à vos ressources cloud. (ServiceNow, AWS et Azure appellent les libellés tags.)
ServiceNow utilise les libellés que vous attribuez à vos éléments Google Cloud pour les identifier et les mapper éventuellement à des services. Le choix d'un bon schéma d'étiquetage permet à ServiceNow de surveiller votre infrastructure pour obtenir des rapports précis et la conformité ITOM/ITSM.
Nous vous recommandons d'utiliser des libellés pour toutes les ressources nécessitant une identification unique plus spécifique que celle autorisée par votre structure de dossiers et de projets. Par exemple, vous pouvez utiliser des libellés dans les cas suivants:
- Si votre application présente des exigences de conformité strictes, vous pouvez étiqueter toutes les ressources afin que votre organisation puisse identifier facilement toutes les infrastructures concernées.
- Dans un environnement multicloud, vous pouvez utiliser des libellés pour identifier le fournisseur de cloud et la région de toutes les ressources.
- Si vous avez besoin d'une visibilité plus précise que celle fournie par défaut par les rapports Google Cloud Billing ou l'exportation Cloud Billing vers BigQuery, les données peuvent être filtrées par libellé.
Google attribue automatiquement des libellés aux composants gérés par Google qui s'exécutent dans votre VPC. Les libellés attribués par Google commencent par goog-. Vos serveurs MID ne doivent pas essayer d'effectuer une inspection approfondie de ces composants. Pour en savoir plus sur les libellés des ressources gérées par Google, consultez les pages Mappage basé sur des tags et Attribuer des libellés automatiquement aux ressources en fonction des notifications en temps réel de Cloud Asset Inventory.
Le tableau suivant répertorie les libellés que les services Google Cloud attribuent aux ressources qu'ils gèrent.
| Service Google Cloud | Libellés ou préfixe de libellé |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
|
| Dataproc |
|
| Vertex AI Workbench |
|
Pour faciliter la gestion des ressources, le processus de déploiement de votre organisation doit créer des structures de projets et de dossiers, et attribuer des libellés d'éléments de manière cohérente dans l'ensemble de votre organisation. Des incohérences au niveau de l'infrastructure et des étiquettes peuvent compliquer la gestion d'un système CMDB correct sans processus manuels susceptibles d'être incompatibles et qui posent problème à long terme.
La liste suivante suggère des bonnes pratiques pour rendre votre processus de déploiement cohérent et reproductible :
- Utiliser une Infrastructure as Code (IaC) ou des systèmes de provisionnement automatisé tels que Terraform, l'ITOM ServiceNow ou Provisionnement et gouvernance du cloud avec Google Cloud Deployment Manager.
- Mettre en place un processus de gouvernance efficace pour vos étiquettes. Pour en savoir plus sur la gouvernance des libellés, consultez la section Gouvernance des tags dans la documentation de ServiceNow.
Étape suivante
- Pour découvrir d'autres bonnes pratiques en matière de structure de vos ressources pour Cloud Billing, consultez les pages Guide sur l'organisation des ressources et gestion des accès liés à Cloud Billing et Guide de configuration de Cloud Insights pour Google Cloud.
- Pour connaître les bonnes pratiques en matière de structure des autorisations IAM de votre organisation, consultez les pages Bonnes pratiques pour planifier des comptes et des organisations et Provisionnement et gouvernance du cloud.
- Pour connaître les bonnes pratiques en matière de structure des stratégies de pare-feu VPC au sein de votre organisation, consultez la page Stratégies de pare-feu hiérarchiques.
- Découvrez comment utiliser des libellés pour assurer la détection basée sur des tags de ServiceNow.
- En savoir plus sur le collecteur de clients Agent ServiceNow, un mécanisme push qui s'exécute dans votre projet Google Cloud et envoie des données de sortie à l'instance ServiceNow via le serveur MID, stockant des événements et des métriques dans la base de données concernée.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.