Представленный ниже текст – это попытка систематизировать подход к ПО серверной виртуализации как в целом, так и в части отечественных продуктов. Я как сотрудник «ЛАНИТ-Интеграции» постарался подойти к вопросу не с точки зрения количественных и качественных показателей (как когда-то сравнивали циферки максимумов VMware vSphere и Microsoft  Hyper-V), а со стороны потребностей заказчика. Наверняка многие вопросы, которые будут здесь затронуты, вам знакомы. Может, вы уже давно продвинулись дальше в своих изысканиях. Что ж, в таком случае это лишний повод для вас поделиться своими мыслями с сообществом.

Предисловие: определение и поиск критериев для сортировки продуктов

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

Итак, какие же были основные зарубежные коммерческие решения на рынке? Все мы о них слышали, многие с ними работали: VMware vSphere, Microsoft Hyper-V, Red Hat Virtualization, Citrix XenServer. Причём последний в большинстве случаев использовали лишь те, кто старался сэкономить при внедрении решений VDI на базе Citrix Virtual Apps and Desktops (CVAD), дабы не переплачивать лишний раз за лицензии виртуализации от других вендоров.

Вы сейчас спросите, а как же решения open source? Большинство из них используют в своей основе стэк QEMU/KVM. Отличаются они в основном лишь системой управления платформой виртуализации (далее СУПВ). В основном придут в голову решения на базе oVirt, OpenNebula, Proxmox и, конечно же, OpenStack – их использовали и используют, но в основном в двух случаях:

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

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

То есть мы понимаем, что использование open source продуктов в качестве инфраструктурных сервисов без квалифицированной поддержки L2-L3 – это, в первую очередь, риски для заказчика – как финансовые, так и репутационные.

Причины, по которым VMware занимал своё первое почётное место среди компаний-заказчиков всем известны:

• наиболее широко представленный спектр функциональных возможностей;

• оперативный выпуск критических обновлений;

• высокий уровень квалификации технической поддержки и оперативное реагирование в случае внештатных ситуаций;

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

• наиболее широко представленное комьюнити высококвалифицированных специалистов в своей области.

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

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

• недостаточный или не всегда корректно работающий даже базовый функционал;

• минимальная автоматизация или её отсутствие при развертывании;

• непривычная концепция работы с интерфейсом / неудобный дизайн / ограниченный функционал веб-интерфейса СУПВ;

• отсутствие какой-либо документации или её наличие только для базовых операций;

• проблемы совместимости ПО с серверным оборудованием и некоторыми типами систем хранения;

• уровень поддержки – в основном была возможность оказания технической поддержки только в рабочее время (8x5).

Если до этого рынок складывался в основном из проприетарных решений (VMware vSphere/Microsoft Hyper-V), и только часть из них базировалась на открытом исходном коде, то отечественный рынок стал разрабатываться исключительно на базе open source продуктов. Причина, к сожалению, банальна – недостаток основных ресурсов (времени и средств).

Давайте посмотрим на отечественные продукты серверной виртуализации, но сначала распределим их по типам. Несмотря на то, что львиную долю отечественных гипервизоров составляют гипервизоры на базе стэка QEMU/KVM, на рынке также присутствуют интересные решения на базе bhyve и Xen. Но мы предлагаем отталкиваться не от типа гипервизора, а от СУПВ, так как большинству заказчиков не особо важно, что лежит в прослойке гипервизора. В любом случае это будет Linux/Unix-подобная система.

Большая часть СУПВ на отечественном рынке строится на базе open source решений, однако есть и те, кто разработал свои собственные СУПВ. Естественно, большинство из них используют идентичные наборы библиотек и API, но эти решения достойны называться уникальными. Для классификации будем называть их проприетарными.

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

• oVirt-подобные системы – zVirt, РЕД Виртуализация, ROSA VIRTUALIZATION, HOSTVM;

• OpenNebula – ПК СВ “Брест”, SharxBase, Альт Сервер Виртуализация (облачный вариант реализации), Горизонт-ВС;

• Proxmox – Альт Сервер Виртуализация (классический вариант реализации);

