Baixado 61 vezes
Carregado porMauro Tapajós
Gerência de Redes - 8.Tópicos Avançados
O documento discute novos desenvolvimentos em gerenciamento de sistemas especializados, incluindo gerenciamento baseado na web, objetos distribuídos, gerenciamento móvel e inteligência artificial. Também aborda tópicos como gerenciamento de hosts, aplicações, capacidade, mudanças e integração com as organizações.
Mais conteúdo relacionado
Semelhante a Gerência de Redes - 8.Tópicos Avançados
Gerência de Redes - 8.Tópicos Avançados
- 1.
- 2. Gerenciamento Especializado Hoste Serviços
- 3.
- 4.
- 5.
- 6. SLM Integração deSistemas de Gerenciamento com a Organização
- 7.
- 8.
- 9. Novidades com relaçãoa SNMP SMUX – SNMP Multiplexing
- 10. SNMP DPI (DistributedProtocol Interface)
- 11. Agent extensibility Protocol(AgentX)
- 12.
- 13. Novas Abordagens emGerenciamento Sistemas especialistas (AI)
- 14.
- 15.
- 16.
- 17. DMTF – Distributed Management Task Force
- 18.
- 19. DISMAN – Distributed Management Distributed Management Expression MIB (RFC 2982)
- 20. Event MIB (RFC2981)
- 21. Notification Log MIB(RFC 3014)
- 22. Definitions of ManagedObjects for the Delegation of Management Scripts (RFC 3165)
- 23. Definitions of ManagedObjects for Scheduling Management Operations (RFC 3231)
- 24. Alarm MIB (RFC3877)
- 25. Alarm Reporting ControlMIB (RFC 3878)
Notas do Editor
- #3 SMUX – SNMP Multiplexing – RFC 1227 (1991): - Padrão para a comunicação do agente SNMP com outros processos que querem disponibilizar MIB's através do agente - Define uma MIB SMUX - Obsoleto pelas iniciativas abaixo SNMP DPI (Distributed Protocol Interface) - RFC 1592 (1994): - Trata-se de uma extensão ao agente SNMP de forma que ele possa ter seu conjunto de MIB's expandido por “sub-agentes” de forma dinâmica, sem necessidade de recompilação de código. - Proposta pela IBM Agent extensibility Protocol (AgentX) – RFC 2741 (2000): - Agentes expansíveis – agentes master e subagentes - Padrão proposto The Kerberos Security Model – Sem RFC's ainda! - Um novo modelo de segurança para SNMPv3 baseado no serviço Kerberos
- #4 Tudo indica que SNMP terá um futuro promissor por muito tempo. Apesar disso, a crescente diversidade de contextos e orçamentos busca alternativas para gerenciamento.
- #5 A tecnologia de objetos distribuídos pode atuar em gerenciamento. Modela o elementos de rede e seus relacionamentos através de objetos distribuídos. CORBA (Cooperative Object Requestor Broker) – um dos primeiros modelos de objetos distribuídos a ser usado em gerenciamento: - Modelo de gerenciamento através de objetos que se comunicam (ao contrário do modelo gerente-agente) - A interação entre os componentes é baseada em eventos, e não em poling como SNMP - Possui modelo de segurança maduro - Exige grande capacidade (memória e processamento)
- #6 Gerenciamento de redes distribuido é reconhecido como uma necessidade atualmente. Uma aplicação gerente é um bom candidato a ser distribuido. O DISMAN é um esforço do IETF para o desenvolvimento de objetos gerenciados padronizados para gerenciamento distribuído. Prevê a distribuição das atribuições da aplicação gerente – funções de gerenciamento. Inicialmente usará como mecanismo de comunicação o framework SNMP. Seus objetos serão criados para serem consistentes com SNMP. Definirá objetos para tratar itens como: agendamento de operaçõs de gerenciamento, notificações, alarmes, eventos, etc. Trabalhos futuros poderiam avaliar o uso de CORBA ou HTTP.
- #7 Aplicações WEB em servidores disponibilizariam a informação e as operações de gerenciamento com o uso de tecnologias presentes na Internet. Dentre as vantagems das ferramentas de gerência baseadas em Web encontram-se: - Possibilidade de monitorar e controlar os elementos da rede usando qualquer navegador em qualquer nó da rede. Antes, quando falávamos de aplicações de gerência standalone, os gerentes de rede só podiam usar a ferramenta em máquinas onde ela estivesse instalada e devidamente configurada; - A interface gráfica da Web já é bem conhecida e as operações realizadas em um navegador também, não sendo necessários gastos com treinamento de pessoal. - Usar a Web para distribuir as informações sobre a operação da rede tem se mostrado uma tarefa eficaz. Por exemplo, em um determinado endereço da Intranet poderíamos disponibilizar informações para os usuários sobre o estado da rede e atualizações que eles precisam realizar. Isso evitaria, dentre outras perturbações, ligações em demasia ao help desk. - Além disso, não precisamos usar ferramentas diferentes para gerenciar os diversos elementos da infra-estrutura de TI, inclusive os serviços.
- #8 Esforço de um consórcio de empresas para criar um padrão de gerenciamento desktop (1992). Evoluiu de gerenciamento de desktops para gerenciamento WEB-based dentro de empresas. Usa como modelo de informação o CIM (Common Information Model) – especificação orientada a objetos para compartilhamento de informação de gerenciamento, além de MOF (Managed Object Format) para descrever objetos. É usado também por outras iniciativas (modelo unificado). Outras iniciativas do DTMF: - DMI (Distributed Management Interface) – framework para gerenciamento de sistemas desktop, notebooks, PC's e servidores. - WBEM (Web-Based Enterprise Management) – iniciativa que usa tecnologias WEB (Browsers, XML, SOAP, WSDL, etc) para gerenciamento de sistemas. Serviu de origem para o desenvolvimento do CIM. O objetivo principal do WBEM é alcançar a gerência unificada de todos os sistemas e redes de uma organização. - DEN (Directory Enabled Networks) – schemas padrões para diretórios interoperáveis, onde administradores poderiam usar os serviços de diretórios para gerenciar serviços de rede (como um diretório LDAP) Para saber mais: http://www.dmtf.org CIM - http://www.networkcomputing.com/912/912ws1.html WBEM - http://wbemservices.sourceforge.net/
- #10 Neste tipo de equipamento estão disponíveis mais informações, como por exemplo em seu arquivos de log. Certos produtos (chamados watchdogs ) procuram padrões em arquivos de log e geram eventos para plataformas de gerência. A gerência de sistemas é normalmente feita sem usar SNMP. Mesmo assim o mundo SNMP definiu a host resource mib (RFC 2790) para este propósito: - System group (data do sistema, dispositivo e parâmetros de boot, número de usuários logados, número de processos executando) - Storage group (quantidade de memória principal, tabela de dispositivos de armazenamento, tipos de disposivitivos, descrição, unidades de alocação, tamanho unidades de alocação usadas, falhas de alocação) - Device group (tabela de dispositivos, tipo, descrição, status número de erros, tabela de processadores, utilização, placas de rede, tabela de impressoras, status , estado de erro detectado, tabela de discos e de partições, tabela de sistemas de arquivos, tipo, ponto de montagem, permissões de acesso, se é bootável ou não, datas de backup parcial e completo) - Running software group (descrição do software carregado em memória (física ou virtual) e pronto para rodar, inclui sistema operacional, drivers, aplicações, variáveis da tabela, nome do software, path do arquivo executável, parâmetros de execução, tipo, status, - Running software performance group (para cada processo em execução) - Installed software group (uma tabela tem uma entrada para cada software instalado: nome do sofwtare, tipo (operating system, driver, application) e data de instalação)
- #11 O propósito das tecnologias de informática é de executar aplicações. As aplicações precisam de recursos para funcionarem. É importante poder configurar aplicações, detectar falhas, monitorar o desempenho de aplicações e acompanhar a aplicação ao longo de sua vida. Gerência de aplicações é geralmente feita com software especializado que frequentemente faz parte do próprio software da aplicação (monitores, logs, consoles, etc). Algumas formas de gerenciar a aplicação: - Sem instrumentação: usando comandos do sistema operacional ou utilitários genéricos (por exemplo: netstat, top, lsof, etc), para ver recursos utilizados, status, de processos, logs, etc. - Com instrumentação da aplicação: permite uma gerência mais eficaz através de ferrmantas específicas para a aplicação. Há esforços de elaboração de MIBs para poder usar snmp para monitorar e controlar aplicações: - System-level application MIB (RFC 2287): MIB para gerenciamento de aplicações sem instrumentação - Application Management MIB (RFC 2564): complementa a anterior - Network Services MIB (RFC 2788): informações sobre aplicações de rede - outras MIBs específicas de aplicações típicas (DNS, Mail, diretório, WWW, etc).
- #12 2 aspectos: - Planejamento da mudança - Gerenciamento da mudança Escopo da mudança, casos comuns: - Expansão de rede - Adição de segmento de LAN - Adição de sites - Conexão a redes existentes - Conexão com a Internet - Melhorias de design ou facilidades - Upgrade de software - Mudanças de configuração - Suporte a protocolos adicionais - Novas features A função de change controller é realizado por um indivíduo na organização, responsável em coordenar os processos de mudança. É possível se definir um processo para mudanças de emergências.
- #13 Gerenciamento da capacidade (capacity planning) é o processo de se determinar os recursos de rede necessários para evitar um impacto de performance ou disponibilidade sobre aplicações críticas. Se costuma dizer que gerenciamento de performance é a prática de gerenciar tempo de resposta, consistência e qualidade da rede para serviços, individualmente e de modo global. Problemas de performance normalmente são relacionados com capacidade. Dois aspectos envolvem a capacidade de uma rede: O chamado “data plane” é a porção da capacidade gasta efetivamente com os dadosno seu percurso pela rede. São os dados de usuário. O chamado “control plane”, por outro lado, é a porção relativa aos mecanismos de rede que a mantém em operação. Pode-se incluir aí o tráfego adicional gerado por protocolos de gerência, spanning-tree, protocolos de roteamento, keep−alives, além de CPU, memória e buffering. Análise “what−if” : como as mudanças propostas poderiam alterar a utiização da rede. “ Baselining” e análise de tendências : permitem que se planeje melhorias numa rede antes que problemas de capacidade causem piora significativa na performance ou até queda do serviço. Trata-se de comparar medições de utilização no decorrer do tempo, de forma a tornar mais claro o comportamente de indicadores que refletem a resposta da rede. Note-se que é necessária uma grande quantidade de informações para se realizar isso numa rede grande.
- #14 A documentação completa da rede é uma das ferramentas mais importantes para a solução de problemas. Pedaços de documentação espalhados em vários lugares e incompletos não ajudam. O que colocar na documentação: - Todos os dispositivos de interconexão (comutadores, comutadores de camada 3, roteadores, pontes, hubs, repetidores - Os servidores, gateways, firewalls e impressoras de rede - O que há em cada porta de roteadores e switches (talvez até em cada porta de hubs) - Cabeamento (fibra multimodo, fibra monomodo, UTP/STP, Coax - Todas as versões de software - Todas as configurações de dispositivos (comutadores, hubs e roteadores) - Manter um baseline de configuração (arquivos contendo as configurações) - Os endereços (IP e/ou IPX) e máscaras de sub-rede - Protocolos usados em cada enlace (Ethernet, Fast Ethernet, Gigabit Ethernet, FDDI, Token Ring, ATM LANE, ATM com IPOA (CIP)) - Uso de roteamento de protocolos de roteamento (RIP, RIP2, OSPF, IPX RIP, ATRP, DVMRP, PIM, MOSPF, IS-IS) - Uso de DHCP, BOOTP - Uso de VLANs (composição de cada VLAN) - Uso de aplicações de rede e nomes DNS - Configurações de firewalls
- #15 Normalmente existem sistemas com certo grau de integração de forma a permitir a operação correta de atividades de uma empresa através de suas várias áreas. Os sistemas de gerenciamento podem estar muito “amarrados” com o funcionamento interno da própria empresa (processos internos). É necessário um alinhamento dos processos e procedimentos internos com as ferramentas de gerenciamento. Para isso deve haver adequação de sistemas de gerenciamento de rede também por que a informação técnica de gerenciamento tem grande impacto no negócio da empresa. Em vários casos existem as mesmas áreas envolvidas: - Atendimento ao Cliente – Call-Center – Help-desk - NOC – Network Operation Center - Equipes de Manutenção - Controle de qualidade do serviço - Vendedores – responsáveis por contas de clientes Atividades comuns: - Registro de pedidos e reclamações de serviços - Atendimentos e manutenções (agendados ou não) - Acompanhamento e registro da solução - Gerações de relatórios de SLA
- #16 É necessário um projeto (planejamento). A implementação deve ser por etapas e com acompanhamento adequado, por que irá alterar vários processos. Antes de criar indicadores SLA, é interessante agrupar as necessidades de gerenciamento em áreas de gerenciamento. Com isso de divide as atividades e se encontra os executores das etapas sendo previstas. Ao escolher os produtos para gerenciamento, é importante definir modelo de distribuição das aplicações, baseado nas características do ambiente a ser gerenciado – e daí os domínios de gerenciamento. Tópicos como protocolos a serem usados e a modelagem da informação de gerenciamento, com base no modelo adotado, também serão importantes. Em muitos casos será concebido um NOC (Network Operations Center): uma infra-estrutura centralizada de apoio à atividade de gerência composta de recursos de rede, sistemas e humanos, para uma melhor resposta da atividade de gerenciamento. Pode ser necessário o desenvolvimento de novas aplicações de gerenciamento que atendam às necessidades locais. Muitas vezes são customizações ou scripts. em outras sistema inteiros complementam o conjunto de aplicações. Outros tópicos não menos importantes são o planejamento do suporte aos sistemas e treinamento da equipe.
- #17 TTS são usados para controlar demandas (como problemas) e acompanhar sua solução. Um trouble ticket pode ser aberto por um usuário ou automaticamente pela plataforma ou alguma aplicação. Normalmente aplicações de trouble ticketing permitem relatórios sofisticados e podem ser integrados a um sistema de help desk Funções e características de um TTS - Prover um histórico completo do problema de forma que qualquer operador possa tomar alguma iniciativa sem que para isso tenha de consultar outro operador. O conjunto de soluções adotadas - Permitir um melhor escalonamento de problemas atribuindo prioridades aos mesmos. Os supervisores e operadores poderão tomar decisões acerca da necessidade ou não de mais pessoal pela carga corrente do "Centro de Operações de Rede". - Envio de alguns registros diretamente ao responsável. - Limite ("timeout") para cada registro de problema - Registros de equipes diferentes (vários NOCs) - Obtenção de estatisticas tais como "Tempo médio entre falhas" e "Tempo médio de conserto" - Criação de uma base de dados de soluções para problemas já ocorridos ( knowledge base ) É importante que o TTS esteja disponível ao usuário final ou cliente, com visão e privilégios limitados, agregando transparência para o processo.
- #18 O ticket é a unidade de informação básica destes sistemas. Associados a eles estão itens como cliente afetado, data e hora de abertura e fechamento, responsável, equipamentos/serviços impactados, etc.
- #19 Algumas opções em FS/OSS são: RT (Request Tracker) - http://bestpractical.com/rt OTRS - http://otrs.org/ Sinergia - http://sinergia.sourceforge.net/ Simpleticket - http://simpleticket.net/ IssueTracker - http://www.issuetrackerproduct.com/ - para ZOPE Liberum - http://www.liberum.org/ - para Win Algumas opções comerciais: BMC Remedy - http://www.bmc.com/remedy/ HEAT - http://www.frontrange.com/ProductsSolutions/SubCategory.aspx?id=35&ccid=6 Para saber mais: Comparação entre vários sistemas TTS: http://en.wikipedia.org/wiki/Comparison_of_ticket-tracking_systems
- #20 SLA ( Service Level Agreement ) : acordo de nível de serviço entre cliente e fornecedor do serviço. Define exatamente como o serviço deverá ser disponibilizado ao cliente. Formaliza vários parâmetros de SLA para deixar claro que condições de serviço estão garantidas para o usuário final. Pode ter parâmetros de rede, atendimento, ou outros quaisquer. Exemplos: - Taxas de dados mínimas - Tempo de resposta a BD abertos - Número de relatórios de tráfego a serem entregues por mês - Tempo de resposta - Throughput - Largura de banda - Indices de congestionamento - Latência - Utilização OLA ( Operation Level Agreement ) : define SLA entre áreas e equipes internas visando o bom funcionamento dos processos internos da empresa e o adequado atendimento a SLA’s externos. Formaliza o tratamento e a operação cotidianos entre áreas. Referencia a eficiência das áreas e processos.
- #21 Service level management (SLM) define e regula requisitos de capacidade e performance que descrevem acordos de nível de serviço entre fornecedor do serviço e cliente. O administrador de SLM sabe que, muitas vezes, está sujeito a penalidades (multas) descritas no contratos com clientes, quando certo conjunto de parâmetros SLA não são respeitados. Um contrato de SLA deve definir no seu escopo alguns itens essenciais, tais como: - Quais serviços são cobertos - Responsabilidades - Compromissos de prazos para todos os eventos - Classifica a gravidade das ocorrências - Estipula o pagamento de multas e incentivos SLM então é uma metodologia que ajuda no gerenciamento de recursos definindo uma melhor contabilização do serviço entregue, de forma a dar melhor controle do mesmo. Convém lembrar que isto deve ser possível mesmo sob condições problemáticas da rotina de operação de uma rede. O gerenciamento do SLA é realizado através do acompanhamento dos parâmetros do contrato. Esse acompanhamento exige o uso de ferramentas de software que registrem a abertura de chamados (em sistemas de help-desk), tempos de paralisação de equipamentos e outros eventos que tornam indisponível o serviço.
- #22 O processo de gerenciamento de SLA possui duas grandes vertentes: - A definição de níveis de serviço de rede Análise técnica de objetivos e restrições Deteminação do orçamento disponível Criação de perfis de aplicações para as aplicações de rede em questão Definição de padrões de disponibilidade e performance Criação de uma definição de serviço (itens como disponibilidade, performance, tempo de resposta, MTBR, limiares para upgrade, etc) Obtenção de métricas e monitoramento do SL definido - A criação e manutenção de SLA's (alinha requisitos de negócio e custo com a qualidade do serviço prestado) Reconhecimento dos requisitos para os SLA's (aceitação destes por parte de todos) Definição das equipes envolvidas, elementos de serviço (nível de suporte, definição proativa de serviços, procedimento de resolução de problemas, etc) e do SLA para cada grupo. Negociação do SLA Medição e monitoramento dos SLA's A constante discussão sobre os SLA's acordados tem a mesma característica dos programas de melhoria da qualidade, muito comuns nas organizações.
- #23 MTBF – Mean Time Between Failures Em uma rede de computadores o MTBF é designado para expressar o tempo médio entre interrupções de serviço (MTBSO – mean time between service outage), levando-se em consideração que uma rede é um serviço e não um componente. MTTR – Mean Time To Repair Esse termo refere-se ao tempo médio para reparo de um componente ou serviço (MTTSR – mean time to service repair). Esse parâmetro associado ao MTBF mede a eficiência do reparo de um componente ou serviço. Note que não basta reparar o componente rapidamente se este apresenta constantes problemas de interrupção. Em redes de alta disponibilidade para se atingir o MTTR a prestadora deve ter um processo eficiente de substituição de componentes e meios redundantes para assegurar a continuidade dos serviços. Nas fórmulas, o TT é o trouble ticket aberto para um mesmo componente ou serviço.
- #24 Uma rede corporativa não consiste apenas da infra-estrutura de rede. Tudo tem que funcionar . Os serviços são implementados pelo conjunto de aplicações e processos definidos na organização. Ao final temos o negócio da organização. Gerenciamento nestes níveis utilizam dados consolidados e apresentados de outras formas para gerentes e diretores, auxiliando o acompanhamento do negócio através dos seus vários serviços. Estas informações são usadas para efetuar o planejamento técnico da planta e as opções de investimento. Por exemplo: uma operadora pode detectar que seu negócio de acesso discado à Internet não está gerando mais lucros e pode resolver investir em opções de acesso sem fio (hot spots). Para se diagnosticar uma situação destas foi preciso avaliar o comportamento do serviço de acesso discado, sua carga de tráfego, seu rendimento, número de usuários, chamados de usuários, número de manutenções, etc. Ao final, estas informações geraram uma parspectiva maior que indicou a estagnação do serviço. O resultado foi então uma mudança na estratégia de investimentos.
- #25 A idéia nesta SA é montar um conjunto de NMS para executar várias funções em um NOC. Zabbix, OpenNMS ou jffnms (os alunos devem escolher entre os dois com base nas características desejadas) MRTG (para acompanhamento de tráfego – se for necessário, após avaliação dos alunos) Netdirector (para gerenciamento de configuração e mudanças).
- #26 1. Acesse via um MIB Browser os dados da MIB HOST-RESOURCES implementada no agente NET-SNMP de uma das máquinas. 2. Instale e customize o OTRS como TTS e configure para um help-desk interno de uma área de TI/redes. Crie usuários e grupos e disponibilize o sistema para os demais alunos.