RFC 8238 | Терминология сравнительного анализа центров обработки данных

Аннотация

Цели этого информационного документа состоят в том, чтобы установить определения и описать методы измерения для сравнительного анализа центров обработки данных, а также ввести новую терминологию, применимую к оценкам производительности сетевого оборудования центров обработки данных. Этот документ устанавливает важные концепции для сравнения сетевых коммутаторов и маршрутизаторов в центре обработки данных и является предварительным условием для документа методологии тестирования (RFC 8239). Многие из этих терминов и методов могут быть применимы к сетевому оборудованию, выходящему за рамки этого документа, поскольку технологии, изначально применяемые в центре обработки данных, развернуты в других местах.

Скачать оригинальный документ на английском языке RFC 8238 PDF

 

Оглавление

1. Введение
1.1. Требования Языка
1.2. Формат определения
2. Задержка
2.1. Определение
2.2. Обсуждение
2.3. Единицы измерения
3. Джиттер
3.1. Определение
3.2. Обсуждение
3.3. Единицы измерения
4. Калибровка физического уровня
4.1. Определение
4.2. Обсуждение
4.3. Единицы измерения
5. Скорость линии
5.1. Определение
5.2. Обсуждение
5.3. Единицы измерения
6. Буферизация
6.1. Буфер
6.1.1. Определение
6.1.2. Обсуждение
6.1.3. Единицы измерения
6.2. Incast
6.2.1. Определение
6.2.2. Обсуждение
6.2.3. Единицы измерения
7. Пропускная способность приложений: центр обработки данных Goodput
7.1. Определение
7.2. Обсуждение
7.3. Единицы измерения
8. Вопросы безопасности
9. Соображения IANA
10. Ссылки
10.1. Нормативные ссылки
10.2. Информационные ссылки
Благодарности
Адреса авторов

 

1. Введение

Схемы трафика в дата-центре неоднородны и постоянно меняются. Они продиктованы характером и разнообразием приложений, используемых в центре обработки данных. В основном это могут быть потоки трафика восток-запад (сервер-сервер внутри центра обработки данных) в одном центре обработки данных и север-юг (от центра обработки данных к серверу) в другом, в то время как некоторые могут объединять оба. Схемы трафика могут быть импульсными по своей природе и содержать потоки «многие к одному», «многие ко многим» или «один ко многим». Каждый поток может также быть маленьким и чувствительным к задержке или большим и чувствительным к пропускной способности, в то же время содержащий смесь трафика UDP и TCP. Все они могут сосуществовать в одном кластере и проходить через одно сетевое устройство одновременно. Сравнительные тесты для сетевых устройств давно используются [RFC1242 #], [RFC2432 #], [RFC2544 #], [RFC2889 #] и [RFC3918 #]. Эти тесты были в основном сфокусированы на различных атрибутах задержки и максимальной пропускной способности тестируемого устройства (DUT — Device Under Test). Эти стандарты хороши для измерения теоретической максимальной пропускной способности, скорости пересылки и задержки в условиях тестирования, но они не представляют реальные схемы трафика, которые могут повлиять на эти сетевые устройства. К сетевым устройствам центра обработки данных относятся коммутаторы и маршрутизаторы.

В настоящее время типичные сетевые устройства для центров обработки данных характеризуются:

• Высокая плотность портов (48 портов и более)
• Высокая скорость (в настоящее время до 100 ГБ/с на порт)
• Высокая пропускная способность (линейная скорость на всех портах для уровня 2 и / или уровня 3)
• Низкая задержка (в микросекундном или наносекундном диапазоне)
• Низкий объем буфера (в диапазоне МБ на сетевое устройство)
• Возможность пересылки уровня 2 и уровня 3 (уровень 3 не является обязательным)

Этот документ определяет набор определений, метрик и новой терминологии, включая сценарии перегрузки и анализ буфера коммутатора, и переопределяет основные определения, чтобы представить широкое сочетание условий трафика. Методики испытаний определены в [RFC8239].

 

1.1. Требования Языка

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].

 

