Capítulo V Arquitectura de Gestão OSI.
5 Arquitectura de Gestão OS
6.3 Funcionamento geral
Para a comunicação entre o Gestor e o Agente a Gestão de Sistema baseia-se nos princípios definidos na Arquitectura de Protocolos OSI, isto a transferência de informação de gestão pressupõe a existência de uma ligação estabelecida, em cada camada de protocolo, das entidades pares que contêm o Gestor e o Agente. Assim sendo, a transferência de informação de gestão só pode ocorrer enquanto a ligação ao nível da aplicação estiver activa, isto é, após o seu estabelecimento e antes do seu cancelamento.
Durante a fase do estabelecimento da ligação são negociadas as capacidades do serviço de gestão, através da definição das Unidades Funcionais suportadas. Neste contexto é possível especificar, por exemplo, o método de acesso aos objectos e o tipo de respostas expectáveis.
6.3.1
CMISE e CMIP
O CMISE é um serviço orientado à ligação que utiliza os serviços do Association Control Service Element (ACSE) para gestão da ligação e os serviços Remote Operation Service Element (ROSE) para transferir as operações e notificações de Gestão.
Através do ACSE efectua-se o estabelecimento, interrupção, ou terminação da ligação de Gestão. O ROSE permite o suporte de Aplicações Interactivas, em modo não confirmado ou confirmado. É através deste serviço que se enviam comandos, (Gestor → Agente), e se enviam respostas a esses comandos ou notificações (Agente →. Gestor).
Conforme já foi referido, a transferência de informação de gestão realiza-se através do protocolo de gestão CMIP. Na sua versão inicial, este protocolo do nível de aplicação é suportado sobre a pilha de protocolos OSI. Porém, existe uma outra versão, denominada de CMIP over TCPI/IP , isto é, CMOT, em que o protocolo é suportado sobre a pilha de protocolos Internet. Nesta outra versão, o protocolo é suportado em TCP/IP, sendo normalmente utilizada a Classe de Transporte 0, num serviço orientado-à-ligação, ou a Classe de Transporte 4, num serviço não orientado-à- ligação.
Na transferência de informação de gestão, através do CMIP, é possível utilizar o seguinte conjunto de PDUs:
103
• m-Get e m-Set, através das quais se efectua a leitura ou escrita de Objectos
Geridos.
• m-Cancel-Get, através da qual se cancela uma operação de GET que esteja em
curso.
• m-Action, através se realiza uma dada acção em Objectos Geridos.
• m-Create e m-Delete, através das quais se procede à criação ou remoção
dinâmica dum Objecto Gerido.
• m-Event-Report, através da qual se enviam Notificações assíncronas para o
Gestor.
Conforme se representa na Error! Reference source not found., existe uma
correspondência directa entre os serviços CMISE associados à transferência de informação de gestão e as CMIP-PDUS. Ainda de acordo com essa tabela, algumas destas transferências implicam a existência dum serviço confirmado, outras não.
Operação de Gestão1 Serviço CMISE Confirmação CMIP-PDU
Notificação M-EVENT-REPORT O m-Event-Report
Leitura M-GET C m-Get
Escrita M-SET O m-Set
Escrita valor por omissão M-SET O m-Set Execução duma acção M-ACTION O m-Action
Criação dum OG M-CREATE C m-Create
Remoção dum OG M-DELETE C m-Delete
Tabela 11: campos ASN.1 da macro de definição de objectos em SMIv1 e SMIv2
6.3.2
Unidades Funcionais
Quando se estabelece uma ligação de gestão existe uma Unidade Funcionak Básica que lhe está associada – a Unidade Funcional de Núcleo (Kernel Functional Unit) – que permite o acesso a todos os serviços CMISE, à excepção do M-CANCEL-GET. As Unidades Funcionais Adicionais permitem definir outras características da transferência de informação de gestão. Por exemplo, a execução de determinadas acções pode envolver vários objectos em simultâneo. Neste contexto, para uma única acção deverá ser devolvida uma resposta por cada um dos objectos afectados. Todas estas respostas têm de ser identificadas como fazendo parte da mesma acção, pelo que tem de existir um parâmetro identificador que as ligue. Este parâmetro é um Linked- Reply e para que esta capacidade esteja acessível é necessário que a Unidade
104
Funcional de Respostas Múltip las (Multiple Reply Functional Unit) tenha sido previamente negociada.
Quando se negocia e aceita esta unidade funcional é possível negociar a selecção de múltiplos objectos através da Unidade Funcional de Selecção de Múltiplos Objectos. Com excepção do serviço CMISE M-CREATE, é possível aplicar este critério de selecção a todos os outros e definir quais as Classes de Objectos e respectivas instâncias que se pretendem seleccionar, através da especificação de
regras de scoping, que são aplicadas na Árvore de Inclusão. Existem quatro tipos de regras que se podem aplicar na selecção de objectos com scoping e que se encontram representadas na Error! Reference source not found..
Critérios de scoping Objecto de Base Nível 2
Objecto de Base até Nível 2 A partir do Objecto de Base
Figura 34: Aplicação de regras de scoping
Quando se efectua a selecção de múltiplos objectos, é possível aplicar dois critérios de sincronização distintos no seu processamento: Sincronização Best-effort, que é a opção por omissão, ou Sincronização Atómica, quando se pretende unicidade na realização da operação.
É possível ainda efectuar uma escolha mais detalhada, ou baseada em determinadas propriedades se, após esta Unidade Funcional estar negociada, se negociar também a
Unidade Funcional de Filtragem2. EXEMPLO
Antes de continuarmos, utilizem esta tabela de exemplos para identificar outras situações em que eles sejam válidos.
Unidade Funcional Exemplo de aplicação
Respostas Múltiplas Suspender a actividade dos contadores de taxação Múltiplos objectos
(scoping) Referenciar um sistema e colocar todas as suas entidades no estado administrativo locked. Filtragem Selecção das notificações a serem enviadas para o Gestor
105
6.4 Modelo Funcional
Em Gestão OSI definem-se as 5 Áreas Funcionais, que já conhecem (certo ?), que assentam num conjunto de Funções de Gestão, que por sua vez são suportadas pelos serviços de gestão CMISE.
Esta situação está representada na Error! Reference source not found..
Event-Report Get Set Action
Create Delete Cancel-get
Se rv iç os C M IS Fu nç õe s de G es tã o Á re as Fu nc io na is State Management Alarm Reporting Management Relationship Management Event Report Management Log Control Management Security Alarm
Reporting Audit TrailSecurity ControlAccess
Accouting
Metering Metrics &Attributes Test
Management Confidence &
Diagnostic Test Summarization Function Scheduling Object Management Management Knowledge Changeover Software Management Domains & Policy Time Management Command Sequencer Response Time Monitoring
Desempenho Faltas Configuração Contabilidade Segurança
Figura 35: Arquitectura Funcional de Gestão
Como podem observar, a lista de Funções de Gestão é enorme ! Todas elas estão normalizadas, consistindo essencialmente num conjunto de Classes de Objectos pré- definidas, que se podem re-utilizar. O conjunto de Funções de Gestão está continuamente a aumentar. Vamos apenas referir algumas delas3 , nomeadamente aquelas com que já tiveram algum contacto no TeMIP.
• Object Management: estrutura de notificações pré-definidas para reportar a criação ou remoção de Objectos Geridos e a modificação dos seus Atributos. • Log Control Management: operações de coleccionamento e armazenamento de
notificações em ficheiros de Logs.
• State Management: operações para gestão do estado do Objectos Geridos.
• Alarm Reporting Management: estrutura genérica de classificação de alarmes, de acordo com o tipo, causa provável…
3Se quiserem saber mais detalhes, ou conhecer as que não forem mencionadas, para além das normas, podem encontrar descrições resumidass destas funções em [1].
106
• Access Control: operações para introduzir e processar regras de controlo de acesso.
• Scheduling: controlo temporal das operações de gestão, com base na definição de periodos de tempo seleccionados.
• Domain and Policy: estabelecimento e adminstração de domínios e a definição de critérios de policiamento
• Event Report Management: identificação das condições que originam que um dado evento seja enviado para os destinos seleccionados.