Avançar para o conteúdo principal
BlogServiços de Consultoria em NuvemAlta Disponibilidade - O que precisa de saber

Alta Disponibilidade - O que você precisa saber

alta disponibilidade

Olá, sou o Mike-Solutions Engineer na Linode. Se está curioso sobre a Alta Disponibilidade, este posto deverá ajudar a esclarecer as coisas. Aproveite!

No mundo hiper-conectado de hoje, os consumidores esperam ter acesso aos serviços instantaneamente, a qualquer momento e de qualquer lugar. Além disso, você precisa pensar sobre o tempo de atenção - você sabe que tem cerca de 30 segundos para captar a atenção de um consumidor antes que ele siga em frente? Por este motivo, é crucial implementar alta disponibilidade (HA) em suas aplicações. Neste post de blog, vou definir HA, explicar os vários componentes que vão para uma arquitetura HA básica e examinar como construir uma infraestrutura HA simples para uma aplicação web.

O que é Alta Disponibilidade?

Primeiro, vamos definir a disponibilidade: a percentagem do tempo total que um sistema informático está acessível para uma utilização normal. Por outras palavras, a disponibilidade descreve até que ponto um sistema está em linha e acessível. Pode-se supor que a disponibilidade óptima é 100%, mas isso é impossível. 

É aqui que entra a Alta Disponibilidade. Os sistemas HA são aqueles com disponibilidade on-line variando de 99,9 a 99,999 por cento do tempo (ver Tabela 1). Um HA ideal a alcançar é 99,999%-"cinco noves" - o que constitui cerca de cinco minutos de inatividade por ano.

Alta Disponibilidade pelos Números

Os designers de sistemas tentam alcançar o maior HA possível. O HA pode ser aumentado através da tolerância a falhas. Isto envolve a construção de diferentes características do sistema que permitem um funcionamento contínuo no caso de uma falha do sistema. Exemplos de características de tolerância a falhas são a redundância e a replicação - mais sobre estas a seguir.

Como é que funciona a Alta Disponibilidade?

Há muitas características que podem ir para a construção de um sistema HA ideal. Estes componentes devem ser integrados em conjunto, continuamente monitorizados e capazes de uma recuperação rápida. Estes incluem:

  • exemplo de redundância,
  • equilíbrio de carga,
  • falha de hardware e software através de componentes díspares,
  • replicação de dados, e
  • escalada automática.

Estas características são explicadas de forma mais detalhada no diagrama abaixo:

Como Avaliar a Disponibilidade do Seu Sistema

Quer determinar a disponibilidade da infraestrutura da sua nuvem? É baseado em três critérios:

  • o seu tamanho e alcance
  • inclusão de componentes de hardware
  • dimensionamento antecipado para satisfazer a procura futura

Após a avaliação, você pode decidir revisar sua infraestrutura. Aconselho-o a rever cada critério separadamente primeiro, e depois colectivamente. A revisão da sua arquitectura pode incluir ferramentas virtuais, como por exemplo:

  • novos servidores secundários e add-ons
  • Utilitários de software habilitador de HA
  • hardware suplementar

Como é que o equilíbrio de carga afecta o HA?

O balanceamento de carga distribui inteligentemente o tráfego de entrada por um ou mais servidores. Estas ferramentas, tais como os NodeBalancers da Linode, foram concebidas para serem "ajustadas e esquecidas". Permitem que os servidores backend sejam adicionados ou removidos sem problemas, sem que os utilizadores finais se deparem com qualquer tempo de inactividade.

Um equilibrador de carga típico monitoriza um endereço IP para pedidos recebidos e digitaliza-o em busca de sobrecarga ou falha. Se detectado, segue regras configuradas (incluindo IP Failover atribuído) para enviar tráfego para um nó mais prontamente disponível. Desta forma, o tráfego é distribuído uniformemente e os utilizadores finais não se deparam com interrupções no serviço.

Quase todas as aplicações podem beneficiar do equilíbrio de carga. É um componente chave para escalonar nos utilizadores, ao mesmo tempo que se alcança redundância.

O que é exactamente o Failover?

O failover é a pedra angular dos sistemas HA. Com o failover, as tarefas são automaticamente reencaminhadas para um servidor secundário ou terciário, em caso de paragem planeada ou acidental. 

O Failover compreende soluções de hardware e software, tais como adicionar servidores de bases de dados espelhados a um cluster, ou configurar um endereço IP de modo a encaminhar o tráfego para o servidor mais disponível. 

Como funciona a Replicação do Sistema de Ficheiros?

Num cluster HA, cada servidor (por exemplo, aplicação, base de dados, sistema de ficheiros) será configurado para espelhar outros servidores, sendo os dados armazenados replicados automaticamente entre todos os outros servidores da arquitectura. Os pedidos recebidos serão capazes de aceder aos dados, independentemente do servidor em que residem. Isto resulta numa experiência ininterrupta para o utilizador final. 

O software Network File System (NFS) como GlusterFS, LizardFS, e HDFS pode agregar vários tipos de servidores num único sistema de ficheiros de rede paralelo. Em caso de falha de um servidor, o software NFS redireciona automaticamente os pedidos dirigidos a um servidor online, cujos ficheiros e dados foram espelhados e sincronizados.

