Gerenciamento de redes para sistemas embarcados

Gerenciamento de redes para sistemas embarcados

CURSO DE CIÊNCIA DA COMPUTAÇÃO

Jorge Luis Staub

GERENCIAMENTO DE REDES PARA SISTEMAS EMBARCADOS

Santa Cruz do Sul, novembro de 2007.

2

Jorge Luis Staub

GERENCIAMENTO DE REDES PARA SISTEMAS EMBARCADOS

Trabalho de conclusão II apresentado ao Curso de Ciência da Computação da Universidade de Santa Cruz do Sul, como requisito para obtenção do titulo de Bacharel em Ciência da Computação.

Orientador: Prof. Ms. Cristiano Both

Santa Cruz do Sul, novembro de 2007.

3 RESUMO

O gerenciamento de redes pode ser definido como um conjunto de ferramentas integradas para monitoramento e controle dos recursos da rede. Tem como principal objetivo a produtividade e eficiência, garantindo assim a disponibilidade dos serviços em um nível de desempenho aceitável. O processo de gerência de redes consiste, em obter informações dos equipamentos e serviços da rede para posteriormente tratá-las de forma a obter um diagnóstico dos possíveis problemas que acompanham a evolução contínua da microeletrônica e da tecnologia de comunicação.

A evolução da capacidade dos equipamentos dedicados gerou uma nova necessidade de gerenciamento. Neste contexto os dispositivos de uso específico são ligados a uma rede de computadores e seus sistemas operacionais são otimizados e com algumas limitações funcionais. Entretanto, esses equipamentos dedicados necessitam de um detalhado sistema de gerenciamento e monitoramento.

Assim, este trabalho propõe integrar em uma placa FPGA, um agente SNMP e juntamente com um sistema gerente obter dados gerenciais sobre um determinado sistema embarcado.

Palavras-Chave: Gerência de Redes, uClinux, SNMP, Sistemas Embarcados, FPGA.

4 ABSTRACT

The network management can be defined as a group of integrated tools to monitor and controls the network resources. The main goal is the productivity and efficiency in order to disponibility of services in a level acceptable performance. The network management proccess consists, basically in obtain information about equipments and network services in order to have a diagnostic of possible problems that have been happening with the continuous evolution of microelectronics and communication technologies.

The evolution of the dedicated devices generated a need of management. In this context devices with specific use are connected to a computer network and their operating systems are optimized and with some functional limitations. However, such equipments need a comprehensive management system.

So, this research proposes to integrate in a FPGA board, a SNMP agent that together with a management system obtains management information about an embedded system.

Keywords: Network Management, uClinux, SNMP, Embedded Systems, FPGA

5 LISTA DE FIGURAS

Figura 1: Modelo básico de um Sistema de Gerência de Redes Figura 2: Mensagens em um Protocolo de Gerência de Redes Figura 3: Modelo de gerenciamento SNMP Figura 4: Estrutura de Árvore da MIB Figura 5: Plataforma de desenvolvimento Virtex-II Pro Figura 6: Arquitetura do sistema de gerenciamento de redes Figura 7: Tela de abertura do sistema de gerenciamento Figura 8: Cadastro de novo dispositivo para monitorar Figura 9: Coleta de dados técnicos do dispositivo Figura 10: Parâmetros da coleta de dados Figura 11: Tela do sistema de gerenciamento coletando dados Figura 12: Gerando tráfego na interface de rede Figura 13: Selecionando ID da coleta para analisar tráfego Figura 14: Relatório de tráfego gerado pelo sistema de gerência Figura 15: Gráfico de Bytes Enviados e Recebidos. Figura 16: Gráfico do % de uso da interface de rede Figura 17: Relatório de Processos Ativos – uso de CPU e Memória Figura 18: Analise de pacotes com programa Ethereal Figura 19: Tela inicial do XPS Figura 20: Tela do assistente de novo projeto Figura 21: Seleção do modelo da placa FPGA Figura 22: Seleção do tipo de processador Figura 23: Opções avançadas do Processador MicroBlaze Figura 24: Configuração dos periféricos da placa (1) Figura 25: Configuração dos periféricos da placa (2) Figura 26: Configuração dos periféricos internos Figura 27: Configuração do Cache Setup Figura 28: Configuração do Software Setup Figura 29: Resumo e finalização das configurações Figura 30: Software Plataform Settings – seleção do kernel Figura 31: Software Plataform Settings – Ajustes no SO Figura 32: Tela principal do menu de configuração do kernel Figura 33: Tela de propriedades da porta serial Figura 34: Tela do XPS – Abrir projeto recente Figura 35: Tela do XPS – Console XMD Figura 36: Tela de mensagens da carga do uClinux Figura 37: Arquivo de configuração Makefile Figura 38: Mensagem de erro de compilação (1) Figura 39: Arquivo de include do pacote net-snmp Figura 40: Mensagem de erro de compilação (2) Figura 41: Arquivo hr_system.c – erro de declaração de atributos

12 12 13 16 24 27 29 30 31 31 32 33 34 34 35 36 37 38 47 48 49 50 51 51 52 53 53 54 54 55 55 58 63 64 65 65 67 68 68 69 70

6 LISTA DE TABELAS

Tabela 1: Principais comandos disponíveis no pacote SNMP Tabela 2: Descrição dos grupos da MIB II Tabela 3: Descrição dos principais subgrupos da MIB II Tabela 4: Grupos da MIB host-resources Tabela 5: Descrição dos principais subgrupos da MIB host-resources Tabela 6: Análise de impacto do monitoramento no tráfego da rede Tabela 7 : Análise do uso de Ciclos de CPU na FPGA

14 18 18 19 19 38 39

7 LISTA DE ABREVIATURAS

API ASN.1 CMIP CMIS CPU DDR EDA EDK FPGA FTP GUI HTML HTTP IAB IBM IEEE IETF IP ISO LAN MIB MMU MTU NMS OID OSI PC PDU PHP POSIX

Application Program Interface Abstract Syntax Notation One Common Management Information Protocol Common Management Information Service Central Processor Unit Double Data Rate Electronic Design Automation Embedded Development Kit Field Programmable Gate Array File Transfer Protocol Graphic User Interface Hipertext Markup Language Hipertext Transfer Protocol Internet Activities Board Industrial Business Machine Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Protocol International Organization for Standardization Local Area Network Management Information Base Memory Manager Unit Maximum Transmission Unit Network Management Station Object Identifier Open Systems Interconnection Personal Computer (Estação de Trabalho) Protocol Description Unit Preprocessor Hypertext Protocol Portable Operating System Interface for Unix

