Що таке високодоступна інфраструктура і навіщо вона потрібна

Будь-який цифровий сервіс, будь то інтернет-магазин, SaaS-платформа, API, медіапортал або корпоративна система, рано чи пізно стикається з якимись проблемами. То обладнання зламалося, то мережі дали збій, то оновлення ПЗ вийшло з багами. Ну а про людський фактор ми взагалі промовчимо.

Тому в інфраструктурній інженерії існує просте і зрозуміле правило: питання не в тому, чи відбудеться збій, а в тому, коли саме він відбудеться. І тут нам, інженерам, на допомогу приходить High Availability Infrastructure (високодоступна інфраструктура).

Високодоступна інфраструктура (High Availability Infrastructure або просто HA) - це підхід до проектування ІТ-систем, при якому відмова окремих компонентів не призводить до зупинки сервісу. Якщо один елемент виходить з ладу, система автоматично перемикається на резервні ресурси і контури, в результаті чого користувач часто навіть не помічає виникнення проблеми.

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

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

 

 

 

 

Що означає висока доступність

Висока доступність (High Availability, HA) - це здатність системи залишатися працездатною навіть при відмові окремих компонентів інфраструктури. Простіше кажучи, сервіс продовжує функціонувати навіть тоді, коли один із серверів, мережевих пристроїв або програмних модулів перестає працювати.

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

В інженерній практиці доступність зазвичай вимірюється відсотком часу, протягом якого сервіс залишається доступним для користувачів. Цей показник часто закріплюється в угоді про рівень обслуговування - SLA (Service Level Agreement) і чим вище відсоток доступності, тим менше допустимий час простою системи протягом року.

Навіть невелика різниця в частках відсотка може означати істотну відмінність в реальному часі недоступності сервісу. Наприклад, перехід від 99,9% до 99,99% знижує допустимий простій майже в десять разів.

Нижче наведено типові рівні доступності, які використовуються в інфраструктурі онлайн-сервісів і хмарних платформ.

 

Таблиця - Типові рівні доступності (SLA)

Доступність	Допустимий простій на рік	Де зазвичай використовується
99%	приблизно 3,6 дні	невеликі сайти та внутрішні сервіси
99.9%	приблизно 8,7 годин	SaaS-додатки та корпоративні системи
99.99%	приблизно 52 хвилини	великі веб-проєкти та онлайн-платформи
99.999%	приблизно 5 хвилин	фінансові системи та критично важливі сервіси

 

Показник 99,999% часто називають «five nines availability». Досягти такого рівня доступності можна тільки при ретельно продуманій архітектурі з резервуванням серверів, розподіленими базами даних, відмовостійкими мережами і автоматичними механізмами відновлення системи.

Рівень SLA всіх серверів від 3v-Hosting наближається до 99.99%

 

 

 

 

Що таке Single Point of Failure (SPOF)

Говорячи про високу доступність, неможливо обійти ще одне ключове поняття, таке як Single Point of Failure, або єдина точка відмови.

Single Point of Failure (SPOF) - це будь-який компонент інфраструктури, відмова якого призводить до зупинки всього сервісу. Простіше кажучи, це елемент системи, від якого критично залежить робота додатка і у якого немає резервної заміни.

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

 

Давайте подивимося на типові приклади єдиних точок відмови. На практиці SPOF може знаходитися на різних рівнях інфраструктури:

• один сервер додатків, на якому працює весь сайт або API;
• єдина база даних, де зберігаються всі дані сервісу;
• один балансувальник навантаження, через який проходить весь вхідний трафік;
• єдиний мережевий комутатор або маршрутизатор;
• один DNS-сервер, відповідальний за дозвіл доменного імені;
• єдине сховище даних (storage-сервер або файлова система);
• і т.д.

 

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

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

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

Саме усунення єдиних точок відмови лежить в основі архітектури High Availability, дозволяючи системі продовжувати роботу навіть при збої окремих її елементів.

 

 

 

 

Причини інфраструктурних збоїв

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

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

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

 

Апаратні збої

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

До найчастіших апаратних проблем відносяться:

• вихід з ладу SSD або HDD;
• відмова модулів оперативної пам'яті;
• перегрів процесорів або інших компонентів;
• несправності блоків живлення;
• збої або деградація RAID-масивів.

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

 

Мережеві проблеми

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

Типові мережеві інциденти можуть включати:

• перевантаження мережевих каналів;
• збої в роботі маршрутизаторів або комутаторів;
• помилки конфігурації мережевих пристроїв;
• проблеми з BGP-маршрутизацією;
• неправильну роботу балансувальників навантаження.

 

Програмні помилки

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

У даному розрізі до поширених проблем відносяться:

• невдалі оновлення додатків;
• помилки в нових версіях програмного забезпечення;
• неправильні конфігурації сервісів;
• витоки пам'яті та деградація продуктивності;
• зависання процесів або сервісів.

 

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

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

 

Людський фактор

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

Ще приклади таких ситуацій:

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

 

Саме тому сучасні практики DevOps приділяють велику увагу автоматизації, контролю змін і системам моніторингу.

 

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

 

 

 

 

Базові принципи високодоступної архітектури

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

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

 

Усунення єдиної точки відмови

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

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

На практиці це означає використання:

• декількох серверів додатків;
• резервних балансувальників навантаження;
• кластерів баз даних;
• розподілених систем зберігання.

 

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

 

Автоматичне перемикання (Failover)

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

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

Механізми перемикання можуть працювати на різних рівнях інфраструктури:

• балансувальник навантаження перенаправляє трафік на інші сервери;
• кластер бази даних автоматично вибирає новий primary-вузол;
• оркестратор контейнерів перезапускає додаток на іншому вузлі;
• системи зберігання перемикаються на резервні дискові вузли.

Головна мета failover - це звести до мінімуму час недоступності сервісу в разі виникнення збою.

 

Реплікація даних

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

На практиці використовуються різні моделі реплікації:

• master–replica (primary–replica) - коли основний сервер синхронізує дані з резервними вузлами;
• multi-master архітектура - коли кілька серверів можуть одночасно приймати записи;
• розподілені storage-системи - коли дані автоматично розподіляються між безліччю вузлів.

 

 

Моніторинг і автоматичне відновлення

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

Як правило, моніторинг збирає інформацію про:

• стан серверів і окремих віртуальних машин;
• завантаження CPU, пам'яті та дисків на сервері;
• доступність сервісів і додатків;
• мережеві затримки і пропускну здатність каналу;
• стан баз даних.
• і т.д.

 

Існує безліч інструментів моніторингу, але найбільш популярними і добре зарекомендували себе зараз вважаються Prometheus, Grafana, Zabbix і Alertmanager.

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

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

 

 

 

 

Типові інструменти для побудови HA-інфраструктури

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

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

 

Таблиця - Інструменти High Availability

Рівень інфраструктури	Завдання	Популярні інструменти
Балансування навантаження	Розподіл вхідного трафіку між кількома серверами застосунків	HAProxy, Nginx, Traefik, Envoy
Failover та віртуальні IP	Автоматичне переключення трафіку на резервний вузол у разі збою	Keepalived, Pacemaker, Corosync
Кластеризація баз даних	Реплікація даних та автоматичне переключення primary-вузла	Patroni, Galera Cluster, PostgreSQL Streaming Replication, MySQL Group Replication
Оркестрація контейнерів	Автоматичне керування контейнерами та перезапуск сервісів	Kubernetes, Docker Swarm, Nomad
Сховище даних	Розподілене зберігання файлів та захист від втрати даних	Ceph, GlusterFS, MinIO
Моніторинг та сповіщення	Спостереження за станом інфраструктури та виявлення проблем	Prometheus, Grafana, Zabbix, Alertmanager
Service Discovery	Автоматичне виявлення сервісів у розподіленій системі	Consul, etcd, ZooKeeper
Логи та спостережуваність	Збір і аналіз логів для діагностики проблем	ELK Stack (Elasticsearch, Logstash, Kibana), Loki

 

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

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

 

 

 

 

Ціна високої доступності

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

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

Однак при оцінці витрат важливо враховувати не тільки вартість інфраструктури, але і вартість простою сервісу.

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

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

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

 

 

 

Часто задавані питання (FAQ)

 

Що таке High Availability?

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

 

Чим High Availability відрізняється від Fault Tolerance?

High Availability допускає короткочасне переключення системи на резервні ресурси.

Fault Tolerance передбачає безперервну роботу без будь-якої перерви, навіть на рівні мілісекунд.

 

Чи можна побудувати HA на VPS?

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

 

Скільки серверів потрібно для HA?

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

 

Чи впливає висока доступність на продуктивність?

Як правило, ні. Завдяки розподілу навантаження між декількома вузлами система може обробляти більше запитів.

 

Чи можна додати HA до вже працюючого проекту?

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

 

Чи завжди висока доступність необхідна?

Ні. Для невеликих сайтів, блогів або тестових проектів складна HA-архітектура може бути надмірною.

 

 

 

 

Висновки

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

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

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

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

Для сервісів, де стабільність безпосередньо впливає на бізнес, таких як інтернет-магазини, SaaS-платформи, API та фінансові системи, висока доступність стає практично обов'язковим елементом інфраструктури. Вона дозволяє підтримувати стабільну роботу сервісу, мінімізувати простої та забезпечувати користувачам надійний цифровий досвід.