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

Один физический сервер и несколько виртуальных

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

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

Чтобы представить устройство такой инфраструктуры, достаточно проследить, как распределяются ресурсы.

1. Администратор создает виртуальные машины и назначает каждой виртуальные процессоры, объем RAM и виртуальные диски с учётом её задач.

2. Гипервизор обеспечивает их одновременную работу на общем оборудовании и управляет доступом к физическим ресурсам.

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

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

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

Какие задачи можно разделить между виртуальными серверами

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

Для небольшой компании распределение задач может выглядеть так.

• Бухгалтерская система. Отдельная машина для учетного приложения позволяет планировать его обновления и выделять ресурсы под рабочую нагрузку;

• Файловый сервер. Общие документы размещают в собственной VM, где настраивают права доступа сотрудников и правила хранения файлов;

• Внутренний портал. Корпоративный сайт или база знаний работают со своим набором программных компонентов, не затрагивая окружение других приложений;

• Службы инфраструктуры. Каталог пользователей и DNS размещают с учетом зависимостей остальных систем: их доступность необходима для нормальной работы сети;

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

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

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

Зачем бизнесу объединять инфраструктуру

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

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

Оценивать результат объединения стоит по нескольким практическим критериям.

1. Расходы на оборудование и эксплуатацию. Меньшее число физических машин может сократить потребление электроэнергии, занимаемое место и количество обслуживаемых компонентов. Экономию считают с учетом стоимости общей платформы, лицензий и средств защиты данных.

2. Скорость развертывания. Шаблоны виртуальных машин позволяют быстрее создавать однотипные окружения с заранее подготовленной ОС и базовыми настройками.

3. Гибкость распределения ресурсов. Объем памяти и количество виртуальных процессоров можно менять по потребностям приложения в пределах возможностей платформы. Для некоторых изменений потребуется выключение VM.

Объединение оправдано, когда суммарная нагрузка предсказуема и остается резерв для роста. Если одна система уже использует почти всю производительность дисков или CPU, перенос соседних сервисов на ту же платформу способен ухудшить их работу. В таком случае нагрузку распределяют между несколькими физическими узлами.

Что произойдет при отказе физического оборудования

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

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

1. Резервирование компонентов. Дублирующие блоки питания при правильном подключении и дисковый массив с избыточностью помогают пережить отдельные отказы. Однако они не защищают от всех неисправностей сервера.

2. Резервное копирование. Копии хранят вне единственного рабочего узла и проверяют восстановление. После серьёзного сбоя потребуется доступное оборудование, на котором можно заново запустить виртуальные машины. Срок восстановления зависит от объема данных и подготовленности инфраструктуры.

3. Кластер высокой доступности. Несколько физических узлов позволяют автоматически перезапустить виртуальные машины на исправном сервере при отказе другого. Для этого нужны доступные сохранившемуся узлу данные VM, корректная настройка кластера и запас вычислительных ресурсов.

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

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