CC BY
51
УДК 004.75+004.624
05.13.10 - Управление в социальных и экономических системах (технические науки)
МЕТОДИКА МИГРАЦИИ ВИРТУАЛЬНЫХ НАГРУЗОК С ПЛАТФОРМЫ ВИРТУАЛИЗАЦИИ VMWARE VSPHERE НА ПЛАТФОРМУ ВИРТУАЛИЗАЦИИ MICROSOFT HYPER-V
Попок Леонид Евгеньевич канд. экон. наук, доцент SPIN-код автора: 8450-7190 e-mail: lpopok@gmail.com
Богомолов Александр Евгеньевич аспирант
SPIN-код автора: 1920-4704 e-mail: bo gomoloff. a@ gmail.com
Кубанский государственный аграрный университет им. И.Т. Трубилина, Россия, 350044, Краснодар, Калинина ул., 13
В статье рассматриваются современные подходы к осуществлению миграции виртуальных машин между различными платформами виртуализации. Дана сравнительная характеристика инструментов осуществления миграции виртуальных нагрузок. Сделаны выводы о целесообразности применения различных подходов в зависимости от стоящей перед миграцией задачи и имеющихся ресурсов. Представлена авторская методика миграции виртуальных машин с платформы виртуализации VMware vSphere на платформу виртуализации Microsoft Hyper-V, позволяющая повысить скорость и надежность процесса миграции и существенно сэкономить на операционных издержках предприятия
Ключевые слова: ВИРТУАЛИЗАЦИЯ, ВИРТУАЛЬНЫЕ МАШИНЫ, МИГРАЦИЯ НАГРУЗОК, ИНФРАСТРУКТУРА
DOI: http://dx.doi.org/10.21515/1990-4665-153-007
UDC 004.75+004.624
Management in social and economic systems
METHOD OF MIGRATION OF VIRTUAL LOADS FROM THE VMWARE VSPHERE VIRTUALIZATION PLATFORM TO THE MICROSOFT HYPER-V VIRTUALIZATION PLATFORM
Popok Leonid Evgenevich Cand.Econ.Sci., associate professor, RSCI SPIN-code: 8450-7190 e-mail: lpopok@ gmail. com
Bogomolov Alexander Evgenievich
postgraduate student,
RSCI SPIN-code: 1920-4704
e-mail: bo gomoloff. a@gmail. com
FSBEIHPE "Kuban State Agrarian University
named after I.T. Trubilin", Krasnodar, Russia
The article discusses modern approaches to the implementation of the migration of virtual machines between different virtualization platforms. A comparative characteristic of virtual migration tools is given. Conclusions are drawn on the expediency of applying different approaches depending on the task facing migration and available resources. The author presents a technique for migrating virtual machines from VMware vSphere virtualization platform to Microsoft Hyper-V virtualization platform, which allows to increase the speed and reliability of the migration process and significantly save on operating costs of the company
Keywords: VIRTUALIZATION, VIRTUAL MACHINES, LOAD MIGRATION, INFRASTRUCTURE
Современные подходы к автоматизации бизнес-процессов все больше сталкиваются с вопросами повышения эффективности использования имеющихся вычислительных ресурсов. Переход на технологии облачных вычислений заставляет компании пересматривать подходы к оценке собственных возможностей и искать пути снижения операционных издержек, при этом не усложняя процессы администрирования информационной инфраструктуры.
В современных условиях ведения бизнеса крупные компании для снижения операционных затрат и упрощения процедур администрирования серверных систем и оборудования, все чаще используют платформы виртуализации, как набор вычислительных ресурсов и их логическое объединение, абстрагированное от аппаратной реализации. Однако, использование платформы виртуализации влечет за собой дополнительные расходы на закупку лицензий программного обеспечения платформы виртуализации. В таких условиях немаловажным критерием становится общая стоимость владения лицензий программного обеспечения платформы виртуализации и снижение затрат на закупку этого программного обеспечения.
Миграция виртуальных нагрузок является стратегически важным шагом в долгосрочной перспективе экономии денежных средств, связанных с закупкой лицензий на программное обеспечение платформы виртуализации и обеспечения конкурентных преимуществ для компаний различных отраслей в условиях экономического кризиса и роста глобальной конкуренции.
Основными целями миграции виртуальных машин с платформы виртуализации VMware vSphere на платформу виртуализации Microsoft Hyper-V являются снижение общих затрат на обслуживание ИТ-инфраструктуры за счет снижения затрат на лицензии платформы виртуализации, повышение эффективности деятельности посредством централизации вычислительных ресурсов платформы виртуализации и унификации регламентов их использования, централизации и унификации управления платформой виртуализации.
Результатом нашего исследования явилась методика миграции виртуальных машин с платформы виртуализации VMware vSphere на платформу виртуализации Microsoft Hyper-V. Следование предлагаемой методике и инструкциям является важнейшим фактором для обеспечения успешной миграции в планируемые сроки и снижения рисков.
В рамках тестирования инструменты оцениваются по ряду критериев:
- делегирование и права на инфраструктуру;
- стоимость инструмента миграции;
- поддержка решения поставщиком;
- скорость миграции/время простоя машин;
- требования к дисковым ресурсам на проведение миграции;
- вопросы автоматизации массовой миграции;
- возможность отката и восстановления в случае возникновения проблем.
Ниже представлена основная информация о каждом инструменте и оценка параметров по пятибалльной шкале. Далее предложена краткая сводная таблица с баллами по оцениваемым параметрам и предложены наиболее эффективные варианты.
Microsoft System Center Virtual Machine Manager (SCVMM). SCVMM позволяет подключить серверы управления VMware vCenter и из единой консоли видеть все узлы виртуализации и все виртуальные машины, с возможностью создания, управления и конвертации машин. В данном тестировании рассматривался лишь аспект миграции виртуальных машин на Hyper-V.
Первым шагом в рассмотрении методики миграции является вопрос делегирования минимальных полномочий команде миграции на промышленную среду VMware vSphere. Согласно официальной документации Microsoft для добавления vCenter в VMM требуется учетная запись с полными правами на всю инфраструктуру VMware vSphere и локальными административными правами на vCenter. По пятибалльной шкале SCVMM оценивается в 4 балла по критерию делегирования и прав на инфраструктуру, из-за требования локальной записи на узлах.
Вторым важным моментом является поддержка решения. SCVMM является частью System Center, флагманского продукта компании Microsoft, периодически обновляется, поддерживается поставщиком программного обеспечения, и оценивается в 5 баллов по критерию поддержки.
Следующим критерием является скорость миграции, время недоступности вири-альных машин на период миграции. SCVMM мигрирует виртуальную машину в выключенном состоянии, копируя ее диск в формате VMDK на узел по протоколу HTTP и выполняя конвертацию в VHDX по окончании копирования. Время недоступности типовой для этапа тестирования виртуальной машины составило 1 час 3 6 минут от начала процесса до окончания миграции и доступности виртуальной машины по сети. Оценка по критерию скорости миграции - 2 балла.
С точки зрения требований к ресурсам, на целевом узле требуется выделение двойного объема дискового пространства от используемого виртуальной машиной: на копирование диска и его конвертацию. После конвертации копия исходного диска уда-
ляется и используется одна копия виртуальных дисков. Оценка по критерию требований к ресурсам - 2 балла.
Автоматизация процесса является одним из ключевых факторов для массовой миграции. SCVMM автоматически выбирает наименее загруженный узел для мигрируе-мой виртуальной машины и свободный диск для размещения ее файлов. Виртуальная машина сразу же является высокодоступной, подключенной к виртуальным сетям, управляемым VMM, получает указанный IP адрес из специального пула. Все операции можно единожды выполнить из GUI и сохранить в виде сценариев PowerShell для последующих модификаций. При этом некоторые сложные сценарии миграции, например
- виртуальные машины с нестандартными настройками или дополнительными требованиями, - могут потребовать доработки скриптов. Либо разработки новых скриптов, если это окажется более целесообразно. Объектная модель и скриптовый язык SCVMM (PowerShell) позволяет такие доработки. Оценка по критерию автоматизации - 5 баллов.
При миграции виртуальной машины средствами SCVMM исходная машина на стороне VMware выключается и остается там по окончании миграции, требуя ручного удаления, что дает возможность простого включения исходной виртуальной машины, как плана отмены миграции. Оценка по критерию восстановления - 5 баллов.
SCVMM является платным продуктом, лицензируемым на процессор узла виртуализации, однако входит в пакет вместе с лицензиями на Windows Server, и, как правило, уже имеется у большинства крупных организаций. Оценка по критерию стоимости
- 3 балла.
Microsoft Virtual Machine Converter (MVMC). MVMC является отдельным продуктом Microsoft для миграции машин с инфраструктуры VMware vSphere (либо физических серверов) на Hyper-V (либо Microsoft Azure).
В разрезе делегирования прав для MVMC хватает минимальной роли, которую настроили для миграции средством VMM. Прав на vSphere узлах не требуется. Оценка по критерию делегирования прав на инфраструктуру - 5 баллов.
На текущий момент времени MVMC является неподдерживаемым продуктом. Оценка по критерию поддержки - 1 балл.
Во время миграции выключенная машина копируется, затем конвертируется. Требуется 32 минуты на типовую тестовую виртуальную машину. Оценка по критерию скорости миграции - 3 балла.
MVMC требует двойной объем дискового пространства на время конвертации. Оценка по критерию требований к ресурсам - 2 балла.
Задачи, выполняемые MVMC, частично автоматизируются. Подключение к сети, кластеризация виртуальных машин, инсталляция компонентов интеграции, выделение адреса, все это возможно сделать из PowerShell; однако выбор узла Hyper-V и диска для размещения нагрузок требуют явного решения администратора. Оценка по критерию автоматизации - 3 балла.
При миграции виртуальной машины средствами MVMC исходная машина на стороне VMware выключается и остается там по окончании миграции, требуя ручного удаления, что дает возможность простого включения оригинальной виртуальной машины как плана отмены миграции. Оценка по критерию восстановления - 5 баллов.
MVMC является бесплатным продуктом и не требует закупки. Оценка по критерию стоимости - 5 баллов.
5nine Easy Converter. 5nine Easy Converter (далее 5nine) - это стороннее решение V2V. Поставляется в виде бесплатной и платной версий, где платная версия имеет возможность автоматизации. Преимуществом в сравнении с VMM/MVMC является поддержка виртуальных машин второго поколения, в которые он может конвертировать машины VMware vSphere, использующие режим загрузки UEFI.
В разрезе делегирования прав на стороне vCenter для 5nine хватает минимальной роли, которую настроили для миграции с помощью VMM. При миграции напрямую с VSphere требуются права суперпользователя (root) на узлах. Оценка по критерию делегирования прав на инфраструктуру - 4 балла.
Продукт 5nine является сторонним, платная версия поддерживается разработчиком. Службы поддержки Microsoft не принимают инциденты по конвертации сторонним продуктом, но сконвертированная машина является поддерживаемой со стороны Hyper-V. Оценка по критерию поддержки - 3 балла.
Скорость миграции машин и время недоступности для 5nine сравнимо с MVMC при миграции с vCenter. Выключенная машина копируется, затем конвертируется. Требуется 37 минут на типовую тестовую виртуальную машину с vCenter. Оценка по критерию скорости миграции - 3 балла.
Продукт 5nine требует двойной объем дискового пространства на время конвертации. Оценка по критерию требований к ресурсам - 2 балла.
Задачи, выполняемые бесплатной версией 5nine, не автоматизируются. Для платной версии существует модуль PowerShell из четырех коммандлетов, позволяющий ав-
томатизировать миграцию напрямую с vSphere. Данный модуль не поддерживает миграцию с vCenter, а так как, как правило, компании имеют сотни узлов vSphere, и виртуальные машины автоматически перемещаются между ними, это накладывает ограничения - машины нужно будет на стороне VMware предварительно мигрировать на отдельный узел, где отключена технология балансировки. Оценка по критерию автоматизации - 3 балла.
При миграции виртуальной машины средствами 5nine исходная машина на стороне VMware удаляется. Для отмены миграции следует предварительно сделать клон машины (можно автоматизировать, но требует дисковых ресурсов) либо восстанавливать исходную виртуальную машину из резервной копии. Оценка по критерию восстановления - 3 балла.
Продукт 5nine Easy Converter в варианте с автоматизацией является платным решением и лицензируется на каждую ВМ по ценам, сравнимым с Azure; около 25-30$ за виртуальную машину. Оценка по критерию стоимости - 2 балла.
Скриптовое решение на базе NFS, VMotion и бесплатных утилит. В качестве альтернативы коммерческим решениям предлагается вариант, позволяющий существенно снизить время простоя виртуальной машины на период миграции. На сервере Windows один из дисков предоставляется в общий доступ как по протоколу SMB (типовые общие папки Windows), так и по протоколу NFS (протокол общих дисков для ОС UNIX, поддерживаемый также VMware VSphere). На стороне VMware vCenter общий том NFS добавляется как хранилище, и виртуальная машина переносится на него во включенном состоянии с помощью технологии vMotion. После того, как файлы машины окажутся на сервере Windows, машина выключается, и ее диск из формата VMDK мгновенно конвертируется сначала в VHD, а затем в VHDX с помощью изменения заголовков файлов виртуального диска утилитами VHDtool и VHDXtool. Далее скриптами PowerShell для VMM создается целевая высокодоступная виртуальная машина на Hyper-V с параметрами, аналогичными исходной, к ней подключается полученный VHDX диск. На виртуальный диск, еще в выключенном состоянии, устанавливаются компоненты интеграции. Виртуальная машина включается, требуется одна перезагрузка, виртуальная машина получает старый IP-адрес и готова к работе через несколько минут недоступности.
С точки зрения делегирования прав на стороне vCenter требуется лишь два права - клонирование (создать копию для отмены миграции) и перемещение дисков на том
NFS. Прав на vSphere не требуется. Оценка по критерию делегирования прав на инфраструктуру - 5 баллов.
Наиболее сложным вопросом для описанного решения является его поддержка. Так как для конвертации не используется ни один из продуктов Microsoft, проблемы с конвертацией формальной поддержки получить не могут. Однако, если по окончанию конвертации виртуального диска в формат VHDX, диск получился монтируемым, то созданная машина Hyper-V имеет стандартную поддержку Microsoft. Оценка по критерию поддержки - 4 балла.
Виртуальная машина переносится на Windows сервер во включенном состоянии без остановки служб. Конвертация виртуальной машины выполняется за несколько секунд. Время простоя равно времени двух перезагрузок операционной системы. Оценка по критерию скорости миграции - 5 баллов.
Дополнительного дискового пространства на процесс конвертации не требуется. Оценка по критерию требований к ресурсам - 5 баллов.
Решение полностью построено на скриптах, использует модуль PowerShell для VMM и PowerCLI от VMware, а также сторонние бесплатные утилиты nfsutil, vhdtool и vhdxtool. Все задачи можно автоматизировать. Оценка по автоматизации - 5 баллов.
При миграции виртуальной машины средствами Storage vMotion файлы исходной машины VMware переносятся на том NFS, где на месте конвертируются в другой формат. Копирования дисков не происходит ни на одном из этапов, поэтому копий исходной виртуальной машины не остается. Для отмены миграции следует предварительно сделать резервную копию виртуальной машины. Оценка по критерию восстановления -3 балла.
Данный подход не использует платных продуктов и не требует закупки. Оценка по стоимости - 5 баллов.
Результаты тестирования инструментов миграции виртуальных нагрузок представлены в таблице 1.
Таблица 1 - Критерии оценки инструментов миграции виртуальных нагрузок
Критерий оценки SCVMM MVMC 5nine Скрипты
Делегирование и права на инфраструктуру 4 5 4 5
Поддержка решения 5 1 3 3
Время недоступности сервиса 2 3 3 5
Требования к ресурсам 2 2 2 5
Автоматизация решения 5 3 3 5
Возможность отката и восстановления 5 5 3 2
Стоимость решения 3 5 2 5
ИТОГО 26 24 20 30
Из полученной таблицы, с учетом описанных оценочных баллов по критериям каждого подхода, видно, что наиболее оптимальный подход - миграция с помощью скриптового метода, однако, также можно рекомендовать использовать метод миграции с помощью SCVMM для миграции тех виртуальных нагрузок, которые по каким-либо техническим причинам не могут мигрировать с помощью скриптового подхода.
Результатом нашего исследования является авторская методика миграции виртуальной нагрузки с платформы виртуализации VMware vSphere на платформу виртуализации Microsoft Hyper-V. Подход и процедуры миграции спроектированы таким образом, чтобы обеспечить наименьшее время простоя систем и пользователей, а также альтернативные пути выполнения этапов миграции и возможность отмены изменений в случае их неудачного завершения. Критерии, заложенные в процедуру миграции на стадии проектирования, позволяют снизить влияние переходных процессов миграции на технологические процессы бизнес-компаний.
Процедура миграции выполняется автоматизировано и включает в себя два способа миграции виртуальных машин с одной платформы виртуализации на другую.
Способ 1 - смена форматов виртуальных жестких дисков с использованием скриптов миграции при помощи утилит преобразования виртуальных жестких дисков «VHDTool» и «VHDXTool». Данные утилиты являются бесплатными и распространяются со свободной лицензией.
Способ 2 - конвертация виртуальных машин, встроенная в программное обеспечение Microsoft SCVMM с автоматизацией с помощью скриптов.
Подготовка к миграции начинается с решения ряда организационных задач.
1) Проектирования и тестирования процедур миграции на стенде.
2) Формирование команд миграции. Формируется группа технических специалистов, которые будут осуществлять работы по миграции виртуальных машин. Предусмотрен следующий состав команды миграции.
- Операторы миграции АС. Технические специалисты, осуществляющие:
■ подготовку к миграции;
■ работу с инструментами миграции;
■ общий контроль над процедурами и проверку результатов миграции.
- Администраторы автоматизированных систем. Специалисты службы ИТ, которые управляют приложениями. При поддержке специалистов ИТ и других участников команды миграции готовят входные данные, а также проверяется работа приложений, перед началом и после завершения миграции.
3) Обучение команд миграции. После формирования команд миграции проводится их обучение работе с инструментами и технологиями миграции, включая практические занятия на стендовом оборудовании и изучение проектной документации.
4) Реестр объектов миграции. На данном этапе создается список автоматизированных систем, подлежащих миграции.
5) План-график. Совместно с администраторами автоматизированных систем составляется и согласовывается план-график миграции, выбранных систем.
Процедура миграции ВМ с платформы виртуализации VMware vSphere на Microsoft Hyper-V включает в себя несколько шагов, применяемых в зависимости от результатов работы скрипта миграции и соответствия автоматизированных систем показателям работоспособности после миграции (параметры работоспособности определяются Администраторами автоматизированных систем в зависимости от конкретной автоматизированной системы).
На рисунке 1 показана общая блок-схема организации миграции виртуальных нагрузок.
Способ №1 — Смена формата виртуальных жестких дисков. Данный способ предполагает использование автоматизированного метода преобразования жестких дисков утилитами УНОТоо1 и УНОХТоо1.
Оператор миграции авторизуется на ВМ сервера миграции (рабочее место мигра-тора) и запускает скрипт «М^гайоп.рБЪ» с указанием файла, содержащего список ми-грируемых ВМ, в качестве параметра. Список виртуальных нагрузок составляется на этапе подготовки к миграции.
На данном этапе миграция и конвертация виртуальных дисков происходит с минимальным простоем виртуальных машин, а именно, необходимо время для перезапуска виртуальной машины, установки компонентов интеграции, а также время для конвертации самих дисков. Расчетное время простоя одной виртуальной машины с одним диском на 150 ГБ при миграции составляет 10 минут. Ошибки миграции записываются в файл «Migration_Log.txt».
В случаях неудачной миграции и/или ошибок в ходе миграции, применяются процедуры восстановления виртуальных машин из резервной копии и переход к способу №2.
Способ №2 — Использование инструментов SCVMM для миграции. Данный этап также является автоматизированным, однако использует инструменты, предоставляемые продуктом БСУММ.
Я
2. Миграция
I
3. Проверка работоспособности АС
4. Откат ВМ АС
Миграция завершена
Отчет о миграции
Рисунок 1 - Общий подход к миграции.
Ь«р://е1 .kubagro.ru/2019/09/рсШ07.рс11'
В отличии от способа №1, виртуальные машины, мигрируемые данным методом, выключаются в самом начале миграции, поэтому период простоя получается существенно длиннее, однако это гарантирует целостность данных при возврате к первоначальному состоянию виртуальных машин в случае ошибок миграции. Расчетное время простоя одной виртуальной машины с одним диском на 150 ГБ при миграции составляет 1 час 40 минут.
Оператор миграции АС авторизуется на рабочей станции миграции (рабочее место мигратора) и запускает скрипт «М^гайоп.рБЪ» содержащий список мигрируемых виртуальных нагрузок в качестве параметра. Список виртуальных нагрузок составляется на этапе подготовки к миграции. Ошибки миграции записываются в файл «М grati on_Log.txt».
Проверка успешности миграции. После завершения этапов миграции операторы миграции проверяют общее состояние виртуальных нагрузок (проверка осуществляется автоматизировано):
- запуск виртуальной машины;
- загрузка операционной системы виртуальной машины;
- сетевые настройки и сетевую связность;
- соответствие оборудованию виртуальной машины до начала миграции.
Далее администраторы автоматизированных систем проверяют работоспособность виртуальных машин в соответствии с параметрами работоспособности (параметры работоспособности определяются администраторами автоматизированных систем в зависимости от конкретной автоматизированной системы), которые аналогичны использовавшимся до миграции.
Если обе проверки выполнены успешно, то миграция виртуальных машин автоматизированной системы считается успешной.
На рисунке 2 показана схема организации процесса проверки успешности миграции виртуальных нагрузок.
2. Миграция
3. Проверка работоспособности АС
Проверка работоспособности АС в соответствии с критериями
Анализ состояния ВМ
Анализ и исправление ошибок миграции
4. Откат ВМ АС
НЕТ-^
ВМ не может
быть мигрирована
I
Т
■ДА—|
Рисунок 2 - Схема организации процесса проверки успешности миграции виртуальных
нагрузок
Основные допущения. Процесс миграции виртуальных нагрузок автоматизированных систем с одной платформы виртуализации на другую включает в себя ряд допущений, описанных ниже.
Названия виртуальных машин на платформе виртуализации VMware vSphere уникальны. Таким образом не может возникнуть ситуации, когда на разных серверах vCenter находятся виртуальные машины с одинаковым именем. Если же такие виртуальные машины будут найдены в процессе миграции, то такая виртуальная машина будет пропущена, а ошибка запротоколирована.
Мигрируемые виртуальные машины на платформе VMware vSphere настроены на загрузку только через BIOS.
Мигрируемые виртуальные машины используют поддерживаемую ОС (Windows Server 2003 SP2 или старше либо совместимый дистрибутив Linux).
На время миграции техническая учетная запись «мигратора» (указывается при запуске скрипта) имеет права локального администратора на виртуальных машинах.
С сервера миграции до мигрируемых виртуальных машин существует сетевая связанность:
- есть маршрутизация;
- открыты необходимые порты на брандмауэрах.
Виртуальные машины имеют только одну виртуальную сетевую карту (vmNIC)
Все устройства хранения виртуальных машин должны быть подключены к виртуальной шине SCSI:
- если к шине IDE подключен виртуальный привод DVD, он будет автоматически удален из конфигурации ВМ;
- если к шине IDE подключен виртуальный жесткий диск, он будет переподключен к шине SCSI;
- если устройств больше 4 (максимальное количество для шины IDE), виртуальная машина не мигрируется, ошибка протоколируется.
Виртуальные машины не используют физические LUN (диски RDM).
Виртуальные машины должны быть запущены на момент начала миграции.
У виртуальных машин отсутствуют снимки состояния (snapshots).
Сеть, используемая виртуальными машинами, физически присутствует на целевых серверах Hyper-V как VLAN в режиме Trunk.
Целевые виртуальные машины на Hyper-V будут только первого поколения (Generation 1).
Все диски виртуальных машин после миграции будут «тонкими» (динамическими).
Таким образом, в результате нашего исследования был разработан новый авторский подход и инструмент миграции виртуальных нагрузок с платформы виртуализации VMWARE vSphere на платформу виртуализации Microsoft Hyper-V, позволяющий мигрировать виртуальные нагрузки с минимальным временем простоя и наиболее эффективно. Важнейшие рекомендации проведенного исследования были апробированы, внедрены и используются в настоящее время в ПАО «Сбербанк».
Список литературы
1. Алексанков С.М. Модели динамической миграции с итеративным подходом и сетевой миграции виртуальных машин [Текст] / С. М. Алексанков // Научно-технический вестник информационных технологий, механики и оптики. - 2015. - №6. -С. 1098-1104.
2. Федотов Е. А. Анализ методов виртуализации применяемых в инфраструктуре предприятия [текст] / Е. А. Федотов, В. Н. Федотова, М. И. Поляничка // Вестник магистратуры. - 2015. - №11(50).Т.1. - С. 57-59.
References
1. Aleksankov S.M. Modeli dinamicheskoj migracii s iterativnym podhodom i setevoj migracii virtual'nyh mashin [Tekst] / S. M. Aleksankov // Nauchno-tehnicheskij vestnik in-formacionnyh tehnologij, mehaniki i optiki. - 2015. - №6. - S.1098-1104.
2. Fedotov E. A. Analiz metodov virtualizacii primenjaemyh v infrastrukture predpri-jatija [tekst] / E. A. Fedotov, V. N. Fedotova, M. I. Poljanichka // Vestnik magi-stratury. -2015. - №11(50).T.1. - S. 57-59.
