Testes do projeto de rede

Teste servem para provar para você mesmo e para seu cliente que o projeto da rede vai satisfazer os objetivos de negócio e técnicos
Embora se possam usar alguns testes prontos "da indústria", é mais frequente realizar testes específicos para o projeto da rede
- Isso envolve construir um protótipo e medir desempenho (vazão a nível de aplicação, atraso e disponibilidade)
- Uma alternativa possível é de usar ferramentas de modelagem
A seleção de procedimentos e ferramentas de testes depende dos objetivos dos testes
Objetivos comuns para os testes:
- Verificar que o projeto satisfaz os objetivos mais importantes de negócio e técnicos
- Validar a seleção de tecnologias e de dispositivos de LAN e de WAN
- Verificar que o provedor de serviço oferece, de fato, os serviços prometidos
- Identificar problemas de conectividade ou de gargalos
- Testar a redundância da rede
- Analisar os efeitos de quedas de enlaces no desempenho
- Determinar técnicas de otimização (multicast, RSVP, ...) que serão necessárias para satisfazer objetivos de desempenho
- Analisar os efeitos de atualizações (upgrades) de enlaces e/ou dispositivos no desempenho (análise "what-if")
- Provar que seu projeto é melhor do que um projeto concorrente (quando o cliente pedir tal comparação)
- Para passar um "teste de aceitação" que permite continuar com o projeto e implantar a rede
- Convencer a gerência e seus colegas que o projeto é eficaz
- Identificar riscos que podem dificultar a implementação e fazer o planejamento de contingências
- Determinar quantos testes adicionais são necessários (ex. pode-se decidir continuar o projeto apenas como piloto para investigar mais)

Testes da indústria

Testes comparativos são executados e publicados por fabricantes, laboratórios independentes e revistas especializadas
- Network Device Testing Laboratory (Harvard University)
- Strategic Network Consulting, INC. (SNCI) - www.snci.com
- Interoperability Lab (IOL) da University of New Hampshire - www.iol.unh.edu
Normalmente testam dispositivos
Os resultados só podem ser usados para o convencimento de que o projeto da rede está ok para redes muito simples, consistindo de uma topologia essencialmente igual à dos testes publicados
- Para redes mais complexas, você deverá elaborar seus próprios testes
- Motivo: deve-se fazer testes de sistema e não apenas testes de componentes

Construção e teste de um protótipo para a rede

Listamos as tarefas necessárias à construção e testes de um protótipo que verifique e demonstre o comportamento de uma rede
Um protótipo é uma implementação inicial de um novo sistema que modela como a rede final será implementada
O protótipo deve ser funcional mas não precisa ser uma implamentação completa da rede

Determinação do escopo do protótipo

Quanto da rede deve ser implementado para convencer o cliente de que o projeto está ok (satisfaz os requisitos)?
Isole os aspectos que são mais importantes
- Funções importantes
- Funções que envolvem risco
  - Onde o projeto foi muito influenciado por restrições do negócio ou técnicas
  - Onde o projeto foi muito influenciado pelos tradeoffs entre objetivos
- Funções que foram alvo de rejeição em projetos anteriores
  - Ex.: o cliente já recusou um projeto no passado devido à sua fraca gerenciabilidade e fraca usabilidade
Os recursos disponíveis (gente, equipamento, dinheiro, tempo) vão também ditar o alcance do protótipo
Um protótipo pode ser implementado e testado de três formas diferentes
- Como rede de testes num laboratório
- Integrado a uma rede de produção mas com realização de testes fora do horário comercial
- Integrado a uma rede de produção e com realização de testes no horário comercial normal
É interessante implementar uma rede de testes em laboratório antes de implementá-la na rede de produção
- Para acertar bugs
- Para avaliar produtos nunca usados antes
- Para acertar a configuração inicial de dispositivos
O teste final deve ser em produção, durante o horário comercial normal
Cuidado com o seguinte ao fazer testes num ambiente de produção:
- Avise os usuários com antecedência sobre os horários de testes para que eles estejam esperando problemas de desempenho, mas peça que eles trabalhem normalmente para não invalidar os testes devido a um comportamento anormal dos usuários
- Avise os administradores da rede com antecedência para que eles também não estejam executando testes ao mesmo tempo!
- Avise os operadores da rede com antecedência para que eles estejam esperando alarmes inesperados na console de gerência e outro comportamento estranho
- Se possível, execute vários testes pequenos (até 2 minutos) para minimizar o impacto nos usuários
- Execute testes leves primeiro e aumente a carga do teste aos poucos, e somente se testes anteriores estiverem ok. Não passe para carga máxima "de cara"
- Monitore os resultados dos testes e pare assim que:
  - Os objetivos dos testes foram alcançados; ou
  - Os testes estão impactando a rede em demasia

