O que são redundância, replicação e backup?

Muitas vezes pensamos na nuvem como um sistema globalmente distribuído e onipresente. No entanto, na realidade, a nuvem é composta por hardware em execução em datacenters. A resiliência requer que você contabilize alguns dos riscos associados aos locais físicos nos quais os componentes hospedados na nuvem são executados.

Este artigo fornece uma introdução geral à redundância, replicação e backup, que são métodos usados para criar cargas de trabalho resilientes a riscos físicos que causam interrupção, interrupção ou perda de dados do serviço.

Redundância é a capacidade de manter várias cópias idênticas de um componente de serviço e usar essas cópias de uma maneira que impede que qualquer componente se torne um único ponto de falha.

A replicação ou redundância de dados é a capacidade de manter várias cópias de dados, chamadas réplicas.

O backup é a capacidade de manter uma cópia de dados com carimbo de data/hora que pode ser usada para restaurar dados perdidos.

Do ponto de vista da confiabilidade, uma maneira importante de atenuar muitos riscos é incluir alguma forma de redundância, replicação ou backup em seu planejamento de continuidade de negócios.

Redundância

A redundância consiste na implantação de várias instâncias de um componente. Embora a redundância seja simples de entender, em algumas situações, ela pode se tornar complexa de implementar.

Ao começar a entender a redundância, é mais fácil considerar a redundância em relação aos componentes sem estado, que são componentes que não armazenam dados. Embora a maioria das soluções do mundo real exija o gerenciamento do estado, nesta seção, discutiremos a redundância em termos de uma API (interface de programação de aplicativo) sem estado de exemplo. A API de exemplo aceita entrada, funciona nessa entrada e retorna uma saída, sem armazenar dados. Na seção subsequente, Replicação: Redundância para dados, acrescentaremos considerações para redundância com estado mantido.

Cenário: Redundância sem estado

Neste exemplo, um componente de API sem estado é implantado em uma máquina virtual. Para evitar o tempo de inatividade do componente de API se houver uma falha de hardware no host físico, o exemplo implementa uma solução redundante que:

• Implanta várias cópias da instância da API.
• Implementa um balanceador de carga para distribuir solicitações entre instâncias de API.

O balanceador de carga monitora a integridade de cada instância para enviar solicitações apenas para instâncias saudáveis.

Considerações sobre redundância

Ao implementar soluções redundantes, como no cenário acima, é importante levar em consideração o seguinte:

• Custos de recursos. Por definição, a redundância envolve ter várias cópias de algo, o que aumenta o custo total para hospedar a solução.

• Desempenho. Quanto maior a área geográfica que você distribui as cópias das coisas, mais riscos você ajuda a atenuar. No entanto, as solicitações dos clientes levarão mais tempo para percorrer distâncias mais longas, pois elas precisam percorrer mais infraestrutura de rede e isso aumenta a latência da rede.

  Na maioria das situações do mundo real, a latência de rede é inconsequente para curtas distâncias, como em um datacenter ou até mesmo entre datacenters em uma cidade. Mas se você distribuir cópias em uma longa distância, a latência de rede poderá se tornar mais significativa.

• Consistência de instâncias. É importante manter as instâncias consistentes entre si e evitar a configuração de instâncias individualmente, pois você pode introduzir acidentalmente diferenças entre as instâncias. Se houver diferenças entre instâncias, as solicitações poderão ser processadas de forma diferente, dependendo de qual instância as atende. Isso pode causar bugs e comportamentos difíceis de diagnosticar.

• Distribuição do trabalho. Quando você tem várias instâncias de um componente, precisa distribuir o trabalho entre elas. Você pode distribuir o trabalho em todas as instâncias igualmente ou enviar solicitações para uma única instância primária e usar apenas uma instância secundária se a instância primária não estiver disponível.

  Para componentes que recebem solicitações de entrada, os balanceadores de carga geralmente são usados para enviar essas solicitações para instâncias. No entanto, às vezes os componentes funcionam de forma independente e não recebem solicitações de clientes, portanto, nessas situações, as instâncias podem precisar coordenar seu trabalho entre si.

