Balanceamento de Carga (IV)

Balanceamento de Carga por hardware

 Um dispositivo de hardware para balanceamento de carga, também conhecido como um router de camada de 4-7, é uma appliance que é usada para dividir a carga da rede por vários servidores com base em factores tais como a utilização dos processadores, o número de ligações ou o desempenho geral do servidor.

O uso de uma appliance deste tipo minimiza a probabilidade de qualquer servidor ser sobrecarregado e optimiza a largura de banda disponível para cada computador ou terminal. Além disso, o uso de hardware para balancear a carga  pode minimizar quebras de rede, facilitar a priorização de tráfego, fornecer monitorização de aplicações, fornecer autenticação de utilizadores, e ajudar a proteger contra actividades maliciosas tais como ataques de negação de serviço (DoS).

O princípio básico é que o tráfego de rede é enviado para um endereço IP partilhado, chamado IP virtual (VIP) e este está atribuído ao balanceador de carga. Assim que o balanceador de carga recebe uma solicitação neste VIP terá que tomar uma decisão sobre para onde encaminhá-lo e esta decisão normalmente é controlada por um algoritmo de balanceamento de carga, uma verificação do estado do servidor ou um conjunto de regras.

O pedido é então enviado para o servidor apropriado e este produzirá uma resposta que, dependendo do tipo de balanceador utilizado, será enviada ou para o balanceador de carga, no caso de um dispositivo de Camada 7, ou, mais geralmente com um dispositivo de Camada 4, directamente para o utilizador final (normalmente através de seu default gateway).

No caso de um balanceador de carga por proxy, o pedido do servidor web pode ser retornado para o balanceador de carga e manipulado antes de ser enviado de volta para o utilizador. Esta manipulação pode envolver a substituição de conteúdo ou compressão e alguns dispositivos de topo de gama dispõem de total capacidade de processamento de scripts.

Algoritmos de Balanceamento de Carga

Os balanceadores de carga usam diversos tipos de algoritmos para controlar o tráfego com o objectivo específico de distribuir a carga de forma inteligente e / ou maximizar a utilização de todos os servidores no cluster.

Distribuição Aleatória

Numa distribuição aleatória, o tráfego é atribuído a um servidor escolhido aleatoriamente entre o grupo de servidores de destino. Neste caso, podem ser atribuídas muito mais solicitações a um dos servidores, enquanto os outros servidores estão de parados. No entanto, em média, cada servidor recebe uma quota aproximadamente igual de carga devido à selecção aleatória. Embora simples de implementar, pode levar à sobrecarga de um servidor ou mais e simultaneamente à subutilização dos outros.

Ler mais »

Balanceamento de Carga (III)

Antes de mergulharmos mais fundo no abismo de todas as técnicas e algoritmos utilizados no mundo do balanceamento de carga, é importante esclarecer alguns conceitos e noções e dar uma espreitadela à terminologia mais utilizada no balanceamento de carga. O público-alvo deste blog é suposto saber o que é o modelo OSI e, portanto, eu não me vou preocupar com explicações acerca das camadas ou níveis...

Verificação do estado do servidor

A verificação do estado ou saúde do servidor (server health checking ) é a capacidade do balanceador de carga para executar testes aos servidores para determinar se eles estão ou não a fornecer os serviços:

• Ping: Este é o método mais simples, porém não é muito fiável porque o servidor pode responder enquanto, por exemplo, o serviço web está em baixo;

• TCP connect: Este é um método mais sofisticado que pode verificar se um serviço está instalado e a funcionar, como um serviço web na porta 80 ou seja, tentar abrir uma ligação para a porta no servidor real;

• HTTP GET HEADER: Isso irá fazer uma solicitação HTTP GET para o servidor web e, normalmente, verificar se há um cabeçalho resposta, como 200 OK;

• HTTP GET CONTENTS: Isto fará um HTTP GET seguido de uma verificação do conteúdo real em busca de uma resposta correcta. Pode ser útil para verificar uma página dinâmica que retorna 'OK' somente se alguns testes de verificação de aplicação funcionam, por exemplo, validação de consultas a bases de dados. Este recurso só está disponível nalguns dos produtos mais avançados, mas é o método mais fiável para aplicações web porque verifica se a aplicação está de facto disponível.

Balanceamento de carga na camada 2

