Estratégias de arquitetura para usar zonas e regiões de disponibilidade

Este guia descreve recomendações para determinar quando implantar cargas de trabalho em zonas ou regiões de disponibilidade.

Ao projetar uma solução para o Azure, você precisa decidir se deseja implantar em várias zonas de disponibilidade em uma região ou implantar em várias regiões. Essa decisão afeta a confiabilidade, o custo e o desempenho da sua solução, bem como a capacidade da sua equipe de operar a solução. Este guia fornece informações sobre os principais requisitos de negócios que influenciam sua decisão, as abordagens que você pode considerar, as compensações envolvidas em cada abordagem e o efeito de cada abordagem nos pilares principais do Azure Well-Architected Framework.

As regiões do Azure que você usa para sua solução são uma escolha crítica. O guia Selecionar Regiões do Azure descreve como selecionar e operar em várias regiões geográficas. A forma como você usa regiões e zonas de disponibilidade em sua solução também afeta vários pilares do Well-Architected Framework:

• Fiabilidade: Sua abordagem de implantação pode ajudá-lo a mitigar vários tipos de riscos. Em geral, ao distribuir sua carga de trabalho por uma área mais distribuída geograficamente, você pode obter maior resiliência.

• Otimização de Custos: Algumas abordagens arquitetônicas exigem que você implante mais recursos do que outras abordagens, o que pode aumentar seus custos de recursos. Outras abordagens envolvem o envio de dados através de zonas ou regiões de disponibilidade geograficamente separadas, o que pode incorrer em taxas de tráfego de rede. Também é importante considerar o custo contínuo do gerenciamento de seus recursos, que geralmente é maior quando você tem requisitos de negócios abrangentes.

• Eficiência de desempenho: As zonas de disponibilidade são conectadas por meio de um link de rede de alta largura de banda e baixa latência. Esse link é suficiente para a maioria das cargas de trabalho para permitir a replicação síncrona e a comunicação entre as zonas. No entanto, se você testar sua carga de trabalho e determinar que ela é sensível à latência da rede entre zonas, talvez seja necessário considerar a localização física dos componentes da carga de trabalho próximos uns dos outros para minimizar a latência quando eles se comunicam.

• Excelência Operacional: Uma arquitetura complexa exige mais esforço para implantar, configurar e gerenciar. Para uma solução altamente disponível, você também pode precisar planejar como fazer failover para um conjunto secundário de recursos. Failover, failback e redirecionamento transparente do tráfego podem ser complexos, especialmente quando etapas manuais são necessárias. É uma boa prática automatizar seus processos de implantação e gerenciamento. Para obter mais informações, consulte os guias do pilar Excelência Operacional, incluindo OE:05 Infrastructure as code, OE:09 Task automation, OE:10 Automation design e OE:11 Deployment practices.

O pilar Segurança aplica-se independentemente da forma como concebe a sua solução. Normalmente, as decisões sobre se e como você usa zonas e regiões de disponibilidade não mudam sua postura de segurança. O Azure aplica o mesmo rigor de segurança a todas as regiões e zonas de disponibilidade.

Definições

Compreender como as regiões e zonas de disponibilidade são organizadas no Azure

O Azure tem muitos datacenters em todo o mundo. Uma região do Azure é um perímetro geográfico que contém um conjunto de datacenters. Você precisa ter uma compreensão completa das regiões e zonas de disponibilidade do Azure.

As regiões do Azure têm várias configurações, que também são conhecidas como arquiteturas de região.

Muitas regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de datacenters. Dentro de uma região, as zonas de disponibilidade estão próximas o suficiente para ter conexões de baixa latência com outras zonas de disponibilidade, mas distantes o suficiente para reduzir a probabilidade de que mais de uma zona seja afetada por interrupções locais ou pelo clima. As zonas de disponibilidade têm infraestrutura independente de energia, refrigeração e rede. Eles são projetados para que, se uma zona sofrer uma interrupção, as zonas restantes possam continuar a oferecer suporte a serviços regionais, capacidade e alta disponibilidade.

O diagrama a seguir mostra vários exemplos de regiões do Azure. As regiões 1 e 2 suportam zonas de disponibilidade.

