Selectel dedicated: налаштування від bare metal до продакшену

Selectel dedicated: чому продакшен впирається в залізо

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

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

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

Перевірити це з боку орендаря майже неможливо: метрики розмиті, залізо поза вашим контуром, а налаштування гіпервізора закриті.

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

Звідси й відмови рівно в пік: репліка не встигає, планувальник не встигає, звітність конкурує з прийманням замовлень.

Selectel dedicated прибирає найнеприємніший шар цієї невизначеності: процесор, пам’ять і диски виділеного сервера не діляться з іншими орендарями, тому ваше навантаження ні з чим не змішується.

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

Що змінюється після переїзду на виділений сервер

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

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

• Стабільний час відгуку. 95-й та 99-й перцентиль тримаються в одному коридорі і вдень, і у вечірній пік — розкид між швидкими та повільними запитами скорочується.
• Продуктивність на піку. Процесор, диски та мережа не діляться з чужими навантаженнями: зростання одночасних сесій не перетворюється на чергу.
• Зникнення класу відмов через сусідів. Просідання дискової підсистеми та мережеві сплески від чужої активності більше не відтворюються.
• Скорочення простою. Планові роботи йдуть перемиканням на резервний вузол, а не зупинкою сервісу для користувачів.
• Відмовостійкість. Резервування живлення, дисків і мережевих портів на майданчику плюс гарячий резерв під критичні ролі.
• Резервування даних. Знімки диска за розкладом і регламент відновлення з виміряним на навчальному збої часом.

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

Формати розміщення на Selectel dedicated та їх обмеження

Форм-фактор розміщення обирають не за піковою потужністю, а за допустимим класом відмов у продакшені. Один виділений сервер дає повний контроль над ядром і дисковим стеком, але заміна заліза або диска — це зупинка сервісу.

Кластер серверів знімає це обмеження ціною ускладнення: потрібні балансування, реплікація стану та виведення вузла з роботи без втрати запитів.

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

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

Етапи переведення інфраструктури на виділений сервер

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

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

Послідовність робіт

1. Аудит інфраструктури. Збираємо карту сервісів і залежностей, профіль навантаження за годинами та піками, вимоги до диска, мережі й резервування. На виході — перелік вузьких місць і обмежень, які не можна перенести «як є».
2. Схема розміщення. Розподіляємо ролі вузлів, сегментуємо мережу, плануємо сховище, резервне копіювання за межі майданчика та точки відмови. Схема узгоджується до закупівлі конфігурації.
3. Підготовка заліза та майданчика. Розмітка дисків і рівні RAID, файлова система, віддалений доступ, мережеві налаштування та правила фільтрації трафіку. Фіксуємо базовий стан кожного вузла.
4. Автоматизація розгортання. Описуємо інфраструктуру декларативно, конфігурації тримаємо в системі контролю версій, розгортання виконуємо повторювано — з нуля та сама схема відтворюється без ручних правок.
5. Розгортання та перевірка на стенді. Переносимо навантаження, відновлюємо сервіси з копій, імітуємо відмову вузла та заміряємо час відновлення. Правки в схему вносимо лише за результатами вимірів.
6. Приймальні перевірки. Проганяємо чек-ліст: відновлення даних, поведінка під час відмови, моніторинг і оповіщення, розмежування доступів, журнали подій. Розходження усуваємо до виведення в бойовий контур за індивідуальним розрахункомПередача в експлуатацію. Передаємо документацію, регламенти обслуговування та ролі доступу, проводимо навчання чергової команди. Супроводжуємо перші цикли оновлень, поки процеси не стануть рутинними.

Конфігурації, схеми мережі та регламенти експлуатації

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

• Конфігурація серверів — склад заліза, розмітка дисків, параметри завантаження, список служб та їх налаштування: вузол відтворюється заново за описом, без розбирання працюючого.
• Схема мережі — адресація, сегменти та маршрути між ними, правила фільтрації трафіку, точки підключення зовнішніх каналів.
• Політики доступу — ролі та права, видача й відкликання ключів, зберігання секретів, окремі облікові записи для людей і для сервісів.
• Регламент відновлення — що і як часто копіюється, терміни зберігання, покроковий порядок підйому та час, за який він перевірений на навчальній відмові.
• Моніторинг і оповіщення — перелік перевірок, пороги спрацювання, маршрути повідомлень, хто реагує і в які терміни.
• Інструкції черговому — типові операції: перезапуск служби, заміна диска, ротація ключів, виведення вузла на обслуговування.
• Паспорт інфраструктури — карта вузлів, залежності між сервісами, журнал змін.

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

Кейс: як прибрали простої на навантаженому сервісі

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

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

Що змінили

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

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

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

Що вийшло

Час відновлення скоротився з 4-6 годин до 10-15 хвилин, і в більшості сценаріїв перемикання проходить без ручного втручання. Доступність сервісу зросла з 99,2% до 99,95% за період спостережень.

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

Чим виділений сервер відрізняється від віртуальної машини

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

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

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

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

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

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

Технічні сумніви: що уточнюють до старту

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

Що станеться під час відмови обладнання?

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

Як масштабувати, коли зросте навантаження?

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

Де закінчується ваша відповідальність?

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

Як влаштовано резервне копіювання?

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

Обговоримо ваше завдання і повернемося з планом

Розбір завдання йде в кілька кроків: ви описуєте, що потрібно отримати від виділеного заліза на Selectel, ми уточнюємо відсутнє питаннями та повертаємося з оцінкою завдання і планом робіт. Готове технічне завдання не потрібне — достатньо контексту, решту витягнемо самі. Порядок розбору однаковий для будь-якого масштабу: спочатку межі, потім навантаження, потім схема.

Щоб оцінка була точною, надішліть склад вихідних даних — за пунктами:

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

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