Устранение проблем с производительностью сети
Обзор
Azure обеспечивает стабильный и быстрый способ подключения локальной сети к Azure. Небольшие и крупные компании успешно используют такие методы, как VPN-подключение "сеть — сеть" и ExpressRoute, для ведения бизнеса в Azure. Но что происходит, когда производительность не соответствует вашим ожиданиям или прежним показателям? Эта статья поможет стандартизировать методы тестирования и настроить базовые показатели конкретной среды.
Вы узнаете, как легко и последовательно протестировать задержку сети и пропускную способность между двумя узлами. Кроме того, вам предоставят некоторые советы по способам просмотра сети Azure для изоляции проблемных точек. Для рассматриваемых скрипта PowerShell и средств требуется наличие двух узлов в сети (на обоих концах тестируемого соединения). Один узел должен быть Windows Server или рабочим столом, другой может быть Windows или Linux.
Сетевые компоненты
Прежде чем углубиться в устранение неполадок, рассмотрим некоторые общие понятия и компоненты. Мы упомянем каждый компонент в сквозной цепочке, которая обеспечивает возможность подключения в Azure.
На самом высоком уровне существует три основных домена маршрутизации сети:
- Сеть Azure (синее облако)
- Интернет или глобальная сеть (зеленое облако)
- Корпоративная сеть (оранжевый облако)
Кратко рассмотрим каждый компонент на схеме, идя справа налево.
Виртуальная машина — сервер может иметь несколько сетевых адаптеров. Убедитесь, что статические маршруты, маршруты по умолчанию и параметры операционной системы отправляют и получают трафик требуемым образом. Кроме того, каждый номер SKU виртуальной машины имеет ограничение пропускной способности. Если вы используете меньший номер SKU виртуальной машины, трафик ограничивается пропускной способностью, доступной в сетевом адаптере. Мы рекомендуем использовать DS5v2 для тестирования, чтобы обеспечить достаточную пропускную способность на виртуальной машине.
Сетевой адаптер. Убедитесь, что вы знаете частный IP-адрес, назначенный сетевому адаптеру.
NSG сетевого адаптера — могут применяться определенные группы безопасности сети на уровне сетевого адаптера, убедитесь, что набор правил 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.
Для использования этого набора средств для тестирования производительности следует выполнить три шага:
Установка модуля PowerShell.
(new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-ExpressionЭта команда загружает модуль PowerShell и устанавливает его локально.
Установите вспомогательные приложения.
Install-LinkPerformanceЭта команда AzureCT устанавливает iPerf и PSPing в новом каталоге
C:\ACTTools, а также открывает порты брандмауэра Windows для разрешения трафика ICMP и порта 5201 (iPerf).Запустите тест производительности.
Во-первых, на удаленном узле необходимо установить и запустить iPerf в режиме сервера. Убедитесь, что удаленный хост прослушивает порт 3389 (протокол удаленного рабочего стола для Windows) либо порт 22 (SSH для Linux) и разрешает трафик через порт 5201 для iPerf. Если удаленный узел — это система Windows, установите AzureCT и выполните команду Install-LinkPerformance. Команда настраивает iPerf и правила брандмауэра, необходимые для успешного запуска iPerf в режиме сервера.
После подготовки удаленного компьютера откройте PowerShell на локальном компьютере и запустите тестирование:
Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10Эта команда выполняет серию параллельных нагрузочных тестов и тестов задержки, чтобы оценить пропускную способность и задержку вашего сетевого соединения.
Просмотрите результаты тестирования.
Формат выходных данных PowerShell выглядит примерно так:
Подробные результаты всех тестов iPerf и PSPing находятся в отдельных текстовых файлах в каталоге средств AzureCT в пути "C:\ACTTools".
Устранение неполадок
Если тест производительности не дает ожидаемых результатов, следует применить прогрессивный пошаговый процесс. Учитывая количество компонентов в пути, систематический подход обеспечивает более быстрый путь к разрешению, чем переход вокруг. Систематический поиск и устранение неполадок позволяют избежать ненужного многократного тестирования.
Примечание.
Рассматриваемый сценарий решает проблему с производительностью, а не проблему с подключением. Чтобы изолировать проблему подключения к сети Azure, следуйте инструкциям в статье о проверке подключения ExpressRotue.
Во-первых, следует проверить правильность своих предположений. Целесообразны ли ваши ожидания? Например, у вас есть канал ExpressRoute со скоростью 1 Гбит/с и задержкой 100 мс. Нецелесообразно ожидать скорости 1 Гбит/с с учетом характеристик производительности TCP в каналах с высокой задержкой. Дополнительные сведения касательно предположений о производительности см. в разделе Справка.
Затем мы рекомендуем начать с границ между доменами маршрутизации и попытаться изолировать проблему до одного основного домена маршрутизации. Вы можете начать с корпоративной сети, глобальной сети или сети Azure. Часто люди относят проблемы на счет "черного ящика" на маршруте. В то время как обвинять черную коробку легко сделать, это может значительно отложить разрешение. Особенно если она находится в области, в которую вы можете внести изменения. Перед обращением к поставщику услуг или интернет-провайдеру убедитесь, что вы выполнили комплексную проверку.
Когда вы определили основной домен маршрутизации, который, как представляется, содержит проблему, необходимо создать схему области, в которую входит вопрос. При рисовании схемы можно методично работать и изолировать проблему. Вы можете запланировать тестовые точки и обновлять карту по мере выполнения тестирования.
Теперь, когда у вас есть схема, разделите сеть на сегменты, чтобы сузить область поиска проблемы. Проверьте, в которых из сегментов присутствуют и отсутствуют проблемы. Продолжайте перемещаться по тестовым точкам, чтобы определить проблемный компонент.
Кроме того, не забудьте проверить другие уровни модели OSI. Вы можете сразу сосредоточиться на сети и уровнях 1–3 (физический уровень, уровень данных и уровень сети), но проблемы также могут быть на уровне 7 на уровне приложений. Будьте непредвзяты и проверяйте любые предположения.
Расширенное устранение проблем с ExpressRoute
Если вы не знаете, где на самом деле находится граничная точка облака, это может усложнить изолирование компонентов Azure. При использовании ExpressRoute граничной точкой является сетевой компонент Microsoft Enterprise Edge (MSEE). При использовании ExpressRoute MSEE является первой точкой контакта в сети Майкрософт и последним прыжком при выходе из нее. При создании объекта подключения между шлюзом виртуальной сети и каналом ExpressRoute вы фактически подключаетесь к MSEE. Расценивайте MSEE как первый или последний прыжок в зависимости от того, какое направление трафика важно для изоляции проблемы в сети Azure. Зная, какое направление показывает, находится ли проблема в Azure или далее внизу в глобальной сети или корпоративной сети.
Примечание.
Обратите внимание, что MSEE не находится в облаке Azure. ExpressRoute фактически находится в граничной части сети Майкрософт, а не в Azure. После установления соединения с MSEE через ExpressRoute вы будете подключены к сети Майкрософт, откуда сможете перейти к любой из облачных служб, например Microsoft 365 (с пирингом Майкрософт) или Azure (с частным пирингом и/или пирингом Майкрософт).
Если две виртуальные сети подключены к одному и тому же каналу ExpressRoute, вы можете выполнить ряд тестов, чтобы изолировать проблему в Azure.
План тестирования
Запустите тест Get-LinkPerformance между ВМ1 и ВМ2. Этот тест помогает определить, является ли проблема локальной. Если этот тест создает допустимые результаты задержки и пропускной способности, можно пометить локальную виртуальную сеть как хорошую.
Предположим, что трафик локальной виртуальной сети хорош, выполните тест Get-LinkPerformance между VM1 и VM3. Этот тест проверяет подключение через сеть Майкрософт к MSEE и обратно в Azure. Если результаты теста показывают приемлемые задержку и пропускную способность, вы можете отметить сеть Azure как работоспособную.
После исключения Azure вы можете выполнить аналогичную последовательность тестов в вашей корпоративной сети. Если тестирование прошло успешно, пора обратиться к поставщику услуг или интернет-провайдеру для диагностики вашего подключения к глобальной сети. Пример. Выполните этот тест между двумя филиалами или вашим компьютером и сервером центра обработки данных. В зависимости от того, что вы тестируете, найдите конечные точки, такие как серверы и клиентские ПК, которые могут использовать этот путь.
Важно!
Важно отметить время выполнения теста и записать результаты в общем расположении. Каждый тестовый запуск должен иметь идентичные выходные данные, чтобы вы могли сравнивать их результаты без "пробелов" в данных. Согласованность между несколькими тестами является основной причиной, по которой мы используем AzureCT для устранения неполадок. Магия не в точных сценариях загрузки, которые мы запускаем, но вместо этого магия заключается в том, что мы получаем согласованные тесты и выходные данные из каждого и каждого теста. Сведения о времени выполнения и согласованные данные всех тестов особенно полезны, если позже вы обнаружите, что проблема является спорадической. Будьте внимательны с сбором данных заранее, и вы будете избегать нескольких часов повторного тестирования тех же сценариев.
Область возникновения проблемы обнаружена, что делать дальше?
Чем точнее вы изолируете проблему, тем быстрее можно будет найти решение. Иногда вы достигаете точки, откуда нельзя продолжить устранение неполадок. Например, вы видите, что соединение с вашим поставщиком услуг проходит через Европу, но ожидаемый вами путь полностью находится в Азии. На этом этапе вы должны обратиться к кому-либо за помощью. Выбор лица, к которому следует обращаться, зависит от домена маршрутизации, в котором вы изолируете неполадку. Еще лучше будет сократить поиски до определенного компонента.
В случае проблем с корпоративной сетью ваш внутренний ИТ-отдел или поставщик услуг может помочь с настройкой устройства или ремонтом оборудования.
Рекомендуется устранить неполадки с глобальной сетью, чтобы поделиться результатами тестирования с поставщиком услуг или поставщиком услуг, так как это может помочь им с их работой. Результаты теста также могут избежать выполнения таких же задач, которые вы уже сделали. Тем не менее, они могут проверка ваши результаты сами. Это основано на принципе доверия , но проверить.
В 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 МБ.
Результаты задержки и пропускной способности
Важно!
Эти данные предназначены только для общего ознакомления. Многие факторы влияют на задержку, и, хотя эти значения в целом согласуются с течением времени, условия в пределах 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 мс. Разница в задержке может указывать на проблему в сети. Но реальность такова, что оптоволоконная линия не идет в Бразилию по прямой. Поэтому следует учесть еще где-то 1000 км пути из Сиэтла в Бразилию.
Примечание.
Хотя эти числа следует учитывать, они были протестированы с помощью AzureCT, который основан на IPERF в Windows через PowerShell. В этом сценарии IPERF не учитывает параметры TCP Windows по умолчанию для коэффициента масштабирования и используют гораздо меньшее число сдвигов для размера окна TCP. Числа, представленные здесь, были выполнены с использованием значений IPERF по умолчанию и предназначены только для общих ссылок. Настраивая команды IPERF с -w помощью коммутатора и большого размера окна TCP, более высокую пропускную способность можно получить на длинных расстояниях, показывая значительно лучшие показатели пропускной способности. Кроме того, для обеспечения полной пропускной способности ExpressRoute идеально подходит для запуска IPERF в нескольких потоках с нескольких компьютеров одновременно, чтобы обеспечить максимальную производительность связи и не ограничивается емкостью обработки одной виртуальной машины. Чтобы получить лучшие результаты Iperf в Windows, используйте set-NetTCPSetting -AutoTuningLevelLocal Experimental. Перед внесением изменений проверка политики организации.