Сервер для виртуализации: как выбрать конфигурацию и посчитать, сколько ВМ потребуется

Компания использует шесть устаревших серверов: они обслуживают почту, файлы, 1С, мониторинг и тестовые стенды. Пришло время их менять. Вместо нескольких серверов можно взять один мощный и перенести задачи в виртуальные машины. Но сколько для этого понадобится ядер, памяти и дискового пространства?

Разберём, как рассчитать ресурсы для виртуальных машин и подобрать конфигурацию Yandex BareMetal под свою нагрузку.

Что такое сервер виртуализации и как он работает

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

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

Гипервизоры делят на два типа в зависимости от того, как они взаимодействуют с оборудованием.

Контейнеры включены в таблицу для сравнения: это отдельный способ изоляции, для которого гипервизор не нужен. Основные понятия описаны в глоссарии Yandex Cloud.

KVM входит в ядро Linux, а Hyper-V можно включить как роль Windows Server. При этом оба относятся к гипервизорам первого типа.

На базе гипервизоров строят платформы управления виртуальной инфраструктурой. Например, Proxmox VE использует Debian^™ и KVM, а также позволяет запускать контейнеры LXC рядом с виртуальными машинами. С KVM работают и другие платформы, в том числе oVirt и OpenStack^®.

О том, как устроена виртуализация у облачного провайдера, рассказываем в статье «Гипервизор Yandex Cloud: архитектура разработки».

Для аппаратной виртуализации процессор должен поддерживать Intel VT-x или AMD-V. Если нужно запускать ВМ внутри другой ВМ, потребуется вложенная виртуализация. Её доступность зависит от процессора, настроек сервера и гипервизора. На выделенном сервере эти настройки вы контролируете сами — это удобно для учебных лабораторий и тестовых стендов.

Когда нужен свой гипервизор, а когда удобнее облачные ВМ

Собственный сервер виртуализации стоит рассмотреть, если вам нужно управлять всей платформой: выбирать гипервизор, настраивать сеть, распределять ресурсы и устанавливать обновления.

По опросу Yandex Cloud за апрель 2025 года, 66% опрошенных компаний используют bare metal для собственной виртуализации на OpenStack, VMware и других платформах. Это второй по популярности сценарий после хранения и обработки данных.

Свой гипервизор может пригодиться, если вы хотите:

• перенести задачи со старых физических машин на один-два хоста;
• сохранить привычную платформу виртуализации и процессы её обслуживания;
• создавать тестовые стенды с полным контролем сети;
• использовать имеющиеся лицензии с привязкой к ядрам или сокетам, если их условия это позволяют;
• разместить все ВМ на отдельном физическом сервере.

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

Для такого сценария подойдёт Yandex Compute Cloud с оплатой за время работы. Особенности переезда с VMware разобраны в статье «Yandex Cloud глазами инженера VMware».

Если планируете разместить сервер 1С, СУБД и терминальный сервер в отдельных ВМ на одном хосте, сначала рассчитайте их нагрузку. Для однопоточных операций 1С особенно важна производительность одного ядра.

Как подобрать компоненты сервера виртуализации

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

Дисклеймер: в этом блоке мы говорим о виртуализации на выделенных серверах, а не об отдельных виртуальных машинах.

Процессор: сколько ядер нужно виртуальным машинам

Гипервизор распределяет виртуальные процессоры ВМ — vCPU — между физическими ядрами сервера. Если машины не используют все vCPU одновременно, им можно суммарно выделить больше виртуальных процессоров, чем есть физических ядер. Это называется переподпиской.

Для предварительного расчёта можно использовать такие ориентиры:

Считайте переподписку по физическим ядрам. Гиперпоточность — SMT — может повысить производительность, но не удваивает её.

Например, для 20 средних ВМ по 4 vCPU при переподписке 2:1 потребуется 40 физических ядер. В нашем расчёте добавим ещё четыре для гипервизора — получим 44 ядра. Допустимую переподписку затем нужно проверить под нагрузкой.

