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

  • Статья

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

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

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

Развертывание ресурсов классической вычислительной плоскости 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-адрес контейнера в подсети контейнера.

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

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

Адресное пространство виртуальной сети (CIDR) Максимальный размер подсети (CIDR) Azure Databricks без других подсетей
/16 /17
/17 /18
/18 /19
/20 /21
/21 /22
/22 /23
/23 /24
/24 /25

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

Размер подсети (CIDR) IP-адресов на подсеть Максимальное количество узлов кластера Azure Databricks
/17 32768 32763
/18 16384 16379
/19 8192 8187
/20 4096 4091
/21 2048 2043
/22 1024 1019
/23 512 507
/24 256 251
/25 128 123
/26 64 59

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

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

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

Предупреждение

Корпорация Майкрософт объявила, что 30 сентября 2025 г. подключение к исходящему доступу по умолчанию для виртуальных машин в Azure будет прекращено. См . это объявление. Это означает, что рабочие области Azure Databricks, использующие исходящий доступ по умолчанию, а не стабильный исходящий общедоступный IP-адрес, может не продолжать работать после этой даты. Databricks рекомендует добавлять явные исходящие методы для рабочих областей до этой даты.

Сведения о настройке общедоступного IP-адреса стабильного исходящего трафика см. в разделе "Исходящий трафик" с внедрением виртуальной сети.

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

Если требуются общие сетевые ресурсы, такие как 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), а не автоматическую конфигурацию виртуальной сети на основе портала и развертывание рабочей области на основе портала. Например, используйте существующие подсети, существующую группу безопасности сети или добавьте собственные правила безопасности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

Сведения в этом разделе относятся только к рабочим областям Azure Databricks, созданным после 13 января 2020 г. Если рабочая область была создана до выпуска безопасного подключения кластера (SCC) 13 января 2020 г., см. следующий раздел.

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

Направление Протокол Источник Исходный порт Назначение Порт назначения Использовано
Входящий трафик Любой Виртуальная сеть Любой Виртуальная сеть Любое По умолчанию.
Входящий трафик TCP AzureDatabricks (тег службы)
Только если SCC отключен		 Любой Виртуальная сеть 22 Общедоступный IP-адрес
Входящий трафик TCP AzureDatabricks (тег службы)
Только если SCC отключен		 Любой Виртуальная сеть 5557 Общедоступный IP-адрес
Исходящие TCP Виртуальная сеть Любое AzureDatabricks (тег службы) 443, 3306, 8443-8451 По умолчанию.
Исходящие TCP Виртуальная сеть Любое SQL 3306 По умолчанию.
Исходящие TCP Виртуальная сеть Любое Хранилище 443 По умолчанию.
Исходящие Любой Виртуальная сеть Любой Виртуальная сеть Любое По умолчанию.
Исходящие TCP Виртуальная сеть Любое Концентратор событий 9093 По умолчанию

Примечание.

Если вы ограничиваете правила исходящего трафика, Databricks рекомендует открывать порты 111 и 2049 для включения определенных установок библиотеки.

Внимание

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

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

Ошибки создания рабочей области

Подсети <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.

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

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

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