Classe cloud

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

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

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

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

Description du 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 pour 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’ordinateur virtuel, où les CI sont généralement créés en se connectant directement à l’inventaire cloud. Toutefois, les instances d’ordinateur virtuel ne représentent pas l’utilisation réelle de l’instance dans le cloud.

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 Azur (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 exécuté sur Amazon EC2 par la classe Server [cmdb_ci_server], avec l’attribut IsVirtual défini sur true et la relation Runs on :Runs avec 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. En cours d’exécution Détection ou d’un autre programme de détection sur l’hôte Linux invité, fournit le hostnamefichier .

Vous devez disposer des éléments suivants :

Obtention de 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 Runs On :Runs

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 cloud. Un objet dans le cloud nécessite les éléments d’identification suivants :

ID d’objet : qui correspond aux 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 dans le cloud est hébergée. Par exemple, Centre de données AWS [cmdb_ci_aws_datacenter], Centre de données Azure [cmdb_ci_azure_datacenter], Centre de données Google [cmdb_ci_google_datacenter] qui sont étendus à partir du centre de données logique.
Le centre de données logique lui-même a deux entrées d’identificateur :
- ID d’objet : ID unique du centre de données logique, le cas échéant
- Région : région de la ressource cloud
Le centre de données logique a une dépendance sur les comptes de service dans le cloud, qui a deux entrées d’identificateur :
- ID d’objet : ID unique du compte, le cas échéant.
- ID de compte : l’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.