Частота тоже важна, особенно для приложений с однопоточными операциями. При сравнении Intel^® Xeon^® и AMD учитывайте число ядер, производительность ядра, каналы памяти и стоимость лицензий. Если ПО лицензируется по ядрам, сервер с меньшим числом быстрых ядер иногда обходится дешевле.

В многосокетных серверах учитывайте NUMA: процессор быстрее обращается к локальной памяти, чем к памяти другого узла. Крупные ВМ по возможности размещайте так, чтобы их процессорные ресурсы и память помещались в одном NUMA-узле.

На серверах Yandex BareMetal системные настройки BIOS заданы по умолчанию. Менять их без необходимости не рекомендуется.

Память: сумма потребностей ВМ и запас

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

Формула для предварительного расчёта:

Память хоста = (сумма памяти всех ВМ + резерв платформы) × 1,2–1,3.

Резерв берите из документации выбранной платформы. Например, Proxmox VE требует минимум 2 ГБ для ОС и своих служб. Для ZFS или Ceph дополнительно указывается ориентир около 1 ГБ памяти на каждый терабайт используемого хранилища.

В наших примерах заложим 4 ГБ для системы. Память для хранилища и виртуальных машин посчитаем отдельно.

Для рабочего сервера рекомендуем память ECC. Проверьте не только общий объём, но и заполнение каналов памяти: от этого зависит пропускная способность.

Диски: производительность при одновременной работе ВМ

Когда десятки ВМ одновременно читают и записывают данные мелкими блоками, дисковая подсистема может стать узким местом. Для такой нагрузки стоит рассмотреть NVMe. SATA SSD подойдут менее требовательным ВМ и локальным копиям, HDD — архивам.

Для дисков ВМ часто выбирают RAID 10 или зеркала ZFS. RAID 5 и RAID 6 могут заметно терять производительность на случайной записи — их пригодность нужно проверять под своей нагрузкой.

Одному хосту может хватить локальных дисков. Для кластера можно использовать распределённое хранилище, например Ceph или vSAN. Оно делает данные доступными нескольким узлам. При этом распределённое хранилище — не единственный способ организовать миграцию ВМ.

В документации Proxmox VE для Ceph приведены ориентиры: минимум три узла и отдельная сеть от 10 Гбит/с, а для NVMe — от 25 Гбит/с.

Сеть: пропускная способность и ограничения

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

Для нескольких служебных ВМ может хватить 1 Гбит/с. Для десятков машин, живой миграции и распределённого хранилища ориентируйтесь на 10–25 Гбит/с, затем уточняйте требования по нагрузке.

При настройке сети Yandex BareMetal учитывайте три особенности:

• MAC-адреса. В режиме сетевого моста у каждой ВМ свой MAC-адрес. На порт сервера действует лимит в пять MAC-адресов. Увеличить его через поддержку можно только на картах 10 и 25 Гбит/с.
• STP и пакеты BPDU. Коммутаторы блокируют порт, с которого поступают BPDU. Такие пакеты может отправлять виртуальный коммутатор гипервизора с включённым STP.
• Связь между сетями. Для ВМ разных команд можно использовать дополнительные приватные подсети с тегированными VLAN. Серверы из разных пулов связывают через маршрутизацию на уровне L3 с использованием VRF.

Часть этих ограничений разобрана в статье «Как не нужно работать с выделенными серверами».

Отказоустойчивость: ресурсы нужны всему кластеру

Если единственный хост выйдет из строя, все размещённые на нём ВМ остановятся. Для критичных систем рассчитывайте кластер по схеме N+1: после отказа одного узла оставшимся должно хватать ресурсов для всех необходимых ВМ.

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

Для резервирования сетевого подключения можно использовать MC-LAG: сервер подключают к двум коммутаторам. Такая схема позволяет сохранить связь при отказе одного подключения или коммутатора.

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

Резервные копии ВМ храните вне хоста, например в Yandex Object Storage. Снапшот на рабочем диске не защитит от потери самого диска или сервера.

Как рассчитать сервер для виртуализации за пять шагов

