VPS и выделенный сервер вместе: какую нагрузку переносить на железо, а какую оставить отдельно

MAATRIX · Выделенные серверы · Статья 32 из 48

У переезда на выделенный сервер есть соблазнительная финальная сцена: все виртуальные машины выключены, один большой хост работает, список счетов стал короче. Но хорошая архитектура не обязана заканчиваться полным освобождением старой площадки. Иногда самый полезный VPS — тот, который вы сознательно оставили после переезда.

На нём может жить внешняя проверка доступности, небольшой независимый сервис, входной прокси или служба, которой нужна другая локация. А на физической машине — база, вычислительные работники и постоянная нагрузка, ради которой отдельное железо и арендовали.

Разделение нагрузки между VPS и выделенным сервером помогает совместить предсказуемые ресурсы с независимостью отдельных ролей. Но оно же добавляет сетевые связи, права доступа и новые варианты отказа. Чтобы такая схема оказалась полезной, распределять нужно задачи, а не просто раскладывать процессы по свободным гигабайтам.

Начните с карты связей, а не списка машин

Представим условный сервис: веб-приложение, база, поиск, очередь, обработчики файлов, тестовый стенд и мониторинг. На схеме это семь прямоугольников. Между ними гораздо важнее стрелки: кто к кому обращается, как часто, сколько данных передаёт и что происходит при отсутствии ответа.

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

Поэтому для каждой связи полезно записать четыре вещи: частоту обращений, объём передачи, чувствительность к задержке и поведение при обрыве. Если потеря связи заставляет приложение бесконечно повторять тяжёлую операцию, перенос добавит проблему, даже когда оба сервера исправны.

Вторая часть карты — зависимости управления. Где лежат резервные копии, кто хранит доступы, откуда приходят уведомления, как будет выполняться восстановление? Схема, в которой средство восстановления доступно только через восстанавливаемый сервер, любит рассказывать о себе в самый неподходящий момент.

На выделенном сервере оставляют плотную постоянную работу

Хороший кандидат для переноса — нагрузка, которая регулярно использует заметный объём CPU, памяти или диска и которую удобно обслуживать на одной платформе. Это могут быть вычислительные работники, насыщенная база данных, аналитический узел или несколько тесно связанных компонентов приложения.

Базу и активно общающееся с ней приложение часто полезно держать близко по сети. Но слово «близко» не означает обязательного размещения в одной ОС. Отдельные виртуальные машины на физическом хосте позволяют разделить окружения; при этом общая зависимость от хоста сохраняется.

Для умеренного приложения кандидатом может быть ANKH: Ryzen 7600X, 6 ядер, 64 ГБ DDR5, 1 ТБ NVMe за $329 в месяц. Если основная работа — параллельные вычисления и памяти достаточно, можно испытывать PYLON с Ryzen 7950X, 16 ядрами, теми же 64 ГБ и 1 ТБ за $429. Оба тарифа размещаются в США.

При большом суммарном рабочем наборе интересен NECROPOLIS: 48 ядер EPYC 7642, 128 ГБ DDR4 и 2 × 1 ТБ NVMe за $529. Это вместительный кандидат для нескольких служб, но не разрешение каждому процессу потреблять всё доступное. Квоты, ограничения и наблюдение нужны именно потому, что ресурсов стало больше и претендентов на них тоже.

Российский CARTOUCHE с двумя E5-2680 v4, 28 ядрами суммарно, 128 ГБ DDR4 и 2 × 600 ГБ SSD за $295 стоит рассматривать при подходящих требованиях к размещению и производительности. Прежде чем свести несколько VPS на его диски, посчитайте фактическую ёмкость после выбранной схемы хранения, временные файлы и рост.

Это кандидаты для проверки, а не готовое распределение по количеству пользователей. Если причина медленной работы находится во внешнем API, переезд процессора не переносит само API поближе к вашим желаниям.

Независимое наблюдение лучше оставить снаружи

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

Она должна проверять полезный результат: доступность страницы с актуальным содержимым, ответ API, выполнение контрольной операции. Успешный ping не доказывает, что можно оформить заказ, а открытый порт не гарантирует работоспособность базы.

Сбор внутренних метрик при этом остаётся полезным. Агент на выделенном сервере показывает память, диск и состояние процессов; внешняя проверка видит систему со стороны. Эти способы наблюдения дополняют друг друга. Практические варианты проверок описаны в статье о настройке Uptime Kuma.

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

Независимость проверяют не только по отдельному IP. VPS и dedicated могут иметь общую площадку или часть сети. Для повседневного внешнего наблюдения этого иногда достаточно, для проверки отказа площадки — уже нет. Требуемую степень разделения выбирают по тому событию, которое нужно обнаружить.

Входной прокси на VPS: удобная граница с собственной ценой

Небольшой VPS может принимать входящие HTTP-запросы и передавать их приложению на выделенном сервере. Это бывает удобно для управления точкой входа, маршрутизации между службами или постепенного переноса. Сам принцип описан в документации NGINX Reverse Proxy.

