Relacionamentos de IC no CMDB
O CMDB, em contraste com uma lista de ativos estáticos, ajuda a rastrear não apenas os itens de configuração (ICs) em seu sistema, mas também os relacionamentos entre esses itens.
- IC primário
- IC secundário
- Tipo de relacionamento que vincula ambos os ICs
- Servidor1 é o IC secundário
- Servidor2 é o IC primário
- [Gerenciado por] é o tipo de relacionamento
Por exemplo, uma aplicação da Web pode ler dados de uma instância do Oracle, que por sua vez, pode depender de uma parte do hardware subjacente. A maioria dos ICs em um CMDB tem vários relacionamentos com outros ICs, usuários e grupos.
Os relacionamentos entre ICs podem ser descobertos automaticamente. Se você usar Descoberta, muitos relacionamentos poderão ser carregados automaticamente no sistema por meio do processo de descoberta. Se você importar seus dados de outro sistema, obterá algum tipo de relacionamento.
Você pode adicionar relacionamentos descobertos automaticamente, criar ou editar relacionamentos para um IC, iniciando o Editor de relacionamento de IC no formulário de IC. Como alternativa ao editor de relacionamento de IC, em Aplicação da Store do Espaço do CMDB Fornece a funcionalidade mais recente para editar relacionamentos de IC. Para obter mais informações, consulte Edite relacionamentos no Mapa unificado .
Relacionamentos dependentes e não dependentes
Relacionamentos dependentes, como hardware tomcat RunsOn, são usados pelo Mecanismo de Identificação e reconciliação (IRE) para identificar ICs dependentes. O IRE evita entradas duplicadas de ICs em seu Configuration Management Database (CMDB) aproveitando esses relacionamentos para determinar se um IC descoberto recentemente já está no CMDB.
Para relacionamentos não dependentes, o CMDB rastreia a origem da descoberta e a hora da última verificação na tabela Origens de relacionamento [sys_rel_source]. Relacionamentos não dependentes não são usados para identificação de IC e podem ser excluídos se não forem mais necessários.
Para evitar sobrecarregar seu IRE com carga excessiva, por padrão, a tabela Origens de relacionamento [sys_rel_source] não é preenchida automaticamente. Se você quiser rastrear informações completas sobre relacionamentos não dependentes, altere o padrão usando a propriedade glide.identification_engine.populate_sys_rel_source.
Relacionamentos dependentes São usados para identificação de IC, portanto, não devem ser excluídos diretamente, pois não são rastreados.
As informações na tabela Origens de relacionamento [sys_rel_source] podem ser usadas para decidir se é seguro excluir um relacionamento potencialmente não dependente. Por exemplo, uma origem de descoberta que está tentando excluir um relacionamento não dependente pode confirmar que:
- Não há outras fontes de dados para esse relacionamento.
- O relacionamento não foi atualizado por um período de tempo especificado e, portanto, não é mais necessário.
Quando um relacionamento não dependente é excluído da tabela Relacionamento de IC [cmdb_rel_ci], todos os registros correspondentes em cascata na tabela Origens de relacionamento [sys_rel_source] são excluídos.
Relacionamentos principais
| Primário | Secundário(a) | Descrição |
|---|---|---|
| Fluxo de Aplicativo para | Fluxo de Aplicativo de | Conexões entre ICs de endpoint. Nota: Somente para uso interno (modelo de serviço). |
| Conecta-se a | Conectado por | Conexões de rede entre elementos que se comunicam. Exemplos: estação de trabalho para alternar, alternar para alternar, carga de trabalho do kubernetes para serviço. |
| Contém | Incluído em | Normalmente, um relacionamento de contenção (IC para IC contido). O IC secundário normalmente tem um único IC primário com este tipo de relacionamento. Exemplos: Tomcat para Tomcat WAR, VMware Datacenter contém rede. |
| Define recursos para | Obtém recursos de | O IC primário define/obtém recursos de um IC secundário. Exemplo: VMware - O grupo de recursos obtém recursos do servidor ESX. |
| Depende de | Usado por | O IC primário depende do IC secundário. O que significa que o problema/mudança no IC secundário pode afetar o IC primário. |
| Hospedado em | Hosts | Relacionamento de hospedagem entre um elemento e seu host. Exemplos: recurso de nuvem para datacenter lógico, carga de trabalho k8s para cluster k8s. |
| Implementar endpoint para | Implementar endpoint de | Endpoint para IC que expõe este endpoint. Nota: Somente para uso interno (modelo de serviço). |
| Gerencia | Gerenciado por | Normalmente usado quando um IC gerencia um ou mais ICs. Exemplo: o vCenter gerencia o vCenter Datacenter. |
| Membros | Membro de | Normalmente usado com clusters em que um nó do cluster é um membro de um cluster. Exemplo: o ESXi Server é membro do vCenter Cluster. |
| É Proprietário de | Pertence a | Normalmente, um relacionamento de contenção (IC para IC próprio). O IC secundário normalmente tem um único primário com este tipo de relacionamento. |
| Executado em | Execuções | Normalmente, entre um IC que representa um aplicativo de software e o hardware/VM de hospedagem. Exemplo: Tomcat "Executa em" servidor Linux. |
| Usar endpoint para | Usar endpoint de | Do IC para um endpoint de saída. Nota: Somente para uso interno (modelo de serviço). |