Развертывание Azure Databricks в виртуальной сети Azure (внедрение виртуальной сети)

В этой статье описывается, как развернуть рабочую область Azure Databricks в собственной виртуальной сети Azure, что также называется инъекцией в виртуальную сеть (VNet).

Настройка сети с внедрением виртуальной сети

Azure Databricks, развернутая по умолчанию, — это полностью управляемая служба в Azure. Виртуальная сеть Azure развертывается в заблокированной группе ресурсов. Все ресурсы классической плоскости вычислений связаны с этой виртуальной сетью. Если требуется настройка сети, вы можете развернуть ресурсы классической вычислительной плоскости Azure Databricks в собственной виртуальной сети. Это позволяет:

• Подключите Azure Databricks к другим службам Azure (например, Azure Storage) более безопасно с помощью служебных конечных точек или частных конечных точек Azure.
• Подключитесь к локальным источникам данных с помощью определяемых пользователем маршрутов. См. Определяемые пользователем параметры маршрута для Azure Databricks.
• Подключите Azure Databricks к сетевому виртуальному устройству, чтобы проверить весь исходящий трафик и выполнить действия в соответствии с правилами разрешения и запрета. См. Вариант: Маршрутизация трафика Azure Databricks с помощью виртуального устройства или брандмауэра
• настроить использование пользовательских DNS-серверов в Azure Databricks; См. Параметр: настройка пользовательского DNS.
• настроить правила группы безопасности сети (NSG), чтобы указать определенные ограничения исходящего трафика;

Развертывание ресурсов классической вычислительной плоскости Azure Databricks в собственной виртуальной сети также позволяет воспользоваться гибкими диапазонами CIDR. Для виртуальной сети можно использовать размер /16-/24диапазона CIDR. Для подсетей используйте диапазоны IP вплоть до /26.

Требования к виртуальной сети

Виртуальная сеть, в которой развертывается рабочая область Azure Databricks, должна соответствовать следующим требованиям.

• Регион: Виртуальная сеть должна находиться в том же регионе и подписке, что и рабочая область Azure Databricks.
• Подписка. Виртуальная сеть должна относиться к той же подписке, что и рабочая область Azure Databricks.
• Адресное пространство. Блок CIDR между /16 и /24 для виртуальной сети и блок CIDR до /26 для двух подсетей: подсети контейнера и подсети узла. Рекомендации по использованию максимального количества узлов кластера в зависимости от размера виртуальной сети и ее подсетей см. в разделе Адресное пространство и максимальное количество узлов кластера.
• Подсети. Виртуальная сеть должна содержать две подсети, выделенные для рабочей области Azure Databricks: подсеть контейнера (иногда называемую частной подсетью) и подсеть узла (иногда называемую общедоступной подсетью). При развертывании рабочей области с помощью безопасного подключения к кластеру как подсеть контейнера, так и подсеть хоста используют частные IP-адреса. Вы не можете совместно использовать подсети в рабочих областях или развертывать другие ресурсы Azure в подсетях, используемых рабочей областью Azure Databricks. Рекомендации по использованию максимального количества узлов кластера в зависимости от размера виртуальной сети и ее подсетей см. в разделе Адресное пространство и максимальное количество узлов кластера.

Адресное пространство и максимальные узлы кластера

В рабочей области с небольшой виртуальной сетью IP-адреса (сетевое пространство) могут закончиться быстрее, чем в рабочей области с большой виртуальной сетью. Используйте блок CIDR между /16 и /24 для виртуальной сети и блок CIDR до /26 для двух подсетей: подсети контейнера и подсети узла. Вы можете создать блок CIDR до /28 для ваших подсетей, однако Databricks не рекомендует использовать подсеть меньше /26.

Диапазон CIDR для адресного пространства виртуальной сети влияет на максимальное количество узлов кластера, которые может использовать ваша рабочая область.

Для рабочей области Azure Databricks требуется две подсети в виртуальной сети: подсеть контейнера и подсеть узла. Azure резервирует пять IP-адресов в каждой подсети. Azure Databricks требует двух IP-адресов для каждого узла кластера: один IP-адрес узла в подсети узла и один IP-адрес контейнера в подсети контейнера.

• Возможно, вам не нужно использовать все адресное пространство виртуальной сети. Например, может потребоваться создать несколько рабочих областей в одной виртуальной сети. Так как вы не можете совместно использовать подсети в рабочих областях, может потребоваться, чтобы подсети не использовали общее адресное пространство виртуальной сети.
• Необходимо выделить адресное пространство для двух новых подсетей, находящихся в адресном пространстве виртуальной сети, и не перекрывать адресное пространство текущих или будущих подсетей в этой виртуальной сети.

В следующей таблице показан максимальный размер подсети на основе размера сети. В этой таблице предполагается, что дополнительные подсети не существуют, которые занимают адресное пространство. Используйте меньшие подсети, если у вас уже имеются подсети или вы хотите зарезервировать адресное пространство для других подсетей:

Чтобы найти максимальные узлы кластера на основе размера подсети, используйте следующую таблицу. IP-адреса для столбца подсети включают пять зарезервированных IP-адресов Azure. Самый правый столбец указывает количество узлов кластера, которые могут одновременно функционировать в рабочей области, обеспеченной подсетями этого размера.

Исходящие IP-адреса при использовании безопасного подключения к кластеру

Если вы включите безопасное подключение к кластеру в рабочей области, использующую внедрение виртуальной сети, Databricks рекомендует, чтобы в вашей рабочей области был стабильный исходящий общедоступный IP-адрес.

Стабильные исходящие общедоступные IP-адреса полезны, так как их можно добавить во внешние списки разрешений. Например, чтобы подключиться из Azure Databricks к Salesforce с стабильным исходящим IP-адресом. Если вы настраиваете списки IP-доступа, эти общедоступные IP-адреса необходимо добавить в список разрешений. См . статью "Настройка списков IP-доступа для рабочих областей".

Чтобы настроить стабильный общедоступный IP-адрес исходящего трафика, смотрите Egress при внедрении VNet.

Общие ресурсы и пиринг

Если требуются общие сетевые ресурсы, такие как DNS, Databricks настоятельно рекомендует использовать лучшие практики Azure для модели концентратора и периферии. Используйте пиринг виртуальных сетей для расширения частного IP-пространства виртуальной сети рабочей области до сетевого концентратора, сохраняя периферийные узлы изолированными друг от друга.

Если у вас есть другие ресурсы в виртуальной сети или используется пиринг, Databricks настоятельно рекомендует добавить правила запрета в группы безопасности сети (NSG), подключенные к другим сетям и подсетям, которые находятся в той же виртуальной сети или имеют пиринговые подключения к этой виртуальной сети. Добавьте правила запрета для подключений как для входящих, так и исходящих подключений, чтобы они ограничивали подключения как к вычислительным ресурсам Azure Databricks, так и из них. Если кластеру требуется доступ к ресурсам в сети, добавьте правила, чтобы разрешить только минимальный объем доступа, необходимый для удовлетворения требований.

Дополнительные сведения см. в разделе "Правила группы безопасности сети".

Создайте рабочую область Azure Databricks с помощью портала Azure

В этом разделе описано, как создать рабочую область Azure Databricks на портале Azure и развернуть ее в существующей виртуальной сети. Azure Databricks обновляет виртуальную сеть с двумя новыми подсетями, если они еще не существуют, используя указанные диапазоны CIDR. Служба также обновляет подсети с помощью новой группы безопасности сети, настраивает правила для входящих и исходящих подключений, а затем развертывает рабочую область в обновленной виртуальной сети. Для получения большего контроля над конфигурацией виртуальной сети используйте шаблоны Azure-Databricks, предоставленные Azure Resource Manager (ARM), а не на портале. Например, используйте существующие группы безопасности сети или создайте собственные правила безопасности. См. раздел Расширенная конфигурация с использованием шаблонов Azure Resource Manager.

Пользователю, создающему рабочую область, необходимо назначить роль участника сети соответствующей виртуальной сети или пользовательскую роль, назначенную с разрешениями Microsoft.Network/virtualNetworks/subnets/join/action и Microsoft.Network/virtualNetworks/subnets/write.

Необходимо настроить виртуальную сеть, в которой будет развернута рабочая область Azure Databricks. Вы можете использовать существующую виртуальную сеть или создать новую, но виртуальная сеть должна находиться в том же регионе и той же подписке, что и рабочая область Azure Databricks, которую планируется создать. Размер виртуальной сети должен быть в диапазоне CIDR от /16 до /24. Дополнительные требования см. в статье Требования к виртуальной сети.

Используйте существующие подсети или укажите имена и диапазоны IP-адресов для новых подсетей при настройке рабочей области.

1. На портале Azure выберите + Создать ресурс > Аналитика > Azure Databricks или найдите Azure Databricks и щелкните Создать или + Добавить, чтобы открыть диалоговое окно службы Azure Databricks.

2. Выполните действия по настройке, описанные в кратком руководстве Создание рабочей области Azure Databricks в вашей виртуальной сети.

