У владельца сайтов редко все начинается с десятка проектов. Сначала появляется один. Потом второй для другого направления бизнеса, небольшой блог, лендинг, тестовый домен. В какой-то момент в панели виртуального хостинга уже тесно, и возникает вполне разумная мысль: а не арендовать ли один VPS и не перенести ли туда все сайты сразу?
Технически можно. Один виртуальный сервер способен обслуживать несколько доменов, и для этого не требуется отдельный VPS под каждый сайт. Но слово «можно» здесь намного проще слова «стоит». Если собрать все проекты на одной машине без учета нагрузки и изоляции, экономия быстро превращается в ситуацию, когда проблема одного сайта кладет остальные.
Поэтому вопрос лучше ставить иначе: какие сайты разумно объединять на одном VPS, сколько ресурсов им понадобится вместе и насколько опасна для вас общая точка отказа?
Один VPS не делится на независимые кусочки автоматически
Представим сервер, на котором работают пять сайтов. У VPS есть определенный объем оперативной памяти, процессорного времени и дискового пространства. Эти ресурсы принадлежат всей виртуальной машине.
Если один WordPress внезапно запускает тяжелую задачу и забирает процессор, последствия могут почувствовать остальные четыре проекта. Если неудачный импорт съедает свободную память, проблема тоже становится общей. Если огромный лог заполняет диск, место заканчивается не у одного домена, а у сервера.
Именно этим VPS принципиально отличается от представления «я купил большой тариф и раздал каждому сайту по кусочку». Разделить ресурсы можно, но это требует настройки.
На обычном виртуальном хостинге значительную часть такой работы делает провайдер. На собственном VPS правила устанавливает администратор.
Когда несколько сайтов на одном сервере выглядят вполне разумно
Есть сценарии, где отдельная виртуальная машина для каждого проекта действительно была бы лишней.
Например, компания поддерживает основной корпоративный сайт, пару небольших лендингов и внутренний информационный проект. Нагрузка предсказуемая, владельцы одни и те же, требования к программному окружению похожи. Все это вполне может жить вместе.
То же относится к веб-мастеру с несколькими небольшими контентными сайтами. Если проекты не создают серьезной нагрузки, один нормально настроенный VPS проще обслуживать, чем коллекцию маленьких серверов.
Есть и организационный плюс. Один сервер — одна точка для обновлений системы, мониторинга и резервного копирования. Не приходится вспоминать, на какой из семи машин закончился сертификат или осталось старое серверное ПО.
Но удобство сохраняется только до тех пор, пока проекты действительно совместимы по требованиям и рискам.
Считать ресурсы нужно не по количеству доменов
Фраза «VPS для десяти сайтов» почти ничего не говорит о требуемой конфигурации.
Десять небольших статических сайтов могут создавать меньше нагрузки, чем один магазин. Три хорошо кэшируемых WordPress могут быть спокойнее одного проекта с тяжелым поиском, личными кабинетами и постоянно работающим импортом.
Поэтому складывать нужно не сайты, а их потребление.
Если проекты уже работают, посмотрите статистику текущего хостинга. Нас интересуют пиковые значения CPU, память, объем файлов и баз, количество процессов, фоновые задания. Полезно знать, какой сайт создает основную нагрузку.
С диском расчет относительно прямой: файлы всех проектов, базы данных, система, логи, временные данные и запас. Если на VPS создаются локальные резервные копии, они тоже занимают место, хотя единственную копию на том же сервере хранить не следует.
С RAM сложнее. Память используют не только сайты. Она нужна операционной системе, веб-серверу, PHP, базе данных, панели управления, кэшу и другим службам. Несколько сайтов могут одновременно запускать PHP-процессы, поэтому смотреть только на размер каждого WordPress на диске бессмысленно.
Процессорная нагрузка тоже суммируется неравномерно. Если все сайты получают пики в разное время, серверу проще. Если в девять утра одновременно запускаются cron, резервное копирование, импорт товаров и рассылка, вы сами создаете искусственный час пик.
Иногда перед покупкой более мощного VPS достаточно разнести тяжелые задачи по расписанию.
Панель управления сильно упрощает жизнь, но меняет устройство сервера
Размещать несколько сайтов вручную можно через конфигурации Nginx или Apache, отдельные каталоги, пользователей, базы и сертификаты. Для опытного администратора это обычная работа.
Если Linux не является вашей повседневной средой, панель управления часто оказывается практичнее. Она позволяет создавать домены, базы, FTP или SFTP-доступы, выпускать сертификаты и менять версии PHP через веб-интерфейс.
Для сервера с множеством сайтов это особенно удобно.
Но панель не бесплатна в смысле ресурсов, даже если за саму лицензию платить не требуется. Ее службы тоже используют память и процессор. Некоторые панели устанавливают почтовый сервер, антивирус, DNS и дополнительное ПО.
Поэтому конфигурацию VPS следует выбирать с учетом всего стека, а не только CMS.
И еще один момент: наличие красивой панели не отменяет администрирование. Обновления операционной системы, безопасность, мониторинг, резервное копирование и восстановление все равно должны быть чьей-то ответственностью.
Самая неприятная сторона одного VPS — общая авария
Пока сервер работает, объединение сайтов выглядит очень рационально. Настоящая цена решения проявляется во время сбоя.
Ошибка конфигурации веб-сервера может сделать недоступными все проекты. Закончившийся диск остановит сразу несколько сайтов. Неудачное обновление системы затронет всю машину. Если сам VPS недоступен из-за инфраструктурной проблемы, вместе с ним исчезает весь размещенный набор.
Для пяти небольших личных проектов такой риск может быть приемлемым.
Для двух интернет-магазинов, каждый из которых приносит бизнесу заказы, уже стоит задуматься.
Это не означает, что каждому коммерческому сайту обязательно нужен отдельный сервер. Вопрос в допустимом масштабе отказа. Если потеря одного VPS одновременно останавливает все критичные интернет-ресурсы компании, вы сознательно создали единую точку отказа.
Иногда дешевле и спокойнее разделить проекты хотя бы на две группы.
Безопасность тоже становится общей задачей
Несколько сайтов на одном VPS должны быть изолированы настолько, насколько позволяет выбранная архитектура.
Худший вариант — все проекты работают от одного системного пользователя, используют общие права на файлы, а доступ от одного сайта фактически открывает путь к остальным.
Если один WordPress взломают через уязвимый плагин, атакующий не должен автоматически получить возможность переписывать файлы всех соседних доменов.
Раздельные системные пользователи, корректные права, отдельные базы и учетные записи заметно уменьшают последствия компрометации. Контейнеризация может дать еще один уровень изоляции, но она добавляет сложности и нужна далеко не каждому владельцу нескольких сайтов.
Важно и происхождение проектов. Свои сайты, которые вы полностью контролируете, объединять проще. Размещать на той же машине неизвестный код клиента, экспериментальный проект и критичный магазин уже гораздо рискованнее.
Чем меньше вы доверяете одному из приложений, тем сильнее аргумент в пользу отдельного окружения.
Нужно ли держать почту на том же VPS
Технически собственный почтовый сервер можно разместить рядом с сайтами. Практически это добавляет еще одну службу, которую нужно правильно настроить, защищать и обслуживать.
Для многих небольших проектов проще оставить почту у специализированного почтового сервиса или хостинг-провайдера, а VPS использовать непосредственно для сайтов.
Так веб-сервер не занимается дополнительной работой, а ошибка при обслуживании VPS не обязательно оставляет компанию одновременно без сайта и электронной почты.
Это хороший пример общего принципа: наличие root-доступа означает, что вы можете установить почти все, но не означает, что все обязательно нужно устанавливать на одну машину.
Как переносить несколько сайтов без большого отключения
Не стоит переносить всю коллекцию одним движением, особенно если раньше вы не администрировали VPS.
Сначала подготовьте сервер: веб-стек, нужные версии PHP, базы, сертификаты, резервное копирование и мониторинг. Затем перенесите один некритичный сайт и проверьте его работу.
После этого переходите к остальным.
Так вы обнаружите ошибки конфигурации на одном проекте, а не на десяти одновременно. Заодно станет видно реальное потребление ресурсов новым сервером.
Перед переключением DNS убедитесь, что файлы и база синхронизированы, HTTPS работает, формы отправляются, фоновые задания запускаются, а административная часть доступна. Для динамических проектов важно продумать финальную синхронизацию данных, чтобы новые заказы или комментарии не остались на старом сервере.
Старый хостинг лучше не отключать сразу после изменения DNS. Дайте себе время убедиться, что переход завершен корректно.
Когда один VPS уже пора разделять
Первый сигнал — один проект начинает заметно влиять на остальные. Магазин получает всплеск заказов, CPU занят, и одновременно замедляются корпоративный сайт и блог.
Второй — проекты требуют несовместимого окружения. Одному нужна определенная версия ПО, другой обновляется быстрее, третий требует отдельной конфигурации безопасности.
Третий — различается критичность. Небольшой экспериментальный сайт не должен иметь возможность повлиять на основной ресурс бизнеса.
Четвертый — обслуживание становится неудобным. Если любое обновление приходится откладывать из страха задеть десяток приложений, монолитный VPS перестал упрощать работу.
Пятый — сервер приходится увеличивать в основном ради одного сайта. В таком случае часто логичнее вынести именно этот проект на отдельную машину, а остальные оставить на прежней.
Разделение не обязательно означает возвращение к хаосу из десятков серверов. Можно сгруппировать сайты по назначению: коммерческие отдельно, небольшие информационные отдельно, тестовые окружения отдельно.
А может, для нескольких сайтов VPS вообще не нужен
Да. И это стоит сказать прямо.
Если у вас несколько небольших сайтов, которые нормально работают на виртуальном хостинге, не требуют специального серверного ПО и не упираются в ресурсы, VPS может только добавить работы.
На shared hosting провайдер обслуживает операционную систему и серверный стек. Вы занимаетесь сайтами. На VPS появляется root-доступ, но вместе с ним появляются обновления, настройка firewall, контроль служб, мониторинг и ответственность за безопасность.
Переход оправдан, когда нужен больший контроль, собственное окружение, предсказуемые ресурсы или виртуальный хостинг уже ограничивает проекты.
Если единственная причина — «сайтов стало пять», сначала посмотрите тарифы обычного хостинга. Многие из них изначально рассчитаны на несколько доменов. На главной Hostingi.org можно сравнить варианты виртуального хостинга, а если ограничения shared hosting уже действительно мешают — переходить к VPS/VDS.
Как выбирать VPS именно под группу сайтов
Не ищите тариф с обещанием «до 20 сайтов». Для VPS такая цифра почти бесполезна.
Составьте список проектов и отметьте для каждого тип CMS, размер файлов и базы, характер нагрузки, фоновые задачи и критичность. Посмотрите, какие версии программного обеспечения им нужны.
Затем оцените общие ресурсы и добавьте запас для пиков. Обратите внимание не только на vCPU и RAM, но и на возможность увеличить их без сложного переезда, скорость и размер диска, резервное копирование, снапшоты, сетевые ограничения и уровень поддержки.
Если самостоятельно администрировать Linux не хочется, отдельно выясните, является ли VPS управляемым. У разных провайдеров понятие администрирования отличается: где-то помощь ограничивается инфраструктурой, где-то специалисты настраивают веб-сервер и переносят сайты.
Для нескольких проектов качество поддержки особенно заметно. Ошибка на одном сервере затрагивает сразу весь набор, поэтому возможность быстро получить технически содержательный ответ ценнее красивого списка характеристик.
И наконец, подумайте не только о сегодняшнем количестве сайтов. Важнее то, насколько легко инфраструктура позволит вынести один выросший проект на отдельный VPS. Хорошая схема не должна превращать будущий рост в сложную миграцию всего хозяйства.
Один VPS для нескольких сайтов — совершенно нормальная архитектура, пока вы понимаете ее границы. Она экономит усилия, упрощает управление и позволяет эффективнее использовать ресурсы. Но все проекты начинают делить не только CPU и RAM, а еще сбои, ошибки администратора и часть рисков безопасности.
Поэтому объединять сайты стоит не потому, что сервер «вмещает много доменов», а потому, что этим проектам действительно удобно и безопасно жить вместе.