Начните со списка виртуальных машин и их нагрузки. По нему можно рассчитать ресурсы хоста и понять, нужен ли кластер.

1. Составьте список ВМ. Для каждой укажите число vCPU, память, объём дисков и пиковые IOPS. Если измерений нет, используйте профили из таблицы ниже. Для предварительной оценки берите верхнюю границу, затем уточняйте её по фактической нагрузке.
2. Выберите один хост или кластер. Если простой на время восстановления допустим, можно использовать один хост с резервными копиями вне него. Для критичных систем рассмотрим кластер из трёх узлов: после отказа любого из них оставшиеся два должны вмещать все необходимые ВМ.
3. Рассчитайте ядра. Разделите сумму vCPU каждого профиля на коэффициент переподписки: 4 для лёгких ВМ, 2 для средних и 1 для тяжёлых. Сложите результаты и добавьте 10% для гипервизора.
4. Подберите диски и сеть. Умножьте суммарный объём дисков ВМ на 1,3 — это запас на снапшоты и рост. Отдельно учтите ёмкость, которую займут зеркалирование или репликация. Производительность дисков оцените по одновременной пиковой нагрузке ВМ. Сеть подбирайте с учётом пользовательского трафика, копирования, миграции и работы хранилища. Для Ceph на NVMe в наших примерах заложим 25 Гбит/с. Также проверьте лимиты MAC-адресов.
5. Рассчитайте память. Сложите память всех ВМ и резерв платформы, затем добавьте 25% на рост. В этой методике резервируем 4 ГБ на систему каждого узла и ориентировочно 1 ГБ на терабайт физической ёмкости дисков под ZFS или Ceph. Это предварительная оценка: требования выбранной платформы нужно проверить отдельно.

Память = (память ВМ + резерв систем + резерв хранилища) × 1,25.

Запас 25% добавляем один раз, ко всей сумме.

Пример № 1. Перенос небольшой инфраструктуры

После инвентаризации задачи с шести старых серверов распределили между 12 ВМ:

• шесть лёгких: по 2 vCPU, 4 ГБ памяти, 40 ГБ диска и 300 IOPS;
• пять средних: по 4 vCPU, 12 ГБ памяти, 150 ГБ диска и 2 тыс. IOPS;
• одна СУБД: 8 vCPU, 64 ГБ памяти, 500 ГБ диска и 10 тыс. IOPS.

Простой на время восстановления допустим, поэтому выбираем один хост.

Процессор. Лёгким ВМ нужно 12 ÷ 4 = 3 физических ядра, средним — 20 ÷ 2 = 10, СУБД — 8 без переподписки. Всего 21 ядро. С резервом 10% получаем 23,1 — округляем до 24 ядер.

Диски. Суммарный объём — 1 490 ГБ. С запасом 30% получаем 1 937 ГБ, или примерно 2 ТБ полезного пространства. Суммарный пик — 21,8 тыс. IOPS. Выбираем NVMe; для зеркала полезной ёмкостью 2 ТБ потребуется около 4 ТБ физической ёмкости.

Сеть. Если подключить все 12 ВМ через мост с отдельными MAC-адресами, стандартного лимита в пять адресов не хватит. Для этого варианта выбираем порт 10 Гбит/с и заранее согласовываем увеличение лимита.

Память. Виртуальным машинам нужно 24 + 60 + 64 = 148 ГБ. Добавляем 4 ГБ для системы и 4 ГБ для ZFS. С запасом получаем:

(148 + 4 + 4) × 1,25 = 195 ГБ.

Выбираем 256 ГБ памяти: 192 ГБ уже меньше расчётного значения.

Итоговая конфигурация: 24 ядра, 256 ГБ ECC, NVMe-массив с полезной ёмкостью от 2 ТБ и сеть 10 Гбит/с. Для дисков можно использовать зеркало или RAID 10. Это пример нагрузки для строки «5–15 ВМ» в сводной таблице ниже.

Пример № 2. Интегратор с окружениями клиентов

У интегратора 60 ВМ: 30 лёгких, 25 средних и пять тяжёлых. Параметры каждой машины такие же, как в первом примере.

