Повышение эффективности протоколов передачи данных в системах высокопроизводительных вычислений кластерной архитектуры Ахмед Набиль Мухаммед Мудхш

Содержание к диссертации

Введение

Глава 1. Анализ кластерных вычислительных систем 4

1.1 Развитие кластерных систем 13

1.2 Модель ускорения для кластерной архитектуры 17

1.3 Ярусно-параллельная форма 24

1.4 Оборудование кластера 32

1.5 Программные приложения для кластера 38

1.6 Оценка возможной оптимизации 42

1.7 Выбор тестов 46

Вывод по главе 1 48

Глава 2. Сетевой стек Linux 50

2.1 Общие сведения о высокоскоростных сетях 50

2.2 Сетевая подсистема Linux 53

2.3 Получение пакета в Linux в общем случае 54

2.4 Отправка пакета в Linux в общем случае 59

Вывод по главе 2 61

Глава 3. Разработка интерфейса для реализации протоколов 63

3.1 Возможная оптимизация 63

3.2 Реализация протокола 65

3.3 Детали реализации 69

3.4 Методика повышения эффективности 71

3.4 Отличия от аналогичных средств 76

Вывод по главе 3 78

4. Тестирование реализации интерфейса 79

4.1 Методы тестирования сетевой инфраструктуры вычислительного кластера 79

4.2 Характеристики системы 82

4.3 Характеристики узлов 85

4.4 Результаты тестирования 86

4.5 Анализ результатов 93

Вывод по главе 4 97

Заключение 99

Библиографический список 102

Приложения 110

• Модель ускорения для кластерной архитектуры
• Получение пакета в Linux в общем случае
• Методика повышения эффективности
• Результаты тестирования

Введение к работе

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

производительности сетевого взаимодействия (например, Open OnLoad, DPDK, Netmap, PF_RING). Развитие разработанных средств продолжается, на основе существующих решений появляются новые (например, PF_RING DNA). Многие решения нацелены на оптимизацию работы уже имеющегося оборудования (например, DPDK, Netmap). Учитывая высокую активность разработчиков в данной области, высокую практическую значимость решений в данной области и фактическое отсутствие результатов для сетей вычислительных кластеров, можно считать выбранную тему работы актуальной.

Использование стека TCP/IP для передачи данных в рамках вычислительных кластеров может ограничить масштабируемость из-за накладных расходов (относительно сложная обработка на узле; сложная работа самого протокола; копирование данных; накладные расходы из-за обработки системных вызовов и обработки прерываний). Для получения лучшей производительности, в некоторых системах реализация сетевого стека, в том числе реализация TCP/IP, работает непосредственно в режиме ядра и является неотъемлемой частью операционной системы. С другой стороны, есть решения, которые «помещают» сетевой стек наоборот в пространство пользователя и организуют работу особым образом, снижая, например, накладные расходы на выполнение системных вызовов. Эффективность этих систем обусловлена специальным аппаратным обеспечением сетевых карт, обеспечивающим прямой доступ к структурам данных NIC. В других случаях также специализированное оборудование позволяет организовать удаленный прямой доступ к памяти, RDMA (например, Infiniband). Таким образом, когда речь заходит о высокопроизводительных вычислениях, нестандартные подходы и новые решения — чуть ли не единственный способ добиться требуемой производительности и масштабируемости.

В то же время стек TCP/IP — надежное, проверенное временем решение, зарекомендовавшее себя с лучшей стороны за несколько десятилетий. Он обеспечивает отказоустойчивость и обладает способностью адаптироваться к свойствам объединенной сети. Реализацию стека TCP/IP в ядре операционной системы Linux можно назвать одной из лучших. Она очень надежна и обладает отличной производительностью.

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

В работе рассматриваются средние по числу узлов вычислительные кластеры, использующие Ethernet для организации сетевого взаимодействия, с ОС Linux на узлах. Такие кластеры широко распространены, например, в университетской среде. К такому типу относятся недорогие, средние по числу узлов кластеры и Beowulf-кластеры. Несмотря на их распространенность, внимание исследователей, как правило, обращено к HPC-системам, использующим дорогостоящие "заказные" сети и специализированные протоколы.

