Недавно компания VMware обновила свое решение Hybrid Cloud Extension (HCX), предназначенное для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud. Версия HCX 4.0 предоставляет возможности большего контроля над процессами миграции, минимизации времени простоя, а также упрощении реконфигурации политик безопасности VMware NSX после миграции.
Давайте посмотрим на новые возможности VMware HCX 4.0:
1. Новая система нумерации релизов и обновленные политики жизненного цикла
Теперь систему версий можно просто представить вот так:
Кроме того, изменились политики жизненного цикла VMware N-2 Lifecycle Policy, которые теперь учитывают новую систему версионирования. Каждый минорный и мажорный релиз HCX будет поддерживаться минимум 12 месяцев со дня выхода.
2. Оценка времени миграции
Теперь решение HCX в реальном времени может оценить время, которое вам понадобится на миграцию нагрузок в виртуальных машинах. Используя механику Mobility Groups, платформа HCX позволяет оценить время миграции каждой конкретной ВМ, составив из этих оценок прогноз по времени миграции группы.
Для первичного развертывания механизм Migration Estimation будет поддерживать только метод миграции Bulk Migration, а в будущем появится поддержка методов vMotion и Replication-Assisted.
3. Информация о событиях миграции
Для всех типов миграции (Bulk, vMotion, Replication-Assisted vMotion и OS-Assisted) предоставляется детальная информация об этих событиях. Там показаны данные всех событий, потоков рабочих процессов, также статусы текущих миграций и многое другое:
Такой уровень детализации очень поможет администраторам при решении проблем, связанных с миграцией рабочих нагрузок в облако. Более подробно об этом вы можете узнать из этого видео.
4. Инфоормация о виртуальных модулях Network Extension
HCX 4.0 предоставляет детальную информацию обо всех расширяемых сетях, реализуемых виртуальными модулями Network Extension (NE). Для них можно увидеть такие параметры, как bit rate, bytes transmitted и received, packet rate, packets transferred и received, с интервалом обновления в 1 минуту. Находится это на вкладке Network Extension Details в разделе Connection Statistics.
5. Перевод виртуальных модулей Network Extension в режим In-Service во время обновления
Виртуальные модули NE могут использоваться не только в процессе миграции, но и после него. Для таких ситуаций теперь есть специальный режим In-Service (как режим обслуживания в vSphere), который позволяет апгрейдить виртуальные модули, сокращая потенциальный простой инфраструктуры и минимизировать прерывания процессов.
6. Миграция тэгов NSX Security Tags
Пользователи VMware NSX Distributed Firewall на источнике миграции могут смигрировать тэги NSX Security Tags в инфраструктуру публичного облака. Это работает для методов миграции Bulk Migration, HCX vMotion, HCX Replication-Assisted vMotion (RAV) и cloud-to-cloud mobility migration. Существующие тэги могут быть на базе решений NSX for vSphere и NSX-T.
Демо процесса миграции тэгов можно посмотреть вот тут.
Ну и в завершение - полезные ссылки, включая ссылку на скачивание VMware HCX 4.0:
На днях компания VMware выпустила очередное обновление своей утилиты для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные) - Cross vCenter Workload Migration Utility 3.1. Напомним, что версия 3.0 этого средства выходила на VMware Labs в ноябре прошлого года.
Давайте посмотрим на новые возможности утилиты:
Поддержка конвертации форматов диска между Thick (Lazy Zeroed), Thick (Eager Zeroed) и Thin provisioning.
Поддержка шаблона переименования виртуальной машины при операциях клонирования.
Также появилась парочка багофиксов:
Устранена ошибка дубликата выбранной сети при пакетной миграции ВМ.
Исправлена ошибка запуска, когда указан новый домашний vCenter в качестве аргумента командной строки.
Напомним, что утилитой можно пользоваться через плагин в составе vSphere Client с интерфейсом на базе технологии HTML5, так и в отдельном графическом интерфейсе.
Скачать Cross vCenter Workload Migration Utility 3.1 можно по этой ссылке.
Вчера мы писали про выпуск новой версии решения VMware App Volumes 4, предназначенного для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам.
Одновременно с релизом этой платформы, на сайте проекта VMware Labs появилась новая утилита App Volumes Migration Utility, которая дополняет средства App Volumes по облегчению жизни администраторов, занимающихся обслуживанием решения.
Эта утилита позволяет смигрировать старые объекты AppStacks, в которых распространялись приложения в VMware App Volumes 2.18, на новый формат VMware App Volumes 4.0, который реализует концепцию приложений и пакетов. С помощью App Volumes Migration Utility можно сделать так, чтобы не потребовалось повторное развертывание приложений в среде App Volumes после миграции основного продукта.
Работать с утилитой просто. Вводим данные для входа:
Выбираем выходную файловую шару для пакетов:
Отмечаем доступные для миграции AppStacks и нажимаем кнопку Migrate:
Скачать App Volumes Migration Utility можно по этой ссылке.
На сайте проекта VMware Labs появилась еще одна утилита - Horizon DaaS Migration Tool 2.1. Она позволяет смигрировать ранние версии Horizon DaaS (6.1.5, 6.1.6, 7.0.0) на самую последнюю версию 8.0.0. Напомним, что Horizon DaaS - это продукт купленной компании Desktone.
Почему надо мигрировать на последнюю версию DaaS:
VMware Horizon DaaS 6.1.5, 6.1.6 скоро перестанет поддерживаться.
Клиенты на версии VMware Horizon DaaS 8.0.0 смогут обновиться на новые версии, для которых будут выходить новые фичи и апгрейд функциональности и безопасности.
Для миграции поддерживаются сценарии VMware Horizon DaaS 6.1.x и 7.0.0 на версию 8.0.0. Между тем, не поддерживаются следующие сценарии:
При миграции не поддерживаются Floating Desktops, поэтому их надо пересоздавать отдельно путем миграции золотых образов, после чего надо пересоздать пулы десктопов.
Миграция хостов RDSH и приложений. Их нужно мигрировать так же, как и Floating Desktops.
Функциональность Multi Data Center пока не поддерживается в Horizon DaaS 8.0.0.
Несколько Multi Desktop Managers не поддерживается для одного клиента.
Последние две возможности скоро будут доступны в обновленной версии Horizon DaaS. Скачать VMware Horizon DaaS Migration Tool 2.1 и инструкции по миграции можно по этой ссылке.
Об утилите Horizon Migration Tool мы уже несколько раз писали, версия 2.3 которой вышла в марте 2017 года. Спустя более чем два года, компания VMware выпустила обновленную версию Horizon Migration Tool 3.0.2, которая стала доступной на сайте проекта VMware Labs.
Напомним, что средство Horizon Migration Tool предназначено для миграции виртуализованных приложений и десктопов с платформы Citrix XenApp на платформу VMware Horizon View. В процессе миграции одна ферма Citrix XenApp переносится в одну или несколько ферм VMware View.
Давайте посмотрим, что нового появилось за 2 года в данной утилите:
Поддержка миграции с платформ Citrix на VMware Horizon 7.2.
Добавлена возможность миграции пулов десктопов Citrix PVS на платформу Horizon 7.2.
Добавлена возможность миграции пула Citrix Dedicate MCS Desktop Pool на платформу Horizon 7.2 как ручного пула (manual pool), пула связанных клонов (linked-clone pool) или пула мгновенных клонов (instant clone pool).
Исправлен баг, когда приложения XenApp с кастомными путями, содержащими пробелы, не мигрировались корректно.
Не так уж и много, но хоть что-то. Скачать VMware Horizon Migration Tool 3.0.2 можно по этой ссылке.
Недавно мы писали о выходе обновленной версии решения для обеспечения катастрофоустойчивости виртуальных датацентров VMware Site Recovery Manager 8.2. Многие пользователи после ее релиза задались вопросом миграции на виртуальный модуль (Virtual Appliance), который построен на базе операционной системы Photon OS и управляется через веб-браузер.
Давайте вкратце рассмотрим этот процесс. В целом процедура миграции выглядит так:
Убеждаемся, что ваш SRM на базе Windows обновлен до версии 8.2.
Экспортируем конфигурацию и останавливаем SRM на хосте с Windows.
Развертываем Site Recovery Manager Virtual Appliance и импортируем туда конфиг.
Пошагово этот процесс будет таким:
1. Логинимся в Site Recovery Manager for Windows, открываем командную строку и переходим в папку %SRM_INSTALL_DIR%\bin.
2. Запускаем следующий скрипт, он потребует ввод пароля администратора:
export-srm-data.bat
3. Экспортированную папку перемещаем на виртуальный модуль SRM.
4. Выключаем машину с SRM для Windows и логинимся как root в SRM VA.
5. Если вы создавали кастомные сертификаты, то их надо положить в папку /etc/ssl/certs (это файлы с расширением .pem). Импортировать сертификаты можно через Site Recovery Manager Appliance Management Interface.
Для изменения прав доступа к сертификатам используйте команду:
chmod a+r <new-root-ca>.pem
Далее выполните:
c_rehash
6. После этого запустите импорт окружения SRM, указав папку, которую вы экспортировали из Windows-окружения:
7. Вас попросят пароль администратора vCenter Single Sign-On, root виртуального модуля, а также пароль от файла, который был задан при экспорте конфигурации.
8. На вкладке Home веб-консоли решения SRM VA выберите импортированную пару сайтов и нажмите Actions > Reconnect. Выберите первый сайт из списка, введите адрес Platform Services Controller сервера SRM на резервной площадке и введите имя пользователя и пароль.
9. Далее вас попросят выбрать сервер vCenter, который нужно настроить и его сервисы, где вы просто нажимаете Next, а потом Finish.
Как многие из вас знают, VMware vCenter для Windows версии 6.7 (на данный момент Update 1) - это последний vCenter, который еще доступен как отдельный продукт для Windows-машины. Следующая версия vCenter будет поставляться только как виртуальный модуль vCenter Server Appliance на базе Photon OS от VMware.
Мы уже писали о некоторых аспектах миграции на vCSA с vCenter for Windows, но в этом посте дадим несколько новых деталей по этому процессу. VMware рекомендует выполнить 2 основных шага миграции с vCenter на vCSA:
Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.
Полный обзор процесса миграции показан в видео ниже:
Обратите внимание, что во время миграции вы можете выбрать опцию импорта исторических данных из старой копии vCenter for Windows в созданную новую копию vCSA (это опциональный процесс во время миграции, и можно сделать импорт уже позднее).
Migration Tool делает импорт всех скопированных данных в развернутый виртуальный модуль vCSA (включая параметры идентификации vCenter, такие как FQDN, IP-адрес, UUID, сертификаты, MoRef IDs и прочее). Также происходит миграция и vSphere Distributed Switch (vDS).
Надо отметить, что в процессе миграции не происходит никаких изменений в исходном vCenter, поэтому откат в случае неудачного обновления прост - останавливаете vCSA и продолжаете использовать vCenter Server for Windows.
Помимо всего этого есть утилита vCenter Server Converge Tool (о ней мы писали тут и тут), которая позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC. Проблема заключалась в том, что ранее администраторы использовали внешний PSC, поскольку он поддерживал Enhanced Linked Mode (ELM). И несмотря на то, что внедренный PSC стал поддерживать ELM еще в vSphere 6.7 и vSphere 6.5 Update 2, многие пользователи еще с предыдущих версий поддерживают комплексную инфраструктуру внешних PSC с репликацией между площадками.
Сейчас все стало проще - утилита vCenter Server Converge Tool устанавливает embedded PSC на vCenter Server Appliance (vCSA), после чего налаживает канал репликации с оставшимися внешними PSC. После того, как эта процедура пройдет на всех площадках, вы сможете отключить внешние PSC, а встроенный механизм vCenter HA сам настроится на работу с внедренными PSC.
Пройтись по шагам различных вариантов миграции vCenter и его PSC (встроенного или внешнего) можно вот в этих обучающих материалах VMware (там вы все это можете прокликать прямо в интерфейсе):
Кстати, надо понимать, что процесс миграции vCenter - это одновременно и его апгрейд. То есть вы можете, например, провести миграцию-апгрейд vCenter Server 6.0 на VCSA версии 6.7.
Ну и помните, что весь самый новый функционал есть только в VMware vCSA, который является рекомендуемым вариантом развертывания по умолчанию. Вам уже давно пора перейти на vCSA, если вы все еще пользуетесь vCenter для Windows.
Это может пригодиться, например, при перемещении профилей пользователей из окружения для разработки и тестирования в производственную среду по завершении цикла тестирования.
Чтобы собрать необходимые данные для соединения с консолями UEM нужно сделать следующее:
Получить API URL источника и назначения в настройках консоли UEM: All Settings -> System -> Advanced -> URLS -> Rest API
Получить Tenant Key источника и назначения: All Settings -> System -> Advanced -> API -> REST API -> API Key (admin)
Создать административного пользователя и экспортировать сертификат на источнике и назначении. Для этого идем в Users -> Admins -> Add Admin->
Role – REST API или AirWatch Administrator.
API-> Use Certificate и задаем для него пароль.
Нажимаем Save.
Идем обратно в Admin на вкладке API, чтобы экспортировать сертификат с заданным паролем в формат p12.
Перемещаем 2 сертификата в формате p12 в распакованную папку с утилитой.
Надо помнить, что не все типы профилей поддерживаются для миграций с помощью этой утилиты, поэтому она может выдать ошибку (поскольку некоторые профили AirWatch не поддерживает сам Get Profiles API).
Скачать Workspace ONE UEM Profile Migration Utility можно по этой ссылке.
В статье «Миграция в облако» мы рассказывали о частичном и полном переходе на облачную площадку, рассматривали примеры реальных кейсов, затрагивая наиболее распространенные ошибки. Сегодня поговорим о том, какие инструменты помогают мигрировать между различными облаками и когда возникает такая необходимость.
Зачем мигрировать
На практике нередки ситуации, когда требуется перенести виртуальные машины с одной площадки на другую, например из частного облака компании в публичное облако IaaS-провайдера. Это актуально и тогда, когда наблюдается мгновенная нехватка собственных ресурсов или клиент решает сменить поставщика облачных услуг. Миграция между облаками также может быть вызвана изменениями в законодательстве. К слову сказать, многие иностранные компании, осуществляющие деятельность на территории РФ, размещали собственные информационные системы, а с ними и персональные данные россиян на зарубежных облачных площадках. Но с выходом ФЗ-152 «О защите персональных данных» потребовалась миграция в облака российских поставщиков.
Так, известная во всем мире компания VBH («Фаубеха») — крупнейший дистрибьютор товаров и услуг для оконных, дверных производств — столкнулась с задачей внедрения нового на тот момент ERP-решения Microsoft Dynamics Axapta 2009. Компания размещала собственную инфраструктуру в облачном дата-центре на территории Германии. Используя единое облачное пространство, удалось создать стандартизированную инфраструктуру с такими ERP-решениями, как Microsoft Dynamics Navision, Axapta, 1С и SAP.
С выходом нового закона, который обязал хранить персональные данные на территории Российской Федерации, потребовалось перенести часть систем в Россию. Сервис в результате разместился на площадке российского облачного провайдера «ИТ-ГРАД». Об опыте подобных переездов расскажем ниже. Читать статью далее ->>
Летом прошлого года мы писали об утилите Horizon Migration Tool, которая предназначена для миграции виртуализованных приложений и десктопов с платформы Citrix XenApp на платформу VMware Horizon View. В процессе миграции одна ферма Citrix XenApp переносится в одну или несколько ферм VMware View.
На днях на сайте проекта VMware Labs вышло обновление - Horizon Migration Tool версии 2.3, давайте посмотрим, что там появилось нового:
Добавлена поддержка миграции XenApp 7.6 и более поздних версий на платформы Horizon 7 и Horizon 7.1.
Добавлена поддержка миграции XenDesktop 7.6 и более поздних версий на платформы Horizon 7 и Horizon 7.1.
Добавлена поддержка миграции XenDesktop 7.6 и более поздних версий на Horizon Cloud Egon и Ferris.
На данный момент поддерживаются следующие типы пулов виртуальных десктопов:
Citrix:
Manual pool
Random machine creation service pool
Horizon 7:
Manual pool
Automated linked clone pool
Automated instant clone pool
Скачать последнюю версию Horizon Migration Tool 2.3 можно по этой ссылке.
Напомним, что на сайте проекта VMware Labs с начала прошлого года доступен VCS to VCVA Converter, который позволял делать миграции в режиме технологического превью. Теперь же это средство - официально поддерживаемый продукт VMware в составе vCenter, а сам Fling на VMware Labs помечен как Deprecated.
Кстати, Update 2m (Migration) не предоставляет возможностей чистой установки vCSA, поэтому загружать его нужно только тем, кто планирует именно миграцию сервисов физического или виртуального vCenter. Вот так выглядит установщик 2m по сравнению с обычным Update 2:
А вот так выглядит таблица возможных миграций на виртуальный модуль vCSA (обратите внимание, что поддерживается только версия 5.5):
vCenter Server Appliance 6.0 Update 2 with external Platform Services Controller
vCenter Single Sign-On 5.5 + vCenter Server 5.5
vCenter Server Appliance 6.0 Update 2 with embedded Platform Services Controller
Возможности VMware vCenter Server to vCenter Server Appliance (VCSA) Migration Tool:
Поддержка виртуального и физического vCenter Server 5.5 (для vSphere 6.0 скоро будет отдельный апдейт).
Поддержка VMware Update Manager (VUM) - если VUM установлен как вненшний сервис, ничего в процессе миграции делать не нужно, если же он размещен вместе с vCetner Server - его нужно вынести в отдельный сервер.
Использование Migration Assistant в ОС Windows, где установлен vCenter Server, для обеспечения процесса миграции.
Выполнение пре-миграционных проверок на исходном vCenter Server перед началом процесса миграции.
Использование vCenter Server или ESXi для развертывания нового виртуального модуля vCenter Server Appliance.
2 варианта в процессе миграции:
Только основные данные vCenter Server Inventory
Все данные, включая данные о производительности, а также история (Tasks and Events).
Поддержка внешней или внедренной базы данных на исходном Windows vCenter Server:
Microsoft SQL Server
Microsoft SQL Express
Oracle
Миграция базы данных vCenter на embedded PostgreSQL на целевом vCSA.
Миграция всей регистрационной информации для расширений vCenter (но некоторые расширения надо будет перерегистрировать).
Возможность отката к окружению обычного vCenter Server.
Сохранение всех настроек: IP-адреса, FQDN, UUID, сертификатов, идентификаторов MoRef ID.
Скачать VMware vCenter Server 6.0 Update 2 Migration можно по этой ссылке. Документация доступна тут. А вот тут написано о том, как оценить примерное время миграции для планирования простоя сервисов управления виртуальной инфраструктурой.
Как вы знаете, в VMware vSphere 5 есть возможность динамической миграции хранилищ виртуальных машин - Storage vMotion. Эта возможность позволяет не только без простоя перенести виртуальные машины между хранилищами и их LUN, но и изменять формат результирующего виртуального диска (thin или thick).
В этой заметке мы рассмотрим один из интересных аспектов миграции Storage vMotion - перенесение томов RDM (Raw Device Mapping) виртуальных машин, работающих в режиме виртуальной и физической совместимости (physical and virtual RDMs).
Также перенос хранилища виртуальной машины мы можем сделать не только в "горячем" режиме, но и в "холодном" с помощью функции Cold Migration (для выключенной ВМ). В этом случае мы также можем выбрать формат виртуального диска результирующей ВМ. Давайте посмотрим как эти условия влияют на перенос RDM томов во всех случаях.
Перенос включенных ВМ с физическим RDM (pRDM) средствами Storage vMotion:
Если вы пытаетесь изменить формат результирующего диска - Storage vMotion будет сделать нельзя.
Если вы не пытаетесь изменить формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос включенных ВМ с виртуальным RDM (vRDM) средствами Storage vMotion:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с физическим RDM (pRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том pRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с виртуальным RDM (vRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Таким образом, у нас получается 3 ситуации, когда исходный RDM-том конвертируется в VMDK-диск на целевом томе, при этом в мастере миграции вас никто об этом не предупреждает.
Также есть еще один аспект при миграции таких томов. Если исходный RDM-том находился в режиме Independent Persistent (а pRDM обязательно в этом режиме находится), то, как следует из свойств этого диска, он не участвует в создании снапшотов ВМ.
После миграции, если он будет сконвертирован в vmdk-файл, то он также останется в этом режиме:
А это значит софт для резервного копирования виртуальных машин не будет бэкапить такой диск, поскольку он не участвует в создании снапшота. Учитывайте этот момент.
Мы уже писали о новых возможностях Hyper-V 3.0, которые появятся в готовящейся к выходу серверной платформе Windows Server 8, список которых позволяет говорить о серьезной конкуренции с платформой VMware vSphere в будущем.
Одна из таких интересных возможностей - это Live Storage Migration, которая позволяет перенести хранилище работающей виртуальной машины с сервера на сервер (при использовании локальных дисков) или между томами СХД (аналогом этой функции является Storage vMotion у VMware, которая доступна, начиная с издания vSphere Enterprise).
У Алексея Кибкало в блоге появился интересный обзор Live Storage Migration в Hyper-V 3.0 Developer Preview, в котором утверждаются, что данная функция (как и простой Live Migration) будет доступна бесплатно, в том числе в бесплатном издании Microsoft Hyper-V Server. При этом для работы Live Storage Migration и Live Migration не потребуется создавать кластеры.
Второй интересный момент - при миграции хранилища предоставляются гибкие возможности по переносу снапшотов. Можно перенести снапшоты, оставив оригинальный диск виртуальной машины на старом хранилище, можно перенести машину, оставив старые снапшоты, при этом все они останутся доступными для виртуальной машины:
Вообще, субъективно, Hyper-V 3 начинает мне нравится все больше и больше. Особенно на фоне офигевшей ценовой политики VMware в России. Понятно, что крупные компании с этой иглы уже не снимешь, а вот в среднем и малом бизнесе, похоже, назрели большие перемены в сфере виртуализации.
Таги: Microsoft, Hyper-V, Бесплатно, Storage, Live Migration, Blogs, SMB
На прошедшей конференции Build компания Microsoft раскрыла некоторые детали о новых возможностях своей обновленной платформы виртуализации на базе Hyper-V 3.0 в составе серверной ОС Windows Server 8.
В Hyper-V 3.0 появится множество интересных возможностей в сфере серверной виртуализации и VDI-инфраструктуры:
Поддержка до 160 логических процессоров на хостах Hyper-V
Поддержка до 2 ТБ RAM хост-сервера
Поддержка до 32 виртуальных процессоров виртуальных машин (vCPU) и до 512 ГБ оперативной памяти на одну ВМ
Поддержка технологии NUMA в гостевой ОС, что позволяет повысить производительность виртуальной машины
Поддержка нескольких одновременных "горячих" миграций (Live Migration)
Поддержка техники Storage Live Migration - миграция хранилища виртуальной машины без прерывания ее работы (это будет работать без необходимости наличия общего хранилища - на локальных дисках за счет встроенных возможностей репликации)
Новый формат виртуальных дисков VHDX, который позволяет создавать виртуальные диски объемом до 16 ТБ (вместо 2 ТБ в формате VHD). Также новый формат будет более производительным, надежным и поддерживать работу с большими блоками
Технология Offloaded Data Transfer (ODX), которая позволяет передать на сторону дискового массива операции по работе с хранилищами виртуальных машин (у VMware подобная технология называется vStorage API for Array Integration, VAAI)
Обновленный виртуальный коммутатор, предоставляющий расширенные возможности по виртуализации сетевого окружения виртуальной машин и возможности ее переносимости между облачными инфраструктурами (нечто похожее на технологию VXLAN от VMware и Cisco)
Поддержка виртуальных адаптеров (Virtual Fibre Channel) для виртуальных машин (до 4), через которые ВМ могут получить прямой доступ к LUN посредством Multi-Path I/O (MPIO). Также будут виртуальные Fibre Channel-коммутаторы
Поддержка загрузки хостов через Fiber channel и iSCSI SAN.
Поддержка технологии SR-IOW для привилегированного доступа к PCI-устройствам
Расширенные средства мониторинга производительности (CPU Metering и другое)
Пулы ресурсов для кластеров (Resource pools)
Поддержка дедупликации данных, позволяющей сократить тебуемое виртуальными машинами пространство на системе хранения, без существенной потери производительности. Это позволит также уменьшить окна резервного копирования
Прямая передача данных между хостами за счет Offloaded Data Transfer
Поддержка NIC Teaming и load balancing для создания виртуальных сетей на хосте (ранее это делалось с помощью сторонних драйверов)
Поддержка массивов JBOD и тонких дисков на JBOD (Thin Provision)
Поддержка средства Bitlocker для кластерных дисков
Новая версия файловой системы Cluster Shared Volume (CSV) 2.0 со встроенной поддержкой дедупликации и создания снапшотов со стороны массивов
Средство в GUI для управления IP-адресами (IPAM)
Поддержка CIFS/SMB-хранилищ с использованием протокола Remote Direct Memory Access (RDMA)
Технология Hyper-V Replica, позволяющая организовать асинхронную репликацию виртуальных машин (напомним, что в Veeam Backup and Replication 6 также будет такая возможность)
Поддержка технологии RemoteFX для RDP-сессии с хостом, улучшенная компрессия трафика для WAN-каналов
Возможность создания базового образа для виртуальных ПК (gold master image). Индивидуальные сессии пользователей могут быть настроены с помощью перемещаемых профилей (roaming profiles)
Поддержка до 63 хост-серверов и до 4000 виртуальных машин в кластере
Поддержка графических библиотек DirectX 10, OpenGL 1.1 и технологии Metro UI в виртуальных машинах
Службы Active Directory будут доработаны под виртуализацию (поддержка снапшотов ВМ, виртуализация контроллеров домена и их клонирование)
Встроенный брокер соединений с возможностью балансировки сессий
Возможность включения и отключения GUI сервера, превращая его в Server Core (и обратно)
Поддержка распределенного виртуального коммутатора Cisco NEXUS 1000V, который будет специально разработан под Windows Server 8
О Cisco NEXUS 1000V под Hyper-V можно почитать вот в этой статье.
Очевидно, что компания Microsoft сделала очень большой шаг на пути конкуренции с VMware vSphere, замахиваясь уже не только на сегмент среднего и малого бизнеса, но и на корпоративный сектор.
Windows Server 8 можно скачать как Developer Preview по этой ссылке.
Некоторые пользователи серверов хранения iSCSI на базе Microsoft iSCSI Target хотели бы перейти на StarWind Enterprise (тем более, что есть бесплатная версия StarWind). Но есть одна проблема - Microsoft iSCSI хранит свои данные в виде VHD-дисков, а у StarWind - формат IMG.
Специально для этого в StarWind и сделали утилиту StarWind V2V Converter, которая справляется с задачей конвертации VHD2IMG:
Оригинальные VHD тоже неплохо бы оставить в целях бэкапа.
Таги: StarWind, Enterprise, Migration, V2V, iSCSI, Storage, Microsoft
Мы уже вам надоели с необходимостью подготовки миграции вашей виртуальной инфраструктуры VMware vSphere с хостов ESX на ESXi (поскольку vSphere 5 будет только на базе ESXi), но, все-таки, пролжим деятельность в этом направлении.
Мы уже писали о средстве PXE Manager for vCenter, имеющемся на сайте проекта VMware Labs. Оно нужно для автоматизации развертывания хостов VMware ESXi (Stateless или Stateful) по PXE. Говорят, что утилита войдет в состав VMware vSphere 5. Работает оно только с хостами VMware ESXi, но в версии 4.1 Update 1 утилита получила функцию по миграции хостов ESX на ESXi:
Теперь в утилиту можно добавить хост ESX (предварительно вы уже должны создать образ ESXi):
А далее просто выбрать пункт "Convert this ESX Server to VMware ESXi Server". Дальнейший процесс миграции со скриптом постконфигурации описан в статье Andy Grant "PXE Manager Howto: Converting ESX hosts to ESXi".
Я уже, наверное, набил вам оскомину, но снова повторюсь - в версии VMware vSphere 5, которая выйдет в августе-сентябре (в подтверждение этому - посмотрите на книжку на Amazon, которая выходит 7 сентября), уже не будет платформы виртуализации VMware ESX. Останется только "тонкая" платформа VMware ESXi. Поэтому всем организациям необходимо планировать миграцию с ESX на ESXi. Об этом у нас есть серия постов:
В нем нам рассказывают о том, как нужно управлять виртуальной инфраструктурой VMware vSphere на базе VMware ESXi, и какие методики используются в сравнении с моделью управления на классическом ESX:
Для готовящихся к миграции и имеющих различные скрипты и агентов в сервисной консоли серверов ESX - читать обязательно.
Как вы уже знаете, VMware vSphere 5 будет уже только на базе гипервизора ESXi, а выпуск продукта ESX прекращается (версия 4.1 - последняя на базе этой платформы). Поэтому тем, кто еще не перешел на VMware ESXi нужно задумываться о миграции.
Мы уже писали на тему того, как перейти с ESX на ESXi (тут, тут и тут), а сегодня расскажем в общих чертах о плане миграции таких хост-серверов и о том, что делать после установки нового ESXi (пост-миграционные процедуры).
Интересный пример совместного использования технологий HP и Microsoft показал нам Calvin Zito. За счет Live Migration в Hyper-V и репликации в массивах HP EVA происходит перемещение виртуальных машин между датацентрами (и серверами, и хранилищами). И все это делается на большие расстояния!
Итак, Long Distance Cluster Extension EVA Live Migration with Hyper-V:
Таги: Microsoft, Hyper-V, HP, Live Migration, Storage, Hardware, Replication, VMachines
История взаимоотношения вендоров и их партнеров-реселлеров - это всегда сложная история. С одной стороны вендор хочет, чтобы его продукты и услуги были настолько просты для потребления, чтобы их купило как можно больше заказчиков (как варинат - консультанты становятся не нужны). С другой стороны, партнер хочет обладать неким эксклюзивным преимуществом перед заказчиком (профессионализм исполнителей - не всегда выше, чем у ИТ-службы заказчика), которое позволит ему выполнить как можно больше проектов с высокой маржой (сравните маржинальность поставок ПО и проектной деятельности). Идеальный вариант, устраивающий и вендора и интегратора - поставка лицензий с одновременным выполнением проекта (при этом, кхе-кхе, желательно средствами дешевой рабочей силы от третьей стороны - чтобы осталось только перекладывать бумажки).
Вывод из этого очень простой: поскольку партнеры вендора - это, все-таки, драйвер его бизнеса, ему нужно дать инструменты (эксклюзивные), с помощью которых он сможет, во-первых, поднять экспертизу и не слажать перед заказчиком в бою, а, во-вторых, прийти на площадку клиента и сделать все по-быстрому и в срок. Это, кстати, очень хорошая практика, постичь которую дано не каждой большой компании, особенно российской.
Казалось бы компания VMware немного забыла о нас в этом году (во второй его половине) - минорное обновление Capacity Planner и VMware Health Analyzer, это, все же, маловато. А заказчики говорят, что они сами с усами и все умеют внедрять...
Так вот новости с VMware Partner Advisory Board, прошедшего на VMworld 2009 в Сан-Франциско, обрадовали нас уже тогда - компания VMware выпустит VMware Migration Manager, который позволит централизованно исполнять и контролировать миграции физических серверов в виртуальную среду (P2V) на площадке клиента и выглядеть при этом круто, как настоящий консультант.
Так вот - ждать осталось недолго. VMware Migration Manager уже почти скоро сможет работать для ваших проектов по P2V-миграции, разумеется, с помощью партнеров VMware. VMware Migration Manager - это веб-консоль, с помощью которой можно как инициировать процесс загрузки обработанной (видимо, с помощью Capacity Planner) информации аппаратного и программного окружения физической инфраструктуры, централизованно управлять процессом P2V-миграции физических систем на сервера VMware vSphere / ESX, осуществлять трэкинг проекта P2V, строить отчеты о текущем статусе и финальные. Также есть Migration Console & Accelerator Toolkit, который содержит в себе множество скриптов и утилит для ускорения процесса P2V-миграции со стороны партнера.
Большая P2V-миграция это вам не кое-что, а серьезный процесс:
И выполнять его надо централизованно и с помощью комплекса специализированных средств:
Компания Sun выпустила очередной релиз платформы VirtualBox 3.1, который обладает эксклюзивной для hosted-платформ (поверх хостовой ОС) функциональностью гипервизора. В VirtualBox 3.1 появились функции "горячей" миграции виртуальных машин между хостами, сама возможность получила название Teleportation. Необходимость этой возможности пользователям настольных платформ виртуализации пока остается под сомнением.
Виртуальные машины на хостах с установленным VirtualBox 3.1 для использования Teleportation должны иметь доступ к общему хранилищу FS/CIFS, iSCSI или Fibre Channel. Важное изменение претерпела и лицензия на VirtualBox 3.1, теперь это не GPL, а VirtualBox Personal Use and Evaluation License (PUEL).
Экспериментальная поддержка виртуального EFI (для запуска гостевых ОС Mac OS X)
Поддержка 2D-ускорения для гостевых ОС Windows с использованием графической карты хоста
Поддержка паравиртуализованны сетевых адаптеров с драйверами virtIO (эти драйверы доступны как часть проекта по доработке гипервизора KVM, который ведет Rad Hat, для гостевых ОС Windows 2000, XP, Vista и Linux kernels 2.6.25 или более поздних)
Таги: Sun, Oracle, VirtualBox, Teleportation, Live Migration
Уже многим известно, что гипервизор Hyper-V R2 в ОС Windows Server 2008 R2 умеет динамически перемещать виртуальные машины между хост-серверами. Эта возможность называется Live Migration, реализуется она с помощью гибридной файловой системы CSV (Cluster Shared Volumes). Но прежде чем начать использовать Live Migration виртуальных машин, необходимо выполнить следующие действия:
Установить Windows Server 2008 R2 и включить роль сервера Hyper-V на всех узлах failover cluster. Описание процедуры приведено в документе Hyper-V Planning and Deployment Guide.
На видео ниже описана вся процедура настройки Microsoft Hyper-V от двух "голых" серверов до кластера с горячей миграцией (процедура длится около 1 часа)...
Да, именно так. Hyper-V 2.0 RTM в составе Windows Server 2008 R2 RTM с горячей миграцией Live Migration между хостами уже готов и в самое ближайшее время должен стать доступен для загрузки на партнерском портале Microsoft. Если вы не являетесь партнером Microsoft - придется ждать до 22 октября. Кстати и Windows 7 RTM уже готов.
Какие возможности включает в себя Hyper-V 2.0 из Windows Server 2008 R2:
Поддержка горячей миграции Live Migration
Поддержка горячего добавления виртуальных дисков VHD
Поддержка до 64 логических процессоров (8 ядер на 8 физических CPU)
Коллеги из Microsoft порадовали интересной новостью. Гипервизор Hyper-V в ОС Windows Server 2008 R2 будет поддерживать возможности живой миграции (Live Migration) между различными процессорами... Таги: Microsoft, Hyper-V, Live Migration, Intel, AMD
RSS
