К быстродействию сети через программное обеспечение

Стив Чейпин

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

Рис.1. Относительные непроизводительные потери приложений

1 - Общая задержка передачи сообщений
2 - Аппаратные потери в сети Ethernet
3 - Потери, обусловленные программами стека TCP/IP
4 - Аппаратные потери в сети Fast Ethernet
5 - Потери, обусловленные программами стека TCP/IP
6 - Аппаратные потери в гигабитной сети
7 - Потери, обусловленные программами стека TCP/IP
8 - Аппаратные потери в гигабитной сети
9 - Потери, обусловленные программным обеспечением VIA

Мы настоятельно рекомендуем вам взять на вооружение архитектуру виртуального интерфейса (Virtual Interface Architecture—VI Architecture, или VIA). Лидеры компьютерной индустрии, такие как Dell Computer, уже выпускают продукты, отвечающие этому стандарту и ориентированные на кластеры серверов, работающих как под управлением Linux, так и Windows NT. Хотя эта технология еще не достигла своей полной зрелости, она уже реально работает, так что в течение следующего полугодия или года можно ожидать появление значительного числа продуктов, поддерживающих стандарт VI Architecture. Если ваши приложения слишком требовательны к сетевым ресурсам, вам следует знать о возможностях архитектуры VIA уже сегодня, с тем чтобы, когда закончится период ее взросления, быть готовыми к ее внедрению в своей сети.

В 1998 г. компания Microsoft, одна из первых поставившая на VI Architecture, объявила о том, что собирается реализовать поддержку этой технологии в своей ОС Windows. Однако сегодняшняя официальная линия компании далека от ее прежних замыслов: "Фирма Microsoft не намерена поддерживать в своих продуктах интерфейсы VI Architecture. Она предполагает использовать альтернативный подход, основанный на интерфейсах WinSock и получивший название WinSock Direct. Библиотеки программных модулей VI Architecture и соответствующие соединительные платы будут предоставлять сторонние поставщики продуктов сетевого взаимодействия, такие как GigaNet и Compaq". Все это говорит за то, что вряд ли стоит надеяться на официальную поддержку стандарта VIA в ОС Windows, но никаких причин для беспокойства в этом, однако, нет. Вместо того чтобы использовать агент User Agent компании Microsoft, а аппаратный блок VI Architecture какого-нибудь производителя оборудования, вы получаете и то и другое у одного поставщика. Тем не менее ваше приложение, наделенное функциями VI Architecture, будет с таким же успехом работать на кластерных серверах Linux и NT.

Экспоненциальное уменьшение задержки

Если говорить о процессорах, то вполне резонно ожидать пропорционального увеличения производительности однопроцессорных приложений с ростом быстродействия самих процессоров: производительность приложений, работающих на серверах с 400-МГц процессорами Pentium II, будет в два раза превосходить производительность тех же приложений, работающих на серверах с 200-МГц процессорами Pentium II. Однако для приложений, установленных в сети, это правило, в общем случае, не выполняется, что связано с наличием уровня программного обеспечения между приложениями и сетевым оборудованием. Если компоненты сетевой инфраструктуры стали работать заметно быстрее, то скорость работы программного обеспечения, в лучшем случае, осталась без изменения.

Переход с сети Ethernet на гигабитные сети изменяет степень влияния непроизводительных потерь приложений, обусловленных как программным, так и аппаратным обеспечением, на общую задержку передачи сообщений (рис.1). При работе приложения в стандартной сети Ethernet вклад программной и аппаратной составляющих непроизводительных потерь в общую задержку передачи сообщений приблизительно одинаков. В сети Fast Ethernet программные потери становятся доминирующим фактором, определяющим эту задержку, хотя разумное соотношение между программной и аппаратной ее составляющими все еще сохраняется. В сетях, работающих на гигабитных скоростях, аппаратная задержка становится несущественной по сравнению с программной задержкой. К примеру, TCP/IP-приложения, развернутые в сети Myrinet (гигабитная кластерная сеть), имеют задержку передачи сообщений, в 11 раз превышающую задержку, характерную для систем обмена сообщениями, основанными на технологии VI Architecture!