Se você implantar em uma região do Azure que contém zonas de disponibilidade, poderá usar várias zonas de disponibilidade juntas. Usando várias zonas de disponibilidade, você pode manter cópias separadas de seu aplicativo e dados em datacenters físicos separados em uma grande área metropolitana.

Há duas maneiras de usar zonas de disponibilidade em uma solução:

• Os recursos zonais são fixados em uma zona de disponibilidade específica. Você pode combinar várias implantações zonais em diferentes zonas para atender aos requisitos de alta confiabilidade. Você é responsável por gerenciar a replicação de dados e distribuir solicitações entre zonas. Se ocorrer uma interrupção em uma única zona de disponibilidade, você será responsável pelo failover para outra zona de disponibilidade.

• Os recursos redundantes de zona estão distribuídos por várias zonas de disponibilidade. A Microsoft gerencia a distribuição de solicitações e a replicação de dados entre zonas. Se ocorrer uma interrupção em uma única zona de disponibilidade, a Microsoft gerenciará o failover automaticamente.

Os serviços do Azure dão suporte a uma ou ambas as abordagens. As soluções de plataforma como serviço (PaaS) normalmente suportam implantações com redundância de zona. As soluções de infraestrutura como serviço (IaaS) normalmente oferecem suporte a implantações zonais. Para obter mais informações sobre como os serviços do Azure funcionam com zonas de disponibilidade, consulte Serviços do Azure com suporte à zona de disponibilidade.

A Microsoft tenta usar abordagens que causam menos interrupções durante as implantações de atualização de serviço. Por exemplo, a Microsoft pretende implantar atualizações em uma única zona de disponibilidade de cada vez. Essa abordagem pode reduzir o impacto que as atualizações podem ter em uma carga de trabalho ativa porque a carga de trabalho pode continuar a ser executada em outras zonas enquanto a atualização está em processo. No entanto, em última análise, é responsabilidade da equipe de carga de trabalho garantir que sua carga de trabalho continue a funcionar durante as atualizações da plataforma. Por exemplo, quando você usa conjuntos de dimensionamento de máquina virtual com o modo de orquestração flexível ou a maioria dos serviços PaaS do Azure, o Azure coloca seus recursos de forma inteligente para reduzir o impacto das atualizações da plataforma. Considere o provisionamento excessivo, que é implantar mais instâncias de um recurso, para que algumas instâncias permaneçam disponíveis enquanto outras instâncias são atualizadas. Para obter mais informações sobre como o Azure implanta atualizações, consulte Práticas avançadas de implantação segura.

Muitas regiões também têm uma região emparelhada. As regiões emparelhadas suportam certos tipos de abordagens de implantação multirregionais. Algumas regiões mais recentes têm várias zonas de disponibilidade e não têm uma região emparelhada. Você ainda pode implantar soluções de várias regiões nessas regiões, mas as abordagens usadas podem ser diferentes.

Para obter mais informações sobre como o Azure usa regiões e zonas de disponibilidade, consulte Regiões e zonas de disponibilidade do Azure.

Compreender as responsabilidades partilhadas

O princípio da responsabilidade compartilhada descreve como as responsabilidades são divididas entre o provedor de nuvem e você. Dependendo do tipo de serviços que você usa, você pode assumir mais ou menos responsabilidade pela operação do serviço.

A Microsoft fornece zonas e regiões de disponibilidade para lhe dar flexibilidade na forma como concebe a sua solução para satisfazer os seus requisitos. Quando utiliza serviços geridos, a Microsoft assume mais responsabilidades de gestão dos seus recursos. Essas responsabilidades podem incluir replicação de dados, failover, failback e outras tarefas relacionadas à operação de um sistema distribuído.

Seu próprio código precisa seguir práticas recomendadas e padrões de design para lidar com falhas normalmente. Essas práticas são especialmente importantes durante operações de failover, como operações que acontecem quando ocorre um failover de zona de disponibilidade ou região, porque o failover entre zonas ou regiões geralmente exige que seu aplicativo tente novamente conexões com serviços.

Identificar os principais requisitos de negócios e carga de trabalho

Para tomar uma decisão informada sobre como usar zonas e regiões de disponibilidade em sua solução, você precisa entender seus requisitos. Discussões entre designers de soluções e partes interessadas do negócio devem orientar esses requisitos.

Tolerância ao risco