E quanto à base de dados?

O objectivo aqui é conseguir uma replicação síncrona - os seus dados são continuamente copiados de um servidor de base de dados para outro. Isto resulta numa distribuição uniforme dos dados aos utilizadores finais, sem perturbações. Pode conseguir isto através das seguintes plataformas de software, em qualquer combinação:

Onde se encaixa a Seamless Scaling?

Precisa que o seu sistema cresça e seja receptivo aos utilizadores finais. Cada sistema é diferente, por isso não existe uma plataforma única, de tamanho único, para escalar um sistema enquanto mantém o HA. Necessita de escolher a plataforma de implementação distribuída certa para si. Alguns exemplos são:

  • SaltStack: uma plataforma de gestão de configuração escalável e flexível para a automatização de nuvens por eventos
  • Chef: software que escreve receitas de configuração do sistema em Erlang ou Ruby
  • Puppet: software que gere a configuração de sistemas Unix e Microsoft Windows

Vejamos um exemplo

Para ajudar a colocar as coisas em perspectiva, elaborámos uma lista de medidas que poderíamos tomar para alcançar HA. Isto implica conceber um sistema com um único equilibrador de carga, três servidores web/aplicativos, e três servidores de bases de dados. Atenção: são necessários pelo menos três servidores DB para estabelecer o quorum de dados dentro das arquitecturas HA.

  1. Uma vez montado o cluster, configure os servidores web/app para replicar os dados do site usando o seu NFS de escolha.
    1. Isto activará o equilibrador de carga, e atribuirá tráfego entre os três nós da web/app, removendo automaticamente quaisquer nós que tenham falhado.
  2. Criar uma configuração MySQL Master-Master usando Percona XtraDB.
    1. Designar um IP privado flutuante, gerido por Keepalived, para funcionar como failover .
  3. Apontar todos os servidores web/app para o IP privado flutuante, de modo a que este se desloque automaticamente para um nó de base de dados em linha, no caso de qualquer servidor DB ser desligado.

Voilá! Isto resultará numa perturbação mínima para os utilizadores finais porque o acesso ao servidor permanece disponível, apesar de qualquer ponto de falha.

Conclusão

Então, quer estabelecer um sistema HA?

É importante saber que isto requer um planeamento cuidadoso. Primeiro, é necessário calcular o custo real do tempo de paragem. Isto varia consoante a organização e desempenhará um papel fundamental na determinação do tempo de paragem num determinado ano é aceitável. Esta informação é fundamental para determinar a combinação certa de configuração de hardware, ferramentas de software, e manutenção do sistema.

A adição de componentes de hardware a um sistema pode impedir o HA. Anexar um servidor ao seu cluster acaba por aumentar o risco de falha, pelo que deve ser feito correctamente. 

É verdade - uma arquitectura de sistema simplificada é, bem, mais simples. Mas, não vem sem compromisso. Este tipo de sistema deve ser retirado da rede para cada actualização do sistema. Esta perturbação esporádica irá enfraquecer a disponibilidade do sistema. O mesmo é verdade para o software. Um único erro, como um erro tipográfico tolo ou uma instalação deficiente, irá comprometer o HA.

O sistema HA ideal - um sistema que permanece online mais de 99,999 por cento do tempo integra redundância, failover, e monitorização, enquanto adapta hardware, rede, sistema operativo, middleware, e correcções e actualizações de aplicações online, em tempo real, sem perturbação do utilizador final.


Comentários (7)

  1. Author Photo

    What about geographic redundancy? Node balancers no yet supports nodes in other data centers. How I can achieve this?

    • pwoods

      You’re right, Javier: our NodeBalancers offer redundancy for Linodes within the same data center. For geographic redundancy, we’d recommend using a CDN service, such as Cloudflare, Fastly, Limelight, or similar. You could set this up yourself by using a service such as HAProxy. There’s a great Community Questions post that covers this in further detail: https://www.linode.com/community/questions/17647/can-i-use-nodebalancers-across-data-centers

      Otherwise, we’ve added this as a feature request for future NodeBalancer development to our internal tracker. If we make any changes, we’ll be sure to post about them here on our blog.

  2. Author Photo

    What about geographic redundancy?

    • pwoods

      Hi there! I just responded to a similar comment above. In short, we recommend a CDN for geographic redundancy, though you could use HAProxy if you’d like to set this up yourself.

  3. Author Photo

    Thanks for writing the awesome article. I really loved the stuff. You see, I have been using Linode server from past 2 years and it’s been working pretty awesome for me. Although, it’s not the conventional hosting server. Instead it’s the managed hosting instance which is being managed by Cloudways.
    I hardly remember any downtime. So, am I consistently experiencing the high availability? or Cloudways is playing it’s role.

    • Author Photo

      Thanks for the compliment, Marilu! There are a few things that can cause uptime, such as the dependability of the hosts or the host’s software. In your case, it could be both. In regards to Cloudways’ service, I suggest reaching out to their support as they would be in a better position to answer that question.

Deixe uma resposta

O seu endereço de correio electrónico não será publicado. Os campos obrigatórios estão marcados com *