Análise de Desempenho de Modelos para a Distribuição de Tráfego Internet a um Cluster de Servidores WEB.

Transcrição

1 Análise de Desempenho de Modelos para a Distribuição de Tráfego Internet a um Cluster de Servidores WEB. Mauro W. Cavalcante 1, Dr. João Bosco da M. Alves 2, Dr. Paulo José Freitas Filho 2 1 Secretaria de Informática Tribunal Regional do Trabalho 8ª Região (TRT8) Trav. Dom Pedro I 746, , Belém, Pará 2 CPGCC - Centro Tecnológico -Universidade Federal de Santa Catarina (UFSC) , Florianópolis, Santa Catarina m.cavalcante@ieee.org, {jbosco, freitas}@inf.ufsc.br Abstract. In this paper we review some of the main load scheduling polices applied to web serves. We also propose a scheduling police Load-Sharing- Dispatcher, namely Burst Control, for Web switches operating at layer four of the OSI protocol stack. Its goal is to improve and rationalize load sharing in Web Clusters that provide static information. The proposed algorithm has the additional benefit of guaranteeing a maximum Web server load for each server. A performance analysis comparing the proposed model and the Round- Robin popular model is also presented. Resumo. Este trabalho revisa alguns dos principais modelos de Distribuição de Carga em servidores Web. Complementarmente, propõe-se um modelo de distribuição denominado rajada controlada (Burst Control-BC), que trabalha na camada de nível quatro do modelo OSI. Este, implementa a racionalização da distribuição das requisições dos clientes a uma família de servidores internet heterogênea. A principal característica do modelo é estabelecer uma carga máxima de processamento a cada um dos servidores WEB. Uma análise de desempenho e uma comparação entre o modelo proposto e o modelo Round-Robin também é apresentada. 1. Introdução O aumento explosivo do tráfego na World Wide Web (WWW) traz como conseqüência o rápido crescimento da taxa de requisições sobre os sites, que podem sofrer grandes congestionamentos pela impossibilidade de estabelecer um controle deste comportamento de tráfego. Ter um Web site rápido para algumas companhias é uma necessidade básica, assim como deve suportar quaisquer picos de acessos que surjam na rede. As flutuações na entrada de requisições aos sites mantêm, constantemente, seus administradores em busca de soluções e alternativas que permitam aos servidores internet (web servers) maior capacidade no processamento de requisições com objetivo de atender a demanda requisitada pelos usuários. Uma solução é aumentar a capacidade dos recursos computacionais. Contudo, às vezes, esta solução ainda não é suficiente, pois o número máximo de requisições que um único servidor pode suportar é limitado e pode não ser grande o suficiente para atender a crescente demanda de requisições.

2 Para permitir a escalabilidade do tráfego requisitado, uma alternativa é distribuir em mais de um servidor a capacidade de responder as requisições internet. A implementação da distribuição das requisições dos usuários para uma família de servidores necessita de uma arquitetura específica no site e de uma técnica de distribuição de requisições para os servidores, de tal forma que o cliente seja atendido pelo mesmo servidor durante todo o processamento das mensagens de uma determinada conexão http. É fundamental a distribuição otimizada das requisições na internet onde os produtos para balanceamento de cargas são, no momento, a melhor solução existente no mercado. Todos eles agem como servidores DNS, mas acrescentam inteligência selecionando sites com base em parâmetros como: proximidade, tempo de resposta/latência, perda de pacotes (avaliam o desempenho de link), carga do servidor local e condições do servidor local (analisam o desempenho e o estado de atividade dos servidores individuais). O balanceamento pode ser realizado localmente, que visa a distribuição da carga entre os servidores locais; ou global, onde o balanceamento é realizado de acordo com a posição geográfica dos sites espalhados nos diversos continentes, neste caso, permite uma segurança adicional para problemas como: ataques de hackers, incêndios, enchentes, falhas de equipamentos de comunicação e servidores de serviços, etc. Para as empresas de comércio eletrônico ou fornecedoras de informações em tempo real, lidar com problemas desse tipo não só faz parte do dia-a-dia como dos seus planos de contingência. Para suportar esta demanda de tráfego existem no mercado diversas soluções de equipamentos (hardware) e também de software, que permitem aos sites o controle eficaz de demanda de tráfego. Os métodos empregados na busca de soluções à distribuição inteligente de tráfego (carga), implementados nos roteadores ou switches de balanceamento de carga, acarretam uma latência devido ao processamento das informações obtidas nas mensagens provenientes dos servidores WEB, como por exemplo: CPU, sessões ativas, filas. A principal motivação deste trabalho, é a pesquisa e o teste de alguns algoritmos que proporcionem a tomada de decisão adequada, sem a necessidade de uma grande latência nos equipamentos, por conta da busca de informações da rede, do cliente e dos servidores. A principal característica do modelo proposto neste trabalho é estabelecer um limite máximo de carga de processamento a cada um dos servidores WEB, permitindo, desta forma, a estabilidade do site para qualquer flutuação de tráfego internet requisitado ao mesmo. 2. Métodos de Distribuição na Arquitetura Dispatcher Denomina-se de Dispatcher a política que permita a seleção de requisições dos clientes com base em um distribuidor à uma família de servidores, possibilitando um processo de crescimento gradual no desempenho dos sites internet e total transparência aos clientes dos servidores. O Dispatcher, também denominado de Web switch ou switch, é o responsável por receber todo o tráfego oriundo dos clientes e distribuí-los aos servidores internet.

