До питання реалізації персистентних процесів в керуючих системах реального часу (частина 1)

останнім часом черговим модним терміном в інформаційних технологіях стала «персистування». Багато статей публікується про персистентних даних, dzavalishin розробляє цілу персистентную операційну систему, і ми поділимося для різноманітності матеріалами нещодавно зробленого доповіді про персистентних процесах.

Персистування, кажучи по-простому, означає незалежність від стану яка обіймає середовища. Таким чином, на наш погляд, цілком правомірно говорити про персистентності процесів, як їх здатності виконуватися незалежно від стану породила їх середовища, в тому числі – від відмов на нижчих рівнях, що, взагалі кажучи, є однією з найважливіших задач при розробці автоматичних систем керування реального часу.

У статті проводиться класифікація основних рівнів реалізації функцій відмовостійкої системи керування, розгляд характерних для даних рівнів відмов і дослідження конкретних технічних рішень, застосовуваних на кожному рівні для забезпечення персистентності.

Залежно від способу реалізації системи управління, її ієрархічна модель може бути організована різним чином.

Наприклад, таким:
Обчислювальні процеси
Спеціалізована резервована апаратура
Середа зв'язку з ресурсами
Зовнішні ресурси
таким:
Обчислювальні процеси
Кластеризовані системні сервіси і операційні середовища
Хостова операційна система
Апаратура і вбудовані програми
Середа зв'язку з ресурсами
Зовнішні ресурси
або, теоретично, навіть таким:
Обчислювальні процеси
Кластеризованный сервер додатків
Системні сервіси і операційна система
Апаратура і вбудовані програми
Середа зв'язку з ресурсами
Зовнішні ресурси
Якщо ви впевнено почуваєте себе батьком обчислювальних архітектур і маєте в надлишку (щодо функціональної складності завдання) робочу силу і творчий потенціал програмістів і електронників, а тим більше, не дай бог, наділені значною відповідальністю перед законом за результати застосування вашої системи, то для вас призначений перший з означених шляхів – побудова резервується апаратно-програмного комплексу зі спеціалізованою архітектурою. Цей шлях має свої коріння у вбудованих системах і є чудовим полем для висхідних кар'єр железячників і програмістів низькорівневих інтерфейсів. Автор постарається більш докладно висвітлити це напрям в одній з наступних статей (як ми розробляли транспьютер), тут же обмежимося зауваженням, що, на жаль, цей шлях пов'язаний зі значними зусиллями при ручній роботі по реалізації високорівневих функцій, і тому мало прийнятний для систем зі значною функціональною складністю.

Відразу позначимо свої міркування з приводу використання сервера додатків в керуючих системах високої готовності, проілюстрованого третьої схемою. При зовнішній привабливості для недосвідчених в задачах автоматичного управління умів, вихованих розробкою інформаційних систем, такий підхід таїть у собі ряд трудноустранимых недоліків. Цільовим завданням основних сучасних серверів додатків є забезпечення балансування навантаження і підвищення пропускної здатності обробки, що знаходиться в традиційному протиріччі з завданням мінімізації часу реакції (латентність), необхідної від систем реального часу. Також такі сервери додатків мають високу складність і самі по собі є вразливим ланкою з точки зору забезпечення відмовостійкості. Нарешті, забезпечуються ними для своїх додатків інтерфейси часто виявляються недостатніми для задач автоматичного керування, часто потребують взаємодії з залізом, використання нестандартних мережевих протоколів та ін. У підсумку, хоча авторові відомий ряд успішних прикладів реалізації архітектури сервера додатків для побудови інформаційних систем, але жодного промислового впровадження в області систем автоматичного управління.

Таким чином, у даній статті зупинимося на архітектурі кластера віртуальних машин, проілюстрованого вище схемою номер 2, і розглянемо детальніше її основні рівні, рухаючись знизу вгору.

1. Зовнішні ресурси

Іноді початківці розробники випускають з уваги, що, найчастіше, найбільш вразливою ланкою контуру управління можуть бути самі керовані ресурси або інші зовнішні об'єкти. Ця ситуація чудово ілюструється старим анекдотом:

– Я – найрозумніша! – сказала Вікіпедія.
– Я знайду що завгодно! – сказав «Гугл».
– Я – все! – сказав Інтернет!..
– Ну-ну – сказало Електрика та… моргнув.


Буквально розуміючи цей анекдот, якщо ви не забезпечили введення електроживлення на об'єкт від двох незалежних ліній електропередач, або, наприклад, підвезення солярки до резервного дизель-генератора з оперативністю не гіршою, ніж час його автономної роботи, то всі ваші успіхи в області резервування апаратури серверів носять, в плані забезпечення відмовостійкості, чисто косметичний характер.

