Вход|Регистрация

Неразборчивое о виртуальном

Fusion Sphere testing. Part 2

Пятница, 26 июня 2015, 20:38
Disclaimer: в данной статье приводится исключительно личное мнение автора данного блога. Оно может не совпадать с официальной позицией его работодателя и/или компаний-партнёров.
<----------------------------------------------->
Функции непрерывности и отказоустойчивости, реализованные во Fusion Compute.

1. vMotion.

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

Условия миграции из официальной документации:

В целом, технология миграции находится на уровне vSphere 4.x. Нет распараллеливания потоков по нескольким аплинкам и аналогов Long Distance vMotion.

2. Storage vMotion

В среде виртуализации Fusion Compute все хранилища делятся на два типа:

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

Различия двух типов заложены где-то в файловой системе среды виртуализации и никак не зависят от типа подключения СХД и протоколов доступа к нему (FC SAN, iSCSI, NAS, local HDD).

“Горячий” перенос дисков ВМ между хранилищами возможен только для хранилищ типа “virtualized”. При этом, весьма неприятным моментом для нас стало то, что "родной" для платформы тип распределённого хранилища Fusion Storage, отдаёт разделы, которые в имевшемся у нас релизе не могли быть размечены как virtualized.

3. High Availability

Для каждого кластера среда виртуализации позволяет использовать один из двух механизмов высокой доступности:

  • VRM-dependent
  • VRM-independent

В первом случае сервис VRM отслеживает доступность хостов виртуализации по сети и, при необходимости, перезапускает ВМ, работавшие на отказавшем хосте. При выходе из строя самого VRM (или хоста с ним), роль арбитра берёт на себя пассивная нода VRM. Если вас сильно не повезло (например отказал Power Domain в блейд-шасси), обе упавшие ноды VRM уже не будут перезапущены.

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

Логика работы VRM-independent механизма высокой доступности в общих чертах схожа с реализацией VMware HA. Главное ограничение, заключается в том, что все датасторы в кластере (включая локальные!) должны быть подключены в режиме “virtualized”.

Настройка резервирования ресурсов кластера для ВМ с отказавшего хоста производится практически идентично с реализацией в VMware vSphere.

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

4. Distributed Resource Scheduler

В решении FusionCompute реализован механизм ручной и автоматической балансировки нагрузки между хостами виртуализации, объединёнными в единый кластер. Балансировка обеспечивается выбором хоста при запуске ВМ и горячей миграцией ВМ между хостами при превышении порогового значения использования ресурсов процессора и памяти:

Существует три режима учёта дисбаланса ресурсов:

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

Интенсивность миграции и задержку реакции системы на "случайные" пики нагрузки можно регулировать в графическом интерфейсе от уровня Conservative до Radical с дискретностью один час. Такая маска допустимой балансировки может быть применена к каждому дню, к определённым дням недели, либо к конкретным числам каждого месяца.

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

5. Maintenance Mode

Среда виртуализации имеет возможность перевести хост виртуализации в режим обслуживания. Логика работы данного механизма отличается от реализации VMware:

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

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

Написать комментарий

Fusion Sphere testing. Part 1

Вторник, 16 июня 2015, 19:12
Disclaimer: в данной статье приводится исключительно личное мнение автора данного блога. Оно может не совпадать с официальной позицией его работодателя и/или компаний-партнёров.
<----------------------------------------------->
1. Fusion Compute. Среда виртуализации.
Серверная виртуализация в продукте Huawei работает на базе кастомизированного образа гипервизора Xen.
Версия гипервизора, прямо скажем, не самая свежая. Дата её релиза: октябрь 2011. Актуальная версия на сайте xenproject.org – 4.5.x Штатных методов доустановки патчей на Xen во Fusion Sphere мне найти не удалось. Возможно, его можно доустановить вручную, но нет никакой гарантии, что после этого не отвалится интеграция с остальными компонентами системы. Установка хостов происходит в привычном псевдографическом интерфейсе и не должна вызвать каких-либо сложностей, кроме сценария использования среды виртуализации совместно с Fusion Storage. Для такого случая надо учесть что настройки Dom0 должны ещё при установке выбираться в соответствии с будущей ролью хоста (управляющие ноды, только вычислительные ноды, вычислительные ноды с ресурсами хранения).