8
RFC RMON ROM SDRAM SMI SNA SNMP SOPC TCP UDP USB WAN WAP XMD XPS

Request for Comments Remote Network Monitoring MIB Read Only Memory Synchronous Dynamic Random Access Memory Structure of Management Information System Network Architecture Simple Network Management Protocol System-On-a-Programmable-Chip Transmission Control Protocol User Datagram Protocol Universal Serial Bus Wide Area Network Wireless Application Protocol Xilinx Microprocessor Debugger Xilinx Platform Studio

9 SUMÁRIO

INTRODUÇÃO.................................................................................................................. 10 1 GERENCIAMENTO DE REDES ......................................................................... 11
2.1 MODELO BÁSICO DE GERENCIAMENTO ....................................................................... 11 2.2 ELEMENTOS DA ARQUITETURA SNMP....................................................................... 13 2.2.1 Agentes SNMP..................................................................................................... 14 2.2.2 O software gerente................................................................................................ 15 2.3 BASE DE INFORMAÇÃO GERENCIAL (MIB).................................................................. 15 2.3.1 Acesso aos valores da MIB................................................................................... 17 2.3.2 Objetos da MIB II................................................................................................. 17 2.3.3 Objetos da MIB Host-Resources........................................................................... 19

3

SISTEMAS EMBARCADOS................................................................................. 20

3.1 O SISTEMA OPERACIONAL UCLINUX........................................................................... 21 3.1.1 O Sistema Operacional PetaLinux ........................................................................ 22 3.2 A PLACA FPGA XILINX ............................................................................................. 22 3.3 GERENCIAMENTO DE SISTEMAS EMBARCADOS ............................................................ 24

4
4.1 4.2 4.3 4.4 4.4.1 4.4.2 4.4.3 4.4.4

IMPLEMENTAÇÃO DO SISTEMA .................................................................... 26
ARQUITETURA DO SISTEMA DE GERENCIAMENTO ....................................................... 26 FUNCIONAMENTO GERAL DO SISTEMA ........................................................................ 27 SISTEMA DE GERENCIAMENTO DE REDE PARA SISTEMAS EMBARCADOS ........................ 28 COMO MONITORAR UM DISPOSITIVO FPGA COM O SISTEMA ....................................... 28 Cadastrando um novo dispositivo para monitorar.................................................. 29 Iniciando o monitoramento ................................................................................... 31 Gerando tráfego na interface de rede..................................................................... 33 Analisando os relatórios e gráficos gerados pelo sistema ...................................... 34

5 6

ANALISE DE DESEMPENHO DO SISTEMA .................................................... 38 CONCLUSÃO E TRABALHOS FUTUROS ........................................................ 40

REFERÊNCIAS................................................................................................................. 42 ANEXO A – PREPARAÇÃO DO AMBIENTE DE TRABALHO .................................. 45 ANEXO B – RELATÓRIO DE ERROS E SOLUÇÕES.................................................. 67

10 INTRODUÇÃO

O Gerenciamento de redes vem sendo bastante pesquisado nos últimos anos, visto a grande e crescente quantidade de equipamentos ligados em redes LAN (Local Area Network) e WAN (Wide Área Network). Entretanto, pouco se desenvolveu para gerenciamento de sistemas embarcados, que utilizam recursos de hardware limitados. Nos dias atuais, sistemas embarcados são indispensáveis para aumentar a produtividade em diferentes situações, tais como área acadêmica, eletro-eletronica e automotiva. É natural que muitos desses sistemas estejam conectados a Internet para possibilitar uma maior funcionalidade desses equipamentos. Com essa evolução, esses sistemas embarcados conectados em uma rede IP necessitam ser monitorados e gerenciados como qualquer outro equipamento de redes de computadores.

Neste contexto, este trabalho visa o gerenciamento de um sistema embarcado para analisar o uso de seus principais recursos como CPU, memória e interface de rede. Para isto, foi desenvolvido um sistema de gerenciamento de redes para sistemas embarcados, onde se integrou um agente SNMP (Simple Network Management Protocol), por que esse será responsável pelo monitoramento e envio das informações ao sistema de gerenciamento.

O trabalho está organizado conforme a seguinte descrição. O Capítulo 2 apresenta o conceito de gerenciamento de redes, o protocolo SNMP, sua estrutura, características, agentes, gerentes e também a base de informações gerenciais. No Capítulo 3 os sistemas embarcados são discutidos. São evidenciadas as vantagens e desvantagens de utilizar o

uClinux em uma FPGA (Field Programmable Gate Array), assim como a necessidade de
gerenciamento de seus limitados recursos. Já o capítulo 4 apresenta detalhes do desenvolvimento do sistema de gerenciamento de redes para sistemas embarcados utilizando software livre e os passos necessários para a integração de um agente SNMP no sistema embarcado. No quinto capitulo são analisados os resultados do sistema e sua viabilidade técnica de implantação. Finalmente o sexto capitulo apresenta as conclusões do trabalho e sugestões para trabalhos futuros.

11 1 GERENCIAMENTO DE REDES

Conforme (SPECIALSKI, 2006), uma rede de computadores precisa ser gerenciada por menor e mais simples que seja, a fim de garantir, aos usuários, a disponibilidade dos serviços a um nível de desempenho aceitável. À medida que a rede cresce, aumenta a complexidade de seu gerenciamento, forçando assim a adoção de ferramentas automatizadas para seu monitoramento e controle.

Esta afirmação também vale para os sistemas embarcados, cada vez mais utilizados em equipamentos de propósito especifico, como celulares, tocadores de MP3, fornos de microondas e geladeiras. Uma vez que os recursos do sistema dedicado sejam monitorados, pode-se garantir que o mesmo esteja trabalhando adequadamente.

A arquitetura para gerenciamento de rede mais utilizada é o SNMP, que se refere a um conjunto de padrões para gerenciamento de redes de computadores que inclui um protocolo, uma especificação de estrutura de dados e um conjunto de objetos de dados. Esta é a arquitetura de gerência adotada como padrão para redes TCP/IP, que será descrito nas próximas seções do trabalho.

