Alta disponibilidade em roteadores: Um ambiente de teste
Autor: Jo˜ao Eur´ıpedes Pereira J ´unior1, Orientador: PhD. Pedro Frosi Rosa1
1Programa de P´os-Graduac¸˜ao em Ciˆencia da Computac¸˜ao
Universidade Federal do Uberlˆandia (UFU) Uberlˆandia – MG – Brasil
joao@dirpd.ufu.br, frosi@facom.ufu.br
N´ıvel: Mestrado
Ano de ingresso no programa: 2008 ´
Epoca esperada de conclus˜ao: Marc¸o / 2010
Resumo. High available routers are crucial pieces of today’s internet. Virtual Router Redundancy Protocol (VRRP) and Common Address Redundancy Protocol (CARP) are attempts to catch this need, but evolving customers and bussiness requirements drive the improvements of such solutions. This paper reflects a research (on progress) to understand this protocols and propose a test enviroment to observe their behavior and collect information. This information will be compiled in a benchmark to support a future architecture propose. The first test is defined and the experiment is described. Guidelines for other tests and related works are presented.
1. Introduc¸˜ao
O protocolo Virtual Router Redundancy Protocol (VRRP) foi projetado para elimi-nar o ponto ´unico de falha inerente aos ambientes de roteamento configurados estati-camente [Nadas 2008]. No entanto, existem alguns trabalhos, [G. Attebury 2006], [E. Lopes Filho ], [J. Kuo ], que citam o pr´oprio VRRP como um ponto de falha. Como uma alternativa ao VRRP, que apresenta problemas t´ecnicos e teve a patente reclamada pela Cisco, a comunidade do OpenBSD desenvolveu o Common Address Redundancy Pro-tocol (CARP). O CARP permite que m ´ultiplos hosts compartilhem o mesmo enderec¸o IP, dependendo da configurac¸˜ao ele pode prover disponibilidade ou balanceamento de carga [car ].
Este documento registra uma pesquisa (em andamento), cujo objetivo ´e entender o fun-cionamento dos protocolos VRRP e CARP, e fazer um benchmark com esses protoco-los. Esse benchmark ser´a utilizado em uma fase posterior da pesquisa, que visa definir uma arquitetura de alta disponibilidade envolvendo o protocolo Stream Control Trans-mission Protocol (SCTP) [Steward 2007]. Com esse int ´uito, foi implementado um ambi-ente de teste com m´aquinas virtuais usando VRRP e CARP para simular roteadores de alta disponibilidade.
O ambiente de teste ´e apresentado na sec¸˜ao 2 e o primeiro experimento descrito na sec¸˜ao 3. A sec¸˜ao 4 versa sobre os trabalhos relacionados e sobre como a pesquisa apresentada nesse trabalho pode ser extendida, restando as considerac¸˜oes finais para a sec¸˜ao 5.
2. O Ambiente de teste
F´ısicamente o ambiente de teste se resume a um notebook com um processador Intel Core 2 Duo T8300 e 2Gb de RAM, logicamente se resume a quatro roteadores, que ser˜ao usados aos pares, dois para o protocolo VRRP e dois para o protocolo CARP, um cliente e um servidor.
O notebook roda o sistema operacional Linux, distribuic¸˜ao Suse, vers˜ao 11.0, kernel 2.6.25, onde foram criadas duas interfaces do tipo ponte (bridge), br0 e br1, e oito in-terfaces do tipo tap, numeradas de um a oito.
As pontes (bridges) s˜ao equipamentos usados para unir v´arias LANs. No inicial todos os frames que entram por uma das portas da ponte s˜ao repassados para as outras portas, mas apenas a interface cujo enderec¸o Media Access Control (MAC) casa com o enderec¸o de destino contido no frame o recebe. O frame ´e processado e devolvido para a ponte, que memoriza por qual porta a resposta retornou. O pr´oximo frame enviado para o mesmo destino ser´a repassado apenas para a porta memorizada.
O Linux provˆe o recurso de ponte ethernet virtual, com a qual ´e poss´ıvel criar instˆancias de ponte e associar interfaces `a mesma. Cada instˆancia de ponte funciona como foi descrito no par´agrafo anterior e todas as interfaces associadas `a ponte s˜ao equivalentes a portas.
As interfaces tap s˜ao outro recurso oferecido pelo sistema operacional. Essas interfaces s˜ao t ´uneis ethernet entre o espac¸o do usu´ario e o espac¸o do kernel, o que permite que o kernel e as aplicac¸˜oes troquem frames ethernet como se houvesse um enlace entre eles. Das oito interfaces tap criadas, as ´ımpares foram associadas `a ponte br0 e as pares `a ponte br1, formando assim duas redes locais de quatro interfaces cada uma.
Cada roteador ´e uma m´aquina virtual instalada usando o software VirtualBox e possui duas interfaces de rede, associadas a uma das interfaces tap ´ımpar e a uma das interfaces tap par. Uma das interfaces de rede de cada m´aquina virtual est´a associada a uma das in-terfaces tap da m´aquina hospedeira que pertenc¸a `a ponte br0, enquanto a outra interface est´a associada a uma das interfaces tap que pertenc¸a `a ponte br1.
A interface da ponte br0 foi configurada com o IP 192.168.0.254 e a interface da ponte br1 foi configurada com IP 192.168.1.254. A interface do director1 associada `a ponte br0 foi configurada com o IP 192.168.0.1 e a interface associada `a ponte br1 foi configurada com o IP 192.168.1.1. A interface do director2 associada `a ponte br0 foi configurada com o IP 192.168.0.2 e a interface associada `a ponte br1 foi configurada com o IP 192.168.1.2. A interface do freebsd1 associada `a ponte br0 foi configurada com o IP 192.168.0.3 e a inter-face associada `a ponte br1 foi configurada com o IP 192.168.1.3. A interinter-face do freebsd2 associada `a ponte br0 foi configurada com o IP 192.168.0.4 e a interface associada `a ponte br1 foi configurada com o IP 192.168.1.4.
Linux Virtual Server (LVS) ´e um arranjo (cluster) de servidores Linux que provˆe servic¸os de alta disponibilidade e alto desempenho. Essas caracter´ısticas s˜ao obtidas com o uso das t´ecnicas de failover, redundˆancia com substituic¸˜ao autom´atica, e load balancing, distribuic¸˜ao da demanda para v´arios servidores.
O LVS ´e composto por Directors e Real Servers. Os Directors fazem o balanceamento de carga e a redundˆancia entre os Real Servers, e funcionam como roteadores virtuais. Os Directors tamb´em suportam redundˆancia entre si para aumentar a disponibilidade dos servic¸os oferecidos pelo LVS. O papel dos Real Servers ´e prover servic¸os, exatamente como trabalham os servidores comuns da internet.
Figure 1. Gateway comum
O balanceamento de carga entre os servidores ´e feito por um m´odulo do kernel do Linux, chamado ipvs. O ipvs ´e um comutador (switcher) de pacotes baseado na pilha TCP/IP. Esse m´odulo mant´em uma tabela, cujas informac¸˜oes s˜ao usadas para decidir o destino dos pacotes. A decis˜ao tamb´em leva em conta o n ´umero de conex˜oes que um Real Server est´a atendendo, de maneira a deixar a carga nos Real Servers equilibrada. A caracter´ıstica de balanceamento de carga est´a fora do escopo desse documento, para maiores informac¸˜oes vide [lvs ].
Figure 2. Gateway LVS
A redundˆancia entre os Directors fica a cargo do protocolo VRRP. O VRRP especifica um protocolo de eleic¸˜ao que atribui dinamicamente a responsabilidade pelo roteador vir-tual a um dos roteadores VRRP na LAN. Inicialmente, um dos roteadores VRRP deve ser configurado para assumir o controle (MASTER) do roteador virtual, todos os outros roteadores VRRP da mesma instˆancia devem ser configurados para aguardar (BACKUP) at´e que a instˆancia VRRP esteja sem um roteador VRRP MASTER. O roteador VRRP MASTER faz anuncios peri´odicos, mantendo todos os roteadores VRRP BACKUP a par da sua presenc¸a. Quando o roteador MASTER deixa de enviar ou os roteadores BACKUP deixam de receber os anuncios, ´e feita uma eleic¸˜ao. O vencedor dessa eleic¸˜ao se torna o novo roteador VRRP MASTER e assume o controle do roteador virtual.
Para que um servic¸o oferecido por um LVS atinja a alta disponibilidade ac¸˜oes precisam ser constantemente tomadas em resposta a eventos, como falhas de software ou hard-ware. Essas ac¸˜oes s˜ao tomadas pelo Keepalived [kee ], um daemon controlador de LVS, em outras palavras, o keepalived monitora e manipula o servidor virtual, automatizando as medidas e aumentando a disponibilidade.
A pec¸a fundamental no ambiente de teste ´e o roteador virtual. No caso do protocolo VRRP o roteador virtual ´e um LVS, oferecendo o servic¸o de roteamento (gateway) entre a LAN e a internet, como mostrado na figura 2. O LVS ´e composto por duas m´aquinas virtuais, chamadas de director1 e director2. Cada m´aquina virtual possui duas interfaces de rede. Uma usada para conectar o host `a LAN, e outra usada para conectar o host `a WAN.
Nas m´aquinas virtuais que rodam o sistema operacional Linux, o software keepalived-1.1.15 foi instalado e configurado para fornecer disponibilidade usando o pro-tocolo VRRP. A ferramenta net-snmp foi instalada e configurada de maneira a permitir a coleta de informac¸˜oes.
Duas m´aquinas virtuais rodam o sistema operacional FreeBSD 7.0. Elas tiveram o kernel recompilado para habilitar o protocolo CARP, uma interface CARP foi criada e configu-rada em cada uma das m´aquinas. A ferramenta net-snmp foi instalada e configuconfigu-rada de maneira a permitir a coleta de informac¸˜oes.
3. Os Testes
Em essˆencia os testes se constituem de um cliente fazendo requisic¸˜oes para e recebendo respostas de um servidor. Essas requisic¸˜oes e respostas tem que passar pelo roteador,
que embora seja ´unico do ponto de vista do cliente ou do servidor, ´e constitu´ıdo sempre de mais de um roteador (dois por quest˜ao de simplicidade). Esse arranjo (cluster) de roteadores tem a func¸˜ao de prover um servic¸o de alta disponibilidade e/ou alto desem-penho. Os experimentos sempre tem o objetivo de demonstrar o funcionamento, preju-dica-lo ou interrompe-lo. Durante os mesmos, informac¸˜oes s˜ao coletadas de maneira a permitir explicac¸˜oes mais precisas sobre o comportamento observado.
Figure 3. Tr ´afego na pcn0 do freebsd2
Figure 4. Tr ´afego na pcn0 do freebsd1
O primeiro experimento realizado com o ICMP, usando a ferramenta ping, cuja func¸˜ao ´e verificar se o compartilhamento de IP entre os roteadores reais est´a funcionando. O IP compartilhado deve responder aos ICMP Requests com ICMP Replies, quando os dois roteadores estiverem funcionando, e quando apenas um deles estiver funcionando. O IP compartilhado n˜ao deve responder quando os dois roteadores estiverem desligados.
O enderec¸o compartilhado pelo grupo de roteadores CARP ´e o 192.168.0.100, enquanto o enderec¸o compartilhado pela instˆancia VRRP ´e o 192.168.0.200. Em duas sess˜oes de shell distintas, a ferramenta ping foi chamada para enviar os requisic¸˜oes ICMP e receber as re-spostas, sendo uma chamada para cada enderec¸o. Enquanto as respostas ICMP estiverem chegando e soubermos que pelo menos um dos roteadores est´a ativo, o com partilhamento estar´a funcionando.
No in´ıcio do experimento os dois roteadores Linux estavam funcionais, e verificou-se que os dois enderec¸os respondiam `as requisic¸˜oes ICMP. Ent˜ao a interface eth1 do director1 foi colocada no estado DOWN, verificou-se que o IP compartilhado deixou de responder por um curto espac¸o de tempo, perdendo trˆes n ´umeros da sequencia de identificac¸˜ao das respostas ICMP, voltando a responder logo em seguida. O roteador VRRP director2, que
estava no estado BACKUP, passou para o estado MASTER, assumindo assim a respons-abilidade de responder aos ICMP Requests. Mais tarde a interface eth1 do director1 foi colocada no estado UP, verificando-se o mesmo comportamento da falha na sequencia de respostas ICMP, com o director1 voltando a responder `as requisic¸˜oes ICMP e o director2 voltando para o estado de BACKUP.
Os dois roteadores FreeBSD tamb´em iniciaram o experimento ambos funcionais e com a interface 192.168.0.100 respondendo `as requisic¸˜oes ICMP. A interface pcn0 do roteador do grupo CARP,freesbd1, foi colocada no estado DOWN, verificou-se que o IP compartilhado deixou de responder por um curto espac¸o de tempo, perdendo trˆes n ´umeros da sequencia de identificac¸˜ao das respostas ICMP, voltando a responder logo em seguida.
As figuras 3 e 4 mostram o tr´afego nas interfaces pcn0 dos roteadores freebsd2 e freebsd1, ambas participantes do grupo CARP. O roteador mestre do grupo CARP responde pela interface 192.168.0.100. Foram enviadas cerca de 65 mil requisic¸˜oes ICMP durante os dias 12, 13, e 14. Cada requisic¸˜ao possu´ıa o tamanho de 1000 bytes, gerando um tr´afego aproximado de 8kbps. A ´area colorida representa o tr´afego de requisic¸˜oes e respostas ICMP passando pela interface. Note que as ´reas coloridas est˜ao alternadas, indicando que o CARP est´a trabalhando no esquema de alta disponibilidade.
4. Trabalhos relacionados
Diferente do CARP, o protoloco VRRP contempla apenas a funcionalidade de disponibili-dade. Em [J. Kuo ] ´e proposta uma extens˜ao do protocolo VRRP para prˆover a funcional-idade de balanceamento de carga. O trabalho [G. Attebury 2006] mostra um firewall de alta disponibilidade que utiliza CARP e pf, uma biblioteca para filtrar pacotes de rede.
Definido o ambiente de teste, resta definir novos parˆametros de interesse e consequente-mente novos experimentos. A princ´ıpio existem trˆes grupos de experimentos, os de fun-cionalidade, os de desempenho, e os de seguranc¸a. Os de funcionalidade tem a func¸˜ao de determinar se o arranjo est´a ou n˜ao funcionando, e em que situac¸˜oes e configurac¸˜oes ele funciona, ou deixa de funcionar. Os de desempenho servem mensurar em quais carac-ter´ısticas, ou sob que situac¸˜oes um protocolo ´e mais eficiente que o outro. Os de seguranc¸a identificam como o servic¸o pode ser alterado, forjado, ou interrrompido.
Nos experimentos de seguranc¸a est˜ao previstas aplicac¸˜oes capazes de gerar pacotes VRRP ou CARP, que ser˜ao usadas para atacar os roteadores virtuais do ambiente de teste.
5. Considerac¸˜oes Finais
O ambiente de teste se mostrou uma ferramenta ´util, preenchendo as expectativas do au-tor em relac¸˜ao `a observac¸˜ao do comportamento do funcionamento dos roteadores de alta disponibilidade. Os dados gerados durante o primeiro experimento, sobre o tr´afego das interfaces dos roteadores, ficaram armazenados em um banco de dados, permitindo a gerac¸˜ao de gr´aficos. A recuperac¸˜ao desses dados permitir´a no futuro uma an´alise es-tat´ıstica de caracter´ısticas dos protocolos VRRP e CARP, que ser´a resumida na forma de um benchmark.
References
[carp] common address redundancy protocol http://www.freebsd.org/doc/en/ books/handbook/carp.htmlacessado em 30/10/2008.
Keepalived http://www.keepalived.org/ acessado em 22/10/2008.
[lvs] the linux virtual server project http://www.linuxvirtualserver.org/ aces-sado em 22/10/2008.
E. Lopes Filho, G. Tadayoshi Hashimoto, P. F. R. A high availability firewall model based on sctp protocol.
G. Attebury, B. R. (2006). Router and firewall redundancy with openbsd and carp. IEEE ICC. J. Kuo, S. Te, P. L. C. H. P. T. C. L. S. K. Y. H. Z. T. An evaluation of the virtual router
redundancy protocol extension with load balancing.
Nadas, S. (2008). [vrrp] virtual router redundancy protocol version 3 for ipv4 and ipv6. Steward, R. (2007). [sctp] stream control transmission protocol.