Escrevendo um plano de testes para o protótipo

Uma vez que o escopo do protótipo está decidido, um plano de testes é escrito, contendo:
- Objetivos dos testes e critérios de aceitação
- Tipos de testes que serão executados
- Equipamento de rede e outros recursos necessários
- Scripts de teste
- Cronograma do projeto de testes
Elaboramos sobre esses pontos abaixo

Elaboração de objetivos de testes e critérios de aceitação

Listar os objetivos dos testes é o passo mais importante
- Os objetivos devem ser específicos e concretos
- Deve-se incluir critérios de aceitação
Exemplos de objetivos e critérios de aceitação:
- "Medir o tempo de resposta para a aplicação Xpto durante horário de pico (entre 10:00 e 11:00 da manhã). Critério de aceitação: tempo de resposta <= 500 ms"
- "Medir a vazão da aplicação Xpto durante horário de pico (entre 10:00 e 11:00 da manhã). Critério de aceitação: vazão >= 2 Mbps"
- "Medir o tempo para que um usuário do sistema de Voz Sobre IP (VoIP) ouça o tom de discar após tirar o fone do gancho. Critério de aceitação: O tempo deve ser menor ou igual ao tempo oferecido pelo sistema PBX normal"
Os critérios de aceitação são baseados nos objetivos de negócio e técnicos já levantados para o projeto da rede
O mais importante é que o próprio cliente e o testador concordem sobre o significado dos critérios de aceitação para que não haja dúvida sobre se cada teste passou ou não
Os critérios de aceitação podem ser baseados num baseline de desempenho da rede atual
- Exemplo: diminuir o tráfego de broadcast em 50%

Determinação dos tipos de testes a realizar

Há três tipos básicos de testes:
- Testes de desempenho
  - Caracterização da vazão, atraso, variação no atraso, tempo de resposta e eficiência
- Testes de estresse
  - Degradação do serviço com aumento de carga
- Testes de falhas
  - Caracterização da disponibilidade e acurácia da rede
Embora seja mais raro, outros testes especiais podem ser feitos para gerenciabilidade, usabilidade, adaptabilidade e segurança
Testes típicos
- Tempo de resposta de aplicações
  - Medir o tempo para operações típicas realizadas pelo usuário (iniciar a aplicação, abrir arquivo, salvar arquivo, pesquisar, ...)
  - Pode usar um simulador ou examinar usuários reais trabalhando
- Testes de vazão
  - Vazão para uma aplicação particular ou para um grupo de aplicações
  - Medido em KBytes/seg ou MBytes/seg
- Testes de disponibilidade
  - Monitoram-se os erros e as falhas durante vários dias
- Testes de regressão
  - Verificação de que as aplicações que executavam corretamente na rede antiga continuam rodando na nova rede

Documentação dos equipamentos de rede e outros recursos

Listar tudo que é necessário para fazer os testes
- Mapa de rede
- Lista de dispositivos
- Outros equipamentos (cabos, etc.)
- Enlaces
- Ferramentas (de monitoração, de injeção de tráfego, de simulação, ...)
- Aplicações especiais que aumentam a eficiência dos testes (aplicação de distribuição de software, aplicação de controle remoto como PCAnywhere, ...)
- Outros recursos
  - Tempo blocado num laboratório especial
  - Ajuda de colegas
  - Ajuda de usuários
  - Nomes ou endereços IP durante os testes

Escrita de scripts de testes

