В последнее время очередным модным термином в информационных технологиях стала “персистентность”. Много статей публикуется о персистентных данных, dzavalishin разрабатывает целую персистентную операционную систему, поделимся и мы для разнообразия материалами недавно сделанного доклада о персистентных процессах.
Персистентность, говоря по-простому, означает независимость от состояния объемлющей среды. Таким образом, на наш взгляд, вполне правомерно говорить о персистентности процессов, как их способности выполняться независимо от состояния породившей их среды, в том числе – от отказов на нижележащих уровнях, что, вообще говоря, является одной из важнейших задач при разработке автоматических систем управления реального времени.
В статье проводится классификация основных уровней реализации функций отказоустойчивой системы управления, рассмотрение характерных для данных уровней отказов и исследование конкретных технических решений, применяемых на каждом уровне для обеспечения персистентности.
В зависимости от способа реализации системы управления, её иерархическая модель может быть организована различным образом.
Например, таким:
| Вычислительные процессы |
| Специализированная резервированная аппаратура |
| Среда связи с ресурсами |
| Внешние ресурсы |
таким:
| Вычислительные процессы |
| Кластеризованные системные сервисы и операционные среды |
| Хостовая операционная система |
| Аппаратура и встроенные программы |
| Среда связи с ресурсами |
| Внешние ресурсы |
или, теоретически, даже таким:
| Вычислительные процессы |
| Кластеризованный сервер приложений |
| Системные сервисы и операционная система |
| Аппаратура и встроенные программы |
| Среда связи с ресурсами |
| Внешние ресурсы |
Если вы уверенно чувствуете себя отцом вычислительных архитектур и имеете в избытке (относительно функциональной сложности задачи) рабочую силу и творческий потенциал программистов и электронщиков, а тем более, не дай бог, облечены значительной ответственностью перед законом за результаты применения вашей системы, то для вас предназначен первый из обозначенных путей – построение резервируемого аппаратно-программного комплекса со специализированной архитектурой. Этот путь имеет свои корни во встраиваемых системах и является замечательным полем для восходящих карьер железячников и программистов низкоуровневых интерфейсов. Автор постарается более подробно осветить это направление в одной из следующих статей (как мы разрабатывали транспьютер), здесь же ограничимся замечанием, что, к сожалению, этот путь связан со значительными усилиями при ручной работе по реализации высокоуровневых функций, и потому мало приемлем для систем со значительной функциональной сложностью.
Сразу обозначим свои соображения по поводу использования сервера приложений в управляющих системах высокой готовности, проиллюстрированного третьей схемой. При внешней привлекательности для неискушённых в задачах автоматического управления умов, воспитанных разработкой информационных систем, такой подход таит в себе ряд трудноустранимых недостатков. Целевой характеристикой основных современных серверов приложений является обеспечение балансировки нагрузки и повышение пропускной способности обработки, что находится в традиционном противоречии с задачей минимизации времени реакции (латентности), требуемой от систем реального времени. Также такие серверы приложений имеют высокую сложность и сами по себе являются уязвимым звеном с точки зрения обеспечения отказоустойчивости. Наконец, обеспечиваемые ими для своих приложений интерфейсы зачастую оказываются недостаточными для задач автоматического управления, зачастую требующих взаимодействия с железом, использования нестандартных сетевых протоколов и пр. В итоге, хотя автору известен ряд успешных примеров реализации архитектуры сервера приложений для построения информационных систем, но ни одного промышленного внедрения в области систем автоматического управления.
Таким образом, в данной статье остановимся на архитектуре кластера виртуальных машин, проиллюстрированного выше схемой номер 2, и рассмотрим подробнее её основные уровни, двигаясь снизу вверх.
1. Внешние ресурсы
Иногда начинающие разработчики упускают из виду, что, зачастую, наиболее уязвимым звеном контура управления могут являться сами управляемые ресурсы или другие внешние объекты. Эта ситуация прекрасно иллюстрируется старым анекдотом:
– Я – самая умная! – сказала Википедия.
– Я найду что угодно! – сказал «Гугл».
– Я – всё! – сказал Интернет!..
– Ну-ну – сказало Электричество и… моргнуло.
Буквально понимая этот анекдот, если вы не обеспечили ввод электропитания на объект от двух независимых линий электропередач, или, например, подвоз солярки к резервному дизель-генератору с оперативностью не худшей, чем время его автономной работы, то все ваши успехи в области резервирования аппаратуры серверов носят, в плане обеспечения отказоустойчивости, чисто косметический эффект.
Менее буквально интерпретируя сказанное, всегда следует проверять, не заканчивается ли ваша великолепная задублированная цепь управления одним-единственным исполнительным механизмом или источником ресурса, и если это так, то что с этим делать. Например, как известно, стоп-кран в поезде действует совершенно независимо от основной тормозной системы, а не является резервным интерфейсом того же самого основного тормоза.
2. Среда связи с ресурсами
Кроме самих ресурсов, принципиальное значение имеет среда связи между ними. Для нас важнейшими средами являются, в первую очередь, система объектового электропитания и сеть передачи данных.
Проектируя систему объектового электропитания для комплекса высокой готовности, необходимо обеспечить, как минимум, двойную физически раздельную разводку питающей сети, с подключением критичного оборудования к каждой из линий питания либо путём дублирования оборудования, либо путём использования в нём дублированных блоков питания с возможностью работы от разных питающих цепей. Эти моменты кажутся очевидными, однако, в реальной жизни автору доводилось видеть решающий важные задачи объект автоматизации, питание которого было организовано от двух независимых электроподстанций таким образом, что измерительное оборудование было целиком запитано от одной из них, а управляющий им вычислительный комплекс – от другой.
Горячее резервирование сетей передачи данных подразумевает целый ряд проблем, в различной степени привлекающих внимание широкой публики.
Использование альтернативных маршрутов передачи пакетов через резервные соединения неплохо поддерживается обычным интеллектуальным сетевым оборудованием, за исключением случаев использования нестандартных протоколов нижнего уровня.
Двигаясь выше по стеку протоколов, необходимо затронуть вопрос использования устойчивых к полным или частичным сбоям протоколов передачи данных. Частью этого вопроса является широко известный флейм TCP vs UDP.
К достоинствам использования протокола TCP в управляющих системах относятся:
– автоматический контроль целостности;
– произвольный размер передаваемых данных.
К достоинствам использования протокола UDP в управляющих системах относятся:
– отсутствие состояния;
– возможность полудуплекса;
– быстрый возврат из вызовов*;
– быстрая диагностика проблем на уровне стека и возврат кода ошибки.
Использование TCP в системах реального времени требует от разработчика знакомства с параметрами настройки стека, в первую очередь семейством параметров tcp_keepalive. Использование UDP требует чёткого понимания реализации протокола ARP (с этим связана оговорка для сноски* выше). Использование обоих протоколов подразумевает творческое владение настройками размера приёмного буфера.
Вопрос отсутствия состояния у протокола UDP приобретает важность при перезапуске одной из сторон соединения, в том числе – перезапуске на физически отличающемся оборудовании (резервном сервере).
Отдельно необходимо затронуть редко освещаемый вопрос полудуплекса. Реализация некоторых распространённых сетевых сред такова, что, в результате физического или логического нарушения целостности связи, становится возможной ситуация, когда данные передаются от A к Б, но не могут быть переданы от Б к А. Протокол TCP не может функционировать в таких условиях. Протокол UDP способен сохранить одностороннюю связь при одностороннем обрыве (при условии корректной работы нижележащего сетевого оборудования, и исключая вопросы использования ARP при установлении соединения).
В целом, по мнению автора, для передачи коротких управляющих сообщений в IP сети для отказоустойчивой системы более подходит протокол UDP с организацией контроля доставки сообщений или безусловной повторной рассылки на уровне прикладных программ. Для передачи больших объёмов данных подходит координируемое управляющим уровнем использование протокола TCP, с организацией соединений на короткое время.
Продолжение следует.
Автор: vadimr