Основы технологии VI Architecture Первые зерна технологии VI Architecture были культивированы в стенах академических лабораторий. В рамках нескольких научных программ, включая проекты Fast Message (Университет штата Иллинойс), Portals (Sanda National Laboratories и Университет штата Нью-Мексико) и U-Net (Корнельский университет), было проведено независимое исследование оптимизированных средств связи для кластерных систем. В ходе этих проектов совместно решалась одна общая проблема: выделение коммуникационных буферов DMA (Direct Memory Access) и обеспечение прямого доступа сетевого адаптера к этой памяти при считывании и записи данных. Вместо того чтобы обрабатывать данные, пропуская их через несколько уровней программного обеспечения протокольного стека, операционная система организует буферную DMA-память и "уходит с дороги". При отправке и получении сообщений прикладной уровень и сетевой адаптер взаимодействуют непосредственно через DMA-буферы, минуя операционную систему. Этот же самый базовый механизм использован и в архитектуре VI Architecture. Научные проекты, выполненные в стенах академии, убедительно продемонстрировали практическую работоспособность полученного чернового варианта нового метода. Архитектура VI Architecture существенно расширена по сравнению с наработками академических проектов, ибо она принята в качестве отраслевого стандарта, снискавшего поддержку Compaq Computer, Dell Computer, Intel и других компаний. Технология VI Architecture, бесспорно, открывает новые горизонты для корпоративных серверов.

Таким образом, проблема сводится к тому, чтобы исключить, или хотя бы уменьшить, задержку, обусловленную программным обеспечением. Этот факт не остался незаметным для разработчиков архитектуры сетевого взаимодействия: благодаря их совместным усилиям был создан стандарт VI Architecture (см. "Основы технологии VI Architecture"). Архитектура VI Architecture представляет собой единый стандартный интерфейс программирования кластерных приложений, не зависимый от лежащей в основе кластера сетевой технологии. Он предоставляет наиболее естественный путь для масштабируемого перехода с технологии Fast Ethernet на гигабитные кластерные сетевые технологии, не затрагивающий используемые вами приложения. Если все, что вам нужно, это сужение полосы пропускания, необходимой приложению, то этот путь ничего вам не даст. Если же главной проблемой вашего приложения является задержка передачи сообщений, то архитектура VI Architecture—это как раз то, что вам нужно.

Некоторым недостатком технологии VI Architecture является то, что ее нельзя использовать для общего сетевого трафика. Высокая эффективность архитектуры виртуального интерфейса достигается за счет того, что, исключая уровни протокола TCP/IP (уровни 3 и 4), она предоставляет приложениям уровня пользователя прямой доступ к оборудованию (уровню 2). Таким образом, эта архитектура предназначена, прежде всего, для обеспечения эффективного обмена информацией между кластерными серверами или внутрикорпоративными серверами, а не для взаимодействия компонентов клиент-серверной архитектуры через соединения Интернет.

Какие приложения больше всего выигрывают от применения архитектуры VI Architecture? Прежде всего, это любые тиражируемые серверы, работающие в одинаковом режиме. Наиболее типичным примером такого сервера может служить тиражируемый Web-сервер, выступающий в качестве фронтальной системы для приложения электронной коммерции или какого-либо другого приложения. (см. рис.2). Клиентские запросы поступают на сервер через внешние TCP/IP-соединения. Эти запросы могут инициировать в системной (кластерной) сети поиск необходимой информации в базе данных, динамическую генерацию и передачу Web-страницы, обработку транзакции и так далее. Эта сеть объединяет машины друг с другом и с системой хранения информации на дисках RAID. Масштабирование подобных приложений, а также разработка новых приложений, интенсивно нагружающих сеть, требуют, чтобы эффективность программного обеспечения не отставала от производительности аппаратных средств.

Рис.2. Типичная структура тиражируемых кластерных серверов

1 - Кластер Web-серверов
2 - Сеть Интернет
3 - Средства кластерного взаимодействия
4 - Сервер RAID-системы
5 - Кластер серверов приложений

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

Архитектура VI Architecture

Давайте рассмотрим, как, используя технологию VI Architecture, Web-сервер обрабатывает процедуру поиска информации в базе данных (рис.2). Во-первых, Web-сервер должен установить соединение с приложением базы данных, для чего с помощью агента User Agent он инициирует запрос open(). User Agent—это библиотека программ, обычно предоставляемая производителем используемой ОС, которая реализует интерфейс API уровня пользователя для VI Architecture. В терминологии разработчиков этой архитектуры, приложение и User Agent образуют модуль "потребителя услуг VIA"—VIA Consumer. Здесь мы предполагаем, что имена запросов агента User Agent совпадают с именами запросов более низких уровней, но, вообще говоря, это не обязательно.