• Monitoramento de integridade. A integridade de cada instância determina se essa instância pode fazer seu trabalho e o monitoramento de integridade é importante para habilitar a recuperação rápida se houver um problema.

  Os balanceadores de carga normalmente executam o monitoramento de integridade. Para componentes que não incluem um balanceador de carga, você pode ter um componente externo que observa a integridade de todas as instâncias ou cada instância pode monitorar a integridade de outras instâncias.

Locais físicos na nuvem

A necessidade de redundância é clara quando você entende que, mesmo em um ambiente de nuvem, uma instância ou um pedaço de dados é armazenado em um local físico específico.

Por exemplo:

• Uma máquina virtual é executada em um único local físico a qualquer momento.
• Os dados são armazenados em um local físico específico, como em uma SSD (unidade de estado sólido) ou disco rígido conectado a servidores.

Mesmo que haja várias cópias de um pedaço de dados ou instâncias de um componente, cada cópia está vinculada ao hardware físico em que está armazenada.

A localização física de um ambiente de nuvem como um todo pode ser organizada em escopos físicos. Em cada escopo físico, há riscos potenciais que podem comprometer os componentes ou os dados dentro desse escopo. Aqui está uma lista não exaustiva de riscos que podem ser definidos em termos de escopo físico:

Do ponto de vista da confiabilidade, uma maneira importante de atenuar os riscos associados a um escopo físico é espalhar instâncias de um componente em diferentes escopos físicos. Os serviços do Azure com redundância interna podem oferecer uma ou mais das três seguintes maneiras de implantar instâncias redundantes:

• A redundância local coloca instâncias em várias partes de um único datacenter do Azure e protege contra falhas de hardware que podem afetar uma única instância. A redundância local normalmente fornece o menor custo e latência. No entanto, uma falha de datacenter pode significar que todas as instâncias não estão disponíveis.

• A redundância de zona espalha instâncias em várias zonas de disponibilidade em uma única região do Azure. A redundância de zona protege contra falhas de datacenter, além de falhas de hardware.

• A redundância geográfica coloca instâncias em várias regiões do Azure e fornece proteção contra interrupções regionais em larga escala. A redundância geográfica tem um custo mais alto e requer a consideração do seu design de solução mais amplo e de como você alternará entre instâncias de seus componentes em cada região. Você também precisa considerar a latência, que é descrita na replicação síncrona e assíncrona.

Como funciona a redundância no Azure: Serviços de computação

A redundância é empregada em quase todas as partes do Azure. Como exemplo de como o Azure implementa a redundância, considere os serviços que executam cargas de trabalho de computação.

No Azure, uma VM (máquina virtual) individual é executada em um único host físico em um datacenter do Azure. Você pode fornecer instruções ao Azure para garantir que a VM seja executada no local esperado, como a região e a zona de disponibilidade e, em algumas situações, talvez você queira até colocá-la em um host dedicado a você.

É comum executar várias instâncias de uma máquina virtual. Nesse cenário, você pode optar por gerenciá-los individualmente ou usando um Conjunto de Dimensionamento para Máquinas Virtuais. Quando você usa um conjunto de dimensionamento, ainda pode ver as VMs individuais que o sustentam, mas o conjunto de dimensionamento fornece uma variedade de recursos para ajudar a gerenciar VMs redundantes. Esses recursos incluem o posicionamento automático das VMs com base nas regras especificadas, como, por exemplo, espalhando-as entre domínios de falha dentro da região ou zona de disponibilidade.

Há muitos outros serviços de computação do Azure que dependem de máquinas virtuais para executar tarefas de computação. Os serviços de computação geralmente oferecem várias configurações de redundância que determinam como as máquinas virtuais são distribuídas. Por exemplo, um serviço pode fornecer uma configuração de redundância de zona, que você pode habilitar para distribuir automaticamente máquinas virtuais entre zonas de disponibilidade e configurar o balanceamento de carga.