Однако результаты данной работы могут быть применены и к

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

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

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

Объект исследования

Компьютерные сети (Gigabit Ethernet).

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

Компьютерные сети (Gigabit Ethernet) вычислительных кластеров с ОС Linux на узлах.

Цель работы и задачи исследования

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

с ОС Linux. В качестве критериев эффективности рассматриваются производительность и задержка сети.

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

разработка методики для повышения надежности и эффективности сетевого взаимодействия для средних вычислительных кластеров с ОС Linux на узлах, использующих Ethernet, с учетом особенностей их использования;

разработка архитектуры и программного решения (интерфейса) для реализации новых протоколов на уровне ядра, позволяющего оптимизировать пересылку данных в рамках использования стандартных средств ОС Linux;

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

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

тестирование указанной реализации интерфейса на кластере.
Методы исследования

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

Научная новизна

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

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

3. Предложена методика повышения производительности сети для вычислительных кластеров. В отличие от других методик данная методика нацелена на повышение производительности с использованием имеющегося оборудования. В рамках методики предложен способ реализации стека сетевых протоколов и организации работы сетевого стека для ОС Linux, сформулированы требования к другим компонентам ОС, отвечающим за работу с сетью.

4. Разработана архитектура и создано программное решение (интерфейс) для разработки новых сетевых протоколов на основе методики как в пространстве ядра, так и в пространстве пользователя. В рамках интерфейса предусмотрен ряд оптимизаций. В отличие от других решений (например, DPDK, Netmap, PFRING) данное решение ориентировано на использование в рамках вычислительных кластеров для прикладных пользовательских расчетов, а не для разработки сетевых сервисов. Также к отличиям относится использование существующих средств в рамках ОС Linux, без необходимости их изменения, например, изменения существующего API или изменения разработанных драйверов сетевых карт.

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

Значимость полученных результатов для теории и практики:

Практическая значимость состоит в возможности применения полученных результатов для широко распространенного типа вычислительных кластеров: Ethernet-кластеры с ОС Linux на узлах. Подобные кластеры встречаются как у небольших организаций, так и на крупных предприятиях, желающих избежать привязки к конкретному поставщику; ОС Linux используется в рамках большинства суперкомпьютеров кластерной архитектуры списка «ТОР-500». Именно поэтому диагностика потенциальных проблем и оптимизация работы указанных систем являются важными задачами. В рамках данной работы основное внимание было уделено повышению производительности не за счет использования и разработки принципиально новых систем, а за счет оптимизации работы уже имеющихся систем. Для работы используется стандартное оборудование, что позволяет экономить средства: нет необходимости в закупке нового дорогостоящего оборудования для оптимизации работы. Предложенная методика позволяет оптимизировать сетевое взаимодействие уже имеющихся систем. Программное решение предлагает для прикладного приложения стандартный интерфейс сокетов, поэтому нет необходимости в существенном изменении имеющегося, отлаженного программного обеспечения. В отличие от других решений используются стандартные средства ОС Linux.

Таким образом, перечисленные ниже пункты являются практически значимыми:

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

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

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

Основные положения, выносимые на защиту

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

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

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

Степень обоснованности и достоверности полученных научных результатов

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

Внедрение результатов

Полученные практические результаты используются в рамках учебного кластера кафедры КММС факультета ПМ-ПУ СПбГУ. Указанный интерфейс используется в рамках учебного процесса для изучения особенностей работы реализации сетевого стека в ОС Linux.

Апробация

Основные научные результаты были озвучены на 7 конференциях: 1. ХХ Международная научно-методическая конференция «Современное образование: содержание, технологии, качество». СПбГЭТУ “ЛЭТИ”, 2014 г

2. Научно-техническая конференция профессорско-преподавательского состава. СПбГЭТУ “ЛЭТИ”, 2015 г.

3. XLVI международная научная конференция «Процессы управления и устойчивость» (Сontrol Processes and Stability, CPS’15). СПбГУ, 2015 г.