Balanceamento de carga na camada 2 (também conhecido como agregação de ligações ou agregação de portas) é unir duas ou mais ligações numa única ligação lógica com maior largura de banda. As ligações agregadas também fornecem redundância e tolerância a falhas, se cada uma das ligações seguir um caminho físico diferente.

Ler mais »

Balanceamento de Carga (II)

Balanceamento de Carga no Cliente

Pode ser mais fácil tornar o código e recursos do cliente altamente disponíveis e escaláveis do que fazê-lo para os servidores uma vez que servir conteúdo estático requer menos recursos no servidor. Antes de entrar em detalhes, vamos considerar uma aplicação que precisa ligar-se a servidores na Internet para aceder a dados. Se esta aplicação teórica gerar mais pedidos ao servidor remoto que aqueles que ele pode manipular, vamos precisar de uma solução de balanceamento de carga.

 
Em vez de dar a conhecer ao cliente apenas um servidor a partir do qual pode aceder aos dados, podemos fornecer-lhe muitos servidores, por exemplo s1.meusite.com, s2.meusite.com, e assim por diante. O cliente selecciona aleatoriamente um servidor e tenta aceder aos dados. Se o servidor não estiver disponível, ou não responder num período de tempo pré-definido, o cliente pode escolher outro servidor até conseguir os dados.
Ao contrário das aplicações Web, que armazenam o código do cliente (o código JavaScript ou Flash SWF) no mesmo servidor que fornece dados e recursos, o cliente é independente do servidor e capaz de utilizar servidores de  balanceamento de carga a partir do seu lado (cliente) para obter escalabilidade para a aplicação.

Ler mais »

Balanceamento de Carga (I)

Balanceamento de Carga

O constante crescimento da Internet tem vindo a provocar muitos problemas de desempenho, incluindo tempos de resposta baixos, congestionamento da rede e interrupção dos serviços, quer causada por normal sobrecarga do sistema ou por ataques cibernéticos (DDoS). A solução mais utilizada para minimizar ou resolver esses problemas é o Balanceamento de Carga.
O Balanceamento de Carga é dividir a quantidade de trabalho que um computador tem para fazer entre dois ou mais computadores para que mais trabalho seja feito na mesma quantidade de tempo e, em geral, todos os utilizadores sejam servidos mais rapidamente.
O Balanceamento de Carga (BC) pode também ser descrito como o processo de distribuição de solicitações de serviço por um grupo de servidores. Isso resolve uma série de exigências que se têm tornado cada vez mais importantes nas redes:

• 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 a 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 direccionar as solicitações de serviço ao utilizador final para os servidores que estão menos ocupadas 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 sua capacidade de melhorar a disponibilidade das aplicações. Se uma aplicação ou servidor falha, 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 noutro local.

Na Internet, as empresas cujos websites têm grande volume de tráfego normalmente usam o BC. Quando um único servidor Web não é suficiente para lidar com o tráfego num site então é altura de equacionar a instalação de uma Webfarm que usa várias máquinas na rede actuando como um único servidor.

Ler mais »

Alta Disponibilidade – Redes (II)

Protocolos Redundantes

Se leu os artigos anteriores a sua rede já tem ligações redundantes e portanto resta agora decidir como irão os pacotes seleccionar os caminhos na rede de forma a evitar loops. Isto não é um problema novo; caminhos redundantes foram abordados por protocolos como o Spanning Tree Protocol (STP) na camada 2 e protocolos de endereçamento como o Open Shortest Path First ( OSPF) na Camada 3. Mas esses protocolos podem levar 40 segundos ou mais para convergir e isto é inaceitável para redes críticas, especialmente aquelas com aplicações em tempo real, como VoIP e vídeo.

O STP é um protocolo de gestão de ligações (comutação) que fornece redundância de caminhos, evitando loops indesejáveis na rede. Para uma rede Ethernet funcionar correctamente, apenas pode existir um caminho activo entre duas estações. Este protocolo deve ser utilizado em situações onde se querem ligações redundantes, mas não loops. Ligações redundantes são tão importantes como backups em caso de falha numa rede. Uma falha do router principal activa as ligações de backup para que os utilizadores possam continuar a usar a rede. Sem STP nas bridges e switches, tal falha pode resultar num loop.

Para fornecer redundância de caminhos, o STP define uma árvore de ligações que abarca todos os switches numa rede e força determinados caminhos redundantes a ficarem em estado de espera (bloqueados). Se um segmento de rede no protocolo STP se tornar inacessível, ou se o STP alterar os custos dessa ligação, o algoritmo spanning-tree reconfigura a topologia da árvore de ligações e restabelece a ligação activando um dos caminhos em espera.