Менш буквально інтерпретуючи сказане, слід завжди перевіряти, чи не закінчується ваша чудова задублированная ланцюг управління одним-єдиним виконавчим механізмом або джерелом ресурсу, і якщо це так, то що з цим робити. Наприклад, як відомо, стоп-кран в поїзді діє цілком незалежно від основної гальмівної системи, а не є резервним інтерфейсом того ж самого основного гальма.

Найбільш просунуті системи автоматичного керування дозволяють, у разі виходу з ладу якогось механізму керованої системи, спробувати виконати частину його функцій за допомогою залишилися механізмів, штатно мають інші функції. Наприклад, термінальна система управління космічної ракети може компенсувати передчасне вимикання двигуна третього ступеня додатковою роботою розгінного блоку. ПриміткаНе треба розуміти в тому сенсі, що в термінальній системі управління ракетою є спеціальна гілка коду «Робота розгінного блоку при несправності третього ступеня». Насправді, просто контур управління спроектований таким чином, що можливості різних керованих систем перекривають один одного, і кожна з них намагається зробити максимум можливого для досягнення кінцевої мети з тієї ситуації, в якій вона фактично опинилася.

2. Середа зв'язку з ресурсами

Крім самих ресурсів, принципове значення має середовище зв'язку між ними. Для нас найважливішими середовищами є, в першу чергу, система об'єктового електроживлення і мережа передачі даних.

Проектуючи систему об'єктового електроживлення для комплексу високої готовності, необхідно забезпечити як мінімум подвійну фізично роздільну розведення живильної мережі, з підключенням критичного устаткування до кожної з ліній живлення або шляхом дублювання обладнання, або шляхом використання в ньому дубльованих блоків живлення з можливістю роботи від різних живильних ланцюгів. Ці моменти здаються очевидними, проте, в реальному житті автору доводилося бачити вирішальний важливі завдання об'єкт автоматизації, живлення якого було організовано від двох незалежних електропідстанцій таким чином, що вимірювальне обладнання було цілком запитано від однієї з них, а керуючий їм обчислювальний комплекс – від іншої.

Гаряче резервування мереж передачі даних передбачає цілий ряд проблем, різною мірою привертають увагу широкої публіки.

Використання альтернативних маршрутів передавання пакетів через резервні з'єднання непогано підтримується звичайним інтелектуальним мережевим обладнанням, за винятком випадків використання нестандартних протоколів нижнього рівня.

Рухаючись вище по стеку протоколів, необхідно торкнутися питання використання стійких до повним або частковим збоїв протоколів передачі даних. Частиною цього питання є широко відомий флейм TCP vs UDP.

До переваг використання протоколу TCP в керуючих системах відносяться:
– автоматичний контроль цілісності;
– довільний розмір переданих даних.

До переваг використання протоколу UDP в керуючих системах відносяться:
– відсутність стану;
– можливість напівдуплексу;
– швидке повернення з викликів*;
– швидка діагностика проблем на рівні стека і повернення коду помилки.

Використання TCP в системах реального часу вимагає від розробника знайомства з параметрами налаштування стека, в першу чергу сімейством параметрів tcp_keepalive. Використання UDP вимагає чіткого розуміння реалізації протоколу ARP (з цим пов'язана застереження для виноски* вище). Використання обох протоколів передбачає творче володіння настройками розміру приймального буфера.

Питання відсутності стану протоколу UDP набуває значення при перезапуску однією з боків з'єднання, в тому числі – перезапуску на фізично відрізняється обладнанні (резервному сервері).

Окремо необхідно торкнутися рідко освітлюваний питання напівдуплексу. Реалізація деяких поширених мережевих середовищ така, що в результаті фізичного або логічного порушення цілісності зв'язку, стає можливою ситуація, коли дані передаються від A до Б, але не можуть бути передані від Б до А. Протокол TCP не може функціонувати в таких умовах. Протокол UDP здатний зберегти односторонню зв'язок при односторонньому обриві (за умови коректної роботи нижчого мережевого обладнання, і виключаючи питання використання ARP при встановленні з'єднання).

В цілому, на думку автора, для передачі коротких керуючих повідомлень в IP-мережі для відмовостійкої системи більш підходить протокол UDP з організацією контролю доставки повідомлень або безумовної повторної розсилки на рівні прикладних програм. Для передачі великих обсягів даних підходить координируемое керуючим рівнем використання протоколу TCP, з організацією сполук на короткий час.

Продовження слід.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.