3. На вкладке Сети выберите виртуальную сеть, которую вы хотите использовать в поле Виртуальной сети.

   Внимание

   Если сетевое имя в средстве выбора не отображается, убедитесь, что регион Azure, указанный для рабочей области, соответствует региону Azure нужной виртуальной сети.

   виртуальной сети

4. Дайте имена вашим подсетям и укажите диапазоны CIDR в блоках размером до /26. Рекомендации по использованию максимального количества узлов кластера в зависимости от размера виртуальной сети и ее подсетей см. в разделе Адресное пространство и максимальное количество узлов кластера. Диапазоны CIDR подсети нельзя изменить после развертывания рабочей среды.

   • Чтобы указать существующие подсети, приведите их точные имена. При использовании существующих подсетей также задайте диапазоны IP-адресов в форме создания рабочей области, чтобы точно соответствовать диапазонам IP-адресов существующих подсетей.
   • Чтобы создать новые подсети, укажите имена подсетей, которые еще не существуют в этой виртуальной сети. Подсети создаются с указанными диапазонами IP-адресов. Необходимо задать диапазоны IP-адресов в диапазоне IP-адресов виртуальной сети, которые еще не выделены для существующих подсетей.

   Azure Databricks требует, чтобы имена подсетей не превышали 80 символов.

   Подсети получают связанные правила группы безопасности сети, которые включают правило, разрешающее взаимодействие между кластерами. Azure Databricks предоставил права на обновление обеих подсетей через поставщика ресурсов Microsoft.Databricks/workspaces. Эти разрешения применяются только к правилам группы безопасности сети, которые требуются для Azure Databricks, а не к другим правилам группы безопасности сети, которые вы добавляете, или к правилам группы безопасности сети по умолчанию, входящим во все группы безопасности сети.

5. Нажмите кнопку Создать, чтобы развернуть рабочую область Azure Databricks в виртуальной сети.

Расширенная конфигурация с помощью шаблонов Azure Resource Manager

Чтобы получить больший контроль над настройками виртуальной сети, используйте следующие шаблоны Azure Resource Manager (ARM) вместо автоматической настройки виртуальной сети и развертывания рабочей области через портал UI. Например, используйте существующие подсети, существующую группу безопасности сети или добавьте собственные правила безопасности.

Если вы используете пользовательский шаблон Azure Resource Manager или шаблон рабочей области для внедрения виртуальной сети Azure Databricks для развертывания рабочей области в существующей виртуальной сети, необходимо создать подсети узла и контейнера, подключить группу безопасности сети к каждой подсети и делегировать подсети Microsoft.Databricks/workspaces поставщику ресурсов перед развертыванием рабочей области. Для каждой развертываемой рабочей области необходимо иметь отдельную пару подсетей.

Все в одном шаблоне

Чтобы создать виртуальную сеть и рабочую область Azure Databricks с помощью одного шаблона, используйте универсальный шаблон для подставляемых рабочих областей виртуальной сети Azure Databricks.

Шаблон виртуальной сети

Чтобы создать виртуальную сеть с нужными подсетями с помощью шаблона, используйте шаблон VNet для интеграции VNet в Databricks.

Шаблон рабочей области Azure Databricks

Чтобы развернуть рабочую область Azure Databricks в существующей виртуальной сети с помощью шаблона, используйте шаблон рабочей области для внедрения виртуальной сети Azure Databricks.

Шаблон рабочей области позволяет указать существующую виртуальную сеть и использовать существующие подсети:

• Для каждой рабочей области, которую вы развертываете, необходимо иметь отдельную пару подсетей узлов и контейнеров. Совместное использование подсетей в рабочих областях или развертывание других ресурсов Azure в подсетях, используемых рабочей областью Azure Databricks, не поддерживается.

• Подсети хоста и контейнеров вашей виртуальной сети (VNet) должны иметь прикрепленные группы безопасности сети и должны быть делегированы службе Microsoft.Databricks/workspaces перед использованием этого шаблона Azure Resource Manager для развертывания рабочей области.

• Чтобы создать виртуальную сеть с корректно делегированными подсетями, используйте шаблон для внедрения VNet от Databricks.

• Чтобы использовать существующую виртуальную сеть, если вы еще не делегировали подсети узла и контейнера, см. статью Добавление или удаление делегирования подсети.

Правила группы безопасности сети

В следующих таблицах отображаются текущие правила группы безопасности сети, используемые Azure Databricks. Если Azure Databricks необходимо добавить правило или изменить область существующего правила в этом списке, вы получите предварительное уведомление. Эта статья и таблицы будут обновляться всякий раз, когда такое изменение происходит.

