Jean Carlo Faustino <jean@rnp.br>
Serviço de Suporte a Operações (SSO)
Rede Nacional de Ensino e Pesquisa
Antônio Carlos Fernandes Nunes <antonio@rnp.br>
Serviço de Suporte a Informações (SSI)
Rede Nacional de Ensino e Pesquisa
Apresentação
1. Introdução
2. Round robin
3. SRV RR
4. Testes e Análises
5. Conclusões
6. Considerações finais
Referências bibliográficas
Esse artigo apresenta os recursos de round robin e SRV, próprios do BIND/DNS, e os experimentos com eles realizados. Ao final deste, o leitor terá uma visão geral das limitações e possibilidades da sua adoção como alternativa - de baixo custo - para uma redundância de servidor web corporativo.
O propósito do experimento que culminou nesse artigo foi o de implementar uma redundância de servidor web, a partir dos recursos do próprio BIND/DNS.
Essa redundância, isto é, a continuação da operacionalidade de um serviço de rede no caso de uma queda do servidor principal, tinha como pressuposto a transparência para o usuário final. Neste caso, quando o servidor web principal ficasse fora de operação, um servidor secundário passaria automaticamente a responder pelo serviço exigindo do usuário final apenas um reload na homepage em uso.
Para implementar essa redundância, a ferramenta utilizada foi o DNS (Bind versão 8) através dos seus recursos de round robin e SRV.
Round robin é um recurso de funcionalidade muito útil quando se deseja espalhar o processamento entre servidores (de FTP, web, etc) equivalentes [1].
A sua implementação se faz registrando-se, no DNS, o grupo de servidores (espelhados) com um mesmo nome - conforme o exemplo abaixo:
| www.rnp.br |
60
|
IN
|
A
|
192.168.10.1 |
| www.rnp.br |
60
|
IN
|
A
|
192.168.10.2 |
| www.rnp.br |
60
|
IN
|
A
|
192.168.10.3 |
Essa é a forma de se implementar o processo que a documentação
do BIND chama de round robin. No entanto, chama-se atenção
para o fato de que o mecanismo está implementando um load sharing
e não um load balance, ou seja, o DNS irá compartilhar
o acesso ao serviço de rede através dos diferentes servidores
sem levar em conta nenhum critério de balanceamento de carga ou performance
dos servidores em si [1].
SRV RR (Resource Record) é um recurso que provê "distribute load and backup service", ou seja, a sua implementação permite que o servidor backup assuma se o servidor principal ficar inoperante - além do fato de distribuir o processamento ao longo de vários servidores [1].
O distribute load, deste mesmo recurso, ainda não é um load balance, mas parece ser mais sofisticado que o load sharing do round robin - considerando-se o fato de ser possível colocar pesos para os servidores.
Em resumo, pode-se dizer que o SRV implementa - para serviços de rede como, por exemplo, FTP e web - o recurso análogo ao MX (utilizado nas soluções de servidor de Mail).
A sua implementação, assim como o round robin, se faz pelo registro no servidor DNS. Contudo, esse registro utiliza-se de alguns campos específicos. Abaixo é apresentado o formato do SRV RR [1]:
service.proto.name SRV priority weight port target
Assim, um exemplo de implementação do SRV, nos servidores web do domínio rnp.br, ficaria da seguinte maneira:
| http.tcp.rnp.br |
IN
|
SRV
|
0
|
1
|
80
|
www.rnp.br |
|
IN
|
SRV
|
1
|
1
|
80
|
www2.rnp.br |
Nesse caso, o servidor www2.rnp.br assumiria apenas quando o servidor www.rnp.br ficasse inoperante.
Esse exemplo acima ilustra apenas o recurso de backup service. No entanto, é possível também a utilização do recurso de distribute load, conforme o exemplo abaixo:
| http.tcp.rnp.br |
IN
|
SRV
|
0
|
2
|
80
|
www.rnp.br |
|
IN
|
SRV
|
0
|
1
|
80
|
www2.rnp.br | |
|
IN
|
SRV
|
1
|
1
|
80
|
www3.rnp.br |
Nesse caso, o servidor www.rnp.br atenderia ao dobro das solicitações enviadas para www2.rnp.br. Caso os dois primeiros servidores não estivessem disponíveis, o servidor www3.rnp.br assumiria.
Recomenda-se a utilização do underscore (_) prefixado ao identificador do serviço e do protocolo para evitar conflitos com rótulos DNS, conforme formato apresentado abaixo [3]:
_service._proto.name SRV priority weight port target
Conforme mencionado na introdução desse artigo, o propósito desse experimento era o de pesquisar uma solução de redundância, para o servidor web, utilizando-se dos recursos do próprio BIND/DNS.
A solução ideal era a implementação do SRV RR, porque isso colocaria o servidor secundário automaticamente no ar quando o principal ficasse inoperante [1]. Restava, porém, saber se isso seria feito de maneira transparente para o usuário.
Até 1998 não se conhecia nenhum cliente que tivesse suporte ao recurso do SRV [1][4]. No entanto, esperava-se que nesses últimos quatro anos tivesse ocorrido algum progresso em relação a isso. Com esse pressuposto, o SRV foi então testado - utilizando-se do Mozila 1.0, Internet Explorer 6 e Netscape 7. Surpreendentemente, em nenhum desses browsers o recurso em questão funcionou.
Assim, embora tenha-se realizado ainda uma pesquisa a procura de browsers que tivessem suporte ao SRV, esse recurso do DNS foi abandonado como solução para a redundância de um servidor web pelo fato de não ser compatível com os browsers mais comuns do mercado.
Por outro lado, os testes com o recurso de round robin apresentaram um resultado não somente satisfatório como também superior às expectativas que se tinha sobre ele. Esperava-se, por exemplo, que fosse necessário - ao usuário final - executar um reload quando o servidor web principal fosse substituído pelo secundário. Ao contrário disso, o usuário não somente não precisa executar esse reload como o redirecionamento para o servidor secundário é feito de maneira transparente e instantânea, ou seja, o resultado alcançado com o uso do round robin foi aquele que se esperava alcançar apenas com o uso do SRV.
Infelizmente, há uma importante ressalva a ser feita: assim como o SRV, o round robin depende também do browser que o cliente do serviço está usando, ou seja, embora o round robin tenha apresentado bons resultados com as últimas versões dos browsers anteriormente mencionados, os resultados obtidos com versões anteriores, desses mesmos browsers, praticamente inviabilizam uma solução de redundância - veja-se, por exemplo, o caso do Netscape versão 4.78 que não somente demora aproximadamente quarenta segundos para redirecionar o acesso ao servidor secundário como, também, pode até nem mesmo achar o outro servidor.
Os testes e análises realizados com o recurso de SRV RR e round robin do DNS, com a finalidade de se implementar uma redundância de servidor web, mostraram que ambos os recursos possuem dependência do browser do cliente do serviço.
Como as versões mais recentes dos web browsers mais populares (Netscape, Internet Explorer e Mozila) ainda não suportam o SRV, adotá-lo como solução é praticamente inviável.
Quanto ao recurso de round robin, considerando-se a sua boa performance, ele se apresenta com uma perspectiva melhor para ser adotado como solução de redundância de servidores web. Mas, pelo fato dele também depender da versão dos browsers do cliente, a sua adoção está restrita a um ambiente corporativo pressupondo-se que, nesse caso, os programas e versões de browsers - a serem adotados pelos usuários - possam ser previamente definidos.
Como sugerido pelo próprio título desse artigo, a solução de redundância apresentada é de baixo custo, baseando-se apenas em recursos já existentes no próprio BIND/DNS, podendo-se implementá-lo sem nenhum investimento em equipamentos de rede específicos - como um web-switch, por exemplo.
No entanto, é uma solução de load sharing, não trazendo, portanto, os benefícios de load balance que um web switch - ou solução semelhante - poderia proporcionar. Entretanto, além do load sharing, essa solução - dentro das limitações apresentadas no item "conclusões" - oferece também a possibilidade de um sistema de backup de um servidor web.
Sobre esse último aspecto, deve-se ressaltar o fato de que a implementação de um espelhamento de servidor web também traz outras implicações não tratadas neste artigo - como, por exemplo, a sincronização dos dados e o tratamento dos logs. Contudo, no que se refere ao DNS, as implicações e conceitos foram aqui apresentados.
[1] ALBITZ, P.; LIU, C. DNS and BIND. 3. ed. Sebastopol: O´Reilly & Associates, sep. 1998.
[2] SILVA, T. A. da. BIND versão 9: procedimento de instalação
e configuração. RNP NewsGeneration, vol.5, n.3,
11 maio 2001.
Disponível em: <http://www.rnp.br/newsgen/0105/bind9.shtml>.
Acesso em out. 2002.
[3]GULBRANDSEN, A; VIXIE, P.; ESIBOV, L. A DNS RR for specifying the location of services (DNS SRV). RFC 2782, feb. 2000. Disponível em: <http://www.ietf.org/rfc/rfc2782.txt>. Acesso em out. 2002.
[4] LIST OF TOOLS THAT SUPPORT SRV RECORDS. List of tools that suport SRV records. Disponível em: <http://dns.vanrein.org/srv/tools/>. Acesso em out. 2002.