2.1 Modelo básico de gerenciamento

Segundo (SILVA, 2005), um sistema de gerenciamento de redes é composto por entidades que participam do processo obtendo ou fornecendo informações. Normalmente, a coleta de informações é centralizada em uma estação de gerenciamento e os agentes ficam responsáveis por enviarem informações a esta estação gerente.

Conforme descreve (SPECIALSKI, 2006), as estações de gerenciamento executam aplicações que monitoram e controlam os elementos de rede, que possuem agentes responsáveis pela execução das funções de gerenciamento de rede, requisitadas pelos gerentes.

12
Na Figura 1, pode-se ter uma visão geral do funcionamento de um sistema de gerenciamento de redes, a comunicação entre aplicações e objetos gerenciados, que serão detalhados no próximo capítulo.

Figura 1: Modelo básico de um Sistema de Gerência de Redes Fonte: (SILVA, 2005)

De uma forma geral, as mensagens partem do gerente para os objetos gerenciados, obtendo destes as informações necessárias ao gerenciamento da rede ou do equipamento específico que se deseja monitorar. É possível observar na Figura 2, como ocorre a

comunicação entre gerente e agente, assim como os tipos de mensagens que fluem entre essas duas entidades.

Figura 2: Mensagens em um Protocolo de Gerência de Redes Fonte: (SILVA, 2005)

13 2.2 Elementos da Arquitetura SNMP

A arquitetura SNMP possui uma característica cliente/servidor. A informação pode ser obtida de duas maneiras: através de um alerta SNMP (notificação) que informa o estado (status) do equipamento, emitida pelo agente implementado no dispositivo gerenciado, ou através do gerente SNMP que solicita uma requisição diretamente ao agente SNMP, conforme pode ser visto na Figura 3.

É possível também observar a MIB (Management Information Base), onde são armazenadas as informações dos objetos gerenciados. A MIB é apenas uma base conceitual, ou seja, não importa qual tipo de armazenamento físico (memória, arquivos ou base de dados) é utilizado no armazenamento das informações de gerenciamento.

Figura 3: Modelo de gerenciamento SNMP Fonte: (CORREIA, 2004)

A troca de informações entre a aplicação de gerenciamento e o agente ocorre através dos comandos disponíveis no pacote SNMP. Os principais comandos para manipular e/ou coletar os dados dos equipamentos, podem ser vistos na Tabela 1. Os detalhes dos elementos da arquitetura SNMP serão descritos nas próximas seções deste capítulo.

14
Tabela 1: principais comandos disponíveis no pacote SNMP
COMANDO snmpget snmpset snmpgetnext snmpwalk DESCRIÇÂO envia uma requisição SNMP Get para obter o valor atual contido em um objeto MIB gerenciado por um agente SNMP remoto. envia uma requisição SNMP Set para atualizar o valor atual contido em um objeto MIB gerenciado por um agente SNMP remoto. envia uma requisição SNMP GetNext para obter o valor do proximo objeto MIB gerenciado por um agente SNMP remoto, se disponivel. este comando é semelhante do comando snmpgetnext , porém permite obter todos os valores da MIB simultaneamente.

Fonte: (STALLINGS, 1999)

2.2.1 Agentes SNMP
Os agentes SNMP podem ser encontrados em hosts, bridges, roteadores, switches, servidores, impressoras e muitos outros equipamentos de rede. Para que o equipamento possa ser gerenciado, é necessária a existência de um agente SNMP interno no dispositivo. O agente é responsável por responder as requisições do sistema de gerenciamento.

O agente possui acesso direto à base de informações gerenciais (MIB), que contém todas as informações de gerência. Ao receber uma mensagem SNMP do gerente, o agente identifica que operação está sendo requisitada e quais as variáveis relacionadas. O agente então requisita estas informações à MIB. Em seguida, é criada uma mensagem com os dados solicitados, que posteriormente é enviada ao gerente solicitante (SILVA, 2005).

O agente também pode detectar, a partir da análise do contexto da MIB, alguma situação inesperada no dispositivo que monitora. Nesta situação, o agente gera uma mensagem especial, denominada Trap, e a envia ao gerente, relatando sobre a situação. Uma mensagem de Trap pode indicar um erro grave no equipamento, como falhas de energia.

Conforme (SILVA, 2005), para poder tratar estes erros o agente deve ter certo poder de decisão, cabendo a ele, a partir da análise do contexto da MIB, decidir se é ou não necessário enviar a Trap ao gerente. Isso é necessário para que em certas situações, como por exemplo, durante a inicialização do sistema, Traps desnecessários não sejam trafegados pela rede, o

15 que, em se tratando de dezenas ou centenas de agentes, poderia interferir no desempenho
global da rede. Assim, o agente que fica em cada equipamento, tem um papel fundamental em todo o processo de gerenciamento, acessando e disponibilizando informações de gerência contidas na MIB, além de indicar situações inesperadas de funcionamento do dispositivo que estiver gerenciando através do envio de Traps ao gerente SNMP.

2.2.2

O software gerente

O software gerente instalado em uma rede, tem como função principal enviar periodicamente comandos aos agentes, solicitando informações sobre variáveis de um objeto gerenciado ou modificando o valor de determinada variável, assim como receber e tratar as exceções (Traps) encaminhadas pelos agentes.

A estação gerente é uma máquina na rede que possui o software gerente, responsável por obter informações dos agentes e analisá-las. A estação serve como interface para que o gerente humano possa monitorar e controlar o gerenciamento de uma rede (MEDEIROS, 2006).

A estação gerente pode obter informações de gerência presente nos elementos gerenciados através de uma sondagem regular dos agentes ou até mesmo recebendo informações enviadas diretamente pelos agentes; a estação também pode alterar o estado de elementos remotos gerenciados (MEDEIROS, 2006).

2.3

Base de informação gerencial (MIB)
A base de informação gerencial (MIB) é um conjunto de objetos gerenciados definidos

segundo um padrão estruturados em grupos hierárquicos. Os objetos gerenciados possuem um valor que representa o estado de um objeto real em um determinado instante. É o local onde

16 estão definidas e armazenadas as informações que podem ser acessadas através de um
protocolo de gerenciamento (CORREIA, 2004; SPECIALSKI, 2006).

