TESTES COM O ALGORITMO ROUND-ROBIN (RR)

Este algoritmo distribui as requisições igualmente entre os servidores reais. Sua configuração no LVS é através da interface gráfica do Piranha, que é mostrada na figura 4.1.

Figura 4. 1 - Configurações do algoritmo Round-Robin no LVS Fonte: Elaborado pelos autores, 2014

Após o termino das requisições o servidor WEB1 respondeu por 11.730.667 vezes, o servidor WEB2 respondeu por 11.730.667 vezes e o servidor WEB3 respondeu por 11.730.666 vezes (figura 4.2), mostra-se assim que o algoritmo cumpriu o proposto no balanceamento igualitário de carga entre os servidores web e sendo recomendado seu uso quando os servidores web possuem os mesmos recursos de hardware.

Figura 4. 2 - Totalização das requisições recebidas - Algoritmo RR Fonte: Elaborado pelos autores, 2014

Para comprovar a real distribuição de carga entre os servidores web, foram coletadas informações de uso de recursos de CPU, memória e rede destes servidores, via ferramenta Monitorix. O gráfico da figura 4.3 mostra a média de requisições por segundo recebidas pelo Apache no servidor WEB1 durante o teste com o algoritmo round-robin, o qual foi de 115 acessos por segundo. Valor idêntico foi obtido nos demais servidores WEB2 e WEB3.

Figura 4. 3 - Média de requisições recebidas pelo Apache no servidor WEB1 Fonte: Elaborado pelos Autores, 2014

Ainda ao considerar as requisições, a figura 4.4 ilustra o gráfico de tráfego de entrada e saída na interface eth0 do servidor WEB1, com média de entrada de 52 kbytes por segundo e de saída de 80 kbytes por segundo. O mesmo tráfego foi medido na interface de rede dos outros dois servidores WEB2 e WEB3.

Figura 4. 4 - Média de tráfego de entrada/saída de rede no servidor WEB1 Fonte: Elaborado pelos autores, 2014

Para atender todas as requisições recebidas durante o teste, o Apache utilizou em média cerca de 2.5% de CPU da máquina, conforme mostrado na figura 4.5. O mesmo consumo ocorreu também nos outros dois servidores WEB2 e WEB3.

Figura 4. 5 - Média de consumo de CPU no servidor WEB1 Fonte: Elaborado pelos autores, 2014

Ainda ao considerar o uso de recursos da máquina durante os testes, o servidor WEB1 registrou uma média de uso de 478 Megabytes de memória física, 400 Megabytes de cache (memória de acesso rápido), e oscilou entre 50 e 30 Megabytes em buffers (memória temporária), conforme figura 4.6. Consumo similar de memória foi registrado nos demais servidores.

Figura 4. 6 - Média de consumo de memória no servidor WEB1 Fonte: Elaborado pelos autores, 2014

4.3 TESTES COM O ALGORITMO WEIGHTED ROUND ROBIN (WRR)

Este algoritmo atribui requisições aos servidores reais equivalentes ao peso. Servidores com um valor maior de peso recebem novas requisições primeiramente e respondem a mais requisições do que os servidores com um valor menor de peso. A figura 4.7 mostra a configuração do LVS para utilizar o algoritmo Weighted Round

Robin, onde foi adicionado peso 5 ao servidor WEB1 e peso 1 aos outros dois servidores.

Figura 4. 7 - Configurações do algoritmo Weighted Round Robin no LVS Fonte: Elaborado pelos autores, 2014

Após o termino das requisições o servidor WEB1 respondeu por 24.940.830 vezes, o servidor WEB2 respondeu por 5.125.585 vezes e o servidor WEB3 respondeu por 5.125.585 vezes (figura 4.8), mostrando que o algoritmo distribuiu uma carga de requisições maior para o servidor WEB1 de maior peso, em detrimento dos demais servidores que ficaram ambos com uma carga menor, é recomendado seu uso quando os servidores web possuem recursos de hardware diferentes.

Figura 4. 8 - Totalização das requisições recebidas - Algoritmo WRR Fonte: Elaborado pelos autores, 2014

