Подключение к общедоступной конечной точке для виртуальных машин с помощью Azure Load Balancer (цен. категория "Стандартный") в сценариях обеспечения высокого уровня доступности SAP

  • Статья

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

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

Обзор

При реализации высокого уровня доступности для решений SAP с помощью кластеризации один из необходимых компонентов — Azure Load Balancer. Azure предлагает два SKU балансировщика нагрузки: стандартный и базовый.

Стандартный балансировщик нагрузки Azure предоставляет некоторые преимущества по сравнению с базовым. Например, он работает в разных зонах доступности Azure, обеспечивает улучшенные возможности мониторинга и ведения журнала, упрощая диагностику неполадок и гарантируя сниженную задержку. Функция «порты высокой доступности» охватывает все порты, т. е. больше не нужно перечислять все индивидуальные порты.

Существует ряд важных различий между базовым и стандартным SKU балансировщика нагрузки Azure. Одним из них является передача исходящего трафика в общедоступную конечную точку. Полное сравнение базового и стандартного SKU балансировщика нагрузки см. в разделе Сравнение SKU балансировщиков нагрузки.

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

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

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

Примеры сценариев, требующих доступа к общедоступной конечной точке Azure:

  • Для Azure Fence Agent требуется доступ к адресам management.azure.com и login.microsoftonline.com
  • Azure Backup
  • Azure Site Recovery
  • Использование общедоступного репозитория для исправления операционной системы
  • Для потока данных приложений SAP может потребоваться исходящее подключение к общедоступной конечной точке.

Если развертывание SAP не требует исходящего подключения к общедоступным конечным точкам, вам не нужно реализовывать дополнительную конфигурацию. Для сценария высокой доступности достаточно создать SKU внутреннего балансировщика нагрузки Azure уровня «Стандартный», предполагая, что нет необходимости во входящем подключении с общедоступных конечных точек.

Примечание

Если в серверный пул внутреннего (без общедоступного IP-адреса) Azure Load Balancer ценовой категории "Стандартный" помещаются виртуальные машины без общедоступных IP-адресов, у них не будет исходящего подключения к Интернету без дополнительной настройки, разрешающей маршрутизацию к общедоступным конечным точкам.
Если виртуальные машины имеют общедоступные IP-адреса или уже находятся в серверном пуле балансировщика нагрузки Azure с общедоступным IP-адресом, виртуальная машина уже будет иметь исходящее подключение к общедоступным конечным точкам.

Сначала прочитайте следующую документацию.

Вариант 1. Дополнительные Azure Load Balancer (цен. категория "Стандартный") для исходящих подключений к Интернету

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

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

Важные сведения

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

Совет

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

Шаги по развертыванию

  1. Создание балансировщика нагрузки

    1. На портале Azure щелкните «Все ресурсы», «Добавить» и найдите Балансировщик нагрузки.
    2. Нажмите кнопку Создать.
    3. Имя балансировщика нагрузки: MyPublicILB
    4. Выберите тип Общедоступный и SKU Стандартный
    5. Выберите Создать общедоступный IP-адрес и укажите в качестве имени MyPublicILBFrondEndIP
    6. Выберите в качестве зоны доступности избыточную зону
    7. Щелкните «Проверка» и «Создать», а затем — «Создать»

  2. Создайте серверный пул MyBackendPoolOfPublicILB и добавьте виртуальные машины

    1. Выберите виртуальную сеть
    2. Выберите виртуальные машины и их IP-адреса и добавьте их в серверный пул

  3. Создание правил для исходящего трафика.

     az network lb outbound-rule create --address-pool MyBackendPoolOfPublicILB --frontend-ip-configs MyPublicILBFrondEndIP --idle-timeout 30 --lb-name MyPublicILB --name MyOutBoundRules  --outbound-ports 10000 --enable-tcp-reset true --protocol All --resource-group MyResourceGroup

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

    1. Перейдите в группу безопасности сети
    2. Щелкните «Правила безопасности для исходящего трафика»
    3. Добавьте правило, чтобы Запретить весь исходящий доступ в Интернет.
    4. Добавьте правило, чтобы Разрешить доступ в облако Azure, с приоритетом ниже, чем правило, запрещающее любой доступ в Интернет.

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

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

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

