Компания MIND Software выпускает продукты, помогающие миграции между разными облаками, гипервизорами, платформами, в любом их представлении. Зачем нужно мигрировать? Тематика миграции актуальна и без геополитического драйвера, который тоже со счетов не надо сбрасывать.
Процесс миграции может быть спровоцирован со стороны клиента огромным количеством триггеров, это и геоположение облака, качество и стабильность технологии, SLA от партнера, который является обслуживающим звеном, наличие или отсутствие какой-то функциональности, комплексное TCO.
Этих драйверов очень много, но по сей день огромное число клиентов, конечных пользователей, облачных операторов считают процесс миграции достаточно сложным и относят к высокорискованным процедурам. Они просто боятся этого, поскольку при его выполнении может пойти что-то не так, что-то сломаться.
До какого-то момента это было уделом профессиональных сервисов, которые оказывали комплексные услуги по миграции инфраструктурных ландшафтов. Но с появлением серверной технологии виртуализации это закрепилось как общепринятый подход, и мы получили возможность огромное количество процедур и отдельных элементов сложного миграционного процесса автоматизировать.
Продукция компании MIND Software не превращает процесс миграции в какой-то фокус, в рамках этой процедуры заказчик сильно переживает, поскольку несет риски. С использованием продукта компании MIND Software удается автоматизировать 95% всех рутинных операций, которые нужно выполнять инженерам. В большом объеме рутинных операций кроется большинство проблем: необходимость что-то повторять, незнание каких-то нюансов технологий, ошибки, все это удается обойти при использовании нашего программного обеспечения.
Что же мы делаем? Та часть продукта, которая отвечает за миграцию виртуальной инфраструктуры, выполняет следующее: с помощью нашего инструмента один или набор объектов виртуальной инфраструктуры, банально – виртуальный сервер, виртуальную машину с разными ОС нужно с одной платформы автоматически перенести на какую-то альтернативную платформу, развернутую в другом ЦОДе или в облаке или в соседнем машинном зале. Здесь доступен любой кейс. Нам не важно какая это платформа, какой гипервизор, какое это облако, мы поддерживаем сценарий переноса откуда угодно практически куда угодно. Мы все время расширяем число платформ и технологий, которые попадают в нашу матрицу возможностей.
Мы поддерживаем самые простые сценарии миграции, например берем одну виртуальную машину и переносим ее с одной платформы на другую. Процесс переноса начинается с этапа настройки, продолжается процессом копирования данных, он может проходить онлайн, т.е. без необходимости выключения того сервера, с которого осуществляется копирование.
Что важно в процессе миграции для владельца инфраструктуры. Он уверен что если что-то пойдет не так, надо что-то будет починить во время миграционного перехода, то для него принципиально важно чтобы в той инфраструктуре, которая куда-то едет, ничего не происходило, мы исходим именно из такого сценария. При переносе источник данных всегда остается онлайн. Можно пересоздать сервер назначения, даже если разорвался канал связи и т.д., нам не важно, сервер источник всегда работает. Большинство других инструментов миграции предлагают решение какого-то конкретного этапа, например, конвертацию образа виртуальной машины, но плюс к этому они практически никогда не предлагают выполнить это онлайн, все требуют выключится.
Наша компания может работать и с достаточно сложными сценариями, мы понимаем, что на этих виртуальных серверах работает какая-то прикладная программа, оператор миграции может захотеть объединить какие-то машины в группы, мы даем такую возможность. Мы можем встроить операции с групповыми объектами в определенный сценарий, где этап за этапом, группа за группой виртуальных машин будет мигрироваться последовательно и наш управляющий модуль будет отслеживать последовательность выполнения этой миграции. Таким образом можно обслуживать большое число объектов.
Понимая, что мы обеспечиваем нашим продуктом консистентность на уровне гостевой ОС сервера, мы понимаем, что поверх работают какие-то приложения, желая реализовать консистентностный перенос, не обойтись без обеспечения каких-то действий на уровне приложения. Мы дает пользователю удобный инструмент имплементировать в какие-то этапы миграционного процесса свои пользовательские кастомизированные сценарии работы с приложением. Есть несколько этапов, где оператор миграции может выбирать конкретные действия, выполняя их на прикладном уровне. Это позволяет нам собрать достаточно сложную композицию с точки зрения мигрируемого ландшафта. Однако никогда не будет возможен полностью автоматизированный перенос, всегда останется малая толика ручных операций. Но тем не менее многое можно автоматизировать.
Вопрос совместимости всегда очень важен, он лежит в нескольких плоскостях. Поскольку сам перенос виртуальной инфраструктуры мы осуществляет на уровне гостевой ОС, а она может находиться в контексте разных гипервизоров, разных облачных платформ, то отсюда вытекает, что у нас есть плоскость совместимости с каким-то набором гостевых ОС (Linux и Windows). С точки зрения Linux мы поддерживаем практически все популярные открытые коммерческие дистрибутивы и отечественные дистрибутивы в том числе. Есть здесь и экзотика.
Практически вся линейка Windows server, начиная с 2008-й версии и заканчивая самой последней, также мы в последнее время экспериментируем с историей вокруг VDI (Windows 10 и Windows 11). У нас большое число тестовых проектов с Windows 10, в целом мы с этим справляемся. Для остальных – не всегда, это особенность применения технологии.
Мы заключили или в процессе заключения различных технологических партнерств с отечественными производителями платформенных решений и решений в области виртуализации.
Обычно второй вопрос при внедрении какой-то новой платформы заключается в следующем: после вопроса «а кто мне это дело поставит и настроит?», звучит вопрос «а как туда перенести боевую нагрузку?». Вот тут мы приходим с ответом. Мы взаимодействуем с большим числом облачных провайдеров.
Преимущества. Мы действительно стараемся развивать продукт в кроссплатформенном контексте, поддерживать максимальную вариативность ОС и платформ, мы делаем это онлайн. Мы полностью российская аккредитованная компания – разработчик программного обеспечения и наш продукт находится в реестре российского ПО, мы понимаем, что регуляция в нашем отечестве достаточно важный и имеет очень серьезный вес, мы постараемся выполнять сертификационную работу, получаем необходимые лицензии. Мы понимаем важность в современном контексте этого вопроса, можете не беспокоиться – все у нас будет очень правильно.
Задачи, для которых нас чаще всего применяют и в контексте которых возникает необходимость применения нашего продукта. Это внедрение какого-то отечественного платформенного решения для расширения какого-то контура – это очевидная тема, с которой многие сталкиваются. Но на самом деле есть большое количество клиентов, которые в целом понимают, что если миграция будет простой, она может быть частью непрерывного жизненного цикла инфраструктуры. Если есть какое-то количество сегментов, реализованных на разных платформах или одинаковых платформах, они просто отличаются по уровню SLA, или еще по чему-то и между ними можно легко и без проблем переносить инфраструктурные элементы, то почему бы этого не делать? И поскольку мы наших заказчиков убеждаем в том, что это простая задача с нашим инструментом, то они имеют такую возможность, перемещать какие-то проектные инфраструктурные контуры легко, если на то у них есть запрос. Это может стать регулярной работой в эксплуатационном процессе.
Сценарии могут быть любые: из коммерческого облака в ЦОД и обратно, из иностранной платформы виртуализации на отечественную, из старого ЦОДа в новый, между облаками и так далее. Вопрос исключительно в наличии технической сетевой связанности между платформами, между которыми должна осуществляться миграция. Но даже в отсутствии сетевой связанности есть часть функционального нашего продукта, которая обеспечит вам выгрузку ваших виртуальных машин со всеми настройками на какое-то внешнее перемещаемое хранилище, если каналов связи нет вообще. Это хранилище перевозится в удаленный ЦОД и там с него разворачивается соответствующая инфраструктура. Такие сценарии переноса с разрывом мы тоже в целом поддерживаем. Однако таких запросов не много, но они есть.
