Considerações sobre continuidade de negócios e recuperação de desastres para o Red Hat Enterprise Linux no Azure
Este artigo descreve como melhorar a preparação para continuidade de negócios e recuperação de desastres (BCDR) para um ambiente baseado no Red Hat Enterprise Linux (RHEL) no Azure. Ele fornece recomendações que você pode usar para dar suporte a cargas de trabalho RHEL e implantar componentes de gerenciamento de plataforma RHEL. A assinatura do Red Hat Management contém componentes da plataforma que ajudam a gerenciar cargas de trabalho em uma ou mais zonas de aterrissagem do RHEL. Esses componentes oferecem suas próprias configurações BCDR.
Considerações de design
Implemente as seguintes considerações para melhorar a resiliência de suas cargas de trabalho RHEL.
Objetivos de tempo de recuperação
Um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) é a quantidade de tempo que o sistema deve levar para se recuperar ao seu estado original após um desastre. O RTO inclui o tempo necessário para:
- Restaure a funcionalidade mínima para máquinas virtuais (VMs) e aplicativos.
- Restaure os dados que os aplicativos exigem.
Em termos comerciais, o RTO representa a quantidade de tempo que os processos de negócios estão fora de serviço. Um RTO baixo é ideal para cargas de trabalho de missão crítica para que os processos de negócios possam ser retomados rapidamente. Para cargas de trabalho de prioridade mais baixa, um RTO mais alto pode não ter um efeito percetível no desempenho da empresa.
Objetivos do ponto de recuperação
Para operar com êxito um ambiente de nuvem, você deve implementar backups, replicação ou ambos para proteger os dados contra falhas. O RPO (Recovery Point Objetive, objetivo de ponto de recuperação) refere-se à última vez que os dados foram capturados. Quando um sistema falha, você pode restaurá-lo apenas para o ponto de recuperação mais recente.
Você mede o RPO desde o ponto de recuperação mais recente até o momento em que ocorre uma interrupção. Se você medir o RPO em horas, uma falha do sistema resultará na perda de dados para as horas entre o último ponto de recuperação e a interrupção. Se você medir o RPO em dias, uma falha do sistema resultará na perda de dados para os dias entre o último ponto de recuperação e a interrupção. Um RPO de um dia teoricamente resulta na perda de todas as transações no dia que leva à falha.
Para sistemas de missão crítica, meça o RPO em minutos ou segundos para ajudar a evitar perdas de receita ou lucros. Um RPO curto geralmente resulta em custos de gerenciamento aumentados. Para ajudar a reduzir esses custos, você deve criar uma linha de base de gerenciamento que se concentre no RPO aceitável por mais tempo. Em seguida, você pode diminuir o RPO das plataformas ou cargas de trabalho específicas que exigem mais investimento.
Considerações sobre o BCDR da carga de trabalho
As considerações de projeto de alta disponibilidade e recuperação de desastres para cargas de trabalho baseadas em RHEL dependem das tecnologias que suportam essas cargas de trabalho. Muitas cargas de trabalho modernas podem tirar proveito dos serviços nativos do Azure para fornecer redundância entre zonas de disponibilidade e entre regiões. Use os serviços do Azure para gerenciar a replicação de dados, dimensionar conjuntos de disponibilidade automaticamente e controlar domínios de atualização e falha. Essas práticas facilitam a garantia da disponibilidade das implantações do RHEL.
As soluções de banco de dados e outros aplicativos com monitoração de estado podem precisar de soluções centradas no sistema operacional para fornecer alta disponibilidade e recuperação de desastres. Consulte o desenvolvedor ou fornecedor do aplicativo para verificar as soluções suportadas pelos aplicativos. Para obter mais informações, consulte Alta disponibilidade e recuperação de desastres para aplicativos IaaS.
| Recurso ou serviço do Azure | Definição | Considerações |
|---|---|---|
| Regiões | Um grupo de datacenters que estão localizados próximos uns dos outros para fornecer baixos atrasos de rede. Para garantir uma transferência de dados rápida, uma rede regional específica conecta os datacenters. | Ao escolher uma região do Azure, considere o local de seus datacenters, usuários e dados de back-end. Verifique a disponibilidade dos serviços de que necessita nas regiões que selecionar. Para implantações RHEL, você pode ter uma região para iniciar e, em seguida, pode adicionar mais regiões no futuro para fins de BCDR. |
| Azure ExpressRoute | Um serviço do Azure que você pode usar para estabelecer conexões privadas de datacenters da Microsoft para sua própria infraestrutura ou para um recurso de colocation. | O ExpressRoute contorna a Internet pública e fornece uma ligação privada dedicada. Essa configuração é um requisito comum para implantações RHEL em grande escala. O ExpressRoute é um serviço compartilhado, portanto, você precisa planejar sua capacidade de largura de banda cuidadosamente para atender às necessidades gerais de largura de banda da sua empresa. Se você tiver largura de banda insuficiente, poderá comprometer a experiência do usuário ou o acesso a serviços críticos no datacenter. Certifique-se de implantar a Rota Expressa de forma resiliente entre regiões e locais de emparelhamento. |
| Zonas de disponibilidade | Separe grupos de datacenters que têm seus próprios sistemas de energia, resfriamento e rede em uma região do Azure. As zonas de disponibilidade fornecem alta disponibilidade e resiliência a falhas de datacenter. | Para garantir um contrato de alto nível de serviço (SLA), use zonas de disponibilidade com a infraestrutura RHEL quando possível. As zonas de disponibilidade oferecem redundância de datacenter dentro de uma região. Mas nem todas as regiões têm zonas de disponibilidade, por isso é preciso planear cuidadosamente. Os serviços RHEL, como o Azure Red Hat OpenShift e os serviços de gerenciamento de zona de aterrissagem, oferecem suporte a zonas de disponibilidade. |
| Conjuntos de disponibilidade | Um agrupamento lógico de VMs. Pelo menos uma VM está sempre ativa e em execução durante eventos de manutenção planejados ou não planejados. Um domínio de falha é um subconjunto de um conjunto de disponibilidade que compartilha uma infraestrutura física comum, como energia ou rede. Quando você distribui VMs em diferentes domínios de falha, um conjunto de disponibilidade reduz o impacto de falhas de hardware na disponibilidade da VM. | Os conjuntos de disponibilidade fornecem um SLA alto. Os conjuntos de disponibilidade são adequados para uma infraestrutura RHEL quando uma região não possui zonas de disponibilidade. Os conjuntos de disponibilidade têm apenas redundância de hardware, o que é semelhante às regras de antiafinidade do hipervisor. Portanto, se suas regiões não têm zonas de disponibilidade, você precisa de uma estratégia multirregião para datacenter e redundância geográfica. |
| Balanceador de Carga do Azure | Um serviço de balanceamento de carga de rede. Você pode configurar o Load Balancer para fornecer tráfego de rede de alto volume de forma eficiente em vários servidores Red Hat Enterprise. O serviço opera com baixa latência e alta taxa de transferência, o que melhora o desempenho e a disponibilidade dos aplicativos. O Load Balancer pode ser dimensionado automaticamente de acordo com a demanda. Para promover uma implantação híbrida de seus aplicativos, o Balanceador de Carga pode distribuir o tráfego de rede entre várias regiões no Azure e também entre ambientes locais e o Azure. |
O Balanceador de Carga distribui o tráfego de rede entre vários servidores para fornecer disponibilidade ininterrupta de aplicativos e evitar falhas de ponto único. Se ocorrer um desastre, o Load Balancer redireciona o tráfego para servidores operacionais para fornecer um failover e recuperação rápidos. Essa operação minimiza o tempo de inatividade e mantém as operações de negócios. O Balanceador de Carga pode equilibrar o tráfego entre servidores locais para a nuvem do Azure ou para servidores em várias regiões do Azure. Para obter mais informações, consulte Opções de balanceamento de carga. |
| Discos geridos | Discos virtualizados que o Azure gerencia. Você escolhe o tamanho e o tipo de disco. O Azure distribui discos por várias unidades de armazenamento para proteger os seus dados contra falhas de hardware. | Os discos gerenciados são a melhor opção para toda a infraestrutura RHEL. Não use discos não gerenciados. Para obter mais informações, consulte SLAs para VMs. Diferentes tipos de discos têm desempenho e custos diferentes. Para máquinas de infraestrutura RHEL, recomendamos o SSD Premium do Azure. Considere o custo, o desempenho e a disponibilidade ao escolher o tipo de disco. Quando você desaloca um sistema, SSD local e discos efêmeros são removidos. Faça backup dos dados nesses discos conforme apropriado. |
| Azure Backup | Um serviço que fornece soluções econômicas para fazer backup de seus dados e recuperá-los da nuvem do Azure. | O backup é uma solução confiável e econômica que protege sua infraestrutura RHEL contra falhas ou corrupção de VMs. Use o Backup para restaurar facilmente toda a sua VM ou arquivos e pastas específicos da nuvem, sem ter que recriar a VM ou perder dados. Você também pode usar outras soluções de parceiros suportados. |
| Azure Arc | Uma plataforma que estende os serviços do Azure para que sejam executados em diversos ambientes, incluindo datacenters, dispositivos de borda e arquiteturas multicloud. Use o Azure Arc para fornecer desenvolvimento, operações e gerenciamento de segurança consistentes para aplicativos e serviços. | Use o Azure Arc para implementar backups e monitoramento automatizados centralizados, o que aumenta a resiliência de uma perspetiva BCDR. |
| Azure Site Recovery | Um serviço que fornece recursos de recuperação de desastres para garantir a continuidade dos negócios. Você pode replicar e gerenciar cargas de trabalho, incluindo VMs do Azure e VMs locais, em diferentes regiões. Com o Site Recovery, você pode configurar processos de replicação, failover e recuperação para proteger seus aplicativos durante interrupções planejadas e não planejadas. | Use a Recuperação de Site para minimizar problemas de recuperação, reduzir custos de infraestrutura e garantir recuperação segura e confiável entre regiões do Azure ou de locais locais para o Azure. |
| Bloqueios de recursos | Um recurso do Azure que você pode usar para restringir usuários e funções em sua organização. Proteja os seus recursos críticos contra alterações acidentais ou maliciosas. Você pode bloquear um recurso em vários níveis de escopo, como assinatura, grupo de recursos ou níveis de recursos individuais. Dependendo do tipo de bloqueio, você pode impedir que os usuários excluam ou modifiquem um recurso, mas eles ainda podem ler sua configuração. | Para proteger toda a infraestrutura RHEL e VMs de imagem dourada, use bloqueios de recursos. Para evitar a perda acidental de máquinas importantes, aplique o bloqueio Delete no mínimo. Aplique o bloqueio ReadOnly às máquinas de infraestrutura RHEL porque elas não mudam com frequência. Faça alterações apenas durante as janelas de controle de alterações apropriadas. |
Considerações sobre o BCDR da plataforma RHEL
Para obter mais informações sobre os recursos BCDR para uma infraestrutura de plataforma RHEL, consulte:
- Arquitetura de alta disponibilidade via satélite.
- Arquitetura de alta disponibilidade da plataforma Ansible Automation.
- Arquitetura de alta disponibilidade de gerenciamento de identidades.
Recomendações de design
Para aplicativos nativos da nuvem em contêineres Linux, use uma plataforma baseada em Kubernetes para garantir escalabilidade, alta disponibilidade e redundância. Considere usar a plataforma Azure Red Hat OpenShift ou uma implantação OpenShift autogerenciada com armazenamento replicado ou replicado geograficamente.
Para front-ends de aplicativos Web nativos e aplicativos sem monitoração de estado, você pode usar muitos dos serviços nativos do Azure que fornecem disponibilidade de aplicativos. Para arquiteturas que usam esses serviços, consulte:
- Aplicação Web redundante de zona altamente disponível de linha de base.
- Aplicação Web multi-região altamente disponível.
As arquiteturas anteriores usam vários serviços do Azure para zonas de disponibilidade. A arquitetura de várias regiões usa recursos de replicação geográfica para conteúdo e o Azure Front Door como um serviço de balanceamento de carga.
Para muitas aplicações tradicionais com estado que exigem alta disponibilidade, a RHEL oferece o complemento de alta disponibilidade Pacemaker. Você pode obter sistemas que têm esse recurso do Azure Marketplace ou implantar uma imagem personalizada com os componentes de software necessários incorporados. Para obter mais informações, consulte Configurar um cluster de alta disponibilidade Red Hat no Microsoft Azure.
Problemas de disponibilidade afetam interrupções de serviço e tempos de resposta do serviço. Pode ocorrer degradação do serviço, o que pode degradar a experiência de serviço do cliente. Para garantir que você mantenha níveis de desempenho e capacidade suficiente dentro das regiões necessárias, use o recurso de reserva de capacidade sob demanda do Azure.
Fiabilidade
Muitos dos conceitos que se aplicam às infraestruturas de VM de infraestrutura como serviço também se aplicam às arquiteturas RHEL. Para obter mais informações, consulte Princípios de design de confiabilidade.
Clusters
O Azure não oferece suporte à combinação dos Serviços Centrais do Servidor de Aplicativos e da alta disponibilidade do banco de dados em um único cluster RHEL Pacemaker. Para resolver essa limitação, separe-os em clusters individuais. Você pode combinar até cinco clusters de serviços centrais em um par de VMs.
Para BCDR no SAP, considere os seguintes serviços para executar clusters de serviços centrais SAP:
- Cluster RHEL Pacemaker: os dispositivos de bloco STONITH não são suportados, mas você pode confiar no agente de cerca do Azure.
- Software de cluster não Microsoft certificado pela SAP: explore esta opção se estiver alinhada com os seus requisitos.
Escolha o serviço adequado com base nas suas necessidades específicas e no seu sistema operativo.
Para obter mais informações, consulte:
- Configure um cluster de alta disponibilidade Red Hat no Microsoft Azure para RHEL 9.
- Configure e gerencie clusters de alta disponibilidade para o RHEL 9.
- Documentação RHEL 8.
Réplicas da Galeria de Computação do Azure
Você pode usar a Galeria de Computação para armazenar imagens douradas para implantações. Use essas imagens para a recuperação de desastres de aplicativos e ferramentas. A Galeria de Computação pode usar recursos altamente disponíveis com contas ZRS (armazenamento com redundância de zona) em regiões que oferecem suporte a zonas de disponibilidade. O ZRS oferece resiliência contra falhas zonais. Você também pode replicar imagens da galeria para outras regiões ou geografias.
Nota
Recomendamos que você tenha pelo menos duas galerias em regiões diferentes.
Recuperação de sites
A Recuperação de Local pode aumentar a resiliência de alguns componentes RHEL. Para obter uma lista de servidores de recuperação de site RHEL suportados, consulte Matriz de suporte para recuperação de desastres de VM do Azure com Recuperação de Site. Você também pode configurar a Recuperação de Site como um failover de ambientes locais para a nuvem. Para obter uma estimativa dos custos de Recuperação de Site, use o planejador de implantação de Recuperação de Site.
Nós de cluster de recuperação
Para reduzir os RTOs e aumentar a resiliência, você pode usar nós de cluster de recuperação remota ativos ou em espera. Você deve configurar itens de cluster de recuperação de desastres manualmente. Por exemplo, você deve aplicar configurações para configurar recursos e copiar dados.