1. Веб-хостинг, VPS/VDS и сервер: уточняем термины
В этой статье под веб-хостингом понимается стандартная площадка для сайта с заданным набором ПО и ограничениями, без администрирования серверной ОС владельцем сайта. В более широком смысле web hosting может обозначать разные виды размещения, включая виртуальные и выделенные серверы.
VPS/VDS — виртуальная машина на физическом узле. Название тарифа не говорит обо всех свойствах: нужно уточнить виртуализацию, характер выделения процессорных ресурсов, ограничения дисков и сети, доступные ОС и порядок изменения конфигурации.
Выделенный сервер — отдельная физическая машина, предоставленная под задачу заказчика. Он даёт другой уровень контроля над аппаратными ресурсами, но сам по себе не делает приложение отказоустойчивым. Для доступности важны также архитектура, резервирование и восстановление. Базовое различие виртуального и выделенного размещения описано в сравнении Dedicated Server и VPS от AWS.
2. Сравнение по требованиям, а не по названию тарифа
| Критерий | Веб-хостинг | VPS/VDS | Выделенный сервер |
|---|---|---|---|
| Среда приложения | В рамках поддерживаемого стека | Собственная виртуальная среда | Среда на отдельной физической машине |
| Управление ОС | Обычно на стороне площадки | Заказчик или согласованная услуга | Заказчик или согласованная услуга |
| Особое ПО и процессы | Зависят от ограничений площадки | Проверяются по ОС и условиям виртуализации | Проверяются по ОС, оборудованию и условиям размещения |
| Изменение ресурсов | Переход между доступными вариантами | По возможностям платформы и доступности ресурсов | Изменение оборудования или переход на другую машину |
| Что выяснить до заказа | Версии ПО, лимиты, фоновые задания | vCPU, память, диски, сеть и сопровождение | Конфигурацию, диски, доступы и обслуживание |
Условия стандартного размещения и виртуальной серверной среды различаются по управлению и поддерживаемым возможностям. Для общей терминологии можно обратиться к обзору видов веб-хостинга AWS. Таблица выше — практический список вопросов ТриЭС, а не описание тарифов AWS или гарантия свойств конкретной площадки.
3. Какие данные собрать до подбора
Сначала опишите приложение. Какие версии ОС, интерпретатора и СУБД ему нужны? Есть ли очереди задач, собственные фоновые процессы, поиск, обработка изображений или интеграция с внутренними системами? Одного требования «сайт на CMS» может быть недостаточно, если у него есть нестандартные модули.
Затем соберите профиль нагрузки. Среднее число посещений за месяц скрывает пики и не показывает тяжесть запросов. Для действующего проекта полезны загрузка CPU, потребление памяти, задержки запросов к диску и базе, объём журналов, сетевой трафик и время выполнения критичных операций. Для нового проекта задают рабочие предположения и способ проверить их после запуска.
- Память: приложение, база данных, кэш и фоновые задачи должны рассматриваться вместе.
- Диски: учитывают не только объём, но и характер операций, задержки, временные файлы и рост данных.
- Процессор: важны тип вычислений и параллелизм. Число vCPU нельзя автоматически сравнивать с физическими ядрами другой машины.
- Сеть: нужны сведения о трафике, адресации, разрешённых соединениях и ограничениях площадки.
- Эксплуатация: кто устанавливает обновления, наблюдает за системой и восстанавливает её при проблеме?
После этого можно обсуждать стартовую конфигурацию. Запас ресурсов полезно связывать с ожидаемым ростом и сроком до следующего пересмотра, а не выбирать произвольный множитель «на всякий случай».
4. Три учебных примера выбора
Корпоративный сайт со стандартной CMS
Сайту нужны поддерживаемая версия ПО, база данных, формы и задания по расписанию. Если площадка совместима со всеми зависимостями и её лимиты подходят нагрузке, можно начать с веб-хостинга. Перед заказом стоит проверить работу почтовых уведомлений и резервного копирования, а не считать их включёнными автоматически.
Интеграционный сервис с фоновыми обработчиками
Приложение получает события из CRM, запускает задачи в очереди и обращается к API 1С. Если ему нужны собственные процессы, зависимости и правила доступа, стоит рассмотреть VPS/VDS. При этом владелец должен организовать администрирование самостоятельно или включить его в услугу.
Бизнес-система с обоснованными требованиями к оборудованию
Измерения показывают устойчивую нагрузку, нужны определённая дисковая подсистема или контроль физической конфигурации. Это основание обсудить выделенный сервер. Если узкое место находится в запросах к базе или коде приложения, переход на отдельную машину без исправлений может не дать ожидаемого эффекта.
Эти примеры показывают ход выбора и не являются кейсами клиентов, готовыми конфигурациями или результатом нагрузочного тестирования. Для 1С отдельно проверяют вариант работы, требования платформы и СУБД, размер базы, лицензирование и число одновременных операций.
5. Резервные копии и администрирование — отдельные условия
Вопрос «где разместить» нельзя отделить от вопроса «кто поддерживает». Для каждого уровня полезно назвать ответственного: оборудование, виртуальная среда, ОС, приложение, база данных, домен и DNS. Слово «поддержка» без перечня обязанностей оставляет слишком много неопределённости.
Для копирования согласуйте, какие данные сохраняются, как часто, сколько версий хранится и где находятся копии. Затем определите допустимую потерю данных и время восстановления. Эти параметры часто называют RPO и RTO; в задании полезнее записать понятные бизнесу значения и сценарий проверки, чем ограничиться аббревиатурами.
RAID не заменяет резервную копию: он не является полноценной историей изменений и не решает все сценарии потери данных. Снимок виртуальной машины также нужно оценивать по назначению и месту хранения. Важен не только факт создания копии, но и возможность восстановить согласованный набор данных.
Что спросить о сопровождении
- Кто получает уведомление при недоступности и что делает дальше?
- Кто обновляет ОС, CMS, приложение и СУБД?
- Кто проверяет копии и проводит тестовое восстановление?
- Как согласуются изменения конфигурации и плановые работы?
- Какие сроки реакции и исключения закреплены в условиях услуги?
6. Как принять решение и проверить переезд
Для предварительного выбора достаточно короткого документа: приложения и зависимости, профиль нагрузки, данные и рост, требования к доступности, ответственность за эксплуатацию. Сравнивайте полную стоимость выбранного состава: ресурсы, лицензии, перенос, сопровождение и резервные копии. Более низкая цена размещения не всегда означает меньшие общие затраты.
Если планируется перенос действующего сайта, подготовьте тестовый запуск и порядок переключения. Проверьте страницы, формы, доступ к базе, фоновые задания, HTTPS и внешние подключения. Для поиска сохраните адреса либо согласуйте перенаправления; после переключения проверьте canonical, robots.txt и sitemap. Сам перенос не гарантирует сохранение поискового трафика.
Нужен также понятный план возврата: при каких проблемах останавливают переключение, какие данные могли измениться на новой площадке и как избежать потери этих изменений. Простой возврат DNS не заменяет план согласования данных.
Начать подбор можно на страницах аренды серверов, VPS/VDS и веб-хостинга. Если тип размещения пока неясен, опишите систему в разделе инфраструктуры ТриЭС — сначала определим требования, затем вариант размещения.
Источники и границы материала
- AWS — Dedicated Server vs. VPS: базовые различия способов размещения.
- AWS — What is Web Hosting?: терминология и категории хостинга.
Примеры, таблица вопросов и порядок оценки — рекомендации ТриЭС. Наличие ресурсов, цена, совместимость и условия сопровождения подтверждаются для конкретного предложения.