Replicação: Redundância dos dados

A redundância, quando aplicada ao estado (dados), é chamada de replicação. Com a replicação, você pode manter várias cópias em tempo real ou quase em tempo real de dados dinâmicos, chamadas réplicas. Para melhorar a resiliência aos riscos, você pode distribuir réplicas em locais diferentes. Se uma réplica ficar indisponível, o sistema poderá fazer failover para que outra réplica assuma sua função.

Há diferentes tipos de replicação e cada um coloca prioridades diferentes na consistência, desempenho e custo dos dados. Cada tipo de replicação afeta duas métricas principais usadas nas discussões sobre a continuidade dos negócios: O RTO ( objetivo de tempo de recuperação ), que é a quantidade máxima de tempo de inatividade que você pode tolerar em um cenário de desastre, e o RPO ( objetivo de ponto de recuperação ), que é a quantidade máxima de perda de dados que você pode tolerar em um cenário de desastre. Para saber mais sobre essas métricas e como elas se relacionam com a continuidade dos negócios, confira O que são continuidade dos negócios, alta disponibilidade e recuperação de desastres?.

Devido à importância da replicação em atender aos requisitos funcionais e de desempenho, a maioria dos sistemas de banco de dados e outros produtos e serviços de armazenamento de dados incluem algum tipo de replicação como um recurso fortemente integrado. Os tipos de replicação que eles oferecem geralmente são baseados em sua arquitetura e nas maneiras pelas quais eles devem ser usados. Para saber mais sobre os tipos de replicação compatíveis com os serviços do Azure, confira os guias de confiabilidade do serviço do Azure.

Replicação síncrona e assíncrona

Quando você replica dados, todas as alterações nesses dados devem ser mantidas em sincronia entre réplicas. Há alguns dos principais desafios ao tentar manter a consistência quando os dados são alterados:

• Latência. A atualização de uma réplica leva tempo e quanto mais distantes as réplicas forem, mais tempo levará para transmitir dados pela distância entre as réplicas e receber uma confirmação.

• Gerenciamento de alterações. Os dados podem ser alterados enquanto as réplicas estão sendo sincronizadas e, portanto, o gerenciamento da consistência dos dados pode se tornar complexo.

Para enfrentar esses desafios, há duas maneiras principais de replicar alterações de dados e gerenciar a consistência de dados:

• A replicação síncrona requer que as atualizações ocorram em várias réplicas antes que a atualização seja considerada concluída. O diagrama a seguir ilustra como a replicação síncrona funciona:

  

  Neste exemplo, ocorre a seguinte sequência de etapas:

  1. Um cliente altera os dados e a solicitação é enviada para a réplica 1, que processa a solicitação e armazena os dados alterados.
  2. A réplica 1 envia as alterações para a réplica 2, que processa a solicitação e armazena os dados alterados.
  3. A réplica 2 reconhece a alteração de volta para a réplica 1.
  4. A Réplica 1 reconhece a alteração de volta para o cliente.

  A replicação síncrona pode garantir a consistência, o que significa que ela pode dar suporte a um RPO de zero. No entanto, isso vem ao custo do desempenho. Quanto mais distantes suas réplicas forem geograficamente e quanto mais saltos de rede precisarem ser percorridos, mais latência será introduzida pelo processo de replicação.

• A replicação assíncrona ocorre em segundo plano. O diagrama a seguir ilustra como a replicação assíncrona funciona:

  

  Neste exemplo, ocorre a seguinte sequência de etapas:

  1. Um cliente altera os dados e a solicitação é enviada para a réplica 1.
  2. A Réplica 1 processa a solicitação, armazena os dados alterados e reconhece imediatamente a alteração para o cliente.
  3. Em algum momento posterior, a réplica 1 sincroniza a alteração para a réplica 2.

  Como a replicação assíncrona ocorre fora dos fluxos de transação, ela remove a replicação como uma restrição no desempenho do aplicativo. No entanto, se você precisar executar failover para outra réplica, esta pode não ter os dados mais recentes e, portanto, seu RPO deve ser maior que zero. O RPO exato que a replicação assíncrona pode dar suporte depende da frequência de replicação.

