Устранение неполадок с производительностью сети

Сводка

Azure обеспечивает стабильный и быстрый способ подключения локальной сети к Azure. Клиенты всех размеров используют такие методы, как VPN типа "сеть — сеть" и ExpressRoute для запуска своих предприятий в Azure. Но что происходит, когда производительность не соответствует вашим ожиданиям или предыдущему опыту? Эта статья поможет стандартизировать подход к тестированию и определению базового уровня вашей конкретной среды.

Вы узнаете, как легко и последовательно протестировать задержку сети и пропускную способность между двумя узлами. Вы также получаете советы о способах просмотра Azure сети, чтобы помочь изолировать точки проблем. Для скрипта и средств PowerShell, рассмотренных, требуется два узла в сети (в любом конце проверяемой ссылки). Один узел должен работать под управлением Windows Server или настольной версии Windows, а другой узел может работать под управлением Windows или Linux.

Сетевые компоненты

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

На самом высоком уровне существует три основных домена маршрутизации сети:

• Сеть Azure (синее облако)
• Интернет или глобальная сеть (зеленое облако)
• Корпоративная сеть (оранжевый облако)

Рассмотрим схему справа налево, кратко обсудим каждый компонент:

• Виртуальная машина — сервер может иметь несколько сетевых адаптеров. Убедитесь, что все статические маршруты, маршруты по умолчанию и параметры операционной системы отправляют и получают трафик таким образом, который вы ожидаете. Кроме того, каждый номер SKU виртуальной машины имеет ограничение пропускной способности. Если вы используете меньший номер SKU виртуальной машины, трафик ограничен пропускной способностью, доступной сетевой адаптеру. Используйте DS5v2 для тестирования, чтобы обеспечить достаточную пропускную способность на виртуальной машине.

• NIC — Убедитесь, что вы знаете частный IP-адрес, назначенный соответствующему NIC.

• NIC NSG — на уровне NIC могут применяться отдельные NSG. Убедитесь, что набор правил NSG подходит для трафика, который вы пытаетесь передать. Например, убедитесь, что порты 5201 для iPerf, 3389 для RDP или 22 для SSH открыты, чтобы разрешить прохождение тестового трафика.

• Подсеть виртуальной сети — сетевой адаптер назначается определенной подсети. Убедитесь, что вы знаете, какой из них и какие правила связаны с этой подсетью.

• NSG на уровне подсети — как и для NIC, группы безопасности сети можно применять и на уровне подсети. Убедитесь, что набор правил NSG подходит для трафика, который вы пытаетесь передать. Для входящего трафика к сетевому адаптеру сначала применяется группа безопасности подсети, а затем NSG сетевого адаптера. Когда трафик выходит из виртуальной машины, сначала применяется NSG сетевого интерфейса, а затем NSG подсети.

• UDR подсети — маршруты, определяемые пользователем, могут направлять трафик через промежуточный узел, например брандмауэр или балансировщик нагрузки. Убедитесь, что для вашего трафика установлен маршрут UDR. Если да, понять, куда он идет, и то, что следующий прыжок делает с вашим трафиком. Например, брандмауэр может передать некоторый трафик и запретить другой трафик между двумя узлами.

• Подсеть шлюза / NSG / UDR — так же, как и подсеть виртуальной машины, подсеть шлюза может иметь группы безопасности сети и определяемые пользователем маршруты. Убедитесь, что вы знаете, есть ли они там и какие последствия они имеют на ваш трафик.

• Шлюз виртуальной сети (ExpressRoute) — после включения пиринга (ExpressRoute) или VPN существует не так много параметров, которые могут повлиять на то, как именно или будет ли маршрутизироваться трафик. Если у вас есть шлюз виртуальной сети, подключенный к нескольким каналам ExpressRoute или VPN-туннелям, следует учитывать параметры веса подключения. Вес соединения влияет на предпочтение подключения и определяет маршрут, которым будет идти ваш трафик.

• Route Filter (Не отображается) — фильтр маршрутов необходим при использовании пиринга Microsoft через ExpressRoute. Если вы не получаете маршруты, проверьте, настроен ли фильтр маршрутов и применен к каналу правильно.

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

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

Учитывая сложность этих трех разных высокоуровневых сетевых сред, часто оптимально начать на краях и попытаться показать, где производительность хороша и где она снижается. Этот подход может помочь определить проблемную область маршрутизации среди трех. Затем вы можете сосредоточиться на устранении неполадок в этой конкретной среде.

Инструменты

Вы можете анализировать и локализовать большинство проблем в сети с помощью базовых инструментов, таких как ping и traceroute. Редко возникает необходимость углубляться до анализа пакетов с использованием таких инструментов, как Wireshark.

Чтобы помочь в устранении неполадок, был разработан набор средств подключения Azure (AzureCT), чтобы поместить некоторые из этих средств в простой пакет. Для тестирования производительности средства, такие как iPerf и PSPing, могут предоставлять сведения о вашей сети. iPerf — это часто используемое средство для базовых тестов производительности и довольно простое использование. PSPing — это ping утилита, разработанная SysInternals. PSPing может делать ICMP и TCP пинг, чтобы достигать удаленного узла. Оба этих средства являются упрощенными и "установлены" просто путем копирования файлов в каталог на узле.

Вы можете использовать модуль PowerShell (AzureCT), который упаковывает эти средства и методы.

AzureCT — набор средств подключения Azure

Модуль AzureCT PowerShell включает два компонента: Availability Testing и Performance Testing. Эта статья посвящена тестированию производительности, в частности двум командам Link Performance в этом модуле PowerShell.

