Tweet
Neste artigo vamos dar um overview do Linux Virtual Server (LVS), que é largamente utilizado em sistemas que necessitam de alta disponibilidade, tolerância a falhas e balanceamento de carga.
Por: Alan Cota
Uma breve introdução
A necessidade atual de termos sistemas disponíveis 24x7 (lê-se "24 por 7", ou seja 24 horas durante 7 dias da semana) é cada vez maior e vem crescendo a medida que as aplicações se tornam ainda mais robustas e as corporações cada vez mais dependentes de seus sistemas de TI.
Antes de começarmos a mostrar as funcionalidades do LVS, vamos explicar o que é alta disponibilidade, em suas características e exigências.
Um sistema altamente disponível é um sistema capaz de ser tolerante a eventuais falhas, ou seja, caso um host de seu servidor tenha problemas, automaticamente uma outra máquina tem que "assumir" o lugar desta que falhou, não deixando que o sistema pare de funcionar. Tarefa fácil? Nem tanto. Isso depende de planejamento, investimento em hardware, software, etc.
Neste artigo vamos abordar as funcionalidades do Linux Virtual Server (LVS) e todas as informações necessárias para que você possa começar a planejar seu cluster de alta disponibilidade.
O projeto LVS
O Linux Virtual Server - LVS, é um projeto open source que tem como principal objetivo a criação de clusters de alta disponibilidade para aplicações críticas de TI.
Dentre suas características, podemos mencionar sua performance e escalabilidade flexível. O LVS é um sistema de cluster totalmente transparente para seu usuário final, pois mesmo que você tenha 20 nós em seu cluster, seu usuário interagirá com apenas um endereço de entrada.
Como mostra a figura acima, em um cluster com LVS, nós temos de forma explícita 2 tipos de máquinas, que são importantes ao funcionamento. São elas:
* Load Balancer: Este é o host responsável por receber as requisições vindas dos clientes (usuários finais) e transmití-las aos real servers do cluster. Lógico que este é o ponto fraco de seu cluster, pois você deve estar pensando: "Tudo bem, eu tenho 20 nós em meu cluster. Mais se meu ponto de entrada é apenas 1 máquina, eu tenho uma falha, pois se esta máquina cair, consecutivamente meu cluster cai também!" Realmente está correto! Porém nós vamos ver mais adiante que podemos 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.
* Real Servers: 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 2 real servers.
O LVS é implementado de 3 formas diferentes:
* Virtual Server via NAT
* Virtual Server via IP Tunneling
* Virtual Server via Direct Routing
Vamos explicar cada uma delas:
Virtual Server via NAT
A vantagem do Virtual Server via NAT é que os real server podem executar qualquer sistema operacional que suporta TCP/IP com endereços IP privados e apenas 1 endereço IP é necessário para o Load Balancer.
A desvantagem desta modalidade do LVS é a limitação da escalabilidade, caso o número de real servers em seu cluster passe de 20 servidores. Caso este número seja ultrapassado, o load balancer 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 de processar e enviar pacotes) do load balancer será de 8.93 MBps.
Assumindo que o throughput dos real servers seja de 400Kbps, o load balancer poderá gerenciar até no máximo 22 real servers. Lógico que isso é baseado em suposições e projetado para ambientes realmente enormes, com mais de 20 nós de cluster.
Virtual server via IP tunneling
Nesta modalidade o load balancer ao invés de fazer a comunicação de entrada (request dos usuários) e saída (resposta dos real servers), ele faz apenas um scheduler dos requests, pois a resposta dos real servers é enviada diretamente ao usuário, sem passar pelo load balancer. Desta maneira, o load balancer pode administrar até 100 real servers, sem gerar gargalos no sistema.
Este tipo de LVS é excelente para implementação de sistemas de proxy para a internet altamente disponíveis. Pois o load balancer encaminha as requisições dos clientes para os servidores proxy (real servers) e estes respondem diretamente para os usuários.
Para que isso funcione, todos os servidores do cluster precisam ter o IP Tunneling (Encapsulamento IP) habilitado. E é aqui que "mora o problema", pois habilitar este IP Tunneling pode ser simples para o Linux, mas talvez não seja se você tiver real servers com Solaris, por exemplo. Isto dificulta a utilização de real serves com sistemas operacionais diferentes.
Virtual Server via Direct Routing
Como na modalidade de cluster anterior (Virtual Server via Tunneling), o Direct Routing só processa requisições de entrada, deixando os real servers responderem diretamente para os usuários, utilizando roteamento direto ao invés de IP Tunneling.
A única limitação para este tipo de LVS é que tanto o load balancer quanto os real servers precisam ter uma interface de rede que esteja no mesmo segmento da rede corporativa.
LVS junto com outras ferramentas
Para complementar a implementação, o ambiente LVS pode ser criado junto com outras ferramentas que irão aumentar a segurança e escalabilidade de seu cluster.
Algumas junções interessantes:
Using Piranha to build highly available LVS systems
Using Keepalived to build highly available LVS systems
Using UltraMonkey to build highly available LVS systems
Using heartbeat+mon+coda to build highly available LVS systems
Using heartbeat+ldirectord to build highly available LVS systems
O mais interessante destas implementações é a junção do HeartBeat com o LVS.
O HeartBeat tem como objetivo criar um backup de um servidor, que no nosso artigo podemos ter como base o Load Balancer que é o ponto frágil de nosso 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 caiu 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.
Final
Bem pessoal, este artigo não é um passo-a-passo, mais sim a disponibilização de algumas informações que possam te incentivar a estudar e aprender mais sobre o LVS.
Alguns links úteis:
LVS: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
HeartBeat: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Bom, foi isso. Espero que tenham gostado!
Fonte: vivaolinux
Postado Por: RedDeviL
Por: Alan Cota
Uma breve introdução
A necessidade atual de termos sistemas disponíveis 24x7 (lê-se "24 por 7", ou seja 24 horas durante 7 dias da semana) é cada vez maior e vem crescendo a medida que as aplicações se tornam ainda mais robustas e as corporações cada vez mais dependentes de seus sistemas de TI.
Antes de começarmos a mostrar as funcionalidades do LVS, vamos explicar o que é alta disponibilidade, em suas características e exigências.
Um sistema altamente disponível é um sistema capaz de ser tolerante a eventuais falhas, ou seja, caso um host de seu servidor tenha problemas, automaticamente uma outra máquina tem que "assumir" o lugar desta que falhou, não deixando que o sistema pare de funcionar. Tarefa fácil? Nem tanto. Isso depende de planejamento, investimento em hardware, software, etc.
Neste artigo vamos abordar as funcionalidades do Linux Virtual Server (LVS) e todas as informações necessárias para que você possa começar a planejar seu cluster de alta disponibilidade.
O projeto LVS
O Linux Virtual Server - LVS, é um projeto open source que tem como principal objetivo a criação de clusters de alta disponibilidade para aplicações críticas de TI.
Dentre suas características, podemos mencionar sua performance e escalabilidade flexível. O LVS é um sistema de cluster totalmente transparente para seu usuário final, pois mesmo que você tenha 20 nós em seu cluster, seu usuário interagirá com apenas um endereço de entrada.
Como mostra a figura acima, em um cluster com LVS, nós temos de forma explícita 2 tipos de máquinas, que são importantes ao funcionamento. São elas:
* Load Balancer: Este é o host responsável por receber as requisições vindas dos clientes (usuários finais) e transmití-las aos real servers do cluster. Lógico que este é o ponto fraco de seu cluster, pois você deve estar pensando: "Tudo bem, eu tenho 20 nós em meu cluster. Mais se meu ponto de entrada é apenas 1 máquina, eu tenho uma falha, pois se esta máquina cair, consecutivamente meu cluster cai também!" Realmente está correto! Porém nós vamos ver mais adiante que podemos 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.
* Real Servers: 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 2 real servers.
O LVS é implementado de 3 formas diferentes:
* Virtual Server via NAT
* Virtual Server via IP Tunneling
* Virtual Server via Direct Routing
Vamos explicar cada uma delas:
Virtual Server via NAT
A vantagem do Virtual Server via NAT é que os real server podem executar qualquer sistema operacional que suporta TCP/IP com endereços IP privados e apenas 1 endereço IP é necessário para o Load Balancer.
A desvantagem desta modalidade do LVS é a limitação da escalabilidade, caso o número de real servers em seu cluster passe de 20 servidores. Caso este número seja ultrapassado, o load balancer 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 de processar e enviar pacotes) do load balancer será de 8.93 MBps.
Assumindo que o throughput dos real servers seja de 400Kbps, o load balancer poderá gerenciar até no máximo 22 real servers. Lógico que isso é baseado em suposições e projetado para ambientes realmente enormes, com mais de 20 nós de cluster.
Virtual server via IP tunneling
Nesta modalidade o load balancer ao invés de fazer a comunicação de entrada (request dos usuários) e saída (resposta dos real servers), ele faz apenas um scheduler dos requests, pois a resposta dos real servers é enviada diretamente ao usuário, sem passar pelo load balancer. Desta maneira, o load balancer pode administrar até 100 real servers, sem gerar gargalos no sistema.
Este tipo de LVS é excelente para implementação de sistemas de proxy para a internet altamente disponíveis. Pois o load balancer encaminha as requisições dos clientes para os servidores proxy (real servers) e estes respondem diretamente para os usuários.
Para que isso funcione, todos os servidores do cluster precisam ter o IP Tunneling (Encapsulamento IP) habilitado. E é aqui que "mora o problema", pois habilitar este IP Tunneling pode ser simples para o Linux, mas talvez não seja se você tiver real servers com Solaris, por exemplo. Isto dificulta a utilização de real serves com sistemas operacionais diferentes.
Virtual Server via Direct Routing
Como na modalidade de cluster anterior (Virtual Server via Tunneling), o Direct Routing só processa requisições de entrada, deixando os real servers responderem diretamente para os usuários, utilizando roteamento direto ao invés de IP Tunneling.
A única limitação para este tipo de LVS é que tanto o load balancer quanto os real servers precisam ter uma interface de rede que esteja no mesmo segmento da rede corporativa.
LVS junto com outras ferramentas
Para complementar a implementação, o ambiente LVS pode ser criado junto com outras ferramentas que irão aumentar a segurança e escalabilidade de seu cluster.
Algumas junções interessantes:
Using Piranha to build highly available LVS systems
Using Keepalived to build highly available LVS systems
Using UltraMonkey to build highly available LVS systems
Using heartbeat+mon+coda to build highly available LVS systems
Using heartbeat+ldirectord to build highly available LVS systems
O mais interessante destas implementações é a junção do HeartBeat com o LVS.
O HeartBeat tem como objetivo criar um backup de um servidor, que no nosso artigo podemos ter como base o Load Balancer que é o ponto frágil de nosso 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 caiu 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.
Final
Bem pessoal, este artigo não é um passo-a-passo, mais sim a disponibilização de algumas informações que possam te incentivar a estudar e aprender mais sobre o LVS.
Alguns links úteis:
LVS: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
HeartBeat: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Bom, foi isso. Espero que tenham gostado!
Fonte: vivaolinux
Postado Por: RedDeviL