Replicação e Alta Disponibilidade

A medida que cresce a exigência por serviços de informação, a disponibilidade deste serviços se torna mais crítica. Se um sistema é crítico para uma corporação, é intuitivo que este sistema exija maior disponibilidade.

O requisito mais importante em uma solução de alta disponibilidade é não existir um Ponto Único de Falha, isto é, deve existir suficiente redundância em equipamentos, sistemas e dados, procedimentos, capacitação técnica e ferramentas que tornem o processo de fail-over de uma aplicação tão suave e tão transparente quanto desejado pelo nível de disponibilidade exigido pela corporação.

Alta Disponibilidade é, por definição, um nível de disponibilidade de sistema que é projetado para atingir ou exceder uma expectativa de um requisito de negócio. (Evan Marcus)

Uma breve história da Alta Disponibilidade (High Availability) em ambiente de T.I.de Mainframes centralizados para sistemas abertos e distribuídos

Um olhar sobre o passado da evolução das aplicações de negócios nos últimos 15 a 20 anos, um número considerável de mudanças chaves pode ser observado. Uma das primeiras a serem observadas foi a lenta e quase inexorável migração das aplicações de mainframes para sistemas aberto tipo Unix. Outra mudança foi a descentralização das aplicações para sistemas departamentais e a adoção de aplicativos de prateleira em detrimento aos de desenvolvimento interno.

Um fator chave a ser notado foi que a simples descentralização diminuiu o impacto total sobre a empresa causado pela indisponibilidade de um único sistema departamental. Ao invés de todos ficarem sem condições de acesso aos sistemas causado pela falha do mainframe, apenas um grupo limitado de pessoas passou a ser afetado pela falha dos sistemas departamentais.

Como é comum, sempre existe perdas e ganhos em toda solução. Distribuir dezenas e até centenas de servidores por toda a corporação, diminuiu o impacto da indisponibilidade de um dado sistema sobre o conjunto da corporação mas aumentou dramaticamente a complexidade e os custos de gerenciamento a medida que os negócios demandavam cada vez mais recursos computacionais.

Primeira geração - métodos e procedimentos para aumentar a disponibilidade

A medida que os servidores proliferaram pelos departamentos e posteriormente foram centralizados em “data centers”, os gerentes de T.I. tornaram-se preocupados com o impacto de uma indisponibilidade nas diversas áreas de negócio das corporações. Estas preocupações levaram ao desenvolvimento de soluções que aumentaram a disponibilidade dos sistemas. Um dos primeiros pontos atacados foram os componentes que maior probabilidade e taxas de falhas. Fabricantes começaram a fornecer sistemas com componentes com redundância, como fontes de alimentação e ventilação. Discos magnéticos são outros componentes com constantes taxas de falhas. Fabricantes de hardware e software responderam com espelhamentos de discos e uso de RAID por software embarcados em controladoras ou executando sob controle do sistema operacional.

De uma forma geral, este desenvolvimento pode ser sumarizado pelo termo da indústria RAS, “reliability, availability e serviceability”. A medida que os componentes se tornaram mais confiáveis, os administradores de sistemas buscaram menor exposição a perda do sistema como um todo. Assim como tinham redundância em componentes individuais, fontes de alimentação, ventiladores e discos, administradores buscaram soluções que criassem sistemas inteiramente redundantes. As primeiras implementações eram apenas sistemas duplicados mas em “estado de espera”, totalmente desconectados dos dados dos sistemas ativos.

O objetivo era reduzir o MTTR, tempo médio para reparo, através de melhor “serviceability”. Mudar para um servidor “pronto para entrar em operação” requeria menor tempo do que reparar o original. Quando um servidor falhava, os dados mantido em discos externos, eram desconectados e conectados ao servidor em espera. Esta ação é conhecida como “failover”. Em um cenário adequadamente projetado, as estações cliente não exigiam mudanças para reconhecer o novo servidor. O novo servidor assumia a identidade do antigo servidor na rede.

A medida que sistemas de armazenamento de dados foram sendo envolvidos, a habilidade de conectar mais de um servidor no sistema de armazenamento de dados foi sendo desenvolvida. Dual-Hosting Systems, isto, suportar dois servidores no mesmo sistemas de discos, um servidor em espera poderia ser colocado online mais rapidamente no evento de uma falha do principal.