2. Fusion Compute. Централизованное управление.

Управление хостами осуществляется сервисом Virtual Resource Manager (VRM). Сервис функционирует в виртуальной машине -- виртуальном аппаинсе. Отказоустойчивость VRM обеспечивается созданием пассивной ноды VRM на другом хосте виртуализации, выполняемым при инсталляции активной ноды VRM. Визард установки сам соберёт указанные два хоста в "управляющий" кластер. Но при желании в его конфигурацию можно вносить любые изменения и запускать там же продуктивные ВМ.
База данных VRM расположена внутри и никаких действий от администратора для своей настройки не требует. ОС внутри аппаинса -- SLES 11SP1.
Предполагается, что инсталлятор запускается на внешней Windows машине (например, ваш ноутбук). Установка VRM, это то место, где я собрал первую порцию граблей. Из основного:
  • на данном ноуте должна быть установлена та версия Java, которая лежит на iso с дистрибутивом! Пришлось долго подбирать версии, пока не догадался взять с диска;
  • файловая шара с образом апплаинса должна иметь короткий путь (лучше без пробелов!) и быть расшарена конкретным пользователям, а не в режиме Everyone;
  • не доверяйте документации, даже если указано, что это от вашей версии. Читайте подсказки в интерфейсе самого визарда.
Хосты виртуализации в установленный VRM подключаются по-одному, либо с помощью заранее заготовленного Excel-шаблона, структуру которого умеет парсить VRM. Как такового понятия Resource Pool в тестировавшейся нами версии Fusion Compute нет. Такой объект, как Folder в у Fusion Compute также пока отсутствует. В результате, виртуальные машины отображаются плоским списком в порядке создания, что даже в тестовой инсталляции вызывало регулярные поиски нужных ВМ и отнимало много времени.
Отдельного специализированного shell'а (аналога vCLI\PowerCLI), у решения нет. Всё управление кроме совсем уж низкоуровневых "копаний", происходит в веб-консоли VRM. Но надо отдать должное, сам интерфейс достаточно шустрый и без каких-либо "приветов из 90-х". После некоторого периода постоянной работы, начинаешь привыкать.
3. Fusion Compute. Конфигурационные максимумы и операционные ограничения.
Конфигурационные максимумы платформы, заявленные вендором приведены в таблице ниже.

 

VMware vSphere 6.0

Huawei FusionSphere 5

Logical processors per Host

480

320

Physical Memory per Host

6 TB

4 TB

Virtual CPUs Per VM

128

64

Memory Per VM

4 TB

1 TB

Active VMs per Site

50000

80000

Maximum Nodes per Cluster

64

128

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

Что можно сделать без остановки ВМ:

Что нельзя сделать без остановки ВМ:


  • добавление vCPU (необходимо заранее настроить в свойствах ВМ);
  • добавление сетевой карты (того же типа, что существующие);
  • удаление сетевой карты (только для типа 1Gb);
  • добавление диска (того же типа, что существующие);
  • установление и снятие лимита на I/O для дисков;
  • установка/снятие опции привязки ВМ к хосту
  • добавление памяти;
  • смена типа сетевых адаптеров (1Gb/10Gb);
  • Смена MAC-адреса.
  • удаление сетевой карты (типа 10Gb);
  • смена порт-группы для сетевого адаптера(!!!);
  • удаление диска;
  • смена большинства расширенных настроек.
При этом, многие устройства внутри гостевой ОС уже представляются как USB-устройста, что намекает на то, что Huawei повторяет шаги, сделанные VMware ещё в vSphere 4.x и некоторые перечисленные выше ограничения должны быть сняты в дальнейшем.

Написать комментарий

Fusion Sphere testing. Part 0