O armazenamento das informações na MIB foi padronizado em uma estrutura em forma de árvore, conforme pode ser visto na Figura 4, composta por nós, onde cada nó tem um OID (Object Identifier) chamado de índice e um nome associado. Por exemplo: o OID “1.3.6.1.2.1.1.4.0” contém como valor uma string com o contato técnico responsável pelo agente SNMP. Este OID também é conhecido por “SNMPv2-MIB::sysContact.0”, que por sua vez é uma abreviação de “iso.org.dod.internet.mgmt.mib-2.system.SNMPv2-

MIB.sysContact.0”. A maioria dos dispositivos de rede com suporte a SNMP implementa pelo
menos a SNMPv2-MIB, que contém entre outras coisas a descrição das interfaces de rede e o valor dos contadores dessa interface (CORREIA, 2004; SILVA, 2005).

Figura 4: Estrutura de Árvore da MIB Fonte: (CORREIA, 2004).

Atualmente existem inúmeras MIBs implementadas que foram propostas em RFCs (Request for Comments), e também muitas MIBs proprietárias implementadas por fabricantes para melhor gerenciar seus equipamentos. Com isto tem-se uma quantidade muito grande de variáveis, o que torna a escolha difícil para o gerente, no sentido de selecionar o que é mais importante para ser gerenciado, dentre inúmeras possibilidades (CORREIA, 2004).

17 Neste trabalho, foram selecionadas duas MIBS. A MIB II, e a Host-Resources MIB,
que contém os objetos que serão gerenciados pelo sistema de gerenciamento de redes para sistemas embarcados, desenvolvido pelo autor. A escolha dessas MIBS foi necessária para se conseguir monitorar dois tipos de informações: referente ao dispositivo gerenciado (MIB II) e referente aos recursos que o sistema operacional gerência (Host-Resources MIB). Estes objetos serão detalhados nas próximas seções.

2.3.1 Acesso aos valores da MIB
Cada objeto SNMP é definido para ter um tipo de acesso somente de leitura, leitura e escrita ou apenas escrita. Isso determina se o usuário pode ler ou alterar o valor de um objeto (SILVA, 2005).

Antes que qualquer objeto possa ser lido ou escrito, o nome comunitário do agente SNMP deve ser conhecido. Estes nomes comunitários são configurados pelo administrador e podem ser vistos como senhas necessárias para acessar e manipular dados do agente SNMP. Neste sentido, nomes comunitários existem para permitir que partes da MIB no SNMP, e subconjuntos de objeto sejam referenciados. Como o termo comunitário é requerido, espera-se que o verdadeiro propósito destes valores sejam identificar comunitariamente os objetos SNMP configurados. Porém, é prática comum fazer estes nomes comunitários limitarem o acesso da capacidade do SNMP para usuários sem permissão (SILVA, 2005).

2.3.2 Objetos da MIB II

Os objetos da MIB II estão organizados em grupos, conforme se pode ver na Tabela 2. Segundo (SPECIALSKI, 2006), a organização em grupos é conveniente porque os objetos são organizados de acordo com as funções das entidades gerenciadas e também para oferecer um guia para os implementadores de agentes, no sentido de identificar quais objetos devem ser implementados.

18
Tabela 2: Descrição dos grupos da MIB II
GRUPOS System Interfaces Address Translation IP ICMP TCP UDP EGP CMOT Transmission SNMP INFORMAÇÕES Identificação do dispositivo gerenciado. Interface de rede com o meio físico. Mapeamento de endereços IP em endereços físicos. Protocolo IP Protocolo ICMP Protocolo TCP Protocolo UDP Protocolo EGP Protocolo CMOT Meios de transmissão Protocolo SNMP

Fonte: (CORREIA, 2004)

Cada grupo da MIB II é dividido em subgrupos. Na Tabela 3, pode-se observar a descrição dos principais subgrupos e objetos da MIB II. Tabela 3: Descrição dos principais subgrupos da MIB II
Grupo Objeto sysDescr sysUpTime Descrição descrição do sistema (versão, hardware, sistema operacional) tempo desde a última reinicialização nome da pessoa de contato localização fisica do equipamento indica se esta entidade é um gateway IP datagramas recebidos com erros no cabeçalho IP datagramas recebidos com erros no endereco IP algoritmo de retransmissão número maximo de conexões TCP Número de segmentos recebidos número de segmentos descartados por erro número de reinicializações geradas número da interface descrição da interface tipo da interface tamanho do maior datagrama IP status da interface (UP/Down) total de pacotes descartados na entrada total do trafego de entrada em pacotes (bytes) total de pacotes descartados na saida total do trafego de saida em pacotes (bytes) total de pacotes SNMP recebidos total de pacotes SNMP enviados total de Traps SNMP recebidos total de Traps SNMP enviados

System sysContact sysLocation IP ipForwarding ipInHdrErrors ipInAddrErrors TCP tcpRtoAlgorithm tcpMaxconn tcpInSegs tcpInErrs tcpOutRsts Interfaces ifIndex ifDescr if Type ifMtu ifAdmininStatus ifInDiscards
ifInOctets

ifOutDiscards
ifOutOctets

SNMP
snmpInPkts snmpOutPkts snmpInTraps snmpOutTraps

Fonte: (LEINWAND; CONROY, 2000).

19 2.3.3 Objetos da MIB Host-Resources

Na MIB Host-Resources estão armazenadas diversas informações importantes sobre o equipamento, tais como: taxa de uso da CPU e memória, programas que estão sendo executados no momento, tamanho do disco e percentual em uso, entre muitas outras. Esta MIB é dividida em seis grupos, conforme descrito na Tabela 4.

Tabela 4: Grupos da MIB host-resources
Grupo System Storage Device Running Software Running Software Performance Installed Software Informações Informações do sistema: tempo ativo, data e hora, total processos Informações sobre unidades de armazenamento: HDs, CD, disquete Informações sobre dispositivos: placa de rede, teclado, mouse Informações sobre software instalado: parametros Informações sobre programas executando e consumo de CPU e memoria Informações sobre software instalado: data e hora da instalação
Fonte: (RFC: 2790)

