abr 212015
 

INFRAESTRUTURA

 

O meu ambiente montado em máquinas virtuais, está configurado da seguinte forma:

  1. Host Cliente
    • 2 Interfaces de Rede
    • Eth0: 10.0.2.4/24
    • Eth1: 192.168.56.101/24
  2. Host Storage
    • 2 Interfaces de Rede
    • Eth0: 10.0.2.X/24
    • Eth1: 192.168.56.101/24

Continue reading »

abr 112015
 

Com esse post irei configurar um Load Balance com dois nós utilizando uma configuração ativa/passiva utilizando HAProxy e keepalived. O load balancer fica entre os usuários e 2 servidores web apache, que mantenham o mesmo conteúdo. O load balancer distribui os pedidos para os 2 servidores apache e também verifica o estado dos mesmos, caso um dos servidores esteja fora, os pedidos serão automaticamente redirecionados para o outro servidor. O HAProxy trabalha com sessões, que significa que você pode usá-lo com qualquer aplicação web que faça uso de sessões (fóruns, sites de compras – carrinho, etc). Continue reading »

mar 142015
 

INTRODUÇÃO

 

Os Servidores Web são componentes essenciais em uma rede, onde disponibilizam uma infinidade de serviços, no entanto, são dispositivos eletrônicos e estão sujeitos a falhas, tanto físicas quanto lógicas.

Os responsáveis pelo gerenciamento dos servidores utilizam uma gama de recursos para aumentar e garantir a disponibilidade de acesso aos serviços disponibilizados, como Nobreaks, conexões de rede redundantes, entre outras soluções, mas uma falha pode causar enormes prejuízos e perda da credibilidade de qualquer setor.

Os fabricantes dos equipamentos dedicam uma atenção especial no desenvolvimento de componentes com proteção e que possuam o mínimo de pontos críticos de falhas. Desta forma, é comum encontrarmos em servidores Web conexões redundantes, que se alternam em caso de falhas de conexão, sistemas que registram em dois ou mais discos o mesmo arquivo e fontes de energia que se alternam entre falhas elétricas.

A arquitetura da rede de computadores possui premissas de configuração para reduzir os pontos críticos de falhas, componentes específicos como Nobreaks e geradores à combustível, que visam garantir energia elétrica suficiente para manter operante os Servidores Web e componentes de rede necessários.

Dominar as técnicas de tolerância de falhas torna-se essencial aos desenvolvedores e projetistas para disponibilizar um serviço de qualidade e que possa se recuperar de forma eficiente. O custo-benefício é outro ponto importante que deve ser levado em consideração, pois o investimento em tecnologia de prevenção de falhas é muito bem visto e possui um mercado mundial em crescimento, onde alguns serviços de larga escala estão hospedados em mainframes de alto custo, mas garantem alta disponibilidade.

O conceito de Alta Disponibilidade não se restringe apenas à arquitetura da rede, mas sim a todo e qualquer tipo de falha de disponibilidade como parte física, servidores, discos e rede. Visando garantir Alta Disponibilidade a serviços críticos, surgem sistemas alternativos com hardware acessível, chamado de Cluster, que é um agregado de computadores interligados em rede que possui alta escalabilidade e custo mínimo.

Continue reading »

Alta disponibilidade e alta performance com PostgreSQL 9.0 + Pgpool-II

 Banco de Dados  Comentários desativados em Alta disponibilidade e alta performance com PostgreSQL 9.0 + Pgpool-II
jul 132012
 

Com o novo modelo de replicação do PostgreSQL, torna-se viável a utilização de balanceamento de carga nas operações de leitura, uma vez que os servidores de contingência permanecem em modo read-only (Hot Standby). Até a versão 8.4, o balanceamento de carga só era possível se utilizado juntamente com ferramentas de replicação de terceiros, por exemplo Slony.

Apesar de ser uma replicação Master/Slave assíncrona, a funcionalidade Streaming Replication do PostgreSQL 9.0 garante uma replicação consistente e com atraso praticamente imperceptível para o usuário final. Este comportamento viabiliza a utilização dos servidores de contingência, denominados slaves, como fonte de dados atualizada, reduzindo a carga de leitura sobre o servidor master.

A ferramenta Pgpool-II possui a funcionalidade de balanceamento de carga, que visa distribuir operações de leitura entre os servidores envolvidos. Pensando na popularidade da replicação do PostgreSQL 9.0, o grupo de desenvolvedores do Pgpool-II acrescentou algumas funcionalidades específicas de integração com a nova versão do PostgreSQL, lançando a versão 3.0 do Pgpool-II.

