No mundo real, pode haver situações em que um mergulho no desempenho de seus servidores pode ocorrer a partir de eventos que vão desde um pico repentino de tráfego até uma queda repentina de energia. Pode ser muito pior e os seus servidores podem ficar aleijados – independentemente de as suas aplicações estarem alojadas na nuvem ou numa máquina física. Tais situações são inevitáveis. No entanto, ao invés de esperar que isso não ocorra, o que você deve realmente fazer é se preparar para que seus sistemas não encontrem falhas.
A resposta ao problema é o uso da configuração ou arquitetura de Alta Disponibilidade (HA). A arquitetura de alta disponibilidade é uma abordagem de definição dos componentes, módulos ou implementação de serviços de um sistema que garante um ótimo desempenho operacional, mesmo em momentos de altas cargas. Embora não existam regras fixas de implementação de sistemas HA, geralmente existem algumas boas práticas que devem ser seguidas para que você obtenha o máximo dos mínimos recursos.
Por que você precisa disso?
Deixe-nos definir o tempo de inatividade antes de avançarmos. O downtime é o período de tempo em que o seu sistema (ou rede) não está disponível para uso, ou não responde. O downtime pode causar enormes perdas a uma empresa, pois todos os seus serviços são colocados em espera quando os seus sistemas estão parados. Em agosto de 2013, a Amazon caiu por 15 minutos (tanto na web quanto nos serviços móveis), e acabou perdendo mais de US$ 66.000 por minuto. Esses são números enormes, mesmo para uma empresa do tamanho da Amazon.
Existem dois tipos de paradas – programadas e não programadas. Um downtime programado é resultado de manutenção, que é inevitável. Isto inclui a aplicação de correções, atualização de softwares ou mesmo alterações no esquema do banco de dados. Um tempo de inatividade não programado é, no entanto, causado por algum evento imprevisto, como falha de hardware ou software. Isto pode acontecer devido a quedas de energia ou falha de um componente. Os tempos de parada programados são geralmente excluídos dos cálculos de desempenho.
O objetivo principal da implementação da arquitetura de Alta Disponibilidade é garantir que o sistema ou aplicativo esteja configurado para lidar com diferentes cargas e diferentes falhas com o mínimo ou nenhum tempo de inatividade. São múltiplos componentes que o ajudam a alcançar isto, e iremos discuti-los brevemente.
Como é medida a disponibilidade?
As organizações que planeiam utilizar plenamente uma infra-estrutura de nuvem também devem ser capazes de satisfazer as exigências de disponibilidade 24/7. A disponibilidade pode ser medida como a percentagem de tempo que os sistemas estão disponíveis.
x = (n – y) * 100/n
Onde n é o número total de minutos num mês civil e y é o número total de minutos que o serviço não está disponível num determinado mês civil. Alta disponibilidade refere-se simplesmente a um componente ou sistema que está continuamente operacional por um período de tempo desejavelmente longo. A disponibilidade ampla mas quase impossível de alcançar o padrão de disponibilidade de um produto ou sistema é referida como “cinco 9s” (99,999 por cento) de disponibilidade. A alta disponibilidade é um requisito para qualquer empresa que espera proteger seu negócio contra os riscos causados por uma interrupção do sistema. Esses riscos podem levar a perdas de receita de milhões de dólares.
Valora realmente o dinheiro?
O fato de que optar por uma arquitetura de alta disponibilidade lhe dá maior desempenho é bom, mas isso também tem um grande custo. Você deve se perguntar se você acha que a decisão é justificada do ponto de vista financeiro.
É preciso decidir se o tempo de atividade extra vale realmente a quantia de dinheiro que tem de ser investida. Você deve se perguntar quão prejudiciais os tempos de inatividade podem ser para a sua empresa e quão importantes são os seus serviços na gestão do seu negócio.
Como podemos conseguir isso?
Agora que você tenha decidido ir com ele, vamos discutir as formas de implementá-lo. Não-intuitivamente, adicionar mais componentes a um sistema não ajuda a torná-lo mais estável e alcançar alta disponibilidade. Na verdade, pode levar ao oposto, pois mais componentes aumentam a probabilidade de falhas. Projetos modernos permitem a distribuição das cargas de trabalho em múltiplas instâncias, como uma rede ou um cluster, o que ajuda na otimização do uso de recursos, maximizando a saída, minimizando os tempos de resposta e evitando a sobrecarga de qualquer sistema no processo conhecido como balanceamento de carga. Também envolve mudar para um recurso standby como um servidor, componente ou rede em caso de falha de um ativo, conhecido como sistemas Failover.
Uso de múltiplos servidores de aplicação:
Imagine que você tem um único servidor para prestar seus serviços e um súbito pico no tráfego leva à sua falha (ou o bloqueia). Em tal situação, até que seu servidor seja reiniciado, nenhuma outra solicitação pode ser atendida, o que leva a um downtime.
A solução óbvia aqui é implantar sua aplicação em múltiplos servidores. Você precisa distribuir a carga entre todos eles, para que nenhum deles fique sobrecarregado e a saída seja ótima. Você também pode implantar partes da sua aplicação em diferentes servidores. Por exemplo, pode haver um servidor separado para lidar com e-mails ou um servidor separado para processar arquivos estáticos como imagens (como uma Rede de Entrega de Conteúdo).
Bases de Dados de Escalonamento:
Bases de Dados são as mais populares e talvez uma das maneiras mais simples conceitualmente para salvar dados de usuários. Deve-se lembrar que as bases de dados são tão importantes para os seus serviços quanto os seus servidores de aplicações. As bases de dados rodam em servidores separados (como o Amazon RDS) e são propensas a travamentos também. O pior é que as falhas nos bancos de dados podem levar à perda de dados de usuários, o que pode ser caro.
Redundância é um processo que cria sistemas com altos níveis de disponibilidade, alcançando a detectabilidade de falhas e evitando falhas de causas comuns. Isto pode ser alcançado através da manutenção de escravos, que podem intervir se o servidor principal falhar. Outro conceito interessante de escalonamento de bancos de dados é o sharding. Um fragmento é uma partição horizontal em uma base de dados, onde linhas da mesma tabela que é então executada em um servidor separado.
Localizações geográficas diversificadas:
Escalar suas aplicações e então suas bases de dados é um grande passo à frente, mas e se todos os servidores estão na mesma localização física e algo terrível como um desastre natural afeta o centro de dados no qual seus servidores estão localizados? Isto pode levar a tempos de inatividade potencialmente enormes.
É, portanto, imperativo que você mantenha seus servidores em locais diferentes. A maioria dos serviços web modernos permitem que você selecione a localização geográfica de seus servidores. Você deve escolher sabiamente para garantir que seus servidores estejam distribuídos em todo o mundo e não localizados em uma área.
Neste post, eu tentei tocar nas idéias básicas que formam a idéia da arquitetura de alta disponibilidade. Em última análise, é evidente que nenhum sistema pode resolver todos os problemas. Portanto, você precisa avaliar cuidadosamente a sua situação e decidir quais as opções que melhor lhes convêm. Aqui está a esperança de que isto o introduziu ao mundo da arquitectura de alta disponibilidade e o ajudou a decidir como fazer isto por si mesmo.
Quais são as melhores práticas?
Para evitar falhas do sistema e manter os tempos de paragem planeados e não planeados à distância, o uso de uma arquitectura de alta disponibilidade (HA) é altamente recomendado, especialmente para aplicações de missão crítica. Os especialistas em disponibilidade insistem que, para que qualquer sistema esteja altamente disponível, suas partes devem ser bem projetadas e rigorosamente testadas. A concepção e subsequente implementação de uma arquitectura de alta disponibilidade pode ser difícil dada a vasta gama de software, hardware e opções de implementação. No entanto, um esforço bem sucedido normalmente começa com requisitos comerciais claramente definidos e compreendidos de forma abrangente. A arquitetura escolhida deve ser capaz de atender aos níveis desejados de segurança, escalabilidade, desempenho e disponibilidade.
A única forma de garantir que os ambientes de computação tenham um nível desejável de continuidade operacional durante as horas de produção é concebendo-os com alta disponibilidade. Além de projetar corretamente a arquitetura, as empresas podem manter aplicações cruciais online, observando as melhores práticas recomendadas para alta disponibilidade.
- Backups, Recuperação e Replicação de Dados
A marca de um bom plano de proteção de dados que protege contra falhas do sistema é uma sólida estratégia de backup e recuperação. Dados valiosos nunca devem ser armazenados sem backups adequados, replicação ou a capacidade de recriar os dados. Todo centro de dados deve planejar a perda ou corrupção dos dados com antecedência. Erros nos dados podem criar problemas de autenticação do cliente, prejudicar as contas financeiras e, consequentemente, a credibilidade da comunidade empresarial. A estratégia recomendada para manter a integridade dos dados é criar um backup completo do banco de dados primário e depois testar incrementalmente o servidor fonte para corrupção dos dados. A criação de backups completos está na vanguarda da recuperação de falhas catastróficas do sistema.
- Clustering
Even com a mais alta qualidade de engenharia de software, todos os serviços da aplicação estão fadados a falhar em algum momento. Alta disponibilidade é tudo sobre a entrega de serviços de aplicação, independentemente de falhas. O clustering pode fornecer serviços de aplicação instantâneos em caso de falha. Um serviço aplicacional que está ‘ciente do cluster’ é capaz de chamar recursos de múltiplos servidores; ele cai de volta para um servidor secundário se o servidor principal ficar offline. Um cluster de Alta Disponibilidade inclui vários nós que compartilham informações através de grades de memória de dados compartilhados. Isto significa que qualquer nó pode ser desconectado ou desligado da rede e o resto do cluster continuará a operar normalmente, desde que pelo menos um único nó esteja totalmente funcional. Cada nó pode ser atualizado individualmente e reingressado enquanto o cluster opera. O alto custo de aquisição de hardware adicional para implementar um cluster pode ser mitigado pela configuração de um cluster virtualizado que utiliza os recursos de hardware disponíveis.
- Balanceamento de carga da rede
Balanceamento de carga é uma forma eficaz de aumentar a disponibilidade de aplicações críticas baseadas na web. Quando são detectadas instâncias de falha no servidor, elas são substituídas sem problemas quando o tráfego é redistribuído automaticamente para servidores que ainda estão em execução. O balanceamento de carga não só leva a uma alta disponibilidade, mas também facilita a escalabilidade incremental. O balanceamento de carga de rede pode ser realizado através de um modelo ‘pull’ ou ‘push’. Ele facilita níveis mais altos de tolerância a falhas em aplicações de serviço.
- Fail Over Solutions
A arquitectura de alta disponibilidade consiste tradicionalmente num conjunto de servidores frouxamente acoplados que têm capacidades de failover. O failover é basicamente um modo operacional de backup no qual as funções de um componente do sistema são assumidas por um sistema secundário, caso o principal fique offline, seja por falha ou por tempo de inatividade planejado. Um ‘cold failover’ ocorre quando o servidor secundário só é iniciado após o servidor primário ter sido completamente desligado. Um ‘hot failover’ ocorre quando todos os servidores estão funcionando simultaneamente, e a carga é totalmente direcionada para um único servidor em um determinado momento. Em ambos os cenários, as tarefas são automaticamente descarregadas para um componente do sistema em standby, para que o processo permaneça o mais perfeito possível para o usuário final. O failover pode ser gerenciado via DNS, em um ambiente bem controlado.
- Redundância geográfica
A redundância geográfica é a única linha de defesa quando se trata de evitar falhas de serviço diante de eventos catastróficos, como desastres naturais que causam interrupções no sistema. Como no caso da geo-replicação, múltiplos servidores são implantados em locais geográficos distintos. Os locais devem ser distribuídos globalmente e não localizados em uma área específica. É crucial executar pilhas de aplicações independentes em cada um dos locais, de modo que, caso haja uma falha em um local, o outro possa continuar funcionando. Idealmente, essas localizações devem ser completamente independentes umas das outras.
- Planear para falhas
Embora a aplicação das melhores práticas para alta disponibilidade seja essencialmente o planejamento para falhas; existem outras ações que uma organização pode tomar para aumentar sua preparação no caso de uma falha no sistema que leve a um tempo de inatividade. As organizações devem manter dados sobre falhas ou consumo de recursos que possam ser usados para isolar problemas e analisar tendências. Esses dados só podem ser coletados através do monitoramento contínuo da carga de trabalho operacional. Um help desk de recuperação pode ser colocado em prática para reunir informações sobre problemas, estabelecer histórico de problemas e iniciar resoluções imediatas de problemas. Um plano de recuperação não só deve ser bem documentado como também testado regularmente para garantir a sua praticidade ao lidar com interrupções não planeadas. O treinamento do pessoal em engenharia de disponibilidade irá melhorar suas habilidades na concepção, implantação e manutenção de arquiteturas de alta disponibilidade. Políticas de segurança também devem ser implementadas para diminuir a incidência de interrupções do sistema devido a violações de segurança.
Exemplo: FileCloud Arquitetura de Alta Disponibilidade
Digrama de acompanhamento explica como os servidores FileCloud podem ser configurados para Alta Disponibilidade para melhorar a confiabilidade do serviço e reduzir o tempo de inatividade. Clique aqui para obter mais detalhes.