BC/NW 2009; №2 (15):5.2
АНАЛИЗ МЕХАНИЗМОВ РЕАЛИЗАЦИИ СРЕДСТВАМИ ОС UNIX СЛУЖБ СЕТЕВОГО И ТРАНСПОРТНОГО УРОВНЕЙ МОДЕЛИ OSI
Абросимов Л.И., Лебедь А.А., Крамаренко М. Д.
(ГОУВПО «Московский энергетический институт (технический университет)», Россия)
Оценка производительности играет существенную роль во всех отраслях техники. Состав параметров производительности обычно меняется в зависимости от типа системы и от точки зрения исследователя. Оценка производительности вычислительных сетей (ВС) менее исследована, но не менее важна, чем в других, отраслях техники. Все устройства вычислительной техники предназначены для выполнения определенных функций, относящихся к обработке информации.
Предложенные методы оценки производительности ВС при расчете численных значений производительности ВС базируются на вероятностно-временных характеристиках сетевых устройств (СУ), которые можно измерить только экспериментально. Оценка производительности сетевых устройств также важна для проектирования и модернизации сети.
Известные подходы оценивают производительность СУ по принципу «черный ящик». Чёрный ящик – термин, используемый в различных точных науках (в частности, системотехнике, кибернетике и физике) для обозначения системы, механизм работы которой очень сложен, неизвестен или неважен в рамках данной задачи. Такие системы обычно имеют некий «вход» для ввода информации и «выход» для отображения результатов работы. Состояние выходов обычно функционально зависит от состояния входов.[1]
Применение принципа «черный ящик» для измерения характеристик СУ имеет существенные недостатки, а именно: не позволяет учитывать дифференциацию запросов, не учитывает функциональных связей параметров «черного ящика». Для устранения указанных недостатков, необходимо исследовать и описать механизмы функционирования СУ.
При исследовании производительности в качестве СУ будем рассматривать персональный компьютер (PC), работающий под управлением ОС Linux, и включенный в тестируемую ЛВС. Выбор в качестве СУ персонального компьютера обусловлен его широким использованием в вычислительных сетях в качестве сервера, рабочей станции, коммутирующего устройства и наличием большого количества программных средств отладки системы. Выбор ОС Linux обусловлен доступностью системы, наличием открытого кода и широким выбором программного обеспечения для отладки и настройки ядра системы.
Рассмотрим подробнее функционирование компьютера. Компьютер объединяет аппаратные средства (АС) и программное обеспечение (ПО). В настоящее время одной из важнейших составляющих ПО современного компьютера является операционная система (ОС).
ОС – базовый комплекс компьютерных программ, обеспечивающий интерфейс с пользователем, управление АС, работу с файлами, ввод и вывод данных, а также выполнение прикладных программ и утилит. ОС позволяет абстрагироваться от деталей реализации аппаратного обеспечения, предоставляя разработчикам программного обеспечения минимально необходимый набор функций.
Можно выделить 3 самых распространенных ОС, используемых в СУ вычислительных сетей: Windows, Unix/Linux, Solaris. В данном исследовании в качестве ОС рассматривается функционирование ОС Linux.
Для осуществления обмена информацией с другими компьютерами, СУ оснащается сетевым интерфейсом с внешним устройством. Для работы с сетевым интерфейсом в ОС Linux предусмотрен механизм обработки прерываний.
Программные прерывания инициируются выполняемой программой явным исполнением специальных инструкций, то есть синхронно, а не асинхронно. Программные прерывания могут служить для вызова сервисов операционной системы.
Конкретные механизмы возбуждения внутренних прерываний по инициативе пользовательского процесса различаются в разных аппаратных архитектурах. Поскольку ОС Linux стремится обеспечить среду, в которой пользовательские программы могли бы быть полностью мобильны, потребовался дополнительный уровень, скрывающий особенности конкретного механизма возбуждения внутренних прерываний. Этот механизм обеспечивается так называемой библиотекой системных вызовов.
Для пользователя библиотека системных вызовов представляет собой обычную библиотеку заранее реализованных функций системы программирования языка Си. При программировании на языке Си использование любой функции из библиотеки системных вызовов ничем не отличается от использования любой собственной или библиотечной Си-функции. Однако внутри любой функции конкретной библиотеки системных вызовов содержится код, являющийся, вообще говоря, специфичным для данной аппаратной платформы.[2] Также важно понимать различие между API и системным вызовом.
API – это описание функции, которое определяет, каким образом можно получить данный сервис, а системный вызов – это непосредственный запрос к ядру, сделанный через программное прерывание.
Вызов пользовательской программой API функции, реализующей системный вызов, представлен на рис 1.
Рис. 1. Выполнение API и системного вызова
Системный вызов обеспечивает выполнение программной функции, находящейся в теле ядра операционной системы. Так как понятие функция имеет множество определений (в математике, философии и т.д.), то введем новое определения U-функция.
U-функция – это программная функция (подпрограмма) ядра операционной системы, связанная с каким-либо системным вызовом.
В данной статье исследуются сетевой и транспортный уровни модели OSI.
Транспортный уровень модели предназначен для доставки данных без ошибок, потерь и дублирования в той последовательности, как они были переданы. При этом не важно, какие данные передаются, откуда и куда, то есть он предоставляет сам механизм передачи. Блоки данных он разделяет на фрагменты, размер которых зависит от протокола, короткие объединяет в один, а длинные разбивает. Протоколы этого уровня предназначены для взаимодействия типа точка-точка, например: TCP, UDP.
Сетевой уровень сетевой модели OSI предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и заторов в сети.[1] Одним из протоколов данного уровня является протокол IP.
Задачами исследования являются:
- определение состава U-функций, реализующих сетевой и транспортный уровни;
- измерение времени выполнения каждой U-функции в процессе передачи блоков данных;
- определение вероятностных характеристик вызова и обработки U-функций;
- определение зависимостей вероятностно-временных характеристик, определяющих производительность ВС от параметров трафика и характеристик сетевых устройств.
Для решения поставленной задачи был собран стенд, состоящий из двух компьютеров.
Для анализа был выбран стек протоколов ICMP/IP на основе программы ping. Команда ping была выбрана в качестве первой команды для исследования из-за своей простоты в управлении (в ОС Linux имеется одноименная программа). Данные протоколы реализованы программно в ядре ОС в виде набора U-функций. Отсюда возникает проблема измерения производительности: для измерения нужно выделить точку входа (точка А) функции операционной системы отвечающую за начало обработки данных протоколом ICMP (сетевого уровня модели OSI), а также точки B, C и D, отвечающие за выход пакета данных в сеть, прием ответного пакета из сети и выход пакета из сетевого уровня (передача пакета более высокому уровню) модели OSI соответственно. Исходя из этого, определив U-функцию начала обработки информации и U-функцию конца обработки, можно измерить время задержки информации СУ сети.
Поскольку данные протоколы реализованы программно, то производительность сетевых и транспортных уровней сетевой модели OSI можно замерить с помощью программных средств, замерив время выполнения набора U-функций для посылки данных в сеть tAB время обработки данных сетевой картой и в принимающем узле tBC и время обработки принятого пакета данных из сети tCD.
Для этого можно воспользоваться программными мониторами.
Мониторы трассирующего типа / трассировщики (tracer) представляют собой программы, регистрирующие заданные параметры вычислительного процесса в определённых точках. Каждая такая точка соответствует определённому событию в работе ВС, и при её прохождении организуется переход на программы измерительного монитора, осуществляющие сбор, накопление и вывод измерительной информации. Мониторы трассирующего типа могут реализовываться как набор модификаций к ОС (встроенные мониторы) или как структурно независимые от ОС программы, в которых интерфейс с исследуемой системой осуществляется динамически и только на время работы монитора [4].
Таким образом, монитор трассирующего типа – это специализированное программное обеспечение (ПО), которое используется наряду со средствами отладки, называемыми дебагерами (debugger). Основная задача дебагера – проследить очерёдность вызовов подпрограмм. Трассировщики и дебагеры используются при разработке ПО.
Также для определения точек А, В, С и D необходимо получить список функций, характерный для данного класса задач. Для этого можно воспользоваться программой профайлером.
Профайлер (profiler) – это программа или модуль, который засекает время и частоту выполнения отдельных участков программы и предоставляет статистические данные об этом, что дает возможность программисту проанализировать эти сведения.
Профайлер позволяет исследовать, где программа расходует ресурс времени и какие функции вызывались в процессе ее выполнения, включая родительские и дочерние. Эта информация позволяет выявить критическую, т.е. самую медленную по времени, ветвь программы, а также частоту вызова функций. Профайлинг позволяет выявить ошибки выполнения программы, которые иначе остались бы незамеченными.
Для мониторинга был выбран комплекс программных средств LTT и DProbes, что позволяет получить единый файл результатов out.data – файл «сквозной» трассировки с временными отметками срабатывания зондов. И комплекс программных средств Kernprof и Gprof для получения файла со списком U-функций.
Рис. 2. Диаграмма измерения времени доставки пакетов (серия из 5 экспериментов)
Полученные численные значения демонстрируют работоспособность выбранного подхода к проведению исследований.
Для статистически обоснованных результатов планируется проведение серии экспериментов.
ЛИТЕРАТУРА
1. http://ru.wikipedia.org
2. http://www.lcard.ru/~nail/unix/glava_2.html