Эволюция архитектуры виртуального интерфейса

Вернер Фогельс,Торстен фон Айкен

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

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

К сожалению, несовместимость предлагаемых решений и нежелание производителей идти на компромисс препятствуют дальнейшему прогрессу и не позволяют воплотить полученные достижения исследователей в конкретные продукты. А ведь именно практическая реализация могла бы создать необходимые предпосылки для действительно широкого распространения данных интерфейсов. Корпорации Intel, Microsoft и Compaq предложили новую спецификацию Virtual Interface Architecture [1], предназначенную для построения кластерных архитектур и системных сетей. Коммерческие продукты, соответствующие спецификациям VIA, уже представлены (в качестве примера можно привести сетевой интерфейс GNN1000 компании GigaNet, http://www.giganet.com). Технология развивается, появляются новые системы и сетевые интерфейсы пользовательского уровня с течением времени становятся все более и более совершенными.

VIA создавался на базе нескольких ранее существовавших прототипов, в том числе, на основе разработки университета Корнелла U-Net [2]. Мы постараемся описать основные особенности этих архитектур и подробно остановимся на следующих вопросах.

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

Факторы эффективности

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

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

Рис. 1. График задержки подтверждения приема необработанного сообщения. Время получения подтверждения приема локального вызова удаленной процедуры под управлением ОС Windows NT (локальная модель COM) в сравнении с вызовом удаленной процедуры через архитектуру Virtual Interface Architecture с использованием интерфейса GigaNet GNN1000 (распределенная модель COM с интерфейсом VIA). В случае обхода ядра удаленный вызов выполняется быстрее локального. График задержки подтверждения приема необработанного сообщения, переданного через интерфейс VIA (передача «сырых» сообщений через интерфейс VIA) показывает, что резервы для оптимизации протокола DCOM еще далеко не исчерпаны.

Как показано на рис.1, подтверждение приема при вызове удаленной процедуры с использованием сетевого интерфейса пользовательского уровня происходит гораздо быстрее по сравнению с выполнением аналогичной локальной операции в среде Windows NT. Обработка удаленного вызова производится средствами распределенной компонентной объектной модели Microsoft DCOM и архитектуры VIA интерфейса GNN1000. В случае локального вызова используется компонентная объектная модель COM. Кроме того, на рисунке показана задержка подтверждения приема «сырых» сообщений, проходящих через виртуальный интерфейс (это значение принимается за базовый показатель при оценке накладных расходов протокола DCOM).

Малое время задержки имеет очень важное значение для построения кластерных систем корпоративного уровня, которые должны обладать высокой готовностью и масштабируемостью. Система управления кластерами и кластерные серверные приложения опираются на специальный протокол циклического опроса, который позволяет восстановить состояние системы в случае возникновения ошибок. Протокол обслуживает переменное число «участников», должен получать ответ в каждом цикле опроса и крайне чувствителен к любой задержке. Кластерные приложения предъявляют высокие требования к надежности (в частности, при выполнении операций резервного копирования и тиражирования) и используют специальные средства межузлового взаимодействия для синхронизации процессов передачи данных между отдельными компонентами системы. Кластерные приложения допускают возможность масштабирования только в том случае, если скорость межузлового взаимодействия во много раз превышает скорость ответа системы на запросы клиентов. Эксперименты с сервером Microsoft Cluster Server, показали, что если малого времени задержки при организации межкластерного взаимодействия добиться не удается, масштабируемость ограничивается восемью узлами [3].

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

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

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

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

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

Основные этапы разработки интерфейса

Сетевые интерфейсы пользовательского уровня, базирующиеся на сообщениях, позволяют приложениям обмениваться данными за счет явной пересылки и приема сообщений. Они похожи на привычные интерфейсы передачи сообщений между несколькими компьютерами (такие, как MPI, Intel NX и Thinking Machines CMDD). Все сетевые интерфейсы пользовательского уровня, о которых идет речь, предоставляют возможность одновременного обращения к сети сразу нескольким пользователям. Для обеспечения нужной степени защиты процедуры настройки в них отделены от непосредственной передачи данных. В процессе настройки принимает участие и операционная система. Она отвечает за защиту и исключает взаимное влияние приложений друг на друга. При передаче же данных интерфейсы в обход операционной системы выполняют лишь простые проверки, обеспечивающие необходимый уровень защиты.

18.03.1999г

Также в разделе: