Упражнение. Выявление и разрешение неполадок входящих сетевых подключений

Завершено

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

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

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

  1. В Azure Cloud Shell задайте имя группы ресурсов.

    export RESOURCEGROUP=learn-ts-loadbalancer-rg
    
  2. Перейдите в папку src/scripts.

    cd ~/load-balancer/src/scripts
    
  3. Выполните приведенную ниже команду, чтобы перенастроить подсистему балансировки нагрузки, сеть и виртуальные машины. Этот скрипт представляет некоторые проблемы, которые будут диагностироваться и исправляться.

    bash reconfigure.sh
    
  4. Чтобы перейти в папку src/stresstest, выполните следующие команды.

    cd ~/load-balancer/src/stresstest
    
  5. Снова запустите нагрузочный тест, заменив <ip address> IP-адресом подсистемы балансировки нагрузки. Если вы не можете вспомнить этот адрес, запустите сценарий src/scripts/findip.sh повторно.

    dotnet run <ip address>
    

    На этот раз приложение не будет генерировать никаких результатов и в конечном итоге может завершиться с сообщением "Ошибка при отправке запроса в подсистему балансировки нагрузки. Операция была отменена". Нажмите клавишу Ввод, чтобы остановить работу приложения.

  6. На портале Azure последовательно выберите элементы Панель мониторинга>dashboard-learn-ts-loadbalancer.

  7. Изучите панель мониторинга, где отображаются метрики состояния пробы работоспособности и доступности пути к данным. Может потребоваться изменить диапазон времени на последние 30 минут. Он должен выглядеть, как на следующей диаграмме, при этом обе метрики сбрасываются в ноль.

    Screenshot that shows the health probe status and data path availability is in an unhealthy state.

    На этой диаграмме показано, что виртуальные машины не отвечают на запросы пробы работоспособности от подсистемы балансировки нагрузки. Поэтому они были помечены как неработоспособные. Между клиентом и приложением, запущенным на этих виртуальных машинах, нет доступного пути к данным.

Диагностика и исправление неполадок

Прежде всего, необходимо проверить, запущены ли виртуальные машины. Давайте разрешим проблемы на каждой виртуальной машине по очереди. Сначала давайте рассмотрим appretailvm1. appretailvm2 вы проверите позже.

Тестирование виртуальной машины appretailvm1

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

  1. Вернитесь в Cloud Shell.

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

    bash ~/load-balancer/src/scripts/jumpboxip.sh
    
  3. Выполните приведенную ниже команду, чтобы получить пароль, созданный при запуске сценария начальной настройки. Скопируйте этот пароль для следующего шага.

    cd ~/load-balancer/src/scripts
    cat passwd.txt
    
  4. Войдите в поле перехода с IP-адресом и паролем из предыдущих выходных данных команды. Замените azureuser, если вы использовали другое имя пользователя.

    ssh azureuser@<jump box ip address>
    
  5. На перенаправителе выполните следующую команду, чтобы проверить, запущена ли виртуальная машина retailappvm1.

    ping retailappvm1 -c 10
    

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

  6. Выполните следующую команду, чтобы отправить запрос HTTP GET на виртуальную машину retailappvm1.

    curl -v http://retailappvm1
    

    Опять же, эта команда должна выполняться успешно.

Проверка проб работоспособности и правил маршрутизации

