CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
ANTONIO MARCOS HONORIO
MAIKON HENRIQUE DA SILVA SOUZA
ESTUDO E ANÁLISE DO BALANCEAMENTO DE CARGA DE
SERVIDORES COM LINUX VIRTUAL SERVER (LVS)
LINS/SP
1° SEMESTRE /2014
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
ANTONIO MARCOS HONORIO
MAIKON HENRIQUE DA SILVA SOUZA
ESTUDO E ANÁLISE DO BALANCEAMENTO DE CARGA DE
SERVIDORES COM LINUX VIRTUAL SERVER (LVS)
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins para obtenção
do Titulo de Tecnólogo em Redes de
Computadores.
Orientador: Prof. Me Julio Fernando Lieira.
LINS/SP
1° SEMESTRE /2014
ANTONIO MARCOS HONORIO
MAIKON HENRIQUE DA SILVA SOUZA
ESTUDO E ANÁLISE DO BALANCEAMENTO DE CARGA DE SERVIDORES COM
LINUX VIRTUAL SERVER (LVS)
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins, como parte dos
requisitos necessários para a obtenção do título de
Tecnólogo em Redes de Computadores sob a
orientação do Prof. Me Julio Fernando Lieira.
Data de aprovação _______/________/________
____________________________________________________
Orientador Julio Fernando Lieira
____________________________________________________
Examinador
____________________________________________________
Examinador
Dedicamos este trabalho aos nossos
Professores e familiares que estiveram
presente conosco durante toda esta jornada.
Antonio Marcos Honório
Maikon Henrique da Silva Souza
AGRADECIMENTOS
Primeiramente agradeço a Deus por ter me dado saúde e força nesta
caminhada para poder cumprir todas as etapas as quais me propus realizar.
Agradeço a toda a minha família que sempre me apoiou e me ajudou a não
desanimar nestes anos de estudos, principalmente aos meus pais Antonio e Gilda,
minha sogra Antonia e meus irmãos Carlos, Gisele e Keli; agradeço a todos os meus
primos e também a meu sobrinho, Diego, pela parceria nas aulas.
Agradeço a Fatec por ter me dado esta chance de estudo que espero retribuir
um dia.
A todos os professores que com paciência e competência nos ajudam a nos
tornar profissionais mais preparados para a vida. Ao professor Júlio Fernando Lieira,
nosso orientador, que com muita dedicação nos ajudou em todos os momentos
dessa caminhada e a professora Luciane Noronha que sempre me deu força nesta
jornada.
Um agradecimento especial a todos meus amigos de sala durante este curso,
principalmente ao Maikon parceiro neste momento final e de muitas dificuldades.
E como não poderia deixar de ser, agradeço a minha esposa Adriana,
companheira e parceira de todas as horas, que não mediu esforços para me ajudar
e me animar nos momentos de desânimo. E, claro, aos meus queridos filhos Karol e
Marco Antonio, pois é por eles que concluo este curso.
Antonio Marcos Honório
AGRADECIMENTOS
Nessa etapa muito importante da minha vida e que irei carregar comigo todo
conhecimento adquirido nesse precioso período de tempo, venho agradecer a todos
que contribuíram nessa jornada.
Primeiramente a Deus que traçou o meu caminho até aqui, com alegrias e
saúde.
A minha mãe Vilma e ao meu pai Otacilio que desde sempre me apoiaram e
ofereceram o alicerce necessário, não só para concluir essa etapa em minha vida,
mas como todas que passei até o presente momento.
A minha tia Lourdes que tenho como uma segunda mãe.
A minha irmã Pâmela e a minha namorada Ana pelo apoio e dedicação nos
momentos em que precisei.
A toda a minha família que se manteve presente comigo durante essa
caminhada.
Ao meu parceiro e amigo nesse trabalho Antonio Marcos Honório, por
partilhar todo o seu conhecimento e dedicação em prol desse trabalho.
A cada um dos professores, com os qual tive o privilégio de conviver durante
esse período.
Um agradecimento especial ao professor Julio Fernando Lieira, que graças ao
seu conhecimento, dedicação e disponibilidade nos ajudou a concluir esse trabalho
nos orientando e enriquecendo nossos conhecimentos.
Agradeço a Fatec por proporcionar todos os recursos necessários para os
estudos, e por ser palco da fase mais importante da minha vida, por isso, serei
eternamente grato a essa instituição.
Também agradeço aos amigos que posso chamar de irmãos que tive a sorte
de fazer durante essa jornada: João Luiz, Cezar Henrique, Luciano Kiyosaque,
Bruno Carvalho, Antonio Marcos, Bruno Vinicius, Mauricio Gimenez, Fernando e
Gustavo Cremonesi, Mari Nogueira e Alexandre Kenji.
Maikon Henrique da Silva Souza
RESUMO
Este trabalho tem como objetivo apresentar uma solução que assegure um serviço
web confiável e resguardado contra falhas, sejam elas de software ou de hardware.
A solução adotada foi a criação de um cluster com balanceamento de carga
utilizando a tecnologia do LVS, que é um projeto de código aberto cujas
características de redundância, desempenho e escalabilidade se enquadram
perfeitamente às necessidades deste trabalho. Para melhor compreensão do mesmo
foram abordados conceitos de rede de computadores com suas topologias e
arquitetura; assim como um levantamento bibliográfico sobre alta disponibilidade,
clusters, além das tecnologias disponíveis para implementação do LVS. Todo
processo de configuração e implantação da estrutura do LVS via Direct Routing
foram descritos, bem como a coleta e análise dos dados do comportamento dos
servidores WEB perante os testes de vários algoritmos de escalonamento definidos
na estrutura do LVS. A tecnologia do LVS, além do fato de não incorrer em custo, se
mostrou valiosa por oferecer um ambiente confiável não somente para um serviço
web, mas como assegurar alta disponibilidade em um serviço de e-mail, banco de
dados, proxy entre outros; assim torna-se uma tecnologia imprescindível para
qualquer outro ambiente, seja ele acadêmico ou empresarial, e que tenha
necessidade de garantir a total disponibilização de seus serviços.
Palavras-chave: Cluster, balanceamento de carga, alta disponibilidade, Direct
Routing.
ABSTRACT
This work had the purpose of presenting a solution that ensure a reliable web service
and sheltered against failures, whether of software or hardware.
The adopted solution was to create a cluster with load balancing using technology of
LVS, which is an open source project whose features redundancy, performance and
stability fit perfectly to the needs of this work. For better understanding of the work
were discussed concepts of computer network with their topologies and architecture;
as well as a bibliographical survey about high availability, clusters, beyond the
technologies available for deployment of LVS. The whole process of configuration
and deployment of the LVS structure by way of Direct Routing were described, as
well as the collection and analysis of data on the behavior of WEB servers, before
the testing of various scheduling algorithms defined in the LVS structure. The LVS
technology, beyond the fact of not incurring cost, proved valuable for providing a
trusted environment not only for a web service, how to ensure high availability in an
email service, database, proxy among other; thus becoming an essential technology
for any environment, be it academic or business that has the need of ensure the full
provision of their services.
Keywords: Cluster, Load Balancing, High Availability, Direct Routing.
LISTA DE ILUSTRAÇÕES
Figura 1. 1 - Modelo de computação centralizada ..................................................... 22
Figura 1. 2 - Modelo de computação distribuída ....................................................... 23
Figura 1. 3 - Exemplo de uma rede ponto-a-ponto .................................................... 24
Figura 1. 4 - Exemplo de uma rede cliente/servidor .................................................. 26
Figura 1. 5 - Topologia totalmente conectada ........................................................... 27
Figura 1. 6 - Topologia em malha .............................................................................. 28
Figura 1. 7 - Topologia em anel ................................................................................. 28
Figura 1. 8 - Topologia em barramento ..................................................................... 29
Figura 1. 9 - Topologia em estrela ............................................................................. 30
Figura 1. 10 - Topologia em árvore ........................................................................... 30
Figura 1. 11 - Topologia sem fio ................................................................................ 31
Figura 1. 12 - Camadas da arquitetura TCP/IP e respectivos protocolos.................. 34
Figura 1. 13 - Datagrama do protocolo IP ................................................................. 35
Figura 2. 1 - Esquema de Alta Disponibilidade.......................................................... 40
Figura 2. 2 - Exemplo de cluster de balanceamento de carga .................................. 41
Figura 2. 3 - Esquema geral de um Linux Virtual Server ........................................... 43
Figura 2. 4 - LVS via NAT.......................................................................................... 45
Figura 2. 5 - LVS via IP Tunneling ............................................................................. 46
Figura 2. 6 - LVS via Direct Routing .......................................................................... 47
Figura 3. 1 - Arquitetura LVS ..................................................................................... 53
Figura 3. 2 - Interface de Login do software piranha ................................................. 63
Figura 3. 3 - Definição do IP primário e tipo de LVS no servidor LVS1 e LVS2 ........ 64
Figura 3. 4 - Definição do IP Secundário e configurações de monitoramento ........... 65
Figura 3. 5 - Adicionando um servidor virtual ao cluster LVS .................................... 66
Figura 3. 6 - Adicionando um servidor real ao cluster LVS........................................ 67
Figura 3. 7 – Servidores reais adicionados ao cluster LVS ....................................... 67
Figura 3. 8 - Teste de funcionamento da estrutura .................................................... 69
Figura 4. 1 - Configurações do algoritmo Round-Robin no LVS................................ 72
Figura 4. 2 - Totalização das requisições recebidas - Algoritmo RR ......................... 72
Figura 4. 3 - Média de requisições recebidas pelo Apache no servidor WEB1 ......... 73
Figura 4. 4 - Média de tráfego de entrada/saída de rede no servidor WEB1............. 73
Figura 4. 5 - Média de consumo de CPU no servidor WEB1 ..................................... 74
Figura 4. 6 - Média de consumo de memória no servidor WEB1 .............................. 74
Figura 4. 7 - Configurações do algoritmo Weighted Round Robin no LVS ................ 75
Figura 4. 8 - Totalização das requisições recebidas - Algoritmo WRR ...................... 75
Figura 4. 9 - Requisições - Apache no WEB1 - algoritmo WRR ................................ 76
Figura 4. 10 - Tráfego de entrada/saída de rede no WEB1 - algoritmo WRR ........... 76
Figura 4. 11 - Média de consumo de CPU no - WEB1 - algoritmo WRR................... 77
Figura 4. 12 - Média de consumo de memória no WEB1 - algoritmo WRR............... 77
LISTA DE QUADROS
Quadro 1. 1 - Diferenças entre redes cliente/servidor e ponto-a-ponto ..................... 26
Quadro 1. 2 - Modelo de Referência OSI .................................................................. 33
Quadro 2. 1 - Métodos de implementação do LVS .................................................... 44
Quadro 4. 1 - Resultados de testes com algoritmos de escalonamento ................... 78
LISTA DE SCRIPTS
Script 3. 1 - Comandos para desabilitar o iptables .................................................... 55
Script 3. 2 - Desabilitando o SELinux ........................................................................ 55
Script 3. 3 - Configuração IP nas interfaces do servidor web 1 ................................. 55
Script 3. 4 - Configuração IP nas interfaces do servidor web 2 ................................. 56
Script 3. 5 Configuração IP nas interfaces do servidor web 3 ................................... 56
Script 3. 6 - Ativação das configurações IP nas interfaces ........................................ 56
Script 3. 7 - Procedimentos de instalação e configuração inicial do Apache ............. 57
Script 3. 8 - Configuração do Apache para gerar informações mais detalhadas ....... 58
Script 3. 9 - Instalação das dependências do Monitorix ............................................ 58
Script 3. 10 - Comandos para download e instalação do Monitorix ........................... 59
Script 3. 11 - Comandos instalação e configuração do arptables .............................. 60
Script 3. 12 - Configuração IP nas interfaces do servidor LVS 1 ............................... 61
Script 3. 13 - Configuração IP nas interfaces do servidor LVS 2 ............................... 61
Script 3. 14 - Ativação das configurações IP nas interfaces dos servidores LVS ...... 62
Script 3. 15 - Instalação dos pacotes ipvsadm e piranha nos servidores LVS .......... 62
Script 3. 16 - Configurações sysctl nos servidores LVS ............................................ 62
Script 3. 17 - Configuração e inicialização do software piranha ................................ 63
Script 3. 18 - Arquivo com as configurações do cluster LVS criado pelo Piranha ..... 68
Script 4. 1 - Script de requisição de página ............................................................... 70
Script 4. 2 - Configurações na máquina de requisição de páginas ............................ 71
LISTA DE ABREVIATURAS E SIGLAS
ARP - Address Resolution Protocol
ARPA – Advanced Research Projects Agency
ARPANET - Advanced Research Projects Agency Network
CAN - Campus Area Network
CPU - Central Processing Unit
CVS - Concurrent Version System
DARPA - Defense Advanced Research Projects Agency
DH - Destination hash
DNS - Domain Name System
FSP - Free Software Foundation
FTP - File Transfer Protocol
GNU - General Public License
GUI - Graphical User Interface
HTTP - Hyper Text Transfer Protocol
HTTPS – Hyper Text Transfer Protocol Secure
IAB - Internet Activity Board
IEEE - Institute of Electrical and Electronics Engineers
IP - Internet Protocol
IPVS - IP Virtual Server
ISO - International Organization for Standardization
Kbps - kilobit por Segundo
LAN - Local Area Network
LBLC - Locality-Based Least-Connection
LBLCR - Locality-Based Least-Connection with Replication Scheduling
LC - Least-Connection
LVS – Linux Virtual Server
MAN - Metropolitan Area Network
Mbps - Megabit por segundo
NAT - Network Address Translation
NAT - Network Address Translation
NNTP - Network News Transfer Protocol
NQ - Never Queue
OSI - Open Systems Interconnection
PC - Personal Computer
PHP - Hypertext Preprocessor
RR – Round Robin
SED - Shortest Expected Delay
SMTP - Simple Mail Transfer Protocol
SRI - Stanford Research Institute
SSH – Secure Shell
TCP - Transmission Control Protocol
UCLA - University of California, Los Angeles
UCSB - University of California, Santa Barbara
UDP - User Datagram Protocol
VLAN - Virtual Local Area Network
WAN - Wide Area Network
WLAN - Wireless Local Area Network
WLC - Weighted Least-Connection
WRR - Weighted Round Robin
SUMÁRIO
INTRODUÇÃO .........................................................................................17
1 REDES DE COMPUTADORES............................................................20
1.1 MODELO COMPUTACIONAL ............................................................................. 21
1.2 TOPOLOGIAS DE REDES .................................................................................. 23
1.2.1 Redes Ponto-a-Ponto ....................................................................................... 23
1.2.2 Redes Cliente/Servidor..................................................................................... 25
1.3 TOPOLOGIAS DE CONEXÃO ............................................................................ 27
1.3.1 Topologia Totalmente Conectada..................................................................... 27
1.3.2 Topologia em Malha ......................................................................................... 27
1.3.3 Topologia em Anel............................................................................................ 28
1.3.4 Topologia em Barramento ................................................................................ 29
1.3.5 Topologia em Estrela........................................................................................ 29
1.3.6 Topologia em Árvore ........................................................................................ 30
1.3.7 Topologia Sem Fio ........................................................................................... 31
1.3.8 Topologia Híbrida ou Mista............................................................................... 31
1.4 MODELO DE REFERÊNCIA OSI ........................................................................ 31
1.5 MODELO DE REFERÊNCIA TCP/IP .................................................................. 33
1.5.1 Camada Física ................................................................................................. 34
1.5.2 Camada Inter-Redes ........................................................................................ 35
1.5.3 Camada de Transporte..................................................................................... 35
1.5.4 Camada de Aplicação ...................................................................................... 36
2 BALACEAMENTO DE CARGA E ALTA DISPONIBILIDADE EM
SERVIDORES..........................................................................................38
2.1 CLUSTER............................................................................................................ 38
2.1.1 Aplicações para Clusters .................................................................................. 38
2.1.2 Tipos de Clusters.............................................................................................. 39
2.2 ALTA DISPONIBILIDADE ................................................................................... 39
2.3 BALACEAMENTO DE CARGA ........................................................................... 40
2.4 LINUX VIRTUAL SERVER (LVS) ........................................................................ 41
2.5 LVS VIA NAT ....................................................................................................... 44
2.6 LVS VIA IP TUNNELING ..................................................................................... 45
2.7 LVS VIA DIRECT ROUTING ............................................................................... 46
2.8 ALGORITMOS DE ESCALONAMENTO ............................................................. 47
2.8.1 Round-Robin (RR) ............................................................................................ 48
2.8.2 Weighted Round-Robin (WRR) ....................................................................... 48
2.8.3 Destination hash (DH) ...................................................................................... 48
2.8.4 Least-Connection (LC) ..................................................................................... 48
2.8.5 Weighted Least-Connection (WLC) .................................................................. 49
2.8.6 Shortest Expected Delay (SED) ....................................................................... 49
2.8.7 Never Queue (NQ) ........................................................................................... 50
2.8.8 Locality-Based Least-Connection (LBLC) ......................................................... 50
2.8.9 Locality-Based Least-Connection With Replication Scheduling (LBLCR)......... 50
2.9 FERRAMENTAS EXISTENTES .......................................................................... 51
2.9.1 HeartBeat ......................................................................................................... 51
2.9.2 Piranha ............................................................................................................. 51
2.9.3 KeepAlived ....................................................................................................... 52
2.9.4 Ultra Monkey .................................................................................................... 52
3 Balanceamento de Carga de servidores com LVS ..............................53
3.1 CONFIGURAÇÕES DOS SERVIDORES WEB .................................................. 54
3.1.1 Configurações de Rede .................................................................................... 54
3.1.2 Instalação e Configuração do Apache .............................................................. 57
3.1.3 Instalação e Configuração do Monitorix ........................................................... 58
3.1.4 Instalação e Configuração do Arptables ........................................................... 59
3.2 CONFIGURAÇÕES DOS SERVIDORES LVS .................................................... 60
3.2.1 Configurando o Cluster de Balanceamento Via Software Piranha ................... 63
3.2.1.1 Definindo IP para os Servidores LVS Primário e Secundário ........................ 64
3.2.1.2 Adicionar um Servidor Virtual ao Cluster LVS ............................................... 65
3.2.1.3 Adicionar e Ativar os Servidores Reais ......................................................... 67
3.2.2 Configuração dos Servidores LVS Via Arquivo ................................................ 68
3.3 TESTE DE FUNCIONAMENTO DA ESTRUTURA.............................................. 69
4 ANÁLISE DO FUNCIONAMENTO E DESEMPENHO DO LVS...........70
4.1 METODOLOGIA DE TESTES ............................................................................. 70
4.2 TESTES COM O ALGORITMO ROUND-ROBIN (RR) ........................................ 71
4.3 TESTES COM O ALGORITMO WEIGHTED ROUND ROBIN (WRR) ................ 74
4.4 RESULTADOS DOS TESTES COM DEMAIS ALGORITMOS ............................ 78
CONCLUSÃO ..........................................................................................81
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................83
17
INTRODUÇÃO
Cada vez mais empresas dependem da tecnologia da informação para
conseguir manter, promover e expandir seus negócios. Com o crescimento da
internet vem se tornando imprescindível para todos os tipos de empresas o uso de
um servidor confiável e sem falhas e com uma boa relação custo-benefício para dar
sustentabilidade e segurança aos dados.
Problemas frequentemente encontrados na web, tais como “Página não
encontrada”, “Tente novamente mais tarde”, “Serviço indisponível”; não só irritam o
usuário como o impossibilita de realizar suas tarefas, causando prejuízo tanto para a
empresa que disponibiliza o site quanto para o usuário.
Alguns sites possuem tecnologias para suportar grandes números de
acessos, como por exemplo, o site da Receita Federal que é conhecido por lidar de
forma eficiente com situações de excesso de tráfego. Em 2005, foram entregues
mais de 20 milhões de declarações do Imposto de Renda, sendo que 98% das
declarações de IR Pessoa Física foram realizadas pela Internet. (AZEREDO, 2006)
Entretanto, alguns sites ainda sofrem com o excesso de tráfego, como o site
de compra coletiva Groupon, uma das principais empresas do mundo neste
segmento do e-commerce e que apresentou desempenho abaixo do normal em sua
infraestrutura de servidores. De acordo com um estudo da WatchMouse, uma
empresa que realiza pesquisas sobre a internet, revelou que o gigante coletivo ficou
26 horas inoperante entre os dias 22 novembro a 22 dezembro de 2010, impedindo
inúmeros usuários de comprarem em seu site. (E-COMMERCE, 2010)
Outro exemplo de indisponibilidade que gerou transtornos e prejuízos
aconteceu com o site do jornal on-line Africanidade.com em 25/04/2008, o servidor
no qual o site estava hospedado, sofreu um grave problema técnico que provocou
uma indisponibilidade no acesso ao site. Este problema técnico foi suficientemente
grave ao causar perda de dados, o que obrigou a administração do jornal on-line a
tomar a decisão de transferir os dados que se conseguiu recuperar para outro
servidor e para outra empresa de hospedagem. (AFRICANIDADE, 2008)
Como o objetivo de visar soluções eficazes para os problemas descritos
acima, este trabalho tem como objetivo o estudo de técnicas para criar um serviço
web confiável e protegido contra erros e falhas que possam acontecer, sejam elas
18
de software ou de hardware. Isso é possível por meio de um balanceamento de
carga, que faz com que um servidor web não sobrecarregue e torne o serviço
indisponível ou, em caso de falha de um servidor, automaticamente outra máquina
assume o seu lugar e faz com que o sistema não pare de funcionar.
A tecnologia base usada para o desenvolvimento do trabalho foi o Linux
Virtual Server (LVS), que é um projeto open source e que tem como principal
objetivo a criação de clusters com balanceamento de carga para aplicações críticas.
Dentre suas características, pode-se mencionar sua redundância de serviços,
desempenho e escalabilidade flexível.
Para implantação de um serviço seguro e sem falhas é indispensável o uso
da redundância como método para lidar com falhas em componentes confiáveis.
Para que este método possa funcionar corretamente, um sistema tem que ter
sempre um segundo servidor com as mesmas características do servidor principal, o
qual assume as funções em caso de falha do servidor principal.
A redundância fornece total segurança para o sistema como, por exemplo,
caso um servidor precise ser removido para atualização ou manutenção, ele pode
ser retirado e recolocado de volta, sem interrupção do serviço ao cliente.
O LVS possui uma arquitetura totalmente transparente para o usuário final, na
qual o cliente parece estar conectado a um servidor real. Porém é o LVS que realiza
as requisições no lugar do cliente, assim, escolhe um entre dois ou mais servidores
web, caso um desses servidores pare de responder, o LVS redireciona as
requisições para os outros servidores Web que estão ativos, e fica transparente para
o usuário.
O fato da arquitetura ser transparente torna-se um fator de extrema
importância, pois, a partir dele, um conjunto de servidores parece ser um servidor
único, faz com que os usuários não saibam quantos servidores têm por trás do LVS,
e tem-se apenas acesso as suas aplicações.
Basicamente a transparência tem como objetivo esconder o fato de seus
recursos e processos estarem distribuídos através de diversas máquinas.
No que se refere à organização, este trabalho está dividido da seguinte forma:
o primeiro capítulo descreve alguns conceitos importantes sobre redes de
computadores, tais como topologia, protocolos e sua arquitetura; no segundo é feito
um estudo sobre o conceito de alta disponibilidade, balanceamento de carga, a
tecnologia de cluster e sobre LVS; o terceiro capítulo é demostrado um tutorial sobre
19
a instalação e configuração do software de balanceamento de carga, bem como
outros utilitários necessários para a topologia de servidores utilizada neste trabalho;
o quarto capítulo descreve os testes e resultados feitos com os diferentes algoritmos
de balanceamento de carga, e por fim, têm-se as conclusões finais sobre o trabalho.
20
1 REDES DE COMPUTADORES
Segundo Torres (2009), as redes de computadores surgiram da necessidade
da troca de informações de dados que estão fisicamente localizados longe do
usuário, ele afirma que é impossível não pensar em redes de computadores, quando
o assunto é informática. Na Internet, essa troca de informações armazenadas
remotamente vai ao extremo quando acessa dados em locais remotos, e o local
onde geralmente estão armazenadas, não tem a menor importância para o usuário.
Para Tanenbaum (1997), rede de computadores é um conjunto de
computadores autônomos interconectados, trocando informações entre si, através
de um fio de cobre, fibras ópticas, rádio, micro-ondas, satélites de comunicação,
entre outros.
Um exemplo de rede mundialmente difundida é a Internet, que possui
milhares de computadores interconectados trocando as mais diversas informações,
tais como e-mail, arquivos, páginas pessoais e corporativas.
A Internet iniciou-se no final da década de 1960, quanto a Agência de
Projetos de Pesquisas Avançadas do Departamento de Defesa dos Estados Unidos
da América – Advanced Reserch Projects Agency (ARPA), mais tarde chamada de
DARPA – começou a consolidar uma rede experimental de computadores de longa
distância, chamada de ARPANET, que se espalhou pelos Estados Unidos. O
objetivo original da ARPANET era permitir aos fornecedores do governo compartilhar
caros e também escassos recursos computacionais.
Inicialmente a ARPANET permitia que os laboratórios de pesquisa dos
Estados Unidos da América (EUA) (Universidade da Califórnia – UCLA – em Los
Angeles, Universidade de Utah, em Salt Lake City, Universidade da Califórnia em
Santa Barbara – UCSB, e Stanford Research Institute – SRI – em Stanford)
trocassem informações entre si. Desde o início, entretanto, usuários da ARPANET
também usavam a rede para colaboração. Essa colaboração abrangia desde
compartilhamento de arquivos e programas, e troca de mensagens via correio
eletrônico (e-mail) até desenvolvimento conjunto de pesquisa usando computadores
remotos. (TORRES, 2001)
Segundo Torres (2009), atualmente, as redes de computadores podem ser
classificadas de acordo com o tamanho da área geográfica que elas abrangem.
21
Local Area Network (LAN) é o nome dado às redes locais mais comuns, sua
abrangência pode chegar até ao espaço de uma sala ou mesmo de um prédio
inteiro, pois se ultrapassar essa demanda pertencerá á outra classificação. O padrão
de mais comum deste tipo de rede chama-se Ethernet ou IEEE 802.3.
Wireless Local Area Network (WLAN) o que diferencia esta da LAN é a
ausência de cabos, utilizam transmissores de radiofrequência. A arquitetura mais
popular deste tipo de rede chama-se Wi-Fi ou IEEE 802.11.
Campus Area Network (CAN) também chamada de rede de campo é uma
rede maior que a local, com a abrangência maior que um prédio, possui interligação
de pelo menos duas redes locais. Exemplo disso são os hospitais, universidades e
grandes empresas.
Metropolitan Area Network (MAN) é uma rede metropolitana, podendo
abranger até mesmo uma cidade inteira, interligando redes locais e de campo, que
geralmente são realizadas por concessionárias de telecomunicações (Embratel, Oi,
Vivo etc.).
Wide Area Network (WAN) também chamada de rede de longa distância
abrange uma área maior que uma cidade, atuando na esfera mundial, sua melhor
definição é a internet.
Virtual Local Area Network (VLAN) neste caso pode-se configurar uma rede
de computadores distante fisicamente, que mesmo assim fazem parte de uma rede
local, para que possam acessar e compartilhar recursos.
Internet que é rede mundial de computadores e que interliga milhões de
computadores em todo o mundo, de vários tipos e tamanhos, marcas e modelos e
com diferentes sistemas operacionais.
A Intranet, rede privada que usa o mesmo modelo da internet, navega por
meio de um navegador web em um site interno da empresa, disponível para
funcionários.
Extranet é uma intranet que permite acesso remoto, através de um modem ou
mesmo por meio da Internet.
1.1 MODELO COMPUTACIONAL
Para Torres (2009) a classificação das redes de computadores varia conforme
22
o processamento dos dados e pode ser de processamento centralizado,
processamento
distribuído
ou
processamento
cooperativo.
A
computação
centralizada foi o primeiro modelo de redes de computadores, possuíam uma grande
capacidade de processamento sendo acessado através de terminais sem qualquer
poder de processamento (terminais burros), que apenas nos dão dispositivos de
entrada (teclado e monitor) para conectarmos ao computador central conforme a
figura 1.1.
Figura 1. 1 - Modelo de computação centralizada
Fonte: Farias, 2006, Adaptado pelos autores
A computação cooperativa, segundo Torres (2009), é um tipo de computação
distribuída. Nela vários computadores executam a mesma tarefa. Quando são
utilizados computadores comuns conectados à internet, esse tipo de computação
passa a chamar de computação em nuvem, mas se os computadores forem
dedicados ela passa a chamar computação em grade.
Na computação distribuída cada máquina tem seu próprio processador, logo,
tem poder de processamento. Elas podem ser classificadas como cliente/servidor,
ponto-a-ponto, baseada em servidor e front-end/back-end. A figura 1.2 demostra um
exemplo de computação distribuída.
Torres (2009) afirma que as redes baseadas em servidores são semelhantes
23
às de computação centralizada. A diferença é que na computação centralizada os
terminais não possuem qualquer tipo de processamento, diferente das baseadas em
servidor, nas quais os computadores não são terminais burros e sim usados como
clientes, portanto capazes de realizar processamento de dados.
Redes Front-End/Back-End são utilizadas na comunicação entre servidores
(frontal e traseiro). O modelo mais comum é o servidor web (front-end) e o servidor
de banco de dados (back-end). Assim quando é feita a solicitação de uma página
para o servidor web ele busca os dados no servidor de banco e então envia ao
usuário. O servidor web é responsável pela formatação e apresentação dos dados.
(TORRES, 2009)
Figura 1. 2 - Modelo de computação distribuída
Fonte: Farias, 2006, Adaptado pelos autores
1.2 TOPOLOGIAS DE REDES
Topologia de redes é o canal no qual o meio de rede está conectado e que
pode ser descrito fisicamente ou logicamente.
1.2.1 Redes Ponto-a-Ponto
As redes ponto-a-ponto possuem algumas características importantes que
devem ser lembradas. Elas são utilizadas em locais geograficamente menores, são
fáceis de serem implementadas, possuem baixo custo, o sistema de cabeamento é
24
simples, não necessitam de um administrador e não existem computadores
servidores. Porém possuem pouca segurança, exigem que os computadores sejam
independentes e instalados em um mesmo ambiente de trabalho e são de difícil
expansão. A Figura 1.3 mostra um exemplo de rede ponto-a-ponto. (TORRES, 2001)
Figura 1. 3 - Exemplo de uma rede ponto-a-ponto
Fonte: Torres, 2001, p.8
Na rede ponto-a-ponto, os computadores compartilham dados e periféricos
sem muita burocracia. Qualquer computador pode facilmente ler e escrever arquivos
armazenados em outros computadores da rede bem como utilizar periféricos que
estejam instalados em outros PC's. Obviamente tudo isso depende da configuração,
que é feita em cada computador individualmente. Ou seja, não há papel de um
computador “servidor” como nas redes cliente/servidor. (TORRES, 2001)
Os computadores presentes em uma rede ponto-a-ponto são computadores
“completos”, isto é, funcionam normalmente quando não estão ligados em rede,
tanto no que diz respeito ao hardware quanto ao software.
De acordo com Torres (2001), a grande vantagem das redes ponto-a-ponto é
a facilidade de instalação e de configuração, onde os próprios usuários podem
configurar manualmente quais serviços estarão disponíveis em seu computador.
Essa vantagem, entretanto, traz alguns inconvenientes como, por exemplo, a
vulnerabilidade em relação à segurança da rede.
As redes ponto-a-ponto são ideais para escritórios nos quais existem poucas
25
estações, podendo haver o controle dos arquivos, pois nesse tipo de rede todas as
estações conseguem ler e gravar informações em qualquer outra estação, sem
perder a integridade das informações. O correto é existir regras entre os usuários da
rede, definindo apenas uma estação para armazenamento das informações.
O
custo de implementação deste tipo de rede é baixo, pois não são necessários
servidores e outros recursos de infraestrutura, que são caros para pequenas
organizações. Não há grandes gastos com a administração da rede, pois somente
as próprias estações dos usuários são configuradas. Também não se gasta muito
com cabeamento, pois este tipo de rede é destinado a estruturas de pequeno porte,
não sendo necessários recursos como fibras ópticas ou pontos para acesso sem fio.
1.2.2 Redes Cliente/Servidor
Nesse tipo de rede existe a figura do servidor, geralmente um computador
dedicado a fornecer recursos aos usuários da rede. O servidor é um computador
especializado que executa apenas tarefas específicas como armazenar e
compartilhar dados, por exemplo. A utilização de Servidores traz vários benefícios
como segurança, disponibilidade e integridade das informações, além da otimização
de recursos. (TANENBAUM, 2003)
A configuração de uma rede cliente servidor e toda administração é feita de
forma centralizada, ou seja, as configurações estão no servidor. Desta forma é
possível executar processos diretamente no servidor, processos estes resultantes de
aplicativos executados nas estações, aumentando a organização e segurança da
rede.
O custo para a implementação desse tipo de rede depende muito das
necessidades da organização, pois essa rede poderá possuir vários servidores, cada
um com uma função específica. É necessário um administrador de redes para
configuração e manutenção dessa rede. Geralmente também são essenciais
investimentos maiores em infraestrutura como um centro de dados para alocar estes
servidores e cabeamento mais específico como fibras ópticas para interligação dos
servidores e outros dispositivos da rede. (TANENBAUM, 2003)
O desempenho dessa estrutura em relação a ponto-a-ponto, considerando um
servidor que atenda às necessidades, é maior, pois, as estações não ficam
responsáveis pelo processamento referente à rede, ou seja, o armazenamento de
26
arquivos ou o compartilhamento da Internet são de responsabilidade dos servidores.
Os servidores desse tipo de rede podem ser computadores simples ou
equipamentos sofisticados. A definição de qual utilizar depende das necessidades
da organização, dos recursos disponíveis e da necessidade de futura expansão dos
serviços disponibilizados. Nesse tipo de arquitetura é possível implementar bancos
de dados oferecendo serviços de armazenamento e disponibilidade de informações
para as demais estações, como mostra a Figura 1.4.
Figura 1. 4 - Exemplo de uma rede cliente/servidor
Fonte: Tanenbaum, 2003, p.4
No Quadro 1.1 podem ser observadas as principais diferenças existentes
entre os dois modelos descritos.
Quadro 1. 1 - Diferenças entre redes cliente/servidor e ponto-a-ponto
Cliente/Servidor
Ponto-a-Ponto
Serviço de diretório
Administração centralizada
Não tem serviço de diretório
Não tem administração
centralizada
Alta manutenção
Baixa manutenção
Implementação complexa
Simples implementação
Várias opções de segurança
Segurança fraca
Alto custo
Baixo custo
Fonte: Torres, 2009, p.13
27
1.3 TOPOLOGIAS DE CONEXÃO
Segundo o autor Torres (2009) as redes de computadores podem ser
conectadas das seguintes maneiras:
1.3.1 Topologia Totalmente Conectada
Neste modelo cada computador possui uma conexão individual para cada
outro computador, sendo assim ele oferece o maior nível de redundância, porque
caso a conexão seja interrompida é possível continuar a conexão entre eles
simplesmente mudando o caminho da conexão. É claro que neste caso o caminho
será mais longo.
A figura 1.5 a seguir mostra um exemplo deste tipo de topologia.
Figura 1. 5 - Topologia totalmente conectada
Fonte: Torres, 2009, p.21
1.3.2 Topologia em Malha
Ela é parecida com a anterior, mais usa menos conexões e alguns
computadores precisam passar por outros para acessar determinado destinatário.
Para alguns autores não á distinção entre estes dois tipos, eles consideram os dois
como rede em malha. A figura 1.6 mostra um modelo desta topologia.
28
Figura 1. 6 - Topologia em malha
Fonte: Torres, 2009, p.21
1.3.3 Topologia em Anel
De acordo com Torres (2009), cada computador possui dois cabos, um
conectado ao anterior e outro conectado ao mais próximo computador da rede.
Redes em anel são capazes de transmitir e receber dados em qualquer
direção, mas as configurações mais usuais são unidirecionais, de forma a tornar
menos sofisticado os protocolos de comunicação que asseguram a entrega da
mensagem corretamente e em sequencia ao destino, conforme é demostrado na
figura 1.7.
Figura 1. 7 - Topologia em anel
Fonte: Torres, 2009, p.22
29
1.3.4 Topologia em Barramento
Neste tipo de topologia há um elemento central ao quais todos os
computadores são conectados. Quando o elemento central é partido, a rede deixa
de funcionar. Este modelo é muito usado em redes Ethernet usando cabo coaxial ou
cabo de par trançado usando um periférico concentrador chamado hub.
Este tipo de rede também é conhecido como topologia linear e fica bastante
claro que nenhum micro pode usar o cabo enquanto uma comunicação está sendo
efetuada. A figura 1.8 mostra como micros são ligados fisicamente. (TORRES, 2009)
Figura 1. 8 - Topologia em barramento
Fonte: Torres, 2009, p.22
1.3.5 Topologia em Estrela
Redes do tipo estrela são aquelas em que os dispositivos de rede convergem
para um ponto central, ou seja, um concentrador.
Esse concentrador central é um hardware, que pode ser hub, switch ou
roteador.
Todos os equipamentos como computadores, impressoras de rede, pontos de
acesso sem fio, etc. Convergem para o ponto concentrador da rede e, havendo
problema nesse ponto da rede, toda a rede fica inoperante porque o concentrador é
o equipamento responsável para servir as informações aos demais computadores da
rede. Esse tipo de rede é mais eficiente e eficaz, porque, se existir uma interrupção
em uma das estações de trabalho, a rede não será comprometida.
30
Outra vantagem da topologia em estrela é a sua flexibilidade, e também o uso
de cabeamento estruturado, que permite melhor organização, controle e expansão
do cabeamento da rede. A figura 1.9 mostra um exemplo de ligação desta topologia.
Figura 1. 9 - Topologia em estrela
Fonte: Torres, 2009, p.23
1.3.6 Topologia em Árvore
É uma topologia também chamada estrela hierárquica e é feita ligando-se
redes estrelas junta. Esta é a topologia mais comum atualmente, ela utiliza mais
periféricos concentradores. A figura 1.10 demostra um exemplo de ligação.
Figura 1. 10 - Topologia em árvore
Fonte: Torres, 2009, p.23
31
1.3.7 Topologia Sem Fio
Como o próprio nome diz, ela permite que computadores se conectem a rede
sem a necessidade de uso de cabos. É necessário um equipamento chamado ponto
de acesso Wireless Access Point (WAP) para fazer a conexão entre os
computadores dotados de placa de rede sem fio e a rede física.
A figura 1.11 demostra um exemplo deste tipo de rede.
Figura 1. 11 - Topologia sem fio
Fonte: Torres, 2009, p.24
1.3.8 Topologia Híbrida ou Mista
São redes que usam mais de uma topologia descrita acima ao mesmo tempo.
1.4 MODELO DE REFERÊNCIA OSI
O modelo Open Systems Interconnection (OSI), proposto pela Organização
Internacional de Padronização, não é uma arquitetura de rede, pois não especifica
os serviços e os protocolos que devem ser usados em cada camada e sim informa o
que cada uma deve ser responsável. (TANENBAUM, 1997)
32
O modelo OSI descreve sete camadas, onde cada nova camada é criada
quando há necessidade de outra camada de abstração. As camadas referenciadas
devem executar funções bem definidas. Este modelo é tido como base das
arquiteturas já existentes e para o desenvolvimento de novas arquiteturas de redes,
sendo que nem sempre todas as camadas que o modelo propõe são
implementadas. Em seguida, uma breve descrição das camadas embasada na
literatura de Tanenbaum (1997) e Stallings (2005) será realizada, onde começa-se
pela camada mais inferior:
Camada Física: lida com as características de acesso ao meio físico, ou
seja, é a camada responsável pela transmissão dos bits em um meio de
comunicação. Esta camada é interconectada a outra camada física através de um
meio físico para que haja a comunicação, seja ele, metálico, de fibra ou
eletromagnético.
Camada de Enlace: faz a interface entre o bloco de dados e o meio físico.
Sua principal finalidade é dividir a informação recebida da camada superior (Rede)
em quadros (do inglês: frames) com tamanho permitido pelo meio físico, o que reduz
a perda dessas informações através de controle de fluxo, controle de erros e
sincronização.
Camada de Rede: provê às camadas superiores independência quanto à
tecnologia de transmissão utilizada. Responsável também por endereçamento lógico
e roteamento de pacotes, e por este motivo, é de fundamental importância para os
projetos de rede.
Camada de Transporte: realiza controle dos dados transmitidos e
proporciona confiabilidade, controle de fluxo, recuperação de dados perdidos,
transmissão e recepção simultânea (do inglês: full duplex).
Camada de Sessão: camada responsável pelo controle de conexões entre
aplicações como estabelecimento, gerenciamento e término de sessões entre as
partes envolvidas. Também é responsável pela gerência do tráfego, tokens (conjunto
de caracteres) e pela sincronização.
Camada de Apresentação: esta camada é responsável pela adoção de um
sistema padronizado de representação dos dados em alto nível, compressão e
codificação de dados.
Camada de Aplicação: serve de interface entre os usuários e as demais
camadas OSI, é onde ocorrem todas as trocas de informações úteis ao usuário.
33
O Quadro 1.2 exemplifica as camadas, serviços e exemplos de utilização
aplicados do modelo OSI, descrito anteriormente.
Quadro 1. 2 - Modelo de Referência OSI
Camadas
Serviços
Exemplos
7
Aplicação
Aplicação do Usuário
FTP, Web, Browser
6
Apresentação
Encriptação, compressão
ASCII, UniCode, jpg
5
Sessão
Controle, sincronismo
RPC, NetBios
4
Transporte
Recuperação de erro
TCP, UDP
3
Rede
Roteamento, conexão
IP, IPX
2
Enlace
Controle de erro de fluxo
FDDI, Frame Relay, PPP
1
Física
Interface de acesso ao meio
Conector, cabo
Fonte: Stallings, 2005, Adaptado pelos autores
1.5 MODELO DE REFERÊNCIA TCP/IP
Esse modelo baseia-se principalmente em um serviço de transporte orientado
à conexão fornecido pelo Transmission Control Protocol (TCP), e em um serviço de
rede não orientado à conexões (datagrama não confiável), fornecido pelo protocolo
Internet Protocol (IP). (TANENBAUM, 2003)
Diferente dos sistemas proprietários, o TCP/IP foi desenvolvido como padrão
aberto no qual qualquer um pudesse usar em uma grande escala de
interoperabilidade de sistemas. A ideia deste modelo surgiu no Departamento de
defesa Americano, que tinha como objetivo manter a comunicação entre as bases
militares em uma ocorrência de ataques ou catástrofes que afetassem os meios de
comunicação. (MENDES, 2007)
Os padrões da arquitetura TCP/IP não são elaborados por órgãos
internacionais de padronização, como a ISO ou a IEEE. O coro técnico que
coordena o desenvolvimento dos protocolos dessa arquitetura é um comitê
denominado Internet Activity Board (IAB). O IAB é formado por pesquisadores
seniores, tendo a maioria deles projetado e implementado os protocolos da
arquitetura internet. O IAB, na realidade, produz poucos documentos. Qualquer
34
pessoa pode projetar, documentar, implementar e testar um protocolo para
ser
usado na Internet. (SOARES, 1995)
Segundo Odom (2003), o TCP/IP possui uma série de protocolos menores: na
verdade, o próprio nome TCP/IP é uma combinação de dois desses protocolos: o
TCP e o IP. A arquitetura TCP/IP é composta por quatro camadas conforme é
demostrado na figura 1.12.
Figura 1. 12 - Camadas da arquitetura TCP/IP e respectivos protocolos
Fonte: Odom, 2003, Adaptado pelos autores
1.5.1 Camada Física
A camada de rede, ou física, é responsável por converter as tensões elétricas
recebidas pela placa de rede em bits 1 ou 0. Em seguida, esses bits são agrupados
em pacotes e entregues à camada superior que, por sua vez, continuará repassando
até chegar à camada de aplicação, na qual o conteúdo recebido será processado e
apresentado ao usuário. (MENDES, 2007)
Na arquitetura Internet (TCP/IP) não há restrições às redes que são
interligadas para formar a inter-rede. Para uma rede ser conectada ela deve apenas
possuir uma interface que a torne compatível com o protocolo IP. Essa função se
encontra mais especificamente no nível de interface da rede, que encaminha os
datagramas IP para os destinos específicos. Para realizar este encaminhamento os
endereços IP são traduzidos para os endereços de hardware dos dispositivos
conectados à rede. (SOARES, 1995)
35
1.5.2 Camada Inter-Redes
O nível inter-redes é responsável pela interligação de redes de comunicação.
Sua tarefa è permitir que os hosts enviem e recebam pacotes em qualquer rede e
garantir que estes pacotes trafegarão corretamente até seu destino. O roteamento
de pacotes é uma questão de grande importância neste nível, assim como o controle
de congestionamentos na rede. (TANENBAUM, 2003)
Estas mensagens podem chegar a uma ordem diferente daquela em que
foram enviadas, obrigando as camadas superiores a reorganizá-las, caso a entrega
em ordem seja desejável. (TANENBAUM, 2003)
A camada inter-rede define um formato de pacote oficial e o protocolo IP. O
pacote ou datagrama (Figura 1.13) utilizado pelo protocolo IP consiste em um
cabeçalho e um payload (pacotes de dados), sendo que o cabeçalho possui um
comprimento fixo de 20 bytes mais um comprimento variável. A tarefa da camada
inter-redes é entregar os pacotes IP onde são necessários. O roteamento é uma
questão de grande importância nessa camada, assim como a necessidade de evitar
congestionamentos. (TANENBAUM, 2003)
Figura 1. 13 - Datagrama do protocolo IP
Fonte: Tanenbaum, 2003, p.461
1.5.3 Camada de Transporte
O nível de transporte provê uma conexão entre a acamada de aplicação e os
36
serviços oferecidos pelas camadas mais baixas (física e inter-redes). Isso torna as
redes físicas transparentes para a camada de aplicação. A camada de transporte
trata também do controle de conexão, oferecendo serviços orientados à conexão e
serviços sem conexão. (FOROUZAN, 2008)
Dois protocolos fim-a-fim atuam nesta camada. O primeiro deles, o TCP, é um
protocolo orientado a conexão confiável que permite a entrega sem erros de um
fluxo de bytes, originado de um determinado computador, em qualquer outro
computador da inter-rede. Esse protocolo fragmenta o fluxo de bytes de entrada em
mensagens e encaminha cada uma delas para a camada inter-redes. No destino, O
TCP cuida também do controle de fluxo, impedindo que um transmissor rápido
sobrecarregue um receptor lento com um volume de mensagens maior do que ele
pode manipular. (TANEMBAUM, 2003)
O segundo protocolo, o User Datagram Protocol (UDP), é um protocolo de
conexão não confiável destinado a aplicações que não requerem controle de fluxo
nem a manutenção da sequência das mensagens enviadas. Ele é amplamente
usado em consultas e aplicações diretas do tipo cliente/servidor com solicitação e
resposta, nas quais a entrega é mais importante do que a entrega precisa, como
transmissão de dados de voz ou de vídeo. (TANEBAUM, 2003)
1.5.4 Camada de Aplicação
A camada de aplicação trata de protocolos de alto nível. No modelo TCP/IP
questões de representação, codificação e controle de diálogo foram tratados em
uma única camada. O TCP/IP combina todas as questões relacionadas a aplicações
e presume que esses dados estejam empacotados corretamente para a próxima
camada. (MENDES, 2007)
A camada de aplicação contém os protocolos de alto nível. Dentre eles estão
o protocolo de terminal virtual (Telnet), o File Transfer Protocol (FTP) e o protocolo
de correio eletrônico Simple Mail Transfer Protocol (SMTP). O protocolo de terminal
virtual permite que o usuário de um computador estabeleça login em uma máquina
remota e a utilize. O protocolo de transferência de arquivos permite mover dados
com eficiência de uma máquina para outra. Originalmente, o correio eletrônico era
um tipo de transferência de arquivos. Posteriormente um protocolo especializado foi
desenvolvido para essa função. Muitos outros protocolos foram incluídos com o
37
decorrer dos anos como o Domain Name System (DNS), que realiza o mapeamento
dos nomes de hosts para seus respectivos endereços de rede, o Network News
Transfer Protocol (NNTP), protocolo usado para mover novos artigos e o Hyper Text
Transfer Protocol (HTTP), utilizado para acessar páginas web, entre outros.
(TANEMBAUM, 2003)
Neste capítulo foram abordados aspectos gerais de rede de computadores,
suas topologias e protocolos. No próximo capítulo serão abordados assuntos
referentes à Alta Disponibilidade, Cluster, com ênfase em LVS.
38
2 BALACEAMENTO DE CARGA E ALTA DISPONIBILIDADE EM
SERVIDORES
Neste capítulo são abordados os conceitos relacionados a clusters, suas
aplicações
e
seus
tipos,
balanceamento
de
carga,
alta
disponibilidade,
escalabilidade computacional, estudo sobre a tecnologia do LVS, algoritmos de
escalonamento e algumas das ferramentas existentes que possibilitam a
implantação e funcionalidade do ambiente.
2.1 CLUSTER
De acordo com o autor Dantas (2002) Cluster é um sistema que compreende
um conjunto de computadores ou sistemas na qual trabalham de forma agregada
para executar aplicações ou desempenhar outras tarefas, produzindo a ilusão de um
recurso único. Esse conceito é denominado de transparência do sistema.
Ele foi desenvolvido para balancear servidores entre computadores, tem
como objetivo dividir certo processamento de dados com outras máquinas
conectadas na mesma rede para acelerar o processamento. (DANTAS, 2002)
2.1.1 Aplicações para Clusters
Os clusters podem ser utilizados para uma infinidade de aplicações.
Basicamente, para qualquer uma que demande processamento pesado. Como
exemplos de aplicações, destaca-se a previsão meteorológica (previsão do tempo e
condições climáticas), simulações geotérmicas (simulação de eventos no solo),
renderização de efeitos especiais (muito usado em filmes), simulações financeiras,
distribuição de carga, entre outras. (DANTAS, 2002)
Basicamente, qualquer tipo de aplicação crítica, ou seja, aplicações que não
podem ser interrompidas ou não podem perder dados (como os sistemas de bancos,
por exemplo), podem empregar as tecnologias de cluster, desde que devidamente
configurados para não serem sujeitas a falhas graves. Assim, o cluster deve contar
com nobreaks ou geradores que assegurem o funcionamento do sistema mesmo
nos casos de queda de energia, além de meios de manutenção e detecção e falhas
eficientes. (DANTAS, 2002)
39
2.1.2 Tipos de Clusters
Segundo Pitanga (2003) Existem vários tipos de clusters, aqui estão descritos
os tipos de clusters mais utilizados:
Cluster de alta disponibilidade: os sistemas deste modelo conseguem
permanecer ativos por um extenso período de tempo e em plena condição de uso de
forma contínua através do uso da redundância implícita ao sistema, além disso,
conseguem detectar erros se resguardando de possíveis falhas, esse tipo de cluster
é muito empregado para base de dados de missões críticas, para os correios,
servidores de arquivos e aplicações.
Cluster de alto desempenho: esse tipo de cluster tem como papel permitir que
a união de vários computadores comuns consiga-se um alto poder de
processamento.
Cluster para balanceamento de carga: este modelo tem como papel distribuir
controladamente o processamento. Seu mecanismo de redundância exige constante
monitoramento, se um nó falhar as requisições são redistribuídas entre os nós
disponíveis no momento. São utilizados, por exemplo, em cluster de servidores de
web.
2.2 ALTA DISPONIBILIDADE
A Alta Disponibilidade está vinculada diretamente a crescente dependência
dos serviços oferecidos pelos computadores. Atualmente, várias empresas contam
com os recursos computacionais para fornecerem os seus serviços, como sistemas
bancários, sites web, e-business, banco de dados, entre outros.
Um cluster de Alta Disponibilidade tem como finalidade manter os serviços
prestados, por um sistema computacional, disponíveis a todo o momento, mesmo
em caso de falhas. Isso é obtido através da criação de réplicas dos serviços e
servidores, onde os computadores atuam como um único sistema. Cada computador
monitora os outros por meio de software, e no caso de ocorrer uma falha um deles
assume os serviços daquele que ficou indisponível. (PITANGA, 2003)
Segundo Pitanga (2003) A Alta disponibilidade pode ser classificada como:
Disponibilidade
básica:
Empregada
em
máquinas
comuns,
sem
mecanismos especiais, garantindo disponibilidade de 99% a 99,9%. Isto equivale a
40
dizer que em um ano a máquina pode ficar indisponível por um período de 9 horas a
quatro dias.
Alta
disponibilidade:
São
mecanismos
especializados
que
contém
mecanismos de detecção, recuperação e mascaramento de falhas elevando a
disponibilidade do sistema. Nesse modelo, as máquinas têm uma disponibilidade de
99,99% a 99,999%, podendo ficar indisponível por um período de 5 horas até uma
hora em um ano de operação.
Disponibilidade contínua: teoricamente ideal chegando muito próximo de
100%, neste modelo o tempo de inoperância do sistema é insignificante, todas as
paradas planejadas ou não são mascaradas, e o sistema está sempre disponível,
mas sempre existe a possibilidade do sistema parar.
A figura 2.1 demostrada a seguir apresenta
um modelo de alta
disponibilidade, na qual os Servidores são precisamente réplicas, tanto de hardware
como de software. O Servidor da direita, através do esquema de monitoramento,
detecta a indisponibilidade do Servidor da esquerda, e logo assume o posto para
manter o serviço disponível.
Figura 2. 1 - Esquema de Alta Disponibilidade
Fonte: Pitanga, 2003, Adaptado pelos Autores
2.3 BALACEAMENTO DE CARGA
Esta solução tem como finalidade manter o equilíbrio de carga entre vários
servidores, assegurando assim a disponibilidade do serviço em momentos de
41
elevados acessos. A necessidade desta implementação é devido a elevada
quantidade de tráfego nos servidores que prestam serviço em uma rede, pois, um
dos maiores problemas enfrentados na Internet são os excessivos acessos quando
se tem apenas um servidor.
De acordo com Pitanga (2003) O sistema de cluster baseado em
balanceamento de carga consiste em integrar seus computadores para que todas as
requisições provenientes dos clientes sejam distribuídas de forma equilibrada entre
os servidores. A tarefa principal é redirecionar essas requisições de entrada por
meio de um elemento que fará o balanceamento entre os servidores e os usuários.
Consequentemente, nessa estrutura teriam-se múltiplos servidores, mas que
parecem ser apenas um para o cliente.
A figura 2.2 mostra um tipo de cluster que é especialmente empregado em
serviços de comércio eletrônico e provedores de Internet, que precisam resolver
diferenças de carga provenientes de múltiplas requisições de entrada em tempo real.
Figura 2. 2 - Exemplo de cluster de balanceamento de carga
Fonte: Pitanga, 2003, Adaptado pelos Autores
2.4 LINUX VIRTUAL SERVER (LVS)
O LVS é um projeto Open Source que tem como principal objetivo a
construção de sistemas com alta disponibilidade e profundamente escaláveis, a
42
partir do uso conjunto de vários servidores. A arquitetura é totalmente imperceptível
para o usuário final e os serviços são providos por um conjunto de máquinas e
acessados por meio de um único servidor. O LVS pode oferecer serviços de maior
capacidade, desempenho e serviços redundantes em relação aos serviços
disponíveis em servidores únicos. (GOVERNO ELETRÔNICO, 2006)
Dentre suas características, é importante citar seu desempenho e
escalabilidade flexível. O LVS é um sistema de cluster totalmente transparente para
seu usuário final, pois mesmo que tenha 20 nós em seu cluster, seu usuário
interagirá com apenas um endereço de entrada.
Para o funcionamento do LVS são necessários dois tipos de máquinas:
Load Balancer: este é o host responsável por receber as requisições vindas
dos clientes e transmiti-las aos servidores reais do cluster, lógico que este é o ponto
vulnerável do cluster. Mas se o ponto de entrada é apenas uma máquina, isto é uma
falha, pois se esta máquina falhar, consecutivamente o cluster também falhará,
porém pode-se usar ferramentas como o HeartBeat para monitorar e criar um
"espelho" deste Servidor de Load Balancer para se caso ele falhar, a máquina
espelhada assumir seu lugar automaticamente.
Servidores reais: são os servidores do cluster que detêm os serviços
oferecidos pelo cluster aos clientes. Para um cluster é necessário que exista no
mínimo dois servidores reais. (GOVERNO ELETRÔNICO, 2006)
O LVS é como um roteador da camada quatro do modelo OSI. A estrutura do
cliente-servidor continua preservada, onde cada cliente pensa que está diretamente
conectado a um servidor real e este pensa que está conectado diretamente a um
cliente. Tanto o cliente como o servidor não percebem que as conexões sofrem a
intervenção do direcionador. Um servidor real do LVS não coopera e não sabe da
existência de outros servidores reais no LVS, um LVS não é um beowulf (Projeto de
cluster que utiliza computadores pessoais) e também não é um cluster, mas se
comporta como um agregador de serviços que possibilita o atendimento de uma
demanda grande em um serviço.
O código IPVS é responsável por possibilitar a criação do sistema LVS, é uma
coleção de modificações para kernel Linux, que combinadas com as capacidades de
roteamento e filtragem de pacotes de uma máquina Linux, transformam-na em um
roteador com características especiais, capaz de balancear sessões TCP e UDP
entre várias máquinas. Este roteador especial chamado Linux Director distribui a
43
carga de requisições de serviços entre os computadores que os proveem. Com isso,
o sistema constituído pela máquina Linux com o código IPVS e as outras máquinas
que hospedam os serviços é chamado Linux Virtual Server. (GOVERNO
ELETRÔNICO, 2006)
O sistema LVS não precisa de nenhuma modificação nos servidores reais ou
nos clientes. Estes por sua vez, enviam suas requisições apenas para uma máquina
não importando quantos servidores reais estejam provendo os serviços, que podem
ser os comuns HTTP e HTTPS, servidores de e-mail, bancos de dados, Concurrent
Version System (CVS), Secure Shell (SSH), ou seja, em geral todas as aplicações
TCP/IP. (GOVERNO ELETRÔNICO, 2006)
O LVS fornece, de maneira imperceptível e simples, um ambiente altamente
escalável de alta disponibilidade. Seu ponto único de falha é o Director, mas mesmo
assim, em conjunção com outras ferramentas como HeartBeat e Ldirectord, pode-se
construir um sistema de alta disponibilidade para o Director, aumentando ainda mais
sua confiabilidade e eliminando seu ponto único de falha.
A figura 2.3 demostra como funciona um servidor Linux Virtual Server.
Figura 2. 3 - Esquema geral de um Linux Virtual Server
Fonte: Elaborado pelos autores, 2014
O LVS pode ser implantado de três formas diferentes, como Virtual Server via
Network Address Translation (NAT), via IP Tunneling e via Direct Routing.
44
No LVS via NAT tem como vantagem a utilização de qualquer sistema
operacional nos servidores reais, mas tem como desvantagem a baixa capacidade
implantação de servidores reais, além de sua alta latência e seu menor desempenho
comparado aos métodos IP Tunneling e Direct Routing. (MACK, 2004)
O método IP Tunneling tem como vantagem seu alto desempenho, sua
capacidade de suportar um número maior de servidores reais (mais de 100), e a
possibilidade de implantar os servidores reais em uma rede diferente dos servidores
LVS. A desvantagem desse método é em relação aos sistemas operacionais dos
servidores reais, que devem suportar túneis. (MACK, 2004)
O método Direct Routing oferece alto desempenho, os servidores reais
podem utilizar a maioria dos sistemas operacionais, desde que a interface de
loopback não responda arp. Todos os servidores da estrutura devem estar no
mesmo segmento de rede. (MACK, 2004)
O quadro 2.1 demonstra as principais características dos métodos NAT, IP
Tunneling e Direct Routing.
Quadro 2. 1 - Métodos de implementação do LVS
Fonte: Elaborado pelos autores, 2014
2.5 LVS VIA NAT
Segundo Cota (2005), a superioridade do Linux Virtual Server via NAT está
em que os servidores reais podem executar qualquer sistema operacional que
45
suporta TCP/IP com endereços IP privados e apenas um endereço IP é necessário
para o Load Balancer.
A desvantagem deste tipo de cluster do LVS é a limitação da escalabilidade,
caso o número de servidores reais em seu cluster passe de 20 servidores. Caso
este número seja ultrapassado, o load balancer pode ser um gargalo em seu
sistema LVS, pois todos os pacotes que passam pelo load balancer têm que ser
reescritos para fazer o NAT. Isto é lógico, pois supondo que a média do tamanho
dos pacotes TCP que irão trafegar por seu load balancer seja de 563 bytes, o tempo
médio para reescrever este pacote é de 60us, em um processador Intel Pentium. O
throughput (capacidade total de um canal em processar e transmitir dados durante
um determinado período de tempo) do load balancer será de 8.93 Megabit por
Segundo (Mbps).
Ao assumir que o throughput dos servidores reais seja de 400 Kilobit por
Segundo (kbps), o load balancer pode gerenciar até no máximo 22 servidores reais.
Lógico que isso é baseado em suposições e projetado para ambientes realmente
enormes, com mais de 20 nós de cluster. A figura 2.4 demostra LVS via NAT.
Figura 2. 4 - LVS via NAT
Fonte: Elaborado pelos autores, 2014
2.6 LVS VIA IP TUNNELING
De acordo com Cota (2005), neste tipo de cluster o load balancer ao invés de
fazer a comunicação de entrada e saída, ele faz apenas um agendamento das
46
requisições, pois a resposta do servidor real é enviada diretamente ao usuário, sem
passar pelo load balancer. Desta maneira, o load balancer pode administrar até 100
servidores reais, sem gerar gargalos no sistema.
Este tipo de LVS é recomendado para implementação de sistemas de Proxy
(define os intermediários entre o usuário e seu servidor, tendo como função a
conexão do computador local com a rede externa) para a Internet altamente
disponível. Pois o load balancer encaminha as requisições dos clientes para os
servidores Proxy e estes respondem diretamente para os usuários.
Para que esta estrutura funcione, todos os servidores do cluster precisam ter
o IP Tunneling habilitado. E é aqui que teremos um problema, pois habilitar este IP
Tunneling pode ser simples para o Linux, mas talvez não seja se tiver servidores
reais com Solaris, por exemplo. Isto dificulta a utilização de servidores reais com
sistemas operacionais diferentes.
A figura 2.5 demostra um exemplo de LVS via IP Tunneling
Figura 2. 5 - LVS via IP Tunneling
Fonte: Elaborado pelos autores, 2014
2.7 LVS VIA DIRECT ROUTING
Como descrito por Cota (2005), no tipo de cluster via Direct Routing, o
servidor LVS só processa requisições de entrada, deixando os servidores reais
47
responder diretamente para os usuários, utilizando roteamento direto.
A única limitação para este tipo de LVS é que tanto o load balancer quanto os
servidores reais precisam ter uma interface de rede que esteja no mesmo segmento
ou Sub-Rede. A figura 2.6 exemplifica o LVS via Direct Routing.
Figura 2. 6 - LVS via Direct Routing
Fonte: Elaborado pelos autores, 2014
Estas três formas dependem de um algoritmo de escalonamento para realizar
o balanceamento de carga do LVS.
2.8 ALGORITMOS DE ESCALONAMENTO
Como descrito no Governo Eletrônico (2006), existem diversos algoritmos
utilizados para a implementação do LVS e seus métodos de escalonamento para o
balanceamento de carga. Os métodos de escalonamento controlam a maneira como
a carga é distribuída entre os nós que compõem o sistema. Quando o Director
recebe uma requisição de um cliente, é através dos algoritmos de escalonamento
que ele decide qual nó deverá tratá-la.
Existem métodos de escalonamento dinâmico que dão maior controle sobre a
carga de chegada, com pouco ou nenhum custo adicional em processamento. O
48
Director mantém uma lista do número de conexões ativas e inativas para cada nó do
cluster e usa esta informação para determinar qual nó irá receber a nova conexão.
2.8.1 Round-Robin (RR)
Através da leitura do Governo Eletrônico (2006), é possível afirmar que o
Director armazena uma lista com os endereços de cada servidor real, assim que
recebe uma conexão, ele a redireciona para um servidor dessa lista, onde uma
próxima conexão será enviada para o servidor seguinte e assim continua
percorrendo essa lista de forma circular atendendo todas as requisições. Todos os
servidores da lista são tratados de maneira igual, não importando quantas conexões
estão sendo manipuladas por um servidor específico, nem seu tempo de resposta
e/ou capacidades de processamento.
2.8.2 Weighted Round-Robin (WRR)
De acordo com a leitura do Governo Eletrônico (2006), cada nó do sistema
LVS possui um peso, baseado na quantidade de carga que ele pode processar. O
peso é então usado, em conjunto com o método Round-Robin, para selecionar o
próximo nó que será usado quando uma nova conexão chegar, sem levar em
consideração o número de conexões que ainda estão ativas, servidores reais com
pesos maiores terão prioridade no recebimento e quantidade de requisições, se
comparados com servidores reais com pesos menores.
2.8.3 Destination Hash (DH)
De acordo com o Governo Eletrônico (2006), neste método, o Director, envia
requisições de um mesmo endereço IP de origem para o mesmo servidor real no
sistema LVS, usando uma lista estática de endereços de destino. O método é útil
quando o servidor real é um servidor Proxy ou cache.
2.8.4 Least-Connection (LC)
Neste método conforme citado no Governo Eletrônico (2006), quando uma
49
nova conexão chega, o Director verifica o número de conexões ativas e inativas para
decidir para qual nó irá enviar a requisição.
Para realizar esta escolha, o Director multiplica o número de conexões ativas
do nó por 256 e adiciona ao resultado o número de conexões inativas resultando em
um overhead (processamento em excesso) para cada nó. O nó com menor
overhead receberá a conexão. Caso haja nós com mesmo overhead, o primeiro nó
encontrado na tabela do IPVS será selecionado.
2.8.5 Weighted Least-Connection (WLC)
De acordo com as conclusões do Governo Eletrônico (2006), este método
mescla o Least-Connection com um peso para cada nó, útil para ser usado com nós
de diferentes capacidades de processamento.
O Director define para qual nó uma requisição será enviada, calculando o
overhead, como no método anterior, dividindo este número pelo peso associado ao
nó. O nó com menor valor associado após esta operação receberá a conexão. Caso
haja nós com mesmo valor associado, o primeiro da tabela do IPVS será
selecionado.
2.8.6 Shortest Expected Delay (SED)
De acordo com o Governo Eletrônico (2006), pode-se considerar que este
método pode prover uma pequena melhoria em relação ao método WLC em
serviços que usam TCP e mantêm a conexão ativa enquanto o nó processa a
requisição. O cálculo do valor do overhead para o SED é feito adicionando-se 1 ao
número de conexões ativas, dividido pelo peso associado a cada nó. O nó com
menor overhead recebe a requisição.
Deve-se notar neste algoritmo:
• Ele não usa o número de conexões inativas enquanto determina o overhead
para cada nó;
• Ele adiciona 1 ao número de conexões ativas para antecipar como o
overhead irá parecer quando uma nova conexão for realizada;
• O algoritmo SED tenta minimizar o tempo de espera para cada trabalho até
sua finalização. O tempo de espera é (Ci+1) /Ui, sendo Ci o número de conexões do
50
servidor e Ui o peso fixado para este servidor;
• A diferença entre SED e WLC é que SED inclui a conexão que chega à
função de custo, incrementando 1. Ele apresenta melhor qualidade em grandes
sistemas heterogêneos, cujos pesos variam muito.
2.8.7 Never Queue (NQ)
De acordo com que é descrito no Governo Eletrônico (2006), este método
proporciona uma melhoria em relação ao SED, pois caso um nó não possua
conexões ativas ele ganhará uma nova requisição de serviço. Apesar do resultado
exposto no cálculo do SED podem ocorrer situações em que uma máquina que não
possua nenhuma conexão ativa apresente um overhead maior que outra que
possua.
2.8.8 Locality-Based Least-Connection (LBLC)
Segundo o Governo Eletrônico (2006), os Directors também podem direcionar
o tráfego de saída para um agregado de servidores Proxy transparentes (utilizado
em redes amplas sem interação com o usuário). Nesta configuração, os nós do
cluster são Proxy transparentes ou servidores de web cache (responsável por
procurar pela página web requisitada em seu cache e caso a possua, avalia sua
idade e a confronta com a sua data de validade estipulada pelo criador da página ou
segundo um conjunto de regras estipuladas pelo próprio servidor de web cache) que
estão entre os clientes e a Internet.
Quando o LBCL é usado, o Director tenta enviar todas as conexões de um
endereço IP particular para o mesmo servidor Proxy invisível. Ou seja, a primeira vez
que uma requisição chegar, o Director definirá um servidor real para atendê-la
usando uma versão um pouco modificada do método WLC e todas as requisições
subsequentes deste cliente continuarão a ser enviadas para o servidor escolhido.
2.8.9 Locality-Based Least-Connection With Replication Scheduling (LBLCR)
É semelhante ao LBLC, mas com uma melhoria, o Director contém um
mapeamento de um cliente para um agregado de servidores que podem atendê-lo,
51
se todos os nós do conjunto estiverem sobrecarregados, o Director seleciona um
servidor com menos conexões e o adiciona ao conjunto. Caso este conjunto não se
modifique em um intervalo de tempo específico, o servidor com maior carga será
excluído.
Além de algoritmos de escalonamento, existem ferramentas que podem ser
utilizadas em conjunto com o LVS para realizar o balanceamento de carga e alta
disponibilidade de um serviço.
2.9 FERRAMENTAS EXISTENTES
Para implementar uma estrutura de alta disponibilidade e balanceamento de
carga é necessário o uso de ferramentas que possibilitam a implantação, segurança
e funcionalidade do ambiente.
2.9.1 HeartBeat
De acordo com Governo Eletrônico (2006), o HeartBeat tem como função
criar um backup de um servidor, que pode utilizar como base o Load Balancer que é
o ponto frágil do cluster. Com um backup do load balancer, o heartbeat pode
monitorar via cabo Ethernet ou serial o servidor original e quando for verificado que o
serviço LVS falhou no load balancer, ele automaticamente ativa o backup, que
assume o lugar do load balancer até que um administrador possa corrigir o problema
no servidor original.
2.9.2 Piranha
Segundo Ludolf (2011), o Piranha é uma das ferramentas de clustering da
Red Hat Inc., que inclui o módulo IPVS do kernel (Gerencia os recursos do sistema
operacional e permite que os programas façam uso deles), uma tecnologia de
monitoração do cluster e uma interface web para configuração do cluster. A
tecnologia de monitoração do Piranha tem como propósito averiguar o status dos
servidores de balanceamento ativo e backup, e também verificar a disponibilidade
dos serviços nos servidores
componentes:
reais. O Piranha é constituído dos seguintes
52
• Código de kernel do IPVS;
• Daemon do LVS que gerencia a tabela de roteamento utilizando a
ferramenta “ipvsadm”;
• Daemon nanny, responsável por monitorar os servidores e serviços nos
servidores reais do cluster;
• Daemon pulse responsável por controlar os outros daemons e chavear o
LVS entre os Directors ativos e backup em caso de falha;
• Ferramenta Piranha GUI para gerenciar e administrar o ambiente do cluster.
2.9.3 KeepAlived
De acordo com KeepAlived (2012), KeepAlived é uma ferramenta que garante
uma segurança para a estrutura, e ele possui algumas funcionalidades nativas
interessantes como:
• Redundância de Directors, ou seja, se o mestre falhar, o slave vai assumir;
• Segurança dos servidores reais, ou seja, se um servidor real deixar de
responder por um serviço, ele será automaticamente removido do ambiente;
• Aviso constante, caso aconteça alguma falha no ambiente, o usuário poderá
ser notificado por e-mail.
2.9.4 Ultra Monkey
É um projeto criado para fornecer serviços de alta disponibilidade e de
balanceamento de carga, utilizando o sistema operacional Linux para prover uma
solução flexível que pode ser usada para diversas tarefas. Embora funcione sobre
Linux, o software Ultra Monkey fornece clustering para qualquer serviço, de uma
forma virtual, desde que executado num sistema operacional que possa comunicar
usando TCP ou UDP. (ULTRA MONKEY, 2005)
53
3 BALANCEAMENTO DE CARGA DE SERVIDORES COM LVS
Este capítulo mostra uma implementação de balanceamento de carga de
servidores com LVS (Linux Virtual Server) de alta disponibilidade. O método LVS
escolhido foi o Direct Routing, conforme descrito no capítulo anterior.
Para tanto, foi criada uma infraestrutura de testes com máquinas virtuais
conforme mostrado na figura 3.1, e é utilizado o software de virtualização Virtual
Box. Foram criadas ao todo seis máquinas virtuais, sendo três Servidores Web
(servidores que detêm os serviços oferecidos pelo cluster aos clientes), e dois
Servidores LVS (responsáveis por receber as requisições vindas dos usuários finais
e transmiti-las aos servidores do cluster, realizando o balanceamento), e uma para
efetuar requisições.
Em todas as máquinas virtuais da estrutura, foi utilizado o sistema operacional
PUIAS/Springdale Linux 6.4. Tal distribuição foi escolhida por sua compatibilidade
com os softwares necessários para implementação do LVS, o que não ocorreu com
outras distribuições como Debian, Ubuntu Server e OpenSuse, também testadas.
Figura 3. 1 - Arquitetura LVS
Fonte: Elaborado pelos autores, 2014
54
O funcionamento da arquitetura implementada da estrutura será da seguinte
maneira:
a) A máquina cliente, através de um script php, fará requisições de páginas web;
b) Tais requisições serão recebidas pelo servidor LVS primário, o qual direciona o
pedido para um dos três servidores web;
c) O servidor web escolhido recebe o pedido de página e responde ao cliente.
A escolha do servidor web para o qual o pedido será direcionado é orientada
pelo algoritmo de escalonamento utilizado.
Neste sentido, foram testados oito algoritmos disponibilizados na ferramenta
Piranha, utilizada neste trabalho para gerenciar o LVS, e cujos resultados estão
descritos no próximo capítulo.
Cabe salientar que a arquitetura montada, implementa alta disponibilidade do
servidor LVS por meio de um segundo servidor, o qual assume o balanceamento em
casos de falha do servidor LVS primário, sem que haja uma grande interrupção no
sistema.
3.1 CONFIGURAÇÕES DOS SERVIDORES WEB
Os servidores web disponibilizam os serviços que serão oferecidos para os
clientes. Nestes servidores, além da instalação do Apache (software que implementa
o serviço web), também foi instalado a ferramenta Monitorix, utilizada para obter
relatórios referentes ao estado de vários componentes do servidor, tais como
utilização de CPU, memória, disco, rede; comportamento do servidor Apache quanto
ao número de requisições recebidas, consumo de memória e CPU.
Além da instalação destes softwares, também foi feita a instalação e
configuração do arptables, necessário para o perfeito funcionamento da estrutura do
LVS quando implementado via Direct Routing (conforme descrito na seção 2.7).
3.1.1 Configurações de Rede
Antes de iniciar as configurações, deve-se desabilitar o iptables e o SELinux
nos três servidores web, uma vez que na distribuição PUIAS/Springdale, utilizada
nos servidores web, o iptables e o SELinux vêm habilitados por padrão. O script 3.1
mostra os comandos necessários para desabilitar o iptables.
55
# service iptables save
# service iptables stop
# chkconfig iptables off
Script 3.1 - Comandos para desabilitar o iptables
Fonte: Elaborado pelos autores, 2014
O SELinux é desabilitado editando-se o arquivo “/etc/sysconfig/selinux” mudando a
diretiva SELinux de permissive para disabled (script 3.2).
# vi /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#
enforcing - SELinux security policy is enforced.
#
permissive - SELinux prints warnings instead
enforcing.
#
disabled - No SELinux policy is loaded.
SELINUX=disabled
of
# SELINUXTYPE= can take one of these two values:
#
targeted - Targeted processes are protected,
#
mls - Multi Level Security protection.
SELINUXTYPE=targeted
Script 3.2 - Desabilitando o SELinux
Fonte: Elaborado pelos Autores, 2014
Depois é necessário configurar as interfaces de rede dos três servidores web
editando os arquivos
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-lo:0 (Scripts 3.3, 3.4, 3.5) .
Servidor Web 1
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.101
NETMASK=255.255.255.0
# vi /etc/sysconfig/network-scripts/ifcfg-lo:0
DEVICE=lo:0
IPADDR=192.168.0.100
NETMASK=255.255.255.255
NETWORK=192.168.0.0
Script 3.3 - Configuração IP nas interfaces do servidor web 1
Fonte: Elaborado pelos autores, 2014
e
56
Servidor Web 2
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.102
NETMASK=255.255.255.0
# vi /etc/sysconfig/network-scripts/ifcfg-lo:0
DEVICE=lo:0
IPADDR=192.168.0.100
NETMASK=255.255.255.255
NETWORK=192.168.0.0
Script 3.4 - Configuração IP nas interfaces do servidor web 2
Fonte: Elaborado pelos autores, 2014
Servidor Web 3
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.103
NETMASK=255.255.255.0
# vi /etc/sysconfig/network-scripts/ifcfg-lo:0
DEVICE=lo:0
IPADDR=192.168.0.100
NETMASK=255.255.255.255
NETWORK=192.168.0.0
Script 3.5 Configuração IP nas interfaces do servidor web 3
Fonte: Elaborado pelos autores, 2014
É importante notar que a configuração da interface virtual lo:0, como
mostrado, é a mesma para os três servidores web. O IP aqui utilizado deve ser o
mesmo IP da interface virtual dos servidores LVS.
Depois de editado os arquivos, para efetivar as configurações são
necessários executar os comandos mostrados no script 3.6 nos três servidores.
# ifdown eth0
# ifup eth0
# ifup lo:0 && echo "ifup lo:0" >> /etc/rc.local
Script 3.6 - Ativação das configurações IP nas interfaces
Fonte: Elaborado pelos autores, 2014
57
3.1.2 Instalação e Configuração do Apache
O serviço web foi implementado através do software Apache. Aqui são
mostrados os procedimentos para sua instalação e configuração, os quais devem
ser feitos da mesma forma nos três servidores web (web1, web2 e web3).
O script 3.7 mostra os comandos para os procedimentos para:
a) Atualizar a base de informações do sistema de gerenciamento de pacotes do
Linux;
b) Instalar o pacote do Apache;
c) Configurar o serviço para inicializar automaticamente junto com a inicialização do
sistema;
d) Inicialização manual do Apache.
# yum upgrade –y
--------------------# yum install httpd
# chkconfig httpd on
# service httpd start
Script 3.7 - Procedimentos de instalação e configuração inicial do Apache
Fonte: Elaborado pelos autores, 2014
Já é possível testar o funcionamento do serviço web apontando um
navegador para os endereços IPs dos servidores web. O resultado é a página de
bem vindo padrão do Apache. Porém, como o Apache foi instalado nos três
servidores, deve ser criada uma página específica para identificar cada servidor.
Para tanto, é necessário criar um arquivo com o nome index.html dentro do
diretório /var/www/html/, cujo conteúdo será WEB 1 para identificar o servidor
web1, WEB 2 para identificar o servidor web2 e WEB 3 para o servidor web3.
O próximo procedimento é configurar o Apache para gerar informações mais
detalhadas que são coletadas e analisadas pela ferramenta Monitorix. Para tanto,
edite o arquivo httpd.conf, habilite a diretiva “ExtendedStatus On” e adicione as
configurações mostradas no script 3.8.
58
# vi /etc/httpd/conf/httpd.conf
ExtendedStatus On
<Location /server-status>
SetHandler server-status
Order allow,deny
Allow from all
</Location>
Script 3.8 - Configuração do Apache para gerar informações mais detalhadas
Fonte: Elaborado pelos autores, 2014
Após efetuar as modificações na configuração do Apache é necessário
reiniciá-lo.
3.1.3 Instalação e Configuração do Monitorix
Monitorix é uma ferramenta livre projetada para monitorar tanto a utilização
dos recursos de hardware (CPU, Memória, Rede e Disco.) da máquina, quanto a
utilização dos serviços (web e smtp.) ao executar em um sistema operacional Linux.
Tais informações são exibidas em gráficos com a sua própria interface web. Foi
escrito em linguagem Perl e licenciado sob os termos da General Public License
(GNU) conforme publicado pela Free Software Foundation (FSP).
Antes da instalação do Monitorix é preciso instalar alguns softwares
necessários para sua execução, denominados dependências, conforme mostrado no
script 3.9.
#
yum
install
MailTools
rrdtool
perl-MIME-Lite
rrdtool-perl
perl-CGI
perl-libwww-perl
perl-DBI
perl-
perl-XML-Simple
perl-Config-General wget
#wget
http://springdale.math.ias.edu/data/puias/unsupported/6/i386/
perl-HTTP-Server-Simple-0.42-1.puias6.noarch.rpm
# rpm -ivh perl-HTTP-Server-Simple-0.42-1.puias6.noarch.rpm
Script 3.9 - Instalação das dependências do Monitorix
Fonte: Elaborado pelos autores, 2014
59
Depois de instaladas as dependências, o Monitorix pode ser baixado e
instalado por meio dos comandos mostrados no script 3.10.
# wget http://www.monitorix.org/monitorix-3.3.0-1.noarch.rpm
# rpm -ivh monitorix-3.3.0-1.noarch.rpm
Script 3.10 - Comandos para download e instalação do Monitorix
Fonte: Elaborado pelos autores, 2014
O próximo passo é configurar o Monitorix para iniciar automaticamente
durante a inicialização do sistema. Isso é feito através do comando “chkconfig -level 35 monitorix on”, o qual deve ser executado com privilégio de root.
Para que o Monitorix processe as informações do funcionamento do Apache,
é
preciso
editar
seu
arquivo
de
configuração
com
o
comando
“vi
/etc/monitorix.conf” e modificar a linha “apache = n”, para “apache = y”.
Inicialize o Monitorix por meio do comando “service monitorix start”.
3.1.4 Instalação e Configuração do Arptables
O arptables se faz necessário devido ao método de implementação LVS
Direct Routing utilizado neste trabalho, uma vez que neste método o servidor LVS
precisa estar na mesma rede IP dos servidores web e os servidores web devem
responder diretamente aos clientes. O problema que surge é que tanto o servidor
LVS quanto os servidores web possuem o IP Virtual que é usado pelo cliente para
requisitar os serviços. Entretanto, somente o servidor LVS deve responder aos
pedidos ARP vindos do cliente (ou roteador da rede no caso do cliente estar fora da
rede), pois caso os servidores web também respondam, os pedidos não passam
pelo servidor LVS e, portanto, não acontece o balanceamento de carga.
Os comandos para instalação e configuração do arptables nos três servidores
web são mostrados no script 3.11. Como pode ser notado, após a instalação do
pacote pelo comando “yum”, aplicou-se uma regra para evitar que os servidores web
respondam a pedidos ARP para o IP Virtual, bem como uma regra para trocar o IP
de qualquer reposta ou pedido ARP que esteja saindo com o IP Virtual.
60
Servidor Web 1
# yum install arptables_jf -y
# arptables -A IN -d 192.168.0.100 -j DROP
# arptables -A OUT -d 192.168.0.100 -j mangle --mangle-ip-s
192.168.0.101
# /etc/init.d/arptables_jf save
Servidor Web 2
# yum install arptables_jf -y
# arptables -A IN -d 192.168.0.100 -j DROP
#arptables -A OUT -d 192.168.0.100 -j mangle --mangle-ip-s
192.168.0.102
# /etc/init.d/arptables_jf save
Servidor Web 3
# yum install arptables_jf -y
# arptables -A IN -d 192.168.0.100 -j DROP
# arptables -A OUT -d 192.168.0.100 -j mangle --mangle-ip-s
192.168.0.103
# /etc/init.d/arptables_jf save
Script 3.11 - Comandos instalação e configuração do arptables
Fonte: Elaborado pelos autores, 2014
3.2 CONFIGURAÇÕES DOS SERVIDORES LVS
Antes de iniciar as configurações, deve-se desabilitar o iptables e o SELinux
nos dois servidores LVS, uma vez que na distribuição PUIAS/Springdale, utilizada
nestes servidores, o iptables e o SELinux vêm habilitados por padrão. Estes
comandos são os mesmos executados para os servidores web (seção 3.1.1),
conforme mostrado na figura 3.2.
O SELinux é desabilitado editando-se o arquivo “/etc/sysconfig/selinux”
mudando SELinux de permissive para disabled (script 3.2, seção 3.1.1).
61
Depois é necessário configurar a interface de rede real (eth0) e a interface de
rede
virtual
(eth0:1)
dos
dois
servidores
LVS
editando
os
arquivos
/etc/sysconfig/network-scripts/ifcfg-eth0 e /etc/sysconfig/network-scripts/ifcfg-eth0:1
(scripts 3.12 e 3.13).
Servidor LVS 1
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.8
NETMASK=255.255.255.0
# vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0:1
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.100
NETMASK=255.255.255.0
Script 3.12 - Configuração IP nas interfaces do servidor LVS 1
Fonte: Elaborado pelos autores, 2014
Servidor LVS 2
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.9
NETMASK=255.255.255.0
# vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0:1
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.100
NETMASK=255.255.255.0
Script 3.13 - Configuração IP nas interfaces do servidor LVS 2
Fonte: Elaborado pelos autores, 2014
Depois de editado os arquivos, para efetivar as configurações são
necessários executar os comandos mostrados no script 3.14 nos dois servidores.
62
#
#
#
#
ifdown eth0
ifup eth0
ifdown eth0:1
ifup eth0:1
Script 3.14 - Ativação das configurações IP nas interfaces dos servidores LVS
Fonte: Elaborado pelos autores, 2014
Agora em ambos servidores (lvs1 e lvs2) deve-se atualizar a base de dados
do gerenciador de pacotes do sistema através do comando “yum upgrade -y”.
Finalizada a atualização é preciso instalar o pacote ipvsadm que gerencia a
distribuição das conexões aos servidores; e também instalar o pacote piranha que é
a interface de administração, através da qual se configura os servidores que fazem
parte do cluster de balanceamento. O script 3.15 resume estes procedimentos.
# yum upgrade -y
# yum install –y ipvsadm piranha
Script 3.15 - Instalação dos pacotes ipvsadm e piranha nos servidores LVS
Fonte: Elaborado pelos autores, 2014
Após instalar os pacotes, é necessário editar o arquivo sysctl.conf em ambos
os servidores LVS alterando ou acrescentando (caso não existam) as diretivas do
script 3.16, as quais são responsáveis por ativar o roteamento (forwarding) de
pacotes e ajustar as configurações do protocolo ARP, devido ao problema descrito
no início da seção 3.1.4.
# vi /etc/sysctl.conf
...
net.ipv4.ip_forward = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.eth0.arp_announce = 2
...
Script 3.16 - Configurações sysctl nos servidores LVS
Fonte: Elaborado pelos autores, 2014
O próximo passo é definir uma senha de acesso para a interface de
administração do software de gerenciamento LVS Piranha, bem como iniciar este
serviço (script 3.17).
63
# piranha-passwd
# service piranha-gui start
# chkconfig piranha on
Script 3.17 - Configuração e inicialização do software piranha
Fonte: Elaborado pelos autores, 2014
Iniciado o serviço, o acesso à interface do Piranha é feito por meio de um
navegador, digitando-se o endereço http://192.168.0.8:3636 para o servidor LVS1,
ou http://192.168.0.9:3636 para o servidor LVS2. A figura 3.2 mostra a interface de
login do Piranha.
Figura 3. 2 - Interface de Login do software Piranha
Fonte: Elaborado pelos autores, 2014
3.2.1 Configuração do Cluster de Balanceamento Via Software Piranha
Nesta etapa faz-se a construção do cluster de balanceamento, cujos
procedimentos são:
a) Definir o endereço IP do servidor LVS Primário e do servidor LVS Secundário;
b) Adicionar um Servidor Virtual ao cluster LVS;
c) Definir a política de balanceamento;
64
d) Adicionar e ativar os servidores reais.
As próximas seções detalham tais procedimentos
3.2.1.1 Definindo IP para os Servidores LVS Primário e Secundário
Este procedimento é realizado através da opção GLOBAL SETTINGS da
interface do software piranha (figura 3.3). Como pode ser visto, foi definido o IP
192.168.0.8 para o servidor LVS Primário e também foi definido o tipo de LVS como
sendo Direct Routing, clicando-se no botão rotulado como Direct Routing. É
importante notar que a mesma configuração deve ser feita no servidor LVS2.
Figura 3. 3 - Definição do IP primário e tipo de LVS no servidor LVS1 e LVS2
Fonte: Elaborado pelos autores, 2014
A definição do servidor LVS Secundário (backup) é feita através da opção
REDUNDANCY da interface do software Piranha (figura 3.4), bem como as
configurações de como o servidor secundário vai monitorar o status de
funcionamento do servidor LVS Primário, o que é feito via a ferramenta Heartbeat.
Esta ferramenta dispara pings para o servidor LVS primário em intervalos
65
determinados para monitorar seu status. A seguir uma breve descrição dos itens
que devem ser configurados:
Redundant server public IP: endereço IP LVS de backup (lvs2);
Heartbeat Interval (seconds): determina os segundos entre heartbeats, o
intervalo em que o servidor LVS secundário irá checar o status funcional do servidor
LVS primário (lvs1);
Assume dead after (seconds): Caso o LVS primário não responda após
este número de segundos, o LVS de backup irá assumir o serviço;
Heartbeat runs on port: porta na qual o heartbeat se comunica com o LVS
primário. Aporta padrão é a 539.
Figura 3. 4 - Definição do IP Secundário e configurações de monitoramento
Fonte: Elaborado pelos autores, 2014
3.2.1.2 Adicionar um Servidor Virtual ao Cluster LVS
Por meio do botão rotulado ADD da opção VIRTUAL SERVERS adiciona-se
um servidor Virtual ao cluster LVS, definindo-se o IP Virtual dos servidores LVS,
através do qual os clientes do cluster solicitarão acesso aos serviços dos servidores
66
reais, a interface virtual e o algoritmo (política) de escalonamento. A figura 3.5
mostra as configurações disponíveis, as quais são descritas a seguir:
Name: Nome do servidor virtual;
Application port: Porta da aplicação;
Virtual IP Address: Ip virtual;
Device: interface virtual;
Re-entry Time: Segundos no qual o servidor LVS ativo irá reintegrar um
servidor real ao cluster após alguma falha;
Service Timeout: intervalo de tempo em que o servidor não responde e será
retirado do cluster;
Quiesce Server: Habilita a limpeza espontânea das tabelas de roteamento
caso um host anteriormente retirado retorna ao status de ativo;
Load monitoring tool: Utilizado para monitorar os status dos hosts;
Scheduling: É o algoritmo que será empregado para determinar como será
executado o balanceamento das conexões entre os servidores reais.
Figura 3. 5 - Adicionando um servidor virtual ao cluster LVS
Fonte: Elaborado pelos autores, 2014
Para salvar estas configurações deve-se clicar no botão rotulado ACCEPT.
67
3.2.1.3 Adicionar e Ativar os Servidores Reais
Na mesma interface de adição do servidor virtual, clicando-se em REAL
SERVER, adicionam-se os servidores reais que responderão ao serviço. Neste
trabalho serão três servidores web com IPs: 192.168.0.101, 192.168.0.102 e
192.168.0.103. Após clicar no botão rotulado ADD da interface REAL SERVER,
configura-se o IP do Servidor web, a porta e o peso que será utilizado pelo algoritmo
de balanceamento de carga (figura 3.6). Para salvar a configuração deve clicar no
botão ACCEPT. Este mesmo procedimento deve ser feito para cada um dos
servidores reais do cluster.
Figura 3. 6 - Adicionando um servidor real ao cluster LVS
Fonte: Elaborado pelos autores, 2014
A figura 3.7 ilustra os três servidores reais adicionados e ativados neste
trabalho.
Figura 3. 7 – Servidores reais adicionados ao cluster LVS
Fonte: Elaborado pelos autores, 2014
68
3.2.2 Configuração dos Servidores LVS Via Arquivo
Nas seções anteriores foi mostrado como se configurar o cluster de
servidores LVS via a interface web da ferramenta de gerenciamento Piranha, a qual
facilita este procedimento. Todas estas configurações são armazenadas em um
arquivo texto localizado em /etc/sysconfig/ha/lvs.cf. É possível sua edição
direta sem utilizar a interface web. O script 3.18 mostra estas configurações.
serial_no = 164
primary = 192.168.0.8
service = lvs
rsh_command = ssh
backup_active = 1
backup = 192.168.0.9
heartbeat = 1
heartbeat_port = 539
keepalive = 2
deadtime = 10
network = direct
debug_level = NONE
monitor_links = 1
virtual server1 {
active = 1
address = 192.168.0.100 eth0:1
port = 80
send = "GET / HTTP/1.1\r\n\r\n"
expect = "HTTP"
load_monitor = uptime
scheduler = rr
protocol = tcp
timeout = 10
reentry = 180
quiesce_server = 0
server websrv1 {
address = 192.168.0.101
active = 1
weight = 1
}
server websrv2 {
address = 192.168.0.102
active = 1
weight = 1
}
server websrv3 {
address = 192.168.0.103
active = 1
weight = 1
}
}
Script 3.18 - Arquivo com as configurações do cluster LVS criado pelo Piranha
Fonte: Elaborado pelos autores, 2014
69
É possível, após a configuração do servidor LVS Primário, copiar este arquivo
para o servidor LVS Secundário, pois se evita erros de configuração, onde estas
devem ser idênticas em ambos os servidores.
3.3 TESTE DE FUNCIONAMENTO DA ESTRUTURA
Realizadas as configurações nos servidores LVS e servidores web reais, para
testar o funcionamento do balanceamento basta abrir um navegador e inserir o IP
virtual 192.168.0.100. A figura 3.8 mostra a resposta a um pedido, o qual foi
atendido pelo servidor web 3.
Figura 3. 8 - Teste de funcionamento da estrutura
Fonte: Elaborado pelos autores, 2014
Com a estrutura do LVS configurada e em funcionamento; o próximo capitulo
apresenta alguns testes que abordam e comparam os algoritmos de escalonamento
oferecidos por essa estrutura.
70
4 ANÁLISE DO FUNCIONAMENTO E DESEMPENHO DO LVS
Com o objetivo de demonstrar o funcionamento e desempenho da estrutura
LVS
proposta,
foram
realizados
testes
com
os
diversos
algoritmos
de
escalonamento disponíveis no LVS. O uso destes algoritmos foi configurado via o
software Piranha e informações de comportamento dos servidores web foram
coletadas por meio do software Monitorix. Este capítulo mostra a metodologia de
testes dos servidores web na estrutura LVS, bem como uma análise das
informações coletadas.
4.1 METODOLOGIA DE TESTES
O teste consiste em obter resultados em relação ao comportamento da
estrutura LVS aplicando-se cada um dos oito algoritmos de escalonamento
disponíveis pela ferramenta Piranha, que são: Round-Robin, Weighted RoundRobin, Least-Connection, Weighted Least-Connections, Locality-Based LeastConnection,
Locality-Based
Least-Connection
Scheduling
with
Replication,
Destination Hash e Source Hash. Cada teste com cada algoritmo teve uma duração
de 24 horas, onde se pode ter uma ideia do real funcionamento da estrutura com
cada algoritmo de escalonamento selecionado.
Para automatizar as requisições de páginas para os servidores web, foi
utilizado um script escrito em linguagem PHP (script 4.1) onde se executa em uma
máquina com a distribuição Linux Puias Linux.
<?php
$WEB1=0; $WEB2=0; $WEB3=0;
for($i=0;$i<35192000;$i++){
$f=fopen('http://192.168.0.100/index.html','rb');
$data='';
while(!feof($f))
$data.=fread($f,5);
fclose($f);
$data = str_replace("\r\n",'',trim($data));
print "|$data|\n";
if (strpos($data,'WEB 1')!==false) $WEB1++;
else if (strpos($data,'WEB 2')!==false) $WEB2++;
else if (strpos($data,'WEB 3')!==false) $WEB3++;
else print("\n Conteudo nao encontrado");
}
print "\nWEB 1: $WEB1 \nWEB 2: $WEB2 \nWEB 3: $WEB3\n";
?>
Script 4.1 - Script de requisição de página
Fonte: Elaborado pelos autores, 2014
71
Além da confecção do script, alguns preparativos são necessários para
executar o script nesta distribuição, tais como: desabilitar o iptables e o selinux;
configurar a interface de rede; instalar o pacote da linguagem PHP. O script 4.2
mostra os comandos relacionados com estes procedimentos.
#
#
#
#
service iptables save
service iptables stop
chkconfig iptables off
vi /etc/sysconfig/selinux
...
SELINUX=disabled
...
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.56
NETMASK=255.255.255.0
#
#
#
#
ifdown eth0
ifup eth0
yum upgrade -y
yum install php
Script 4.2 - Configurações na máquina de requisição de páginas
Fonte: Elaborado pelos autores, 2014
Devido à forma de coleta de dados da ferramenta Monitorix, a qual fornece
gráficos dos dados coletados durante o tempo de 24 horas, mensal e anual, foi
disparado um total de 35.192.000 requisições de página para atingir um tempo 24
horas de teste.
4.2 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.
72
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
73
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
74
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
75
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
76
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.
77
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
78
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:
79
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 garantirse 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
80
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.
81
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
82
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.
83
REFERÊNCIAS BIBLIOGRÁFICAS
AFRICANIDADE. Jornal on-Line Africanidade.com, 2008. Disponivel em:
<http://www.africanidade.com/articles/835/1/Indisponibilidade-do-siteAfricanidadecom/Paacutegina1.html>. Acesso em: 22 mar. 2014.
AZEREDO,
P.
Revista
TI.
Timaster,
2006.
Disponivel
<http://www.timaster.com.br/revista/materias/main_materia.asp?codigo=1098>.
Acesso em: 22 abr. 2014.
em:
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-inoperante26-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/guiade-cluster>. Acesso em: 24 setembro 2013.
KEEPALIVED. keepalived para Linux. keepalived, 2012.
<http://www.keepalived.org/>. Acesso em: 22 outubro 2013.
Disponivel
em:
LUDOLF, D. Piranha de Red Hat. Seja Livre, 2011. Disponivel
<http://sejalivre.org/piranha-de-red-hat/>. Acesso em: 26 setembro 2013.
em:
MACK, JOSEPH. LVS-Mini-Howto. Austintek.com, 2004. Disponivel em:
<http://www.austintek.com/LVS/LVS-HOWTO/mini-HOWTO/LVS-mini-HOWTOpt.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.
PITANGA, M. Computação em Cluster: O Estado da Arte da Computação. 1ª. ed.
84
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.