Alta disponibilidade em roteadores: Um ambiente de teste

Transcrição

1 Alta disponibilidade em roteadores: Um ambiente de teste Autor: João Eurípedes Pereira Júnior 1, Orientador: PhD. Pedro Frosi Rosa 1 1 Programa de Pós-Graduação em Ciência da Computação Universidade Federal do Uberlândia (UFU) Uberlândia MG Brasil joao@dirpd.ufu.br, frosi@facom.ufu.br Nível: Mestrado Ano de ingresso no programa: 2008 Época esperada de conclusão: Març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. Palavras-Chave. Alta disponibilidade, VRRP, CARP

2 1. Introdução O protocolo Virtual Router Redundancy Protocol (VRRP) foi projetado para eliminar o ponto único de falha inerente aos ambientes de roteamento configurados estaticamente [Nadas 2008]. No entanto, existem alguns trabalhos, [G. Attebury 2006], [E. Lopes Filho ], [J. Kuo ], que citam o próprio VRRP como um ponto de falha. Como uma alternativa ao VRRP, que apresenta problemas técnicos e teve a patente reclamada pela Cisco, a comunidade do OpenBSD desenvolveu o Common Address Redundancy Protocol (CARP). O CARP permite que múltiplos hosts compartilhem o mesmo endereço IP, dependendo da configuração ele pode prover disponibilidade ou balanceamento de carga [car ]. Este documento registra uma pesquisa (em andamento), cujo objetivo é entender o funcionamento dos protocolos VRRP e CARP, e fazer um benchmark com esses protocolos. Esse benchmark será utilizado em uma fase posterior da pesquisa, que visa definir uma arquitetura de alta disponibilidade envolvendo o protocolo Stream Control Transmission Protocol (SCTP) [Steward 2007]. Com esse intúito, foi implementado um ambiente de teste com máquinas virtuais usando VRRP e CARP para simular roteadores de alta disponibilidade. O ambiente de teste é apresentado na seção 2 e o primeiro experimento descrito na seção 3. A seção 4 versa sobre os trabalhos relacionados e sobre como a pesquisa apresentada nesse trabalho pode ser extendida, restando as considerações finais para a seção 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ão 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, distribuição Suse, versão 11.0, kernel , onde foram criadas duas interfaces do tipo ponte (bridge), br0 e br1, e oito interfaces do tipo tap, numeradas de um a oito. As pontes (bridges) são equipamentos usados para unir várias LANs. No inicial todos os frames que entram por uma das portas da ponte são repassados para as outras portas, mas apenas a interface cujo endereço Media Access Control (MAC) casa com o endereço de destino contido no frame o recebe. O frame é processado e devolvido para a ponte, que memoriza por qual porta a resposta retornou. O próximo frame enviado para o mesmo destino será repassado apenas para a porta memorizada. O Linux provê o recurso de ponte ethernet virtual, com a qual é possível criar instâncias de ponte e associar interfaces à mesma. Cada instância de ponte funciona como foi descrito no parágrafo anterior e todas as interfaces associadas à ponte são equivalentes a portas.