Как Azure Databricks управляет правилами группы безопасности сети

Правила группы безопасности сети в следующих разделах автоматически подготавливаются и управляются Azure Databricks с помощью делегирования узлов и подсетей контейнеров виртуальной сети в Microsoft.Databricks/workspaces службу. Эти правила не следует обновлять или удалять, так как они защищены делегированием подсети. Эти правила необходимы корпорации Майкрософт для надежной работы и поддержки Azure Databricks в виртуальной сети.

Некоторые правила NSG используют VirtualNetwork как источник, так и назначение, чтобы упростить проектирование в отсутствие тегов службы на уровне подсети. Все кластеры защищены внутренними политиками сети, которые предотвращают взаимодействие между кластерами, даже между разными рабочими областями, развернутыми в одной и той же управляемой клиентом виртуальной сети.

Azure Databricks рекомендует для каждой рабочей области использовать уникальную группу безопасности сети.

правила группы безопасности сети для рабочих пространств

В этой таблице перечислены правила группы безопасности сети для рабочих областей и два правила группы безопасности входящего трафика, которые включаются только в том случае, если безопасное подключение к кластеру (SCC) отключено.

Устранение неполадок

Подсети <subnet-id> требуется одно из следующих делегирований [Microsoft.Databricks/workspaces] для использования ссылки на ассоциацию службы

Возможная причина: вы создаете рабочую область в виртуальной сети, узлы и подсети контейнеров которой не были делегированы службе Microsoft.Databricks/workspaces. К каждой подсети должна быть присоединена сетевая группа безопасности, и она должна быть надлежащим образом делегирована. Дополнительные сведения см. в разделе Требования к виртуальной сети.

Подсеть <subnet-id> уже используется рабочей областью <workspace-id>

Возможная причина: вы создаете рабочую область в виртуальной сети с подсетями узла и контейнера, которые уже используются в существующей рабочей области Azure Databricks. Вы не можете совместно использовать несколько рабочих областей в одной подсети. Для каждой развертываемой рабочей области необходимо иметь новую пару подсетей для хоста и контейнера.

Инстансы недоступны: ресурсы не доступны через SSH.

Возможная причина: блокировка трафика с управляющего уровня на рабочие узлы. Если развертывание выполняется в имеющуюся виртуальную сеть, подключенную к локальной сети, проверьте настройку, используя сведения из статьи Подключение рабочей области Azure Databricks к локальной сети.

Непредвиденный сбой запуска: при настройке кластера произошла непредвиденная ошибка. Повторите попытку и обратитесь к команде Azure Databricks, если проблема повторится. Внутреннее сообщение об ошибке: Timeout while placing node.

Возможная причина: трафик от рабочих к конечным точкам хранилища Azure заблокирован. Если вы используете пользовательские DNS-серверы, также проверьте состояние DNS-серверов в виртуальной сети.

Cloud Provider Launch Failure: при настройке кластера произошла ошибка поставщика облачных служб. Дополнительные сведения см. в руководстве по Azure Databricks. Код ошибки Azure: AuthorizationFailed/InvalidResourceReference.

Возможная причина: виртуальная сеть или подсети больше не существуют. Убедитесь, что виртуальная сеть и подсети существуют.

Завершение работы кластера. Причина: сбой запуска Spark: не удалось запустить Spark вовремя. Эта проблема может быть вызвана неисправным хранилищем метаданных Hive, недопустимыми конфигурациями Spark или неисправными скриптами инициализации. Для устранения этой проблемы посмотрите журналы драйвера Spark и свяжитесь с Databricks, если проблема сохраняется. Внутреннее сообщение об ошибке: Spark failed to start: Driver failed to start in time.

Возможная причина: контейнер не может взаимодействовать с хостинг-экземпляром или со счетом хранения рабочей области. Исправьте, добавив настраиваемый маршрут для подсетей учетной записи хранения рабочей области с использованием следующего узла — Интернет.

Конфликт с политикой намерения сети

При создании новой рабочей области Databricks убедитесь, что правило исходящего трафика NSG из виртуальной сети в тег службы Databricks разрешает трафик через порты 443, 3306 и 8443-8451. Существующие рабочие области также должны включать эти порты. Databricks уведомил вас в июле 2024 года о том, что не удалось обновить правила NSG, и эти порты не включены. Чтобы устранить эту проблему, включите порты 443, 3306 и 8443-8451 в правиле исходящего трафика NSG.

См. обновления правил групп безопасности сети для групп безопасности сети и правила групп безопасности сети для рабочих областей.