Для других читателей с тем же вопросом :См. также Адрес, который будет использоваться для доступа к частному IP-адресу для ресурса AZURE из помещения -для получения некоторой справочной информации.

Прежде чем я начну отвечать, небольшая поправочка к вашему вопросу, как вы написали "...то же DNS-имя". Я думаю, что это недоразумение, поскольку Azure Cosmos DB является полностью управляемой службой, означает SaaS и поэтому имеет уникальные имена. Другими словами, невозможно, чтобы две службы Azure Cosmos DB имели одно и то же DNS-имя. Тем не менее, я не хочу исправлять это в вопросе, но предпочитаю ссылку как часть ответа, так как это действительно распространенное недоразумение. Все сводится к тому, как построено разрешение имен гибридного решения.

Разрешить такой сценарий легко, используя уникальные DNS-имена (, что не является проблемой, поскольку CosmosDB является SaaS и поэтому имеет уникальные имена ), и убедиться, что все ресурсы могут быть разрешены.

Краткий ответ

Для каждой из ваших подписок под корпоративной учетной записью, подключенной к -учреждению через ExpressRoute или VPN, настройте частный DNS Azure и сервер пересылки DNS, развернутый в одном и том же подсеть. Хаб соединяет все, в том числе и в помещении -.

Подробный ответ

Гипотетический пример (определение миссии)

Как это работает лучше пояснить на примере.

Учитывая гипотетический корпоративный «NKOTB INC» имеет 3 отдела:

• Финансы
• ИТ
• Маркетинг

Каждый отдел управляет 2 подписками Azure, один для разработки, другой для производства нагрузка. Таким образом, мы должны иметь дело как минимум с шестью подписками, чтобы выполнить требования.

Требования, связанные с сетью -, следующие::

• Каждая подписка должна иметь возможность подключения к -помещения.
• Каждая подписка может использовать или не использовать ресурсы, развернутые с использованием частных ссылок.
• Из-за юридических ограничений все ресурсы во всех подписках в настоящее время развернуты в регионе «Восток США».
• Планируется расширение бизнеса, в конечном итоге за счет других регионов. Поэтому это следует учитывать при планировании.

Подход к реализации

Используя этот сценарий, вы можете получить по крайней мере 7 подписок:

• dev -финансы
• prd -финансы
• dev -it
• prd -it
• dev -marketing
• prd -marketing
• Hub , который подключается к -помещения через VPN или ExpressRoute.

Для всех шести подписок необходимо развернуть частную DNS Azure и сервер пересылки DNS. Кроме того, все они используют виртуальную сеть, которая связана с подпиской центрального концентратора -. Таким образом, в конечном итоге вы получите эти семь внутренних 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

The Hub -настроен второй набор DNS-серверов и серверов пересылки. Только этот набор DNS-серверов знает о других семи серверах пересылки DNS, развернутых в других доменах и отвечающих за разрешение имен домена «eastus.azure.nkotb». Все локальные DNS-серверы -настроены на пересылку всех DNS-запросов для *.eastus.azure.nkotb на этот набор DNS-серверов.

Пример 1 :внутренний DNS между подпиской и локальным сервером

Учитывая, что финансовый отдел решает развернуть базу данных с именем «Альцгеймер» в рабочей подписке, используя частную ссылку. Таким образом, внутреннее DNS-имя (FQDN )для этой базы данных будет alzheimer.prd.finance.eastus.azure.nkotb. Благодаря внутреннему разрешению имен, согласованному во всех подписках, а также в -prem, это имя может быть разрешено везде в корпоративной сети.

Как работает пример 1

• Случайный клиент, расположенный в помещении -, запрашивает у местного DNS-сервера разрешение alzheimer.prd.finance.eastus.azure.nkotb.
• Локальный DNS-сервер не знает ответа, но настроен на пересылку всех запросов на *.eastus.azure.nkotbDNS-серверу пересылки, развернутому в рамках подписки Hub -, поэтому он это делает. Этот DNS-сервер доступен (по сети -по ), так как в предпосылке -он подключен к этой подписке концентратора через ExpressRoute/VPN.
• Сервер пересылки DNS, развернутый в подписке-концентраторе, не знает ответа, но знает о сервере пересылки DNS, развернутом в подписке на производственное финансирование, поэтому запрос перенаправляется в этом направлении. Этот DNS-сервер доступен (по сети -по ), так как обе подписки имеют одноранговые сети VNET.
• DNS-сервер и сервер пересылки, развернутые в prd.finance.eastus.azure.nkotb, могут разрешать IP-адрес базы данных и отправлять ответ обратно по цепочке.
• Клиент, расположенный в помещении -, получает ответ.
• На каждый последующий -вверх DNS-запрос (в пределах TTL записи )будет немедленно получен ответ от локального DNS-сервера, поскольку ответ был кэширован.

Пример 2 :внутренний DNS между 2 подписками

Учитывая, что команда маркетинга решила развернуть базу данных с именем «Ballyhoo» в рамках подписки для разработчиков, внутреннее DNS-имя будет ballyhoo.dev.marketing.eastus.azure.nkotb. Как и другая база данных, развернутая финансовым отделом, эта база данных также может быть разрешена из -prem. Но в этом сценарии ИТ-команда собирает некоторые данные в рамках подписки ИТ-разработчика, которые должны храниться в базе данных ballyhoo.dev.marketing.eastus.azure.nkotb. Таким образом, этот сценарий описывает, как запись DNS может быть разрешена в пределах 2 подписок.

Как работает пример 2

• Приложение для сбора данных, развернутое в dev -IT-подписке, запрашивает у локального преобразователя DNS, развернутого в той же виртуальной сети, 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 , чтобы получить необходимые знания и навыки. Для ваших вопросов подойдут следующие курсы:

• Основы Microsoft Azure
• Проектирование и внедрение гибридных сетей