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

Продовження статті.

Початок: частина 1

3. Апаратура і вбудовані програми

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

Перш за все, на наше глибоке переконання, жодна серйозна стаття про відмовостійкості немислима без віддачі данини поваги фірмі IBM і платформ z Systems і Power Systems. Мейнфрейми z Systems і кластери Power Systems HA спеціально спроектовані таким чином, щоб забезпечити на апаратному, микропрограммном і системному програмному рівні єдину відмовостійку платформу для додатків користувача, і по надійності потенційно перевершують ті рішення, які можна реалізувати на більш поширеною архітектурі Intel. На жаль, згадані рішення IBM мають також певні недоліки, найбільш загальним з яких є їх вартість. Досвід розробників показує, що при сучасній вартості z, p і Intel-рішень (самого заліза та ліцензійних програм для нього), а також при теперішньому курсі долара до рубля, досить складно в російських умовах економічно виправдати нові вкладення у власні архітектури, навіть з урахуванням значних додаткових трудовитрат на забезпечення заданих показників надійності рішень Intel. Загалом, колеги, що працюють з «великим залізом» самі добре знають свої резони, їх шлях дуже поважаємо, але не може бути рекомендований новачку.

Примітка для держсектораТут ми змушені зробити розвилку в логіці нашого викладу, і врахувати той факт, що значна частка ринку відмовостійких систем в Росії орієнтована на потреби державного сектора. Тому для розробників, обтяжених, крім інших турбот, почесними обов'язками по обслуговуванню побажань держави, зауважимо наступне. В даний час, як відомо, Урядом РФ проголошена політика імпортозаміщення. У своїй найбільш принциповою формі ця політика має на увазі виняткове використання продукції виробництва Росії та країн ЄАЕС. Проте, ряд керівних документів встановлює більш м'які вимоги, які диктують обмеження використання продукції тільки з країн НАТО, Європейського Союзу та інших, що підтримують режим секторальних санкцій відносно РФ. Для сфери інформаційних технологій істотно, що під режим таких м'яких обмежень не підпадають КНР (включаючи Тайвань) і Японія, що виводить в перші ряди для розгляду серверні системи компаній Lenovo (досить вдало перекупившей до виходу відповідної постанови Intel-сумісний бізнес IBM) і Fujitsu.

Розглядаючи Intel-сумісні рішення в області стійких до відмов апаратних засобів, слід звернути увагу, зокрема, на наступні моменти:
– гаряче резервування серверів;
– гаряче резервування мережевого обладнання та з'єднань між серверами;
– гаряче резервування дискової пам'яті в системі зберігання даних;
– стійкість вбудованого програмного забезпечення до збоїв;
– контроль робочого стану ОС.

Зручною готовою платформою для гарячого резервування серверів, мережевого обладнання та дискової пам'яті є блейд — і флекс-системи, що випускаються рядом виробників. Автор схильний рекомендувати подібну систему початківцям розробникам відмовостійких рішень (якщо дозволяє бюджет), так як в ній виробником заздалегідь вирішені багато питань, які інакше можуть виникнути тільки з придбанням гіркого досвіду. У той же час, гаряче резервування може бути забезпечено шляхом комплексування окремо монтуються компонентів. Слід зазначити, що, так чи інакше, необхідно вирішувати питання організації централізованої системи зберігання даних з альтернативним доступом для виключення єдиної точки відмови при виході з ладу підсистеми звернення до даних.

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

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

Одного разу автору довелося спостерігати поведінку блейд-сервера фірми Lenovo, при оновленні завантажувача операційної системи на якому відбувся збій, і конфігураційні файли завантажувача записалися з помилкою. Завантажувач починав вантажити ядро Linux, після чого зависав. Через деякий час в сервісному процесорі сервера спрацьовував таймаут завантаження ОС, і сервер перезавантажувався. Прошивка UEFI сервера, виявивши, що попередня спроба завантаження завершилася невдачею, самостійно ухвалювала рішення про відкат до попередньої версії завантажувача з архівного каталогу, що викликала його, і система благополучно завантажувалася. Так система, яка на звичайній платформі рівня робочої станції була б неоперабельний до ручного завантаження з ремонтного розділу, на серверній платформі благополучно автоматично завантажувалась у два прийому, до тих пір, поки наступним оновленням не був відновлений правильний завантажувач. Від адміністратора при первинній настройці системи потрібно було лише виставити коректне значення таймера завантаження.

До широко відомим засобів забезпечення відмовостійкості серверів відносяться пам'ять ECC, об'єднання дискових носіїв в надлишкові RAID масиви, дублювання всіх компонентів серверів і серверних шасі, забезпечення альтернативних шляхів зв'язку між компонентами серверної системи тощо

Резюмуючи, в даний час на ринку представлена достатня різноманітність спеціалізованих серверних систем, апаратними можливостями яких щодо забезпечення відмовостійкості не слід нехтувати.

Насамкінець, зазначимо поширена помилка – думка, що мінімальний відмовостійкий кластер повинен складатися з трьох вузлів, так як це найменше число, що передбачає резервування і при цьому забезпечує мажоритарне голосування при виході одного з вузлів з ладу. Насправді, вихід з ладу або переведення на обслуговування одного вузла з трьох залишає два вузла у вкрай нестійкому стані взаємної конкуренції, яка з великою ймовірністю може закінчитися їхнім взаємним відстрілом при найменшому збої зв'язку або при введенні в дію назад третього вузла, який почне встановлювати з ними відносини по черзі. Тому реальна відмовостійкий конфігурація кластера повинна включати мінімум 4 або 5 вузлів (ймовірність голосування 2:2, і сама по собі дуже низька, так як передбачає одночасні проблеми на двох вузлах, може бути виключена несиметричною топології кластера).

4. Хостова операційна система

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

Відмовостійкі серверні платформи заявляються виробником як сумісні тільки з невеликою кількістю операційних систем. У типовому випадку, до таких систем для Intel-сумісних платформ-Windows, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES) і VMware ESXi. Установка інших операційних систем можлива, але, як правило, призводить до відсутності штатної підтримки критичних для забезпечення відмовостійкості апаратних можливостей (наприклад, засобів multipath для резервування дискових контролерів).

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

Основними використовуваними на сьогоднішній день засобами серверної віртуалізації для Unix-сумісних систем є VMware ESXi, KVM (RHEL і SLES), Xen (SLES). Всі ці платформи забезпечують кластеризацію віртуальних машин (в якості додаткової опції), тобто підтримку автоматичної міграції віртуальних машин з вийшов з ладу вузла на резервний.

За функціональними характеристиками гіпервізора, на сьогоднішній день лідируюче положення займає VMware ESXi. Однак, вартість ліцензій VMware для кластера високої готовності, з характерним для нього значною кількістю процесорів, може виявитися дуже істотною.

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

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

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

0 коментарів

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