Керований чи некерований VPS: що обрати

Керований чи некерований VPS: коротка відповідь

Вибір між керованим і некерованим VPS — це питання розподілу обов’язків, а не вибору продукту. У некерованому VPS ви самостійно відповідаєте за встановлення оновлень, firewall, резервне копіювання, моніторинг і перезавантаження о 2am. У керованому VPS провайдер бере на себе частину цих завдань. Обсяг цієї частини суттєво відрізняється залежно від хостингу. Єдине коректне порівняння — це перелік завдань, від яких вас звільняє кожен тариф, зіставлений із вартістю ваших власних годин.

Стандартного визначення терміна керований не існує. Для одного хостингу це означає встановлення оновлень операційної системи та відповідь спеціаліста на звернення. Для іншого — встановлений control panel, а все, що працює поверх нього, залишається вашою відповідальністю. Для третього — письмовий договір про обслуговування із зазначеним часом відповіді. Два тарифи з однаковою назвою можуть повністю відрізнятися за всіма важливими параметрами, тому спочатку ознайомтеся з документом про обсяг послуг і лише потім порівнюйте ціни. Якщо ви ще навіть не визначилися, для чого потрібен цей сервер, спочатку варто з’ясувати що саме можна робити за допомогою VPS.

Завдання, за які хтось має відповідати

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

• Встановлення виправлень операційної системи та перезавантаження, потрібні після оновлення kernel.
• Правила firewall, які потрібно підтримувати в актуальному стані під час додавання та видалення сервісів. Основи firewall ufw для VPS описують початковий набір правил.
• Доступ SSH: робота з ключами, вимкнення входу за паролем, відкликання ключа після звільнення працівника та спосіб відновити доступ, якщо ви самі заблокували себе.
• Резервні копії, копія за межами основного сервера та фактичне виконання відновлення.
• Моніторинг: потрібно знати, що сервер доступний, на диску є вільне місце, сервіс продовжує працювати, а термін дії сертифіката не завершився.
• Перевірка журналів і реагування, якщо в них виявлено щось підозріле.
• Налаштування сервісів для web server, database, reverse proxy та queue, якщо ви його використовуєте.
• Оновлення сертифіката та усунення несправності, якщо автоматичне оновлення припинило працювати.
• Ресурси: потрібно помітити, що пам’ять вичерпується, раніше за out of memory (OOM) killer.
• Реагування на інциденти: потрібно бути на зв’язку та готовим реагувати в час, який обирає не ви.

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

Що зазвичай не входить до керованого обслуговування

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

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

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

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

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

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

Оцініть власний час у порівнянні з щомісячною різницею

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

• Скільки коштує одна година вашого часу і скільки годин на місяць займають ці завдання після автоматизації?
• Скільки коштує одна година простою для системи, що працює на цьому сервері?

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

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

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

Поставте запитання до оплати й попросіть надати відповіді в письмовій формі. Сторінка з описом послуги не є документом із визначеним обсягом робіт.

1. Що входить до обсягу робіт? Попросіть надати перелік завдань, а не рекламний матеріал.
2. Чи поширюється підтримка на програмне забезпечення, яке встановлюю я, чи лише на програмне забезпечення, встановлене вами?
3. Чи встановлюєте ви оновлення автоматично та чи перезавантажуєте сервер для оновлень ядра без попереднього запиту до мене?
4. Хто відповідає, якщо оновлення, встановлене вами, порушить роботу моєї програми?
5. Чи створюєте ви резервні копії? Де їх зберігають, як довго зберігають і хто виконує відновлення?
6. Чи відновлювали ви нещодавно сервер клієнта та скільки часу це зайняло?
7. Який час відповіді на заявку та чи відрізняється він о 03:00 у неділю?
8. Чи зберігаю я доступ root і чи обмежує його використання обсяг підтримки?
9. Чи стягується плата за сервер або за обліковий запис?
10. Якщо я припиню користуватися послугою, що я зможу забрати із собою? Конфігурацію, яка зберігається у власній панелі керування провайдера, може бути складно експортувати.

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