Среда, 3 июня 2015, 22:22
В связи со всем известным трендом на "импортозамещение" компании-партнёры стали более пристально рассматривать продукты китайских вендоров. В начале 2015 мне довелось участвовать в достаточно обширном тестировании программно-аппаратного комплекса компании Huawei под названием Fusion Sphere.
<----------------------------------------------->
Disclaimer: в данной статье приводится исключительно личное мнение автора данного блога. Оно может не совпадать с официальной позицией его работодателя и/или компаний-партнёров.
<----------------------------------------------->

1. Общие данные о системе.

Рынок серверной виртуализации в наше время прочно поделен между несколькими крупными вендорами. Отдельные ниши занимают открытые решения на базе гипервизоров Xen и KVM. Компания Huawei в данной гонке занимает явно "догоняюшую" позицию. Главные силы их разработчиков сейчас брошены на наращивание функционала. Ещё совсем не давно все мы наблюдали такую же картину у главного конкурента VMware -- компании Microsoft. Забегая сильно вперёд стоит отметить, что такое экстенсивное наращивание функционала у продукта Huawei к сожалению часто происходит с ущербом стабильности и удобству управления.

Небезызвестный Gartner в прошлом году отнёс Huawei к нишевым игрокам на поле серверной виртуализации:

Для ценителей сравнений "feature-by-feature" по ссылке доступен подобный документ самого Huawei. Само сравнение начинается со страницы 51. Как либо комментировать его содержимое я пока не стану.

2. Состав нашего тестируемого комплекса.
Для тестирование к нам приехал целый комплекс с оборудованием -- Fusion Cube. Это некий аналог vBlock'а или FlexPod'а. Предполагается, что Fusion Cube приезжает к Заказчику с уже актуальными прошивками, сконфигурированными внутренниями связями между всем оборудованием и требует минимальных процедур включения в существующую инфраструктуру. В наше распоряжение попало полностью "голое" железо, что ни о чём не говорит, потому что у партнёра всегда найдутся "правильные" специалисты, но реальный опыт лёгкого включения получить не удалось.
Внутри Fusion Cube состоит из уже хорошо известного шасси E9000 с сетевыми коммутаторами также от Huawei. Комплектоваться шасси может несколькими типами лезвий:
  • CH121 -- вычислительная нода кластера;
  • CH222 -- вычислительная нода, также предоставляющая ресурсы хранения данных.
В данный момент уже доступны аналоги V3 с поддержкой последнего поколения процессоров Intel, но сути это не меняет.
Перечень ПО, участвовавшего в нашем тестировании:
  • FusionCompute (V100R005C00SPC100) -- среда виртуализации, являющаяся базисом для всех остальных программных компонент.
  • FusionAccess (V100R005C20SPC100) -- ПО для создания и управления инфраструктурой виртуальных ребочих мест (VDI).
  • FusionStorage (V100R003C2SPC300) -- программный контроллер распределённого хранилища на локальных ресурсах серверов. Аналог VMware vSAN.
  • FusionManager (N/A) -- ПО для создания и управления приватными облачными ресурсами на базе FusionCompute.

3. Высокоуровневая архитектура комплекса

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

Написать комментарий

Kiev VMware vBeer #8

Четверг, 27 ноября 2014, 14:17

Несмотря на информацию из предыдущего поста, предлагаю провести очередную встречу киевского VMware User Group.

Время: 05.12.2014 (пятница) начиная с 19:00.
Место: Паб "Натюрлих", ул. Богдана Хмельницкого 3.

Картинка для привлечения внимания.

Написать комментарий
event  

Public speaking: VMware Tour Russia 2014

Среда, 26 ноября 2014, 20:44

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

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

Во-вторых, совсем недавно я выступил на одном из двух крупных мероприятий VMware в России. Доклад мой был посвящён инструментам, технологиям и новым подходам к эффективному управлению платформой для VDI-инфраструктуры. Какие задачи на каком "уровне" удобнее и легче решать. Презентация доступна тут:

«Современные методы управления виртуальными рабочими местами»

В-третьих, чуть больше, чем через пару недель, состоится очередная встреча белорусского комьюнити VMware -- VMUG #3 Belarus. Все подробности тут: анонс

Написать комментарий
event  
⇤ Последнее
← Позже 1-я страница Раньше →