Однако прокси не ускоряет любую схему автоматически. Он добавляет ещё один участок сети и расходует собственные ресурсы. Если весь трафик проходит через небольшой виртуальный сервер, именно его канал или ограничения могут стать новым пределом, хотя большая машина будет скучать.

Расположение прокси ближе к пользователю не устраняет удалённость динамического приложения. Если каждый запрос всё равно идёт к origin через океан, задержка этой поездки остаётся. Кэширование может уменьшить число таких обращений, но только для данных, которые допустимо кэшировать с нужной свежестью.

Отдельно настраивают защищённое соединение между узлами, доступ к origin только из необходимых источников, корректную передачу сведений о клиенте и доверие к заголовкам. Без этого приложение способно неверно определять адрес пользователя или принимать подменённые служебные сведения.

Один прокси также становится отдельной точкой отказа. Если требуется сохранение входа при его потере, нужно проектировать резервирование самой точки входа. Слова «перед сервером стоит VPS» не заменяют ни эту работу, ни DDoS-защиту, условия которой уточняются отдельно.

Что не стоит разносить по разным локациям без измерений

Самый рискованный кандидат на случайное разделение — приложение с большим количеством последовательных обращений к удалённой базе. Даже небольшая задержка, многократно повторённая в одной операции, становится заметной. Пропускная способность 1 Гбит/с не сокращает время каждого сетевого обмена.

Так же внимательно относятся к синхронной репликации и распределённым подтверждениям. Например, PostgreSQL при соответствующем режиме ожидает подтверждение от синхронной реплики; время сетевого обмена участвует в задержке. Это описано в документации по synchronous replication.

Если оставить реплику на VPS, проверьте не только её ёмкость. Она должна успевать применять изменения, выдерживать обслуживание и выполнять назначенную роль при переключении. Небольшой резерв может хранить копию, но не обслуживать всю рабочую нагрузку. Тогда нужно заранее определить допустимый ограниченный режим.

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

Не следует смешивать задачи независимой копии, быстрого чтения и автоматического аварийного переключения. Один дополнительный VPS иногда участвует во всех трёх, но для каждого назначения нужны свои проверки. Фраза «у нас есть реплика» не отвечает на вопрос, что именно произойдёт при отказе.

Резервные копии и временные среды выбирают по разным причинам

Хранилище резервных копий выносят за пределы основного сервера ради независимости данных. При этом обычный VPS с небольшим диском не всегда лучший вариант: может потребоваться отдельное хранилище, подходящее по объёму, срокам хранения и скорости восстановления. Важно также разделить права, чтобы компрометация приложения не позволяла удалить все доступные копии.

Тестовые среды оставляют отдельно по другой причине: они создают непредсказуемую нагрузку и допускают эксперименты. Если команда регулярно запускает тяжёлые тесты, их изоляция от рабочей базы может быть полезнее максимальной экономии на общей памяти. Особенно когда staging живёт по расписанию разработчиков, а production — по расписанию клиентов.

Временные вычислительные исполнители на VPS подходят там, где работу можно разделить на независимые задания и безопасно повторить при сбое. Но нужно проверить доступность исходных данных: перенос большого массива на каждого временного работника способен поглотить выигрыш от его появления.

Для постоянного небольшого сервиса отдельный VPS может сохранять понятную границу ответственности. Например, у него другая команда, цикл обновлений или требования к ОС. Объединение только ради свободных ресурсов иногда создаёт больше согласований, чем экономит денег.

Рабочая схема для условного проекта

Допустим, основной сервис имеет стабильную базу, несколько обработчиков и отдельный тестовый контур. В первой версии распределения база и активно общающееся с ней приложение переезжают на подходящий dedicated, внешняя проверка остаётся на VPS, резервные копии хранятся независимо. Тестовый контур сохраняет прежнее размещение до отдельного измерения.

Затем проверяют реальные связи. Если фоновые обработчики почти не общаются с базой и получают компактные задания, часть можно оставить или запускать отдельно. Если они постоянно читают большие объёмы локальных данных, перенос всех исполнителей далеко от хранилища может ухудшить результат.

Владелец системы получает примерно такую таблицу решений:

После этого проверяют не только штатную работу, но и разрыв каждой важной связи. Что увидит пользователь при недоступности базы? Сохранится ли очередь при перезапуске работника? Кто сообщит о недоступном прокси? Если ответы приходится импровизировать, архитектура ещё не доведена до эксплуатации.

Хорошее разделение уменьшает число неприятных зависимостей

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

Экономику считают для всего набора: аренда dedicated, сохранённые VPS, хранилище и обслуживание связей. Выделенная машина не обязана заменить каждую виртуальную. Её задача — принять ту работу, для которой она полезна, и дать предсказуемый результат.

Лучший итог переезда — не пустой список VPS. Это схема, где тяжёлые процессы получают ресурсы, тесно связанные компоненты не разговаривают через лишние границы, а средства наблюдения и восстановления переживают те отказы, ради которых они существуют. Иногда для этого нужна одна большая машина и несколько маленьких, каждая с очень ясной обязанностью.

Все материалы о выделенных серверах