Апгрейд на три дня: что увеличивается за 10 минут, а что нет

MAATRIX

Через три дня — распродажа, релиз, анонс в СМИ или просто «традиционный» скачок трафика, который случается каждый год в одну и ту же неделю. Кто-то в чате пишет «давайте поднимем тариф на время пика» — и это звучит как решение на пять минут: зашёл в панель, выбрал план побольше, применил. Проблема в том, что за словом «апгрейд» скрываются как минимум три разных технических операции с разной скоростью и разными ограничениями, и если не разбираться заранее, за два дня до пика можно узнать, что канал не резинится, IP-адреса ждут неделю, а диск назад не сжимается. Ниже — без экономики (стоит ли вообще это делать, разобрано в статье про то, как не платить за пиковые мощности весь год после сезона) — чисто техническая раскладка: что можно увеличить за 10 минут через панель, что требует часов или дней, а что физически недостижимо без смены сервера.

Что реально меняется за 10 минут: vCPU и RAM

На абсолютном большинстве VPS-платформ (KVM/QEMU-виртуализация — а это стандарт де-факто для арендных серверов) смена тарифа по CPU и RAM — это изменение конфигурации виртуальной машины на гипервизоре. В панели это выглядит как выбор нового плана и кнопка «применить», и по факту это действительно занимает минуты. Честная оговорка: на подавляющем большинстве платформ это не горячая замена — гипервизору нужно пересобрать виртуальную машину с новыми лимитами, а значит нужна остановка и старт (иногда достаточно reboot, иногда требуется именно stop → start, потому что часть параметров применяется только при холодном запуске). Живой hot-add CPU/RAM без остановки поддерживают немногие платформы и не для всех гостевых ОС, поэтому закладывайте простой в 1–5 минут на перезагрузку, а не рассчитывайте на бесшовность.

После перезагрузки первым делом проверяйте, что ОС действительно увидела новые ресурсы:

nproc
free -h
lscpu | grep -E "CPU\(s\)|Model name"

Ловушка, в которую попадает большинство: ОС видит новые ядра и память, а приложения — нет, потому что их конфиги статические и были рассчитаны под старый тариф. После апгрейда RAM с 4 до 8 ГБ вручную нужно поднять:

• worker_processes в nginx (или оставить auto, если он у вас уже так настроен — тогда пересчитается сам после перезапуска воркера);
• pm.max_children / pm.max_requests в PHP-FPM — фиксированное число, оно не масштабируется само;
• innodb_buffer_pool_size в MySQL/MariaDB — если оставить на старом значении, прибавка RAM просто будет простаивать;
• maxmemory в Redis, если вы ограничивали его специально под старый лимит;
• переменные окружения вида WORKERS, MAX_MEMORY, POOL_SIZE в собственных приложениях — Node.js, Python-воркеры на Gunicorn/uWSGI и подобные часто читают число воркеров при старте и не пересчитывают на лету.

То есть «10 минут» — это время на сам ресайз в панели плюс перезагрузку. Ещё 15–30 минут закладывайте на правку конфигов и рестарт сервисов, иначе новые ресурсы физически будут в системе, но приложение ими не воспользуется — вы заплатите за апгрейд и не получите эффекта.

Диск: расширить можно на лету, сжать — почти никогда

Расширение диска у большинства провайдеров действительно не требует остановки сервера — это операция на уровне блочного устройства, и файловая система умеет расти «поверх» без размонтирования. Типичная последовательность после того, как в панели увеличен размер диска:

# посмотреть текущую разметку
lsblk
df -h

# расширить раздел под новый размер диска (пример для /dev/vda, раздел 1)
growpart /dev/vda 1

# расширить файловую систему ext4
resize2fs /dev/vda1

# для XFS вместо resize2fs — только на смонтированной ФС
xfs_growfs /

Это действительно занимает пару минут и обычно без даунтайма. Но здесь важно понимать физику: диск, который вы «увеличили», продолжает жить в том же пуле хранения на том же физическом узле. Если у провайдера диски — сетевое блочное хранилище (Ceph-подобные системы), расширение почти всегда мгновенное и без ограничений, кроме свободного места в пуле. Если это локальный NVMe/SSD, привязанный к конкретному физическому серверу, расширение ограничено свободным местом именно на этом узле — а его может не хватить, и тогда «увеличить диск» на деле означает миграцию виртуалки на другой узел с большим запасом, что уже не 10 минут, а операция с плановым окном обслуживания.

Ключевая асимметрия, о которой почти никто не думает заранее: уменьшить диск обратно после пика нельзя — ни resize2fs, ни панель провайдера не умеют безопасно сжать раздел с данными на месте (теоретически resize2fs умеет уменьшать offline, но это редкая и рискованная операция, которую практически никто не делает на проде). После пика у вас остаётся два варианта: платить за увеличенный диск постоянно, либо поднимать новый инстанс с диском исходного размера и переносить данные бэкапом — то есть полноценная миграция, а не «отмена» апгрейда. Подробный процесс расширения диска без даунтайма и разбор частых ошибок — в отдельной статье про расширение диска на рабочем сервере. Если для эпизода пика вам нужен временный объём (например, для логов или кешей, которые не жалко потерять), почти всегда дешевле и правильнее подключить отдельный временный диск и удалить его целиком после пика, чем расширять основной системный том.

Что физически нельзя ускорить за 10 минут

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

Пропускная способность сети. «Увеличить канал в тарифе» в большинстве случаев означает поднять программный лимит (traffic shaping) на вашем порту, а не физическую скорость аплинка узла. Сам физический канал сервера — это конкретное железо (обычно 1 или 10 Гбит/с на порт), которое либо есть у вас в тарифе, либо нет, и никакая кнопка в панели не превращает 1 Гбит/с в 10 за время апгрейда — для этого нужен другой физический сервер или другой узел сети. При этом даже официальный лимит канала не гарантирует, что вы получите его целиком в моменте: канал общий для узла, и в пиковые часы у соседей та же нагрузка. Тема разобрана подробнее в статье про то, как канал заканчивается раньше диска — прежде чем полагаться на «безлимитный» или «широкий» канал в тарифе на время пика, стоит понимать, что там на самом деле гарантировано, а что нет.

Дополнительные IP-адреса. Выдача новых IPv4-адресов у серьёзных провайдеров — это не автоматическая операция, а процесс с проверкой обоснования использования (регламенты RIPE и подобных региональных регистратур требуют объяснить, зачем клиенту нужен ещё один адрес). Это дни, а не минуты, и в моменте пика рассчитывать на «закажу ещё пару IP» не стоит — планировать нужно заранее, если сценарий пика вообще требует дополнительных адресов (например, для отдельных SSL-сертификатов на легаси-клиентах или для распределения нагрузки по разным адресам).

Смена типа хранилища или выделенные ядра. Переход с виртуальных vCPU на выделенные физические ядра, подключение GPU, смена сетевого хранилища на локальный NVMe-массив — всё это фактически означает переезд на другую конфигурацию железа, а часто и на другой физический сервер. Это не апгрейд тарифа в привычном смысле, а миграция с копированием данных и своим окном простоя — у любой платформы есть физический потолок конкретного узла, и никакая кнопка «повысить тариф» не переносит вас на другое железо мгновенно.

Ниже сводная таблица — не абсолютная истина для всех провайдеров, а ориентир, с чем сверяться при планировании:

Как спланировать апгрейд перед известным пиком

Если пик заранее известен (сезонная распродажа, анонс, релиз с датой), апгрейд «за 10 минут» стоит делать не за 10 минут до события, а минимум за сутки-двое:

1. Панель провайдера или API могут подвиснуть именно в момент общего наплыва — если у вас распродажа, скорее всего у соседей по инфраструктуре тоже, и очередь заявок на изменение тарифа в этот день длиннее обычного.
2. После ресайза нужно проверить, что приложение реально использует новые ресурсы (см. раздел про конфиги выше) — это требует времени и, желательно, тестовой нагрузки, а не «применили и понадеялись».
3. Даунтайм на перезагрузку должен попасть в тихое окно, а не совпасть с началом пика — впритык к старту акции велик риск, что перезагрузка ляжет ровно на первый всплеск трафика.
4. Провайдер может тарифицировать смену плана по календарным суткам — уточните, спишут ли разницу пропорционально, чтобы не платить за полный день из-за апгрейда в 23:50.

