Proposta de um Framework para Gerência de Clusters - PDF
Proposta de um Framework para Gerência de Clusters
Download "Proposta de um Framework para Gerência de Clusters"
João Lucas Graça Lagos
1 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA APLICADA Proposta de um Framework para Gerência de Clusters Dissertação submetida à Pontifícia Universidade Católica do Paraná como requisito parcial à obtenção do grau de Mestre em Informática Aplicada por Daniel Francisco Wandarti Curitiba, janeiro de 2003
3 Proposta de framework para gerência de clusters. Daniel Francisco Wandarti Esta dissertação foi julgada adequada para a obtenção do título de Mestre em Informática Aplicada na especialidade Sistemas Distribuídos, e aprovada em sua forma final pelo curso de Pós-Graduação. Curitiba, janeiro de Prof. Dr. Carlos Alberto Maziero, orientador Prof. Dr. Carlos Alberto Maziero coordenador do curso de Pós-Graduação em Informática Aplicada da Pontifícia Universidade Católica Paranaense. Banca Examinadora Prof. Dr. Edgar Jamhour Prof. Dr. Luiz Nacamura Junior
5 aos meus pais Henrique e Edite
7 Agradecimentos Sou muito grato aos meus pais, pelo apoio e por tudo que fizeram por mim. Também sou muito grato ao meu orientador, Professor Carlos Maziero, pela sua paciência, dedicação e por suas valiosas informações.
9 Resumo O objetivo desta dissertação de mestrado é estudar, propor e implementar uma ferramenta para gerência de clusters abertos. Esta dissertação de mestrado faz parte do projeto ParaPUC que está em desenvolvimento desde outubro de 1998 no programa de Pós-Graduação de Informática Aplicada da PUCPR. O projeto aqui descrito é inspirado do projeto Beowulf da NASA (e outros projetos similares). Beowulf é um conjunto de PCs de mercado (mass-market comodity off the shelf) interconectados através de uma rede local de baixo custo (LAN - Local Area Network) rodando sobre sistema operacional de mercado e aplicações paralelas que utilizem alguma biblioteca de troca de mensagem no padrão PVM/MPI. Um cluster de PC beowulf é conhecido pela sua facilidade de construção e baixo custo, onde com apenas alguns PCs e uma rede local é possível obter um cluster com poder de processamento parecidos com o de um supercomputador. Devido à esta facilidade de construção surge um problema com relação ao beowulf, que é a sua gerência. Este problema reside no fato de que é necessário gerenciar vários nós utilizando uma ferramenta com baixo impacto, que seja expansível, escalável e interoperável. A dissertação é composta de uma revisão bibliográfica sobre arquiteturas paralelas e clusters, uma revisão sobre gerência de sistemas e gerência de clusters e a proposta para uma ferramenta de gerência de clusters baseada em CIM, CORBA e Java. Esta proposta inclui uma proposta para extensão do CIM, a classe Cluster.
11 Abstract The goal of this Master thesis is to study, to define and to implement a management tool for open clusters. This activity is being carried under the ParaPUC project of the Postgraduate Program in Applied Computer Science of the Pontifícia Universidade Católica do Paraná. This project is inspired on the NASA s Beowulf project (and other similar projects). A Beowulf cluster is a set of mass-market off the shelf PCs interconnected through a low cost local area network (LAN), running on operational system of market and parallel applications that use some library of message passing libraries like PVM or MPI. Beowulf clusters are know by their easiness of construction and low cost. With only standards PCs and a local network is possible to get a cluster with power of processing similar to the one of a supercomputer. Although their construction easiness, the management of such clusters is a problem that remains to be solved in an open way. The management infrastructure should be flexible (to easily support changes in the cluster structure), should use light protocols and have a small memory and processing footprint, should be also escalable and interoperable. This dissertation is composed of a bibliographical revision about parallel architectures and clusters, a revision about system management and cluster management and the proposal of a tool to manage open clusters based in CIM, CORBA and Java. This proposal includes a CIM extension, the class Cluster.
13 Sumário 1 Introdução 1 2 Conclusão e perspectivas 3 3 Gerência de sistemas Conceitos básicos Ciclo da gerência Informações de gerência Modelo básico de gerência Polling e Event Reporting Áreas de gerência de sistemas Gerência de falhas Gerência de contabilização Configuração Definindo a informações de configuração Gerência de desempenho Gerência de segurança Padrões de gerência OSI SNMP SNMPv SNMPv CORBA CIM WBEM JMX Comparação entre padrões Conclusão xiii
14 4 Gerência de clusters Aspectos da gerência de clusters Trabalhos existentes SUMO SCMS ClusterProbe PHOENIX PARMON Análise crítica Deficiências Tecnologias usadas Aspectos comuns Conclusão Arquitetura proposta Ambiente Arquitetura Diagrama de eventos Componentes do Sistema GUI Object Manager Object Provider Objetos CIM Contexto Extensibilidade Referência Estruturas Monitoração Alarme Classes CIM Classe Cluster Adicionando classes CIM Áreas de gerência Exemplos Resultados obtidos Conclusão
15 6 Conclusão e perspectivas 75
17 Lista de Figuras 3.1 Ciclo da gerência Modelo agente/gerente MFD Processo gerenciador Modelo XRM Esquema Domínio e faixa Metaschema (obtido de [DMT01]) Componentes chave do JMX Arquitetura WBEM Arquitetura SMILE Arquitetura PARMON Arquitetura proposta Diagrama de eventos para obter o valor de uma propriedade Diagrama de eventos para monitorar o valor de uma propriedade Diagrama de eventos para criar um alarme Diagrama para classe Cluster Tela principal da GUI Tela quando um alarme é gerado na GUI Tela de monitoração das CPUs na GUI xvii
19 Lista de Tabelas 3.1 Camadas OSI Tabela comparativa dos padrões SNMP, OSI e CIM Funcionalidades do SCMS Ferramentas suportadas na implementação atual do SCMS xix
21 Capítulo 1 Introdução A procura pelo maior poder de processamento tem sido um dos principais esforços no desenvolvimento de computadores. Antes da era do computador, cientistas e engenheiros não conseguiam imaginar a possibilidade de se executar algumas centenas de instruções por segundo. Entretanto, logo que se depararam com esta possibilidade, clamam por ainda mais poder computacional. Por séculos, a ciência tem seguido o paradigma de primeiro observar, teorizar e, somente então, testar a teoria através de experimentos. Similarmente, engenheiros têm projetado, desenvolvido e testado um protótipo, para, finalmente, desenvolver um produto final. Porém, é mais barato e mais rápido realizar simulações detalhadas por computador e, então, fazer os experimentos ou construir o protótipo. Há, também, os casos em que a simulação não pode ser acompanhada de experimentação, como a evolução do universo. Desta maneira, a necessidade de maior poder computacional tem gerado ainda mais expectativas. Mas como construir computadores capazes de efetuar bilhões de operações por segundo? A opção mais simples e direta é estender as tecnologias existentes, que são bem conhecidas, ou seja, tentar construir um computador com arquitetura talvez similar à de Von Neumann, com um processador extremamente rápido. Seria muito difícil, para não dizer impossível, com a tecnologia atual, ter um processador com capacidade de executar bilhões de cálculos por segundo. Então, a solução é dividir para conquistar. Assim, se um processador não consegue efetuar bilhões de operações por segundo, centenas de processadores conseguem. Com isto, surgiram os supercomputadores e, após, os clusters de computadores. Dentre os clusters de computadores, o mais difundido, atualmente, é o Beowulf, um cluster aberto, que utiliza PCs de mercado, com sistema operacional de mercado e uma biblioteca padrão de troca de mensagens. No entanto, com o aparecimento desta nova classe, o Beowulf, surgiu, também, um pro-
22 1. Introdução 2 blema: como administrar e monitorar de forma efetiva estes computadores, conjuntamente com o sistema operacional e a aplicação? Existem algumas ferramentas propostas, mas nenhuma que auxilie na administração do cluster de forma satisfatória e que tenha, também, as características de ser expansível, escalável, de baixo impacto e interoperável. A base desta dissertação é uma proposta para uma arquitetura de gerência de clusters Beowulf que satisfaça as condições de ser expansível, escalável, de baixo impacto e interoperável. Para satisfazer estas condições, será utilizado padrão CIM (Common Information Management) para a representação da informação gerenciada. A comunicação será feita através de CORBA e a implementação com Java. A dissertação é composta de 6 capítulos, assim distribuídos: no capítulo dois é feita uma revisão bibliográfica sobre arquiteturas paralelas e clusters; no capítulo três é apresentada uma revisão sobre a gerência de sistemas, sendo abordados, também, os padrões - SNMP, OSI, CORBA, CIM, WBEM e JMX, além de uma comparação entre os padrões de representação da informação - SNMP, OSI e CIM; o capítulo quatro trata de gerência de clusters, apresentando alguns trabalhos existentes - SUMO, ClusterProbe, SCMS e PHOENIX; o capítulos cinco apresenta a proposta da arquitetura, uma proposta para extensão do CIM e alguns resultados obtidos; o capítulo seis conclui o trabalho.
23 Capítulo 2 Conclusão e perspectivas O desenvolvimento da tecnologia de Clusters de PCs Beowulf foi a solução para muitos problemas existentes na época em que havia apenas arquiteturas proprietárias para processamento paralelo. Entre eles, as padronizações na programação, não havendo mais a necessidade de reescrever programas para as novas tecnologias, e a obtenção de conhecimento em processamento paralelo, considerado, agora, um investimento. Outra vantagem também é o preço, pois agora estes supercomputadores são muito mais acessíveis. A gerência de redes também já teve muitos problemas, até o surgimento de padrões. O primeiro destes padrões foi o SNMP, hoje, o mais difundido. Porém, este ainda possui diversas deficiências, estimulando, assim, o surgimento de novos padrões. Dentre estes, o mais interessante é o CIM, pois objetiva modelar a informação, seja heterogênea ou não, e esta modelagem segue uma orientação a objetos. Com a tecnologia de clusters abertos ainda há um vazio - a gerência de forma satisfatória. A criação de uma ferramenta para gerência de clusters que utilizem um padrão para a modelagem da informação e CORBA para comunicação entre gerente e agente foi uma união muito feliz. Com a utilização de CORBA, foi possível o desenvolvimento de uma ferramenta que satisfizesse os requisitos necessários para uma ferramenta de administração de clusters abertos. A contribuição efetiva deste trabalho está na criação de uma ferramenta para gerência de clusters abertos, visto que grande parte das ferramentas atuais limita-se apenas à monitoração. Outra característica, também ausente em grande parte das ferramentas atuais, é a expansibilidade, sendo possível, ao usuário, acrescentar alguma(s) classe(s) para a gerência de sua própria aplicação. Alguns tópicos podem ser considerados na continuidade deste objetivo: Módulo de agendamento: um módulo que saiba a carga de cpu de todos os nós, memória livre e o grau de completude das tarefas e, através de um módulo desenvolvido
24 2. Conclusão e perspectivas 4 para conversar com a aplicação em um determinado protocolo, (exemplo: PVM/MPI [Ge94]) agendar em quais nós devem ser executadas determinadas tarefas [LSW99] [Fer99]. Com tal módulo fica mais fácil detectar um eventual deadlock entre processos e também é possível determinar o grau de utilização dos nós [Fer99] [Ge97]; Otimização dos OPs: otimizar os OPs, utilizando linguagem e/ou ORB mais leves para que possam rodar em micros menos potentes, tornando mais viável sua utilização em um grid computacional [FdRdR02]; Ponte SNMP: fazer uma ponte SNMP, sendo possível obter dados disponíveis somente através deste protocolo [GXF95] [AMR99]; PCIM: acrescentar à ferramenta as classes relativas ao PCIM [IET02]; ORB com multicast: adaptar a ferramenta para utilizar um ORB que suporte multicast para ser usado no momento que for obter/armazenar valores de propriedades ou invocar métodos de um contexto de nós do cluster [BdSFL02] [UPAM00]; Segurança: desenvolver um módulo de segurança para a ferramenta.
25 Capítulo 3 Gerência de sistemas À medida que redes e sistemas crescem, crescem, também, a complexidade, a importância, a heterogeneidade e o custo de gerenciamento. Para minimizar tais fatores surgiu o SNMP (Simple Network Management Protocol), padrão criado para ser utilizado em uma variedade de equipamentos e sistemas, que possam ser utilizados de forma independente de fornecedor [Sta93]. Os principais requerimentos para investir em gerência de sistemas são: controlar recursos estratégicos, controle da complexidade, melhora do serviço, balanceamento de necessidades, redução do downtime e controle de custos. Gerência de sistemas é a prática de (a) monitorar e controlar uma rede existente de modo que os computadores estejam rodando e que satisfaçam as expectativas dos usuários, (b) planejar extensões e modificações da rede para satisfazer a demanda, (c) incorporar novos elementos à rede, facilmente, sem interferir nas operações existentes [Lew95]. Uma grande rede não pode ser gerenciada somente por esforços humanos, é necessária a utilização de ferramentas para seu auxílio. À medida que o tempo passa, estas ferramentas têm ficado cada vez mais complexas e também se evidencia o aumento do número de revendedores de equipamentos. Conclui-se, daí, que uma rede que não pode ser gerenciada corretamente possui pouco valor. 3.1 Conceitos básicos A seguir, alguns conceitos básicos em gerência de sistemas, como o ciclo da gerência, modelo gerente/agente e informações de gerência Ciclo da gerência O ciclo da gerência de sistema é um ciclo composto de:
26 3. Gerência de sistemas 6 Coleta de dados: monitoração dos recursos gerenciados; Diagnóstico: tratamento e análise dos dados coletados para delinear o problema; Ação: controle sobre os recursos gerenciados para corrigir o problema. Coleta de Dados Ação Diagnóstico Figura 3.1: Ciclo da gerência Informações de gerência As informações para monitoramento podem ser classificadas em: Estática: caracteriza a configuração corrente e seus elementos. Informações que mudam com pouca freqüência, por exemplo, número de portas de um router; Dinâmica: relacionada aos eventos da rede, por exemplo, número de pacotes enviados; Estatística: informações que podem derivar das informações dinâmicas, por exemplo, número de pacotes perdidos nos últimos 2 minutos. Para que a gerência de uma rede ou sistema seja efetiva, é necessário monitorar seu desempenho. Uma das dificuldades mais encontradas na gerência de redes ou sistemas é a seleção e uso apropriados dos indicadores [Sta93]. Algumas dificuldades: Muitos indicadores em uso; O significado dos indicadores não bem compreendidos;
27 3. Gerência de sistemas 7 Alguns indicadores introduzidos e suportados por somente alguns fabricantes; Grande parte dos indicadores não passíveis de comparação entre eles; Os indicadores medidos corretamente mas interpretados erroneamente; Em muitos casos, o cálculo dos indicadores leva muito tempo, e o resultado final dificilmente pode ser utilizado para controlar o ambiente. Os indicadores se encaixam nas seguintes categorias: métricas orientadas ao serviço e métricas orientadas à eficiência. Para julgar se uma rede supre as necessidades é preciso verificar se os indicadores de um determinado serviço satisfazem o usuário. Por isto, um indicador orientado a serviço é mais importante que um indicador orientado à eficiência: Disponibilidade: probabilidade de o sistema estar operacional no instante de tempo t; Tempo de resposta: tempo gasto pelo sistema para reagir a uma determinada entrada de dados; Exatidão: transmissão exata entre usuário e host e vice-versa, logicamente essencial para qualquer rede; Throughput: é uma métrica orientada à aplicação, como exemplo: pode incluir número de um certo tipo de transações num determinado intervalo de tempo ou número de sessões de usuários para uma aplicação durante certo tempo; Utilização: métrica mais detalhada que throughput, refere-se em determinar o percentual de tempo que um recurso esteve em uso por um determinado tempo Modelo básico de gerência Componentes de um sistema de gerência de rede (figura 3.2): Aplicação de gerência: gerencia a rede visível para o usuário, como monitoração de desempenho, monitoramento de falhas e monitoramento de contabilização; Função de gerente: desempenha a função de monitoração básica, retornando informações retornadas por outros elementos da configuração; Função do agente: recolhe e armazena as informações de gerência para um ou mais elementos e comunica as informações para o monitor;
28 3. Gerência de sistemas 8 Entidade gerenciada Aplicação de Gerencia Objetos gerenciados operações eventos Gerente requisição e resposta evento Agente MIB Banco de dados Protocolo de gerência Figura 3.2: Modelo agente/gerente Objetos gerenciados: informação gerenciada que representa os recursos e suas atividades. Vale ressaltar um módulo funcional adicional, relacionado com informações estatísticas: Agente de monitoração: gera análises estatísticas e sumarizadas de informações gerenciais. Se o gerente for remoto, este módulo age como um agente e comunica as informações sumarizadas ao gerente. Os módulos funcionais podem ser configurados de diversas maneiras. A estação que roda a aplicação de monitoração também é sujeita a ser monitorada. Assim, o monitor geralmente inclui software agente e um conjunto de objetos gerenciados. É vital monitorar o status e comportamento do monitor da rede para garantir a continuidade do desempenho de suas funções e o acesso à própria carga, além da rede. Aqui não são usados os termos cliente e servidor já que estes podem ter muitos sentidos em um sistema distribuído.
29 3. Gerência de sistemas Polling e Event Reporting A informação utilizada por monitores de redes é coletada e armazenada por agentes e disponibilizada para um ou mais gerentes do sistema. Duas técnicas são usadas para tornar o agente da informação disponível ao gerente: Pooling: seqüência de interações requisição-resposta entre gerente e agente. O gerente pode indagar qualquer agente (desde que tenha autorização) e requisitar os valores de vários elementos da informação; o agente responde com a informação de sua MIB. event reporting: a iniciativa é do agente e a função do gerente é ouvir, esperando a chegada de informações. Um agente pode gerar um relatório, periodicamente, informando seu status atual. Ambos são muito práticos e uma monitoração típica irá utilizar os dois métodos, variando, apenas, a ênfase utilizada. 3.2 Áreas de gerência de sistemas As cinco grandes áreas de gerência de sistemas são: gerência de falhas, gerência de contabilização, configuração, gerência de desempenho e segurança [Sta93] Gerência de falhas Para manter o funcionamento do sistema de forma correta, o gerente precisa cuidar do sistema como um todo e de cada componente essencial, individualmente. Quando uma falha ocorre, o gerente deve: 1. determinar o local da falha; 2. isolar o sistema do ponto de falha; 3. reconfigurar ou modificar o sistema de forma a minimizar o erro; 4. consertar ou trocar os componentes falhos. Deve-se atentar para a diferença entre falhas e erros. Uma falha é uma condição anormal que requer atenção (ou ação) do gerente para corrigir - talvez até a troca de um equipamento físico - e erro é um simples evento - como uma violação de CRC na transmissão de um pacote. Problemas no monitoramento de falhas Em um ambiente complexo, a localização e diagnóstico de uma falha podem ser difíceis. Algumas dificuldades na localização da falha:
30 3. Gerência de sistemas 10 Falhas não observáveis: certas falhas não podem ser observadas localmente. Por exemplo, um deadlock entre processos distribuídos; Falhas parcialmente observáveis: um nó falho pode ser observado, mas a observação pode ser insuficiente para indicar o erro. O nó pode não estar respondendo devido à falha de algum dispositivo de baixo nível; Falhas observáveis incertas: mesmo com observações detalhadas, existem algumas observações que se tornam incertas ou mesmo inconsistentes. O tempo de resposta muito grande de um dispositivo pode ser causado pela falha de timer local Gerência de contabilização Monitoramento de contabilização consiste em manter um registro da utilização dos recursos da rede ou sistema por um usuário ou grupo de usuários. O gerente precisa ser capaz de rastrear o uso dos seus recursos, por um usuário final ou classe de usuários finais, por razões, incluindo: Um usuário final ou grupo de usuários finais podem abusar dos seus privilégios de acesso e sobrecarregar a rede ao custo de outros usuários finais; Usuários finais podem estar tendo uma utilização ineficiente e o gerente pode ajudar ao trocar procedimentos para melhorar o desempenho; O gerente da rede está em uma posição melhor para planejar o crescimento da rede caso conheça com detalhes suficientes a atividade dos usuários finais Configuração Gerência de configuração consiste em inicializar a rede ou sistema e desligar parte ou todos seus componentes sem afetar os outros componentes ativos. Também consiste em manter, adicionar ou atualizar a relação entre componentes e o status. Uma reconfiguração é geralmente necessária quando em resposta ao desempenho ou devido a uma atualização, recuperação de falha ou checagem de segurança Definindo a informações de configuração Informações de configuração descrevem a natureza e status dos recursos que são de interesse do gerente do sistema ou rede. A informação de configuração inclui uma especificação
31 3. Gerência de sistemas 11 do recurso gerenciado e os atributos destes recursos. Os recursos podem ser físicos (roteadores, facilitadores de comunicação, HDs) ou lógicos (temporizadores, contadores, espaço físico). Atributos podem ser, por exemplo, nome, endereço, número de identificação. Estas informações de configuração podem ser estruturadas de diversas maneiras: Uma lista estruturada, simples, de campos de dados, com cada campo contendo um valor único. Esta é a abordagem utilizada pelo padrão SNMP; Um banco de dados orientado a objetos. Cada elemento de interesse é representado por um ou mais objetos. Cada objeto contém atributos cujos valores refletem as características do elemento representado. Um objeto pode, também, conter comportamentos, como notificações a serem geradas, caso ocorram certas relações de eventos desse elemento. Esta é a abordagem utilizada pelo padrão OSI; Um banco de dados relacional. Campos individuais, no banco, contêm valores que refletem características da rede de elementos. A estrutura do banco reflete a relação entre elementos da rede. Apesar dessas informações serem acessíveis à estação do gerente, são geralmente armazenadas perto do recurso em questão, seja no agente do nó, se o recurso é parte do nó, seja no proxy do nó, se o nó que contém o recurso não suporta um software agente. A função de controle deveria habilitar o usuário a especificar os limites e tipos de valores, cujos atributos de um recurso específico de algum agente possam ser configurados. Os limites podem ser uma lista de todos os estados de valores ou os valores máximo e mínimo para parâmetros e atributos. O tipo do valor permitido, também deveria ser especificado Gerência de desempenho Redes de comunicação modernas são compostas de muitos componentes heterogêneos, que necessitam se intercomunicar e compartilhar dados e recursos. Muitas vezes, é crítico para uma aplicação que a comunicação sobre a rede tenha um desempenho mínimo garantido. Esta gerência é composta de duas categorias funcionais: monitoramento e funcional. Função de monitoramento é a função que rastreia atividades e a função de controle habilita a gerência a fazer ajustes para melhorar o desempenho Gerência de segurança Consiste em gerenciar a proteção da informação de gerência e facilidades de controle de acesso. Isto inclui gerar, distribuir e armazenar chaves de criptografia. Logs são uma
32 3. Gerência de sistemas 12 ferramenta muito importante e a gerência de segurança está muito envolvida em coletar, armazenar e examinar os registros de auditoria e logs de segurança. 3.3 Padrões de gerência Existem algumas propostas e padrões de protocolos para gerência de rede: OSI (Open Systems Interconnection); SNMP (Simple Network Management Protocol); CORBA (Common Object Request Broken Architecture); CIM (Common Information Model); WBEM (Web-Based Enterprise Management); JMX (Java Management extensions). OSI, SNMP e CORBA são patrocinados pela ISSO e IETF (Internet Task Force). CIM e WBEM, pela DMTF (Distributed Management Task Force). O JMX é considerado um framework de gerência, patrocinado pela Sun e Java Community Process. Os protocolos de rede são importantes para se construir uma ferramenta de gerência de rede, mas, mais importante que isto é a maneira como se utilizam estas ferramentas e estes protocolos, já que estas ferramentas servem para auxiliar o gerente da rede OSI O modelo de gerência OSI é baseado em objetos e, seus recursos, supervisionados e gerenciados, são chamados de objetos gerenciados. Neste modelo o que um objeto gerenciado é exatamente, não importa muito, já que ele pode ser qualquer coisa (um switch, PBX, multiplexador, programas, algoritmos, etc) [Sta93]. No modelo OSI, os objetos gerenciados são classificados pela sua posição na camada OSI. Se for uma camada específica, são chamados objetos gerenciados da camada N (tabela 3.1). Os objetos com mais de uma camada são chamados sistemas de objetos gerenciados. O processo agente situa-se entre os objetos gerenciados e o sistema de controle de rede (Management Functional Domain - MFD). Múltiplos MFDs podem existir em uma empresa ou pertencer a um país. Este conceito não existe no modelo de gerência SNMP. Aspectos de um objeto gerenciado: as operações efetuadas em um objeto gerenciado devem fazer parte de sua definição;
33 3. Gerência de sistemas 13 Camada Camada 7 Camada 6 Camada 5 Camada 4 Camada 3 Camada 2 Camada 1 Descrição Protocolo do Nível de Aplicação Protocolo do Nível de Apresentação Protocolo do Nível de Sessão Protocolo do Nível de Transporte Protocolo do Nível de Rede Protocolo do Nível de Enlace de dados Protocolo do Nível de Física Tabela 3.1: Camadas OSI objeto gerenciado objeto gerenciado objeto gerenciado objeto gerenciado processo agente sistema A processo agente sistema B MFD... outros MFDs Figura 3.3: MFD a definição de um objeto gerenciado pode, também, incluir os efeitos dessa operação no recurso gerenciado; o estado/propriedade de um objeto gerenciado pode determinar as suas operações. Segundo o modelo OSI, um objeto gerenciado é definido por: atributos: os atributos não podem ser criados, deletados ou renomeados durante a instanciação do objeto. Os atributos podem ser alterados por estímulo interno e externo; operações: create (cria um novo objeto), delete (deleta um objeto existente), action (executa uma ação/operação no objeto), get value (obtém valor de um atributo), add value (adiciona um valor para um atributo), remove value (remove o valor de um atributo) e set value (seta o valor de um atributo); comportamento: o comportamento significa como o objeto reage a uma operação e certos limites colocados em seu comportamento;