AVALIAÇÃO DE DESEMPENHO DA REDE DO POP-PI Bolsista: José Athayde Torres Costa Neto Orientador: Magno Alves dos Santos Coordenador: Nathan Franklin Saraiva de Sousa Teresina-PI Dezembro, 2008.
SUMÁRIO 1. INTRODUÇÃO...5 2. JUSTIFICATIVA...6 3. OBJETIVOS E METAS...7 4. MÉTRICAS DE DESEMPENHO...8 4.1. Atraso...8 4.2. Variação de Atraso (Jitter)...9 4.3. Perda de Pacotes...9 4.4. Largura de Banda...9 4.5. Vazão (Throughput)...10 5. INFRA-ESTRUTURA DE MONITORAÇÃO ATIVA...11 6. PONTOS DE MEDIÇÃO...13 6.1. NTP...13 6.2. PING...14 6.3. TRACEROUTE...16 6.4. OWAMP...17 6.4.1. Definição...17 6.4.2. Características...17 6.4.3. Visão Geral...18 6.5. IPERF...19 6.6. BWCTL...20 6.6.1. Definição...20 6.6.2. Características...21 6.6.3. Visão Geral...21 6.7. CLMP...23 7. NETWORK DIAGNOSTIC TOOL (NDT)...25 7.1. Características:...25 7.2. Servidor...27 7.2.1. O processo fakewww...27 7.2.2. O processo web100srv...28
7.3. Cliente...29 7.3.1. Linha de Comando...29 7.3.2. Applet Java...31 8. CACTISONAR...34 8.1. O CACTI...34 8.2. Funcionalidades do CactiSONAR...34 8.2.1. Cadastro e Monitoramento de Serviços perfsonar...34 8.2.2. Modelos de Testes e Matrizes de Testes...35 8.2.3. Gráficos do CactiSONAR...36 8.2.4. RDD-MA...37 9. SIMULAÇÃO DA REDE DO POP-PI...38 9.1. OPNET...38 9.2. Definição do Problema...39 9.3. Modelagem...40 9.4. Simulação...43 9.5. Análise...44 9.6. Resultados...50 10. CONCLUSÃO...51 REFERÊNCIAS BIBLIOGRÁFICAS...52 ANEXOS...54 ANEXO I INSTALAÇÃO E CONFIGURAÇÃO DOS PONTOS DE MEDIÇÃO...55 ANEXO II INSTALAÇÃO E CONFIGURAÇÃO DO NDT...67 ANEXO III INSTALAÇÃO E CONFIGURAÇÃO DO CACTISONAR...71
ÍNDICE DE FIGURAS FIGURA 1: Infra-estrutura de monitoração ativa proposta...12 FIGURA 2: Teste com NTP...14 FIGURA 3: Testando sincronização com ntptime....14 FIGURA 4: Teste com a ferramenta PING...15 FIGURA 5: Teste com a ferramenta TRACEROUTE...16 FIGURA 6: Teste com OWAMP usando o comando owping em localhost...19 FIGURA 7: IPERF como servidor...20 FIGURA 8: IPERF como cliente...20 FIGURA 9: BWCTL servidor...22 FIGURA 10: BWCTL cliente...22 FIGURA 11: Arquitetura do Sistema CLMP....23 FIGURA 12: Teste local com o cliente web100clt...30 FIGURA 13: Teste remoto através do applet Java....31 FIGURA 14: Tabela com estatísticas de uso do NDT e resultados do teste corrente....32 FIGURA 15: Gráfico do percentual de ocorrência de cada tipo de link encontrado...32 FIGURA 16: Criação de serviço perfsonar...35 FIGURA 17: Criação de Modelos de Teste...35 FIGURA 18: Criação da Matriz de Testes...36 FIGURA 19: Exemplos de Gráficos inseridos pelo CactiSONAR....36 FIGURA 20: Criando um novo projeto no OPNET...40 FIGURA 21: Tela inicial de modelagem da rede...41 FIGURA 22: Rede interna do PoP-PI....42 FIGURA 23: Cenário final da rede....42 FIGURA 24: Gráficos de: Atraso, Throughput, Enfileiramento e Tráfego de envio...44 FIGURA 25: Gráfico de utilização do link...45 FIGURA 26: Tela de Login do CACTI...73 FIGURA 27: Habilitando o Plugin Management e opções de menu do perfsonar....74 FIGURA 28: Instalando plugin perfsonar...75
1. INTRODUÇÃO O trabalho do administrador de rede é complicado. Ele não é só responsável por instalar e manter os fios, hubs, switches, roteadores e firewalls, mas também deve garantir que todos eles funcionem juntos e com eficiência. Naturalmente, isto deve ser feito dentro de limites de um orçamento, que no geral, é menor que o realmente necessário para realizar o trabalho. Todo profissional de redes de computadores certamente já ouviu e se questionou a respeito da qualidade de sua rede. Perguntas como: "a minha rede é rápida?", "porque a rede está tão lenta hoje?", "como posso saber se a minha rede tem bom desempenho?", fazem parte do cotidiano deste profissional. Seria ótimo se existissem respostas padrões a essas perguntas, juntamente com uma forma padrão de resolver o desempenho lento da rede. No entanto, isso não acontece na prática. Logo, é necessário buscar soluções para estes problemas. 5
2. JUSTIFICATIVA É fato que toda empresa ou instituição possui uma ou várias redes de computadores, seja para o acesso aos serviços da empresa ou à Internet. Porém, com o crescimento desordenado da rede, ela acaba sofrendo problemas e os usuários logo sentem os efeitos, o mais comum é a lentidão. Quem não conhece técnicas de medição de rede, logo vai apelar para o aumento da largura da banda, no entanto não é apenas com a velocidade de downloads ou largura de banda que é solucionado um problema desses. É provável que mesmo com o aumento da largura de banda, algumas redes continuem com problemas no tráfego, logo, percebe-se que é preciso conhecer ferramentas de medição do desempenho de redes. Várias podem ser as causas do baixo desempenho da rede, entre elas a perda de pacotes, a baixa taxa de transferência, o congestionamento, o atraso, a indisponibilidade etc. Com o intuito de garantir um bom desempenho da rede, um sistema de monitoração é de extrema importância para detectar possíveis falhas nela. Para isso, devem ser utilizadas ferramentas de desempenho de rede que podem ajudar o administrador a determinar o status da rede e identificar as áreas que podem ser melhoradas para aumentar seu desempenho. 6
3. OBJETIVOS E METAS Esse trabalho de pesquisa e implementação irá descrever as principais métricas de desempenho de redes, bem como um estudo detalhado das ferramentas utilizadas para os testes de medição ativa. Com isso, será criada uma infra-estrutura de monitoração, capaz de monitorar os pontos de medição ativa instalados na rede do PoP-PI. Ao final será realizada uma simulação da rede de distribuição do PoP-PI utilizando uma ferramenta específica, a fim de se obter uma melhor avaliação do desempenho da mesma. Portanto o objetivo principal desse trabalho é analisar e implantar uma infraestrutura de monitoramento na rede do PoP-PI para permitir a análise do desempenho num caminho fim-a-fim. Garantindo desta forma que a rede funcione com boa eficiência. 7
4. MÉTRICAS DE DESEMPENHO As métricas de desempenho descrevem as características do estado da rede durante os experimentos. Essas medidas podem ser obtidas através de técnicas de medição ativas que consistem na injeção de pacotes de controle na rede, ou passivas, em que são apenas observados os pacotes que trafegam pela rede. A seguir serão descritas as principais métricas de desempenho utilizadas no contexto desse projeto, destacando as técnicas de medição ativas. 4.1. Atraso As métricas relacionadas ao atraso em redes estimam o tempo que leva para um pacote sair de sua origem e chegar ao seu destino. No entanto, diversos problemas devem ser considerados para se estimar esse parâmetro, como falta de sincronia e diferentes taxas de crescimento dos relógios do transmissor e receptor. O atraso pode ser definido de duas formas: Atraso em um sentido: é o tempo que um pacote leva do emissor ao receptor. Esta métrica possui vários problemas para ser estimada devido às diferenças dos relógios do transmissor e receptor. O problema pode ser solucionado se forem usados equipamentos ou ferramentas de sincronização dos relógios como o NTP. Ferramenta utilizada para medição do atraso em um sentido: OWAMP. Atraso de ida e volta: é o tempo que um pacote leva para ser enviado a um receptor e devolvido ao emissor (Round Trip Time). Neste caso, sem o problema de sincronia dos relógios, o parâmetro fica muito mais simples de ser obtido. Algumas considerações devem ser feitas, como por exemplo, a precisão mínima de leitura do relógio no sistema operacional. A causa do atraso sofrido pelos pacotes na ida pode ser completamente diferente do atraso sofrido na volta, assim, a existência desta diferença não pode ser considerada. Ferramentas, como PING, estão disponíveis para estimar esta métrica. 8
4.2. Variação de Atraso (Jitter) A variação de atraso ou Jitter é definida para pares consecutivos de pacotes, assim a medição de um único Jitter requer dois pacotes, sendo a diferença do atraso de um pacote com o atraso do seu anterior. Diferente do atraso em um sentido, se os instantes de envio forem conhecidos ou o intervalo entre eles for constante, essa métrica não possui problemas para ser estimada entre máquinas com relógios não sincronizados. O Jitter é percebido, por exemplo, quando fluxos de voz ou vídeo são transmitidos em uma rede e os pacotes não chegam ao seu destino dentro da ordem sucessiva, ou seja, eles variam em termos de tempo de atraso. Esta distorção é particularmente prejudicial ao tráfego multimídia, fazendo com que o sinal de áudio ou vídeo tenha uma qualidade distorcida ou fragmentada na recepção. Ferramentas utilizadas: PING, OWAMP. 4.3. Perda de Pacotes Muitas das aplicações de rede estão suscetíveis à perda de pacotes, por isso o motivo do estudo dessa métrica. Boa parte delas pode ser recuperada via retransmissão dos pacotes, porém aplicações como as de transmissão de vídeo e voz em tempo real não permitem que haja retransmissão, tornando-as particularmente sensíveis a perdas. Portanto, é importante conhecer as características de perda e estudar o desempenho dos algoritmos de recuperação de pacotes. Dependendo do processo de perda presente na rede, mecanismos como a redução na qualidade do vídeo e a utilização de algoritmos de recuperação de perdas, podem ser aplicados para melhorar a qualidade do serviço. O percentual de perda de pacotes na rede pode ser estimado com base no número total de pacotes perdidos dividido pelo total de pacotes enviados. Ferramentas utilizadas: PING, OWAMP e NDT. 4.4. Largura de Banda Largura de banda é uma medida de capacidade de transmissão de dados, normalmente expressa em kilobits por segundo (Kbps), megabits por segundo (Mbps) ou 9
gigabit por segundo (Gbps). A largura de banda indica a capacidade máxima de transmissão teórica de uma conexão. Entretanto, na medida em que a taxa de transmissão utilizada se aproxima da largura de banda teórica máxima, fatores negativos como atraso na transmissão das informações podem causar deterioração na qualidade. A largura de banda de uma rede pode ser vista como um tubo que transfere dados. Quanto maior o diâmetro do tubo mais dados podem ser enviados através dele simultaneamente. Ferramenta utilizada para medição da largura de banda: IPERF e BWCTL. 4.5. Vazão (Throughput) A vazão é o montante de tráfego de dados movidos de um nó da rede para outro em um determinado período de tempo, ou seja, é a quantidade de dados transferidos de um lugar a outro, ou a quantidade de dados processados em um determinado espaço de tempo. Tendo como unidades básicas de medidas o Kbps, o Mbps e o Gbps. O throughput pode ser traduzido como a taxa de transferência efetiva de um sistema. A taxa de transferência efetiva de um determinado sistema pode ser menor que a taxa de entrada ou da largura de banda devido às perdas e atrasos no sistema. Ferramentas utilizadas: NDT. 10
5. INFRA-ESTRUTURA DE MONITORAÇÃO ATIVA A infra-estrutura proposta será baseada na arquitetura de monitoramento perfsonar (PERFormance Service Oriented Network monitoring ARchitecture). O perfsonar é uma infra-estrutura para o monitoramento de desempenho em redes de computadores que pode operar em ambientes multi-domínio, tornando mais fácil identificar problemas fim-a-fim que podem acontecer quando existem diferentes domínios de redes envolvidos. É uma ferramenta desenvolvida em parceria de várias organizações como Internet2, Géant2 e RNP. Contém um conjunto de serviços que agem como uma camada intermediária entre as ferramentas de medição e as aplicações de diagnóstico ou de visualização. Ou seja, a infra-estrutura do perfsonar trabalha em três camadas: a camada dos pontos de medição, a camada de serviços e a camada de interface com o usuário. Um dos serviços que utilizaremos é o Ponto de Medição de Linha de Comando (Command Line Measurement Point - CLMP), responsável por realizar os testes de medição através dos pontos de medição por requisição da ferramenta de monitoramento. A ferramenta de monitoramento utilizada nesse processo é o CactiSONAR, que é nada mais que um plugin do Cacti adaptado com as funcionalidades do perfsonar. Assim, o CactiSONAR permite se ter um controle de monitoramento fim-a-fim utilizando o contexto do perfsonar. Implantação da infra-estrutura A implantação da infra-estrutura de monitoração ativa consistirá em duas etapas principais: a implantação dos pontos de medição nas unidades selecionadas e a implantação da infra-estrutura central de controle e visualização das medições. Serão três os tipos de pontos de medição o MP1, MP2 e MP3. O MP1 será responsável pela medição da vazão e envolverá a utilização do CLMP e do BWCTL. O MP2 será responsável pela medição do atraso unidirecional de alta precisão, pela medição do atraso bidirecional e pela realização de testes de TRACEROUTE. O MP2 11
utilizará o CLMP e as ferramentas OWAMP, PING e TRACEROUTE. O MP1 e MP2 são compatíveis com o ambiente perfsonar. O MP3 será responsável pela realização de testes sob demanda. Ele possibilita ao usuário final avaliar o desempenho de sua conexão e diagnosticar eventuais problemas no caminho entre sua estação de trabalho e o local onde se encontra o MP3. Este ponto de medição será implementado através da ferramenta NDT. O sistema central de controle é composto por um ambiente responsável por agendar testes periódicos e disponibilizar os resultados das medições. O ambiente utilizado para isso é o CactiSONAR. A figura abaixo mostra como ficará essa estrutura: FIGURA 1: Infra-estrutura de monitoração ativa proposta Como vimos, o PoP-PI apresentará os três pontos de medição (MP1, MP2 e MP3) e as instituições ligadas ao PoP-PI apenas dois (MP1 e MP2). Um servidor CactiSONAR conectado ao PoP-PI seria responsável por agendar e requisitar as medições realizadas entre o PoP-PI e as instituições. Assim, o sistema funcionará de forma que o servidor CactiSONAR emite as requisições agendadas aos pontos de medição e o CLMP de cada ponto de medição recebe essas requisições e realiza as medições solicitadas, retornando por fim, o resultado ao CactiSONAR e mostrado-o através de gráficos. 12
6. PONTOS DE MEDIÇÃO A seguir mostraremos as ferramentas utilizadas pelos pontos de medição destacando as funcionalidades de cada uma dentro do sistema proposto. Ferramenta de sincronismo dos relógios: o NTP Ferramentas encarregadas de realizarem os testes de medição: o PING o TRACEROUTE o OWAMP o IPERF o BWCTL Ferramenta encarregada de executar as ferramentas de testes de medição através das requisições recebidas do CactiSONAR e retornar os resultados: o CLMP 6.1. NTP O NTP é uma ferramenta que permite a sincronização dos relógios dos computadores e outros equipamentos de rede a partir de uma referência padrão de tempo aceita mundialmente, conhecida como UTC (Universal Time Coordinated). A extensão do alcance da Internet torna essa sincronização do tempo crucial para a troca de informações entre milhares de computadores que operam 24 horas por dia. A utilização do NTP é muito vantajosa, pois possibilita a sincronização automática de todos os equipamentos conectados em rede. Ou seja, o administrador não precisa ir de máquina em máquina acertando o relógio local. Além disso, a questão da segurança é reforçada com a adoção da sincronização dos relógios dos equipamentos em rede, pois a investigação de eventos de ataques em computadores depende da verificação de logs em diversos equipamentos. A inconsistência dos horários registrados inviabiliza esse trabalho. O NTP implementa um modelo de sincronização hierárquico distribuído. No topo encontram-se os servidores de tempo stratum 1, computadores conectados diretamente a 13
dispositivos conhecidos como "relógios de referência" (ou servidores stratum 0), de altíssima precisão. Estes dispositivos podem ser relógios atômicos, receptores GPS (Global Positioning Systems) ou receptores de rádio. Qualquer servidor NTP que tenha como referência de tempo um servidor stratum 1 passa a ser um stratum 2, e que tenha como referência a um servidor stratum 2 passa a ser um stratum 3, e assim por diante. A instalação do NTP pode ser vista no anexo Instalação e Configuração das Ferramentas dos Pontos de Medição. Depois de executado o ntpd (processo daemon do NTP), o servidor irá demorar alguns minutos para ser sincronizado. Com o comando ntpq -p é possível monitorar o processo de sincronização dos servidores, realizando consultas do estado dos mesmos. FIGURA 2: Teste com NTP Como vimos o teste acima mostra os cinco servidores configurados indicando para cada um o nível (stratum) e o atraso. Agora, com o comando ntptime é possível verificar se a sincronização está OK ou não. FIGURA 3: Testando sincronização com ntptime. 6.2. PING PING (Packet INternet Groper) é uma aplicação utilizada em redes de computadores que provê um teste básico de comunicação, para verificar se determinado equipamento na rede está funcionando ou se está acessível na mesma. Seu 14
funcionamento é similar ao de um sonar de submarino onde ele envia sinais e ouve as respostas. O nome para essa aplicação vem do famoso jogo de ping-pong onde, fazendo um paradoxo, o ping é o envio de pacotes e a resposta ou eco dos mesmos seria o pong. A aplicação PING, envia pacote via ICMP (echo request) para o equipamento de destino e recebe a resposta ICMP (echo reply) contendo os seguintes dados listados abaixo e mostrados na imagem que se segue: Atraso de ida e volta (em Milisegundos); Exibe a quantidade de pacotes respondidos pelo destino; Informa o tamanho dos pacotes enviados (em Bytes); Mostra ainda uma estatística da comunicação média informando, o menor e o maior tempo de resposta e ainda a média do tempo de resposta. FIGURA 4: Teste com a ferramenta PING. A ferramenta PING já vem, instalada e configurada em qualquer ambiente Linux e Windows. Para testá-la, basta digitar o comando PING seguido do endereço de destino. Esse comando é utilizado para verificar o tempo de resposta do destino, permissão de acessibilidade e integridade na troca de pacotes. Dependendo das características da resposta ele pode exibir diversas informações auxiliando no diagnóstico de problemas no trafego de dados entre um equipamento e outro. Outra ferramenta que utiliza o ICMP de maneira semelhante ao PING é o TRACEROUTE. 15
6.3. TRACEROUTE O TRACEROUTE tem como função descobrir e exibir o caminho realizado pelos pacotes desde seu envio até sua chegada no destino. Nesse caminho são mostrados os endereços de todos os roteadores por onde passaram os pacotes informando o tempo de resposta de cada um. O TRACEROUTE pode ajudar na descoberta de falhas, como por exemplo, gateways intermediários que descartam pacotes ou rotas que excedem a capacidade do datagrama IP. Usando essa ferramenta pode-se saber qual o tempo necessário para um pacote percorrer todos os gateways até chegar do outro lado e assim ter um controle sobre esse atraso na transmissão dos dados. Ou ainda, saber em qual ponto o pacote parou na rede. FIGURA 5: Teste com a ferramenta TRACEROUTE. A ferramenta TRACEROUTE já vem, instalada e configurada em qualquer ambiente Linux. Para testá-la, basta digitar o comando TRACEROUTE seguido do endereço de destino. No Windows ela é usada com o comando TRACERT. O TRACEROUTE funciona enviando 3 pacotes com o campo Time To Live (TTL) configurado para 1. O primeiro roteador (primeiro hop) envia então um pacote (ICMP) indicando que o pacote não pode ser transmitido para a origem porque o TTL expirou. Após receber a indicação de erro, um outro pacote é enviado com o TTL configurado para 2 e o segundo roteador (segundo hop) neste momento responderá para a origem que o TTL expirou. Esse processo continua até que se alcance o destino ou um limite prédeterminado. 16
A resposta do TRACEROUTE mostra três tempos, isso é porque quando um roteador é encontrado o mesmo é testado três vezes. Já quando aparece como resposta * * * significa que esse roteador não respondeu que o TTL expirou. Com o TRACEROUTE conseguimos somente o caminho de ida até o destino, não sendo possível obter o caminho de retorno que pode ser diferente. 6.4. OWAMP 6.4.1. Definição O OWAMP é um exemplo de implementação do Protocolo de Medição Ativa em um sentido (One-Way Active Measurement Protocol) sendo criado por um grupo da Internet2 submetido ao GT IPPM do IETF, a fim de determinar métricas de latência e atraso. A principal motivação para o desenvolvimento OWAMP foi encontrar problemas na rede, como o congestionamento que acontece geralmente em uma direção, routeamentos assimétricos e enfileiramento de pacotes. Existem outras implementações de atraso em um sentido (Surveyor, Madura, etc.), mas o maior obstáculo para elas tem sido a interoperabilidade, devido à inconformidade com as normas aceitas. A natureza de código-fonte aberto do OWAMP torna possível que métricas unidirecionais se tornem tão comum, como métricas de ida e volta (como a ferramentas PING). É suportado para Linux e FreeBSD. Os congestionamentos, por exemplo, normalmente só ocorre em uma direção de um caminho de rede, por isso, métricas unidirecionais é a forma mais simples de isolar estes efeitos. Medições ativas, tais como medições de atraso em um sentido, pacotes perdidos em um sentido e variação de atraso em um sentido são, sem dúvida, uma das melhores maneiras de determinar se uma determinada aplicação está funcionando bem ou não. 6.4.2. Características O OWAMP é uma ferramenta cliente/servidor e funciona por dois protocolos, o protocolo de controle, implementado através da aplicação daemon owampd, e o protocolo de teste, implementado através da aplicação cliente owping. 17
O owampd possui as seguintes características: Implementado em TCP. Utiliza a porta 861. Responsável pela execução dos testes recebidos. Suporta autenticação e autorização. Utilizado para configurar os testes, permitindo alterar tamanho dos pacotes, porta utilizada, agendar envios, etc. Utilizado para iniciar e parar os testes. O cliente owping possui as seguintes características: Implementado em UDP. Responsável por requisitar a execução dos testes. Pode tanto receber quanto enviar testes. Utiliza portas aleatórias maiores que 1024 para executar os testes. As sessões de testes podem ser abertas, autenticados ou criptografadas. 6.4.3. Visão Geral O OWAMP funciona de forma que o cliente owping requisita testes ao servidor owampd, podendo este aceitar ou negar a requisição dos testes. Sendo aceita, os testes são executados e retornados os resultados ao cliente. Cada conexão cliente/servidor é classificada (autenticação) e cada classificação está associada com um conjunto de limites hierárquicos que são usados para tomar decisões políticas (autorização): Largura de Banda (bandwidth) Buffer de sessão (disk) Retenção dos dados (delete_on_fetch) Política de conexão (allow_open_mode) Um requisito importante para o funcionamento do OWAMP é uma boa configuração do NTP. Assim, é preciso que os relógios do cliente e do servidor OWAMP estejam sincronizados para que a ferramenta funcione corretamente, recomendando utilizar de servidores stratum 1 com fontes externas para melhor precisão das medidas. 18
Outro requisito importante e que se aplica as demais ferramentas, é a questão do firewall, pois as portas necessitam estar abertas para controle de comunicação e testes de tráfego. A figura abaixo mostra um exemplo de teste com o OWAMP. FIGURA 6: Teste com OWAMP usando o comando owping em localhost. anexo. A instalação e configuração do OWAMP no Linux serão mostradas na sessão em 6.5. IPERF O IPERF é uma ferramenta de análise de desempenho de banda e perda de pacotes na rede. É um software cliente/servidor adequado para medições ativas. Além das medições, esse software pode ser usado com um gerador simples de carga na rede, quando não há preocupação com o perfil do tráfego que está sendo gerado. Também com IPERF é possível medir o Jitter (variação do atraso) e a perda. O IPERF é capaz de usar tanto o protocolo UDP, quanto TCP e pode lidar com múltiplas conexões simultâneas. Neste caso usando UDP irá retornar perdas de pacotes e Jitter, e usando TCP irá retornar largura de banda. 19
A instalação da ferramenta no Linux (Debian) é simples, basta instalar sem precisar configurar, através do comando apt-get install iperf. Um teste básico com a ferramenta é utilizando o parâmetro -s para o servidor e para o cliente o parâmetro -c seguido do IP do servidor. O resultado mostrado será a vazão obtida para a quantidade de bytes enviados em certo tempo. Veja a figura abaixo: FIGURA 7: IPERF como servidor FIGURA 8: IPERF como cliente 6.6. BWCTL 6.6.1. Definição O BWCTL ou Bandwith Test Controller é uma ferramenta usada para verificar a largura de banda disponível de um local para o outro. Atualmente, o IPERF é uma das ferramentas mais usadas para estes tipos de testes de taxa de transferência, por isso, o grande objetivo do BWCTL é criar um daemon para alocação de recurso e escalonamento, a fim de controlar do testes realizados com o IPERF. A abordagem adotada pelo BWCTL é verificar a vazão entre cada ponto no caminho para determinar o foco do problema. Esta é, sem dúvida, uma das melhores maneiras para determinar se um aplicativo está funcionando da forma como deveria funcionar. Uma solução típica para esses tipos de testes, antes do desenvolvimento do BWCTL, era executar o IPERF ou ferramenta similar nos dois hosts finais e nos caminhos intermediários. Mas para isso, era necessário estabelecer algumas permissões em todos os sistemas envolvidos e sincronizar os testes com os outros participantes. 20
Com isso o BWCTL foi desenvolvido para ajudar nesses casos, permitindo o escalonamento de testes, automaticamente, sem se preocupar com testes sendo executados um em cima dos outros, desviando os resultados. 6.6.2. Características O BWCTL é uma ferramenta cliente/servidor e funciona através de duas aplicações, o daemon bwctld e o cliente bwctl. A aplicação cliente bwctl, requisita os testes para as duas extremidades envolvidas. Estes pedidos incluem duração do teste e outros parâmetros, podendo a comunicação ser aberta, autenticada ou criptografada. O BWCTL permite que os pedidos de terceiros possam ser realizados entre dois servidores independentes e remotos utilizando autenticação exclusiva de cada lado. Além de oferecer as mesmas opções de linha de comando do IPERF. Isso facilita ainda mais o manuseio da ferramenta e, consequentemente, facilita a realização dos testes. A aplicação daemon bwctld, é onde a política de testes é implementada. O bwctld é um tradicional processo daemon com o processo pai escutando os pedidos dos processos filhos. Em cada host de realização dos testes, o bwctld: Aceita requisição do IPERF incluindo os parâmetros e duração do teste. Responde com tentativa de reserva de um teste ou uma mensagem de negação. A reserva de um teste é confirmada com uma mensagem de start session. Protege os recursos Executa os testes Retorna os resultados do teste para ambos os lados. 6.6.3. Visão Geral Os servidores envolvidos no testes alocam uma janela de tempo para que os testes sejam executados, com isso é garantido que não será executado nenhum teste paralelo nos pontos envolvidos, garantindo assim um melhor resultado para os testes. 21
Cada conexão cliente/servidor é classificada (autenticação) e cada classificação está associada com um conjunto de limites hierárquicos que são usados para tomar decisões políticas (autorização): Política de conexão (allow_open_mode) Largura de banda (allow_tcp,allow_udp,bandwidth) Agendamento (Duração,event_horizon,pending) A figura abaixo mostra um exemplo de teste com o BWCTL. FIGURA 9: BWCTL servidor FIGURA 10: BWCTL cliente Um requisito importante para o funcionamento do BWCTL é uma boa configuração do NTP. Assim, é preciso que os relógios do cliente e do servidor BWCTL estejam sincronizados para que a ferramenta funcione corretamente, recomendando utilizar de servidores stratum 1 com fontes externas para melhor precisão das medidas. 22
Outro requisito importante e que se aplica as demais ferramentas, é a questão do firewall, pois as portas necessitam estar abertas para controle de comunicação e testes de tráfego. A instalação e configuração do BWCTL no Linux serão mostradas na sessão de anexo. 6.7. CLMP O Ponto de Medição de Linha de Comando ou CLMP (Command Line Measurement Point) é um serviço web do perfsonar para solicitação por demanda ou medições agendadas usando ferramentas comuns de medição de rede através de linha de comando tais como PING, TRACEROUTE, OWAMP e BWCTL. A Figura a seguir mostra como esse serviço é acoplado ao sistema e de que forma ele deverá funcionar. FIGURA 11: Arquitetura do Sistema CLMP. Quando os usuários solicitar informações de medição para o cliente CactiSONAR, o cliente envia uma solicitação XML para o CLMP. O CLMP então obtém as informações solicitadas através das ferramentas de medição (PING, TRACEROUTE, OWAMP e BWCTL) encapsulando e retornando os dados solicitados para o cliente em uma resposta XML. 23
O serviço perfsonar, CLMP, é configurado através de uma interface web de administração (Web Admin) que está incluído na instalação CLMP. A interface Web Admin armazena as configurações em arquivos, de onde são aplicados ao CLMP. A instalação do CLMP requer alguns pré-requisitos de softwares para que ela funcione perfeitamente, como a máquina virtual Java instalada, o Tomcat para acesso a interface Web Admin, e as ferramentas de medição PING, TRACEROUTE, OWAMP e BWCTL. A instalação e configuração detalhada serão mostradas no anexo. 24
7. NETWORK DIAGNOSTIC TOOL (NDT) O Network Diagnostic Tool (NDT) é um programa cliente/servidor que provê ao usuário um teste de configuração e desempenho da rede. O aplicativo mede a vazão através do uso do protocolo TCP nas duas direções: do cliente para o servidor e do servidor para o cliente. Um kernel do Linux modificado com um patch web100, é responsável por desempenhar funções de diagnóstico. Os dados do fluxo TCP são capturados e analisados para determinar o motivo da vazão alcançada. Vários estudos têm mostrado que a maioria dos problemas de desempenho de rede ocorre dentro ou perto dos usuários, mas pode haver também problemas nas condições dos links, ou com a infra-estrutura de rede local. Pesando nisso o NDT foi designado para identificar facilmente e rapidamente um conjunto específico de condições que determinam o desempenho da rede. O sistema é composto por vários componentes, um programa cliente e um par de programas servidores. Os processos servidores incluem um servidor web básico (fakewww) para lidar com as solicitações recebidas do cliente, e um segundo processo (web100srv) que realiza os testes específicos necessários para determinar quais os problemas, se algum existir, analisa e retorna os resultados para o cliente. O cliente pode acessar o servidor através de duas formas: tanto com linha de comando (web100clt) como através de uma página web. O cliente de linha de comando deve ser instalado manualmente na máquina em que for realizado o teste, enquanto que o cliente através da página web utiliza um applet Java para automatizar o processo de teste. Este applet Java é baixado automaticamente quando o servidor web é acessado. Isso permite que administradores de sistema possam facilmente realizar testes de rede sem que haja a instalação prévia, bastando apenas ter a máquina virtual Java instalada. 7.1. Características: Um simples servidor web elimina a necessidade de um servidor mais completo. Medições de throughput são relatadas em ambos os sentidos. Dados do web100 são extraídos para analise dos resultados. Um applet Java utilizado pela web permite testar a partir de qualquer cliente. 25
Uma ferramenta através de linha de comando permite testar a partir de locais remotos. Resultados multiníveis podem ser adaptados para usuários mais experientes. Requisitos do Sistema: o Sistema Operacional Linux o Patch web100 o Biblioteca web100-userland o Biblioteca libpcap O processo servidor do NDT exige um kernel Linux compilado com um patch web100 para reunir as informações necessárias para analisar os testes. Os processos cliente, tanto de linha de comando quanto o applet Java, podem operar em qualquer sistema Linux ou Windows. O que ele pode fazer: o Identificar se o cliente, servidor ou a rede estão operando conforme esperado. o Fornecer informações para ajuste da aplicação. o Sugerir mudanças para melhorar o desempenho. o Dizer ao usuário final que tem algo errado mesmo quando o administrador da rede diz que está tudo normal, podendo o problema ser na máquina ou aplicação. o Detectar o gargalo do link. o Detectar erros de negociação em modo duplex. o Detectar falhas de hardware, através de perdas ocorridas sem congestionamento. o Detectar o modo Duplex (Full/Half) em uma conexão. o Detectar as condições normais de congestionamento. O que ele não pode fazer: o Dizer exatamente onde está o problema na rede. o Dizer como os outros servidores estão operando. o Dizer como os outros clientes estão operando. Instalação do NDT: em anexo. 26
7.2. Servidor Os processos web100srv e fakewww iniciados após a instalação do NDT, não passam de simples programas, que são executados para o funcionamento do NDT. A seguir falaremos de cada um deles. 7.2.1. O processo fakewww O programa fakewww é na verdade um simples servidor web, responsável por controlar as solicitações recebidas do cliente. Isso elimina a necessidade de se instalar e configurar um servidor web mais complexo. Com ele é possível o cliente realizar os testes usando uma simples página web através da internet. Por padrão, o fakewww escuta na porta 7123, mas esta pode ser alterada. O servidor fakewww só responde ao comando HTTP GET. Todos os outros comandos exigem que a conexão seja fechada e uma mensagem de erro é registrada. Por isso, o servidor inclui uma lista de html, classes java ou arquivos.jar que podem ser retornados ao cliente. Veja algumas opções de configuração do servidor fakewww: -d : imprime informações de depuração. -h : imprime uma página de ajuda. -F : opera em modo de espera. -l arquivo_de_log : cria um arquivo de log e registra o cliente em atividade. -p número_da_porta : especifica uma porta TCP diferente para ouvir os pedidos dos clientes. Agora veja exemplos de como se executar o processo fakewww alterando suas configurações: # fakewww -l /var/log/fakewww.log : roda o servidor na porta 7123 e registra os resultados no arquivo de log /var/log/fakewww.log. # fakewww p 80 : roda o servidor na porta padrão 80. 27
7.2.2. O processo web100srv O processo web100srv representa o programa servidor do NDT. Este foi desenvolvido baseado no serviço web100, responsável por desempenhar as funções de diagnóstico. O servidor web100srv realiza testes e análises, podendo trocar dados com o cliente tanto através de linha de comando como através de um applet Java. Vários testes específicos são conduzidos com o objetivo de identificar e conhecer os problemas de configuração que afetam negativamente o desempenho da rede, tornando o NDT uma eficaz ferramenta de diagnóstico. Um programa cliente conecta ao servidor abrindo um canal com a porta TCP 3001. Este canal é mantido durante toda a vida do teste permitindo a troca dos resultados. O servidor aceita o pedido de conexão e cria um processo filho específico, podendo assim voltar a escutar novos pedidos. Uma vez que um pedido de teste seja aceito, o servidor retorna um par de portas TCP que o cliente deve usar para novos testes. O processo servidor faz uma abertura passiva destas portas através do comando listen. O cliente realiza uma abertura ativa, através do comando connect, para que possa funcionar, mesmo quando localizados atrás de um NAT ou Firewall. Por padrão, o servidor usa as portas TCP 3002 e 3003 para testar este serviço. Começa os testes com o cliente abrindo uma conexão na porta 3003. O servidor grava e retorna o tamanho máximo de segmento TCP. A conexão é fechada e o cliente grava os resultados para serem exibidos. Em seguida, o cliente abre uma conexão na porta 3002. Dados são enviados do cliente para o servidor durante 10 segundos e o resultado é uma medição da vazão (throughput) alcançada do cliente para o servidor (upload), utilizando a biblioteca libpcap. Estes resultados são depois quantizados e enviados para análise. Agora o cliente abre uma conexão na porta 3003 e envia dados do servidor para o cliente durante 10 segundos, resultando em uma medição da vazão alcançada na direção de download. Depois que o teste termina, o servidor recupera do núcleo web100 um conjunto de variáveis e contadores usados pelo motor de análise para determinar as condições de falhas ocorridas. 28
Por fim os dados coletados são analisados. Os resultados desta análise é dizer o gargalo do link no caminho fim-a-fim, detectar sinais de desacordo duplex, cabos defeitos que causam perdas de pacotes, sinais de congestionamento e de operação full/half duplex. Isso tudo ajudar a identificar quando existem problemas, e quando a rede está operando corretamente. Veja algumas opções de configuração do servidor web100srv: -a : gera uma página de administração. -d : imprime informações de depuração. -h : imprime uma página de ajuda. -m : seleciona o modo simples ou multi-teste. -q : desativa o enfileiramento FIFO das requisições que chegam do cliente. -l arquivo_de_log : cria um arquivo de log e registra o resultado dos teste. -p número_da_porta : especifica uma porta TCP diferente da padrão 3001 para ouvir os pedidos dos clientes. -4 : utiliza ipv4. -6 : utiliza ipv6. Agora veja exemplos de configuração do processo web100srv: # web100srv -a >& /dev/null & : inicia o servidor com o administrador habilitado. # web100srv -ddd : inicia o servidor em primeiro plano e habilita 3 níveis de mensagens de depuração. 7.3. Cliente Existem duas formas de se usar a ferramenta: através de linha de comando com o programa cliente web100clt e através de um applet Java que será acessado por uma página web. 7.3.1. Linha de Comando O cliente de linha de comando web100clt conecta diretamente ao web100srv do NDT para realização de testes de caminhos de rede e configuração da rede. Os 29
resultados são analisados e uma série de mensagens de diagnóstico é retornada ao cliente e exibida no console do usuário. Por ser usado através de linha de comando este programa cliente deverá estar instalado na máquina para que funcione, podendo rodar tanto em ambiente Linux como no Windows (utilizando o cygwin). O cliente pode compartilhar um servidor com outros clientes, de forma que os pedidos serão tratados em forma de fila FIFO. Mas esse enfileiramento pode perfeitamente ser desativado pelo administrador do servidor NDT, fazendo com que o cliente encerre automaticamente caso haja outro cliente sendo processado. Veja algumas opções de configuração do cliente web100clt: -d : imprime informações de depuração. -h : imprime uma página de ajuda. -l : incrementa o nível da mensagem de diagnóstico. -b tamanho_do_buffer : define o tamanho do buffer TCP de envio e recebimento. -n endereço : especifica o endereço a ser realizado o teste. -4 : utiliza ipv4. -6 : utiliza ipv6. Agora veja exemplos de utilização do cliente web100clt: # web100clt -4 n host.exemplo.com : executa um teste NDT entre o host local e o host remoto host.exemplo.com utilizando ipv4. FIGURA 12: Teste local com o cliente web100clt. 30
7.3.2. Applet Java Este applet é na verdade um programa feito em Java com funcionalidades parecidas do cliente através de linha de comando, mas com uma interface bem mais amigável. Ou seja, o applet é responsável pela realização de testes do desempenho e configuração da rede. Ele é acessado através da página web criada durante a instalação. Na página irá conter algumas informações básicas do servidor NDT e o applet Java que será carregado automaticamente, mas para isso você precisará ter o Java instalado em sua máquina. Veja uma imagem do applet carregado na página: FIGURA 13: Teste remoto através do applet Java. Para iniciar o teste, basta clicar no botão START. Isso fará com que o cliente se comunique com o servidor web100srv e realize os testes necessários para obtenção do melhor diagnóstico possível da rede. Depois que o teste é completo, a tela principal do applet mostra resultados básicos de ida e volta da vazão (throughput), bem como o limite que o link pode suportar, variando do tipo dial-up até 10 Gbps. Os botões Estatistics, More Details e Report Problem também são ativados. Quando clicamos no botão Estatistics são mostrados resultados dos vários testes realizados pelo NDT, são eles: Informações sobre o SO e o Java da máquina cliente. Detalhes de desempenho, incluindo atraso de ida e volta, tamanho do pacote e estatísticas de perda dos pacotes. Porcentagem de tempo que o servidor irá enviar e receber buffer limitado. 31
Opções do protocolo TCP que foram negociadas entre o cliente e o servidor, como Sack, Nagle, REC, Time Stamping e Window Scaling. Teste de middlebox, detecção de firewall ou NAT. Informações do tamanho do link encontrado, do tipo de conexão, da operação em modo Full Duplex, da ocorrência de congestionamento de rede, das condições do cabo de rede e da ocorrência de erros. No botão More Details serão mostradas as seguintes informações: Lista de variáveis do web100, juntamente com o valor de cada uma, calculada pelo servidor. Valor do limite de rede teórico. Tamanho do buffer de envio e recebimento que limita a vazão. Uma outra opção de visualização dos resultados de testes obtidos pelo servidor é através da página admin.html. Nela poderão ser encontradas estatísticas de uso do NDT, bem como resultados do teste corrente. Vejamos nas imagens abaixo uma tabela e um gráfico que podem ser encontrados nesta página: FIGURA 14: Tabela com estatísticas de uso do NDT e resultados do teste corrente. FIGURA 15: Gráfico do percentual de ocorrência de cada tipo de link encontrado. 32
Como vimos, a tabela mostra ao administrador como foi o desempenho do último teste realizado pelo cliente NDT, tendo acesso às informações básicas como data e hora do último teste, total de testes realizados, o gargalo e o limite teórico do link, a vazão entre cliente-servidor e servidor-cliente, pacotes perdidos, o RTT médio e mínimo, percentual de pacotes fora de ordem, tamanho dos buffers de envio e recebimento, entre outras. Quanto ao gráfico, ele nos mostra o percentual de vezes que os tipos de link foram encontrados em todos os testes realizados pelo NDT. 33
8. CACTISONAR O perfsonar é uma arquitetura orientada a serviços projetada para coletar, armazenar e apresentar resultados de medições de desempenho. Um conjunto definido de serviços é responsável pelas medições e tarefas administrativas. Com isso, CactiSONAR, é a implementação dos vários serviços perfsonar como componentes da ferramenta de monitoração CACTI. Ou seja, o CactiSONAR é nada mais que um plugin do CACTI que permite o controle de medições fim-a-fim em Pontos de Medições (MP) do perfsonar. 8.1. O CACTI O ambiente do CACTI é interessante pelo seu potencial de visualização, pois é conhecido como uma solução para se criar gráficos relacionados à rede utilizando-se da tecnologia RRDTool. O CactiSONAR permite aos usuários do CACTI aumentar suas possibilidades de gerenciamento de uma maneira fácil através da inclusão de novas métricas fim-a-fim obtidas a partir de serviços do perfsonar, tornando-se uma ferramenta útil para solucionar problemas de desempenho de rede. A coleta de dados no CACTI pode ser realizada através do SNMP ou scripts externos. A forma de integração de scripts é usada pelo CactiSONAR para interagir com os serviços de MP do perfsonar. O CactiSONAR permite a definição de testes que são agendados e executados por um grupo de MPs do perfsonar. Permite também, aos administradores observarem os dados coletados ao longo do tempo, possibilitando a agregação e a composição dessas métricas de forma personalizada, e realizando análises conforme a necessidade do usuário. 8.2. Funcionalidades do CactiSONAR 8.2.1. Cadastro e Monitoramento de Serviços perfsonar Para que um serviço perfsonar seja utilizado no CactiSONAR, a primeira ação a ser realizada é inserir ele ao ambiente. Para isso devem ser inseridas informações do ponto de acesso ao MP e o tipo serviço utilizado. 34
FIGURA 16: Criação de serviço perfsonar. Uma vez inseridos os serviços, quando realizando algum tipo de teste, são monitorados pelo CactiSONAR. Com os MPs cadastrados ao ambiente, o CactiSONAR permite o agrupamento de serviços comuns, podendo executar determinadas ações sobre o mesmo grupo. 8.2.2. Modelos de Testes e Matrizes de Testes Outra funcionalidade importante do CactiSONAR é a possibilidade da criação de modelos de teste, que são definições de valores padrões para os parâmetros de determinada ferramenta e que são passados nas execuções dos testes através das matrizes de testes. Isso permite que um mesmo tipo de teste seja aplicado a mais de um MP, facilitando o processo de criação dos testes. FIGURA 17: Criação de Modelos de Teste. Na Figura abaixo mostra que o usuário pode escolher entre quais Pontos de Medição os testes serão realizados, sendo que as linhas representam a origem e as 35
colunas representam os destinos. Criada a matriz, os testes serão acionados pelo CactiSONAR nos MPs correspondentes. FIGURA 18: Criação da Matriz de Testes. 8.2.3. Gráficos do CactiSONAR FIGURA 19: Exemplos de Gráficos inseridos pelo CactiSONAR. A Figura acima mostra exemplos de gráficos inseridos pelo CactiSONAR. Esses gráficos foram criados a partir de dados coletados usando o serviço CLMP do perfsonar. O gráfico (a), por exemplo, apresenta a variação de atraso em um sentido medida usando a ferramenta OWAMP. O gráfico (b) apresenta o atraso de ida e volta calculado pela ferramenta PING. O gráfico (c) apresenta a largura de banda alcançável 36
em UDP medida usando dois Pontos de Medição. E finalmente, o gráfico (d) que apresenta um gráfico que usa o atraso, a variação do atraso e as perdas medidos usando o PING para apresentar um indicador de qualidade MOS (Mean Opinion Score), mostrando a capacidade de se correlacionar métricas no CactiSONAR. 8.2.4. RDD-MA Um serviço perfsonar que o CactiSONAR implementa é o RRD-MA. Através desse serviço, permite-se ao administrador expor os dados que são coletados pelo ambiente. O serviço RRD-MA pode ser configurado de acordo com as necessidades dos administradores do ambiente, sendo possível restringir quais os dados que serão publicados pelo serviço. Uma vez medidos os dados, o CactiSONAR permite a exposição desses dados pelo RRD-MA, através da ferramenta perfsonar-ui. 37
9. SIMULAÇÃO DA REDE DO POP-PI O processo de simulação tem por objetivo projetar um modelo do mundo real, e sobre este modelo realizar experimentos com o propósito de entender o comportamento de um sistema e avaliar estratégias para ele. A fim de se obter uma melhor avaliação do desempenho da rede do PoP-PI, foi utilizada uma ferramenta de simulação de redes. Essa ferramenta possibilitou a modelagem da rede, oferecendo uma visão geral da rede e permitindo uma análise real do ambiente computacional em sua totalidade. Possibilitou também a execução da simulação, através de um tráfego gerado para a rede, e com isso, ser possível obter os resultados do comportamento dessa rede para depois serem analisados. 9.1. OPNET A ferramenta utilizada para esse processo de simulação da rede do PoP-PI foi o OPNET IT Guru, uma versão acadêmica do OPNET Modeler. O OPNET é uma ferramenta utilizada para especificação, simulação e análise de desempenho de redes. Ela permite a especificação de um grande número de componentes de comunicação, como roteadores, switchs, servidores, hubs, componentes para redes ethernet, redes sem fio, fibra óptica, dentre outros. Para obtenção da versão gratuita da ferramenta, foi necessário realizar um cadastro simples, que permite fazer o download do simulador e instalá-lo. A instalação foi feita em sistema operacional Windows XP. A modelagem e simulação de redes através do OPNET foram divididas em cinco etapas, de forma a entender melhor esse processo: Definição do Problema: o levantamento de equipamentos e serviços disponíveis na rede é realizado nessa etapa, bem como a definição de quais os problemas serão analisados; Modelagem: a rede e os serviços disponíveis são modelados nessa fase; Simulação: após a modelagem do ambiente é realizada a simulação, que produzirá gráficos com os resultados obtidos. 38
Análise: vários cenários podem ser modelados e simulados nesta fase apenas com a alteração de parâmetros, para por fim os resultados gerados através dos gráficos serem comparados e analisados. Resultados: a partir da análise dos gráficos obtidos nas etapas anteriores as conclusões sobre alterações e melhorarias no ambiente devem ser tomadas nessa etapa. 9.2. Definição do Problema O problema trata-se em analisar a rede do PoP-PI, tentando encontrar falhas que possam acarretar o seu desempenho. Essas falhas serão detectadas utilizando as métricas de desempenho, como atraso, variação de atraso, perda de pacotes, largura de banda e vazão. Foi realizado um levantamento de todos os equipamentos, ligações, tipos de ligações, tamanho dos links e serviços utilizados na rede. A rede do PoP-PI, atualmente, conecta diversas instituições como: FAPEPI (Fundação de Amparo à Pesquisa do Piauí) 10Mbps (Ethernet) UFPI (Universidade Federal do Piauí) 34Mbps (Rádio) UESPI (Universidade Estadual do Piauí) 4Mbps (PPP-E1) CEFET-PI (Centro de Ensino Tecnológico do Piauí) 11Mbps (Rádio) CTT (Centro Tecnológico de Teresina) 11Mbps (Rádio) EMBRAPA 2Mbps (PPP-E1) Hospital São Marcos 512Kbps (Rádio) CEFET - Floriano 128Kbps (PPP) RPP (Rede Piauiense de Pesquisa) 64Kbps e 128Kbps (PPP) Dentre os equipamentos utilizados, destacamos alguns: Roteador de Borda (Juniper) Switch de Distribuição (Foundry) Roteadores IMB 2210 Roteador Cisco 2500. Servidores HP, Firewall 39
Links Ethernet 10BaseT e 100BaseT Fibra Óptica E dentre os serviços e aplicações utilizadas, destacamos alguns: Serviço Web (HTTP) Serviço de Email Serviço de FTP DNS Serviços de Gerência (Nagios, Cacti) Banco de Dados 9.3. Modelagem Com base nos equipamentos e serviços da rede selecionados na fase anterior, apenas aqueles suportados pelo OPNET versão acadêmica foram utilizados para a fase de modelagem. Procurou escolher aqueles mais próximos possíveis dos equipamentos reais da rede do PoP-PI. Inicialmente, foi criado um novo projeto e respectivamente um novo cenário para ele, podendo escolher a dimensão que a rede irá ocupar e os modelos de componentes que serão usados. Veja a tela abaixo: FIGURA 20: Criando um novo projeto no OPNET. 40