• OpenStack – РУСТЭК, Кибер Инфраструктура, KeyStack, VK Private Cloud, AccentOS;

• XCP-ng-подобные – решения на базе гипервизора Xen: Numa vServer, V-Софт.

Здесь допущу небольшой комментарий. Возможно, немного необъективно причислять к СУПВ серверной виртуализации ещё и облачные решения, но в целом решения на базе OpenStack, как собственно и OpenNebula, именно на этот функционал и заточены. Поэтому прошу не рубить голову с плеч – довольно сложно классифицировать некоторые продукты с широким спектром возможностей.

Осталось перечислить продукты с проприетарными/самописными СУПВ:

• SpaceVM (продолжение разработки платформы ECP Veil);

• vStack (на базе гипервизора bhyve);

• VMmanager (альтернативное решение от Астры в дополнение к ПК СВ Брест, но для менее масштабных развертываний);

• АЭРОДИСК vAIR;

• Базис Dynamix, Базис Dynamix Enterprise; *

• Р-Виртуализация (ведёт своё начало от Parallels/Virtuozzo);

• Скала^Р МВ (имеет собственную СУПВ, при этом в качестве гипервизора применяется решение от Росплатформы – Р-Виртуализация). *

* Стоит немного отвлечься, чтобы ещё больше запутать читателя, компания ООО «Базис» – это результат  объединения компаний Ростелеком (продуктовая линейка Tionix), Rubytech (продуктовая линейка Скала^Р) и Yadro (в лице дочерней компании Digital Energy). Продуктовые решения группы этих компаний на стыке технологий могут заимствовать друг у друга часть компонентов, не забывая о тех внешних решениях, которые  использовали ранее. Например, решение для VDI – Скала^Р МВ.ВРМ на текущий момент строится на базе компонентов:

• Базис vControl (ранее Скала^Р Управление);

• Базис WorkPlace (ранее Скала^Р ВРМ);

• Р-Виртуализация;

• Р-Хранилище. 

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

У кого-то при упоминании некоторых продуктов из списка выше в воспоминаниях промелькнут их современные и не очень интерфейсы управления. У кого-то их фирменные цвета и стили оформления, а кто-то вспомнит уникальный, но не всегда корректно отрабатывающий функционал или попытки найти нужную информацию в вендорской документации. Наверняка всё это было. Мы оценивали эти продукты как объективно, так и субъективно (в силу своего «чувства прекрасного»). Что-то искали и что-то находили, ставили виртуальные «плюсы» или «минусы» тому или иному продукту. Что же мы искали?

Базовый набор функциональных требований к ПО серверной виртуализации

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

• Качественная и оперативная линия технической поддержки (объективности ради, она не всегда бывает качественной и оперативной, но это уже частные случаи).

• Комплект документации для возможности настройки базовых функций.

А теперь про те самые базовые функции.

• Наличие современного GUI с использованием HTML5 (и обязательно на русском языке, так как это довольно частое требование технического задания) и CLI для возможности настройки базовых функций.

• HA (High Availability) – обязательный функционал любого кластера виртуализации, есть в наличии во всех продуктах, но у него есть один нюанс, к которому мы привыкли и считаем само собой разумеющимся. Если в привычных нам зарубежных системах виртуализации Hyper-V, VMware и XenServer этот функционал работает всегда, вне зависимости от того, доступна ли СУПВ (так как реализуется агентом на самом гипервизоре), то во всех отечественных решениях (по крайней мере из тех, что нам встречались), этот функционал перестаёт работать, если СУПВ по той или иной причине не функционирует.

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

• Балансировка нагрузки внутри кластера (DRS) – конечно, есть не у всех, но таки быть обязан.

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

• “Файловые системы” (рискнём назвать их кластерными), доступные всем хостам кластера с различными реализациями блокировок для эксклюзивного доступа хоста к файлам виртуальных машин. Здесь кто во что горазд: GlusterFS, GFS2, OCFS2, CephFS, NFS, с использованием LVM-томов, а также различные реализации проприетарных кластерных хранилищ на базе SDS. 

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

• Поддержка основных блочных и файловых протоколов сети хранения (FC, iSCSI, NFS).

