В последнее время «настойчивость» стала еще одним модным термином в информационных технологиях.
Опубликовано много статей о постоянных данных, дзавалишин разрабатывает целую персистентную операционную систему, мы также поделимся для разнообразия материалами из недавнего отчета о персистентных процессах.
Постоянство, проще говоря, означает независимость от состояния окружающей среды.
Таким образом, на наш взгляд, вполне правомерно говорить об инерционности процессов, как об их способности выполняться независимо от состояния среды, породившей их, в том числе от сбоев на более низких уровнях, что, вообще говоря, является одним из одной из важнейших задач при разработке систем автоматического управления реального времени.
В статье классифицированы основные уровни реализации функций отказоустойчивой системы управления, рассмотрены типичные уровни отказов для этих уровней, исследованы конкретные технические решения, используемые на каждом уровне для обеспечения инерционности.
В зависимости от способа реализации системы управления ее иерархическая модель может быть организована по-разному.
Например, вот так:
| Вычислительные процессы |
| Специализированное резервное оборудование |
| Ресурсная коммуникационная среда |
| Внешние ресурсы |
| Вычислительные процессы |
| Кластерные системные службы и операционные среды |
| Хостовая операционная система |
| Аппаратное обеспечение и прошивка |
| Ресурсная коммуникационная среда |
| Внешние ресурсы |
| Вычислительные процессы |
| Кластерный сервер приложений |
| Системные службы и операционная система |
| Аппаратное обеспечение и прошивка |
| Ресурсная коммуникационная среда |
| Внешние ресурсы |
Первый из обозначенных путей – построение резервированного аппаратно-программного комплекса со специализированной архитектурой.
Этот путь уходит корнями во встроенные системы и является прекрасным полем для карьерного роста для инженеров аппаратного обеспечения и программистов интерфейсов низкого уровня.
Более подробно это направление автор постарается осветить в одной из следующих статей (как мы разрабатывали транспьютер), а здесь ограничимся замечанием, что, к сожалению, этот путь связан со значительными усилиями в ручной работе по реализации функций высокого уровня и поэтому не очень приемлем для систем со значительной функциональной сложностью.
Сразу изложим наши соображения по поводу использования сервера приложений в системах управления высокой доступности, проиллюстрированные третьей схемой.
При внешней привлекательности для неискушенных в задачах автоматического управления умов, воспитанных развитием информационных систем, такой подход таит в себе ряд трудноустранимых недостатков.
Целью основных современных серверов приложений является обеспечение балансировки нагрузки и увеличение пропускной способности обработки, что традиционно противоречит цели минимизации времени отклика (задержки), требуемого от систем реального времени.
Также такие серверы приложений отличаются высокой сложностью и сами по себе являются уязвимым звеном с точки зрения обеспечения отказоустойчивости.
Наконец, интерфейсы, которые они предоставляют для своих приложений, зачастую оказываются недостаточными для задач автоматического управления, зачастую требующих взаимодействия с аппаратными средствами, использования нестандартных сетевых протоколов и т. д. В результате, хотя автору известен ряд успешных примеры реализации серверной архитектуры приложений для построения информационных систем, но ни одной промышленной реализации в области систем автоматического управления.
Таким образом, в данной статье мы остановимся на архитектуре кластера виртуальных машин, проиллюстрированной выше схемой №2, и более подробно рассмотрим его основные уровни, двигаясь снизу вверх.
1. Внешние ресурсы Иногда начинающие разработчики упускают из виду тот факт, что зачастую наиболее уязвимым звеном в контуре управления могут быть сами управляемые ресурсы или другие внешние объекты.
Эту ситуацию прекрасно иллюстрирует старый анекдот: - Я самый умный! сказала Википедия.
- Я найду что угодно! - сказал Гугл.
- Я все! – сказал Интернет!.
— Ну-ну, — сказало электричество и… моргнуло.
Буквально понимая этот анекдот, если вы не обеспечили электроснабжение объекта от двух независимых линий электропередачи, или, например, подачу солярки на резервный дизель-генератор с КПД не хуже времени автономной работы, то все Ваши успехи в области резервирования серверного оборудования носят с точки зрения обеспечения отказоустойчивости чисто косметический характер.
На менее буквальном уровне вам всегда следует проверять, заканчивается ли ваша большая резервная схема управления единственным исполнительным механизмом или источником ресурсов, и если да, то что с этим делать.
Наиболее совершенные системы автоматического управления позволяют в случае выхода из строя какого-либо механизма управляемой системы попытаться выполнить часть ее функций, используя остальные механизмы, обычно выполняющие другие функции.
Например, терминальная система управления космической ракеты может компенсировать преждевременное выключение двигателя третьей ступени дополнительной работой разгонного блока.
Примечание Это не следует понимать в том смысле, что в системе управления терминалом ракеты существует специальная ветвь кода «Работа разгонного блока при неисправности третьей ступени».
На самом деле контур управления просто устроен таким образом, что возможности различных управляемых систем перекрывают друг друга, и каждая из них пытается сделать максимум возможного для достижения конечной цели из той ситуации, в которой она фактически находится.
2. Среда для общения с ресурсами Помимо самих ресурсов, фундаментальное значение имеет среда связи между ними.
Для нас важнейшими средами являются, прежде всего, система электроснабжения объекта и сеть передачи данных.
При проектировании системы электроснабжения объектов комплекса высокой готовности необходимо обеспечить не менее двух физически раздельных проводок электросети с подключением ответственного оборудования к каждой из линий электропередачи либо путем дублирования оборудования, либо за счет использования в нем дублирующих источников питания с возможностью работы от разных цепочек поставок.
Эти моменты кажутся очевидными, однако в реальной жизни автору довелось увидеть решающий важные задачи объект автоматизации, питание которого было организовано от двух независимых электрических подстанций таким образом, что измерительное оборудование полностью питалось от одной из них.
, а управляющий им компьютерный комплекс был от другого .
Сети передачи данных с горячим резервом связаны с рядом проблем, которые привлекли разную степень общественного внимания.
Использование альтернативных маршрутов передачи пакетов по резервным соединениям хорошо поддерживается обычным интеллектуальным сетевым оборудованием, за исключением случаев, когда используются нестандартные протоколы нижнего уровня.
Двигаясь выше по стеку протоколов, необходимо решить вопрос использования протоколов передачи данных, устойчивых к полным или частичным сбоям.
Частью этого вопроса является хорошо известный флейм TCP и UDP. К преимуществам использования протокола TCP в системах управления относятся: – автоматический контроль целостности; – произвольный размер передаваемых данных.
К преимуществам использования протокола UDP в системах управления относятся: – отсутствие состояния; – возможность полудуплекса; – быстрый возврат звонков*; — быстро диагностировать проблемы на уровне стека и возвращать код ошибки.
Использование TCP в системах реального времени требует от разработчика знакомства с параметрами конфигурации стека, в первую очередь с семейством параметров tcp_keepalive. Использование UDP требует четкого понимания реализации протокола ARP (это связано со сноской* выше).
Использование обоих протоколов требует творческого контроля над настройками размера приемного буфера.
Вопрос безгражданства в протоколе UDP становится актуальным при перезапуске одной из сторон соединения, в том числе перезапуске на физически другом оборудовании (резервном сервере).
Отдельно необходимо затронуть редко освещаемый вопрос полудуплекса.
Реализация некоторых распространенных сетевых сред такова, что в результате физического или логического нарушения целостности связи становится возможной ситуация, когда данные передаются от A к B, но не могут быть переданы от B к A. Протокол TCP не может работать в таких условиях.
Протокол UDP способен поддерживать одностороннюю связь в случае одностороннего разрыва (при условии корректной работы основного сетевого оборудования и исключения проблем использования ARP при установлении соединения).
В целом, по мнению автора, для передачи коротких управляющих сообщений в IP-сети для отказоустойчивой системы больше подходит протокол UDP с контролем доставки сообщений или безусловным перераспределением на уровне прикладной программы.
Для передачи больших объемов данных подходит использование протокола TCP, согласованного уровнем управления, с организацией соединений за короткое время.
Продолжение: часть 2 Теги: #ИТ-инфраструктура #Системное администрирование #Администрирование серверов #эксплуатация #высокая доступность #надежность #ха #системы управления #высокая доступность
-
Чтение Цветной Инструкции.
19 Oct, 24 -
Карта Гравитационного Поля Земли
19 Oct, 24 -
Дарю Комплект Книг
19 Oct, 24 -
Волонтерство. Да Или Нет?
19 Oct, 24 -
Полмиллиона На Web 3.0
19 Oct, 24
