Федеральное государственное автономное образовательное учреждение высшего профессионального образования

Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
НАЦИОНАЛЬНЫЙ ИССЛЕДОВТЕЛЬСКИЙ УНИВЕРСИТЕТ
ВЫСШАЯ ШКОЛА ЭКОНОМИКИ
МОСКОВСКИЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ
НАЦИОНАЛЬНОГО ИССЛЕДОВАТЕЛЬСКОГО УНИВЕРСИТЕТА
«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к дипломному проекту
На тему “Построение кластера высокой доступности на основе ОСРВ QNX
Neutrino”
Студент Потёмкин Алексей Николаевич
Руководитель проекта Борисенко Николай Владимирович
Допущен к защите ____________2013г.
КОНСУЛЬТАНТЫ ПРОЕКТА:
Специальная часть
А. Н. Потёмкин
Рецензент
Д.Е. Кашев
Зав. кафедрой__________________
МОСКВА
2
Оглавление
Аннотация .................................................................................................................................................... 3
Введение ...................................................................................................................................................... 4
Актуальность темы. ..................................................................................................................................... 5
Анализ предметной области. ..................................................................................................................... 6
Обзор альтернатив ....................................................................................................................................17
Linux-HA Project / Pacemaker Project. ...................................................................................................17
Keepalived (LVS). .....................................................................................................................................25
WindowsFailoverClustering ....................................................................................................................31
Аппаратные решения для обеспечения высокой доступности. ............................................................34
Зеркалирование дисков или RAID 1 .....................................................................................................34
Избыточные сетевые соединения .......................................................................................................36
Использование сетей хранения данных (SAN)....................................................................................36
Использование источников бесперебойного питания. .....................................................................37
Достоинства системы QNX Neutrino. .......................................................................................................38
Микроядерность....................................................................................................................................39
Технология адаптивной декомпозиции ..............................................................................................41
Заключение исследовательской части. ...................................................................................................66
Специальная часть .....................................................................................................................................68
Архитектура кластера ............................................................................................................................68
Кластер типа активный/активный. .......................................................................................................72
Расчет надежности. ...................................................................................................................................74
Надежность программного обеспечения. ..........................................................................................75
Раздел по безопасности жизнедеятельности. ........................................................................................81
Защитное зануление системы. .............................................................................................................81
Расчет защитного зануления системы. ................................................................................................86
Экономическая часть.................................................................................................................................89
Расчет затрат на разработку дипломного проекта .............................................................................89
Заработная плата исполнителя дипломного проекта ........................................................................90
Расчет прибыли, налогов и рентабельности. ......................................................................................91
Расчет налогов .......................................................................................................................................91
Расчет общей стоимости разработки ..................................................................................................92
Заключение. ...............................................................................................................................................93
Список литературы. ...................................................................................................................................94
3
Аннотация
Квалификационная работа на тему «Построение кластера высокой
доступности на основе ОСРВ QNX Neutrino» содержит 90 листов
пояснительной записки, 18 рисунков, 12 слайдов графического материала.
Целью данной квалификационной работы является разработка кластера
высокой доступности для минимизации времени простоя различных
объектов управления.
Теоретическое исследование проводилось методом анализа литературы
и нормативных источников.
Теоретическая часть состоит из исследования существующих систем
высокой доступности, исследования возможностей ОСРВ QNX Neutrino и
интерфейсов взаимодействия между компонентами систем высокой
доступности.
Практическая часть состоит из схемы всей системы целиком и
отдельного описания программной и аппаратной частей. В программной
части представлен алгоритм работы программы и блок – схема. В аппаратной
описаны интерфейсы взаимодействия и схема кластера.
4
Введение
Современные объекты управления требуют безотказной работы от
управляющей системы. Будь то медицинские системы, контролирующие
жизненные показатели пациента, системы управления опасным
производством, биллинговые системы, системы бронирования билетов,
системы для электронной коммерции, автомобильная электроника везде
требуется высокая надежность и безотказность обслуживающей системы.
Если какой-то компонент системы выходит из строя, вся система
должна продолжать работать и заменить вышедший из строя компонент так,
чтобы это было незаметно для пользователя. Или, по крайней мере, система
должна иметь предсказуемое время реакции.
Одним из наиболее эффективных способов построения безотказных,
надежных систем являются кластеры. Кластер объединяет в себе несколько
компьютеров и предоставляет их как единую, целостную систему.
Существующие готовые кластерные решения зачастую имеют очень
высокую цену и, далеко не каждое учреждение может себе позволить такую
систему.
Возникает задача построения относительно дешевого варианта
кластерной системы, которая легко масштабируется, не имеет единой точки
отказа и обеспечивает предсказуемое время реакции на сбой.
5
Актуальность темы.
Современные программные и аппаратные средства становятся все
более сложными, в связи с этим растет риск поломки или отказа одного из
компонентов системы или всей системы целиком. В современном мире
зачастую просто неприемлемо тратить время на поиск и устранение
неисправности. Это должно происходить автоматически и с минимальными
последствиями для пользователя.
Неважно сервис ли это, обслуживающий миллионы людей или система
управления автомобильной электроникой время реакции и устранения
неисправности должно быть минимальным.
Идеальная система высокой доступности простаивает примерно 5
минут за год. То есть система работает и доступна 99,999% времени.
Многие современные системы высокой доступности предоставляют
аппаратные решения, такие как:
- избыточные компоненты или системы
- компоненты, поддерживающие горячую замену
- кластеры
Но частой причиной отказа системы являются отказы программного
обеспечения, поэтому идеальной была бы система, единый компонент
которой сам по себе являлся бы системой высокой доступности.
6
Анализ предметной области.
Для начала разберемся зачем нужны кластеры и что это вообще такое.
Разберем основные термины.
Имеется четыре категории ошибок в компьютерной системе:
программные ошибки, аппаратные ошибки, ошибки состояния и временные
ошибки.
Программные ошибки – ошибки проектирования или реализации ПО.
Деление на ноль, попытка доступа к элементу массива по индексу, который
слишком большой или слишком маленький, или некорректная реализация
математического уравнения – примеры программных ошибок.
Аппаратные ошибки вызываются отказами лежащей в основе
аппаратуры. Примерами являются остановки процессора в
мультипроцессорной системе и неспособность сенсора посылать данные.
Ошибки состояния являются результатом различия между системным
восприятием внешней среды и действительной средой.
Временные ошибки происходят, когда операции не удовлетворяют
временным ограничениям.
Имеется несколько способов для улучшения или поддержки
нормальной производительности в среде, в которой происходит
неисправность.
Предотвращение неисправности представляет собой способ,
используемый при попытке предотвратить возникновение неисправностей.
Маскирование неисправности представляет собой метод, который
предотвращает ситуацию, когда неисправность вводит ошибки в систему.
7
Обнаружение неисправности представляет собой способность
обнаруживать неисправности в системе. Могут быть обнаружены только
последствия неисправности или ошибки. Причина, по которой происходит
неисправность, должна быть выведена из результата.
Отказоустойчивость представляет собой способность системы
продолжать выполнять свою задачу после возникновения неисправностей.
Она может быть достигнута с использованием многих способов.
Маскирование неисправностей – один подход, другой – обнаружение и
обработка ошибки, чтобы либо сохранить, либо восстановить
функционирование системы.
При введении термина «отказоустойчивость» предполагается, что
система устойчива к отказам своих компонент, рассматриваемых в этом
смысле как «неделимые блоки».
Структура унифицированного отказоустойчивого вычислителя
определяется его назначением и должна обеспечивать сохранение
работоспособности в условиях одиночных сбоев и отказов.
Функционирование аппаратуры в условиях обратимых дефектов
требует таких решений, которые в течение активного рабочего цикла
выполняемой задачи либо обеспечивают парирование сбоев, либо их
маскирование и восстановление процесса управления. Полное тестирование
и реконфигурация аппаратной части может происходить только в течение
пассивного цикла выполняемой задачи. Повышение надежности основано на
принципе предотвращения неисправностей путем снижения интенсивности
отказов и сбоев за счет применения электронных схем и компонентов с
высокой и сверхвысокой степенью интеграции, снижения уровня помех,
облегченных режимов работы схем, обеспечения тепловых режимов их
8
работы, а также за счет совершенствования методов сборки аппаратуры.
Единицей измерения надежности является среднее время наработки на отказ
(MTBF - Mean Time Between Failure).
Принципы, лежащие в основе методов достижения
отказоустойчивости, и оказывающие решающее влияние на его
конфигурацию:
1)
Избыточность ресурса (аппаратного, временного, программного);
2)
Наличие дополнительных аппаратных и программных средств,
управляющих восстановлением вычислительного процесса после отказов;
3)
Достоверность выходных сигналов каждого неделимого блока;
4)
Удаление из рабочей конфигурации только неисправных
неделимых блоков;
5)
Функциональная и системная однородность групп неделимых
блоков;
6)
Само - контролируемость узлов, вырабатывающих
специфические сигналы, не удовлетворяющие свойству однородности
(например, схем контроля);
7)
Однородность архитектуры управления функционированием и
управления отказоустойчивостью.
Лучшими среди отказоустойчивых систем являются системы,
обеспечивающие непрерывную готовность. Разработка подобной системы
охватывает как аппаратные средства, так и программное обеспечение. Очень
важным дополнительным требованием к таким системам является
сохранение уровня производительности в случае отказа какого-либо
компонента. Время восстановления после отказа не превышает одной
секунды.
9
Реализация вычислений в режиме непрерывной готовности затрагивает
практически все аспекты разработки системы - в ней не должно быть ни
одного функционального узла, отказ которого может вывести из строя
систему в целом.
Во множестве систем высокой готовности используется ПО обработки
аппаратных и программных отказов, быстро переключающее работу с одного
компьютера на резервный в рамках той же системы. Имеется возможность
спроектировать систему, не просто защищенную от сбоев, а гарантирующую
полную передачу рабочих функций.
Для обеспечения отказоустойчивости при разработке ПО необходимо
реализовать:
-
модульность;
-
резервирование;
-
контроль;
-
реконфигурацию;
-
восстановление.
Для обеспечения отказоустойчивости используются два подхода –
кластерный и мажоритарный. В первом случае на каждом из узлов
отказоустойчивого вычислителя выполняются разные приложения, но при
отказе одного из узлов приложения этого узла мигрируют на
работоспособный узел. Во втором случае все три узла работают синхронно
на одних и тех же данных, проводят взаимное сравнение своих результатов и
отключают неисправный процессор. Если процессоры не само - тестируемые,
то минимальная конфигурация должна содержать 3 процессора, и с ростом
их числа отказоустойчивость повышается.
10
Кластер — это разновидность параллельной или распределенной
системы, которая:
-
состоит из нескольких связанных между собой компьютеров;
-
используется как единый, унифицированный компьютерный
ресурс.
Кластер функционирует как единая система, то есть для пользователя
или прикладной задачи вся совокупность вычислительной техники выглядит
как один компьютер. Именно это и является самым важным при построении
кластерной системы.
Основное назначение кластера состоит в обеспечении:
1)
высокого уровня доступности (High Availability), иначе
называемого уровнем готовности;
2)
высокой степени масштабируемости;
3)
удобства администрирования по сравнению с разрозненным
набором компьютеров или серверов.
Иными словами, кластеры позволяют значительно повысить
отказоустойчивость сетевых служб и увеличить их производительность с
сохранением простоты администрирования и использования.
К общим требованиям, предъявляемым к кластерным системам,
относятся:
- Высокая готовность
-Высокое быстродействие
-Масштабирование
-Общий доступ к ресурсам
-Удобство обслуживания
11
Программное обеспечение унифицированного отказоустойчивого
вычислителя реализует кластерную систему высокой готовности (high
availability), поэтому первое требование ставится во главу угла.
Сегодня в мире распространены несколько типов систем высокой
готовности. Среди них кластерная система является воплощением
технологий, которые обеспечивают высокий уровень отказоустойчивости
при самой низкой стоимости. Отказоустойчивость кластера обеспечивается
дублированием всех жизненно важных компонент. Максимально
отказоустойчивая система должна не иметь ни единой точки, то есть
активного элемента, отказ которого может привести к потере
функциональности системы. Такую характеристику как правило называют –
NSPF (No Single Point of Failure, - англ., отсутствие единой точки отказа).
При построении систем высокой готовности, главная цель - обеспечить
минимальное время простоя.
Для того чтобы система обладала высокими показателями готовности,
необходимо:
1)
чтобы ее компоненты были максимально надежными;
2)
чтобы она была отказоустойчивая, желательно, чтобы не имела
точек отказов;
3)
а также важно, чтобы она была удобна в обслуживании и
разрешала проводить замену компонент без останова.
Пренебрежение любым из указанных параметров, может привести к
потере функциональности системы.
Что касается обеспечения максимальной надежности, то она
осуществляется путем использования электронных компонент высокой и
12
сверхвысокой интеграции, поддержания нормальных режимов работы, в том
числе тепловых.
Отказоустойчивость обеспечивается путем использования
специализированных компонент (ECC, Chip Kill модули памяти,
отказоустойчивые блоки питания, и т.п.), а также с помощью технологий
кластеризации. Благодаря кластеризации достигается такая схема
функционирования, когда при отказе одного из компьютеров задачи
перераспределяются между другими узлами кластера, которые
функционируют исправно.
Кластерная архитектура рассчитана на следующую конфигурацию:
1)
все узлы кластера имеют независимую оперативную память;
2)
в части доступности устройств ввода-вывода и, прежде всего
дисков, возможны следующие конфигурации:
а) кластер с разделяемыми дисками (shared disk) подразумевает,
что любой узел имеет прозрачный доступ к любой файловой системе общего
дискового пространства. Помимо разделяемой дисковой подсистемы на узлах
кластера могут иметься локальные диски, но в этом случае они
используются, главным образом, для загрузки ОС на узле. Такой кластер
должен иметь специальную подсистему, называемую «распределенный
менеджер блокировок» (Distributed Lock Manager, DLM), для устранения
конфликтов при одновременной записи в файлы с разных узлов кластера;
б) Кластер без разделения ресурсов (shared nothing), как и следует из
названия, не имеет общих устройств ввода/вывода . Правда, здесь есть одна
тонкость: речь идет об отсутствии общих дисков на логическом, а не на
физическом уровне. Это означает, что на самом деле дисковая подсистема
может быть подключена сразу ко всем узлам. Если на дисковой подсистеме
13
имеется несколько файловых систем (или логических/физических дисков), то
в любой конкретный момент времени доступ к определенной файловой
системе предоставляется только одному узлу. К другой файловой системе
доступ может иметь (т. е. владеть ресурсом) совсем другой узел. Такая схема
применяется для того, чтобы в случае отказа одного узла ресурс мог быть
передан другому узлу.
с) в соответствии с еще одной схемой локальные диски узлов кластера
зеркалируются (дублируются). Очевидно, что такой подход годится только
для задач, решение которых не возлагает значительной нагрузки на дисковые
подсистемы.
Как уже было сказано выше, основными характеристиками кластера
являются высокий уровень готовности, масштабируемость и представление
кластера как единого целого с точки зрения внешней среды.
Уровень готовности характеризует готовность системы к
функционированию в течение длительного времени без остановки и
измеряется в процентном отношении времени нахождения системы в
работоспособном состоянии к общему времени. Иногда он характеризуется
временем простоя системы за год.
Высоким уровнем готовности считается обычно уровень 99, 9 % и
выше, хотя такая градация носит достаточно условный характер. С уровнем
готовности связано понятие отказоустойчивости. Обычно под
отказоустойчивой понимают систему с уровнем готовности 99, 999 % и
выше. Используемый иногда термин «истинная отказоустойчивость»
подразумевает практически безостановочную работу системы (99, 9999 % и
выше).
14
Важно понимать, что заявляемый производителями уровень готовности
относится лишь к аппаратной части кластера и операционной системе и
обычно не учитывает надежность ПО, особенно сторонних разработчиков.
Более того, чтобы обеспечить высокий уровень производительности, каналы
подключения к дисковым массивам, сетевой среде и между узлами должны
быть отказоустойчивыми и дублированными. Вдобавок дублировать следует
также сами дисковые массивы, маршрутизаторы и коммутаторы сети,
источники бесперебойного питания и т. д. Особенно важное значение имеет
использование в качестве дисковых подсистем массивов RAID, причем для
повышения отказоустойчивости и производительности специалисты
советуют применять RAID - 10. Разумеется, чем больше компьютеров в
кластере, тем теоретически выше уровень доступности.
Обращаясь к теме масштабирования кластеров, следует отметить, что
грамотное размещение на узлах кластера даже обычных (не кластерных)
приложений позволяет не только существенно повысить запас прочности, но
и увеличить общую производительность по сравнению с одним сервером.
Количество узлов в кластере зависит от конкретной реализации, оно
колеблется от двух до нескольких десятков, и, как уже было сказано, каждый
узел может быть многопроцессорным. Добавление нового узла в кластер
обычно проходит безболезненно и не требует перегрузки других узлов.
Таким образом, при нехватке вычислительных ресурсов кластер можно на
ходу увеличить «в размерах».
Весьма важной особенностью кластера является так называемый
единый образ системы (Single System Image, SSI), благодаря которому
пользователи могут видеть серверы в кластере как единое целое. Для
пользователя кластер — это большой сервер, на котором работает множество
15
приложений, хотя в действительности они функционируют на различных
узлах.
Единый образ системы исключительно важен и для администратора,
так как позволяет управлять кластером как одной системой. Разумеется, с
помощью соответствующих утилит администратор может управлять и
отдельными узлами.
Особый интерес представляет доступ клиентов к кластеру в момент
отказа узла.
Кластеру назначается один или несколько общих виртуальных IP адресов. Эти виртуальные IP - адреса используются для доступа к кластеру
как единому целому. Кроме того, каждому узлу назначается свой
индивидуальный IP - адрес.
Помимо общих виртуальных IP - адресов каждому сетевому ресурсу
кластера (это может быть система для файлового сервиса или приложение с
соответствующим ему дисковым пространством) назначается свой
виртуальный IP - адрес. В нормально работающем кластере такие
виртуальные IP - адреса принадлежат узлам, на которых выполняется
приложение или сетевая служба, т. е. при обращении к виртуальному IP адресу откликается определенный узел. При отказе того или иного узла
кластерные ресурсы вместе с соответствующими виртуальными IP адресами переходят к другим узлам.
Что же происходит при отказе узла или отдельной сетевой службы, с
точки зрения клиента? Все зависит от того, какими протоколами и
приложениями пользуется клиент в данный момент. Если они относятся к
категории сервисов, не отслеживающих состояние соединения, то клиент
попросту не заметит ничего, вернее, он может столкнуться с некоторой
16
задержкой в выполнении запросов, вследствие того, что на миграцию служб
требуется определенное время.
Если же сервисы отслеживают состояние соединения, то их работа
зависит от конкретной реализации. В общем случае от клиента может
потребоваться заново установить соединение. Однако в ряде случаев
повторного открытия соединений может и не потребоваться, поскольку
клиентское ПО само автоматически переустановит соединение.
Программное обеспечение унифицированного отказоустойчивого
вычислителя в сочетании с предлагаемыми аппаратными средствами должно
обеспечить надежность 99,999% , в этом случае приложение должно иметь
непроизводительные потери времени не более чем 5,25 минуты в год,
независимо от количества программных сбоев, отключений электропитания,
отказов оборудования, ошибок оператора и других неожиданных
неприятностей. Даже если приложение останавливается только на один час в
год (например, для модернизации), это значит, что степень его готовности
составляет всего "четыре девятки" - 99,99%.
Судя по этим цифрам, очевидно, что высокая готовность является
системной проблемой. Таким образом, для получения системы высокой
готовности все ее компоненты, включая операционную систему, аппаратную
платформу и код приложений, должны разрабатываться с учетом требований
высокой готовности. Например, это относится к следующим вопросам. Как
операционная система обрабатывает ошибки драйвера (которые часто
приводят к полному отказу системы)? Может ли ОС немедленно
перезапустить драйвер без сброса системы? Или в этом случае вся система
должна быть перезагружена?
Исследования показывают, что вопросы, связанные с программным
обеспечением, включая программные ошибки и необходимость обновления,
17
являются причиной большинства простоев в предоставлении сервиса.
Поэтому достижение высокой готовности должно начинаться с базового
программного обеспечения, на котором строятся все приложения высокой
готовности - с операционной системы.
Обзор альтернатив
Рассмотрим существующие программные решения для построения
кластерных систем.
Linux-HA Project / Pacemaker Project.
Linux-HA - проект, предоставляющий возможности построения
кластеров высокой доступности на основе операционных систем Linux,
FreeBSD, OpenBSD, Solarisи MacOSX. Основой проекта является демон
Heartbeat.
Heartbeat – демон управляющий кластером. Из его основных функций
можно отметить следующие:
- Heartbeat отслеживает состояние ресурсов, при возникновении
неполадки демон может перезапустить отказавший процесс или переместить
его на другой узел кластера
- удаление отказавших узлов из кластера
- графический интерфейс для конфигурации и мониторинга ресурсов и
узлов кластера
Сам по себе демон Heartbeat управляет инфраструктурой кластера,
взаимодействием узлов между собой, включением узлов в кластер и
удалением их из него. Менеджер ресурсов кластера в Heartbeat имеет
ограниченный функционал и может следить одновременно лишь за двумя
18
узлами кластера. Для построения более функционального и надежного
кластера существует отдельный менеджер ресурсов кластера – Pacemaker.
Pacemaker существенно расширяет функционал Heartbeat. Основные
функции Pacemaker:
- Обнаружение и восстановление неисправностей на уровне сервисов
и узлов кластера
- Не зависит от подсистемы хранения данных, не требуется общий
диск
- Ресурсом кластера может быть все, что можно заскриптовать
- Поддержка STONITH (Shoot-The-Other-Node-In-The-Head) средство для вывода "умершего" узла из кластера. Решает, в том
числе такую проблему как Split-Brain - ситуация, когда связь между
узлами теряется, но оба они живы, каждый из них думает, что
другой умер и пытается забрать все ресурсы себе, это может
привести к повреждению данных, поэтому своевременный вывод
одного из узлов из кластера решит эту проблему.
- Поддержка любого количества узлов в кластере
- Поддержка ресурсозависимых и кворумных кластеров
Pacemakerподдерживает практически любую избыточную
конфигурацию: Активный/Пассивный, Активный/Активный, N+1,
N+M, N-to-1, N-to-N.
Конфигурация Активный/Пассивный
19
В этом случае Pacemaker использует DRDB для хранения данных.
В некоторых типах кластера необходим доступ к одним и тем же
данным с разных машин, но организовывать распределенное общее
хранилище зачастую очень дорого. В таком случае в качестве альтернативы
используют DRDB. DRDB представляет из себя программный RAID-1, то
есть зеркалирует файлы между машинами.
DRBD работает с блочными устройствами, используемыми в качестве
строительных блоков для формирования кластеров высокой надежности. Он
зеркалирует все блочное устройство, используя сетевой интерфейс. DRBD
зеркалирует каждый блок данных, который записывается на диск, в
равноправный узел.
20
Стрелки с точками показывают поток данных, который реализуется,
когда DRBD зеркалирует данные сервиса высокой доступности (high av
ailably service) от активного узла кластера к резервному узлу кластера.
Shared Failover конфигурация – несколько кластеров типа
Активный/Пассивный объединяются в один.
21
Конфигурация Активный/Активный
Здесь используется общее хранилище, и каждый узел кластера может
замещать другой. Нагрузка распределяется равномерно между всеми
машинами в кластере. В случае отказа одной из машин нагрузка
перерспределяется между остальными узлами.
Архитектурно кластерный софт можно разделить на три части:
- Управление взаимодействием узлов в кластере и добавление/удаление
узлов (на схеме изображено красным)
- Компоненты, относящиеся к определенному узлу в кластере (на схеме
зеленые). Это такие компоненты как управление и мониторинг за
локальными ресурсами.
22
- Основной компонент – менеджер ресурсов кластера (изображен
синим). Этот компонент реагирует на события кластера (присоединение или
удаление узла) и события ресурсов кластера и обрабатывает их. Также
компонент реагирует на изменение конфигурации кластера со стороны
администратора.
Из-за ограниченной функциональности демон Heartbeat постепенно
замещается связкой Pacemaker + CoroSync.
CoroSync – проект, который вырос из OpenAIS. OpenAIS – открытая
реализация проекта AIS (Application Interface Specification).
AIS – это набор спецификаций, которые описывают интерфейс
программирования приложений для реализации приложений высокой
доступности. Основной целью проекта AIS является упрощение написания
23
приложений высокой доступности и обеспечение переносимости этих
приложений.
CoroSync предоставляет следующий функционал:
- Процессы объединяются в группы процессов для виртуальной
синхронизации, это обеспечивает репликацию состояния разных машин.
- Простой менеджер высокой доступности, который перезапускает
процессы в случае сбоя.
- Базу данных конфигураций и статистики по узлам кластера и кластеру
в целом
- Кворумную систему, уведомляющую приложения, когда кворум
достигнут.
Реализация Pacemaker совместно с CoroSync имеет следующий вид:
24
Сам Pacemaker состоит из четырех основных частей, к которым можно
подключать дополнительные модули (в том числе из LinuxHAProject)
- CIB (Cluster Information Base)
- CRMd (Cluster Resource Manager daemon)
- PEngine (Policy Engine)
- STONITHd
CIB – использует XMLдля описания конфигурации кластера и
состояния всех его ресурсов. Содержимое CIB реплицируется между всеми
компонентами кластера и используется PEngine для вычисления идеального
состояния кластера и путей достижения этого состояния.
Один из демонов CRMd выбирается мастером и, если мастер выйдет из
строя другой демон станет мастером.
25
Инструкции из PEngine направляются в LRMd (демон локального
менеджера ресурсов). В свою очередь локальный демон отвечает о
результате выполнения операций. На основе этого ответа
PEngineпересчитывает идеальное состояние кластера и перестраивает
инструкции на основе результатов этого вычисления.
Keepalived (LVS).
Проект для инфраструктур, основанных на Linux. Основная цель
обеспечить балансировку нагрузки между узлами кластера и обеспечить
высокую доступность. В основном используется для обеспечения
безотказной работы сетевых сервисов.
Балансировка нагрузки основана на LVS (LinuxVirtualServer)
LVS – кластер состоит из одного или двух узлов маршрутизатора и
переменного числа серверов. Реальные сервера объединяются частной сетью.
LVS маршрутизаторы подсоединяются к этой частной сети, а также к
общедоступной сети.
26
Адаптеры, присоединяющие LVS маршрутизаторы к частной и
общедоступной сетям,могут быть любыми устройствами, однако должны
быть теми же самыми на каждом маршрутизаторе.
В каждый момент времени активен только один LVS маршрутизатор.
Роль активного маршрутизатора состоит в перенаправлении запросов на
обслуживание с адресов виртуальных серверов на реальные серверы.
Перенаправление основывается на одном из четырех поддерживаемых
алгоритмов балансировки нагрузки:
27
- RoundRobin - распределяет работу равномерно между всеми
реальными серверами
- Least - connections - распределяет больше работ реальным серверам с
меньшим количеством активных связей (таблица IPVS хранит
активные связи)
- Weighted round robin - распределяет больше работ серверам со
значительно большей емкостью. Емкость определяется
присвоенным пользователем весом, который уменьшается или
увеличивается в соответствии с динамической информацией о
нагрузке
- Weighted least connections - распределяет больше работ реальным
серверам с меньшим количеством активных связей относительно их
емкости. Емкость определяется присвоенным пользователем весом,
который уменьшается или увеличивается в соответствии с
динамической информацией о нагрузке
Активный маршрутизатор динамически отслеживает состояние
реальных серверов и выполняемую каждым работу одним из трех способов.
Если работа с конкретным реальным сервером запрещается, активный
маршрутизатор прекращает посылку работ на сервер до того, как он вернется
к нормальному состоянию.
Периодически LVS маршрутизаторы обмениваются сообщениями,
подтверждающими их исправность "Я жив", посредством имеющегося между
ними общедоступного соединения. Если резервный узел не получает
сообщение, подтверждающее исправность, в течение ранее установленного
временного интервала, он инициирует операцию по сбойной ситуации для
того, чтобы взять на себя роль активного маршрутизатора. В процессе
выполнения операции по сбойной ситуации резервный маршрутизатор
28
присваивает себе плавающие IP – адреса неисправного маршрутизатора (как
это описано в файле конфигурации кластера) и, используя метод,
называемый ARP "подслушиванием", запускает действия по своему
объявлению пунктом назначения для IP – пакетов, адресованных на
неисправный узел. Когда неисправный узел становится готовым к
обслуживанию запросов, он начинает функционировать в режиме горячего
резерва.
В каждый момент времени LVS – кластер поддерживает только один
метод маршрутизации. Трансляция сетевых адресов (NAT), предполагается
добавить туннелирование и прямую маршрутизацию.
Запросы клиента к сервису прибывают на IP адрес виртуального
сервера. Это публично известный адрес, которому администратор сайта
установил соответствие с полностью определенным доменным именем.
Уникальный виртуальный адрес сервера есть сочетание трех величин
протокол (TCP или UDP), IP адрес и номер порта.
Компонентами LVS кластера являются:
pulse
Это управляющий процесс, который запускает все другие требуемые
демоны. Он запускается на LVS маршрутизаторе командным файлом
/etc/rc.d/init.d/pulse, как правило, во время начальной загрузки. Посредством
pulse, которая реализована как простая программа определения исправности,
неактивный LVS маршрутизатор определяет, исправен ли активный
маршрутизатор и в какой момент времени требуется инициировать
процедуру обработки сбойной ситуации.
29
Lvs
Демон lvs выполняется на LVS маршрутизаторе. Он считывает файл
конфигурации и вызывает ipvsadm для обеспечения работы с таблицей
маршрутизации IPVS.
Nanny
Демон слежения nanny выполняется на активном LVS маршрутизаторе.
С помощью этого демона активный маршрутизатор определяет состояние
каждого из реального сервера и получает информацию об их загруженности.
На каждом реальном сервере выполняется отдельный процесс, используемый
каждым виртуальным сервером.
/etc/lvs.cf
Это файл конфигурации LVS кластера. Непосредственно или нет все
демоны получают информацию о конфигурации из этого файла.
Piranha
Средство для отслеживания, конфигурирования и администрирования
LVS кластера.
Ipsvadm
Это средство вносит изменения в таблицу маршрутизации IPVS в ядре.
Демон lvs настраивает и администрирует LVS кластер посредством вызова
30
ipsvadm для добавления, замены или удаления строк в таблице
маршрутизации IPVS.
Высокая доступность достигается засчет протокола VRRP.
Протокол VRRP объединяет несколько маршрутизаторов в один
виртуальный и назначает им один общий IP адрес.
Общая архитектура Keepalived:
Keepalived представляет из себя три процесса. Родительский процесс
мониторинга и два процесса – потомка: VRRP и healthcheck. VRRP отвечает
за обеспечение высокой доступности, healthcheck проверяет состояние служб
кластера.
Keepalived конфигурируется с помощью файла keepalived.conf, затем
конфигурация парсится и применяется.
31
Keepalived предоставляет некоторые функции управления памятью,
такие как выделение памяти, перераспределение и освобождение памяти.
Демон может работать в нормально режиме и в отладочном режиме. В
отладочном режиме демон может отслеживать утечки памяти и следить за
общим распределением памяти.
WatchDog – компонент отслеживающий состояние дочерних
процессовVRRPи healthcheck.
Netlinkreflector – собственное представление сетевого интерфейса в
keepalived. Мониторинг осуществляется через Netlinkканал ядра.
Checkers – одинизглавныхкомпонентовkeepalived. Тут проверяется
«жив» ли сервер, тут же на основе полученной информации решается вопрос
о присоединении/отсоединении сервера от кластера.
WindowsFailoverClustering
Рассмотрим также возможности построения кластерных систем,
которые предоставляет Windows.
WSFC – Windows Server Failover Clustering предоставляет
инфраструктуру для поддержки высокой доступности серверных
приложений (например SQLServer).Если узел кластера выходит из строя,
сервис может быть автоматически или вручную перенесен на другой
доступный узел кластера.
WSFCпредоставляет следующий функционал:
- Распределенная конфигурация и уведомления. Сам WSFC сервис и
метаданные, связанные с критичным приложением, хранятся на каждом узле
кластера. Эти метаданные содержат настройки WSFCи статус приложения, а
32
также дополнительные настройки критичного приложения. Изменения в
статусе или в метаданных автоматически распространяются на все узлы
кластера.
- Управление ресурсами. Каждый узел кластера может содержать свои
собственные физические ресурсы (диски, сетевые интерфейсы и т.д.). Можно
настроить зависимость приложений от этих ресурсов.
- Мониторинг «здоровья» кластера. Мониторинг осуществляется с
помощью сетевых коммуникаций и мониторинга отдельных ресурсов на
каждом узле кластера. Общее «здоровье» кластера определяется кворумом.
- Failover – каждый дополнительный узел может стать основным и
наоборот. Базируясь на состоянии кластера, владение ресурсами и их
обработкой может быть перемещено с одного узла на другой.
Windows также предоставляет API как для Failover кластеров высокой
доступности, так и для балансировки нагрузки.
33
Вот так выглядят компоненты Failover кластера для Windows систем:
Эти компоненты включают в себя:
- Сервис кластера (Cluster service) – контролирует кластерную
активность на отдельном узле системы
- Cluster Disk Driver – обеспечивает эксклюзивный доступ к
кластерным дисковым ресурсам, во избежание повреждения данных
- Resource Monitors–сервисы для общения между ресурсами кластера и
сервисом кластера (Cluster service). Через этот компонент сервис кластера
может отслеживать состояние ресурсов отдельных узлов и всего кластера.
34
- Resource DLLs – обрабатывают практически все операции над
ресурсами кластера.
- Cluster Database – хранит информацию о конфигурации кластера
- Административный интерфейс предоставляет возможность
администрирования кластера.
Рассмотрим существующие аппаратные решения для обеспечения
высокой доступности.
Аппаратные решения для обеспечения высокой доступности.
Зеркалирование дисков или RAID 1
Полное копирование данных на двух и более дисках. В случае выхода
из строя одного из дисков работоспособность системы не изменится. RAID 1
надежен, т.к. работает, если функционирует хотя бы один диск в массиве.
Сразу несколько дисков могут выйти из строя с гораздо меньшей
вероятностью, чем один, так как вероятность отказа нескольких дисков равна
произведению вероятностей отказа каждого из них.
35
Еще и плюсов стоит отметить, что зеркалирование иногда позволяет
ускорить процесс чтения информации с дисков. Каждый диск может быть
доступен отдельно и запросы на чтение можно направлять на различные
диски. Это особенно ощутимо когда несколько процессов одновременно хотя
считать данные с диска. Направив разные процессы на разные диски
получается выигрыш в производительности.
У этого способа есть и минусы. При наличии двух дисков мы получаем
фактический полезный объем лишь одного.
Рекомендуется создавать RAID массивы типа 10, в этом случае
несколько массивов типа 0 (поочередная запись) объединяются в массив типа
1, то есть зеркалируются.
36
Избыточные сетевые соединения, несколько сетевых интерфейсов на
одной машине. Объединение маршрутизаторов в один виртуальный.
Рассмотренный выше протокол VRRP пример реализации сетевой
избыточности.
Использование сетей хранения данных (SAN).
SAN - сеть, которая предоставляет сетевые блочные устройства. SAN
позволяет воспринимать удаленное устройство хранения как локально
подключенное. Сетевые блочные устройства представляют собой устройства
хранения соединенные с помощью определенных протоколов и интерфейсов
(iSCSI, FibreChannel, AoE).
Достаточно долгое время на рынке SAN доминировал протокол
FibreChannel. FibreChannel – транспортный протокол передачи SCSI команд
через сети FibreChannel. У FibreChannel практически не было альтернатив,
однако недостатки у протокола существовали. Основные недостатки – это
цена и проблемы с доступом к географически распределенным устройствам.
В последние годы FibreChannel используется в основном в
высокопроизводительных системах. В более бюджетном сегменте его
замещает протокол iSCSI.
Протокол iSCSIописывает механизм инкапсуляции SCSIкоманд в
IPпакеты и передаче их поверх TCP. Благодаря такой реализации возможен
удаленный доступ к любому хранилищу через интернет. Для этого не нужно
дополнительно инфраструктуры, SAN на основе iSCSI может быть построен
на любой физической основе, поддерживающей IP, например Ethernet,
GigabitEthernet и 10G Ethernet. Однако и тут существуют проблемы, SCSI как
интерфейс канального уровня предполагает последовательную и надежную
передачу пакетов. В IPже пакеты передаются без соблюдения строгой
37
последовательности. Это может привести к потере данных, особенно в
глобальных сетях, где вероятность потерь ip пакетов больше чем где бы то ни
было. В связи с этим протокол предусматривает обработку ошибок. SCSI
команды буферизируются до момента их подтверждения. Если что-то пошло
не так и повредился пакет или разорвалась TCPсессия, предпринимается
попытка восстановления сессии и повторения передачи поврежденных
пакетов.
iSCSI работает на основе клиент – серверной архитектуры. Клиент,
который представляет из себя сервер, рабочую машину или, как в нашем
случае кластер (то есть набор серверов) инициирует запросы на чтение
данных. Сервер - система хранения данных обрабатывает запросы и отвечает
на них.
Сессия iSCSI состоит из двух этапов – аутентификации и обмена.
Аутентификация позволяет осуществлять контроль доступа и согласовывать
различные параметры сессии между клиентом и сервером. После
подтверждения аутентификации начинается процесс обмена. Одна
транзакция должна происходить через одно TCPсоединение, иначе придется
еще и контролировать разные потоки, что еще больше снизит надежность.
Также существуют протоколы передающие FCтрафик поверх TCP/IP,
например iFCP.
Использование источников бесперебойного питания.
Такие источники позволяют избежать повреждения оборудования при
кратковременных сбоях электричества. Также позволяют штатно завершить
работу оборудования при длительных неполадках с электричеством.
38
Теперь рассмотрим плюсы и минусы вышеприведенных систем и
системы QNX, выбранной для построения кластера.
Достоинства системы QNX Neutrino.
Кластерные системы сами по себе обычно делят на три типа:
1) Кластеры высокой доступности, обеспечивающие бесперебойную
работу критически важных сервисов
2) Кластеры для балансировки нагрузки, такие кластеры распределяют
нагрузку между узлами для обеспечения быстрого ответа пользователю
3) Вычислительные кластеры, используются для
высокопроизводительных вычислений, задача разбивается на
несколько подзадач и выполняется на разных узлах кластера
QNX Neutrino - операционная система жесткого реального времени. QNX
может работать как на встраиваемых системах с ограниченными ресурсами
так и как полноценная надежная ОС. Это возможно благодаря микроядерной
архитектуре системы. Благодаря ей же система легко масштабируется.
e
39
Микроядерность также дает преимущества в построении систем
высокой доступности. Все компоненты работают в своих отдельных модулях
минимально взаимодействующих друг с другом. Все драйверы , стеки
протоколов, файловые системы и приложения выполняются в защищенном
пространстве пользователя, вне ядра. На уровне ядра выполняются только
самые необходимые службы. Благодаря этому при обновлении какого либо
компонента не нужно перезагружать систему целиком. Также если
повредится какая та часть одного модуля это не скажется на других .
Теоретически любой компонент при отказе может быть перезагружен и это
не скажется на других компонентах системы. В совокупности это позволяет
строить оптимизированные и очень доступные системы.
40
Как видно из схемы выше, QNX поддерживает множество платформ,
начиная от x86 и заканчивая MIPS и PowerPC.
QNX - POSIX совместимая операционная система. Это позволяет легко
портировать под нее приложения, написанные для Unix/Linux.
QNX поддерживает технологию динамического распределения
процессорного времени между группами процессов, так называемую
технологию адаптивной декомпозиции. Технология адаптивной
декомпозиции позволяет обеспечить дополнительный уровень надежности и
задействовать процессор на полную его мощность. Это может быть очень
критично в маломощных встраиваемых системах. Но и в
многопроцессорных/многоядерных серверах правильный расход
процессорного времени важен.
41
Технология адаптивной декомпозиции позволяет объединять процессы
и потоки в группы и обеспечивать гарантированное процессорное время для
этих групп. Объединение в группы не позволяет какому то процессу забирать
все процессорное время, вместо этого оно динамически распределяется
между группами. Технология позволяет передавать ресурсы процессора от
менее загруженных блоков к блокам, требующим дополнительного
процессорного времени. Технология адаптивной декомпозиции идеально
подходит для встраиваемых систем, требующих высокого уровня
отказоустойчивости и гарантированного времени отклика.
В отказоустойчивой системе гарантированное процессорное время
позволяет быстро восстанавливать отказавший компонент. Независимо от
загрузки процессора администратор системы может подключиться к ней и
продиагностировать неполадку.
QNX Neutrino – система жесткого реального времени. Это значит, что
задача будет выполнена даже в самом худшем случае. Это дает нам
дополнительные плюсы в обеспечении безотказной работы.
42
В QNX реализованы основные функции POSIX используемые в
системах реального времени совместно с основным средством
взаимодействия процессов в QNX–передачей сообщений. Функции POSIX
не встроены в микроядро QNX, они реализованы в виде опциональных
процессов и общих библиотек.
На низком уровне QNX содержит фундаментальные объекты, на
высоком уровне функции, манипулирующие этими объектами.
Минимальной единицей выполнения в QNX является поток (thread).
Несколько потоков выполняются внутри процесса. Каждый процесс в QNX
защищен с помощь блока управления памятью от других процессов. То есть
один процесс не может залезть в адресное пространство другого и нарушить
работу всей системы.
43
Рассмотрим, как взаимодействуют между собой потоки и процессы и
что из этого мы можем использовать при построении нашей системы
высокой доступности.
Основным, как я уже писал, способом взаимодействия между потоками
является передача сообщений. Помимо передачи сообщений существует и
другие примитивы синхронизации, такие как сигналы, очереди сообщений
POSIX, разделяемая память, каналы, семафоры и мьютексы. Такое
разнообразие примитивов синхронизации дает нам некую гибкость в
построении приложений.
Рассмотрим передачу сообщений подробнее. Осуществляется передача
с помощью функций MsgSend(),MsgReceive()и MsgReply(). Поток посылает
сообщение другому потоку (он может быть внутри другого процесса) и
блокируется, до тех пор, пока поток, которому предназначается сообщение
не вызовет MsgReply(), обработает сообщение и ответит с помощью
MsgReply(). Если же поток вызвал MsgReply() он будет блокирован до тех пор
пока кто нибудь не пошлет ему сообщение с помощью MsgSend(). Это так
называемая синхронная передача сообщений.
44
Таким образом, выполняется синхронизация между посылающим и
принимающим потоками. Посылающий поток блокируется, а принимающий
запускается на выполнение. Это не требует никакой дополнительной работы
от ядра по определению какой поток выполнять следующим. Это позволяет
избежать потребления ресурсов и возникновения задержек.
Сообщение копируется непосредственно из адресного пространства
одного потока в адресное пространство другого, без дополнительной
буферизации. Таким образом, производительность передачи сообщений
зависит от аппаратного обеспечения. Ядро не добавляет никакой
дополнительной информации в сообщение. Сообщения имеют взаимно
определенный смысл только между посылающим и принимающим потоками.
Однако QNX поддерживает и расширенные сообщения с дополнительной
информацией от пользовательских процессов или потоков. Примитив
передачи сообщений поддерживает передачу несколькими частями, поэтому
все равно ни посылающей, ни принимающей стороне не нужен
промежуточный буфер.Вместо этого обе стороны определяют таблицу
векторов в которой указано где в памяти находятся фрагменты сообщений.
Передача по частям позволяет сообщениям в которых заголовок
отделен от данных быть переданными без потерь в производительности.
Обычно такие потери связаны с копированием блока данных и
присоединением к заголовку для составления целикового сообщения.
45
Передача сообщений по частям активно используется файловыми
системами. При чтении данные копируется прямо из кэша файловой системы
по частям. Каждая часть указывает на этот кэш.
Есть несколько вариаций передачи сообщений. Сообщения
передаваемые не по частям, без использования дополнительного вектора в
памяти назовем простыми.
Функция
Посылаемое
Ответное сообщение
сообщение
MsgSend()
Простое
Простое
MsgSendsv()
Простое
По частям
MsgSendvs()
По частям
Простое
MsgSendv()
По частям
По частям
46
Остальные функции (MsgReceive, MsgReply()) просто добавляют vк
себе в конец для сообщения по частям.
Сообщения передаются с помощью специально созданных каналов.
Поток, желающий получать сообщений создает канал, другой поток, который
хочет сообщения отправлять присоединяется к этому каналу. Как только
соединение установлено, через него можно посылать сообщения с помощью
MsgSend().Каналы и связи идентифицируются целочисленным
идентификатором. Связи отображаются напрямую в дескрипторы файлов,
поэтому можно посылать сообщение прямо файловому дескриптору.
Для создания канала и установки соединения используется следующее
API:
ChannelCreate() – создает канал для приема сообщений
ChannelDestroy() – уничтожает канал
ConnectAttach() –устанавливает соединение с каналом
ConnectDetach()- разрывает соединение.
Сервер
Канал
Клиент
Соединения
Сервер
Канал
47
Процессы, действующие как серверы, могут обрабатывать сообщения
например так:
chid = ChannelCreate(flags);
SETIOV(&iov, &msg, sizeof(msg));
while(true)
rcd_id = MsgReceivev(chid, &iov, parts, &info);
switch( msg.type) {
// Здесь выполняется обработка сообщений
}
MsgReplyv(rcv_id, &iov, rparts);
}
Код, приведенный выше позволяет потоку принимать сообщения от
любого другого подключенного к каналу. Канал содержит в себе три
очереди: одну очередь для потоков, ожидающих сообщений, одну для
потоков, пославших сообщение, которое еще не дошло, и наконец, одну
очередь для потоков пославших сообщение, которое было доставлено, но на
которое еще не пришел ответ.
Канал
Клиент
Канал
Клиент
Несколько потоков
могут ожидать на канале
Несколько клиентов
могут быть поставлены в
очередь на одном канале
48
Находящееся в любой очереди сообщение блокирует ожидающий
поток.
Помимо синхронной посылки сообщений поддерживаются также
короткие неблокирующие сообщения (пульс). Такие сообщения могут
состоять максимум из 5 байтов (4 на данные, 1 на код). Пульс часто
используется для уведомления потока о прерывании или еще каком - либо
событии без блокировки.
Процессы принимают сообщения в порядке приоритета. Когда поток в
процессе получает сообщение его приоритет приравнивается к приоритету
пославшего это сообщения потока. Это позволяет избежать инверсии
приоритетов и вовремя среагировать на сообщение.
Весь механизм передачи сообщений легко расширяется на несколько
машин благодаря нативному протоколу, используемому в QNX - QNET.
Qnet представляет из себя группу доверенных машин. Qnet
предоставляет возможность этим машинам расшаривать свои ресурсы.
При использование Qnet можно использовать стандартные системные
утилиты (mv, cp и т.д.) для манипулирования файлами так, как будто они
находятся на локальной машине. Помимо файлов также можно работать с
процессами на других машинах.
Иными словами Qnet предоставляет возможность легкого
масштабирования системы. При добавление машины в сеть Qnet она
49
получает доступ к ресурсам сети, и все машины сети получают доступ к
ресурсам новой машины.
Можно также распараллелить программу на несколько машин.
Процессы, выполняющиеся на разных машинах, с помощью Qnet могут
прозрачно взаимодействовать между собой с помощью передачи друг другу
сообщений. Ровно так же процессы взаимодействуют на одной машине.
Иные формы межпроцессорного взаимодействия также работают через
Qnet (сигналы, очереди сообщений, именованные семафоры)
Для понимания того, как это работает, рассмотрим например
системный вызов open() для открытия файла. В сети Qnet open() вызывается
точно также, как и в случае одной машины, за одним исключением необходимо дополнительно указать имя узла, на который отправляется
команда. По этому имени впоследствии получается дескриптор узла, которые
используется для коммуникации на низком уровне ядра.
Рассмотрим, как это работает подробнее. При подключении узла к сети
Qnet, пространство путей файловой системы становится доступно всем
машинам сети, т.е. мы получаем как бы примонтированную файловую
систему добавленной машины ко всем машинам сети. Пространство путей
каждой машины хранится в каталоге /net. Каталог /net создается менеджером
Qnet. Каталог доступен только после включения Qnet.
Если, например, мы добавили узел node2 к нашей сети, то в каталоге
/net мы увидим следующее:
/net/node2/bin
/net/node2/home
….. И так далее.
50
Таким образом, можно открывать файлы на удаленных машинах так,
как будто они находятся на локальной машине.
Некоторые примеры использования Qnet:
- Отобразить содержимое файла на машине node2:
less /net/node2/etc/TIMEZONE
- Получение системной информации обо всех машинах
подключенных к Qnet:
pidinnet
- Получение информации о процессах на другой машине
pidin -nnode2 | less
- Возможно, даже запускать процессы на удаленной машине:
on -fnode2 date
Открыть устройство, подключенное к последовательному порту на
удаленной машине:
fd = open("/net/node2/dev/ser1", O_RDWR….);
Также можно получать доступ к очередям сообщений другой машины.
При создании очереди с помощью mq_open() очередь появляется в системе в
каталоге /dev/mqueue. На другой машине она будет доступна в каталоге
/net/nodename/dev/mqueue.
51
Точно так же можно получить доступ к именованным семафорам на
другой машине. Например, можно использовать адрес
/net/nodename/semaphore_location в системном вызове sem_open().
Благодаря Qnet расширяется функционал моего кластера. Становится
проще писать приложения для распределенного вычисления на нескольких
узлах кластера. Программисту нужно будет указывать, с какими сервисами
работать с помощью их путей в файловой системе удаленного узла. Если
путь в удаленной системе заранее неизвестен, то к ресурсу можно
обращаться по именам с помощью менеджера GlobalNameService.
GNS работает в двух режимах: серверном и клиентском. Серверный
GNS - центральная база данных, которая хранит короткие имена и
обрабатывает запросы на получение имени по пути в файловой системе и
запросы на подключение. Клиентский GNS отдает имена ресурсов GNS
серверу и обрабатывает запросы между локальными приложениями и GNS
сервером.
Имя
Путь
52
Когда приложение взаимодействует с GNS оно использует следующее
API:
- Сервер использует name_attach() для регистрации сервиса в GNS и
name_deattach для обратного процесса.
- Клиент использует name_open() для открытия зарегистрированного
сервиса и name_close() соответственно для его закрытия.
Так как такой функционал полезен в построении кластера рассмотрим
этот процесс подробнее:
Прежде чем зарегистрировать сервис необходимо решить
регистрировать его локально или глобально. Если регистрировать локально,
только локальный узел сможет видеть этот ресурс, другие узлы не будут его
видеть. Если регистрировать глобально каждый узел будет видеть ресурс и
сможет им пользоваться.
Типичный вызов name_attach() выглядит так:
if ((attach = name_attach(NULL, "printer", NAME_FLAG_ATTACH_GLOBAL) ==
NULL){
returnEXIT_FAILURE;
}
В качестве аргументов в функцию передается имя сервиса, флаг
глобальный/локальный и обработчик распределенного выполнения, который
получается после создания структуры распределенного выполнения . Если в
качестве первого аргумента указан ноль, структура распределенного
выполнения создается автоматически.
53
Если какие то два узла регистрируют одно и то же имя сервиса. Это
рассматривается системой как избыточность, если одно приложение выводит
сервис из GNS или если оно завершается, то другое приложение с тем же
ресурсом берет все на себя.
Клиент для присоединения к сервису вызывает функцию name_open().
if ((fd = name_open("printer", NAME_FLAG_ATTACH_GLOBAL)) == -1)
{
returnEXIT_FAILURE;
}
Если флаг не указывать GNS будет искать ресурс только локально.
Все зарегистрированные сервисы хранятся в каталоге /dev/name/global
или /dev/name/local в зависимости от того, как они зарегистрированы.
Для всех узлов в локальной сети каталог /dev/name/global одинаковый. А
каталог /dev/name/local хранит информацию о локально зарегистрированных
сервисах.
Для корректной работы GNS нужен как минимум один GNS сервер. Он
содержит у себя база данных всех зарегистрированных сервисов и управляет
этой базой. GNS клиентов может быть много на разных узлах системы.
Для обеспечения нужной нам избыточности можно запустить 2 GNS
сервера на разных узлах. Они будут содержать одинаковую базу данных
сервисов. Также можно запустить два GNS сервера для работы в различных
глобальных доменах.
54
В случае с избыточным GNS каждый клиент регистрирует сервис в
каждом GNS сервере. Между собой GNS сервера общаться не могут.
Вот так выглядит избыточная конфигурация GNS сервера.
Два сервера GNS не обязательно запускать одновременно. Можно
запустить сначала один, а затем через некоторое время второй с ключом sbackup_server. То есть мы указываем второму серверу скачать все текущую
базу с первого и уведомить всех клиентов о том, что появился еще один
сервер.
55
Есть ситуации, когда одни клиенты подключены к одному серверу, а
другие к другому. Для каждого сервера сервисы будут уникальны.
Таким образом, клиент определяет по какой схеме работают GNS
сервера. Если клиент сконфигурирован на взаимодействие с двумя и более
серверами значит конфигурация избыточная.
Нет никакого ограничения на количество запущенных GNS серверов,
однако чем их больше, тем больше накладные расходы вызывает функция
регистрации сервиса name_attach().
56
Помимо всего прочего QNET поддерживает QoS. В зависимости от
заданной политики qnet распределяет трафик между сетевыми интерфейсами.
Существует три политики выбора интерфейса:
- loadbalancing ( политика по умолчанию ) - равномерно распределяет
трафик между интерфейсами
- preffered - использует один интерфейс, игнорируя все другие, до тех
пор пока интерфейс не откажет
- exclusive - использует только один интерфейс, даже если он откажет
Рассмотрим подробнее каждую из них:
- loadbalancing - Qnet решает какой из сетевых интерфейсов
использовать в зависимости от текущей загруженность и скорости
интерфейсов. Пакаты становятся в очередь к тому интерфейсу,
который быстрее всех их обработает. Это позволяет повысить
пропускную способность сети между узлами кластера. Если один из
интерфейсов откажет, QNET автоматически переключится на
другой доступный. Время переключения можно настроить. Qnet
переодически шлет пакеты отказавшему интерфейсу для проверки
того восстановился он или нет. Если интерфейс восстановлен Qnet
снова его задействует.
- preffered - В данном случае можно назначить интерфейс, который
будет использоваться в одиночку до тех пор пока не откажет. После
этого Qnet переключается на другой доступный интерфейс и
продолжает передачу данных, но уже с политикой loadbalancing.
57
Когда предпочитаемый интерфейс восстанавливается, Qnet снова
использует только этот интерфейс.
- exclusive - Здесь используется только один интерфейс, не зависимо
от того сколько интерфейсов еще доступно. Если такой интерфейс
откажет Qnet не будет использовать доступные интерфейсы.
Задаются политики как часть пути к интерфейсу. Например, если мы
хотим использовать интерфейс на узле 1 в эксклюзивном режиме нужно
использовать следующий путь:
/net/node1~exclusive:en0/dev/ser1
Помимо всего вышеописанного QNX поддерживает очень важный и
ключевой механизм для моей работы: менеджер высокой доступности
(HAM – High Avaliability Manager).
Существуют ситуации, когда добавление избыточного железа просто
не подходит. Да и само по себе избыточное железо может стать причиной
сбоев, т.к. чем сложнее система и чем больше в ней компонентов, тем больше
шансов, что какой-то из компонентов откажет.
QNX сама по себе является системой высокой доступности и поэтому
отлично подходит для таких ситуаций. Помимо уже описанной
микроядерности QNX предоставляет компоненты высокой доступности:
HAM - high avaliability manager (менеджер высокой доступности) и high
availability client-side library (клиентская библиотека высокой доступности).
Клиентская библиотека высокой доступности предоставляет функции,
позволяющие автоматически и прозрачно восстановить подключения
ресурсов, вышедшие из строя. Клиент может выбрать какие именно
58
подключения сделать высоко доступными. В обычной системе, когда клиент
общается с сервером и происходит сбой, клиенту возвращается ошибка. В
случае использования библиотеки соединение восстанавливается
практически незамедлительно.
Рассмотрим в качестве примера ситуацию, когда клиент открывает
файл через сетевую файловую систему. Если вдруг NFS сервер, по какой-то
причине отключится HAM перезапустит его и примонтирует заново. В
обычной ситуации все открытые сессии будут устаревшими. Если же
использовать функцию библиотеки высокой доступности ha_attach, все
сессии сами восстановятся. Функция ha_attach позволяет клиенту
предоставить собственную функцию восстановления соединения, которая
будет вызвана автоматически. Функция восстановления может просто
перезапустить сессию или же произвести более детальное восстановление.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <ha/cover.h>
#define TESTFILE "/net/machine99/home/test/testfile"
typedef struct handle {
int nr;
int curr_offset;
59
} Handle ;
int recover_conn(int oldfd, void *hdl)
{
int newfd;
Handle *thdl;
thdl = (Handle *)hdl;
newfd = ha_reopen(oldfd, TESTFILE, O_RDONLY);
if (newfd >= 0) {
// устанавливаем смещение в последнюю известнуюточку
lseek(newfd, thdl->curr_offset, SEEK_SET);
// счетчик успешных восстановлений
(thdl->nr)++;
}
return(newfd);
}
int main(int argc, char *argv[])
{
int status;
int fd;
int fd2;
Handle hdl;
char buf[80];
hdl.nr = 0;
hdl.curr_offset = 0;
// открываем сессию
60
// функцией восстановления будет recover_conn
// hdl будет передан ей в качестве параметра
fd = ha_open(TESTFILE, O_RDONLY, recover_conn, (void *)&hdl, 0);
if (fd < 0) {
printf("could not open file\n");
exit(-1);
}
status = read(fd,buf,15);
if (status < 0) {
printf("error: %s\n",strerror(errno));
exit(-1);
}
else {
hdl.curr_offset += status;
}
fd2 = ha_dup(fd);
// fs-nfs2 отказывает,в этот момент
// начинается процесс восстановления
// Старый дескриптор fd уже не актуален
sleep(18);
// Пытаемся читать что - то из файла с дескриптором fd
// получаем ошибку, восстанавливаемся с помощью recover_conn
status = read(fd,buf,15);
if (status < 0) {
printf("error: %s\n",strerror(errno));
exit(-1);
}
else {
61
hdl.curr_offset += status;
}
printf("total recoveries, %d\n",hdl.nr);
ha_close(fd);
ha_close(fd2);
exit(0);
}
Так как библиотека взаимодействует с низкоуровневым вызовом
MsgSend(), то стандартные библиотечные функции (open(), read(), write(),
printf() и т.д.) также можно сделать высокодоступными.
Непосредственно процесс восстановления осуществляет HAM менеджер ресурсов, мониторит критически важные ресурсы и выполняет
многоступенчатое восстановления после сбоя. HAM использует простую
систему издатель/подписчик для мониторинга возникновения различных
событий. Реакцией на возникновение события может быть действие или
последовательность действий. К примеру мы запустили NFS, а затем
примонтировали несколько директорий из различных мест. Можно указать
менеджеру просто перезапустить NFS в случае сбоя, а можно кроме
перезапуска еще и заново примонтировать соответствующие директории.
HAM является каналом, по которому остальные части системы могут
получать и доставлять информацию о состоянии системы в целом.
В построении отказоустойчивой системы очень важно чтобы не было
так называемой единой точки отказа - компонента, выход из строя которого
приведет к выходу из строя всей системы. HAM, осуществляющий
62
мониторинг системы и ресурсов сам по себе никогда не должен стать единой
точкой отказа. Во время запуска HAM создает точную копию себя - процесс
под названием Guardian. Guardian ждет пока HAM откажет и, в этом случае,
становится на его место. Если, по какой то причине, откажет сам Guardian то
HAM заменит его, создав новую копию себя.
Рассмотрим подробнее как устроен HAM.
HAM состоит из трех основных частей :
- Сущности
-
Условия
-
Действия
- Сущности - объекты, за которыми следит HAM. Обычно это pid
процесса. Так же как и процессы сущности идентифицируются по
уникальному дескриптору. С каждой сущностью ассоциировано
символьное имя, уникальное в пределах одной системы.
Существует три фундаментальных типа сущностей:
- Самоприсоединенные сущности. Такие сущности сами выбирают
что и когда мониторить, а также когда остановить мониторинг.
Такие сущности говорят менеджеру "Сделай то то если я умру".
- Внешнеприсоединенные сущности. Такими могут быть основные
сервисы и процессы, живучесть которых очень важна. Эти сущности
полезны когда один процесс хочет знать о смерти другого, а другой
об этом не заботится.
63
- Глобальные сущности. Фактически это любая сущность системы. С
помощью таких сущностей можно сделать что то если любой
процесс в системе умирает.
- Условия - представляют состояние сущностей.
Условие
Описание
CONDDEATH
Сущность умерла.
Сущность ненормально завершила свою работу. Когда
CONDABNORMALDEATH сущность умирает таким способом, генерируется файл дампа
ядра.
CONDDETACH
Сущность больше не является объектом мониторинга HAMа.
CONDATTACH
HAM мониторит сущность.
CONDBEATMISSEDHIGH
The entity missed sending a "heartbeat" message specified for a
condition of "high" severity.
CONDBEATMISSEDLOW
The entity missed sending a "heartbeat" message specified for a
condition of "low"
CONDRESTART
Сущность была успешно перезапущена.
CONDRAISE
Произошло какое то внешнее событие. Подписчики на это
события могут указывать что делать при его возникновении.
CONDSTATE
Состояние сущности изменилось. Подписчики на изменения
могут также указывать что при этом делать.
CONDANY
Любое условие. Можно также ассоциировать какое то
действие с этим условием
Для всех условий, кроме CONDRAISE и CONDSTATE HAM является
издателем. Подписчики могут объявлять набор действий производимых при
появлении соответствующего условия.
- Действия
Действие ассоциируется с каким - либо условием и выполняется когда
условие истинно. HAM предоставляет несколько функций для различных
действий:
64
Действие
Описание
ham_action_restart()
Перезапустить сущность.
ham_action_execute()
Запустить какую - либо команду.
ham_action_notify_pulse()
Уведомить процессы о возникновении условия.
Уведомление посылается со специальной переменной
pulse, значение которой задает процесс, желающий
получить уведомление.
ham_action_notify_signal()
Уведомить процессы о возникновении условия.
Уведомление посылается с использованием специального
сигнала, значение которого задает процесс, желающий
получить уведомление.
ham_action_notify_pulse_node()
То же самое что и ham_action_notify_pulse() только с
указанием конкретного узла
ham_action_notify_signal_node()
То же самое что и ham_action_notify_signal() только с
указанием конкретного узла
ham_action_waitfor()
Позволяет организовывать паузы между действиями, если
их несколько
ham_action_heartbeat_healthy()
Если сущность перестает посылать сигналы heartbeat
функция перезапускает механизм и запускает
условие CONDBEATMISSEDHIGH
или CONDBEATMISSEDLOW.
ham_action_log()
Посылает условие в лог.
На случай если эти действия вдруг не сработают или откажут можно
указать дополнительные функции обработки таких отказов:

ham_action_fail_execute()

ham_action_fail_notify_pulse()

ham_action_fail_notify_signal()

ham_action_fail_notify_pulse_node()

ham_action_fail_notify_signal_node()

ham_action_fail_waitfor()

ham_action_fail_log()
Таким образом, можно обрабатывать даже не выполненные действия.
65
Сущности и другие компоненты системы могут уведомлять HAM о
некоторых событиях, а HAM в свою очередь может доставлять эти
уведомления другим компонентам, заинтересованным в этих событиях.
Существует два пути уведомления HAM о событиях:
- Уведомление об изменении состояния.
Если нужно чтобы один компонент системы знал что случилось с
другим соответствующая сущность может уведомить HAM об изменении
своего состояния. HAM в ответ на это генерирует определенные события.
Заинтересованный компонент подписывается на эти события и обрабатывает
их.
Для уведомления об изменении состояния необходимо вызвать
функцию ham_entity_condition_state(). Для подписки на такие уведомления
необходимо вызвать функцию ham_condition_state().
- Другие уведомления.
В дополнении к вышеописанному сущности могут уведомлять HAM о
событиях с помощьюфункции ham_entity_condition_raise(). При этом
дополнительно можно указывать тип, класс и приоритет события. Благодаря
этому можно подписываться на более специфические условия. Подписка
осуществляется с помощью функции ham_condition_raise().
Таким образом, для реализации высокой доступности мы выбираем
сущности, критичные для работы. Выбираем условия для обработки и пишем
соответствующие обработчики. Неплохо было бы еще знать о состоянии всех
сущностей и о статистике перезапусков/смертей. HAM предоставляет такую
возможность с помощью доступной только для чтения файловой системы.
Находится она в директории /proc/ham. Всю информацию и статистику
можно вывести с помощью команды ls (ls /proc/ham).
66
Заключение исследовательской части.
Таким образом, QNX предоставляет множество функций высокой
доступности «из коробки». Кроме того QNX микроядерная система, что
позволяет запускать ее на встраиваемых системах с очень ограниченным
набором ресурсов и делать отказоустойчивые системы в таких областях как
управление системами жизнеобеспечения пациента и автомобильная
электроника.
Linux-HA/Pacemaker представляют из себя целый программный
комплекс, который сам по себе увеличивает вероятность отказа системы.
Кроме того Linux - монолитная ОС, поэтому если откажет какой то
драйвер это скорее всего приведет к отказу ОС целиком и, соответственно
отказу целой машины в кластере. Кластер на QNX попытается сначала
локально восстановить ресурс и только после этого, если ресурс не
восстанавливается, перебросить работу на другой узел кластера.
QNX также предоставляет механизм балансировки нагрузки, так же из
"коробки". Благодаря Qnet взаимодействие между процессами в
распараллеленной программе становится прозрачным.
Так как Qnet предоставляет возможность писать параллельные
программы и имеет встроенный механизм балансировки нагрузки, то кластер
объединенный сетью Qnet становится еще и вычислительным кластером. То
есть помимо высокой доступности мы еще в некоторых случаях мы получаем
производительность. Кластер на QNX легко масштабируется простым
добавлением машины и включением Qnet на ней.
67
Готовые кластерные решения очень дороги и требовательны к железу.
В случае использования QNX мы получаем очень много функций высокой
доступности сразу при этом железо может быть практически любым, сфера
применения QNX очень широкая.
Остается только организовать кластер аппаратно и написать менеджер
управления ресурсами кластера для координирования всех узлов кластера.
68
Специальная часть
Итак, необходимо используя все преимущества системы QNX
построить на ней кластер высокой доступности. Для тестирования кластера я
буду использовать образы виртуальных машин с QNX в VmwarePlayer.
Практическая часть включает систему управления ресурсами кластера
(программную) а также общую схему работы системы.
Существует несколько типов реализации кластера высокой
доступности. Я, в данной работе постарался реализовать практически все
типы таких кластеров. С алгоритмической точки зрения в менеджере
ресурсов кластера основными типами являются кластера
активный/пассивный и кластер активный/активный.
Архитектура кластера, в общем, выглядит следующим образом:
Менеджер Ресурсов Кластера
HAM
HAM
HAM
Qnet
Qnet
Узел 1
Узел 2
Узел N
…………….
Qnet
Разделяемые ресурсы
69
1) Узлы кластера объединяются в доверенную сеть Qnet.
2) На каждом узле в зависимости от типа кластера выбираются
ресурсы для локального мониторинга
3) На каждом узле запускается менеджер ресурсов кластера
4) Менеджер ресурсов позволяет узлам взаимодействовать друг с
другом и следит за состоянием кластера в целом. Менеджер также
взаимодействует с локальными мониторами ресурсов. Именно он
ответственен за перераспределение ресурсов в случае отказа одного
из узлов кластера и является основной частью системы.
Алгоритм работы менеджера кластера следующий:
Начало
Подготовка служб
кластера, формирование
текущего списка узлов
Формирование текущего
списка процессов на
каждом узле
Ввод данных
Мониторинг
жизнедеятельности
кластера
Конец
70
Для начала после запуска программы выводится список всех узлов,
подключенных к кластеру и формируется список процессов на всех узлах.
Затем администратор кластера указывает какие ресурсы должны быть высоко
доступными. После этого в зависимости от типа кластера осуществляется
мониторинг общего состояния кластера.
Рассмотрим подробнее каждый тип кластера.
Начнем с кластера типа активный/пассивный. В этом случае активно
работает один узел и если он откажет, подключается пассивный и берет на
себя всю нагрузку.
Сначала на выбранном активном узле (мастере) запускаем менеджер.
Менеджер выглядит следующим образом:
71
Менеджер выдает список процессов и доступных узлов.
В случае кластера активный/пассивный выбираем из списка доступных
узлов узел, который будет активным. Остальные автоматически помечаются
пассивными.
Далее выбираем процессы на активном узле, для которых требуется
обеспечить высокую доступность. По нажатию кнопки «Отслеживать
состояние процесса» предлагается выбрать действие по восстановлению в
случае отказаили же написать свое собственное действие.
Активный узел начинает отслеживать состояние критических сервисов.
Пассивные узлы синхронизируются с активным с помощью rsync
Далее программа работает по следующему алгоритму:
72
Кластер типа активный/активный.
В этом случае активно работают все узлы системы и в случае отказа
одного из них другие продолжают работать, перераспределяя нагрузку между
собой.
Для данного типа кластера операционная система QNX дает нам
дополнительные преимущества. Благодаря прозрачному общению между
процессами с помощью сети Qnet, помимо высокой доступности мы также
получаем увеличенную производительность. Распараллеливать приложение
для использования в сети Qnet очень просто, т.к. по сути, процессы в таком
приложении общаются друг с другом так, как будто они на локальной
машине.
В данном типе кластера менеджер ресурсов запускается на всех
машинах. Работает он по следующему алгоритму:
73
74
Кластер типа N+1.
В этом случае в кластере есть один узел, который готов взять на себя
обязанности любого другого. Это бывает полезно, если в кластере на разных
узлах выполняются разные сервисы. В случае если это не так, кластер такого
типа превращается в кластер активный/пассивный.
Алгоритм будет в данном случае почти такой же, как в случае кластера
активный/пассивный, за исключением того, что на каждой активной машине
выбирается свой сервис, а также выбирается машина, которая будет
резервной. Эта машина знает, какие сервисы работают на каждой из машин,
и хранит настройки каждого сервиса. В случае отказа одной из машин,
резервная машина узнает, какие сервисы были на этой отказавшей машине, и
берет на себя ее обязанности.
В алгоритм добавляется проверка сервисов, которые запущены на
умершей машине, в остальном он полностью такой же как и в случае
кластера активный /пассивный.
75
Расчет надежности.
Надежность программного обеспечения.
При расчете надежности программного обеспечения учитывают
следующие показатели:
- Завершенность
- Восстанавливаемость
- Устойчивость
- Доступность
Завершенность
Завершенность – свойство ПО не попадать в состояния отказов
вследствие ошибок и дефектов в программах и данных. Определяется
временем наработки на ошибку и покрытием тестами.
Рассчитаем среднее время наработки на ошибку.
Средняя наработка на ошибку рассчитывается следующим образом:
где λПО – интенсивность ошибок программного обеспечения.
Интенсивность ошибок разрабатываемого программного обеспечения
рассчитывается по формулам:
где τ –время отладки;
α – коэффициент крутизны линии, характеризующий скорость роста
надежности;
N0 – число обнаруженных ошибок во время отладки;
76
N –число строк кода;
Kтп – коэффициент, учитывающий влияние методологии
программирования на надежность ПО;
КТПi - коэффициент, учитывающий использование i-той технологии
программирования;
КЯЗi – коэффициент, учитывающий использование i-го языка
программирования;
КПЛi – коэффициент, учитывающий использование i-ой платформы
программирования.
В данном программном обеспечении использована процедурная
технология программирования (КТПi = 0,1), язык программирования Си
(КЯЗi = 2), операционная система QNX (КПЛi = 1.5)
КТП = 0,1*2*1,5 = 0,3
Количество строк кода N = 2037.
Отладка программного обеспечения производилась с помощью
тестирования в течение 10 часов. Результаты тестирования представлены в
таблице.
Число ошибок
Время отладки
Интенсивность ошибок
13
1
0,001914584
10
7
2
3
0,000736377
0,000343642
5
4
0,000184094
3
5
0,000088365
2
1
6
7
0,000049091
0,000021039
1
8
0,000018409
1
9
0,000016363
0
10
0
77
На основе полученных данных построим кривую зависимости
интенсивности ошибок от времени отладки
Зависимость интенсивности ошибок
от времени отладки
0.0025
Интенсивность ошибок
0.002
0.0015
0.001
0.0005
0
1
2
3
4
5
6
7
8
9
10
Время отладки, часы
Функциональная зависимость интенсивности ошибок ПО от времени
отладки описывается экспоненциальным законом и зависит от коэффициента
крутизны линии, характеризующей скорость роста надежности α, и от
фактического времени отладки ПО. Исходя из анализа результатов
тестирования ПО определяем α = 0,05.
Таким образом, интенсивность ошибок разрабатываемого ПО
составляет:
N
43
0 K

 0,3  0,000633
