Desenvolver um plano de continuidade dos negócios e recuperação de desastres
Sua organização deseja que você projete uma estratégia de recuperação de site para seus aplicativos. Primeiro, você deve entender os requisitos específicos para criar a recuperação de site para seu ambiente híbrido. Você também precisa entender quais ferramentas estão disponíveis no Azure para ajudar você.
Nesta unidade, você aprenderá a identificar as principais infraestruturas, os RTOs (objetivos de tempo de recuperação) e os RPOs (objetivos de ponto de recuperação). Você aprenderá quais requisitos podem ser relevantes com os serviços de PaaS (plataforma como serviço) que estiver usando. Você também aprenderá a planejar o backup e a recuperação de desastre. Por fim, você descobrirá alguns dos recursos do Azure que ajudam a criar uma solução de recuperação de site.
Continuidade dos negócios e recuperação de desastres
Você precisa desenvolver um plano de BCDR para criar uma solução de recuperação de site apropriada. A BCDR se refere a um processo que ajuda você a restaurar seus aplicativos para um estado funcional após um evento significativo. Esse evento pode ser um desastre natural, como um terremoto. Ou, então, pode ser de natureza técnica, como a exclusão de um banco de dados. Normalmente, esses eventos têm um escopo mais amplo e envolvem um esforço maior para recuperação.
Para planejar um processo de recuperação de desastre bem-sucedido, primeiro você precisa avaliar que tipo de impacto no negócio qualquer falha em potencial teria. Considere automatizar o processo de recuperação o máximo possível. Inevitavelmente, algumas partes do processo de recuperação de desastre envolvem atividade humana, portanto, você precisa documentar completamente o processo. Você também precisa simular desastres regularmente, para que seu processo de recuperação permaneça efetivo.
Identificar os stakeholders e a infraestrutura
Identifique todas as pessoas que têm uma participação em seus aplicativos que permanecem funcionais. Esses stakeholders podem ser usuários externos ou internos. Sua equipe de suporte e qualquer pessoa necessária para uma contribuição manual no processo de BCDR é um stakeholder. Outros aplicativos e serviços que dependem dos seus aplicativos também podem ser stakeholders.
Identifique a infraestrutura que compõe o ambiente para seus aplicativos. Normalmente, essa infraestrutura consiste nas VMs (máquinas virtuais), nos recursos de rede, nos recursos de armazenamento e em qualquer outro serviço executado com eles.
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 em caso de desastre. Por exemplo, se o seu aplicativo estiver inativo, talvez você ache aceitável que ele seja executado em dados com menos de meia hora após a recuperação. Alguns aplicativos podem funcionar com o uso de dados mais antigos, mas para outros, é essencial sempre executar os dados mais recentes possíveis.
Um RTO é a duração máxima de tempo de inatividade aceitável para seu aplicativo. Por exemplo, talvez você ache inaceitável que seu aplicativo fique inativo por mais de quatro horas devido à possível perda dos negócios após esse período. Os aplicativos críticos precisarão de um RTO mais curto.
Os requisitos contratuais ou regulatórios podem muitas vezes influenciar o RPO e o RTO do seu aplicativo. O RPO e o RTO também podem variar de acordo com o aplicativo. Os aplicativos menos críticos podem ter valores maiores de RPO e RTO, enquanto os aplicativos comercialmente críticos podem ter uma tolerância menor de tempo de inatividade e perda de dados. Calcule o RTO e o RPO de acordo com o entendimento do risco pela sua organização e do custo gerado com a perda de dados e o tempo de inatividade.
Identificar requisitos de PaaS
Embora você possa ter controle sobre o tempo de inatividade e a recuperação dos aplicativos que você gerencia, talvez não tenha o mesmo controle sobre os serviços de PaaS. Qualquer serviço de PaaS que você usar pode ter garantias de disponibilidade e planos de recuperação próprios que você precisa considerar no seu plano de BCDR.
Identifique e faça o inventário dos serviços dos quais você depende, de modo a incorporar as funcionalidades de recuperação no plano de BCDR. É importante entender os requisitos relevantes e como eles afetam o processo de BCDR.
Azure Site Recovery
O Azure Site Recovery é um serviço que fornece recursos de BCDR para seus aplicativos no Azure, no local e em outros provedores de nuvem. O Site Recovery tem planos que ajudam a automatizar a recuperação de desastre. Ele permite que você defina como será feito o failover dos computadores e a ordem em que eles serão reiniciados após o failover bem-sucedido. Dessa forma, o Site Recovery ajuda a automatizar as tarefas e reduzir ainda mais o RTO. Você também pode usar o Site Recovery para testar periodicamente os failovers e a eficácia geral do processo de recuperação.
Backups de dados
Os backups ajudam a proteger os aplicativos contra exclusão acidental ou dados corrompidos. Os backups desempenham uma função importante em qualquer plano de BCDR.
Seu RPO depende da frequência e do quão regularmente você executa os processos de backup. Por exemplo, se houver um processo de backup configurado para ser executado a cada duas horas e ocorrer um desastre cinco minutos antes do próximo backup, você perderá uma hora e 55 minutos de dados. Ter backups mais frequentes significa que você obtém um RPO reduzido. Em seu plano geral, você deve incluir um processo detalhado de backup.
Você poderá usar o Backup do Azure como o processo de backup. O serviço Backup do Azure fornece backup seguro para todos os ativos de dados gerenciados pelo Azure. Ele usa soluções de infraestrutura zero para habilitar 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 o SQL Server ou o SAP HANA em execução em VMs do Azure tenham opções de backup e restauração de nível empresarial.
O Backup do Azure o Azure Site Recovery têm o objetivo de tornar o sistema mais resiliente a erros e falhas. No entanto, a principal meta do Backup do Azure é manter cópias de dados com estado que permitem 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.
Recursos de resiliência do Azure
O Azure é fornecido com recursos para ajudar a garantir que seus aplicativos e sua infraestrutura sejam resilientes.
Emparelhamento de região
Todas as regiões do Azure são emparelhadas com uma região diferente. Em um par de regiões, as regiões nunca são atualizadas simultaneamente. Em vez disso, elas são atualizadas uma por uma. Se algo acontecer com uma região, a outra ficará disponível.
Esses pares de regiões também são usados para replicação. Os serviços de armazenamento e muitos serviços de PaaS são replicados e têm pares de failover na região emparelhada. Como parte do planejamento de BCDR, é importante usar o emparelhamento de região para aproveitar o isolamento que ele fornece. Você pode reduzir a quantidade de tempo que leva para se recuperar de uma falha e aumentar sua disponibilidade.
Conjuntos de disponibilidade
Um conjunto de disponibilidade é uma funcionalidade de agrupamento lógico no Azure. Ele garante que os recursos de VM colocados dentro dele sejam isolados uns dos outros quando eles são 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 os hosts de VM de um datacenter do Azure exigirem tempo de inatividade para manutenção. A maioria das atualizações nos hosts de VM pode ser feita sem afetar as VMs em execução neles, mas há ocasiões em que esse tipo de atualização não é possível.
Para assegurar que as atualizações não ocorram em todas as VMS simultaneamente, o datacenter do Azure é dividido de maneira lógica em seções nos 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ítica que precisa ser aplicado ao host, ele é sequenciado por meio de domínios de atualização. O uso de sequenciamento por meio de domínios de atualização garante que o datacenter inteiro não fique indisponível durante as atualizações e a aplicação de patches na plataforma.
Os domínios de falha representam as seções físicas do datacenter e ajudam a garantir a diversidade de rack de servidores em um conjunto de disponibilidade. Os domínios de falha são alinhados com a separação física do hardware compartilhado no datacenter. O hardware compartilhado inclui a energia, o resfriamento e o hardware de rede que dá suporte aos servidores físicos nos racks de servidores.
Se o hardware que dá suporte a um rack de servidores ficar indisponível, a interrupção só afetará esse rack de servidores. Quando você coloca suas VMs em um conjunto de disponibilidade, elas são distribuídas automaticamente entre vários domínios de falha. Em caso de falha de hardware, ela afetará apenas algumas das suas VMs.
Zonas de disponibilidade
As zonas de disponibilidade são localizações físicas de datacenters independentes dentro de uma região. Elas incluem energia, resfriamento e rede próprios. Ao levar em consideração as zonas de disponibilidade quando implantar recursos, você poderá ajudar a proteger as cargas de trabalho contra interrupções do datacenter, mantendo a presença em uma região.
Os serviços de zonas são serviços (como máquinas virtuais) que você pode implantar em zonas específicas de uma região. Outros serviços são serviços com redundância de zona e são replicados entre as zonas de disponibilidade na região específica do Azure. Ambos os tipos ajudam a garantir que não haja pontos únicos de falha em uma região do Azure.
