Кластер не починається з купівлі «потужнішої машини». Проблеми зазвичай виникають, коли один вузол одночасно обслуговує сайт, базу даних, черги та резервні копії. Тоді збій або стрибок навантаження може зупинити весь сервіс. Щоб розділити ризики й ресурси, інфраструктуру проєктують за ролями.
- визначають компоненти, які не варто розміщувати на одному сервері;
- знаходять потенційні точки відмови для кожної ролі;
- окремо планують мережу, доступи та резервування.
Коли одного сервера вже недостатньо
Переходити до кластера варто не лише через зростання кількості відвідувачів, а й тоді, коли компоненти системи починають заважати один одному. Наприклад, нічне створення резервних копій може сповільнювати базу даних, а раптовий наплив запитів до вебзастосунку – витісняти кеш із пам’яті. У такій ситуації оренда виділених серверів дає змогу виділити фізичні ресурси для окремих ролей, а не шукати одну компромісну конфігурацію для всіх завдань.
Спочатку потрібно з’ясувати, що саме обмежує роботу: процесор, оперативна пам’ять, дискова підсистема чи мережевий канал. Якщо CPU постійно перевантажений обробкою запитів, перенесення бази даних на окремий вузол не завжди допоможе. Але коли база конкурує з вебпроцесами за RAM і дискові ресурси, поділ ролей може прибрати вузьке місце. Кластер також доречний, якщо відмова одного сервера робить сервіс повністю недоступним.
Розподіл ролей: веб, база даних, кеш, резервування
Базова схема кластера зазвичай розділяє вебрівень, базу даних і резервне копіювання. Вебвузли обробляють HTTP-запити та масштабуються горизонтально: зі зростанням трафіку до них додають однотипні сервери. Базі даних потрібні передбачувана продуктивність дисків і достатній обсяг пам’яті, тому її краще не поєднувати з ресурсоємними фоновими завданнями. Кеш зменшує кількість звернень до БД, але не повинен бути єдиним місцем зберігання критичних даних.
| Роль сервера | Основне завдання | Критичний ресурс | Ризик при поєднанні |
| Вебвузол | Обробка запитів користувачів | CPU, RAM, мережа | Піки трафіку впливають на БД |
| База даних | Зберігання та обробка даних | RAM, SSD, IOPS | Фонові завдання створюють затримки |
| Кеш | Швидка видача тимчасових даних | RAM | Втрата кешу збільшує навантаження на БД |
| Резервний вузол | Копії та відновлення | Диск, пропускна здатність | Бекапи заважають робочим сервісам |
Не варто зберігати резервні копії лише на тому самому сервері, де працює основний сервіс. Помилка конфігурації, збій накопичувача або невдале оновлення можуть одночасно зачепити робочі файли й локальний бекап. Копії краще винести на окремий вузол або в інше сховище, визначити частоту їх створення та регулярно перевіряти відновлення. Нетестований бекап не дає впевненості, що сервіс вдасться швидко повернути в роботу.
Балансування навантаження і відмовостійкість
Балансувальник розподіляє вхідні запити між кількома вебвузлами, тому відмова одного з них не обов’язково зупинить сайт. Він перевіряє доступність бекендів і спрямовує трафік на сервери, які коректно відповідають. Проте балансування не захистить базу даних, якщо вона працює в одному екземплярі. Для критичних систем варто окремо продумати реплікацію та сценарій перемикання.
Перевіряти потрібно не лише сервери застосунку. Потенційними точками відмови можуть бути балансувальник, DNS, база даних, файлове сховище та канал зв’язку між вузлами. Для невеликого проєкту стартовою схемою можуть бути два вебсервери за балансувальником і окремий сервер БД. Ускладнювати архітектуру варто лише тоді, коли цього вимагають навантаження або вимоги до безперервної роботи.
У каталозі xserver.cloud доступні віртуальні та виділені сервери для різних завдань. Ролі в кластері можна підбирати окремо: компактніші конфігурації використовувати для вебвузлів, а продуктивніші – для баз даних, віртуалізації чи сховищ. У розподіленій системі однакова конфігурація для кожного вузла не завжди виправдана.
Приватна мережа між серверами і безпека обміну даними
Внутрішній обмін між вузлами слід максимально відокремити від публічного трафіку. База даних, брокер повідомлень, панель адміністрування та службові API не мають бути відкритими для інтернету без потреби. Для кожного сервісу потрібно визначити дозволені джерела підключення, порти та спосіб автентифікації. Відкритий «про всяк випадок» порт лише збільшує поверхню атаки.
Безпека мережі не зводиться до одного правила. Використовуйте фаєрволи між ролями, окремі облікові записи для сервісів, шифрування чутливого трафіку та контроль адміністративного доступу. Якщо сервери розміщені в різних локаціях, заздалегідь оцініть затримку між ними: синхронна реплікація бази даних значно чутливіша до неї, ніж асинхронне копіювання файлів. Документуйте маршрути й права доступу, щоб розширення кластера не створювало нових ризиків.
XServer: підхід до проєктів з кількома виділеними серверами
Для кластера важлива не лише обчислювальна потужність, а й можливість керувати кожним вузлом окремо. Панель керування XServer дає змогу встановлювати операційні системи та серверне ПЗ, керувати живленням і мережею, контролювати навантаження та підключатися до сервера через браузер. Це спрощує підготовку однотипних вузлів і допомагає швидше реагувати на проблеми.
XServer розвиває хмарну інфраструктуру в Україні, Польщі, Болгарії, Нідерландах, Німеччині, Великій Британії та США. Компанія повідомляє про дублювання вузлів, резервні канали та стандарти безпеки на своїх майданчиках. Це не замінює власну схему відмовостійкості застосунку, але допомагає зменшити ризики на рівні інфраструктури. Технічна підтримка працює цілодобово й допомагає з питаннями роботи серверів.
Кластер варто будувати від критичних залежностей, а не від кількості машин. Спочатку розділяють вебрівень, дані та резервні процеси, потім додають балансування й перевіряють, чи не залишився єдиний незахищений вузол. Мережеві правила мають обмежувати доступ між ролями, а резервні копії потрібно регулярно перевіряти відновленням. Тоді кожен новий сервер виконує конкретну функцію, а не лише ускладнює систему.
