Самое интересное из арсенала vSphere 6

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

Начнем мы с изменений, коснувшихся технологии Fault Tolerance (FT), которая позиционировалась как усиленная версия vSphere High Availability для бизнес-критичных серверов. Идея была в том, чтобы в мгновение ока обеспечить переключение на резервную ВМ при неполадках с основной машиной.

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

Улучшенный механизм Fault Tolerance должен решить и эту проблему. Теперь поддерживается 4 процессора и до 64 ГБ памяти на машину. Увеличение числа vCPU потребовало пересмотра синхронизации процессоров и памяти. Если раньше использовался механизм повторения инструкций на резервной ВМ, то теперь была внедрена новая схема Fast Checkpointing, которая выполняет инструкции одновременно на обеих виртуальных машинах.

Среди прочих улучшений FT дополнительно стоит выделить поддержку технологии мгновенных снимков виртуальной машины и бэкапа по VADP. Теперь можно использовать привычные инструменты резервного копирования на уровне образа ВМ.

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

Раньше нельзя было перенести виртуальную машину на другой управляющий сервер vCenter, теперь же такая возможность появилась, при этом дополнительно произойдет корректная передача метаданных (настройки HA, правила DRS и т. д.).

Также появилась возможность переносить машину между виртуальными коммутаторами vSS (Standard switch) и vDS (Distributed switch) в различных комбинациях. Исключением тут будет лишь вариант перехода от vDS к vSS – vDS содержит дополнительные метаданные, которые стандартным коммутатором просто не будут восприниматься.

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

Что касается библиотеки дистрибутивов, то она стала глобальной. В шестой версии vSphere нам предложен довольно интересный инструмент Content Library. Идея проста: объединить между всеми vCenter репозитории нужных дистрибутивов. Таким образом, полностью отпадает необходимость искать где-то забытый образ ОС или шаблон для нового стенда.

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

Также стоит упомянуть, что с релизом vSphere 6 VMware вывела на рынок одну из наиболее обсуждаемых технологий хранения – Virtual Volumes (VVol). Идея заключается в том, чтобы управлять политиками хранения на уровне виртуальных машин, а не datastore. Инсталляции с VVol помогут упростить операционные задачи, повысить эффективность распределения дисковых ресурсов и перейти на более гибкие инструменты управления.

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

Когда в качестве хранилища используются разделяемые внешние устройства, datastore практически всегда строится из одного большого LUN. При этом такой большой раздел является самым маленьким логическим элементом в СХД. На невиртуализированных системах детализация на уровне LUN была вполне приемлемой, так как на каждый том приходился всего один сервер.

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

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

Для решения проблемы VMware изменила подход к работе с дисками, реализовав технологию виртуальных томов. В первую очередь, на новых томах иначе хранится сама виртуальная машина. Каждый диск размещается в невидимом для администратора логическом каталоге на СХД. Причем не просто как файл на разделе VMFS – для каждого виртуального диска VMDK создается что-то вроде собственного LUN.

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

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

Остается открытым вопрос: как связаны VAAI API для блочных устройств, который улучшал производительность VMFS, делегируя часть операций дисковому массиву, и VVol? При работе с виртуальными томами хост ESXi контролирует не только поток данных, но и управляющий канал до массива. Таким образом, VVol выглядит как более продвинутое расширение интерфейса VAAI NAS.

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

Благодаря VVol системы хранения теперь знают о наличии виртуальных дисков и могут создавать снимки, клоны и занулять определенные VMDK.
Что касается VAAI NAS и VVol, то, в отличие от блочного варианта, все функции VAAI NAS предоставляются через вызовы RPC с помощью плагина от производителя СХД. VVol расширяет эту модель набором VASA API, что позволяет передать хранилищу управление всеми операциями vSphere.

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

Резюмируем, какие новые функции предоставила VMware в продукте vSphere:

• Был улучшен механизм Fault Tolerance: появилась новая схема Fast Checkpointing, а также добавлены технологии мгновенных снимков ВМ и нормального бэкапа через интерфейс VADP.
• Улучшения в инструменте vMotion: появилась возможность переноса машины между виртуальными коммутаторами и на другой управляющий сервер vCenter.
• Появление инструмента Content Library, объединяющего между всеми vCenter репозитории нужных в работе дистрибутивов.
• Технология VVol, изменившая подход к размещению виртуальных машин.
• В новой версии своего флагманского продукта VMware добавила немало серьезных нововведений и сделала значительный шаг на пути к виртуализации критичных приложений.

P.S. Другие материалы из нашего блога на Хабре:

ссылка на оригинал статьи https://habrahabr.ru/post/280862/