СПОСОБ, СИСТЕМА И МАШИНОЧИТАЕМЫЙ НОСИТЕЛЬ ДЛЯ ВЫПОЛНЕНИЯ МИГРАЦИИ С ФИЗИЧЕСКИХ МАШИН НА ВИРТУАЛЬНЫЕ Российский патент 2023 года по МПК G06F9/48 

Перекрестная ссылка на связанную заявку

Настоящая заявка создана на основе заявки на патент в Китае №201810308312.7, поданной 8 апреля 2018 г., устанавливает ее приоритет и включает все содержание оригинальной заявки в настоящий документ посредством ссылки.

Область техники

Раскрываемая информация относится, но не ограничивается только этими областями, к техническим аспектам передачи данных, в частности, к способу, системе и машиночитаемому носителю для выполнения миграции с физических серверов на виртуальные машины (P2V).

Уровень техники

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

Сводная информация

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

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

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

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

Данные с диска для создания виртуальной машины обновляются на основе полученных первых недостоверных данных.

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

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

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

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

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

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

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

Проверочный код, выданный виртуальной машиной, сопоставляется с вычисленным проверочным кодом для получения первых недостоверных данных.

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

Вычисленный проверочный код последовательно считывается с учетом смещения файла.

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

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

В вышеописанных решениях проверочный код содержит «сильный» и «слабый» проверочные коды.

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

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

Если первое сопоставление неудачно, выдается ошибка сопоставления.

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

Если второе сопоставление неудачно, выдается ошибка сопоставления.

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

Считывание данных из файла записи.

Сегментирование считанных данных в блоки данных с учетом фиксированной длины в байтах.

Создание соответствующего проверочного кода для каждого сегмента блока данных.

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

Первые недостоверные данные передаются на виртуальную машину, чтобы на их основе выполнить первое обновление данных.

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

Вторые недостоверные данные передаются на виртуальную машину, чтобы на их основе выполнить второе обновление данных.

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

Размер N-ых недостоверных данных должен быть меньше предварительно установленного порогового значения.

В вышеописанных решениях после получения N-х недостоверных данных способ может дополнительно включать следующую операцию.

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

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

Создание первого временного файла.

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

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

Относящийся к программе и хранимый в виртуальной машине файл заменяется вторым временным файлом.

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

Выполняется расчет общего проверочного кода для второго временного файла.

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

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

Информация о типе и версии операционной системы (ОС) на физической машине сравнивается с указанной информацией о типе и версии ОС на виртуальной машине.

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

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

Сравнивается версия привода, соответствующая ОС на физической машине и указанная версия привода, соответствующая ОС на виртуальной машине.

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

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

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

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

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

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

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

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

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

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

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

В вышеописанных решениях модуль обновления дополнительно настраивается для передачи первых недостоверных данных на виртуальную машину, чтобы на их основе выполнить первое обновление данных.

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

Вторые недостоверные данные передаются на виртуальную машину, чтобы на их основе выполнить второе обновление данных.

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

Размер N-ых недостоверных данных должен быть меньше предварительно установленного порогового значения.

В вышеописанных решениях система может дополнительно включать: модуль фильтрации.

Модуль фильтрации настраивается для сравнения информации о типе и версии ОС на физической машине с указанной информацией о типе и версии ОС на виртуальной машине.

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

В данных вариантах раскрытия изобретения дополнительно представлена система миграции P2V, которая может включат: память и процессор.

Память настраивается для хранения выполняемой программы.

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

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

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

Краткое описание рисунков

На рис. 1 представлена блок-схема способа миграции P2V, предусмотренного вариантом раскрытия изобретения.

На рис. 2 представлена блок-схема способа миграции P2V, предусмотренного вариантом раскрытия изобретения.

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

На рис. 4 представлена блок-схема способа миграции P2V, предусмотренного вариантом раскрытия изобретения.

На рис. 5 представлена блок-схема способа миграции P2V, предусмотренного вариантом раскрытия изобретения.

