Скажем, если надо «переехать», например, с платформой VMware на какую-то другую платформу, такая задача не часто встречается в деятельности IT-специалистов. Поэтому мы создаем и для этого такие инструменты.

На сегодняшний день наше решение состоит из четырех продуктов.

Mind Migrate – это, собственно говоря, разовая миграция для виртуальных сервисов. Mind Guard – это совсем недавно выпущенный продукт, еще не официально его представляем, но мы сегодня уже поговорим о нем. Это обеспечение защиты этих виртуальных серверов.

Mind Universe - автоматическое создание и управление инфраструктурой приложения в любой из поддерживаемых облачных платформ или систем виртуализации.

Mind Swap – это программный модуль для реализации различных сценариев миграции ВМ и их дисковых ресурсов на уровне гипервизора без прерывания работы виртуального сервера.

Mind

Что делаютMind? Ставится задача по «перевозу» виртуального сервера. Виртуальный сервер - это виртуальная машина и ОС вместе со своими данными. Продукт существует на рынке уже в районе двух лет. При этом он опробован в «продакшене» у разных заказчиков, от небольших до крупных, изучены сценарии, в которых возникает такая необходимость. В продукт Mind мы закладываем поддержку всех этих сценарий. То есть наша основная задача – создать очень простой продукт, понятный в плане графического интерфейса, в плане документации, в плане возможности его использования при минимальной подготовке и обеспечить возможность передвижения виртуальных серверов из любого места в любое. То есть мы в данном случае на экране с продемонстрированными иконками осуществляем приезд, например, виртуальной машины из среды VMware в BASIS.

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

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

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

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

Как устроен этот продукт. Мы работаем на уровне операционной системы. Мы выделяем виртуальную машину, в которой устанавливается наш сервер управления Modul Control. Виртуальная машина очень требовательная к ресурсам, 4 VCPU, 16 Гбайт памяти. Операционная система Ubuntu либо Astra. Далее внутри виртуальных машин, которые мы планируем перевозить, нам необходим получить до них доступ, через SMB, если это Windows машина, также нужны учётные записи администратора.

Мы при помощи этих учётных записей Modul Control устанавливает агенты на операционную систему. При этом мы никаким образом не взаимодействуем с нижележащей инфраструктурой. То есть нам не важно, какая платформа, это может быть чистый сервер, это может быть VMware, Hyper-V, в принципе, все что угодно. Далее покажу список совместимости, мы это проверяли. Но обеспечивается виртуально 100-процентная совместимость с любой платформой. Соответственно, на целевой платформе, например, на Astra, создаются виртуальные машины в такой же конфигурации, как и мигрируемые машины, их создавать нужно вручную. Конфигурация дисков должна быть точно такая же, как и в виртуальной машине. Мы работаем только с тем, что видит операционная система уже внутри виртуальной машины. Мы точно такую же структуру дисков сохраняем и создаем на целевой платформе. На этих целевых виртуальных машинах запускается операционная система - «болванка». Специально мы, опять же, поддерживаем Ubuntu или Astra для миграции Linux машин и для переезда Windows-машин ОС «болванка». Соответственно, мы тоже даем туда доступ контролеру. Контроллер устанавливает там свой агент. Операционную систему мы на целевых машинах ставим, для того, чтобы там мог заработать агент. Создаем задание на миграцию: из этой виртуальной машины переезжаем в эту виртуальную машину и начинаем процесс переезда.

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

Что следует из того, что мы работаем на уровне операционных систем? Это, конечно же, максимальная совместимость. Изначально был вариант спроектировать данное программное обеспечение безагентским, то есть создать продукт, который будет взаимодействовать с платформой виртуализации, проводить необходимые действия через API. Но это хорошо, когда одна-две платформы виртуализуются, как это было в России массово, два-три года назад. Но в современном мире, когда число вендоров по виртуализации в России на данный момент исчисляется десятками, это невозможно. Мы решили, что будем работать на уровне операционной системе.

