Ce document traite des modèles d'architecture permettant de rechercher et de collecter des informations sur des éléments dans Google Cloud, sur d'autres plates-formes cloud et sur site à l'aide de la détection de services ServiceNow. 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. Ce type de 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 sont tenus de découvrir et de suivre tous les éléments de leur écosystème technique, qui peuvent potentiellement atteindre des millions. Les services informatiques doivent construire un système de gestion de la configuration qui relie ces éléments aux services techniques fournis par les éléments. Ce système doit également surveiller les éléments et les services de manière à assurer la gestion des opérations informatiques (ITOM) et des bonnes pratiques ITSM.
Pour les clients Google Cloud, une architecture commune utilise la détection 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 un large éventail d'outils pour automatiser les workflows informatiques de gestion des ressources sur plusieurs fournisseurs 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 ServiceNow pour cette architecture
Les composants de la plate-forme ServiceNow dans ces modèles d'architecture incluent les suivants:
- Une instance ServiceNow contenant une base de données de gestion de configuration (CMDB) des é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. Une CI possède plusieurs attributs qui contiennent des métadonnées spécifiques sur le composant et ses relations avec les autres CI.
- Un ou plusieurs serveurs Service Management, Instrumentation et Discovery (MID) s'exécutant dans votre projet Google Cloud. Les serveurs MID collectent les métadonnées pour les CI et les stockent dans la CMDB.
Ces modèles d'architecture définissent certaines pratiques courantes pour l'importation des données de l'inventaire des éléments cloud de Google dans la détection de l'inventaire des éléments Google Cloud Platform de ServiceNow.
Modèles d'architecture pour l'intégration à Google Cloud
Ce document présente les modèles d'architecture suivants pour l'intégration de Google Cloud à ServiceNow:
Modèle de découverte d'adresses IP sans agent de Google Cloud
Découverte de Google Cloud avec le modèle Client Collector de l'agent
Ces exemples de modèles d'architecture sont conçus pour un déploiement hybride comprenant une infrastructure dans Google Cloud et d'autres dans le cloud ServiceNow. Ils dé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 toute l'infrastructure gérée par Google en appelant les API Cloud de Google. Pour plus d'informations sur les API appelées, consultez la page 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 de base de l'architecture de découverte cloud 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 centres 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 base de données
- Conteneurs (GKE)
- Mappage de service basé sur les libellés 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 comprend les éléments suivants:
- Un projet Google Cloud (projet de service A dans le schéma), 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.
- Un deuxième projet Google Cloud (projet de service B dans le diagramme), constitué de serveurs MID exécutés dans leurs propres VM.
- Un troisième projet Google Cloud (projet hôte C du diagramme), constitué de l'interconnexion partenaire.
- Des services gérés supplémentaires tels que les API Cloud, BigQuery et Cloud Storage.
- Les 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 CMDB.
Modèle de découverte basé sur l'adresse IP sans agent de 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 nécessite davantage de charge opérationnelle pour gérer le serveur MID qu'avec 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, telles que les suivantes:
- Gestion des identifiants d'OS et sécurité
- Détection améliorée, telle que la détection basée sur des fichiers et la découverte 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 sont situés 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 de communication externe du canal de communication (ECC) (non affichée). Cette architecture est illustrée par le schéma suivant.
La partie Google Cloud de ce modèle comprend les éléments suivants:
- Le projet de service A, qui comprend deux équilibreurs de charge Google Cloud, une ou plusieurs VM, une instance GKE et un ou plusieurs serveurs MID ServiceNow. Chaque serveur MID s'exécute sur sa propre VM.
- Projet de service B, qui est constitué de 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.
- Les routes réseau configurées à partir des serveurs MID vers les API Google Cloud.
- Comptes de service permettant aux serveurs MID de se connecter à des 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 CMDB.
Détection Google Cloud avec le modèle Client Collector de l'agent
Ce modèle d'architecture comprend les éléments suivants:
- La première découverte dans le cloud.
- Un ou plusieurs serveurs MID.
Un agent ServiceNow supplémentaire, le collecteur du client d'agent, que vous installez sur vos VM. Ces agents se connectent directement aux serveurs MID et transmettent les informations supplémentaires suivantes à ServiceNow:
- Découverte en mode quasi-temps réel
- Mesure des logiciels
- Vue CI en direct
- Automatisation des workflows sur les serveurs
Cette architecture est décrite dans le schéma suivant.
La partie Google Cloud de ce modèle comprend les éléments suivants:
- Le projet de service A, qui comprend deux équilibreurs de charge Google Cloud, une ou plusieurs instances de VM, une instance GKE et un ou plusieurs serveurs MID ServiceNow. Chaque serveur MID s'exécute sur sa propre VM.
- Projet de service B, qui est constitué de 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.
- Les routes réseau configurées à partir des serveurs MID vers les API Google Cloud.
- Les routes réseau configurées à partir des serveurs MID vers des VM Google Cloud sur lesquelles des agents de détection 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 CMDB.
- Agents de découverte ServiceNow installés sur des VM Google Cloud gérées par le client.
Workflow de découverte d'éléments cloud
Les sections suivantes traitent du workflow de découverte des é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 page Installer l'agent collecteur de clients.
- 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 appeler les API Google Cloud pertinentes. Assurez-vous que les serveurs MID disposent d'une route réseau valide pour appeler les API Google Cloud.
Workflow
- L'inventaire des éléments cloud 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 comme 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 des éléments cloud dans un bucket Cloud Storage.
- Certaines informations requises ne peuvent pas être obtenues à partir de la base de données Cloud Asset Inventory. Dans le modèle sans agent, les informations sur la VM n'incluent pas la version de correctif du système d'exploitation actuelle. Pour ce niveau de détail, les serveurs MID effectuent une détection approfondie en procédant comme suit :
- Les serveurs MID créent une tâche par lot basée sur les adresses IP des VM qui nécessitent 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 la gestion des versions de correctifs et d'autres informations.
- Si les collecteurs clients de l'agent sont installés, les données qu'ils capturent sont transmises directement aux serveurs MID, plutôt que stockées dans la base de données Cloud Asset Inventory. Pour en savoir plus, consultez les pages Préparation du réseau et Configuration du serveur MID.
- Après avoir collecté les données de découverte d'éléments, les serveurs MID les stockent dans la CMDB comme suit :
- Les serveurs MID créent des CI dans la CMDB pour représenter la capacité opérationnelle fournie par chaque élément.
- Les serveurs MID détectent automatiquement les libellés 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 services.
Le processus de workflow doit être répété régulièrement en fonction des besoins. En fonction de l'échelle et de la configuration de votre déploiement, vous pouvez choisir une découverte basée sur les événements ou sur la planification. Pour en savoir plus, consultez la section "Gérer le cycle de vie de la CI" des consignes de conception CMDB.
Considérations de conception
Les sections suivantes fournissent des conseils de conception pour mettre en œuvre l'un 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 manière, les instances sont proches des éléments cloud sur lesquels elles effectuent une découverte approfondie.
Les modèles d'architecture décrits dans ce document partent du principe que votre base de données CMDB stocke les données de découverte de toutes vos ressources cloud et de toutes vos ressources sur site, et pas seulement de 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 de localiser l'installation de la CMDB dans votre environnement dépend de vos exigences spécifiques.
Décider d'utiliser les agents MID Server
Un autre point à prendre en compte lors de la conception est le fait d'utiliser les agents MID Server et les comptes de service. 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 influer sur vos coûts de support opérationnel, dont vous devez tenir 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 l'emporter sur la valeur fournie par les données.
Prise en charge multirégionale des serveurs MID
Si votre entreprise a besoin d'une compatibilité multirégionale de l'infrastructure serveur MID, vous devez déployer chaque serveur MID dans au moins deux zones de disponibilité et le dupliquer dans une autre région.
Implications en termes de coût
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 les données sont transférées hors de Google Cloud. C'est pourquoi vous devez analyser les coûts 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 entraînent des coûts de sortie inférieurs s'ils s'exécutent dans Google Cloud par rapport à 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 le meilleur rapport qualité-prix pour votre entreprise.
Par exemple, vous devez tenir compte du nombre de serveurs MID que vous déployez dans des instances Google Cloud Compute Engine. Le déploiement de serveurs MID 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 souhaitez déployer un ou plusieurs serveurs MID, consultez la page Installer plusieurs serveurs MID sur un seul système.
Considérations relatives à la compatibilité opérationnelle
Votre déploiement inclut 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. Si des contrôles de sécurité réseau intensifs existent entre Google Cloud et l'environnement dans lequel les serveurs MID sont déployés, ces contrôles 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 à laquelle une détection approfondie sera exécutée.
Sécuriser des serveurs MID
Nous recommandons 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 pour limiter la capacité d'application des modifications uniquement aux modifications approuvées via des processus ITIL ou via un pipeline CI/CD.
Sécuriser les comptes de service
Nous recommandons les pratiques de sécurité suivantes pour gérer les comptes de service:
- Si vous hébergez vos serveurs MID dans Google Cloud, l'authentification est gérée automatiquement à l'aide du compte de service associé. Si vous hébergez vos serveurs MID en dehors de Google Cloud, vous devez générer une clé de compte de service gérée par l'utilisateur pour l'authentification, puis sécuriser et auditer ces identifiants persistants. Pour plus d'informations, consultez la section Bonnes pratiques pour gérer les clés de compte de service.
- Assurez-vous que les serveurs MID utilisent un compte de service disposant uniquement des rôles et des autorisations IAM qui sont absolument nécessaires pour la découverte d'éléments. Pour en savoir plus, consultez la section Bonnes pratiques pour l'utilisation des comptes de service.
Structure des dossiers et 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 les environnements dans lesquels elle est déployée. En structurant vos ressources de cette manière, vous pouvez mapper vos éléments avec les services techniques qu'ils fournissent.
Tenez compte des modifications que vous apportez au dossier et à la structure de projet afin de prendre en charge la détection de services. 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 pour assurer la compatibilité avec ServiceNow doivent être compatibles et s'aligner sur la structure de facturation de 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 représente un exemple de hiérarchie de ressources Google Cloud sous sa 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 font référence aux libellés en tant que tags).
ServiceNow utilise les libellés que vous attribuez à vos éléments Google Cloud pour identifier vos éléments et éventuellement les mapper aux services. Le choix d'un bon schéma d'étiquetage permet à ServiceNow de surveiller votre infrastructure pour la précision de la création de rapports et de la conformité ITOM/ITSM.
Nous vous recommandons d'utiliser des libellés pour les ressources qui nécessitent une identification unique plus spécifique que ce que votre structure de dossiers et de projets autorise. Par exemple, vous pouvez utiliser des libellés dans les cas suivants:
- Si votre application nécessite des exigences de conformité strictes, vous pouvez ajouter une étiquette à toutes les ressources de l'application afin que votre organisation puisse facilement identifier toute l'infrastructure couverte.
- Dans un environnement multicloud, vous pouvez utiliser des libellés pour identifier le fournisseur cloud et la région pour 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 éléments gérés par Google qui s'exécutent dans votre VPC. Le libellé goog- est précédé des libellés attribués par Google. Vos serveurs MID ne doivent pas tenter d'effectuer une inspection approfondie de ces éléments. 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 permettre une gestion efficace des ressources, le processus de déploiement de votre organisation doit créer des structures de projet et de dossier, et attribuer des libellés d'éléments de manière cohérente à 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 en tant que code (IaC) ou des systèmes de provisionnement automatisés tels que Terraform, ServiceNow ITOM 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.
Étapes suivantes
- Pour découvrir d'autres bonnes pratiques en matière de structure des ressources pour Cloud Billing, consultez les pages Guide d'organisation des ressources de facturation Cloud et de la gestion des accès et Guide de configuration de Cloud Insights pour Google Cloud.
- Pour découvrir 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 de stratégies de pare-feu VPC dans votre organisation, consultez la page Stratégies de pare-feu hiérarchiques.
- Découvrez comment utiliser les libellés pour 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.