Para comprovar a real distribuição de carga entre os servidores web, foram coletadas informações de uso de recursos de CPU, memória e rede destes servidores, via ferramenta Monitorix. O gráfico da figura 4.9 mostra a média de requisições por segundo recebidas pelo Apache no servidor WEB1 durante o teste com o algoritmo Weighted Round Robin, o qual foi de 250 acessos por segundo, o qual foi 5 vezes maior que o valor obtido nos demais servidores WEB2 e WEB3.

Figura 4. 9 - Requisições - Apache no WEB1 - algoritmo WRR Fonte: Elaborado pelos autores, 2014

Ainda ao considerar as requisições, a figura 4.10 ilustra o gráfico de tráfego de entrada (110 kbytes por segundo) e saída (170 Kbytes por segundo) na interface eth0 do servidor WEB1, tráfego este que foi cerca de 5 vezes maior que o medido na interface de rede dos outros dois servidores WEB2 e WEB3.

Figura 4. 10 - Tráfego de entrada/saída de rede no WEB1 - algoritmo WRR Fonte: Elaborado pelos autores, 2014.

Para atender todas as requisições recebidas durante o teste, o Apache apresentou picos de 20% de utilização de CPU da máquina, conforme mostrado na figura 4.11. Nos outros servidores, o consumo foi de 4% no servidor WEB2 e 6% no servidor WEB3.

Figura 4. 11 - Média de consumo de CPU no - WEB1 - algoritmo WRR Fonte: Elaborado pelos autores, 2014

Ainda ao considerar o uso de recursos da máquina durante os testes, o servidor WEB1 registrou uma média de uso de 480 Megabytes de memória física, 410 Megabytes de cache (memória de acesso rápido), e oscilou entre 30 e 10 Megabytes em buffers (memória temporária), conforme figura 4.12. Consumo similar de memória foi registrado nos demais servidores.

Figura 4. 12 - Média de consumo de memória no WEB1 - algoritmo WRR Fonte: Elaborado pelos autores, 2014

4.4 RESULTADOS DOS TESTES COM DEMAIS ALGORITMOS

Os mesmos procedimentos dos testes anteriores foram realizados com os demais algoritmos disponíveis no LVS via interface do software Piranha. Os resultados obtidos são mostrados no Quadro 4.1.

Quadro 4. 1 - Resultados de testes com algoritmos de escalonamento

Fonte: Elaborado pelos autores, 2014

Embora os resultados obtidos nos testes com os algoritmos LBLC, LBLCR, DH e SH possam parecer estranhos, principalmente no que tange as informações na coluna Requisições Respondidas, estes retratam a realidade do funcionamento de cada algoritmo, conforme descrito a seguir:

LBLC: O servidor LVS busca transmitir todas as conexões de um endereço IP particular para o mesmo servidor, ou seja, a primeira vez que uma requisição surgir, o servidor LVS escolherá um servidor web para atendê-la, e todas as requisições que surgirem na sequência deste cliente permanecerão a serem transmitidas para o mesmo servidor escolhido. Se o servidor escolhido estiver sobrecarregado ou indisponível, as requisições serão enviadas ao servidor com menos conexões. No caso desse trabalho o servidor WEB 1 conseguiu atender a todas as requisições sem se sobrecarregar;

LBLCR: É similar ao algoritmo LBLC, mas com um avanço, o servidor LVS mantém um mapeamento de um cliente para um conjunto de servidores que podem atendê-lo. Se todos os servidores do conjunto estiverem sobrecarregados, o servidor LVS separa um servidor com menos conexões e o acrescenta ao conjunto. Caso este conjunto não se modifique em um intervalo de tempo específico (seis minutos, intervalo padrão como definido no código do IPVS), o servidor com maior carga será excluído. Nos testes apresentados anteriormente, o servidor WEB 1 conseguiu atender a todas as requisições sem se sobrecarregar;

DH: O servidor LVS sempre envia requisições de um mesmo endereço IP de