Cada grupo da MIB Host-Resources, também é dividido em subgrupos. Na Tabela 5, pode-se observar a descrição dos principais subgrupos e objetos da MIB Host-Resources. Tabela 5: Descrição dos principais subgrupos da MIB Host-Resources
Grupo System hrSystemUpTime hrSystemDate hrSystemProcesses Storage hrMemorySize hrStorageDescr hrStorageSize hrStorageUsed Running Software hrSWRunName hrSWRunParameters hrSWRunPerfCPU hrSWRunPerfMem Running Soft. Performance hrProcessorLoad Installed Software hrSWInstalledDate Data da Instalação do programa Taxa de carga do processador Nome do programa ativo Parametros de carga do programa Total de Ciclos de CPU consumidos desde a carga Total de Ciclos de Memória consumida desde a carga (em KB) Total de memória física - em Kbytes Descrição dos dispositivos - HD, CDRom, Memoria Virtual Capacidade total de de armazenamento Capacidade de armazenamento utilizada Tempo ativo desde a última reinicialização Data e hora atual do equipamento Numero total de processos ativos Objeto Descrição

Fonte: (LEINWAND; CONROY, 2000).

Os detalhes da integração destas MIBs e do agente SNMP no sistema embarcado, será descrito nos próximos Capítulos deste trabalho.

20 3 SISTEMAS EMBARCADOS
Nos últimos anos tem-se visto uma crescente utilização de softwares embarcados em praticamente todos os objetos eletrônicos construídos pelo homem. Sistema embarcado é um software embutido dentro de um dispositivo eletrônico, como o sistema de injeção eletrônica de um automóvel, permitindo que este equipamento atue com maior funcionalidade e flexibilidade. Antes apenas utilizados em sistemas complexos como sistemas industriais, aeronaves e navios, hoje já existem softwares embarcados em geladeiras, televisores e fornos de micro-ondas. Estes equipamentos tornam-se cada vez mais sofisticados, demandando mais complexidade no hardware e software embarcado (TAURION, 2007).

As vantagens dos equipamentos se comunicarem uns com os outros e com os computadores que processam as aplicações nas empresas são imensas. Por exemplo, um fabricante de geladeiras, saber com antecedência de eventuais problemas de manutenção identificados por sensores e transmitidos via Internet aceleram as atividades da assistência técnica e transformam as relações com os seus clientes.

Um sistema embarcado traz algumas diferenças em relação a um computador convencional (PC). Um PC tem entradas e saídas comuns como teclado, mouse, monitor, impressora, disco rígido e rede que são suportadas de forma nativa pelo sistema operacional. Nos sistemas embarcados têm uma variedade de opções maior, como botões, chaves e vários tipos de displays, porém nem todos, têm suporte nativo, ou seja, devem ser ativados durante a compilação do kernel.

A grande maioria dos sistemas operacionais criados ou portados para plataformas embarcadas, dispõe de serviços que estendem facilmente o seu uso em uma rede local e na Internet. As suas distribuições já estão incluídas os drivers para facilitar a instalação e configuração (UCLINUX, 2007).

21 3.1 O Sistema Operacional uClinux

Em 1997 teve início um projeto para portabilizar o kernel 2.0 do sistema operacional Linux para microcontroladores e microprocessadores sem MMU (Memory Manager Unit). Este projeto ganhou o nome de Projeto uClinux, que teve sua primeira versão desenvolvida para o microprocessador DragonBall da Motorola (ASSIS, 2004).

O uClinux, por ser uma versão do Linux, é um sistema operacional que adere ao padrão POSIX (Portable Operating System Interface for Unix), o que torna os programas desenvolvidos para Linux compatíveis com o uClinux (ASSIS, 2004).

Embora os dois sistemas por definição sejam compatíveis, uma aplicação compilada para Linux não funciona no uClinux. Isto acontece porque o uClinux utiliza algumas bibliotecas modificadas do Linux que visam diminuir o tamanho final dos programas, como a

uClibc. Esta necessidade de diminuir o tamanho final dos programas se faz necessário, uma
vez que o uClinux tem como alvo plataformas que geralmente possuem recursos limitados de memória e processamento, como, o ARM (Acorn RISC Machine), PowerPC e Microblaze (UCLINUX, 2007). A atual distribuição do uClinux, baseada no kernel 2.6.x do Linux, disponibiliza uma série de serviços tradicionais em ambientes Unix/Linux, como suporte para filesystem,

network e bootloader. Entretanto, possui serviços desenvolvidos em nível de aplicação como,
por exemplo, o SSH (Secure Shell) e o SNMP que é o foco principal deste trabalho.

A compilação do kernel uClinux é realizada por meio de um menu de configurações, semelhante à compilação de um kernel de qualquer GNU/Linux. Deste modo, ativar ou desativar um ou outro serviço vai depender apenas da seleção do que melhor se encaixa aos objetivos do trabalho. Para microprocessadores que não possuem MMU, como o Microblaze, que foi utilizado neste trabalho de conclusão, a distribuição GNU/Linux recomendada é o uClinux ou o Petalinux. (MICROBLAZE, 2007).

22 3.1.1 O Sistema Operacional PetaLinux
O suporte e desenvolvimento do sistema operacional para sistemas dedicados, uClinux foi assumido pela Empresa Petalogix (PETALOGIX, 2007), a qual manteve a mesma estrutura interna do sistema toda a mesma, inclusive o nome do kernel continua sendo

uClinux.

Pode-se notar claramente algumas evoluções em relação à versão anterior do

uClinux, como destaque principal o suporte ao kernel versão 2.6.x e a integração da
ferramenta de compilação para o ambiente uClinux (cross-compiler).

Para o desenvolvimento deste trabalho, foi utilizada a versão mais recente do Petalinux, que pelo motivo citado acima, foi referenciado no trabalho com o nome de uClinux. Esta nova versão do uClinux manteve compatibilidade com os dispositivos FPGA um pouco mais antigas, como a que foi utilizada neste trabalho.

3.2 O dispositivo FPGA Xilinx
Um dispositivo FPGA é uma plataforma de hardware reconfigurável. Em outras palavras, é um circuito integrado produzido em larga escala, que pode ser programado e reprogramado após sua fabricação, não estando limitado a funções pré-determinadas de fábrica.

Um FPGA é composto de pequenos blocos lógicos programável, que por sua vez contêm um pequeno número de registradores e elementos lógicos configuráveis. Ela é caracterizada pela quantidade de blocos lógicos ou transistores, assim como por sua estrutura lógica, velocidade e consumo (MOHR, 2006).

