Rui, Isso parece grego para mim...
Perdão pela franqueza, mas no meu mundo não consegui encontrar alguém que tivesse (orgulho do seu) CMDB. Quanto mais uma federação. Obviamente isso não desacredita o conhecimento que compartilhas, mas parece-me alguém exclamando: "- O meu Porsche tem um botão y..." ou "- Na Daslu tem uma sala exclusiva para...". Quisera eu chegar neste nível de detalhe e competência. Katzo, como me sinto desesperançado ao ler seus artigos... Preciso fazer um upgrade no meu universo, hehehe. :-( Abrazon e não tome isso como uma crítica, mas como um desabafo de necedade (a palavra existe!!) EL Cohen 2010/8/1 Rui Natal <[email protected]> > > > > > Compartilhando com os amigos de Forum... > > > > *Características de uma solução de CMDB* > > ** > > *Hoje vamos nos concentrar tão somente em Federação.* > > Dados federados são dados armazenados fora do CMDB, mas ligados a IC’s e > que serão acessados através do CMDB. São informações relacionadas que por si > não qualificam um IC de forma significativa e que, portanto, devem ficar > armazenadas fora do CMDB. Um exemplo, no caso de um Incidente relacionado a > um IC, seriam atributos (campos) detalhados que por si não são importantes > para estarem no contexto do CMDB è informações do registry de uma máquina. > > Um exemplo típico é o de uma bibliotecária que acessa algumas informações > básicas e importantes a partir de uma ficha sobre o livro ou sobre a obra. > E, efetivamente o livro e a obra encontram-se em outra localidade. > > *Por que usar Federação ?* > > O CMDB deve ser a fonte única de referência ou de verdade (SST – single > source of truth) sobre seu ambiente, porém não necessariamente o repositório > único destas referências. Os produtos e ferramentas consumidoras devem > utilizar o CMDB para encontrar todos os dados de Configuração. > > O CMD deve ser o catálogo ou índice que fornece as informações básicas > sobre o que a empresa possui e como e onde acessar o restante. Em geral, > deveremos encontrar mais dados federados do que armazenados no CMDB. > > A criação de links federados aos dados existentes a partir do CMDB não > significa que se precisará acessar estes dados sempre através do CMDB. > > > A federação evita que seja necessário reescrever um aplicação para que seus > dados sejam lidos do CMDB, ao invés de seus databases atuais. > > *Que dados devem ser federados ?* > > Atributos que raramente mudam, ou que mudam mais de uma vez ao dia; > atributos que usualmente não serão necessários para se tomar decisões de > negócio; informações específicas sobre um IC, tais como: requisições de > mudança ou registro de incidente. > > > > Em julho de 2009, a DMTF anunciou que aprovou o padrão Configuration > Management Database Federation (CMDBf) para faciltar o compartilhamento de > informações entre CMDB’s e outros repositórios com dados de gerenciamento > (Management Data Repositories – MDR). Este novo padrão é a primeira > tecnologia a prover uma solução “*cross-vendor*” padronizada para federar > dados de gerenciamento de sistemas. > > A novidade com a introdução da versão 3 do ITIL foi o conceito de Sistema > de Gerenciamento de Configuração (CMS - Configuration Management System). É > o sistema responsável por manter informações sobre os itens de configuração > requeridos na entrega de um serviço de TI, incluindo seus relacionamentos. > Em nível de dados, o CMS pode requerer dados de vários CMDB’s físicos, os > quais, juntos, constituem um “CMDB federado”. Outras fontes de dados também > são conectadas ao CMS, como a DML (Definitive Media Library). > > > > Bom dia a todos. > > > > Rui Natal > > >