origem para o mesmo servidor web na estrutura do LVS, usando uma lista estática de endereços de destino. O algoritmo é útil quando o Servidor Real é um servidor Proxy, cache ou alguma outra aplicação autenticada, pois irá sempre transmitir a requisição do cliente para o mesmo servido do cluster, não perdendo a autenticação, caso contrário o servidor vai ficar eliminando a autenticação, pois a cada requisição, a solicitação do cliente pode ir para um servidor diferente. Nesse trabalho não foi criado uma tabela hash para esse algoritmo, pois se tratam de servidores web; mas com os resultados dos testes pode-se observar que as requisições foram enviadas para o mesmo servidor do cluster (WEB 1), onde foram atendidas sem que houvesse alguma paralisação no serviço;

SH: Este algoritmo pode ser usado quando o servidor LVS precisa garantir-

se que os pacotes de resposta são enviados de volta pelo mesmo roteador ou firewall no qual a requisição teve origem. Este algoritmo de escalonamento é apenas necessário quando o servidor LVS possui mais de uma interface física de rede e necessita saber para qual firewall ou roteador enviar os pacotes de resposta, e também para aplicações autenticadas. Como no algoritmo DH, não foi criado uma tabela hash para esse algoritmo; mas com os resultados dos testes pode-se

observar que as requisições foram enviadas para o mesmo servidor do cluster (WEB 2), onde foram atendidas sem que houvesse alguma paralisação no serviço. O servidor WEB 1, não respondeu primeiro por ter uma conexão ativa, então consequentemente o servidor WEB 2 respondeu as requisições.

Após análise dos resultados, pode-se concluir que os mesmos comprovam o funcionamento correto de cada algoritmo de balanceamento de carga do LVS.

CONCLUSÃO

O objetivo deste trabalho foi desenvolver um serviço web confiável onde foi utilizada a tecnologia do LVS, com a estrutura Direct Routing e foi utilizada a ferramenta Piranha para sua configuração e monitoramento. A estrutura pode ser reaproveitada para que possa ser usada em outros tipos de serviços como e-mail, impressão, banco de dados, além de explorar os outros métodos do LVS como NAT e IP Tunneling, e também a sua função de alta disponibilidade.

O objetivo foi atingido com sucesso, onde a estrutura se mostrou confiável nos vários testes executados. Toda estrutura foi construída onde se fez o uso de Software Livre, o que permite a redução de custos numa possível implantação deste trabalho.

A pesquisa para a elaboração do trabalho foi intensa, há pouco material sobre a tecnologia LVS, a maioria artigos, o que torna a sua implementação um pouco mais difícil.

Do início ao fim do trabalho houve várias dificuldades como a escolha da distribuição Linux dos servidores virtuais, software de gerenciamento do LVS, escolhas dos sistemas operacionais onde seria instalado o software de servidor web e como obter os resultados do desempenho de cada servidor web de forma gráfica.

Para escolher a distribuição Linux que seria o servidor LVS, foram testadas as distribuições Debian, Ubuntu, OpenSuse e Springdale /Puias Linux. Ubuntu, Debian e OpenSuse apresentaram problemas em relação ao funcionamento do LVS, principalmente com a sua ferramenta para gerenciamento o Ultra Monkey, onde a mesma se encontra defasada. Já a distribuição Linux Puias se mostrou extremamente confiável, com o software de gerenciamento Piranha, funcionou sem erros e foi definido para fazer parte da estrutura.

Para os sistemas operacionais dos servidores web foram testados o Puias Linux, Mac OS X Snow Leopard e Windows Server 2008 Server Core. Tanto o Windows quanto o Mac não se mostraram estáveis. O Windows em relação ao software servidor web, onde o apache não funcionava corretamente, somente o IIS funcionava. O Mac se mostrava instável, travava e consumia muita memória, além da incompatibilidade com o software de virtualização, o VirtualBox. Já o Puias com o apache tinha total estabilidade e compatibilidade com os servidores LVS (com a

mesma distribuição), por isso foi escolhido como distribuição para os três servidores web.

O software de servidor web foi mais fácil de ser escolhido, pois levou em conta a compatibilidade com os sistemas operacionais, o apache foi à escolha mais coerente.

Para gerar resultados da implementação em gráficos foi feito uma pesquisa com três softwares diferentes: Zabbix, Cacti e Monitorix; onde Zabbix e cacti além de apresentar erros não apresentavam relatórios do apache por padrão, já o Monitorix ofereceu uma instalação e configuração amigável e uma interface intuitiva. Por conta desses resultados foi definido que o Monitorix seria a ferramenta para a geração de gráficos.