На рис. 6 представлена блок-схема способа миграции P2V, предусмотренного вариантом раскрытия изобретения.

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

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

Подробное описание вариантов осуществления

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

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

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

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

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

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

В первую очередь, приводится описание существительных и терминов в вариантах раскрытия изобретения. Существительные и термины в вариантах раскрытия изобретения имеют следующие объяснения.

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

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

На рис. 1 представлена блок-схема способа миграции P2V, предусмотренного вариантом раскрытия изобретения. На рис. 2 представлена блок-схема принципиально другого способа миграции P2V, предусмотренного вариантом раскрытия изобретения. На основе приведенных выше объяснений существительных и терминов в вариантах раскрытия предмета изобретения, техническое решение реализации настоящего изобретения описывается ниже со ссылкой на рис. 1 и рис. 2. Миграция P2V, предусмотренная в варианте раскрытия изобретения, представляет собой онлайн-миграцию (живую миграцию) и реализуется системой миграции P2V. Ссылаясь на рис. 1 и рис. 2, способ миграции P2V, может включать в себя следующие операции.

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

Здесь, в прикладных программах, платформа управления виртуализацией реализуется системой виртуализации приложений (VAS). VAS реализована с применением виртуальной машины с интеграцией в ядро (KVM). Платформа управления виртуализацией реализуется путем развертывания приложений виртуализации на сервере и предоставляет консоль управления, полностью основанную на архитектуре браузера/сервера (B/S) и, следовательно, может легко управлять виртуальными машинами. Физическая машина может управляться операционной системой Linux.

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

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

В операции 102 получают первые недостоверные данные, генерируемые запуском программы на физической машине в процессе передачи ее дисковых данных.

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

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

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

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

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

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

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

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

К примеру, после приема файла записи (rec1), переданного физической машиной, виртуальная машина считывает файл, подлежащий синхронизации, и помещает его в список файлов. Затем виртуальная машина последовательно считывает каждый файл, сегментирует файл на блоки данных одинаковой длины в соответствии с фиксированной длиной в байтах, вычисляет два проверочных кода для каждого блока данных и сохраняет проверочные коды в соответствующие структуры данных. В конце виртуальная машина передает проверочные коды на терминал физической машины. Физическая машина вызывает системную функцию для открытия канала протокола управления передачей (TCP) между физической машиной и виртуальной машиной, считывает данные из канала, сохраняет полученные проверочные коды в хэш-таблице и выполняет сопоставление проверочных кодов. Физическая машина циклически считывает синхронизируемый файл, циклически вычисляет «слабый» проверочный код блока данных для каждого раза, а затем проверяет, существует ли совпадающий «слабый» проверочный код в хэш-таблице. Если соответствующий «слабый» проверочный код найден, физическая машина вызывает функцию для вычисления «сильного» проверочного кода и делает сравнение на основе вычисленного «сильного» проверочного кода. Если совпадающий «слабый» проверочный код не найден, физическая машина увеличивает смещение файла на 1 и продолжает считывать следующий блок данных. В случае совпадения как для «слабого», так и для «сильного» проверочного кода физическая машина сравнивает интервал между текущим и предыдущим совпадающим смещением и передает данные в пределах этого интервала, а именно несопоставимые данные (первые недостоверные данные). Затем физическая машина увеличивает смещение файла на размер блока данных и продолжает чтение следующего блока данных.

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

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

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

Здесь способы получения вторых недостоверных данных, третьих недостоверных данных... N-х недостоверных данных являются такими же, как способ получения первых недостоверных данных, и N-е недостоверные данные получаются на основе файла записи recN.