Виртуальная машина retailappvm1 запущено, и на ней выполняется приложение. Между подсистемой балансировки нагрузки и виртуальными машинами во внутреннем пуле возникла проблема.

  1. На портале Azure найдите Monitor.

  2. На странице Monitor — обзор выберите Работоспособность службы.

    Screenshot that shows Service Health option selected from the left-hand side menu.

  3. Выберите элемент Работоспособность ресурсов.

  4. В поле Тип ресурса выберите Подсистема балансировки нагрузки. В списке ресурсов выберите retailapplb.

    Screenshot of the Service Health - Resource health page that shows the retailapplb selected.

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

  6. В разделе Журнал работоспособности разверните самое верхнее событие и ознакомьтесь с рекомендуемыми действиями. Эти действия предполагают проверку конечных точек виртуального IP-адреса (правило маршрутизации) и выделенного IP-адреса (проба работоспособности) в подсистеме балансировки нагрузки.

    Screenshot of the Resource health page that shows health history including date, number of health events, status, description, and recommended steps.

  7. Перейдите к группе ресурсов learn-ts-loadbalancer-rg и выберите retailapplb.

  8. Выберите Правила балансировки нагрузки>retailapprule. Это правило получает трафик TCP через порт 80 внешнего IP-адреса и отправляет его на порт 80 на выбранной виртуальной машине во внутреннем пуле. Эта конфигурация кажется правильной, хотя порт, используемый пробой работоспособности, выглядит подозрительно. В настоящее время задан порт 85.

    Screenshot of the **retailapprule** page that shows the health probe is using port 85.

  9. Закройте страницу retailapprule.

  10. Выберите Зонды работоспособности>retailapphealthprobe.

  11. Измените Порт с 85 обратно на 80 и выберите Сохранить.

    Screenshot of the **retailapphealthprobe** page that shows the port number updated to 80.

  12. Подождите несколько минут.

  13. Выберите Панель мониторинга в левом меню портала Azure.

  14. На панели мониторинга выберите диаграмму, показывающую метрики состояния пробы работоспособности и доступности пути к данным. Метрика Data Path Availability (Доступность пути к данным) должна увеличиться до 100, но метрика Health Probe Status (Состояние пробы работоспособности) будет колебаться около 50. Теперь из подсистемы балансировки нагрузки доступен путь, по меньшей мере, к одной виртуальной машине, но только 50 % виртуальных машин отображаются как работоспособные.

    Screenshot of the Health Probe Status and Data Path Availability chart where the Data Path Availability is at 100 but Health Probe Status hovers around 50.

    Выберите диаграмму для перехода на страницу метрик для Load Balancer. Эта страница позволяет обновить диаграмму и увеличить определенный период времени.

  15. В Cloud Shell введите указанную ниже команду, чтобы покинуть перенаправитель.

    exit
    
  16. Снова запустите приложение нагрузочного теста, используя IP-адрес подсистемы балансировки нагрузки.

    cd ~/load-balancer/src/stresstest
    dotnet run <ip address>
    

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

Проверка правил NSG для подсети

Проблема может быть вызвана правилом безопасности сети, блокирующим внешний трафик.

  1. На портале Azure перейдите к группе ресурсов learn-ts-loadbalancer-rg.

  2. Выберите группу безопасности сети retailappnsg. Эта группа безопасности определяет, какой трафик разрешено передавать через виртуальную сеть.

  3. Выберите Правила безопасности для входящего трафика. Хотя существует правило, которое разрешает входящий трафик из подсистемы балансировки нагрузки, работающей в виртуальной сети, нет правила, разрешающего трафик, исходящий извне виртуальной сети через порт 80.

  4. Выберите Добавить. Откроется панель Добавление правила безопасности для входящего трафика.

  5. Введите следующие параметры, а затем выберите Добавить.

    Свойство Значение
    Оригинал Любое
    Диапазоны исходных портов *
    Назначение Любые
    Сервис Пользовательская
    Диапазоны портов назначения 80
    Протокол TCP
    Действие Allow
    Приоритет 100
    Имя. Port_80
    Description Порт HTTP
  6. В Cloud Shell снова запустите приложение нагрузочного теста, используя IP-адрес подсистемы балансировки нагрузки.

    cd ~/load-balancer/src/stresstest
    dotnet run <ip address>
    

    Теперь приложение выполняется, но вы получаете только ответ от виртуальной машины retailappvm1. Дайте приложению поработать в течение двух-трех минут. Нажмите клавишу ВВОД, чтобы остановить приложение.

  7. На портале Azure перейдите на панель мониторинга.

  8. Выберите диаграмму для метрики среднего числа пакетов. Обратите внимание на пиковое значение для последнего запуска приложения нагрузочного теста. Это значение должно быть, по меньшей мере, в два раза больше значения, зарегистрированного ранее, когда были доступны обе виртуальные машины. Хотя теперь вы получили функционирующую систему, существует опасность перегрузки рабочей виртуальной машины.

Тестирование виртуальной машины appretailvm2