A junção de todas essas pesquisas, problemas e dificuldades, fizeram com que enriquecesse o conhecimento dos integrantes que realizaram o trabalho, e por consequência fez com que o trabalho fosse concluído com sucesso.

REFERÊNCIAS BIBLIOGRÁFICAS

AFRICANIDADE. Jornal on-Line Africanidade.com, 2008. Disponivel em: <http://www.africanidade.com/articles/835/1/Indisponibilidade-do-site-

Africanidadecom/Paacutegina1.html>. Acesso em: 22 mar. 2014.

AZEREDO, P. Revista TI. Timaster, 2006. Disponivel em: <http://www.timaster.com.br/revista/materias/main_materia.asp?codigo=1098>. Acesso em: 22 abr. 2014.

COTA, ALAN. Alta Disponibilidade com LVS. Viva o Linux, 2005. Disponivel em: <http://www.vivaolinux.com.br/artigo/Alta-Disponibilidade-com-LVS/>. Acesso em: 20 setembro 2013.

DANTAS, M. Tecnologia de Redes de Comunicação e Computadores. São Paulo: Axcel Books do Brasil, 2002.

E-COMMERCE News. tráfego deixa Groupon inoperante, 2010. Disponivel em: <http://ecommercenews.com.br/noticias/balancos/trafego-deixa-groupon-inoperante- 26-horas-em-30-dias>. Acesso em: 01 maio 2014.

FARIAS, P. C. B. Curso Básico de Redes Parte 1. Julio Battisti, 2006. Disponivel em: <http://www.juliobattisti.com.br/tutoriais/paulocfarias/redesbasico001.asp>. Acesso em: 05 set. 2013.

FOROUZAN, B. A. Comunicação de Dados e Redes de Computadores. 4ª. ed. São Paulo: Mcgraw Hill- Artmed, 2008.

GOVERNO ELETRÔNICO. guiacluster.pdf. Programa de Governo Eletrônico

Brasileiro, 2006. Disponivel em: <http://www.governoeletronico.gov.br/anexos/guia-

de-cluster>. Acesso em: 24 setembro 2013.

KEEPALIVED. keepalived para Linux. keepalived, 2012. Disponivel em: <http://www.keepalived.org/>. Acesso em: 22 outubro 2013.

LUDOLF, D. Piranha de Red Hat. Seja Livre, 2011. Disponivel em: <http://sejalivre.org/piranha-de-red-hat/>. Acesso em: 26 setembro 2013.

MACK, JOSEPH. LVS-Mini-Howto. Austintek.com, 2004. Disponivel em: <http://www.austintek.com/LVS/LVS-HOWTO/mini-HOWTO/LVS-mini-HOWTO- pt.html>. Acesso em: 20 Maio 2014.

MENDES, D. R. Redes de Computadores Teoria e Prática, 2007. Disponivel em: <http://novatec.com.br/livros/redescom/capitulo9788575221273.pdf>. Acesso em: 15 out. 2013.

ODOM, W. Cisco CCNA TM. 3ª. ed. Rio de Janeiro: Alta Books, 2003.

São Paulo: Brasport, 2003.

SOARES, L. F. G. Redes de Computadores das Lans,Mans e Wans ás Redes

ATM. 2 edição. ed. Rio de Janeiro: campus, 1995.

STALLINGS, W. Redes e Sistemas de Comunicação de Dados. 5ª. ed. Rio de Janeiro: campus, 2005.

TANENBAUM, A. S. Redes de Computadores. 3ª. ed. Rio de Janeiro: Campus, 1997.

TANENBAUM, A. S. Redes de Computadores. 4ª. ed. Rio de Janeiro: Campus, 2003.

TORRES, G. Redes de Computadores Curso Completo. Rio de Janeiro: Axcel Books, 2001.

TORRES, G. Redes de computadores. Versão Revisada. ed. Rio de Janeiro: Novaterra, 2009.

ULTRA MONKEY. Ultra Monkey: About. Ultra Monkey, 2005. Disponivel em: <http://www.ultramonkey.org/about.shtml>. Acesso em: 26 outubro 2013.