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