ТП
N t
2037
 ПО  0  e t  0,000633  e 0,0511  0.0003782
0 
Для разрабатываемого программного обеспечения средняя наработка
на ошибку составит 2682.
78
Степень покрытия тестами функции и структуры программы.
Существует три типа покрытия, для каждого из которых требуется
различное число тестовых примеров:
- Покрытие утверждения
- Покрытие ветвей
- Покрытие условий
Покрытие утверждений. Здесь нужно следить за тем, выполнялась ли
каждая строка кода, по крайней мере, один раз. Чтобы достичь 100%-го
покрытия утверждений, понадобится выполнить утверждение IF, причем оно
должно принять значение TRUE для выполнения соответствующего
требования THEN.
Покрытие ветвей. В данном случае нужно следить затем, была ли взята
каждая ветвь или точка принятия решения при всех возможных исходах.
Чтобы покрытие было 100%-м, требуется два прохода через условие IF, когда
при одном проходе оно принимает значение TRUE, а при другом – FALSE.
Каждый цикл DO-WHILE так же должен быть выполнен при условиях TRUE
и FALSE. Для утверждений CASE или SWITCH требуются тестовые
примеры, которые будут брать все возможные ветки, включая заданные по
умолчанию пути.
Покрытие условий. Оно известно так же как покрытие предикатов и
следит затем, принимает ли каждый операнд в комплексных логических
выражениях значения FALSE/TRUE. Комплексные логические выражения
содержат операторы AND, OR и XOR.
Каждый из этих типов покрытия содержит в себе более низкие уровни.
Достижение 100%- го покрытия ветвей означает 100%- ное покрытие
утверждений. Аналогично достижение 100%- го покрытия условий
автоматически приводит к удовлетворению 100%- го покрытия ветвей.
На основе тестирования были получены следующие коэффициенты:
Коэффициент полноты:
79
К полн 
P
,
100%
Где Р – степень покрытия тестами в процентах.
К полн 
97%
 0,97