Вариант 2. Брандмауэр Azure для исходящих подключений к Интернету

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

Архитектура выглядит следующим образом:

Исходящие подключения и брандмауэр Azure

Важные сведения

  • Брандмауэр Azure — это облачная служба со встроенными механизмами обеспечения высокой доступности, которая поддерживает зональное развертывание.
  • Требуется дополнительная подсеть, которая должна называться AzureFirewallSubnet.
  • При исходящей передаче больших наборов данных из виртуальной сети, в которой находятся виртуальные машины SAP, на виртуальную машину в другой виртуальной сети или в общедоступную конечную точку расходы могут быть нецелесообразно высоки. Одним из таких примеров является копирование больших резервных копий по виртуальным сетям. См. подробные сведения в статье с ценами на брандмауэр Azure.
  • Если в компании используется отличное от брандмауэра Azure брандмауэрное решение и политика безопасности требует, чтобы весь исходящий трафик проходил через централизованное корпоративное решение, реализовать такое решение может быть непрактично.

Совет

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

Шаги по развертыванию

  1. В шагах развертывания предполагается, что у вас уже есть виртуальная сеть и подсеть, определенные для виртуальных машин.

  2. Создайте подсеть AzureFirewallSubnet в той же виртуальной сети, где развернуты виртуальные машины и стандартный балансировщик нагрузки.

    1. На портале Azure перейдите к виртуальной сети. Щелкните «Все ресурсы», найдите виртуальную сеть, щелкните виртуальную сеть и выберите «Подсети».
    2. Щелкните «Добавить подсеть». Введите имя AzureFirewallSubnet. Введите соответствующий диапазон адресов. Щелкните Save (Сохранить).

  3. Создайте брандмауэр Azure.

    1. На портале Azure выберите «Все ресурсы», щелкните «Добавить», «Брандмауэр», «Создать». Выберите группу ресурсов (выберите ту же группу ресурсов, в которой находится виртуальная сеть).
    2. Введите имя для ресурса брандмауэра Azure. Например, MyAzureFirewall.
    3. Выберите регион и по крайней мере две зоны доступности, соответствующие зонам доступности, в которых развернуты виртуальные машины.
    4. Выберите виртуальную сеть, в которой развернуты виртуальные машины SAP и стандартный балансировщик нагрузки Azure.
    5. Общедоступный IP-адрес Щелкните «Создать» и введите имя. Например, MyFirewallPublicIP.

  4. Создайте правило брандмауэра Azure, чтобы разрешить исходящее подключение к указанным общедоступным конечным точкам. В приведенном примере показано, как включить доступ к общедоступной точке API управления Azure.

    1. Выберите «Правила», «Коллекция правил сети»и нажмите «Добавить коллекцию правил сети».
    2. Имя: MyOutboundRule, укажите приоритет, выберите действие Разрешить.
    3. Служба: Имя: ToAzureAPI. Протокол: Выберите Любые. Исходный адрес: введите диапазон для своей подсети, где развернуты виртуальные машины и Load Balancer (цен. категория "Стандартный"), например: 11.97.0.0/24. Порты назначения: введите *.
    4. Сохранять
    5. Так как вы все еще находитесь в брандмауэре Azure, выберите «Обзор». Обратите внимание на частный IP-адрес брандмауэра Azure.

  5. Создание маршрута к брандмауэру Azure

    1. На портале Azure выберите «Все ресурсы», щелкните «Добавить», «Таблица маршрутизации», «Создать».
    2. Введите имя MyRouteTable, выберите «Подписка», «Группа ресурсов» и «Местоположение» (соответствующее местоположению виртуальной сети и брандмауэра).
    3. Сохранять

    Правило брандмауэра будет выглядеть так: Схема параметров брандмауэра.

  6. Создайте определяемый пользователем маршрут из подсети виртуальных машин на частный IP-адрес MyAzureFirewall.

    1. В таблице маршрутизации щелкните «Маршруты». Выберите "Добавить".
    2. Имя маршрута: ToMyAzureFirewall, префикс адреса: 0.0.0.0/0. Тип следующего прыжка: выберите «Виртуальное устройство». Адрес следующего прыжка — введите частный IP-адрес настроенного брандмауэра: 11.97.1.4.
    3. Сохранять