Diferentes organizações têm diferentes graus de tolerância ao risco. Mesmo dentro de uma única organização, a tolerância ao risco geralmente difere de acordo com a carga de trabalho. A maioria das cargas de trabalho não requer disponibilidade extremamente alta. No entanto, algumas cargas de trabalho são tão críticas que vale a pena mitigar até mesmo riscos improváveis, como grandes desastres naturais que afetam uma ampla área geográfica.

A tabela a seguir lista alguns dos riscos comuns que você deve considerar em um ambiente de nuvem.

É ideal para mitigar todos os riscos possíveis para cada carga de trabalho. No entanto, esta abordagem não é prática nem rentável. É importante ter uma discussão aberta com as partes interessadas do negócio para que você possa tomar decisões informadas sobre os riscos que você deve mitigar.

Requisitos de resiliência

É importante entender os requisitos de resiliência para sua carga de trabalho, incluindo o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e o RPO (Recovery Point Objetive, objetivo de ponto de recuperação). Esses objetivos ajudam você a decidir quais abordagens descartar. Se você não tem requisitos claros, você não pode tomar uma decisão informada sobre qual abordagem seguir. Para obter mais informações, consulte Estratégias de arquitetura para identificar e classificar fluxos.

Objetivos de nível de serviço

Você deve entender o SLO (objetivo de nível de serviço) de tempo de atividade esperado da sua solução. Por exemplo, você pode ter um requisito de negócios de que sua solução precisa atender a 99,9% tempo de atividade.

O Azure fornece contratos de nível de serviço (SLAs) para cada serviço. Um SLA indica o nível de tempo de atividade que você deve esperar do serviço e as condições que você precisa atender para atingir o SLA esperado. No entanto, lembre-se de que a maneira como um SLA do Azure define a disponibilidade do serviço nem sempre está alinhada com a forma como você avalia a integridade da sua carga de trabalho.

Suas decisões de arquitetura afetam o SLO composto da solução. Em geral, quanto mais redundância você incorporar à sua solução, maior será a probabilidade de seu SLO. Muitos serviços do Azure fornecem SLAs mais altos quando você implanta serviços em uma configuração com redundância de zona ou de várias regiões. Analise os SLAs de cada um dos serviços do Azure que você usa para garantir que você entenda como maximizar a resiliência e o SLA do serviço.

Residência de dados

Algumas organizações impõem restrições aos locais físicos nos quais seus dados podem ser armazenados e processados. Por vezes, estes requisitos baseiam-se em normas legais ou regulamentares. Em outros cenários, uma organização pode decidir adotar uma política de residência de dados para evitar preocupações com os clientes. Se você tiver requisitos estritos de residência de dados, talvez seja necessário usar uma implantação de região única ou um subconjunto de regiões e serviços do Azure.

Localização do utilizador

Ao entender onde seus usuários estão localizados, você pode tomar uma decisão informada sobre como otimizar a latência e a confiabilidade para suas necessidades. O Azure fornece muitas opções para dar suporte a uma base de usuários geograficamente dispersa.

Se seus usuários estiverem concentrados em uma área, uma implantação de região única pode simplificar seus requisitos operacionais e reduzir seus custos. No entanto, você precisa considerar se uma implantação de região única atende aos seus requisitos de confiabilidade. Para aplicativos de missão crítica, você ainda deve usar uma implantação de várias regiões, mesmo que seus usuários estejam colocalizados.

Se os usuários estiverem geograficamente dispersos, talvez faça sentido implantar sua carga de trabalho em várias regiões. Os serviços do Azure fornecem diferentes recursos para dar suporte a uma implantação em várias regiões, e você pode usar a pegada global do Azure para melhorar sua experiência de usuário e aproximar seus aplicativos de sua base de usuários. Você pode usar o padrão Selos de Implantação ou o padrão Geodes ou replicar seus recursos em várias regiões.

Mesmo que seus usuários estejam em áreas geográficas diferentes, considere se você precisa de uma implantação em várias regiões. Considere se você pode atingir seus requisitos em uma única região usando a aceleração de tráfego global, como a aceleração que o Azure Front Door oferece.

Orçamento

Se você opera com um orçamento restrito, é importante considerar os custos envolvidos na implantação de componentes de carga de trabalho redundantes. Esses custos podem incluir taxas de recursos extras, custos de rede e os custos operacionais de gerenciar mais recursos e um ambiente mais complexo.

