Considerações sobre continuidade dos negócios e recuperação de desastre para o Red Hat Enterprise Linux no Azure
Este artigo descreve como melhorar a continuidade dos negócios e a preparação para BCDR (recuperação de desastre) para um ambiente baseado em RHEL (Red Hat Enterprise Linux) no Azure. Ele fornece recomendações que você pode usar para dar suporte a cargas de trabalho do RHEL e implantar componentes de gerenciamento de plataforma RHEL. A assinatura do Red Hat Management contém componentes de plataforma que ajudam a gerenciar cargas de trabalho em uma ou mais zonas de destino do RHEL. Esses componentes oferecem suas próprias configurações de BCDR.
Considerações sobre o design
Implemente as considerações a seguir para melhorar a resiliência de suas cargas de trabalho do RHEL.
Objetivos de tempo de recuperação
Um objetivo de tempo de recuperação (RTO) é a quantidade de tempo que seu 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 VMs (máquinas virtuais) e aplicativos.
- Restaure os dados que os aplicativos exigem.
Em termos de negócios, 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 perceptível no desempenho da empresa.
Objetivos de 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 objetivo de ponto de recuperação (RPO) 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 do 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 perda de receita ou lucros. Um RPO curto geralmente resulta em aumento dos custos de gerenciamento. Para ajudar a reduzir esses custos, você deve criar uma linha de base de gerenciamento que se concentre no RPO aceitável mais longo. Em seguida, você pode diminuir o RPO das plataformas ou cargas de trabalho específicas que justificam mais investimento.
Considerações sobre BCDR de carga de trabalho
As considerações de design de alta disponibilidade e recuperação de desastre para cargas de trabalho baseadas em RHEL dependem das tecnologias que dão suporte a essas cargas de trabalho. Muitas cargas de trabalho modernas podem aproveitar os 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 automaticamente conjuntos de disponibilidade e controlar domínios de atualização e falha. Essas práticas facilitam a garantia da disponibilidade de implantações do RHEL.
As soluções de banco de dados e outros aplicativos com 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 compatíveis com os aplicativos. Para obter mais informações, confira Alta disponibilidade e recuperação de desastre para aplicativos IaaS.
| Recurso ou serviço do Azure | Definição | Considerações |
|---|---|---|
| Regiões | Um grupo de datacenters localizados próximos uns dos outros para fornecer baixos atrasos de rede. Para garantir uma transferência rápida de dados, 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 necessários nas regiões selecionadas. Para implantações do 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 uma instalação de colocação. | O ExpressRoute ignora a Internet pública e fornece uma conexão privada dedicada. Essa configuração é um requisito comum para implantações do RHEL em grande escala. O ExpressRoute é um serviço compartilhado, portanto, você precisa planejar cuidadosamente sua capacidade de largura de banda para atender às necessidades gerais de largura de banda da sua empresa. Se você não tiver largura de banda suficiente, poderá comprometer a experiência do usuário ou o acesso a serviços críticos no datacenter. Certifique-se de implantar o ExpressRoute de maneira 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 SLA (contrato de nível de serviço) alto, use zonas de disponibilidade com a infraestrutura do RHEL quando possível. As zonas de disponibilidade oferecem redundância de datacenter em uma região. Mas nem todas as regiões têm zonas de disponibilidade, portanto, você precisa planejar com cuidado. Os serviços RHEL, como o Red Hat OpenShift no Azure e os serviços de gerenciamento de zona de destino, dão suporte a zonas de disponibilidade. |
| Conjuntos de disponibilidade | Um agrupamento lógico de VMs. Pelo menos uma VM está sempre em execução durante eventos de manutenção planejada ou não planejada. 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 das 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 tem zonas de disponibilidade. Os conjuntos de disponibilidade têm apenas redundância de hardware, que é semelhante às regras de antiafinidade do hipervisor. Portanto, se suas regiões não tiverem zonas de disponibilidade, você precisará de uma estratégia multirregional para redundância geográfica e de datacenter. |
| Azure Load Balancer | 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 Load Balancer pode distribuir o tráfego de rede entre várias regiões no Azure e também entre ambientes locais e o Azure. |
O Load Balancer distribui o tráfego de rede em vários servidores para fornecer disponibilidade ininterrupta de aplicativos e evitar falhas de ponto único. Se ocorrer um desastre, o Load Balancer redirecionará 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 comerciais. O Load Balancer 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 gerenciados | Discos virtualizados que o Azure gerencia. Você escolhe o tamanho e o tipo de disco. O Azure distribui discos em várias unidades de armazenamento para proteger seus dados contra falhas de hardware. | Os discos gerenciados são a melhor opção para toda a infraestrutura do 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 computadores 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, o SSD local e os discos efêmeros são removidos. Faça backup dos dados nesses discos conforme apropriado. |
| Serviço de Backup do Azure | 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 VM. Use o Backup para restaurar facilmente toda a VM ou arquivos e pastas específicos da nuvem, sem precisar recriar a VM ou perder dados. Você também pode usar outras soluções de parceiros com suporte. |
| Azure Arc | Uma plataforma que estende os serviços do Azure para que eles sejam executados em diversos ambientes, incluindo datacenters, dispositivos de borda e arquiteturas multinuvem. 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 perspectiva de 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 o Site Recovery para minimizar problemas de recuperação, reduzir custos de infraestrutura e garantir uma 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 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 do RHEL e VMs de imagem dourada, use bloqueios de recursos. Para evitar a perda acidental de máquinas importantes, aplique o bloqueio Excluir no mínimo. Aplique o bloqueio ReadOnly aos computadores de infraestrutura do RHEL porque eles não mudam com frequência. Faça alterações apenas durante as janelas de controle de alterações apropriadas. |
Considerações sobre BCDR da plataforma RHEL
Para obter mais informações sobre os recursos de 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 identidade.
Recomendações sobre design
Para aplicativos nativos de nuvem em contêineres do Linux, use uma plataforma baseada em Kubernetes para garantir escalabilidade, alta disponibilidade e redundância. Considere usar a plataforma Red Hat OpenShift no Azure ou uma implantação autogerenciada do OpenShift com armazenamento replicado ou replicado geograficamente.
Para front-ends de aplicativos Web nativos e aplicativos sem estado, você pode usar muitos dos serviços nativos do Azure que fornecem disponibilidade de aplicativos. Para arquiteturas que usam esses serviços, consulte:
- Aplicativo Web com redundância de zona altamente disponível de linha de base.
- Aplicativo Web multirregional 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 muitos aplicativos com estado tradicionais que exigem alta disponibilidade, o RHEL oferece o complemento de alta disponibilidade do Pacemaker. Você pode obter sistemas que têm esse recurso no Azure Marketplace ou implantar uma imagem personalizada com os componentes de software necessários inseridos. Para obter mais informações, consulte Configurar um cluster de alta disponibilidade do Red Hat no Microsoft Azure.
Os problemas de disponibilidade afetam as interrupções e os tempos de resposta do serviço. A degradação do serviço pode ocorrer, o que pode degradar a experiência de serviço do cliente. Para garantir que você mantenha os níveis de desempenho e a capacidade suficiente nas regiões necessárias, use o recurso de reserva de capacidade sob demanda do Azure.
Confiabilidade
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 dá suporte à combinação de Serviços Centrais do Servidor de Aplicativos e 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 do SAP:
- Cluster do RHEL Pacemaker: não há suporte para dispositivos de bloco STONITH, mas você pode contar com o agente de limite do Azure.
- Software de cluster não Microsoft certificado pela SAP: explore essa opção se ela estiver alinhada aos seus requisitos.
Escolha o serviço apropriado com base em suas necessidades específicas e seu sistema operacional.
Para saber mais, veja:
- Configure um cluster de alta disponibilidade do Red Hat no Microsoft Azure para RHEL 9.
- Configure e gerencie clusters de alta disponibilidade para RHEL 9.
- Documentação do RHEL 8.
Réplicas da Galeria de Computação do Azure
Você pode usar a Compute Gallery para armazenar golden images 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 dão 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 regiões geográficas.
Observação
Recomendamos que você tenha pelo menos duas galerias em regiões diferentes.
Recuperação de Site
O Site Recovery pode aumentar a resiliência de alguns componentes do RHEL. Para obter uma lista de servidores de recuperação de site RHEL com suporte, consulte Matriz de suporte para recuperação de desastre de VM do Azure com Site Recovery. Você também pode configurar o Site Recovery como um failover de ambientes locais para a nuvem. Para obter uma estimativa dos custos do Site Recovery, use o planejador de implantação do Site Recovery.
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 os itens do cluster de recuperação de desastre manualmente. Por exemplo, você deve aplicar configurações para configurar recursos e copiar dados.