Algumas características são comuns a quase todos, como os elementos lógicos, lookup

tables, memória, recursos de roteamento (que são peças-chave na flexibilidade da FPGA) e
entradas e saídas configuráveis – que proverão à interface do sistema. Como o FPGA é passível de configuração, torna-se simples criar sistemas que possuam exatamente os módulos necessários para uma determinada aplicação, sendo possível desenhar os seus próprios

23
módulos (MOHR, 2006; SILVA, 2006).

Dentre as características existentes, destacam-se os dois processadores PowerPC 405, controlador PHY Ethernet 10/100 onboard, o codec AC97 para áudio e o clock de 100 MHz (XILINX, 2007). A plataforma também possui conectores de expansão, permitindo instalar circuitos de propósitos especiais (DIGILENT, 2007).

Segundo (MOHR, 2006; SILVA, 2006), o microprocessador Microblaze, permite ao usuário selecionar um conjunto específico de funções requisitadas por seu design, sendo que as funções abaixo são fixas: - 32 registradores de uso geral de 32-bits; - instruções de 32-bits com 3 operandos e 2 modos de endereçamento; - bus de endereços de 32-bits; - single issue pipeline; - formato de dados big-endian ou little-endian dependendo da máquina empregada.

Além do Microblaze, o FPGA Xilinx Virtex-II Pro possui dois microprocessadores

PowerPC 405, que são uma versão embutida do processador PowerPC 405. Dentre os
processadores vistos neste estudo, o PowerPC 405 é o único hard processor, ou seja, um microprocessador fixo em hardware na FPGA (DIGILENT, 2007) .

Diferentemente dos outros processadores, o PowerPC possui MMU, otimizada para ambientes embutidos. Implementa uma derivação da arquitetura PowerPC, para ambientes embutidos (PowerPC embedded-environment architecture). Para este processador, outras distribuições de Linux podem ser utilizadas, como o PowerPC Linux e o Monta Vista Hard

Hat Linux, esta última versão, porém não é gratuita (MOHR, 2006).

Para a prototipação deste trabalho foi utilizada uma placa fabricada pela Digilent, baseada no FPGA Virtex-II Pro, da Xilinx, que pode ser vista na Figura 5. É uma plataforma com diversos componentes periféricos a serem escolhidos para integrar sistemas complexos.

24

Figura 5: Plataforma de desenvolvimento Virtex-II Pro Fonte: Figura recolhida em Digilent (2007)

3.3 Gerenciamento de sistemas embarcados

Observando as novidades e tendências no mundo dos sistemas embarcados, como descrito no início desta seção, assim como o crescente número de trabalhos acadêmicos realizados utilizando sistemas embarcados, nota-se a necessidade de melhorar o gerenciamento do sistema operacional embarcado instalado nas placas FPGAs. Dentre os trabalhos acadêmicos relacionados nas referencias bibliográficas, vale destacar os de (MOHR, 2006) e (SILVA, 2006).

25 Em seu trabalho (MOHR, 2006), aplicou os conceitos de VPN (Virtual Private Network) em um sistema Linux embarcado em FPGA, provendo a infra-estrutura necessária
para implementações que visam à segurança na transmissão de informações a partir de sistemas embarcados. Com isso, a necessidade que muitos aparelhos têm de utilizar um computador como ponte para acessar uma rede privada, terá uma alternativa de baixo custo.

No trabalho de (SILVA, 2006), a proposta de construir o protótipo de um sistema embarcado microprocessado, que permita, por meio do WAP (Wireless Application Protocol) de um aparelho telefônico celular, utilizar o microprocessador Microblaze em conjunto com o

kernel uClinux, no controle à distância de dispositivos. A análise do comportamento e do
funcionamento deste sistema em laboratório permitiu verificar a possibilidade de seu uso em redes WAP reais. Em ambos os trabalhos, o fato em comum é a utilização de um dispositivo FPGA, do microprocessador Microblaze, e do sistema operacional embarcado uClinux. Em ambos os trabalhos, poderia-se, por exemplo, acompanhar as taxas de uso de CPU e memória, saber qual programa está consumindo mais ciclos de CPU. Poderia-se também, obter dados importantes em relação à interface de rede, tais como: - Total do tráfego de entrada e saída em pacotes (bytes). - Total de pacotes descartados na entrada e na saída. - Percentual de uso da interface de rede. - Taxa de uso de CPU e memória.

Neste contexto, este trabalho descreve os passos para instalar um agente SNMP no dispositivo FPGA e através do sistema de gerenciamento de redes para sistemas embarcados desenvolvido pelo autor obter e analisar os dados obtidos do dispositivo.

26 4 IMPLEMENTAÇÃO DO SISTEMA

O objetivo deste trabalho é desenvolver um sistema de gerenciamento de redes para sistemas embarcados utilizando software livre. Este capítulo descreve os passos necessários para a instalação e configuração dos elementos que constituem a arquitetura do sistema.

4.1

Arquitetura do Sistema de Gerenciamento
A arquitetura geral do sistema de gerenciamento de redes para sistemas embarcados, é

composta dos seguintes módulos: - Agente SNMP: para permitir a coleta dos dados do dispositivo e possibilitar o monitoramento e tráfego de rede do dispositivo; - FPGA: dispositivo que, em conjunto com o uClinux, forma o sistema embarcado. - Aplicação de gerenciamento de redes: aplicativo que irá monitorar e gerenciar os dispositivos ligados na rede. - Estação de trabalho (PC): para operar o sistema de gerenciamento, na qual estão instalados os seguintes serviços: 1. Servidor WEB Apache: para disponibilizar as páginas; 2. Linguagem PHP: para processar os comandos de coleta dos dados; 3. MySQL : para armazenar os dados coletados.

As informações coletadas e processadas pelo sistema de gerenciamento de redes, geram gráficos e tabelas, tais como: utilização da rede, erros de pacotes, taxas de utilização da CPU e memória. Os dados ficam armazenados em banco de dados para consultas futuras. Na Figura 6, pode ser visualizada a arquitetura do sistema.

27

Figura 6 – Arquitetura do sistema de gerenciamento de redes Fonte: Figura elaborada pelo autor

4.2

Funcionamento geral do sistema