Например, как показано на рис. 2, одновременно с работой программы в физической машине выполняется первый цикл передачи данных, а изменения всех файлов в процессе передачи записываются в файл rec1. После этого rec1 передается целевой виртуальной машине для обновления файла. Во время обновления файла виртуальная машина генерирует второй файл записи rec2. В следующем итерационном процессе всегда копируется файл записи, созданный в предыдущем цикле обновления файла. Поскольку скорость передачи записи и обновления файла высока, размер файла записи на физической машине быстро уменьшается до очень небольшого значения. После нескольких циклов передачи данных, когда файл записи на физической машине уменьшается до порога V, установленного системой (примечание: порог и количество записей обновления в файле записи могут быть установлены заранее, т. е. степень изменения файла, служит измеряемым показателем), N-е недостоверные данные получаются на основе текущего файла записи.

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

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

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

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

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

В варианте осуществления после получения N-х недостоверных данных способ может дополнительно включать следующую операцию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В общепринятой практике поддерживается только миграция на операционные системы такой же версии, т. е. ОС до миграции должна быть такой же, что и после миграции, и версия ОС после выполнения миграции не может быть обновлена. Например, если какие-то программы работают под управлением ОС Win8 до миграции, то требуется выполнить обновление до ОС Win10 после миграции, поскольку в ОС более высокой версии больше прикладных интерфейсов программирования (API) и меньше угроз безопасности, обновление версии ОС нельзя произвести в процессе миграции, учитывая текущий уровень техники. При использовании описанных выше вариантов использования, реализуется миграция с операционной системы старой версии на операционную систему новой версии. Благодаря модулю фильтрации для каждого привода нивелируется влияние на программы верхнего уровня различий в версиях приводов на нижнем уровне. Также обеспечивается автоматическое обновление версий программ приводов, таким образом оптимизируется качество разработки программ и эффективность работы пользователей в виртуальной среде.

На рис. 4 представлена блок-схема способа миграции P2V, предусмотренного вариантом раскрытия изобретения. Миграция P2V, представленная в описываемом варианте раскрытия изобретения — это «холодная» миграция, она реализуется при помощи механизма миграции P2V. В ходе практической реализации «холодная» миграция может включать как локальную, так и удаленную миграции. Локальная миграция в данном варианте раскрытия изобретения описывается ниже в соответствии с рис. 4 и может включать следующие операции.

В операции 201 физическая машина производит сбор информации о себе.

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

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

В операции 202 на физической машине создается файл образа, который затем монтируется.

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

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

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

В операции 203 дисковые данные физической машины копируются в файл образа.

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

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

a: Загружается информация об устройстве SeaBIOS и выполняется самотестирование (примечание: виртуальная машина KVM использует ПО SeaBIOS для эмуляции BIOS и реализации аналогичных функций), а затем в соответствии с конфигурационной информацией может быть получен первый загрузочный механизм.

b: Считывается и запускается загрузчик bootLoader (обычно это программа grub) для главной загрузочной записи (MBR) в первом загрузочном устройстве, после чего инициализируется выполнение соответствующей работы, например, модификация программы привода с интерфейсом scsi.

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

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

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

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

На рис. 5 представлена блок-схема способа миграции P2V, предусмотренного вариантом раскрытия изобретения. На рис. 6 представлена блок-схема принципиально другого способа миграции P2V, предусмотренного вариантом раскрытия изобретения. Миграция P2V, представленная в описываемом варианте раскрытия изобретения — это «холодная» миграция, она реализуется при помощи механизма миграции P2V. В ходе практической реализации «холодная» миграция может включать как локальную, так и удаленную миграции. Удаленная миграция в данном варианте раскрытия предмета изобретения описывается ниже в комбинации с рисунками 5 и 6, в нее могут входить следующие операции.

В операции 301 собирается информация, связанная с виртуальной машиной на платформе управления виртуализацией.

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

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

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

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

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

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

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

