Статический IP-адрес для Azure Databricks

Как правильно настроить статический общедоступный IP-адрес (или диапазон IP-адресов) для рабочего пространства Databricks в Azure? Какое было бы самое простое рабочее решение?

Я хотел бы иметь возможность занести в белый список IP-адрес Databricks на ftp-сервере (работающем вне Azure), к которому будут обращаться некоторые задания. Databricks уже работает в VNET, поэтому я попробовал следующие сценарии:

  1. Шлюз NAT - когда связанный шлюз с общедоступными кластерами подсети не запускается с ошибкой: «Ошибка конфигурации сети» и другие сведения «[Шлюз Nat] не может быть развернут в подсети, содержащей общедоступные IP-адреса базового SKU или балансировщик нагрузки базового SKU. NIC».
  2. Использование брандмауэра и таблицы маршрутизации - как описано здесь - это работает частично (мне не удалось установить пакеты python - SSLError (SSLError ("плохое рукопожатие: SysCallError (-1, 'Unexpected EOF')"))). Проблема в том, что это довольно дорого ~ 1 евро в час.
  3. Маршрутизируйте трафик через NVA - как описано здесь - мне не удалось заставить его работать - он кажется слишком сложным для моего простого развертывания.

azure azure-databricks databricks
person Marcin    schedule 18.03.2020    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я также пробовал №1 и №2 безуспешно.

Проблема с №3 и переадресацией IP-адресов заключается в том, что, хотя вы можете создать третью подсеть «NVA» (подключенную к Интернету через NAT) в виртуальной сети Azure DataBricks, и вы можете получать пакеты из общедоступной подсети databricks, перенаправленные в эту подсеть «NVA», эти пакеты не пойдут дальше, так как Azure NAT, подключенный к подсети "NVA", не будет их принимать (поскольку они исходят из другой подсети)

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

  1. Databricks VNET имеет 3 подсети: частные databricks (10.139.64.0/18), общедоступные databricks (10.139.0.0/18) и новую под названием «NVA» (10.139.128.0/24).
  2. NAT Azure с общедоступным IP-адресом подключен к подсети "NVA".
  3. Виртуальная машина Windows Server с 2 созданными сетевыми интерфейсами: 1 интерфейс, подключенный к подсети «NVA» (например, статический IP-адрес 10.139.128.4), и 2-й интерфейс, подключенный к подсети «databricks-public» (например, статический IP-адрес 10.139.0.4)
  4. Удаленный доступ с ролью «Маршрутизатор» установлен и настроен на виртуальной машине Windows Server. Интерфейс с IP «NVA» (10.139.128.4) выбирается как подключенный к Интернету при настройке NAT в «Маршрутизация и удаленный доступ»
  5. Таблица маршрутизации Azure создается и присоединяется к подсети «databricks-public». Среди прочего, у него есть маршрут 0.0.0.0/0 -> 10.139.0.4 (виртуальное устройство)

Поток пакетов в окончательной настройке выглядит так:

  1. databricks-общедоступная подсеть (рабочая виртуальная машина) отправляет пакет в Интернет
  2. Вместо прямого выхода в Интернет используется принудительный маршрут с 0.0.0.0/0 на 10.139.0.4 (виртуальная машина Windows Server).
  3. Виртуальная машина Windows переводит (NAT) пакет, исходящий из подсети 10.139.0.0/18, в пакет, исходящий из подсети 10.139.128.0/24
  4. Azure NAT забирает этот пакет и выполняет NAT еще раз (назначая общедоступный IP-адрес в качестве источника пакета).

Последний шаг (и лазурный NAT) не обязателен, но я просто не хотел, чтобы виртуальная машина была напрямую подключена к Интернету.

person burma    schedule 26.03.2020
comment
Спасибо, что поделились своим решением @burma. Это также работает для меня, однако, как вы написали, эта архитектура не идеальна - создает некоторые накладные расходы на управление инфраструктурой, потенциальное узкое место / единую точку отказа ... и усложняет развертывание (я предполагаю, что настройку Windows vm можно как-то автоматизировать ...) . Я жду отзывов от Microsoft - обновлю пост, как только он у меня будет. - person Marcin; 30.03.2020

arrow_upward
0
arrow_downward

По словам продуктовой группы Microsoft:

  • поддержка шлюза NAT находится в их дорожной карте - пока нет ETA (похоже, что развертывание блоков данных использует базовые общедоступные IP-адреса, а шлюз NAT поддерживает только стандартные общедоступные IP-адреса),
  • Брандмауэр является официально рекомендуемым решением, а NVA - подходящим решением.
person Marcin    schedule 27.04.2020
comment
Шлюз NAT для блоков данных теперь находится в общедоступной предварительной версии (и он работает) - docs.microsoft.com/en-us/azure/databricks/security/ - person Marcin; 18.12.2020