Ключевые критерии выбора системы виртуализации

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

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

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

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

Гиперконвергентная система виртуализации или классическая?
С каким гипервизором выбрать систему виртуализации?
Гипервизоры российских систем виртуализации
Насколько важна автоматическая конвертация виртуальных машин для их миграции на другую платформу?
Критична ли функция автоматической миграции и восстановления в резервном ЦОД в случае аварии?
Экосистема решений вокруг виртуализации
Встроенный vs внешний бэкап системы виртуализации
Требования к аппаратным ресурсам при выборе системы виртуализации
Нужен ли сертификат ФСТЭК на систему виртуализации?
Заключение

Гиперконвергентная система

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

Особенности

Использование дисков непосредственно в серверах, на которых работает платформа виртуализации, позволяет значительно упростить развертывание и управление инфраструктурой.
Достаточно всего трех серверов без СХД, увеличение мощностей происходит путем добавления новых узлов.
Использование гиперконвергентных систем может значительно снизить затраты на закупку и обслуживание «железа».
Гиперконвергентные системы обычно обладают возможностью автоматического балансирования нагрузки и распределения ресурсов, что повышает надежность и производительность работы приложений.
Можно приобрести в составе программно-аппаратного комплекса у одного поставщика (сервер с предустановленной системой виртуализации) или по отдельности – серверы и гиперконвергентную виртуализацию от разных поставщиков, создавая собственное решение на основе различных компонентов.

Классическая система

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

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

Особенности:

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

Многие уже привыкли к классической инфраструктуре и считают её лучшим вариантом выбора.

Одной из причин, почему заказчики не хотят или не могут приобретать СХД является то, что в настоящее время* на российском рынке отсутствуют реестровые системы хранения данных (СХД) с технологией метрокластера, позволяющей виртуальным машинам, размещенным в различных центрах обработки данных (ЦОД), действовать так, словно они находятся в одном локальном кластере. В случае выхода одного ЦОДа из строя, все данные сохраняются в другом ЦОДе и автоматически происходит поднятие сервисов. Для обеспечения данной функциональности виртуальным машинам необходим доступ к одному и тому же хранилищу на всех узлах. Ранее подобный функционал был доступен в западных СХД, приобрести которые сейчас становится практически невозможно. Заказчикам, чьи инфраструктуры базировались на дорогостоящих СХД, остается только ждать своего часа. Строить новые такие же системы в данный момент не получится.

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

С каким гипервизором выбрать систему виртуализации?

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

KVM (Kernel-based Virtual Machine) является популярным решением с открытым исходным кодом, обладающим хорошей производительностью. Однако многие ругают его за более низкую производительность в сравнении с VMware ESXi и невозможностью одновременно поднимать работу большого количества виртуальных машин.

Гипервизоры российских систем виртуализации:

KVM
Bhyve
Xen

Помимо KVM, на российском рынке доступны и другие варианты гипервизоров систем виртуализации – на основе Xen и FreeBSD bhyve.

Отличия архитектуры этих гипервизоров от KVM:

в них используются другие модули,
распределение процессорных инструкций происходит по-другому,
в некоторых случаях, их использование позволяет получить прирост производительности, которую не дает KVM.

Преимущества KVM:

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

KVM является самым первым слоем, который участвует в виртуализации. У гипервизора всегда есть надстройка, которая осуществляет управление им, при этом сделать надстройку над KVM гораздо проще, чем над bhyve FreeBSD или Xen. Соответственно, российские разработчики либо выбирают уже готовые, opensource-продукты, дорабатывают и меняют их, либо пишут свои системы, которые работают с этим KVM.

Вендор

Space

BASIS

Флант

Средство управления виртуализацией

Собственное решение вендора

OpenNebula

oVirt

Parallels

OpenStack

Собственное решение вендора

Гипервизор

KVM

bhyve

Xen

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

Насколько важна автоматическая конвертация виртуальных машин для их миграции на другую платформу?

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

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

Возможные сложности настройки

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

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

Как это происходит

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

Именно в этот момент подключаются все необходимые драйверы устройств и выдаются корректные сетевые параметры подключения к виртуальной машине.

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

А если автоматического конвертера нет?

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

Минусы:

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

Поэтому мы рекомендуем обращаться в ГК Softline, которая обеспечит поддержку и управление процессом в режиме "единого окна".

Критична ли функция автоматической миграции и восстановления в резервном ЦОД в случае аварии?

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

N.B.: Речь идет именно об автоматической миграции виртуальных машин в другой ЦОД на случай выхода из строя основного ЦОДа. При этом под ЦОДом мы подразумеваем не только отдельно стоящее здание, которое используется под заказчика. ЦОДом может быть просто серверная комната в одном здании, а второй ЦОД может располагаться в другом здании на случай выхода из строя первого.

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

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

Экосистема решений вокруг виртуализации

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

Другие варианты расширения экосистемы вокруг виртуализации

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

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

Встроенный vs внешний бэкап системы виртуализации

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

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

Нюансы агентского и безагентского режима бэкапа

Важно учитывать, что платформы виртуализации могут не поддерживать внешнюю систему бэкапа в безагентском режиме, который предполагает работу резервного копирования на уровне гипервизора. В свою очередь, агентский режим подразумевает установку агента внешнего резервного копирования на каждую виртуальную машину. Основное различие заключается в том, что безагентский режим работает более эффективно, так как требует значительно меньше ресурсов и администрирования. Это значит, что при 10-20 виртуальных машинах можно легко использовать агентов. Однако при наличии 100 или 200 машин этот способ вряд ли будет эффективен.

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

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

Требования к аппаратным ресурсам при выборе системы виртуализации

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

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

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

Нужен ли сертификат ФСТЭК на систему виртуализации?

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

В настоящее время большинство российских вендоров стремятся получить сертификацию ФСТЭК. Однако важно понимать, что процесс сертификации ФСТЭК представляет собой многоэтапное мероприятие.

Разработчик может получить эту сертификацию одним из двух путей:

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

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

Заключение

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

*Данные актуальны на 29 мая 2024 г.

Ключевые критерии выбора системы виртуализации