A diferença entre Alta Disponibilidade e Disaster Recovery
Neste artigo vamos abordar a diferença entre Alta Disponibilidade e Disaster Recovery. Qualquer bom sistema direcionado ao público ou à empresa atualmente deve ser construído para esperar o inesperado. Nenhum sistema é perfeito e, em algum momento, acontecerá algo que tornará o sistema inoperante como por exemplo: incêndio, furacão, terremoto, atualizações, erro humano – a lista continua. Além disso existem tantas maneiras possíveis de falha dos sistemas, que é necessário projeta-los com a expectativa de que a falha ocorra em algum momento.
Existem dois tópicos relacionados, mas muitas vezes confusos e que atendem à arquitetura do sistema que diminuem o risco contra falhas: alta disponibilidade (HA) e Disaster Recovery (DR). A alta disponibilidade, simplificando, está eliminando pontos únicos de falha e o disaster recovery é o processo de retornar um sistema ao estado operacional quando estiver inoperante. Em essência, o disaster recovery é acionado quando a alta disponibilidade falhar.
Alta disponibilidade
Como mencionado, a Alta Disponibilidade trata da eliminação de pontos únicos de falha, portanto implica redundância. Existem basicamente três tipos de redundância implementados na maioria dos sistemas: hardware, software e ambiental.
A redundância de hardware
foi uma das primeiras maneiras de introduzir alta disponibilidade na computação. Antes de a maioria dos aplicativos estar conectada à Internet, eles atendiam às empresas em uma LAN. Esses servidores não precisavam da escala que os aplicativos modernos fazem, onde pode haver milhares de conexões simultâneas com demanda 24/7. Esses aplicativos, no entanto, forneciam dados críticos para os negócios e, portanto, precisavam de hardware tolerante a falhas. Pontos únicos de falha foram eliminados pelos fabricantes que construíram servidores que tinham:
- Armazenamento redundante com RAID ou tecnologia semelhante, o que garantiu que os dados fossem gravados para leitura em vários discos físicos. Isso evitou a perda de dados e o tempo de inatividade.
- A energia redundante, normalmente na forma de várias fontes de alimentação, permitiu que os administradores conectassem servidores a fontes de energia independentes, para que os servidores pudessem permanecer ligados se houvesse perda de energia de uma fonte.
- Correção de erros, como ECC RAM, que permitiam a recuperação de dados em caso de corrupção de dados no armazenamento.
- Rede redundante, como várias NICs conectadas a redes independentes para garantir que um servidor permaneça on-line em caso de falhas na rede.
A redundância de software
Além disso os designers de aplicação trabalharam para garantir que os próprios aplicativos possam tolerar falhas em um sistema. Seja falha de hardware, erros de configuração ou qualquer outro motivo que pudesse derrubar uma parte do software. Algumas maneiras pelas quais isso foi realizado incluem:
- Tecnologias de cluster, como clusters de banco de dados, que distribuem cargas de trabalho por vários servidores.
- Apatridia em aplicativos para dimensionamento rápido e alta disponibilidade fácil de configurar.
- Balanceamento de carga com monitoramento de aplicativos por meio de análises de integridade. Isso permite que solicitações recebidas de aplicativos sejam roteadas para nós de aplicativos íntegros, além de gerar eventos para manipular proativamente as falhas.
- Sistemas de autocorreção que movimentam cargas de trabalho ou alocam capacidade adicional quando falhas são detectadas.
Com o surgimento da computação em nuvem, os provedores de nuvem levaram a alta disponibilidade a um nível totalmente novo para incluir redundância do ambiente em larga escala com:
- A redundância de hardware em um rack de servidor nos datacenters para incluir rede, energia e armazenamento de hardware que permitem aos usuários distribuir cargas de trabalho para reduzir pontos únicos de falha.
- A redundância de data center em uma região geográfica, geralmente chamada de “zona de disponibilidade”, permite que os usuários executem aplicativos em data centers separados, localizados geograficamente próximos um do outro.
Todos esses domínios (hardware, software e ambiental) buscam resolver o mesmo problema básico, envidando esforços para eliminar pontos únicos de falha. Os resultados agora fornecem contratos de alto nível de serviço (SLAs) que medem o tempo de inatividade não planejado em menos de 10 segundos por um período de 24 horas.
Disaster Recovery
Continua onde a alta disponibilidade falha. O disaster recovery pode ser tão simples quanto restaurar a partir de um backup, mas também pode ser muito complexa, dependendo de dois fatores: o RTO (Recovery Time Objective) e o RPO (Recovery Point Objective).
Aqui você pode consultar por que ter um plano de Disaster Recovery.
Um objetivo de tempo de recuperação é a quantidade máxima de tempo que um sistema pode ficar inativo antes de ser recuperado para um estado operacional. Para alguns sistemas, esse objetivo de tempo de recuperação pode ser medido em horas ou até dias, mas, para sistemas mais críticos, os objetivos de tempo de recuperação geralmente são medidos em segundos.
Um objetivo do ponto de recuperação é a quantidade de perda de dados, medida no tempo, que é tolerável em um desastre. Para alguns sistemas, a perda de dados de um dia pode ser aceitável, enquanto para outros sistemas isso pode ser meros minutos ou segundos. A extensão das RTOs e RPOs tem implicações profundas em como os planos de recuperação de desastres são implementados.
RTOs e RPOs
RTOs e RPOs curtos exigem que um sistema implemente a replicação de dados ativa entre sistemas primários e de recuperação (como envio de log de banco de dados) e mantenha os sistemas de failover prontos (expressos como “hot hot”) ou quase pronto (“hot hot”) estado a assumir no caso de um desastre. Da mesma forma, o gatilho para um failover de disaster recovery é automatizado. Existem empresas que podem ajudar na consultoria em Cloud .
No entanto para RTOs e RPOs mais longos, a restauração de sistemas de backups diários pode ser suficiente para atender aos RTOs e RPOs. Esses backups podem ser backups de servidores de aplicações, bancos de dados ou ambos. O processo para restaurá-los pode ser manual, automatizado ou ambos. Porém, sempre que os backups são usados para restaurar os sistemas para um estado operacional, isso geralmente é chamado de configuração “quente e frio”. De qualquer forma, o processo de recuperação de uma configuração quente-frio é significativamente mais longo que expresso quente-quente ou quente-quente.
Custo de RTOs e RPOs
Um dos maiores fatores que impede as organizações de implementar alta disponibilidade e RTOs e RPOs curtas é o custo. No que diz respeito à HA, mais redundância requer mais recursos, o que se traduz em custos mais altos. Da mesma forma, RTOs e RPOs curtos exigem que a capacidade esteja disponível para lidar com um failover. O que também se traduz em custos mais altos. Sempre existe um ato de equilíbrio entre os custos e o tempo de inatividade do sistema e, às vezes, os custos de alta disponibilidade, RTOs curtos e RPOs curtos não valem a pena para alguns aplicativos, enquanto para outros é necessário, independentemente dos custos.
Fundamentalmente, a Alta Disponibilidade e o Disaster Eecovery visam o mesmo problema: manter os sistemas em funcionamento em um estado operacional, com a principal diferença: o HA é destinado a lidar com problemas enquanto um sistema está sendo executado, enquanto o DR se destina a lidar com os problemas após um sistema falhar. Independentemente da alta disponibilidade de um sistema, qualquer aplicativo de produção, por mais trivial que seja, é necessário ter algum tipo de plano de recuperação de desastre.
Outro tema que também deve ser levado em consideração na melhoria da resiliência nos sistemas e acaba gerando algumas dúvidas é a diferença entre o Disaster Recovery e o Backup.
Adentro
Concluindo, você deve conhecer a Adentro, pois essa empresa pode te ajudar na adequação dos modelos de Alta Disponibilidade e Disaster Recovery tanto em nuvem quanto on premise. Quer saber mais a respeito? clique aqui e tire suas dúvidas em contato conosco.
Gostou desse artigo? Compartilhe-o!
Caso tenha dúvidas ou interesse em sugerir a elaboração de novos conteúdos específicos, comente logo aqui abaixo.