Complexidade

É uma boa prática para evitar complexidade desnecessária na arquitetura da solução. Quanto mais complexidade você introduzir, mais difícil se torna tomar decisões sobre sua arquitetura. Arquiteturas complexas são mais difíceis de operar, mais difíceis de proteger e, muitas vezes, com menor desempenho. Certifique-se de seguir o princípio da simplicidade.

Cenário de exemplo

Ao fornecer regiões e zonas de disponibilidade, o Azure permite que você selecione uma abordagem de implantação que atenda às suas necessidades. Cada abordagem proporciona benefícios específicos e incorre em custos associados.

Para ilustrar as abordagens de implantação que você pode usar, considere um cenário de exemplo. Suponha que você queira implantar uma nova solução que inclua um aplicativo que grava dados em algum tipo de armazenamento.

Este exemplo não é específico de nenhum serviço específico do Azure. Pretende-se fornecer um exemplo para ilustrar conceitos fundamentais.

Há várias maneiras de implantar essa solução. Cada abordagem proporciona um conjunto diferente de benefícios e incorre em custos diferentes. Em um alto nível, você pode considerar uma implantação localmente redundante, zonal (fixada),redundante de zona ou multirregião . O quadro seguinte resume algumas das preocupações dos pilares.

A tabela a seguir resume algumas das abordagens que você pode usar e como elas afetam sua arquitetura.

O restante deste artigo descreve cada uma das abordagens listadas na tabela anterior. A lista de abordagens não é exaustiva. Você pode decidir combinar várias abordagens ou usar abordagens diferentes em diferentes partes da sua solução.

Abordagem de implantação 1: implantações localmente redundantes

Se você não especificar várias zonas ou regiões de disponibilidade ao implantar seus recursos, o Azure não dará garantias sobre se os recursos serão implantados em um único datacenter ou divididos em vários datacenters na região. Em alguns cenários, o Azure também pode mover seu recurso entre zonas de disponibilidade.

A maioria dos recursos do Azure está altamente disponível por padrão, com SLAs altos e redundância interna em um datacenter gerenciado pela plataforma. No entanto, do ponto de vista da confiabilidade, se qualquer parte da região sofrer uma interrupção, há uma chance de que sua carga de trabalho possa ser afetada. Se estiver, sua solução pode estar indisponível ou seus dados podem ser perdidos.

Para cargas de trabalho altamente sensíveis à latência, essa abordagem também pode resultar em desempenho inferior. Os componentes da carga de trabalho podem não estar colocalizados no mesmo datacenter, portanto, você pode observar alguma latência para o tráfego intrarregião. O Azure também pode mover de forma transparente suas instâncias de serviço entre zonas de disponibilidade, o que pode afetar ligeiramente o desempenho. No entanto, essa queda no desempenho não é uma preocupação para a maioria das cargas de trabalho.

O quadro seguinte resume algumas das preocupações dos pilares.

A tabela a seguir resume algumas das preocupações de uma perspetiva arquitetônica.

Implantações localmente redundantes com backup entre regiões

Você pode estender uma implantação localmente redundante executando backups regulares de sua infraestrutura e dados para uma região secundária. Essa abordagem adiciona uma camada extra de proteção para mitigar uma interrupção na região principal.

Ao implementar essa abordagem, você precisa considerar cuidadosamente seu RTO e RPO.

• Tempo de recuperação: Se ocorrer uma interrupção regional, talvez seja necessário reconstruir sua solução em outra região do Azure, o que afeta seu tempo de recuperação. Considere criar sua solução usando uma abordagem de infraestrutura como código (IaC) para que você possa reimplantar rapidamente em outra região se ocorrer um desastre de grandes proporções. Certifique-se de que suas ferramentas e processos de implantação sejam tão resilientes quanto seus aplicativos para que você possa usá-los para reimplantar sua solução, mesmo se houver uma interrupção. Planeje e ensaie as etapas necessárias para restaurar sua solução de volta a um estado de trabalho.

• Ponto de recuperação: A frequência de backup determina a quantidade de perda de dados que você pode enfrentar, que é conhecida como seu ponto de recuperação. Normalmente, você pode controlar a frequência dos backups para atender ao seu RPO.