Funções de réplica

Em muitos sistemas de replicação, as réplicas podem assumir diferentes funções, o que ajuda a coordenar alterações nos dados e reduz a chance de conflitos. Há dois tipos principais de funções, ativas e passivas. Há duas maneiras comuns de distribuir réplicas com essas funções:

• A replicação ativa-passiva significa que você tem uma réplica ativa, que é responsável por agir como a fonte da verdade. Todas as alterações feitas nos dados devem ser aplicadas a essa réplica. Todas as outras réplicas atuam em uma função passiva , o que significa que elas recebem atualizações para os dados da réplica ativa, mas não processam alterações diretamente dos clientes. As réplicas passivas não são usadas para tráfego dinâmico, a menos que ocorra um failover e as funções das réplicas sejam alteradas. O diagrama a seguir mostra um sistema ativo-passivo com uma réplica passiva:

  

  Em um sistema ativo-passivo, o período de tempo necessário para fazer failover determina o RTO. Normalmente, o RTO para um sistema ativo-passivo é medido em minutos.

  Algumas soluções de replicação também dão suporte a réplicas somente leitura, o que permite ler (mas não gravar) dados das réplicas passivas. Essa abordagem pode ser útil para obter mais utilização de suas réplicas, como quando você precisa executar análises ou relatórios sobre dados sem afetar a réplica primária que você está usando para o trabalho transacional do aplicativo. Vários serviços do Azure dão suporte a réplicas somente leitura, incluindo o Armazenamento do Microsoft Azure com o tipo de replicação GRS (RA-GRS) de acesso de leitura e a replicação geográfica ativa do Banco de Dados SQL do Azure.

• A replicação ativa-ativa permite o uso de várias réplicas ativas para tráfego dinâmico simultaneamente, e qualquer uma das réplicas pode processar solicitações:

  

  A replicação ativa-ativa possibilita um alto nível de desempenho, pois o sistema consegue usar os recursos de todas as réplicas. A replicação ativa-ativa pode dar suporte a um RTO de zero em algumas situações. No entanto, esses benefícios vêm ao custo de complicar a consistência dos dados, pois as alterações concorrentes simultâneas em várias réplicas podem precisar ser reconciliadas de forma assíncrona.

Serviços de dados complexos podem combinar replicação ativa-ativa e ativa-passiva. Por exemplo, eles podem implantar um conjunto de réplicas em uma região do Azure e outra em uma região diferente. Em cada região, uma única réplica ativa atende a solicitações enquanto uma ou mais réplicas passivas ficam para failover. Enquanto isso, ambas as regiões operam em um modelo ativo-ativo, permitindo que o tráfego seja distribuído entre elas.

Como a replicação funciona nos serviços de dados do Azure

Cada serviço do Azure que armazena dados oferece alguma forma de replicação. No entanto, cada serviço pode usar uma abordagem diferente específica à arquitetura do serviço e aos usos pretendidos.

Por exemplo, o Armazenamento do Azure pode fornecer replicação síncrona e assíncrona por meio de um conjunto de recursos:

• Várias cópias de seus dados são replicadas de forma síncrona em sua região primária. Você pode escolher se deseja colocar réplicas em hardware físico diferente em um único datacenter no LRS (armazenamento com redundância local) ou espalhá-las por várias zonas de disponibilidade para ZRS (armazenamento com redundância de zona).
• Se a região primária estiver emparelhada e você habilitar o GRS (armazenamento com redundância geográfica), os dados também serão replicados para a região emparelhada. Como as regiões emparelhadas são geograficamente distantes, essa replicação ocorre de forma assíncrona para reduzir o impacto na taxa de transferência do aplicativo.
• Você pode optar por usar armazenamento com redundância de zona e armazenamento com redundância geográfica simultaneamente usando a GZRS (camada de armazenamento com redundância de zona geográfica). Os dados na região são replicados de forma síncrona e os dados entre regiões são replicados de forma assíncrona.