Para cada teste, escreva uma script de teste, listando todas as etapas para a execuão do teste
O script deve também identificar:
- As ferramentas usadas
- Como cada ferramenta é usada para fazer as medições relevantes
- Que informação deve ser logada durante cada teste
- Valores iniciais para parâmetros dos testes e como alterar esses parâmetros ao longo do teste (exemplo: carga oferecida)
Exemplo de um script de teste segue para a configuração abaixo

cenarioteste.gif (10072 bytes)

Objetivos dos testes: Avaliar a capacidade do firewall bloquear tráfego da aplicação Xpto durante condições de tráfego leve e moderadamente pesado
Critério de aceitação: O firewall deve bloquear o pedido TCP SYN e qualquer estação na rede A que tentar abrir uma sessão com a aplicação Xpto no Servidor 1 na rede B. O firewall deve devolver um reset TCP (RST). Observe que SYN significa "abertura de conexão e suncronização de números de sequência".
Etapas de teste:
1. Iniciar a captura de tráfego no analizador de protocolos na rede A
2. Iniciar a captura de tráfego no analizador de protocolos na rede B
3. Executar a aplicação Xpto numa estação localizada na rede A para acessar o servidor 1 na rede B
4. Parar a captura de tráfego nos analizadores de protocolos
5. Exibir dados no analizador de protocolos da rede A para verificar que o analizador capturou um pacote TCP SYN proveniente da estação. Verificar que o destino do pacote é o Servidor 1 na rede B e que a porta destino é 1234 (a porta da aplicação Xpto). Verificar que o firewall respondeu à estação com um pacote TCP RST
6. Exibir dados no analizador de protocolos da rede A para verificar que o analizador não capturou qualquer tráfego para a aplicação Xpto
7. Logar os resultados do teste no arquivo de log do projeto
8. Salvar os arquivos de rastreamento dos analizadores de protocolos no diretório de arquivos de rastreamento
9. Gradualmente aumentar a carga no firewall, aumentando o número de estações na rede A, 1 de cada vez, até chegar a 50 estações tentando abrir conexão com a aplicação Xpto no Servidor 1. Repetir as etapas 1 a 8 ao adicionar cada estação

Cronograma de testes

Para um projeto complexo de testes (demorando mais do que 1 semana), elaborar um cronograma evidenciando data inicial, data final e milestones principais
- Incluir responsável por cada tarefa principal
Tarefas típicas são:
- Escrever os objetivos dos testes e critérios de aceitação
- Projetar a topologia para o ambiente de testes
- Determinar o hardware e software necessários para os testes
- Emitir o pedido de compra para o hardware e software, se necessário
- Escolher as ferramentas de testes
- Emitir o pedido de compra para as ferramentas de testes, se necessário
- Determinar outros recursos que serão necessários e providenciá-los
- Escrever scripts de testes
- Instalar e configurar o hardware e o software
- Iniciar testes
- Logar resultados dos testes
- Revisar e analizar resultados
- Reduzir os dados de resultados, se necessário
- Apresentar resultados ao cliente
- Arquivar os resultados

Implementação do plano de testes

É basicamente uma questão de seguir o plano

Ferramentas para testar uma rede

Há três tipos de ferramentas que ajudam a realizar testes
Ferramenta de gerência e monitoração de rede
- Cisco Works, HP OpenView
- Pode obter informações variadas sobre tráfego, erros, etc.
- Na sua ausência, pode-se usar comandos que dão informação equivalente nos roteadores
  - show interfaces, show processes, show buffers, ...
- Outra alternativa: analizadores de protocolos
  - Bom para analizar comportamento de tráfego, erros, utilização, eficiência, taxas de broadcast e multicast, etc.
  - Ajuda a gerar tráfego artificial durante os testes
Ferramentas especiais de testes e simulação
- Simulação pode ser menos caro do que testar uma rede de verdade
- De forma geral, é muito difícil fazer uma boa simulação que esteja perto do mundo real
Ferramentas de gerência de nível de serviço
- Ferramentas novas que analizam o desempenho fim-a-fim de aplicações, incluindo requisitos de QoS
- Exemplo: NetPredictor de NetPredict

Um exemplo de um cenário de testes

Exemplo abaixo é um estudo de caso real

Informação inicial