После этого User Agent инициирует формирование агентом Kernel Agent запроса open(). Kernel Agent представляет собой драйвер устройства, ориентированный на конкретную ОС и конкретный сетевой адаптер и предоставляющий единообразный интерфейс API для взаимодействия с модулями VIA Consumer различных приложений. Kernel Agent и сетевой адаптер образуют модуль "поставщика услуг VIA"—VIA Provider.

Агент Kernel Agent устанавливает соединение с модулем VIA Provider удаленного приложения, после чего этот VIA Provider организует две очереди—для отправляемых и принимаемых сообщений. Такое соединение приложение-приложение вместе с очередями и называется виртуальным интерфейсом (Virtual Interface—VI). Модуль VIA Consumer, используя функцию MemoryMap() модуля VIA Provider, может связывать буферы в устройство памяти прямого доступа (Direct Memory Access—DMA). Эта функция является ключевой—она позволяет исключить ОС из процесса обмена сообщениями между приложениями и обеспечить поступление входящих (исходящих) сообщений непосредственно из сетевого адаптера в память приложения (из памяти приложения в сетевой адаптер), минуя уровни ОС.

Сетевой адаптер, поддерживающий технологию VI Architecture, должен предоставлять средства для организации очередей сообщений. Использование сетевого адаптера, лишенного функций VI Architecture, приведет к более высокой загрузке агента Kernel Agent операциями по учету исходящих и входящих сообщений. Рабочие очереди содержат дескрипторы отправляемых или получаемых сообщений (на каждый виртуальный интерфейс приходится одна очередь отправляемых и одна очередь принимаемых сообщений), а очередь Completion Queue уведомляет приложение о том, что операции по обмену данными завершены.

Когда Web-сервер готов отправить запрос к базе данных, он вызывает подпрограмму send() своего агента User Agent. User Agent создает дескриптор сообщения, включающий информацию об адресах буферов данных, использовании защиты памяти и статусе сообщения. Каждый интерфейс VI имеет "колокольчик", в который звонит VIA Consumer, предупреждая о том, что был подан запрос на выполнение операции по передаче или приему сообщения. Таким колокольчиком является указатель на рабочий дескриптор, переданный в сетевой адаптер.

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

Вот и все. Как видно из вышеизложенного, с точки зрения пользователя, процедура обмена сообщениями с помощью виртуального интерфейса действительно ничуть не сложнее, чем посредством любой другой библиотеки программ передачи сообщений. Производители будут поставлять агенты User Agent и полнофункциональные модули VIA Provider, так что перевоплощение вашего приложения в модуль VIA Consumer сведется практически к использованию агента User Agent для передачи ваших сообщений. Почему практически? Да потому что вам придется позаботиться о том, чтобы ваше приложение выделило буферы сообщений и использовало функцию MemoryMap(), чтобы зафиксировать их в карте распределения памяти, прежде, чем они будут использованы. Архитектура VI Architecture предоставляет и другие виды сервиса, такие как прямой удаленный доступ к памяти для записи и считывания—RDMAWright() и RDMARead(), -- которые позволяют записывать или извлекать данные из отображаемой памяти приложения на другом конце виртуального интерфейса. После завершения процедуры обращения Web-сервера к базе данных он может инициировать запрос close() в модуле VIA Provider и закрыть интерфейс VI.

Кому выгодна архитектура VI Architecture?

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

Тем не менее любая значительная высокоскоростная технология ЛВС, будь то Fast Ethernet или Myrinet, или любая другая технология, которая может появиться в следующем году, непременно будут поддерживать архитектуру VI Architecture. Это означает, что перенос ваших приложений на архитектуру VI обеспечит им преимущества на многие годы вперед.

Экспериментальные реализации архитектуры VI Architecture как в промышленности, так и в академических лабораториях, продемонстрировали реальную работоспособность этой технологии. Продукты VI Architecture начинают появляться на рынке: фирма GigaNet предлагает первые сетевые интерфейсы, наделенные функциями VI Architecture, а также драйверы для ОС Solaris, TurboLinux, RedHat Linux, Windows NT и Windows 2000. Если вы считаете, что в следующем году вам, возможно, придется развертывать ресурсоемкие приложения, вам непременно стоит изучить возможности, предоставляемые архитектурой виртуального интерфейса.

Рис.3. Структурная схема технологии VI Architecture

1 - Приложение
2 - Агент User Agent интерфейса VI
3 - Интерфейс API VIA Provider
4 - Open/Close/MemoryMap
5 - Send/Receive/RDMA Wright/RDMA Read
6 - Агент Kernel Agent
7 - Сетевой адаптер с функциями VI

Demar Shoes Европейское качество демар интернет магазин харьков бесплатная доставка по городу!