Процессоры, память, сеть и локальные или подключённые системы хранения формируют ресурсную базу виртуализации.
Виртуализация серверов: хосты, кластеры и виртуальные машины
Гипервизоры, распределение CPU и RAM, HA, live migration, shared storage, сеть, backup и совместимость инфраструктуры.
Основные темы
Физический хост, гипервизор, виртуальные машины и распределение ресурсов.
02CPU и RAMvCPU, память, overcommit, NUMA и запас ресурсов для нагрузки.
03Кластер и HAНесколько хостов, отказоустойчивость, shared storage и live migration.
04Совместимость и миграцияГипервизор, сеть, backup, приложения, лицензии и переход между платформами.
Из физического сервера — несколько VM
Виртуализация разделяет ресурсы одного или нескольких физических хостов между изолированными виртуальными машинами.
Слой виртуализации распределяет вычислительные ресурсы между VM и управляет их запуском и состоянием.
Каждая VM получает виртуальные CPU, память, диски и сетевые интерфейсы для своей операционной системы и приложений.
Объединение хостов позволяет распределять нагрузку и строить отказоустойчивую инфраструктуру.
CPU, RAM и overcommit
Виртуальные ресурсы нельзя оценивать отдельно от физической платформы и реального профиля нагрузки.
Количество vCPU не равно количеству физических ядер один к одному: важны загрузка VM, конкуренция за CPU и политика гипервизора.
Допустимый коэффициент зависит от характера нагрузки и не должен назначаться одинаково для всех приложений.
Для memory-intensive систем важны физический объём RAM, запас для гипервизора и поведение при дефиците памяти.
На многосокетных серверах крупные VM нужно рассматривать с учётом NUMA-топологии физического хоста.
HA и live migration
Кластерная виртуализация зависит не только от хостов: критичны сеть, хранение, совместимость и резерв ресурсов.
При отказе одного хоста кластер должен иметь достаточно ресурсов и настроенный механизм перезапуска или переноса нагрузок.
Возможность миграции зависит от гипервизора, CPU-совместимости, сети и архитектуры хранения.
Кластер может использовать совместно доступное хранилище; требования к latency, IOPS и доступности нужно считать вместе с VM-нагрузкой.
Management, migration, storage и пользовательский трафик могут предъявлять разные требования к пропускной способности и резервированию.
Смена гипервизора — не просто замена ПО
Перед миграцией нужно проверить весь связанный стек, а не только возможность установить новую платформу виртуализации.
Нужно проверить гостевые ОС, прикладное ПО, драйверы, агенты и требования к лицензированию.
FC, iSCSI, NFS и другие варианты хранения должны поддерживаться новой архитектурой и соответствовать требованиям по отказоустойчивости.
После смены гипервизора нужно сохранить требуемые RPO/RTO, сценарии восстановления и совместимость backup-системы.
План перехода должен учитывать окна миграции, тестирование, откат и требования сервисов к доступности.
Какие платформы встречаются в инфраструктуре
Такие платформы могут продолжать работать в существующих контурах. Сам факт их наличия не означает, что миграция должна выполняться немедленно.
В проектах могут рассматриваться Basis, zVirt, vStack, РЕД Виртуализация, SpaceVM и другие платформы — выбор требует проверки функций и совместимости.
HA, live migration, storage, сеть, backup, VDI, лицензии, приложения и допустимый простой должны проверяться вместе.
Что определить до расчёта кластера
vCPU, RAM, диски и характер нагрузки.
Какой отказ должен выдержать кластер и какой нужен резерв.
IOPS, latency, протоколы и пропускная способность.
RPO/RTO, совместимость и допустимый простой.
Свяжитесь с нами
Расскажите о вашей задаче — мы ответим в течение рабочего дня и подготовим предложение под вашу ситуацию.
- Тел.+7 (999) 156-14-51
- Emailinfo@servergov.ru
- РежимПн–Пт, 9:00–18:00 МСК
- Закупки44-ФЗ / 223-ФЗ