Para mais informações, confira Redundância do Armazenamento do Microsoft Azure.

Outro exemplo é o Azure Cosmos DB, que também fornece replicação. Todos os bancos de dados do Azure Cosmos DB têm várias réplicas. Quando você distribui réplicas globalmente, elas dão suporte a operações de escrita em múltiplas regiões, permitindo que os clientes escrevam em uma réplica em qualquer uma das regiões que você utiliza. Essas operações de gravação são replicadas de forma síncrona dentro da região e replicadas de forma assíncrona em outras regiões. O Azure Cosmos DB fornece um mecanismo de resolução de conflitos no caso de haver conflitos de gravação entre as diferentes réplicas. Para saber mais, confira a distribuição de dados global com o Azure Cosmos DB – por trás das cenas.

Se você usar máquinas virtuais, poderá usar o Azure Site Recovery para replicar máquinas virtuais e seus discos entre zonas de disponibilidade ou para outra região do Azure.

Ao criar uma solução do Azure, consulte os guias de confiabilidade de cada serviço para entender como esse serviço fornece redundância e replicação, inclusive em diferentes locais.

Cópia de segurança

O backup faz uma cópia de seus dados em um momento específico no tempo. Se houver um problema, você poderá restaurar o backup mais tarde. No entanto, as alterações nos dados que ocorreram depois que o backup foi feito não estarão no backup e poderão ser perdidas.

Usando o backup, você pode fornecer soluções para fazer backup e recuperar seus dados dentro ou na nuvem do Microsoft Azure. O backup pode protegê-lo contra uma variedade de riscos, incluindo:

• Perdas catastróficas de hardware ou outra infraestrutura.
• Corrupção e exclusão de dados.
• Ataques cibernéticos, como ransomware.

Como o backup afeta seus requisitos

Quando usados como parte de uma estratégia de recuperação de desastre, os backups normalmente dão suporte a um RTO e RPO que são medidos em horas:

• O RTO é influenciado pelo tempo necessário para que você inicie e conclua seus processos de recuperação, incluindo a restauração de um backup e a validação de que a restauração foi concluída com êxito. Dependendo do tamanho do backup e de quantos arquivos de backup precisam ser lidos, é comum levar várias horas ou até mais para restaurar totalmente um backup.

• O RPO é influenciado pela frequência do processo de backup. Se você fizer backups com mais frequência, isso significa que você perderá menos dados se precisar restaurar de um backup. No entanto, os backups exigem armazenamento e, em algumas situações, podem afetar o desempenho do serviço enquanto os backups estão sendo feitos. Por esse motivo, você precisa considerar a frequência de backup e encontrar o equilíbrio certo para os requisitos da sua organização. A frequência de backup deve ser uma consideração no planejamento de continuidade dos negócios.

Alguns sistemas de backup dão suporte a requisitos de backup mais complexos, incluindo várias camadas de backup com diferentes períodos de retenção e backups diferenciais ou incrementais que são mais rápidos para salvar e consumir menos armazenamento.

Backup nos serviços do Azure

Muitos serviços do Azure fornecem recursos de backup para seus dados.

O Backup do Azure é uma solução de backup dedicada para vários serviços importantes do Azure, incluindo máquinas virtuais, Armazenamento do Azure e AKS (Serviço de Kubernetes do Azure).

Além disso, muitos bancos de dados gerenciados fornecem seus próprios recursos de backup como parte do serviço, como:

• O Banco de Dados SQL do Azure fornece backups automatizados.
• O Azure Cosmos DB fornece recursos de backup contínuos e periódicos.
• O Azure Key Vault permite que você baixe um backup dos dados em seu cofre.
• O Serviço de Aplicativo do Azure fornece backup automático e personalizado para aplicativos Web e também pode fazer backup de seus bancos de dados.