A seguir um cenário possível envolvendo PostgreSQL 9.0 e Pgpool-II 3.0:

Pgpool-II é um software intermediário(middleware) entre a aplicação(frontend) e o servidor PostgreSQL(backend). Age de forma transparente e suporta até 128 nós de replicação. Pode-se considerar as seguintes funcionalidades principais:

Pooling de conexões (Aglomerador de conexões)

  • Mantém conexões abertas com o servidor PostgreSQL, reutilizando-as para novas conexões com as mesmas propriedades.
  • Reduz o overhead causado pela abertura de novos processos (fork) no servidor PostgreSQL.

Fonte: Pgpool Global Development Group

As conexões são fechadas entre o usuário e o Pgpool-II. O usuário devolve a conexão ao pool, mas as mesmas persistem no servidor de banco de dados para reutilização:

Fonte: Pgpool Global Development Group

Replicação

Permite o envio de todas as operações para todos os servidores PostgreSQL envolvidos.

Balanceamento de carga

Distribui consultas de forma aleatória entre os servidores PostgreSQL envolvidos.

Fonte: Pgpool Global Development Group

Consultas paralelas

Particiona tabelas entre os servidores envolvidos, possibilitando a execução de consultas ao mesmo tempo sobre conjuntos diferentes de dados.A funcionalidade de replicação do Pgpool-II não oferece a consistência necessária para a maioria das aplicações. O modelo de replicação é conhecido como Dual-master, sendo baseado em comandos. Desta forma os comandos são executados em cada servidor, tornando possível a existência de bases de dados com informações diferentes quando utilizadas funções que retiram informações do servidor. Por exemplo: now() e random().

A paralelização de consultas não é o foco deste artigo, mais informações sobre estas funcionalidades estão disponíveis no site do projeto http://pgpool.projects.postgresql.org/.

Para o ambiente em questão utiliza-se apenas as füncionalidades de pool de conexões e balanceamento de carga.

A versão 3.0 do Pgpool-II provê a este ambiente, as seguintes características:

  • Failover automático através da detecção de falha no processo monitor do Pgpool-II e execução de comando definido no parâmetro failover_command;
  • Modo de balanceamento Master/Slave específico para Streaming Replication;
  • Interpretação de comandos (parser) para distinguir comandos de alteração e consultas;
  • Verificação do atraso do servidor slave em relação ao master. Caso o atraso exceda o valor definido no parâmetro delay_threshold, as consultas só serão enviadas ao servidor master;
  • Possibilidade de adição de servidores slaves sem reiniciar o serviço do Pgpool.

Para que o próprio servidor do Pgpool-II não seja um ponto único de falha, pode-se configurar uma réplica do servidor. O script pgpool-HA é um recurso do software Heartbeat que pode garantir o serviço do Pgpool-II sempre ativo independente do servidor.

A ferramenta web Pgpooladmin pode auxiliar na administração das funcionalidades do Pgpool-II. Instalada no próprio servidor do Pgpool-II ela facilita tarefas de monitoramento, administração do processo e alterações na configuração. Estas ferramentas auxiliares estão disponíveis no site do projeto http://pgfoundry.org/projects/pgpool/.

A análise de ferramentas de alta disponilidade e desempenho para servidores PostgreSQL é o foco do Treinamento PostgreSQL Alta disponibilidade, promovido pela Dextra Sistemas. Este e outros ambientes são configurados pelos próprios alunos durante treinamento, visando capacitar o aluno na escolha e implantação da tecnologia adequada em ambientes corporativos.

Clusters de alta disponibilidade.

 Clusterweb  Comentários desativados em Clusters de alta disponibilidade.
jan 052012
 

Em vez de montar um único servidor com componentes redundantes, existe também a opção de usar um cluster de alta disponibilidade (chamados de “high-availability clusters” ou “failover clusters”), onde são usados dois servidores completos, onde a única função do segundo servidor é assumir a posição do primeiro em caso de falhas (modo chamado de ativo/passivo), diferente de um cluster com balanceamento de carga, onde os servidores dividem as requisições (ativo/ativo).

