Classe dans le cloud

Description, règle d’identification et autres structures de schéma importantes pour les classes cloud CMDB .

Pour obtenir une description des tables courantes CMDB dans un système de base, reportez-vous à la section Descriptions des tables CMDB.

Figure 1. Modèle de classe AWS/Azure/OpenStack

Figure 2. Modèle de schéma cloud de centre de données IBM

Figure 3. Modèle de schéma de centre de données Google

Description de schéma dans le cloud

ServiceNow dispose de modèles étendus d’environnements cloud, notamment Amazon Web Services (AWS), Microsoft Azure Service, Google Cloud Platform (GCP) et IBM Cloud. En ce qui concerne le calcul, les modèles pour les environnements cloud et les serveurs virtuels sont similaires. Par exemple, les instances d’Amazon Elastic Compute Cloud (EC2) et de Microsoft® Azure Cloud Compute sont une extension des instances d’ordinateurs virtuels, où les CI sont généralement créés en se connectant directement à Cloud Inventory. Toutefois, les instances d’ordinateur virtuel ne représentent pas l’utilisation réelle de l’instance dans le cloud.

Le compte de services dans le cloud [cmdb_ci_cloud_service_account] est la classe principale pour le suivi des comptes dans le cloud tels qu’AWS, GCP et Azure (remplaçant, par exemple, l’utilisation de la table cmdb_ci_aws_account pour AWS).

Par exemple, vous pouvez représenter un hôte invité Linux s’exécutant sur Amazon EC2 par la classe Serveur [cmdb_ci_server], avec l’attribut IsVirtual défini sur true et la relation Runs on :Runs vers l’instance EC2. L’intégration d’AWS Config Service ou de l’application Amazon CloudWatch fournit des informations sur l’ID de l’objet EC2. L’exécution Découverte d’un autre programme de détection sur l’hôte Linux invité, fournit le hostnamefichier .

Vous devez disposer des éléments suivants :

• Obtenir l’UUID correct qui est stocké dans la table Numéro de série [cmdb_serial_number].
• Connexion/création de l’instance cloud au système d’exploitation hôte, correspondance sur l’UUID/ID d’objet et création de la relation S’exécute le/S’exécute.

En outre, il existe un modèle complet de stockage, de mise en réseau, de Lamda / Fonctions en plus de la modélisation de différentes régions à l’aide du concept de la table Centre de données logique [cmdb_ci_logical_datacenter] avec la relation Hosts :HostedOn avec le calcul, le stockage, etc.

Règle d'identification

Le système de base contient des règles d’identification prédéfinies pour les classes de schéma dans le cloud. Un objet cloud nécessite les éléments d’identification suivants :

• ID d’objet : qui est synonyme des ID que les fournisseurs dans le cloud utilisent pour chaque type de ressource dans le cloud, comme Azure Compute, EC2 et Amazon Simple Storage Service (S3).

• L’ID d’objet est unique par région et a donc une relation dépendante nécessitant des informations de la table Centre de données logique [cmdb_ci_logical_data_center], sur la région où la ressource cloud est hébergée. Par exemple, AWS Datacenter [cmdb_ci_aws_datacenter], Azure Datacenter [cmdb_ci_azure_datacenter], Google Datacenter [cmdb_ci_google_datacenter] qui sont étendus à partir de Logical Datacenter.

  Le centre de données logique lui-même a deux entrées d’identificateur :

  • ID de l’objet : ID unique du centre de données logique, le cas échéant
  • Région : région de la ressource dans le cloud

• Le centre de données logique dépend des comptes de service dans le cloud, qui ont deux entrées d’identificateur :

  • ID de l’objet : ID unique du compte, le cas échéant.
  • ID de compte : ID de compte unique qui englobe les différentes ressources dans le cloud. L’ID de compte est généralement plus applicable que l’ID d’objet.

Pour plus d'informations, consultez Identification et réconciliation CMDB (IRE).