• Поддержка тонких дисков ВМ (Thin provisioning).

• Возможность использования шаблонов ВМ.

• Возможность проброса RDM дисков и внешних устройств (PCI/USB), подключенных к гипервизору, напрямую в ВМ.

• Возможность управлять виртуальными сетями на базе VLAN (стандарта IEEE 802.1Q) – в идеале все хотят видеть распределенный коммутатор, но в большинстве случаев этот функционал реализован на базе мостов или виртуального коммутатора на базе Open vSwitch с элементами автоматизации. Neutron, который используется в OpenStack решениях, в большинстве случаев предоставит куда более богатый функционал, но какой ценой? (Об этом поговорим чуть позже.)

• Наличие ролевой модели хотя бы в минимальном объеме (администратор, пользователь ВМ, пользователь с правами только на чтение, ну или что-то подобное).

• Ведение аудита за действиями системы и пользователей.

Возможно, часть из описанного функционала где-то реализована в минимальном объёме, где-то работает не всегда корректно. Например, такой функционал, как DRS, который работает не всегда так, как мы привыкли видеть в сравнении с VMware, поддержка тонких дисков ВМ по какой-то причине доступна далеко не во всех продуктах и т. д. Скажем так, нюансы присутствуют даже в тех случаях, когда речь идёт об условно базовых потребностях. Чаще всего вендоры будут утверждать, что чуть ли не весь этот функционал присутствует, оставив за скобками определённые тонкости в его работе, поэтому здесь может быть только одна рекомендация – «доверяй, но проверяй», каждый рассматриваемый продукт необходимо тщательно тестировать, в том числе и на стрессо- и отказоустойчивость.

Расширенный набор функциональных требований к ПО серверной виртуализации

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

• CLI с возможностью тонкой настройки. Объективно довольно важный элемент, особенно когда речь идёт и траблшутинге и дебаге. Если решения на базе oVirt и OpenNebula имеют определенный функционал управления через CLI в части системы управления и никак не касаются самого гипервизора (что уже собственно совсем неплохо), то, например, решение SpaceVM имеет собственный интерпретатор команд как для СУПВ, так и для каждого гипервизора в отдельности, аналогично тому, что нам доступно в привычных продуктах от VMware.

• Расширенный функционал на основе гранулярной ролевой модели с возможностью создания кастомных ролей и тонкой настройки для каждого объекта СУПВ. Все хотят видеть то, что есть сейчас в VMware, но пока, с нашей точки зрения, явного лидера здесь нет. oVirt-системы имеют в своей базе значительный функционал, но можно сказать, что всем есть к чему стремиться.

• Встроенный функционал резервного копирования (безагентный). Довольно часто в техническом задании прописывается подобный функционал. Во многих решениях он есть, но, с нашей точки зрения, не стоит рассматривать его как средство резервного копирования для промышленных систем. Он не сможет обеспечить необходимый уровень SLA и никак не гарантирует консистентность данных. Мы бы рекомендовали использовать встроенные средства СРК только для тестовых и некритичных сред. Для промышленных сред всё же лучше использовать специализированное ПО СРК. Благо на российском рынке такие решения имеются, например, Кибер Бэкап и RuBackup. 

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

  • Основная часть решений на базе oVirt в своей базе предполагает функционирование СУПВ в единственном числе (в силу самой реализации). Однако вендорами ведётся работа над тем, чтобы задублировать такой сервис. Например, в zVirt в обновлении 4.2 был представлен такой функционал. Правда, на момент написания этой статьи, пока только в экспериментальном режиме (для тестовых сред). Что ж, будем ждать реализации такого решения для прода.

  • Решения на базе OpenNebula, например, решение от Астра – ПК СВ «Брест», имеют механизмы для обеспечения отказоустойчивости СУПВ путём развертывания нечетного числа узлов управления (или как их называет Астра — Front-end), где используется алгоритм RAFT с плавающим IP-адресом. При этом каждый узел имеет свой экземпляр БД, который реплицируется между узлами такого кластера.

