Конфигурирование Встроенных Систем диплом
| Вид материала | Диплом |
- Описание содержания электронного умк дисциплины «Проектирование встроенных систем цос», 84.2kb.
- История операционных систем семейства Windows, 588.09kb.
- 4. Использование информационных систем для бизнес-планирования, 334.22kb.
- Инженер-программист, системный администратор, 302.86kb.
- Казпотребсоюза Карагандинский экономический университет Кафедра ивс тематика, 52.08kb.
- Диплом "Россия" Диплом, 66.88kb.
- Микроконтроллеры – отдельный класс, 90.87kb.
- Конфигурирование разделов на жестком диске, 164.19kb.
- Российского Государственного Университета нефти и газа им. И. М. Губкина ведет подготовку, 47.59kb.
- Институт Промышленных Технологий и Инжиниринга, Управление Качеством. Первое образование:, 309.81kb.
Санкт-Петербургский государственный университет
Математико-механический факультет
Кафедра системного программирования
Управление и Конфигурирование Встроенных Систем
Дипломная работа студента
Ушакова К.С.
Научный руководитель: Венгерова Е.А.
Рецензент: Лавров П.С.
«Допустить к защите» Терехов А. Н.
зав. кафедрой:
д. ф.-м.н., профессор
Санкт-Петербург
2007
1Оглавление
1 Оглавление 2
2 Введение 4
2.1 Обзор области 5
2.1.1 Интерфейсы управления 6
2.1.1.1 SNMP 6
2.1.1.2 CMIP 7
2.1.1.3 TR-069 8
2.1.2 Доступные реализации 8
2.1.2.1 Texas Instruments 8
2.1.2.2 ATM Gateway 9
3 Configuration Manager 11
3.1 Терминология 11
3.2 Окружение 11
3.3 Структура 12
3.4 Интерфейс управления 13
3.4.1 Конфигурационное дерево 13
3.4.2 Идентификаторы 14
3.4.3 Типы значений 14
3.4.4 Операции с конфигурационными узлами 14
3.4.5 Ссылки 15
3.4.6 Транзакции 15
3.4.7 Оповещения об изменениях 16
3.5 Информационная модель управления 16
3.5.1 Типы узлов 16
3.5.1.1 Базовый узел 18
3.5.1.2 Целое число 18
3.5.1.3 Строка 18
3.5.1.4 Бинарные данные 18
3.5.1.5 Символическая ссылка 18
3.5.1.6 Множество 19
3.5.1.7 Структура 19
3.5.1.8 Массив 19
3.5.1.9 Группа 20
3.5.1.10 Действие 20
3.5.1.11 Метаданные 20
3.5.1.12 Перечисление 21
3.5.2 Оптимизация множеств 21
3.5.3 Связь методов get и lookup 22
3.6 Ядро CM 22
3.6.1 Валидация структур данных 22
3.6.1.1 Проверка памяти 23
3.6.1.2 Magic 23
3.6.1.3 Сложные типы данных 23
3.6.2 Управление памятью 24
3.6.3 Инициализация 26
3.6.4 Детали реализации 27
3.6.4.1 Поддержка значений узлов 27
3.6.4.2 Транзакции 28
3.6.4.3 Обработка set и get запросов 28
3.6.4.4 Поддержка оповещений об изменении и доступе. 29
3.6.4.5 Обработка событий 30
3.6.5 API для приложений, работающих с CM 31
3.6.6 Журналирование 31
3.7 Модули ядра 32
3.7.1 Access Control 32
3.7.2 Logger 33
3.7.3 Persistent Memory Manager 33
3.7.4 Parameter Manager 33
3.7.5 Process Manager 33
3.8 Модули конфигурирования сетевых ресурсов 33
3.8.1 Интерфейсы и порты 33
3.8.2 Адреса 34
3.8.3 Маршруты 34
3.8.4 Брандмауэр 36
3.8.4.1 fw_packet_filter 36
3.8.4.2 swbridge_packet_filter 39
4 Заключение 41
5 Список литературы 42
2Введение
Сетевые устройства, такие как шлюзы, маршрутизаторы, коммутаторы, межсетевые экраны и т.д., могут получить ряд преимуществ от использования программного обеспечения с открытым кодом, таких как ядро Linux или ряда служб, работающих в контексте пользователя. Более того, в последнее время наметилась тенденция отказа производителей сетевых устройств от использования закрытых операционных систем, таких как ISOS или VxWorks. Проблема, которая возникает при использовании открытого программного обеспечения – несогласованный интерфейс настройки и управления различными подсистемами.
Задача управления сетевыми устройствами усложняется тем, что существует несколько внешних интерфейсов управления, как стандартизированных, так и частных. Особой группой интерфейсов являются протоколы удаленного управления, такие как SNMP, TR-069 или внутренние протоколы компаний – производителей сетевых устройств. В связи с тем, что их разработка велась различными несогласованными группами специалистов, в них реализованы различные модели конфигурационной информации. Таким образом, еще одной задачей является разработка некой универсальной объектной модели, позволяющей адаптировать имеющиеся протоколы управления.
Конфигурация происходит от лица ряда принципалов – сервера автоматической конфигурации, пользователя и других. Это возлагает на систему управления задачу сохранение целостности данных.
Поставленные задачи:
- Исследование предметной области
- анализ интерфейсов и протоколов управления;
- анализ доступных реализаций.
- анализ интерфейсов и протоколов управления;
- Разработка архитектуры программного продукта (CM – Configuration Manager) с учетом произведенного анализа и следующих требований:
- Иерархическая организация конфигурационной информации.
Информация должна представлять из себя некоторое дерево переменных. Каждая переменная отражает некоторую информацию о состоянии системы или самого управляющего приложения.
- Модульная архитектура.
Каждый модуль должен предоставлять некоторый набор (возможно поддерево) переменных. Одна и та же версия CM может использоваться в составе разных аппаратных конфигураций, при этом загружаются только необходимые модули.
- Предоставление унифицированного интерфейса к конфигурационной информации.
Этот интерфейс может быть использован модулями системы, предоставляться внешним приложениям, работающим с конфигурационной информацией или же использоваться для обработка запросов приложений.
- Унифицированное добавление интерфейсов управления.
- Отслеживание изменений в системе, вызванных внешними сущностями.
Не все изменения состояния системы могут происходить напрямую через CM, но CM должен должным образом реагировать на произошедшие изменения и предпринимать соответствующие действия. Источником таких изменений могут служить как пользователь, который просто выдернул проводок, так и приложения, работающие на устройстве и меняющие его состояние, например, демоны маршрутизации.
- Предоставление средств сбора и анализа логов.
- Иерархическая организация конфигурационной информации.
- Разработка объектной модели.
- Реализация основных компонент программного продукта.
- Разработка и реализация набора модулей, отвечающих за конфигурирование сетевых ресурсов системы.
Основные требования, предъявляемые к программному продукту:
- CM должен работать под управлением операционной системы Linux (ядра 2.4 и 2.6) на различных конфигурациях оборудования;
- должна существовать возможность легкого переноса на другие UNIX-подобные платформы;
- CM должен быть переносим на различные архитектуры CPU (первоочередные: i368, x64, mips).