O quadro seguinte resume algumas das preocupações dos pilares.

A tabela a seguir resume algumas das preocupações de uma perspetiva arquitetônica.

Abordagem de implantação 2: implantações zonais (fixas)

Em uma implantação zonal , você especifica que seus recursos devem ser implantados em uma zona de disponibilidade específica. Essa abordagem às vezes é conhecida como uma implantação fixada por zona .

Uma abordagem zonal reduz a latência entre os componentes. No entanto, por si só, não aumenta a resiliência da sua solução. Para aumentar sua resiliência, você precisa implantar várias instâncias de seus componentes em várias zonas de disponibilidade e decidir como rotear o tráfego entre cada instância. Este exemplo mostra uma abordagem de roteamento de tráfego ativo-passivo .

No exemplo anterior, um balanceador de carga é implantado em várias zonas de disponibilidade. É importante considerar como você roteia o tráfego entre instâncias em diferentes zonas de disponibilidade, pois uma interrupção de zona também pode afetar os recursos de rede implantados nessa zona. Você também pode considerar o uso de um balanceador de carga global, como o Azure Front Door ou o Azure Traffic Manager, que não é implantado em uma região.

Ao usar um modelo de implantação zonal, você assume muitas responsabilidades:

• Você precisa implantar recursos em cada zona de disponibilidade e configurar e gerenciar esses recursos individualmente.

• Você precisa decidir como e quando replicar dados entre as zonas de disponibilidade e, em seguida, configurar e gerenciar a replicação.

• Você é responsável por distribuir as solicitações para os recursos corretos, como usar um balanceador de carga. Você precisa garantir que o balanceador de carga atenda aos seus requisitos de resiliência. Você também precisa decidir se deseja usar um modelo de distribuição de solicitação ativo-passivo ou ativo-ativo.

• Se uma zona de disponibilidade sofrer uma interrupção, você precisará lidar com o failover para enviar tráfego para recursos em outra zona de disponibilidade.

Uma implantação ativa-passiva em várias zonas de disponibilidade às vezes é conhecida como DR na região ou DR metro.

O quadro seguinte resume algumas das preocupações dos pilares.

A tabela a seguir resume algumas das preocupações de uma perspetiva arquitetônica.

Essa abordagem geralmente é usada para cargas de trabalho baseadas em máquinas virtuais (VMs). Para obter uma lista completa de serviços que oferecem suporte a implantações zonais, consulte Serviço de zona de disponibilidade e suporte regional.

Ao planejar uma implantação zonal, verifique se os serviços do Azure que você usa têm suporte nas zonas de disponibilidade que você planeja usar. Para listar quais SKUs de VM estão disponíveis em cada zona de disponibilidade, consulte Verificar disponibilidade de SKU de VM.

Abordagem de implantação 3: implantações com redundância de zona

Quando você usa essa abordagem, sua camada de aplicativo é distribuída em várias zonas de disponibilidade. Quando as solicitações chegam, um balanceador de carga integrado ao serviço dispersa as solicitações pelas instâncias em cada zona de disponibilidade. O serviço em si abrange zonas de disponibilidade. Se uma zona de disponibilidade sofrer uma interrupção, o balanceador de carga direcionará o tráfego para instâncias nas zonas de disponibilidade íntegras.

Seu nível de armazenamento também está distribuído em várias zonas de disponibilidade. As cópias dos dados do seu aplicativo são distribuídas em várias zonas de disponibilidade por meio da replicação síncrona. Quando o aplicativo faz uma alteração nos dados, o serviço de armazenamento grava a alteração em várias zonas de disponibilidade. A transação só é considerada concluída quando todas essas alterações estiverem concluídas. Esse processo garante que cada zona de disponibilidade sempre tenha uma cópia de data de up-todos dados. Se uma zona de disponibilidade sofrer uma interrupção, outra zona de disponibilidade poderá ser usada para acessar os mesmos dados.

Uma abordagem com redundância de zona aumenta a resiliência da solução a problemas como interrupções do datacenter. No entanto, como os dados são replicados de forma síncrona, seu aplicativo precisa aguardar que os dados sejam gravados em vários locais separados que podem estar em partes diferentes de uma área metropolitana. Para a maioria dos aplicativos, a latência na comunicação entre zonas é insignificante. No entanto, para algumas cargas de trabalho altamente sensíveis à latência, a replicação síncrona em zonas de disponibilidade pode afetar o desempenho do aplicativo.