Середній шлях: некерований план плюс автоматизація

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

Автоматичні оновлення безпеки

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Тепер цей файл має містити APT::Periodic::Update-Package-Lists "1"; і APT::Periodic::Unattended-Upgrade "1";. Відсутній файл або 0 в одному з рядків означає, що нічого не виконується і ви не отримуватимете повідомлень.

Перевірте це без внесення змін до системи. Зверніть увагу: назва пакета має форму unattended-upgrades, а команда — форму однини:

sudo unattended-upgrade --dry-run --debug

У виведенні наведено всі пакети, які було перевірено. Завершується воно рядком на кшталт No packages found that can be upgraded unattended, якщо очікуваних оновлень немає. Фактичні запуски записуються до /var/log/unattended-upgrades/unattended-upgrades.log, тому перевіряйте цей файл, а не робіть припущень.

Оновлення ядра не змінює нічого, доки машину не перезавантажено, оскільки під час запуску завантажується ядро, яке працює. Файл /var/run/reboot-required з’являється, коли потрібне перезавантаження. Перевіряйте наявність цього файла або дозвольте машині виконувати перезавантаження за допомогою /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" відкладає перезавантаження, поки в системі є авторизований користувач. Це безпечніше на машині, якою ви користуєтеся інтерактивно, і не має користі на машині, до якої ніхто не входить. У матеріалі Повне налаштування автоматичних оновлень на Ubuntu описано синтаксис списку блокування та параметри електронної пошти.

Моніторинг, що працює в іншому місці

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

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

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

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

Резервні копії, відновлені вами щонайменше один раз

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init виводить created restic repository <id> at sftp:... один раз. Запуск цієї команди для репозиторію, який уже існує, завершується помилкою, а не перезаписує його. Саме така поведінка вам потрібна. Зберігайте копію цієї парольної фрази за межами сервера: без неї репозиторій неможливо прочитати, і способу відновлення немає.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots має показати щойно створений запуск із датою сьогоднішнього дня. restic check перевіряє структуру репозиторію та виводить no errors were found. Тепер виконайте дію, яку більшість пропускає:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

Очікуваний файл або існує, або ні. З’ясувати це зараз можна за десять хвилин. Потім додайте запуск до таймера, щоб він не залежав від вас. Запишіть /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

І /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers показує наступний запуск і час, що залишився. Порожній результат означає, що ви ввімкнули службу замість таймера. Це найпоширеніша помилка в цьому місці. Persistent=true запускає пропущене завдання після наступного завантаження, тому машина, яка була вимкнена вночі, все одно створить резервну копію. У матеріалі Резервні копії Restic на VPS докладніше описано структуру репозиторію та зберігання копій, а служби й таймери systemd пояснює файли unit построково.

Чого автоматизація не забезпечує

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

systemctl is-enabled nginx docker
sudo reboot

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

Коли керований сервіс виправдовує витрати

Потрібно об’єктивно оцінити керований варіант. Є 4 ситуації, у яких це правильний вибір.

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

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

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

FAQ

У чому різниця між керованим і некерованим VPS?

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

Чи означає керований VPS, що мені не потрібні власні резервні копії?

Ні. Резервні копії провайдера зазвичай захищають образ усього сервера на стороні провайдера та призначені для випадків відмови хоста. Вони рідко допомагають, якщо ви видалили файл, виконали невдалу міграцію або пошкодили дані кілька тижнів тому, а виявили це лише сьогодні. Запитайте, як довго зберігаються snapshots, чи можна відновити окремий файл і хто виконує відновлення. Потім зберігайте власну копію за межами основного майданчика за допомогою такого інструмента, як restic, і перевіряйте її за допомогою restic restore latest --target /tmp/restore-check, щоб переконатися, що вона працює.

Чи безпечніший керований VPS за некерований?

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

Чи можу я розпочати з некерованого VPS, а пізніше перейти на керований?

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

Чи зберігається доступ root на керованому VPS?

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