4. The 15th International Conference on Computational Science and Its Applications (ICCSA 2015). Канада, 2015 г.

5. 10th International Conference on Computer Science and Information Technologies (CSIT 2015). Армения, 2015 г.

6. Научно-техническая конференция профессорско-преподавательского состава. СПбГЭТУ
“ЛЭТИ”, 2016 г.

7. The 7th International Conference "Distributed Computing and Grid-technologies in Science and
Education" (GRID 2016). Россия, 2016 г.

Публикации

Основные теоретические и практические результаты диссертации опубликованы в 9 статьях и докладах, из них по теме диссертации 9, из них 2статьи, входящие в ведущие рецензируемые издания, рекомендованные в действующем перечне ВАК РФ, 3 статьи опубликованы в зарубежных изданиях, индексируемых в базе Scopus,3 публикаций опубликованы в других изданиях и материалах конференций, 1 свидетельство программы ЭВМ.

Структура и объем диссертации

Диссертационная работа состоит из введения, четырёх глав, заключения,списка использованной литературы, приложение. Работа содержит 114 страниц основного текста, 3 таблиц, 27 рисунков. Список использованной литературы включает 81 наименование.

Модель ускорения для кластерной архитектуры

Главным показателем, определяющим эффективность работы параллельного приложения на кластере (в сравнении с последовательной версией) является ускорение.

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

Если взять a — долю последовательных вычислений в рамках алгоритма, то получим ускорение равное (по закону Амдаля [33]): SN

На рисунке 1.6 представлен график ускорения по закону Амдаля для доли последовательных вычислений, равной 20% .

Однако в указанной формуле не учтено время передачи данных между процессорами, находящимися на разных узлах кластера, а для кластерной архитектуры это время может являться существенным, поэтому его необходимо учитывать. В случае кластерной архитектуры введем параметр tij - время сетевого взаимодействия между двумя процессорными ядрами (возможно, на разных узлах кластера), i и j. Тогда получим следующую формулу для времени выполнения параллельного приложения на N процессорных ядрах (на нескольких узлах):

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

Где C(i) — функция, соответствующая расстоянию между узлами, dij — параметр, характеризующий соединения процессорных ядер между собой (таким образом учитывается и вариант многоядерных узлов кластера), t0 — характерное время (некоторое значение). Если предположить, что процессоры одинаково загружены расчетами и обменом данными, то получим следующую формулу:

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

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

Оптимальное число процессорных ядер (или узлов в случае одного одноядерного процессора на узел) в данном случае будет равняться:

И максимальной ускорение (при использовании Nopt числа процессорных ядер) будет равно: (1 - а) а +

2 Nopt Для удобства обозначим:

п = р у Тогда n будет параметром, характеризующим скорость обмена данными между процессорными ядрами. Этот параметр будет учитывать особенности архитектуры и отношение производительности процессорного ядра к производительности сети. Тогда формула для ускорения примет вид: (l-a) + a N + n N3 Тогда для фиксированных a и N (например, доля последовательных вычислений равна 20% (a=0.2), а число процессорных ядер равно 8 (N=8)) график зависимости SN от n будет иметь вид, представленный на рисунке 1.8.

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

Главным фактором, влияющим на значение данного параметра в рамках типичной кластерной архитектуры является производительность сети. Параметр n равен:

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

На рисунке 1.9 представлены графики зависимости ускорения от числа процессорных ядер для различных значений n, близких к 0.

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

Получение пакета в Linux в общем случае

В общем случае процедура получения пакета для типичного узла Ethernet-кластера в рамках ОС Linux выглядит следующим образом [51].

Сетевая карта записывает полученный пакет по DMA в текущий буфер (указываемый текущим дескриптором кольцевого буфера для приема пакетов), если есть свободный буфер. Если свободного буфера нет, пакет отвергается. Это может сказаться на производительности: приведет к повторной передаче данных или приведет к потере данных.

Сетевая карта генерирует прерывание.

Обработчик прерывания — код ОС, который вызовет зарегистрированную (например, с помощью «request_irq») функцию драйвера сетевой карты.