Este é um conceito chave que permanece através da evolução das configurações de failover. Reduzir o MTTRecovery, isto é, tempo médio para recuperação é o conceito chave para o nível de disponibilidade.

Armazenamento Dual-Hosting significa que o servidor em espera não precisa mais ser manualmente conectado em caso de falha. Tendo um sistema configurado e pronto para utilizar os dados da aplicação levou ao desenvolvimento de scripts que automatizaram os procedimentos para o servidor assumir a identidade e configuração do servidor original. Estes scripts foram o início do Failover Management Software (FMS).

Agora que era possível automatizar o procedimento de failover, a outra parte do problema se tornou como detectar com confiabilidade a falha do servidor original? Os dois componentes fundamentais para prover disponibilidade das aplicações eram detecção de falha e tempo para recuperação. Desenvolvedores de software responderam com pacotes FMS.

A medida que o tempo passada, novos sistemas abertos ganharam significante poder computacional e capacidade de expansão. Ao invés de simples servidores mono-processados com megabytes de memória, novos sistemas com dezenas e centenas de processadores com gigabytes de memória e terabytes de discos. Este dramático crescimento de capacidade permitiu o início da era da consolidação de aplicações em grandes servidores com o objetivo de reduzir complexidade, gerenciamento e custos de propriedade. Agora havia um sistema enorme provendo todo o poder computacional da corporação. Estes sistemas classe “enterprise” substituíram os servidores departamentais. Neste ponto um ciclo completo. Aplicações críticas agora executavam em um número limitado de grandes sistemas.Entretanto os gerentes de T.I., continuavam desejando muitos da qualidades que levaram a descentralização:

Poder escolher entre diversos fornecedores de sistemas e aplicações

Flexibilidade para implementar, quando desejassem, aplicações baseadas na internet que fossem menos complexas e com maior disponibilidade.

Dispor de gerenciamento centralizado através de todas as plataformas e manter baixo custo de propriedade.

Primeira Geração – Arquitetura de Sistemas de Alta Disponibilidade

Arquitetura Asimétrica

Em uma configuração assimétrica, uma aplicação executa em um servidor primário ou “master server”. Um servidor secundário, dedicado, fica em estado de prontidão para entrar em operação e assumir a identidade do primário. O servidor secundário não é configurado para executar nenhuma outra função. A configuração assimétrica é a mais simples e confiável configuração possível. O servidor secundário fica em estado de prontidão e nenhuma aplicação está executando nele, de forma que não possa forma alguma apresentar problemas com a aplicação principal.

Arquitetura Simétrica

Em uma configuração simétrica, cada servidor é configurado para executar uma aplicação específica e essencialmente fornecer redundância ao seu servidor do par. Em caso de uma falha um dos servidores processará ambas as aplicações.

Em uma análise superficial, a configuração simétrica é de maior benefício em temos de utilização de hardware. Muitos clientes tem objeção ao conceito de um sistema caro ser mantido em estado de prontidão sem nenhuma utilização Porém existe uma séria falha nesta linha de pensamento.

No modelo simétrico, o servidor secundário precisa apenas de tanta capacidade computacional quanto a necessária para o servidor principal. Em caso de failover o poder computacional permanece o mesmo. Em modelo simétrico o servidor que receber a carga do failover terá que suportar o desempenho não de uma aplicação, mas da soma das duas aplicações processando simultaneamente. Em um exemplo simplificado, se cada aplicação necessita um processador, as duas aplicações juntas necessitam dois processadores. Portanto para que os dois servidores tenham capacidade de failover, ambos terão dois processadores, cada um com um processador em espera.

Dificuldades adicionais podem surgir em uma configuração simétrica. Algumas aplicações funcional perfeitamente com múltiplas cópias em um mesmo servidor, outras porém falham. Mesmo duas diferentes aplicações executando no mesmo servidor podem trazer complicações. Cada uma tem requisitos de I/O, memória e recursos diferentes no mesmo sistema.

Arquitetura N to 1