Требование к доступности: при отказе сервера клиентские ВМ должны перезапуститься на других узлах в течение нескольких минут. Рассчитываем кластер из трёх узлов по схеме N+1.

Процессоры. Лёгким ВМ нужно 15 физических ядер, средним — 50, тяжёлым — 40. Всего 105 ядер, с резервом 10% — примерно 116.

Диски. Виртуальным машинам нужно 7 450 ГБ. С запасом 30% получаем около 9,7 ТБ полезного пространства. Для Ceph с тремя копиями данных потребуется не менее 29,1 ТБ физической ёмкости.

Предварительно выбираем по два NVMe-накопителя на 6,4 ТБ в каждом узле. Всего это 38,4 ТБ физической ёмкости. Именно этот объём используем дальше для расчёта памяти хранилища.

Память. ВМ требуется 120 + 300 + 320 = 740 ГБ. Добавляем 12 ГБ для систем трёх узлов и 38,4 ГБ для Ceph. С запасом получаем:

(740 + 12 + 38,4) × 1,25 = 988 ГБ.

После отказа одного узла оставшиеся два должны обеспечивать примерно 116 ядер и 988 ГБ памяти. Значит, на каждый узел нужно не менее 58 ядер и 494 ГБ памяти.

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

• 64 физических ядра;
• 512 ГБ памяти ECC;
• два NVMe-накопителя по 6,4 ТБ для Ceph;
• два сетевых подключения по 25 Гбит/с с MC-LAG.

Это предварительная конфигурация. До запуска нужно проверить производительность хранилища, работу при отказе узла и фактическое время перезапуска ВМ.

Почему два более мощных сервера не равноценны трём

У двух серверов по 192 ядра и 768 ГБ памяти суммарно столько же памяти, сколько у трёх узлов по 512 ГБ, а ядер даже больше. Но после отказа одного сервера останется только 768 ГБ при расчётной потребности 988 ГБ.

Чтобы такая пара выдержала отказ, каждому серверу потребуется не менее 988 ГБ памяти. При схеме N+1 из двух узлов половину общей ёмкости нужно оставлять доступной на случай отказа. У трёх одинаковых узлов для этого достаточно трети.

Отдельно нужно учитывать устройство хранилища и кворума. В нашем примере выбраны три узла и Ceph с размещением трёх копий данных на разных серверах. При отказе одного узла хранилище продолжит работу с пониженной избыточностью.

Конфигурация сервера по числу и профилю виртуальных машин

Таблица поможет предварительно оценить ресурсы. Для смешанной нагрузки используем те же профили, что и в примерах: 50% лёгких ВМ, 40% средних и 10% тяжёлых. Если состав ваших машин отличается, пересчитайте ресурсы по методике выше.

Число ядер указано физических, ёмкость дисков — полезная, после зеркалирования или репликации. В строках с кластером процессор и память указаны на каждый узел.

Расчёт конфигурации выделенного сервера Yandex BareMetal:

Для одного хоста выбирайте серверную платформу на гипервизоре первого типа. Для кластера дополнительно нужны управление несколькими узлами, миграция и автоматический перезапуск ВМ при отказе. Поддержку Ceph, vSAN или другого хранилища проверяйте у выбранной платформы.

Ядра и память считайте вместе. Большое число ядер не поможет, если памяти хватает только части машин. Используйте расчёт из шага 5, учитывая резерв гипервизора и хранилища. Если все ВМ лёгкие, ресурсов потребуется заметно меньше, чем для смешанной нагрузки.

Кластер выбирают по требованиям к доступности. Он может понадобиться и для нескольких критичных ВМ. Чтобы перезапустить машину на другом узле, этому узлу должны быть доступны её данные. Для этого используют общее или распределённое хранилище либо подходящую схему репликации.

Крупные ВМ проверяйте отдельно. Например, для каждой СУБД с 16 vCPU и 128 ГБ памяти оцените возможность размещения в одном NUMA-узле. Общая сумма ресурсов всех ВМ такой проверки не заменяет.

Как выбрать платформу виртуализации

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

