Виртуализация удобна: на одном физическом сервере можно держать несколько ролей, быстро переносить сервисы, выделять ресурсы и обслуживать инфраструктуру компактнее. Но сама по себе она не делает систему надежной. Если не контролировать хост, storage, снапшоты, backup и восстановление, несколько серверов превращаются в одну крупную точку отказа.
В небольшой компании виртуализация часто появляется постепенно. Сначала на хост переносят файловый сервер, потом 1С, затем вспомогательные службы, тестовую машину, сервис мониторинга. Через год уже никто не помнит, какая VM за что отвечает, какие ресурсы ей нужны и что остановится при отказе физического узла.
Физический хост остается главным риском
Гостевые серверы могут выглядеть аккуратно, но все они зависят от железа под ними. Нужно понимать модель хоста, гарантийный статус, состояние дисков, памяти, питания, охлаждения и сетевых интерфейсов. Если хост один, это должно быть прямо записано как риск: отказ физического сервера остановит все виртуальные машины, даже если внутри них нет ошибок.
Если хостов несколько, важно не только их количество. Нужно знать, какие VM могут быть запущены на другом узле, хватит ли ресурсов при аварии, где лежит storage и что произойдет при отказе общего компонента. Наличие второго сервера не всегда означает отказоустойчивость.
Storage важнее, чем кажется
Для виртуальных машин дисковая подсистема часто становится узким местом. Нужно контролировать не только свободное место в гостевой Windows или Linux, но и datastore, рост виртуальных дисков, очередь операций, деградацию массива, ошибки контроллера и запас под обслуживание. Переполненный datastore может остановить сразу несколько сервисов.
Особое внимание нужно к снапшотам. Снапшот удобен перед изменением, но не является резервной копией и не должен жить бесконтрольно. Долгоживущие снапшоты увеличивают нагрузку, усложняют восстановление и могут неожиданно занять место. В регламенте должно быть указано, кто создает снапшот, зачем, на какой срок и кто проверяет удаление после успешного изменения.
Ресурсы: CPU, RAM и конкуренция VM
Виртуализация позволяет выдать виртуальным машинам больше ресурсов, чем физически есть на хосте. Иногда это нормально: не все сервисы нагружены одновременно. Но overcommit должен быть осознанным. Если база, файловый сервер, удаленные рабочие места и backup начинают активно работать в одно окно, пользователи увидят тормоза, хотя каждая VM отдельно будет выглядеть "живой".
Контролировать нужно не только среднюю загрузку CPU. Важны пики, ожидание диска, нехватка памяти, ballooning или swap, сетевые uplink, расписание backup и антивирусных проверок. Для бизнес-сервисов полезно знать не только техническую нагрузку, но и часы, когда замедление особенно дорого.
Backup виртуальных машин
Копия VM полезна, но она должна быть проверена как восстановление сервиса. Для каждой важной машины нужно знать, что именно копируется, как часто, куда, сколько хранятся точки, как шифруются или защищаются копии, кто получает уведомления об ошибках и сколько времени занимает запуск после аварии.
Отдельно проверяются зависимости. Восстановить файл виртуального диска недостаточно, если неясно, какой IP нужен сервису, где учетные записи, какие папки подключены, какая база должна стартовать первой и как пользователи узнают о восстановлении. Поэтому backup VM должен быть связан с картой сервисов и регламентом восстановления.
Документация и владелец изменений
Минимальный паспорт виртуализации должен содержать список хостов, список VM, роли, владельцев сервисов, зависимости, выделенные ресурсы, правила снапшотов, backup, мониторинг, учет лицензий и порядок изменения. Это не бюрократия ради документа. Без такого паспорта любое изменение становится ручным расследованием.
При обслуживании серверов виртуализация должна контролироваться как слой инфраструктуры, а не как невидимая оболочка. Команда поддержки видит физический хост, гостевые системы, storage, backup и последствия изменений. Тогда виртуальная среда действительно упрощает эксплуатацию, а не скрывает накопленные риски.
Признаки, что контроль потерян
- Никто не может быстро объяснить, какие VM критичны и что от них зависит.
- Снапшоты живут неделями или месяцами без владельца.
- Свободное место в datastore заканчивается быстрее, чем в гостевых системах.
- Backup считается успешным, но восстановление VM ни разу не проверялось.
- Нагрузка пользователей растет, но распределение CPU, RAM и диска не пересматривается.
- Второй хост есть, но сценарий работы при отказе первого не проверен.
Виртуализация в небольшой компании полезна, когда за ней есть эксплуатационный контур: мониторинг, документация, backup, правила изменений и проверка восстановления. Без этого она делает инфраструктуру компактнее, но не обязательно надежнее.