TCP/IP performance tuning for Azure VMs (Настройка производительности TCP/IP для виртуальных машин Azure)
В этой статье рассматриваются распространенные методы настройки производительности TCP/IP и некоторые факторы, которые следует учитывать при их использовании для виртуальных машин, работающих в Azure. Здесь изложены основные сведения об этих методах и их настройке.
Распространенные методы настройки TCP/IP
Максимальный передаваемый блок данных, фрагментация и разгрузка большой отправки
MTU
Максимальный передаваемый блок данных (MTU) — это самый крупный кадр (пакет) в байтах, который может быть отправлен через сетевой интерфейс. Параметр MTU является настраиваемым. Значение MTU по умолчанию, используемое на виртуальных машинах Azure, и настройка по умолчанию для большинства сетевых устройств составляет 1500 байт.
Фрагментация
Фрагментация происходит при отправке пакета, размер которого превышает значение MTU сетевого интерфейса. Стек TCP/IP разобьет этот пакет на более мелкие части (фрагменты), соответствующие MTU интерфейса. Фрагментация происходит на уровне IP-адреса и не зависит от базового протокола (например, TCP). Если 2000-байтовый пакет передается через сетевой интерфейс с MTU 1500, он будет разбит на фрагменты в 1500 и 500 байт.
Сетевые устройства на маршруте между источником и назначением могут либо отбрасывать пакеты, превышающие MTU, либо фрагментировать их.
Бит "не фрагментировать" в пакете IP
Бит "не фрагментировать" (DF) является флагом в заголовке IP-протокола. Бит DF указывает, что сетевые устройства на маршруте между отправителем и получателем не должны фрагментировать пакет. Этот бит может быть установлен по целому ряду причин. (Один из примеров см. в разделе "Определение MTU маршрута" данной статьи.) Когда сетевое устройство получает пакет с установленным битом "не фрагментировать", а пакет превышает MTU интерфейса, оно по умолчанию отбрасывает этот пакет. Устройство отправляет сообщение о фрагментации ICMP обратно источнику пакета.
Влияние фрагментации на производительность
Фрагментация может негативно сказаться на производительности. Одной из основных причин снижения производительности является влияние фрагментации и повторной сборки пакетов на ЦП и память. Когда сетевому устройству необходимо выполнить фрагментацию пакета, ему потребуются ресурсы ЦП и памяти для этой задачи.
То же самое происходит при повторной сборке пакета. Сетевое устройство должно хранить все фрагменты, пока они не будут получены, чтобы он смог повторно собрать их в исходный пакет.
Azure и фрагментация
Фрагментированные пакеты в Azure не обрабатываются ускорением сети. При получении фрагментированного пакета виртуальная машина будет обработана через нео ускоренный путь. Это означает, что фрагментированные пакеты не получат преимущества ускоренной сети (более низкая задержка, снижение дрожания и более высокие пакеты в секунду). По этой причине рекомендуется избегать фрагментации, если это возможно.
По умолчанию Azure удаляет фрагменты порядка, то есть фрагментированные пакеты, не поступающие на виртуальную машину в том порядке, в который они были переданы из исходной конечной точки. Это может произойти, когда пакеты передаются через Интернет или другие крупные WAN. В некоторых случаях можно включить переупорядочение фрагментов из порядка. Если приложению требуется это, откройте вариант поддержки.
Настройка MTU
Мы не рекомендуем клиентам увеличивать MTU на сетевых адаптерах виртуальных машин. Если виртуальная машина должна взаимодействовать с назначениями, которые не находятся в виртуальная сеть с аналогичным набором MTU, фрагментация, скорее всего, приведет к снижению производительности.
Разгрузка большой отправки
Разгрузка большой отправки (LSO) позволяет повысить производительность сети за счет переноса сегментации пакетов на адаптер Ethernet. Если функция LSO включена, стек TCP/IP создает большой TCP-пакет и отправляет его на адаптер Ethernet для сегментации перед пересылкой. Преимущество LSO заключается в том, что это позволяет освободить ЦП от сегментирования пакетов до размера MTU и перенести соответствующие операции в интерфейс Ethernet, где они выполняются на аппаратном уровне. Дополнительные сведения о преимуществах LSO см. в статье Поддержка разгрузки большой отправки.
Если функция LSO включена, клиенты Azure могут сталкиваться с кадрами больших размеров при сборе пакетов. Такие большие размеры могут привести некоторых клиентов к ошибочной мысли, что имеет место фрагментация либо используется большой MTU. Благодаря функции LSO адаптер Ethernet может объявить стеку TCP/IP больший максимальный размер сегмента (MSS) для создания большего пакета TCP. Затем весь этот несегментированный кадр направляется на адаптер Ethernet и отображается при сборе пакетов на виртуальной машине. Но пакет будет разбит на множество небольших кадров адаптером Ethernet, в соответствии с MTU адаптера Ethernet.
Масштабирование и PMTUD окна MSS TCP
Максимальный размер сегмента TCP
Максимальный размер сегмента TCP (MSS) — это параметр, ограничивающий размер TCP-сегментов, что позволяет избежать фрагментации пакетов TCP. В операционных системах для установки размера MSS обычно используется такая формула:
MSS = MTU - (IP header size + TCP header size)
Заголовок IP и заголовок TCP имеют размер 20 байт каждый (всего 40 байт). Таким образом, интерфейс с MTU 1500 будет иметь MSS 1460. Однако размер MSS можно настроить.
Этот параметр согласуется в ходе трехстороннего подтверждения TCP, если между источником и назначением настроен сеанс TCP. Обе стороны отправляют значение MSS, и меньшее из двух значений используется для TCP-соединения.
Помните, что значения MTU источника и назначения не являются единственными факторами, определяющими величину MSS. На промежуточных сетевых устройствах, таких как VPN-шлюзы Azure, MTU может настраиваться независимо от источника и назначения с целью оптимизировать производительность сети.
Обнаружение MTU пути
Параметр MSS согласовывается, однако не всегда указывает на реальный размер MSS, который можно использовать. Это связано с тем, что на других сетевых устройствах на маршруте между источником и назначением значение MTU может быть меньше, чем в точках источника и назначения. В этом случае устройство, значение MTU которого меньше размера пакета, отбросит этот пакет. Устройство передаст обратно сообщение о необходимости фрагментации ICMP (тип 3, код 4) с указанием своего MTU. Это сообщение ICMP позволяет исходному узлу уменьшить MTU для соответствующего маршрута. Этот процесс называется обнаружением MTU пути (Path MTU Discovery, PMTUD).
Процесс PMTUD неэффективен и влияет на производительность сети. При отправке пакетов, размер которых превышает MTU сетевого маршрута, их необходимо передавать с меньшим значением MSS. Если отправитель не получит сообщение о необходимости фрагментации ICMP (например, из-за сетевого брандмауэра на маршруте; такая ситуация обычно называется "черной дырой" PMTUD), он не узнает, что размер MSS необходимо уменьшить, и будет повторно передавать этот пакет. Поэтому мы не рекомендуем увеличивать значение MTU виртуальной машины Azure.
VPN и MTU
Если вы используете виртуальные машины, которые выполняют инкапсуляцию (например, виртуальные частные сети IPsec), на размер пакета и MTU влияет ряд дополнительных факторов. Виртуальные частные сети добавляют к пакетам дополнительные заголовки, что увеличивает их размер и требует уменьшения значения MSS.
Для Azure рекомендуется установить фиксацию MSS TCP на уровне 1350 байт, MTU интерфейса туннеля — 1400 байт. Дополнительные сведения см. на странице устройств VPN и параметров IPsec/IKE.
Задержка, время кругового пути и масштабирование окна TCP
Задержка и время кругового пути
Задержка в сети определяется скоростью света в оптоволоконной сети. Время кругового пути (RTT) между двумя сетевыми устройствами также оказывает большое влияние на пропускную способность сети TCP.
| Маршрут | расстояние; | Время одностороннего маршрута | Время кругового пути |
|---|---|---|---|
| Нью Йорк — Сан-Франциско | 4148 км | 21 мс | 42 мс |
| Нью Йорк — Лондон | 5585 км | 28 мс | 56 мс |
| Нью Йорк — Сидней | 15993 км | 80 мс | 160 мс |
В этой таблице показано расстояние по прямой между двумя точками. Расстояние в сетях обычно превышает расстояние по прямой. Ниже приведена простая формула для вычисления минимального RTT, зависящего от скорости света.
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
Для скорости распространения можно использовать значение 200. Это расстояние в километрах, которое свет проходит за 1 миллисекунду.
Возьмем в качестве примера расстояние между Нью-Йорком и Сан Франциско. Расстояние по прямой составляет 4148 км. Подставив это значение в формулу, получаем следующее:
Minimum RTT = 2 * (4,148 / 200)
Результат уравнения приведен в миллисекундах.
Если требуется повысить производительность сети, оптимальным вариантом будет выбор мест назначения с кратчайшим расстоянием между ними. Кроме того, следует спроектировать виртуальную сеть таким образом, чтобы оптимизировать маршрут трафика и сократить задержку. Дополнительные сведения см. в разделе "Вопросы проектирования сети" этой статьи.
Влияние задержки и времени кругового пути на TCP
Время кругового пути напрямую влияет на максимальную пропускную способность TCP. В протоколе TCP размер окна — это максимальный объем трафика, который может быть отправлен через TCP-соединение, прежде чем отправитель получит подтверждение от получателя. Если для TCP MSS задано значение 1460, а для размера окна TCP — значение 65 535, отправитель может переслать 45 пакетов, прежде чем он получит подтверждение от получателя. Если отправитель не получает подтверждение, данные передаются повторно. Формула выглядит так:
TCP window size / TCP MSS = packets sent
В этом примере 65 535/1460 округляется до 45.
Именно это состояние "ожидание подтверждения", т. е. механизма обеспечения надежной доставки данных, RTT влияет на пропускную способность TCP. Чем дольше отправитель ждет подтверждения, тем больше времени потребуется, чтобы отправить следующие данные.
Ниже приведена формула для вычисления максимальной пропускной способности отдельного TCP-подключения.
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
В этой таблице показана максимальная пропускная способность (в МБ/с) для одного TCP-подключения (для удобства в качестве единицы измерения используются мегабайты.)
| Размер окна TCP, байты | Задержка RTT, мс | Максимальная пропускная способность в мегабайтах за секунду | Максимальная пропускная способность в мегабитах за секунду |
|---|---|---|---|
| 65 535 | 1 | 65,54 | 524,29 |
| 65 535 | 30 | 2.18 | 17,48 |
| 65 535 | 60 | 1,09 | 8,74 |
| 65 535 | 90 | 0,73 | 5,83 |
| 65 535 | 120 | 0,55 | 4.37 |
Если пакеты теряются, максимальная пропускная способность TCP-подключения снижается, так как отправитель повторно передает уже отправленные данные.
Масштабирование окна TCP
Масштабирование окна TCP — это метод, который динамически увеличивает размер окна TCP, позволяя отправлять больше данных, прежде чем потребуется подтверждение. В предыдущем примере до подтверждения были бы отправлены 45 пакетов. При увеличении числа пакетов, которые могут быть отправлены до обязательного подтверждения, уменьшается количество случаев, когда отправитель ожидает подтверждения, что увеличивает максимальную пропускную способность TCP.
Эта зависимость показана в таблице ниже.
| Размер окна TCP, байты | Задержка RTT, мс | Максимальная пропускная способность в мегабайтах за секунду | Максимальная пропускная способность в мегабитах за секунду |
|---|---|---|---|
| 65 535 | 30 | 2.18 | 17,48 |
| 131 070 | 30 | 4.37 | 34,95 |
| 262 140 | 30 | 8,74 | 69,91 |
| 524 280 | 30 | 17,48 | 139,81 |
При этом длина заголовка TCP для окна TCP составляет всего 2 байта, что означает, что максимальное значение окна приема равно 65 535. Для увеличения максимального размера окна был введен коэффициент масштабирования окна TCP.
Коэффициент масштабирования является также параметром, который задается в операционной системе. Ниже приведена формула для вычисления размера окна TCP с использованием коэффициентов масштабирования.
TCP window size = TCP window size in bytes * (2^scale factor)
Ниже приведен расчет для коэффициента масштабирования 3 и размера окна 65 535.
65,535 * (2^3) = 524,280 bytes
С коэффициентом масштабирования 14 размер окна TCP увеличивается до 14 (максимальное допустимое смещение). В результате размер окна TCP будет составляет 1 073 725 440 байт (8,5 гигабит).
Поддержка масштабирования окна TCP
В Windows можно задавать различные коэффициенты масштабирования для разных типов подключений (классы подключений включают центр обработки данных, Интернет и т. д .). Чтобы просмотреть тип подключения для масштабирования окна, используйте команду PowerShell Get-NetTCPConnection:
Get-NetTCPConnection
Для просмотра значений каждого класса можно использовать команду PowerShell Get-NetTCPSetting:
Get-NetTCPSetting
Задать начальный размер окна TCP и коэффициент масштабирования TCP в Windows можно с помощью команды PowerShell Set-NetTCPSetting. Дополнительные сведения см. в статье о команде Set-NetTCPSetting.
Set-NetTCPSetting
Ниже приведены действующие параметры TCP для AutoTuningLevel.
| AutoTuningLevel | Коэффициент масштабирования | Множитель масштабирования | Формула для расчета максимального размера окна |
|---|---|---|---|
| Выключено | Нет | Нет | Размер окна |
| С ограниченным доступом | 4 | 2^4 | Размер окна × (2^4) |
| Высокий уровень ограничений | 2 | 2^2 | Размер окна × (2^2) |
| Обычная | 8 | 2^8 | Размер окна × (2^8) |
| Экспериментальный | 14 | 2^14 | Размер окна × (2^14) |
Эти параметры, скорее всего, повлияют на производительность TCP, однако следует помнить, что влиять на нее также могут многие другие факторы в Интернете, на которые не влияют настройки среды Azure.
Ускорение работы в сети и масштабирование на стороне приема
Ускорение работы в сети
Исторически сложилось так, что сетевые функции виртуальных машин отличалась высокими требованиями к ресурсам ЦП как на гостевой виртуальной машине, так и на гипервизоре или узле. Каждый пакет, проходящий через узел, обрабатывается в программном обеспечении на ЦП узла, включая все операции инкапсуляции и декапсуляции виртуальной сети. Таким образом, чем больший трафик проходит через узел, тем выше нагрузка на ЦП. И если ЦП узла занят другими операциями, это также влияет на пропускную способность и задержку сети. Azure решает эту задачу путем ускорения сети.
Режим ускорения сети обеспечивает постоянную сверхнизкую задержку за счет использования встроенного программируемого оборудования Azure и различных технологий, таких как SR-IOV. Ускорение сети переносит значительную часть программно-определяемого сетевого стека Azure с процессоров на интерфейсы SmartNIC на основе ППВМ. Это изменение позволяет приложениям конечных пользователей задействовать вычислительные циклы, что снижает нагрузку на виртуальную машину, дрожание и колебания задержки. Иными словами, производительность становится более стабильной.
Режим ускорения сети повышает производительность, позволяя гостевой виртуальной машине обходить узел и устанавливать путь к данным непосредственно до интерфейса SmartNIC узла. Ниже описаны некоторые преимущества режима ускорения сети.
Уменьшение задержки / большее количество пакетов в секунду. Удаление виртуального коммутатора на пути к данным устраняет время, затрачиваемое пакетами на обработку политики на узле. Таким образом, увеличивается число пакетов, которые могут быть обработаны на виртуальной машине.
Уменьшение дрожания. Обработка с помощью виртуального коммутатора зависит от числа политик, которые необходимо применить, и рабочей нагрузки ЦП, выполняющего обработку. Так как принудительное применение политик осуществляется на аппаратном уровне, эта зависимость устраняется за счет доставки пакетов непосредственно на виртуальную машину. Это позволяет избежать обмена данными между узлом и виртуальной машиной, прерываний работы программного обеспечения и переключений контекста.
Уменьшение нагрузки ЦП. Обход виртуального коммутатора на узле приводит к снижению использования ЦП для обработки сетевого трафика.
Чтобы задействовать режим ускорения сети, необходимо напрямую включить его на каждой виртуальной машине. Инструкции см. в статье Создание виртуальной машины Linux с ускоренной сетью.
Масштабирование на стороне приема
Масштабирование на стороне приема (RSS) — это технология сетевого драйвера, которая эффективнее распределяет прием сетевого трафика между несколькими процессорами в многопроцессорной системе. Простыми словами, RSS позволяет системе обрабатывать больше поступающего трафика, так как использует все доступные процессоры, а не только один. Подробное обсуждение технических аспектов RSS см. в статье Общие сведения о масштабировании на стороне приема.
Чтобы добиться максимальной производительности с включенным режимом ускорения сети на виртуальной машине, необходимо активировать RSS. Кроме того, RSS повышает эффективность и виртуальных машин, которые не используют ускорение сети. Общие сведения о том, как определить, включена ли технология RSS, и как ее включить, см. в статье Оптимизации пропускной способности сети для виртуальной машины Azure.
Ликвидация TCP TIME_WAIT и TIME_WAIT
TCP-TIME_WAIT — это еще один стандартный параметр, который влияет на производительность сети и приложений. На загруженных виртуальных машинах, открывающих и закрывающих много сокетов в качестве как клиентов, так и серверов (исходный IP-адрес:исходный порт + конечный IP-адрес:конечный порт), в режиме нормальной работы протокола TCP определенный сокет может надолго оказаться в состоянии TIME_WAIT. Состояние TIME_WAIT делает возможной доставку дополнительных данных на сокет перед его закрытием. Таким образом, стеки TCP/IP обычно запрещают повторное использование сокета путем автоматического удаления TCP-пакета SYN клиента.
Интервал времени, в течение которого сокет находится в состоянии TIME_WAIT, является настраиваемым. Его значение может варьироваться от 30 до 240 секунд. Сокеты являются ограниченным ресурсом, и количество сокетов, которые могут использоваться в каждый конкретный момент, можно настроить (как правило, доступное количество сокетов составляет примерно 30 000.) Если все доступные сокеты используются либо у клиентов и серверов не совпадают параметры TIME_WAIT, а виртуальная машина пытается повторно использовать сокет в состоянии TIME_WAIT, новые соединения не устанавливаются, так как TCP-пакеты SYN автоматически отбрасываются.
Значение диапазона портов для исходящих сокетов обычно настраивается в стеке TCP/IP операционной системы. То же самое применимо и для параметров TCP TIME_WAIT и повторного использования сокета. Изменение этих чисел может вести к улучшению масштабируемости. Но в зависимости от ситуации эти изменения могут вызвать проблемы взаимодействия. Следует соблюдать осторожность при их изменении.
Чтобы обойти данное ограничение на масштабирование можно использовать функцию ликвидации TIME_WAIT. Ликвидация TIME_WAIT позволяет повторно использовать сокет в определенных ситуациях, например если порядковый номер в IP-пакете нового соединения превышает порядковый номер последнего пакета из предыдущего соединения. В этом случае операционная система разрешит установить новое подключение (принять новый пакет SYN/ACK) и принудительно закрыть предыдущее, которое находилось в состоянии TIME_WAIT. Эта возможность поддерживается на виртуальных машинах Windows в Azure. Чтобы узнать о поддержке на других виртуальных машинах, обратитесь к поставщику соответствующей ОС.
Дополнительные сведения о настройке параметров TCP TIME_WAIT и диапазона портов источника см. в статье Параметры, которые можно изменить для повышения производительности сети.
Факторы виртуальной сети, которые могут влиять на производительность
Максимальная исходящая пропускная способность виртуальной машины
В Azure доступно несколько разных типов и размеров виртуальных машин, каждый из которых обладает определенным сочетанием характеристик производительности. Одной из таких характеристик является пропускная способность сети, которая измеряется в мегабитах в секунду (Мбит/с). Поскольку виртуальные машины размещены на общем оборудовании, пропускная способность сети должна быть справедливо распределена между виртуальными машинами, которые используют общее оборудование. Крупным виртуальным машинам выделяется большая пропускная способность, чем более мелким.
Пропускная способность сети, выделяемая каждой виртуальной машине, определяет скорость передачи данных от виртуальной машины (исходящий трафик). Ограничение распространяется на весь сетевой трафик, покидающий виртуальную машину, независимо от его назначения. Например, если для виртуальной машины установлено ограничение 1000 Мбит/с, эта квота расходуется на любой исходящий трафик — как к другой виртуальной машине в той же виртуальной сети, так и за пределы Azure.
Входящий трафик не измеряется и не ограничивается напрямую. Однако способность виртуальной машины обрабатывать входящие данные может быть ограничена другими факторами, такими как ограничения на использование ЦП и хранилища.
Функция ускорения сети позволяет повысить производительность сети по таким показателям, как задержки в сети, пропускная способность и использование ЦП. Ускорение сети может увеличить пропускную способность вириальной машины, но только в пределах пропускной способности, выделенной для нее.
К виртуальной машине Azure всегда должен быть подключен по крайней мере один сетевой интерфейс. Их может быть и несколько. Пропускная способность, выделенная для виртуальной машины, оценивается по сумме исходящего трафика на всех присоединенных к ней сетевых интерфейсах. Другими словами, пропускная способность выделяется на виртуальную машину в целом независимо от количества присоединенных к ней сетевых интерфейсов.
Ожидаемая пропускная способность сети и количество поддерживаемых сетевых интерфейсов для разных размеров виртуальных машин указаны в описаниях размеров для виртуальных машин Windows в среде Azure. Чтобы увидеть максимальную пропускную способность, выберите тип, например Общее назначение, а затем найдите раздел о серии размеров на странице результатов (например, "серия Dv2"). Для каждой серии существует таблица с характеристиками, в которой спецификации сети указаны в последнем столбце под названием "Максимальное число сетевых адаптеров и ожидаемая пропускная способность сети (Мбит/с)".
Ограничение пропускной способности применяется ко всей виртуальной машине. Пропускная способность не зависит от указанных ниже факторов.
Количество сетевых интерфейсов. Ограничение пропускной способности применяется к совокупному исходящему трафику от виртуальной машины.
Ускорение сети. Эта функция помогает максимально эффективно использовать заявленный предел, но не изменяет его.
Назначение трафика. При оценке ограничения на исходящий трафик полностью учитываются все назначения.
Протокол. При оценке ограничения на исходящий трафик полностью учитываются все протоколы.
Чтобы получить дополнительную информацию, см. Пропускная способность сети для виртуальных машин.
Вопросы производительности интернет-соединений
Как обсуждалось в этой статье, на производительность сети могут повлиять факторы в Интернете вне сферы контроля Azure. Ниже приведены некоторые из них.
Задержка. Время кругового пути между точками назначения может зависеть от проблем в промежуточных сетях, от трафика, который не проходит по "кратчайшему" расстоянию, и от неоптимальных путей пиринга.
Потеря пакетов. Потеря пакетов может быть вызвана перегрузкой сети, физическими проблемами пути и недостаточной производительностью сетевых устройств.
Размер MTU/фрагментация. Фрагментация на маршруте может вести к задержкам при получении данных или к неправильному порядку пакетов, что может повлиять на их доставку.
Хорошим инструментом для измерения характеристик производительности сети (таких как потеря пакетов и задержка) по каждому сетевому маршруту между исходным и конечным устройством является утилита Traceroute.
Вопросы проектирования сети
Наряду с рассмотренными выше вопросами на производительность сети может также повлиять топология виртуальной сети. Например, конструкция типа "звезда", обеспечивающая передачу трафика глобально в виртуальную сеть с одним концентратором, приведет к задержке в сети, что повлияет на ее общую производительность.
Количество сетевых устройств, через которые проходит сетевой трафик, также может повлиять на общую задержку. Например, если в структуре "звезда" трафик перед передачей в Интернет проходит через виртуальный сетевой модуль периферийного сервера и виртуальный модуль концентратора, сетевые виртуальные устройства могут привести к задержке.
Регионы Azure, виртуальные сети и задержка
Регионы Azure состоят из нескольких центров обработки данных, которые расположены в одной географической области. Эти центры могут не находиться рядом друг с другом физически. Иногда они разделены расстоянием до 10 километров. Виртуальная сеть — это логическая конструкция, созданная на базе структуры сети физических центров обработки данных Azure. Виртуальная сеть не подразумевает какую-либо конкретную сетевую топологию в центре обработки данных.
Например, две виртуальные машины в одной виртуальной сети и подсети могут находиться в разных стойках, рядах или даже центрах обработки данных. Они могут быть разделены как метром, так и километрами волоконно-оптического кабеля. Эти вариации могут вести к возникновению переменной задержки (с разницей в несколько миллисекунд) между разными виртуальными машинами.
Географическое размещение виртуальных машин и потенциальная задержка между двумя виртуальными машинами могут зависеть от конфигурации групп доступности и зон доступности. Однако расстояние между центрами обработки данных в регионе зависит от конкретного региона и в основном от топологии центров обработки данных в его пределах.
Нехватка исходных портов SNAT
Развертывания в Azure могут взаимодействовать с конечными точками за пределами Azure в общедоступном сегменте Интернета и / или в пространстве общедоступных IP-адресов. Когда экземпляр инициирует исходящее подключение, Azure динамически сопоставляет частный IP-адрес виртуальной машины с общедоступным IP-адресом. После создания этого сопоставления средой Azure обратный трафик исходящего потока также можно направлять по частному IP-адресу, с которого поток исходил изначально.
Подсистема Azure Load Balancer должна поддерживать это сопоставление для каждого исходящего подключения в течение некоторого периода. Учитывая мультитенантную природу Azure, поддержание этого сопоставления для каждого исходящего потока и каждой виртуальной машины может быть ресурсоемкой задачей. Поэтому существуют ограничения, которые задаются и основываются на конфигурации виртуальной сети Azure. Или, говоря точнее, виртуальная машина Azure может одновременно устанавливать определенное количество исходящих подключений. При достижении этих лимитов виртуальная машина больше не сможет создавать исходящие подключения.
Но это поведение можно настроить. Дополнительные сведения о SNAT и нехватке портов SNAT см. в этой статье.
Измерение производительности сети в Azure
В этой статье рассматривается ряд максимальных показателей производительности, связанных с задержкой сети и временем кругового пути (RTT) между двумя виртуальными машинами. Этот раздел содержит рекомендации по тестированию задержки и RTT, а также проверке производительности TCP и производительности сети виртуальных машин. Вы можете настроить и протестировать производительность для описанных выше параметров TCP/IP и сети, используя методы, описанные в этом разделе. Вы можете подставлять значения задержки, MTU, MSS и размера окна в приведенные выше расчеты и сравнивать теоретический максимальный уровень с фактическими значениями, наблюдаемыми во время тестирования.
Измерение времени кругового пути и потери пакетов
Производительность TCP в значительной степени зависит от RTT и потери пакетов. Служебная программа PING, доступная в Windows и Linux, является наиболее простым способом для измерения показателей RTT и потери пакетов. В выходных данных PING будет показана минимальная, максимальная и средняя задержка между источником и назначением. Также отображаются потери пакетов. PING по умолчанию использует протокол ICMP. Для проверки RTT TCP-соединения можно использовать PsPing. Дополнительные сведения см. на странице PsPing.
Измерение фактической пропускной способности виртуальной машины
Чтобы точно измерить пропускную способность виртуальных машин Azure, следуйте этим рекомендациям.
Дополнительные сведения о тестировании других сценариев см. в следующих статьях:
Обнаружение проблем с эффективностью TCP
При сборе пакетов клиенты Azure могут видеть TCP-пакеты с флагами TCP (SACK, DUP ACK, RETRANSMIT и FAST RETRANSMIT), которые могут указывать на проблемы с производительностью сети. Эти пакеты прямо указывают на неэффективность сети вследствие потери пакетов. Однако потеря пакетов не обязательно связана с проблемами с производительностью Azure. Проблемы с производительностью могут возникать в результате проблем с приложениями, операционной системой или других проблем, которые могут быть не связаны с платформой Azure напрямую.
Кроме того, помните, что иногда повторная пересылка и дублирование подтверждений в сети является нормальным явлением. Протоколы TCP разрабатывались для обеспечения надежности. Наличие подобных пакетов TCP в среде сбора пакетов не всегда указывает на системную проблему в сети, если только такие явления не возникают слишком чисто.
Тем не менее, пакеты таких типов указывают на то, что пропускная способность TCP не находится на максимальном уровне по причинам, изложенным в других разделах этой статьи.
Следующие шаги
Теперь, когда вы прочитали о настройке производительности TCP/IP для виртуальных машин Azure, вы можете ознакомиться с другими рекомендациями по планированию виртуальных сетей или дополнительными сведениями об их подключении и настройке.