Упомянутая функция драйвера сетевой карты (работая в контексте «top half» -в контексте прерывания) выполнит необходимые проверки и в случае их успеха, создаст экземпляр структуры «struct skbuff» (представляющей полученный пакет в рамках ОС Linux).

Далее, эта функция может скопировать данные пакета (включая заголовки уровня 2 модели OSI — то есть, заголовки Ethernet — скопировать весь пакет, каким он пришел по сети) из буфера, связанного с дескриптором в кольцевом буфере для приема пакетов, в новый буфер (выделив для него память) и пометить использованный элемент как свободный (через дескрипторы, формат которых зависит от конкретной сетевой карты, так как сетевая карта должна «понимать» этот формат). Но есть и другой вариант — функция вместо копирования пакета может заменить упомянутый буфер, то есть «отдать» этот буфер вверх по сетевому стеку ОС, а вместо него выделить новый буфер и указать адрес нового элемента в дескрипторе. Решение, принятое в рамках данного вопроса разработчиками драйвера сетевой карты, может серьезно повлиять на производительность, так как копирование данных занимает значительное время. Конечно, на это решение могут повлиять, к примеру, аппаратные ограничения сетевой карты.

Затем функция задает необходимые поля экземпляра «struct skbuff», в том числе поле «protocol» - протокол третьего уровня модели OSI, определенный по полю «тип/длина» заголовка Ethernet.

Наконец, функция планирует обработку пакета в контексте «bottom half» (в современных версиях ядра это будет, скорее всего, «softirq»), например, с помощью вызова функции «netif_rx».

В контексте «bottom half» (уже с разрешенными прерываниями) будет выполнена функция вроде «__netif_receive_skb», которая продолжит обработку пакета: передаст его «сырым сокетам» (если таковые есть), в зависимости от типа протокола третьего уровня передаст пакет соответствующей реализации протокола третьего уровня, например, IPv4, которая может быть тесно связана с реализацией протокола 4 уровня, например, TCP (в итоге вызывается функция, зарегистрированная через «dev_add_pack»).

В рамках указанной реализации продолжится обработка пакета в соответствии с особенностями протокола. Здесь же могут быть, например, различные фильтры (например, «netfilter» («iptables») в случае IPv4). Использование подобных сетевых фильтров также может сказаться на производительности. Учитывая что узлы кластера, как правило, расположены в локальной, хорошо защищенной сети, использование сетевого фильтра (надежно обеспечивающего безопасность в общем случае) может оказаться нецелесообразным по причине надежности сети (в плане безопасности) и потенциального снижения производительности.

Наконец, после всех проверок, пакет (представленный экземпляром «struct skbuff») будет добавлен в очередь для приема пакетов сокета, для которого предназначен пакет (если таковой имеется). Если в ожидании получения пакета на этом сокете есть процесс («спящий» процесс), он будет снова помечен как планируемый (будет «разбужен»). Когда этот процесс продолжит выполнение (в рамках системного вызова), он «увидит» пришедший пакет и сможет передать его пространству пользователя. Если подобного процесса не будет, пакет просто останется в очереди. Если очередь заполнится, новые пакеты будут отвергаться. А это, разумеется, может сказаться на производительности: в случае протокола с подтверждениями понадобится повторная передача, без подтверждений — данные просто будут утеряны.

Когда пользовательский процесс выполнит системный вызов вроде «recv», в рамках системного вызова будет проверена очередь для приема пакетов соответствующего сокета (вызывается функция реализации протокола четвертого уровня, указанная в поле «recvmsg» структуры, указанной в поле «ops» в «struct socket»). Если она пуста и вызов блокирующий, процесс «заснет» и будет «разбужен», когда пакет будет добавлен в очередь (как описано выше). Если же вызов неблокирующий, пользовательское приложение «поймет», что пакетов нет. В этом случае оно может повторить системный вызов. Подобный опрос в цикле может уменьшить задержку получения данных, однако, за счет сильной загрузки центрального процессора. Наконец, стоит упомянуть о передаче данных пользовательскому процессу. В общем случае она подразумевает копирование данных из буфера ядра в пользовательский (область памяти, выделенную для пользовательского процесса, которую тот указал для получения пакета). Такое копирование, разумеется, может сказаться на производительности. Избежать подобного копирования и повысить производительность могут помочь методики zero-copy.