100%
Коэффициент достоверности:
К дост 
N пр - N ош
N пр
Где Nпр – число прогонов;
Nош – число ошибок, обнаруженных во время данных прогонов.
Kдост = 600-43/600 = 0,928
К дост 
700 - 34
 0,928
700
Устойчивость
Устойчивость к дефектам и ошибкам – свойство ПО автоматически
поддерживать заданный уровень качества функционирования при
проявлениях дефектов и ошибок или нарушениях установленного
интерфейса.
Появление дефектов, ошибок интерфейса в данной системе может
возникнуть только из-за сбоя технических средств. Поскольку вся вводимая
пользователем информация проверяется на соответствие необходимому типу
данных, то есть устойчивость программы обеспечивается за счет алгоритма.
Для выявления дефектов вследствие сбоя технических средств в
системе присутствует возможность осуществлять контроль над входными.
Промежуточными и конечными данными.
Таким образом, любое несоответствие данных действительности будет
обнаружено оператором.
80
Восстанавливаемость
Восстанавливаемость – свойство ПО в случае отказа возобновлять
требуемый уровень качества функционирования, а также поврежденные
программы и данные.
В случае отказа, чтобы разрабатываемая система соответствовала
требуемому уровню качества функционирования, данную систему
необходимо запустить заново, что составляет 0,5 минут. Однако при этом
данные, обрабатываемые системой на момент отказа, будут потеряны, и
работу с программой нужно начинать сначала. Данное свойство ПО основано
на временной избыточности.
Доступность
Доступность или готовность – свойство ПО быть в состоянии
выполнять требуемую функцию в данный момент времени при заданных
условиях использования.
Коэффициент готовности рассчитывается по формуле:
Tо
,
Tо  Tв
где То – средняя наработка на ошибку (2682 часов),
Kг 
Тв – время восстановления программы (0,1 минуты=0,0016 часа).
Таким образом, коэффициент готовности разрабатываемой системы:
Kг 
2682
2682  0,0016
 0,9999994 .
