Olhando abaixo:
Aqui vemos uma única conta corporativa AZURE X. Consulte "azsql1.database.windows.net". Você pode acessar isso no local.
E se, para fins de argumentação, eu tivesse um segundo ambiente AZURE. configurado exatamente da mesma forma - AZURE Corporate Account Y, com "azsql1.database.windows.net".
É teórico, mas eu gostaria de saber como o local resolve isso se alguém tentar usar "azsql1.database.windows.net" para um relatório de conexão, digamos, Tableau, Spotfire?
Presumo que, de alguma forma, você precise informar qual encaminhador de DNS usar em qual conta corporativa do AZURE.
Então, me perdoe, mas eu entendo coisas básicas de resolução de DNS com internet bla bla bla, mas não sou um especialista em redes.
Responder1
Para outros leitores com a mesma pergunta: Veja tambémEndereço a ser usado para acessar o endereço IP privado do recurso AZURE no localpara obter algumas informações básicas.
Antes de começar a responder uma pequena correção à sua pergunta, como você escreveu "... mesmo nome DNS". Penso que isto é um mal-entendido, uma vez que oBanco de dados do Azure Cosmosé um serviço totalmente gerenciado, significaPaaSe como tal tem nomes exclusivos. Por outras palavras, é impossível que dois serviços DB do Azure Cosmos tenham o mesmo nome DNS. Ainda assim, não quero corrigir isso na pergunta, mas prefiro a referência como parte da resposta, pois este é realmente um mal-entendido comum. Tudo se resume à forma como a resolução de nomes de uma solução híbrida é arquitetada.
Resolver tal cenário é fácil, usando nomes DNS exclusivos (o que não é um problema, pois o CosmosDB é SaaS e, como tal, tem nomes exclusivos) e garantindo que todos os recursos possam ser resolvidos.
Breve resposta
Para cada uma das suas assinaturas na conta corporativa conectada localmente via ExpressRoute ou VPN, configure umDNS privado do Azuree um encaminhador DNS, que é implantado na mesma sub-rede. Um Hub conecta tudo, inclusive no local.
Resposta longa
Exemplo hipotético (definição de missão)
Como funciona é melhor explicar usando um exemplo.
Dada a hipotética empresa "NKOTBINC" possui 3 departamentos:
- Finança
- ISTO
- Marketing
Cada departamento opera 2 assinaturas do Azure, uma para desenvolvimento e outra para carga de trabalho de produção. Portanto, temos que lidar com pelo menos seis assinaturas no total, para atender aos requisitos.
Os requisitos relacionados à rede são os seguintes:
- Cada assinatura precisa ter conectividade local.
- Cada assinatura pode ou não usar recursos implantados por meio de links privados.
- Devido a restrições legais, todos os recursos de todas as assinaturas estão atualmente implantados dentroregião"Leste dos EUA".
- Está prevista a ampliação do negócio, eventualmente utilizando outras regiões. Portanto, isso deve ser considerado no planejamento.
Abordagem de implementação
Usando este cenário, você pode acabar com pelo menos 7 assinaturas:
- dev-finance
- prd-financiamento
- dev-it
- prd-isso
- marketing de desenvolvimento
- prd-marketing
- Eixoque se conecta ao local via VPN ou ExpressRoute.
Todas as seis assinaturas precisam implantar um DNS privado do Azure e um encaminhador de DNS. Além disso, todos eles usam uma VNET que é emparelhada com a assinatura central do Hub. Então, eventualmente, você acabará com estes sete domínios DNS internos:
- dev.finance.eastus.azure.nkotb
- prd.finance.eastus.azure.nkotb
- dev.it.eastus.azure.nkotb
- prd.it.eastus.azure.nkotb
- dev.marketing.eastus.azure.nkotb
- prd.marketing.eastus.azure.nkotb
- hub.eastus.azure.nkotb
A assinatura do Hub possui um segundo conjunto de servidores DNS e encaminhadores configurados. Somente este conjunto de servidores DNS tem conhecimento dos outros sete encaminhadores DNS implantados nos demais domínios, e responsáveis pela resolução de nomes do Domínio “eastus.azure.nkotb”. Todos os servidores DNS locais estão configurados para encaminhar todas as solicitações DNS de *.eastus.azure.nkotb para esse conjunto de servidores DNS.
Exemplo 1: DNS interno entre uma assinatura e local
Dado que a equipe financeira decide implantar um banco de dados chamado “Alzheimer” dentro da assinatura de produção, usando um link privado. Portanto, o nome DNS interno (FQDN) desse banco de dados seria alzheimer.prd.finance.eastus.azure.nkotb. Graças à resolução interna de nomes, alinhada em todas as assinaturas e também no local, esse nome pode ser resolvido em qualquer lugar da rede corporativa.
Como funciona o Exemplo 1
- Um cliente aleatório localizado no local está solicitando ao servidor DNS local para resolver o problema
alzheimer.prd.finance.eastus.azure.nkotb. - O servidor DNS local não sabe a resposta, mas está configurado para encaminhar todas as solicitações para
*.eastus.azure.nkotbo encaminhador DNS implantado na assinatura do Hub, e ele o faz. Este servidor DNS é acessível (em termos de rede), pois o local está conectado a esta assinatura de hub via ExpressRoute/VPN. - O encaminhador DNS implantado na assinatura do hub não sabe a resposta, mas está ciente do encaminhador DNS implantado na assinatura de financiamento de produção, portanto, a solicitação é encaminhada nessa direção. Este servidor DNS é acessível (em termos de rede), uma vez que ambas as subscrições têm pares de VNETs.
- O servidor DNS e o encaminhador implantados em prd.finance.eastus.azure.nkotb podem resolver o endereço IP do banco de dados e enviar a resposta de volta na cadeia.
- O cliente localizado no local recebe a resposta.
- Cada solicitação DNS de acompanhamento (dentro do TTL do registro) será respondida imediatamente pelo servidor DNS local, pois a resposta foi armazenada em cache.
Exemplo 2: DNS interno entre 2 assinaturas
Dado que a equipe de marketing decide implantar um banco de dados chamado "Ballyhoo" na assinatura do desenvolvedor, o nome DNS interno seria ballyhoo.dev.marketing.eastus.azure.nkotb. Assim como o outro banco de dados implantado pelas finanças, esse banco de dados também pode ser resolvido no local. Mas neste cenário, a equipe de TI coleta alguns dados dentro da assinatura do desenvolvedor de TI, que devem ser armazenados no ballyhoo.dev.marketing.eastus.azure.nkotbbanco de dados. Portanto, este cenário descreve como um registro DNS pode ser resolvido em 2 assinaturas.
Como funciona o Exemplo 2
- O aplicativo de coleta de dados implantado na assinatura dev-IT solicita ao resolvedor DNS local implantado na mesma VNET o endereço IP de
ballyhoo.dev.marketing.eastus.azure.nkotb. - O servidor DNS local não sabe a resposta, mas está configurado para encaminhar todas as solicitações para o encaminhador DNS implantado na assinatura do Hub, e ele o faz. Este servidor DNS é acessível (em termos de rede), uma vez que ambas as subscrições têm pares de VNETs.
- O encaminhador DNS implantado na assinatura do hub não sabe a resposta, mas está ciente do encaminhador DNS implantado na assinatura de marketing de desenvolvimento, portanto, a solicitação é encaminhada nessa direção. Este servidor DNS é acessível (em termos de rede), uma vez que ambas as subscrições têm pares de VNETs.
- O servidor DNS e o encaminhador implantados em dev.marketing.eastus.azure.nkotb podem resolver o endereço IP do banco de dados e enviar a resposta de volta na cadeia.
- O aplicativo de coleta de dados recebe a resposta.
- Cada solicitação DNS de acompanhamento (dentro do TTL do registro) será respondida imediatamente pelo servidor DNS local, pois a resposta foi armazenada em cache.
Notas
Seu contato comercial no Azure geralmente ajuda a planejar esses cenários, para que você não precise resolver tudo sozinho. Existem outros aspectos importantes a serem considerados durante o processo de planejamento, mas o espaço não permite que sejam aqui delineados. Realização: Geralmente ajuda se a equipe da rede for incluída no processo desde o início.
Em geral, eu recomendo fortemente usar o software gratuitoMicrosoft Aprenda para Azurepara construir o conhecimento e as habilidades necessárias. Para suas dúvidas, os seguintes cursos seriam adequados: