Как выбрать сервер для виртуализации: что учитывать в конфигурации

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

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

В этой статье:

• С чего начать расчет ресурсов
• Как выбрать процессор и память
• Локальные накопители или СХД
• Один сервер или несколько
• Что учитывать в сети
• Как гипервизор влияет на конфигурацию
• Примеры конфигураций сервера для виртуализации
• 5 ошибок при выборе сервера для виртуализации
• Вопросы и ответы

С чего начать расчет ресурсов

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

По каждой виртуальной машине нужно зафиксировать:

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

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

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

Важно!

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

Как выбрать процессор и память

После расчета ресурсов можно проверить, какая аппаратная конфигурация соответствует полученным требованиям.

Число ядер или производительность одного ядра

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

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

Один или два процессора

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

В двухпроцессорных серверах часть каналов и разъемов ОЗУ связана с конкретным сокетом. Поэтому перед подбором модулей нужно проверить схему установки для выбранной платформы и процессоров.

Как подобрать ОЗУ

На этом этапе уже не нужно повторно считать требуемый объем. Задача другая: проверить, поддерживает ли его выбранная платформа и как набрать нужную емкость модулями.

Важно учесть:

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

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

Локальные накопители или СХД

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

Локальные накопители

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

При подборе накопителей учитывают:

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

Тип интерфейса сам по себе не определяет производительность. Нужно учитывать характеристики конкретных накопителей, контроллера и выбранной схемы RAID.

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

СХД

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

При выборе проверяют:

• протокол подключения;
• производительность;
• полезную емкость;
• резервирование контроллеров и путей доступа;
• совместимость с выбранной платформой виртуализации;
• возможности увеличения объема.

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

СХД в наличии на складе в Москве

Показать варианты →

Когда имеет смысл несколько серверов

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

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

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

Как рассчитать запас

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

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

Когда нужен кластер

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

— Редакция CRABBIT

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

Telegram-канал CRABBIT

В Telegram короче, живее и по делу

Серверы, СХД и информационная безопасность: короткие разборы, новости и полезные материалы для работы.

Подписаться на канал →

Серверы СХД ИБ

Что учитывать в сети

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

Как оценить нагрузку на сеть

Сначала определяют основные потоки данных:

• трафик приложений и пользователей;
• обмен с СХД;
• перенос ВМ между узлами;
• резервное копирование;
• служебный обмен.

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

Поэтому пропускную способность выбирают по пиковому совместному обмену, а не по среднему значению.

Когда разделять трафик

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

Разделение особенно полезно там, где большие объемы данных передаются между узлами или на СХД и не должны мешать работе приложений.

Нужны ли резервные подключения

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

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

Как гипервизор влияет на конфигурацию

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

Перенос виртуальных машин между узлами

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

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

Крупные ВМ и NUMA

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

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

Поэтому для крупных ВМ важно смотреть не только на общий объем ОЗУ и число ядер, но и на то, как они распределены между процессорами.

Прямой доступ к устройствам

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

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

Лицензирование

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

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

Примеры конфигураций сервера для виртуализации

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

Проект 1. Перенос внутренних систем на один физический сервер

Задача. Компания переводит на виртуальные машины 1С, СУБД, контроллер домена, файловые службы и несколько внутренних приложений. Все системы будут работать на одном физическом узле. Для виртуальных дисков используется локальное хранилище.

Решение:

• Dell PowerEdge R760;
• 2 x Intel Xeon Gold 6548Y+;
• 256 ГБ DDR5;
• BOSS-N1 с 2 x M.2 NVMe 960 ГБ;
• 4 x SSD SAS 3,84 ТБ;
• PERC H965i;
• 2 x блока питания 1400 Вт.

BOSS-N1 выделен под загрузочную среду, основные виртуальные диски размещаются на четырех SSD SAS. Два процессора рассчитаны на одновременную работу нескольких корпоративных систем. В конфигурации установлено 256 ГБ ОЗУ, при дальнейшем росте объем можно увеличить.

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

Проект 2. Виртуальная среда с большим объемом ОЗУ и локального хранения

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

Решение:

• Dell PowerEdge R760;
• 2 x Intel Xeon Gold 6542Y;
• 512 ГБ DDR5;
• 2 x SSD SAS 1,92 ТБ;
• 4 x SSD SAS 3,84 ТБ;
• PERC H965i;
• дисковая корзина на 16 SAS/SATA и 8 NVMe;
• 2 x блока питания 1400 Вт.

512 ГБ ОЗУ рассчитаны на более требовательный набор ВМ. Дисковая корзина оставляет пространство для добавления накопителей при росте объема данных. Поддержка SAS/SATA и NVMe дает возможность менять состав дисковой подсистемы без перехода на другое шасси.

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

Проект CRABBIT. Высокопроизводительная среда виртуализации

Задача. Заказчику требовался сервер с большим количеством вычислительных ресурсов, емким NVMe-хранилищем и сетью 100 Гбит/с. Техническое задание и спецификация были подготовлены заранее.

Решение:

• Dell PowerEdge R7625;
• 2 x AMD EPYC 9554 по 64 ядра;
• 768 ГБ DDR5;
• 8 x NVMe SSD Samsung PM1743 по 7,68 ТБ;
• Mellanox ConnectX-6 DX 100 GbE;
• iDRAC Enterprise;
• 2 x блока питания 1800 Вт.

В одной системе заказчик получил 128 физических ядер, 768 ГБ ОЗУ и 61,44 ТБ установленной емкости NVMe. CRABBIT поставил компоненты, собрал сервер и провел нагрузочное тестирование. Подбор архитектуры с нуля в проект не входил: конфигурация была определена заказчиком заранее.

Полный разбор проекта: Виртуализация под ключ: когда точное ТЗ экономит месяцы работы.

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

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

1. Лишние виртуальные процессоры

Большое число vCPU само по себе не ускоряет виртуальную машину. При высокой загрузке физического узла гипервизору приходится находить свободные вычислительные ресурсы для всех активных ВМ.

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

2. Рост виртуальных дисков

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

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

3. Долгое хранение снимков

Снимок фиксирует состояние ВМ в определенный момент и сохраняет последующие изменения отдельно. По мере работы объем дополнительных данных растет.

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

4. Одновременный запуск ВМ

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

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

5. Конкуренция за хранилище

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

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

Вопросы и ответы