В каждом конкретном варианте осуществления после того как физическая машина получает соответствующую информацию о виртуальной машине от VAS, пользователь указывает имена пула хранения и виртуальной машины из списка доступных вариантов, устанавливает временный IP-адрес виртуальной машины и в соответствии со специальным форматом создает XML-файл (файл в формате расширенного языка разметки), необходимый для создания этой виртуальной машины. Если объем выбранного пула хранения оказывается меньше, чем размер диска исходной физической машины, пользователю выдается предупреждение, предлагающее выбрать подходящий по размеру пул хранения, а окончательно созданный файл образа сохраняется в этом пуле хранения.

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

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

В операции 303 на платформу управления виртуализацией передается файл специального формата.

В операции 304 осуществляется контроль работы платформы управления виртуализацией (ПУВ) для создания и запуска виртуальной машины.

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

Например, механизм миграции P2V дистанционно управляет платформой управления виртуализацией (VAS) для создания вспомогательной виртуальной машины с учетом информации о целевой виртуальной машине, запускает вспомогательную виртуальную машину из файла образа ISO, где выполняется система Micro Linux, устанавливает соединение с физической машиной, используя ОС Linux, затем в соответствии с полученной информацией о разделах диска физической машины разбивает диск на разделы, форматирует их и создает раздел LVM. После того, как через установленное к вспомогательной виртуальной машине коммуникационное подключение выполняется вход на нее, первым переносится файл ключей, затем файл выполняемых сценариев, информация о разделах и прочие сведения, которые передаются в указанные каталоги этой виртуальной машины.

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

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

2) Резервное копирование данных: после разбиения диска на разделы он монтируется, а затем данные из корневого каталога диска копируются в файл диска. При копировании файлов подкаталоги корневого каталога рассматриваются как единое целое.

3) Обновление программы загрузки включает следующие операции.

a: Загружается информация об устройстве SeaBIOS и выполняется самотестирование (примечание: виртуальная машина KVM использует ПО SeaBIOS для эмуляции BIOS и реализации аналогичных функций), а затем в соответствии с конфигурационной информацией может быть получен первый загрузочный механизм.

b: Считывается и запускается загрузчик bootLoader (обычно это программа grub) для главной загрузочной записи (MBR) в первом загрузочном устройстве, после чего инициализируется выполнение соответствующей работы, например, модификация программы привода с интерфейсом scsi.

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

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

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

На рис. 7 представлена композиционная и структурная схема системы миграции P2V, предусмотренная вариантом раскрытия изобретения. Как показано на рис. 7, система миграции P2V, предусмотренная вариантом раскрытия изобретения, может включать в себя: модуль обработки 71, модуль сбора 72, модуль обновления 73 и модуль управления 74.

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

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

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

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

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

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

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

вычисление проверочного кода для локального файла, соответствующего программе;

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

В каждом конкретном варианте осуществления, модуль сбора данных 72 дополнительно настроен для последовательного считывания вычисленного проверочного кода с учетом смещения файла;

сопоставление проверочного кода, полученного при каждом считывании, с проверочным кодом, выданным виртуальной машиной;

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

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

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

определение, если первое сопоставление неудачно, выдается ошибка сопоставления;

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

определение, если первое сопоставление неудачно, выдается ошибка сопоставления.

В каждом конкретном варианте осуществления, модуль управления 74 дополнительно настроен на управление виртуальной машиной для чтения данных в файле записи;

сегментирование считанных данных в блоки данных в соответствии с фиксированной длиной в байтах;

создание соответствующего проверочного кода для каждого сегмента блока данных.

В приведенных выше решениях модуль обновления 73 дополнительно настроен на передачу первых недостоверных данных на виртуальную машину, чтобы позволить виртуальной машине выполнить первое обновление данных на их основе;

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

передача вторых недостоверных данных на виртуальную машину, чтобы на их основе выполнить второе обновление данных;

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

Размер N-ых недостоверных данных должен быть меньше предварительно установленного порогового значения.

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

В каждом конкретном варианте осуществления, модуль обновления 73 дополнительно настроен: для создания первого временного файла;

в этот первый временный файл записываются первые недостоверные данные и первые данные, хранимые в виртуальной машине, для формирования второго временного файла;

