lilian noronha nassif - dcc · iv agradecimentos ao professor josé marcos silva nogueira, pelas...
TRANSCRIPT
Lilian Noronha Nassif
PLANEJAMENTO DE CAPACIDADE PARA A WAN DA REDE MUNICIPAL DEINFORMÁTICA
Dissertação apresentada ao Curso deMestrado da Escola de Governo deMinas Gerais da Fundação JoãoPinheiro, como requisito parcial para aobtenção do título de Mestre emAdministração Pública.
Área de Concentração: Informática.
Orientador: Prof. José Marcos SilvaNogueira.
Belo HorizonteFundação João Pinheiro
1997
ii
FOLHA DE APROVAÇÃO
PLANEJAMENTO DE CAPACIDADE PARA A WAN DA REDE MUNICIPAL DEINFORMÁTICA
LILIAN NORONHA NASSIF
Dissertação defendida e aprovada pela banca examinadora constituída pelos Senhores:
Prof. José Marcos Silva Nogueira (Phd) - orientadorDCC - ICEx - UFMG
Prof. Berthier Ribeiro de Araújo Neto (Phd)DCC - ICEx - UFMG
Prof. Mário Fernando Montenegro Campos (Phd)DCC – ICEx - UFMG
Belo Horizonte, 06 de outubro de 1997.
iii
À minha mãe
iv
Agradecimentos
Ao professor José Marcos Silva Nogueira, pelas fundamentais orientações dadas
ao trabalho, fazendo-me compreender os relevantes pequenos passos para se conseguir
alcançar o objetivo final.
À Prodabel, que de forma empreendedora conseguiu investir em material
acadêmico na produção de dissertações para sua realidade. Ao diretor-presidente da
Prodabel, Gustavo da Gama Torres, que especialmente contribuiu para a realização
deste curso de mestrado. Aos diretores Pedro Ernesto Diniz e Jânio Bragança, que
aprovaram o projeto de dissertação, incluindo-o como projeto da empresa.
Aos colegas da Prodabel, Carlos César Morais, Edson Geraldo, Márcio Freire,
Alexandre Zeferino, Margareth Guelber, Fátima Procópio, Marcelo Pimenta, Paulo
Guedes, Bernardo Amaral e Luciano Nascimento, pela amizade e convivência técnica e
pelas diversas vezes em que nos envolvemos para solucionar problemas e implementar
tecnologias na atual Rede Municipal de Informática, que tornou-se o objeto de estudo
deste trabalho.
À professora Laura da Veiga e ao professor Nagib Contrim, pelo empenho na
montagem do curso de Mestrado e pela excelente qualidade obtida na conjugação de
Administração Pública e Informática.
À grande amiga Fabrícia Frederico Senra, pela preciosa ajuda nos softwares de
apoio.
À minha mãe e minha irmã, pelo amor, carinho e por tudo que já passamos juntas.
Ao meu pai coruja.
Ao Pedro Ernesto, meu companheiro, pelo incentivo, compreensão e
solidariedade durante este período.
Ao Luís Henrique, por ter abaixado o som dos RAP’s, Trash’s, Rock’s e outros da
pesada.
Aos meus colegas do mestrado, por termos compartilhado angústias,
aprendizados e vitórias durante nosso percurso.
Ao Henrique Cristiano, Alexandre Barros e Lilian Cristina, pela contribuição em
trabalhos afins.
Ao DCC (Departamento de Ciência da Computação) da UFMG, que permitiu a
utilização de seus equipamentos e software e principalmente, pela autorização de uso do
simulador COMNET III, considerada ferramenta chave deste trabalho.
v
SUMÁRIOFolha de Aprovação .......................................................................................................... iiDedicatória .... ...................................................................................................................iiiAgradecimentos ............................................................................................................... ivSumário .... ........................................................................................................................ vLista de gráficos .... .........................................................................................................viiiLista de figuras .... ............................................................................................................ ixLista de tabelas .... ............................................................................................................ xResumo .... ....................................................................................................................... xiAbstract .... .......................................................................................................................xii
PARTE I - Introdução, abordagem sobre Planejamento de Capacidade e Tópicosrelacionados
1. Introdução ..................................................................................................................1
1.1 O contexto da informática nos anos 90.....................................................................11.2 Motivação e objetivos do trabalho ............................................................................31.3 Organização da Dissertação ....................................................................................4
2. Planejamento de Capacidade ...................................................................................7 2.1 A Necessidade de planejar.......................................................................................72.2 Metodologia de Planejamento de Capacidade..........................................................82.3 Modelagem de sistemas.........................................................................................122.4 Simulação - Modelo e Técnica utilizados neste trabalho ........................................142.5 Estatística aplicada na simulação...........................................................................16
2.5.1 Técnicas de análise de dados ..........................................................................162.5.2 Conceitos básicos de probabilidade .................................................................182.5.3 Propriedades de algumas distribuições de probabilidade .................................192.5.4 Seleção de distribuição de probabilidade para a amostra.................................20
2.5.4.1 Atividade I: Fazer hipóteses para distribuições conhecidas........................212.5.4.2 Atividade II: Fazer estimativa de parâmetros..............................................212.5.4.3 Atividade III: Determinar o quanto as distribuições estão ajustadas ...........21
3. A Ferramenta COMNET III .......................................................................................23 3.1 Escolhendo o nível de detalhe correto....................................................................233.2 Passos da Construção do Modelo de Simulação....................................................24
3.2.1 Topologia da Rede ...........................................................................................243.2.2 Tráfego da Rede e Carga de Trabalho .............................................................243.2.3 Operações de Rede .........................................................................................243.2.4 Controle da Simulação .....................................................................................25
3.3 Forma de cadastramento das informações no Comnet III - Identificando variáveisbásicas para o modelo .................................................................................................25
PARTE II - Aplicação da Metodologia de Planejamento de Capacidade à WAN daRMI
4. FASE 1: PLANOS CORPORATIVOS e FASE 2: COMPREENSÃO DO AMBIENTE 28 4.1 FASE 1: PLANOS CORPORATIVOS .....................................................................284.2 FASE 2: COMPREENSÃO DO AMBIENTE............................................................30
4.2.1 Levantamento da Topologia .............................................................................304.2.1.1 Levantamento dos equipamentos de rede utilizados..................................31
4.2.2 Levantamento de equipamentos e circuitos da RMI .........................................324.2.3 Configuração de software e hardware ..............................................................324.2.4 Levantamento de aplicações e serviços ...........................................................334.2.5 Levantamento de protocolos de comunicação..................................................34
vi
4.2.6 Janela de tempo e Níveis de Serviços..............................................................345. FASE 3: CARACTERIZAÇÃO DA CARGA DE TRABALHO.....................................37
5.1 Definição de variáveis ............................................................................................375.2 Monitores para coleta de dados..............................................................................39
5.2.1 Gerenciamento SNMP......................................................................................405.2.2 O Tcpdump ......................................................................................................42
5.3 Usando o SNMP na RMI ........................................................................................435.3.1 Coleta de dados ...............................................................................................435.3.2 Transformação dos dados................................................................................455.3.3 Análise de dados..............................................................................................45
5.3.3.1 Identificação da janela de tempo................................................................455.3.3.2 Análise do horário de pico..........................................................................485.3.3.3 Análise de volume de dados trafegados no backbone central ....................49
5.4 Usando o Tcpdump na RMI....................................................................................505.4.1 Coleta de dados ...............................................................................................505.4.2 Transformação de dados..................................................................................51
5.4.2.1 Reduzindo dados capturados pelo Tcpdump .............................................525.4.3 Análise de Dados .............................................................................................55
5.4.3.1 Análise da composição do tráfego usando o pacote Iptraf .........................556. FASE 4: CONSTRUÇÃO DO MODELO.....................................................................59
6.1 Topologia da Rede .................................................................................................596.2 Tráfego da Rede ....................................................................................................61
6.2.1 Originadores de Tráfego representados no COMNET III ..................................626.2.1.1 Objeto Source: Message............................................................................626.2.1.2 Objeto Source: Response ..........................................................................63
6.2.2 Seleção de distribuição de probabilidade para a amostra.................................636.2.2.1 Atividade I: Fazer hipóteses para distribuições conhecidas........................646.2.2.2 Atividade II: Fazer estimativa de parâmetros..............................................656.2.2.3 Atividade III: Determinar o quanto as distribuições estão ajustadas ...........656.2.2.4 Escolha da distribuição empírica................................................................67
6.3 Operações de Rede ...............................................................................................686.4 Controle da Simulação ...........................................................................................686.5 Resumo e Conclusões do capítulo .........................................................................68
7. FASE 5: VALIDAÇÃO E CALIBRAÇÃO DO MODELO.............................................71 7.1 Como validar o modelo...........................................................................................71
7.1.1 Validação: Quantidade de mensagens geradas ...............................................727.2 Como foi feita a Calibração ....................................................................................737.3 Análises sobre o modelo validado ..........................................................................757.4 Situações de “What if” ............................................................................................77
7.4.1 Falha de um dos roteadores do backbone........................................................777.4.2 Falha de um dos links do backbone .................................................................787.4.3 Topologia em anel em operação ......................................................................79
7.5 Resumo e Conclusões do capítulo .........................................................................828. FASE 6: PREVISÃO DE NOVAS CARGAS...............................................................84
8.1 Levantamento de novas cargas..............................................................................848.2 Cenário 1: Aumento de tráfego para aplicação existente........................................868.3 Cenário 2: Introdução de nova aplicação................................................................86
9. FASE 7: PREVISÃO DE DESEMPENHO e FASE 8: ALTERNATIVA PARA SISTEMA ...............................................................89
9.1 FASE 7: PREVISÃO DE DESEMPENHO...............................................................899.2 FASE 8: ALTERNATIVAS PARA O SISTEMA........................................................91
10. CONCLUSÕES .........................................................................................................95 11. BIBLIOGRAFIA.........................................................................................................99 12. ANEXO....................................................................................................................103
vii
12.1 Composição da RMI ...........................................................................................10312.2 Levantamento dos servidores/aplicativos acessados pela WAN.........................11012.3 Análise do volume de Dados do backbone central .............................................113
12.3.1 Roteadores da PBH1212..............................................................................11312.3.2 Roteadores da Tupis ....................................................................................11412.3.3 Roteadores da Prodabel...............................................................................115
12.4 Horário de pico ...................................................................................................11612.4.1 Roteadores da PBH1212..............................................................................11612.4.2 Roteadores da Tupis ....................................................................................11712.4.3 Roteadores da Prodabel...............................................................................118
12.5 Análise da Composição do Tráfego....................................................................11912.6 Ambiente de simulação ......................................................................................122
viii
LISTA DE GRÁFICOS
GRÁFICO 2-1: Exemplo de Histograma .......................................................................................17GRÁFICO 2-2: Exemplo de carta de controle ...............................................................................18GRÁFICO 5-1: Carta de Controle para roteador 10.13.0.1............................................................46GRÁFICO 5-2: Carta de Controle para roteador 10.13.0.231 ........................................................46GRÁFICO 5-3: Carta de Controle para roteador 10.54.12.1..........................................................47GRÁFICO 5-4: Carta de Controle para roteador 10.54.12.2..........................................................47GRÁFICO 5-5: Carta de Controle para roteador 10.13.7.1............................................................47GRÁFICO 5-6: Carta de Controle para roteador 10.13.7.2............................................................48GRÁFICO 5-7: Tráfego da WAN para servidores da PBH1212 (medida: pacotes) .......................56GRÁFICO 5-8: Tráfego da WAN para os servidores da PBH1212 (medida: octetos)....................57GRÁFICO 5-9: Tráfego da WAN para os servidores da RMI.........................................................58GRÁFICO 7-1: Utilização dos links da RMI - Modelo validado ......................................................76GRÁFICO 7-2: Utilização dos links na falha do roteador 10.13.0.1 ...............................................77GRÁFICO 7-3: Utilização dos links na falha do link 501-7100 .......................................................79GRÁFICO 7-4: Utilização dos links para topologia em anel...........................................................82GRÁFICO 9-1: Utilização dos canais de comunicação após acréscimo de 20% de novas cargas .90GRÁFICO 9-2: Utilização dos canais de comunicação após adição da aplicação WWW...............91GRÁFICO 9-3: Utilização dos links após alteração de velocidade.................................................92GRÁFICO 12-1: Entrada/saída de octetos do roteador 10.13.0.1................................................113GRÁFICO 12-2: Entrada/saída de octetos do roteador 10.13.0.231............................................113GRÁFICO 12-3: Entrada/saída de octetos do roteador 10.13.7.1................................................114GRÁFICO 12-4: Entrada/saída de octetos no roteador 10.13.7.2................................................114GRÁFICO 12-5: Entrada/saída de octetos do roteador 10.54.12.1..............................................115GRÁFICO 12-6: Entrada/saída de octetos do roteador 10.54.12.2..............................................115GRÁFICO 12-7: Entrada de octetos no roteador 10.13.0.1 em intervalos de 30 min. ..................116GRÁFICO 12-8: Entrada de octetos no roteador 10.13.0.231 em intervalos de 30min.................116GRÁFICO 12-9: Entrada de octetos no roteador 10.13.7.2 em intervalos de 30 min. .................117GRÁFICO 12-10: Entrada de octetos no roteador 10.13.7.1 em intervalos de 30 min..................117GRÁFICO 12-11: Entrada de octetos no roteador 10.54.12.1 em intervalos de 30min.................118GRÁFICO 12-12: Entrada de octetos no roteador 10.54.12.2 em intervalos de 30min.................118GRÁFICO 12-13: Tráfego WAN para servidor da PBH4000, por protocolo (em pacotes) ............119GRÁFICO 12-14: Tráfego da WAN para servidor da PBH4000, por protocolo (em octetos).........119GRÁFICO 12-15: Tráfego da WAN para servidores da Prodabel, por protocolo em pacotes) ......120GRÁFICO 12-16: Tráfego da WAN para servidores da Prodabel, por protocolo (em octetos)......120GRÁFICO 12-17: Tráfego da WAN para servidor da Tupis, por protocolo (em pacotes)..............121GRÁFICO 12-18: Tráfego da WAN para servidor da Tupis, por protocolo (em octetos)...............121
ix
LISTA DE FIGURAS
FIGURA 2-1: Metodologia de Planejamento de Capacidade baseada em modelo.......................... 9FIGURA 2-2: Técnicas de Previsão de Desempenho....................................................................12FIGURA 3-1: Ícones do COMNET III utilizados na modelagem da Rede Municipal de Informática 27FIGURA 4-1: Topologia em Anel da RMI ......................................................................................31FIGURA 4-2: Arquitetura de um sistema computacional ...............................................................33FIGURA 5-1: Hierarquia da MIB da Internet com destaque para a MIB da Cisco...........................42FIGURA 6-1: Modelo de simulação da RMI no COMNET III..........................................................60FIGURA 6-2: Componentes do backbone .....................................................................................60FIGURA 6-3: Teste de hipótese para distribuição exponencial......................................................65FIGURA 6-4: Teste de hipótese para distribuição Weibull.............................................................65FIGURA 7-1: Modelo com topologia em anel................................................................................81FIGURA 8-1: Modelo de simulação da RMI com acréscimo da aplicação WWW ..........................88FIGURA 12-1: Anel Central - ligações a 128 Kb..........................................................................103FIGURA 12-2: Anel 1 .................................................................................................................103FIGURA 12-3: Anel 2 .................................................................................................................103FIGURA 12-4: Anel 3 .................................................................................................................104FIGURA 12-5: Anel 4 .................................................................................................................104FIGURA 12-6: Anel 5 .................................................................................................................105FIGURA 12-7: Anel 6 .................................................................................................................105FIGURA 12-8: Anel 7 .................................................................................................................105FIGURA 12-9: Anel 8 .................................................................................................................106FIGURA 12-10: Anel 9 ...............................................................................................................106FIGURA 12-11: Anel 10..............................................................................................................106FIGURA 12-12: Ligações das portas seriais nos roteadores .......................................................107
x
LISTA DE TABELAS
TABELA 2-1: Exemplo de Distribuição de Freqüência ..................................................................16TABELA 6-1: Distribuição de Freqüência para anel1-1 .................................................................67TABELA 7-1: Quantidade de Mensagens. Simulado X Real..........................................................72TABELA 7-2: Exemplo um de agrupamento de distribuição de freqüência ....................................74TABELA 7-3: Exemplo dois de agrupamento de distribuição de freqüência...................................74TABELA 7-4: Utilização dos links com topologia em anel..............................................................80TABELA 8-1: Atual distribuição de usuários da Internet na RMI....................................................87TABELA 12-1: Circuitos PPP da RMI .........................................................................................107TABELA 12-2: Órgãos da PBH e entidades vinculadas...............................................................108TABELA 12-3: Indisponibilidade dos circuitos da RMI no mês de maio .......................................109TABELA 12-4: Servidores da PBH1212 acessados pela WAN....................................................110TABELA 12-5: Servidor da Tupis acessado pela WAN ...............................................................110TABELA 12-6: Servidor da PBH4000 acessado pela WAN.........................................................110TABELA 12-7: Servidores da Prodabel acessados pela WAN.....................................................111TABELA 12-8: Descrição dos Aplicativos....................................................................................111TABELA 12-9: Porcentagem de destino das mensagens, por anel, para cada servidor WAN da
RMI .....................................................................................................................................112
xi
Resumo
A dissertação apresenta um tratamento científico para o planejamento decapacidade de uma rede de longa distância. Para isso são utilizadastécnicas, metodologias e ferramentas adequadas ao objeto em estudo.Ao tratar dos conceitos de planejamento de capacidade, modelagem desistemas, simulação e estatística, o texto dá embasamento às tomadasde decisão do projeto. A metodologia de Planejamento de Capacidadeutilizada consiste em oito fases: Planos Corporativos, Compreensão doAmbiente, Caracterização do Tráfego, Construção do Modelo, Validaçãoe Calibração do modelo, Previsões de Novas Cargas e Alternativas parao Sistema. A rede de longa distância da Rede Municipal de Informáticade Belo Horizonte é tomada como referência real para a aplicação dessametodologia. A caracterização do tráfego envolveu análises estatísticassobre os dados de entrada, sendo o modelo implementado comdistribuição de freqüência empírica. O modelo foi construído em umsimulador comercial COMNET III, através do qual foi possível fazeranálises sobre a inclusão de novas cargas de tráfego, focalizandosempre os resultados do ponto de vista da utilização dos circuitos decomunicação do backbone da rede. A descrição das etapas dametodologia em total compatibilização com o ambiente de rede de longadistância, a construção do modelo topológico e de tráfego, e osresultados obtidos através do uso de simulação como técnica depredição de desempenho foram importantes produtos obtidos nestetrabalho.
xii
Abstract
The dissertation presents a scientific approach to capacity planning in awide area network. Adequate methodologies, techniques and tools areused. Through the use of capacity planning, systems modeling,simulations and statistics concepts the text supports decision making inwide area network administration. The methodology consists of eightphases: corporate planning, environment understanding, trafficcharacterization, model construction, model validation and fine tuning,new workload forecast, and alternate ways. The wide area network ofthe municipal computer network of Belo Horizonte is a actual reference tothe application of that methodology. The traffic characterization camefrom statistical analyses of input data. The model was implemented withempirical frequency distribution. The model was developed using acommercial simulator, COMNET III, that allowed for analyses about newworkload insertion and used data from the communication circuits of thenetwork backbone. The main results of that work were the description ofmethodology steps according to wide area network, the building of thetopologic and traffic model, and the reports from the simulation modelsoftware.
1
PARTE I - Introdução, abordagem sobre Planejamentode Capacidade e tópicos relacionados
Nesta primeira parte será exposta a contextualização da Informática nos dias
atuais, bem como a caracterização do problema a ser trabalhado. Em seguida será
feita uma abordagem dos tópicos essenciais à discussão do Planejamento de
Capacidade, envolvendo metodologia e técnicas adequadas que darão embasamento
às decisões de projeto realizadas na Parte II.
Capítulo 1
Introdução
1.1 O contexto da informática nos anos 90
Acima de tudo, é a aceleração da mudança em si que marca este nosso momento nahistória.
Alvin Tofler
O custo e a flexibilidade dos sistemas centralizados tradicionais, operados em
plataformas mainframe, estão sendo questionados. Durante muito tempo, o mainframe
dominou o mundo do processamento de dados, praticamente sem concorrentes. Com
o advento dos PC’s, na década de 80, e a introdução de uma nova geração de
programas gráficos, com imenso potencial para aplicações sofisticadas, surgiu um
novo tipo de usuário, com mais domínio das “máquinas”, mais exigente em termos de
qualidade, rapidez e custo. O processamento tradicional passou a ser questionado
quanto ao custo, produtividade, “tempo de resposta” e flexibilidade, levando as
empresas à busca de alternativas. O downsizing em seus sistemas de informação, ou
seja, a migração das grandes plataformas para plataformas menores passou a se
colocar na ordem do dia. Hoje existe um mercado farto de produtos, equipamentos e
serviços para plataformas de microcomputadores e estações de trabalho, os quais
viabilizam a substituição do mainframe.
2
Mais que uma substituição de máquinas, essa mudança de plataforma
proporciona caminhar junto e participar da Revolução da Informação1. Segundo Tofler
[62] a humanidade vive a “terceira onda”. Na primeira, a agrária, onde o homem
colocou fim à vida nômade através do controle das fontes de alimentação, aprendendo
a domesticar animais, a plantar e colher. A segunda onda, ocorrida no fim do século
XIX, foi marcada pela Revolução Industrial. Trouxe uma sociedade de massa,
industrial, possibilitando às pessoas não necessitarem mais voltar todo o trabalho para
a auto-suficiência. A terceira onda, a atual, envolve um conjunto de transformações
aceleradas pela tecnologia. Entre outras coisas, tem-se os cartões de créditos, os
videogames, os serviços eletrônicos, um novo equilíbrio geopolítico no mundo, os
computadores e uma disponibilização de informações nunca vista anteriormente.
Focalizando principalmente a revolução da Informação nos anos 90, vê-se que
o mundo da informática está no dia-a-dia das pessoas, presentificando-se pelo do uso
da informação digital, que é criada, arquivada e modificada nos computadores. O
grande destaque desta década foi a utilização dos computadores pessoais em rede,
sendo possível a circulação e processamento de informações em ambientes diversos.
A Internet aparece então como a “estrela” deste espetáculo. Sendo comumente
designada como “rede mundial de computadores”, ela possui estrutura para trafegar a
informação em seus mais diversos formatos, como voz, imagem, dados e vídeo,
permitindo que pessoas do mundo inteiro compartilhem de entretenimento e saber.
Tecnologias diversas surgem para melhorar essa comunicação de longa
distância. A velocidade e a tecnologia de comunicação passam a ser os meios que
interagem os computadores remotos, fazendo com que a noção de tempo e espaço
seja reduzida.
Apesar de a informação ser tratada, nos dias atuais, como grande fonte de
poder para a sociedade pós-moderna, ela não é no entanto confinada. Na verdade, ela
está disponibilizada em um ambiente multi. Esse prefixo exibe de forma explícita a
popularidade da Internet: multi-usuários, multi-plataforma, multi-protocolo, multi-
camadas, multimídia [19]. Na visão de Tofler [62], os sistemas de computadores
grandes e fortemente centralizados aumentam o poder do Estado sobre o indivíduo,
em contrapartida aos computadores descentralizados e redes de computadores que
fortalecem o poder do indivíduo.
1 Charlab [15] entende a revolução como “Transformação radical dos conceitos artísticos ou científicosdominantes numa determinada época”.
3
A década de 90 trouxe palavras-chaves para a área da Informática, que de
forma mínima e não exploratória pode-se citar: PC’s, downsizing, redes de
computadores e Internet. Direcionando essas tecnologias está uma sociedade
moderna, que segundo Giddens [29] é inerentemente globalizante.
1.2 Motivação e objetivos do trabalho
No caso da Prefeitura de Belo Horizonte, a informática é gerida pela
PRODABEL (Empresa de Informática e Informação do Município de Belo Horizonte),
onde, através da descentralização dos sistemas de informação, foi realizada uma
transição da arquitetura SNA (Systems Network Arquitecture), caracterizada por
mainframe e terminais IBM, para redes baseadas em sistemas abertos, entre eles, a
adoção do padrão TCP/IP (Transport Control Protocol / Internet Protocol), com a
perspectiva de evolução para redes cliente-servidor.
As aplicações foram distribuídas para servidores localizados em diversas redes
locais surgindo a necessidade de interligação das mesmas através de WAN’s. Alguns
dos problemas com esta implementação são o dimensionamento da capacidade dos
enlaces necessários à topologia adotada, a carga de trabalho gerada pelas aplicações
TCP/IP e o comportamento destas aplicações nos diferentes serviços de comunicação
oferecidos pela concessionária local. A não avaliação sistemática e científica desses
enlaces pode gerar congestionamentos de tráfego, tempos de resposta fora de
padrões aceitáveis, ou por outro lado, desperdício da banda passante de linhas super-
dimensionadas.
Para a Prodabel, a gerência da Rede Municipal de Informática (RMI)
pressupõe, freqüentemente, a análise desses enlaces para o crescimento e
atendimento aos novos pontos que se integrarão à RMI ou para redimensionamento
de enlaces já existentes.
A Prodabel é, também, uma empresa pública, e como descreve Osborne &
Gaebler [45], o setor público é cercado de muita burocracia. Muitas regras são
estabelecidas para se designar “como” devem ser feitas as atividades, regulando os
procedimentos e ignorando os resultados. No caso, tais regras dificultam à empresa
se manter atualizada no que se refere à aquisição de equipamentos mais eficientes e
apropriados a soluções tecnológicas no ambiente computacional da rede pública.
Some-se às dificuldades impostas pela burocracia o fator velocidade, incorporado ao
ritmo de mudança da era da modernidade, como bem descreve Giddens[29]. Esse
descompasso com as borbulhantes inovações da modernidade exige uma gerência
4
eficiente dos recursos disponíveis através de uma parametrização adequada do
ambiente e da consciência dos limites dos ajustes, antecipando problemas e
gerenciando com previsibilidade.
É dentro deste contexto que se insere o presente trabalho, que procura
contribuir para que sejam realizadas as desejáveis mudanças no ambiente da WAN da
RMI. Pretende-se com este trabalho alcançar as seguintes metas :
n Caracterização da rede identificando que aplicações estão
trafegando na WAN, qual o tráfego utilizado pelas mesmas e onde
se encontram os clientes e os servidores do tráfego;
n Construção de um modelo de simulação;
n Realização de simulação seguida de análises sobre o ambiente;
n Identificação de métodos, técnicas e ferramentas para realizar
Planejamento de Capacidade para uma rede de longa distância;
n Especialização da metodologia para uso sistemático na Rede
Municipal de Informática.
1.3 Organização da Dissertação
Este trabalho apresenta aspectos que envolvem o Planejamento de
Capacidade e utiliza a metodologia desenvolvida por Menascé et al.[42]. Entre os
principais ítens abordados destacam-se o uso de modelo de simulação e a análise
estatística para os dados do sistema real.
A dissertação está dividida em duas partes. A primeira contextualiza o trabalho
nos tempos atuais da Informática. Aborda também a teorização sobre Planejamento
de Capacidade com tópicos essenciais para dar embasamento ao mesmo, sendo eles
Modelagem de sistemas, Simulação e Estatística. A segunda parte aplica a
metodologia de Planejamento de Capacidade a um objeto empírico, no caso, a WAN
da Rede Municipal de Informática. As etapas são descritas com detalhes,
referenciando as ferramentas utilizadas.
A primeira parte inicia-se com Introdução (Capítulo 1), que enfoca a
informática nos anos 90 e expõe a motivação e a organização do trabalho. Possui um
capítulo referente a Planejamento de Capacidade (Capítulo 2), que discute a
necessidade de se fazer planejamento e os benefícios obtidos com o mesmo. Nesse
capítulo é também apresentada a metodologia de Planejamento de Capacidade
baseada em modelos e que será utilizada neste trabalho.
5
Um dos tópicos tratados nesse capítulo se refere à Modelagem de sistemas,
que apresenta os tipos de modelos que podem representar o sistema real. É
destacado o modelo que será utilizado no trabalho diante de outras formas de
representação.
O tópico sobre Simulação apresenta as linguagens de programação baseadas
em simulação, bem como os simuladores. É apresentada uma visão genérica sobre o
assunto e justificativa da escolha técnica.
No tópico que se segue, é destacada a afinidade entre a Estatística e a
Simulação, abordando conceitos e técnicas que serão usados no decorrer do trabalho.
O tratamento dos dados de forma estatística visa à compreensão e utilização dos
mesmos para qualquer ferramenta de simulação.
Ao final da primeira parte, é destinado um capítulo para a ferramenta
COMNET III (Capítulo 3), que será utilizada para a construção do modelo de
simulação. O capítulo descreve a funcionalidade da ferramenta, bem como os passos
essenciais para a construção do modelo utilizando esse simulador.
A segunda parte da dissertação reserva uma, e em algumas situações, duas
fases da metodologia de Planejamento de Capacidade para cada capítulo. A
metodologia é demonstrada com aplicação direta na WAN da RMI.
A Fase1: Planos Corporativos (Capítulo 4) descreve as premissas e metas
da Prodabel de modo geral.
Na Fase 2: Compreensão do Ambiente (Capítulo 4) é feito o levantamento de
dados indispensáveis para descrever o ambiente em estudo. O detalhamento das
informações desta etapa são encontrados no Anexo.
A Fase 3: Caracterização do Tráfego (Capítulo 5) é a fase onde mais se
consumiu tempo e estudo. Está dividida em quatro partes: Definição de Variáveis,
Coleta de Dados, Transformação de Dados e Análise de Dados. O Anexo
apresenta outros gráficos e tabelas relativos a esse capítulo.
A Fase 4: Construção do Modelo (Capítulo 6) descreve os passos para a
construção do modelo no COMNET III, englobando a construção da Topologia, a
Carga de Tráfego, as Operações da Rede e o Controle da Simulação.
Na Fase 5: Validação e Calibração do Modelo (Capítulo 7), são
apresentados a validação do modelo e os cenários de situações sobre o mesmo.
A Fase 6: Previsão de Novas Cargas (Capítulo 8) aborda formas de
levantamentos para se obter informações sobre novas cargas a serem implementadas
na WAN. Desse levantamento, são escolhidos dois cenários para serem
6
representados no modelo. O resultado do comportamento do modelo após a adição de
novas cargas é feito na Fase 7: Previsão de Desempenho (Capítulo 9). A partir das
análises feitas na fase 7, é realizada uma proposta alternativa para o sistema a qual é
vista na Fase 8: Alternativas para o Sistema (Capítulo 9).
Ao final da PARTE II são apresentadas as Conclusões do trabalho (Capítulo
10), revisando os objetivos inicialmente propostos, os resultados alcançados e os
trabalhos futuros decorrentes desse.
7
Capítulo 2
Planejamento de Capacidade
Este capítulo aborda os tópicos indispensáveis à compreensão do
Planejamento de Capacidade da forma como o mesmo é aplicado neste trabalho. São
destacados os tópicos sobre Modelagem de Sistemas, Simulação e Estatística.
2.1 A Necessidade de planejar
Segundo Menascé et al.[42], planejamento é o processo de elaboração de
métodos para alcançar certos objetivos pré-estabelecidos, e capacidade de qualquer
sistema é o máximo desempenho ou saída do mesmo, ou seja, a taxa máxima que o
sistema consegue trabalhar. Por exemplo, a capacidade de uma indústria é medida
pela quantidade máxima de unidades fabricadas em um dia.
Nos sistemas de computação, um composto de hardware, software e linhas de
comunicação, são realizadas diversas solicitações pelos usuários. Ao conjunto de
programas, dados e comandos acionados pelos usuários dá-se o nome de carga de
trabalho [43]. Os sistemas de computação atendem a essas solicitações com um
determinado desempenho que pode ser medido através do tempo de resposta, taxa de
processamento, índice de disponibilidade ou taxa de utilização. Dessa forma, a
capacidade de um sistema se refere à carga de trabalho que o mesmo pode processar
sem ultrapassar os limites de desempenho estabelecidos pelos níveis de serviço.
De forma genérica, enfocando sistemas de computação, Menascé et al. [42]
define planejamento de capacidade como sendo uma previsão de quando a saturação
do sistema irá ocorrer e qual o caminho mais efetivo, em termos de custo, para atrasar
a saturação do sistema o máximo possível.
8
É praticamente impossível, na visão de Menascé et al.[42], fazer planejamento
de capacidade sem ser capaz de prever o desempenho do sistema. Existem algumas
técnicas para fazer a previsão de desempenho que serão tratadas ainda neste
capítulo. Algumas perguntas podem ser respondidas quando se usa planejamento de
capacidade, como por exemplo:
Qual a capacidade correntemente instalada?
Que serviços devem ser disponibilizados no futuro?
Que objetivos de qualidade são planejados para estes serviços?
Por que a saturação está ocorrendo?
Em que parte do sistema irá uma transação gastar mais tempo de execução no
ponto de saturação?
Quais as alternativas para evitar a saturação?
De forma geral, as variáveis de entrada para o planejamento de capacidade
são: a) a evolução da carga; b) os parâmetros do sistema; c) o nível de serviço
desejado. Já as saídas do planejamento de capacidade são: a) os pontos de
saturação e b) as alternativas de custos viáveis.
Muitas são as razões para se utilizar planejamento de capacidade; entre elas:
a) a insatisfação do usuário. Caso não sejam realizados planos para mudanças no
sistema, elas provavelmente provocarão nele um aumento de carga e o nível de
serviço desejado será comprometido; b) diminuição de produtividade. Se o nível de
serviço desejado for violado, o sistema estará funcionando precariamente, com
atrasos nas comunicações, implicando queda de produtividade; c) restrição de verbas.
Quando o ponto de saturação for alcançado sem ter sido previsto, provavelmente a
forma de otimização no sistema será realizada com a aquisição de novos
equipamentos ou software, ou mesmo com o aumento na velocidade das linhas de
comunicação, o que envolve investimentos não previstos, provocando a convivência
com o sistema saturado; d) controle do ambiente de sistemas de informação. Um
sistema saturado propicia que os diversos usuários passem a buscar alternativas das
mais diversas formas. A aquisição de software que seja executado localmente é uma
delas. Porém, alternativas como essas podem introduzir um descontrole no ambiente,
provocando duplicação de dados em vários locais, replicação de esforços na
montagem destes ambientes e dificuldades de integração das informações.
2.2 Metodologia de Planejamento de Capacidade
9
Para o planejamento de capacidade, este trabalho adotará a metodologia
proposta em Menascé et al. [42], composta de oito fases :1) Planos Corporativos; 2)
Compreensão do Ambiente; 3) Caracterização do Tráfego; 4) Construção do Modelo;
5) Validação e Calibração; 6) Previsão de Novas Cargas; 7) Previsão de
Desempenho; 8) Elaboração de Alternativas.
FIGURA 2-1: Metodologia de Planejamento de Capacidade baseada em modelo
Fonte: Menascé et al., 1994. p.24.
A primeira fase, Planos Corporativos, aborda os planos da empresa de forma
genérica, de maneira a entender suas tendências de investimento, necessidades e
expectativas. A fase de Compreensão do Ambiente tem como objetivo fazer uma
descrição das aplicações correntes e do ambiente computacional existente. São
identificados, nesta fase, a janela de tempo (time windows) e os níveis de serviços
desejados. A janela de tempo corresponde à identificação de um espaço no tempo em
10
que se quer monitorar o sistema e coletar dados. Os níveis de serviços podem ser
vistos pelo usuário através de métricas de desempenho tais como tempo de resposta,
disponibilidade, confiabilidade e custo.
Se o sistema está executando serviços do usuário, então ele está disponível.
Quanto mais longo for este período, melhor será a disponibilidade. Por exemplo, se,
durante uma semana de 40 horas, um determinado circuito ficar ativo durante 32
horas, então a disponibilidade deste circuito será de 32/40 x 100 = 80%.
A confiabilidade pode ser medida através da ocorrência de falhas durante o
processamento de serviços. A MTTF (Mean time to failure) é uma medida de
confiabilidade. Por exemplo, se, durante uma semana de 40 horas, um determinado
circuito teve uma queda na hora 10 e ficou parado 2 horas, depois teve outra queda na
hora 20 e ficou parado por 3 horas, e mais tarde teve nova queda na hora 27, ficando
parado por mais 4 horas, então o MTTF deste circuito é dado baseando-se no número
de horas que o mesmo ficou ativo depois que houve a primeira falha, dividido pelo
número de falhas depois da primeira falha. Ou seja, para este exemplo temos: (8 +
4)/2 = 6 horas. Este dado pode ser interpretado da seguinte maneira: o circuito tem
um intervalo médio, entre as falhas (MTTF), que é de 6 horas, ou seja, na média, o
circuito falha a cada 6 horas.
A fase de Caracterização do Tráfego irá lidar com a obtenção de parâmetros de
entrada. A representatividade do modelo irá depender muito da qualidade desses
parâmetros. As técnicas de medição sugerem três grandes passos: a) especificação
das variáveis a serem medidas; b) coleta de dados - com prévia seleção de
ferramentas de monitoração; c) análise dos dados - transformando dados em
informações significantes.
A seguir, é realizada a fase de Construção do Modelo, que deve refletir o
sistema real no que se refere à composição de seus componentes e a carga de
trabalho associada aos diversos objetos. O modelo deverá ser validado e ajustado na
fase de Validação e Calibração. São comparados os valores de entrada e de saída,
avaliando-se a necessidade de retorno ao modelo para alteração de parâmetros. O
processo é realizado até que o modelo seja aceitável. A calibração pode ser vista
como uma técnica de aproximação.
A Previsão de Novas Cargas é a fase que se segue na metodologia e se
propõe a abordar, por exemplo, qual a carga de trabalho prevista para o próximo ano
no ambiente computacional da empresa. Geralmente a carga de trabalho irá crescer
11
por um dos seguintes motivos: 1) novas aplicações; 2) aumento do volume de
processamento por aplicações existentes; e 3) melhorias no ambiente da aplicação.
Nessa fase, três problemas são enfrentados pelo planejador de capacidade:
1) A dificuldade em obter dados confiáveis dos usuários, especialmente
quando não existe uma terminologia comum.
2) Sistemas não completamente desenvolvidos ou a serem desenvolvidos não
propiciam estimativas confiáveis.
3) A existência de uma demanda latente. Quando um sistema se encontra
saturado, usuários e programadores evitam utilizá-lo. Ao serem
implementadas melhorias no sistema, é incorporada mais eficiência na
utilização, há um crescimento no uso e, conseqüentemente, um
crescimento de carga não esperado.
Nesta fase de Previsão de Novas Cargas, podem ser utilizados questionários e
entrevistas, obtendo-se dados sobre a taxa de chegada de transações triviais e sobre
o número de usuários interativos que terão as novas cargas. Mas nem sempre essas
informações são passíveis de serem respondidas pelos usuários.
Outra possibilidade é a utilização de técnicas de previsões. São técnicas
baseadas nos históricos de dados de determinada métrica. Sobre tal métrica são
usados métodos, como, por exemplo, um deslocamento das médias verificadas no
histórico como sendo a tendência de crescimento da aplicação para o futuro.
A fase de Previsão de Desempenho do sistema pretende antecipar o
comportamento do sistema quando as novas cargas forem adicionadas. Devido ao
grau de incerteza quando se faz a previsão de novas cargas, deve-se considerar mais
de um cenário ao se fazer a previsão do desempenho.
No processo de planejamento de capacidade não são necessárias previsões
muito acuradas, mas devem ser obtidas as tendências de forma correta.
As técnicas usadas para se fazer a predição de desempenho diferem quanto
ao custo, complexidade e acuracidade. Na FIG. 2-2, pode-se ver que a técnica de
regras práticas é considerada a técnica de mais baixa complexidade e custo e o
benchmark é a técnica mais acurada, complexa e de custo mais elevado.
12
Regras Análise Modelos de DesempenhoPráticas de
Tendências Analítico Simulação Benchmarks
Complexidade e CustoBaixa Alta
FIGURA 2-2: Técnicas de Previsão de Desempenho Fonte: Menascé et al., 1994. p.70.
As regras práticas focam recursos chaves e através de valores individuais
desses componentes, são realizadas comparações com algumas regras. Por exemplo:
a) a utilização do canal de I/O deve ser inferior a 35%; b) a utilização da CPU não
deve ultrapassar 80%; c) o pico de utilização não deve ultrapassar 90%. A relação do
pico para a média deve ser de 2.25:1. Dessa forma, a média não deve ultrapassar
40%. A técnica das regras práticas é muito simples, mas não tem muita precisão.
A técnica de análise de tendências baseia-se em dados históricos sobre o
comportamento anterior de determinada aplicação, comparando intensidade de carga
e respectivo desempenho. Neste tipo de técnica existem algumas falhas,
principalmente porque a mesma assume uma relação linear entre desempenho e
carga.
A técnica de benchmark traz resultados acurados, uma vez que ela lida com
sistemas reais e cargas reais. Porém, esse processo impossibilita a avaliação dos
impactos de novas aplicações que ainda não foram totalmente desenvolvidas.
Para a solução de modelos de desempenho há praticamente duas abordagens:
simulação e solução analítica. Os modelos de simulação são baseados em programas
que emulam diferentes aspectos dinâmicos do sistema. Como estes modelos são
muito detalhados, eles são caros para serem desenvolvidos, executados e validados.
Porém, eles fornecem informações detalhadas sobre o fenômeno a ser investigado.
Os modelos analíticos são compostos de um conjunto de fórmulas e algoritmos
que fornecem valores de medidas de desempenho. Para que estes modelos sejam
matematicamente tratados eles são menos detalhados que os modelos de simulação.
Eles são menos acurados, porém rodam mais eficientemente.
2.3 Modelagem de sistemas
Segundo Strack [60], um modelo é uma representação de um objeto, sistema,
ou idéia em alguma outra forma que não a da entidade em si. Em um sentido amplo,
13
Strack [60] referencia o modelo como sendo uma certa quantidade de informações
sobre aquilo que é representado, conforme os objetivos da análise. Para Fishman [26],
sistema é uma coleção de entidades relacionadas, sendo que cada uma possui
atributos que podem ser relacionados. O primeiro passo para estudar um sistema é
construir um modelo que possa ser baseado em teoria ou em observações empíricas.
A utilização dos modelos é ampla e se dá em todos os ramos da ciência. As
funções principais de um modelo, destacadas por Strack [60], são :
1) Ajuda na elaboração de raciocínios, pois o mesmo força uma
organização, sendo avaliadas e validadas as idéias que estão representadas.
2) Auxilia a comunicação, pois a linguagem verbal é às vezes ambígua
e através dos modelos se tem uma descrição única da estrutura.
3) Envolve menos riscos e menores custos.
4) Permite a realização de previsões, através da análise de
comportamentos antecipados.
Adotaremos aqui a forma de classificação de modelos adotada em Strack [60].
Os modelos podem ser classificados como físicos, analógicos, matemáticos e de
simulação.
Os modelos icônicos ou físicos são representados por atributos físicos
semelhantes ao sistema em questão. Eles podem ser bi ou tridimensionais. São
exemplos desse tipo de modelo os protótipos, modelos pilotos e modelos em escala.
Os protótipos usam a representação de um-para-um em relação ao sistema real. Têm
capacidade de fornecer informações com precisão, mas não facilitam modificações.
Os modelos pilotos representam uma versão operacional de um processo ou sistema,
contendo atributos essenciais. São mais flexíveis para modificações que os protótipos.
Os modelos de escala representam dimensões menores ou maiores que o sistema
real, sendo denominados de modelos de escala reduzida ou de escala ampliada.
Nos modelos analógicos, as propriedades do sistema em estudo são
representadas por propriedades análogas. Os estudos são feitos com determinadas
variáveis que depois são transpostas para outras. Os gráficos são um exemplo de
modelo analógico, assim como os modelos esquemáticos, os organogramas, os
fluxogramas e os fluxos de processos.
Nos modelos matemáticos, os símbolos algébricos são usados para
representar os componentes dos sistemas e a inter-relação entre eles. São exemplos
deste modelo: fórmulas, sistemas de equações ou desigualdades, matrizes e modelos
de pesquisa operacional.
14
Para se obter os resultados nos modelos procedurais ou de simulação, estes
são executados, em vez de resolvidos. Segundo Shannon [53], a simulação não é uma
teoria, mas uma metodologia de resolução de problemas. A simulação pode ser
dividida em dois tipos: contínua e discreta.
A simulação contínua modela sistemas em que as variáveis mudam
continuamente de valor (ex: equações diferenciais). A simulação discreta é utilizada
em sistemas nos quais ocorrem eventos que indicam o início ou o fim de uma
atividade.
As relações lógicas descrevem a dinâmica do sistema e a evolução entre os
eventos. Os resultados são obtidos medindo-se os tempos entre os eventos e
fazendo-se uma estatística quantitativa das atividades das entidades envolvidas.
A simulação discreta apresenta as seguintes características:
a) o sistema é modelado em uma rede de fluxo;
b) o sistema contém elementos que possuem funções bem definidas;
c) os elementos têm capacidade finita de processar os dados e quando
esgotada tal capacidade o atendimento é feito por filas;
d) o início e fim das operações acontecem através de eventos.
Os modelos de simulação são ainda classificados como determinísticos ou
estocásticos [39]. Se o modelo de simulação não contiver nenhum componente
randômico, então ele é chamado determinístico. Um modelo que representa uma
equação química é um exemplo de modelo de simulação determinística. Entretanto, se
alguma variável de input do modelo for randômica, então o modelo de simulação é
considerado estocástico ou probabilístico.
A compreensão da simulação está baseada em alguns conceitos da teoria de
probabilidade e de estatística. O cerne da simulação está na utilização de números
aleatórios, distribuições de probabilidade e técnicas de amostragem.
2.4 Simulação - Modelo e Técnica utilizados neste trabalho
A simulação é o modelo a ser utilizado neste trabalho. A opção por este tipo de
modelo foi feita levando-se em consideração que as relações entre as entidades do
mundo real que se pretende representar são consideravelmente complexas.
Dificilmente se conseguiria representar todas as relações deste universo em estudo
através de modelos realistas que pudessem ser avaliados analiticamente.
Sendo a simulação considerada também uma técnica para a predição de
desempenho, ela é eficiente para o propósito do estudo, visto que possibilita razoável
15
precisão nos dados gerados para o objeto a ser investigado. Segundo Claffy [19], as
tradicionais técnicas de modelagem matemáticas, em particular a teoria das filas, têm
encontrado pouco sucesso na modelagem dos atuais ambientes de rede. A técnica de
simulação vem sendo utilizada com melhores resultados para descrever o
comportamento do tráfego de redes. As análises analíticas ignoram métricas
importantes do tráfego em rede WAN, tais como a origem e destino do tráfego, assim
como quais são as aplicações que possuem mais popularidade. Claffy [19] acrescenta
ainda que os estudos analíticos são comumente utilizados em ambientes pequenos
sem conseguir confirmar vários tipos de dados como é necessário para o ambiente de
WAN.
A construção do modelo de simulação pode ser feita através de linguagens de
programação de simulação, linguagens de propósito geral ou através de simuladores.
Segundo Law & Kelton [38], as vantagens de se programar um modelo de
simulação em uma linguagem de simulação, ao invés de se programar em linguagens
de propósito geral, tais como FORTRAN, C, Pascal ou BASIC, são as seguintes :
n As linguagens de simulação fornecem muitas features necessárias para a
programação do modelo de simulação, diminuindo significativamente o
tempo de programação.
n Os modelos de simulação são mais fáceis de serem mudados quando
escritos em uma linguagem de simulação.
n As linguagens de simulação fornecem uma melhor detecção de erros
potenciais que são identificados e checados automaticamente.
Entre as vantagens de se desenvolver o modelo de simulação através de
linguagens de propósito geral temos :
n Estas linguagens são mais conhecidas.
n FORTRAN e BASIC rodam em qualquer tipo de computador, enquanto que
as linguagens de programação de simulação possuem restrições.
n Um programa eficientemente escrito em C ou FORTRAN utiliza menos
tempo de execução do que o mesmo programa escrito em linguagem de
simulação.
n As linguagens de propósito geral são mais baratas que as linguagens de
simulação.
Outra grande classe de software de simulação, além das linguagens, refere-se
aos simuladores.
16
Os simuladores são pacotes de software que permitem simular uma classe
específica de sistemas com pouca ou nenhuma programação. A maior vantagem dos
simuladores sobre as linguagens de simulação é que o tempo de desenvolvimento do
modelo é consideravelmente menor. Outra grande vantagem é que ele permite que
pessoas com pouca experiência com programação façam uso do mesmo.
Porém os simuladores também possuem desvantagens. Uma delas é que eles
são limitados a modelar somente sistemas que tenham as mesmas entidades do
simulador, além de que, se o programa possuir erros fica muito difícil de se detectar,
pois geralmente não se tem acesso ao código.
Como exemplo de linguagens de simulação, citadas em Law & Kelton [38] e
Fishman [26], tem-se: GPSS (General Purpose Simulation System), SIMAN/Cinema,
SIMSCRIPT, SLAM e SLAMSYSTEM. Como exemplo de softwares de simulação tem-
se o NETWORK e o COMNET III.
2.5 Estatística aplicada na simulação
O sucesso do estudo de simulação envolve não somente a construção de um
modelo específico para um sistema. O uso de probabilidade e estatística é parte
integrante no estudo da simulação. Essa correlação se dá devido à necessidade de
análise dos dados coletados, tirando-se conclusões válidas para tomadas de decisões
razoáveis baseadas em tais análises. A transferência do sistema do mundo real para o
modelo de simulação envolve um estudo sobre o comportamento dos dados
coletados.
2.5.1 Técnicas de análise de dados
Tabela de Frequência
Segundo definição dada em Spiegel [57], quando se utiliza grandes massas de
dados brutos, costuma-se agrupá-los em categorias e determinar o número de
indivíduos pertencentes a cada uma das classes, chamada de freqüência da classe.
Ao conjunto tabular dos dados, juntamente com as freqüências correspondentes,
denomina-se distribuição de freqüência.
Um exemplo de distribuição de freqüência pode ser visto a seguir na tabela 2-1.
Análise da tonelagem movimentada por navio(Porto de Santos, 1968)
TABELA 2-1: Exemplo de Distribuição de Freqüência
17
Qtde. de carga por navio Freqüência observada Distribuição defreqüência acumulada
0 - 500 472 0,364501 - 1000 261 0,5661001 - 1500 194 0,7161501 - 2000 115 0,8052001 - 2500 95 0,8782501 - 3000 49 0,9163001 - 3500 41 0,9483501 - 4000 17 0,9624001 - 4500 27 0,9754501 - 5000 4 0,986Acima de 5000 19 1,000
A tabela 2-1 pode ser interpretada da seguinte maneira: 36,4 % dos navios que
chegam ao Porto de Santos possuem carga entre 0 e 500 toneladas; 56,6% dos
navios que chegam ao Porto de Santos possuem carga entre 0 e 1000 toneladas
sendo que 20,2% (56,6 - 26,4) possuem carga entre 501 e 1000.
Histograma
Uma distribuição de freqüência tal como a da tabela 2-1 é mais fácil de
visualizar se representada graficamente. Um tipo de gráfico muito útil para representar
esse tipo de dados classificados é chamado histograma.
No gráfico 2-1, podemos ver o histograma relativo aos dados da tabela 2-1.
GRÁFICO 2-1: Exemplo de Histograma
Gráfico de controle
Outra importante ferramenta utilizada para analisar dados coletados é o gráfico
ou carta de controle. Segundo Werkema [63], as cartas de controle são ferramentas
para o monitoramento da variabilidade e para a avaliação da estabilidade de um
18
processo. Quando a variabilidade se mantém estável, diz-se que o processo está sob
controle estatístico; porém, se sobre o processo estão atuando causas especiais de
variação, diz-se que o processo está fora de controle estatístico.
Um gráfico de controle consiste de : a) uma linha média (LM ou MU); b) um
limite inferior de controle (LIC ou LCL); c) um limite superior de controle (LSC ou UCL)
e d) valores traçados no gráfico.
GRÁFICO 2-2: Exemplo de carta de controle
Se o processo está sob controle, todos os pontos traçados no gráfico estarão
entre as linhas dos limites de controle (UCL e LCL), como mostra o exemplo do gráfico
2-2.
2.5.2 Conceitos básicos de probabilidade
Um experimento é o processo de coleta de dados relativos a um fenômeno que
acusa variabilidade em seus resultados. O conjunto de todos os resultados possíveis
de um experimento é chamado de espaço amostral. Um evento é um subconjunto do
espaço amostral [55].
A probabilidade de um evento pode ser definida como a frequência relativa, ou
seja, a proporção de vezes que um evento ocorre em uma série suficientemente
grande de realizações de um experimento, em condições idênticas [55].
Uma variável randômica, no qual denotamos por X, é uma função que designa
um número real para cada ponto no espaço amostral. Se para cada valor de X for
associada a sua probabilidade teremos uma distribuição de probabilidades, que fica
caracterizada pela função que associa a cada valor uma probabilidade. Esta função,
chamada de função de probabilidade, é representada por F(x).
A função de distribuição F(x) (também chamada função de distribuição
acumulada) da variável randômica X fornece a probabilidade dessa variável assumir
um valor inferior a x e é definida para cada número real x como sendo
19
F(x) = P(X <= x) para -∞ < x < ∞
onde X refere-se a uma variável randômica,
x aos valores que a variável randômica X pode assumir e
P(X <= x) significa a probabilidade associada com o evento {X <= x}.
A variável randômica X é dita discreta se ela puder assumir valores que
possam ser contados, tais como x1, x2, ...xn. Portanto, uma variável randômica que
possua um número finito de valores é dita discreta.
A variável randômica que pode assumir um número incontável de valores é dita
contínua. Um exemplo de um conjunto de valores incontáveis são todos os números
reais entre 0 e 1.
2.5.3 Propriedades de algumas distribuições de probabilidade
Existem várias distribuições teóricas de probabilidade que se adequam para
determinadas situações. A seguir vamos comentar algumas distribuições, segundo a
visão de Strack [60] e Law & Kelton [38] :
• Distribuição Uniforme: É uma distribuição de probabilidade contínua usada para gerar séries de
números com distribuição uniforme entre dois valores. Esta forma de distribuição
apresenta mesma probabilidade de ocorrência entre dois valores.
• Distribuição Exponencial:
É a distribuição de probabilidade contínua que representa a distribuição dos
intervalos de tempo entre a ocorrência de eventos aleatórios distintos sucessivos,
descrevendo um processo completamente desordenado. Ela representa
convenientemente o intervalo de tempo entre chegadas a pontos de atendimento ou
ocorrências de eventos.
• Distribuição Normal:
É a distribuição de probabilidade contínua, a qual representa medidas de
fenômenos aditivos independentemente distribuídos.
• Distribuição Gamma:
20
É uma distribuição de probabilidade contínua que tem como possível aplicação
a relação com o tempo para completar alguma tarefa, podendo ser por exemplo,
conserto de uma máquina.
• Distribuição Weibull:
É uma distribuição de probabilidade contínua que tem como possível aplicação
a relação com o tempo para completar uma tarefa ou tempo para falhar uma parte do
equipamento.
• Distribuição de Poisson:
É uma distribuição de probabilidade discreta, sendo aplicável em situações em
que alguma espécie de evento ocorre aleatoriamente no tempo sobre distâncias, áreas
ou volumes. Ela se relaciona com a distribuição exponencial em problemas
envolvendo a ocorrência de eventos ordenados no tempo. A distribuição de Poisson
descreve a ocorrência de mudanças intermitentes, descontínuas, no processo em
estudo, ou seja, define o número de mudanças na unidade de tempo. A distribuição
exponencial, por seu lado, descreve o espaço de tempo entre essas ocorrências.
2.5.4 Seleção de distribuição de probabilidade para a amostra
Quando da análise de uma amostra de dados, é conveniente que se faça a
formulação de hipóteses sobre a mesma, a fim de tomar decisões. Essas suposições
são chamadas de hipóteses estatísticas e consistem em fazer considerações sobre as
distribuições de probabilidade da amostra. Alguns passos devem ser seguidos para se
conseguir avaliar que distribuição de probabilidade uma amostra de dados está
seguindo. Se for verificado que os resultados esperados para a amostra diferem dos
resultados esperados para aquela hipótese, pode-se concluir que as diferenças são
significativas e há uma tendência a rejeitar a hipótese. Para a tomada de decisão no
sentido da rejeição ou aceitação da hipótese, faz-se uso de alguns processos que
habilitam a decisão, que são chamados, segundo Spiegel [57], de testes de hipótese,
ou, segundo Law & Kelton [38] de testes de bom ajuste (goodness-of-fit). Utiliza-se
também estimadores de parâmetros para obtenção do parâmetro da amostra de forma
adequada. Por exemplo, a distribuição exponencial utiliza a média como parâmetro,
mas qual deveria ser a melhor forma de calcular a média para esta distribuição? A
seguir, são citados os passos a serem executados para se chegar à adequação de
uma amostra de distribuição de probabilidade. Estes passos são baseados nas
análises feitas por Law & Kelton[38].
21
2.5.4.1 Atividade I: Fazer hipóteses para distribuições conhecidas
Nesta etapa se decidem que tipos de distribuições serão testadas. A princípio
se faz uso de um conhecimento inicial que se refere à similaridade entre os dados da
amostra e as propriedades das distribuições teóricas. Por exemplo, se os dados são
contínuos, pode-se verificar quais distribuições contínuas possuem aplicações
semelhantes às do caso estudado. Como exemplos de distribuições contínuas se tem,
segundo Law & Kelton[38]: Distribuição Uniforme, Exponencial, Gamma, Weibull,
Normal, Lognormal, Beta, Pearson tipo V e VI e distribuição Triangular.
Por exemplo, se os dados da amostra representam o intervalo de tempo entre
chegadas a pontos de atendimento ou ocorrências de eventos, pode-se postular, por
razões teóricas, que tais dados seguem a distribuição exponencial, dada a
aplicabilidade da mesma para esta situação. Porém, pode acontecer de os dados
seguirem outra distribuição que possui aplicabilidade diferente desta.
2.5.4.2 Atividade II: Fazer estimativa de parâmetros
Neste passo, são obtidos os valores dos parâmetros da distribuições
especificadas na Atividade I. Usam-se os dados da amostra para especificar um valor
numérico para um parâmetro; desta forma, está-se estimando um parâmetro. Segundo
Law & Kelton [38], deve-se considerar o estimador de Máxima Verossimilhança, que é
superior em propriedades em comparação com outros estimadores, como o Método de
Momentos e dos Mínimos Quadrados. As propriedades que diferenciam esses
métodos podem ser vistas em Breiman (1973, pp.85-88) e Kendall & Stuart (1979, cap.
18), citados em Law & Kelton [38] . Por serem estas diferenças baseadas em
demonstrações matemáticas e estatísticas, elas não são demonstradas aqui.
2.5.4.3 Atividade III: Determinar o quanto as distribuições estão ajustadas
Para verificar se as distribuições são representativas da amostra, ou mesmo
para selecionar qual a distribuição que melhor se ajusta à amostra de dados, realizam-
se alguns testes de bom ajuste (goodness-of-fit).
22
Um exemplo de teste de bom ajuste é o teste do qui-quadrado (χ2) . O qui-
quadrado é uma medida de discrepância existente entre as freqüências observadas e
esperadas e é definida como
k
χ2 = ∑ (oj - ej)2 / ej
j=1
Usando-se a fórmula acima, que relaciona a freqüência esperada (ej) com a
freqüência observada (oj) , e verificando-se que o valor de χ2 é maior do que valores
críticos tais como χ20,95 ou χ2
0,99, conclui-se que as freqüências observadas diferem
significativamente das freqüências esperadas, e desta forma pode-se rejeitar a
hipótese no nível de significância correspondente.
Outro teste também utilizado para se fazer bom ajuste é o de Kolmogorov-
Smirnov. Esse teste tem algumas vantagens sobre o do qui-quadrado, como o fato de
que, ele não precisa agrupar os dados em intervalos, como o qui-quadrado faz, e
portanto não enfrenta problemas sobre qual a melhor maneira de agrupar os dados.
Desta forma, nenhuma informação é perdida. Entretanto o teste de Kolmogorov-
Smirnov (KS) não é aplicado para todas as distribuições, ao contrário do qui-quadrado.
Ademais, o KS usa fórmulas mais complicadas. Mais detalhes sobre esses testes
podem ser vistos em Law & Kelton[38], pp.382-393.
23
Capítulo 3
A ferramenta COMNET III
O COMNET III é um simulador que possui menus e gráficos e é voltado para
modelar sistemas de rede WAN e LAN. É um produto da CACI, empresa que possui
experiência com tecnologia de simulação há 35 anos.
Um simulador com essas características, voltado para a modelagem dos
objetos do mundo real que este trabalho se propõe a analisar, facilita o planejamento
de capacidade e dispensa a necessidade de programação. O tempo de programação
para o estudo deste mesmo sistema poderia ser muito longo, inviabilizando o objetivo
final, que é fazer planejamento de capacidade.
Além das vantagens técnicas oferecidas pelo COMNET III, a sua utilização para a
realização deste projeto deveu-se também ao fato do mesmo estar disponível no DCC
(Departamento de Ciência da Computação) da Universidade Federal de Minas Gerais.
No COMNET III User’s Manual [12], encontram-se descrições da abrangência
da ferramenta, bem como de seu funcionamento. Alguns desses aspectos são
abordados a seguir.
3.1 Escolhendo o nível de detalhe correto
O grau de sucesso do modelo de simulação depende do nível de detalhe
escolhido para responder adequadamente às perguntas desejadas. Muitos detalhes
poderão fazer com que sejam perdidos importantes aspectos do comportamento do
sistema. O COMNET III permite basicamente dois níveis de detalhes: a análise de um
backbone de rede e a análise de uma rede local.
Para a análise de um backbone de rede é necessário saber o tamanho e a
freqüência das transações, o número de usuários e sua localização geográfica. Pode-
24
se identificar, por exemplo, se haverá gargalos nas linhas ou se a capacidade do
roteador será insuficiente quando, por exemplo, for colocada uma nova aplicação na
rede.
Na análise de uma rede local, pode-se, através do COMNET III, fazer uma
identificação mais detalhada sobre as características de hardware dos sistemas finais,
ou seja, através de informações fornecidas para o modelo, como a velocidade do
processador e o acesso a disco, pode-se prever como ficará o desempenho do
sistema em uma situação de aumento de carga de trabalho.
3.2 Passos da Construção do Modelo de Simulação
Para a construção do Modelo de Simulação, serão descritos os seguintes
passos básicos: Topologia da Rede, Tráfego e Carga de Trabalho da Rede,
Operações da Rede e Controle da Simulação.
3.2.1 Topologia da Rede
Neste primeiro passo da construção do modelo, são identificados os objetos
que irão compor a topologia, sendo eles basicamente: a) os nós, que representam o
hardware (computadores, roteadores, switches, micros em rede local); b) os links
(CSMA/CD e ponto-a-ponto), que trafegam dados entre os nós; e c) os arcos
(representados por linhas), que conectam os nós aos links.
3.2.2 Tráfego da Rede e Carga de Trabalho
O tráfego de rede se refere às mensagens que são enviadas entre os nós da
topologia, e a carga de trabalho se refere a uma atividade interna do nó processador.
Há dois tipos de “origens” no COMNET III: a) as origens de aplicações, que executam
comandos que geram tráfego na rede ou carga de trabalho no nó; b) as origens de
tráfego, que são fontes mais simples e que somente geram tráfego entre os nós.
3.2.3 Operações de Rede
As operações da rede especificam como as mensagens são roteadas através da
rede com um algoritmo de roteamento e como elas são transmitidas na rede através
de um protocolo de transporte.
O COMNET III trabalha com protocolos de roteamento estático e dinâmico. Entre
os dinâmicos, ele implementa o RIP (Rounting Information Protocol), o IGRP (Interior
Gateway Rounting Protocol) e o OSPF (Open Shortest Path First).
25
3.2.4 Controle da Simulação
Depois da construção do modelo, e antes do início da simulação, são usados
alguns comandos para fazer o controle da simulação. Entre eles, pode-se informar o
tempo de duração da simulação e o número de replicações da mesma. Pode-se ainda
utilizar algumas opções de animate ou trace, nas quais se pode habilitar a visualização
do trânsito dos pacotes, ou o tempo decorrido da simulação.
3.3 Forma de cadastramento das informações no Comnet III -Identificando variáveis básicas para o modelo
Abaixo, são listadas quais são efetivamente as variáveis que devem ser
buscadas no mundo real para a construção dos objetos do modelo de simulação
utilizando o COMNET III. A relação destas variáveis está direcionada para a
construção de um modelo cujo enfoque é o backbone.
I. Nó: Computer Group
A. Informações básicas utilizadas:
1. Número de micros.
II. Source Message
A. Informações básicas utilizadas:
1. Protocolo de transporte.
2. Lista de destinos.
3. Distribuição de probabilidade relativa a :
n Intervalo de entre-mensagens.
n Tamanho das mensagens.
III. . Link: CSMA/CD
A. Informações básicas utilizadas:
1. Nome : endereço IP da LAN.
IV. . Nó: Router.
A. Protocolo de roteamento: é informado através do menu
define/backbone routing.
B. Informações básicas utilizadas:
1. Nome: endereço IP da porta WAN.
2. Tabelas de roteamento.
3. Bus Rate (Mbps): velocidade do barramento em Mbps.
26
V. Link: point-to-point
A. Informações básicas utilizadas: velocidade da linha.
VI. Response Message:
A. Informações básicas utilizadas:
1. Protocolo de transporte.
2. Distribuição de probabilidade relativa ao tamanho das
mensagens.
Muitas destas variáveis podem ser obtidas de forma simples, através de um
levantamento sobre a estrutura física das redes na WAN, por exemplo. Porém, as
variáveis que se referem ao tamanho das mensagens, aos destinos dessas
mensagens e ao interarrival dessas mensagens, são informações difíceis de se obter,
requerendo muito tempo, estudos e refinamentos dos dados, como poderá ser visto no
capítulo Caracterização da Carga de Trabalho.
Os objetos descritos acima podem ser identificados nos modelos gerados pelo
COMNET III, através dos ícones da FIG.3-1.
27
FIGURA 3-1: Ícones do COMNET III utilizados na modelagem da Rede Municipalde Informática
a) nó: roteador b) Source: Message c) Source: Response d) nó: servidor e) link:ponto-a-ponto f) link: CSMA/CD g) nó: computer group
a) roteador b) Source: Message
c) Source: Response d) Servidor
e) link: ponto-a-ponto f) link: CSMA/CD
g) computer group
28
PARTE II - Aplicação da Metodologia de Planejamento deCapacidade à WAN da RMI
Nesta segunda parte será aplicada a metodologia de Planejamento de
Capacidade a um objeto empírico, que é a WAN da Rede Municipal de Informática. As
etapas são descritas com detalhes, referenciando as ferramentas utilizadas.
CAPÍTULO 4
FASE 1: Planos Corporativos eFASE 2: Compreensão do Ambiente
4.1 FASE 1: PLANOS CORPORATIVOS
Quando a Prodabel realizou a descentralização de seu ambiente mainframe
IBM para plataformas RISC’s, ela optou, como guia desta mudança, pela adoção de
sistemas abertos. Adotar sistemas abertos significa, para a Prodabel, garantir a
interoperabilidade entre software e máquina, possibilitando a escolha, no mercado, da
melhor opção tecnológica, criando independência de fornecedores, abrindo um leque
de opções tecnológicas.
Ainda adotando esta premissa técnica, a Prodabel pretende fazer novas
alterações em seu ambiente. No caso brasileiro, a referência nacional de padrões
abertos na informática é definido pelo POSIG (Perfil OSI do Governo Brasileiro).
Enquanto empresa pública, a Prodabel vem procurando se adequar a esse perfil.
Em 1996, a empresa mudou o seu nome de “Processamento de Dados do
Município de Belo Horizonte” para “Empresa de Informática e Informação do Município
de Belo Horizonte”. Tal mudança de nome atualiza o papel que hoje a Informática tem.
Supera a relação anterior, em que o papel dos computadores era realmente o de
29
unicamente processar dados. A evolução tecnológica e a disseminação dos PC’s
(Personal Computer) como ferramenta acessível abriram caminhos para que os
computadores viessem a informatizar os sistemas e ser meio de acesso e
transformação de informações. Neste sentido, a Prodabel atualiza o seu papel de
acordo com o perfil de empresa que o nosso tempo vem demandando, levando para a
Prefeitura de Belo Horizonte ações que fazem da Prodabel muito mais que um
simples órgão processador de dados.
A missão da Prodabel, definida em documento interno, é “Coordenar as
políticas públicas de informação e informática e disponibilizar os recursos tecnológicos
para a sua execução, com o objetivo de garantir, com a PBH (Prefeitura de Belo
Horizonte), os direitos e a participação do cidadão frente ao poder público e nas
decisões de governo, através da democratização e disseminação de informações com
qualidade e segurança” [47]. A Prodabel, portanto, deve “ser um centro dinâmico de
inovações para a administração pública municipal, agente de mudanças institucionais,
requalificação do trabalho, desenvolvimento e normalização, no uso da tecnologia da
informação, até 1988” [49].
As diretrizes da Prodabel para o período de 1997 e 1998, descritas em [49]
são:
1) Ampliar e consolidar o processo de ações cooperadas e em parcerias, com
instituições públicas e privadas, estabelecendo 3 novas ações até 12/97.
2) Consolidar o processo de descentralização, garantindo a evolução
tecnológica, organizacional e dos processos de trabalho, atingindo 60% dos
ítens programados até 12/97.
3) Aumentar a participação de outras fontes, além do tesouro municipal, em
20% do faturamento da Prodabel, até 12/98.
4) Reforçar o processo de modernização e informatização de gabinetes,
através da implantação de ferramental tecnológico adequado, priorizando a
implantação de fluxo de tramitação de documentos com protocolo entre os
gabinetes da PBH, até 12/97.
5) Implantar um programa de qualidade, objetivando a satisfação da
sociedade em geral, da administração municipal e dos trabalhadores,
buscando atingir índice médio de 70% da série ISO 9000, até 07/98.
6) Consolidar a Prodabel como centro ativo na democratização de
informações sobre a cidade (e para o cidadão), através da criação de 10
programas neste sentido, até 12/97.
30
7) Aprimorar a gestão de recursos humanos, priorizando a implantação de um
modelo de avaliação de desempenho, até 12/97.
8) Definir e implantar uma política de relacionamento institucional, em todos os
níveis, buscando a melhoria da satisfação do usuário em 60%, até 12/97.
9) Estabelecer o programa de qualificação e capacitação de pessoal,
priorizando a implantação do centro de capacitação profissional, até 12/97.
10) Instituir o “Selo Cidadão” na Prodabel, definindo e implantando modelo e
metodologia, até 12/97.
O Planejamento de Capacidade se encaixa na diretriz de número 2, pois
pretende consolidar um aspecto do processo de descentralização, sendo este aspecto
a malha de comunicação da WAN, garantindo também a evolução tecnológica das
tecnologias de comunicação.
A Prodabel pretende dar rumo às suas atualizações tecnológicas e conjugar os
seus projetos, de acordo com sua missão, visão e diretrizes corporativas.
4.2 FASE 2: COMPREENSÃO DO AMBIENTE
4.2.1 Levantamento da Topologia
A topologia em estrela foi inicialmente prevista para a RMI através de projeto
realizado pela BRISA (Sociedade Brasileira para Interconexão de Sistemas Abertos).
Porém, em constatação posterior, verificou-se a impossibilidade de adoção de tal
topologia, naquele momento, pelo alto custo envolvido. Foi criado um grupo de trabalho
interno que elaborou uma topologia alternativa para a RMI. A nova topologia indicada
por este grupo de trabalho foi uma topologia em anéis, onde cada rede local possui no
mínimo dois caminhos para comunicação. Existe ainda um anel principal que interliga
todos os demais anéis e que é considerado aqui como o backbone da RMI. Utilizando
essa topologia em anéis, segundo a avaliação do grupo de trabalho, os roteadores
seriam de menor capacidade e conseqüentemente de menor custo.
Na figura 4-1, pode-se ver a topologia em anéis proposta para a RMI. Cada anel,
nessa figura representado apenas por um número, é na verdade composta de um
conjunto de redes locais. No Anexo pode ser vista a composição de cada anel, ou seja,
quais as redes locais, representadas pelos órgãos municipais, fazem parte de cada anel
(FIG. 11-1 a FIG. 11-11). Por exemplo, o anel 3 (FIG.11-4) descrito no Anexo é
composto por 4 redes locias, sendo elas, a rede da ARN (Administração Regional
Norte), da SLU (Superintendência de Limpeza Urbana), do HOB (Hospital Odilon
31
Behrens) e da ARVN (Administração Regional Venda Nova). Na figura 4-1 os anéis
estão numerados de 1 a 10 e o backbone central, com ligações em apresentadas em
linhas pontilhadas, compõem-se das redes da Prodabel, PBH1212 e Tupis.
A PBH (Prefeitura de Belo Horizonte) possui diversas secretarias e autarquias.
Muitas delas localizam-se no prédio sede da PBH, na Av. Afonso Pena, 1212, daí a
abreviatura dada pela Prodabel à este prédio sede, chamando-o de PBH1212. No
prédio da RuaTupis também existem diferentes secretarias. Outros órgãos da PBH
estão localizados de forma distribuída na grande Belo Horizonte. A tabela 11-2
descreve os órgãos da PBH e as entidades diretamente vinculadas.
PDBL
TUPIS
PBH 1212
63 8729
5
4
1
10
FIGURA 4-1: Topologia em Anel da RMI
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.2.
4.2.1.1 Levantamento dos equipamentos de rede utilizados1. Nos prédios da PBH1212, PRODABEL e TUPIS são utilizados dois roteadores
CISCO 4500, com 2 portas Ethernet e 5 interfaces seriais.
2. No prédio da BHTRANS são utilizados dois roteadores CISCO 2500, com 1 porta
Ethernet e 2 interfaces seriais.
32
3. No prédio da SMSA (Secretaria Municipal de Saúde) são utilizados dois roteadores
CISCO 2500, com 1 porta Ethernet e 2 interfaces seriais. A SMSA pretende fazer
conexão no futuro com mais 139 pontos remotos.
4. Em todos os demais pontos da rede são utilizados 1 roteador CISCO 2500, com 1
porta Ethernet e 2 interfaces seriais. Está prevista uma reserva técnica de
roteadores.
4.2.2 Levantamento de equipamentos e circuitos da RMI
A RMI possui 51 circuitos de linha privativa utilizando PPP (Point-to-Point
Protocol), com as seguintes velocidades :
3 circuitos de 64 Kbps ,
3 circuitos de 128 Kbps e
45 circuitos de 19.2 Kbps.
A RMI utiliza também X.25 para sub-redes da SMSA, BHTRANS e para
algumas redes do anel 10.
Existem hoje na RMI cerca de 48 redes locais, 56 roteadores, 1014
microcomputadores e 106 hubs. A distribuição desses equipamentos nas redes pode
ser vista no Anexo (FIG. 11-1 a 11-11).
4.2.3 Configuração de software e hardware
Segundo Menascé et al. [42], uma estrutura em camadas que caracteriza um
sistema de computação pode ser representada tipicamente, conforme mostra a figura
4-2.
33
Aplicações do Usuário
SoftwaresDBMS Transações Comandos
Sistema Operacional
Hardware
FIGURA 4-2: Arquitetura de um sistema computacional
Fonte: Menascé et al., 1994. p.26.
A camada de hardware dos computadores que compõem a RMI engloba
basicamente microcomputadores e estações de trabalho RISC’s. Os
microcomputadores são PC’s 386, 486 ou Pentium. As máquinas RISC’s são
geralmente servidoras e hoje na RMI existem RISC’s da IBM, SUN e Digital.
A maioria das máquinas clientes utilizam o Sistema Operacional MS-DOS, e
em menor proporção, o Windows 95. Para as máquinas servidoras, é utilizado, em
maior proporção, o Unix (AIX, Solaris, Digital Unix, SCO Unix, Linux), mas também
existem servidores Windows NT e OS/2.
Os Bancos de Dados utilizados são: Adabas (em maior proporção), Oracle e
SQL Server.
4.2.4 Levantamento de aplicações e serviços
Aplicações
A Prodabel, em agosto de 1996, finalizou a migração de todos os seus
sistemas, do mainframe para a plataforma Unix. Atualmente, esses sistemas são
acessados, pelos usuários, basicamente através do serviço de emulação de terminal
(TELNET). Existem hoje 22 sistemas com essas características, disponibilizados em 6
servidores pela RMI. Esses sistemas estão descritos no Anexo (Tabela 11-8).
Existem outras aplicações na RMI, porém o uso e acesso são de âmbito da
rede local e, assim sendo, para efeito deste trabalho, não foram descritos, pois o
interesse se concentra no fluxo de dados da WAN.
34
Serviços
A RMI faz uso de uma ferramenta de workflow e correio eletrônico, o Lotus
Notes. Para este serviço existem cerca de 700 usuários e quatro servidores. Entre
estes servidores, apenas dois são acessados pela WAN, sendo eles : 1) o servidor de
nome Lapa disponível na PBH1212 e 2) o servidor Danville, disponível na Prodabel.
Os demais servidores atendem a redes locais. Foi feita a classificação do Lotus Notes
neste momento como um serviço da RMI, pelo fato de o mesmo ser acessado
principalmente para a utilização do correio eletrônico. Porém, existem planos para que
ele seja largamente utilizado como ferramenta de workflow.
O gerenciamento da RMI foi também considerado como um serviço. Esse
gerenciamento é feito pelo ISM (Integrated System Management), que é uma
ferramenta de gerenciamento da Bull, e baseia-se no protocolo SNMP (Simple
Network Management Protocol) ( mais detalhes sobre o gerenciamento podem ser
vistos na Fase 3). O servidor está localizado na Prodabel e através dele é realizado o
gerenciamento dos agentes da RMI, sendo eles, basicamente, os roteadores e
servidores.
4.2.5 Levantamento de protocolos de comunicação
Nas redes locais da RMI é utilizado o protocolo NETBEUI disponível para as
redes Windows for Workgroups. Porém, todo o acesso externo é feito através da pilha
de protocolos TCP/IP. Desta forma, todos os microcomputadores interligados na RMI
fazem uso de dois protocolos.
No âmbito da WAN é utilizado basicamente o protocolo PPP na camada de
enlace, o IP na camada de rede e o TCP na camada de transporte.
Atualmente o protocolo de roteamento utilizado nos roteadores é o roteamento
estático, porém tem-se como meta de curto prazo implantar o OSPF (Open Shortest
Path First) que é um protocolo de roteamento dinâmico.
4.2.6 Janela de tempo e Níveis de Serviços
A identificação da janela de tempo permite saber qual o intervalo de tempo que
deverá ser monitorado. As medidas coletadas servirão como entrada para o processo
35
de caracterização de carga [42]. Várias janelas de tempo podem ser identificadas de
acordo com o objetivo da caracterização da carga. Por exemplo, pode-se querer
trabalhar com o horário de 20h da véspera de Natal em um magazine para prever o
comportamento do sistema neste horário.
No caso da RMI, a janela de tempo escolhida foi o horário de pico do dia de
maior volume de tráfego de dados do mês. Outras janelas de tempo podem ser
escolhidas, como, por exemplo, o dia de maior movimento para pagamento do IPTU
(Imposto Predial e Territorial Urbano), que geralmente são os 2 dias úteis anteriores
ao dia 15 de cada mês.
Com relação aos níveis de serviços da RMI, deve-se levar em consideração
que, em um ambiente computacional, os usuários não querem ter restrições de uso ao
ambiente devido a situações como queda de link, alta utilização do canal de
comunicação, contenção de memória, alta taxa de utilização de CPU, entre outros.
Segundo Menascé et al. [42], os usuários percebem a qualidade do serviço através
das seguintes métricas de desempenho:
n Tempo de resposta
n Disponibilidade
n Confiabilidade
n Custo
A fim de verificar a atual situação dos níveis de serviço da WAN da RMI, foi
feito um levantamento de dados por um período limitado de tempo (mês de maio/97).
Para se ter uma avaliação mais apurada, é necessário armazenar históricos dos dados
para depois referenciar a disponibilidade, confiabilidade e custo em relação a um
período de tempo mais sistemático, como por exemplo, mês, trimestre, semestre, ano.
A disponibilidade dos links da RMI pode ser vista na tabela 11-3 do anexo.2
Para o período entre 1 e 31 do mês de maio, a disponibilidade dos link 501-
6732 da RMI foi de:
disponibilidade (%) = (intervalo de tempo - intervalo de tempo em down)/
(intervalo de tempo)
disponibilidade (%) = (720 - 145.55) / 720 = 0.799
O link 501-6732 ficou disponível 79,9% durante o mês de maio. Acrescentamos
que os motivos das paralisações não estão registrados na tabela 11-3, porém, na
maioria das vezes que ocorre queda nos circuitos da RMI a reabilitação dos mesmos
só é realizada com chamado técnico à concessionária. No mês de maio a Telemig
2 Os dados desta tabela foram cedidos pela Prodabel / DIOPE/DIR/GRM
36
ainda estava fazendo algumas implantações de circuitos na RMI o que poderia estar
ocasionando certa instabilidade nos circuitos.
Uma medida de confiabilidade é o MTTF (Mean Time to Failure). Esta medida
será utilizada para avaliar a confiabilidade dos links da RMI. O MTTF de circuito é
dado baseando-se no número de horas que o mesmo ficou ativo depois que houve a
primeira falha, dividido pelo número de falhas depois da primeira falha. A seguir, para
exemplificar, é realizada uma análise da confiabilidade de alguns circuitos da RMI
durante o mês de maio.
Confiabilidade do circuito 501-7103 = [(310.4 + 21.53 + 5.55 + 24) / 4] = 90.37
Dizer que o MTTF no mês de maio do circuito 501-7103 foi de 90.37 significa
que o circuito falhou, em média, a cada 90h22 .
Confiabilidade do circuito 501-6682 = [(21.28 + 238.10 + 333.31)/3] = 197.56
Dizer que o MTTF no mês de maio do circuito 501-6682 foi de 197.56 significa
que o circuito falhou, em média, a cada 197h33.
O custo3 atual mensal dos links da RMI está em torno de:
3 circuitos de 64 Kbps = 3 x R$ 452,11 = 1.356,33
3 circuitos de 128 Kbps = 3 x R$ 522,30 = 1.566,90
e 45 circuitos de 19.2 Kbps = 45 x R$ 249,55 = 11.229,75
Total mensal = 14.152,98
A métrica relativa ao tempo de resposta não foi contemplada neste trabalho
pelo fato de ela ser uma métrica fim-a-fim, ou seja, ela está associada ao tempo que o
usuário recebe a resposta de um comando. Isto não envolve somente a rede WAN,
mas também o tempo de tráfego na LAN e de processamento no servidor. Em Claffy
[19], essa visão sobre a métrica de tempo de resposta é reforçada, e ele a classifica
como uma métrica centrada no servidor e não como uma métrica centrada em rede.
Aqui se utilizou, no entanto, como métrica de desempenho para a WAN, a taxa de
utilização dos links. O valor dessa métrica será visto no Capítulo 5.
3 Os preços dos circuitos estão baseados na tabela de preços da Telemig/UNG
37
Capítulo 5
FASE 3: Caracterização do Tráfego
A caracterização do comportamento do sistema real pressupõe a coleta de
dados que servirão de entrada para o modelo que representa tal sistema. Rose4,
citada em Menascé et al. [42], considera que a coleta de dados ou medição pode ser
vista como um processo de observação da operação do sistema por um período de
tempo e gravação dos valores das variáveis que são relevantes para uma
compreensão quantitativa do sistema. Segundo Menascé et al.[42], o processo de
medição envolve três grandes passos: 1) Definição de variáveis; 2) Coleta de Dados;
3) Análise e transformação dos dados.
5.1 Definição de variáveis
A escolha das variáveis, neste trabalho, está concentrada na perspectiva da
rede WAN. Claffy [19] classifica dois tipos de perspectivas, sendo uma centrada no
servidor e outra na rede. A diferença entre estas duas perspectivas fica mais aparente
quando se está analisando rede de longa distância, em que existe um grande número
de usuários, serviços e aplicações originados de diversos pontos.
A WAN da RMI será analisada quanto aos seguintes aspectos:
1. volume de dados trafegados no backbone central;
2. horário de pico;
3. aplicações do protocolo TCP/IP;
4. origem e destino das mensagens;
4 Rose, C. “A Measurement procedure for queuing network models of computer systems”. ACMComputing Surveys. Vol. 10, No. 3, Setembro 1978.
38
5. intervalos de tempo entre chegadas das mensagens originadoras de
tráfego;
6. tamanho das mensagens que chegam ao backbone central e cuja origem
são as redes pertencentes aos diversos anéis;
7. tamanho das mensagens de resposta geradas pelos servidores;
8. utilização dos canais de comunicação.
Para isto é necessário fazer a coleta de dados das seguintes variáveis :
1. octetos de entrada e saída de cada roteador durante alguns dias;
2. octetos de entrada e saída de cada roteador a cada meia hora;
3. porto utilizado nos pacotes;
4. IP origem e IP destino;
5. timestamp de geração do pacote;
6. octetos transferidos em cada pacote de origem;
7. octetos transferidos em cada pacote de resposta;
8. taxa de utilização dos canais de comunicação.
Essas informações focam a análise sobre o comportamento da WAN. As
variáveis mudam de acordo com o que está se querendo caracterizar. Por exemplo,
para analisar o comportamento da memória virtual de um computador, deve-se
escolher variáveis como, por exemplo, taxa de page fault e throughput de paginação
de discos.
A escolha das variáveis acima pretende cobrir uma compreensão ampla do
ambiente. Obtendo-se o volume de dados trafegados no backbone central poder-se-á
verificar qual o roteador mais demandado e qual a média de transferência diária de
dados. O horário de pico deve ser identificado a fim de se fazer a coleta de dados das
demais variáveis neste horário e não em qualquer outro. Já as variáveis extraídas do
pacote, que se referem ao timestamp e tamanho das mensagens, deverão ser usadas
para análise de reconstrução estatística de tráfego. As informações de origem, destino
e porto dos pacotes poderão gerar informações de porcentagem de uso diversas,
como poderá ser visto no item 5.4.
39
5.2 Monitores para coleta de dados
Para realizar a coleta das variáveis já definidas, fez-se uso de alguns
monitores. Para Ferrari et al.5, citada em Menascé et al. [42], os monitores são
ferramentas para medição do nível de atividade de um sistema de computação. A
principal função deles é a de coletar dados. São classificados como a) monitores de
hardware; b) monitores de software; c) monitores híbridos. Já Sauer [51] prefere
classificá-los como a) monitores de hardware; b) monitores de software; e c) monitores
de account. Menascé et al. [42] enquadra os monitores de account como monitores de
software.
Os monitores de hardware são geralmente probes (sondas eletrônicas) que
são colocadas no sistema computacional para registrar as medições. Os monitores de
hardware são portáveis e geralmente não consomem recursos do sistema.
Os monitores de software consistem de rotinas colocadas no software de um
sistema computacional para registrar o estado e eventos do sistema. Os monitores
híbridos são aqueles que combinam monitores de hardware e de software. Os
monitores de account são geralmente ferramentas disponíveis nos sistemas
operacionais, tais como o VMS Accounting ou o comando sar do Unix.
Para realizar a coleta de dados neste trabalho foram utilizados comandos de
gerenciamento SNMP (Simple Network Management Protocol) e o Tcpdump. Para
cada um desses monitores estaremos descrevendo a seguir as etapas de coleta de
dados, transformação e análise de dados. Os monitores abrangeram a coleta de
diferentes variáveis previamente identificadas em 5.1. A primeira monitoração
realizada foi através do gerencimento SNMP que basicamente identificou a janela de
tempo, o fluxo e o volume de dados nos grandes roteadores da RMI. À partir das
análises sobre os dados coletados com o SNMP foi então realizada outro tipo de
coleta de dados com outro monitor, sendo ele o tcpdump. Os dados do tcpdump foram
efetivamente os dados de entrada para o simulador. Sobre estes dados foram feitas
análises estatísticas sobre a distribuição de probabilidade para os intervalos entre
chegada das mensagens e a distribuição de probabilidade para o tamanho das
mensagens. Também foram analisados os destinos dessas mensagens geradas.
5 Ferrari, D., Serazzi, G., Zeigner, A. “Measurement and Tunning of Computer Systems”. Prentice Hall.Englewood Cliffs. N.J.1983.
40
5.2.1 Gerenciamento SNMP
Para a coleta de dados referentes aos ítens “volume de dados trafegados no
backbone central” e “horário de pico”, foram utilizados comandos de gerenciamento
SNMP.
A estrutura do gerenciamento SNMP (Simple Network Management Protocol) é
formada por quatro componentes básicos, similares aos modelos de gerenciamento
OSI [7]. São eles: a entidade gerente ou estação gerente, o agente, o protocolo de
gerenciamento e a base de informações de gerenciamento.
O Gerente
A estação de gerenciamento corresponde a um sistema hospedeiro que
executa aplicações de gerenciamento (entidade gerente). Essas aplicações monitoram
e, em alguns casos, controlam a operação de recursos da rede. Um gerente pode
obter informações atualizadas sobre os objetos gerenciados e controlá-los. Para isso,
transmite operações de gerenciamento aos agentes.
O Agente
O agente reside num recurso da rede e é chamado de agente SNMP. Entenda-
se por recurso da rede (ou objeto gerenciado) um hospedeiro (microcomputador,
terminal, impressora, etc.), um sistema gateway (roteador) ou um equipamento de
meio (modem, bridge, hub ou multiplexador). Um agente pode transmitir ao gerente as
notificações emitidas pelos objetos gerenciados.
O protocolo de gerenciamento usado entre a estação de gerenciamento e o
agente é o SNMP. Esse protocolo transporta as operações de gerenciamento que
devem ser executadas nos objetos gerenciados. Cada objeto é visto como uma
coleção de variáveis cujo valor pode ser recuperado ou alterado. Esse mecanismo
possibilita a execução das duas funções básicas de gerenciamento: a monitoração e o
controle de recursos.
As informações de Gerenciamento ( MIB I e MIB II)
A base de dados das informações a serem gerenciadas é chamada de MIB
(Management Information Base). O SNMP foi originalmente desenvolvido para
satisfazer a uma necessidade imediata de gerenciamento das comunicações TCP/IP
41
na Internet. A primeira MIB desenvolvida é chamada de MIB-I. Ela foi descrita pela
RFC-1066 (Request for Comments) em maio de 1990 e continha 114 objetos ou tipos
de informações que eram vistos como essenciais para o gerenciamento de redes
baseadas em TCP/IP. Depois de ser implementada e experimentada na Internet, a
MIB-I teve novas definições adicionadas. Os resultados foram publicados na RFC
1213: Management Information Base for Network Management of TCP/IP based
Internets: MIB-II [25].
Os objetos gerenciados no modelo SNMP constituem um contexto de
informações que incluem dados de estado, configuração e de estatística que são
armazenados nos dispositivos.
A ISO (International Organization for Standardization) e a CCITT (International
Telegraph and Telephone Consultative Committee), promoveram a idéia de estruturar
informações em uma árvore global de nomeação, designando um identificador para
qualquer objeto que necessite de um nome. Essa árvore é usada para designar
qualquer informação de interesse de padronização da organização. A figura 5-1
mostra a árvore global de nomeação sendo que à partir do nodo private, foi
acrescentado como exemplo de uma MIB proprietária, a estrutura da MIB da Cisco.
MIB’s proprietárias são aquelas definidas por fornecedores ou corporações e
estão localizadas sob o nodo private e enterprise. Os fornecedores podem contactar o
IAB (Internet Architecture Board) para solicitar uma sub-árvore na árvore de
gerenciamento de informações. O fornecedor poderá definir variáveis que acha
necessário para gerenciar seu produto. Existem mais de 800 fornecedores registrados
desta forma. Apenas para dar uma amostra desta participação, vemos abaixo uma
relação de números designados pelo IAB para alguns fornecedores:
1 - Proteon
2 - IBM
9 - Cisco
18 - Wellfleet
36 - DEC
45 - SynOptics
63 - Apple Computer Inc.
119 - NEC Corporation
122 - Sony
311 - Microsoft
42
FIGURA 5-1: Hierarquia da MIB da Internet com destaque para a MIB daCisco
5.2.2 O Tcpdump
Foi utilizado o programa Tcpdump para a coleta de dados referente as
aplicações do protocolo TCP/IP, aos intervalos de tempo entre chegadas das
mensagens, ao tamanho das mensagens que chegam ao backbone central vindos das
redes pertencentes aos anéis e à origem e destino dos pacotes.
Outros softwares poderiam ter sido usados para tal monitoração. O COMNET
III possui interface para arquivos de tráfego gerado pelos produtos: Network General
43
Distributed Sniffer System, HP NetMetrix, Frontier Software NETscout, CompuWare
EcoNET e 3COM KANsentry [13].
O Tcpdump foi utilizado, pois é um produto freeware da Internet e captura
todas as informações que foram definidas. Os produtos acima citados possuem mais
recursos e geram arquivos no formato lido pelo COMNET III, porém sua aquisição,
durante a realização deste trabalho, não foi possível. O Tcpdump pode ser obtido na
Internet pelo endereço de FTP
ftp://ftp.is.co.za/.l/networking/ip/diagnostic/tcpdump/tcpdump-3.0.4.Z.
O Tcpdump faz um dump do tráfego da rede, coletando através da porta de
rede do microcomputador todas as informações referentes à comunicação em rede.
Abaixo é mostrada a saída de dados quando de sua execução:
09:32:01.913177 10.13.4.1.telnet > 10.13.4.2.12051: P 1028619554:1028619688(134) ack303599152 win 1608009:32:01.933177 10.13.4.2.12051 > 10.13.4.1.telnet: . ack 134 win 53609:32:01.943177 10.13.1.5.7869 > 10.13.4.1.1038: P 87816221:87816373(152) ack 35127268win 812009:32:01.943177 10.13.1.1.telnet > 10.13.4.62.4464: . ack 540149 win 1606009:32:01.953177 10.13.1.1.telnet > 10.13.4.62.4464: P 0:93(93) ack 1 win 1606009:32:01.963177 10.13.4.62.4464 > 10.13.1.1.telnet: P ack 93 win 146009:32:01.983177 10.13.4.1.1038 > 10.13.1.5.7869: P 1:153(152) ack 152 win 812009:32:01.993177 10.13.4.35.3973 > 10.13.4.1.telnet: P 572538:572539(1) ack 1110618381 win146009:32:02.013177 10.13.1.5.7869 > 10.13.4.1.1038: P 152:304(152) ack 153 win 812009:32:02.013177 10.13.4.1.telnet > 10.13.4.35.3973: P 1:6(5) ack 1 win 1606009:32:02.013177 10.13.4.35.3973 > 10.13.4.1.telnet: P ack 6 win 146009:32:02.033177 10.13.4.1.1038 > 10.13.1.5.7869: P 153:305(152) ack 304 win 812009:32:02.063177 10.13.1.5.7869 > 10.13.4.1.1038: P 304:456(152) ack 305 win 812009:32:02.063177 10.13.4.1.1038 > 10.13.1.5.7869: P 305:457(152) ack 456 win 812009:32:02.063177 0.00:00:81:07:cc:6b.452 > 0.ff:ff:ff:ff:ff:ff.452:ipx-sap-nearest-req 4 ''09:32:02.113177 10.13.4.33.1455 > 10.13.4.1.telnet: P 620459:620460(1) ack 1036579127 win146009:32:02.113177 10.13.4.1.telnet > 10.13.4.33.1455: P 1:2(1) ack 1 win 1606009:32:02.113177 10.13.4.33.1455 > 10.13.4.1.telnet: P ack 2 win 146009:32:02.153177 10.13.1.5.7869 > 10.13.4.1.1038: . ack 457 win 812009:32:02.173177 10.13.4.35.3973 > 10.13.4.1.telnet: P 1:2(1) ack 6 win 1460
Vemos que o Tcpdump registra o timestamp, ou seja, o horário em que ocorreu
o evento, o IP origem seguido do porto de comunicação, o IP destino, seguido do
porto, informações de ack (confirmação) e tamanho de janela e, por último, o número
de octetos.
5.3 Usando o SNMP na RMI
5.3.1 Coleta de dados
44
Em uma das estações de trabalho da Prodabel, chamada “Denver”, foram
criadas shells’s scripts para a leitura de dados das MIB’s dos roteadores do backbone
central referentes ao número de octetos de entrada e saída em cada porta de cada um
desses roteadores. Foram utilizadas as variáveis 1.3.6.1.4.1.9.2.2.1.1.36 (octetos de
entrada no roteador) e 1.3.6.1.4.1.9.2.2.1.1.37 (octetos de saída do roteador) da MIB
do roteador Cisco. Este número de variável é composto percorrendo-se a Figura 5-1,
onde, a partir de 1.3.6.1.4, passa-se a usar variáveis que são específicas do
fabricante, no caso, a Cisco, que é a marca dos roteadores que estão sendo
gerenciados.
No caso citado, a servidora “Denver” funcionou como objeto gerente, os
roteadores da RMI foram os agentes e as informações de gerenciamento foram as
MIB’s dos roteadores gerenciados.
Os comandos principais utilizados para se fazer a coleta de dados foram :
snmpinfo -m dump - h $host 1.3.6.1.4.1.9.2.2.1.1.36snmpinfo -m dump - h $host 1.3.6.1.4.1.9.2.2.1.1.37
A variável $host assume os endereços IP dos roteadores que são gerenciados.
A saída desses comandos mostra o valor das variáveis de entrada de octetos e saída
de octetos de todas as portas do roteador que está sendo gerenciado. Esta saída é
mostrada a seguir:
1.3.6.1.4.1.9.2.2.1.1.37.1 = 78938991.3.6.1.4.1.9.2.2.1.1.37.2 = 01.3.6.1.4.1.9.2.2.1.1.37.3 = 5501993
No exemplo acima, o roteador possui apenas três portas e para cada uma
delas está sendo mostrado o número de octetos que saíram.
Com o gerenciamento SNMP, foi possível coletar dados sobre:
• o volume de dados trafegados no backbone central;
• horário de pico.
O volume de dados trafegados no backbone central foi coletado através da
utilização do comando snmpinfo, descrito acima, nos horários de 8h, quando se inicia
o expediente na Prefeitura, e de 17h30, quando termina o expediente.
O horário de pico de utilização dos roteadores, no que se refere aos dados
trafegados, foi obtido usando-se o snmpinfo descrito acima a partir de 8h até 17h30,
em intervalos de 30 minutos.
45
5.3.2 Transformação dos dados
Após a coleta dos dados via SNMP, os mesmos foram inicialmente reduzidos
em um aplicativo desenvolvido para este trabalho. Esta redução é necessária diante
da grande massa de dados coletada. Durante cerca de 20 dias foram coletados em
cada porta dos roteadores do backbone ( totalizando 24 portas) , a quantidade de
octetos que entraram e saíram em cada porta, nos horários de 8 e de 17h. Isto gerou
cerca de (20*24*2=) 960 dados que foram reduzidos e posteriormente agrupados em
planilhas. Foi utilizado o Excel 5.0 e o Excel 97. As planilhas geraram gráficos em
barras, que são apresentados nos gráficos 11-1 a 11-12, no Anexo. Esses dados
também podem ser vistos nas cartas de controle representadas nas figuras 5-1 a 5-6.
5.3.3 Análise de dados
Nesta fase são analisados os dados monitorados de forma a inferir
informações significativas sobre o comportamento do fluxo de dados na WAN da RMI.
Primeiramente, foi feito um apanhado de dados através de SNMP (Ver: 5.3.1)
durante vários dias do mês e depois durante o horário comercial, ou seja, de 8h às
17h. Com estes dados, foram analisados a janela de tempo, o horário de pico e o
volume de dados trafegados no backbone central.
5.3.3.1 Identificação da janela de tempo
Para identificar o dia que corresponde à janela de tempo escolhida para este
trabalho, ou seja, o dia do mês de maior movimento de dados na RMI, foi realizada
uma coleta de entrada e saída de dados de cada porta serial do roteador durante
cerca de 20 dias. O dia em que os roteadores da RMI tiveram maior movimentação de
dados nas portas seriais foi então considerado o dia que representa o maior
movimento de dados no mês para a WAN. Para maior precisão deste dia, é
necessária, a realização de várias coletas e observação das variações mensais. Após
a identificação deste dia, foi feita uma análise para cada roteador do backbone,
verificando o fluxo para as portas seriais.
O backbone central, formado pelos locais intitulados PDBL (Prodabel),
PBH1212 e Tupis possuem, cada um, dois roteadores, com os seguintes números IP:
• Prodabel: Roteadores: 10.54.12.1 e 10.54.12.2.
• PBH1212: Roteadores: 10.13.0.1 e 10.13.0.231.
• Tupis: Roteadores: 10.13.7.1 e 10.13.7.2.
46
Estes roteadores possuem de 3 a 4 portas seriais ativas que estão conectadas
a outras redes, formando uma topologia em anel, conforme mostra a figura 4-1.
GRÁFICO 5-1: Carta de Controle para roteador 10.13.0.1
Cada ponto do gráfico 5-1, corresponde ao tráfego de octetos de entrada e
saída de todas as portas seriais do roteador 10.13.0.1 para um dia de coleta de dados.
Por exemplo, o primeiro ponto se refere ao dia 31/03 e o oitavo ponto, que aparenta
ser o de maior volume de dados, corresponde ao dia 09/04. A análise está sendo feita
sobre o roteador e, portanto, podemos interpretar este gráfico da seguinte maneira: o
roteador 10.13.0.1 trafega em média 124MB por dia, distribuído este tráfego em suas
portas seriais.
GRÁFICO 5-2: Carta de Controle para roteador 10.13.0.231
O primeiro dia do gráfico 5-2 corresponde ao dia 31/03 e o quinto dia, que
aparenta ser o de maior volume de dados, se refere ao dia 08/04. O roteador
10.13.0.231 trafega em média 246MB por dia em suas portas seriais.
47
GRÁFICO 5-3: Carta de Controle para roteador 10.54.12.1
Para o roteador 10.54.12.1 foi observado um pico de utilização fora de controle
para o dia 22/04, chegando a alcançar um valor de tráfego de 34MB em suas portas
seriais. Houve também outro ponto fora de controle, ocorrido no dia 30/4, com
utilização de 13MB. A média do mês gira em torno de 23MB/dia.
GRÁFICO 5-4: Carta de Controle para roteador 10.54.12.2
O roteador 10.54.12.2 apresenta média de tráfego de octetos em torno de
98MB/dia, sendo que houve um pico de utilização no dia 25/4 alcançando 150MB de
tráfego.
GRÁFICO 5-5: Carta de Controle para roteador 10.13.7.1
48
O roteador da Tupis de número IP 10.13.7.1 possui uma média estável de
tráfego em torno de 42MB/dia. Há destaque para o dia 24 (12o. ponto) que trafegou
maior volume de dados.
GRÁFICO 5-6: Carta de Controle para roteador 10.13.7.2
O roteador 10.13.7.2 mantém uma média de tráfego de 120 MB/dia, não
havendo destaque para um determinado dia do mês.
O que se pode concluir desta análise mensal sobre os roteadores é que os
mesmos apresentam certa uniformidade no tráfego diário, ou seja, durante os dias do
mês trafega-se uma quantidade similar de dados em cada roteador do backbone da
RMI. Algumas exceções ocorreram nos pontos grafados nos limites inferior e superior
da carta de controle de alguns roteadores, porém, esse descontrole deve ser
analisado comparando-o com um conjunto maior de dados – dados de outros meses -
para se poder afirmar que tal dia é sistematicamente considerado como o dia que
trafega uma quantidade maior ou menor de dados. Observando-se as cartas de
controle dos roteadores do backbone, verifica-se que o roteador mais utilizado é o
10.13.0.231 da PBH1212 com média de transmissão de dados a 246MB/dia, e o
menos utilizado é o 10.54.12.2, da Prodabel, com média de 23MB/dia.
A coleta de dados para a caracterização de outras métricas na WAN pode ser
realizada em qualquer um dos dias do mês que estiver dentro dos limites de controle.
Para efeito deste trabalho, foi considerado o dia 22 como sendo o dia escolhido para a
coleta de dados na WAN.
5.3.3.2 Análise do horário de pico
Roteadores da PBH1212Pelas observações feitas, viu-se que, na PBH1212, o pico de utilização ocorre
no período da manhã entre 9h30 e 10h30, e à tarde entre 15h até 16h30 (GRAF. 11-7
e GRAF. 11-8).
49
Roteadores da TupisO pico de utilização nos roteadores da Tupis está compreendido, na parte da
manhã entre 10h e 11h, e na parte da tarde, entre 15h e 16 h (GRAF. 11-9 e GRAF.
11-10).
Roteadores da ProdabelA Prodabel possui alguns picos de utilização do canal com a PBH1212 nos
horários antes das 9h e nos horários próximos às 12h. Isto se dá devido à
transferência de arquivos via FTP nos horários considerados fora do pico de
atendimento nos demais locais. Os analistas da Prodabel aproveitam estes horários
para atualizar bases, transferir arquivos da Prodabel para os servidores na PBH1212.
O pico de uso dos canais da Prodabel (excluindo-se os horários próximos às
12h e anteriores às 9h) se dá na parte da manhã entre 9h30 e 10h30, e na parte da
tarde entre 15h30 e 16h30 (GRAF. 11-11 e GRAF.11-12).
De modo geral, os roteadores do backbone têm picos na parte da manhã entre
9h30 e 10h30 e na parte da tarde entre 15h e 16h30.
5.3.3.3 Análise de volume de dados trafegados no backbone central
Roteadores da PBH1212Através dos levantamentos realizados, pôde-se observar que o maior fluxo de
dados ocorre entre Prodabel e o roteador 10.13.0.1, sendo que o tráfego maior está no
sentido da PBH1212 para Prodabel. Os anéis 3 e 8 têm pouco fluxo de dados de
entrada/saída em relação à PBH1212. Os gráficos que expressam essas conclusões
estão no Anexo (GRAF.11-1 e GRAF. 11-2). Percebe-se que o anel 5 utiliza bastante
os serviços da PBH1212. Ele chega a utilizar uma quantidade semelhante à da Tupis.
Roteadores da TupisO maior fluxo se dá entre Tupis e PBH1212; a PBH1212 envia mais octetos
para a Tupis do que o contrário. As comunicações com os anéis 9, 7, 2 e 6 são baixas,
sendo todas abaixo de 10 MB por dia (GRAF. 11-3 e GRAF.11-4).
Dos roteadores 10.13.7.2 e 10.13.7.1, o maior volume de dados se dá em
dados recebidos pelo roteador 10.13.7.2 da rede da PBH1212. Este volume gira em
torno de 70 a 80 MB/dia.
Entre os anéis que estão conectados à rede da Tupis, destaca-se o anel 3,
que faz maior uso de dados enviados por esta rede (em torno de 10 a 15 MB/dia).
50
Roteadores da ProdabelPara o roteador 10.54.12.1, a comunicação maior ocorre entre Prodabel e
Tupis, sendo que a Prodabel mais recebe do que envia dados para a Tupis. A
comunicação com os demais anéis ocorre na faixa dos 5MB de saída de dados
(GRAF. 11-5 e GRAF.11-6).
Com relação ao roteador 10.54.12.2, a comunicação mais significante ocorre
entre Prodabel e PBH1212, sendo que a Prodabel envia mais dados do que recebe. A
comunicação com os demais anéis ocorre abaixo da faixa dos 10MB.
Dos dois roteadores da Prodabel, 10.54.12.1 e 10.54.12.2, o maior fluxo de
dados ocorre entre Prodabel e PBH1212, na faixa de 60 a 80 MB por dia. A faixa de
comunicação com a Tupis está entre 40 e 70 MB por dia.
5.4 Usando o Tcpdump na RMI
5.4.1 Coleta de dados
Foi utilizado o Tcpdump nas redes que possuem servidores na RMI, visto que
todo o tráfego da WAN tem como destino uma rede que possua servidor.
A RMI possui doze servidores de WAN que estão localizados na PBH1212, na
Tupis, na Prodabel e na SMAU (Secretaria Municipal de Atividades Urbanas)6 .
Na RMI foram instaladas quatro máquinas destinadas à coleta de dados
através do Tcpdump, nos locais onde existem servidores na WAN. Isto foi necessário,
pois os servidores da RMI estão todos com a versão 3.2.5 do AIX, versão esta que
não tem disponível e não compila o aplicativo Tcpdump disponível para outros Unix.
Se os servidores da RMI já estivessem com a versão 4.0 do AIX, não seria necessário
montar máquinas extras na WAN para se fazer a coleta de dados. Eles poderiam ter
sido coletados nos próprios servidores. Porém há que se considerar que, não sendo
os servidores os monitores dessa coleta, não prejudicamos o servidor com esta tarefa;
ele podia realizar suas tarefas normalmente, enquanto, através da rede, em outro
micro, todo o tráfego da Ethernet estava sendo coletado.
Foi utilizado então o Linux para PC como Sistema Operacional dessas quatro
máquinas. Logo após a montagem destes ambientes, foi feita uma sincronização de
6 A SMAU está localizada à Av. Afonso Pena, 4000 e é referenciada pela Prodabel e neste trabalho comoPBH4000
51
tempo entre as máquinas para que todas ficassem com a mesma data, hora, minuto e
segundo para compor o arquivo de dump.
Durante uma hora, hora esta analisada e escolhida como hora de pico, o
Tcpdump gravou informações em arquivos que depois seriam analisados. O tamanho
desses arquivos variou entre 20 MB na Prodabel, 20 MB na Tupis, 9 MB na PBH4000
e 125 MB na PBH1212. A coleta ocorreu simultaneamente nesses quatro locais, de
15h às 16h.
O Tcpdump foi executado com a seguinte opção:
tcpdump -w /dir/nome_arq
Esta opção permite que sejam gravadas todas as informações coletadas em
tempo real, e na seqüência, podem ser executados novos comandos sobre este
arquivo, filtrando-se as informações desejadas.
5.4.2 Transformação de dados
Após a coleta de dados através do Tcpdump, foram realizados comandos
sobre os quatro arquivos gerados. A idéia era separar por fonte geradora de tráfego,
quais as ocorrências da mesma nesses quatro arquivos. Por exemplo, a Regional
Venda Nova utilizou a WAN neste horário e com certeza fez uso de algum servidor da
WAN que está localizado em algum desses quatro pontos da RMI. Ao separar as
ocorrências de pacotes da Regional Venda Nova nesses quatro arquivos, pode-se
reconstruir os pacotes que saíram daquela Regional e que trafegaram pela WAN.
O comando realizado sobre o arquivo de tcpdump da Tupis para extrair tal
informação foi:
tcpdump -tt -q -r tupis src net 10.26.0 and dst net 10.13.4
Este comando lê o arquivo tupis (arquivo de dump gerado) através da opção –r,
gerando o resultado com o timestamp (opção -tt) e em formato reduzido (opção -q),
solicitando que sejam exibidos apenas os pacotes que tiveram origem na rede de
número IP 10.26.0, que se refere aos números IP’s da rede da Regional Venda Nova e
que tiveram destino para a rede 10.13.4, que se refere à rede da Tupis.
Esse mesmo comando foi repetido para os outros arquivos de dump, gerando
assim quatro arquivos referentes ao tráfego gerado pela Regional Venda Nova. Logo
depois esses quatro arquivos foram concatenados e ordenados pelo timestamp. Desta
forma, obteve-se um arquivo final da Regional Venda Nova com todo o fluxo que ela
gerou na WAN.
52
Tal procedimento foi repetido para todos os anéis da RMI sobre os quatro
arquivos de dump. Para este trabalho foram desenvolvidas shell’s scripts no Unix.
Sobre os arquivos resultantes da separação do tráfego por origem, avaliou-se a
porcentagem de destino das mensagens que será fonte de entrada de dados no
simulador.
5.4.2.1 Reduzindo dados capturados pelo Tcpdump
Através de alguns programas de agrupamento de dados, foi possível fazer
análise sobre os dados monitorados. A análise em si está descrita no item 5.4. Aqui, é
abordado o tratamento dos dados do dump, feito a partir das ferramentas do Iptraf.
O arquivo de dump gerado pelo Tcpdump foi lido pelo programa red_data2,
descrito a seguir.
O pacote Iptraf
O Iptraf é um pacote de aplicativos disponível pela Internet e se refere a um
conjunto de programas escritos em perl, por Cécile Martel [40], para analisar o tráfego
do CERN (European Laboratory for Particle Physics)7. Este pacote tem basicamente
os seguintes programas:
• Para obtenção de dados
• get_traf, get_traf2, get_n_pack, get_n_pack2
• Para redução de dados
• red_data, red_data2, red_data3, red_data4
• Para sumarização de dados
• ana_proto, ana_top, ana_top_src, ana_in_out, transip
Foi utilizado, neste trabalho, o programa red_data2. Os programas de obtenção
de dados (get_traf, get_traf2 ,etc,) não foram utilizados porque geram arquivos que
somente podem ser utilizados pelos programas de redução de dados do Iptraf, e este
não era o objetivo. Desejava-se que os arquivos gerados a partir da monitoração
pudessem ser usados também para filtrar os tráfegos das origens.
Reduzindo dados com o red_data2
7 O nome original do CERN é Conseil Europeen pour la Recherche Nucleaire
53
Ao se utilizar o programa red_data2, são geradas, a partir do arquivo geral
gravado pelo Tcpdump -w, somente as informações de que tal programa precisava.
Isto foi feito com a execução do seguinte comando :
tcpdump -e -n -q -t -r /dir/nome_arq |compress > /dir/nome_arq/arq.Z
Opções do Tcpdump:
-e: mantém o cabeçalho de link-level header;
-n: não faz alteração do endereço MAC (Medium Access Control) para
endereço IP;
-q: reduz formato de saída;
-t: não mostra timestamp;
-r: lê arquivo.
Esse comando filtra do arquivo geral informações sem o timestamp, sem
transformação do endereço MAC em endereçamento IP e com formato reduzido. Além
disso ele faz compressão desta filtragem.
Após este comando de preparação dos dados para serem lidos pelo red_data2,
tal comando foi executado como se segue :
perl red_data2.pl -i arq.Z -d arq_saida
O red_data2 trabalha da seguinte forma: ele cria arquivos de
origem/destino/protocolo por roteador, computa o tráfego total, quebrado por protocolo
e depois o tráfego para cada roteador, também separado por protocolo.
Antes de executar o programa red_data2, deve ser feita uma alteração na sua
fonte, inserindo-se o nome e os endereços MAC dos roteadores da rede local que está
sendo analisada.
A saída do protocolo red_data2 é vista em forma de relatório, como o
apresentado abaixo. Neste trabalho, sumarizamos as informações geradas por
relatórios deste tipo e a apresentamos através de gráficos (GRAF. 11-13 a GRAF.11-
18).
Packets evaluated: 611024 Valid: 611024 Too short: 0 Truncated by tcpdump: 0 Traffic breakdown by router: Router #packets % #octetos % mediterraneo2_lan 441496 72.26 39168794 60.16
54
italia 86180 14.10 14516688 22.30 mediterraneo_lan 83348 13.64 11417017 17.54 other 0 0.00 0 0.00 Total Traffic: 611024 packets 65102499 octetos Protocol #packets % #octetos % tcp telnet 450591 73.74 18522555 28.45 tcp other 151975 24.87 44281438 68.02 tcp printer 8393 1.37 2298506 3.53 icmp 65 0.01 0 0.00 Traffic of router mediterraneo2_lan: 441496 packets = 72.26% of total packets; 39168794 octetos = 60.16% of total octetos. %pr : percentage of this protocol total trafic Protocol #packets % %pr #octetos % %pr tcp telnet 359251 81.37 79.73 9130535 23.31 49.29 tcp other 77444 17.54 50.96 29781509 76.03 67.26 tcp printer 4764 1.08 56.76 256750 0.66 11.17 icmp 37 0.01 56.92 0 0.00 0.00 Traffic of router italia: 86180 packets = 14.10% of total packets; 14516688 octetos = 22.30% of total octetos. %pr : percentage of this protocol total trafic Protocol #packets % %pr #octetos % %pr tcp other 74504 86.45 49.02 14494437 99.85 32.73 tcp telnet 11537 13.39 2.56 13792 0.10 0.07 tcp printer 124 0.14 1.48 8459 0.06 0.37 icmp 15 0.02 23.08 0 0.00 0.00
Os números dos portos são o mecanismo utilizado para classificar a proporção
das aplicações na rede. Originalmente esses portos eram designados pelo Internet
Assigned Numbers Authority (IANA) que utilizava a faixa de 0 a 255 para aplicações
específicas. Por exemplo, o telnet possui o número de porto igual a 23. Recentemente,
o Unix introduziu certa anarquia na designação desses números de portos, utilizando a
faixa de 512 a 1024 para identificar aplicações específicas. Por exemplo, o número
513 é utilizado para o rlogin. Em julho de 1992, o IANA estendeu a sua faixa de
designação de 0 - 1023. O IANA não tem objetivo de controlar a designação dos
55
portos; ele registra o uso de portos para uma conveniência da comunidade usuária
[19].
Abaixo estão relacionados e agrupados os tipos de aplicações:
n Troca de arquivos: ftpdata e ftpcontrol (TCP portos 20,21);
n Correio: smtp, nntp, vmtp, uucp (TCP portos 25,119,175,540);
n Interativa: telnet, finger, rwho, rlogin (TCP portos 23, 79, 513, UDP porto
513);
n DNS (Domain Name Server): (UDP porto 53, TCP porto 53);
n outros serviços TCP/UDP: todos os outros portos não incluídos acima (i.e.,
talk, x-windows);
n serviços que não são TCP/UDP: outros protocolos diferentes do TCP e
UDP (i.e. ICMP (Internet Control Message Protocol), IGMP (Internet
Gateway Management Protocol), EGP (Exterior Gateway Protocol), etc.).
5.4.3 Análise de Dados
Através da identificação do HMM (Horário de Maior Movimento), ou da mesma
forma, da janela de tempo, foram feitas as coletas de dump das redes locais. Com
estes arquivos de dump, gerados com o Tcpdump, foram feitas diversas análises que
estão detalhadas no decorrer deste capítulo, entre as quais:
• Análise da composição desses dados em termos das aplicações do
protocolo TCP/IP (isto é, Telnet, FTP, SNMP).
• Análise dos objetos originadores de tráfego, obtendo-se o tamanho das
mensagens geradas, os intervalos de tempo entre chegadas das
mensagens e os destinos dessas mensagens.
• Análise dos objetos que respondem ao tráfego inicializado, obtendo-se o
tamanho das mensagens de resposta.
5.4.3.1 Análise da composição do tráfego usando o pacote Iptraf
Através do programa red_data2, contido no pacote Iptraf, é possível verificar a
porcentagem dos pacotes e octetos trafegados nas portas LAN de cada roteador. No
caso em estudo, ao invés de o destino ser a porta de roteadores da rede local,
escolhemos os destinos como sendo os servidores.
O red_data2 avalia também a porcentagem de uso das aplicações TCP/IP
para toda a rede e depois faz a avaliação do uso destes para cada servidor.
56
No GRAF. 5-7, na rede da PBH1212, pode-se ver que a aplicação mais usada,
em termos de pacotes, foi o TELNET, seguido pela comunicação entre servidores que
possuem módulos distribuídos – representado por “adabas-networking”. Para esta
análise, o arquivo de dump foi filtrado, selecionando-se apenas o tráfego da WAN para
a rede da PBH1212.
GRÁFICO 5-7: Tráfego da WAN para servidores da PBH1212 (medida: pacotes)
No gráfico 5-8, vemos que, quando se faz a medição em octetos, o Network do
Adabas é o responsável por 90% das comunicações, na WAN, envolvendo a
PBH1212. Porém, ao se observar o número de pacotes que trafegam na WAN,
percebe-se, através do gráfico 5-7, que 91% dos pacotes se referem à aplicação
TELNET. Portanto, fica claro que o TELNET gera mais pacotes, porém com menos
dados que a aplicação gerada pelo Network do Adabas.
telnet91%
adabas-networkin6%
other2%
notes0%
ftp0%
printer1%
snmp0%
ftp-data0%
telnet
adabas-networkinotherprinternotes
snmpftpftp-data
telnet10%
ftp0%
printer0%
other0%
notes0%
snmp0%
ftp-data0%
adabas-networkin
telnet
notes
57
GRÁFICO 5-8: Tráfego da WAN para os servidores da PBH1212 (medida:octetos)
No Anexo estão os gráficos que representam o acesso para todos os demais
servidores da RMI quanto à representatividade dos protocolos (GRAF.11-13 a 11-18).
No geral, os servidores são acessados por uma grande quantidade de pacotes
TELNET, que representam menor quantidade de octetos trafegados do que os
pacotes, em menor quantidade, de aplicações referentes ao Network do Adabas.
No gráfico 5-9, está representada uma caracterização do tráfego proveniente
da WAN e com destino aos servidores da WAN, podendo ser visualizados os
servidores mais solicitados para as aplicações mais representativas, ou seja, TELNET
e o Network do Adabas.
0 .00
0 .05
0 .10
0 .15
0 .20
0 .25
0 .30
0 .35
0 .40
0 .45
santos a g u d o i tu d e n v e r sao_pau lo c a m p i n a s i ta l ia a i ken pet ropo l is danv i l l e lapa
serv idores
Uti
lizaç
ão (
%)
paco tes
by tes
58
GRÁFICO 5-9: Tráfego da WAN para os servidores da RMI
O servidor Santos é a máquina mais solicitada pela WAN, tanto em termos de
pacotes quanto em octetos; já o servidor Lapa, nesta amostra, demonstrou ser o
servidor menos solicitado pela WAN.
O servidor Santos é o servidor mais solicitado pela WAN para as aplicações de
TELNET e do Network do Adabas. As servidoras Sao_paulo e Agudo não têm
módulos dos bancos distribuídos em outros servidores da WAN e o servidor Lapa, que
é um servidor Lotus Notes, obviamente não é solicitado pela WAN, para as aplicações
de Telnet e Network do Adabas.
59
Capítulo 6
FASE 4: Construção do Modelo
Nesta fase da metodologia, foram seguidos os passos para a construção do
modelo descritos no Capítulo 3 – item 3.2. Vale destacar o passo referente ao “Tráfego
da Rede”, no qual foram aplicadas análises estatísticas sobre os dados e realizadas as
atividades necessárias para se fazer a seleção de distribuição de probabilidade
descritas no Capítulo 2.
6.1 Topologia da Rede
Para a construção da topologia da rede, foram utilizadas as informações
coletadas na FASE 2 da Metodologia de Planejamento de Capacidade que aborda a
“Compreensão do Ambiente”.
O COMNET III consegue fazer a importação automática dos objetos através de
interface com softwares de gerenciamento de rede tais como Network General
Distributed Sniffer System, HP NetMetrix, HP OpenView, Cabletron SPECTRUM, IBM
NetView for AIX, Castlerock SNMPc [13]. Porém o software de gerenciamento adotado
na Prodabel é o ISM, que não dispõe no momento desta interface com o COMNET III.
Sendo assim, foi feito o cadastramento da topologia da RMI no COMNET III, de forma
manual.
Durante as Fases 4 e 5, foram feitos sucessivos protótipos do modelo, de
forma a torná-lo mais representativo e simplificado.
A construção da topologia da rede no COMNET III consiste em representar as
entidades do sistema real através dos objetos simbólicos oferecidos pelo simulador.
As entidades representadas foram: servidor, rede local, enlace (ponto-a-ponto e
CSMA/CD), roteadores, mensagens de tráfego (de origem e de resposta). Estes
60
objetos foram detalhados no capítulo referente à Ferramenta COMNET III – Capítulo 3,
item 3.3.
O modelo construído pode ser visto na figura 6-1 abaixo. Consideramos como
backbone, os roteadores 10.13.0.231, 10.13.0.1, 10.13.7.1, 10.13.7.2, 10.54.12.2 e
10.54.12.1 que são interligados através dos links 501-7100, 501-7104 e 501-7103. A
figura 6-2 destaca esses componentes do backbone a fim de facilitar a visualização
dos mesmos nos modelos construídos e apresentados neste trabalho.
FIGURA 6-1: Modelo de simulação da RMI no COMNET III
FIGURA 6-2: Componentes do backbone
61
Pode-se observar que não existe uma representação um-para-um, conforme os
dados descritos na Fase de “Compreensão do Ambiente”. Por exemplo, todos os
servidores que são acessados pela WAN e que estão localizados na PBH1212 (TAB.
11-4), são representados no modelo pelo objeto “Servers1212”; o servidor localizado
na Tupis (TAB. 11-5) foi representado pelo objeto “ServerTupis”; o servidor localizado
na PBH4000 (TAB. 11-6) foi representado pelo objeto “Server4000”; e os servidores
localizados na Prodabel (TAB. 11-7) foram representados pelo objeto “ServersPdbl”.
Como o interesse de análise é no backbone, seria dispensável o detalhamento dos
servidores em uma rede local. Aqui, interessa apenas o tráfego na WAN recebido e
gerado por eles; portanto o fato de os mesmos estarem agrupados diminui o nível de
detalhe e traz mais precisão aos dados que se quer analisar.
Outra representação do modelo que não reflete objetos na proporção de um-
para-um está relacionado com as fontes de tráfego através dos anéis. Ao fazer a
seleção dos originadores de tráfego, trabalhou-se com 22 arquivos. Apesar de só
existirem 9 anéis na RMI, a sua representação lógica teve de ser feita de acordo com
a tabela de roteamento definida no sistema real. Pelo fato de a RMI estar usando
roteamento estático, cada anel estava dividido em dois. Por exemplo, no anel 1
existem 4 redes locais (FIG. 11-2), porém a tabela de roteamento de duas destas
redes sempre define a rota do next hop para um lado do anel e a tabela de roteamento
das duas demais redes do anel definem o next hop para o outro lado do anel. Desta
forma, os dados originados deste anel chegam ao backbone apenas nestas condições.
A representação desta situação no modelo teve de ser feita como duas fontes distintas
originadas pelo anel 1. Uma das fontes chega por um lado do backbone e é
representada como anel1-1 e a outra fonte chega do outro lado do backbone e é
representada como anel1-2.
O desempenho do COMNET III está relacionado, entre outros, com o número
de objetos que são colocados no modelo. Portanto, é necessário simplificar o modelo
tanto para obter resultados mais diretos como também para conseguir executar o
modelo em tempo considerado razoável.
6.2 Tráfego da Rede
Para representar o tráfego no modelo, deve-se disponibilizar informações nos
objetos que são considerados geradores de tráfego no COMNET III. Estes objetos,
para o tipo de análise que estamos querendo fazer, são Source:Message e
62
Source:Response. As informações que devem ser preenchidas nesses objetos para a
geração de tráfego são :
Source: Message:
Intervalo de entre-chegadas das mensagens;
Tamanho das mensagens ;
Destino das mensagens.
Source: Response:
Tamanho das mensagens.
Algumas dessas informações, como o intervalo de entre-chegadas das
mensagens e o tamanho das mensagens, devem ser dadas através de distribuição de
probabilidades. Portanto, uma análise estatística deve ser feita sobre cada um dos
dados originadores de tráfego para se verificar que distribuição de freqüência eles
estão seguindo, ou mesmo se pode utilizar a distribuição empírica.
6.2.1 Originadores de Tráfego representados no COMNET III
6.2.1.1 Objeto Source: Message
No modelo construído no COMNET III, que representa o backbone da RMI, os
dados que originam tráfego são implementados através do objeto “Source: Message”.
Esse objeto solicita basicamente as seguintes informações: a) a distribuição de
probabilidades dos tamanhos das mensagens; b) a distribuição de probabilidades em
que essas mensagens são geradas; e c) qual o destino dessas mensagens. Todas
essas informações foram levantadas a partir da amostra de dados obtida através do
Tcpdump.
A geração de mensagens através do objeto “Source:Message” é usada para
enviar mensagens da origem para um ou mais destinos. O roteamento dessas
mensagens no COMNET III é feito como se elas fossem datagramas.
Como pode ser visto no modelo (FIG.6-1), existe um “Source:Message” para
cada conjunto de redes que pertencem a um mesmo anel.
Através do arquivo de Tcpdump das redes da PBH1212, Prodabel, Tupis e
PBH4000, foram coletados os octetos trafegados durante o envio das mensagens e o
horário (timestamp) em que ocorreu tal transmissão.
Por exemplo, no arquivo de dump da PBH1212, foram selecionados, para cada
um dos anéis da RMI, todos os registros que tiveram destino para a rede da PBH1212.
O mesmo foi feito com o arquivo de dump da Prodabel, da Tupis e da PBH4000.
Depois, foram agrupadas em um único arquivo as ocorrências do anel 1 que tiveram
63
registros nestes 4 arquivos de dump. O mesmo foi feito para o anel 2, para o anel 3 e
para todos os demais anéis da RMI. Como os destinos dos pacotes desses anéis são
somente os locais em que existem servidores e estes servidores estão em uma das
quatro redes acima citadas, então pode-se concluir que todos os registros de
mensagens geradas pelos anéis foram obtidos nos destinos. Pelo fato de se ter
agrupado esses registros por anel, cada um dos anéis pôde ser caracterizado no
modelo através dos parâmetros solicitados no objeto “Source: Message”.
6.2.1.2 Objeto Source: Response
No COMNET III, os objetos que respondem aos dados originados pelos
Source: Message são os objetos chamados Response: Message. Como todo o tráfego
da WAN tem destino para os servidores, os objetos Response: Message foram
colocados nos servidores. Este objeto solicita basicamente a informação de
distribuição de probabilidade do tamanho das mensagens de resposta.
Através do arquivo de Tcpdump das redes da PBH1212, Prodabel, Tupis e
PBH4000, selecionamos os registros das mensagens de respostas que tiveram origem
nos servidores destas redes. Desta forma, criamos 4 arquivos nos quais faremos
análises de distribuições de freqüência para o tamanho das mensagens de resposta.
6.2.2 Seleção de distribuição de probabilidade para a amostra
Queremos analisar nesta etapa qual a distribuição de probabilidades que os
dados coletados estão seguindo. Os dados a serem analisados são os mencionados
anteriormente como entrada para os objetos geradores de tráfego, sendo portanto
objetivo desta etapa pesquisar a distribuição de probabilidades que melhor se adequa:
a) aos tamanhos das mensagens de cada Source: Message;
b) aos intervalos de entre-chegadas das mensagens de cada Source: Message;
e
c) aos tamanhos das mensagens de cada Response : Message.
Iremos utilizar as atividades apontadas no Capítulo 2 – item 2.5.4 - para orientar
este trabalho de pesquisa sobre as distribuições de probabilidade. Estas atividades
podem ser realizadas com o uso de software estatístico que permita executar tais
etapas com rapidez e precisão. O software escolhido para esta etapa foi o C-FIT [14].
• O C-FIT é uma ferramenta para ajustar distribuições de probabilidades a
amostras de dados. O software utiliza três métodos estimadores de
64
parâmetros, sendo eles o Método de Máxima Verossimilhança, Método dos
Mínimos Quadrados e o Método de Momentos, já referenciados no Capítulo
2. Através do C-FIT, podem ser verificadas 16 distribuições teóricas, sendo
elas: Beta, F, Gumbel (Min), Rayleigh, Chi, Frechet, LogNormal,
Rectangular, Chi-Square, Gamma, Logistic, Student-T, Exponential, Gumbel
(Max), Normal, Weibull [14].
• O C-FIT gera ainda relatórios com os parâmetros das distribuições, um
resumo estatístico e faz testes de bom ajuste através do teste do qui-
quadrado e teste de Kolmogorov-Smirnov.
6.2.2.1 Atividade I: Fazer hipóteses para distribuições conhecidas
Para os dados relativos ao intervalo de entre-chegadas das mensagens,
fizemos a princípio a suposição teórica de que os intervalos seguiam a distribuição
exponencial, dada a semelhança da aplicabilidade desta distribuição com os nossos
dados e também por estes serem dados contínuos, assim como esse tipo de
distribuição. A fim de especular outras distribuições, testamos os dados com relação à
outras distribuições disponíveis no C-FIT e que são distribuições disponíveis no
COMNET III. Desta forma, as distribuições testadas foram: exponencial, gamma,
weibull, normal, lognormal e beta.
Iremos mostrar, na figura 6-3, um dos testes realizados no C-FIT, colocando
nossos dados de intervalos entre-chegadas, referentes ao anel 8-1, em comparação
com a reta da distribuição exponencial.
65
FIGURA 6-3: Teste de hipótese para distribuição exponencial
Mostramos na figura 6-4, outra hipótese realizada para este mesmo conjunto
de dados. Desta vez, fizemos a suposição dos dados seguirem a distribuição Weibull.
A interpretação dos gráficos 6-3 e 6-4 será feita no item 6.2.2.3.
FIGURA 6-4: Teste de hipótese para distribuição Weibull
6.2.2.2 Atividade II: Fazer estimativa de parâmetros
Escolhemos o método de Máxima Verossimilhança para estimar os
parâmetros. Este método é o mais indicado pelos livros pesquisados (Ver Cap. 2 e
Law e Kelton [38], p.368). Os parâmetros estimados (λ e ε) podem ser vistos no
relatório gerado pelo C-FIT juntamente com outros dados estatísticos. Este relatório
está apresentado no próximo item.
6.2.2.3 Atividade III: Determinar o quanto as distribuições estão ajustadas
Para verificar se realmente a distribuição hipotética se ajusta com a amostra de
dados, devemos observar o gráfico mostrado anteriormente (FIG.6-2). Com um teste
visual pode-se observar que os dados da nossa amostra não seguem a mesma linha
representada pela distribuição hipotética. Para este exemplo, o teste visual não deixa
dúvidas de que esta amostra não se ajusta à distribuição escolhida. Porém, se o teste
visual não fosse tão nítido, estando os dados mais ou menos próximos à linha da
distribuição, poderia ser verificado o valor de nível de significância (CS Sig. Level)
apontado pelo teste do qui-quadrado. Para ser considerado como ajustado, este valor
teria de ser maior que 0.05. Vemos no relatório do C-FIT, apresentado a seguir, que
este valor está igual a zero e portanto abaixo de 0.05. Desta forma, rejeitamos a
66
hipótese de que os intervalos de entre-chegadas das mensagens do anel 8-1 seguem
a distribuição exponencial. Outra tentativa de hipótese foi feita para este mesmo
conjunto de dados, comparando-o com a distribuição Weibull. Na figura 6-3 também
fica claro que esta hipótese deve ser rejeitada pois, nem todos os pontos da amostra
estão sobre a linha da distribuição Weibull.
Distribution Fitting Report
Date & Time: July 15, 1997 3:20:45 pm
Basic Statistics
Num. of Samples 1220Num. of Bins 99
Mean 2.01571Standard Deviation (unbiased) 4.60693Coeffienct of Skewness (unbiased) 3.0615Coeffienct of Kurtosis (unbiased) 9.1567Coeffienct of Variation 2.28551
Minimum 0Maximum 28.07Bin Minimum 0Bin Maximum 28.07Variable Minimum (if required) -0.0230082Variable Maximum (if required) 28.093
Chi Square Goodness-of-fit Summary
CS Statistic CS Sig. Level
Exponential MLM 41421.4 0
Kolmogorov-Smirnov Goodness-of-fit Summary
KS Statistic KS Sig. Level
Exponential MLM 0.47549 5.22158e-240
67
Para cada um dos geradores de tráfego no modelo, representados pelos
ícones
intitulados “MsgAnelx-x” (FIG. 6-1), foram realizadas as atividades descritas nos ítens
6.2.2.1 a 6.2.2.3. Foram realizados no total, 132 testes de hipóteses para os dados
relativos aos intervalos de entre-chegadas das mensagens e para os dados relativos
ao tamanho das mensagens. Esta quantidade de testes se deve ao fato do modelo
possuir 22 objetos que originam tráfego. Para esses objetos foram realizados testes de
hipóteses para seis distribuições (exponencial, gamma, weibull, normal, lognormal e
beta). Em todos os testes as hipóteses foram rejeitadas.
Estudos realizados por Paxson & Floyd [46] também resultaram na rejeição da
hipótese de que os intervalos entre pacotes para a aplicação TELNET na WAN
seguem a distribuição exponencial.
6.2.2.4 Escolha da distribuição empírica
Após termos feito vários testes hipotéticos de distribuições teóricas sem ter
alcançado boa representatividade da amostra, optamos por representá-la através de
uma distribuição empírica. Isto foi feito fazendo-se tabelas de distribuições de
freqüência acumulada. Como exemplo, mostramos abaixo a tabela de distribuição de
freqüência do anel1-1 referente ao tamanho das mensagens (TAB. 6-1).
TABELA 6-1: Distribuição de Freqüência para anel1-1
Tamanho damensagem
Freqüência %cumulativo
0 993 37.79%1 637 62.02%2 95 65.64%
68
3 507 84.93%9 29 86.04%
11 13 86.53%23 11 86.95%44 289 97.95%
100 20 98.71%102 20 99.47%253 14 100.00%
Mais 0 100.00%
A tabela 6-1 pode ser interpretada da seguinte maneira: 37.79% das
mensagens que foram originadas no anel 1-1 e que tiveram destino para um dos
servidores da RMI tinham tamanho 0; 24.23% (0.6202 - 0.3779) das mensagens
originadas no anel1-1 e que tiveram destino para um dos servidores da RMI tinham
tamanho 1.
Vemos que 62.02% das mensagens têm tamanho 0 ou 1. Isto se dá
basicamente porque o anel 1 faz uso das aplicações dos servidores da RMI através de
emulação de terminal, ou seja, através do TELNET. Com o uso do TELNET, todo
caracter digitado na máquina que está emulando o terminal será ecoado.
Construímos tabelas de distribuição de freqüência para cada objeto gerador de
tráfego e digitamos tais valores no COMNET III.
6.3 Operações de Rede
As operações de Rede são definidas no COMNET como genérica a todos os
objetos do modelo. A primeira definição de operação se refere ao algoritmo de
roteamento, o qual escolhemos como roteamento estático, conforme é hoje a
realidade do roteamento na WAN da RMI. Outra operação de rede se refere ao
protocolo de transporte adotado na WAN. No caso da RMI, este protocolo de
transporte é o TCP.
6.4 Controle da Simulação
O controle da simulação no COMNET III é realizado através de uma janela de
controle onde é informado, como dado principal, o tempo de simulação. Utilizamos o
tempo de 3600 s, pois este foi o tempo da coleta de dados.
6.5 Resumo e Conclusões do capítulo
69
Neste capítulo abordamos como foi feita a construção do modelo, que
caracteriza-se pela construção da topologia, construção do tráfego da rede, definição
das operações da rede e controle da simulação. A topologia foi construída de forma
manual sem o uso de programas que fazem importação automaticamente. O modelo
não foi construído com representação de um-para-um, visto que uma forma
simplificada de representação traz menos detalhes e melhores resultados nas
interpretações. O tráfego foi gerado a partir de objetos denominados Source:
Messages que reproduzem o tráfego original a partir de informações como: a)
distribuição de probabilidades dos intervalos de tempo para a geração de mensagens;
b) distribuição de probabilidades para o tamanho dessas mensagens que estão sendo
geradas; e c) uma lista de destinos para onde essas mensagens serão enviadas.
Foi feita uma extensa análise nos dados coletados para se utilizar distribuições
de probabilidades teóricas para representar os dados a) e b) acima denominados.
Essa análise contou com o uso de um software estatístico, o C-FIT. A análise dos
dados seguiu um roteiro de atividades estatísticas onde se utilizou como estimador de
parâmetros, o Método de Máxima Verossimilhança e como teste de bom ajuste, o
teste do qui-quadrado. As amostras não apresentaram suficiente aproximação das
distribuições de probabilidades testadas, portanto, o modelo foi construído com
distribuições de probabilidades empíricas que foram informadas no COMNET III
através de tabelas de distribuição de freqüência acumulada.
Apesar de todo o esforço para se utilizar distribuições teóricas, sem no entanto
ter-se obtido sucesso, considera-se ainda assim, esse estudo indispensável. Isto
porque, a distribuição teórica traz mais flexibilidade em testes de previsões de
desempenho para cargas de tráfego diferentes, uma vez que seus parâmetros podem
ser alterados facilmente. Por exemplo, o parâmetro da distribuição exponencial é a
média, através de alterações no valor da média é possível informar uma carga maior
ou menor de tráfego. Dificilmente conseguiremos alterar as tabelas de distribuições de
frequência acumulada para representar maior ou menor intensidade de uso de
determinado gerador de tráfego.
Estudos de caracterização realizados para o TELNET, que é a aplicação mais
utilizada na WAN da RMI, e descritos em [46] e [47], também apontam para uma
representação empírica ou pela distribuição de Pareto, para o caso dos intervalos de
entre-chegada das mensagens. O COMNET III não possui representação da
distribuição de Pareto e portanto não analisamos a amostra de dados para essa
distribuição.
70
71
Capítulo 7
FASE 5: Validação e Calibração doModelo
7.1 Como validar o modelo
Para se fazer qualquer tipo de inferência sobre o modelo, é necessário
inicialmente fazer comparações entre os resultados que esse modelo gerou e os
resultados do sistema real. Até que o modelo seja considerado válido, qualquer tipo de
conclusão sobre ele pode ter valor duvidoso.
Segundo Strack [60], uma das dificuldades da simulação é a validação de
modelos. É necessário verificar se o modelo se comporta da mesma maneira que o
sistema real.
Em nosso trabalho, avaliamos a credibilidade do modelo através da
comparação dos resultados do modelo - feitas através de relatórios - com o sistema
real. Fizemos a seguinte hipótese para verificar a validação: a quantidade de
mensagens geradas pelas fontes de tráfego do modelo tinham comparação favorável
com relação à quantidade de mensagens geradas por estas mesmas fontes de tráfego
do mundo real?
Como utilizamos um modelo empírico e não uma distribuição de probabilidade
teórica para representar objetos geradores de tráfego no modelo, esta etapa de
validação e calibração pôde ser mais simplificada, como descrevemos acima. No
entanto, ao se usar distribuições teóricas, esta validação deve ser feita com
abordagens estatísticas. Maiores detalhes podem ser vistos em Law & Kelton- Cap. 5.
[38].
72
7.1.1 Validação: Quantidade de mensagens geradas
Como já foi citado anteriormente, todo o tráfego no modelo tem origem nas
mensagens geradas nas redes locais dos anéis. A geração dessas mensagens está se
baseando na distribuição de probabilidade informada para tal originador de tráfego.
Portanto, espera-se que, ao final da simulação, determinada rede tenha gerado um
número próximo de mensagens da geração de mensagens real.
No arquivo de dump que se refere, por exemplo, ao anel 7, temos, para cada
linha, uma mensagem que foi gerada na rede. Portanto, se o arquivo contiver n linhas,
significa que tal anel gerou n mensagens.
O que fizemos foi comparar este valor com o valor de mensagens geradas pelo
objeto no simulador que representa este anel 7. Através do relatório “Received
Message Counts”, é possível fazer esta verificação.
Na tabela 7-1 podemos verificar que o número de mensagens geradas pelo
COMNET (# Msg. COMNET) é muito próximo do valor real medido (# Msg. Real).
TABELA 7-1: Quantidade de Mensagens. Simulado X Real
Destino Origem # Msg.COMNET
# Msg.Real
Servers1212 MsgPdbl 33355 33833Servers1212 MsgAnel6-2 16527 16494Servers1212 MsgAnel3-2 38305 39018Servers1212 MsgAnel1-1 1702 2285Servers1212 MsgAnel4-2 76434 75876Servers1212 MsgAnel6-1 12159 12377Servers1212 MsgTupis 57107 56218Servers1212 MsgAnel7 7458 7714Servers1212 MsgPBH4000 17510 17532Servers1212 MsgAnel5-1 1895 2263Servers1212 MsgAnel1-2 4207 4670Servers1212 MsgAnel8-2 8689 9191Servers1212 MsgAnel3-1 7963 8647Servers1212 MsgAnel2-2 3801 3801Servers1212 MsgAnel4-1 4890 5517Servers1212 MsgAnel8-1 800 879
ServersPdbl MsgAnel4-2 1977 1929ServersPdbl MsgAnel7 861 817ServersPdbl MsgAnel6-1 657 669ServersPdbl MsgTupis 18919 18806ServersPdbl MsgAnel1-1 257 348ServersPdbl MsgPBH4000 4827 4808
73
ServersPdbl MsgAnel2-1 241 220ServersPdbl Msg1212 11761 12868ServersPdbl MsgPdbl 1443 1486ServersPdbl MsgAnel2-2 559 569ServersPdbl MsgAnel1-2 598 660ServersPdbl MsgAnel3-1 192 221ServersPdbl MsgAnel8-1 287 348ServersPdbl MsgAnel6-2 449 441ServersPdbl MsgAnel3-2 609 639ServersPdbl MsgAnel9-2 245 191ServersPdbl MsgAnel4-1 318 380ServersPdbl MsgAnel9-1 115 94ServersPdbl MsgAnel8-2 112 128ServersPdbl MsgAnel5-1 510 592
ServerTupis MsgAnel7 3445 3649ServerTupis MsgPBH4000 357 339ServerTupis Msg1212 752 806ServerTupis MsgAnel1-2 531 603ServerTupis MsgPdbl 433 415
Server4000 Msg1212 2999 3330Server4000 MsgAnel7 1720 1810Server4000 MsgAnel8-2 2672 2889Server4000 MsgTupis 910 880Server4000 MsgPBH4000 21 29Server4000 MsgPdbl 102 122Server4000 MsgAnel1-2 185 198
7.2 Como foi feita a Calibração
O tráfego no modelo foi inserido a partir de tabelas de distribuição de
freqüências. Comparando-se os dados reais e os dados resultantes da simulação, e
detectando-se qualquer discrepância, deve-se otimizar o agrupamento de dados da
tabela de distribuição de frequência que representa o objeto que possui resultados
discrepantes em relação aos dados do mundo real.
As amostras coletadas tinham dados com valores extremos. Por exemplo, para
os dados referentes ao intervalo de entre-chegada das mensagens, observamos que,
para uma mesma amostra, havia valores muito pequenos, como 0,01s, e valores muito
grandes, como 600s. A razão dessa diferença é explicada pela própria funcionalidade
da aplicação. Quando estamos nos referindo aos intervalos de entre-chegadas das
mensagens da aplicação TELNET, estamos na verdade constatando a ação real de
um usuário que está digitando caracteres no microcomputador. Se o mesmo está
freqüentemente digitando, os intervalos entre as mensagens são curtos; porém,
74
quando o usuário fica 10 minutos (600s) sem digitar nada, verificamos um grande
intervalo de tempo entre as mensagens.
Ao utilizarmos a distribuição de freqüências, temos que agrupar os dados em
um intervalo de valores. Se o agrupamento de valores for muito grande, poderemos
perder informações. Seja o exemplo mostrado na tabela 7-2.
TABELA 7-2: Exemplo um de agrupamento de distribuição de freqüência
tempo (s) % acumulada1 0,892 0,9550 0,99200 1,00
Na tabela 7-2 vemos que 89% dos dados têm intervalos de entre-chegadas
entre 0 e 1 s. Podemos perceber que o intervalo entre 0 e 1 está muito grande, pois
ele abrange considerável porção da amostra. Ao informarmos uma distribuição deste
tipo no simulador, ele escolherá valores aleatórios neste intervalo, podendo resultar
em valores muito diferentes do real. Porém, se subdividirmos o intervalo entre 0 e 1
em intervalos menores, poderemos informar com mais precisão onde está a maior
concentração dos dados. A partir da tabela 7-2, iremos subdividir o primeiro intervalo,
gerando uma segunda distribuição de freqüência para a amostra, como é mostrado na
tabela 7-3.
TABELA 7-3: Exemplo dois de agrupamento de distribuição de freqüência
Valor % acumulada0,03 0,500,06 0,550,09 0,600,1 0,740,5 0,800,9 0,851 0,892 0,9550 0,99200 1,00
Na tabela 7-3, o simulador irá gerar 50% dos intervalos com valores entre 0 e
0,03s, fazendo com que o resultado seja mais preciso do que o apresentado na tabela
7-2, onde 89% dos intervalos seriam gerados entre 0 e 1s.
75
Durante a calibração do modelo foram feitas algumas alterações nas tabelas de
freqüência, objetivando escolher melhores intervalos para a distribuição empírica. Tais
alterações trouxeram maior precisão nos dados.
7.3 Análises sobre o modelo validado
Através das medições feitas no sistema real sobre os canais de utilização,
pudemos verificar que tais links estão desbalanceados, sendo que alguns estão
sobre-utilizados e outros sub-utilizados. Ao validarmos o modelo, os links haviam
apresentado utilização semelhante ao real.
A utilização do canal de comunicação é tratada, neste trabalho, como sendo o
tempo total utilizado durante a simulação dividido pelo tempo de simulação. O tempo
total utilizado se refere ao tempo de transmissão somado ao tempo de propagação. O
tempo de transmissão é calculado dividindo-se o tamanho total de bits transmitidos
pela velocidade do circuito. O tempo de propagação se refere ao tempo médio de
atraso que um pacote leva para atravessar o link multiplicado pelo número de pacotes
trafegados. O canal de comunicação é full duplex permitindo transmissão de dados
nos dois sentidos simultaneamente.
Atualmente, a Prodabel vem calculando a utilização dos links baseada somente
no tempo de transmissão, o que no nosso entender pode incorrer em falhas de
avaliação, pois o tempo de propagação é significativo e não deve ser desprezado.
76
No gráfico 7-1, podemos ver como está a utilização dos links da RMI em ordem
crescente de utilização.
GRÁFICO 7-1: Utilização dos links da RMI - Modelo validado
O gráfico 7-1 está representando, de forma bidimensional, o fluxo dos dados
nos dois sentidos de comunicação.
Em Menascé et al. [42] estão descritas duas regras práticas com relação à
utilização. Uma das regras práticas define um parâmetro de 35% como limite para a
garantia de bom desempenho do canal. Outra regra prática já define que o pico de
utilização não deve exceder 90%. Isto porque, assume-se que a razão entre o pico e a
média de utilização deve ser de 2.25:1, o que faz com que a média seja inferior a 40%.
Em Chou [16], define-se que a velocidade das linhas devem ser dimensionadas para
alcançar um nível de utilização de 60 a 70%.
Essas considerações serão trazidas para o nosso trabalho, de forma a
servirem de embasamento quando formos analisar a utilização dos links e realizar
alterações no modelo para ajustar as velocidades dos canais de comunicação.
Estaremos considerando a faixa entre 30 e 60% como uma utilização razoável. Para
se melhorar a análise dos dados seria necessário um histórico do comportamento dos
canais de comunicação para se verificar a variabilidade de uso.
0
10
20
30
40
50
60
70
80
Uti
lizaç
ão (
%)
501-7118
501-7131
501-6685
501-6671
501-6683
501-6686
501-7103
501-6678
501-6684
501-6668
501-6680
501-6682
501-7100
501-6641
501-7104
501-6679
501-6642
501-7111
501-6647
501-6644
Links
Ponta1 do link Ponta2 do link
77
Pelo gráfico 7-1 podemos observar que o canal de comunicação entre a
Regional Venda Nova e a PBH1212 (link 501-6644) é o link mais utilizado. O segundo
link mais utilizado é o link entre a SMSA e a PBH1212 (link 501-6647).
O backbone que é formado pelas ligações Prodabel-Tupis (link 501-7103),
PBH1212-Prodabel (link 501-7100), e Tupis-PBH1212 (link 501-7104) está com
utilização variando entre 05 e 30%.
7.4 Situações de “What if”
Pretendemos criar aqui algumas situações sobre o modelo ajustado para
avaliação do comportamento do modelo em circunstâncias diversas. Escolhemos duas
situações de falha e uma alteração na topologia e operação da WAN para
verificarmos: a) O que aconteceria se um dos roteadores do backbone falhasse; b) O
que aconteceria se um dos links do backbone falhasse; c) O que aconteceria se a
topologia em anel estivesse em operação.
7.4.1 Falha de um dos roteadores do backboneAlteramos o modelo de forma a colocar o roteador da PBH1212 durante uma
hora em estado de down. Queremos com isto analisar como ficaria o tráfego nos
outros links que acessam o backbone central.
A utilização dos links depois da simulação é apresentada no gráfico 7-2.
GRÁFICO 7-2: Utilização dos links na falha do roteador 10.13.0.1
501-
7389
501-
7131
501-
6685
501-
6671
501-
6683
501-
6686
501-
7103
501-
6678
501-
6684
501-
6668
501-
6680
501-
6682
501-
7100
501-
6641
501-
7111
501-
7104
501-
6679
501-
6642
501-
6647
501-
6644
0
10
20
30
40
50
60
70
80
90
100
Uti
lizaç
ão(%
)
Links
modelo validado modelo com roteador down
78
Com a queda do roteador 10.13.0.1, houve significativo aumento de carga para
o link que interliga a Tupis e a PBH1212 (link 501-7104), chegando este canal a ter
aproximadamente 60 % de utilização. Outro link do backbone, o 501-7103, também
teve aumento de utilização, chegando a 25%. Como o roteador 10.13.0.1 da PBH1212
interligava também redes provenientes dos anéis 3 e 8, o tráfego desses passou a ser
feito pela outra ponta do anel. Grande destaque é dado ao link 501-6641 que
corresponde à conexão do anel 3 com a Tupis. Esse link passou a trafegar os dados
que antes eram transmitidos pelo link 501-6644 e que, com a queda do roteador
10.13.0.1, ficou desativado.
Com a falha do roteador 10.13.0.1, o tráfego do backbone passa a ser feito
somente pelos canais 501-7103 e 501-7104. Isto significa que a queda do roteador
10.13.0.1 implica na perda do link 501-7100, sobrecarregando os outros canais do
backbone. Para se evitar a perda do link 501-7100, na situação de falha do roteador
10.13.0.1, sugere-se o remanejamento deste canal para uma das portas do segundo
roteador existente na PBH1212, no caso o 10.13.0.231. Com isso, espera-se que o
tráfego que anteriormente circulava pelo circuito 501-7100 continue nomalmente,
enquanto o canal 501-7104 passe a redirecionar somente o tráfego dos anéis 3 e 8
que em situação normal estariam conectados diretamente ao roteador 10.13.0.1.
7.4.2 Falha de um dos links do backboneAlteramos o modelo de forma a colocar o link 501-7100, que interliga a
Prodabel com a PBH1212, em estado de down. Queremos com isto analisar como
ficaria o tráfego do backbone central.
A utilização dos links depois da simulação pode ser vista através do gráfico 7-3.
79
501-
6685
501-
7131
501-
6683
501-
7103
501-
6678
501-
6686
501-
6641
501-
6680
501-
7100
501-
6642
501-
7111
501-
7104
501-
6647
0
5
10
15
20
25
30
35
40
45
50
Uti
lizaç
ão (
%)
Links
modelo validado modelo com link down
GRÁFICO 7-3: Utilização dos links na falha do link 501-7100
Com a queda do link 501-7100, houve aumento na utilização do canal 501-
7104 para a faixa de 45% e também do canal 501-7103 para aproximadamente 22%.
A utilização dos outros links que chegam ao backbone continuam estáveis. Podemos
ver que o rearranjo do tráfego que anteriormente passava pelo link 501-7100
concentra-se somente nos outros dois links do backbone, ou seja, links 501-7103 e
501-7104. O que podemos constatar é que o backbone possui banda suficiente para
contenção em situação de falha do link 501-7100.
7.4.3 Topologia em anel em operação
A RMI está provisoriamente trabalhando com a atual estratégia de roteamento
(estático), o que está influenciando na real representação topológica da rede para o
primeiro modelo construído neste trabalho (FIG. 6-1). Pode-se observar, através da
FIG. 2-1 e da FIG. 6-1, que os anéis não estão se fechando. Cada um dos anéis está
dividido em dois, representando na verdade uma rede em estrela e não uma rede em
anel.
80
Em breve a RMI estará operando com a sua topologia planejada e, por isso,
alteramos o modelo de forma a conectar os anéis e visualizar o comportamento dos
links diante desta mudança (FIG. 7-1). Foi utilizado protocolo de roteamento dinâmico
com métrica de menor salto.
Abaixo, na tabela 7-4, verificamos a taxa de utilização dos links para a nova
representação do modelo.
TABELA 7-4: Utilização dos links com topologia em anel
links Utilização(%)
501-6641 0501-7111 0501-7118 0501-7814 0501-6682 0.2501-6684 0.2501-7131 0.81501-6683 4.55501-7103 4.85501-6686 5.79501-6668 18.86501-6677 20.5501-6680 25.15501-6642 25.6501-7100 31.56501-7104 33.42501-6678 36.32501-6679 36.85501-6685 41.65501-6647 68.74501-6644 138.01
81
Iremos utilizar a tabela 7-4 como sendo os novos valores do modelo validado
pois, ela representa uma topologia que será a adotada pela Prodabel para suas
futuras implementações de carga de tráfego na RMI. Na figura 7-1 podemos verificar
essa topologia e no gráfico 7-4 podemos ver os valores da tabela 7-4, de forma
gráfica. Entendemos que uma vez validado o modelo em conformação com o sistema
real passa-se a ter liberdade de representar o mesmo tráfego com formas topológicas
diferentes, uma vez que os originadores desse tráfego continuarão gerando a mesma
quantidade de mensagens com a diferença de estarem sendo roteadas por diferentes
canais.
FIGURA 7-1: Modelo com topologia em anel
82
GRÁFICO 7-4: Utilização dos links para topologia em anel
No gráfico 7-4, observa-se que, para o mesmo tráfego validado (TAB. 7-1)
temos uma utilização diferente para os canais de comunicação ao alterarmos a
topologia. O gráfico 7-4 representa a utilização dos canais de comunicação para a
topologia mostrada na figura 7-1.
Com essa nova representação da topologia em anel e o uso do roteamento
dinâmico baseado no menor salto, destacam-se, com taxas de utilização mais
elevadas, os links 501-6644 e 501-6647. Todos os demais links concentram-se em
faixas de utilização abaixo de 40%. Os links do backbone estão com menos de 20%
de utilização.
7.5 Resumo e Conclusões do capítulo
O modelo foi validado a partir de comparações entre a quantidade de
mensagens geradas no COMNET III e a quantidade de mensagens geradas no
sistema real. Foi necessário realizar calibrações no modelo de forma a alterar as
tabelas de distribuições de frequência acumulada para realizar um melhor
agrupamento de dados. O modelo validado (FIG. 6-1 e GRAF. 7-1) apontou grandes
diferenças na utilização dos canais de comunicação. Alguns links estão pouco
utilizados, como é o caso dos links 501-7118, 501-6685, 501-7131, 501-6671 e 501-
7103 que possuem menos de 10% de utilização, e outros links estão muito utilizados
como é o caso do link 501-6644.
501-6641
501-7111
501-7118
501-7814
501-6682
501-6684
501-7131
501-6683
501-7103
501-6686
501-6668
501-6677
501-6680
501-6642
501-7100
501-7104
501-6678
501-6679
501-6685
501-6647
501-6644
0
10
20
30
40
50
60
70
80
90
100U
tiliz
ação
(%
)
Links
Ponta1 do link Ponta2 do link
83
Após ter-se dado credibilidade ao modelo foram simuladas algumas situações
de falha e de alteração na operação e na topologia do modelo. O sistema apresentou
ter banda suficiente para continuar atendendo à demanda de tráfego na situação de
falha do link 501-7103. No caso da queda do roteador 10.13.0.1 sugere-se a
realocação do link 501-7100 para uma das portas do roteador 10.13.0.231, caso
contrário o link 501-7100 ficará inativo e haverá sobrecarga no link 501-7104.
Com a alteração da topologia para anel com roteamento dinâmico passamos a
ter um novo modelo validado (FIG. 7-1 e GRAF. 7-4) com uma representação mais
significativa para as próximas simulações que realizaremos no modelo. Verificamos
que, ao se utilizar a métrica de menor salto para o roteamento dinâmico, ocorre alta
utilização do canal de comunicação identificado como 501-6644.
84
Capítulo 8
FASE 6: Previsão de Novas Cargas
Este capítulo irá abordar formas de levantamentos no intuito de se obter
informações sobre novas cargas a serem implementadas na WAN. A partir desse
levantamento são escolhidos alguns cenários para serem representados no modelo.
Os resultados desses cenários, bem como a apresentação de propostas alternativas
para o sistema são mostrados no Capítulo 9.
8.1 Levantamento de novas cargas
Para a execução desta etapa, foram realizados questionários e entrevistas com
todas as áreas da empresa que apresentaram projetos para a RMI8. Esses projetos
constam no documento de Planejamento 1997/98 da Prodabel [49], o qual serviu como
guia para a condução das entrevistas. De modo geral, as entrevistas tinham o objetivo
de focalizar o tráfego na WAN e, por isso, os projetos que se referiam à redes locais
ou outras atividades de desenvolvimento e pesquisa foram desconsiderados.
As entrevistas focalizaram vários aspectos, representados pelas perguntas:
a) Onde ficará o servidor da aplicação?
b) Onde ficarão os clientes desta aplicação?
c) Quantas máquinas serão disponibilizadas por local?
d) Qual a estimativa do horário de pico?
e) Quantos acessos cada usuário fará no horário de pico?
f) Tem-se a estimativa de dados a serem trafegados?
8As entrevistas e questionários foram realizados juntamente com analistas da GRP (Gerência de Projetosda RMI).
85
g) Quando estará funcionando esta aplicação?
Esta etapa enfrenta grandes dificuldades, pois é difícil obter informações dos
usuários sobre sistemas que ainda não estão em funcionamento. Não se pode medir
um sistema a menos que ele esteja operacional. Não é possível medi-lo em suas fases
de projeto e desenvolvimento. Para se planejar modificações é necessáro produzir
estimativas de parâmetros numéricos sobre o sistema atual [51].
Durante o levantamento, encontramos situações diferentes para o aumento de
novas cargas na WAN, entre elas:
n Aumento de tráfego para aplicações existentes;
n Implantação de novas aplicações;
n Atualização de tecnologias para aplicações existentes (por exemplo,
de emulação de terminal para cliente-servidor).
Além dos questionários e entrevistas, pode-se fazer previsão de novas cargas
baseando-se em dados históricos. Nos levantamentos realizados, não foi possível
obter históricos sobre a evolução da RMI, uma vez que a implantação da mesma é
recente e ainda estão sendo consolidados projetos para sua administração. Com isto,
a utilização de técnicas de previsão baseadas na disponibilidade e confiabilidade de
dados históricos ficou prejudicada.
Para um embasamento histórico, entre outras informações que podem ser
obtidas através de gerenciamento SNMP, sugerimos a obtenção das informações
abaixo, para um período trimestral:
a) Número de microcomputadores em cada rede local;
b) Resumo estatístico com média, mínima e máxima da utilização dos canais
de comunicação no horário de pico;
c) Número de servidores;
d) Número de aplicações disponíveis na WAN;
e) Número de redes e links.
Segundo Menascé et al. [42], quatro padrões históricos de dados podem ser
obtidos, sendo eles tendenciosos, estáveis, cíclicos e sazonais. Os tendenciosos
refletem as cargas que tendem a aumentar ou diminuir; os estáveis não demonstram
nenhuma inclinação para alteração; os sazonais e cíclicos são similares, pois
apresentam flutuações de comportamento. Para cada uma das métricas escolhidas,
deve-se fazer a plotagem dos dados e, de modo visual, pode-se encaixar o
comportamento dos dados em um dos padrões do histórico de dados.
86
8.2 Cenário 1: Aumento de tráfego para aplicação existente
Através do levantamento de novas cargas é possível verificar, por exemplo,
qual o acréscimo do número de máquinas para executarem aplicações já existentes.
Este novo número de máquinas trará uma nova carga ao modelo.
A princípio, através do levantamento realizado, haverá um aumento de 200
microcomputadores na RMI para o período de 97/98. Isto representa
aproximadamente 20% de microcomputadores hoje existentes na rede WAN.
Pretende-se verificar como ficarão os links do backbone para esta nova demanda de
tráfego. Veremos, na próxima fase, como ficará a utilização dos canais de
comunicação diante deste aumento de tráfego.
8.3 Cenário 2: Introdução de nova aplicação
Outra demanda de crescimento verificada nos planejamentos da Prodabel para
1998 foi a integração da Internet com a RMI. Como a Internet ainda não está
disponibilizada no ambiente da Rede Municipal de Informática, não é possível fazer
medições sobre a mesma. Atualmente, o acesso dos órgãos da Prefeitura de Belo
Horizonte à Internet é feito através de um banco de modens a um servidor localizado
na Prodabel e que está desconectado da RMI. Portanto, a fim de simular uma das
aplicações da Internet, utilizamos a caracterização da aplicação WWW (Word Wide
Web), realizada sobre a rede da UFMG (Universidade Federal de Minas Gerais) e
descrita na dissertação de Barros [4], para incorporar em nosso modelo.
Word Wide Web foi o nome dado a um projeto desenvolvido pela CERN em
1989, em Geneva, para projetar e desenvolver uma série de conceitos de protocolos
de comunicação e sistemas que incorporassem a interligação de vários tipos de
informação, de acordo com o conceito de hipermídia [27]. O projeto WWW seguiu três
princípios: 1) abolição do conceito de armazenamento de informação centralizada; 2)
independência geográfica; 3) interface uniforme simples que esconda os detalhes dos
formatos dos protocolos envolvidos na transferência de documentos.
Comer [22] define o WWW como um repositório on-line , de larga escala, onde
os usuários podem procurar por informações utilizando um navegador (browser). O
WWW utiliza técnicas de hipertexto e hipermídia. O hipertexto permite que palavras
selecionadas no texto possam ser expandidas para fornecer outras informações. A
hipermídia contém, além do texto, imagens digitalizadas ou gráficos. Por diversas
87
vezes, ao se utilizar o WWW, muitos usuários fazem download de arquivos, o que na
verdade pode ser um encapsulamento do FTP dentro do WWW.
Para a modelagem da aplicação WWW, utilizamos o intervalo de entre-
chegadas das mensagens como seguindo a distribuição de Weibull com parâmetros
de shape=0.40971 e scale=2.02417. O tamanho das mensagens de resposta foi
caracterizado pela distribuição Lognormal com parâmetros de average=0.00928 e
std.dev=0.660007. Já o tamanho das mensagens de origem foi definido através de
tabela de distribuição de frequência [4].
Foi feito um levantamento dos usuários que hoje acessam o servidor WWW da
Prodabel através de comunicação via modem. Esta relação de usuários foi agrupada
na tabela 8-1, de acordo com o anel com que os usuários fazem a comunicação. A
Tabela 8-1 reflete a situação atual dos usuários da Internet e é esta distribuição atual
que iremos modelar no simulador. A Prodabel tem a estimativa de futuramente estar
disponibilizando mais de 800 usuários de Internet na RMI.
TABELA 8-1: Atual distribuição de usuários da Internet na RMI
Anel No. De usuáriosAnel-1 31Anel-2 16Anel-3 12Anel-4 24Anel-5 26Anel-6 3Anel-7 3Anel-8 3Anel-9 3PBH1212 49
Para representar estes dados no modelo, foi necessário alocar a fonte
geradora de tráfego (source message) ao objeto computer group. Neste objeto é
possível informar o número de equipamentos que geram este mesmo tráfego. Na
FIG.8-1, pode ser vista a representação do modelo para a adição dessas novas
cargas.
88
FIGURA 8-1: Modelo de simulação da RMI com acréscimo da aplicação WWW
Da mesma forma como introduzimos a carga da aplicação WWW através da
caracterização realizada em outros trabalhos, pode-se construir outros cenários com
caracterizações de cargas de outras aplicações ainda não existentes na RMI, porém já
caracterizadas em outros ambientes.
Em Arlitt & Williamson [3], tem-se a modelagem do tráfego da Internet para ser
utilizado como input no SimKit, que proporciona ambiente para simulação. Já em
Heyman & Lakshman [34], foi realizada a caracterização de modelos de tráfego de
vídeo. Outra interessante caracterização, porém mais focada no servidor, se refere ao
tráfego de documentos no servidor WWW [6].
Veremos, na próxima fase, como ficará a utilização dos canais de comunicação
para o modelo representado pela figura 8-1, diante da implementação do tráfego da
aplicação WWW.
89
Capítulo 9
FASE 7: Previsão de Desempenho eFASE 8: Alternativa para o sistema
9.1 FASE 7: PREVISÃO DE DESEMPENHO
Conforme Menascé et al.[42], o coração do planejamento de capacidade está
na habilidade de prever adequadamente a execução de um sistema para uma
determinada carga de trabalho / tráfego.
Para se fazer a previsão, é necessário o uso de alguma técnica. Resultados
muito acurados não serão possíveis de serem obtidos, porém é necessária a obtenção
de tendências corretas.
A técnica de previsão de desempenho utilizada para este trabalho foi a
simulação. Conforme pode ser visto na figura 2-2, esta técnica apresenta boa relação
de custo e precisão de dados.
No gráfico 9-1, está representado o resultado do cenário 1, discutido na Fase
6, onde foi acrescentado tráfego ao modelo para previsão do seu desempenho.
90
GRÁFICO 9-1: Utilização dos canais de comunicação após acréscimo de 20% denovas cargas
Pode-se ver que com o acréscimo de 20% do tráfego ao modelo, destaca-se a
linha 501-6644, que passou a ter 97% de utilização. O canal 501-6647 também
apresentou significativa utilização da banda passante, chegando ao valor de 53% de
utilização. Há que se observar que, mesmo com o aumento de 20% do tráfego, alguns
canais de comunicação ainda estão pouco utilizados, como é o caso dos links 501-
6641, 501-7111, 501-7118, 501-7814, 501-6684, 501-6682, 501-7131, 501-6683 e
501-7103, que não atingiram 10% de utilização do canal de comunicação.
Destacamos aqui o canal de comunicação 501-7103, que é um dos links do
backbone. Este link tem velocidade de 128 kbps e possui baixa utilização. Os demais
links do backbone, que são compostos pelos canais 501-7100 e 501-7104, mesmo
após a adição de novas cargas, permanecem com utilização abaixo de 20%.
Outra carga que acrescentamos ao modelo se refere à incorporação da
aplicação WWW descrita no cenário 2 da fase 6. Apresentamos a seguir, no gráfico 9-
2, o resultado da utilização dos canais de comunicação após a simulação.
501-
6641
501-
7111
501-
7118
501-
7814
501-
6684
501-
6682
501-
7131
501-
6683
501-
7103
501-
6686
501-
6668
501-
6677
501-
6680
501-
6642
501-
7100
501-
7104
501-
6678
501-
6679
501-
6685
501-
6647
501-
6644
0
10
20
30
40
50
60
70
80
90
100
Uti
lizaç
ão (
%)
Links
modelo validado carga de + 20%
91
GRÁFICO 9-2: Utilização dos canais de comunicação após adição da aplicaçãoWWW
Significativas utilizações ocorrem para os links 501-6684 e 501-6683, que
chegam a alcançar 100 % de utilização. Os links do backbone se comportaram de
maneira diferenciada com a adição desta nova carga. O link 501-7103 teve baixíssima
utilização, uma vez que ele não representava a menor rota para se alcançar o servidor
WWW que está localizado na Prodabel. O link 501-7104 teve utilização próxima de
20% e o link 501-7100 alcançou cerca de 50% de utilização. Os maiores destaques
para a adição da aplicação WWW ficaram para os links 501-6683, 501-6686 e 501-
6684. Esses links interligam os anéis 1, 4 e 5 respectivamente, ao backbone. Pela
tabela 8-1 podemos observar que esses anéis possuem cerca de 25 a 30 usuários da
aplicação WWW, o que justifica tamanho acréscimo na utilização do canal de
comunicação.
9.2 FASE 8: ALTERNATIVAS PARA O SISTEMA
Diante dos resultados obtidos com o modelo, pode-se avaliar algumas
alternativas que possam trazer uma melhor relação de custo X benefício. Para o
modelo em estudo, propõe-se uma variação da capacidade das linhas de
501-
6641
501-
7111
501-
7118
501-
7814
501-
7131
501-
6683
501-
7103
501-
6686
501-
6668
501-
6677
501-
6680
501-
6642
501-
7100
501-
6682
501-
7104
501-
6678
501-
6679
501-
6685
501-
6647
501-
6684
501-
6644
0
10
20
30
40
50
60
70
80
90
100U
tiliz
ação
(%
)
Links
modelo validado modelo com www
s
92
comunicação de forma a trazer um melhor equilíbrio para os canais de comunicação.
A busca deste equilíbrio fará com que haja diminuição de custos e melhoria de
qualidade. A diminuição dos custos está relacionada com a solicitação, à
concessionária de telecomunicações, de linhas de menor velocidade e, portanto, de
menor custo. Já a melhoria de qualidade está relacionada com o aumento de
velocidades das linhas de comunicação que estão apresentando alta utilização do
canal de comunicação.
Desta forma, foi simulado um modelo com diminuição da velocidade de 6 links
de comunicação e aumento de velocidade de 4 links de comunicação. Os links que
tiveram a velocidade reduzida de 19.2 kbps para 9.6 kbps foram: 501-7118, 501-7814,
501-7111, 501-6677 e 501-7131. Os links que tiveram a velocidade aumentada de
19.2 kbps para 64 kbps foram: 501-6683, 510-6686, 510-6685 e 501-6644. Foi
reduzida também a velocidade do link 501-7103, de 128 kbps para 64 kbps.
GRÁFICO 9-3: Utilização dos links após alteração de velocidade
Através do gráfico 9-3, pode-se observar que ainda existem alguns links que
permanecem com baixa utilização, porém são circuitos que serão utilizados como
backup. Ou seja, na situação onde o circuito comumente utilizado por determinado
anel, estiver com falha na comunicação, será acionado o circuito do outro extremo do
anel. Neste caso, a baixa utilização que estamos verificando na situação normal
poderá ser elevada nas situações de contingência. Se a disponibilidade do circuito
501-
7100
501-
7103
501-
7104
501-
6680
501-
6683
501-
6677
501-
6685
501-
7131
501-
6678
501-
7118
501-
6644
501-
6641
501-
7814
501-
6679
501-
6686
501-
6647
501-
6642
501-
7111
501-
6668
501-
6682
501-
6684
0
10
20
30
40
50
60
70
80
90
100
Uti
lizaç
ão (
%)
Links
modelo c/ 20% e WWW modelo alterado
93
comumente utilizado for muito baixa, então será viável manter os circuitos de backup
com velocidade igual à do circuito mais utilizado. Porém, se a disponibilidade for alta,
deve-se avaliar a relação custo x benefício de se ter altas velocidades para circuitos
pouco utilizados. Para uma avaliação melhor desta situação é necessário um histórico
dos níveis de serviços da RMI, ou seja, confiabilidade, disponibilidade e custo dos
canais de comunicação.
De modo geral, após as alterações realizadas no modelo, pode-se observar
maior equilíbrio na utilização dos canais, mantendo a maioria dos links na faixa dos 35
a 50% de utilização. Podemos observar que o link 501-7103, integrante do backbone,
ainda continua pouco utilizado, mesmo com a redução de sua velocidade de 128 Kbps
para 64 Kbps. Porém, esse link poderá ter a utilização aumentada nas situações de
falha de um dos outros dois links do backbone.
O custo envolvido para a disponibilização das novas aplicações consideradas
neste trabalho, ou seja, a adição de mais 20% de máquinas e a implementação da
aplicação WWW na RMI, poderá ser visto através do cálculo abaixo. Este cálculo já
considera a proposta de ajustes nos canais de comunicação para comportamento
similar ao apresentado no gráfico 9-3.
5 Circuitos de 9.6 Kbps = 5 x R$ 219,91 = 1.099,55
36 Circuitos de 19.2 Kbps = 36 x R$ 249,55 = 8.983,80
8 Circuitos de 64 Kbps = 8 x R$ 452,11 = 3.616,88
2 Circuitos de 128 Kbps = 2 x R$ 522,30 = 1.044,60
TOTAL = 14.744,83
O custo atual da RMI, para os canais de comunicação que utilizam PPP, é de
R$14.152,98 (Ver: Item 4.2.6). Este valor está muito próximo do valor que obtivemos
acima (R$14.744,83). O que podemos concluir é que ao otimizarmos a relação entre o
uso do canal de comunicação e a velocidade que o mesmo deve ter para suportar o
tráfego demandante, conseguimos obter praticamente a mesma relação de custo,
porém com mais aplicações disponíveis. Ou seja, pelo mesmo custo mensal, a
Prodabel poderá implantar os cenários que aqui delineamos. É necessário no entanto,
alocar adequadamente cada canal de comunicação com a velocidade demandada
pelo uso.
Outras alternativas de melhorias para o sistema, além do aumento nas
velocidades dos canais de comunicação, podem ser obtidas se forem utilizadas outras
94
métricas de roteamento dinâmico sem ser apenas a de menor salto. Se o roteamento
for baseado também na métrica de utilização do canal de comunicação, pode-se
considerar que dinamicamente o sistema estará realizando avaliação dos canais de
comunicação e fazendo a opção pelo melhor caminho e não apenas pelo menor
caminho. Pode-se também alterar a forma de utilização da aplicação mais utilizada na
rede, ou seja, o TELNET. Como pode-se notar nos gráficos 5-7, 11-13, 11-15 e 11-17,
essa aplicação é responsável por grande número de transmissões de pacotes que na
verdade carregam poucos dados. Isto porque, essa é uma aplicação interativa, onde
cada caracter digitado é ecoado no terminal. Sugere-se que seja utilizado bufferização
nos emuladores de terminal para que haja otimização na relação da quantidade de
pacotes enviados e a quantidade de dados contida nos mesmos.
95
Capítulo 10
Conclusões
A Prodabel foi empreendedora ao alterar o seu parque computacional
implementando o downsizing em seus sistemas de informação. Tal mudança foi de
grande importância para trazer a discussão de um novo ambiente em um novo
patamar de paradigmas. Após 21 anos, desde a sua fundação, a Prodabel, que
sempre utilizou plataformas mainframes, alterou radicalmente sua estrutura
computacional. Essa alteração demanda estudos de novas formas de controle e
entendimento do ambiente. Há um espaço vazio para a análise deste novo ambiente
que certamente será preenchido por novos softwares, equipamentos e métodos. Na
verdade, o mercado oferece uma grande variedade destas opções que no entanto não
se ajustam em todos os ambientes.
Esta dissertação é uma tentativa de mostrar que existe um caminho que pode
ser percorrido com métodos, técnicas e ferramental apropriado. O Planejamento de
Capacidade para o ambiente WAN da RMI foi então o referente empírico para
delinearmos esta discussão. No que se refere às comunicações de longa distância, o
ambiente de mainframe difere bastante das plataformas em redes. Na arquitetura
SNA, da IBM, cada terminal tem uma velocidade associada. As aplicações são em
modo caracter, não fazendo uso de recursos gráficos. Hoje, estes componentes
básicos são completamente diferentes na Prodabel. Não apenas um microcomputador
utiliza uma linha para o acesso remoto, mas um grupo de micros que se interligam
localmente e fazem uso de aplicações com perfis diversos, podem estar conectados
remotamente através de um único modem. Com a descentralização, vários protocolos
e tecnologias podem e são utilizados para propiciar a comunicação de longa distância.
Entre estas tecnologias, tem-se X.25, Frame-Relay, ATM (Assynchronous Transfer
96
Mode), RDSI (Rede Digital de Serviços Integrados), PPP (Point-to-Point Protocol),
entre outros.
Em busca de entender o atual ambiente, propomos que a utilização do
Planejamento de Capacidade seja a chave para entender com método o
comportamento não só da atual e recente mudança que a Prodabel realizou, mas
também para prever a futura e breve mudança que a Prodabel realizará nos perfis das
aplicações da RMI e que possam refletir na tecnologia a ser adotada na WAN.
A Metodologia de Planejamento de Capacidade que utilizamos foi
completamente abrangente e genérica. Assim como em Menascé et al.[42] podem ser
verificadas diversas situações do uso desta metodologia, entre elas planejamento de
capacidade de máquinas servidoras ou mesmo planejamento de capacidade para filas
de atendimento, acrescentamos, com este trabalho, mais uma situação em que esta
metodologia se adequa.
As etapas da metodologia que demandaram mais tempo e estudo neste
trabalho foram a Fase 3 - Caracterização do Tráfego - e a Fase 5 - Validação e
Calibração do Modelo. Ou seja, basicamente a entrada e a saída do modelo. Depois
de diversas comparações entre estes dados de entrada e saída, pôde-se verificar a
aproximação dos mesmos e conseqüentemente comprovar não somente a
credibilidade do modelo, mas também a credibilidade da ferramenta COMNET III.
O tráfego do modelo poderia ter sido introduzido através de um arquivo no
formato que o COMNET III consegue ler e reproduzir o sistema real através da
simulação. Porém, optamos por uma análise estatística dos dados, pois desta forma
procurou-se encontrar um modelo que pudesse ser representado não somente por
dados empíricos, mas também por distribuições de probabilidade teóricas. Uma
amostra de dados caracterizada por uma distribuição de probabilidade teórica
possibilita maior variedade de testes que podem ser realizados no modelo do que uma
amostra caracterizada através de uma distribuição empírica. Isto porque, na
distribuição teórica, podemos alterar o tráfego gerado pelo objeto que a utiliza através
de mudança dos parâmetros da mesma. Por exemplo, a distribuição exponencial
utiliza a média como parâmetro, portanto basta alterar este parâmetro se for
necessário aumentar ou diminuir o tráfego. Já na distribuição empírica, aumentar ou
diminuir o tráfego pode ser feito somente através de escala e não através de
parâmetros estatísticos. A representação do tráfego no modelo através de distribuição
empírica traz menos flexibilidade de análises e testes do que a representação do
tráfego através de distribuições teóricas.
97
O uso da análise estatística dos dados de entrada do modelo de simulação
está reforçado em diversos livros que abordam o tema de simulação [38] [60] [25]. A
estatística aparece como tópico indispensável à compreensão do processo de
simulação.
O ferramental utilizado para se realizar Planejamento de Capacidade é um
componente importante. Neste trabalho foram utilizados programas de monitoração
(Tcpdump), de análise (Iptraf), estatísticos (Minitab e C-FIT), de gerenciamento (ISM),
e simulador (COMNET III) os quais possibilitaram a resolução dos problemas de cada
etapa. O COMNET III sugere várias ferramentas de monitoração que geram entrada
de dados adequada para ser feita a simulação. Foi utilizado o Tcpdump, pois o mesmo
é um software disponível na Internet e pôde gerar todas as informações que eram
necessárias à análise. Os outros produtos de monitoração são comerciais e, durante o
trabalho, foi impossível fazer a aquisição de um deles.
Como trabalho futuro, sugere-se realizar a caracterização da carga de tráfego
de aplicações baseadas em telnet e aplicações cliente-servidor. Foi detectado nos
levantamentos de novas cargas que a Prodabel irá fazer esta mudança em seus
sistemas, convertendo-os para cliente-servidor; porém, como será o tráfego das
aplicações neste novo ambiente? Para a mesma aplicação, para o mesmo número de
usuários, como será a utilização dos canais de comunicação para esta mudança de
tecnologia? Outro trabalho decorrente deste se refere ao estudo do nível de serviço
referente ao tempo de resposta para servidores remotos, onde se deve agregar, além
da rede WAN, dados sobre a rede local e sobre o desempenho do servidor. Desta
forma poderia ser explorada a relação entre tempo de resposta e utilização dos canais
de comunicação, basicamente tentando-se responder à seguinte situação: Qual a
influência no tempo de resposta quando se está trabalhando com altas taxas de
utilização dos canais de comunicação?
Diversos cenários podem ainda ser testados com o modelo construído. Entre
eles, poderia ser feita a construção de uma topologia em estrela com mais roteadores
concentrados na PBH1212, pois a mesma é o destino mais solicitado na RMI. Ou,
mesmo, poder-se-ia construir uma topologia em estrela com hierarquia. Desta forma,
poderia ser avaliado se há outra formação de topologia que traga menor quantidade
de links e que sejam de menor velocidade, a serem contratados da concessionária. A
informação final desejada é o custo X benefício. Pode-se também verificar uma outra
distribuição das redes pelos anéis, baseada na informação dos destinos que elas mais
acessam. Por exemplo, as redes que têm interesse em acessar a servidora presente
98
na PBH4000 deveriam ficar no mesmo anel que esta. O que se verificou é que as
redes do anel 5, onde está a PBH4000, não têm interesse na servidora deste local.
O Planejamento de Capacidade para este trabalho significa tratar
cientificamente o comportamento de uma rede de comunicação. O uso desta
metodologia, técnicas e ferramentas está imbuído de preocupações com a qualidade
de serviço que deve ser prestado aos usuários deste sistema de computadores; está
também repleto de preocupações com a utilização dos recursos públicos de forma a
trazer benefícios, sem no entanto, criar desperdícios. Utilizar o planejamento de
capacidade significa também diminuir a margem de erros na implantação de novos
serviços. O que se está querendo dizer é que, apesar de a Prodabel ter vivido uma
recente e significativa mudança estrutural, não acreditamos que esta nova estrutura irá
permanecer por longa data, como foi o caso da estrutura baseada no mainframe. A
velocidade das mudanças tecnológicas tende a ser mais frenética nos tempos atuais.
A história tem nos mostrado isto e a Internet, que é o furor desta década de 90, estará
revolucionando cada vez mais as comunicações.
A tecnologia a serviço da comunicação entre os homens e a informação
circulando de forma eficiente e a custo reduzido… Isto nos leva a pensar que estamos
colaborando para a viabilidade de projetos em que a informação possa ser
democratizada principalmente nos meios do serviço público. Um governo preocupado
em informar o cidadão precisa fazer uso intenso da tecnologia para isto. Desta forma,
a informática deve poder atuar com seriedade e critérios, com previsibilidade e
possibilidade de evolução com agilidade.
99
11. BIBLIOGRAFIA
[1] Andrade, Henrique Cristiano M. “Aspectos de Gestão de Requisitos deDesempenho do Sistema Integrado de Supervisão”. Belo Horizonte:UFMG/DCC/ICEX, 1997. (Dissertação, Mestrado em Ciência da Computação).
[2] Andrade, H.C.M., Barros, A.C. “Utilizando o COMNET 3 para implementação deprojetos de planejamento de capacidade para sistemas distribuídos. Belo Horizonte:UFMG/DCC.012, 1996.
[3] Arlitt, Martin F., Williamson, Carey L. “A Synthetic Workload Model for InternetMosaic Traffic”. Department of Computer Science/University ofSaskatchewan/Canada,1996.
[4] Barros, Alexandre Cardoso. “Caracterização e Modelagem de Tráfego para oProjeto de uma Topologia de Rede backbone ATM para um Campus Universitário”.Belo Horizonte: UFMG/DCC/ICEX, 1997. (Dissertação, Mestrado em Ciência daComputação).
[5] Bolker, Ethan. Kersch, Don. “BEST/1 for Capacity Planning”.IBM, 1993.
[6] Braun, Hans Werner, Claffy, Kimberly C. “Web Traffic characterization : anassessment of the impact of caching documents from NCSA’s web server”. ComputerNetworks and ISDN Systems V.28. 1-3,1995-1996.
[7] BRISA. “Gerenciamento de Redes - Uma abordagem de SistemasAbertos”.Brasília: Makron Books,1993.
[8] BRISA. “Rede Municipal de Informática - Levantamento da Situação Atual e dosRequisitos de Evolução do Ambiente de TeleInformática”. Belo Horizonte:BRISA,Junho/ 1995.
[9] BRISA. ”Rede Municipal de Informática - Projeto Físico. BRISA.,Novembro/1995.
[10] BRISA. ”Rede Municipal de Informática - Projeto Funcional. Belo Horizonte:BRISA, Julho/1995.
[11] Caceres, R., Danzig, P.B.,Jamin, S.,Mitzel, D. J. “Characteristics of Wide-AreaTCP/IP Conversations”. Proceedings of ACM SIGCOMM’91,1991.
[12] CACI. “COMNET III User’s Manual : Planning for network managers”. LaJolla:CACI, 1995.
[13] CACI. “COMNET Press Releases - COMNET Predictor”. LaJolla: CACI,1997.
100
[14] C-FER. “C-FIT User Guide- Probability Distribution Fitting Software”. Alberta:C-FER, 1996.
[15] Charlab, Sérgio, Oxner, Willian. ”O seu futuro eletrônico”. Disponível na Bhnet emCharlab.zip, 1995
[16] Chou, Wushow (Ed.).”Computer Communications - Volume II Systems andApplications”. New Jersey: Prentice-Hall, Inc., 1983.
[17] Cisco Systems. “Cisco Management Information Base (MIB) - User QuickReference”. Cisco Systems, Inc., 1994.
[18] Claffy, Kimberly C., Polyzos, George C. “Application of Sampling Metodologies toNetwork Traffic Characterization”. Proceedings of ACM SIGCOMM’93, 1993.
[19] Claffy, Kimberly C. ”Internet Traffic Characterization”. University of California, SanDiego, 1994. (Tese, Doutorado em Computer Science and Engineering)
[20] Cole, Robert. “Computer Communications”. New York: Springer-Verlag, 1984.
[21] Comer, Douglas E. “Computer Networks and Internets”. Prentice Hall, 1997.
[22] Comer, Douglas E., Stevens, David L. “Internetworking with TCP/IP - Volume III”.Prentice Hall,1994.
[23] Compuware. “Econet - Network Applications Performance Management”.Compuware, 1995.
[24] Derfler Jr., Frank. “Guia de Conectividade”. Rio de Janeiro: Campus, 1993.
[25] Feit, Sidnie. “SNMP - A guide to Network Management”. McGraw-Hill, 1995.
[26] Fishman, George S. “Concepts and methods in discrete event digital”.Wiley-Interscience, 1973.
[27] Floyd, S., Jacobson, V. “The synchronization of periodic routing messages”.Proceedings of ACM SIGCOMM’93,1993.
[28] Fluckiger, François. “From Word Wide Web to Information Superhighway”.Computer Networks and ISDN Systems V.28.No. 4, 1996
[29] Giddens, Anthony. “As Consequências da Modernidade”. São Paulo: Unesp, 1991.
[30] Gil, Antônio de Loureiro. “Qualidade Total em Informática”. São Paulo: Atlas, 1992.
[31] Guengerich, Steven. “Downsizing em Sistemas de Informação”. São Paulo:Makron Books, 1993.
[32] Hackathorn, Richard D. “Conectividade de Bancos de Dados Empresariais”. Ed.Infobook, Rio de Janeiro. 1993.
101
[33] Hayes, Stephen. “Analyzing Network Performance Management”. IEEECommunications Magazine Volume 31 Number 5, Maio/1993.
[34] Heimlich, S. ”Traffic Characterization of the NSFNET NNational Backbone”.Proceedings of the 1990 Winter USENIX Conference, Dezembro/1988.
[35] Heyman, Daniel P., Lakshman, T.V. “Source Models for VBR Broadcast VideoTraffic”. Networking. Volume 4, 1996.
[36] Hsu, John Y. “Computer Networks - Architecture, Protocols, and Software”. ArtechHouse, 1996.
[37] Hunter, Bruce H., Hunter, Karen B. “Unix Systems - advanced administration andmanagement handbook”. N.Y.: Macmillan Publishing Company, 1991.
[38] Law, Averill M., Kelton, W. David. “Simulation Modeling & Analysis”. 2nd ed.MacGraw Hill, 1991.
[39] Loukides, Mike. “System Performance Tunning”. O’Reilly & Associates, 1990.
[40] Martel, Cécile. “A Study of CERN External IP Traffic - User’s Guide”.CERN, 1994.
[41] McKerrow, Phillip. “Performance Measurement of Computer Systems”.International Computer Science Series, 1988.
[42] Menascé, Daniel A., Almeida, Virgílio A. F., Dowdy, Larry W. “Capacity Planningand Performance Modeling”. Prentice Hall PTR, 1994.
[43] Menascé, Daniel, Almeida, Virgílio A. F. “Planejamento de Capacidade deSistemas de Computação - Análise Operacional como Ferramenta”. Rio de Janeiro:Campus, 1985.
[44] Morettin, Luiz Gonzaga. “Estatística Básica”. São Paulo: McGraw-Hill Ltda., 1994.
[45] Osborne, David, Gaebler, Ted. “Reinventando o Governo”. Brasília: MhComunicação, 1995.
[46] Paxson, Vern, Floyd, Sally. “Wide Area Traffic : The Failure of Poisson Modeling”.IEEE/ACM Transactions on Networking, Vol. 3 No. 3, junho/1995.
[47] Paxson, Vern. “Empirically Derived Analytic Models of Wide-Area TCPConnections”. IEEE/ACM Transactions on Networking, Vol. 2 No. 4, agosto/1994.
[48] Prodabel. “Descentralização da Informática na PBH”. Belo Horizonte: Prodabel,1994.
[49] Prodabel. “Planejamento 1997/98”. Departamento de Planejamento e Marketing.Belo Horizonte: Prodabel, 1997.
[50] Prodabel/DIOPE/DIR/GRP. “Topologia da RMI”. Belo Horizonte: Prodabel,1997.
[51] Sauer, Charles H., Chandy, K. Mani. “Computer Systems Performance Modeling”.Prentice-Hall, 1981.
102
[52] Scholl, Frederick W. “Client/Server Capacity : A Primer”. CACI,1997.
[53] Shannon. Robert E. “System Simulation ; the art and science”.Englewood Cliffs,Prentice-Hall, 1975.
[54] Shimizu, Tamio. “Simulação em computador digital”. São Paulo: Ed. daUniversidade de São Paulo, 1975.
[55] Soares, José Franciso, Farias, Alfredo Alves, César, Cibele Comini.”MétodosEstatísticos – Uma Introdução Moderna”. Belo Horizonte: Universidade Federal deMinas Gerais, 1988.
[56] Soares, Luiz Fernando G., Lemos, Guido. Colcher, Sérgio. “Redes decomputadores: das LAN’s, MAN’s e WAN’s às redes ATM”. 2nd ed. Rio de janeiro:Campus, 1995.
[57] Spiegel, Murray R. “Estatística - Resumo da teoria. 875 problemas resolvidos. 619problemas propostos”. São Paulo: McGraw-Hill, 1977.
[58] Spohn, Marcelo. “Um Paradigma Orientado a Análise de Performance de Redesde Pacotes”. UFRGS,1993. (Dissertação, Mestrado em Ciência da Computação).
[59] Stanton, Kevin. “Network Strategy Planning and Design in the Latin AmericaCommunications Environment: A Case Study”. NCR, 1996.
[60] Strack, Jair. “GPSS - Modelagem e Simulação de Sistemas”. Rio de Janeiro:Livros Técnicos e Científicos Editora S.A., 1984.
[61] Tanenbaum, Andrew S. “Redes de Computadores”.2nd ed. Rio de Janeiro:Campus, 1994.
[62] Tofler, Alvin. ”Previsões & Premissas”. Record, 1983
[63] Werkema, Maria Cristina Catarino. “Ferramentas estatísticas básicas para ogerenciamento de processos”. Belo Horizonte: Fundação Christiano Ottoni, Escola deEngenharia da UFMG, 1995.
103
12. ANEXO12.1 Composição da RMI
Roteador 1 PRODABEL
10.137.148.18
slot 1 slot 2
PBH 121210.137.148.17
Roteador 1
slot 1 slot 2
501-7100 - 128 Kbps
Roteador 1 PRODABEL
10.141.148.17
slot 1 slot 2
TUPIS10.141.148.18
Roteador 2
slot 1 slot 2
501-7103 - 128 Kbps
Roteador 2 TUPIS
10.137.141.18
slot 1 slot 2
PBH 121210.137.141.17
Roteador 2
slot 1 slot 2
501-7104 - 128 Kbps
10.13.0.1 10.54.12.2 10.13.0.231 10.13.7.2 10.54.12.1 10.13.7.1
serv : 5mic : 218rot : 2hub : 20
serv : 3mic : 181rot : 2hub :
serv : 1mic :64rot : 2hub : 12
FIGURA 12-1: Anel Central - ligações a 128 Kb
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.3.
PBH 121210.13.0.1
slot 1 slot 2
Roteador 1
AR N
E
ARNEAGMDCUP SMED CAMARA
AR P
- 1
PRODABEL10.54.12.1
slot 1 slot 2
Roteador 2
501-6683
19200
501-6710
19200
501-6735
19200
501-6736
19200
501-6708
19200
501-6668
19200
10.21.0.110.8.8.110.1.0.110.11.0.110.25.4.1
10.131.132 10.137.13217 17 18 17
10.130.13118 18
17
10.129.13018 18
10.128.12917 17
10.148.128
18
serv : 000mic : 005rot : 001hub : 001
serv : 000mic : 004rot : 001hub : 001
serv : 000mic : 002rot : 001
hub : 001
serv : 000mic : 007rot : 001
hub : 002
serv : 000mic : 011rot : 001hub : 001
FIGURA 12-2: Anel 1Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.4.
BHTRANS BEPREM AR PSMC
PRODABEL10.54.12.2
slot 1 slot 2
Roteador 1
BH
TRA
NS
TUPIS10.13.7.2
AR
P -
2
slot 1 slot 2
Roteador 2
X.25
19200312-2020
501-6685
19200
501-6706
19200
501-6733
19200
501-6712
19200
501-6678
19200
10.27.0.110.10.0.110.50.0.118
10.141.136
17 1710.135.136
17 1818 1810.134.13510.133.134
17 1710.148.133
18
10.58.3.1
serv : 005mic : 130rot : 001
hub : 012
serv : 000mic : 012rot : 001
hub : 003
serv : 000mic : 009rot : 001
hub : 001
serv : 000mic : 009rot : 001
hub : 001
FIGURA 12-3: Anel 2Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.5.
104
ARN SLU ARVNHOB
PBH 121210.13.0.1
slot 1 slot 2
Roteador 1
AR V
N
TUPIS10.13.7.1
AR N
slot 1 slot 2
Roteador 1
501-6641
19200
501-6717
19200
501-6738
19200
501-6705
19200
501-6644
19200
10.23.0.1 10.26.0.110.53.0.110.56.0.117
18 1810.137.14210.140.142
17 1710.147.140
18 18
10.138.14717 17
10.141.138
18
serv : 000mic : 010rot : 001hub : 001
serv : 000mic : 025rot : 001hub : 002
serv : 000mic : 011rot : 001hub : 001
serv : 000mic : 012rot : 001hub : 001
FIGURA 12-4: Anel 3
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.6.
ArquivoGeral
AR L
PRODABEL10.54.12.1
SMSA
PAM'sDS'sCS's
X.25
PBH 121210.13.0.231
2336
slot 1 slot 2
Roteador 2
AlmoxSMSA
AR L
slot 1 slot 2
Roteador 2
19200 19200 19200 19200 64000
19200312-1164
17
501-664710.137.146
18 18501-710710.145.146
17 17
10.17.0.310.17.40.110.8.12.1
501-710510.144.145
18 18501-670210.143.144
17 17
10.20.0.118
10.148.143501-6686
10.17.0.1SMSA
X25
10.17.0.0
serv : 000mic : 012rot : 001
hub : 001
serv : 000mic : 005rot : 001hub : 001
serv : 000mic : 008rot : 001hub : 001
serv : 006mic : 026rot : 001hub : 006
FIGURA 12-5: Anel 4
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.7.
105
PBH 4000 SUDECAP
PRODABEL10.54.12.1
PBH 121210.13.0.231
4000
URBELARO
S LOBO
AR O
- 1
Roteador 2
slot 1 slot 2
Roteador 2
slot 1 slot 2
501-6680
64000
501-6704
19200
501-6723
19200
501-6709
19200
501-6684
19200
10.24.4.110.51.0.110.55.0.110.15.0.1 18
10.148.15017 1718 1817 17
10.149.15010.147.14918 18
10.139.14710.137.139
17
serv : 002mic : 100rot : 001hub : 009
serv : 000mic : 005rot : 001hub : 001
serv : 000mic : 005rot : 001hub : 001
serv : 000mic : 005rot : 001hub : 001
FIGURA 12-6: Anel 5
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.8.
Barbacena
PBH 121210.13.0.231
ALV.
CAB
RAL
slot 1 slot 2
Roteador 2
Previcaixa ARCS
slot 1 slot 2
Roteador 2
1500
TUPIS10.13.7.2
COMDEC Zoo
501-6642
64000
501-6711
19200
501-6743
19200
501-7110
19200
501-7109
19200
501-7111
19200
10.19.0.110.80.0.110.8.4.110.8.3.1 10.11.8.1 18
10.141.15517 1718 1817 17
10.154.15510.153.15410.152.15318 1818 17
10.151.15210.137.151
17
serv : 000mic : 023rot : 001
hub : 002
serv : 000mic : 001rot : 001hub : 001
serv : 000mic : 003rot : 001
hub : 001
serv : 000mic : 017rot : 001
hub : 001
serv : 000mic : 037rot : 001
hub : 005
FIGURA 12-7: Anel 6
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.9.
Gab-ViceSEBRAEARO
Catete
AR O
- 2
TUPIS
slot 1 slot 2
Roteador 2
ARNO
AR N
O
slot 1 slot 2
Roteador 1 PRODABEL
10.54.12.2
501-6677
19200
501-6716
19200
501-7108
19200
501-7126
19200501-6682
19200
10.22.0.110.2.4.110.28.4.110.24.0.118
17 1718 1810.148.15910.158.159
17 1717 18
18
10.157.15810.156.15710.141.156
10.13.7.2
serv : 000mic : 018rot : 001
hub : 001
serv : 000mic : 002rot : 001hub : 001
serv : 000mic : 002rot : 001
hub : 001
serv : 000mic : 003rot : 001
hub : 001
FIGURA 12-8: Anel 7
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.10.
106
PBH 121210.13.0.1
slot 1 slot 2
Roteador 1
AR B
CGM
slot 1 slot 2
Roteador 1 TUPIS
10.13.7.1
ARBManga-beiras
CGMNúcleo de
Apoio501-7814
19200
501-6726
19200
501-6732
19200
501-6713
19200
501-6679
19200
10.18.0.110.15.16.110.8.20.1
17
17 1818 1817 1710.137.16410.163.16410.162.163
17 1810.161.162
10.141.161
18
10.28.0.1
serv : 000mic : 011rot : 001
hub : 001
serv : 000mic : 004rot : 001hub : 001
serv : 000mic : 002rot : 001
hub : 001
serv : 000mic : 002rot : 001hub : 001
FIGURA 12-9: Anel 8
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.11.
DS B
arre
iro
TUPIS10.13.7.2
DISAB DISANO DISAL DISAN DISAP
PRODABEL10.54.12.2
slot 1 slot 2
Roteador 1
DS P
ampu
lha
Roteador 2
slot 1 slot 2
501-7118
19200501-7388
19200
501-7117
19200 19200
501-7124 501-7577
19200501-7131
19200
10.17.212.110.17.224.110.17.32.110.17.204.110.17.36.1
18
18 1717 1718 1810.148.17410.173.17410.172.17310.171.172
17 1717 1810.170.17110.141.170
18serv : 000mic : 001rot : 001hub : 001
serv : 000mic : 001rot : 001hub : 001
serv : 000mic : 001rot : 001hub : 001
serv : 000mic : 003rot : 001hub : 001
serv : 000mic : 001rot : 001hub : 001
FIGURA 12-10: Anel 9
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.12.
slot 1 slot 2
Roteador 1 TUPIS
10.13.7.1
AlmoxSMMA
PROCON GráficaDepto
Transpt.Garagem
PRODABEL10.54.12.2
slot 1 slot 2
Roteador 1
SMAB
X28
311-6154
X28
311-6168
X28
311-6172
X25-19200
312-2126
X25-19200
312-108810.8.16.110.29.0.1
SLUBR040
X25
serv : 000mic : 001rot : 000hub : 000
serv : 000mic : 000rot : 000hub : 000
serv : 000mic : 001rot : 001hub : 001
serv : 000mic : 002rot : 001hub : 001
serv : 000mic : 001rot : 000hub : 000
serv : 000mic : 001rot : 000hub : 000
FIGURA 12-11: Anel 10
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.13.
O anel 10 (FIG. ) será implementado temporariamente em X.25 e X.28 com posterioralteração para PPP, utilizando a topologia definida na FIG X.
107
PBH 121210.13.0.1
slot 1 slot 2
Roteador 1
ARB
PBH 121210.13.0.231
slot 1 slot 2
Roteador 2
PBBH
400
0PRODABEL10.54.12.2
slot 1 slot 2
Roteador 1 PRODABEL
10.54.12.1
slot 1 slot 2
Roteador 2
ARO
S Lo
bo
Tupis10.13.7.1
slot 1 slot 2
Roteador 1 Tupis
10.13.7.2
slot 1 slot 2
Roteador 2
ARNE
ARVN
DS B
arre
iro
Álv.
Cabr
alPB
H 23
36
ARNO
BHTR
ANS
ARL
DCUP
ARP
PBH
1500
ARO
Cate
te
ARN
CGM
DS P
ampu
lha
PROD
ABEL
PROD
ABEL
PBH
1212
PBH
1212
Tupis
149
Tupis
149
FIGURA 12-12: Ligações das portas seriais nos roteadores
Fonte: Prodabel/DIOPE/DIR/GRP, 1997. p.14.
TABELA 12-1: Circuitos PPP da RMI
Linha Anel Ponto 1 Ponto 2 Vel. No. Link1 0 PBH1212 PDBL 128 501-71002 0 PBH1212 Tupis 149 128 510-71043 0 PDBL Tupis 149 128 501-71034 1 PDBL DCUP 19,2 501-66835 1 DCUP SMED 19,2 510-67106 1 SMED CM 19,2 501-67357 1 CM AGM 19,2 501-67368 1 AGM AR NE 19,2 501-67089 1 PBH1212 AR NE 19,2 501-666810 2 PDBL BHTRANS 19,2 501-668511 2 BHTRANS BEPREM 19,2 501-670612 2 BEPREM SMC 19,2 501-673313 2 SMC AR P - 2 19,2 501-671214 2 AR P - 2 Tupis 149 19,2 501-667815 3 Tupis 149 AR N 19,2 501-664116 3 AR N SLU 19,2 501-671717 3 SLU HOB 19,2 501-673818 3 HOB AR VN 19,2 501-670519 3 PBH1212 AR VN 19,2 501-664420 4 PDBL AR L 19,2 501-668621 4 AR L Arquivo Geral 19,2 501-670222 4 Arquivo Geral Almox. SMSA 19,2 501-710523 4 Almox. SMSA SMSA 19,2 501-710724 4 PBH1212 SMSA 64 501-664725 5 PBH1212 PBH4000 64 501-668026 5 PBH4000 SUDECAP 19,2 501-670427 5 SUDECAP URBEL 19,2 501-672328 5 URBEL AR O - S.Lobo 19,2 501-670929 5 PDBL AR O - S.Lobo 19,2 501-668430 6 PBH1212 Previcaixa 64 501-664231 6 Previcaixa Barbacena 19,2 501-671132 6 Barbacena Defesa Civil 19,2 501-674333 6 Defesa Civil Zoo 19,2 501-711034 6 Zoo ARCS 19,2 501-710935 6 Tupis 149 ARCS 19,2 510-711136 7 Tupis 149 AR O Catete 19,2 501-6677
108
37 7 SEBRAE AR O Catete 19,2 501-671638 7 SEBRAE DARGO 19,2 501-710839 7 DARGO AR NO 19,2 501-712640 7 PDBL AR NO 19,2 501-668241 8 Tupis 149 CGM 19,2 501-781442 8 CGM Núcleo Apoio 19,2 501-672643 8 Núcleo Apoio Mangabeiras 19,2 501-673244 8 Mangabeiras AR B 19,2 501-671345 8 PBH1212 AR B 19,2 501-667946 9 Tupis DS Barreiro 19,2 501-711847 9 DS Barreiro DS Noroeste 19,2 501-738848 9 DS Noroeste DS Leste 19,2 501-711749 9 DS Leste DS Norte 19,2 501-712450 9 DS Norte DS Pampulha 19,2 501-757751 9 DS Pampulha PDBL 19,2 501-7131
TABELA 12-2: Órgãos da PBH e entidades vinculadas
GP Gabinete do PrefeitoSUDECAP Superintendência de Desenvolvimento da CapitalURBEL Companhia Urbanizadora de Belo HorizontePRODABEL Empresa de Informática e Informação do Município
de Belo Horizonte S/ABHTRANS Empresa de Transporte e Trânsito de Belo HorizonteBELOTUR Empresa Municipal de Turismo de Belo HorizonteCGM Corregedoria Geral do MunicípioAGM Auditoria Geral do MunicípioASSCS Assessoria de Comunicação SocialPGM Procuradoria Geral do MunicípioSMDS Secretaria Municipal de Desenvolvimento SocialSMAD Secretaria Municipal de AdministraçãoSMAU Secretaria Municipal de Atividades UrbanasSMC Secretaria Municipal de CulturaSMED Secretaria Municipal de EducaçãoSMES Secretaria Municipal de EsportesSMFA Secretaria Municipal de FazendaSMGO Secretaria Municipal de GovernoSMMA Secretaria Municipal de Meio AmbienteSMPL Secretaria Municipal de PlanejamentoSMSA Secretaria Municipal de SaúdeARB Administração Regional BarreiroARCS Administração Regional Centro SulARL Administração Regional LesteARNE Administração Regional NordesteARNO Administração Regional NoroesteARN Administração Regional NorteARO Administração Regional OesteARP Administração Regional PampulhaARVN Administração Regional Venda NovaBEPREM Beneficência da Prefeitura de Belo HorizonteSLU Superintendência de Limpeza UrbanaBHZOO Fundação ZooBotânica de Belo Horizonte
109
HOB Hospital Municipal Odilon Behrens
TABELA 12-3: Indisponibilidade dos circuitos da RMI no mês de maio
Circuito início paralisação fim paralisação tempoparalisado
501-7126 06/05/97 16:09 07/05/97 10:30 18: 21501-7109 28/05/97 8:10 28/05/97 9:15 1: 05501-7107 08/05/97 9:17 08/05/97 11:15 1: 05501-7103 05/05/97 22:00 06/05/97 12:40 14: 40501-7103 06/05/97 14:35 06/05/97 14:50 0: 15501-7100 05/05/97 22:00 06/05/97 12:40 14: 40501-7100 06/05/97 14:35 06/05/97 14:50 0: 15501-6743 22/05/97 9:45 22/05/97 15:20 5: 35501-6732 06/05/97 13:50 07/05/97 11:00 21: 10501-6732 19/05/97 9:34 19/05/97 12:00 2: 26501-6732 20/05/97 9:28 21/05/97 11:23 25: 55501-6732 21/05/97 16:56 22/05/97 10:11 17: 15501-6732 23/05/97 10:13 26/05/97 17:00 78: 47501-6717 26/05/97 13:36 27/05/97 15:41 26: 05501-6713 19/05/97 9:34 19/05/97 17:00 7: 26501-6713 20/05/97 9:28 20/05/97 19:15 9: 47501-6713 21/05/97 14:53 22/05/97 11:30 20: 37501-6713 23/05/97 9:17 23/05/97 16:00 6: 43501-6713 27/05/97 8:59 27/05/97 15:25 6: 26501-6712 13/05/97 16:38 14/05/97 14:51 22: 13501-6710 06/05/97 12:31 07/05/97 15:31 27: 00501-6710 21/05/97 14:21 21/05/97 17:35 3: 14501-6709 14/05/97 13:54 15/05/97 11:00 21: 06501-6706 02/05/97 11:05 02/05/97 12:30 1: 25501-6706 05/05/97 13:07 06/05/97 12:30 23: 23501-6706 07/05/97 8:24 07/05/97 9:45 1: 21501-6706 14/05/97 11:42 14/05/97 17:00 5: 18501-6706 21/05/97 11:35 21/05/97 17:11 5: 36501-6684 30/05/97 11:19 30/05/97 15:00 23: 10501-6682 05/05/97 9:05 05/05/97 16:00 6: 55501-6682 06/05/97 13:17 06/05/97 13:50 0: 33501-6682 16/05/97 11:56 16/05/97 14:00 2: 04501-6682 30/05/97 11:19 30/05/97 13:30 2: 11501-6668 02/05/97 15:24 02/05/97 16:30 1: 06501-6641 14/05/97 16:12 15/05/97 14:00 21: 48501-5496 23/05/97 9:48 23/05/97 16:00 6: 12
110
12.2 Levantamento dos servidores/aplicativos acessados pela WAN
Será descrito a relação dos sistemas por servidor e por local.Local: PBH - Av. Afonso Pena, 1212
TABELA 12-4: Servidores da PBH1212 acessados pela WAN
Servidores AplicativosCampinas PB36
PB85SF01SF03SF06
Santos PB36SF11SF34SF35SP03SP06SP07
São_Paulo SA07MT01
Itu PB36SA28SP02
Agudo Sistema de materiaisLapa Lotus Notes (Correio e
workflow)
Local: DRM - Rua Tupis, 149
TABELA 12-5: Servidor da Tupis acessado pela WAN
Servidor AplicativoItália PB36
SF12
Local: SMAU - Av. Afonso Pena, 4000
TABELA 12-6: Servidor da PBH4000 acessado pela WAN
Servidor AplicativoPetrópolis PB36
PB39SA02SA03SF09SO09SO13
111
Local: Prodabel - Av. Presidente Carlos Luz, 1275
TABELA 12-7: Servidores da Prodabel acessados pela WAN
Servidor AplicativoDanville Lotus Notes (Correio e
workflow)Denver Ambiente de desenvolvimento
Natural/AdabasAiken ISM (Gerenciamento SNMP)
TABELA 12-8: Descrição dos Aplicativos
MT01 Sistemas de Materiais da PBH
PB36 Rotina de Gerência de Acesso a Sistemas
PB39 Rotina de Cadastro Único de Endereços
PB85 Rotina de Controle de Emissão e Postagem - CEP
SA02 Sistema Integrado de Permissão Municipal
SA03 Sistema de Fiscalização Municipal
SA07 Folha de Pagamento da PBH
SA28 Sistema de Controle de Patrimônio Imobiliário do Município
SF01 Imposto Predial e Territorial Urbano - IPTU
SF03 Sistema Integrado para Gerência de Arrecadação - SIGA
SF06 Imposto sobre a Transmissão de Bens Intervivos - ITBI
SF09 Sistema Integrado de Informações Urbanas - SIUR
SF11 Sistema Orçamentário Financeiro e Contábil
SF12 Sistema Integrado de Mobiliário Contribuinte Novo - ISS
SF34 Controle Certidão e Execução Fiscal
SF35 Sistema de Dívida Ativa - SIDA
SO09 Sistema Integrado da Lei de Uso e Ocupação do Solo e Certidões
SO13 Nova Lei de Uso e Ocupação do Solo
SP02 Sistema Integrado de Gerência de Documentos (OPUS)
SP03 Sistema Integrado de Gerenciamento Orçamentário
SP06 Sistema de Acompanhamento de Projetos
SP07 Cont. Instrumentos Jurídicos de Natureza Contratual
112
TABELA 12-9: Porcentagem de destino das mensagens, por anel, para cadaservidor WAN da RMI
Ser-vidor/Anel
Agu-do(%)
Aiken
(%)
Cam-pinas(%)
Dan-ville(%)
Den-ver(%)
Itália
(%)
Itu
(%)
La-pa(%)
Petró-polis(%)
San-tos(%)
Sao_paulo(%)
Anel1 - 17,6 7,2 - 0,1 25,3 21,8 - 9,8 18,2 -Anel2 - 33,1 - - 0,1 - 41,3 - - 25,5 -Anel3 - 9,5 5,8 - - 9,7 18 - 4,8 52,1 0,1Anel4 42,7 4,3 1,2 0,1 - 0,8 23,1 - 0,9 24,7 2,2Anel5 - 5,4 6,8 - 17,6 3,57 39,5 - - 27,1 -Anel6 17,1 5,2 - - - 0,1 26,9 0,2 0,1 50,3 0,1Anel7 15,8 - 35,7 - 0,1 0,3 12,7 - 8,7 26,7 -Anel8 - 3,6 6,2 - - 15 29,3 - - 45,9 -Anel9 - 36,2 - - 0,2 - 28 - - 35,6 -Anel10 - 100 - - - - - - - - -RedeProda-bel
0,2 - 50,7 - - 4,1 1,3 0,4 0,1 1,2 42
Rede1212
- 7 - 0,2 16,1 76,6 - - 0,1 - -
RedeTupis
- 5,7 3,1 - 4,1 - 11,2 - 0,1 66,7 9,1
A Tabela 11-9 mostra somente o tráfego da WAN. A tabela pode ser
interpretada da seguinte maneira: 17,6% dos pacotes que trafegam na WAN e que
tiveram origem no Anel1 se destinam à servidora Aiken; 7,2% dos pacotes que
trafegam na WAN e que tiveram origem no Anel1 se destinam à servidora Campinas e
assim sucessivamente na interpretação da tabela.
113
12.3 Análise do volume de Dados do backbone central
12.3.1 Roteadores da PBH1212
GRÁFICO 12-1: Entrada/saída de octetos do roteador 10.13.0.1
GRÁFICO 12-2: Entrada/saída de octetos do roteador 10.13.0.231
0
20,000,000
40,000,000
60,000,000
80,000,000
100,000,000
120,000,000
Prodabel Anel1 Anel 3 Anel8
Total inputTotal output
0
10,000,000
20,000,000
30,000,000
40,000,000
50,000,000
60,000,000
70,000,000
Tupis Anel6 Anel4 Anel5
Total inputTotal output
114
12.3.2 Roteadores da Tupis
GRÁFICO 12-3: Entrada/saída de octetos do roteador 10.13.7.1
GRÁFICO 12-4: Entrada/saída de octetos no roteador 10.13.7.2
Bytes input/output 10.13.7.1 em 06/03
0
10,000,000
20,000,000
30,000,000
40,000,000
50,000,000
60,000,000
Pdbl Anel3
Total inputTotal output
0
1 0 , 0 0 0 , 0 0 0
2 0 , 0 0 0 , 0 0 0
3 0 , 0 0 0 , 0 0 0
4 0 , 0 0 0 , 0 0 0
5 0 , 0 0 0 , 0 0 0
6 0 , 0 0 0 , 0 0 0
7 0 , 0 0 0 , 0 0 0
1 2 1 2 A n e l9 A n e l7 A n e l2 A n e l6
T o t a l i n p u t
T o t a l o u t p u t
115
12.3.3 Roteadores da Prodabel
GRÁFICO 12-5: Entrada/saída de octetos do roteador 10.54.12.1
GRÁFICO 12-6: Entrada/saída de octetos do roteador 10.54.12.2
05,000,000
10,000,00015,000,00020,000,00025,000,00030,000,00035,000,00040,000,00045,000,00050,000,000
tupis anel4 anel1 anel5
Total input
Total output
0
10,000,000
20,000,000
30,000,000
40,000,000
50,000,000
60,000,000
70,000,000
1212 Anel7 Anel9 Anel2
Total input
Total output
116
12.4 Horário de pico
12.4.1 Roteadores da PBH1212
GRÁFICO 12-7: Entrada de octetos no roteador 10.13.0.1 em intervalos de 30min.
GRÁFICO 12-8: Entrada de octetos no roteador 10.13.0.231 em intervalos de30min.
01,000,0002,000,0003,000,0004,000,0005,000,0006,000,0007,000,0008,000,000
8:00 10:00 12:00 14:00 16:00
Prodabel
Anel1
Anel3
Anel8
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
3,000,000
8:00 9:30 11:00 12:30 14:00 15:30 17:00
Tupis
Anel6
Anel4
Anel5
117
12.4.2 Roteadores da Tupis
GRÁFICO 12-9: Entrada de octetos no roteador 10.13.7.2 em intervalos de 30min.
GRÁFICO 12-10: Entrada de octetos no roteador 10.13.7.1 em intervalos de 30min.
0
50
100
150
200
250
300
350
400
450
500
8:00 9:30 11:00 12:30 14:00 15:30 17:00
1212
Anel9
Anel7
Anel2
Anel6
0
100
200
300
400
500
600
8:00 10:00 12:00 14:00 16:00
PdblAnel3
118
12.4.3 Roteadores da Prodabel
GRÁFICO 12-11: Entrada de octetos no roteador 10.54.12.1 em intervalos de30min.
GRÁFICO 12-12: Entrada de octetos no roteador 10.54.12.2 em intervalos de30min.
0
50
100
150
200
250
300
350
8:30 10:30 12:30 14:30 16:30
tupis
Anel4
Anel1
Anel5
0
2,000,000
4,000,000
6,000,000
8,000,000
10,000,000
12,000,000
8:00 10:00 12:00 14:00 16:00
1212
Anel7
Anel9
Anel2
119
12.5 Análise da Composição do Tráfego
telnet65%
adabas-networking31%
printer4%
snmp0%
telnet
adabas-networking
printer
snmp
GRÁFICO 12-13: Tráfego WAN para servidor da PBH4000, por protocolo (empacotes)
telnet1%
adabas-networking99%
printer0%
snmp0%
telnet
adabas-networking
printer
snmp
GRÁFICO 12-14: Tráfego da WAN para servidor da PBH4000, por protocolo (emoctetos)
120
telnet75%
snmp16%
notes5%
other3%
X01%
printer0%
ftp0%
ftp-data0%adabas-networking
0%
telnet
snmp
notes
other
X0
adabas-networking
ftp-data
printer
ftp
GRÁFICO 12-15: Tráfego da WAN para servidores da Prodabel, por protocolo empacotes)
telnet6%
snmp56%
notes8%
other13%
X015%
adabas-networking2%
ftp-data0%
ftp0%
printer0%
telnet
snmp
notes
other
X0
adabas-networking
ftp-data
printer
ftp
GRÁFICO 12-16: Tráfego da WAN para servidores da Prodabel, por protocolo(em octetos)
121
adabas-networking67%
telnet31%
printer1%
other1%
snmp0%
other0%
adabas-networking
telnet
printer
other
snmp
other
GRÁFICO 12-17: Tráfego da WAN para servidor da Tupis, por protocolo (empacotes)
adabas-networking
telnet
printer
other
snmp
other
adabas-networking
telnet
printer
other
snmp
other
GRÁFICO 12-18: Tráfego da WAN para servidor da Tupis, por protocolo (emoctetos)
122
12.6 Ambiente de simulação
O modelo foi construído no COMNET III sendo executado em uma
máquina SUN UltraSparc Model 140 com RAM de 512MB e sistema
operacional SunOS 5.5.1.
Os modelos de simulação foram executados em background com tempo
de execução variando entre 5h para modelos mais simples como o
representado pela figura 6-1 e 12h para o modelo representado pela figura 8-1.
Esses tempos de execução foram os melhores, obtidos após terem sido feitos
diversos ajustes nas opções do simulador, tais como, desabilitação da
visualização do fluxo de pacotes, desabilitação de display de tempo, redução
do número de relatórios resultantes da simulação, desabilitação de gráficos
estatísticos on-line, entre outras opções.
Durante diversas execuções do modelo no simulador, acompanhou-se o
andamento do processo dentro da máquina. Isso foi feito executando-se o
comando “ps -aux” do Unix, que é um comando para listar os processos em
execução na máquina. Constatou-se que o processo referente ao simulador
consome normalmente 90% da CPU e 12% de memória. Usando o comando
“vmstat” do Unix, que fornece uma estatística da memória virtual, foi verificado
que a máquina não estava executando paginação de memória. Normalmente,
esta máquina não estava sendo muito utilizada, com apenas 3 a 4 usuários
simultâneos, daí os 90% de utilização para esse processo.
Os modelos têm tamanho entre 140KB e 170KB e um relatório já no
formato TXT possui normalmente 10KB. Durante a execução do modelo é
gerado um arquivo de trace que chega a ter entre 35 e 42MB.