Existem diversas soluções para clusters de alta disponibilidade. Entre as soluções abertas, uma das mais usadas é o projeto Linux-HA (High-Availability Linux, disponível no http://www.linux-ha.org), que desenvolve o heartbeat, um daemon responsável por monitorar o status dos servidores do cluster e permitir que o segundo servidor assuma as funções do primeiro em caso de pane.

Cada um dos servidores possui pelo menos duas placas de rede, o que permite que eles sejam simultaneamente ligados à rede e ligados entre si através de um cabo cross-over ou de um switch dedicado. A conexão interna é usada pelo heartbeat para as funções de monitoramento e sincronismo dos processos, de forma que o segundo servidor possa assumir imediatamente a função do primeiro quando necessário, assumindo o endereço IP anteriormente usado por ele.

É comum também o uso de uma terceira interface de rede em cada servidor (ligada a um switch separado), destinada a oferecer uma conexão de backup com a rede. Isso permite eliminar mais um possível ponto de falha, afinal, de nada adianta ter servidores redundantes se o switch que os liga à rede parar de funcionar. 🙂

Em geral, o heartbeat é usado em conjunto com o Drbd (http://www.drbd.org), que assume a função de manter os HDs dos dois servidores sincronizados, como uma espécie de RAID 1 via rede. Ao usar o Drbd, o HD do segundo servidor assume o papel de unidade secundária e é atualizado em relação ao do primeiro em tempo real. Quando o primeiro servidor pára, a unidade de armazenamento do segundo servidor passa a ser usada como unidade primária. Quando o servidor principal retorna, o HD é sincronizado em relação ao secundário e só então ele reassume suas funções.

Outra opção é utilizar uma SAN (veja a seguir) para que os dois servidores compartilhem a mesma unidade de armazenamento. Nesse caso, não é necessário manter o sincronismo, já que os dados são armazenados em uma unidade comum aos dois servidores.

Como pode ver, adicionar componentes redundantes, sejam fontes, HDs ou servidores adicionais aumentam consideravelmente os custos. A principal questão é avaliar se o prejuízo de ter o servidor fora do ar por algumas horas ou dias durante as manutenções, acidentes e imprevistos em geral é maior ou menor do que o investimento necessário.

Um pequeno servidor de rede local, que atende a meia dúzia de usuários em um pequeno escritório dificilmente precisaria de redundância, mas um servidor de missão-crítica (como no caso de um banco) com certeza precisa. Cada nível de redundância adiciona um certo valor ao custo dos servidores, mas reduz em certa proporção o tempo de downtime.

A disponibilidade do servidor é genericamente medida em “noves”. Um nove indica uma disponibilidade de 90%, ou seja, uma situação em que o servidor fica fora do ar até 10% do tempo (imagine o caso de uma máquina instável, que precisa ser freqüentemente reiniciada, por exemplo), o que não é admissível na maioria das situações.

Com dois noves temos um servidor que fica disponível 99%, o que seria uma boa marca para um servidor “comum”, sem recursos de redundância. Por outro lado, uma disponibilidade de 99% significa que o servidor pode ficar fora do ar por até 7 horas e 18 minutos por mês (incluindo todas as manutenções, quedas de energia, operações de backup que tornem necessário parar os serviços e assim por diante), o que é tolerável no caso de uma rede local, ou no caso de um servidor que hospeda um site fora da área de comércio eletrônico, mas ainda não é adequado para operações de missão crítica.

Para adicionar mais um nove, atingindo 99.9% de disponibilidade (o famoso “three nines”), não é possível mais contar apenas com a sorte. É necessário começar a pensar nos possíveis pontos de falha e começar a adicionar recursos de redundância. Entram em cena as fontes redundantes, o uso de uma controladora RAID com suporte a hot-swap, uso de um nobreak com boa autonomia para todo o equipamento de rede, de forma que o servidor continue disponível mesmo durante as quedas de luz, e assim por diante. Afinal, 99.9% de disponibilidade significa que o servidor não fica fora do ar por mais de 43 minutos por mês.

No caso de servidores de missão crítica, qualquer interrupção no serviço pode representar um grande prejuízo, como no caso de instituições financeiras e grandes sites de comércio eletrônico. Passa então a fazer sentido investir no uso de um cluster de alta disponibilidade e em links redundantes, de forma a tentar atingir 99.99% de disponibilidade. Esta marca é difícil de atingir, pois significa que o servidor não deve ficar mais do que 4 minutos e meio (em média) fora do ar por mês, incluindo aí tudo o que possa dar errado.

Como sempre, não existe uma fórmula mágica para calcular o ponto ideal (é justamente por isso que existem consultores e analistas), mas é sempre prudente ter pelo menos um nível mínimo de redundância, nem que seja apenas um backup atualizado, que permita restaurar o servidor (usando outra máquina) caso alguma tragédia aconteça.