Здесь стоит отметить, что в некоторых решениях на базе OpenNebula СУПВ реализована в виде классических ВМ, а где-то в виде контейнеров, и здесь уже всё может быть не так однозначно по части катастрофоустойчивости.

• Некоторые проприетарные решения имеют свою реализацию отказоустойчивости СУПВ. Например, в SpaceVM СУПВ может работать как в виде сервиса на одном или двух хостах кластера (или разных кластеров, если решение предполагает некоторую территориальную распределенность), либо в виде сервиса, но внутри виртуальных машин. При этом функционирует такое решение в режиме active/passive, а БД каждого из таких узлов реплицируется внутренними средствами. На третьем узле (или локации) возможно разместить ВМ свидетеля для автоматического переключения ролей СУПВ в случае отказа активного узла. Ключевым отличием решения SpaceVM от решений на базе OpenNebula является то, что больше, чем на две локации (третья площадка всё-таки будет только со свидетелем, и без СУПВ) «растянуть» одну СУПВ не получится.

• Обеспечение катастрофоустойчивости ВМ (он же DR). Объективности ради, подобный функционал присутствовал в двух исполнениях в привычной нам VMware – это vSphere Replication, который не стоил каких-то дополнительных денег, но и не предполагал никакой автоматизации. За автоматизацию отвечал уже Site Recovery Manager (SRM) и стоил отдельных денег, но зато предлагал интеграцию с СХД (за счёт Array Integration API, или VAAI) и соответственно позволял реплицировать не только каждую конкретную ВМ, а несколько ВМ, объединенных в консистентную (по времени) группу. Это позволяло обеспечить целостность группы сервисов, например, группу приложений и баз данных. Тот же функционал предоставляли и решения от Veeam и Zerto. 

Консистентность данных, например, в БД, этим методом обеспечить нельзя с уверенностью на 100% – какие-то данные могли не успеть попасть в базу и остаться только в журнале транзакций, и тогда  придётся  немного поработать руками. Но никто и не говорил, что будет легко. 

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

• Во-первых, стоит вспомнить о том, что на российском рынке есть свои решения как для DR, так и для миграции между системами виртуализации (и облаком). Это, как минимум, ПО от MIND Software – MIND Guard и ПО от Хайстекс –  Хайстекс Акура. Мы не будем сейчас углубляться в методологию репликации и различия этих решений, скажем лишь о том, что они выполняют свои задачи, и это главное. Если для большинства решений по виртуализации просто можно отдельно купить MIND Guard и Хайстекс Акура, то, например, в zVirt такое ПО встроено, начиная с версии 4.1 и, так сказать, «вписано» в СУПВ. При этом обязательным условием для zVirt здесь является то, что ВМ должны реплицироваться между двумя разными экземплярами СУПВ.

• В противовес решению по репликации ВМ в zVirt можно поставить функционал репликации ВМ, реализованный в SpaceVM в рамках собственной СУПВ. Но здесь наоборот репликация осуществляется исключительно в рамках одной СУПВ, пусть и, возможно, распределенной между двумя площадками.

• Также стоит отметить гиперконвергентные решения на российском рынке, которые ввиду собственной реализации программно-определяемой системы хранения, могут обеспечить резервирование целой площадки путём репликации данных на уровне самой СХД (программно-определяемой). В этом случае можно упомянуть такие решения, как Sharx Base, АЭРОДИСК vAIR, Скала-Р и Р-Виртуализация.