Arquitetura de failover N to 1 é um modo de reduzir a redundância de hardware e ainda prover um servidor em espera. O conceito é baseado na idéia que a ocorrência de múltiplas falhas simultâneas em diferentes servidores é pouco provável. Portanto um único servidor em espera pode atender a possíveis falhas em servidores principais, assumindo a identidade e os serviços do servidor em falha. Em uma configuração N to 1 um servidor redundante dedicado é conectado a todo sistema de armazenamento onde residem os dados dos servidores principais.

O principal problema com a arquitetura N to 1 é a exigência de procedimento de failback, quando o servidor principal é reparado, todos os serviços hospedados no servidor em espera devem ser migrados de volta para o servidor principal. Outra exigência é a conexão do servidor em espera à todos os sistemas de armazenamento de dados de todos os servidores, de forma a garantir o failover.

Granularidade de Failover

Outra importante limitação da primeira geração de sistemas FMS é a granularidade. Este conceito se refere a quais recursos devem sofrer o failover.

A primeira geração de sistemas utiliza a granularidade do servidor. Isto significa que na eventualidade de uma falha de uma aplicação de alta disponibilidade em um servidor, todas as aplicações naquele servidor irão fazer o failover para o servidor secundário.

Esta limitação tem severa implicações de escalabilidade, por exemplo, executando múltiplas instâncias de um banco de dados Oracle em um servidor, a falha de uma única instância causará a migração de todas as instâncias para o servidor secundário e portanto a indisponibilidade durante a migração de todas as instâncias, a despeito do problema haver ocorrido em apenas uma.

Segunda Generação – Alta Disponibilidade em Escala

Escalabilidade é o primeiro e maior benefício obtido na segunda geração de software de alta disponibilidade. A maioria da segunda geração de pacotes de HA suporta grandes quantidade de nós no cluster de HA. A larga adoção de redes de armazenamento de dados - Storage Area Network (SAN) pelas corporações tem tornado possível enormes cluster de HA e os desenvolvedores de software tem tirado vantagem destes recursos.

Service Groups

Um outra característica importante da segunda geração de software de HA é o conceito de Resource Groups ou “Service Groups”.

Uma service group de aplicação é tipicamente composto de múltiplos recursos, alguns de hardware outros de software, cooperando em conjunto para produzir um simples serviço. Por exemplo, um serviço de banco de dados pode ser composto de um endereço lógico IP, um software de DBMS, um file system, volumes lógicos virtualizando dezenas de discos físicos em um sistema de armazenamento de dados e um conjunto de discos físicos sendo gerenciados pelo software de gerenciamento de volume lógicos. Um grande e único nó do cluster pode hospedar um grande número de services groups, de aplicação, cada um provendo um serviço, de forma granular aos clientes da rede. Portanto o conceito de service groups resolveu o problema da granularidade do failover. Quando um único service group falha, ele pode ser migrado independente dos demais do mesmo servidor.

Configurações avançadas de failover

O advento da SAN Storage Area Networks habilitou muitas novas formas de configurações de failover.

Arquitetura N + 1

As funcionalidades da SAN - Storage Area Networks permitiram não somente grandes cluster de HA, mas também e mais importante, a múltipla conectividade de múltiplos servidore ao mesmo sistema de armazenamento de dados, de uma forma que todos os servidores poduram acessar os dados dos demais. O que implicou em remover o conceito de servidor redundante dedicado da equação de alta disponibilidade. Melhor do que uma arquitetura N to 1, agora podemos ter "N + 1".

Em uma arquitetura avançada N +1, um servidor extra no cluster atua simplesmente como um motor de reserva. Quando um servidor falha, a aplicação é reiniciada no servidor de reserva que assume a identidade do servidor em falha. Quando o servidor original é restaurado, ele agora atua como novo servidor de reserva, não exigindo mais o failback para o servidor original. Qualquer servidor do cluster pode atuar como servidor redundante de reserva para qualquer dos nós do cluster. Isto habilita grandes cluster de HA com apenas um servidor de reserva.

Arquitetura N + N

Cluster N-to-N é o coração da arquitetura atual de alta disponibilidade. ,

Arquitetura N-to-N se refere múltiplos services groups executando em múltiplos nós do cluster, cada service group sendo capaz de fazer failover para diferentes nós do cluster.

