Índice

Introdução
Metagerenciamento baseado em browser
   Relato de problemas online, uso de relatórios online
   Procedimentos de gerenciamento online, documentação online
   Assitência a troubleshooting online
Gerenciamento baseado no browser
    Scripts de Troubleshooting scripts executados pelo browser
    Gerenciamento de configuração
    Applet Java com pilha SNMP
Gerenciamento baseado em HTTP
    Mapeamento CLI-para-URL
    Páginas HTML e programas CGI embarcados
    Aplicação de gerenciamento embarcada
    Minimizar o footprint de um servidor HTTP embarcado
PHP e SNMP
  Exemplo

Introdução

A atração de tecnologias Web tem se apresentado como uma solução irresistível em muitos segmentos da indústria de software. No gerenciamento de redes IP, as empresas começaram escrevendo formulários HTML e scripts CGI nos anos 1993-94. Em 1995-96 predominou experimentos com servidores HTTP e applets java embarcadas em equipamentos de rede. EM 1997  muitas plataformas de gerenciamento de rede (NMP) integraram interfaces Web nas suas ferramentas. Durante os anos de 1997-98 as pessoas perceberam que tecnologias Web recentes - e.g., Java applets, servlets, RMI, Serialização de Objetos, ou agentes móveis - não fariam somente o que os NMPs tradicionais faziam: novas formas de recuperação de dados, detecção de falhas, ou distribuição de aplições de gerenciamento de rede, mais genericamente,  novas maneiras de gerenciar redes IP [REF 1].

Gerenciamento baseado na Web é um conceito que se desenvolveu bastante nos últimos anos. Muitas pessoas comfundem essec conceito com o uso do browsers Web para realizar tarefas de gerenciamento - uma abordagem muito simples que se chama gerenciamento baseado em browsers (browser-based management). A extensão dessa confusão  é tal que o autor Harler  titulou seu livro “Web-Based Network Management: Beyond the Browser“ [REF 2], para enfatizar que há mais gerenciamento baseado em browser do que meramente um browser. Outras pessoas confundem gerenciamento baseado na Web com WBEM. O trabalho a seguir irá apresentar tipos de gerenciamento baseado na Web: Browser-Based Metamanagement, Browser-Based Management e HTTP-Based Management. Nesse contexto será apresentado a seguir o modelo de programação utilizado por PHP permitir o gerenciamento por HTTP como alternativa viável para substituição a java applets com algumas restrições. É importante salientar que este documento não pretende esgotar o assunto, pois ainda faltaria falar de gerenciamento baseado em XML e gerenciamento baseado em Java Distribuído.
 

Metagerenciamento baseado em browser

    O auge do gerenciamento baseado no browser foi em 1993 [REF 3], quando a NCSA MOSAIC começaram a se espalhar por todo o planeta. Esse ano (1993) é considerado o ano auge da Web, quando ela deixou de existir para um pequeno grupo de pesquisadores e alcançou o mundo. As tecnologias Web mais antigas (isto é, Web browsers, HTTP, HTML, and CGI) foram usadas  em NSM  desde os primeiros tempos. Por exemplo, Discussões em uma lista de discussão relacionada e Usenet newsgroups mostram que muitas pessoas estavam fazendo experimentos similares ao mesmo tempo. Tecnologias Web não substitutem gerenciamento baseado em SNMP, mas complementa isso realizando tarefas colaterais - o que chama-se metagerenciamento (metamanagement). Gerenciamento baseado na Web, descritos nesta seção, é típica daquela estudade nos primeiros dias do gerenciamento baseado na Web. Ele é caracterizado pelo uso interativo de um browser para´a realização de tarefas de metagerenciamento.