O quadro seguinte resume algumas das preocupações dos pilares.

A tabela a seguir resume algumas das preocupações de uma perspetiva arquitetônica.

Essa abordagem é possível com muitos serviços do Azure, incluindo Conjuntos de Escala de Máquina Virtual do Azure, Serviço de Aplicativo do Azure, Azure Functions, Serviço de Kubernetes do Azure (AKS), Armazenamento do Azure, Azure SQL, Barramento de Serviço do Azure e muitos outros serviços. Para obter uma lista completa dos serviços que suportam redundância de zona, consulte Serviço de zona de disponibilidade e suporte regional.

Implantações com redundância de zona com backup entre regiões

Você pode estender uma implantação com redundância de zona executando backups regulares de sua infraestrutura e dados para uma região secundária. Essa abordagem oferece os benefícios de uma abordagem redundante de zona e adiciona uma camada de proteção para mitigar o evento extremamente improvável de uma interrupção completa da região.

Ao implementar essa abordagem, você precisa considerar cuidadosamente seu RTO e RPO.

• Tempo de recuperação: Se ocorrer uma interrupção regional, talvez seja necessário reconstruir sua solução em outra região do Azure, o que afeta seu tempo de recuperação. Considere criar sua solução usando uma abordagem IaC para que você possa reimplantar rapidamente em outra região durante um desastre de grandes proporções. Certifique-se de que suas ferramentas e processos de implantação sejam tão resilientes quanto seus aplicativos, para que você possa usá-los para reimplantar sua solução, mesmo se ocorrer uma interrupção. Planeje e ensaie as etapas necessárias para restaurar sua solução de volta a um estado de trabalho.

• Ponto de recuperação: A frequência de backup determina a quantidade de perda de dados que você pode enfrentar, conhecida como seu ponto de recuperação. Normalmente, você pode controlar a frequência dos backups para atender ao seu RPO.

O quadro seguinte resume algumas das preocupações dos pilares.

A tabela a seguir resume algumas das preocupações de uma perspetiva arquitetônica.

Abordagem de implantação 4: implantações em várias regiões

Você pode usar várias regiões do Azure juntas para distribuir sua solução em uma ampla área geográfica. Você pode usar essa abordagem de várias regiões para melhorar a confiabilidade da sua solução ou para oferecer suporte a usuários distribuídos geograficamente. Ao implantar em várias regiões, você também reduz o risco de encontrar uma restrição temporária de capacidade de recursos em uma única região. Se a residência de dados for uma preocupação importante para sua solução, considere cuidadosamente quais regiões você usa para garantir que seus dados sejam armazenados apenas em locais que atendam às suas necessidades.

Regiões ativas e passivas

As arquiteturas de várias regiões são complexas e há muitas maneiras de projetar uma solução de várias regiões. Para algumas cargas de trabalho, faz sentido ter várias regiões processando ativamente solicitações simultaneamente (implantações ativas-ativas). Para outras cargas de trabalho, é melhor designar uma região primária e usar uma ou mais regiões secundárias para failover (implantações ativo-passivas). Esta seção se concentra no segundo cenário, no qual uma região é ativa e outra é passiva. Para obter mais informações sobre soluções multirregiões ativas, consulte Padrão de carimbos de implantação e Padrão Geode.

Replicação de dados

A comunicação entre regiões é muito mais lenta do que a comunicação intrarregião. Em geral, uma distância geográfica maior entre duas regiões incorre em mais latência de rede devido à maior distância física que os dados precisam percorrer. Para obter mais informações sobre a latência de rede esperada quando você se conecta entre duas regiões, consulte Estatísticas de latência de ida e volta da rede do Azure.

A latência da rede entre regiões pode afetar significativamente o design da solução, pois você precisa considerar cuidadosamente como a latência extra afeta a replicação de dados e outras transações. Para muitas soluções, uma arquitetura entre regiões requer replicação assíncrona para minimizar o efeito do tráfego entre regiões no desempenho.

Replicação assíncrona de dados