Практический чек-лист на «Т минус 2 дня»:

[ ] Заявка/операция на увеличение vCPU/RAM подана заранее, не в день пика
[ ] Запланировано тихое окно для перезагрузки (ночь/раннее утро)
[ ] Список конфигов, которые нужно поправить вручную после ресайза (буферы БД, воркеры)
[ ] Тестовая нагрузка после апгрейда — хотя бы синтетический прогон, не только "сайт открылся"
[ ] Диск увеличен заранее, если пик предполагает рост логов/кешей/аплоадов
[ ] Если нужен доп. IP — заявка подана за неделю, не за день
[ ] Зафиксирована дата отката в календаре или тикете — см. следующий раздел

Даунтайм при апгрейде: когда он неизбежен и как его сократить

Даунтайм на ресайз vCPU/RAM почти всегда есть — вопрос в том, сколько он длится и насколько заметен пользователям. На одном сервере без резервирования перезагрузка — это недоступность сервиса на время цикла stop/start, обычно от 30 секунд до нескольких минут в зависимости от провайдера и загрузки хоста. Что реально снижает влияние:

• Делайте апгрейд в объективно тихое время, а не «когда руки дошли» — если у вас есть график трафика по часам (а он почти всегда есть в мониторинге), выбирайте локальный минимум.
• Если серверов несколько за балансировщиком, выводите узел из ротации перед перезагрузкой (drain/maintenance mode в LB или просто снятие с апстрима nginx/HAProxy), апгрейдьте, возвращайте обратно — тогда пользователи вообще не замечают операцию, потому что трафик идёт на остальные узлы.
• Проверяйте статус сервисов сразу после ресайза, а не через час:

systemctl status nginx
systemctl status your-app.service
journalctl -u your-app.service --since "10 min ago"

• Не полагайтесь на автозапуск сервисов «по умолчанию» — иногда после смены тарифа гипервизор действительно перезагружает ВМ так, как будто это холодный старт, и сервисы, поднятые вручную (не через systemd unit с enable), не запустятся сами.

Если известный пик слишком критичен для даже минутного даунтайма — например, это витрина интернет-магазина в первый час распродажи — правильная стратегия не «апгрейдить именно в момент пика», а поднять мощность заранее, за сутки-двое, с запасом простоя в тихом окне, и подойти к самому пику уже на стабильной, проверенной конфигурации.

Откат после пика: что убрать сразу, а что оставит след

Симметрия здесь обманчива: технически «понизить тариф обратно» — та же операция ресайза, что и повышение, но по факту откатывается не всё.

vCPU и RAM откатываются полностью той же процедурой в обратную сторону — выбрали план поменьше, применили, дождались перезагрузки. Единственное, о чём нужно не забыть — вернуть обратно конфиги, которые вы поднимали под увеличенные ресурсы. Если innodb_buffer_pool_size или pm.max_children остались рассчитаны на 8 ГБ RAM, а вы откатились на 4 ГБ, сервер может начать падать по OOM в самый неожиданный момент — это одна из самых частых граблей после «временного» апгрейда: повышение сделали организованно и по чек-листу, а откат — второпях, забыв, что конфиги правились вручную.

Диск не откатывается — это разобрано выше, и это ключевая причина, по которой временный диск для эпизода пика лучше подключать отдельным томом, а не расширять системный.

Плата за IP и другие выданные ресурсы обычно продолжает начисляться, пока вы явно не откажетесь от них в панели — провайдер не знает, что адрес нужен был только на неделю, если вы сами не отметили это при заказе или не отписали его вручную после пика.

Самая частая причина, по которой временный апгрейд превращается в постоянный — не техническая, а организационная: решение поднять тариф принимает кто-то один в момент подготовки к пику, а решение понизить обратно не принимает никто, потому что к моменту, когда можно было бы откатиться, все заняты следующей задачей. Это тот же механизм, что подробно разобран в статье про даунгрейд тарифа и почему на него не решаются: единственный практический способ не попасть в эту ловушку — заранее, ещё на этапе апгрейда, поставить в календарь или таск-трекер конкретную дату отката с ответственным, а не полагаться на то, что «кто-нибудь вспомнит».

Частые вопросы