Как установить платформу на Yandex BareMetal

На выделенные серверы можно самостоятельно установить любую необходимую систему виртуализации. Некоторые их них доступны для подключения через Marketplace, например, образ Proxmox VE 9. При использовании MC-LAG группы агрегирования настраиваются автоматически. Кластер и хранилище Ceph затем создают средствами Proxmox VE.

ESXi и Windows Server с Hyper-V устанавливают из собственного ISO-образа через KVM-консоль. Она даёт удалённый доступ к экрану и клавиатуре физического сервера.

Для ESXi заранее продумайте дисковую схему. Он не создаёт программный RAID при установке и не поддерживает массивы встроенных контроллеров Fake RAID. Если нужен локальный RAID-массив, потребуется совместимый аппаратный контроллер, который можно предусмотреть в конфигурации по запросу. Другие варианты хранения — внешнее хранилище или vSAN.

Какие функции влияют на оборудование

• Живая миграция. Нужны совместимые процессоры и настройки гипервизора. Одинаковое поколение CPU упрощает подбор, но не является универсальным требованием. Для миграции крупных ВМ ориентируйтесь на сеть от 10 Гбит/с.
• Распределённое хранилище. Число узлов, диски и сеть выбирайте по требованиям конкретной системы. Для рассматриваемой схемы Ceph используем от трёх узлов и NVMe; у vSAN требования зависят от конфигурации.
• Проброс GPU в ВМ. Нужна поддержка IOMMU — Intel VT-d или AMD-Vi, — а также совместимые устройства, драйверы и гипервизор.

Если нужно сменить платформу

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

Конфигурации Yandex BareMetal для виртуализации

Yandex BareMetal — сервис аренды физических серверов. Все ресурсы машины доступны только вам: вы устанавливаете свой гипервизор, который работает напрямую с оборудованием. Каждый сервер подключён как минимум двумя сетевыми интерфейсами со скоростью 1, 10 или 25 Гбит/с. Подробнее — в статье «Bare metal: полный контроль и высокая производительность».

Класс сервера обозначают первые буквы в коде конфигурации: BA — универсальный, HA — высокочастотный, HM — с увеличенным объёмом памяти, SA — для хранения, LA — экономичный. Остальная часть кода описывает платформу, диски и сеть. Обозначения C1–C7 объединяют конфигурации с общей платформой и назначением.

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

Для 5–15 ВМ собственная конфигурация позволит точнее попасть в расчёт. Готовая C4 даст дополнительный запас, если он нужен для роста или других задач.

Для 15–40 ВМ проверьте, хватает ли 64 ядер выбранной C4. Если нет, рассмотрите C1. BA-i523-NH-2X25G можно использовать для нагрузки с активной записью или как узел кластера Ceph.

В строках «40–100 ВМ» и «Более 100 ВМ» указаны варианты отдельного узла кластера. Число серверов и объём памяти на каждом определяйте по расчёту N+1.

Наличие конфигураций меняется. Стоимость зависит от срока аренды — рассчитайте её в калькуляторе цен.

Как заказать сервер

Выбор зависит от того, насколько точно готовые варианты подходят под вашу нагрузку:

• Готовая конфигурация. Сервер можно получить за несколько минут, если он есть в пуле. Срок аренды — день, один, три или шесть месяцев либо год.
• Своя конфигурация. Вы выбираете процессор, память, диски, сетевые карты и резервирование питания из доступных вариантов. Сборка занимает до четырёх календарных дней. Срок аренды — месяц, полгода или год.
• Конфигурация по запросу. Подойдёт, если нужны GPU, RAID-контроллеры или дисковые полки вместимостью до 24 NVMe. Условия согласовываются индивидуально.

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

Порядок заказа описан в пошаговой инструкции. Цена фиксируется на весь срок аренды.

Лицензии и настройки сети

Лицензии гипервизора и гостевых ОС вы обеспечиваете самостоятельно.

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

Максимальный MTU в приватной сети — 8910 байт. Увеличенный MTU можно использовать для трафика Ceph и миграции, согласовав настройки на всём пути передачи данных. Канал до облачных сетей Yandex Virtual Private Cloud по умолчанию ограничен 10 Гбит/с на пользователя.

Подключение к облаку и резервное копирование

Yandex Cloud Interconnect позволяет связать выделенные серверы с облачными ресурсами и вашей серверной. Например, «КИТ Финанс» использовал Yandex BareMetal и облачные ВМ для горячего резерва торговых систем.

Для резервного копирования физических серверов доступен Yandex Cloud Backup. Он поддерживает серверы с Ubuntu^®, Debian^™ 11 и CentOS 7.

В аренду включены входящий и исходящий трафик, а также публичное подключение со скоростью 1 Гбит/с. Трафик до Yandex Object Storage и через Cloud Interconnect также не тарифицируется. Стоимость хранения и других используемых сервисов рассчитывается отдельно.

Платформа виртуализации с сопровождением

Если команда не планирует самостоятельно сопровождать платформу, рассмотрите BareMetal Extend: Virtualization.

Это коммерческая платформа виртуализации с распределённым хранилищем на кластере Yandex BareMetal. Мы вместе с K2 Cloud проектируем, разворачиваем и поддерживаем её.

Функциональность находится на стадии Preview, доступ предоставляется по заявке. Подробнее — в анонсе Yandex BareMetal Extend.

Выделенный сервер, облачные ВМ или своё оборудование

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

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

Критерии выбора арендованного оборудования мы разбирали в статье «Как выбрать вычислительные мощности для бизнес- и IT-задач».

Пример использования выделенных серверов — кейс студии «Наши игры». По данным кейса, компания перенесла игру на 53 сервера Yandex BareMetal и снизила расходы на обслуживание инфраструктуры на 15%.

Частые ошибки при выборе сервера для виртуализации

• Переподписывать память так же, как vCPU. Если в пиковый час всем ВМ понадобится выделенная память, её может не хватить. Подкачка на диск замедлит работу.
• Не рассчитать сеть и лимит MAC-адресов. Это две отдельные проверки: хватает ли пропускной способности и можно ли подключить нужное число ВМ через мост.
• Выбрать RAID 5 из HDD без проверки нагрузки. Массив может не справиться со случайными обращениями десятков ВМ. При восстановлении после отказа диска производительность дополнительно снижается.
• Не подготовиться к отказу хоста. Заранее определите, где и как восстановятся ВМ. Резервные копии храните вне рабочего сервера.
• Выделять лишние vCPU. Если приложение использует четыре потока, 16 vCPU могут не дать ускорения, а при конкуренции за ресурсы — увеличить задержки. Добавляйте vCPU по результатам измерений.
• Хранить снапшоты без срока удаления. По мере изменений данных они занимают всё больше места и могут влиять на производительность. Снапшоты на рабочем массиве не заменяют резервные копии.
• Считать лицензии после выбора оборудования. Проверьте правила для конкретных редакций Windows Server, vSphere и гостевых ОС. Большое число физических ядер может заметно увеличить расходы.
• Настраивать bond без согласования сетевой схемы. Режим объединения интерфейсов, настройки портов коммутаторов и VLAN должны быть совместимы.

Чек-лист перед заказом сервера

• Какие ВМ переезжают и сколько ресурсов нужно каждой?
• Сколько физических ядер требуется с учётом переподписки и резерва?
• Помещаются ли процессорные ресурсы и память каждой крупной ВМ в один NUMA-узел?
• Хватает ли памяти ECC для ВМ, гипервизора, хранилища и запаса на рост?
• Достаточно ли ёмкости и IOPS дискового массива с учётом снапшотов, роста и восстановления после отказа диска?
• Хватает ли пропускной способности сети? Проверены ли лимиты MAC-адресов и доступность нужных VLAN?
• Допустим ли простой одного хоста? Если нужен кластер, хватит ли ресурсов после отказа узла?
• Какие лицензии уже есть и сколько будут стоить недостающие?
• Где хранятся резервные копии и проверено ли время восстановления ВМ?

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

С чего начать

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