Управління точками відмови при проектуванні хмарних додатків

Чотири способи підвищення надійності хмарних додатків

Пітер Бедлл. технічний директор, PowWow

Пітер Белл (Peter Bell) є технічним директором бережливого стартапу PowWow, розташованого в Нью-Йорку. Представлений на міжнародному рівні і багато пише на теми хмарних обчислень, доменних мов, динамічних архітектур, NoSQL, а також вимог і оцінок. Брав участь в ряді конференцій, включаючи DLD Conference, ooPSLA, Code Generation, Practical Product Lines, the British Computer Society Software Practices Advancement, UberConf, the Rich Web Experience і No Fluff Just Stuff tour. Публікувався в IEEE Software. Dr. Dobbs. IBM developerWorks. Information Week. Methods - Tools. Mashed Code. NFJS the Magazine. JSMag і GroovyMag. Є постійним інструктором в General Assembly - кампусі технології, дизайну і підприємництва в Нью-Йорку.

Що таке надійність

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

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

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

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

Розглянемо чотири способи проектування потужних і надійних Web-додатків:

  • Скорочення кількості єдиних точок відмови.
  • Управління поведінкою відмов.
  • Виявлення відмов.
  • Запобігання відмов за допомогою стратегій проектування, розробки, тестування та розгортання.

Скорочення кількості єдиних точок відмови

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

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

  • DNS-сервери.
  • Web-сервери.
  • Сервери баз даних.
  • Файлові сервери.
  • Розподільники навантажень.
  • Інші спеціалізовані сервери.
  • Взаємозалежності зі сторонніми додатками.

На малюнку 1 показані типові точки відмови.

Малюнок 1. Типові точки відмови

DNS-сервери

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

Web-сервери

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

Сервери баз даних

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

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

файлові сервери

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

розподільники навантажень

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

Інші спеціалізовані сервери

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

Взаємозалежності зі сторонніми додатками

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

Малюнок 2. Додаткові точки відмови

управління відмовами

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

Іншим типовим на сьогодні підходом є використання черги повідомлень, обробної переміщення повідомлень між підсистемами і надає певні гарантії їх доставки (див. Малюнок 3).

Малюнок 3. Обхід відмови без локального сховища

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

виявлення відмов

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

Особливо важливо продумати запити моніторингу, що відправляються на Web-сервери для всебічної перевірки системи. Чи не тестируйте завантаження домашньої сторінки, якщо вона є статичною, а весь інший сайт динамічно витягує інформацію з бази даних. Якщо у вас є додаток, яке вимагає аутентифікації користувача за допомогою корпоративної системи управління обліковими записами і витягує дані з системи планування корпоративних ресурсів (ERP), переконайтеся, що сценарій моніторингу входить в систему як тестовий користувач, доданий вами в ERP-систему, і що дані з ERP-системи відображаються коректно в отправляемом Web-сервером відповіді. Важливо використовувати наскрізний моніторинг такого роду на додаток до моніторингу підсистем, щоб гарантувати коректність роботи програми.

обхід відмов

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

Розробка через тестування

Одним з найбільш ефективних способів переконатися, що додаток добре спроектовано і забезпечує очікувану функціональність, є розробка через тестування (test-driven development - TDD). Цей процес гарантує коректність коду і істотно покращує гнучкість і якість дизайну.

безперервна інтеграція

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

безперервне розгортання

висновок

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