1.2. Формат определения

• Срок, который должен быть определен (например, «задержка»)
• Определение: конкретное определение термина
• Обсуждение: краткое обсуждение термина, его применения и любых ограничений процедур измерения
• Единицы измерения: методология измерений и единицы измерения, используемые для сообщения об измерениях рассматриваемого термина, если применимо

 

2. Задержка/Латентность (Latency)

2.1. Определение

Задержка — это количество времени, которое требуется кадру для прохождения DUT. Задержка измеряется в единицах времени (секунды, миллисекунды, микросекунды и т. д.). Цель измерения задержки состоит в том, чтобы понять влияние добавления устройства в канал связи.

Интервал задержки может быть оценен между различными комбинациями событий, независимо от типа переключающего устройства (пересылка битов, также называемое сквозное соединение или устройство хранения и пересылки). [RFC1242 #] определяет задержку по-разному для каждого из этих типов устройств.

Традиционно определениями измерения задержки являются:

FILO (First In Last Out)

ФИЛО (первый в последнем выходе):

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

FIFO (First In First Out)

ФИФО (первый вошел, первый вышел):

Временной интервал, начинающийся, когда конец первого бита входного кадра достигает входного порта, и заканчивающийся, когда начало выходного бита выходного кадра видно на выходном порте. Задержка (как определено в [RFC1242 #]) для устройств пересылки битов использует эти события.

LILO (Last In Last Out)

ЛИЛО (последний в последнем выходе):

Интервал времени, начинающийся, когда последний бит входного кадра достигает входного порта и последний бит выходного кадра виден на выходном порту.

LIFO (Last In First Out)

ЛИФО (последний пришел первым вышел):

Интервал времени, начинающийся, когда последний бит входного кадра достигает входного порта, и заканчивающийся, когда первый бит выходного кадра виден на выходном порту. Задержка (как определено в [RFC1242 #]) для устройств хранения и пересылки использует эти события.

---

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

• FILO – это FL (Первый бит Последний бит)
• FIFO — это FF (Первый бит Первый бит)
• LILO — это LL (Последний бит, Последний бит)
• LIFO — это LF (Последний бит, Первый бит)

Это определение, как объяснено в этом разделе в контексте сравнительного анализа коммутаторов центра обработки данных, заменяет предыдущее определение «задержки», как это предусмотрено в RFC 1242, раздел 3.8 и цитируется здесь:

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

Чтобы приспособиться к обоим типам сетевых устройств и гибридов двух появившихся типов, измерения задержки переключения, сделанные в соответствии с этим документом, ДОЛЖНЫ быть измерены с событиями FILO. FILO будет включать в себя задержку коммутатора и задержку кадра, а также задержку сериализации. Это картина «всей» латентности, проходящей через DUT. Для приложений, которые чувствительны к задержке и могут функционировать с начальными байтами кадра, МОЖЕТ использоваться FIFO (или, для устройств пересылки битов, задержка по RFC 1242). Во всех случаях ДОЛЖНЫ быть сообщены комбинации событий, используемые в измерениях задержки.

2.2. Обсуждение

Как упомянуто в разделе 2.1, FILO является наиболее важным определением измерения.

Не все проверяемые устройства являются исключительно сквозными или сохраняемыми. DUT центров обработки данных часто сохраняют и пересылают для пакетов меньшего размера, а затем переходят в режим сквозной передачи при определенных пакетах большего размера. Значение размера пакета, при котором изменяется поведение, МОЖЕТ быть настраиваемым, в зависимости от производителя проверяемого устройства. FILO охватывает оба сценария: хранение и пересылка и сквозное. Порог для изменения поведения не имеет значения для сравнительного анализа, поскольку FILO охватывает оба возможных сценария.

Механизм LIFO может использоваться с коммутаторами хранения и пересылки, но не с сквозными коммутаторами, поскольку он будет обеспечивать отрицательные значения задержки для пакетов большего размера, поскольку LIFO устраняет задержку сериализации. Следовательно, этот механизм НЕ ДОЛЖЕН использоваться при сравнении задержек двух разных DUT.

 

2.3. Единицы измерения

Методы измерения, используемые для целей сравнительного анализа, следующие:

1) FILO ДОЛЖЕН использоваться в качестве метода измерения, так как он будет включать задержку пакета; сегодня приложению обычно необходимо прочитать весь пакет, чтобы обработать информацию и предпринять действия.

2) FIFO МОЖЕТ использоваться для определенных приложений, способных обрабатывать данные при поступлении первых битов — например, с программируемым полем матричным массивом (FPGA).

3) LIFO НЕ ДОЛЖЕН использоваться, потому что, в отличие от всех других методов, он вычитает задержку пакета.

 

3. Дрожание/Джиттер (Jitter)

3.1. Определение

В контексте центра обработки данных дрожание является синонимом общего термина «изменение задержки». Он получен из нескольких измерений задержки в одном направлении, как описано в RFC 3393. Обязательное определение «изменения задержки» — это изменение задержки пакета (PDV), как определено в разделе 4.2 [RFC5481]. При рассмотрении потока пакетов задержки всех пакетов вычитаются из минимальной задержки для всех пакетов в потоке. Это облегчает оценку диапазона изменения задержки (Макс. — Мин.) Или высокого процентиля PDV (99-й процентиль, для устойчивости к выбросам).

Если для измерения задержки используются метки времени от первого бита к последнему биту, то изменение задержки ДОЛЖНО быть измерено с использованием пакетов или кадров одинакового размера, поскольку определение задержки включает время сериализации для каждого пакета. В противном случае, если использовать Первый-Первый в Первый-бит, ограничение размера не применяется.

3.2. Обсуждение

В дополнение к диапазону PDV и / или высокому процентилю PDV, вариация задержки между пакетами (IPDV), как определено в разделе 4.1 [RFC5481] (различия между двумя последовательными пакетами), МОЖЕТ использоваться для определения того, как разнос пакетов изменился во время передачи — например, чтобы увидеть, стал ли поток пакетов близко разнесенным или «пакетным». Однако абсолютное значение IPDV НЕ СЛЕДУЕТ использовать, так как это «сворачивает» «бурную» и «рассеянную» стороны распределения IPDV вместе.

3.3. Единицы измерения

Измерение изменения задержки выражается в секундах. Гистограмма PDV МОЖЕТ быть предоставлена для совокупности измеренных пакетов.

 

4. Калибровка физического уровня

4.1. Определение

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

Он включает в себя список всех используемых компонентов физического уровня, как указано здесь:

• Тип устройства, используемого для генерации трафика / измерения трафика.
• Тип линейных карт, используемых в генераторе трафика.
• Тип приемопередатчиков на генераторе трафика.
• Тип приемопередатчиков на DUT.
• Тип кабелей.
• Длина кабелей.
• Название программного обеспечения и версия генератора трафика и DUT.
• МОЖЕТ быть предоставлен список включенных функций на DUT, который рекомендуется (особенно в случае протоколов уровня управления, таких как протокол обнаружения канального уровня и связующее дерево). Полный файл конфигурации МОЖЕТ быть предоставлен для этого.

4.2. Обсуждение

Калибровка физического уровня способствует сквозной задержке и должна приниматься во внимание при оценке DUT. Небольшие различия в физических компонентах теста могут повлиять на измеряемую задержку; следовательно, они ДОЛЖНЫ быть описаны при представлении результатов.

4.3. Единицы измерения

РЕКОМЕНДУЕТСЯ, чтобы все кабели, используемые для тестирования (1), были одинакового типа и длины и (2) были поставлены одним и тем же поставщиком, когда это возможно. НЕОБХОДИМО документировать спецификации кабеля, перечисленные в разделе 4.1, вместе с результатами испытаний. Протокол испытаний ДОЛЖЕН указывать, была ли задержка кабеля вычтена из результатов испытаний. НЕОБХОДИМО обеспечить точность измерений генератора трафика (для текущего испытательного оборудования это обычно значение в диапазоне 20 нс).

 

5. Скорость линии (Line Rate)

5.1. Определение

Время передачи, или максимальная скорость передачи данных, контролируется «часами передачи» в DUT. Время приема (максимальная скорость входных данных) определяется на основе частоты передачи подключенного интерфейса.

Скорость линии или частота кадров физического уровня — это максимальная емкость для отправки кадров определенного размера на тактовой частоте передачи проверяемого устройства.

Термин «номинальное значение скорости линии» определяет максимальную пропускную способность для данного порта — например (выражается как Gigabit Ethernet), 1 GE, 10 GE, 40 GE, 100 GE.

Частота («тактовая частота») тактовой частоты передачи в любых двух подключенных интерфейсах никогда не будет точно одинаковой; следовательно, терпимость необходима. Это будет выражено значением частей на миллион (PPM). Стандарты IEEE допускают определенную +/- разницу в тактовой частоте передачи, а Ethernet спроектирован так, чтобы обеспечить небольшие, нормальные вариации между двумя тактовыми частотами. Это приводит к допуску значения скорости линии, когда трафик генерируется от тестового оборудования к DUT.

Скорость линии ДОЛЖНА измеряться в кадрах в секунду (FPS).

5.2. Обсуждение

Для источника синхронизации передачи большинство коммутаторов Ethernet используют «модули синхронизации» (также называемые «модулями генератора»), которые герметизированы, с внутренней температурной компенсацией и очень точны. Выходная частота этих модулей не регулируется, поскольку в этом нет необходимости. Однако многие тестовые наборы предлагают программную настройку тактовой частоты передачи. Эти настройки ДОЛЖНЫ использоваться для «компенсации» испытательного оборудования, чтобы не отправлять больше, чем скорость линии проверяемого устройства.

Чтобы учесть незначительные отклонения, обычно обнаруживаемые в тактовой частоте имеющихся в продаже тактовых модулей и других кварцевых генераторов, стандарты Ethernet определяют максимальное изменение тактовой частоты передачи, которое должно составлять не более +/- 100 ppm от расчетной центральной частоты. Следовательно, тестируемое устройство должно иметь возможность принимать кадры со скоростью +/- 100 ppm, чтобы соответствовать стандартам.

Очень немногие тактовые схемы имеют точность +/- 0,0 PPM, потому что:

1. Стандарты Ethernet допускают максимальное отклонение +/- 100 частей на миллион со временем. Следовательно, частота колебаний контуров генератора может изменяться во времени и в широком диапазоне температур, помимо других внешних факторов.
2. Кристаллы или модули часов, как правило, имеют специфическую дисперсию +/- PPM, которая значительно лучше, чем +/- 100 PPM. Часто это +/- 30 PPM или лучше, чтобы считаться «инструментом сертификации».

При тестировании пропускной способности коммутатора Ethernet на «линейной скорости» любой конкретный коммутатор будет иметь отклонение тактовой частоты. Если тестовый набор работает на +1 PPM быстрее, чем тестируемый коммутатор, и выполняется тест на устойчивую скорость линии, можно наблюдать постепенное увеличение задержки и, в конечном итоге, потери пакетов при заполнении и переполнении буферов в коммутаторе. В зависимости от того, насколько сильно различаются тактовые частоты между двумя подключенными системами, эффект может наблюдаться после того, как поток трафика будет работать в течение нескольких сотен микросекунд, нескольких миллисекунд или секунд. Та же низкая задержка и отсутствие потери пакетов можно продемонстрировать, установив занятость канала тестового набора на чуть менее 100% занятости канала. Как правило, 99-процентное заполнение канала обеспечивает отличную задержку и отсутствие потери пакетов. Ни один коммутатор или маршрутизатор Ethernet не будет иметь тактовую частоту передачи точно +/- 0.0 PPM. Очень немногие (если таковые имеются) тестовые наборы имеют тактовую частоту, которая составляет точно +/- 0.0 PPM.

Производители тестового оборудования хорошо осведомлены о стандартах и ​​позволяют программно управляемому «смещению» +/- 100 PPM (регулировка тактовой частоты) компенсировать нормальные изменения тактовой частоты тестируемых устройств. Эта корректировка смещения позволяет инженерам определить приблизительную скорость, с которой работает подключенное устройство, и убедиться, что она соответствует параметрам, разрешенным стандартами.

5.3. Единицы измерения

«Скорость линии» может быть измерена в терминах «частоты кадров»:

Частота кадров = тактовая частота передачи / (длина кадра * 8 + минимальная задержка + преамбула + ограничитель начального кадра)

Frame Rate = Transmit-Clock-Frequency / (Frame-Length*8 + Minimum_Gap + Preamble + Start-Frame Delimiter)

Minimum_Gap представляет промежуток между кадрами. Эта формула «увеличивает или уменьшает», чтобы представить 1 ГБ Ethernet, 10 ГБ Ethernet и так далее.

Пример для скорости Ethernet 1 ГБ с 64-байтовыми кадрами:
Частота кадров = 1 000 000 000 / (64 * 8 + 96 + 56 + 8) = 1 000 000 000/672 = 1 488 095,2 кадров в секунду

Учитывая допуск +/- 100 PPM, коммутатор может «легально» передавать трафик с частотой кадров между 1 487 946,4 FPS и 1 488 244 FPS. Каждое изменение тактовой частоты на 1 PPM будет приводить к увеличению или уменьшению частоты кадров на 1.488 FPS.

В производственной сети очень маловероятно, что можно было бы увидеть точную скорость линии за очень короткий период. Нет заметной разницы между отбрасыванием пакетов на 99% скорости линии и 100% скорости линии.

Скорость линии может быть измерена при 100% скорости линии с регулировкой -100 PPM.

Скорость линии ДОЛЖНА быть измерена на уровне 99,98% с регулировкой 0 PPM.

Регулировка PPM ДОЛЖНА использоваться только для измерения скорости линии.

 

6. Буферизация (Buffering)

6.1. Буфер

6.1.1. Определения

Размер буфера (Buffer Size)

Термин «размер буфера» представляет общий объем памяти буферизации кадров, доступной на DUT. Этот размер выражается в B (байтах), KB (килобайтах), MB (мегабайтах) или GB (гигабайтах). Когда размер буфера выражен, необходимо также указать MTU кадра (Maximum Transmission Unit) (максимальный блок передачи), используемый для этого измерения, а также установить значение CoS (Class of Service) (класс обслуживания) или DSCP (Differentiated Services Code Point) (кодовая точка дифференцированных услуг), как это часто бывает. буферы разделены реализацией качества обслуживания. Пожалуйста, обратитесь к Разделу 3 [RFC8239] для получения более подробной информации.

Пример. Размер буфера проверяемого устройства при отправке 1518-байтовых кадров составляет 18 МБ.

Размер буфера порта (Port Buffer Size)

Размер буфера порта — это объем буфера для одного входного порта, одного выходного порта или комбинации местоположений входной и выходной буферизации для одного порта. Мы упоминаем три местоположения для буфера порта, потому что схема буферизации проверяемого устройства может быть неизвестной или непроверенной, поэтому знание местоположения буфера помогает прояснить архитектуру буфера и, следовательно, общий размер буфера. Размер буфера порта — это информационное значение, которое МОЖЕТ предоставлять поставщик DUT. Это не то значение, которое проверяется сравнительным тестированием. Сравнительный анализ будет проводиться с использованием методологии Максимальный размер буфера порта или Максимальный размер буфера.

Максимальный размер буфера порта (Maximum Port Buffer Size)

В большинстве случаев он совпадает с размером буфера порта. В архитектуре коммутатора определенного типа, называемой «SoC» (switch on chip) (коммутатор на кристалле), имеется буфер портов и общий буферный пул, доступный для всех портов. Максимальный размер буфера порта, в терминах буфера SoC, представляет собой сумму буфера порта и максимальное значение общего буфера, разрешенного для этого порта, определяемое в единицах B (байты), КБ (килобайты), МБ (мегабайты). или ГБ (гигабайт). Максимальный размер буфера порта должен быть выражен вместе с MTU кадра, используемым для измерения, и битовым значением CoS или DSCP, установленным для теста.

Пример: Было измерено, что DUT имеет 3 КБ буфера порта для 1518-байтовых кадров и в общей сложности 4,7 МБ максимального буфера порта для 1518-байтовых кадров и CoS из 0.

Максимальный размер буфера проверяемого устройства (Maximum DUT Buffer Size)

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

Пример: Было измерено, что DUT имеет 3 КБ буфера порта для 1518-байтовых кадров и в общей сложности 4,7 МБ максимального буфера порта для 1518-байтовых кадров. DUT имеет максимальный размер буфера 18 МБ при 1500 B и CoS из 0.

Пакет (Burst)

Пакет — это фиксированное количество пакетов, отправленных в процентах от скорости линии для определенной скорости порта. Количество отправляемых кадров равномерно распределяется по интервалу T. Константа «C» может быть определена для обеспечения среднего времени между двумя равномерно расположенными последовательными пакетами.

Микропакет (Microburst)

Микропакет — это тип всплеска, при котором отбрасывание пакетов происходит, когда на канале или устройстве не наблюдается длительной или заметной перегрузки. Одна из характеристик микропакета состоит в том, что пакет распределяется неравномерно по T и меньше константы C (C = среднее время между двумя равномерно расположенными последовательными пакетами).

Интенсивность микропакета (Intensity of Microburst)

Интенсивность микропакета — это процентная доля, представляющая уровень от 1 до 100% микропакета. Чем выше число, тем выше микропакет.

I=[1-[ (Tp2-Tp1)+(Tp3-Tp2)+….(TpN-Tp(n-1) ] / Sum(packets)]]*100

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

6.1.2. Обсуждение

При измерении буферизации на тестируемом устройстве важно понимать поведение каждого порта. Это предоставляет данные для общего объема буферизации, доступной на коммутаторе. Условия эффективности буфера помогают понять оптимальный размер пакета для буфера или реальный объем буфера, доступный для определенного размера пакета. В этом разделе не обсуждается, как проводить методологию тестирования; вместо этого он объясняет определения буфера и какие показатели должны быть предоставлены для всестороннего сравнительного анализа буферизации устройств центра обработки данных.

6.1.3. Единицы измерения

Когда измеряется буфер DUT:

• Размер буфера ДОЛЖЕН быть измерен.
• Размер буфера порта МОЖЕТ быть предоставлен для каждого порта.
• Максимальный размер буфера порта ДОЛЖЕН быть измерен.
• Максимальный размер буфера DUT ДОЛЖЕН быть измерен.
• Интенсивность микропакета МОЖЕТ быть упомянута при проведении испытания микропакета.
• ДОЛЖНО быть указано значение CoS или DSCP, установленное во время теста.

6.2. Incast

6.2.1. Определение

Термин «Incast», очень часто используемый в центре обработки данных, относится к моделям трафика «многие к одному» или «многие ко многим». Как определено в этом разделе, он измеряет количество входных и выходных портов и процент синхронизации, приписываемый им. Как правило, в центре обработки данных он ссылается на множество различных портов входящего сервера (многие), отправляя трафик на общую восходящую линию (многие-к-одному) или на несколько восходящих линий (многие-ко-многим). Этот шаблон обобщен для любой сети, поскольку многие входящие порты отправляют трафик на одну или несколько восходящих линий.

Синхронное время поступления (Synchronous arrival time)

Синхронное время поступления — это когда два или более кадров размеров L1 и L2 поступают в их соответствующие входные порты или несколько входных портов, и существует перекрытие времени поступления для любого из битов на проверяемом устройстве, тогда кадры L1 и L2 имеют синхронный приход раз. Это называется «Incast», независимо от того, является ли шаблон много-к-одному (проще) или много-ко-многим.

Асинхронное время прибытия (Asynchronous arrival time)

Асинхронное время прибытия — это любое условие, не определяемое «синхронным временем прибытия».

Процент синхронизации (Percentage of synchronization)

Процент синхронизации определяет уровень перекрытия (количество битов) между кадрами размеров L1, L2..Ln.

Пример: два 64-байтовых кадра длиной L1 и L2 поступают на входной порт 1 и порт 2 проверяемого устройства. Между ними имеется перекрытие в 6,4 байта, где кадры L1 и L2 были одновременно на их соответствующих входных портах. Поэтому процент синхронизации составляет 10%.

Трафик с отслеживанием состояния (Stateful traffic)

Трафик с отслеживанием состояния — это пакеты, обмен которыми осуществляется с помощью протокола с отслеживанием состояния, такого как TCP.

Трафик без состояния (Stateless traffic)

Трафик без состояния — это пакеты, обмен которыми осуществляется с помощью протокола без состояния, такого как UDP.

6.2.2. Обсуждение

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

В любом случае, независимо от того, где находится буферная память в архитектуре коммутатора, Incast создает использование буфера.
Когда один или несколько кадров имеют синхронные времена прибытия в DUT, они считаются формирующими Incast.

6.2.3. Единицы измерения

НЕОБХОДИМО измерить количество входных и выходных портов.

НЕОБХОДИМО иметь ненулевой процент синхронизации, который ДОЛЖЕН быть указан.

7. Пропускная способность приложений: центр обработки данных Goodput

7.1. Определение

В сетях центров обработки данных сбалансированная сеть является функцией максимальной пропускной способности и минимальных потерь в любой момент времени. Это фиксируется Goodput [TCP-INCAST].

Goodput

Goodput — это пропускная способность на уровне приложений. Для стандартных приложений TCP очень маленькая потеря может оказать существенное влияние на пропускную способность приложения. [RFC2647] предоставляет определение Goodput; определение в этом документе является вариантом этого определения.

Goodput — это количество битов за единицу времени, отправляемое на правильный интерфейс назначения DUT, за вычетом любых повторно переданных битов.

7.2. Обсуждение

В бенчмаркинге центров обработки данных полезный результат — это значение, которое СЛЕДУЕТ измерять. Это дает реалистичное представление об использовании доступной пропускной способности. Цель в средах центров обработки данных — максимизировать производительность при минимальных потерях.

7.3. Единицы измерения

Гудпут, G, затем измеряется по следующей формуле:

G = (S / F) x V байт в секунду

• S представляет байты полезной нагрузки, не включая заголовки пакетов или TCP
• F — размер кадра
• V — скорость носителя в байтах в секунду

Пример: передача файлов по протоколу TCP через HTTP на носителе 10 ГБ/с.

Файл не может быть передан через Ethernet как один непрерывный поток. Он должен быть разбит на отдельные кадры по 1500 Байт, когда используется стандартный MTU. Каждый пакет требует 20 B информации заголовка IP и 20 B информации заголовка TCP; следовательно, 1460 B доступны для каждого пакета для передачи файла. Системы на основе Linux дополнительно ограничены 1448 B, поскольку они также имеют отметку времени 12 B. Наконец, в этом примере дата передается по Ethernet, что добавляет 26 B накладных расходов на пакет к 1500 B, увеличивая ее до 1526 B.

G = 1460/1526 x 10 Гбит / с, что составляет 9,567 Гбит / с или 1,196 ГБ / с.

Обратите внимание: в этом примере не учитываются дополнительные издержки Ethernet, такие как межкадровый интервал (минимум 96 битов), а также не учитываются коллизии (которые имеют различное влияние в зависимости от нагрузки сети).

При проведении измерений Goodput, пожалуйста, документируйте, помимо пунктов, перечисленных в разделе 4.1, следующую информацию:

• Используется стек TCP
• Версии ОС
• Версия и модель прошивки интерфейса сетевой платы (NIC — Network Interface Card)

Например, стеки Windows TCP и разные версии Linux могут влиять на результаты теста на основе TCP.

8. Вопросы безопасности

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

Топология эталонной сети будет независимой тестовой установкой и НЕ ДОЛЖНА подключаться к устройствам, которые могут перенаправлять тестовый трафик в производственную сеть или перенаправлять трафик в сеть управления тестированием.

Кроме того, бенчмаркинг выполняется по принципу «черного ящика», опираясь исключительно на измерения, наблюдаемые вне DUT.

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

9. Соображения IANA

Этот документ не требует никаких действий IANA.

10. Ссылки

10.1. Нормативные ссылки

[RFC1242] Bradner, S., «Benchmarking Terminology for Network Interconnection Devices», RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC2544] Bradner, S. and J. McQuaid, «Benchmarking Methodology for Network Interconnect Devices», RFC 2544, DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>.

[RFC5481] Morton, A. and B. Claise, «Packet Delay Variation Applicability Statement», RFC 5481, DOI 10.17487/RFC5481, March 2009, <https://www.rfc-editor.org/info/rfc5481>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8239] Avramov, L. and J. Rapp, «Data Center Benchmarking Methodology», RFC 8239, DOI 10.17487/RFC8239, August 2017, <https://www.rfc-editor.org/info/rfc8239>.

10.2. Информационные ссылки

[RFC2432] Dubray, K., «Terminology for IP Multicast Benchmarking», RFC 2432, DOI 10.17487/RFC2432, October 1998,

<https://www.rfc-editor.org/info/rfc2432>.

[RFC2647] Newman, D., «Benchmarking Terminology for Firewall Performance», RFC 2647, DOI 10.17487/RFC2647, August 1999,
<https://www.rfc-editor.org/info/rfc2647>.

[RFC2889] Mandeville, R. and J. Perser, «Benchmarking Methodology for LAN Switching Devices», RFC 2889, DOI 10.17487/RFC2889, August 2000,
<https://www.rfc-editor.org/info/rfc2889>.

[RFC3918] Stopp, D. and B. Hickman, «Methodology for IP Multicast Benchmarking», RFC 3918, DOI 10.17487/RFC3918, October 2004,

<https://www.rfc-editor.org/info/rfc3918>.

[TCP-INCAST] Chen, Y., Griffith, R., Zats, D., Joseph, A., and R. Katz, «Understanding TCP Incast and Its Implications for Big Data Workloads», April 2012, <http://yanpeichen.com/professional/usenixLoginIncastReady.pdf>.

Благодарности

Авторы хотели бы поблагодарить Эла Мортона (Al Morton), Скотта Брэднера (Scott Bradner), Иана Кокса (Ian Cox) и Тима Стивенсона (Tim Stevenson) за их отзывы и обратную связь.

Адреса авторов

Lucien Avramov
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: lucien.avramov@gmail.com

Jacob Rapp
VMware
3401 Hillview Ave.
Palo Alto, CA 94304
United States of America
Email: jhrapp@gmail.com