Uma versão actualizada do STP é o chamado RSTP (Rapid Spanning Tree Protocol) que reduz o tempo de convergência do STP para cerca de um segundo. Uma das desvantagens deste RSTP (e do STP) é que apenas uma das ligações redundantes pode ser colocada em "espera activa", outra é que quando o STP muda o caminho activo para outro router, então os endereços de gateway dos clientes também têm que mudar.

Para evitar esses problemas, deve ser utilizado o Virtual Router Redundancy Protocol (VRRP) em conjunto com o STP ou o RSTP nos routers, que simula um endereço virtual de encaminhamento para os routers principais e leva cerca de três segundos para fazer o failover.A vantagem de usar VRRP é que se ganha uma maior disponibilidade para o caminho padrão, sem necessidade de configuração de protocolos de encaminhamento dinâmico ou de descoberta de routers em cada host.

Os routers VRRP vistos como um "grupo de redundância" partilham a responsabilidade do encaminhamento de pacotes, como se fossem proprietários do endereço IP correspondente ao gateway padrão configurado nos hosts. Um dos routers VRRP actua como mestre e os outros como backups; se o router mestre falhar, um dos backups torna-se o novo mestre. Desta forma, a redundância do router é sempre garantida, permitindo que o tráfego na rede local seja encaminhado sem depender de um único router.

Mas como o VRRP e o RSTP trabalham de forma independente, é possível que o VRRP designe um router como mestre e o RSTP determine que o caminho para o router de backup é o caminho preferencial. No pior caso, isto significa que se o router backup receber tráfego, vai enviá-lo imediatamente para o router mestre para processamento, acrescentando assim um router ao caminho.
O Common Address Redundancy Protocol (CARP) é uma melhoria sobre o VRRP e é também uma ferramenta para ajudar a criar redundância, por ter vários computadores a criar uma única interface de rede virtual entre eles, de modo que se qualquer máquina falhar, o outro pode responder em vez disso, permitindo ainda um grau de partilha de carga entre os sistemas.

Ler mais »

Alta Disponibilidade – Redes (I)

Dispositivos redundantes

 
As redes actuais são de alta tecnologia e, na maioria dos casos, de alta velocidade. Todos os projectos de WAN (Wide Area Network) necessitam ter uma ligação alternativa em caso de qualquer tipo de falha na ligação principal. Um cenário simples será o de ter uma única ligação T1 para cada escritório remoto ou filial se ligar à sede da empresa. E se essa ligação cair? Como continuar as operações nessas circunstâncias?
 
Criação de redundância é a forma mais comum de aumentar a disponibilidade. Primeiro devemos garantir que há redundância no núcleo do router; CPUs redundantes, fontes de alimentação e ventoinhas podem ser adicionados aos routers e switches montados em rack. Com CPUs redundantes pode-se forçar um failover numa placa enquanto se actualizar a segunda, ao invés de ter que desligar completamente o router para efectuar a actualização.
 
O objectivo das topologias redundantes é eliminar as interrupções da rede causadas por um único ponto de falha. Todas as redes necessitam de redundância para maior fiabilidade e isto é conseguido através de um equipamento fiável e projectos de rede que são tolerantes a falhas e defeitos e as redes devem ser projectadas de modo a convergirem rapidamente contornando a falha.
 
A redundância de rede é um conceito simples de entender; se existir um ponto único de falha e ele falhar, então não há nada a fazer. Se forem colocados métodos de acesso secundários (ou mesmo terciários), então, quando a principal ligação falhar, existirá uma forma alternativa de interligar os recursos e manter a empresa operacional.
 
O ponto crítico é que os equipamentos de rede altamente fiáveis são caros porque são projectados para não falharem e isso geralmente inclui coisas como duas fontes de energia, os CPUs de reserva e sistemas de disco redundantes.
 
Um sistema altamente disponível pode ser construído a partir de produtos de rede menos caros mas esses componentes podem não ter as fontes de alimentação redundantes ou outras características dos equipamentos de alta fiabilidade e, portanto, eles podem falhar com mais frequência do que os equipamentos mais caros. No entanto, se o projecto da rede geral tiver em consideração o facto de que o equipamento pode falhar, então o utilizador final ainda será capaz de aceder à rede, mesmo se algo falhar.
 

Ler mais »