Relato de problemas online, uso de relatórios online

    Numa primeira fase, os administradores aprenderam como usar as tecnologias recentes desenvolvendo algumas poucas páginas e programas CGI (scripts ou banners). Por exemplo, escrevendo uma dúzia de formulários HTML e uma interface desses formulários com um simples banco de dados por meio de programas CGI, pode ser possível padronizar e automatizar relatório de problemas e troubleticketing (o que pode simplificar e diminuir significativamente o trabalho de calldesks [REF 3]. Outro exemplo seria a publicação na Web de relatórios de uso de recursos de um dispositivo de maneira a detectar quando o dispositivo está trabalhando perto de seu limite, quando entao seria tomado uma providência. Um caso tipo de gerenciamento proativo. Tal dispositivo teria de ser monitorado periodicamente(diariamente, semanalmente, mensalmente, etc). Hoje pode parecer algo trivial e até talvez me perguntariam: porque tu está mencionando isso ? Tu faria diferente ? Mas antigamente a maioria dos relatórios eram impressos em papel para posterior análise o que consumia recursos, hoje desnecessariamente. Além disso com essa tecnologia o gerente pode acessar a informação de um PC, Mac, estação Unix, etc., desde que tenha um browser.

Procedimentos de gerenciamento online, documentação online

    Em ambientes de produção, operadores de rede tipicamente seguem procedimentos bem definidos para identificar a causa de um problema e para corrigi-lo. A possibilidade de ter toda essa informação disponível eletronicamente (formato HTML) possibilita rápida e fácil recuperação de informação de procedimentos de gerenciamento. O uso da navegação indexada e search engines facilitam a recuperação dessas informações, antes armazenada em papel impresso, CD-ROMs por exemplo. Também é interessante acrescentar que a economia em recursos de armazenamento (espaço físico, manutenção) é relevante.

Assitência a troubleshooting online

Numa terceira fase, os admisnitradores auxiliavam os operadores a identificar causa de problemas com assistência de trouble-shotting online. Issso já envolvia aplicações mais elaboradas com uma quantidade maior de formulários HTML e programas CGIs. Os operadores poderiam identificar a causa de um problema com uma navegação com poucas possibilidades. Eram sistemas especialistas (alguns mais simples, outros nem tanto) que solicitavam algumas infiormações dos operadores e resultava numa lista de possíveis causas o que economiza muito tempo: antes os operadores tinham de procurar nos catálogos de procedimentos.

A integração de pdocedimentos de gerenciamento online, documentação de dispositivos online e troubleshotting online provou ser um importante passo em ambientes de produção. Além disso, GUI mais amigáveis e informações online eram (são) mais simples para atualização de informações.
 

Gerenciamento baseado no browser

Cronologicamente, o próximo passo para administraores e operadores foi gerenciar agentes de modo interativo por um browser Web, chamado gerenciamento baseado em browser [REF 3]. Eles não executavam mais somente tarefas auxiliares por um browser, mas também gerenciavam equipamentos diretamente. Naquela época, os agentes tinham somente dois servidores embutidos: SNMP e telnet. Assim, um gerenciamento baseado em browser, interações agentes/gerentes eram baseado em SNMP ou telnet.

Scripts de Troubleshooting scripts executados pelo browser

Certos procedimentos podem ser automatizados porque consistem somente de exeução de comandos. Não requerem que o operador esteja presente fisicamente na frente do equipamento para manusear o hardware. Algumas dessas operações podem ser facilmente encapsuladas em um script. Por exemplo, um operador pode usar o comando snmpset para fazer um reset numa interface SNMP, ou o comando ping para testar a alcançabilidade de um host. Porém, outras operacções de solução de problemas não podem ser automatizadas porque precisam trabalhar em modo interativo (uma conexão telnet, por exemplo). Então, uma boa parte de comandos suportados por uma interface de linha de comando (CLI) não possuem equivalentes em MIBs. Alguns anos amargos exigiram o uso de telnet para resolver o impasse. Em 1994, uma ferramenta baseado em Tcl foi desenvolvida para implementar automação de programas interativos, data que coincidiu com a ampla disseminação da interface Web em NMSs. É importante lembrar que esse problema já havia sido resolvido alterando o código fonte do telnet, uma solução não muito elegante, mas necessária na época.

Gerenciamento de configuração

Gerenciamento baseado na Web também permite que para uma simples forma de gerenciamento de configuração que permite a capacidade de alguns agentes fazer download de suas configurações de um servidor remoto após um reboot (por TFPT por exemplo). Preenchendo as informações de configuração do equipamento num formulário, o administrador gera novos arquivos de configuraçãi onde todos os arquivos de configuração de agentes são armazenados. Finalmente, quando o agente é reiniciado pelo operador, manualmente ou pela Web (os roteadores da Digitel reiniciam por comandos Web), automaticamente o arquivo de configuração é obtido e carregado. A vantagem desta solução é o uso de agentes SNMP legados: tecnologias Web são usadas somente para gerar novos arquivos de configuração.

Applet Java com pilha SNMP

Outro tipo de gerenciamento baseado em browser aparceu vários ano depois com Java. Em 1997-98 surgiram várias empresas que desenvolveram aplicações parcialmente ou completamente em java. Nesse cenário, a nova aplicação gerenciamento baseado em Java é independente da tradicional plataforma de gerenciamento baseada em SNMP. a plataforma java complementa a SNMP e roda em paralelo. Essa nova plataforma oferece interface muito mais amigáveis que formulários HTML e a interação ainda se baseia numa tecnologia conhecida e bem definida: SNMP, ou outros. A diferença está no potencial gráfico. A aplicação de gerenciamento são implementadas como applets rodando no browser do operador ou como uma aplicação Java standalone - com pouca diferença no código.

Esse tipo de gerenciamento é bem próprio para sites que precisam monitoração de desempenho simples e sonline [REF 3]. Seria possível, nentão, configurar um agentes SNMP, agentes RMON, reuperar informações de gerenciamento via SNMP por vários minutos, processar essas informações e apresentar os resultado com gráficos elaborados. O mercado acabou implementando essa solução como substituta do gerenciamento baseado em SNMP, ao invés de uma solução paralela. A oportunidade do negócio era interessante porque quebrava o monopólio de quatro grandes fabricantes. É importante lembrar que soluções gratuitas também fornecidas como o MRTG (Multi Router Traffic Grapher) e WebTrafMon.
 

Gerenciamento baseado em HTTP

Os agentes considerados até agora não suportam qualquer de tecnologia Web. Um marco no gerenciamento baseado em Web foi o advento de servidores HTTP embarcados em dispositivos e sistemas de rede que permitiu pensar-se em gerenciamento baseado em HTTP, e. g., gerente e agente comunicando-se por HTTP. Esse tipo de gerenciamento apresenta-se em duas formas com pequenas diferenças.

A primeira é apresentada na figura [FIG 1]. O usuário (administrador ou operador) gerencia o agente por meio de um sistema GUI num browser. O sistema GUI é implementado  como um applet Java. No agente podemos ter diferentes tipos de gateways HTTP-SNMP, como será visto adiante. A MIB SNMP na imagem representa todas as MIBs suportadas pelo agente, genéricas ou específicas do fabricante.

A segunda forma é ilustrada na figura [FIG 2]. O agente não é alterado. Entretanto, o sistema GUI é implementado como uma aplicação Java no lado do gerente, ou seja, o usuário não usa mais o browser.

Mapeamento CLI-para-URL

    Em seção anterior foi discutido a utilidade de scripts que implementassem comandos interativos rodando em modo não assistido. Emulando uma sessão de telnet, tem-se acesso ao CLI de parte de um equipamento. Esta abordagem não é tão flexível como pode parecer em primeira instância. O tooolkit mencionado é bom para executar o mesmo grupo de comandos, mas não se propõe como gateway genérico para o CLI do agente. O problema é definir pontos cruciais que implicam diretamente em desempenho e escalabilidade: um ou mais script por comando, uma sessão telnet por comando CLI, por exemplo. Além disso o resultado textual de cada comando CLI deve ser conhecido de maneira que possa se interpretar ois resultados, que normalmente/obviamente interessa bastante. Pior do que isso, o resultado pode ser deuma sequência de comandos anteriores ou a combinação deles. Então o que acontece na prática é que tais scripts realizam tarefas bem específicas - que foram bem depuradas.

Servidores HTTP embarcados resolveram esse problema: por meio de HTTP fazem o que é suportado por um CLI e, em especial, o que não é possível por SNMP. Bruins [REF 4] relatou um experimento com mapeamento CLI-para-URL realizado em 1995. Por exemplo, um gerente solicita a seguite URL:

<http://router_name/exec/show/interface/ethernet0/>

O roteador destino é identificado pelo seu nome de domínio qualificado ou endereço IP router_name. Ele roda um gateway HTTP-SNMP que traduz a URL no CLI correspondente:

show interface ethernet0

Este gateway encaminha o comando para o interpretador de linha de comando, que interpreta o comando como se ele tivesse diso digiatdo em modo interativo. O resultado do comando é enviado de volta para o gateway. O gateway traduz esse resultado em uma página HTML e envia ao gerente. O usuário pode então  usar seu browser ou aplicação Java como se ele fosse o console do dispositivo ou sistema gerenciado.

Este esquema apresenta duas vantagens. É muito simples implementar por causa do mapeamento direto entre os CLIs e URLs. A outra vantagem é o fácil manuseio por parte dos operadores por causa que tais operadores normalmente estão familiarizado com  CLIs de diferentes fabricantes e não precisam aprender outra linguagem. Além disso, o mapeamento CLI-para-URL possibilita nvas formas para gerenciamento de configuração e formulários HTML orientado a simtomas, já que não é mais preciso fazer um telnet para dispositivos de rede ou sistemas. Assim, operadores que conhecem CLIs podem também criar URLs intrativas sem precisar escrever um script interativo.
 

Páginas HTML e programas CGI embarcados

Com servidores HTTP embarcados logo apareceram páginas estáticas HTML embarcadas, tipicamente armazenadas em EPROM. algumas dessas páginas descrevem características do sistema de um determiando dispositivo de rede. Porém o grande potencial dessas páginas se revelam quando como formulários HTML e programsa CGIs também embarcados, particularmente e extremamente útil para configuração de gerenciamento, por oferecerem uma interface mais amigável e mecanismos de configuração mais simples (diferente daquele que gerava um arquivo de configuração e armazenava em um servidor tfpt tipicamente). Além disso, CGIs podem gerar páginas HTML dinamicamente, útil para realização de simples monitoração de desempenho e que coincide com Gerenciamento por Delegação. Neste caso, o Gerenciamento por Delegação promove a delegação de parte de uma aplicação de gerenciamento para o próprio agente. Como aumenta-se a carga de CPU onde o agente está instalado para permitir o gerenciamento, é importante ter em mente na hora de projetar tal agente há a necessidade de preservar os ciclos de CPU dedicados para as tarefas operacionais do agente.

Páginas HTML embarcadas dinâmicas e estáticas bem como programas CGI embarcadas foram descritos em 1996 por Mullaney quando relatou um protótipo desenvolvido pela Cabletron [REF 5]. TRabalho semelhante na Cisco foi relatado em 1997 por Maston [REF 6]. Com o passar do tempo, estas características tem ganhado popularidade, especialmente para gerenciamento de configuração. Um crescimento número de equipamentos de fabricantes estão agora suportando tais tecnologias. Espera-se que num futuro próximo isso se torne uma maneira comum de configurar agentes em modo interativo. Obviamente configuração interativa não é sempre ma opção, especialmente em grandes redes.

Aplicação de gerenciamento embarcada

O conceito de aplicação de gerenciamento embarcada foi descrito (e criticado) por Wellens e Auerbach em 1996 [REF 7]. Como os agentes são tipicamente gerencaidos por GUIs de gerenciamento específicos de fabricantes (add-ons) integrados na plataforma de gerenciamento, esses autores argumentam que os add-ons podem ser armazenados e executados dentro dos próprios agentes. A aplicação de gerenciamento embarcada é codificada como uma coleção de páginas HTML e programas CGIs, onde o operador interage diretamente com o agente por meio de um broswer.

Como as abordagens anteriores, esta usa HTTP ao invés de SNMP para veicular os dados entre gerentes e agentes. A principal vantagem é que os dispositivos de rede e/ou sistemas é diretamente vendida com a aplicação de gerenciamento. A principal desvantagem é que uma pessoa deve sentar em frent a um browser para gerenciar o agente: o gerenciamento não pode ser automatizado. Outro problema é o custo do gerenciamento dependendo da forma de licensa do add-on, isto é, se a licensa do add-on for por dispositivo gerenciado e haver a necessidade de gerenciar vários dispositivos. Assim, um novo modelo de negócio para gerenciamento de software é necessário [REF 3]. Outro problema ainda é a utlização de ciclos de CPU para funções de gerenciamento (geração de gráficos, formatação de dados,etc).  A tarefa primária do agente é realizar suas funções operacionais, não as tarefas de gerenciamento; assim, a quantidade de overhead necessária para gerenciamento deve ser limitada. Achar esse limite é um dos principais problemas neste contexto. Pode depender de inúmeros fatores não previsíveis e normalmente é utilizado um limite para um caso simples de carga de CPU.

Minimizar o footprint de um servidor HTTP embarcado

Dois times de pesquisa tem focados em minimização de footprint de servidores HTTP embarcados no agente: Reed et al. at IBM Almaden Research Center and Hong et al. at Postech, Korea. Em 1996-7, Reed et al. desenvolveu um servidor HTTP mínimo que cabia em uma classe. Para tal excluiram várias características do HTTP. Formulários HTTP não eram processados por programas CGIs externos, mas pelo próprio servidor HTTP, que era multithread. Solicitações HTTP especificam qual tratador deveria processar a solicitação HTTP (um tratador é um servidor HTTP com parser de HTML específico). RPCs são utilizadas para realizar as tarefas de gerenciamento solicitadas por HTTP. O servidor HTTP mínimo foi usado no NetFinity, uma ferramenta de gerenciamento distribuída para PCs. O autor fez testes de avaliação de desempenho no seu servidor HTTP mínimo e mostrou que ele utiliza menos ciclos de CPU que um servidor HTTP convencional.

Em 1999-2000 Hong et al. desenvolveu o POStech Embedded Web Server (POS-EWS). Os objetivos da arquitetura era minimizar o overhead de gerenciamento baseado em HTTP no agente e maximizar a eficiência do servidor HTTP. POS-EWS possui um código C bastante compacto (30 kbytes). A média de memória utilizada em tempo de execução (footprint) é apenas de 64 kbytes. Ao invés de usar a filosofia multithread, este servidor HTTp é monothread e executa múltiplas máquinas de estados finitos para tratar conexões simultâneas. POS-EWS foi integrada num roteador IP comercial desenvolvido pela Hana Systems, Korea.

PHP e SNMP

"PHP is a server-side, cross-platform, HTML embedded scripting language."

"Linguagem (e biblioteca) para criação de aplicações para Internet/Intranet
Baseada (em termos de sintaxe, tipagem ) em Perl.
Procedural, com suporte a Orientação a Objetos."

Esta seção não tem por objetivo de apresentar em detalhes do uso de snmp em PHP mas mostrar algumas funcionalidades que viabilizam o uso de php como uma solução para gerenciamento baseado para Web. Maiores detalhes podem ser obtidos em http://www.php.net/manual/ref.snmp.php.

PHP dispensa maiores apresentações. É bastante simples de usar e ao mesmo tempo poderosa. Simples porque lembra a sintaxe de C e poderosa porque inclui bibliotecas que vão desde acesso a banco de dados, criptografia e consultas SNMP. Para poder fazer consultas snmp em php é necessário ter a biblioteca UCD SNMP instalada. Na plataforma Windows essas funções estão presentes apenas no NT.

Assim, uma possível arquitetura seria a apresentada na figura [FIG 3]

Os seguintes comandos são suportados em php:

snmpget — recupera um objeto SNMP

string snmpget (string hostname, string community, string object_id [, int timeout [, int retries]])

snmpset — configura um objetoSNMP

bool snmpset (string hostname, string community, string object_id, string type, mixed value [, int timeout [, int retries]])

snmpwalk — recupera todos os objetos SNMP de um agente

array snmpwalk (string hostname, string community, string object_id [, int timeout [, int retries]])

snmpwalkoid — consulta uma árvore de informações sobre uma entidade de rede

array snmpwalkoid (string hostname, string community, string object_id [, int timeout [, int retries]])

snmp_get_quick_print — recupera o valor corrente  da  funcionalidade quick_print da biblioteca UCD

boolean snmp_get_quick_print (void )

snmp_set_quick_print — configura o valor de quick_print dentro da biblioteca UCD SNMP.

void snmp_set_quick_print (boolean quick_print)
 

Exemplo

A seguir é listado um exemplo que recupera alguns campos do grupo System da MIB II. Obviamente os objetos poderiam ser obtidos com o comando snmpwalk. Mas o uso de snmpget foi intencional a título de exemplo. O mesmo exemplo pode ser visto em http://noc.metropoa.tche.br/uzun.php.

<HTML>
<HEAD>
<TITLE>Document Title</TITLE>
<META NAME="Generator" CONTENT="HTMLed Pro 3.0">
<META NAME="Author" CONTENT="Rodrigo Uzun Fleischmann">
</HEAD>
<BODY BACKGROUND=fundo.gif>

<?php

echo "SysName: ";
echo snmpget("127.0.0.1", "public", "system.SysName.0");
echo "<BR>";

echo "SysDescr: ";
echo snmpget("127.0.0.1", "public", "system.SysDescr.0");
echo "<BR>";
 

echo "SysContact: ";
echo snmpget("127.0.0.1", "public", "system.SysContact.0");
echo "<BR>";

echo "SysLocation: ";
echo snmpget("127.0.0.1", "public", "system.SysLocation.0");
echo "<BR>";

echo "SysUpTime: ";
echo snmpget("127.0.0.1", "public", "system.SysUpTime.0");
echo "<BR>";
 

?>
 

</BODY>
</HTML>

Bibliografia

[REF 1] IP Network Management Plataforms Before the Web
[REF 2] C. Harler. Web-Based Network Management: Beyond the Browser. Wiley, New York, NY, USA, 1999.
[REF 3] Martim, tese de doutorado ...
[REF 4] B. Bruins. “Some Experiences with Emerging Management Technologies”. The Simple Times, 4(3):6–8, 1996.
[REF 5] P. Mullaney. “Overview of a Web-Based Agent”. The Simple Times, 4(3):8–12, 1996.
[REF 6] M.C. Maston. “Using the World Wide Web and Java for Network Service Management”. In A. Lazar, R. Saracco, and R. Stadler (Eds.), Integrated Network Management V. Proc. 5th IFIP/IEEE International Symposium on Integrated Network Management (IM’97), San Diego, CA, USA, May 1997, pp. 71–84. Chapman & Hall, London, UK, 1997.
[REF 7] C. Wellens and K. Auerbach. “Towards Useful Management”. The Simple Times, 4(3):1–6, 1996.
[REF 8] M.J. Choi, H.T. Ju, H.J. Cha, S.H. Kim, and J.W.K. Hong, “An Efficient and Lightweight Embedded Web Server for Web-based Network Element Management”. In Proc. IEEE/IFIP Network Operations and Management Symposium (NOMS 2000), Hawaii, USA, April 2000, pp. 187–200. IEEE Press, New York, NY, USA, 2000.