Desenvolver um plano de continuidade de negócio e recuperação após desastre
A sua organização quer que conceba uma estratégia de recuperação de sites para as aplicações. Primeiro, você deve entender os requisitos específicos para a recuperação do local de construção para seu ambiente híbrido. Você também deve entender quais ferramentas estão disponíveis no Azure para ajudá-lo.
Nesta unidade, você aprenderá a identificar as principais infraestruturas, RTOs (Recovery Time Objetives, objetivos de tempo de recuperação) e RPOs (Recovery Point Objetives, objetivos de ponto de recuperação). Você aprende quais requisitos podem ser relevantes com qualquer serviço de plataforma como serviço (PaaS) que você possa estar usando. Você também aprende a planejar backup e recuperação de desastres. Finalmente, você descobre alguns dos recursos do Azure que ajudam a criar uma solução de recuperação de site.
Continuidade de negócio e recuperação após desastre
Você precisa desenvolver um plano BCDR para projetar uma solução de recuperação de local apropriada. BCDR refere-se a um processo que ajuda a restaurar seus aplicativos para um estado funcional após um evento significativo. Este evento pode ser um desastre natural, como um terremoto. Ou pode ser de natureza técnica, como a eliminação de uma base de dados. Esses eventos são tipicamente mais amplos em escopo e envolvem maior esforço de recuperação.
Para criar um processo de recuperação de desastres bem-sucedido, primeiro você precisa avaliar que tipo de impacto nos negócios qualquer falha potencial poderia ter. Considere automatizar o processo de recuperação o máximo possível. Inevitavelmente, algumas partes do seu processo de recuperação de desastres envolvem a entrada humana, portanto, você deve documentar completamente o processo. Você também deve simular desastres regularmente para que seu processo de recuperação permaneça eficaz.
Identificar os intervenientes principais e a infraestrutura
Identifique todas as pessoas que precisam que as aplicações permaneçam funcionais. Estes intervenientes podem ser utilizadores externos ou internos. Sua equipe de suporte, e qualquer pessoa necessária para a entrada manual no processo BCDR, é uma parte interessada. Outros aplicativos e serviços que dependem de seus aplicativos também podem ser partes interessadas.
Identifique a infraestrutura que compõe o ambiente das aplicações. Normalmente, essa infraestrutura são as máquinas virtuais (VMs), os recursos de rede, os recursos de armazenamento e quaisquer outros serviços executados ao lado desses recursos.
Identificar objetivos de ponto de recuperação e objetivos de tempo de recuperação
Um RPO representa a quantidade de perda de dados aceitável para seu aplicativo se houver um desastre. Por exemplo, se a aplicação estiver inativa, talvez considere que apenas seja aceitável que esta seja executada com dados com menos de meia hora após a recuperação. Algumas aplicações podem funcionar com dados mais antigos, mas, para outras, é essencial executar sempre os dados mais recentes.
Um RTO é a duração máxima de tempo de inatividade aceitável para seu aplicativo. Por exemplo, você pode achar inaceitável que seu aplicativo fique inativo por mais de quatro horas devido à perda potencial para a empresa que viria com uma interrupção mais longa. Aplicativos críticos exigem um RTO mais curto.
Os requisitos contratuais ou regulamentares podem muitas vezes influenciar o RPO e o RTO da sua aplicação. O RPO e o RTO também podem variar de acordo com o aplicativo. Aplicativos menos críticos podem ter valores maiores para RPO e RTO, enquanto aplicativos críticos para os negócios podem ter uma tolerância menor a tempo de inatividade e perda de dados. Você calcula o RTO e o RPO com base na compreensão da sua organização sobre o risco e o custo incorrido com o tempo de inatividade e a perda de dados.
Identificar os requisitos de PaaS
Embora você possa ter controle sobre o tempo de inatividade e a recuperação dos aplicativos que gerencia, talvez não tenha o mesmo controle sobre os serviços PaaS. Quaisquer serviços de PaaS que você usa podem ter suas próprias garantias de disponibilidade e planos de recuperação que você deve considerar em seu plano BCDR.
Identifique e inventarie os serviços dos quais você depende, para que possa incorporar seus recursos de recuperação ao seu plano BCDR. É importante entender os requisitos relevantes e como eles afetam o processo BCDR.
Azure Site Recovery
O Azure Site Recovery é um serviço que fornece recursos BCDR para as aplicações no Azure, no local e noutros fornecedores de cloud. O Site Recovery tem planos que ajudam a automatizar a recuperação de desastres. Ele permite que você defina como as máquinas são submetidas a failover e a ordem em que elas são reiniciadas após o failover bem-sucedido. Desta forma, o Site Recovery ajuda a automatizar tarefas e a reduzir ainda mais o seu RTO. Você também pode usar o Site Recovery para testar periodicamente failovers e a eficácia geral do processo de recuperação.
Cópias de segurança dos dados
Os backups ajudam a proteger os aplicativos contra exclusão acidental ou corrupção de dados. As cópias de segurança desempenham um papel importante em qualquer plano BCDR.
Seu RPO depende da frequência e da frequência com que você executa os processos de backup. Por exemplo, se você tiver um processo de backup configurado para ser executado a cada duas horas e tiver um desastre cinco minutos antes do próximo backup, perderá uma hora e 55 minutos de dados. Ao criar cópias de segurança mais frequentes, obterá um RPO reduzido. No plano geral, deve incluir um processo detalhado da cópia de segurança.
Você pode usar o Backup do Azure para seu processo de backup. O serviço de Backup do Azure fornece backup seguro para todos os ativos de dados gerenciados pelo Azure. Ele usa soluções de infraestrutura zero para permitir backups e restaurações de autoatendimento, com gerenciamento em escala a um custo previsível.
O Backup do Azure oferece soluções de backup especializadas para VMs do Azure e locais. O Backup do Azure também permite que cargas de trabalho como SQL Server ou SAP HANA em execução em VMs do Azure tenham opções de backup e restauração de classe empresarial.
O Backup do Azure e o Azure Site Recovery visam tornar o sistema mais resiliente a falhas e falhas. No entanto, o objetivo principal do Backup do Azure é manter cópias de dados com monitoração de estado que permitam que você volte no tempo. O Site Recovery replica os dados quase em tempo real e permite um failover. Saiba mais sobre o Backup do Azure.
Funcionalidades de resiliência do Azure
O Azure vem com vários recursos para ajudar a garantir que seus aplicativos e infraestrutura sejam resilientes. Os recursos de resiliência do Azure incluem emparelhamento de região, conjuntos de disponibilidade e zonas de disponibilidade.
Emparelhamento de regiões
Todas as regiões do Azure são emparelhadas com uma região diferente. Num par de regiões, as regiões nunca são atualizadas simultaneamente. Em vez disso, eles são atualizados um a um. Se algo acontecer com uma região, a outra região do par fica disponível.
Estes pares de regiões também são utilizados para a replicação. Os serviços de armazenamento e muitos serviços PaaS são replicados e têm pares de failover na região emparelhada. Como parte do seu planejamento BCDR, é importante usar o emparelhamento de regiões para aproveitar o isolamento que ele proporciona. Você pode reduzir o tempo necessário para se recuperar de uma falha e aumentar sua disponibilidade.
Conjuntos de disponibilidade
Um conjunto de disponibilidade é um recurso de agrupamento lógico no Azure. Você pode colocar recursos de VM em um conjunto de disponibilidade para garantir que esses recursos de VM sejam isolados uns dos outros quando forem implantados em um datacenter do Azure. Os conjuntos de disponibilidade consistem em domínios de atualização e domínios de falha.
Os domínios de atualização ajudam a garantir que um subconjunto dos servidores do seu aplicativo continue em execução quando a VM hospeda em um datacenter do Azure exigir tempo de inatividade para manutenção. A maioria das atualizações para hosts de VM pode ser executada sem afetar as VMs em execução neles, mas há ocasiões em que esse tipo de atualização não é possível.
Para garantir que as atualizações não ocorrem simultaneamente em todas as VMs, o datacenter do Azure está logicamente seccionado em domínios de atualização. Quando ocorre um evento de manutenção, como uma atualização de desempenho e um patch de segurança crítico que precisa ser aplicado ao host, esse evento de manutenção é sequenciado por meio de domínios de atualização. O uso de sequenciamento por meio de domínios de atualização garante que todo o datacenter não fique indisponível durante as atualizações e patches da plataforma.
Os domínios de falha representam seções físicas do datacenter e ajudam a garantir a diversidade de servidores em rack em um conjunto de disponibilidade. Os domínios de falha se alinham com a separação física do hardware compartilhado no datacenter. O hardware compartilhado inclui alimentação, resfriamento e hardware de rede que suporta os servidores físicos em racks de servidor.
Se o hardware que suporta um rack de servidor ficar indisponível, a interrupção afetará apenas esse rack de servidor. Quando você coloca suas VMs em um conjunto de disponibilidade, elas são automaticamente distribuídas por vários domínios de falha. Se ocorrer uma falha de hardware, ela afetará apenas algumas de suas VMs.
Zonas de disponibilidade
As zonas de disponibilidade são locais de datacenter físicos independentes dentro de uma região. As zonas de disponibilidade incluem a sua própria alimentação, arrefecimento e rede. Ao levar em conta as zonas de disponibilidade ao implantar recursos, você pode ajudar a proteger cargas de trabalho de interrupções do datacenter e, ao mesmo tempo, manter a presença em uma região.
Serviços zonais são serviços (como máquinas virtuais) que você pode implantar em zonas específicas dentro de uma região. Outros serviços são serviços com redundância de zona e são replicados nas zonas de disponibilidade na região específica do Azure. Ambos os tipos ajudam a garantir que, dentro de uma região do Azure, não haja pontos únicos de falha.
