Em uma topologia hub-spoke tradicional com a abordagem traga sua própria rede, você pode manipular completamente a rede virtual hub. Você pode implantar serviços comuns no hub e disponibilizá-los para spokes de carga de trabalho. Esses serviços compartilhados geralmente incluem itens como recursos DNS, NVAs personalizados e Azure Bastion. No entanto, ao usar a WAN Virtual do Azure, você tem acesso restrito e limitações sobre o que pode instalar nos hubs virtuais.
Por exemplo, para implementar a integração de DNS e Link Privado em uma arquitetura de rede hub-spoke tradicional, você criaria e vincularia zonas DNS privadas à rede hub. Seu plano de acesso remoto de máquina virtual pode incluir o Azure Bastion como um serviço compartilhado no hub regional. Você também pode implantar recursos de computação personalizados, como VMs do Active Directory, no hub. Nenhuma dessas abordagens é possível com a WAN Virtual.
Este artigo descreve o padrão de extensão de hub virtual que fornece orientação sobre como expor com segurança serviços compartilhados a spokes que você não consegue implantar diretamente em um hub virtual.
Arquitetura
Uma extensão de hub virtual é uma rede virtual spoke dedicada conectada ao hub virtual que expõe um único serviço compartilhado a spokes de carga de trabalho. Você pode usar uma extensão de hub virtual para fornecer, a muitos spokes de carga de trabalho, conectividade de rede para seu recurso compartilhado. Os recursos de DNS são um exemplo desse uso. Também é possível usar uma extensão para conter um recurso centralizado que requer conectividade com muitos destinos nos spokes. Uma implantação centralizada do Azure Bastion é um exemplo desse uso.
Figura 1: Padrão de extensão de hub
Baixe um Arquivo Visio dessa arquitetura.
- Extensão de hub virtual para o Azure Bastion. Essa extensão permite que você se conecte a máquinas virtuais em redes spoke.
- Extensão de hub virtual para DNS. Essa extensão permite que você exponha entradas de zona DNS privada a cargas de trabalho em redes spoke.
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.
Confiabilidade
Uma extensão de hub virtual, muitas vezes, é considerada comercialmente crítica, pois está servindo a uma função principal dentro da rede. As extensões devem se alinhar aos requisitos de negócios, ter estratégias de mitigação de falhas e dimensionar de acordo com as necessidades dos spokes.
Seus procedimentos operacionais padrão devem incluir testes de resiliência e monitoramento de confiabilidade de todas as extensões. Esses procedimentos devem validar os requisitos de acesso e taxa de transferência. Cada extensão deve ter um modelo de saúde significativo.
Seja claro quanto aos seus SLOs (objetivos de nível de serviço) para essa extensão e meça com precisão a confiabilidade em relação a ela. Entenda o SLA (contrato de nível de serviço) do Azure e os requisitos de suporte em cada componente individual na extensão. Esse conhecimento ajuda a definir o limite máximo do seu SLO de destino e a entender as configurações permitidas.
Segurança
Restrições de rede. Embora as extensões sejam frequentemente usadas por muitos spokes ou precisem de acesso a muitos spokes, elas podem não precisar de acesso bidirecional a todos os spokes. Use os controles de segurança de rede disponíveis, como usar Grupos de Segurança de Rede e emitir tráfego pelo hub virtual seguro, sempre que possível.
Controle de acesso do plano de controle e dados. Siga as práticas recomendadas para todos os recursos implantados em extensões, fornecendo acesso menos privilegiado ao plano de controle dos recursos e a quaisquer planos de dados.
Otimização de custos
Como em qualquer carga de trabalho, certifique-se de que os tamanhos de SKU apropriados sejam selecionados para os recursos de extensão, a fim de ajudar a controlar os custos. O horário comercial e outros fatores podem gerar padrões de uso previsíveis para algumas extensões. Compreenda os padrões e forneça a elasticidade e a escalabilidade que podem acomodá-los.
Como um serviço compartilhado, os recursos de carga de trabalho geralmente têm um ciclo de trabalho relativamente longo em sua arquitetura corporativa. Considere o uso da economia de custos por meio de ofertas de pré-compra, como Reservas do Azure, preços de capacidade reservada e planos de economia do Azure.
Excelência operacional
Crie extensões de hub virtual para aderir ao SRP (princípio de responsabilidade única). Cada extensão deve ser para uma única oferta, portanto, não combine serviços não relacionados em um único spoke. É possível organizar seus recursos de modo que cada extensão resida em um grupo de recursos dedicado, a fim de facilitar o gerenciamento de políticas e funções do Azure.
Você deve provisionar essas extensões usando a Infraestrutura como Código e ter um processo de compilação e lançamento que dê suporte às necessidades e ao ciclo de vida de cada extensão. Como as extensões geralmente são comercialmente críticas por natureza, é importante ter métodos de teste rigorosos e práticas de implantação seguras para cada extensão.
Ter um controle de mudanças claro e um plano de comunicação empresarial em vigor é fundamental. Talvez seja necessário se comunicar com os stakeholders (proprietários da carga de trabalho) sobre análises de DR (recuperação de desastres) que você está executando ou qualquer tempo de inatividade planejado ou inesperado.
Certifique-se de ter um sistema de integridade operacional sólido em vigor para esses recursos. Habilite as configurações apropriadas do Diagnóstico do Azure em todos os recursos de extensão e capture toda a telemetria e os logs necessários para entender a integridade da carga de trabalho. Considere o armazenamento de longo prazo de logs de operação e métricas para dar suporte a interações de atendimento ao cliente durante o comportamento inesperado da extensão de serviço compartilhado.
Eficiência de desempenho
Uma extensão é um serviço centralizado. Para projetar suas unidades de escala para lidar com alterações de carga, você precisa entender:
- As demandas que sua organização faz sobre a extensão.
- Os requisitos para o planejamento de capacidade.
- Como os spokes aumentarão ao longo do tempo.
Para projetar suas unidades de escala, teste e documente como cada componente em sua extensão é dimensionado individualmente, com base nas métricas e nos limites de escala de serviço que estão em vigor. Algumas extensões podem exigir balanceamento de carga em várias instâncias para atingir a taxa de transferência necessária.
Exemplo de implementação
Extensão DNS de Link Privado: Estabelecer uma extensão de hub virtual para DNS descreve uma extensão de Hub Virtual projetada para dar suporte à pesquisa de DNS de região única para cenários de Link Privado.
Próximas etapas
Recursos relacionados
- O que é um ponto de extremidade privado?
- Configuração de DNS do ponto de extremidade privado do Azure
- Link Privado e integração de DNS em escala
- Link Privado do Azure em uma rede hub-spoke
- DNS para recursos locais e do Azure
- Conectividade de zona de destino de dados em uma única região
- Usar o Link Privado do Azure para conectar redes ao Azure Monitor
- Resolvedor Privado de DNS do Azure
- Acesso de segurança aprimorado a aplicativos Web multilocatário de uma rede local
- Aplicativo Web com redundância de zona altamente disponível na linha de base
- Tutorial: Criar uma infraestrutura de DNS de ponto de extremidade privado com o Resolvedor Privado de DNS do Azure para uma carga de trabalho local