Чтобы использовать этот набор средств для тестирования производительности, выполните следующие три основных действия.

1. Установка модуля PowerShell

   (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
   

   Эта команда загружает и устанавливает модуль PowerShell локально.

2. Установка вспомогательных приложений

   Install-LinkPerformance
   

   Эта команда AzureCT устанавливает iPerf и PSPing в новом каталоге C:\ACTTools и открывает порты брандмауэра Windows для разрешения трафика ICMP и порта 5201 (iPerf).

3. Запуск теста производительности

   Сначала на удаленном узле установите и запустите iPerf в режиме сервера. Убедитесь, что удаленный узел прослушивает порт 3389 (RDP для Windows) или 22 (SSH для Linux) и разрешает трафик на порту 5201 для iPerf. Если удаленный узел работает под управлением Windows, установите AzureCT и выполните команду Install-LinkPerformance, чтобы установить и настроить iPerf и необходимые правила брандмауэра.

   Когда удаленный компьютер готов, откройте PowerShell на локальном компьютере и запустите тест:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

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

4. Просмотр выходных данных теста

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

   

   Подробные результаты всех тестов iPerf и PSPing сохраняются в отдельных текстовых файлах в каталоге C:\ACTToolsсредств AzureCT.

Устранение проблем с производительностью

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

1. Вызов предположений

   Убедитесь, что ваши ожидания разумны. Например, с каналом ExpressRoute 1 Гбит/с и 100 мс задержки, ожидать полного использования 1 Гбит/с трафика нереалистично из-за характеристик работы TCP на каналах с высокой задержкой. Дополнительные сведения о предположениях о производительности см. в разделе "Ссылки".

2. Начните с границы сети

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

3. Создание схемы

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

4. Разделение и завоевание

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

5. Рассмотрите все слои OSI

   Хотя обычно основное внимание уделяется сети и уровням 1-3 (физические, данные и сетевые слои), помните, что проблемы могут возникать на уровне 7 (уровень приложения). Оставайтесь открытыми и проверяйте все предположения.

Продвинутое устранение неполадок ExpressRoute

Изоляция Azure компонентов может быть сложной, если вы не уверены, где находится край облака. При использовании ExpressRoute сетевой компонент Microsoft Enterprise Edge (MSEE) выступает в качестве периферии. MSEE — это первая точка контакта в сети Microsoft и последняя точка перехода при выходе из нее. При создании подключения между шлюзом виртуальной сети и каналом ExpressRoute вы подключаетесь к MSEE. Распознавание MSEE как первого или последнего узла имеет решающее значение для изоляции проблемы в сети Azure. Знание направления трафика помогает определить, находится ли проблема в Azure или далее внизу в глобальной сети или корпоративной сети.

Если две виртуальные сети подключены к тому же каналу ExpressRoute, можно выполнить тесты для изоляции проблемы в Azure.

План тестирования

1. Запустите тест Get-LinkPerformance между VM1 и VM2. Этот тест содержит сведения о том, является ли проблема локальной. Если тест создает допустимые результаты задержки и пропускной способности, можно пометить локальную виртуальную сеть как хорошую.

2. Предположим, что трафик локальной виртуальной сети хорош, выполните тест Get-LinkPerformance между VM1 и VM3. Этот тест проверяет соединение через сеть Microsoft до MSEE и обратно в Azure. Если тест создает допустимые результаты задержки и пропускной способности, можно пометить Azure сеть как хорошую.

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

Проблема изолирована, что делать дальше?

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

Для проблем с корпоративной сетью внутренний ИТ-отдел или поставщик услуг может помочь в настройке устройства или ремонте оборудования.

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

После того как вы изолируете проблему Azure в максимально подробном виде, просмотрите Сетевую документацию Azure и при необходимости откройте запрос в службу поддержки.

Ссылки

Ожидания задержки и пропускной способности

Например, вы настроили ExpressRoute в Сиэтле, Штат Вашингтон, США. В таблице ниже показаны задержка и пропускная способность, наблюдаемые при тестировании соединения с различными центрами обработки данных Azure, а также оценочные расстояния.

Настройка теста:

• Физический сервер под управлением Windows Server 2016 с сетевым адаптером 10 Гбит/с, подключенным к каналу ExpressRoute.

• Контур ExpressRoute со скоростью 10 Гбит/с с включенным режимом частного пиринга.

• Виртуальная сеть Azure с шлюзом UltraPerformance в указанном регионе.

• Виртуальная машина DS5v2 под управлением Windows Server 2016 в виртуальной сети, используя образ Azure по умолчанию с установленным AzureCT.

• Во всех тестах используется команда AzureCT Get-LinkPerformance с 5-минутным нагрузочным тестом для каждого из шести тестовых прогонов. Рассмотрим пример.

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Поток данных для каждого теста выполняется с локального сервера (клиента iPerf в Сиэтле) на виртуальную машину Azure (сервер iPerf в указанном регионе Azure).

• В столбце "Задержка" отображаются данные из ненагрузочного теста (тест задержки TCP без запуска iPerf).

• В столбце "Максимальная пропускная способность" отображаются данные из нагрузочного теста 16 TCP-потоков с размером окна размером 1 МБ.

Результаты задержки и пропускной способности

* Задержка до Бразилии — это пример, в котором укладка оптоволоконного кабеля значительно отличается от расстояния по прямой. Ожидаемая задержка составляет около 160 мс, но на самом деле это 189 мс из-за более длинного маршрута волокна.

Дальнейшие шаги

• Скачайте набор средств Azure Connectivity Toolkit
• Следуйте инструкциям по тестированию производительности соединения