Classe dans le cloud

Pour obtenir des descriptions des tables courantes CMDB dans un système de base, reportez-vous à la section 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 cloud de centre de données IBM

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

Description du schéma de cloud

ServiceNow dispose de modèles étendus d’environnements cloud, notamment Amazon Web Services (AWS), le service Microsoft Azure, 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.

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 que AWS, GCP et Azure (en 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 Serveur [cmdb_ci_server], avec l’attribut IsVirtual défini sur true et avec 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. En cours d’exécution Découverte ou d’un autre programme de détection sur l’hôte Linux invité, fournit le hostname.

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 de cloud au système d’exploitation hôte, mise en correspondance sur l’UUID/ID d’objet et création de la relation Exécutions sur :Exécutions.

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 en utilisant le 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 de 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 cloud, tels qu’Azure Compute, EC2 et Amazon Simple Storage Service (S3).
L’ID d’objet est unique pour chaque 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 de cloud est hébergée. Par exemple, le centre de données AWS [cmdb_ci_aws_datacenter], le centre de données Azure [cmdb_ci_azure_datacenter], le 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 comporte 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 dans le 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 : ID de compte unique qui englobe les différentes ressources cloud. L’ID de compte est généralement plus applicable que l’ID d’objet.

Pour plus d'informations, consultez Identification et rapprochement CMDB (IRE).