Quando você implementa a replicação assíncrona entre regiões, seu aplicativo não espera que todas as regiões reconheçam uma alteração. Depois que a alteração for confirmada na região primária, a transação será considerada concluída. A alteração é replicada para as regiões secundárias posteriormente. Essa abordagem garante que a latência da conexão entre regiões não afete diretamente o desempenho do aplicativo. No entanto, devido ao atraso na replicação, uma interrupção em toda a região pode resultar em alguma perda de dados. Essa perda de dados pode ocorrer porque uma região pode sofrer uma interrupção após a conclusão de uma gravação na região primária, mas antes que a alteração seja replicada para outra região.

O quadro seguinte resume algumas das preocupações dos pilares.

A tabela a seguir resume algumas das preocupações de uma perspetiva arquitetônica.

Replicação síncrona de dados

Se você implementar uma solução síncrona de várias regiões, seu aplicativo precisará aguardar a conclusão das operações de gravação em cada região do Azure antes que a transação seja considerada concluída. A latência incorrida ao aguardar operações de gravação depende da distância entre as regiões. Para muitas cargas de trabalho, a latência entre regiões pode tornar a replicação síncrona muito lenta para ser útil.

O quadro seguinte resume algumas das preocupações dos pilares.

A tabela a seguir resume algumas das preocupações de uma perspetiva arquitetônica.

Arquiteturas de região

Ao projetar uma solução de várias regiões, considere se as regiões do Azure que você planeja usar estão emparelhadas.

Você pode criar uma solução de várias regiões mesmo quando as regiões não estão emparelhadas. No entanto, as abordagens que você usa para implementar uma arquitetura de várias regiões podem ser diferentes. Por exemplo, em Armazenamento, você pode usar armazenamento com redundância geográfica (GRS) com regiões emparelhadas. Se o GRS não estiver disponível, considere usar recursos como replicação de objetos de armazenamento ou projetar seu aplicativo para gravar em várias regiões.

Combine abordagens multi-zona e multi-região

Você deve combinar declarações multizona e multirregião se os requisitos do seu negócio exigirem tal solução. Por exemplo, você pode implantar componentes redundantes de zona em cada região e também configurar a replicação entre as regiões. Para algumas soluções, esta abordagem proporciona um grau muito elevado de fiabilidade. No entanto, configurar esse tipo de abordagem pode ser complicado e caro.

Como os serviços do Azure dão suporte a abordagens de implantação

É importante entender os detalhes específicos dos serviços do Azure que você usa. Por exemplo, alguns serviços do Azure exigem que você configure sua configuração de zona de disponibilidade quando você implanta o recurso pela primeira vez, enquanto outros serviços oferecem suporte à alteração da abordagem de implantação posteriormente. Da mesma forma, alguns recursos de serviço podem não estar disponíveis com todas as abordagens de implantação.

Para saber mais sobre as opções e abordagens de implantação específicas a serem consideradas para cada serviço do Azure, visite o hub de confiabilidade.

Exemplos de casos de uso

Esta seção descreve alguns casos de uso comuns e os principais requisitos que você normalmente precisa considerar para cada carga de trabalho. Para cada carga de trabalho, uma ou mais abordagens de implantação sugeridas são fornecidas, com base nos requisitos e abordagens descritos neste artigo.

Aplicativo de linha de negócios para uma empresa

A Contoso, Ltd., é uma grande empresa de manufatura. A empresa está implementando um aplicativo de linha de negócios (LOB) para gerenciar alguns componentes de seus processos financeiros.

Requisitos de negócio: As informações que o sistema gere são difíceis de substituir, pelo que os dados têm de ser mantidos de forma fiável. Os arquitetos precisam que o sistema incorra no menor tempo de inatividade e perda de dados possível. Os funcionários da Contoso usam o sistema durante todo o dia de trabalho, portanto, o alto desempenho é importante para evitar manter os membros da equipe esperando. O custo também é uma preocupação porque a equipe financeira tem que pagar pela solução.

Abordagem sugerida:A implantação com redundância de zona com backup entre regiões fornece várias camadas de resiliência com alto desempenho.

Aplicação interna

A Fourth Coffee é um pequeno negócio. A empresa está desenvolvendo um novo aplicativo interno que os funcionários podem usar para enviar quadros de horários.