Если рассмотреть развитие ввода-вывода сети, то можно увидеть ввод-вывод с активным ожиданием, ввод-вывод с прерываниями, ввод-вывод с DMA. Далее разработчиками были сделаны попытки использования некоторых методов по уменьшению числа прерываний (и связанных с ними накладных расходов) -различные техники «interrupt mitigation». Узлы кластера, как правило, загружены получением данных. При большом числе поступающих пакетов, сетевая карта будет постоянно сигнализировать о пришедших пакетах — генерировать прерывания. Обработка прерывания - довольно затратная процедура. Она требует сохранения текущего состояния (программный счетчик, регистр флагов, регистры, используемые обработчиком прерывания, зачастую — все регистры общего назначения) и его восстановления по обработке прерывания. И это помимо использования кэша, использования записей TLB.

Поэтому частые прерывания могут серьезно сказаться на производительности пользовательского приложения, могут существенно загрузить работой центральный процессор. Для того, чтобы как-то «сгладить» ситуацию, часто используются различные методики «interrupt mitigation». NAPI — одна из них. Это интерфейс (NAPI - «New API»), используемый в рамках ОС Linux как раз для снижения числа прерываний и, тем самым, «разгрузки» центрального процессора (для других задач). В случае использования NAPI указанная выше процедура обработки поступившего пакета меняется следующим образом.

- Драйвер сетевой карты вместо фактической обработки пакета запрещает прерывания от сетевой карты и планирует опрос NAPI (например, с помощью функции «napi_schedule»).

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

Методика повышения эффективности

С учетом результатов тестов (описанных в главе 4) можно предложить следующую методику повышения эффективности работы сети вычислительного Ethernet-кластера с ОС Linux на узлах.

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

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

1.1. Использование простой адресации (все узлы, как правило, находятся в одном VLAN).

1.2. Использование простых средств для маршрутизации (в рамках среднего вычислительного кластера для передачи пакета от одного узла до другого, как правило, используются лишь коммутаторы и пакет не выходит за пределы одного VLAN).

1.3. Использование упрощенного варианта управления потоком (характеристики узлов известны заранее и практически не изменяются за время эксплуатации кластера).

1.4. Использование меньшего количества контрольных сумм (на разных уровнях) – возможно, всего одной (оборудование кластера надежно, узлы расположены в рамках одного центра).

1.5. Использование явные уведомлений о перегрузке (позволит ускорить выявление факта возникновения перегрузки и упростить решение проблемы (например, упростить реализацию алгоритма борьбы с перегрузкой на узле)).

1.6. Использование упрощенных алгоритмов для обеспечения качества обслуживания (некоторые параметры можно рассчитать заранее).

1.7. Использование простых заголовков на разных уровнях. При этом, время обработки пакета важнее, чем размер заголовка в случае сети вычислительного кластера. Фиксированный формат заголовка позволит упростить обработку пакета и даст возможность использования дополнительных вариантов оптимизации. 1.8. В случае использования кластера для одного конкретного приложения – максимально возможное упрощение используемого стека протоколов для конкретного случая (в этом случае многие параметры можно рассчитать и задать статически). В случае использования кластера для множества приложений, например, в рамках вычислительного центра, такое упрощение затруднено (см. раздел 1.5 данной работы), поэтому следует сосредоточиться на реализации стека протоколов и конфигурировании системы.

2. Изменения реализации стека протоколов в рамках ОС Linux для узлов среднего вычислительного кластера, использующего Ethernet.

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

2.2. Отправка нескольких пакетов в рамках одного системного вызова.

2.3. Возможность отправки пакета без использования qdisc.

2.4. Возможность отправки пакета без передачи пакета «сырым сокетам».

2.5. Возможность использования активного ожидания в рамках системного вызова для приема пакета (например, в случае работы на узле одного приложения, требовательного ко времени).

