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

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

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

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

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

Гиперконвергенция или классика?

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

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

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

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

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

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

KVM или другой гипервизор?

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

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

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

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

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

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

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

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

С конвертером или без?

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

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

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

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

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

Автоматическая миграция и восстановление в резервном ЦОД

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

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

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

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

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

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

Другие варианты расширения экосистемы вокруг виртуализации - это подключение какого-то средства резервного копирования в рамках продукта виртуализации или за его пределами или подключение VDI того же вендора.

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

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

Встроенный или внешний бэкап?

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

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

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

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

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

Аппаратные ресурсы

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

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

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

ФСТЭК или не ФСТЭК?

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

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

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

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

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

Заключение

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