Backup versus replicação

O backup e a replicação protegem você contra riscos diferentes e as duas abordagens são complementares umas às outras.

A replicação dá suporte à resiliência diária e geralmente é usada em uma estratégia de alta disponibilidade. Algumas abordagens de replicação exigem pouco ou nenhum tempo de inatividade ou perda de dados e dão suporte a um RTO e RPO baixos. No entanto, a replicação não o protege contra riscos que resultam em perda de dados ou corrupção.

Por outro lado, o backup geralmente é uma última linha de defesa contra riscos catastróficos. Os backups geralmente exigem um RTO e RPO relativamente altos, embora a maneira como você configura backups afete exatamente o quão alto eles serão. Uma restauração total de um backup geralmente faz parte de um plano de recuperação de desastre.

Preparação de componentes para redundância

Quando você cria um sistema que usa redundância como parte de sua arquitetura, também é importante considerar como:

• Configuração de recurso duplicada para consistência.
• Gerencie a capacidade durante as falhas de instância por meio de provisionamento excessivo.

Configuração de recursos duplicados

Em ambientes de nuvem, a configuração de cada um dos seus recursos é crítica. Por exemplo, ao criar um balanceador de carga de rede, você define uma variedade de configurações que afetam como ele funciona; e ao implantar uma função usando o Azure Functions, você define as configurações relacionadas às configurações de segurança, desempenho e aplicativo. Cada recurso no Azure tem algum tipo de configuração que impulsiona seu comportamento.

Quando você está gerenciando cópias redundantes de recursos em locais diferentes, é importante controlar a configuração deles. Muitas configurações precisarão ser configuradas da mesma maneira em cada cópia, para que os recursos se comportem da mesma maneira. Mas algumas configurações podem ser diferentes entre cada cópia, como referências à rede virtual de uma região específica.

Uma abordagem comum para manter a consistência em seus recursos é usar a infraestrutura como código (IaC), como Bicep ou Terraform. Essas ferramentas permitem criar arquivos que definem um recurso e você pode reutilizar essas definições para cada instância do recurso. Usando IaC, você pode reduzir a carga de criar e gerenciar várias instâncias de recursos para fins de resiliência e há muitos outros benefícios também. Para saber mais, confira o que é a iac (infraestrutura como código)? e recomendações para usar a infraestrutura como código.

Gerenciar a capacidade com provisionamento excessivo

Quando uma instância falha, a capacidade geral do sistema pode ser diferente da capacidade necessária durante operações íntegras. Por exemplo, suponha que você normalmente tenha seis instâncias de um servidor Web para processar o tráfego da Web de entrada, e essas instâncias são distribuídas igualmente entre três zonas de disponibilidade do Azure em uma região:

Se uma zona de disponibilidade sofrer uma interrupção, você poderá perder temporariamente duas instâncias e ficar com apenas quatro instâncias do servidor Web. Se o aplicativo normalmente estiver ocupado e exigir que todas as seis instâncias acompanhem o tráfego normal, a execução em uma capacidade reduzida poderá afetar o desempenho da solução.

Para se preparar para falhas, você pode superprovisionar a capacidade do serviço. O superprovisionamento permite que a solução tolere algum grau de perda de capacidade e ainda continue funcionando sem desempenho degradado.

Para provisionar demais instâncias do servidor Web para considerar a falha de uma zona de disponibilidade, siga estas etapas:

1. Determine o número de instâncias que sua carga de trabalho de pico exige.
2. Recupere a contagem de instâncias de superprovisionamento multiplicando a contagem de instâncias de carga de trabalho de pico por um fator de [(zonas/(zonas-1)].
3. Arredondar o resultado para o número inteiro mais próximo.

No exemplo anterior, a carga de trabalho de pico requer seis instâncias do servidor Web, portanto, o provisionamento excessivo requer um total de nove instâncias:

Próximas etapas

Saiba mais sobre failover e failback.