Похоже, что виртуальная машина appretailvm2 может обрабатывать запросы неправильно. Необходимо проверить, работает ли эта виртуальная машина, а также может ли Load Balancer подключиться к ней.

  1. В Cloud Shell войдите в поле перехода с IP-адресом и паролем из предыдущих выходных данных команды.

    ssh azureuser@<jump box ip address>
    
  2. Попробуйте проверить связь с виртуальной машиной appretailvm2.

    ping retailappvm2 -c 10
    

    Виртуальная машина не отвечает, а команда проверки связи сообщает о 100 процентах потерь пакетов. Виртуальная машина retailappvm2 не запущена, либо возникла проблема с сетью.

  3. На портале Azure перейдите к группе ресурсов learn-ts-loadbalancer-rg.

  4. Выберите виртуальную машину retailappvm2.

  5. На странице Обзор показано, что виртуальная машина остановлена. Выберите Запустить и дождитесь начала работы машины.

    Screenshot that shows the Overview page for the *retailappvm2* virtual machine with the start button highlighted.

  6. Вернитесь в службу Cloud Shell, подключенную к перенаправителю, и повторно выполните команду проверки связи.

    ping retailappvm2 -c 10
    

    На этот раз операции проверки связи должны выполняться успешно.

  7. Проверьте, отвечает ли приложение, выполняемое на виртуальной машине retailappvm2.

    wget retailappvm2
    

    Эта команда истекает. Либо приложение не запущено, либо может возникнуть проблема с сетью. Чтобы остановить выполнение команды, нажмите клавиши CTRL+C.

  8. В перенаправителе войдите на виртуальную машину retailappvm2. При появлении запроса введите указанный ранее пароль.

    ssh azureuser@retailappvm2
    
  9. Выполните следующую команду, чтобы протестировать приложение на этой виртуальной машине.

    wget retailappvm2
    

    Команда должна быть выполнена успешно и создать файл index.html с ответом.

  10. Изучите этот файл index.html.

    cat index.html
    

    Файл должен содержать сообщение retailappvm2 и показывать, что эта виртуальная машина ответила ожидаемым образом.

  11. Закройте подключение к виртуальной машине retailappvm2.

    exit
    
  12. Закройте подключение к перенаправителю.

    exit
    

    Виртуальная машина retailappvm2 работает, приложение запущено, но вы не можете подключиться к приложению извне виртуальной машины. Эта проблема указывает на проблему с сетью.

  13. На портале Azure перейдите к группе ресурсов learn-ts-loadbalancer-rg.

  14. Выберите группу безопасности сети retailappnicvm2nsg.

  15. Выберите Правила безопасности для входящего трафика.

    Группа безопасности сети имеет правило для входящего трафика, которое блокирует весь внешний трафик, использующий протокол TCP. Номер приоритета у этого правила ниже, чем у правила, которое открывает порт 80, поэтому оно является более приоритетным.

    Screenshot that shows the inbound security rules for the NSG.

  16. Выберите правило retailappvnetnsgrulevm2denyall, измените приоритет на 300, а затем выберите Сохранить.

    Screenshot showing the edit page for the inbound rule.

  17. Подождите два минуты и перейдите на панель мониторинга.

  18. Выберите диаграмму, показывающую метрику Health Probe Status (Состояние пробы работоспособности). Значение этой метрики должно увеличиться до 100. Может потребоваться несколько раз обновить диаграмму.

    Screenshot showing the Health Probe Status for the load balancer.

  19. Переключитесь в Cloud Shell и снова запустите приложение нагрузочного теста, используя IP-адрес подсистемы балансировки нагрузки.

    cd ~/load-balancer/src/stresstest
    dotnet run <ip address>
    

    Теперь вы должны увидеть сообщения из retailappvm1 и retailappvm2. Полное подключение к системе восстановлено.

  20. Чтобы остановить приложение, нажмите клавишу ВВОД.

Итоги

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

  • В правиле retailapprule подсистемы балансировки нагрузки был неправильно настроен порт, используемый пробой работоспособности (85 вместо 80). Вы изменили правило для использования порта 80.
  • Группа безопасности сети retailappnsg не имеет правила безопасности для входящего трафика, разрешающего трафик через порт 80. Поэтому группа безопасности сети блокировала пробу работоспособности. Вы добавили правило безопасности для входящего трафика, разрешающее трафик через порт 80.
  • Вы проверили виртуальную машину retailappvm2 и определили, что она остановлена. Вы перезапустите эту виртуальную машину.
  • Затем вы запустили виртуальную машину retailappvm2 и увидели, что приложение выполняется, но не смогли подключиться к нему. Группа безопасности сети имела правило для входящего трафика, блокировавшее весь сетевой трафик для протокола TCP. Это правило "Запретить все" имело приоритет над правилом безопасности для входящего трафика, разрешавшим трафик через порт 80. Вы изменили приоритет правила "Запретить все", чтобы он был выше, чем для правила порта 80. Это изменение разрешило входящий сетевой трафик через порт 80 по протоколу TCP.

Вы вернули службу HTTP с балансировкой нагрузки в полностью работоспособное состояние.