-0.98
КОРОНАВИРУС
Для малого бизнеса серверная инфраструктура редко бывает приоритетом сама по себе. Компании важнее, чтобы сайт, CRM, база данных, корпоративный портал или внутренний сервис работали стабильно и не требовали постоянного внимания со стороны сотрудников.
На старте многие проекты используют обычный виртуальный хостинг, но по мере роста появляются задачи, для которых его возможностей становится недостаточно. Требуется больше ресурсов, отдельное программное окружение, собственные настройки безопасности или возможность запускать фоновые процессы.
В таких ситуациях виртуальный сервер становится промежуточным вариантом между простым хостингом и физическим оборудованием.
Для каких задач бизнесу подходит виртуальный сервер
Главное преимущество виртуального сервера заключается в изолированном окружении. Компания получает собственную операционную систему, выделенный объем вычислительных ресурсов и возможность самостоятельно устанавливать необходимое программное обеспечение.
Это позволяет использовать сервер не только для сайта.
На одной или нескольких виртуальных машинах можно разместить:
- корпоративный сайт или интернет-магазин;
- CRM и внутренние веб-сервисы;
- базы данных;
- систему управления проектами;
- API для мобильных и веб-приложений;
- VPN для сотрудников;
- тестовое окружение разработчиков;
- системы мониторинга;
- резервные сервисы;
- небольшие файловые хранилища.
Такой подход особенно удобен небольшим компаниям, которым уже требуется больше контроля, чем дает стандартный хостинг, но пока нет необходимости строить сложную инфраструктуру из физических серверов.
Почему обычного хостинга может стать недостаточно
На виртуальном хостинге несколько сайтов используют общую серверную среду. Пользователь управляет приложением и файлами, но практически не влияет на конфигурацию операционной системы.
Для небольшого сайта этого обычно достаточно.
Проблемы появляются, когда проект начинает требовать нестандартных компонентов или больше вычислительных ресурсов. Например, компании необходимо установить определенную версию базы данных, запустить собственный сервис, настроить очередь задач или изменить параметры веб-сервера.
Еще один сценарий — рост нагрузки.
Интернет-магазин расширяет ассортимент, в CRM работает больше сотрудников, а сайт начинает получать больше посетителей. В определенный момент ограничения стандартного тарифа становятся заметны по скорости работы приложения или количеству доступных ресурсов.
Переход на виртуальную машину позволяет получить более предсказуемое окружение и управлять его конфигурацией.
Какие характеристики важны малому бизнесу
Выбирать сервер только по количеству процессорных ядер неправильно. Конфигурация должна соответствовать характеру приложения.
CPU особенно важен для динамических сайтов, систем обработки данных, API и приложений с большим количеством параллельных операций.
Оперативная память нужна операционной системе, базам данных, кешу и рабочим процессам приложения. Для CMS и корпоративных систем недостаток RAM нередко ощущается раньше, чем нехватка вычислительной мощности.
Отдельное внимание следует уделить накопителю. SSD и NVMe обеспечивают значительно более быстрый доступ к данным по сравнению с традиционными жесткими дисками. Для баз данных, интернет-магазинов и систем с активной записью это непосредственно влияет на время отклика.
Также стоит учитывать пропускную способность сети и объем включенного трафика, особенно если компания работает с большим количеством файлов, резервными копиями или удаленными сотрудниками.
Не стоит выбирать конфигурацию с большим запасом
Для малого бизнеса особенно важно контролировать регулярные расходы.
Иногда сервер выбирают по принципу «пусть ресурсов будет побольше, чтобы потом не менять». В результате компания месяцами оплачивает процессор, память и дисковое пространство, которые практически не используются.
Противоположная крайность — минимальная конфигурация без какого-либо резерва. Она дешевле, но при росте нагрузки быстро становится узким местом.
Рациональнее отталкиваться от реального потребления ресурсов и оставлять небольшой запас на пиковые периоды.
Если проект развивается постепенно, намного важнее возможность увеличить конфигурацию в будущем, чем изначально оплачивать мощности с многократным запасом.
Один сервер для всего или несколько отдельных
Небольшая компания часто начинает с одной виртуальной машины.
На ней одновременно работают веб-сервер, база данных, корпоративное приложение и вспомогательные процессы. Для малого проекта это нормальная схема: она проще в администрировании и дешевле распределенной инфраструктуры.
По мере роста отдельные компоненты можно разделять.
Например, основной сайт остается на одном сервере, а база данных переносится на другой. Тестовое окружение разработчиков также лучше отделить от рабочего проекта, чтобы эксперименты не влияли на пользователей.
Разделение становится оправданным тогда, когда появляется конкретная техническая причина: нехватка ресурсов, требования к безопасности, необходимость независимого масштабирования или повышение отказоустойчивости.
Создавать сложную архитектуру только «на будущее» обычно не требуется.
Что учитывать при выборе провайдера
Стоимость тарифа — лишь один из критериев.
Для корпоративных задач не менее важно, насколько удобно изменять конфигурацию, какие серверные локации доступны, как организована техническая поддержка и какие дополнительные возможности предоставляет площадка.
Перед размещением проекта стоит проверить:
- характеристики процессоров и дисковой подсистемы;
- доступные объемы RAM;
- скорость сетевого подключения;
- возможность увеличения ресурсов;
- наличие резервного копирования;
- выбор операционных систем;
- способы управления сервером;
- доступные дата-центры и географию размещения;
- условия технической поддержки.
Для сравнения имеет смысл рассматривать несколько площадок с сопоставимыми конфигурациями. В качестве одного из вариантов можно изучить виртуальные серверы JustHost, сопоставив доступные характеристики и локации с требованиями конкретного корпоративного проекта.
Такой подход полезнее выбора исключительно по минимальной цене: дешевой может оказаться конфигурация, которой уже через несколько месяцев перестанет хватать.
Важна география размещения
Местоположение дата-центра влияет прежде всего на задержку между пользователем и сервером.
Если сотрудники и клиенты компании находятся преимущественно в одном регионе, обычно есть смысл выбирать относительно близкую серверную площадку. Для международного проекта требования будут другими.
География важна и при организации распределенной инфраструктуры. Например, часть сервисов может работать ближе к российской аудитории, а отдельные системы — в зарубежной локации.
Однако выбирать дата-центр только по расстоянию тоже неправильно. Необходимо учитывать качество сети, стабильность площадки и маршрутизацию до основных пользователей.
Оптимальный вариант лучше проверять измерением задержки и реальными тестами соединения.
Безопасность становится ответственностью компании
Получая собственную серверную среду, бизнес получает и больше ответственности за ее настройку.
На обычном хостинге значительную часть системных задач выполняет провайдер. В собственной виртуальной машине необходимо следить за операционной системой, обновлениями, учетными записями и сетевой безопасностью.
Минимальный набор мер включает регулярные обновления, использование SSH-ключей, ограничение административного доступа, настройку firewall и резервного копирования.
Не следует держать открытыми сетевые порты, которые не используются приложением. Для административных интерфейсов желательно ограничивать доступ или использовать VPN.
Также важно разделять учетные записи. Постоянная работа под root увеличивает последствия ошибки или компрометации доступа.
Резервные копии нужны даже небольшому проекту
Для малого бизнеса потеря данных иногда оказывается критичнее кратковременной недоступности сайта.
В базе могут находиться заказы, сведения о клиентах, документы, настройки корпоративных систем и результаты работы сотрудников.
Поэтому резервное копирование следует проектировать вместе с основной инфраструктурой, а не после первого сбоя.
Хорошая схема предполагает, что копия хранится независимо от рабочего сервера. Если резерв находится только на том же диске или в той же файловой системе, аппаратная проблема или ошибка администратора может уничтожить одновременно и оригинал, и копию.
Также необходимо периодически проверять восстановление. Сам факт создания архива еще не гарантирует, что из него удастся вернуть работоспособную систему.
Мониторинг помогает не переплачивать
Одна из причин неоправданных расходов — отсутствие статистики по фактическому использованию ресурсов.
Без мониторинга сложно понять, действительно ли проекту нужен более мощный тариф.
Стоит контролировать загрузку CPU, использование оперативной памяти, свободное место на диске, интенсивность операций чтения и записи, сетевой трафик и время ответа приложения.
Если процессор большую часть времени загружен на 10–15%, удваивать количество ядер нет смысла. Если сервер активно использует swap, намного вероятнее, что сначала требуется дополнительная RAM.
Такие данные позволяют точечно увеличивать именно тот ресурс, который ограничивает производительность.
Когда виртуального сервера уже недостаточно
Для большинства небольших компаний одной или нескольких виртуальных машин хватает надолго.
Но по мере роста бизнеса требования могут измениться. Проект начинает постоянно использовать значительные вычислительные ресурсы, появляется большая база данных, возрастает число сотрудников или становится критичной предсказуемая производительность.
В дальнейшем можно увеличивать конфигурацию, разделять сервисы между несколькими узлами или переходить на физическое оборудование.
При этом масштабирование не обязательно должно быть резким. Инфраструктура может развиваться вместе с бизнесом: сначала один сервер, затем отдельная база данных, дополнительные сервисы и только после этого более сложная архитектура.
Что в итоге
Для малого бизнеса виртуальная инфраструктура полезна прежде всего своей гибкостью. Она позволяет получить собственное серверное окружение без затрат на покупку физического оборудования и при этом постепенно увеличивать ресурсы по мере развития проекта.
Главное — не выбирать сервер по формальному количеству ядер или минимальной цене. Нужно понимать характер нагрузки, требования приложения, важность резервного копирования и перспективы масштабирования.
Если конфигурация соответствует реальному потреблению, а площадка позволяет без сложной миграции увеличивать ресурсы, компания получает инфраструктуру, которая может развиваться вместе с ее сервисами и при этом не требует преждевременных расходов на избыточные мощности.
