Classe dans le cloud

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

Pour obtenir une description des tables communes 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 du schéma dans le 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 (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’attributIsVirtual True et la relation Runs on :Runs à 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 un autre programme de découverte 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 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 dans le cloud. Un objet dans le 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, 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 dans le 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 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 aux 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 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 rapprochement CMDB (IRE).