Вариант 3. Использование прокси-сервера для вызовов Pacemaker к API управления Azure

Можно использовать прокси-сервер, чтобы разрешить адресовать вызовы Pacemaker общедоступной конечной точке API управления Azure.

Важные сведения

  • Если корпоративный прокси-сервер уже существует, через него можно направить исходящие вызовы в общедоступные конечные точки. Исходящие вызовы к общедоступным конечным точкам будут проходить через корпоративную точку управления.
  • Убедитесь, что конфигурация прокси-сервера разрешает исходящее подключение к API управления Azure: https://management.azure.com и https://login.microsoftonline.com.
  • Убедитесь, что между виртуальными машинами и прокси-сервером есть маршрут.
  • Прокси-сервер будет обслуживать только вызовы HTTP/HTTPS. Если есть дополнительная необходимость совершать исходящие вызовы в общедоступную конечную точку через разные протоколы (такие как RFC), потребуется альтернативное решение.
  • Во избежание нестабильности в кластере Pacemaker решение прокси-сервера должно быть высокодоступным.
  • В зависимости от расположения прокси-сервера это может привести к дополнительной задержке в вызовах от агента ограждения Azure к API управления Azure. Если корпоративный прокси-сервер по-прежнему находится в локальной среде, а кластер Pacemaker находится в Azure, измерьте задержку и подумайте, подходит ли вам это решение.
  • Если у вас нет высокодоступного корпоративного прокси-сервера, мы не рекомендуем использовать этот вариант, так как это повысит сложность и стоимость решения для клиента. Тем не менее, если вы решили развернуть дополнительное прокси-решение, чтобы разрешить исходящее подключение из Pacemaker к общедоступному API управления Azure, убедитесь, что прокси-сервер имеет высокий уровень доступности, а задержка от виртуальных машин до прокси-сервера мала.

Настройка Pacemaker с использованием прокси-сервера

В отрасли доступно множество различных вариантов прокси-серверов. Пошаговые инструкции по развертыванию прокси-сервера выходят за рамки этого документа. В приведенном ниже примере предполагается, что прокси-сервер отвечает службе MyProxyService и слушает порт MyProxyPort.
Чтобы разрешить Pacemaker взаимодействовать с API управления Azure, выполните следующие действия на всех узлах кластера.

  1. Измените файл конфигурации Pacemaker /etc/sysconfig/pacemaker и добавьте следующие строки (все узлы кластера).

    sudo vi /etc/sysconfig/pacemaker
# Add the following lines
http_proxy=http://MyProxyService:MyProxyPort
https_proxy=http://MyProxyService:MyProxyPort

  2. Перезапустите службу Pacemaker на всех узлах кластера.

  • SUSE

    # Place the cluster in maintenance mode
sudo crm configure property maintenance-mode=true
#Restart on all nodes
sudo systemctl restart pacemaker
# Take the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

  • Red Hat

    # Place the cluster in maintenance mode
sudo pcs property set maintenance-mode=true
#Restart on all nodes
sudo systemctl restart pacemaker
# Take the cluster out of maintenance mode
sudo pcs property set maintenance-mode=false

Другие варианты

Если исходящий трафик направляется через сторонние прокси-серверы брандмауэра на основе URL-адресов:

  • при использовании агентов ограждения Azure следите за тем, чтобы конфигурация брандмауэра разрешала исходящие подключения на AP управления Azure (https://management.azure.com и https://login.microsoftonline.com);
  • при использовании общедоступной облачной инфраструктуры обновления Azure SUSE для применения обновлений воспользуйтесь рекомендациями из блога Azure Public Cloud Update Infrastructure 101 (Инфраструктура обновления общедоступного облака Azure 101).

Дальнейшие действия