2.6. Для пользовательского приложения предоставляется стандартный интерфейс сокетов (нет необходимости в существенном изменении существующих программ).

3. Требования при реализации стека протоколов в рамках ОС Linux на уровне пользователя для узлов среднего вычислительного кластера, использующего Ethernet.

3.1. Для организации работы множества процессов можно использовать различные средства IPC.

3.2. Для пользовательского интерфейса предоставляется стандартный интерфейс сокетов.

3.3. Для модуля ядра, предоставляющего интерфейс, применимы предложения, сформулированные в пункте 2.

4. Требования к реализации драйверов сетевых карт для современных версий ОС Linux.

4.1. Использование интерфейса NAPI (для уменьшения накладных расходов, связанных с обработкой прерываний).

4.2. Задание новых буферов для приема данных в случае приема пакета для устранения дополнительного копирования (экземпляр «struct sk_buff» указывает на буфер с полученными данными, для текущего элемента выделяется новый буфер, и задается через дескриптор).

4.3. Использование аналогичной техники при отправке пакета (устраняется дополнительное копирование).

4.4. Использование возможностей, предоставляемых техниками вроде «Header Split» (запись заголовков поддерживаемых протоколов уровней 2-4 в отдельный буфер), если поддерживается сетевой картой.

5. Изменения конфигурации ОС Linux на узлах вычислительного Ethernet-кластера.

5.1. Использование максимально возможного MTU (например, 9 Кбайт для случая «Jumbo Frames»).

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

5.3. Использование больших значений (рассчитывается с учетом конкретных характеристик узла и требований к системе) для объема данных в очередях сокета для приема данных и для отправки данных. 5.4. Использование техник GSO/GRO (для поддерживаемых стеков протоколов сетевой картой) [70,71].

5.5. Задание высокого значения NAPI budget.

5.6. Изменение конфигурации ядра Linux (и сборка ядра с такой конфигурацией).

5.6.1. Отказ от использования «kernel preemption». В случае вычислительного сервера это снизит накладные расходы, связанные с планированием и переключением контекста за счет снижения интерактивности, что приемлемо для вычислительного сервера (CONFIG_PREEMPT_NONE=y).

5.6.2. Использование «tickless» системы. Это позволит снизить накладные расходы, связанные с обработкой прерываний от системного таймера (CONFIG_NO_HZ_FULL=y).

5.6.3. В случае кластера, недоступного из внешней сети (типичный случай для вычислительного кластера) отказ от использования сетевых фильтров (CONFIG_NETFILTER=n).

5.6.4. Отказ от использования специальных средств для обеспечивания качества обслуживания (qdisc, cgroups).

5.6.5. Отказ от использования специальных средств мониторинга и аккаунтинга.

5.6.6. Отказ от других средств, дающих накладные расходы в случае вычислительного кластера (зависит от конкретной версии системы и требований).

6. Конфигурация запуска вычислительного приложения на узле с ОС Linux.

6.1. Задание высокого приоритета процесса («nice value» для обычного процесса, возможно использование realime приоритета).

6.2. Задание оптимального NUMA-узла (например, узла с большим объемом оперативной памяти; узла с процессором, подключенным к сетевой карте PCI Express «напрямую» - если контроллер PCI Express интегрирован в процессор).

Результаты тестирования

На рисунке 4.2 представлена зависимость времени передачи файла (размером 900 МБ) в зависимости от параметров tcp_rmem (net.ipv4.tcp_rmem): три параметра, соответствующие минимальному объему данных пакетов в очереди сокета для приема пакетов, этому значению по умолчанию и его максимальному значению.

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

Что и происходит – это видно по графику (особенно для случая ограничения на максимальное число байт пакетов в очереди – 10000 байт и 20000 байт). Так как используется TCP, потери данных не происходит, но происходит повторная передача, что и сказывается на производительности (75 секунд в случае значения параметров 10000 байт, а в случае значения 100000 байт – всего лишь 16 секунд).

Таким образом, указанный параметр может существенно повлиять на производительности сети. К слову, данный параметр может иметь небольшое значение по умолчанию во многих дистрибутивах ОС Linux.

