Глядя на нижеследующее:
Здесь мы видим одну учетную запись AZURE Corporate X. Смотрите "azsql1.database.windows.net". Вы можете получить к ней доступ из локальной сети.
А что, если бы у меня была вторая среда AZURE, настроенная точно так же — корпоративная учетная запись AZURE Y, с «azsql1.database.windows.net».
Это теоретически, но мне бы хотелось узнать, как локально решается эта проблема, если кто-то пытается использовать «azsql1.database.windows.net» для отчета о подключении, скажем, в Tableau, Spotfire?
Полагаю, что вам каким-то образом нужно указать, какой DNS-сервер пересылки использовать в той или иной корпоративной учетной записи AZURE.
Так что, простите, но я понимаю основы разрешения DNS в интернете и т. д., но не являюсь экспертом в области сетей.
решение1
Для других читателей с тем же вопросом: см. такжеАдрес, который будет использоваться для доступа к частному IP-адресу ресурса AZURE из локальной сетидля получения дополнительной информации.
Прежде чем я начну отвечать, небольшая поправка к вашему вопросу, так как вы написали "... то же самое имя DNS". Я думаю, что это недоразумение, так какБаза данных Azure Cosmosэто полностью управляемая услуга, означаетPaaSи как таковой имеет уникальные имена. Другими словами, невозможно, чтобы две службы Azure Cosmos DB имели одинаковое имя DNS. Тем не менее, я не хочу исправлять это в вопросе, но предпочитаю ссылку как часть ответа, поскольку это действительно распространенное недоразумение. Все сводится к тому, как спроектировано разрешение имен гибридного решения.
Разрешить такую ситуацию легко, используя уникальные имена DNS (что не является проблемой, поскольку CosmosDB — это SaaS-сервис и, как таковой, имеет уникальные имена) и убедившись, что все ресурсы могут быть разрешены.
Краткий ответ
Для каждой из ваших подписок в корпоративной учетной записи, подключенной к локальной сети через ExpressRoute или VPN, настройтеЧастный DNS Azureи DNS-форвардер, который развернут в той же подсети. Хаб соединяет все, включая локальные.
Длинный ответ
Гипотетический пример (определение миссии)
Как это работает, лучше объяснить на примере.
Учитывая гипотетическую корпоративную "НКОТБINC" имеет 3 отдела:
- Финансы
- ЭТО
- Маркетинг
Каждый отдел использует 2 подписки Azure, одну для разработки, другую для производственной нагрузки. Таким образом, нам приходится иметь дело как минимум с шестью подписками в общей сложности, чтобы соответствовать требованиям.
Требования к сети следующие:
- Каждая подписка должна иметь подключение к локальной системе.
- Каждая подписка может использовать или не использовать ресурсы, которые развертываются с использованием частных ссылок.
- Из-за правовых ограничений все ресурсы во всех подписках в настоящее время развернуты вобласть«Восток США».
- Планируется расширить бизнес, в конечном итоге задействовав другие регионы. Поэтому это следует учитывать при планировании.
Подход к реализации
Используя этот сценарий, у вас может оказаться не менее 7 подписок:
- дев-финанс
- prd-финансы
- dev-it
- prd-it
- dev-маркетинг
- prd-маркетинг
- Центркоторый подключается к локальной сети через VPN или ExpressRoute.
Все шесть подписок должны развернуть частный DNS Azure и DNS-пересылку. Кроме того, все они используют VNET, которая пирингуется с центральной подпиской Hub. Так что в конечном итоге вы получите эти семь внутренних доменов DNS:
- 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
Hub-subscription имеет второй набор DNS-серверов и настроенных пересылок. Только этот набор DNS-серверов знает о семи других DNS-пересылках, развернутых в других доменах, и отвечает за разрешение имен домена "eastus.azure.nkotb". Все локальные DNS-серверы настроены на пересылку всех DNS-запросов для *.eastus.azure.nkotb на этот набор DNS-серверов.
Пример 1: внутренний DNS между подпиской и локальной средой
Учитывая, что финансовая группа решает развернуть базу данных с именем "Alzheimer" в рамках производственной подписки, используя частную ссылку. Таким образом, внутреннее имя DNS (FQDN) для этой базы данных будет alzheimer.prd.finance.eastus.azure.nkotb. Благодаря внутреннему разрешению имен, которое согласуется по всем подпискам, а также локально, это имя может быть разрешено везде в корпоративной сети.
Как работает Пример 1
- Случайный клиент, расположенный локально, запрашивает у локального DNS-сервера разрешение
alzheimer.prd.finance.eastus.azure.nkotb. - Локальный DNS-сервер не знает ответа, но настроен на пересылку всех запросов на
*.eastus.azure.nkotbDNS-пересылку, развернутую в Hub-подписке, поэтому он знает. Этот DNS-сервер доступен (сетевой), так как on-premise подключен к этой подписке hub через ExpressRoute/VPN. - DNS-форвардер, развернутый в подписке концентратора, не знает ответа, но знает о DNS-форвардере, развернутом в подписке финансирования производства, поэтому запрос пересылается в этом направлении. Этот DNS-сервер доступен (сетевой), поскольку обе подписки имеют пиринговые VNET.
- DNS-сервер и сервер пересылки, развернутые в prd.finance.eastus.azure.nkotb, могут разрешить IP-адрес базы данных и отправить ответ обратно по цепочке.
- Клиент, находящийся на территории компании, получает ответ.
- На каждый последующий DNS-запрос (в пределах TTL записи) будет немедленно дан ответ от локального DNS-сервера, поскольку ответ был кэширован.
Пример 2: внутренний DNS между 2 подписками
Учитывая, что маркетинговая команда решает развернуть базу данных с именем "Ballyhoo" в рамках подписки dev, внутреннее имя DNS будет ballyhoo.dev.marketing.eastus.azure.nkotb. Как и другая база данных, развернутая финансовым отделом, эта база данных может быть разрешена также локально. Но в этом сценарии ИТ-отдел собирает некоторые данные в рамках подписки ИТ-dev, которые должны храниться с использованием ballyhoo.dev.marketing.eastus.azure.nkotbбазы данных. Таким образом, этот сценарий описывает, как запись DNS может быть разрешена в рамках 2 подписок.
Как работает пример 2
- Приложение для сбора данных, развернутое в подписке dev-IT, запрашивает у локального DNS-резолвера, развернутого в той же VNET, IP-адрес
ballyhoo.dev.marketing.eastus.azure.nkotb. - Локальный DNS-сервер не знает ответа, но настроен на пересылку всех запросов на DNS-пересылку, развернутую в Hub-подписке, поэтому он знает. Этот DNS-сервер доступен (сетевой), так как обе подписки имеют пиринговые VNET.
- DNS-форвардер, развернутый в подписке-концентраторе, не знает ответа, но знает о DNS-форвардере, развернутом в подписке dev marketing, поэтому запрос пересылается в этом направлении. Этот DNS-сервер доступен (сетевой), поскольку обе подписки имеют пиринговые VNET.
- DNS-сервер и сервер пересылки, развернутые в dev.marketing.eastus.azure.nkotb, могут разрешить IP-адрес базы данных и отправить ответ обратно по цепочке.
- Приложение для сбора данных получает ответ.
- На каждый последующий DNS-запрос (в пределах TTL записи) будет немедленно дан ответ от локального DNS-сервера, поскольку ответ был кэширован.
Примечания
Ваш деловой контакт в Azure обычно помогает планировать такие сценарии, поэтому вам не нужно прорабатывать все самостоятельно. Есть и другие важные аспекты, которые следует учитывать в процессе планирования, но пространство не позволяет описать их здесь. Реализация: Обычно помогает, если сетевая команда включается в процесс с самого начала.
В общем, я настоятельно рекомендую использовать бесплатныйMicrosoft Learn для Azureдля формирования необходимых знаний и навыков. Для ваших вопросов следующие курсы будут адекватны: