Stati c IP для Azure блоков данных - PullRequest
Новая
       20

Stati c IP для Azure блоков данных

1 голос
/ 18 марта 2020

Как правильно настроить stati c publi c ip (или диапазон ip) для рабочего пространства Databricks в Azure? Каким было бы самое простое рабочее решение?

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

  1. NAT gateway - когда связанный шлюз с кластерами publi c su bnet не запускается с ошибкой: " Ошибка конфигурации сети "и более подробная информация" [шлюз Nat] не может быть развернут на su bnet, содержащем IP-адреса Basi c SKU Publi c или балансировщик нагрузки Basi c SKU. NI C ".
  2. Использование брандмауэра и таблицы маршрутизации - как описано здесь - это работает частично (я не смог установить python установленных пакетов - SSLError (SSLError ("bad handshake: SysCallError (-1, 'Unexpected EOF'" ) "))). Проблема в том, что это довольно дорого ~ 1 € в час.
  3. Трафик трафиком c через NVA - как описано здесь - мне не удалось заставить его работать - кажется, тоже немного сложнее для моего простого развертывания.

Ответы [ 2 ]

0 голосов
/ 27 апреля 2020

По словам команды разработчиков из Microsoft:

  • поддержка шлюза NAT включена в их план действий - пока нет ETA (кажется, что для развертывания баз данных используются базисные c publi c IP и NAT шлюз поддерживает только стандартные публичные c IP-адреса), брандмауэр
  • является официально рекомендуемым решением, а NVA - вероятный обходной путь.
0 голосов
/ 27 марта 2020

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

Проблема с # 3 и переадресацией IP заключается в том, что хотя вы можете создать третий "NVA" su bnet (подключенный к Inte rnet с NAT) в Azure DataBricks VNET, и вы можете получить пакеты из databricks-publi c su bnet, перенаправленные на этот "NVA" su bnet, эти пакеты не будут go никакими далее, поскольку Azure NAT, подключенный к «NVA», su bnet не будет принимать их (поскольку они происходят от другого su bnet)

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

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

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

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

Последний step (и azure NAT) не требуется супер, но я просто не хотел, чтобы виртуальная машина была напрямую подключена к подсетям Inte rnet

...