• Сети – крайне интересная и широкая для обсуждения тема. Многие, если не все, вендоры ПО серверной виртуализации стараются расширить функционал своих решений в части сетевой составляющей, пытаясь вобрать в себя хотя бы часть инструментов, которые ранее мы видели в NSX от VMware. Хотя даже базовый функционал распределенного коммутатора, который мы привыкли видеть в VMware, реализован далеко не у всех в том же объеме.
  Зачем же нужны все эти программные маршрутизаторы, наложенные сети, правила микросегментации трафика ВМ и вот это вот всё? В какой-то момент у администраторов виртуализации возникла потребность в том, чтобы иметь возможность управлять сетью и базовыми механизмами сетевой безопасности, не обращаясь к администраторам ЛВС. Эту тенденцию поддержали (хотя правильным будет даже сказать возглавили) ряд вендоров, вроде VMware и Cisco, которые предложили рынку свои решения: VMware NSX и Cisco ACI. Мы в свою очередь остались без всего этого. Российские вендоры ЛВС пока не могут похвастаться чем-то подобным. В сегодняшних же реалиях, с нашей точки зрения, крайне малая часть заказчиков действительно пользуется функционалом, который продолжает появляется в российских платформах виртуализации в части сети, и активно делегируют «ответственность» в свои отделы, отвечающие за ЛВС. Поэтому со своей стороны можем сказать так – хорошо, что развитие со стороны виртуализации идёт в этом направлении, но пока, к сожалению, оно мало востребовано. Думаю, необходимо какое-то время, чтобы накопилась критическая масса и наступил паритет спроса и предложения в этой области.

• Возможность управления конкурентными СУПВ или гипервизорами других вендоров.

• Яркими представителями когорты таких решений являются решения на базе OpenStack – могут управлять большим спектром различных гипервизоров и даже СУПВ:

• реализации стэка QEMU/KVM и LXC на базе практической любой ОС Linux;

• VMware vCenter (vSphere);

• Microsoft Hyper-V;

• Xen и Citrix XenServer;

• Virtuozzo.

• Решения на базе OpenNebula также имеют возможности управления такими системами, как:

• реализации стэка QEMU/KVM и LXC на базе практической любой ОС Linux;

• VMware vCenter (vSphere).

• Из проприетарных СУПВ, как минимум, Скала-Р предполагает возможность интеграции/управления с платформами виртуализации на базе:

• VMware vCenter (vSphere);

• OpenStack.

• Наличие сертификата ФСТЭК. Важный фактор при выборе решения для государственных учреждений. К сожалению, чуть ли не все решения, представленные на нашем рынке и имеющие сертификат ФСТЭК, отстают от актуальных версий как минимум на год, а ввиду активной разработки и доработки решений это может предполагать крайне большой объём полезного и нужного функционала. Здесь остаётся только вам выбирать, использовать решение, сертифицированное ФСТЭК, или использовать актуальную версию продукта, а требования регулятора закрывать наложенными средствами, вроде vGate или Dallas Lock. В списке сертифицированных решений на данный момент присутствуют чуть ли не все решения на базе oVirt (zVirt, РЕД Виртуализация, ROSA Virtualization) и OpenNebula (ПК СВ “Брест”, SharxBase, Альт Сервер Виртуализация, Горизонт-ВС), Numa vServer, а также Базис Dynamix в комплекте с Basis Virtual Security.

User friendly интерфейс

Последний в списке, но далеко не последний по значимости критерий – User friendly интерфейс. Окунёмся немного в субъективизм. Это ведь на самом деле важный критерий – удобство использования.

В нашем опыте демонстрации различных российский решений заказчикам мы сталкивались с разными мнениями: кто-то смотрел исключительно на функционал, а кто-то уделял внимание удобству интерфейса, его логичной (или не очень) структуре. Кто-то искал сходства и аналогии с привычными ему системами виртуализации. Могу сказать так – нашим вендорам ПО серверной виртуализации есть к чему стремиться.

Если же говорить про автора, то, как вы заметили, для меня эталоном в части функциональной составляющей серверной виртуализации является VMware vSphere/vCenter, но с точки зрения интерфейса управления я бы не назвал его идеальным. С точки зрения интерфейса, хоть и в смежной системе, для меня всегда эталоном был и есть интерфейс управления Cisco UCS. 

Как же я был влюблён в самом начале своей профессиональной карьеры в это многообразие настроек, политик, шаблонов, строгие разграничения настроек серверов, SAN, LAN и т.д. На каждый чих была своя политика или своя настройка в соответствующем разделе. Когда я смотрю на интерфейс СУПВ на базе oVirt, то вижу что-то похожее на VMware, но в немного другой обложке. Когда я вижу интерфейс решений на базе OpenNebula, он кажется мне таким же скромным, как функционал Hyper-V Manager, хоть в шаблонах дисков есть знакомое и любимое слово «шаблон», но я каждый раз задаю себе вопрос, а зачем диску нужен шаблон, чтобы его создать (ну правда, зачем?). Понятно, что это всё отсылка к облакам, но всё же. Свой идеал интерфейса управления в части удобства работы с ним, напоминающий мне Cisco UCS, в российской виртуализации я нашел, но не буду его озвучивать, интересно услышать ваше мнение на этот счёт в комментариях.