Основной критерий возможности миграции – это поддерживаемая операционная система. На слайде представлен список операционных систем. Это Ubuntu, CentOS, Debian и прочие. На слайде есть устаревшая ошибка, у нас Windows 2008 не поддерживается, только начиная с версии Windows 2012. Платформы, которые здесь перечислены, это все те, с кем мы совместимы, т.е. непосредственно тестировали или имели проекты. То есть каждый бренд, который указан на этом списке, он проверен, сценарий переезда проходил и фактически скорее всего был даже в продакшене.

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

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

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

Разрабатывается все практически с нуля. Мы не используем open source решения, это полностью наша разработка, которая заключается в том, что мы создаем собственную технологию создания моментальных снимков, чтобы делать консистентную копию всех данных на диске. У нас есть технология передачи этих данных и технология управления.

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

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

Типичный запрос выглядит примерно так, есть информационная система и возможен простой ее не более часа. Сделать это ручным способом практически невозможно. Именно для этого и прибегают к помощи наших инструментов. Миграция происходит в режиме онлайн. Это значит, что виртуальная машина, которую мы хотим переместить, продолжает работать все время с синхронизацией. То есть мы выбираем какую-то базу данных. Мы устанавливаем агенты на эти машины. При этом нам нужен полный доступ. Запускается синхронизация, которая начинает перевозить на целевую платформу. При этом влияние на производительность исходных машин практически отсутствует (2-4% оверхеда). При том, что при перевозе мы умеем данные сжимать, шифровать. Единственное, что важны два момента. Первое, сам успех такой миграции зависит от того, что мы данных по сети перевозим быстрее чем они успевают накапливаться. И что еще важно, это то, что пока эти данные переезжают, мы записываем все их изменения с помощью технологии Change Book Tracking. Мы должны эти изменения где-то на диске хранить. И, как правило, для высоконагруженных систем внутри «виртуалки» источника требуется подсоединить дополнительный диск, где мы будем хранить эти изменения на время переезда. Вот это единственное, наверное, что потребует вмешательства в работу виртуальной машины.

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

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

Лицензирование

Есть единственная нормальная лицензия, это Migrate Enterprise, которая включает в себя все необходимые функции, которые рассказывают о шифровании трафика, ограничении канала, возможности использования CBT-журнала, отдельного диска и так далее. Лицензирование производится по виртуальным машинам. То есть, если вы хотите перевести 400 виртуальных машин, нужно купить 400 лицензий. Есть отдельно лицензия Migrate Enterprise Desk для перевода десктопных операционных систем.

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

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

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

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

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

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

MINDGuard

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

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

Как он работает? Первое - это с первичного сервера на резервный сайт производится асинхронное копирование данных. То есть сначала первичное копирование, а затем накатка изменений. У нас теоретически при идеальных условиях, то есть когда есть широкий канал связи, быстрые диски, быстрые серверы, можно обеспечить до 5 секунд RPO. Потеря данных за 5 секунд у многих клиентов считается приемлемым.

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

Второе – это управление, есть контроллер, который постоянно следит за состоянием площадки. Резервный контроллер, соответственно, располагается на резервной площадке. Через контроллер происходит мониторинг параметров.

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

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

Failover

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

Задачи, которые выполняет Guard. Напомню, архитектура у нас платформенная. Мы устанавливаем агентов, мы не требуем поддержки нижележащей платформы. Сеть хранения данных нас тоже не интересует.

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

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

Ограничения

Первое. У нас на данный момент поддерживается только операционная система Linux. Соответственно, Windows стоит на очереди. В ближайших релизах это будет реализовано. Второе. Мы можем отработать ситуацию Failover, когда основная площадка «ложится». Мы переключаемся на резервную, но сейчас у нас нет автоматизации процесса возврата на основную площадку либо на новую. Мы не говорим, что это нельзя сделать. Можно опять же применить Guard, создать пару вручную и в новом направлении отправить машину. Но автоматизации процесса сейчас нет, но она запланирована. И опять же, запланирована к реализации важная вещь для такого класса решений - это тестирование. То есть как и с средствами резервного копирования, тестирование важно, потому что миграцию мы практически сразу проверяем. Однако, сейчас тестирование можно производить только вручную.

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