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

Сводка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты

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

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

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

#REF!CT — набор средств подключения #REF!

Модуль #REF!CT PowerShell включает два компонента: Availability Testing и Performance Testing. В этом документе основное внимание уделяется тестированию производительности, в частности двум командам производительности ссылок в этом модуле PowerShell.

Ниже приведены три основных шага по использованию этого набора средств для тестирования производительности.

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

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

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

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

   Install-LinkPerformance
   

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

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

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

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

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

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

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

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

   Снимок экрана результатов вывода PowerShell теста производительности ссылки.

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

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

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

1. Бросьте вызов вашим предположениям

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

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

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

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

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

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

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

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

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

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

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

Схема нескольких виртуальных сетей, подключенных к каналу ExpressRoute.

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

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

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

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

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

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

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

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

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

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

Ссылки

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

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

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

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

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

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

• Виртуальная машина DS5v2 под управлением #REF! в виртуальной сети, используя образ #REF! по умолчанию с установленным #REF!CT.

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

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

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

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

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

Схема среды тестирования, в которой устанавливается AzureCT.

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

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

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

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