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

Muitas vezes pensamos na nuvem como um sistema globalmente distribuído e ubíquo. No entanto, na realidade, a nuvem é composta por hardware executado em datacenters. A resiliência requer que você leve em conta alguns dos riscos associados aos locais físicos nos quais seus 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 de serviço, interrupção ou perda de dados.

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

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

Backup é a capacidade de manter uma cópia datada que pode ser usada para restaurar dados perdidos.

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

Observação

Este artigo não fornece orientações de design ou informações detalhadas sobre serviços individuais do Azure. Para obter informações sobre como os serviços específicos do Azure funcionam de uma perspetiva de confiabilidade, consulte o guia de confiabilidade de cada serviço.

Redundância

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

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

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 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 monitoriza o estado de cada instância para enviar solicitações apenas para instâncias funcionais.

Considerações sobre redundância

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

• Custos dos 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 for a área geográfica em que você distribuir as cópias das coisas, mais riscos você ajudará a mitigar. No entanto, as solicitações dos clientes levarão mais tempo para percorrer distâncias maiores, porque eles têm que atravessar mais infraestrutura de rede, e isso aumenta a latência da rede.

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

• Consistência das instâncias. É importante manter as instâncias consistentes entre si e evitar configurar instâncias individualmente, pois você pode introduzir acidentalmente diferenças entre as instâncias. Se houver diferenças entre as instâncias, as solicitações podem ser processadas de forma diferente, dependendo da instância que 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 por todas as instâncias igualmente, ou pode 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.

• Monitorização da saúde. A integridade de cada instância determina se ela pode fazer seu trabalho, e o monitoramento de integridade é importante para permitir a recuperação rápida se houver um problema.

  Os balanceadores de carga normalmente executam a monitorização de saúde. Para componentes que não incluem um balanceador de carga, você pode ter um componente externo que monitora 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 fica clara quando você entende que, mesmo em um ambiente de nuvem, uma instância ou um dado é 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 unidade de estado sólido (SSD) ou disco rígido conectado a servidores.

Mesmo que haja várias cópias de um dado ou instâncias de um componente, cada cópia está vinculada ao hardware físico no qual 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 dados dentro desse escopo. Aqui está uma lista não exaustiva de riscos que podem ser definidos em termos de escopo físico:

Âmbito físico	Possível risco
Uma peça específica de hardware, como um disco ou servidor	Falha de hardware
Um rack em um datacenter	Interrupção do switch de rede no topo do rack
Um datacenter	Problema com o sistema de arrefecimento do edifício
Um grupo de datacenters, que no Azure é chamado de zona de disponibilidade	Tempestade elétrica em toda a cidade
A área geográfica mais ampla em que o datacenter está, como uma cidade, que é uma região do Azure	Catástrofe natural generalizada

Do ponto de vista da confiabilidade, uma maneira importante de mitigar os riscos associados a um escopo físico é distribuir instâncias de um componente por diferentes escopos físicos. Os serviços do Azure com redundância interna podem oferecer uma ou mais das três maneiras a seguir 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 no datacenter pode significar que todas as instâncias não estão disponíveis.

• A redundância de zona distribui instâncias por várias zonas de disponibilidade em uma única região do Azure. A redundância de zona protege contra falhas no 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 de grande escala. A redundância geográfica tem um custo mais alto e requer consideração do design mais amplo da solução 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 em 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 redundância, considere os serviços que executam cargas de trabalho de computação.

No Azure, uma máquina virtual (VM) 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 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 de Máquina Virtual. Quando utiliza um conjunto de escalas, ainda consegue visualizar as VMs individuais que o suportam, mas o conjunto de dimensionamento fornece uma variedade de recursos para ajudar a gerir VMs redundantes. Esses recursos incluem a colocação automática das VMs com base em regras que você especifica, como distribuí-las 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 para 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 diferentes locais. Se uma réplica ficar indisponível, o sistema poderá fazer failover para que outra réplica assuma sua função.