при этом первые данные представляют собой данные, за исключением части файла со смещением, соответствующим первым недостоверным данным в файле, относящемся к данной программе;

замену файла, относящегося к программе и хранящегося в виртуальной машине, вторым временным файлом.

В каждом конкретном варианте осуществления, модуль обновления 73 дополнительно настроен для вычисления общего проверочного кода второго временного файла; и

определения соответствия общего проверочного кода второго временного файла и общего проверочного кода файла, относящегося к программе.

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

Модуль фильтрации 75 настроен на сравнение информации о типе и версии ОС физической машины с указанной информацией о типе и версии ОС на виртуальной машине;

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

В каждом конкретном варианте осуществления, модуль фильтрации 75 дополнительно настроен для установления различий между версией привода, соответствующей ОС на физической машине и указанной версией привода, соответствующей ОС на виртуальной машине;

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

В каждом конкретном варианте осуществления, модуль фильтрации 75 дополнительно настроен для получения файла различий между приводом, относящимся к ОС на физической машине, и указанным приводом, относящимся к ОС на виртуальной машине;

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

На рис. 8 представлена композиционная и структурная схема системы миграции P2V, предусмотренная вариантом раскрытия изобретения. Как показано на рис. 8, система миграции P2V, предусмотренная вариантом раскрытия предмета изобретения, может включать в себя: процессор 81, память 82 и как минимум один внешний коммуникационный интерфейс 83.

Процессор 81, память 82 и внешний коммуникационный интерфейс 83 соединены шиной 84.

Память 82 настроена для хранения выполняемой программы 821.

Процессор 81 настраивается для запуска выполняемой программы, хранимой в памяти, для выполнения следующих операций.

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

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

Исполняемая программа настроена для выполнения процессором следующих операций.

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

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

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

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

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

Изобретение относится к системам миграции с физических на виртуальные машины (P2V). Технический результат заключается в повышении точности согласованности данных при выполнении миграции данных с физических машин на виртуальные. Технический результат достигается за счет того, что данные исходного терминала передаются на целевой терминал и их передача в полном объеме проходит в ходе первого цикла, а все измененные, во время первого цикла, данные собираются в результате мониторинга. В каждом последующем цикле передаются измененные в предыдущем цикле данные, то есть недостоверные данные. После выполнения нескольких циклов, когда заключительный объем недостоверных данных становится меньше предварительно заданного порогового значения, выполнение циклов прекращается и начинается этап выключения. После выполнения последнего цикла запускается виртуальная машина на целевом терминале и программа в ней, а программа на исходном терминале прекращает работу. 3 н. и 18 з.п. ф-лы, 8 ил.

1. Способ миграции с физической на виртуальную машину (P2V), включающий:

передачу дисковых данных физической машины на сервер, причем дисковые данные используются сервером для создания и запуска виртуальной машины (VM) на основе дисковых данных физической машины;

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

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

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

2. Способ по п. 1, отличающийся тем, что получение первых недостоверных данных, созданных в результате выполнения программы на физической машине, на основе файла записи для записи изменений, включает:

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

вычисление проверочного кода для локального файла, соответствующего программе; и

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

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

последовательное считывание вычисленного проверочного кода с учетом смещения файла;

соответственно, сопоставление проверочного кода, полученного при каждом считывании, с проверочным кодом, возвращенным виртуальной машиной; и

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

4. Способ по п. 2, отличающийся тем, что проверочный код содержит «сильный» и «слабый» проверочные коды; и

сопоставление проверочного кода, полученного при каждом считывании, с проверочным кодом, выданным виртуальной машиной, предполагает:

выполнение первого сопоставления первого прочитанного «слабого» проверочного кода со вторым «слабым» проверочным кодом, возвращенным виртуальной машиной;

когда первое сопоставление не удалось, определение того, что сопоставление не удалось;

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