Empresa: Umqua Systems projeta e fabrica circuitos integrados especiais para aparelhos eletrônicos
O projeto se foca numa rede de campus com 4 prédios, 3 deles próximos e 1 a uma distância de 5 km
400 empregados (engenharia, vendas, marketing, finanças)

Objetivos dos testes

Dois objetivos principais para os testes
- Determinar a carga e desempenho da rede atual, com foco especial no backbone FDDI
- Determinar o que acontecerá com o desempenho da rede se 10 a 20 pessoas executarem uma nova aplicação de entrada de pedido usando tecnologia Oracle
Hoje, a empresa usa OpenView para gerar alarmes mas não para observar o desempenho da rede

Aplicações de rede

Aplicações típicas de escritório (mail, compartihamento de arquivos e impressoras)
Computer-Aided Design (CAD) para projetar circuitos integrados
- Os engenheiros têm dois computadores na mesa: PC com Windows 98 para trabalho de escritório e Workstation Sun para a aplicação CAD
Características especiais da aplicação CAD
- Edições pequenas são feitas diretamente no arquivo original (no servidor)
- Para edições grandes, o arquivo é trazido para a estação local e editado localmente
- À noite, um programa de sincronização de arquivos verifica as datas dos arquivos nas várias estações e consolida tudo no servidor central
- Os arquivos variam de 1 a 20 MBytes

A rede atual

Backbone FDDI conectando os prédios 1 a 3
Prédio 4 conectado ao backbone com 2 enlaces paralelos E1 de 2 Mbps, com fibra ótica
Um enlace E1 adicional com subcanais é usado como segue:
- Canal de 64 Kbps com Frame Relay para acessar filais domésticas
- Canal de 128 Kbps para acessar filiais na Europa
Acesso Internet 64 Kbps a partir do prédio 2
Estações Sun se conectam a segmentos 100BaseTX
PCs se conectam a segmentos 10BaseT
Servidores se conectam diretamente no backbone FDDI

umqua.gif (27420 bytes)

Métodos de testes usados

Um plano de testes foi escrito, com objetivos específicos de medir o desempenho atual e predizer o desempenho futuro da rede com a nova aplicação
- Ferramenta básica: NetPredictor para fazer análise "what-if"
Um modelo de carga de tráfego (para NetPredictor) foi obtido através de conversas com os gerentes de rede na empresa
- O modelo foi calibrado através de medições de desempenho obtidas na rede real
  - Ver localização dos analizadores de protocolos na figura acima
  - Dados foram obtidos com médias a cada minuto, durante 24 horas
- O modelo calibrado aparece na tabela abaixo