Requisitos de negócio: Para esta carga de trabalho, a eficiência de custos é uma preocupação primordial. A Fourth Coffee avaliou o impacto do tempo de inatividade nos negócios e decidiu que o aplicativo não precisa priorizar resiliência ou desempenho. A empresa aceita o risco de que uma interrupção em uma zona ou região de disponibilidade do Azure possa tornar o aplicativo temporariamente indisponível.

Abordagens sugeridas:

• A implantação localmente redundante com backups entre regiões tem o menor custo, mas também tem riscos significativos.

• A implantação com redundância de zona com backup entre regiões oferece melhor resiliência, mas a um custo um pouco maior.

Migração de aplicativos herdados

A Fabrikam, Inc., está migrando um aplicativo herdado de um datacenter local para o Azure. Eles planejam usar uma abordagem IaaS baseada em VMs. O aplicativo não foi projetado para um ambiente de nuvem e a comunicação entre a camada de aplicativo e o banco de dados é muito tagarela.

Requisitos de negócio: O desempenho é uma prioridade para esta aplicação. A resiliência também é importante, e o aplicativo deve continuar a funcionar mesmo se um datacenter do Azure sofrer uma interrupção.

Abordagem sugerida:

• A Fabrikam deve primeiro tentar uma implantação com redundância de zona. Devem verificar se o desempenho cumpre os seus requisitos.

• Se o desempenho da solução com redundância de zona não for aceitável, eles devem considerar uma implantação zonal (fixada), com implantações passivas em várias zonas de disponibilidade (DR na região).

Aplicação de cuidados de saúde

A Lamna Healthcare Company está implementando um novo sistema de registro de saúde eletrônico no Azure.

Requisitos de negócio: Devido à natureza dos dados que esta solução armazena, a residência de dados é extremamente importante. A Lamna opera sob uma estrutura regulatória rígida que determina que os dados devem permanecer em um local específico.

Abordagens sugeridas:

• Implantação multi-região multi-região, se houver várias regiões que se encaixam nos requisitos de residência de dados do Lamna.

• Se houver apenas uma única região que atenda às suas necessidades, eles devem considerar uma implantação com redundância de zona ou uma implantação com redundância de zona com backup entre regiões que forneça uma solução de região única.

Sistema bancário

O Woodgrove Bank executa suas principais operações bancárias a partir de uma grande solução implantada no Azure.

Requisitos de negócio: Este sistema é de missão crítica. Qualquer interrupção pode causar um grande impacto financeiro para os clientes. Como resultado, o Woodgrove Bank tem uma tolerância ao risco muito baixa. O sistema precisa do mais alto nível de confiabilidade possível, e a arquitetura precisa mitigar o risco de quaisquer falhas que possam ser mitigadas.

Abordagem sugerida: Para um sistema de missão crítica, eles devem usar uma implantação multizona multirregião e garantir que as regiões se encaixem nos requisitos de residência de dados da empresa.

Software como serviço

A Proseware, Inc., constrói software que as empresas de todo o mundo utilizam. A base de usuários da empresa é amplamente distribuída geograficamente.

Requisitos de negócio: A Proseware precisa permitir que cada um de seus clientes escolha uma região de implantação próxima ao cliente. Habilitar essa escolha é importante para a latência e para os requisitos de residência de dados dos clientes.

Abordagens sugeridas:

• A implantação multirregião de várias zonas geralmente é uma boa opção para um provedor de software como serviço (SaaS), especialmente quando é usado dentro do padrão de Selos de Implantação.

• Implantação redundante de zona única com uma solução de aceleração de tráfego global, como o Azure Front Door.

Próximos passos

As arquiteturas de referência e cenários de exemplo a seguir são para soluções de várias zonas e várias regiões:

• Aplicativo Web com redundância de zona altamente disponível de linha de base
• Aplicação Web multi-região altamente disponível
• Aplicativo de N camadas de várias regiões
• Aplicação Web multicamadas criada para alta disponibilidade e DR

Use os seguintes serviços do Azure para implementar soluções em várias zonas de disponibilidade:

• Azure Site Recovery: Habilitar o DR da VM do Azure entre zonas de disponibilidade
• Arquivos NetApp do Azure: entenda a replicação entre zonas dos Arquivos NetApp do Azure
• Redundância do Armazenamento do Azure