когда второе сопоставление не удалось, определение того, что сопоставление не удалось.

5. Способ по п. 2, отличающийся тем, что формирование виртуальной машиной проверочного кода, на основе файла записи для записи изменений, включает:

считывание данных в файле записи для записи изменений;

сегментирование считанных данных в блоки данных с учетом фиксированной длины в байтах; и

создание соответствующего проверочного кода для каждого сегмента блока данных.

6. Способ по п. 1, отличающийся тем, что после получения N-ых недостоверных данных, дополнительно предполагается:

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

7. Способ по п. 1, отличающийся тем, что выполнение в виртуальной машине первого обновления данных, проводимого на основе первых недостоверных данных, включает:

создание первого временного файла;

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

замену файла, соответствующего программе и хранимого в виртуальной машине, вторым временным файлом.

8. Способ по п. 7, отличающийся тем, что после формирования второго временного файла дополнительно предполагается:

вычисление общего проверочного кода для второго временного файла; и

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

9. Способ по п. 1, дополнительно включающий:

сравнение информации о типе и версии операционной системы (ОС) физической машины с указанной информацией о типе и версии ОС виртуальной машины;

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

10. Способ по п. 9, дополнительно включающий:

установление различий между версией привода, соответствующего ОС физической машины и указанной версией привода, соответствующей ОС виртуальной машины;

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

11. Способ по п. 9, отличающийся тем, что обновление привода, соответствующего ОС виртуальной машины, включает:

получение файла различий между приводом, соответствующим ОС физической машины, и указанным приводом, соответствующим ОС виртуальной машины;

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

12. Система для миграции с физической на виртуальную машину (P2V), включающая:

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

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

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

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

13. Система по п. 12, отличающаяся тем, что модуль сбора данных дополнительно настроен:

передавать файл записи для записи изменений в виртуальную машину для получения проверочного кода, сгенерированного и возвращенного виртуальной машиной на основе полученного файла записи для записи изменений;

вычислять проверочный код для локального файла, соответствующего программе;

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

14. Система по п. 13, отличающаяся тем, что модуль сбора данных дополнительно настроен:

последовательно считывать вычисленный проверочный код с учетом смещения файла;

соответственно, сопоставлять проверочный код, полученный при каждом считывании, с проверочным кодом, возвращенным виртуальной машиной; и

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

15. Система по п. 13, отличающаяся тем, что проверочный код содержит «сильный» и «слабый» проверочные коды; и

модуль сбора данных дополнительно настроен:

выполнять первое сопоставление первого прочитанного «слабого» кода со вторым «слабым» проверочным кодом, возвращенным виртуальной машиной;

определять, если первое сопоставление неудачно, что сопоставление не удалось;

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

определять, если второе сопоставление неудачно, что сопоставление не удалось.

16. Система по п. 13, отличающаяся тем, что модуль управления дополнительно настроен:

управлять виртуальной машиной для чтения данных в файле записи для записи изменений;

сегментировать считанные данные в блоки данных в соответствии с фиксированной длиной в байтах; и

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

17. Система по п. 12, отличающаяся тем, что модуль обновления дополнительно настроен:

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

18. Система по п. 12, отличающаяся тем, что модуль обновления дополнительно настроен:

создавать первый временный файл;

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

заменять файл, соответствующий программе и хранящийся в виртуальной машине, вторым временным файлом.

19. Система по п. 18, отличающаяся тем, что модуль обновления дополнительно настроен:

вычислять общий проверочный код для второго временного файла; и

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

20. Система по п. 12, дополнительно включающая:

модуль фильтрации, настроенный сравнивать информацию о типе и версии операционной системы (ОС) физической машины с указанной информацией о типе и версии ОС виртуальной машины; и

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

21. Машиночитаемый носитель, настроенный для хранения исполняемой программы, где исполняемая программа исполняется процессором для осуществления способа миграции с физической на виртуальную машину (P2V) по любому из пп. 1–11.