81
Раздел по безопасности жизнедеятельности.
Защитное зануление системы.
Электрический ток воздействует на организм человека, и это
воздействие зависит от величины тока и времени тока. При напряжениях
380/220 или 220/127 В в тех установка, в которых заземлена нейтраль
задействуют защитное зануление.
Зануление - это намеренное соединение открытых проводящих частей
электроустановок с глухозаземленной нейтральной точкой генератора или
трансформатора в сетях с тремя фазами и с глухозаземленным выводом
источника тока одной фазы, с заземленной точкой источника в сетях
постоянного тока. Зануление выполнятся исходя из соображений
безопасности
Для зануления используется нулевой защитный проводник.
Нулевой защитный проводник(в системе TN – S - PE – проводник) проводник, соединяющий открытые проводящие части с глухозаземленной
нейтральной точкой источника питания трехфазного тока или с заземленным
выводом источника питания однофазного тока.
Нулевой защитный проводник отличают от PEN – проводника и
рабочего нулевого проводника.
Нулевым рабочим проводником (в системе TN – S - N – проводник)
называют проводник, предназначенный для питания электроприемников,
соединенный с глухозаземленной нейтральной точкой генератора или
трансформатора в сетях трехфазного тока, с глухозаземленным выводом
82
источника однофазного тока, с глухозаземленной точкой источника в сетях
постоянного тока, в установках с напряжением до 1 кВ.
Совмещенный (в системе TN– C - PEN - проводник) нулевой защитный
и нулевой рабочий проводник – проводник в электроустановках
напряжением до 1 кВ, совмещающий функции нулевого защитного и
нулевого рабочего проводника.
С помощью зануления обеспечивается защита от поражения
электрическим током в случае косвенного прикосновения. При
прикосновении напряжение корпуса относительно земли снижается и
электроустановка отключается от сети.
Зануление применяется в следующих случаях:
- В установках с напряжением до 1 кВ в трехфазных сетях
переменного тока с заземленной нейтралью;
- В установках с напряжением до 1 кВ в однофазных сетях
переменного тока с заземленным выводом;
- В установках с напряжением до 1 кВ в сетях постоянного тока с
заземленной средней точкой источника.
Рассмотрим принцип действия зануления. При замыкании фазного
провода на зануленный корпус электропотребителя (рисунок ниже)
образуется цепь тока однофазного короткого замыкания (то есть замыкания
между фазным и нулевым защитным проводниками). Ток однофазного
короткого замыкания вызывает срабатывание максимальной токовой защиты,
в результате чего происходит отключение поврежденной электроустановки
от питающей сети. Кроме того, до срабатывания максимальной токовой
защиты происходит снижение напряжения поврежденного корпуса
относительно земли, что связано с защитным действием повторного
83
заземления нулевого защитного проводника и перераспределением
напряжений в сети при протекании тока короткого замыкания.
Принципиальная схема зануления
1 – корпус электроустановки
R0 – сопротивление заземления нейтрали;
RП – сопротивление повторного заземления нулевого защитного
проводника;
Iк – ток короткого замыкания;
Iн – часть тока короткого замыкания, протекающего через
нулевой защитный проводник;
Iз – часть тока короткого замыкания, протекающего через землю
– корпус электроустановки (электродвигатель, трансформатор и т. п.);
Исходя из вышеописанного зануление обеспечивает защиту от
поражения током при замыкании на корпус поскольку ограниченивается
84
время прохождения тока через тело человека и снижается напряжение
прикосновения.
В качестве токовой защиты, обеспечивающей быстрое отключение
установки в случае аварии используются плавкие предохранители и
автоматические выключатели, которые устанавливаются для защиты от
токов короткого замыкания, магнитные пускатели со встроенной тепловой
защитой, контакторы в сочетании с тепловыми реле, осуществляющие
защиту от перегрузки, автоматы с комбинированными расцепителями,
осуществляющие защиту одновременно от токов короткого замыкания и
перегрузки и др.
Рассмотрим подробнее назначение отдельных элементов схемы
зануления. Из рисунка выше видно, что для схемы зануления необходимы
нулевой защитный проводник, глухое заземление нейтрали источника тока и
повторное заземление нулевого защитного проводника.
Рассмотрим назначение этих элементов применительно к наиболее
распространенным электрическим сетям – трехфазным переменного тока.
Назначение нулевого защитного проводника в схеме зануления обеспечение необходимого значение тока однофазного короткого замыкания
для отключения установки путем создания для этого тока цепи с малым
сопротивлением.
Заземление нейтрали обмоток источника тока, питающего сеть до 1 кВ
снижает напряжение открытых зануленных проводящих частей относительно
земли. Напряжение снижается до допустимого значения при замыкании
фазного провода на землю.
85
Повторное заземление нулевого защитного проводника не влияет на
время отключения электроустановки от сети. При эксплуатации зануления
могут возникнуть ситуации, когда повторное заземление нулевого защитного
проводника необходимо. Такая ситуация например возникает при обрыве
нулевого защитного проводника. При применении системы TN
рекомендуется выполнять повторное заземление нулевого защитного
проводника и совмещенного нулевого защитного проводнка на вводе в
электроустановки зданий, а также в других доступных местах. Для
повторного заземления нулевых защитных проводников в первую очередь
используют естественные заземлители.
Нулевые рабочие провода воздушных линий также подвергаются
повторному заземлению. Такие провода одновременно используются как
нулевые защитные проводники. В соответствии с ПУЭ повторные заземления
выполняются на ответвлениях длиной более 200 метров и на конца линий. В
первую очередь при этом стоит использовать естественные заземлители.
Определяется надежность зануления надежностью нулевого защитного
проводника. Поэтому требуется очень аккуратная прокладка этого
проводника. Это исключит возможность обрыва проводника. Кроме этого в
нулевом защитном проводнике нельзя ставть выключатели и другие
приборы, которые могут нарушить его целостность.
Когда нулевые проводники соединяются между собой необходимо
обеспечить надежный контакт, присоединение нулевых проводников к
частям, подлежащим заземлению осуществляется сваркой или болтами.
Нулевые защитные провода имеют отличительную окраску: желтые
полосы на зеленом фоне.
86
Сопротивление петли «фаза – ноль» может изменяться с течением
времени и нужно переодически контролировать это сопротивление.
Измеряют это сопротивление при монтаже и во время эксплуатации в
периоды установленные в нормативно технической документации, а также
при ремонте сети.
Зануление рассчитывают чтобы определить те условия, при которых
быстро отключается поврежденная установка и соблюдается безопасность
для человека, прикоснувшегося к зануленному корпусу.
При этом должны выполняться следующие требования:
В системе TN время автоматического отключения питания не должно
превышать значений, указанных в таблице:
Наибольшее допустимое время защитного автоматического
отключения питания
Значения времени отключения питания, приведенные в таблице
считаются достаточными для обеспечения безопасности.
Расчет защитного зануления системы.
Напряжение Uф=220В
Мощность S=120кВА
87
В качестве защиты будем использовать плавкие предохранители.
Расстояние до потребителя L=110м.
- Ток нагрузки приемника
Iн 
Sн
120000

 181,82 А
