Выделенные серверы

Физический сервер под свою виртуализацию: когда один мощный сервер выгоднее пачки VPS

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

Что вообще значит «физический сервер под свою виртуализацию»?

Обычно бизнес arендует VPS напрямую у провайдера: заказал виртуальную машину нужной конфигурации, получил доступ и работает. Но есть другой сценарий — компания арендует физический сервер целиком, устанавливает на него собственный гипервизор (программу для управления виртуальными машинами) и уже сама создаёт на этом железе столько виртуальных серверов, сколько нужно, с любыми параметрами.

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

Чем это отличается от простой аренды нескольких VPS?

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

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

В каких случаях это реально выгоднее, чем набор отдельных VPS?

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

  • несколько внутренних систем — CRM, база данных, сервис документооборота, тестовый контур — которые логично изолировать друг от друга, но нет смысла держать на разных физических машинах;
  • подрядчик или ИТ-отдел, который обслуживает несколько проектов клиентов и хочет управлять ресурсами гибко, без переплаты за отдельные тарифы;
  • компания хочет протестировать новую конфигурацию или версию системы на изолированной виртуальной машине, не трогая рабочую;
  • нужно соблюдать требования по изоляции данных между разными подразделениями или клиентами, но заводить под каждого отдельный физический сервер экономически невыгодно.

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

Какие технологии для этого используются?

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

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

Клауд АйСи — облачная инфраструктура и защищённые серверы под 1С и цифровые сервисы бизнеса: размещение в дата-центре, резервное копирование и поддержка.
Всё в одном кабинете по подписке.
Есть бесплатные тарифы навсегда.

Какие сложности возникают при самостоятельной виртуализации?

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

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

Как понять, сколько виртуальных машин поместится на одном сервере?

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

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

Что с лицензиями и техподдержкой в такой схеме?

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

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

Как «Клауд АйСи» помогает с этой задачей?

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

Так как в итоге понять, нужна ли компании своя виртуализация?

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

Разместите 1С и сервисы в облаке

Зарегистрируйтесь и подключите инфраструктуру под ваши задачи — начните с бесплатного тарифа.

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

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

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

Кому подходит такая схема?

Компаниям, у которых несколько отдельных систем с неравномерной нагрузкой — например, CRM, база данных, тестовый контур — которые выгоднее объединить на одном мощном сервере, чем разносить по разным физическим машинам.

Какие риски есть у собственной виртуализации?

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

Нужны ли специальные лицензии для виртуализации?

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

Как понять, хватит ли ресурсов одного сервера под все нужные виртуальные машины?

Расчёт стоит вести от фактической, а не пиковой нагрузки каждой системы, учитывая, что редко все задачи достигают максимума одновременно, и оставлять запас ресурсов на рост.