Relations CI dans le CMDB
Contrairement CMDBà une liste d’actifs statique, le , vous aide à suivre non seulement les éléments de configuration (CI) au sein de votre système, mais également les relations entre ces éléments.
- CI parent
- CI enfant
- Type de la relation qui relie les deux CI
- Server1 est le CI enfant
- Server2 est le CI parent
- [Géré par] est le type de relation
Par exemple, une application Web peut lire les données d’une instance d’Oracle, qui à son tour peut dépendre d’un matériel sous-jacent. La plupart des CI d’un ont plusieurs CMDB relations avec d’autres CI, utilisateurs et groupes.
Les relations entre les CI peuvent être automatiquement détectées. Si vous utilisez Découverte, de nombreuses relations peuvent être chargées automatiquement dans le système via le processus de détection. Si vous importez vos données à partir d’un autre système, vous obtenez une forme de relations.
Vous pouvez ajouter des relations détectées automatiquement, créer des relations ou modifier des relations pour un CI en lançant le Éditeur de relations CI formulaire à partir du CI. Comme alternative à l’éditeur de relations CI, Carte unifiée dans fournit Espace de travail CMDB Application de l’App Store les dernières fonctionnalités de modification des relations CI. Pour plus d’informations, consultez Modifier les relations dans la carte unifiée.
Relations dépendantes et non dépendantes
Les relations dépendantes, telles que Tomcat RunsOn Hardware, sont utilisées par l’Identification and Reconciliation Engine (IRE, Moteur d’identification et de rapprochement) pour identifier les CI dépendants. L’IRE évite les entrées en double de CI dans votre Base de données de gestion des configurations (CMDB) en tirant parti de ces relations pour déterminer si un CI récemment découvert se trouve déjà dans la CMDB.
Pour les relations non dépendantes, la CMDB suit la source de découverte et l’heure de la dernière analyse dans la table Sources de relation [sys_rel_source]. Les relations non dépendantes ne sont pas utilisées pour l’identification des CI et peuvent être supprimées lorsqu’elles ne sont plus nécessaires.
Pour éviter d’accabler votre IRE d’une charge excessive, par défaut, la table Sources de relations [sys_rel_source] ne se remplit pas automatiquement. Si vous souhaitez suivre toutes les informations sur les relations non dépendantes, vous pouvez modifier la valeur par défaut à l’aide de la propriété glide.identification_engine.populate_sys_rel_source.
Les relations dépendantes sont utilisées pour l’identification des CI, elles ne doivent donc pas être directement supprimées, car elles ne sont pas suivies.
Les informations de la table Sources de relation [sys_rel_source] peuvent être utilisées pour décider s’il est prudent de supprimer une relation potentiellement non dépendante. Par exemple, une source de découverte qui tente de supprimer une relation non dépendante peut confirmer que :
- Il n’existe aucune autre source de données pour cette relation.
- La relation n’a pas été mise à jour pendant une période spécifiée et n’est donc plus nécessaire.
Lorsqu’une relation non dépendante est supprimée de la table Relation de CI [cmdb_rel_ci], tous les enregistrements correspondants en cascade dans la table Sources de relation [sys_rel_source] sont supprimés.
Relations clés
| Société parente | Enfant | Description |
|---|---|---|
| Flux applicatif vers | Flux applicatif à partir de | Connexions entre les CI des points de terminaison. Remarque : Pour un usage interne uniquement (modèle de service). |
| Se connecte à | Connecté par | Connexions réseau entre des éléments qui communiquent entre eux. Exemples : station de travail à commuter, basculer à commuter, charge de travail Kubernetes à service. |
| Contient | Contenu par | Généralement, une relation d’imbrication (CI à CI imbriqué). Le CI enfant a généralement un seul CI parent avec ce type de relation. Exemples : Tomcat à Tomcat WAR, VMware Datacenter contient Réseau. |
| Définit des ressources pour | Obtient les ressources de | Le CI parent définit/obtient des ressources d’un CI enfant. Exemple : VMware : le pool de ressources obtient les ressources du serveur ESX. |
| Dépend de | Utilisé par | Le CI parent dépend du CI enfant. Cela signifie qu’un problème/changement dans le CI enfant peut avoir un impact sur le CI parent. |
| Hébergé sur | Hôtes | Relation d’hébergement entre un élément et son hôte. Exemples : ressource dans le cloud vers centre de données logique, charge de travail k8s vers grappe k8s. |
| Implémenter le point de terminaison dans | Implémenter un point de terminaison à partir de | Point de terminaison vers CI qui expose ce point de terminaison. Remarque : Pour un usage interne uniquement (modèle de service). |
| Gère | Géré par | Généralement utilisée lorsqu’un CI gère un ou plusieurs autres CI. Exemple : vCenter gère vCenter Datacenter. |
| Membres | Membre de | Généralement utilisé avec les clusters où un nœud de cluster est membre d’un cluster. Exemple : ESXi Server est membre de vCenter Cluster. |
| Possède | Propriété de | Il s’agit généralement d’une relation d’imbrication (CI à CI détenu). Le CI enfant a généralement un seul parent avec ce type de relation. |
| S’exécute sur | Exécutions | Généralement entre un CI qui représente une application logicielle et le matériel/ordinateur virtuel d’hébergement. Exemple : Tomcat 'Runs on' Serveur Linux. |
| Utiliser un point de terminaison vers | Utiliser un point de terminaison à partir de | Du CI vers un point de terminaison sortant. Remarque : Pour un usage interne uniquement (modèle de service). |