Варианты выбора решения в зависимости от назначения системы

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

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

• Для развертываний на один ЦОД подойдет практически любой продукт, который удовлетворит заказчика функционалом или набором объективных и субъективных оценок.

• Для развертываний на два ЦОДа (но не более) наверняка потребуется смотреть в сторону решений, способных обеспечить отказоустойчивость и/или функционал репликации на уровне ВМ, например, zVirt/SpaceVM, либо к любому из решений применить дополнительное коммерческое ПО для покрытия недостающего функционала. В эту категорию, полагаю, можно включить бОльшую часть гиперконвергентных решений с собственной реализацией SDS (Sharx Base, АЭРОДИСК vAIR, Скала-Р и Р-Виртуализация и т.д.). Естественно, конфигурация на базе аппаратной СХД в некоторых случаях может потребовать функционал синхронной/асинхронной репликации или метро-кластера.

• Для развертываний на трёх и более ЦОДах стоит смотреть в сторону решений на базе OpenNebula и OpenStack или продуктов с функциями частных облаков, программно-определяемых (наложенных) сетей, программных маршрутизаторов и балансировщиков. Либо же придётся применять сложные схемы развертываний на базе продуктов из второй категории с перекрестной репликацией ВМ между площадками.

2. Насколько у заказчика квалифицированный технический персонал.

• По моему мнению, наиболее простыми в развертывании эксплуатации могут быть решения на базе oVirt (хотя даже в этих системах есть свои нюансы), продукты вроде VMmanager, СКАЛА-Р (Управление) и некоторая часть продуктов с проприетарным СУПВ.

• Вторым по сложности развертывания и эксплуатации мне видятся продукты на базе OpenNebula, требующие ручного развертывания, обязательного наличия службы каталогов. Да простит нас Астра, но ПК СВ “Брест” – одна из них. Такие решения требуют хорошо подкованного технического персонала.

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

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

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

• На среднюю нагрузку вполне подойдут решения с OCFS2 или SDS-решения на базе Ceph, а также любые другие продукты с собственными реализациями программных хранилищ (на самом деле спорный пункт, здесь могут быть и иные мнения на этот счёт).

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

4. Требуется ли использование программных сетевых решений (наложенные сети, программные маршрутизаторы и т.д.):

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

5. Требуется ли сертификат ФСТЭК:

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

А что в итоге?

Если вы надеялись, что, прочитав статью, получите готовую пилюлю с планом действий по выбору решений для своих проектов, то, к сожалению, это не так. Мы предлагаем задуматься о том, какие критерии наиболее критичны для каждого конкретного заказчика/проекта и могут послужить точкой опоры при выборе тех или иных решений в сфере ПО серверной виртуализации. Именно поэтому мы не стали приводить сравнительные таблицы, которые могли бы  поставить какие-то решения в топ рейтинга, а какие-то – в конец списка. Лучшая рекомендация – тестировать все решения, или хотя бы те, которые приемлемы для конкретного заказчика в функциональном плане. Другой вопрос, что для этого может потребоваться много времени, сил и средств. 

Естественно, у меня пока не было возможности протестировать каждый продукт на индивидуальном стенде. Мы в “ЛАНИТ-Интеграции” не раз сталкивались с тем, что некоторые заказчики имеют свои чуть ли не всеобъемлющие списки проверок платформ виртуализации, и для части из них мы готовили стенды на базе двух-трёх вендоров с использованием одного комплекта оборудования. Исходя из таких работ, заказчик получал объективную оценку того или иного ПО серверной виртуализации и в итоге делал выбор в пользу более достойного, с его точки зрения, решения. Естественно, мы продолжим эту практику и в будущем. 

А вам – удачных проектов! Надеюсь, до скорых встреч!