Por exemplo, imagine um cluster com 4 nós, cada um suportando 3 instâncias críticas de um banco de dados.

No caso de uma falha de qualquer nó, cada um das três instâncias pode ser migrada e reiniciada em diferentes nós, assumindo que o nós tem capacidade para suportar a nova instância.

Mais ainda, o software de monitoramento do cluster de HA conhece a capacidade de cada nó do cluster, estabelece um limite de overload e monitora não apenas a falha de um service group, mas a demanda e a utilização da capacidade de cada nó do cluster, podendo tomar a decisão de migrar uma aplicação em caso de aumento de demanda sobrepujar a capacidade do nó e escolher um determinado nó pela sua adequação a capacidade demandada.

Esta é a evolução lógica do N + 1, onde não mais existe o conceito limitante de servidor em estado de prontidão, ou "standby system" e sim total capacidade do cluster em prontidão ou "standby capacity".

Conclusão

A geração atual de soluções de alta disponibilidade prove um conjunto robusto e flexível de ferramentas para o completo gerenciamento da disponibilidade das aplicações.

Quando fornecidos em conjunto com redes de armazenamento de dados SAN - Storage Area Networks, bem projetadas e bem implementadas, provem a completa automação do failover para os mais diversos cenários de falhas.

Os temos “replication” e “remote mirror” são usado frequentemente de forma intercambeáveis, de certa forma porque seu resultado é muito similar. Replication, ou replicação, é um processo de duplicação de volume de dados primários sobre um conexão IP para um subsistema de armazenamento local ou remoto. Esta cópia redundantes pode ser utilizada pelas aplicações em caso de indisponibilidade dos dados primários. A origem e destino de uma replicação são usualmente separadas por distância geográficas convenientes a fim de garantir sobrevivência a desastres regionais de grande impacto.

Técnicas de replicação tem dois modos básicos: Assíncronas e Síncronas.

Com replicações assíncronas os dados primários e secundários não estão exatamente no mesmo estado, em geral, ocorrem diferenças da ordem de segundos, podendo atingir até minutos, dependendo fundamentalmente da relação entre a capacidade da banda de rede de conexão existente e a taxa de atualização dos dados no sistema primário.

Replicação síncrona os dados primários e secundários estão exatamente no mesmo estado. Usualmente é possível se passar de um modo síncrono para um assíncrono de forma auto-gerenciada pelo próprio sistema de replicação, para evitar por exemplo, atrasos na atualização dos dados no sistema primário causados por variações de capacidade de banda da rede de conexão. Neste casos o sistema modifica se modo de replicação de síncrona para assíncrona preservando em área de log as modificações no sistema primários e a ordem de atualização dos dados de forma a garantir integridade no sistema secundário.

Semelhante a replicação síncrona, Remote Mirroring, ou volumes de dados espelhados remotamente, utilizam redundância para garantir disponibilidade. Um volume de dados espelhado consiste de duas cópias idênticas de dados conectados por Fibre Channel. Ambos os lados de um volume espelhado processam read e write I/O simultaneamente, garantindo que cada cópia uma duplicação em tempo real da outra. Usualmente por motivos de limitações tecnológicas e de custos, as cópias espelhadas são mantida em datacenters separados apenas por alguns kilometros de distância, conectado por redes metropolitana MAN. Se uma indisponibilidade atinge inteiramente a um data center, a outra cópia garante a continuidade do acesso aos dados, no último estado antes da falha, instantaneamente sem interrupção e com mínima indisponibilidade.

Soluções de replicação e espelhamento podem ser implementadas por software hospedados nos servidores, por recursos de banco de dados ou por software embarcados em subsistemas de armazenamento de dados. Cada solução tem seu custos e benefícios, sendo usualmente uma escolha determinada pelo níveis de disponibilidade exigidos no plano de recuperação de desastres.

Deve-se sempre lembrar que tecnologias de replicação ou espelhamento não substituem soluções de backup, são técnicas complementares em um bem projetado plano de recuperação de desastres.

A VERT em seus 11 anos de trabalho implementou e suportou soluções de alta disponibilidade e recuperação de desastres em aplicações missões crítica nos maiores datacenters do Brasil e oferece ao mercado o estado da arte em tecnologia comprovada pelas maiores empresas de todo o mundo.