Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este guia descreve as recomendações para determinar quando implantar cargas de trabalho entre zonas ou regiões de disponibilidade.
Ao criar 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 e a capacidade de 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 principais pilares do Azure Well-Architected Framework.
As regiões do Azure que você usa para sua solução são uma opção crítica. O guia Selecionar Regiões do Azure descreve como selecionar e operar em várias regiões geográficas. 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 atenuar vários tipos de riscos. Em geral, ao espalhar sua carga de trabalho por uma área mais distribuída geograficamente, você pode obter maior resiliência.
Otimização de custo: Algumas abordagens de arquitetura 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 entre zonas ou regiões de disponibilidade geograficamente separadas, o que pode incorrer em encargos de tráfego de rede. Também é importante considerar o custo contínuo de 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 em conjunto 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 habilitar 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 de rede entre zonas, talvez seja necessário considerar a localização física dos componentes da carga de trabalho para minimizar a latência quando eles se comunicarem.
Excelência Operacional: Uma arquitetura complexa exige mais esforço para implantar, configurar e gerenciar. Para uma solução altamente disponível, talvez você também precise planejar como fazer failover para um conjunto secundário de recursos. O failover, o failback e o redirecionamento transparente do tráfego podem ser complexos, especialmente quando são necessárias etapas manuais. É uma boa prática automatizar seus processos de implantação e gerenciamento. Para obter mais informações, consulte os guias do pilar de Excelência Operacional, incluindo a Infraestrutura OE:05 como código, a automação de tarefas OE:09, o design da Automação OE:10 e as práticas de implantação do OE:11.
O pilar de segurança se aplica independentemente de como você projeta 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.
Dica
Para muitas cargas de trabalho de produção, uma implantação com redundância de zona fornece o melhor saldo de compensações. Você pode estender essa abordagem com backup de dados assíncrono para outra região. Se você não tiver certeza de qual abordagem selecionar, comece com esse tipo de implantação.
Considere outras abordagens de carga de trabalho quando você precisar dos benefícios específicos que essas abordagens fornecem, mas esteja ciente das compensações.
Definições
| Prazo | Definition |
|---|---|
| Active-active | Uma arquitetura na qual várias instâncias de uma solução processam ativamente solicitações ao mesmo tempo. |
| Active-passive | Uma arquitetura na qual uma instância de uma solução é designada como o principal e processa o tráfego e uma ou mais instâncias secundárias são implantadas para atender ao tráfego se a instância primária não estiver disponível. |
| Replicação assíncrona | Uma abordagem de replicação de dados na qual os dados são gravados e confirmados em um local. Posteriormente, as alterações são replicadas para outro local. |
| Zona de disponibilidade | Um grupo separado de datacenters em uma região. Cada zona de disponibilidade é independente das outras zonas de disponibilidade e tem sua própria infraestrutura de energia, resfriamento e rede. Muitas regiões dão suporte a zonas de disponibilidade. |
| Datacenter | Uma instalação que contém servidores, equipamentos de rede e outros hardwares para dar suporte a recursos e cargas de trabalho do Azure. |
| Implantação com redundância local | Um modelo de implantação no qual um recurso é implantado em uma única região sem referência a uma zona de disponibilidade. Em uma região que dá suporte a zonas de disponibilidade, o recurso pode ser implantado em qualquer uma das zonas de disponibilidade da região. |
| Implantação de várias regiões | Um modelo de implantação no qual os recursos são implantados em várias regiões do Azure. |
| Regiões emparelhadas | Uma relação entre duas regiões do Azure. Algumas regiões do Azure estão conectadas a outra região definida para habilitar tipos específicos de soluções de várias regiões. Regiões mais recentes do Azure não são emparelhadas. |
| Região | Um perímetro geográfico que contém um conjunto de datacenters. |
| Arquitetura de região | A configuração específica da região do Azure, incluindo o número de zonas de disponibilidade e se a região está emparelhada com outra região. |
| Replicação síncrona | Uma abordagem de replicação de dados na qual os dados são gravados e confirmados em vários locais. Cada local deve reconhecer a conclusão da operação de gravação antes que a operação de gravação geral seja considerada concluída. |
| Implantação zonal (fixada) | Um modelo de implantação no qual um recurso é implantado em uma zona de disponibilidade específica. |
| Implantação com redundância de zona | Um modelo de implantação no qual um recurso é implantado em várias zonas de disponibilidade. A Microsoft gerencia a sincronização de dados, a distribuição de tráfego e o failover se uma zona sofrer uma interrupção. |
Entender como as regiões e as 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 do Azure e das zonas de disponibilidade.
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. Em uma região, as zonas de disponibilidade sã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 clima. As zonas de disponibilidade têm energia, resfriamento e infraestrutura de rede independentes. Eles são projetados para que, se uma zona sofrer uma interrupção, as zonas restantes possam continuar a dar 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 dão suporte a 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 com redundância de zona são distribuídos entre 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 paaS (plataforma como serviço) normalmente dão suporte a implantações com redundância de zona. As soluções de IaaS (infraestrutura como serviço) normalmente dão suporte a implantações zonais. Para obter mais informações sobre como os serviços do Azure funcionam com zonas de disponibilidade, consulte os serviços do Azure com suporte à zona de disponibilidade.
A Microsoft tenta usar abordagens que são as menos disruptivas durante implantações de atualização de serviço. Por exemplo, a Microsoft pretende implantar atualizações em uma única zona de disponibilidade por 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, é responsabilidade da equipe de carga de trabalho garantir que sua carga de trabalho continue funcionando durante as atualizações da plataforma. Por exemplo, quando você usa conjuntos de dimensionamento de máquinas virtuais com o modo de orquestração flexível ou a maioria dos serviços de PaaS do Azure, o Azure coloca seus recursos de forma inteligente para reduzir o impacto das atualizações da plataforma. Considere o excesso de provisionamento, que está implantando 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 As práticas avançadas de implantação segura.
Muitas regiões também têm uma região emparelhada. Regiões emparelhadas dão suporte a determinados tipos de abordagens de implantação de várias regiões. 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 que você usa podem ser diferentes.
Para obter mais informações sobre como o Azure usa regiões e zonas de disponibilidade, consulte regiões do Azure e zonas de disponibilidade.
Entender as responsabilidades compartilhadas
O princípio de responsabilidade compartilhada descreve como as responsabilidades são divididas entre o provedor de nuvem e você. Dependendo do tipo de serviço que você usa, você pode assumir mais ou menos responsabilidade pela operação do serviço.
A Microsoft fornece zonas de disponibilidade e regiões para oferecer flexibilidade na forma como você projeta sua solução para atender aos seus requisitos. Quando você usa serviços gerenciados, a Microsoft assume mais responsabilidades de gerenciamento para 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 ocorrem quando ocorre uma zona de disponibilidade ou failover de região, porque o failover entre zonas ou regiões geralmente exige que seu aplicativo repita 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. As discussões entre designers de soluções e stakeholders de negócios devem impulsionar esses requisitos.
Tolerância a riscos
Diferentes organizações têm diferentes graus de tolerância a riscos. Mesmo em uma única organização, a tolerância a riscos geralmente difere por carga de trabalho. A maioria das cargas de trabalho não exige disponibilidade extremamente alta. No entanto, algumas cargas de trabalho são tão críticas que vale a pena atenuar riscos até mesmo 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.
| Risco | Exemplos | Probabilidade |
|---|---|---|
| Interrupção de hardware | - Problema com disco rígido ou equipamento de rede - Reinicializações de host |
Alto. Qualquer estratégia de resiliência deve considerar esses riscos. |
| Interrupção do datacenter | - Energia, resfriamento ou falha de rede em um datacenter inteiro - Desastre natural em uma parte de uma área metropolitana |
Medium |
| Interrupção da região | – Grande desastre natural que afeta uma ampla área geográfica - Problema de rede ou serviço que torna um ou mais serviços do Azure indisponíveis em uma região inteira |
Low |
É ideal reduzir todos os riscos possíveis para cada carga de trabalho. No entanto, essa abordagem não é prática ou econômica. É importante ter uma discussão aberta com os stakeholders de negócios para que você possa tomar decisões informadas sobre os riscos que devem ser mitigados.
Dica
Independentemente das metas de confiabilidade, todas as cargas de trabalho devem ter alguma mitigação para recuperação de desastre (DR). Se sua carga de trabalho exigir destinos de alta confiabilidade, suas estratégias de mitigação deverão ser abrangentes e você deverá reduzir o risco de eventos de baixa probabilidade. Para outras cargas de trabalho, tome uma decisão informada sobre quais riscos são aceitáveis e quais riscos precisam de mitigação.
Requisitos de confiabilidade
É fundamental entender os requisitos de confiabilidade para sua carga de trabalho, por exemplo, concordar com metas de recuperação, como RTO (objetivos de tempo de recuperação) e RPO (objetivos de ponto de recuperação). Os requisitos de confiabilidade ajudam você a decidir quais abordagens descartar. Se você não tiver requisitos claros, não poderá 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 ao 99.9% tempo de atividade.
O Azure fornece SLAs (contratos de nível de serviço) 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 alcançar o SLA esperado. No entanto, lembre-se de que a maneira como um SLA do Azure define a disponibilidade do serviço pode nem sempre se alinhar com a forma como você avalia a integridade da carga de trabalho.
Suas decisões de arquitetura afetam o SLO composto da solução. Em geral, quanto mais redundância você criar em sua solução, maior será o seu SLO. Muitos serviços do Azure fornecem SLAs mais altos quando você implanta serviços em uma configuração de várias regiões ou com redundância de zona. Examine os SLAs para 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 dadosResidência de dados
Algumas organizações impõem restrições aos locais físicos nos quais seus dados podem ser armazenados e processados. Às vezes, esses requisitos são baseados em padrões legais ou regulatórios. Em outros cenários, uma organização pode decidir adotar uma política de residência de dados para evitar preocupações do cliente. Se você tiver requisitos estritos de residência de dados, talvez seja necessário usar uma implantação de região única ou usar um subconjunto de regiões e serviços do Azure.
Observação
Evite fazer suposições infundadas sobre seus requisitos de residência de dados. Se você precisar cumprir as normas regulatórias específicas, verifique o que esses padrões realmente especificam.
Localização do usuário
Ao entender onde os 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 os usuários estiverem concentrados em uma área, uma implantação de região única poderá 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 críticos, você ainda deve usar uma implantação de várias regiões mesmo se os usuários estiverem colocados.
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 recursos diferentes para dar suporte a uma implantação de várias regiões e você pode usar o volume global do Azure para melhorar a experiência do usuário e aproximar seus aplicativos da 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 os usuários estejam em diferentes áreas geográficas, considere se você precisa de uma implantação de várias regiões. Considere se você pode alcançar seus requisitos em uma única região usando a aceleração de tráfego global, como a aceleração fornecida pelo Azure Front Door .
Orçamento
Se você operar com um orçamento restrito, é importante considerar os custos envolvidos na implantação de componentes de carga de trabalho redundantes. Esses custos podem incluir encargos extras de recursos, custos de rede e os custos operacionais de gerenciamento de mais recursos e um ambiente mais complexo.
Complexidade
É uma boa prática evitar complexidade desnecessária em sua arquitetura de solução. Quanto mais complexidade você introduzir, mais difícil fica tomar decisões sobre sua arquitetura. Arquiteturas complexas são mais difíceis de operar, mais difíceis de proteger e, muitas vezes, menos performantes. Verifique se você segue 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 fornece 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 para nenhum serviço específico do Azure. Ele destina-se a fornecer um exemplo para ilustrar conceitos fundamentais.
Há várias maneiras de implantar essa solução. Cada abordagem fornece um conjunto diferente de benefícios e gera custos diferentes. Em um alto nível, você pode considerar uma implantação localmente redundante, zonal (fixada),com redundância de zona ou várias regiões . A tabela a seguir resume algumas das preocupações de pilar.
| Pilar | Com redundância local | Zonal (fixado) | Zone-redundant | Várias regiões |
|---|---|---|---|---|
| Reliability | Baixa confiabilidade | Depende da abordagem | Confiabilidade alta ou muito alta | Confiabilidade alta ou muito alta |
| Otimização de custos | Baixo custo | Depende da abordagem | Custo moderado | Alto custo |
| Eficiência de desempenho | Desempenho aceitável (para a maioria das cargas de trabalho) | Alto desempenho | Desempenho aceitável (para a maioria das cargas de trabalho) | Depende da abordagem |
| Excelência operacional | Requisitos operacionais baixos | Requisitos operacionais elevados | Requisitos operacionais baixos | Requisitos operacionais elevados |
A tabela a seguir resume algumas das abordagens que você pode usar e como elas afetam sua arquitetura.
| Preocupação com arquitetura | Com redundância local | Zonal (fixado) | Zone-redundant | Várias regiões |
|---|---|---|---|---|
| Conformidade com a residência de dados | High | High | High | Depende da região |
| Disponibilidade regional | Todas as regiões | Regiões com zonas de disponibilidade | Regiões com zonas de disponibilidade | Depende da região |
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 com redundância local
Se você não especificar várias zonas de disponibilidade ou regiões ao implantar seus recursos, o Azure não garante se os recursos são implantados em um único datacenter ou divididos entre 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 altos SLAs 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 menor desempenho. Seus componentes de carga de trabalho podem não ser colocados no mesmo datacenter, portanto, você pode observar alguma latência para o tráfego intra-regiã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.
A tabela a seguir resume algumas das preocupações de pilar.
| Pilar | Impacto |
|---|---|
| Reliability | Baixa confiabilidade. Os serviços estarão sujeitos a interrupções se um datacenter falhar. No entanto, você pode criar um aplicativo para ser resiliente a outros tipos de falhas. |
| Otimização de custos | Custo mais baixo. Você só precisa ter uma única instância de cada recurso e não incorre em custos de largura de banda entre regiões. |
| Eficiência de desempenho |
-
Para a maioria das cargas de trabalho:Desempenho aceitável. Essa abordagem provavelmente fornecerá um desempenho satisfatório. - Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Os componentes podem residir em zonas de disponibilidade diferentes, de modo que componentes altamente sensíveis à latência possam ter um desempenho menor. |
| Excelência operacional | Alta eficiência operacional. Você só precisa implantar e gerenciar uma única instância de cada recurso. |
A tabela a seguir resume algumas das preocupações de uma perspectiva arquitetônica.
| Preocupação com arquitetura | Impacto |
|---|---|
| Conformidade com a residência de dados | Alto. Quando você implanta uma solução que usa essa abordagem, os dados são armazenados na região do Azure selecionada. |
| Disponibilidade regional | Alto. Essa abordagem pode ser usada em qualquer região do Azure. |
Implantações com redundância local com backup entre regiões
Você pode estender uma implantação com redundância local executando backups regulares de sua infraestrutura e dados para uma região secundária. Essa abordagem adiciona uma camada extra de proteção para atenuar uma interrupção em sua região primária.
Ao implementar essa abordagem, você precisa considerar cuidadosamente o RTO e o RPO.
Tempo de recuperação: Se ocorrer uma interrupção regional, talvez seja necessário recompilar sua solução em outra região do Azure, o que afeta o tempo de recuperação. Considere criar sua solução usando uma abordagem iac (infraestrutura como código) para que você possa reimplantar rapidamente em outra região se ocorrer um desastre importante. Verifique se suas ferramentas e processos de implantação são tão resilientes quanto seus aplicativos para que você possa usá-los para reimplantar sua solução mesmo que haja uma interrupção. Planeje e repita as etapas necessárias para restaurar sua solução para um estado de trabalho.
Ponto de recuperação: Sua frequência de backup determina a quantidade de perda de dados que você pode experimentar, que é conhecida como seu ponto de recuperação. Normalmente, você pode controlar a frequência de backups para que possa atender ao RPO.
A tabela a seguir resume algumas das preocupações de pilar.
| Pilar | Impacto |
|---|---|
| Reliability | Confiabilidade moderada. Os serviços estarão sujeitos a interrupções se um datacenter falhar. Os dados são armazenados de forma assíncrona em uma região geograficamente separada, o que reduz o efeito de uma interrupção de região completa minimizando a perda de dados. Em uma interrupção de região completa, você pode restaurar manualmente as operações em outra região. No entanto, os processos de recuperação podem ser complexos e pode levar tempo para serem restaurados manualmente na outra região. |
| Otimização de custos | Baixo custo. Normalmente, adicionar um backup a outra região custa apenas um pouco mais do que implantar um recurso com redundância local. |
| Eficiência de desempenho |
-
Para a maioria das cargas de trabalho:Desempenho aceitável. Essa abordagem provavelmente fornecerá um desempenho satisfatório. - Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Os componentes podem residir em zonas de disponibilidade diferentes, de modo que componentes altamente sensíveis à latência possam ter um desempenho menor. |
| Excelência operacional | Durante qualquer interrupção em uma região:baixa eficiência operacional. O failover é de sua responsabilidade e pode exigir operações manuais e reimplantações. |
A tabela a seguir resume algumas das preocupações de uma perspectiva arquitetônica.
| Preocupação com arquitetura | Impacto |
|---|---|
| Conformidade com a residência de dados | Depende da seleção de região. Os dados são armazenados principalmente na região do Azure especificada. No entanto, você precisa selecionar outra região para armazenar seus backups, portanto, é importante que você selecione uma região compatível com seus requisitos de residência de dados. |
| Disponibilidade regional | Alto. Você pode usar essa abordagem em qualquer região do Azure. |
Abordagem de implantação 2: implantações zonais (fixadas)
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 seus componentes. No entanto, por si só, isso 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 porque 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 Gerenciador de Tráfego do Azure, 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 usando 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.
A tabela a seguir resume algumas das preocupações de pilar.
| Pilar | Impacto |
|---|---|
| Reliability |
-
Quando implantado em uma única zona de disponibilidade:baixa confiabilidade. Uma implantação zonal não fornece nenhuma resiliência a uma interrupção em um datacenter ou zona de disponibilidade. Você deve implantar recursos redundantes em várias zonas de disponibilidade para obter alta resiliência. - Quando implantado em várias zonas de disponibilidade:alta confiabilidade. Os serviços podem ser resilientes a um datacenter ou interrupção de zona de disponibilidade. |
| Otimização de custos |
-
Quando implantado em uma única zona de disponibilidade:baixo custo. Uma implantação de zona única requer apenas uma única instância de cada recurso. - Quando implantado em várias zonas de disponibilidade:Alto custo. Você implanta várias instâncias dos recursos, cada uma delas cobradas separadamente. |
| Eficiência de desempenho | Alto desempenho. A latência pode ser muito baixa quando os componentes que atendem a uma solicitação estão localizados na mesma zona de disponibilidade. |
| Excelência operacional | Baixa eficiência operacional. Você precisa configurar e gerenciar várias instâncias do serviço. Você precisa replicar dados entre zonas de disponibilidade. Durante uma interrupção da zona de disponibilidade, o failover é de sua responsabilidade. |
A tabela a seguir resume algumas das preocupações de uma perspectiva arquitetônica.
| Preocupação com arquitetura | Impacto |
|---|---|
| Conformidade com a residência de dados | Alto. Quando você implanta uma solução que usa essa abordagem, os dados são armazenados na região do Azure selecionada. |
| Disponibilidade regional | Regiões com zonas de disponibilidade. Essa abordagem está disponível em qualquer região que dê suporte a zonas de disponibilidade. |
Essa abordagem normalmente é usada para cargas de trabalho baseadas em VMs (máquinas virtuais). Para obter uma lista completa de serviços que dão suporte a implantações zonais, consulte o serviço de zona de disponibilidade e o 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 a disponibilidade da SKU da VM.
Dica
Ao implantar um recurso em uma zona de disponibilidade específica, você seleciona o número da zona. A sequência de números de zona é diferente para cada assinatura do Azure. Se você implantar recursos em várias assinaturas do Azure, verifique os números de zona que deve usar em cada assinatura. Para obter mais informações, confira Zonas de disponibilidade físicas e lógicas.
Abordagem de implantação 3: implantações com redundância de zona
Quando você usa essa abordagem, sua camada de aplicativo é distribuída entre várias zonas de disponibilidade. Quando as solicitações chegam, um balanceador de carga integrado ao serviço dispersa as solicitações entre as 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.
Sua camada de armazenamento também é distribuída entre várias zonas de disponibilidade. Cópias dos dados do aplicativo são distribuídas entre várias zonas de disponibilidade por meio de 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 é considerada concluída somente quando todas essas alterações são concluídas. Esse processo garante que cada zona de disponibilidade sempre tenha uma cópia de data 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 para problemas como interrupções de 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 possam estar em diferentes partes 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 entre zonas de disponibilidade pode afetar o desempenho do aplicativo.
A tabela a seguir resume algumas das preocupações de pilar.
| Pilar | Impacto |
|---|---|
| Reliability | Alta confiabilidade. Os serviços são resilientes a uma interrupção de um datacenter ou zona de disponibilidade. Os dados são replicados de forma síncrona entre zonas de disponibilidade sem atraso. |
| Otimização de custos | Custo moderado. Dependendo dos serviços que você usa, você pode incorrer em alguns custos para camadas de serviço mais altas para habilitar a redundância de zona. |
| Eficiência de desempenho |
-
Para a maioria das cargas de trabalho:Desempenho aceitável. Essa abordagem provavelmente fornecerá um desempenho satisfatório. - Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Alguns componentes podem ser sensíveis à latência devido ao tráfego entre zonas ou ao tempo de replicação de dados. |
| Excelência operacional | Alta eficiência operacional. Normalmente, você precisa gerenciar apenas uma única instância lógica de cada recurso. Para a maioria dos serviços, durante uma interrupção de zona de disponibilidade, o failover é de responsabilidade da Microsoft e ocorre automaticamente. |
A tabela a seguir resume algumas das preocupações de uma perspectiva arquitetônica.
| Preocupação com arquitetura | Impacto |
|---|---|
| Conformidade com a residência de dados | Alto. Quando você implanta uma solução que usa essa abordagem, os dados são armazenados na região do Azure selecionada. |
| Disponibilidade regional | Regiões com zonas de disponibilidade. Essa abordagem está disponível em qualquer região que dê suporte a zonas de disponibilidade. |
Essa abordagem é possível com muitos serviços do Azure, incluindo Conjuntos de Dimensionamento de Máquinas Virtuais do Azure, Serviço de Aplicativo do Azure, Azure Functions, AKS (Serviço de Kubernetes do Azure), Armazenamento do Azure, SQL do Azure, Barramento de Serviço do Azure e muitos outros serviços. Para obter uma lista completa de serviços que dão suporte à redundância de zona, consulte o serviço de zona de disponibilidade e o 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 com redundância de zona e adiciona uma camada de proteção para atenuar o evento extremamente improvável de uma interrupção completa da região.
Ao implementar essa abordagem, você precisa considerar cuidadosamente o RTO e o RPO.
Tempo de recuperação: Se ocorrer uma interrupção regional, talvez seja necessário recompilar sua solução em outra região do Azure, o que afeta o 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 grande desastre. Verifique se suas ferramentas e processos de implantação são 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 repita as etapas necessárias para restaurar sua solução para um estado de trabalho.
Ponto de recuperação: Sua frequência de backup determina a quantidade de perda de dados que você pode experimentar, conhecida como seu ponto de recuperação. Normalmente, você pode controlar a frequência de backups para atender ao RPO.
Dica
Essa abordagem geralmente fornece um bom equilíbrio para todas as preocupações arquitetônicas. Se você não tiver certeza de qual abordagem usar, comece com esse tipo de implantação.
A tabela a seguir resume algumas das preocupações de pilar.
| Pilar | Impacto |
|---|---|
| Reliability | Confiabilidade muito alta. Os serviços são resilientes a uma interrupção de um datacenter ou zona de disponibilidade. Para a maioria dos serviços, os dados são replicados entre zonas automaticamente sem atraso. Os dados são armazenados em backup de forma assíncrona em uma região geograficamente separada. Esse backup reduz o efeito de uma interrupção de região completa minimizando a perda de dados. Após uma interrupção de região completa, você pode restaurar manualmente as operações em outra região. No entanto, os processos de recuperação podem ser complexos e pode levar tempo para serem restaurados manualmente na outra região. |
| Otimização de custos | Custo moderado. Normalmente, adicionar um backup a outra região custa apenas um pouco mais do que implementar a redundância de zona. |
| Eficiência de desempenho |
-
Para a maioria das cargas de trabalho:Desempenho aceitável. Essa abordagem provavelmente fornecerá um desempenho satisfatório. - Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Alguns componentes podem ser sensíveis à latência devido ao tráfego entre zonas ou ao tempo de replicação de dados. |
| Excelência operacional |
-
Durante uma interrupção de zona de disponibilidade:alta eficiência operacional. O failover é responsabilidade da Microsoft e ocorre automaticamente. - Durante uma interrupção regional:baixa eficiência operacional. O failover é de sua responsabilidade e pode exigir operações manuais e reimplantações. |
A tabela a seguir resume algumas das preocupações de uma perspectiva arquitetônica.
| Preocupação com arquitetura | Impacto |
|---|---|
| Conformidade com a residência de dados | Depende da seleção de região. Os dados são armazenados principalmente na região do Azure especificada, mas você precisa selecionar outra região para armazenar seus backups. Selecione uma região compatível com seus requisitos de residência de dados. |
| Disponibilidade regional | Regiões com zonas de disponibilidade. Essa abordagem está disponível em qualquer região que dê suporte a zonas de disponibilidade. |
Abordagem de implantação 4: implantações de 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 solução ou para dar suporte a usuários geograficamente distribuídos. Ao implantar em várias regiões, você também reduz o risco de encontrar uma restrição temporária de capacidade de recurso 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 ativas-passivas). Esta seção se concentra no segundo cenário, no qual uma região está ativa e outra é passiva. Para obter mais informações sobre soluções de várias regiões ativas e ativas, consulte o padrão de Selos de Implantação e o padrão geode.
Replicação de dados
A comunicação entre regiões é muito mais lenta do que a comunicação entre regiões. Em geral, uma distância geográfica maior entre duas regiões incorre em mais latência de rede devido à distância física mais longa que os dados precisam percorrer. Para obter mais informações sobre a latência de rede esperada quando você se conectar entre duas regiões, consulte as estatísticas de latência de ida e volta da rede do Azure.
A latência de rede entre regiões pode afetar significativamente o design da solução porque 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 de dados assíncrona
Quando você implementa a replicação assíncrona entre regiões, seu aplicativo não aguarda que todas as regiões reconheçam uma alteração. Depois que a alteração é confirmada na região primária, a transação é considerada concluída. A alteração é replicada para as regiões secundárias posteriormente. Essa abordagem garante que a latência de 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 depois que uma gravação é concluída na região primária, mas antes que a alteração seja replicada para outra região.
A tabela a seguir resume algumas das preocupações de pilar.
| Pilar | Impacto |
|---|---|
| Reliability | Alta confiabilidade. A solução é resiliente a uma interrupção de um datacenter, uma zona de disponibilidade ou uma região inteira. Os dados são replicados, mas podem não ser síncronos, portanto, alguma perda de dados é possível em um cenário de failover. |
| Otimização de custos | Alto custo. Você precisa implantar recursos separados em cada região e cada recurso incorre em custos de implantação e manutenção. A replicação de dados entre regiões também pode incorrer em custos significativos. |
| Eficiência de desempenho | Alto desempenho. As solicitações de aplicativo não exigem tráfego entre regiões, portanto, o tráfego normalmente é de baixa latência. |
| Excelência operacional | Baixa eficiência operacional. Você precisa implantar e gerenciar recursos em várias regiões. Você também é responsável pelo failover entre regiões durante uma interrupção regional. |
A tabela a seguir resume algumas das preocupações de uma perspectiva arquitetônica.
| Preocupação com arquitetura | Impacto |
|---|---|
| Conformidade com a residência de dados | Depende da seleção de região. Essa abordagem exige que você selecione várias regiões para sua carga de trabalho ser executada. Escolha regiões compatíveis com seus requisitos de residência de dados. |
| Disponibilidade regional | Muitas regiões do Azure são emparelhadas. Alguns serviços do Azure usam regiões emparelhadas para replicar dados automaticamente. Se você executar sua carga de trabalho em uma região que não tem um par, talvez seja necessário usar uma abordagem diferente para replicar seus dados. |
Replicação de dados síncrona
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 aguardando 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.
A tabela a seguir resume algumas das preocupações de pilar.
| Pilar | Impacto |
|---|---|
| Reliability | Confiabilidade muito alta. A solução é resiliente a uma interrupção de um datacenter, uma zona de disponibilidade ou uma região inteira. Os dados são sempre sincronizados entre regiões. Portanto, mesmo que uma região inteira falhe, seus dados permanecerão completos e disponíveis em outra região. |
| Otimização de custos | Alto custo. Você precisa implantar recursos separados em cada região e cada recurso incorre em custos de implantação e manutenção. A replicação de dados entre regiões também pode incorrer em custos significativos. |
| Eficiência de desempenho | Baixo desempenho. As solicitações de aplicativo exigem tráfego entre regiões. Dependendo da distância entre as regiões, a replicação síncrona pode adicionar latência significativa às solicitações. |
| Excelência operacional | Baixa eficiência operacional. Você precisa implantar e gerenciar recursos em várias regiões. Você também é responsável pelo failover entre regiões durante uma interrupção regional. |
A tabela a seguir resume algumas das preocupações de uma perspectiva arquitetônica.
| Preocupação com arquitetura | Impacto |
|---|---|
| Conformidade com a residência de dados | Depende da seleção de região. Essa abordagem exige que você selecione várias regiões para sua carga de trabalho ser executada. Selecione regiões compatíveis com seus requisitos de residência de dados. |
| Disponibilidade regional | Muitas regiões do Azure são emparelhadas. Alguns serviços do Azure usam regiões emparelhadas para replicar dados automaticamente. Se você executar sua carga de trabalho em uma região que não tem um par, talvez seja necessário usar uma abordagem diferente para replicar seus dados. |
Arquiteturas de região
Ao criar uma solução de várias regiões, considere se as regiões do Azure que você planeja usar são emparelhadas.
Você pode criar uma solução de várias regiões mesmo quando as regiões não são emparelhadas. No entanto, as abordagens que você usa para implementar uma arquitetura de várias regiões podem ser diferentes. Por exemplo, no Armazenamento, você pode usar GRS (armazenamento com redundância geográfica) com regiões emparelhadas. Se o GRS não estiver disponível, considere usar recursos como replicação de objeto de armazenamento ou projete seu aplicativo para gravar em várias regiões.
Combinar abordagens de várias zonas e várias regiões
Você deve combinar instruções de várias zonas e várias regiões se seus requisitos de negócios exigirem tal solução. Por exemplo, você pode implantar componentes com redundância de zona em cada região e também configurar a replicação entre as regiões. Para algumas soluções, essa abordagem fornece um alto grau de confiabilidade. No entanto, configurar esse tipo de abordagem pode ser complicado e essa abordagem pode ser cara.
Importante
Cargas de trabalho críticas devem usar várias zonas de disponibilidade e várias regiões.
Como os serviços do Azure dão suporte à implantação se aproxima
É 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 a configuração da zona de disponibilidade ao implantar o recurso pela primeira vez, enquanto outros serviços dão suporte à alteração da abordagem de implantação mais tarde. Da mesma forma, alguns recursos de serviço podem não estar disponíveis a cada abordagem 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 caso 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
Contoso, Ltd., é uma grande empresa de fabricação. A empresa está implementando um aplicativo lob (linha de negócios) para gerenciar alguns componentes de seus processos financeiros.
Requisitos de negócios: As informações gerenciadas pelo sistema são difíceis de substituir, portanto, os dados precisam ser mantidos de forma confiável. Os arquitetos precisam que o sistema incorra o mínimo possível de tempo de inatividade e perda de dados. Os funcionários da Contoso usam o sistema durante todo o dia útil, portanto, o alto desempenho é importante para evitar manter os membros da equipe aguardando. O custo também é uma preocupação porque a equipe financeira tem que pagar pela solução.
Abordagem sugerida:implantação com redundância de zona com backup entre regiões fornece várias camadas de resiliência com alto desempenho.
Aplicativo interno
O 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ócios: Para essa carga de trabalho, a eficiência de custo é uma preocupação principal. A Fourth Coffee avaliou o impacto nos negócios do tempo de inatividade e decidiu que o aplicativo não precisa priorizar a resiliência ou o desempenho. A empresa aceita o risco de que uma interrupção em uma zona de disponibilidade ou região do Azure possa tornar o aplicativo temporariamente indisponível.
Abordagens sugeridas:
A implantação com redundância local 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 fornece melhor resiliência, mas a um custo ligeiramente maior.
Migração de aplicativo herdado
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ócios: O desempenho é uma prioridade para este aplicativo. A resiliência também é importante e o aplicativo deve continuar funcionando 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. Eles devem verificar se o desempenho atende aos seus requisitos.
Se o desempenho da solução com redundância de zona não for aceitável, eles deverão considerar uma implantação zonal (fixada), com implantações passivas em várias zonas de disponibilidade (DR na região).
Aplicativo de serviços de saúde
A Lamna Healthcare Company está implementando um novo sistema eletrônico de registro de integridade no Azure.
Requisitos de negócios: Devido à natureza dos dados que essa solução armazena, a residência de dados é extremamente importante. A Lamna opera sob uma estrutura regulatória estrita que determina que os dados devem permanecer em um local específico.
Abordagens sugeridas:
Implantação de várias regiões de várias zonas, se houver várias regiões que se ajustem aos requisitos de residência de dados da 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 fornece uma solução de região única.
Sistema bancário
O Woodgrove Bank executa suas principais operações bancárias de uma grande solução implantada no Azure.
Requisitos de negócios: Esse sistema é fundamental. Qualquer interrupção pode causar um grande impacto financeiro para os clientes. Como resultado, o Banco Woodgrove tem tolerância de risco muito baixa. O sistema precisa do mais alto nível de confiabilidade possível e a arquitetura precisa reduzir o risco de falhas que possam ser atenuadas.
Abordagem sugerida: Para um sistema crítico de missão, eles devem usar uma implantação de várias regiões de várias zonas e garantir que as regiões se ajustem aos requisitos de residência de dados da empresa.
Software como serviço
Proseware, Inc., cria software que empresas em todo o mundo usam. A base de usuários da empresa é amplamente distribuída geograficamente.
Requisitos de negócios: O Proseware precisa permitir que cada um de seus clientes escolha uma região de implantação próxima ao cliente. Habilitar essa opção é importante para latência e para os requisitos de residência de dados dos clientes.
Abordagens sugeridas:
A implantação de várias regiões de várias zonas normalmente é uma boa opção para um provedor saaS (software como serviço), especialmente quando é usada dentro do padrão Selos de Implantação.
Implantação com redundância de zona de região única com uma solução de aceleração de tráfego global, como o Azure Front Door.
Próximas etapas
As arquiteturas de referência e os 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 na linha de base
- Aplicativo Web de várias regiões altamente disponível
- Aplicativo de N camadas de várias regiões
- Aplicativo Web de várias camadas criado para alta disponibilidade e DR
Use os seguintes serviços do Azure para implementar soluções em várias zonas de disponibilidade: