Диагностика Azure HA vSocket

Обзор

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

Симптомы

При развертывании Azure vSocket HA вы можете столкнуться со следующими симптомами:

• Сбой скрипта HA
  • Не удалось выполнить скрипт create_ha_settings в ручном развертывании.
  • Проблемы с развертыванием вторичного vSocket через Marketplace.
• Сбой переключения HA
  • Неудачные тесты HA API из Веб-интерфейса сокета.
  • Неудача в переключении HA, что приводит к непространствованию трафика на вторичный vSocket.
• Статус HA Не Готов
  • CMA показывает, что Статус HA Сайта - Не Готово

Возможные причины

Наиболее частыми причинами неудачі развертывания HA являются:

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

Устранение проблемы

Устранение Сбоя Скрипта HA

Скрипт HA Azure (create_ha_settings) и развертывание вторичного vSocket через Marketplace проверяют, что подписка Azure содержит два действительных vSocket, затем назначают Роли для создания HA и механизма переключения. Если запуск скрипта не удался, выполните следующие шаги по устранению неполадок:

Проверка Журналов Активности

• В Azure Журналы Активности хранят все события, произошедшие внутри каждого ресурса Azure. Просмотрите эти журналы, если развертывание не удалось и одна из ролей не назначена. Перейдите к VM или NIC и выберите журнал активности
  

Проверка Ограничений на Имена в Azure 

• При вводе Имени vSocket в скрипт убедитесь, что имя не содержит пробелов или ограниченных символов, как объясняется в правилах и ограничениях на имена.
• Если в процессе развертывания возникнет проблема с именами, в журнале Ошибок появится следующая ошибка

  Значение параметра disk.name недействительно. (Код: InvalidParameter, Цель: disk.name)

Проверка Конфигурации DNS Azure

• Убедитесь, что стандартный DNS Azure настроен как для VNET, так и для связанных NIC. Если стандартный DNS не настроен в Azure как для VNET, так и для NIC, создание Ролей не удастся.
• Чтобы узнать, какая конфигурация DNS Azure, см. Исправление проблем с конфигурацией DNS 

Проверка Разрешений Azure

• Чтобы скрипт HA выполнялся успешно, убедитесь, что пользователь Azure имеет разрешения владельца. Перейдите в Группа ресурсов > Контроль доступа IAM > Посмотреть мой доступ и убедитесь, что аккаунт пользователя настроен как Владелец или выше. См. Встроенные роли Azure.
  
  
  

Проверка назначения роли Azure 

• Пройдите шаги, предоставленные в Проверка назначения ролей Azure , чтобы подтвердить, что роль идентификации, указанная в группе ресурсов, назначена на ЛВС NIC, ЛВС подсеть и обе виртуальные машины vSocket.

Повторное выполнение скрипта HA

• В крайнем случае скрипт HA (create_ha_settings) можно повторно выполнить после проверки предыдущих шагов.
• Убедитесь, что вы обновили токен Azure и удалите управляемую Azure идентификацию, если она была создана во время первого выполнения скрипта.

Диагностика отказа переключения HA

Если скрипт HA успешно выполняется, но переключение vSocket HA не происходит по ожиданиям (например, трафик не маршрутизируется на вторичный vSocket), выполните следующие шаги:

Запуск теста HA API

• Из Веб-интерфейса vSocket выполните инструмент тестирования API из обоих vSockets, что подтверждает, что вызов API в Azure может быть выполнен успешно. Здесь можно увидеть любые ошибки с разрешениями или назначения плавающего IP.
  

Проверка журнала активности

• В Azure Журналы активности хранят все события, которые произошли внутри каждого ресурса Azure. Просмотрите эти журналы, чтобы определить, не удалось ли плавающий IP быть направленным на LAN NIC или тест API был неуспешным. Перейдите в NIC и выберите журнал активности
  

Пинг плавающего IP

• Из веб-интерфейса vSocket, используйте инструмент Ping, выберите интерфейс ЛВС и пингуйте адрес плавающего IP. Если этот тест не удался, продолжите Проверка назначения плавающего IP
  

Проверка назначения плавающего IP

• Чтобы маршрутизировать трафик на основной vSocket, Azure назначает плавающий IP на ЛВС NIC текущего основного vSocket. Перейдите в основную VM vSocket LAN NIC > IP конфигурация  и проверьте, что плавающий IP существует как "Вторичный". Если нет, продолжайте следующими шагами.

Проверка назначения ролей Azure 

• Во время развертывания Azure vSocket создается и сохраняется в Azure Идентификационная роль для HA.
• Только одна пользовательская роль должна быть назначена каждому ресурсу. Если политика добавляет системные идентификации в Azure, vSocket должен быть исключен из неё.

• Эта роль назначена различным виртуальным ресурсам, подключенным к vSocket. Компоненты в инфраструктуре Azure, которые используют эту роль, включают:

  • LAN сетевой интерфейс (NIC) для каждого vSocket
  • LAN подсеть, связанная с LAN сетевыми интерфейсами
  • Обе vSocket ВМ
• Назначение ролей для NIC можно проверить в Контроль доступа > Назначения ролей и должна быть назначена как для основного, так и для вторичного LAN NIC.
  
• Назначение ролей для ЛВС подсети можно проверить в VNET > Подсеть, затем выберите ЛВС подсеть и нажмите Управление пользователями > Назначение ролей.
  
• Для каждой виртуальной машины vSocket роль идентификации можно проверить в Безопасность > Идентификация > Назначено пользователем, как показано на скриншоте ниже. Никакая системная роль не должна быть назначена на ВМ.
• Если роль HA идентификации отсутствует на любом из вышеуказанных ресурсов, возможно, процесс развертывания не смог её установить. Вы можете выполнить скрипт HA Cato еще раз, если роль отсутствует в любом из вовлеченных ресурсов. Или же, вторичный Azure vSocket может быть повторно развернут, что установит отсутствующие роли идентификации HA.

Проверка, что интерфейс управления имеет доступ к DNS и Интернету

• Убедитесь, что интерфейс управления имеет доступ к Интернету и может подключаться к настроенному DNS-серверу.

• Проверьте разрешение DNS для management.azure.com из портала Azure. Вызов HA API использует это полное доменное имя (FQDN).

  • Перейдите к Виртуальная машина > vSocket > Выполнить команду > RunShellScript
  • Введите dig management.azure.com в текстовое поле
  • Нажмите Выполнить
• Вывод dig будет отображён в портале с ответом DNS.
  
  
• Если разрешение DNS отсутствует, см. Исправление проблем конфигурации DNS.
• С той же страницы попробуйте добраться до любого интернет ресурса, чтобы подтвердить доступ к интернету. Например, ping -c 4 8.8.8.8. Если ping не удался, продолжайте с следующими шагами.
  

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

• Быстрый способ проверки - перейти к сетевому интерфейсу MGMT в Azure и нажать "Эффективные правила безопасности" в нижнем левом углу экрана.
• На приведенном ниже снимке экрана показано, что ни один NSG не назначен, поэтому исходящий трафик не блокируется.

Проверьте маршрутизацию интерфейса MGMT для интернет-трафика.

• Если канал MGMT направлен через сторонний файервол в Azure, убедитесь, что соединения UDP/53 и TCP/443 исходящих разрешены.
• Таблица маршрутизации может быть просмотрена на странице интерфейса управления в Azure, щелкнув опцию "Эффективные маршруты".
• На приведенном ниже снимке экрана показан маршрут интернет-трафика с использованием Интернета как "Следующий переход, тип". Таким образом, файервол не блокирует трафик.
  

Проверка следующего перехода в таблице маршрутизации

• Подтвердите, что таблица маршрутизации ЛВС указывает на Плавающий IP. Измените следующий IP-адрес перехода при необходимости.

Устранение неполадок состояния HA не готово

Если CMA показывает, что статус HA не готов, а оба vSocket работают, оба vSocket будут принимать на себя роль Основного (сценарий расщепленного мозга). Может быть две связанные проблемы:

• Оба vSocket работают на разных версиях прошивки
• Сообщения HA Keepalive не достигают вторичного vSocket

Рекомендуется проверить страницы WebUI обоих vSocket, чтобы подтвердить статус HA каждого из них. Сценарий расщепленного мозга проявляется, если как основной, так и вторичный vSocket находятся в роли Главного. WebUI покажет текущую роль вверху главной страницы Мониторинг.

Проверка версий прошивки

Чтобы соответствовать критериям совместимой версии, оба vSocket должны работать на одной и той же основной версии, например, v17.xx.yy или v18.xx.yy. vSocket выполняют начальное обновление после первого развертывания. Если один из vSocket не обновляется, эта проблема должна быть устранена. Отправьте Тикет поддержки для сообщения об этой проблеме.

Проверка HA Keepalives

Пакеты Keepalive используют порт UDP/20480 для Azure vSocket и будут отправляться только от Главного vSocket к vSocket в резерве. Условие расщепленного мозга возникает, когда оба vSocket имеют роль Главного, что может произойти из-за проблем подключения к ЛВС между vSocket, вследствие чего сообщения поддержания активного соединения HA не доходят до вторичного vSocket. 

Выполните следующие проверки, чтобы подтвердить соединение ЛВС:

• Проверьте, блокирует ли группа безопасности сети порт UDP/20480. Быстрый способ проверить Правила NSG — открыть каждый LAN сетевой интерфейс в Azure и нажать "Эффективные Правила Безопасности" внизу слева экрана.
• Подтвердите, что оба LAN интерфейса связаны с одной и той же LAN подсетью.
• Запустите захват пакетов из WebUI обоих vSocket и убедитесь, что сигналы keepalives, отправленные основным, получены вторичным vSocket.

Решение обнаруженных проблем

Обновление токена Azure

• Если для развертывания скрипта HA используется Azure Cloud Shell, откройте новую сессию и повторно аутентифицируйтесь. Это обновит токен, используемый для запроса API.
  

Исправление проблем с конфигурацией DNS

• Чтобы исправить Конфигурация Azure DNS и установить её на Значение по умолчанию, перейдите в Виртуальная Сеть > DNS Серверы и Сетевой Интерфейс > DNS Серверы, и убедитесь, что используется опция По умолчанию или общественный DNS Сервер. Выключите VM для внесения любых изменений, связанных с DNS, затем включите её снова.
  
  

Отмена регистрации и повторное развертывание Azure vSocket

• Если после выполнения всех вышеуказанных шагов по устранению неполадок скрипт HA или переход на резервный узел HA продолжает терпеть неудачу, возможно, следует отменить регистрацию и повторно развернуть один или оба vSocket. См. Повторное развертывание площадок vSocket высокой доступности
• Важно следовать инструкциям и удалить Виртуальную машину, сетевые интерфейсы, связанные публичные IP-адреса и Управляемую идентичность перед повторным развертыванием vSocket.
• Если развертывается только основная инстанция vSocket, необходимо запустить посвященный скрипт HA (create_ha_settings) для связывания обеих инстанций vSocket для HA.

Создание обращений в Поддержку Cato

Отправьте тикет поддержки с результатами вышеперечисленных шагов по устранению неполадок. Пожалуйста, включите следующую информацию в тикет:

• Чёткое описание проблемы, включая любые сообщения об ошибках.
• Результаты теста DNS для management.azure.com
• Результаты API тестов.
• Скриншоты назначенного плавающего IP, настроенной роли идентификации, эффективных маршрутов и эффективных правил безопасности.
• Скриншоты журнала активности Azure, включая любые обнаруженные ошибки.