3 As interfaces tap são outro recurso oferecido pelo sistema operacional. Essas interfaces são túneis ethernet entre o espaço do usuário e o espaço do kernel, o que permite que o kernel e as aplicações troquem frames ethernet como se houvesse um enlace entre eles. Das oito interfaces tap criadas, as ímpares foram associadas à ponte br0 e as pares à ponte br1, formando assim duas redes locais de quatro interfaces cada uma. Cada roteador é uma máquina 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áquina virtual está associada a uma das interfaces tap da máquina hospedeira que pertença à ponte br0, enquanto a outra interface está associada a uma das interfaces tap que pertença à ponte br1. A interface da ponte br0 foi configurada com o IP e a interface da ponte br1 foi configurada com IP A interface do director1 associada à ponte br0 foi configurada com o IP e a interface associada à ponte br1 foi configurada com o IP A interface do director2 associada à ponte br0 foi configurada com o IP e a interface associada à ponte br1 foi configurada com o IP A interface do freebsd1 associada à ponte br0 foi configurada com o IP e a interface associada à ponte br1 foi configurada com o IP A interface do freebsd2 associada à ponte br0 foi configurada com o IP e a interface associada à ponte br1 foi configurada com o IP Linux Virtual Server (LVS) é um arranjo (cluster) de servidores Linux que provê serviços de alta disponibilidade e alto desempenho. Essas características são obtidas com o uso das técnicas de failover, redundância com substituição automática, e load balancing, distribuição da demanda para vários servidores. O LVS é composto por Directors e Real Servers. Os Directors fazem o balanceamento de carga e a redundância entre os Real Servers, e funcionam como roteadores virtuais. Os Directors também suportam redundância entre si para aumentar a disponibilidade dos serviços oferecidos pelo LVS. O papel dos Real Servers é prover serviços, exatamente como trabalham os servidores comuns da internet. Figure 1. Gateway comum O balanceamento de carga entre os servidores é feito por um módulo do kernel do Linux, chamado ipvs. O ipvs é um comutador (switcher) de pacotes baseado na pilha TCP/IP. Esse módulo mantém uma tabela, cujas informações são usadas para decidir o destino dos pacotes. A decisão também leva em conta o número de conexões que um Real Server está atendendo, de maneira a deixar a carga nos Real Servers equilibrada. A característica de balanceamento de carga está fora do escopo desse documento, para maiores informações vide [lvs ].

4 Figure 2. Gateway LVS A redundância entre os Directors fica a cargo do protocolo VRRP. O VRRP especifica um protocolo de eleição que atribui dinamicamente a responsabilidade pelo roteador virtual 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ância devem ser configurados para aguardar (BACKUP) até que a instância VRRP esteja sem um roteador VRRP MASTER. O roteador VRRP MASTER faz anuncios periódicos, mantendo todos os roteadores VRRP BACKUP a par da sua presença. Quando o roteador MASTER deixa de enviar ou os roteadores BACKUP deixam de receber os anuncios, é feita uma eleição. O vencedor dessa eleição se torna o novo roteador VRRP MASTER e assume o controle do roteador virtual. Para que um serviço oferecido por um LVS atinja a alta disponibilidade ações precisam ser constantemente tomadas em resposta a eventos, como falhas de software ou hardware. Essas ações são 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 peça fundamental no ambiente de teste é o roteador virtual. No caso do protocolo VRRP o roteador virtual é um LVS, oferecendo o serviço de roteamento (gateway) entre a LAN e a internet, como mostrado na figura 2. O LVS é composto por duas máquinas virtuais, chamadas de director1 e director2. Cada máquina virtual possui duas interfaces de rede. Uma usada para conectar o host à LAN, e outra usada para conectar o host à WAN. Nas máquinas virtuais que rodam o sistema operacional Linux, o software keepalived foi instalado e configurado para fornecer disponibilidade usando o protocolo VRRP. A ferramenta net-snmp foi instalada e configurada de maneira a permitir a coleta de informações. Duas máquinas virtuais rodam o sistema operacional FreeBSD 7.0. Elas tiveram o kernel recompilado para habilitar o protocolo CARP, uma interface CARP foi criada e configurada em cada uma das máquinas. A ferramenta net-snmp foi instalada e configurada de maneira a permitir a coleta de informações. 3. Os Testes Em essência os testes se constituem de um cliente fazendo requisições para e recebendo respostas de um servidor. Essas requisições e respostas tem que passar pelo roteador,

