«Слоны» в сетях Ethernet

     Хотя со времен Крылова дефицит слонов значительно уменьшился, встретить их на улице все так же трудно. Другое дело — сети Ethernet. Стремительное развитие сетевых технологий указывает на то, что в скором времени "пакеты-слоны" станут стандартом в скоростных вариантах сетей. Речь идет о Jumbo Frames (Jumbo — кличка циркового слона) — Ethernet-пакетах большой длины. Предложение увеличить максимальную длину поля MAC Client Data в пакете Ethernet с 1500 до 9000 байт выдвинула компания Alteon Networks в 1998 г. Каковы же истоки этой инициативы?

     Сегодня скоростные сети Ethernet (Fast/Gigabit) все еще используют пакеты, разработанные 20 лет назад для более скромной 10-мегабитовой технологии. Это значит, что обмен данными осуществляется порциями, которые не могут превышать 1,5 KB. Подобные пакеты вполне подходили для относительно низкоскоростных сетей, предназначенных в основном для файл-серверных операций и разделения дорогостоящей периферии. Однако в последнее десятилетие функциональное использование сетей все дальше отходит от файл-серверной концепции. Распределенные вычисления, репликация данных и резервное копирование привели к значительному росту межсерверного трафика и необходимости пересылать большие блоки данных. Вследствие этого значительно возросли непроизводительные расходы на фрагментацию/сборку пакетов и обработку заголовков. Все это не вписывалось в возможности современных сетей и серверов. Но кто мог предвидеть столь радикальные изменения на заре Ethernet? Кстати, другие высокоскоростные технологии лучше приспособлены к нуждам современных сетевых вычислений. Так, для FDDI максимальный размер пакета (Maximum Transmission Unit, MTU) составляет 4500 байт, для сетей АТМ (уровень AAL5) MTU по умолчанию равен 9000 байт, а для Fibre Channel в типичном случае используются пакеты размером 65280 байт (теоретически MTU не ограничен). Однако инсталляционная база этих технологий по сравнению с Ethernet крайне невелика, что ставит пользователя в затруднительное положение.

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

     Взгляд со стороны сервера

     В условиях напряженного трафика обмен большими пакетами более эффективен, чем малыми. Дело в том, что над каждым пакетом (вернее, его заголовком) независимо от длины выполняется некоторая фиксированная последовательность операций. Вместе с тем, как правило, размер заголовка остается постоянным. Это значит, что анализ заголовка больших пакетов занимает столько же времени, сколько и малых, а для пересылки некоторого количества данных больших пакетов требуется меньше. Со стороны сервера-получателя меньшее число пакетов означает меньшее число прерываний от сетевой карты, поскольку в большинстве реализаций карта вырабатывает сигнал прерывания при получении пакета. Обработка каждого прерывания требует значительного количества циклов процессора. Если загрузка сервера невелика, то обработка прерываний остается незамеченной. Но в случае, когда процент утилизации процессора высок, ограничение потока прерывания может существенно улучшить производительность системы. Это особенно заметно в сетях Fast/Gigabit Ethernet, где серверы могут получать десятки тысяч или даже миллионы пакетов в секунду.

     Увеличение длины пакета позволяет также минимизировать количество циклов процессора при обмене с памятью. Компьютер оперирует с памятью так называемыми страницами, порциями памяти, равными (или кратными) 4 КВ. Поэтому для перемещения из/в память пакета объемом 8 КВ требуется выполнить только две операции копирования, в то время как для перемещения такого же объема данных с помощью пакетов размером 1,5 КВ необходимо шесть таких операций.
     

     Взгляд со стороны сети

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

     Результат — увеличение производительности

     Сравнение, выполненное Alteon Networks с помощью ряда стандартных тестов, продемонстрировало эффективность межсерверного обмена пакетами большого размера в случае высокой загрузки серверов. Так, при использовании пакетов длиной 9018 байт вместо стандартных Ethernet-пакетов (1518 байт) один из тестов показал увеличение почти на 50% эффективной полосы пропускания канала и одновременно снижение утилизации процессора на 50%. Это значит, что приложениям выделяется больше процессорного времени. Конечно, подсчитать точное количество сэкономленных циклов процессора трудно, но можно сделать приблизительную оценку. В типичном случае для обработки сетевого и транспортного уровней Ethernet-пакета необходимо приблизительно 1200 циклов процессора (из расчета 1000 машинных команд и по 1,2 цикла на команду). Пакет длиной 9018 байт содержит объем данных шести стандартных пакетов Ethernet. Таким образом, "сохраняется" 6000 циклов. При передаче файла объемом 10 MB эта величина превышает 8 млн. циклов.
     

     Некоторые критерии,
     определившие длину пакета

     Итак, пакеты большого размера обеспечивают превосходный трафик и повышают надежность сети. Следует ли из этого, что чем больше пакет, тем лучше? Необязательно. Дело в том, что верхний предел длины пакета определяется техникой контроля ошибок. При передаче пакета адаптер Ethernet формирует 32-битовый хвостовик (Frame Check Sequence, FCS) с контрольным кодом. Контрольный код является результатом выполнения некоторой математической операции над данными пакета (обычно это Cyclic Redundancy Check (CRC), так называемый контроль избыточным циклическим кодом). При приеме пакета адаптер выполняет такую же математическую операцию, и полученный результат сравнивается с кодом, записанным в хвостовике. При их несовпадении пакет считается искаженным. В Ethernet используется 32-разрядный избыточный код. Он гарантирует обнаружение ошибки в случае искажения одного, двух или трех бит для пакета данных длиной приблизительно от 376 до 11455 байт. Таким образом, с учетом страничной организации памяти мы получили уже два аргумента в пользу пакета длиной 9018/9022 байта (9000 байт — данные, 18/22 байта — заголовок и хвостовик для обычного/виртуального сегмента). Наконец, дополнительным аргументом могут служить размеры блоков, используемые многими популярными приложениями. Например, дейтаграмма NFS (Network File System), наиболее распространенной файловой системы в среде Unix, содержит 8400 байт. Это значит, что в один расширенный пакет Ethernet могут быть полностью инкапсулированы одна дейтаграмма NFS или, скажем, два пакета FDDI.
     

     Проблемы совместимости

     Однако все описанные выше "коврижки", получаемые от использования пакетов Ethernet большого размера, ничего не стоят, если не будет достигнута интероперабельность со стандартным оборудованием. К счастью, расширенными пакетами можно легко управлять в среде традиционной Ethernet либо с помощью физического сегментирования сети, либо посредством технологии виртуальных частных сетей (VPN), базирующейся на стандарте IEEE 802.1q (пакеты этого стандарта имеют дополнительное поле для соответствующего тега). На рисунке приведен пример возможной конфигурации сети, в которой используются как стандартный, так и расширенный пакеты. Самым простым способом, однако и самым дорогим, является физическая сегментация сети. Такое решение принимается в случае наличия серверов резервирования или при необходимости репликации больших объемов данных. Более эффективным с точки зрения затрат считается использование технологии виртуальных сетей. С ее помощью расширенные пакеты могут снабжаться специальными метками (тегами), на основании которых их можно направлять к узлам (например, коммутаторам или рабочим станциям), поддерживающим новый тип пакетов.