3 A concentração das requisições em um único ponto (URL) para posterior encaminhamento a um dos servidores internet (Web Cluster) do site, requer que seja definido um método, que será adotado pelo dispatcher para realizar a distribuição das requisições aos servidores. Esta política é implementada de diversas maneiras e finalidades, tendo em vista os protocolos e tipos de dados manipulados. A arquitetura de balanceamento pode ser dividida em duas etapas distintas: a entidade (Cliente, DNS, Dispatcher, Servidor) que executa a tarefa de balanceamento e, o algoritmo, que toma a decisão de distribuição das requisições HTTP entre os servidores. Neste trabalho evidencia-se a arquitetura dispatcher. O distribuidor (web switch) é o elemento chave de qualquer Web Cluster.. Nos últimos anos, diversos trabalhos acadêmicos e produtos de mercado baseiam-se nesta arquitetura. Dentre tantos, cita-se : IBM Network Dispatcher [Hunt,1998]; LARD[Pai et Al,1998]; e HACC[Zhang et Al,1999]. As empresas, tais como, Alteon Web Systems [ Cisco [ F5 Labs [ apresentam no mercado comercial uma linha de produtos de balanceamento que são classificados de acordo com a camada do protocolo OSI: nível 4 ou camada 4 ; nível 7 ou camada 7. Os web switchs nível 4 (WSn4) realizam o procedimento de distribuição no momento da conexão do protocolo TCP/IP, camada 4 modelo OSI. Os pacotes pertencentes à mesma conexão TCP devem ser enviados ao mesmo servidor, através de uma tabela de associação entre cliente e servidor. O WSn4 examina o cabeçalho de cada requisição e, com base no campo flag, determina quando o pacote pertence a uma nova conexão ou a uma já existente. Os WSn4 são compostos de algoritmos que processaram a distribuição sem nenhum conhecimento sobre o tipo de requisição que será posteriormente solicitada pelo cliente, portanto, é realizada uma distribuição cega (content information blind). Este método permite maior rapidez no processo, mas em contra partida, a possibilidade de um equilíbrio de carga de transação entre os servidores não é possível de ser realizado. Também é um ponto negativo a impossibilidade de dispor de servidores com conteúdos e finalidades diferentes. Os web switch nível 7 (WSn7) podem estabelecer uma conexão completa TCP com o cliente, e somente ao receber uma requisição HTTP, será examinado o cabeçalho e, com as informações analisadas, será realizado o processo de distribuição aos servidores. Esta forma de distribuição tem um retardo obrigatório (delayed binding) no WSn7 antes de chegar ao servidor e a sua distribuição, normalmente, é função do serviço solicitado, isto é, conteúdo das URL da requisição HTTP, identificadores de segurança (SSL) e informações de navegação (cookies), permitindo um melhor equilíbrio de carga, assim como o uso de servidores específicos ao serviço Web. Numa comparação superficial entre o SWn7 e o SWn4, pode-se dizer que o primeiro oferece vantagens quando se considera a distribuição a servidores heterogêneos e a alta taxa de utilização de cache. Em contrapartida, suas desvantagens são o alto processamento realizado no switch, que pode vir a ser o gargalo do sistema, e a complexidade de configuração do ambiente de distribuição. Os switchs podem ser classificados quanto à forma de distribuição em : Algoritmos estáticos ou dinâmicos; e Centralizados ou distribuídos. Os algoritmos estáticos (como: randômico, round-robin) são implementados com o procedimento de distribuição imutável, não permitindo a alteração de comportamento no modo de

4 distribuição. Os algoritmos dinâmicos atuam conforme a análise das informações baseadas no algoritmo de distribuição, que podem ser do cliente (IP, porta TCP), do servidor (número conexões ativas, servidor de menor carga) ou de uma combinação cliente/servidor. Os web switch precisam ter como principal diretriz o uso de algoritmos simples, ágeis e de pouco processamento, devido à necessidade de tomar centenas de decisões por segundo. Sobre este ponto de vista, os algoritmos estáticos têm grande vantagem em relação aos algoritmos dinâmicos, da mesma forma os SWn4 sobre os SWn7. Os switchs centralizados executam a distribuição a uma LAN e os distribuídos a uma WAN. Este trabalho evidencia exclusivamente a estrutura centralizada através de algoritmos estáticos. Na arquitetura com base em uma família de servidores (clusterbased web server), pode-se utilizar a política de distribuição com base no algoritmo round-robin [Dias et Al,1996], devido sua simplicidade de implementação. Este método possui as seguintes variações : Simples rodízio - round-robin (RR); Servidor de menor carga - least load server round-robin (LL); e Servidor de menor número de conexões least conection round-robin (LC). O algoritmo estático RR, executa a distribuição por diferentes servidores através de uma lista circular, obedecendo à seqüencialidade de cada item da lista. No algoritmo dinâmico LL, o distribuidor define a próxima requisição para o servidor que possuir a menor carga (a carga de um servidor é definida como a soma dos tempos de todas as requisições pendentes no servidor). Para realizar esta distribuição é necessário que o algoritmo receba a informação de carga de cada servidor, o que requer uma aplicação de monitoramento e informação em execução nos servidores. Devido ao tráfego entre servidores e o distribuidor, esta arquitetura gera, também, um acréscimo ao tráfego da rede interna. O algoritmo dinâmico LC, encaminha a próxima requisição ao servidor que tiver o menor número de conexões HTTP ativas, necessitando, desta forma, manter uma tabela de número de conexões estabelecidas, por servidor, na memória do dispatcher. 3. Modelo Proposto Propõe-se o algoritmo Rajada Controlada (Burst Control-BC), que atua ao nível da camada 4 da OSI, durante o processo de conexão, realizando um processo de distribuição seqüencial, sendo que cada servidor internet recebe n requisições seguidas (rajada) desde que, neste determinado instante, as distribuições realizadas ao servidor internet não ultrapassem o limite máximo de requisições que o servidor pode receber a cada segundo (controle de distribuição). O principal objetivo do modelo é limitar a carga máxima distribuída aos servidores internet, permitindo que os mesmos operem dentro de limites operacionais estáveis e com a possibilidade de dispor de um tempo de resposta máximo garantido ao usuário. Considerando-se que a demanda de tráfego apresenta um comportamento sazonal, com oscilações significativas durante o período de atividade dos sites, o estabelecimento de um processo de inteligência no método, permitirá a variação de parâmetros ao algoritmo, procedimentos ou até algoritmos diferenciados conforme a demanda solicitada, dependendo do nível de abrangência desejado. O método estabelece a existência de uma camada de gerência ao distribuidor que lhe permita alterar

5 parâmetros que influenciam no procedimento do algoritmo, tais como os servidores ativos, valor de n da rajada, valor de desempenho dos servidores. A principal característica do modelo de gerência é possibilitar a alteração dinâmica do comportamento de distribuição, atuando através de gatilho, estabelecido pela fila do número de requisições entrantes no distribuidor, com dois níveis de gatilhos, um máximo e outro mínimo, conforme a carga, sendo que os gatilhos não são de valores fixos, os valores são gerenciados pelo próprio gerente, estabelecendo o próximo momento que atuará sobre o sistema de distribuição. O gerente também poderá ser chamado através de uma seqüência de conexão específica, ou através de uma porta de configuração, porta esta que permitira atuar no módulo de gerência mesmo nos momentos de alta demanda de carga entrante. A base de informações é tratada a dois níveis de algoritmos: o básico, responsável pela distribuição (AD) e o gerencial (AG) responsável pela coleta e gerência da distribuição Algoritmo de Gerência do BC É responsável pela análise das mensagens enviadas pelos clientes para coletar as informações necessárias na escolha do servidor. As informações básicas possibilitam uma avaliação estimada de carga, tais como: serviço de porta TCP; tamanho da janela; rede de origem; número de requisições por servidor; e número de conexões ativas por servidor. A quantidade de tipo de informação obtida neste processo é decorrente das necessidades de distribuição específica de cada tipo de site, podendo este módulo gerencial alterar a política de distribuição dinamicamente conforme as características do site, realizando uma maior coleta de informações nos momentos menos críticos, e executando o mínimo de coleta com os dados mais críticos ao processo durante os instantes de alta demanda de tráfego. Observa-se que o método proposto pode ser implementado com mais recursos e controles nos switch de nível 7, onde as informações analisadas permitiram uma distribuição mais eficiente. Cabe a este módulo proceder a supervisão e gerenciamento dos parâmetros de distribuição, podendo até, ter a função de ligar e desligar servidores, conforme a necessidade específica do site Algoritmo de Distribuição do Método BC É responsável pelo procedimento de distribuição das solicitações de conexão e controle das requisições. Os pedidos de conexões são atendidos através de lista circular de distribuição ordenada pelo algoritmo de gerência e encaminhados em forma de rajada aos servidores, isto é, cada servidor recebe n solicitações de conexões seguidas, para que a seguir possa ser escolhido outro servidor para atender as requisições. O número n é definido para cada servidor, e pode ser no mínimo 1. As requisições são encaminhadas pela relação cliente x servidor estabelecida durante o procedimento de conexão. Ao receber um pedido de finalização de conexão, esta relação será desfeita e a cada novo pedido de conexão, a nova situação de relação será estabelecida, possibilitando, assim que o algoritmo de gerência realize o tratamento deste novo estado, em cada momento de tempo e estado dos servidores, para elaborar a relação da tabela de distribuição.

6 Para obter um melhor desempenho na gerência desta fila de relações, a manutenção da fila será realizada ciclicamente ao processo, exceto quando a fila atingir o limite máximo de elementos. Ao manter esta relação durante um determinado tempo, a distribuição de um novo pedido de conexão deste mesmo cliente será estabelecida pela tabela de relação, se existir, evitando assim todo o procedimento de avaliação e inserção de elementos na lista de relacionamentos. De outra forma, será estabelecido um novo relacionamento na lista de servidores de distribuição. Todas as mensagens são submetidas ao controle do número máximo de requisições por minuto (desempenho) que pode ser enviado para cada servidor, conforme estabelecido no momento do cadastramento do servidor à lista de distribuição do switch. Desta forma, a mensagem somente será enviada ao servidor se, neste exato momento, o número de mensagens enviadas nos últimos 60 segundos não ultrapassar o limite estabelecido do servidor. Se for superior, o sistema de controle atuará submetendo a mensagem a um retardo de 1/60 segundos, que após este tempo será enviada à fila de entrada para um novo procedimento de distribuição. No caso de pedido de uma nova conexão não pertencente à lista de relacionamentos cliente x servidor, será escolhido o próximo servidor da fila de distribuição. Se o servidor selecionado estiver com o número máximo de mensagens saturado, é automaticamente escolhido outro servidor, e somente se nenhum servidor da fila estiver apto a receber este pedido de conexão, isto é, todos estão saturados, então a mensagem será submetida a um retardo de 1/60 segundos, e encaminhada para nova distribuição. O crescimento da fila de requisições submetida ao retardo de 1/60 segundos é o indicativo que o distribuidor está entrando em estado de saturação, assim como os servidores estão no limite máximo de processamento especificado. Este limite de requisições em fila de retardo, é o gatilho de rejeição de novas requisições de conexões, realizadas também pelo tempo de 1/60 segundos. Assim, toda vez que a fila atingir o limite máximo de elementos da fila de retardo, o algoritmo recusará todas as solicitações de novas conexões pelo período de 1/60 segundos. Para permitir o dimensionamento de memória e desempenho do switch, é necessário determinar ao algoritmo métodos de controle que lhe garantam o desempenho necessário para o objetivo desejado. Se estes forem implementados, diretamente em componentes físicos do equipamento, pode ser dimensionado em função do tamanho máximo das filas de armazenagem e do método de recuperação de tabelas, dados e características físicas. O número máximo de elementos nas filas e tabelas de relacionamento e estatísticas de dados, são proporcionais a capacidade máxima de memória definida ao equipamento. É conclusivo que quanto maior forem as filas e tabelas, os métodos de acesso e manipulação dos dados requerem um tempo maior de processamento e, portanto, limitando o número máximo de distribuições realizadas em virtude da limitação tecnológica imposta. O método de distribuição proposto permite então, que seja especificado, com grande margem de segurança, o limite de tráfego máximo a ser distribuído.

7 4. Análise de Desempenho A análise de desempenho tem por objetivo verificar o desempenho do algoritmo proposto na distribuição de requisições de clientes a um cluster de servidores Web, cujos servidores possuem o mesmo conteúdo e são provedores de páginas estáticas. A caracterização da carga atende o perfil de duas situações distintas. Na primeira, a taxa de requisições é inferior a 85% da capacidade de processamento do sistema. No outro teste, utiliza-se a taxa de requisições superior a 95% da capacidade de processamento do sistema. A análise propõe a comparação do desempenho entre o algoritmo do modelo proposto e o algoritmo Round Robin. O modelo lógico, figura 1, é composto dos seguintes elementos : Cliente, Rede 1, Switch (dispatcher), Rede 2, Servidores Web e Rede 3. Neste caso, o Dispatcher direciona a requisição do cliente para o servidor alterando a requisição do cliente o endereço de destino com o IP (e IP checksums) do servidor. Este procedimento é executado em todas as requisições HTTP do cliente, pois o Distribuidor é o único endereço conhecido pela rede e pelo cliente do servidor destino, assumindo assim o papel de concentrador e redirecionador de todas as requisições enviadas dos clientes ao servidor. Para manter o estado de conexão do cliente com o servidor, torna-se necessário manter um registro de todos os assinalamentos realizados entre cliente/servidor, permitindo, assim que as novas requisições de um determinado cliente sejam enviadas para o mesmo servidor das requisições anteriores. Como o servidor irá retornar a solicitação diretamente para o cliente, isto é, sem passar pelo dispatcher, o servidor deverá alterar o cabeçalho IP com o endereço IP do dispatcher. Assim sendo, o cliente não tem conhecimento do endereço do servidor. Esta é uma solução totalmente transparente para o cliente e sem nenhuma necessidade de alteração profunda nos programas dos servidores, visto que o procedimento de substituição do TCP ocorre somente na camada TCP/IP. A arquitetura permite estabelecer um alto nível de disponibilidade do sistema, pois em caso de alguma falha em qualquer servidor, o endereço do mesmo pode ser removido da tabela de distribuição. O dispatcher é o ponto vital da rede, devido ser o único meio de acesso aos servidores, sendo o mesmo, o ponto de risco da estabilidade. Figura 1. Modelo Lógico 5. Modelo de Desempenho O modelo físico,é basicamente um modelo de filas e processos. Para a modelagem do algoritmo utiliza-se a técnica de solução de um problema pela análise de um modelo que

8 descreve o comportamento do algoritmo usando um computador digital, isto é, a simulação através do ambiente ARENA, voltado à modelagem e simulação de sistemas. O processo de modelagem contemplou dois algoritmos: Modelo Rajada Controlada (BC) e Modelo Round-Robin (RR). Neste trabalho, a modelagem não contemplou o módulo de gerência para o modelo BC. No modelo, o número de clientes não é delimitado, assim como, o modelo de simulação de processamento da estação cliente, pois a análise de carga enfatiza a intensidade de requisições submetidas ao switch, desconsiderando os tempos de processo no cliente e também na rede entre o cliente e o switch (Rede 1). Analogamente, na rede (rede 2) entre o switch e os servidores, considera-se o processamento zero. O cliente realiza requisições completas, isto é, estabelece a conexão, realiza aleatoriamente n requisições por sessão e finaliza a sessão. O número de requisições foi modelado por uma distribuição de Poison. A intensidade de requisições submetidas ao site é simulada através de uma distribuição Exponencial. Para avaliar o comportamento do algoritmo e a estabilidade dos servidores, a simulação foi realizada com objetivos de estabelecer uma carga de requisições e processamento dos servidores com um comportamento compatível ao idealmente projetado para o site e com outro 100 vezes superior. A rede é dividida em 3 segmentos: Rede 1; Rede 2 e Rede 3. Para os objetivos da simulação o tempo despendido no tráfego da informação na rede não interfere significativamente no resultado, no sentido do tráfego entrante de requisições ao switch, Já para o tráfego de retorno ao cliente - processo de tráfego originado do ciclo de requisições enviadas ao cliente, necessários para completar a informação da página web no cliente - este tempo foi modelado segundo uma distribuição função Triangular, com base nos tempos e características do modelo de rede utilizado por Cardellini (2000) contemplando na função triangular as bandas de tráfego pequena, média e larga. O modelo não contempla a variação do tamanho de bytes das solicitações de requisições. O algoritmo comporta o modelo de servidores heterogêneos, mas no modelo simulado considera-se que os servidores possuem o mesmo comportamento. Seus tempos de serviço foram também modelados na distribuição Triangular. Seus parâmetros englobam os tempos de todo o conjunto de recursos utilizados no processamento das requisições. O tempo de processamento do algoritmo foi definido no modelo foi conforme a tabela 1. Tabela 1. Tempo do Processo dos Algoritmos de Distribuição Procedimento Modelo BC Modelo RR Conexão Requisições Finalização

9 6. Projeto de Experimentos Dentre as diversas alternativas de projeto de experimentos, considerou-se neste trabalho o projeto fatorial completo 2 k, que utiliza todas as combinações possíveis de todos os níveis de todos os fatores, considerando cada fator em dois possíveis níveis, conforme Tabela 2. A vantagem deste projeto é que todas as combinações possíveis de configuração e carga são examinadas, possibilitando encontrar o efeito de todos os fatores, incluindo fatores secundários e suas interações. A Tabela 2 apresenta os fatores e níveis empregados nos experimentos realizados. Tabela 2. Fatores e Níveis Fatores Nível 1 Nível -1 Fator A Intensidade de requisições ao site Fator B Num. Interações com o Cliente/conexão 10 5 Fator C Rajada de Distribuição por Servidor 4 2 Fator D Fila de Delay ( Disparo de Rejeição ) O estudo de desempenho para o algoritmo BC, com 4 fatores (A,B,C e D), com cada fator tendo 2 níveis, requerendo 2 4 (16) experimentos, com três replicações. O estudo de desempenho para o algoritmo RR, com 2 fatores (A e B), com cada fator tendo 2 níveis, requerendo 2 2 (4) experimentos, com três replicações. Para a análise dos fatores no modelo RR, os fatores C e D não são analisados devido o algoritmo não tratar estes dois fatores Experimentos Realizados como o Modelo BC Para analisar o comportamento do sistema sob estudo, foram eleitas quatro variáveis de resposta : Tempo de Resposta, Carga do Servidor, Requisições Rejeitadas e Requisições Atendidas. Os efeitos dos fatores sobre as variáveis sob estudo estão demonstrados na Tabela 3. Fator Tabela 3. Variáveis de Resposta do algoritmo BC Tempo de Resposta Carga no Servidor Requisições Rejeitadas Requisições Atendidas A 40,70% 1,18% 87,72% 17,17% B 51,79% 2,38% 11,22% 29,98% C 0,00% 0,52% 0,04% 6,36% D 0,00% 0,01% 0,01% 0,18% AB 7,48% 0,71% 0,00% 9,35% AC 0,01% 1,36% 0,59% 18,95% AD 0,00% 0,03% 0,10% 0,27% BC 0,02% 0,86% 0,21% 12,15% BD 0,00% 0,36% 0,05% 4,78% CD 0,00% 0,06% 0,05% 0,80% Erros 0,00% 92,52% 0,00% 0,00%

10 6.2. Experimentos Realizados como o Modelo RR Para analisar o comportamento do sistema sob estudo, foram eleitas três variáveis de resposta : Tempo de Resposta, Carga do Servidor e Requisições Atendidas. Os efeitos dos fatores sobre as variáveis sob estudo estão demonstrados na Tabela 4. Fator Tempo de Resposta Carga no Servidor Requisições Atendidas A 40, , ,28645 B 51, , ,2452 AB 8, , , Erros 0, , , Tabela 4. Variáveis de Resposta do algoritmo RR 7. Analise Comparativa Como era esperado, o tempo de resposta mostrou que o modelo RR é mais rápido que o BC quando a carga de requisições ao site está dentro do projetado, visto que o método de distribuição RR é mais rápido. Contudo, quando o site é saturado de requisições comprometendo a estabilidade de processamento dos servidores, elevando o tempo de resposta para o modelo RR. O modelo BC, sofre a sobrecarga de requisições no distribuidor, elevando, também, o tempo de processamento das requisições, mas o processo de rejeição de requisições possibilita estabilizar o tempo de resposta. A rajada utilizada não foi significativamente grande para influenciar no resultado. A carga de processamento no servidor mostrou-se muito significativa em função do tráfego de requisições para o modelo RR, o que demonstra que o tráfego atua diretamente no desempenho dos servidores e que o controle de desempenho estabelecido pelo modelo BC foi eficaz mantendo estável a carga do processamento dos servidores em relação ao tráfego. Para estabelecer o controle de carga em relação ao tráfego, as requisições rejeitadas sinalizaram claramente o custo do controle de tráfego - altas taxas de rejeição para altas taxas de tráfego. As requisições atendidas throughput do sistema, para o modelo RR têm sua maior representatividade no tráfego, enquanto para o modelo BC está no número de interações realizadas entre o cliente e o servidor. O modelo ratificou garantia de um tráfego estável dentro da capacidade previamente estabelecida aos servidores. Mostrou, também, que uma página web com muitas interações com o servidor, gera a degradação do tempo de resposta e o throughput do sistema. 8. Considerações Finais O método mostrou ser eficaz na distribuição de requisições internet a uma família de servidores, mesmo em situações atípicas, conforme os resultados obtidos na simulação. Como principais benefícios do método podemos citar : Algoritmo de fácil implementação; Algoritmo independente de dados externos ao switch; Garantia de um

11 tempo de resposta máximo ao cliente; e Garantia de comportamento estável aos servidores. Pode ser considerado como ponto positivo a rejeição de requisições utilizada para manter o desempenho dos servidores no valor máximo estabelecido. A rejeição é fundamental para a estabilidade do sistema. A especificação de desempenho dos servidores em requisições por minuto, não é adequada para a alta demanda, deve ser estudada uma outra métrica de desempenho que melhor caracterize a demanda para grande oscilação no tráfego internet. Como alternativa para o aproveitamento total das requisições recebidas dos clientes, pode ser implementado um algoritmo adicional específico para o encaminhamento do tráfego rejeitado a um outro switch, de ação de escape, durante uma sobrecarga de tráfego. Tal solução tem um encadeamento máximo limitado pelo primeiro switch, à memória dele e ao tempo de processamento de busca. Cabe finalmente ressaltar que esta é uma pesquisa em andamento. Estudos ampliados dos experimentos aqui apresentados estão sendo realizados. Tais estudos levarão à conclusões mais definitivas sobre as potencialidades do Modelo BC. 9. Referências Dias,D.,Kish, W.,Muhkerjee, R., and Tewari, R.(1996). A scalable and highly available web server. In Proceedings of the IEEE Computer Conference (COMPCON), Santa Clara.Março. Hunt, G. (1998). Network Dispatcher: a connection router for scalable Internet service, Computer Networks and ISDN Systems, n..30, pp Kwan, T., McGrath, R.,Reed, D. (1995). NCSA s World Wide Web server: Design and Performance, IEEE Computer, nº 11, pp , Novembro. Pai, V. et Al.. (1998). Locality-Aware Request Distribuition in Cluster-based Network Servers, Proceeding of ACM 8ª International Conference Architectural Support fot Prog. Language and Op. Systems, Outubro. Cardellini, V., Colajanni, M., and Yu, P. S.(2000) Geographic load balancing for scalable distributed Web systems. In Proc. IEEE Mascots 2000, São Francisco, CA, Agosto/Setembro Zhang, X., Barrientos, M., Chen, J. B. and Seltzer, M..(1999). HACC: An Architecture for Cluster-Based Web Servers. In Proceedings of the 3rd USENIX Windows NT Symposium, Seattle, WA, Julho.1999.