На рисунке 4.3 представлена зависимость времени выполнения теста «отправка-ожидание-получение» для TCP/IP в зависимости от того, используется ли GSO/GRO или нет. В случае TCP/IP заметно ощутимое снижение времени выполнения без GSO/GRO, поскольку, к примеру, в рамках GSO реализовано несколько стадий обработки пакета: выполняется разбивка данных на пакеты, формирование заголовков, подсчет контрольных сумм на различных уровнях

Подобные техники разгружают процессор. И даже если выигрыш по времени невелик, данные техники освобождают процессор для других задач. В случае теста «отправка-ожидание-получение» для TCP/IP было получено заметное повышение производительности. В совокупности с разгрузкой процессора использование подобных техник (если сетевой адаптер поддерживает их) повышает производительность расчетов и может быть рекомендовано для вычислительных кластеров.

На рисунке 4.4 представлены результаты теста «передача файла» на серверных узлах. Рисунок 4.4. Результаты теста «передача файла» на серверных узлах В данном случае можно выполнить большую часть работы параллельно, что и объясняет результаты теста: разница практически незаметна.

В то время как в случае теста «отправка-ожидание-получение» (рассмотрено далее) можно видеть разницу: реализация модуля ядра в среднем показала производительность, лучше остальных (хотя разница и невелика). Это объясняется тем, что в случае десктопных узлов нет никакой аппаратной разгрузки и таким образом, результаты зависят исключительно от программного стека и конфигурации программного обеспечения. Реализация «сырых сокетов» показывает результаты, подобные модулю ядра, однако, когда нет никаких других сетевых приложений. Иначе (например, в случае передачи файлов большого объема параллельно с данным тестом) она показывает худшую производительность (потому что обрабатываются все пакеты, как связанные с тестом, так и все остальные).

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

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

На рисунке 4.5 представлены результаты выполнения теста «отправка-получение-ожидание» с использованием блокирующих и неблокирующих системных вызовов. Речь здесь идет о системном вызове «recv» (или подобных). В случае блокирующего вызова «recv» процесс «заснет», если в очереди для приема данных нужного сокета нет данных (например, пакеты с данными еще не пришли). Когда пакеты поступят, процесс будет снова помечен как планируемый (будет «разбужен»). Когда этот процесс продолжит выполнение (в рамках системного вызова), он «увидит» пришедший пакет и сможет передать его пространству пользователя. Однако возобновление процесса получения данных пакета может произойти не сразу (после того как пакет пришел – процесс может не сразу быть поставлен на выполнение, хотя он и будет помечен как планируемый – по получении пакета ОС просто пометит процесс как планируемый, но, скорее всего, не станет сразу переключать контекст с текущего (менять процесс, считающийся на процессоре)). Рисунок 4.5. Результаты теста «отправка-получение-ожидание» (реализация интерфейса): блокирующие и неблокирущие системные вызовы; размер сообщения — 5000 байт. Накладные расходы в этом случае могут снизить производительность. В случае неблокирующего вызова «recv» процесс не «заснет», если в очереди для приема данных нужного сокета нет данных – вместо этого системный вызов сразу завершится и процесс «поймет», что в очереди нет пакетов. В случае указанных тестов в таком случае процесс будет снова и снова выполнять «recv» (это сделано в реализации пользовательского приложения – в реализации теста): процесс будет проверять и проверять наличие пакетов в очереди, снова и снова, до тех пор, пока пакет не придет. Это может снизить задержку с момента получения пакета, до его обработки приложением. Что видно по графикам. Однако такой подход полностью загрузит процессор – он будет снова и снова проверять очередь сокета для приема данных. Также в рамках реализации интерфейса предусмотрена возможность активного ожидания (рассмотрена далее). Вариант «с опросом – неблокирующий» по сути излишен, так как в этом случае выполняется опрос в рамках системного вызова, однако, предусмотрена возможность такого опроса и в пользовательском приложении. Он выполнен просто для проверки всех возможных вариантов.

На рисунке 4.6 приведена сводная диаграмма результатов теста «отправка-получение-ожидание».