5 que embora seja único do ponto de vista do cliente ou do servidor, é constituído sempre de mais de um roteador (dois por questão de simplicidade). Esse arranjo (cluster) de roteadores tem a função de prover um serviço de alta disponibilidade e/ou alto desempenho. Os experimentos sempre tem o objetivo de demonstrar o funcionamento, prejudica-lo ou interrompe-lo. Durante os mesmos, informações são coletadas de maneira a permitir explicações mais precisas sobre o comportamento observado. Figure 3. Tráfego na pcn0 do freebsd2 Figure 4. Tráfego na pcn0 do freebsd1 O primeiro experimento realizado com o ICMP, usando a ferramenta ping, cuja função é verificar se o compartilhamento de IP entre os roteadores reais está 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ão deve responder quando os dois roteadores estiverem desligados. O endereço compartilhado pelo grupo de roteadores CARP é o , enquanto o endereço compartilhado pela instância VRRP é o Em duas sessões de shell distintas, a ferramenta ping foi chamada para enviar os requisições ICMP e receber as respostas, sendo uma chamada para cada endereço. Enquanto as respostas ICMP estiverem chegando e soubermos que pelo menos um dos roteadores está ativo, o com partilhamento estará funcionando. No início do experimento os dois roteadores Linux estavam funcionais, e verificou-se que os dois endereços respondiam às requisições ICMP. Então a interface eth1 do director1 foi colocada no estado DOWN, verificou-se que o IP compartilhado deixou de responder por um curto espaço de tempo, perdendo três números da sequencia de identificação das respostas ICMP, voltando a responder logo em seguida. O roteador VRRP director2, que

6 estava no estado BACKUP, passou para o estado MASTER, assumindo assim a responsabilidade 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 às requisições ICMP e o director2 voltando para o estado de BACKUP. Os dois roteadores FreeBSD também iniciaram o experimento ambos funcionais e com a interface respondendo às requisições 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 espaço de tempo, perdendo três números da sequencia de identificação das respostas ICMP, voltando a responder logo em seguida. As figuras 3 e 4 mostram o tráfego nas interfaces pcn0 dos roteadores freebsd2 e freebsd1, ambas participantes do grupo CARP. O roteador mestre do grupo CARP responde pela interface Foram enviadas cerca de 65 mil requisições ICMP durante os dias 12, 13, e 14. Cada requisição possuía o tamanho de 1000 bytes, gerando um tráfego aproximado de 8kbps. A área colorida representa o tráfego de requisições e respostas ICMP passando pela interface. Note que as ŕeas coloridas estão alternadas, indicando que o CARP está trabalhando no esquema de alta disponibilidade. 4. Trabalhos relacionados Diferente do CARP, o protoloco VRRP contempla apenas a funcionalidade de disponibilidade. Em [J. Kuo ] é proposta uma extensão do protocolo VRRP para prôver a funcionalidade 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âmetros de interesse e consequentemente novos experimentos. A princípio existem três grupos de experimentos, os de funcionalidade, os de desempenho, e os de segurança. Os de funcionalidade tem a função de determinar se o arranjo está ou não funcionando, e em que situações e configurações ele funciona, ou deixa de funcionar. Os de desempenho servem mensurar em quais características, ou sob que situações um protocolo é mais eficiente que o outro. Os de segurança identificam como o serviço pode ser alterado, forjado, ou interrrompido. Nos experimentos de segurança estão previstas aplicações capazes de gerar pacotes VRRP ou CARP, que serão usadas para atacar os roteadores virtuais do ambiente de teste. 5. Considerações Finais O ambiente de teste se mostrou uma ferramenta útil, preenchendo as expectativas do autor em relação à observação do comportamento do funcionamento dos roteadores de alta disponibilidade. Os dados gerados durante o primeiro experimento, sobre o tráfego das interfaces dos roteadores, ficaram armazenados em um banco de dados, permitindo a geração de gráficos. A recuperação desses dados permitirá no futuro uma análise estatística de características dos protocolos VRRP e CARP, que será resumida na forma de um benchmark.

7 References [carp] common address redundancy protocol books/handbook/carp.html acessado em 30/10/2008. Keepalived acessado em 22/10/2008. [lvs] the linux virtual server project acessado 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.