Как пройти новый этап виртуализации в условиях импортозамещения

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

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

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

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

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

Для отечественных же производителей вопрос совместимости программных решений сейчас стоит остро. Во-первых, одномоментно заменить все западное ПО на российское невозможно. При переносе сервисов между различными платформами, построенными на разных архитектурных принципах, возникает проблема преемственности. Во-вторых, необходимо обеспечить управление разнородными средами, поскольку перенос, как правило, происходит постепенно. Это касается любых систем, но виртуализации — особенно, поскольку ее уровень в компаниях превышает 90%. Любые ошибки здесь могут остановить работу всей организации. Как следствие, замена платформы виртуализации откладывается до последнего. Вот почему так нужны механизмы, позволяющие не только гарантированно осуществить миграцию виртуальных машин, но и управлять разнородными средами, как западными, так и российскими.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* * *

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!