6. Аналіз надійності
Для перевірки надійності системи ми вручну внесли деякі ретельно підібрані помилки в деякі з своїх серверів і драйверів, щоб побачити, що в результаті відбудеться. Як описувалося в розд. 3.3, наша система розробляється для виявлення та виправлення багатьох помилок, і саме це ми і спостерігали. Якщо з якої б то не було причини відбувався збій деякого компонента, це розпізнавалася сервером реінкарнації, який застосовував усі необхідні кошти для пожвавлення збійного компонента. Нижче це описується більш детально.
Для розуміння роботи нашої системи потрібно розрізняти два класи помилок. Перший клас складають логічні помилки, що означають, що сервер або драйвер дотримується протоколу межмодульних взаємодій і нормально відповідає на запити, як якщо б він успішно виконав роботу, чого насправді не відбувається. Прикладом є драйвер принтера, який друкує безглузду інформацію, але виробляє нормальні повернення. Для будь-якої системи дуже важко, якщо не неможливо, відловлювати помилки такого роду. Логічні помилки перебувають за межами цього дослідження.
Другий клас складається з протокольних помилок, за наявності яких порушуються правила, що визначають поведінку серверів і драйверів. Наприклад, в нашій системі від серверів і драйверів потрібно відповідати на періодичні запити стану, що надходять від сервера реінкарнації. Якщо вони не підкоряються цьому правилу, робиться коригуючий дію. Наша система розробляється для боротьби з протокольними помилками.
Сервер реінкарнації
Сервер реінкарнації – це центральний сервер, керуючий усіма серверами і драйверами операційної системи. Він дозволяє істотно підвищити надійність, забезпечуючи:
1. Негайне розпізнавання фатальних збоїв.
2. Періодичний моніторинг стану.
Таким чином, він допомагає відловлювати два поширених виду збоїв: померлі або погано себе провідні системні процеси і негайно береться за вирішення найбільш гострої проблеми. Якщо системний процес завершується, то сервер реінкарнації безпосередньо оповіщається про це і перевіряє свої таблиці, щоб зрозуміти, чи слід перезапустити сервіс. Цей механізм, наприклад, забезпечує негайну заміну драйвера, примусово завершеного через використання поганого покажчика. Крім того, періодичний моніторинг стану допомагає дисциплінувати погано себе провідні системні сервіси. Наприклад, драйвер, який впадає в нескінченний цикл і не може відповісти на запит стану від сервера реінкарнації, буде примусово завершений і перезапущений.
Заміна драйвера пристрою складається з суворо контрольованій послідовності дій. По-перше, сервер реінкарнації породжує новий процес, виконання якого затримується, оскільки для нього ще не призначено привілеї. Потім сервер реінкарнації повідомляє про новий драйвері файлової системи і, нарешті, призначає необхідні привілеї. Коли всі ці кроки успішно виконуються, новий процес починає працювати і виконує код драйвера, що береться з файлової системи. В якості додаткової обережності двійковий код деяких драйверів може дублюватися в основній пам'яті, щоб, наприклад, драйвер для диска кореневої файлової системи можна було завантажити без потреби в обміні з диском.
Надійність рівня додатків
Наявність збійного драйвера може приводити до наслідків для файлової системи і додатків, що виробляють введення-виведення. Якщо у файлової системи був невиконаний запит вводу-виводу, їй буде повернуто код помилки, що говорить про збій драйвера. У цей момент можуть бути зроблені різні дії. Необхідно проводити відмінність між блоковими і символьними пристроями, тому що введення-виведення для блокових пристроїв буферізуется в буферному кеші файлової системи. На рис. 3 наводиться огляд різних сценаріїв відновлення на рівні програми.
При фатальному збої блокового драйвера можливо повне відновлення без втрати даних, прозоре для програми. Коли розпізнається збій, сервер реінкарнації запускає нову копію драйвера і скидає кеш файлової системи для синхронізації. Таким чином, буферний кеш не тільки підвищує продуктивність, але також є важливим і для надійності.
Прозоре відновлення іноді є можливим і при збоях драйверів символьних пристроїв. Оскільки запит вводу-виводу не буферізуется в кеші блоків файлової системи, інформація про помилку вводу-виводу повинна бути доведена до програми. Якщо програма не може призвести відновлення, про проблему буде сповіщений користувач. Фактично, збої драйверів проштовхуються нагору, що призводить до різних сценаріїв відновлення. Наприклад, якщо відбувається збій драйвера Ethernet, то мережевий сервер помітить відсутність пакетів і зробить прозоре відновлення, якщо додаток використовує надійний транспортний протокол, такий як TCP. З іншого боку, якщо відбувається збій драйвера принтера, то користувач, звичайно, помітить, що його виведення на друк не вдався і повторить команду друку.
Таким чином, у багатьох випадках наша система може забезпечити повне відновлення на прикладному рівні. В решті випадках інформація про збої введення-виведення доводиться до користувача. Можна було б пом'якшити цю незручність шляхом використання тіньового драйвера для відновлення додатків, який використовували зіпсований драйвер в момент його фатального збою, застосовуючи методи, продемонстровані в [25]. Нам не дає зробити це брак робочої сіли.
Результати перевірки надійності
Для перевірки надійності своєї системи ми вручну внесли збої в деякі з своїх драйверів, щоб протестувати деякі види помилок і подивитися на те, що вийде. У найпростішому випадку ми завершували драйвер з застосуванням сигналу SIGKILL. Більш серйозні тестові випадки змушували драйвери разименовивать погані покажчики або впадати в нескінченний цикл. У всіх випадках сервер реінкарнації розпізнавав проблему і заміняв несправний драйвер свіжої копією.
З тестуванні надійності, ми витягли кілька уроків, важливих для розробки нашої системи. По-перше, оскільки сервер реінкарнації перезапускає несправні сервери і драйвери, потрібно, щоб у них не зберігалося стан, і вони могли б бути належним чином повторно ініціалізували при повторному запуску. Компоненти, що зберігають стан, такі як файлова система і сервер процесів, неможливо вилікувати таким чином, оскільки вони дуже багато втрачають при перезапуску. Наші можливості обмежені.
Інше спостереження полягає в тому, що деякі драйвери були реалізовані таким чином, що ініціалізація відбувається тільки при першому виклику OPEN. Однак для прозорого відновлення після збою драйвера на рівні додатків не повинен турбуватися повторний виклик OPEN. Замість цього, виконання виклику READ або WRITE у відновленому драйвері має змусити драйвер призвести повторну ініціалізацію.
Крім того, хоча ми визнаємо наявність залежностей між файловою системою і драйверами, наші тести виявили деякі інші взаємозалежності. Наприклад, наш інформаційний сервер, що видає на екран налагодження дампи при натисканні функціональних клавіш, втрачає своє відображення клавіш після перезапуску. В якості загального правила, залежності слід запобігати, і всі компоненти повинні бути підготовлені для боротьби з непередбачуваними збоями.
Нарешті, щоб ще більше підвищити надійність, слід змінити і користувальницькі додатки. За історичними причинами в більшості програм передбачається, що будь-який збій драйвера є фатальним, і вони негайно здаються, хоча іноді можливо відновлення. Прикладом, в якому можливе відновлення на рівні програми, є печатка. Якщо демон лінійного принтера сповіщається про тимчасове збій драйвера, він може автоматично повторно видати команду друку без втручання користувача. Подальші експерименти з поновленням на рівні додатків є частиною нашої майбутньої роботи.
0 комментариев