Existem 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 em discussões sobre continuidade de negócios: RTO ( Recovery Time Objetive, 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 RPO ( Recovery Point Objetive, 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 de negócios, consulte O que são continuidade de negócios, alta disponibilidade e recuperação de desastres?.

Devido à importância da replicação para 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 totalmente integrado. Os tipos de replicação que eles oferecem geralmente são baseados em sua arquitetura e nas maneiras como eles devem ser usados. Para saber mais sobre os tipos de replicação suportados pelos serviços do Azure, consulte Guias de confiabilidade de serviço do Azure.

Importante

Replicação não é o mesmo que backup. A replicação sincroniza todas as alterações entre várias réplicas e não mantém cópias antigas dos dados.

Suponha que você exclua acidentalmente alguns dados. A operação de exclusão é replicada para cada réplica e seus dados são excluídos em todos os lugares. Nessa situação, você provavelmente precisa restaurar os dados excluídos de um backup. O backup é descrito posteriormente neste artigo.

Replicação síncrona e assíncrona

Quando você replica dados, todas as alterações nesses dados devem ser mantidas em sincronia entre as réplicas. Há alguns desafios principais 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, mais tempo leva para transmitir dados através da distância entre as réplicas e receber uma confirmação.

• Gestão da mudança. Os dados podem mudar enquanto as réplicas estão sendo sincronizadas e, portanto, gerenciar a 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 dos dados:

• A replicação síncrona exige 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 ao cliente.

  A replicação síncrona pode garantir consistência, o que significa que pode suportar um RPO de zero. No entanto, isso vem à custa do desempenho. Quanto mais distantes suas réplicas estiverem 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 acontece 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. Réplica 1 processa a solicitação, armazena os dados alterados e imediatamente confirma a alteração ao cliente.
  3. Em algum momento posterior, a réplica 1 sincroniza a alteração com a réplica 2.

  Como a replicação assíncrona acontece fora dos fluxos de transação, ela remove a replicação como uma restrição no desempenho do aplicativo. No entanto, se você precisar fazer failover para outra réplica, ela 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 suportar 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 as alterações nos dados e reduz a chance de conflitos. Existem dois tipos principais de papéis, ativo e passivo. Há duas maneiras comuns de distribuir réplicas com essas funções:

• A replicação ativo-passiva significa que você tem uma réplica ativa , que é responsável por agir como a fonte da verdade. Quaisquer alterações feitas nos dados devem ser aplicadas a essa réplica. Quaisquer outras réplicas atuam em uma função passiva , o que significa que recebem atualizações dos 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 em tempo real, 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 tempo que leva para failover determina o RTO. Comumente, o RTO para um sistema ativo-passivo é medido em minutos.

  Algumas soluções de replicação também oferecem suporte a réplicas de leitura apenas, o que permite ler (mas não gravar) dados a partir 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 de dados sem afetar a réplica principal que 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 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 simultâneo de várias réplicas ativas para tráfego ao vivo, e qualquer uma das réplicas pode processar solicitações:

  

  A replicação ativa-ativa permite um alto nível de desempenho porque o sistema pode usar os recursos em todas as réplicas. Em algumas situações, a replicação ativa-ativa pode oferecer suporte a um RTO de zero. No entanto, esses benefícios têm o custo de complicar a consistência dos dados, porque 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. Dentro de cada região, uma única réplica ativa atende às solicitações, enquanto uma ou mais réplicas passivas estão em espera para alternância em caso de falha. Enquanto isso, ambas as regiões operam em um modelo ativo-ativo, permitindo que o tráfego seja distribuído entre elas.

Como funciona a replicação 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 que é específica para a arquitetura do serviço e usos pretendidos.

Como 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 dos dados são replicadas de forma síncrona na região principal. 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 distribuí-las por várias zonas de disponibilidade para armazenamento com redundância de zona (ZRS).
• Se a região principal estiver emparelhada e você habilitar o armazenamento com redundância geográfica (GRS), os dados também serão replicados para a região emparelhada. Como as regiões emparelhadas estão geograficamente distantes, essa replicação acontece de forma assíncrona para reduzir o impacto na taxa de transferência do aplicativo.
• Você pode optar por usar o armazenamento com redundância de zona e o armazenamento com redundância geográfica simultaneamente usando a camada de armazenamento com redundância de zona geográfica (GZRS). Os dados dentro da região são replicados de forma síncrona e os dados entre regiões são replicados de forma assíncrona.

Para obter mais informações, veja 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, ele oferece suporte a gravações em várias regiões, onde os clientes podem gravar em uma réplica em qualquer uma das regiões que você usa. Essas operações de gravação são replicadas de forma síncrona dentro da região e, em seguida, replicadas de forma assíncrona em outras regiões. O Azure Cosmos DB fornece um mecanismo de resolução de conflitos caso haja conflitos de gravação nas diferentes réplicas. Para saber mais, consulte Distribuição global de dados com o Azure Cosmos DB - sob o capô.

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 projetar 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 locais diferentes.

Cópia de segurança

O backup faz uma cópia dos seus dados em um ponto específico no tempo. Se houver um problema, você pode restaurar o backup mais tarde. No entanto, quaisquer alterações aos seus dados que tenham acontecido após a realização da cópia de segurança não estarão na cópia de segurança e poderão ser perdidas.

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

• Perdas catastróficas de hardware ou outras infraestruturas.
• Corrupção e exclusão de dados.
• Ciberataques, como ransomware.

Importante

É fundamental que você teste e verifique seus processos de backup e restauração regularmente, juntamente com outras etapas de recuperação. Os testes garantem que seus backups sejam abrangentes e livres de erros, e que seus processos os restaurem corretamente. Os testes também são importantes para garantir que sua equipe entenda os processos a serem seguidos. Para saber mais, consulte Testes e exercícios.

Como o backup afeta suas necessidades

Quando utilizados como parte de uma estratégia de recuperação de desastres, os backups geralmente suportam um RTO e RPO que são medidos em horas.

• O RTO é influenciado pelo tempo necessário para iniciar e concluir os 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 seu processo de backup. Se você fizer backups com mais frequência, isso significa que perderá menos dados se tiver que restaurar a partir 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 de negócios.

Alguns sistemas de backup oferecem suporte a requisitos de backup mais complexos, incluindo vários níveis 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 Serviço Kubernetes do Azure (AKS).

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ínuo e periódico.
• O Azure Key Vault permite-lhe transferir uma cópia de segurança dos dados no 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 uma à outra.

A replicação oferece suporte à resiliência diária e é comumente 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 suportam um RTO e RPO baixos. No entanto, a replicação não o protege contra riscos que resultam em perda ou corrupção de dados.

Em contraste, o backup é muitas vezes 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 os 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 desastres.

Preparando componentes para redundância

Ao projetar um sistema que usa redundância como parte de sua arquitetura, é importante considerar também como:

• Configuração de recursos duplicados para consistência.
• Gerencie a capacidade durante falhas de instância através de superprovisionamento.

Configuração de recursos duplicados

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

Ao gerenciar 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 que você crie arquivos que definem um recurso e você pode reutilizar essas definições para cada instância do recurso. Usando o 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, consulte O que é infraestrutura como código (IaC) e Recomendações para usar a infraestrutura como código.

Gerencie 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 seu tráfego da Web de entrada e essas instâncias sejam 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 seu aplicativo estiver normalmente ocupado e exigir que todas as seis instâncias acompanhem seu tráfego normal, a execução em uma capacidade reduzida pode afetar o desempenho da solução.

Para se preparar para falhas, você pode provisionar em excesso a capacidade do seu serviço. O excesso de provisionamento permite que a solução tolere algum grau de perda de capacidade e ainda continue a funcionar sem desempenho degradado.

Para provisionar excessivamente instâncias do servidor Web para contabilizar 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 provisionamento excessivo multiplicando a contagem de instâncias de carga de trabalho de pico por um fator de [(zones/(zones-1)].
3. Arredondar o resultado para o número inteiro mais próximo.

Observação

A tabela a seguir pressupõe que você esteja usando três zonas de disponibilidade e queira contabilizar a perda de capacidade de uma dessas zonas. Se os seus requisitos forem diferentes, ajuste a fórmula em conformidade.

Contagem de instâncias de carga de trabalho de pico	Fator de [(zonas/(zonas-1)]	Fórmula	Instâncias a provisionar (Arredondado)
3	3/2 ou 1,5	(3 x 1,5 = 4,5)	5 ocorrências
4	3/2 ou 1,5	(4 x 1,5 = 6)	6 casos
5	3/2 ou 1,5	(5 x 1,5 = 7,5)	8 instâncias
6	3/2 ou 1,5	(6 x 1,5 = 9)	9 instâncias
7	3/2 ou 1,5	(7 x 1,5 = 10,5)	11 instâncias
8	3/2 ou 1,5	(8 x 1,5 = 12)	12 instâncias
9	3/2 ou 1,5	(9 x 1,5 = 13,5)	14 instâncias
10	3/2 ou 1,5	(10 x 1,5 = 15)	15 instâncias

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óximos passos

Saiba mais sobre failover e failback.