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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Фильтр маршрутов (не показан). Фильтр маршрутов необходим при использовании пиринга Майкрософт через ExpressRoute. Если вы не получаете никакие маршруты, проверьте, правильно ли настроен фильтр маршрутов и применен ли он к каналу.

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

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

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

Инструменты

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

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

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

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

Модуль AzureCT PowerShell включает два компонента: тестирование доступности и тестирование производительности. В этом документе основное внимание уделяется тестированию производительности, в частности двум командам производительности ссылок в этом модуле 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 (протокол удаленного рабочего стола для 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.

Устранение неполадок

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Расширенное устранение проблем с ExpressRoute

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

Примечание.

MSEE не в облаке Azure. ExpressRoute находится на границе сети Майкрософт, а не в Azure. После подключения к ExpressRoute к MSEE вы подключаетесь к сети Майкрософт, позволяя получать доступ к облачным службам, таким как Microsoft 365 (с пирингом Майкрософт) или Azure (с частным и /или microsoft пирингом).

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

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

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

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

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

Внимание

Для каждого теста пометьте время дня и запишите результаты в общем расположении. Каждый тестовый запуск должен иметь одинаковые выходные данные для согласованного сравнения данных. Согласованность в нескольких тестах является основной причиной использования AzureCT для устранения неполадок. Ключ получает согласованные тестовые и выходные данные каждый раз. Запись времени и наличие согласованных данных особенно полезно, если проблема неразрывна. Будьте внимательны с сбором данных заранее, чтобы избежать повторения одних и тех же сценариев.

Область возникновения проблемы обнаружена, что делать дальше?

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

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

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

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

Ссылки

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

Совет

Географическое расстояние между конечными точками является самым большим фактором задержки. Хотя задержка оборудования (физические и виртуальные компоненты, количество прыжков и т. д.) также играет роль, расстояние от выполнения волокна, а не расстояние прямой линии, является основным участником. Это расстояние трудно измерять точно, поэтому мы часто используем калькулятор расстояния города для грубой оценки.

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

Настройка тестирования:

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

• Канал ExpressRoute со скоростью 10 Гбит/с включенной частной пиринговой связью.

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

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

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

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

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

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

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

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

Внимание

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

Расположение ExpressRoute	Регион Azure	Предполагаемое расстояние (км)	Задержка	Пропускная способность сеанса 1	Максимальная пропускная способность
Seattle	западная часть США 2	191 км	5 мс	262 Мбит/с	3,74 Гбит/с
Seattle	западная часть США	1,094 км	18 мс	82,3 Мбит/с	3,70 Гбит/с
Seattle	Центральная часть США	2,357 км	40 мс	38,8 Мбит/с	2,55 Гбит/с
Seattle	Центрально-южная часть США	2,877 км	51 мс	30,6 Мбит/с	2,49 Гбит/с
Seattle	Центрально-северная часть США	2,792 км	55 мс	27,7 Мбит/с	2,19 Гбит/с
Seattle	Восточная часть США 2	3,769 км	73 мс	21,3 Мбит/с	1,79 Гбит/с
Seattle	Восточная часть США	3,699 км	74 мс	21,1 Мбит/с	1,78 Гбит/с
Seattle	Восточная Япония	7,705 км	106 мс	14,6 Мбит/с	1,22 Гбит/с
Seattle	южная часть Соединенного Королевства	7,708 км	146 мс	10,6 Мбит/с	896 Мбит/с
Seattle	Западная Европа	7,834 км	153 мс	10,2 Мбит/с	761 Мбит/с
Seattle	Восточная Австралия	12,484 км	165 мс	9,4 Мбит/с	794 Мбит/с
Seattle	Юго-Восточная Азия	12,989 км	170 мс	9,2 Мбит/с	756 Мбит/с
Seattle	Южная Бразилия*	10,930 км	189 мс	8,2 Мбит/с	699 Мбит/с
Seattle	Индия (юг)	12,918 км	202 мс	7,7 Мбит/с	634 Мбит/с

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

Примечание.

Эти числа были протестированы с помощью AzureCT на основе iPerf в Windows с помощью PowerShell. IPerf не учитывает параметры TCP Windows по умолчанию для коэффициента масштабирования и использует меньшее число сдвигов для размера окна TCP. Настраивая команды iPerf с помощью коммутатора -w и размера окна TCP, можно добиться лучшей пропускной способности. Запуск iPerf в многопотоковом режиме с нескольких компьютеров также может помочь достичь максимальной производительности связи. Чтобы получить лучшие результаты iPerf в Windows, используйте set-NetTCPSetting -AutoTuningLevelLocal Experimental. Прежде чем вносить изменения, проверьте политики организации.

Следующие шаги

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