Regiões da zona de destino
Este artigo explica como as zonas de destino usam as regiões do Azure. A arquitetura da zona de destino do Azure é independente de região, mas você precisa especificar regiões do Azure para implantar sua arquitetura de zona de destino do Azure. As diretrizes a seguir descrevem como adicionar uma região a uma zona de destino existente e também fornecem considerações para quando você migra sua propriedade do Azure para uma região diferente.
Em algumas situações, você deve implantar aplicativos em várias regiões do Azure para dar suporte aos seus requisitos de negócios de alta disponibilidade e recuperação de desastre. Talvez você não tenha uma necessidade imediata de aplicativos de várias regiões, mas deve projetar sua plataforma de zona de destino do Azure para dar suporte a várias regiões, especialmente para serviços de conectividade, identidade e gerenciamento. Certifique-se de que você pode habilitar e dar suporte rapidamente a zonas de destino de aplicativos de várias regiões.
Para obter mais informações, consulte Selecionar regiões do Azure.
Zonas de destino e regiões do Azure
As zonas de destino do Azure consistem em um conjunto de recursos e configuração. Alguns desses itens, como grupos de gerenciamento, políticas e atribuições de função, são armazenados em um nível de locatário ou grupo de gerenciamento na arquitetura da zona de destino do Azure. Esses recursos não são implantados em uma região específica e, em vez disso, são implantados globalmente. No entanto, você ainda precisa especificar uma região de implantação porque o Azure rastreia alguns dos metadados de recursos em um repositório de metadados regional.
Outros recursos são implantados regionalmente. Dependendo da configuração da sua própria zona de destino, você pode ter alguns ou todos os seguintes recursos implantados regionalmente:
- Um workspace de Logs do Azure Monitor, incluindo soluções selecionadas
- Uma conta da Automação do Azure
- Grupos de recursos, para os outros recursos
Se você implantar uma topologia de rede, também precisará selecionar uma região do Azure para implantar os recursos de rede. Essa região pode ser diferente da região que você usa para os recursos listados na lista anterior. Dependendo da topologia selecionada, os recursos de rede implantados podem incluir:
- WAN Virtual do Azure, incluindo um hub de WAN Virtual
- Redes virtuais do Azure
- gateway de VPN
- Gateway do Azure ExpressRoute
- Firewall do Azure
- Planos de Proteção contra DDoS do Azure
- Zonas DNS privadas do Azure, incluindo zonas para Link Privado do Azure
- Grupos de recursos, para conter os recursos anteriores
Observação
Para minimizar o efeito de interrupções regionais, recomendamos que você coloque os recursos na mesma região que o grupo de recursos. Para obter mais informações, consulte Alinhamento de localização do grupo de recursos.
Adicionar uma nova região a uma zona de destino existente
Você deve considerar uma estratégia de várias regiões, desde o início de sua jornada na nuvem ou expandindo para mais regiões do Azure depois de concluir a implantação inicial da arquitetura da zona de destino do Azure. Por exemplo, se você usar o Azure Site Recovery para habilitar a recuperação de desastre para suas máquinas virtuais, talvez queira replicá-las para uma região diferente do Azure. Para adicionar regiões do Azure à arquitetura da zona de destino do Azure, considere as seguintes recomendações:
| Área | Recomendação |
|---|---|
| Grupos de gerenciamento | Nenhuma ação é necessária. Os grupos de gerenciamento não estão vinculados a uma região. Você não deve criar uma estrutura de grupo de gerenciamento com base em regiões. |
| Assinaturas | As assinaturas não estão vinculadas a uma região. |
| Azure Policy | Faça alterações no Azure Policy se você atribuiu políticas para negar a implantação de recursos em todas as regiões especificando uma lista de regiões "permitidas" do Azure. Atualize essas atribuições para permitir implantações de recursos na nova região que você deseja habilitar. |
| RBAC (controle de acesso baseado em função) | Nenhuma ação é necessária. O RBAC do Azure não está vinculado a uma região. |
| Monitoramento e registro em log | Decida se deseja usar um único workspace de Logs do Azure Monitor para todas as regiões ou criar vários workspaces para abranger várias regiões geográficas. Cada abordagem tem vantagens e desvantagens, incluindo possíveis cobranças de rede entre regiões. Para obter mais informações, consulte Projetar uma arquitetura de workspace do Log Analytics. |
| Rede | Se você implantar uma topologia de rede, WAN Virtual ou hub e spoke tradicional, expanda a rede para a nova região do Azure. Crie outro hub de rede implantando os recursos de rede necessários na assinatura de conectividade existente na nova região do Azure. O Gerenciador de Rede Virtual do Azure pode facilitar a expansão e o gerenciamento de redes virtuais em escala em várias regiões. De uma perspectiva do DNS (Sistema de Nomes de Domínio), talvez você também queira implantar encaminhadores, se usá-los, na nova região do Azure. Use encaminhadores para redes virtuais spoke na nova região para resolução. As zonas DNS do Azure são recursos globais e não estão vinculadas a uma única região do Azure, portanto, não exigem nenhuma ação. |
| Identidade | Se você implantou o Active Directory Domain Services ou o Microsoft Entra Domain Services em sua assinatura de identidade ou spoke, expanda o serviço para a nova região do Azure. |
Observação
Você também deve usar zonas de disponibilidade para alta disponibilidade em uma região. Verifique se as regiões do Azure dão suporte a zonas de disponibilidade e como os serviços que você usa dão suporte a zonas de disponibilidade.
O Microsoft Cloud for Sovereignty tem diretrizes para restringir serviços e regiões. Você pode usar essas diretrizes para impor a configuração do serviço para ajudar os clientes a atender às suas necessidades de residência de dados.
Abordagem de alto nível
Ao expandir uma zona de destino do Azure para uma nova região, considere seguir as etapas nestas seções. Antes de começar, você precisa decidir sobre uma nova região do Azure, ou várias regiões do Azure, para expandir.
Rede
Arquitetura tradicional hub-and-spoke
Dica
Veja uma arquitetura tradicional hub-and-spoke.
Decida se você precisa de uma nova assinatura de landing zone da plataforma. Recomendamos que a maioria dos clientes use suas assinaturas de conectividade existentes, mesmo quando usam várias regiões.
Na assinatura, crie um novo grupo de recursos na nova região de destino.
Crie uma nova rede virtual de hub na nova região de destino.
Se aplicável, implante o Firewall do Azure ou NVAs (soluções de virtualização de rede) em sua nova rede virtual de hub.
Se aplicável, implante gateways de rede virtual para conectividade VPN ou ExpressRoute e estabeleça conexões. Verifique se os circuitos do ExpressRoute e os locais seguem as recomendações de resiliência da Microsoft. Para obter mais informações, consulte Projetando para recuperação de desastre com o emparelhamento privado do ExpressRoute.
Estabeleça o emparelhamento de rede virtual entre a nova rede virtual do hub e as outras redes virtuais do hub.
Crie e configure qualquer roteamento necessário, como o Servidor de Rota do Azure ou rotas definidas pelo usuário.
Se necessário, implante encaminhadores DNS para a nova região de destino e vincule-se a qualquer zona DNS privada para habilitar a resolução de nomes.
- Alguns clientes podem configurar a resolução de nomes em seus controladores de domínio do Windows Server Active Directory na assinatura da zona de destino da plataforma de identidade .
Para hospedar suas cargas de trabalho, você pode usar o emparelhamento de rede virtual para conectar spokes da zona de destino do aplicativo à nova rede virtual do hub na nova região.
Dica
O Gerenciador de Rede Virtual pode facilitar a expansão e o gerenciamento de redes virtuais em escala em várias regiões.
Arquitetura da WAN Virtual
Dica
Veja uma arquitetura de WAN Virtual.
Na WAN Virtual existente, crie um novo hub virtual na nova região de destino.
Implante o Firewall do Azure ou outras NVAs (soluções de virtualização de rede) com suporte em seu novo hub virtual. Configure a intenção de roteamento e as políticas de roteamento da WAN Virtual para rotear o tráfego por meio do novo hub virtual seguro.
Se aplicável, implante gateways de rede virtual para conectividade VPN ou ExpressRoute no novo hub virtual e estabeleça conexões. Verifique se os circuitos do ExpressRoute e os locais seguem as recomendações de resiliência da Microsoft. Para obter mais informações, consulte Projetando para recuperação de desastre com o emparelhamento privado do ExpressRoute.
Crie e configure qualquer outro roteamento necessário, como rotas estáticas do hub virtual.
Se aplicável, implante encaminhadores DNS para a nova região de destino e vincule-se a qualquer zona DNS privada para habilitar a resolução.
Alguns clientes podem configurar a resolução de nomes em seus controladores de domínio do Active Directory na assinatura da zona de destino da plataforma de identidade .
Em implantações de WAN Virtual, isso deve estar em uma rede virtual spoke conectada ao hub virtual por meio de uma conexão de rede virtual, seguindo o padrão de extensão do hub virtual.
Para hospedar suas cargas de trabalho, você pode usar o emparelhamento de rede virtual para conectar spokes da zona de destino do aplicativo à nova rede virtual do hub na nova região.
Identidade
Dica
Examine a área de design da zona de destino do Azure para gerenciamento de identidade e acesso.
Decida se você precisa de uma nova assinatura de zona de destino da plataforma. Recomendamos que a maioria dos clientes use sua assinatura de identidade existente, mesmo quando usam várias regiões.
Crie um novo grupo de recursos na nova região de destino.
Crie uma nova rede virtual na nova região de destino.
Estabeleça o emparelhamento de rede virtual de volta para a rede virtual do hub regional recém-criada na assinatura de conectividade .
Implante cargas de trabalho de identidade, como máquinas virtuais do controlador de domínio do Active Directory, na nova rede virtual.
Talvez seja necessário executar mais configurações das cargas de trabalho depois que elas forem provisionadas, como as seguintes etapas de configuração:
Promova as máquinas virtuais do controlador de domínio do Active Directory para o domínio existente do Active Directory.
Crie novos sites e sub-redes do Active Directory.
Defina as configurações do servidor DNS, como encaminhadores condicionais.
Mover sua propriedade do Azure para uma nova região
Ocasionalmente, talvez você precise mover toda a propriedade do Azure para uma região diferente. Por exemplo, suponha que você implantou sua zona de destino e cargas de trabalho em uma região do Azure em um país ou região vizinha e, em seguida, uma nova região do Azure é iniciada em seu país ou região de origem. Você pode optar por mover todas as suas cargas de trabalho para a nova região para melhorar a latência de comunicação ou para cumprir os requisitos de residência de dados.
Observação
Este artigo fornece informações sobre como migrar os componentes da zona de destino da sua propriedade. Para obter mais informações, consulte Realocar cargas de trabalho na nuvem.
Configuração global da zona de destino
A maior parte da configuração da zona de destino implantada globalmente normalmente não precisa ser modificada quando você move regiões. No entanto, verifique se há atribuições de política que restrinjam as implantações de região e atualize a política para permitir implantações na nova região.
Recursos regionais da zona de destino
Os recursos da zona de destino específicos da região geralmente exigem mais consideração porque você não pode mover alguns recursos do Azure entre regiões. Considere a seguinte abordagem:
Adicionar a região de destino como uma região adicional à sua landing zone: para obter mais informações, consulte Adicionar uma nova região a uma landing zone existente.
Implantar componentes centralizados na região de destino: por exemplo, implante um novo workspace de Logs do Azure Monitor na região de destino para que as cargas de trabalho possam começar a usar o novo componente depois que você migrar a carga de trabalho.
Migrar suas cargas de trabalho da região de origem para a região de destino: durante o processo de migração da carga de trabalho, reconfigure os recursos para usar os componentes de rede, os componentes de identidade, o workspace de Logs do Azure Monitor e outros recursos regionais da região de destino.
Descomissione os recursos na região de origem depois de concluir a migração.
Considere as seguintes dicas ao migrar recursos da zona de destino entre regiões:
Usar infraestrutura como código: use Bicep, modelos do ARM (modelos do Azure Resource Manager), Terraform, scripts ou uma abordagem semelhante para exportar e reimportar configurações complexas, como regras para o Firewall do Azure.
Automação: use scripts para migrar recursos de automação entre regiões.
ExpressRoute: considere se você pode usar o SKU Local do ExpressRoute em sua região de destino. Se seus ambientes locais estiverem na mesma área metropolitana que sua região do Azure, o ExpressRoute Local poderá fornecer uma opção de custo mais baixo em comparação com outros SKUs do ExpressRoute.