Para utilizar o sistema de gerenciamento de redes, todos os dispositivos devem ser conectados na rede, como mostra a Figura 6. Após isto, apenas alguns ajustes são necessários para iniciar o monitoramento do dispositivo FPGA, como por exemplo, cadastrar o endereço IP do dispositivo que será monitorado.

28 Outra forma de utilização é conectar diretamente o dispositivo FPGA à estação de
trabalho ou servidor onde está instalado o sistema de gerenciamento, através de um cabo de rede cross-over. Este procedimento elimina a possibilidade de erros e interferências do

Switch, porém limita o sistema a monitorar um único dispositivo por vez1.

Para a implementação do gerenciamento de um sistema embarcado é necessária a configuração de um agente com duas MIBs. Com isso, é possível monitorar informações especificas do dispositivo (MIB II), juntamente com informações do sistema operacional (Host-Resources MIB). Todas as configurações e problemas enfrentados na implantação do agente SNMP no kernel uClinux estão detalhadas nos anexos “A” e “B”. Com isso, deseja-se criar um guia de configuração para a utilização dessa ferramenta proposta.

4.3

Sistema de gerenciamento de rede para sistemas embarcados
O sistema de gerenciamento de rede para sistemas embarcados, foi desenvolvido

utilizando a linguagem PHP (PHP, 2007), com interface WEB simples e intuitiva e banco de dados MySQL (MYSQL, 2007) para armazenar e recuperar os dados. Sendo assim, o sistema utiliza apenas software livre para realizar o monitoramento de sistemas embarcados. O sistema pode ser testado on-line no endereço http://www.inf.unisc.br/sgr. No banco de dados on-line, estão disponíveis alguns testes de monitoramento, realizados pelo autor, assim como relatórios e gráficos deste monitoramento.

4.4

Como monitorar um dispositivo FPGA com o Sistema
Antes de iniciar o monitoramento, o dispositivo FPGA deve estar conectado à rede e

com a imagem do kernel com o agente SNMP integrado carregada. Em caso de dúvidas ou problemas, os anexos “A” e “B” devem ser consultados. Após esta etapa, o sistema de gerenciamento de redes para sistemas embarcados deve ser carregado. A tela inicial do sistema pode ser observada na Figura 7.
1

O sistema de gerenciamento de redes desenvolvido neste trabalho pode monitorar vários dispositivos ao mesmo tempo. Para isto, os mesmos devem estar cadastrados e ativos no sistema.

29

Figura 7 – Tela de abertura do sistema de gerenciamento Fonte: Figura capturada e editada pelo autor

4.4.1 Cadastrando um novo dispositivo para monitorar

Para adicionar um novo dispositivo, por exemplo, uma nova placa FPGA, deve-se cadastrar o endereço IP deste dispositivo no sistema. O “menu cadastro” deve ser acessado e deve-se clicar em “Incluir”. Em seguida, deve-se preencher os dados solicitados e clicar em “Gravar Dados”. O endereço IP “192.168.0.10”, é o padrão configurado no kernel do

uClinux. A Figura 8 mostra os detalhes do cadastro de um novo dispositivo.

30

Figura 8 – Cadastro de novo dispositivo para monitorar Fonte: Figura capturada e editada pelo autor

As informações na tela de cadastro devem preenchidas conforme descrito abaixo: - Endereço IP: O endereço IP do dispositivo que se deseja monitorar. - Descrição: Uma breve descrição deste dispositivo. - Comunidade(ro): O nome da Comunidade SNMP para acessar as informações da MIB deste dispositivo. Normalmente este nome é “public”. - Interface(index): O índice da interface de rede que se deseja monitorar. Deve-se utilizar o comando “snmpwalk -v1 -c public endereço_ip ifdescr”, para visualizar os dispositivos de rede no dispositivo. - Tipo: Selecione o tipo de dispositivo. As opções disponíveis são: “FPGA”, “WINDOWS” e “LINUX”. Deve-se selecionar sempre a opção “FPGA”. As outras opções estão apenas disponíveis para testes e trabalhos futuros, visando monitorar outros tipos de dispositivos, como um servidor com sistema operacional Windows Server ou Linux. - Ativo: Defina se o dispositivo está ativo no sistema no momento do cadastro ou não. Esta opção permite que se faça o cadastro de vários dispositivos no sistema. Apenas os dispositivos marcados como ativos ficarão disponíveis para monitoramento. Durante a etapa do cadastro, não é necessário que o dispositivo esteja ligado. Porém, para que o mesmo fique operacional no sistema, deve-se ainda coletar dados técnicos do mesmo como, por exemplo, a velocidade da interface de rede. Para esta etapa do processo, o dispositivo deve estar ligado e conectado à rede.

31
Para coletar estes dados, deve-se clicar no “menu cadastro” e selecionar a opção “Alterar” e após clicar em “Coletar” na linha que identifica o dispositivo, conforme mostra a Figura 9. Nesta mesma tela, também é possível encontrar as opções de ativar e desativar o dispositivo, assim como excluir o mesmo do cadastro.

Figura 9 – Coleta de dados técnicos do dispositivo Fonte: Figura capturada e editada pelo autor

4.4.2 Iniciando o monitoramento

Para iniciar o monitoramento do dispositivo, deve-se acessar o “menu Coleta Dados” e selecionar a opção “Iniciar”. Alguns parâmetros devem preenchidos, como visto na Figura 10.

Figura 10 – Parâmetros da coleta de dados Fonte: Figura capturada e editada pelo autor

Onde as informações referentes à Figura 10 estão descritas a seguir: - Dispositivo: o dispositivo que será monitorado. - Intervalo de coleta: o intervalo de tempo entre as coletas. - Tempo de coleta: tempo que sistema ficará monitorando o dispositivo.

32
- ID da coleta: número gerado automaticamente pelo sistema, para identificar esta coleta, permitindo através deste recuperar informações de coletas anteriores. Este ID é gerado utilizando a data e hora do sistema no seguinte formato: “ddmmyy-hhiiss”, onde: - dd: é o dia do mês corrente - mm: é o mês do ano corrente - yy: é o ano corrente utilizando quatro digitos - hh: é a hora corrente - ii: são os minutos da hora corrente - ss: são os segundos correpondentes a hora e minutos acima. Após a configuração dos parâmetros da coleta, deve-se clicar em “Iniciar Coleta”. Podese notar que uma nova janela abre com o status do monitoramento em andamento, conforme visto na Figura 11. Esta janela pode ser minimizada e o acompanhamento do resultado da coleta pode ser feito em paralelo à coleta.

Figura 11 – Tela do sistema de gerenciamento coletando dados Fonte: Figura capturada e editada pelo autor

33 4.4.3 Gerando tráfego na interface de rede

Para melhor visualizar os relatórios e gráficos que o sistema gera a partir dos dados da coleta, é interessante gerar tráfego na interface de rede. Sugere-se utilizar o comando ping, que atende perfeitamente a esta situação. A metodologia adotada para gerar tráfego na interface de rede foi a seguinte: Uma vez iniciada a coleta, a cada intervalo de tempo, dois novos prompts de comando foram utilizados enviando “ping” para o dispositivo durante as cinco primeiras coletas. O tamanho dos pacotes enviados (em bytes) pelo comando ping foram: 32, 1500, 15000, 30000 e 65000. A sintaxe do comando ping no Windows é a seguinte:

ping 192.168.0.10 –l 1500 –t
O parâmetro “-l” indica ao comando ping para enviar pacotes de dados com 1500

bytes ao IP de destino (neste caso 192.168.0.10) ao invés de pacotes com 32 bytes enviados
por padrão. No sistema Linux, deve-se utilizar a seguinte sintaxe de comando:

ping 192.168.0.10 –f –s 1500
Podem-se ter vários prompts abertos gerando tráfego. Observou-se durante este trabalho que a cada novo prompt gerando tráfego com o tamanho do pacote igual a 65000 bytes (valor próximo do máximo aceito, que é 65500), a taxa de utilização da interface de rede aumenta em 1 ponto percentual (1%), logo, com 100 prompts ativos executando o mesmo comando, uma interface de rede com velocidade de 100 Mbits chegaria ao limite do tráfego teórico. Na Figura 12, pode-se observar um exemplo da saída gerada pelo comando ping.

Figura 12 – Gerando tráfego na interface de rede Fonte: Figura capturada e editada pelo autor

34 4.4.4 Analisando os relatórios e gráficos gerados pelo sistema

Após iniciada a coleta dos dados do dispositivo selecionado, pode-se verificar os resultados dos dados já coletados. Para isto, deve-se acessar o “menu Relatórios”, em seguida clicar em “Tráfego” e selecionar o ID da coleta que desejar analisar. Após deve-se clicar em “Ver Relatório”. Pode-se notar que o ID da última coleta estará no inicio desta lista, conforme visto na Figura 13.

Este processo de seleção de ID da coleta deve ser repetido para cada relatório e gráfico disponível no menu do sistema.

Figura 13 – Selecionando ID da coleta para analisar tráfego Fonte: Figura capturada e editada pelo autor

No relatório de “Tráfego de Rede” gerado pelo sistema de gerenciamento de redes para sistemas embarcados, pode-se observar os campos “Bytes Recebidos”, “Bytes Enviados”, “% de Uso da interface de rede”, “Pacotes Descartados” e “Erros na interface de rede”, conforme mostra a Figura 14.

Figura 14 – Relatório de tráfego gerado pelo sistema de gerencia Fonte: Figura capturada e editada pelo autor

35
Analisando os dados da tabela acima: - Total de Bytes Recebidos: 62,91 MB; - Total de Bytes Enviados: 61,12 MB; - Pico de uso da interface de rede: 3,21%; - Pacotes descartados (entrada e saída): zero; - Pacotes com erros (entrada e saída): zero; Os dados do relatório acima, podem ser ainda melhor analisados pelo gráfico gerado pelo sistema conforme pode ser observado na Figura 15. Pode-se notar que os valores do gráfico expressam os dados da Figura 14.

Figura 15 – Gráfico de Bytes Enviados e Recebidos. Fonte: Figura capturada e editada pelo autor

Pelo gráfico da Figura 15, pode-se notar que o total de bytes enviados e recebidos é quase equivalente. Isto se deve ao fato do comando ping responder ao host de origem enviando o mesmo tamanho de pacote recebido. O total de bytes recebidos é um pouco superior em relação aos enviados, devido ao tamanho das mensagens trocadas entre o agente e

36 gerente SNMP; ou seja, o tamanho do pacote recebido pelo dispositivo é maior do que o
tamanho do pacote enviado com as informações solicitadas. Outro gráfico disponível no sistema é de percentual de uso da interface de rede de um determinado período de coleta. Analisando graficamente os mesmos dados da tabela cima, observa-se o pico de uso da interface de rede, conforme mostra a Figura 16.

Figura 16 – Gráfico do % de uso da interface de rede. Fonte: Figura capturada e editada pelo autor

Outra opção de relatório gerado pelo sistema é de processos ativos durante o monitoramento do dispositivo. Na Figura 17, podem ser observados os campos “PID”, “Processo”, “Ciclos de CPU” e “Memória (KB)”.

Estes dados são importantes para saber qual processo está consumindo mais memória e ciclos de CPU do dispositivo monitorado em determinado momento da coleta. Em destaque na Figura 17, o processo “snmpd”.

37

Figura 17 – Relatório de Processos Ativos – Uso de CPU e Memória Fonte: Figura capturada e editada pelo autor

38 5 ANALISE DE DESEMPENHO DO SISTEMA

Em paralelo às coletas efetuadas pelo sistema de gerenciamento de redes para sistemas embarcados, utilizou-se a ferramenta Ethereal (ETHEREAL, 2007) para verificar a quantidade de pacotes SNMP que foram injetados na rede para realizar o monitoramento do dispositivo.

Analisando os dados da Tabela 6, pode-se concluir que quando o tráfego de dados é baixo, como na “Coleta 1” da Tabela abaixo, o percentual dos pacotes SNMP na rede, é significativo, chegando a quase 20% do tráfego total. Porém, quando o trafego de dados é alto, este percentual é insignificante em relação ao volume total de dados tráfegados, chegando a pouco mais de 1% em média, como pode ser observado na “Coleta 5”.

Tabela 6 – Análise de impacto do monitoramento no tráfego da rede
Coleta 1 2 3 4 5 Tamanho pacote (bytes) 32 1500 15000 30000 65000 % T

Comentários