Balanceamento De Carga Em Servidor Web Linux
Cristian Martins Caetano
[email protected]
Faculdade De Tecnologia Senac - Pelotas
Tecnologia Em Redes De Computadores
Resumo. Esse artigo tem como objetivo demonstrar uma tecnologia para quem possui
pouca capacidade de hardware e processamento para hospedar um site que esta
aumentando suas requisições mês a mês. Ainda não quer investir em uma tecnologia mais
avançada foi estudada uma tecnologia em balanceamento de carga em cima de DNS
usando três computadores com pouca capacidade de hardware.
Abstract. This article aims to demonstrate a technology for those who have little capacity
and processing hardware to host a site that is increasing their requests every month. Still
not want to invest in better technology was studied technology in a load balancing over
DNS using three computers with low hardware capacity.
1. Introdução
O aumento da Internet vem causando diversos problemas de desempenho, incluindo baixos tempos
de resposta, congestionamento da rede e interrupção de serviços. Um dos maiores desafios para o
uso amplo da internet é a escalabilidade dos servidores, ou seja, sua capacidade em suportar uma
demanda crescente sem que a qualidade dos serviços providos seja afetada.
Uma medida frequente de sucesso de aplicações WWW e de comércio eletrônico em
particular é a capacidade do sítio de responder requisições prontamente. No caso de servidores de
comércio eletrônico, o sucesso do serviço é consequência da capacidade do servidor de capturar a
atenção de um grande número de usuários e mantê-los satisfeitos com a qualidade do serviço
provido. Por outro lado, um grande número de usuários significa sobrecarga nos servidores
responsáveis pelos serviços, a qual não deve afetar a experiência dos clientes.
O balanceamento de carga pode ser visto como uma solução abrangente na utilização de
grandes redes porque provê um aumento na capacidade da rede melhorando seu desempenho. Os
sistemas de balanceamento de carga integram seus nós para que todas as requisições provenientes
dos clientes sejam distribuídas de maneira equilibrada entre os nós. Assim se tem uma ou várias
máquinas que cuidam de repartir as requisições entre os servidores, de modo que cada uma cuida de
determinada parte das requisições e envia de volta as respostas que serão enviadas aos usuários.
Todos os servidores mantêm uma cópia integral de todos os dados, já que de qualquer forma
cada servidor precisará de todos os dados para atender as requisições que chegarem até ele. Um
software de controle se encarrega de sincronizar os dados entre os servidores automaticamente.
Caso algum dos servidores precise ser desligado, seja por alguma falha ou então por algum tipo de
manutenção, os outros continuam trabalhando normalmente. Ao voltar, o programa de controle
sincroniza o servidor com os demais e ele volta à ativa.
2. Benefícios
Aumento da escalabilidade - Quando muitas aplicações de conteúdo intensivo crescem para além
do ponto em que um único servidor pode fornecer poder de processamento adequado, é cada vez
mais importante para ter flexibilidade de adicionar mais servidores de forma rápida e transparente
aos utilizadores finais.
Alto desempenho – O melhor desempenho é alcançado quando o poder de processamento dos
servidores é usado de forma inteligente. Uma infra-estrutura avançada de balanceamento de carga
pode direcionar as solicitações de serviços ao utilizador final para os servidores que estão menos
ocupados e, portanto, capazes de fornecer o tempo de resposta mais baixo.
Alta disponibilidade e recuperação de desastres - o terceiro benefício do balanceamento de carga
é a capacidade de melhorar a disponibilidade das aplicações. Se uma aplicação ou servidor falhar, o
balanceamento de carga pode automaticamente redistribuir as solicitações de serviço do utilizador
final para outros servidores dentro de um cluster de servidores ou para servidores de outro local.
Maximização de Uptimes - Viabiliza a manutenção individualizada nos servidores sem impacto
nos serviços, entre outros benefícios.
3. Processo de Instalação e Configuração
O Processo de instalação e configuração das aplicações usadas no balanceamento de carga foi feita
em cima do SO Linux debian. Nesse servidor foi instalado o serviço de DNS Bind 9, nos outros
dois servidores foram colocados o serviço Apache 2 e hospedado um site de compra coletiva, na
qual hoje tem bastante acesso, principalmente quando têm promoções com desconto atrativos.
O Balanceamento de carga dessa aplicação foi feita em cima do DNS Bind 9, uma vez que o
cliente faz a requisição do site, ela é feita no DNS. Este diz ao cliente que esse site que ele possui,
encontra-se em outra máquina da sua rede. No DNS há duas entradas de máquinas diferentes na
rede, os dois computadores possui a mesma cópia do site com as mesmas informações, que hospeda
o site e esta com o serviço apache instalado, após o DNS dizer para o cliente que o site se encontra
em outro computador na sua rede, o cliente faz a conexão diretamente com a ela que esta com o site
hospedado.
3.1. Linux Debian
Debian é simultaneamente o nome de uma distribuição não comercial livre (Gratuita de código
fonte aberto) e de um grupo de voluntários que o mantém a volta do mundo. Uma vez que ele se
baseia fortemente no projeto GNU é usualmente chamado Debian GNU/Linux. Ele é conhecido
pelo seu sistema de gestão de pacotes, chamado APT, que permite: atualizações relativamente fáceis
a partir de versões realmente antigas; instalações quase sem esforço de pacotes e remoção limpa dos
pacotes antigos. Atualmente o Debian Stable se encontra na versão 6.0, e procura sempre manter os
pacotes mais estáveis, assim, ele mantém o Gnome 2.30 e o KDE 4.4 por padrão. O grande fato de
ele manter pacotes antigos garante a estabilidade e o grande foco para servidores.
O Projeto Debian é mantido por doações através de organização sem fins lucrativos
Software in the Public Interest (SPI).
Figura 1.– Tela do Sistema Operacional Debian.
3.2. Instalação e Configuração do DNS Bind
O DNS (Domain Name Server) surgiu da necessidade em traduzir nomes mais fáceis de serem
lembrados como (minha faculdade), para seus respectivos endereços na rede. Para facilitar mais a
identificação desses serviços, criaram-se terminações elucidativas, como .com para domínios
comercias, .net para empresas networking, .org para empresas sem fins lucrativos.
Bind (Berkeley Internet Name Domain) é o servidor para o protocolo DNS mais utilizado na
internet, especialmente em sistemas do tipo Unix, onde ele pode ser considerado um padrão de
fato. Foi criado por quatro estudantes de graduação, membros de um grupo de pesquisas em Ciência
da Computação da Universidade de Berkeley e distribuído pela primeira vez com o sistema
operacional 4.3BSB. O programador Paul Vixie, enquanto trabalhava para a empresa DEC, foi o
primeiro mantenedor do BIND. Atualmente o ele é suportado e mantido pelo Internet systems
Consortium.
Por padrão no sistema operacional usado nesse projeto, quando se está fazendo a instalação
do sistema operacional, pergunta-se aos serviços adicionais que se deseja para ser instalado junto.
Mas para instalar o DNS na distribuição debian ou ubuntu o usuário irá usar o comando.
Figura 2. Instalação do Dns Bind9.
Existem diversos tipos diferentes de registros DNS disponíveis, a lista a seguir não pretende
de maneira alguma, ser extensa ou exaustiva, mas mostrar os mais comuns que vai encontrar por ai.
- A- Address: especifica um endereço IP direto.
- AAAA- Address IPv6: especifica um endereço IPv6.
- NS - NameServer: especifica servidores DNS para um domínio ou subdomínio.
- CNAME – Canonical NAME: um apelido para um hostname.
- MX – Mail Xchanger: o servidor de e-mail.
- PTR – Pointer: aponta o hostname/domínio reverso a partir de um endereço IP.
- SOA – Start Of Authority: indica o responsável por respostas autoritativas por um domínio.
- TXT – TeXT: permite incluir um texto curto em um hostname: usado para implementar o SPF.
- SRV – Service; permite definir serviços disponíveis em um domínio.
O DNS Bind 9 por padrão quando se faz a instalação, dentro do diretório /etc/bind/ ele cria
alguns arquivos que são os seguintes:
Figura 3. Arquivos do Bind.
Esses são os arquivos de configuração padrão de instalação do bind9.
Figura 4. Zonas do DNS
O arquivo named.conf.local foi editado e adicionadas duas zonas: uma para o domínio
“projetointegrador1.org” e uma zona reversa, ficando da seguinte maneira.
Foram criados dois arquivos named.zone, named.rev, o arquivo named.zone se refere à zona
projetointegrador1.org e o arquivo named.rev se refere à zona reversa responsável por fazer o
domínio reverso a partir de um endereço ip.
Zone – é o nome do domínio que será criado neste servidor;
Type - tipo de servidor DNS (master ou slave);
File – arquivo da data base desta zona.
Entender como uma consulta trafega pela internet é o primeiro passo para entender os
problemas que se pode ter. O Sistema de DNS trabalha com uma estrutura fortemente hierárquica.
Isso facilita que cada corporação ou entidade cuida de maneira autônoma de seu próprio DNS sem
ter que recorrer a terceiros. Imagina-se se todas as vezes que se quisesse adicionar um host na zona
DNS tivesse que contatar o registro.br ou o seu provedor.
Embora muitas corporações ainda façam isso, talvez por desconhecerem o manuseio correto
do DNS, sempre há atrasos e longas esperas para alteração tão simples. Aguardar dois dias (sem
receber e-mails) por uma mudança de MC porque seu servidor atual deu problemas e se precisa
colocar outro (emergencial) para receber os e-mails temporariamente porque o fulano do provedor
ainda não concluiu seu chamado não é uma situação confortável para nenhum administrador de
rede.
Figura 5 . Arquivo da zona (projetointegrador1.org) .
Esse arquivo se refere às configurações do DNS, fazendo com que a requisição quando
chegue nele com informações para o site ele verifica as entradas nesse arquivo e direciona a
conexão para o host onde o site se encontra hospedado, verifica-se que no DNS há duas entrada
para o nome site. projetointegrador1.org.
STTL - Define o tempo de duração (time-to-live) em segundos, que o registro de recurso mantém
no cachê do servidor.
Class - Define a classe que irá mapear a informação da zona. A classe utilizada por padrão é IN.
Type - Define o tipo de registro de recurso da zona.
SOA - Define o início das zonas e os parâmetros globais.
Serial - Define o número de série para o arquivo da zona. Toda vez que o número de série é alterado
para um valor maior, os arquivos de zonas para um servidor secundário são atualizados. Entenda o
balanceamento de carga.
Refresh - Define um período de tempo em segundos, para os servidores secundários verificar
periodicamente se o número de série foi alterado para fazer a atualização.
Expire - Define um período de tempo em segundos, que os servidores secundários possam
continuar respondendo ser ter sido atualizado pelo servidor primário.
Minimum - Define o tempo de duração em segundos, que o registro de recurso mantêm no cachê
dos servidores secundários.
Figura 6. Arquivo de zona reversa.
O arquivo de zona reversa faz o oposto que o Bind faz, ele converte nomes em endereços ip,
e a zona reversa converte ip em nomes.
Figura 7. Arquivo named.conf.options do bind.
Esse arquivo com o nome named.conf.options só se usará a primeira linha dele, onde diz
directory “/etc/bind”, onde estão armazenados os arquivos de configurações do bind.
3.3. Instalação e Configuração do Apache
O servidor web é um programa responsável por disponibilizar páginas, fotos ou qualquer outro tipo
de objeto ou navegador do cliente. Ele também pode operar recebendo dados do cliente,
processando e enviando resultado para que o cliente possa tomar a ação desejada (como em
aplicações web CG1s, banco de dados web,preenchimento de formulários, etc).
O Apache é um servidor web extremamente configurável, robusto e de alta performance
desenvolvido por uma equipe de voluntários (conhecida como Apache Group) buscando criar um
servidor web com muitas características e como código fonte disponível gratuitamente via Internet.
Segundo a Netcraft (http://www.netvraft.com/), o apache é mais usado que todos os outros
servidores web do mundo juntos.
A instalação do apache pode ser feita com serviço adicional na instalação do sistema
operacional ou através da linha de comando no terminal do sistema digitando apt-get install
apache2.
3.3.1. Configuração do Apache
A configuração do apache é bem básica, por padrão na instalação já vem com os arquivos e
configurados para acesso através do endereço localhost. Os arquivos de configurações do apache
são os seguintes:
Figura 8. Arquivos do Apache 2
3.3.2. Configurando o Arquivo Para o Site
Criando o arquivo no diretório /etc/apache2/sites-available com o nome site e adicionando as
informações nele conforma a imagem abaixo.
Figura 9. Virtual host do site
Esse arquivo se refere ao virtual host do site, que será hospedado no servidor:
Virtualhost - ip da placa de rede do servidor.
ServerAdmin – Email do administrador do domínio.
DocumentRoot – diretório onde será colocado os arquivos do site de acesso.
ServerName - Nome do site que foi dado no DNS.
Após fazer a criação desse arquivo tem que ativar o site para que entre em funcionamento,
digitando o seguinte comando, a2ensite.
4. Entendendo o Balanceamento de Carga
Em ambientes de produção é normal preocupações que não ocorrem com ambientes de
desenvolvimento, como uma disponibilidade alta de balanceamento de carga. Outro problema bem
comum é a sobre carga nas aplicações. Um cenário bem comum são as aplicações web onde o
acesso de muitos usuários e consequentemente causando exaustão do hardware onde as aplicações
estão hospedadas.
A alta disponibilidade pode ser definida como redundância. Se um servidor falhar ou não
poder responder a requisição, outro servidor assumirá da forma mais transparente possível, fazendo
o processamento da requisição solicitada pelo cliente. Isso elimina as falhas das aplicações.
O balanceamento de carga é uma habilidade das aplicações suportarem um número crescente
de usuários a cada dia, como se fosse um sistema único.
Um dos maiores desafios enfrentados pelos servidores agrupados, no caso de servidores
dinâmicos como os de comércio eletrônico, é que o ganho de desempenho, isto é, a melhoria do
desempenho resultante do aumento do número de processadores. A distribuição de requisições entre
um número de servidores impõe novas demandas de processamentos para garantir a consistência
das informações armazenadas por eles.
Outra fonte de custos adicionais além da manutenção e o gerenciamento da distribuição de
requisições aliado a manutenção de estado. O protocolo HTTP não faz a manutenção de estado de
tal forma que cada requisição é tratada de forma independente de outras submetidas pelo mesmo
usuário, podendo ser enviada a qualquer servidor que compõe a requisição hospedada. Entretanto
um serviço de comércio eletrônico, por exemplo, a interação do cliente com o servidor cria certa
quantidade de informação de estado, com os produtos adicionados a uma cesta de compras, a
identificação dos usuários, entre outros. Nesse caso, a distribuição de requisições se deve considerar
a existência dessa informação de estado.
Quando se analisa um portal Internet encontra-se aproximadamente uma centena de
servidores para o mesmo conjunto de tarefas. Enquanto empresas de cerca de 3.000 micros em sua
rede de produção contam, normalmente, com apenas uma dezena deles, não é raro que esses
servidores tenham funções diferentes e capacidades diferentes. Quando se encontra servidores
iguais, provavelmente, estão como forma de redundância e não balanceiam a sua carga.
No momento da mudança da arquitetura de uma rede local para uma rede mais rápida,
baseada em switchs e portas Fast Ethernet com o backbone em Gigabit Ethernet, não se encontra
quem pergunta ou sabe qual a quantidade de acesso que um servidor recebe ou mesmo se a
aplicação que nele contém suporta a quantidade de acesso.
O balanceamento de carga entre servidores faz parte de uma solução abrangente em uma
explosiva e crescente utilização da rede e da Internet. Provendo um aumento na capacidade da rede,
melhorando a desempenho, um consistente balanceamento de carga, mostra-se hoje, como parte
integrante de todo o projeto de Web Hosting e e-commerce. Mas não se pode ficar com as ideias
presas de que isso é só para provedores, devem-se aproveitar as suas características e trazer para
dentro das empresas esse modo de usar a tecnologia para se atender os clientes internos delas.
Devem-se ressaltar três pontos principais para que uma implementação em um ambiente
com balanceamento de carga nos servidores seja realizada com sucesso. O primeiro é o algoritmo
usado para o balanceamento de carga, levando-se em consideração como é feito o balanceamento
entre os servidores e quando um cliente fizer uma requisição para o endereço virtual (VS), todo o
processo de escolha do servidor e resposta deve ocorrer de modo transparente e imperceptível para
o usuário como se não existisse o balanceamento. O segundo ponto é o método usado para checar se
os servidores estão vivos e funcionando, vital para que a comunicação não seja redirecionada para
um servidor que acabou de ter uma falha. O terceiro é o método usado para se ter certeza que um
cliente acesse ao mesmo servidor quando quiser.
Balanceamento de carga entre servidores é muito mais que um simples redirecionamento de
tráfego dos clientes para múltiplos servidores. Para se programar corretamente, o equipamento que
fará o balanceamento precisa ter características como checagem permanente da comunicação,
checagem dos servidores e capacidade de redundância. Todos esses itens são necessários para que
suporte o crescente volume de tráfego das redes sem vir a se tornar um gargalo ou um ponto único
de falha.
O balanceamento de carga será feito em round robin, na sua implementação mais simples.
Round Robin funciona respondendo a requisições não apenas com um endereço ip, mais sim com
uma lista de endereço ip com vários servidores contendo o mesmo conteúdo. Com isso ele funciona
como se lê uma lista, cada requisição que entra para o DNS ele manda para um destino, primeira
requisição ele manda para o servidor A, segundo pedido que entrar mandará para o servidor B, a
terceira requisição para o servidor A novamente, e assim sucessivamente.
Figura 10. round robin
A imagem acima ilustra como funciona realmente o balanceamento. O cliente requisita a
página, faz a consulta no DNS, o servidor DNS retorna a consulta dizendo que a página se encontra
num servidor dentro do nó, feito isso a comunicação fica entre um dos servidores apache conforme
a figura acima.
Figura 11 – Captura da consulta DNS
Essa captura acima se refere à consulta do host para o DNS requisitando a página solicitada
que seria o site a qual o cliente quer o acesso. Após fazer essa consulta o DNS vai enviar uma
resposta para o destino, dizendo que o servidor que hospeda o site está em outro nó hospedeiro, e
então encaminha a conexão para o servidor. Depois de fazer à consulta no DNS a comunicação será
direto entre cliente e servidor.
Figura 12. Captura das consultas DNS
Figura 13. Captura das trocas de pacotes entre o apache e o host
Conforme se pode verificar na imagem acima, as trocas de pacotes entre um dos servidores apache
e seu cliente. O cliente contém o ip 192.168.100.10 e o servidor apache está com 192.168.100.5.
Figura 14. Captura das trocas de pacotes entre o apache e o host
Conforme se pode verificar na imagem acima, as trocas de pacotes entre um dos servidores
apache e seu cliente. Cliente tem o ip 192.168.100.15 e o server está com 192.168.100.8.
4.1 Requisitos de Software
- Sistema operacional Debian 6.
- Instalação do DNS Bind 9.
- Instalação do servidor web apache 2.
5. Requisitos de Hardware
Os requisitos para um bom balanceamento de carga são de quanto melhor o hardware da sua
máquina, maior o seu desempenho e das aplicações e o tempo de resposta para o cliente será menor.
Se a empresa está em início de crescimento poderá adquirir um patrimônio com menor capacidade
de processamento. Lembrando que, com isso, vai ter perda de ganho com o desempenho das suas
aplicações e resultará no aumento da resposta para os clientes, isso dependerá muito também de
quantas requisições terá ao dia para que isso entre em vigor.
6. Estudo de caso
Os testes feitos nesse projeto foram feitos em máquinas virtuais usando o virtualbox, foram criadas
três máquinas virtuais com o sistema operacional debian 6 e 1 windows 7 para teste e um XP.
Os servidores Linux debian 6 as configurações dos mesmos ficou assim:
− 346MB de memória ram
− 10 GB de disco rígido.
− Processador core i3 2.27 GHz
A máquina Virtual Windows Xp para testes ficou com as seguintes configurações:
− 256 MB de memória ram
− 5 GB de disco rígido
− Processador core i3 2.27 GHz
A máquina Virtual Windows 7 ficou com as seguintes configurações:
− 512 MB de memória ram
− 15 GB de disco rígido
− Processador core i3 2.27 GHz
Abaixo uma figura de como ficará a estrutura real utilizada no projeto:
Figura 15 – Estrutura usada para testes no projeto
Os testes feitos no projeto foi fazer a requisição dos hosts para o site projetointegrador1.org
fazendo com que simulasse um acesso de um cliente a um site com essa requisição então o DNS faz
o balanceamento de carga direcionando a requisição para um dos servidores que contém o site
hospedado, Após o host cliente fazer a comunicação com o servidor apache a conexão fica só com
eles dois liberando o servidor DNS, assim quando um novo cliente fizer a requisição para o site a
pergunta irá entrar no DNS e depois será enviado para o próximo servidor da fila.
Os testes feitos após as configurações de todos os serviços foram usar as máquinas dos
clientes e acessar o site projetointegrador1.org através do navegador, para então navegar sobre o
site, preencher formulários e observando e capturando os pacotes com o Wireshark e verificando de
qual dos dois servidores apache estava vindo a resposta.
6.1. Problemas encontrados
Um dos principais problemas encontrados nesse projeto foi uma estrutura real para implantação,
uma vez que em um ambiente real há problemas maiores de como estrutura da rede de onde está
sendo implementado o balanceamento, e nela se terá mais clientes, mais acessos por minuto, e com
isso já causando um stress maior nos servidores, uma vez que no ambiente aplicado nesse projeto
foi usado dois computadores um Windows XP e um Windows 7 para acesso ao site.
Com a estrutura aplicada nesse projeto, foi encontrado outro problema para realizar os testes
em cima dos servidores, já que não se têm vários clientes para acessar a página, como sobrecarregar
os servidores sem cliente suficiente para acessar para que então se observasse como os servidores
iriam se comportar quando várias requisições entrassem para eles e então fosse verificado como iria
funcionar realmente o balanceamento de carga.
6.2 Testes finais
Para que se pudesse realizar um teste aceitável do balanceamento de carga nessa estrutura, foi
usada como saída uma ferramenta de gerar tráfego em cima dos servidores em uma determinada
porta (80), que é a porta que esta rodando site projetointegrador1.org e então realizado novo teste,
com a ferramenta destinou-se 900 conexões para o servidor 192.168.100.5, e 500 conexões para o
servidor 192.168.100.8 e então foi acessado novamente o site através dos hosts clientes. O tempo de
resposta não mudou muito, mesmo com todas essas conexões, em cima dos servidores em nenhuma
ocasião chegou a dar time out para o cliente fazendo com que ele reiniciasse a conexão com o
servidor novamente.
Conclusão
No decorrer do presente trabalho observou-se que a tecnologia de balanceamento de carga em
servidores web que possuem muitos pedidos de acesso é uma saída de pouco custo. Estudou-se uma
estratégia de balanceamento de carga utilizando uma tecnologia não tão moderna, mas sim uma
solução comum de balancear a carga utilizando o DNS com round Robin. Onde o DNS manda o
pedido de acesso para um host de vez conforme a lista de entradas constada nele.
Verificou-se o tempo de resposta entre um servidor com muitas requisições enviando
resposta e depois analisando o tempo de resposta com dois servidores respondendo as requisições.
Os resultados obtidos foram bons e o tempo de resposta da página para o cliente foi imediato uma
vez que ele requisitou o site e recebeu uma resposta rápida. Isso se deve ao balanceamento feito
entre os servidores e evitando um stress para um servidor e fazendo com que as aplicações
funcionem da melhor forma sem sobrecarga,
Detectou-se também que, com essa tecnologia, 99% de disponibilidade dos serviços, fazem
com que seu site fique 24h por dia no ar. Ao necessitar de se fazer uma manutenção no site ou trocar
um hardware do servidor, ao se desligar um deles, sua aplicação e serviços não irão precisar ficar
fora do ar, pois ao desligar um dos servidores o outro irá ficar respondendo todas as requisições de
seus serviços disponibilizados, com isso há um ganho de confiança em seus serviços uma vez que
se tenha uma disponibilidade de 99%.
O ponto mais positivo desse projeto se dá na recuperação de erros. Uma vez que a requisição
é mandada para o servidor, que já está com algumas conexões, os pacotes podem não chegar todos
com sucesso para o destino, o cliente quer a página e então irá iniciar uma nova conexão com isso.
O DNS não irá mandar a requisição para o mesmo destino e sim mandá-lo para o próximo servidor
que consta na lista, fazendo com que a página e os pacotes cheguem ao destino todos com sucesso.
O balanceamento de carga gerado nesse trabalho pode ser de grande importância
futuramente, pois cada vez mais há a necessidade de cortar custos em tecnologias de informação e
disponibilidade de 100% dos serviços.
7 Referência Bibliográfica
Arthuron,
Luiz
(2009)
“Balanceamento
de
carga
com
DNS”.
http://www.slideshare.net/luizarthur/tpicos-cluster-de-balanceamento-de-carga-com-dns. Junho.
Augustus,
Cesar.
(2011)
“Instalando
o
Servidor
http://www.youtube.com/watch?v=uLDi4MQ41O0. Maio.
Apache
no
Linux”.
Caldeira,
Gerson
Abdon
(2005)
“Balanceamento
de
http://eng.registro.br/pipermail/gter/2005-March/007774.html. Maio.
carga
(BIND9)”.
Falcão, Fábio (2010). “Instalando o Apache2 e configurando domínios virtuais no Linux”.
http://fabiofalcao.blogspot.com.br/2010/05/instalando-o-apache2-e-configurando.html. Maio.
Feijó, Gustavo (2008). “Configuração do bind 9”. http://omgili.com/mailinglist/debian-userportuguese/lists/debian/org/8a20e5000801020448p5404a25do2f618fc35a379ef9mailgmailcom.html
Maio
Gonçalves,
João
Cláudio
de
Oliveira
(2007).
“Instalando
http://www.vivaolinux.com.br/artigo/Basico-do-Apache-no-Debian. Abril-Junho.
o
apache”.
Grillo,
Luiz
Felipe
(2005).
“Instalando
e
configurando
http://www.vivaolinux.com.br/artigo/Apache-2-para-Debian. Abril.
o
apache”.
Michellis,
Deives
(2005).
“Uma
breve
introdução
ao
http://www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow. Junho.
DNS”.
Morimoto, Carlos E. (2007) “Servidores em cluester
http://www.hardware.com.br/artigos/cluster-carga/ Abril.
_______ (2008) Instalando o
linux/instalando-apache.html. Maio.
Apache.
e
balanceamento
de
carga”.
http://www.hardware.com.br/livros/servidores-
Oliveira, Daniel B. de (2006). “Balanceamento de carga e redundância para servidores web”.
http://www.fug.com.br/content/view/108/2/. Maio.
Ribas, Diego (2005). “Replicação e balanceamento de carga usando DNS”.
http://www.vivaolinux.com.br/artigo/Replicacao-e-balanceamento-de-carga-em-servidores-usandodns. Maio.
Rocha, Cleber (2009). “DHCP3- server + Bind adicionando host automaticamente”.
http://www.vivaolinux.com.br/artigo/Debian-Lenny-DHCP3server-+-Bind9-adicionando-maquinasautomaticamente. Junho.
Saqueto,
Luis
Viscardo
(2004).
“Configurando
o
Bind
no
Debian”.
http://www.vivaolinux.com.br/artigo/Configurando-o-bind-9-no-Debian?pagina=2. Maio.
Teruskin,
Rafael
(2002).
“Balanceamento
de
carga
http://www.gta.ufrj.br/seminarios/semin2002_1/Rafael/ Junho.
em
servidor
web”.