Cenário: Grupos de gerenciamento de transição para a arquitetura conceitual da zona de aterrissagem do Azure
Este artigo descreve considerações e instruções para migrar e fazer a transição de seu ambiente existente para a arquitetura conceitual das zonas de aterrissagem do Azure. Este cenário abrange um ou vários grupos de gerenciamento.
Nesse cenário, presume-se que o cliente já usa o Azure. Eles têm uma hierarquia de grupo de gerenciamento com várias assinaturas que hospedam alguns aplicativos ou serviços dentro da plataforma. Mas sua implementação atual limita sua escalabilidade e crescimento relacionados à sua estratégia de cloud first .
Como parte dessa expansão, eles planejam migrar de seus datacenters locais para o Azure. Durante a migração, eles lideram com a modernização e transformação de seus aplicativos ou serviços para usar tecnologias nativas da nuvem sempre que possível. Por exemplo, eles podem usar o Banco de Dados SQL do Azure e o Serviço Kubernetes do Azure (AKS). Eles sabem que é preciso tempo e esforço consideráveis, por isso planejam levantar e mudar para começar. Inicialmente, esse plano requer conectividade híbrida por meio de serviços como o Gateway de VPN do Azure ou a Rota Expressa do Azure.
O cliente deseja mover seu ambiente existente para a arquitetura conceitual das zonas de aterrissagem do Azure. Essa arquitetura suporta sua estratégia de nuvem em primeiro lugar e tem uma plataforma robusta que é dimensionada à medida que o cliente aposenta seus datacenters locais.
Estado atual
Nesse cenário, o estado atual do ambiente do Azure do cliente consiste em:
- Um ou mais grupos de gestão.
- Uma hierarquia de grupo de gestão baseada na estrutura organizacional ou na geografia.
- Uma assinatura do Azure para cada ambiente de aplicativo, como desenvolvimento, teste ou produção (dev/test/prod).
- Distribuição não uniforme de recursos. Os recursos de plataforma e carga de trabalho para um único ambiente são implantados nas mesmas assinaturas do Azure.
- Atribuições de política com efeitos de auditoria e efeitos de negação atribuídos no grupo de gerenciamento e no nível de assinatura.
- Atribuições de função de controle de acesso com base em função para cada assinatura e grupo de recursos.
- Uma rede virtual de hub, como o Gateway de VPN do Azure ou a Rota Expressa do Azure, para conectividade híbrida.
- Uma rede virtual para cada ambiente de aplicativo.
- Aplicativos que são implantados na respetiva assinatura com base em sua classificação de ambiente, como desenvolvimento, teste ou produção.
- Uma equipe central de TI que controla e opera o ambiente.
O diagrama a seguir mostra o estado atual desse cenário.
Transição para a arquitetura conceitual da zona de aterrissagem do Azure
Antes de implementar essa abordagem, revise a arquitetura conceitual da zona de aterrissagem do Azure, os princípios de design da zona de aterrissagem do Azure e as áreas de design da zona de aterrissagem do Azure.
Para fazer a transição do estado atual desse cenário para uma arquitetura conceitual de zona de aterrissagem do Azure, use a seguinte abordagem:
Implante o acelerador de zona de aterrissagem do Azure no mesmo locatário do Microsoft Entra ID em paralelo com o ambiente atual. Esse método fornece uma transição suave e em fases para a nova arquitetura de zona de aterrissagem com interrupção mínima para cargas de trabalho ativas.
Essa implantação cria uma nova estrutura de grupo de gerenciamento. Essa estrutura está alinhada com os princípios e recomendações de design das zonas de aterrissagem do Azure. Ele também garante que essas alterações não afetem o ambiente existente.
Para obter mais informações, consulte Como lidar com uma zona de aterrissagem de carga de trabalho dev/test/prod.
(Opcional) Trabalhe com equipes de aplicativos ou serviços para migrar as cargas de trabalho implantadas nas assinaturas originais para novas assinaturas do Azure. Para obter mais informações, consulte Transição de um ambiente existente do Azure para a arquitetura conceitual da zona de aterrissagem do Azure. Você pode colocar cargas de trabalho na hierarquia do grupo de gerenciamento de arquitetura conceitual da zona de aterrissagem do Azure recém-implantada sob o grupo de gerenciamento correto, como corporativo ou online no diagrama a seguir.
Para obter detalhes sobre o efeito nos recursos durante a migração, consulte Políticas.
Eventualmente, você pode cancelar a assinatura existente do Azure e colocá-la no grupo de gerenciamento desativado.
Nota
Você não precisa necessariamente migrar os aplicativos ou serviços existentes para novas zonas de aterrissagem ou assinaturas do Azure.
Crie novas assinaturas do Azure para fornecer zonas de aterrissagem que dão suporte a projetos de migração locais. Coloque-os sob o grupo de gerenciamento adequado, como corporativo ou on-line no diagrama a seguir.
Para obter mais informações, consulte Preparando sua zona de destino para migração.
O diagrama a seguir mostra o estado desse cenário durante a migração.
Resumo
Nesse cenário, o cliente realizou seus planos de expansão e dimensionamento no Azure implantando a arquitetura conceitual da zona de aterrissagem do Azure paralelamente ao seu ambiente existente.