3  U ф 3  220
- Ток плавкой вставки.
I пв 
Кi  I н


5  181,82
 363,64 А
2,5
Кi=5-кратность пускового тока, α=1,5-для электродвигателя с
тяжелыми условиями пуска
Выбираем предохранитель типа ПН-2 , его параметры:
Номинальный ток – 400А
Номинальный ток плавкой вставки-315А
Наибольший отключаемый ток – 40000А
-
Сопротивление фазных проводников, сечение 50мм2
Rф 
L
S

0,028 110
 0,044Ом
70
ρ-удельное сопротивление алюминия
S-сечение проводника
L-длина проводника
- Сопротивление зануляющего проводника, сечение 100мм2:
R
н
 L
0.028 100
S
100
0.028 Ом
- Величина внешнего индуктивного сопротивления:
d
0,2
х п  0,29 ln( )  0,29 ln ( )  0,201Ом
r
0,1
- Полное сопротивление петли фаза-нуль
88
zт
0,779
 (R ф  R н ) 2  ( х ф  х н  х п ) 2 ] * 1,1  [
 (0,044  0,036) 2  (0  0  0,201) 2 ] * 1,1 
3
3
 0,467 *1,1  0,5137
zп  [
Где, ZT=0,779Ом-сопротивление трансформатора
Хф=Хн=0-индуктивные сопротивления Al проводов
- Значение тока короткого замыкания
I кз 
U
220

 428,26 А
Z п 0,5137
- Корпусный потенциал
U к  I кз  R н  428,25  0,036  15,42В
- Ток проходящий через тело человека
I чел 
U к 15,42

 0,015 мА  15 мА
R чел 1000
89
Экономическая часть
Расчет затрат на разработку дипломного проекта
Для разработки дипломного проекта требовался один компьютер с
определенным набором программного обеспечения.
Средний срок службы компьютера составляет 36 месяцев. Таким
образом стоимость аренды компьютера рассчитывается по формуле:
(цена компьютера * время работы)/36.
Цена компьютера 25 000 рублей. Время работы 4месяца.
Стоимость аренды = 25000 * 4 / 36 = 2700рублей.
Рассчитаем теперь стоимость необходимого программного обеспечения:
- Среда разработки программ QNX Momentics IDE- учебная лицензия
бесплатно;
- Образ операционной системы QNX Neutrino–учебная лицензия
бесплатно;
- Программа для запуска виртуальных машин – Vmware Player–
бесплатно;
- Microsoft Office для дома и учебы – 3500 рублей
- Windows 8 Pro – 3500 рублей
Для выполнения дипломного проекта также понадобились расходные
материалы:
- Бумага для печати (200 листов) – 150 рублей
- Диски (2 штуки) – 30 рублей
- Флеш-накопитель – 450 рублей
90
Во время дипломного проекта использовался интернет и мобильная
связь.
- Расход на интернет – 550 рублей/месяц;
- Расходы на мобильную связь – 150 рублей/месяц.
Общая стоимость за все время разработки:
- Интернет – 2200 рублей;
- Мобильная связь – 600 рублей.
Заработная плата исполнителя дипломного проекта:
Заработная плата за месяц,
Время выполнения
Сумма,
руб/мес.
ДП, дни
руб.
50000
120
200000
Итого общая стоимость затрат на разработку дипломного проекта:
Наименование
Сумма, руб.
Аренда оборудования
2700
Программное обеспечение
7000
Расходные материалы
630
Интернет и мобильная связь
2800
Заработная плата
200000
Итого
213130
91
Расчет прибыли, налогов и рентабельности.
Прибыль рассчитывается с учетом рентабельности проекта, как товара
и цены проекта без учета налогов. Ценой в данном случае служит общая
сумма затрат.
Поскольку конкуренция на рынке, среди данного вида проектов,
практически отсутствует, то рентабельность будет практически самой
высокой, а именно 55%.
Прибыль = рентабельность * цена без налога
Цена без налога = Затраты + Прибыль
Прибыль = (рентабельность * затраты) / (1 – рентабельность) = (0,45 *
213130) / (1 – 0,45) = 174272 рублей.
Расчет налогов
В данном разделе дипломного проектирования будут рассчитаны все
налоги, которые нужно будет заплатить, продавая данную разработку.
Налог Пенсионного фонда Российской Федерации (ПФР). Данный
налог составляет 26% от минимального размера оплаты труда (МРОТ).
Минимальный размер оплаты труда в России составляет 5205 рублей.
Нпфр = 5205 · 0,26 · 2 · 4 = 10846,2 рублей.
Налог Федерального фонда обязательного медицинского страхования
(ФФОМС). Данный налог составляет 5,1% от минимального размера оплаты
труда (МРОТ). Минимальный размер оплаты труда в России составляет 5205
рублей.
92
Нффомс = 5205 · 0,051 · 4 = 1061,91 рублей.
Налог на доход в рамках Упрощенной системы налогообложения
(УСНО). Данный налог составляет 6% от дохода. Доходом в данном случае
является цена изделия. Цена изделия складывается из общих затрат и
прибыли.
Цена изделия = затраты + прибыль
Нусно = (затраты + прибыль) · 0,06 = 11329,49 рублей.
Итого:
Налоги = Нпфр + Нффомс + Нусно = 22236 рублей.
Расчет общей стоимости разработки
После расчета всех затрат, налогов и прибыли, можно рассчитать
общую стоимость данного проекта.
Цена проекта = Затраты + Налоги + Прибыль
Цена проекта = 213130 + 22236 + 174272 = 409638 рублей.
Итоговая Диаграмма
Расходы
Зарплата
Прибыль
Налог УСНО
Налог ПФР
Налог ФМС
93
Заключение.
94
Список литературы.