Modelo de distribuição de carga na empresa Umqua Systems (Números em azul foram computados pela ferramenta)
Prédio 2
Número de máquinas clientes	160
Tamanho médio de arquivo acessado	20	Mbytes
Atividade média por pessoa	40	Mbytes/hora
Carga total iniciada no prédio	6.400	Mbytes/hora
Carga em segmento 10 Mbps e em segmento 100 Mbps	10%	90%
Carga local saindo do prédio	67%
Carga local na LAN 10 Mbps	640	Mbytes/hora
Carga local na LAN 100 Mbps	5.760	Mbytes/hora
Tráfego de outros prédios	3.008	Mbytes/hora
Tráfego do prédio 1	80%	3.430,4	Mbytes/hora
Tráfego do prédio 3	20%	857,6	Mbytes/hora
Tráfego do prédio 4	0%	0	Mbytes/hora
Utilização da LAN 10 Mbps	20,9%
Utilização da LAN 100 Mbps	18,8%
Prédio 1
Número de máquinas clientes	160
Tamanho médio de arquivo acessado	17	Mbytes
Atividade média por pessoa	34	Mbytes/hora
Carga total iniciada no prédio	5.440	Mbytes/hora
Carga em segmento 10 Mbps e em segmento 100 Mbps	10%	90%
Carga local saindo do prédio	65%
Carga local na LAN 10 Mbps	544	Mbytes/hora
Carga local na LAN 100 Mbps	4.896	Mbytes/hora
Tráfego de outros prédios	3.540	Mbytes/hora
Tráfego do prédio 2	80%	2.828,8	Mbytes/hora
Tráfego do prédio 3	20%	707,2	Mbytes/hora
Tráfego do prédio 4	0%	0	Mbytes/hora
Utilização da LAN 10 Mbps	20,0%
Utilização da LAN 100 Mbps	18,0%
Prédio 3
Número de máquinas clientes	160
Tamanho médio de arquivo acessado	1	Mbytes
Atividade média por pessoa	2	Mbytes/hora
Carga total iniciada no prédio	320	Mbytes/hora
Carga local saindo do prédio	80%
Carga local na LAN 10 Mbps	320	Mbytes/hora
Tráfego de outros prédios	1,570	Mbytes/hora
Tráfego do prédio 1	60%	153,6	Mbytes/hora
Tráfego do prédio 2	35%	89,6	Mbytes/hora
Tráfego do prédio 4	5%	12,8	Mbytes/hora
Suponha 2 LANs de 10 Mbps:
Utilização em cada LAN 10 Mbps	21,0%
Prédio 4
Número de máquinas clientes	160
Tamanho médio de arquivo acessado	2	Mbytes
Atividade média por pessoa	4	Mbytes/hora
Carga total iniciada no prédio	640	Mbytes/hora
Carga em segmento 10 Mbps e em segmento 100 Mbps	15%	85%
Carga local saindo do prédio	8%
Carga local na LAN 10 Mbps	88,32	Mbytes/hora
Carga local na LAN 100 Mbps	500,48	Mbytes/hora
Tráfego de outros prédios	13	Mbytes/hora
Tráfego do prédio 1	50%	25,6	Mbytes/hora
Tráfego do prédio 2	40%	20,48	Mbytes/hora
Tráfego do prédio 3	10%	5,12	Mbytes/hora
	Do modelo	Medido
Utilização da LAN 10 Mbps	2,0%	2,0%
Utilização da LAN 100 Mbps	1,1%
Utilização do backbone FDDI 100 Mbps	18%	18%
Utilização das linhas E1	4,6%	4,32%

Dados medidos

Apresentam-se dados colhidos com os analizadores de protocolos e algumas conclusões decorrentes da análise dos dados

Carga no backbone FDDI

A figura abaixo mostra a carga no backbone FDDI durante aproximadamente 24 horas
- À noite, temos utilização de uns 2%
- Maior carga perto do fim do dia

11-3.jpg (96042 bytes)

A curva abaixo mostra uma função cumulativa de probabilidade da carga (um histograma cumulativo dos pontos da figura anterior), mostrando que:
- A carga média é de 15%
- Aproximadamente 5% dos pontos indicam carga maior que 25%
- Curva boa para diferenciar a carga média da carga de pico

11-4.jpg (32374 bytes)

Conclusão: não há problemas de sobrecarga
- Já sabíamos disso pois os usuários não estavam reclamando

Carga nas LPCDs

A figura abaixo mostra que a carga nos enlaces é pequeno, com exceção do período da noite durante a sincronização de arquivos, que dura umas 4 horas
Durante o dia, a utilização está abaixo de 10% 90% do tempo
- Sem problemas, portanto

11-5.jpg (57290 bytes)

Análise do novo sistema de entrada de pedidos

Obteve-se uma análise de tráfego usando um analizador de protocolos de uma sessão de um único usuário para modelar o tráfego
Resultados:
- A entrada de um único pedido causa um tráfego de uns 2 Mbytes
  - 220 KBytes de tráfego TCP/IP entre o usuário e o BD Oracle no prédio 1
  - 1,7 Mbytes de tráfego NetWare entre o usuário e o servidor de arquivo NetWare no prédio 1 (tráfego para carregar a aplicação e os formulários virgens de entrada de pedido)
- O trabalho foi completado em 3 minutos com carga média de 90 Kbps
- Para uso contínuo (aplicação já carregada), estima-se que a carga média será de 40 Kbps
- Para 10 usuários, a carga seria de 400 Kbps
  - Isso não vai sobrecarregar as LANs
  - Os enlaces E1 terão utilização aumentada de 4,3% para uns 17%

Conclusões

A rede aguenta o novo tráfego sem problemas
É até possível considerar alternativas mais baratas para os enlaces E1 que estão sub-utilizados

tod-1 programa próxima