Новости Статьи VMware Veeam StarWind vGate! Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4120 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Veeam Agent для Linux и Windows - бесплатны для всех клиентов Veeam

Неделя новых штук на VMware Labs: Cluster Rules Manager (CRM).


Даже для опытных администраторов VMware vSphere понимание всех аспектов работы механизма DRS является непростой задачей. Чтобы облегчить понимание действующих правил DRS (affinity и anti-affinity) в кластере для отдельных виртуальных машин, а также на уровне всего датацентра, сотрудники VMware на сайте проекта Labs выпустили очередную утилиту Cluster Rules Manager (CRM).

С помощью CRM, построенного на базе модуля с веб-интерфейсом для Apache Tomcat, можно делать следующие вещи:

  • Аудит правил anti-affinity (несуществования ВМ на одном хосте) по всем машинам в рамках vCenter Server.
  • Импорт правил DRS affinity сразу из нескольких серверов vCenter.
  • Экспорт правил DRS affinity в новый vCenter.
  • Отчет о всех действующих правилах DRS с подробными параметрами в реальном времени, содержащий различные интеллектуальные метрики. Его можно сделать на уровне всего vCenter, виртуальных датацентров или кластеров. Отчет можно экспортировать и сохранить на диске.
  • Отчет об ассоциированных с виртуальными машинами правилах. Этот отчет также можно сделать на уровне всего vCenter, виртуальных датацентров, кластеров или отдельных ВМ.
  • Возможность соединиться с другим сервером vCenter прямо из интерфейса.

Скачать VMware Cluster Rules Manager можно по этой ссылке. Также полезно будет почитать документы Installation Guide и FAQ.


Таги: VMware, Labs, DRS, vSphere, VMachines

VMware predictive DRS - умный алгоритм для обработки нагрузок предприятия.


Многие из вас читали, что в новой версии VMware vSphere 6.5 появилась экспериментальная поддержка механизма Predictive DRS, который проактивно предпринимает действия по выравниванию нагрузки виртуальных машин на хосты ESXi, еще до того, как эта нагрузка придет.

Посмотрим как раньше работал VMware Distributed Resource Scheduler (DRS):

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

Поэтому появился сбалансированный метод (Balanced). В этом случае DRS старается поддерживать баланс по нагрузке на хосты кластера (или даже между кластерами), чтобы не было перекосов в ту или другую сторону. Работает этот метод совместно с продуктом vRealize Operations (vROps), который собирает метрики с хостов и старается поддерживать баланс в виртуальном датацентре:

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

Поэтому в VMware решили применить другой подход - Predictive DRS. Суть этого метода проста - компонент vROps ежедневно собирает сотни различных метрик со всех объектов виртуального датацентра (хосты, ВМ, хранилища). Эти метрики "обучают" механизм vROps, который каждую ночь анализирует данные о производительности хостов и формирует так называемые Dynamic Thresholds:

Predictive DRS производит очень сложный анализ на основе 10 различных алгоритмов и формирует коридор производительности "нормального" поведения виртуальных машин (обозначен на картинке серым). Границы этого коридора и есть Dynamic Thresholds, при выходе за границы которых в данное время, поведение в кластере считается аномальным. Работает этот механизм на уровне каждой виртуальной машины.

И тут самое интересное - Predictive DRS позволяет заранее понять, что на таких-то хостах виртуальные машины будут биться за ресурсы через некоторое время, и проактивно начинает мигрировать виртуальные машины, готовясь к ситуации изменения нагрузки:

То есть, синяя линия - это то, как будет (а точнее, как обычно было раньше - ведь так, скорее всего, будет и сегодня), а вот красная линия - это то, что подается на вход обычного DRS, чтобы он заранее начинал действия по подготовке ко всплеску нагрузки, который произойдет через некоторое время (например, бухгалтерия придет к 9-00 и будет включать свои виртуальные десктопы). В этот момент их, например, можно поддержать простаивающими хостами ESXi, где хостятся десктопы ленивых менеджеров, приходящих к 11 утра.

Ну а какой метод нужно использовать? VMware рекомендует использовать все три, в зависимости от ситуации:

Ну и отметим, что этот функционал доступен только в рамках решения vRealize Operations, о котором также можно почитать вот тут.


Таги: VMware, DRS, vROps, Update, vSphere

Как сохранить иерархию пулов ресурсов в кластере при отключении VMware DRS.


Многие администраторы VMware vSphere бояться отключать механизм балансировки нагрузки VMware DRS из-за того, что после отключения DRS потеряется иерархия пулов ресурсов, которая была рассчитана и выстроена.

Не стоит этого бояться, ведь при снятии с кластера галочки DRS в vSphere Web Client вас спросят, нужно ли сохранить иерархию ресурсных пулов (снапшот), которая может быть восстановлена, когда вы снова включите DRS:

Сохраняем ее в файл:

Если вы нажмете правой кнопкой на кластере в Web Client, вы увидите загрееный пункт "Restore Resource Pool Tree" в меню "All vCenter Actions":

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

Все довольно просто. Если, все-таки, что-то осталось непонятным - обратитесь к KB 2032893 или посмотрите вот это обучающее видео от VMware:


Таги: VMware, vSphere, DRS, Обучение

Новая утилита на VMware Labs - DRS Doctor для диагностики кластеров.


На сайте проекта VMware Labs, где очень часто появляются полезные штуковины для продуктов VMware, была выпущена очередная интересная утилита - DRS Doctor. Это средство позволяет проводить диагностику поведения DRS-кластера в рамках сервера VMware vCenter. DRS Doctor собирает такую информацию, как состояние кластера, распределение рабочей нагрузки, миграции DRS и многое другое. Все это объединяется в удобном и человекочитаемом формате логов.

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

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

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

Утилита поставляется в качестве средства командной строки для Linux. Для работы вам понадобится установленный Python. Инструкции по установке на CentOS доступны здесь, а скачать DRS Doctor можно по этой ссылке.


Таги: VMware Labs, DRS, Troubleshooting, vSphere

Обновленный документ VMware по технологии vSphere Metro Storage Cluster (vMSC).


На днях компания VMware выпустила интересный документ "VMware vSphere Metro Storage Cluster Recommended Practices" о построении архитектуры распределенного кластера VMware HA/DRS. Теперь в документе учтены все самые последние изменения, которые произошли в этом плане после выхода VMware vSphere 6.

Документ состоит из двух частей: в первой части рассказывается о том, как правильно спроектировать кластер vMSC и настроить платформу VMware vSphere соответствующим образом:

Во второй части подробно описаны различные сценарии сбоев и их обработка кластером vMSC в вашей распределенной виртуальной инфраструктуре:

В документе описаны следующие виды сбоев:

  • Отказ одного хоста в основном датацентре
  • Изоляция одного хоста в основном датацентре
  • Разделение пула виртуальных хранилищ
  • Разделение датацентра на сегменты (сети хостов и сети хранилищ)
  • Отказ дисковой полки в основном ЦОД
  • Полный отказ всех хранилищ в основном датацентре
  • Потеря устройств (полный выход из строя, выведение из эксплуатации) - Permanent Device Loss (PDL)

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


Таги: VMware, vSphere, vMSC, HA, DRS, DR

Обеспечение защиты сервера управления VMware vCenter Server 5.5.


Как вы знаете, у компании VMware был такой продукт как vCenter Server Heartbeat, который защищал управляющий сервер vCenter от сбоя различных его компонентов и на различных уровнях. Некоторое время этот продукт был снят с производства, и теперь защиту vCenter от сбоев рекомендуется обеспечивать стандартными средствами платформы VMware vSphere.

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

Ну а, собственно, для правильной конфигурации самой платформы vSphere и сервера vCenter, компания VMware выпустила полезный документ "VMware vCenter Server 5.5 Availability Guide".

Итак, начнем с того, что VMware предлагает разделить сервисы vCenter на две большие части:

  • Compute Node - это сам vCenter и все сервисы к нему относящиеся (SSO, Web Client, Inventory service)
  • Data Node - это узел, где хранятся данные vCenter, попросту говоря, это СУБД и сама база данных.

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

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

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

Доступность Compute Node

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

  • vCenter Single Sign-On services
  • vCenter Inventory Service
  • vCenter Server
  • vCenter Server management Web service
  • vSphere Web Client

Здесь рекомендуется настроить защиту средствами технологии VMware HA и придерживаться следующих рекомендаций:

  • Создавайте (по-возможности) отдельный кластер для управляющих сервисов - в случае отказа любого из компонентов сервисы будут перезапущены с помощью HA автоматически.
  • Включите не только VMware HA, но и технологию virtual machine monitoring, которая отключена по умолчанию. Это позволит перезапустить сервер с vCenter при зависании гостевой ОС.

  • Включите и настройте admission control в кластере HA/DRS, где работает vCenter. Это позволит гарантированно перезапустить vCenter на одном из хостов в случае сбоя.
  • Установите restart priority в настройках HA для машины с vCenter Server в значение "High". Он будет первым запускаться.
  • Если ваш vCenter находится в Windows-машине, то можно настроить автоматический рестарт машины при невозможности после многократных попыток запустить службу vCenter Service.

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

  • Если у вас компоненты vCenter на разных машинах, не забудьте установить правило affinity rule, чтобы машины оказались на одном хосте при миграции и восстановлении, в целях сохранения максимальной производительности управляющего сервиса.
  • Также для гарантии можно выделить управляющим компонентам гарантированную физическую память (Memory Reservation) в настройках виртуальной машины.

Доступность Data Node

Тут VMware приводит следующие рекомендации:

  • Также, как и в случае с Compute Node, рекомендуется использовать для управляющих сервисов и базы данных отдельный кластер.
  • Если вы используете решение для кластеризации vCenter, необходимо убедиться, что настройка ForceAffinePoweron в параметрах vSphere DRS установлена в значение 1, чтобы включать сервер БД, несмотря на правила DRS.
  • Так же, как и в случае с Compute Node, используйте технику virtual machine monitoring для перезапуска зависшей гостевой ОС.
  • То же самое и про admission control - используйте его для гарантированного восстановления ВМ с сервером БД.
  • Аналогично Compute Node, установите restart priority в настройках HA для машины с базой данных в значение "High". Он будет первым запускаться.
  • Для защиты vCenter Server SQL Server database можно использовать Microsoft Failover Clustering, который официально поддерживается со стороны VMware. Табличка совместимости СУБД и версий vCenter приведена ниже.

О том, как восстанавливать серверы vCenter, и многом другом можно почитать в документе "VMware vCenter Server 5.5 Availability Guide".


Таги: VMware, vCenter, HA, DRS, VMachines

Как запретить vMotion отдельной виртуальной машине на VMware vSphere.


Если вы хотите, чтобы никто не делал vMotion конкретной виртуальной машины с конкретного сервера VMware ESXi, то нужно просто разослать письмо администраторам vSphere с просьбой этого не делать. Но есть еще один способ, который поведал нам Frank Denneman - хотя он тоже имеет ограниченные условия применения. Ну и не забываем, что есть способ путем задания правил механизма балансировки VMware DRS (однако, не у всех по лицензии DRS есть).

В этом способе есть один существенный минус - в то время, как он не позволяет пользователю двинуть виртуальную машину через vMotion вручную, смигрировать машину можно будет через перевод хоста ESXi в Maintenance mode, так как делается это не под аккаунтом пользователя, а под системной учетной записью (System). Но режим обслуживания используется редко, и хотя бы для ручных операций это можно будет сделать. Ну и имейте в виду, что механизм VMware HA также может перезапустить машину на другом хосте в случае сбоя, наплевав на все.

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

Итак, добавляем роль No-vMotion в vSphere Web Client:

1. Заходим в vCenter как administrator.
2. Идем на домашний экран и переходим в Roles на экране Administration.
3. Выбираем действие создать роль (зеленый плюс).
4. Выбираем "All Priveleges", скроллимся до категории "Resource" и отчекиваем следующие привилегии,

  • Migrate powered off virtual machine
  • Migrate powered on virtual machine
  • Query vMotion

Далее добавляем пермиссию для виртуальной машины для нужного администратора/группы:

1. Выбираем "Host and Clusters" и находим нужную ВМ на вкладке Manage.
2. Выбираем пункт "Permissions" и кликаем на добавление пермиссии (зеленый плюс).
3. Нажимаем "Add" и выбираем пользователя или группу, которым мы хотим запретить vMotion этой виртуальной машины.
4. В правой части экрана выбираем роль "No-vMotion" и нажимаем "Ok".

Убеждаемся, что роль применена для данного пользователя к данному объекту (на остальные пермиссии это не повлияет):

Попробуем смигрировать эту виртуальную машину пользователем FrankD - видим, что опция "Migrate" загреена:

Но вот возможность перевода в Maintenance mode, к сожалению, по-прежнему активна:

Кто-нибудь знает более простой и надежный способ?


Таги: VMware, vSphere, vMotion, VMachines, Security, Обучение, ESXi, DRS, Blogs

DRMdiagnose - анализ снапшота кластера VMware vSphere и выдача рекомендаций по выделению ресурсов виртуальным машинам.


На днях, на сайте проекта VMware Labs (у нас есть тэг Labs) появилась новая утилита DRMdiagnose, с помощью которой возможно просмотреть информацию о текущем состоянии ресурсов кластера и получить рекомендации по управлению ими.

DRM - это Distributed Resource Manager, основной компонент VMware vSphere, являющийся ядром механизма VMware DRS, который осуществляет балансировку ресурсов в кластере. Основное назначение утилиты DRMdiagnose - это предоставление информации о том, что произойдет с производительностью виртуальных машин и их вычислительными ресурсами, если настройки ресурсов (limit, shares, reservation) будут изменены для какой-то из виртуальных машин. Кроме того, эта утилита выдает рекомендации относительно того, что нужно сделать с ресурсами виртуальных машин по отношению к текущим назначенным ресурсам (уменьшить, увеличить).

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

DRMdiagnose позволяет увидеть рекомендации в кластере наподобие таких:

Increase CPU size of VM Webserver by 1
Increase CPU shares of VM Webserver by 4000
Increase memory size of VM Database01 by 800 MB
Increase memory shares of VM Database01 by 2000

Decrease CPU reservation of RP Silver by 340 MHz
Decrease CPU reservation of VM AD01 by 214 MHz
Increase CPU reservation of VM Database01 by 1000 MHz

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

  • vCenter server appliance: /var/log/vmware/vpx/drmdump/clusterX/
  • vCenter server Windows 2003: %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
  • vCenter server Windows 2008: %ALLUSERSPROFILE%\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\

Сама утилитка может работать в трех режимах:

  1. Default - если указан путь к drmdump, то выводятся все ВМ кластера, их назначенные ресурсы, а также запрашиваемые ресурсы.
  2. Guided - если указан путь к drmdump и целевые параметры ресурсов ВМ, то утилита сгенерирует набор рекомендаций для их достижения.
  3. Auto - если указан путь к drmdump, то будут сгенерированы рекомендации для самых несбалансированных ВМ (то есть ВМ, для которых разница между назначенными и запрашиваемыми ресурсами самая большая).

Выглядят снапшоты кластера вот так:

А вот так можно запустить утилиту в дефолтном режиме для вывода информации в файл output.txt:

Формат использования DRMdiagnose:

Работает DRMdiagnose только с VMware vCenter 5.1 и выше, скачать утилиту можно по этой ссылке.


Таги: VMware, vSphere, Performance, DRS, Blogs, VMachines, Labs

Настройка VMware Storage DRS Affinity Rule для виртуальных дисков машин - отличия от дефолтного состояния.


Duncan и Frank, известные своими изысканиями в сфере механизмов отказоустойчивости (HA) и балансировки нагрузки (DRS) в виртуальной инфраструктуре VMware vSphere, опубликовали пару интересных материалов, касающихся настройки среды vCloud Director и механизма Storage DRS.

Как вы знаете, в настройках кластера хранилищ (Datastore Cluster) есть галка, которая определяет, будут ли виртуальные диски VMDK машин обязательно находиться на одном хранилище (Datastore) при миграции средствами механизма Storage DRS:

Надо отметить, что галка Keep VMDKs together by default - это не совсем простая для понимания галка. Если ее не поставить, то действовать будет обратное - диски виртуальной машины будут обязательно размещаться на разных хранилищах. Это, по заверениям блоггеров, даст больше гибкости в использовании механизма SDRS в среде vCloud Director при перемещении виртуальных машин между хранилищами, что даст больше преимуществ в динамически балансирующейся среде (особенно для "тонких" дисков). Соответственно, по умолчанию галка Keep VMDKs together by default должна быть выключена.


Таги: VMware, SDRS, Storage DRS, VMDK, Storage, vSphere

VMware Storage DRS - задание допустимого уровня over-commitment для хранилища при миграции ВМ на тонких дисках.


Frank Denneman опять написал интересную статью. Оказывается у механизма VMware Storage DRS, который производит балансировку виртуальных машин по хранилищам кластера SDRS, есть механизм задания допустимого уровня over-commitment для хранилища при миграции ВМ на тонких дисках.

Как вы знаете, у тонких VMDK-дисков (Thin Disks) виртуальных машин есть 2 параметра:

  • Provisioned Space - максимальный размер VMDK-файла, до которого может вырости диск виртуальной машины.
  • Allocated Space - текущий размер растущего VMDK-диска.

Разность этих двух парметров есть значение IdleMB, отражающее объем, на который виртуальный диск еще может вырасти. В расширенных настройках Storage DRS можно задать параметр PercentIdleMBinSpaceDemand, который определяет, сколько процентов от IdleMB механизм SDRS прибавляет к Allocated Space при выдаче и применении рекомендаций по размещению виртуальных машин на хранилищах кластера.

Рассмотрим на примере. Пусть максимальный размер диска VMDK составляет 6 ГБ при Allocated Space в 2 ГБ. Допустим мы задали PercentIdleMBinSpaceDemand = 25%. Тогда мы получим такую картину:

Таким образом, при размещении виртуальной машины на хранилище механизм Storage DRS будет считать, что ВМ занимает не 2 ГБ дискового пространства, а 2+0.25*4 = 3 ГБ. Ну и увидев такую машину на 10 ГБ-хранилище, механизм SDRS, при расчете выравнивания хранилищ по заполненности, будет считать что она занимает 3 ГБ, и свободно осталось лишь 7 ГБ.

Регулируя эту настройку можно добиться различных коэффициентов консолидации тонких VMDK-дисков машин на хранилищах. Ну и очевидно, что значение параметра PercentIdleMBinSpaceDemand равное 100% приведет к тому, что тонкие диски при размещении будут учитываться как их обычные flat-собратья.


Таги: VMware, Storage, SDRS, DRS, vSphere, ESXi, Blogs, VMDK

Работоспособность VMware vSphere Storage DRS (SDRS) с возможностями дисковых массивов, функциональностью vSphere 5 и других продуктов.


Недавно мы уже писали о том, как работает технология балансировки нагрузки на хранилища VMware Storage DRS (там же и про Profile Driven Storage). Сегодня мы посмотрим на то, как эта технология работает совместно с различными фичами дисковых массиов, а также функциями самой VMware vSphere и других продуктов VMware.

Для начала приведем простую таблицу, из которой понятно, что поддерживается, а что нет, совместно с SDRS:

Возможность Поддерживается или нет Рекомендации VMware по режиму работы SDRS
Снапшоты на уровне массива (array-based snapshots) Поддерживается Ручное применение рекомендаций (Manual Mode)
Дедупликация на уровне массива (array-based deduplication) Поддерживается Ручное применение рекомендаций (Manual Mode)
Использование "тонких" дисков на уровне массива (array-based thin provisioning) Поддерживается Ручное применение рекомендаций (Manual Mode)
Использование функций автоматического ярусного хранения (array-based auto-tiering) Поддерживается Ручное применение рекомендаций (Manual Mode), только для распределения по заполненности хранилищ (auto-tiering по распределению нагрузки сам решит, что делать)
Репликация на уровне массива (array-based replication) Поддерживается Ручное применение рекомендаций (Manual Mode)
Тома RDM (Raw Device Mappings) Поддерживается Автоматическое применение рекомендаций (Fully Automated Mode)
Технология репликации на уровне хоста (VMware vSphere Replication) Не поддерживается -----
Снапшоты виртуальных машин (VMware vSphere Snapshots) Поддерживается Автоматическое применение рекомендаций (Fully Automated Mode)
Использование "тонких" дисков на уровне виртуальных хранилищ (VMware vSphere Thin Provisioning) Поддерживается Автоматическое применение рекомендаций (Fully Automated Mode)
Технология связанных клонов (VMware vSphere Linked Clones) Не поддерживается -----
"Растянутый" кластер (VMware vSphere Storage Metro Cluster) Поддерживается Ручное применение рекомендаций (Manual Mode)
Хосты с версией ПО, младше чем vSphere 5.0 Не поддерживается -----
Использование совместно с продуктом VMware vSphere Site Recovery Manager Не поддерживается -----
Использование совместно с продуктом VMware vCloud Director Не поддерживается -----

Комментарии к таблице:

  • Снапшоты на уровне массива - они никак не влияют на работу механизма SDRS, однако рекомендуется оставить его в ручном режиме, чтобы избежать возможных проблем при одновременном создании снапшота и перемещении виртуальных дисков.
  • Дедупликация на уровне массива - полностью совместима со механизмом SDRS, однако рекомендуется ручной режим, так как, с точки зрения дедупликации, наиболее эффективно сначала применить рекомендации по миграции виртуальных дисков, а потом уже использовать дедупликацию (для большинства сценариев).
  • Использование array-based auto-tiering - очевидно, что функции анализа производительности в дисковом массиве и перемещения данных по ярусам с различными характеристиками могут вступить вступить в конфликт с алгоритмами определения нагрузки в SDRS и перемещения vmdk-дисков по хранилищам на логическом уровне. Сам Storage DRS вступает в действие после 16 часов анализа нагрузки и генерирует рекомендации каждые 8 часов, в дисковом же массиве механизм перераспределения блоков по ярусам может работать по-разному: от real-time процесса в High-end массивах, до распределения каждые 24 часа в недорогих массивах. Понятно, что массиву лучше знать, какие блоки куда перемещать с точки зрения производительности физических устройств, поэтому для SDRS рекомендуется оставить выравнивание хранилищ только по заполненности томов VMFS, с отключенной I/O Metric.
  • Репликация на уровне массива - полностью поддерживается со стороны SDRS, однако, в зависимости от использования метода репликации, во время применения рекомендаций SDRS виртуальные машины могут остаться в незащищенном состоянии. Поэтому рекомендуется применять эти рекомендации SDRS во время запланированного окна обслуживания хранилищ.
  • VMware vSphere Storage Metro Cluster - здесь нужно избегать ситуации, когда виртуальный диск vmdk машины может уехать на другой сайт по отношению к хосту ESXi, который ее исполняет (когда используется общий Datastore Cluster хранилищ). Поэтому, а еще и потому, что распределенные кластеры могут строиться на базе технологий синхронной репликации хранилищ (см. предыдущий пункт), нужно использовать ручное применение рекомендаций SDRS.

  • Поддержка VMware vSphere Site Recovery Manager - на данный момент SDRS не обнаруживает Datastore Groups в SRM, а SRM не отслеживает миграции SDRS по хранилищам. Соответственно, при миграции ВМ на другое хранилище не обновляются protection groups в SRM, как следствие - виртуальные машины оказываются незащищенными. Поэтому совместное использование этих продуктов не поддерживается со стороны VMware.
  • Поддержка томов RDM - SDRS полностью поддерживает тома RDM, однако эта поддержка совершенно ничего не дает, так как в миграциях может участвовать только vmdk pointer, то есть прокси-файл виртуального диска, который занимает мало места (нет смысла балансировать по заполненности) и не генерирует никаких I/O на хранилище, где он лежит (нет смысла балансировать по I/O). Соответственно понадобиться эта поддержка может лишь на время перевода Datastore, где лежит этот файл-указатель, в режим обслуживания.
  • Поддержка VMware vSphere Replication - SDRS не поддерживается в комбинации с хостовой репликацией vSphere. Это потому, что файлы *.psf, используемые для нужд репликации, не поддерживаются, а даже удаляются при миграции ВМ на другое хранилище. Вследствие этого, механизм репликации для смигрированной машины считает, что она нуждается в полной синхронизации, что вызывает ситуацию, когда репликация будет отложена, а значит существенно ухудшатся показатели RTO/RPO. Поэтому (пока) совместное использование этих функций не поддерживается.
  • Поддержка VMware vSphere Snapshots - SDRS полностью поддерживает спапшоты виртуальных машин. При этом, по умолчанию, все снапшоты и виртуальные диски машины при применении рекомендаций перемещаются на другое хранилище полностью (см. левую часть картинки). Если же для дисков ВМ настроено anti-affinity rule, то они разъезжаются по разным хранилищам, однако снапшоты едут вместе со своим родительским диском (см. правую часть картинки).

  • Использование тонких дисков VMware vSphere - полностью поддерживается SDRS, при этом учитывается реально потребляемое дисковое пространство, а не заданный в конфигурации ВМ объем виртуального диска. Также SDRS учитывает и темпы роста тонкого виртуального диска - если он в течение последующих 30 часов может заполнить хранилище до порогового значения, то такая рекомендация показана и применена не будет.
  • Технология Linked Clones - не поддерживается со стороны SDRS, так как этот механизм не отслеживает взаимосвязи между дисками родительской и дочерних машин, а при их перемещении между хранилищами - они будут разорваны. Это же значит, что SDRS не поддерживается совместно с продуктом VMware View.
  • Использование с VMware vCloud Director - пока не поддерживается из-за проблем с размещением объектов vApp в кластере хранилищ.
  • Хосты с версией ПО, младше чем vSphere 5.0 - если один из таких хостов поключен к тому VMFS, то для него SDRS работать не будет. Причина очевидна - хосты до ESXi 5.0 не знали о том, что будет такая функция как SDRS.

Больше подробностей приведено в документе "VMware vSphere Storage DRS Interoperability".


Таги: VMware, SDRS, Storage DRS, Storage, ESXi, SRM, View, VMDK

VMware vSphere Storage DRS и Profile Driven Storage - что это такое и как работает.


Одним из ключевых нововведений VMware vSphere 5, безусловно, стала технология выравнивания нагрузки на хранилища VMware vSphere Storage DRS (SDRS), которая позволяет оптимизировать нагрузку виртуальных машин на дисковые устройства без прерывания работы ВМ средствами технологии Storage vMotion, а также учитывать характеристики хранилищ при их первоначальном размещении.

Основными функциями Storage DRS являются:

  • Балансировка виртуальных машин между хранилищами по вводу-выводу (I/O)
  • Балансировка виртуальных машин между хранилищами по их заполненности
  • Интеллектуальное первичное размещение виртуальных машин на Datastore в целях равномерного распределения пространства
  • Учет правил существования виртуальных дисков и виртуальных машин на хранилищах (affinity и anti-affinity rules)

Ключевыми понятими Storage DRS и функции Profile Driven Storage являются:

  • Datastore Cluster - кластер виртуальных хранилищ (томов VMFS или NFS-хранилищ), являющийся логической сущностью в пределах которой происходит балансировка. Эта сущность в чем-то похожа на обычный DRS-кластер, который составляется из хост-серверов ESXi.
  • Storage Profile - профиль хранилища, используемый механизмом Profile Driven Storage, который создается, как правило, для различных групп хранилищ (Tier), где эти группы содержат устройства с похожими характеристиками производительности. Необходимы эти профили для того, чтобы виртуальные машины с различным уровнем обслуживания по вводу-выводу (или их отдельные диски) всегда оказывались на хранилищах с требуемыми характеристиками производительности.

При создании Datastore Cluster администратор указывает, какие хранилища будут в него входить (максимально - 32 штуки в одном кластере):

Как и VMware DRS, Storage DRS может работать как в ручном, так и в автоматическом режиме. То есть Storage DRS может генерировать рекомендации и автоматически применять их, а может оставить их применение на усмотрение пользователя, что зависит от настройки Automation Level.

С точки зрения балансировки по вводу-выводу Storage DRS учитывает параметр I/O Latency, то есть round trip-время прохождения SCSI-команд от виртуальных машин к хранилищу. Вторым значимым параметром является заполненность Datastore (Utilized Space):

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

  • SSD-диски: 10-15 миллисекунд
  • Диски Fibre Channel и SAS: 20-40 миллисекунд
  • SATA-диски: 30-50 миллисекунд

По умолчанию рекомендации по I/O Latency для виртуальных машин обновляются каждые 8 часов с учетом истории нагрузки на хранилища. Также как и DRS, Storage DRS имеет степень агрессивности: если ставите агрессивный уровень - миграции будут чаще, консервативный - реже. Первой галкой "Enable I/O metric for SDRS recommendations" можно отключить генерацию и выполнение рекомендаций, которые основаны на I/O Latency, и оставить только балансировку по заполненности хранилищ.

То есть, проще говоря, SDRS может переместить в горячем режиме диск или всю виртуальную машину при наличии большого I/O Latency или высокой степени заполненности хранилища на альтернативный Datastore.

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

Администратор может просматривать и применять предлагаемые рекомендации Storage DRS из специального окна:

Когда администратор нажмет кнопку "Apply Recommendations" виртуальные машины за счет Storage vMotion поедут на другие хранилища кластера, в соответствии с определенным для нее профилем (об этом ниже).

Аналогичным образом работает и первичное размещение виртуальной машины при ее создании. Администратор определяет Datastore Cluster, в который ее поместить, а Storage DRS сама решает, на какой именно Datastore в кластере ее поместить (основываясь также на их Latency и заполненности).

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

Как видно из картинки с выбором кластера хранилищ для новой ВМ, кроме Datastore Cluster, администратор первоначально выбирает профиль хранилищ (Storage Profile), который определяет, по сути, уровень производительности виртуальной машины. Это условное деление хранилищ, которое администратор задает для хранилищ, обладающих разными характеристиками производительности. Например, хранилища на SSD-дисках можно объединить в профиль "Gold", Fibre Channel диски - в профиль "Silver", а остальные хранилища - в профиль "Bronze". Таким образом вы реализуете концепцию ярусного хранения данных виртуальных машин:

Выбирая Storage Profile, администратор будет всегда уверен, что виртуальная машина попадет на тот Datastore в рамках выбранного кластера хранилищ, который создан поверх дисковых устройств с требуемой производительностью. Профиль хранилищ создается в отельном интерфейсе VM Storage Profiles, где выбираются хранилища, предоставляющие определенный набор характеристик (уровень RAID, тип и т.п.), которые платформа vSphere получает через механизм VASA (VMware vStorage APIs for Storage Awareness):

Ну а дальше при создании ВМ администратор определяет уровень обслуживания и характеристики хранилища (Storage Profile), а также кластер хранилища, датасторы которого удовлетворяют требованиям профиля (они отображаются как Compatible) или не удовлетворяют им (Incompatible). Концепция, я думаю, понятна.

Регулируются профили хранилищ для виртуальной машины в ее настройках, на вкладке "Profiles", где можно их настраивать на уровне отдельных дисков:

На вкладке "Summary" для виртуальной машины вы можете увидеть ее текущий профиль и соответствует ли в данный момент она его требованиям:

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

Далее - правила размещения виртуальных машин и их дисков. Определяются они в рамках кластера хранилищ. Есть 3 типа таких правил:

  • Все виртуальные диски машины держать на одном хранилище (Intra-VM affinity) - установлено по умолчанию.
  • Держать виртуальные диски обязательно на разных хранилищах (VMDK anti-affinity) - например, чтобы отделить логи БД и диски данных. При этом такие диски можно сопоставить с различными профилями хранилищ (логи - на Bronze, данны - на Gold).
  • Держать виртуальные машины на разных хранилищах (VM anti-affinity). Подойдет, например, для разнесения основной и резервной системы в целях отказоустойчивости.

Естественно, у Storage DRS есть и свои ограничения. Основные из них приведены на картинке ниже:

Основной важный момент - будьте осторожны со всякими фичами дискового массива, не все из которых могут поддерживаться Storage DRS.

И последнее. Технологии VMware DRS и VMware Storage DRS абсолютно и полностью соместимы, их можно использовать совместно.


Таги: VMware, Storage, DRS, SDRS, vSphere, ESXi, Enterprise, Обучение, SVMotion

Технологии Dynamic Optimization и Power Optimization в System Center Virtual Machine Manager 2012 для Hyper-V 3.0.


Как знают пользователи виртуализации от Microsoft, в средстве управления System Center Virtual Machine Manager 2008 R2 имелась функция Performance and Resource Optimization (PRO), которая позволяла осуществлять балансировку нагрузки на хост-серверы виртуальной инфраструктуры Hyper-V. Происходит это путем горячей миграции виртуальных машин с загруженных на незагруженные хосты, за счет использования пороговых значений на хостах, задаваемых пользователем (т.е. превышение лимитов памяти или утилизации процессора). По-сути, это аналог VMware DRS в VMware vSphere (и даже Storage DRS, поскольку через партнерские решения могут отслеживаться параметры производительности хранилищ). Миграция виртуальных машин в соответствии с рекомендациями PRO может проводиться автоматически или вручную:

Большим недостатком данной технологии было то, что она требовала наличия продукта System Center Operations Manager, который есть далеко не у всех СМБ-пользователей.

В System Center Virtual Machine Manager 2012 технология PRO была заменена на техники Dynamic Optimization и Power Optimization, которые уже, к счастью, не зависят от Operations Manager и не требуют его. Также появились функции Power Optimization, которые позволяют отключать хост-серверы Hyper-V с малой нагрузкой, за счет миграции с них виртуальных машин (также по пороговым значениям, задаваемым пользователем), в целях экономии электроэнергии (аналог VMware Distributed Power Management, который является частью технологии DRS).

Dynamic Optimization и Power Optimization в SC VMM 2012 позволяют нам настроить следующие параметры:

  • Степерь агрессивности Dynamic Optimization при применении рекомендаций в кластере или группе хостов (Host group)
  • Автоматический или ручной режим работы
  • Интервал между генерациями и применением рекомендаций (по умолчанию 10 минут)
  • Использовать или нет Power Optimization
  • Окно (промежуток времени в течение суток), в котое Power Optimization будет работать

Так выглядят настройки Dynamic Optimization:

Пользователь определяет минимальные значения доступных ресурсов при размещении виртуальных машин на хостах:

Обратите, внимание, что пороговые значения могут быть заданы и для Disk I/O, т.е. виртуальную машину можно смигрировать не только между хостами, но и хранилищами средствами технологии Storage Live Migration.

Хосты, находящиеся в режиме обслуживания (maintenance mode) исключаются из механизма Dynamic Optimization.

А так настройка окна Power Optimization:

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

Таким образом, получается, что Dynamic Optimization и Power Optimization в System Center Virtual Machine Manager 2012 представляют собой аналог VMware DRS и sDRS, что будет очень приятным моментом при использовании SC VMM 2012 с Hyper-V 3.0. И напоследок отметим, что функции Dynamic Optimization и Power Optimization в VMM 2012 работают при управлении не только хостами Hyper-V, но и платформами VMware vSphere и Citrix XenServer.

Но все же отличие Dynamic Optimization от VMware DRS есть - для Dynamic Optimization нельзя задавать Anti-affinity rules, что может оказаться некоторым неудобством для администраторов.


Таги: Microsoft, SC VMM, Update, Dynamic Optimization, Power Optimization, Hyper-V, VMware, DRS

Виртуальные агенты (Agent VMs) и VMware vSphere HA/DRS.


Как многие из вас знают, в среде VMware vSphere есть специализированные виртуальные машины, которую выполняют служебные функции, специфические для виртуальной инфраструктуры. К ним, например, можно отнести, виртуальные агенты (Agent VMs) - машины, предназначенные для того, чтобы присутствовать на хосте всегда (т.е. не участвовать в DRS/DPM) и обслуживать другие ВМ. Хороший пример - это антивирусные виртуальные модули (Virtual Appliance), которые сейчас есть у Trend Micro и Касперского и которые работают через vShield Endpoint и VMsafe API:

Логично предположить, что эти виртуальные машины в среде VMware vSphere надо обрабатывать как-то по-особенному. Это так и происходит. Давайте посмотрим, как это делается:

1. Платформа vSphere помечает внутри себя такие виртуальные машины как виртуальные агенты (Agent VMs).

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

Таким образом, в случае сбоя порядок загрузки ВМ на хосте ESXi следующий:

  • стартуют виртуальные агенты
  • запускаются Secondary виртуальные машины для тех, которые защищены технологией Fault Tolerance
  • поднимаются виртуальные машины с высоким, средним и низким приоритетом, соответственно

3. Механизм VMware DRS/DPM, осуществляющий балансировку виртуальных машин по хостам средствами vMotion и экономию электропитания серверов средствами их отключения при недогрузке датацентра, также в курсе о виртуальных агентах. Поэтому здесь следующее поведение:

  • DRS учитывает Reservations, заданные для агентов, даже в том случае, когда они выключены
  • для режимов обслуживания (maintenance mode) и Standby - виртуальные агенты никуда с хоста автоматически не мигрируют
  • виртуальные агенты должны быть доступны на хосте перед тем, как там будут включены обычные ВМ или они туда будут смигрированы

Источники: тут и тут.


Таги: VMware, vSphere, DRS, DPM, HA, VMachines

DRS Host Affinity Rules - неочевидное поведение.


Вот эта заметка на блоге VMware напомнила об одной интересной особенности поведения правил совместного и несовместного размещения виртуальных машин на хосте ESX/ESXi (DRS Host Affinity Rules).

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

То есть, мы задаем группы виртуальных машин и хостов:

И указываем, что виртуальные машины DRS-группы могут работать только на данной DRS-группе хостов:

Правила эти бывают мягкими (preferential), когда DRS+HA будут стараться следовать им при штатном функционировании кластера, и жесткими (mandatory, "Must run") - в этом случае ни при каких условиях виртуальные машины не переедут на хосты не из группы. Этого не произойдет ни средствами vMotion/DRS/Maintenance Mode, ни средствами перезапуска HA в аварийных ситуациях.

Для жестких правил есть один интересный аспект: они сохраняются и продолжают действовать даже тогда, когда вы отключили кластер VMware DRS. То есть вы не сможете сделать ручной vMotion или Power On машин на хостах не из группы, а HA не будет их там перезапускать. При этом в настройках кластера с отключенным DRS уже не будет возможности редактирования этих правил (категория VMware DRS пропадет). Это сделано для того, чтобы во время временных сбоев (например, vCenter) лицензионные правила существования ВМ для приложений на хостах не нарушались в любом случае.

Поэтому, если нужно удалить правила, нужно снова включить DRS, удалить их и снова отключить DRS.


Таги: VMware, DRS, Обучение, vSphere, ESX, ESXi, vMotion, HA

Осторожно: VMware vSphere Storage DRS + VMware HA может убить вашу виртуальную машину при использовании разных версий ESXi в кластере.


Интересный момент обнаружился на блогах компании VMware. Оказывается, если вы используете в кластере VMware HA разные версии платформы VMware ESXi (например, 4.1 и 5.0), то при включенной технологии Storage DRS (выравнивание нагрузки на хранилища), вы можете повредить виртуальный диск вашей ВМ, что приведет к его полной утере.

Об этом написано в документе vSphere 5.0 Availability Guide:

In clusters where Storage vMotion is used extensively or where Storage DRS is enabled, VMware recommends that you do not deploy vSphere HA. vSphere HA might respond to a host failure by restarting a virtual machine on a host with an ESXi version different from the one on which the virtual machine was running before the failure. A problem can occur if, at the time of failure, the virtual machine was involved in a Storage vMotion action on an ESXi 5.0 host, and vSphere HA restarts the virtual machine on a host with a version prior to ESXi 5.0. While the virtual machine might power on, any subsequent attempts at snapshot operations could corrupt the vdisk state and leave the virtual machine unusable.

По русски это выглядит так:

Если вы широко используете Storage vMotion или у вас включен Storage DRS, то лучше не использовать кластер VMware HA. Так как при падении хост-сервера ESXi, HA может перезапустить его виртуальные машины на хостах ESXi с другой версией (а точнее, с версией ниже 5.0, например, 4.1). А в это время хост ESXi 5.0 начнет Storage vMotion, соответственно, во время накатывания последовательности различий vmdk (см. как работает Storage vMotion) машина возьмет и запустится - и это приведет к порче диска vmdk.

Надо отметить, что такая ситуация, когда у вас в кластере используется только ESXi 5.0 и выше - произойти не может. Для таких ситуаций HA и Storage vMotion полностью совместимы.


Таги: VMware, HA, Storage DRS, Bugs, Bug, vSphere, ESXi, Storage, VMDK

VMware vSphere 5 Stretched Clusters: Metro HA и vMotion на EMC VPLEX.


Скоро нам придется участвовать в интереснейшем проекте - построение "растянутого" кластера VMware vSphere 5 на базе технологии и оборудования EMC VPLEX Metro с поддержкой возможностей VMware HA и vMotion для отказоустойчивости и распределения нагрузки между географически распределенными ЦОД.

Вообще говоря, решение EMC VPLEX весьма новое и анонсировано было только в прошлом году, но сейчас для нашего заказчика уже едут модули VPLEX Metro и мы будем строить active-active конфигурацию ЦОД (расстояние небольшое - где-то 3-5 км) для виртуальных машин.

Для начала EMC VPLEX - это решение для виртуализации сети хранения данных SAN, которое позволяет объединить ресурсы различных дисковых массивов различных производителей в единый логический пул на уровне датацентра. Это позволяет гибко подходить к распределению дискового пространства и осуществлять централизованный мониторинг и контроль дисковых ресурсов. Эта технология называется EMC VPLEX Local:

С физической точки зрения EMC VPLEX Local представляет собой набор VPLEX-директоров (кластер), работающих в режиме отказоустойчивости и балансировки нагрузки, которые представляют собой промежуточный слой между SAN предприятия и дисковыми массивами в рамках одного ЦОД:

В этом подходе есть очень много преимуществ (например, mirroring томов двух массивов на случай отказа одного из них), но мы на них останавливаться не будем, поскольку нам гораздо более интересна технология EMC VPLEX Metro, которая позволяет объединить дисковые ресурсы двух географически разделенных площадок в единый пул хранения (обоим площадкам виден один логический том), который обладает свойством катастрофоустойчивости (и внутри него на уровне HA - отказоустойчивости), поскольку данные физически хранятся и синхронизируются на обоих площадках. В плане VMware vSphere это выглядит так:

То есть для хост-серверов VMware ESXi, расположенных на двух площадках есть одно виртуальное хранилище (Datastore), т.е. тот самый Virtualized LUN, на котором они видят виртуальные машины, исполняющиеся на разных площадках (т.е. режим active-active - разные сервисы на разных площадках но на одном хранилище). Хосты ESXi видят VPLEX-директоры как таргеты, а сами VPLEX-директоры являются инициаторами по отношению к дисковым массивам.

Все это обеспечивается технологией EMC AccessAnywhere, которая позволяет работать хостам в режиме read/write на массивы обоих узлов, тома которых входят в общий пул виртуальных LUN.

Надо сказать, что технология EMC VPLEX Metro поддерживается на расстояниях между ЦОД в диапазоне до 100-150 км (и несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало.

До появления VMware vSphere 5 существовали некоторые варианты конфигураций для инфраструктуры виртуализации с использованием общих томов обоих площадок (с поддержкой vMotion), но растянутые HA-кластеры не поддерживались.

С выходом vSphere 5 появилась технология vSphere Metro Storage Cluster (vMSC), поддерживаемая на сегодняшний день только для решения EMC VPLEX, но поддерживаемая полностью согласно HCL в плане технологий HA и vMotion:

Обратите внимание на компонент посередине - это виртуальная машина VPLEX Witness, которая представляет собой "свидетеля", наблюдающего за обоими площадками (сам он расположен на третьей площадке - то есть ни на одном из двух ЦОД, чтобы его не затронула авария ни на одном из ЦОД), который может отличить падения линка по сети SAN и LAN между ЦОД (экскаватор разрезал провода) от падения одного из ЦОД (например, попадание ракеты) за счет мониторинга площадок по IP-соединению. В зависимости от этих обстоятельств персонал организации может предпринять те или иные действия, либо они могут быть выполнены автоматически по определенным правилам.

Теперь если у нас выходит из строя основной сайт A, то механизм VMware HA перезагружает его ВМ на сайте B, обслуживая их ввод-вывод уже с этой площадки, где находится выжившая копия виртуального хранилища. То же самое у нас происходит и при массовом отказе хост-серверов ESXi на основной площадке (например, дематериализация блейд-корзины) - виртуальные машины перезапускаются на хостах растянутого кластера сайта B.

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

Если откажет только сеть управления для хостов ESXi на одной площадке - то умный VMware HA оставит её виртуальные машины запущенными, поскольку есть механизм для обмена хартбитами через Datastore (см. тут).

Что касается VMware vMotion, DRS и Storage vMotion - они также поддерживаются при использовании решения EMC VPLEX Metro. Это позволяет переносить нагрузки виртуальных машин (как вычислительную, так и хранилище - vmdk-диски) между ЦОД без простоя сервисов. Это открывает возможности не только для катастрофоустойчивости, но и для таких стратегий, как follow the sun и follow the moon (но 100 км для них мало, специально для них сделана технология EMC VPLEX Geo - там уже 2000 км и 50 мс latency).

Самое интересное, что скоро приедет этот самый VPLEX на обе площадки (где уже есть DWDM-канал и единый SAN) - поэтому мы все будем реально настраивать, что, безусловно, круто. Так что ждите чего-нибудь про это дело интересного.


Таги: VMware, HA, Metro, EMC, Storage, vMotion, DRS, VPLEX

Новые возможности VMware vSphere 5.0 - официально.


Компания VMware в июле 2011 года объявила о доступности новых версий целой линейки своих продуктов для облачных вычислений, среди которых находится самая технологически зрелая на сегодняшний день платформа виртуализации VMware vSphere 5.0.

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


Таги: VMware, vSphere, Update, Release, ESXi, Enterprise, Storage DRS, Storage VMotion, vMotion, Network, vMachines, DRS, Auto Deploy, VMFS, Storage, HA, Licensing, Price

Требования и ограничения VMware Fault Tolerance.


Технология VMware Fault Tolerance позволяет защитить виртуальные машины с помощью кластеров непрерывной доступности, позволяющих в случае отказа хоста с основной виртуальной машиной мгновенно переключиться на ее "теневую" работющую копию на другом сервере ESX. Однако эта технология имеет существенные ограничения, приведенные ниже.
Таги: VMware, Fault Tolerance, FT, vSphere, ESX, DRS, DPM, HA, Enterprise

Интеграция VMware Fault Tolerance и DRS в VMware vSphere.


Как вы знаете, в VMware vSphere 4.1 механизм VMware DRS, осуществляющий балансировку нагрузки на хост-серверы ESX, теперь интегрирован с технологией непрерывной доступности VMware Faut Tolerance.

То есть DRS автоматически распределяет по хост-серверам и FT-машины, однако тут есть небольшой нюанс. В соответствии с рекомендациями Fault Tolerance, число таких машин на хосте должно быть не больше 4-х в целях оптимального быстродействия. Если вы попробуете смигрировать пятую виртуальную машину с включенной технологией FT на хост, вы получите вот такое сообщение:

Host already has the recommended number of 4 Fault Tolerance VMs running on it

То есть DRS не смигрирует и не сделает Initial Placement для FT-машин на хосты VMware ESX, где уже работают 4 таких ВМ. Однако, есть возможность увеличить это количество. Для этого необходимо в расширенных настройках (Advanced Settings) кластера VMware HA/DRS добавить параметр:

das.maxftvmsperhost

со значением, например, 6. Если вы поставите значение 0, то VMware DRS будет полностью игнорировать данное требование к числу FT-машин на хост.


Таги: VMware, DRS, Fault Tolerance, FT, ESX, Blogs, VMachines, vSphere

Как работают Limit, Reservation и Shares для пулов ресурсов в VMware vSphere / ESX.


Большинству пользователей виртуальной инфраструктуры VMware vSphere известны такие параметры как Limit, Reservation и Shares для пулов ресурсов (Resource Pool) в пределах кластеров VMware DRS и отельных хостов ESX. Именно этими тремя параметрами определяется потребление виртуальными машинами оперативной памяти и процессорных ресурсов хоста VMware ESX.
Таги: VMware, vSphere, Resources, ESX, HA, DRS

Список новых возможностей VMware vSphere / ESX 4.1.


Андрей Вахитов (vmind.ru) в своем блоге разместил просочившуюся информацию о новой функциональности готовящегося к выпуску релиза платформы виртуализации VMware vSphere 4.1, включая ESX 4.1 и vCenter 4.1.

Приблизительный список основных новых возможностей VMware vSphere 4.1:

  • Поддержка развертывания тонкого гипервизора VMware ESXi по PXE.
  • Контроль обмена трафиком с системой хранения Storage I/O Control в стиле QoS.
  • Network I/O Traffic Management - более гибкое регулирование полосы пропускания сетевого взаимодействия виртуальных машин (в том числе сети VMotion, Fault Tolerance).
  • VMware HA Healthcheck Status - автоматическая проверка работоспособности VMware HA, при этом в случае отклонения настроек кластера от требуемых выдается Alarm в VMware vCenter.
  • Fault Tolerance (FT) Enhancements - теперь FT полностью интегрирован с VMware DRS, работает в кластерах EVC, а первичные и вторичные виртуальные машины корректно балансируются DRS. Кроме того, VMware FT может теперь работать без VMware HA.
  • vCenter Converter Hyper-V Import - можно импортировать виртуальную машину на ESX с сервера Hyper-V
  • DRS Virtual Machine Host Affinity Rules - возможность запрещать некоторые хосты к размещению на них ВМ. Пригодится для соблюдения лицензионной политики.
  • Memory Compression - новый уровень абстракции оперативной памяти ВМ. Быстрее чем засвопированная на диск память, но медленнее, чем физическая.
  • vMotion Enhancements - теперь VMotion работает быстрее (до 8 раз), и увеличено число одновременных миграций ВМ на хосте (с 4 до 8).
  • 8GB Fibre Channel Support
  • ESXi Active Directory Integration - теперь ESXi можно загнать в AD.
  • Configuring USB Device Passthrough from an ESX/ESXi Host to a Virtual Machine - поддержка USB-устройств на хосте ESX / ESXi, пробрасываемых к виртуальной машине.
  • User-configurable Number of Virtual CPUs per Virtual Socket - по-сути, многоядерные (не путать с многопроцессорными) виртуальные машины. Несколько виртуальных ядер в одном виртуальном vCPU.

Таги: VMware, vSphere, Update, Upgrade, ESX, ESXi, VMotion, HA, DRS, Blogs, Fault Tolernce

Документация к System Center Virtual Machine Manager 2008 К2 (управление серверами Hyper-V 2.0).


Как вы знаете, недавно компания Microsoft выпустила не только вторую версию бесплатного гипервизора Hyper-V 2.0 (R2) который встроен в ОС Windows 2008 Server R2, но и вслед за этим зарелизила продукт System Center Virtual Machine Manager 2008 R2 (SC VMM 2008 R2), предназначенный для управления виртуальной инфраструктурой Microsoft. Как и к любому продукту Microsoft, к SC VMM 2008 R2 прилагается прицеп с документацией, ссылки на которую приведены ниже:

А знаете ли вы, что у Microsoft в SC VMM 2008 R2 есть аналог функции VMware DRS...


Таги: Microsoft, SCVMM, Hyper-V, DRS

HA Admission Control и механизм экономии электропитания VMware DPM в vSphere.


Великий Duncan поднял очередную болезненную тему для VMware vSphere. У них (VMware) есть заказчик, у которого 5 хостов VMware ESX в кластере VMware DRS. Вечером, когда нагрузка на хосты ESX спадает, 4 из них переходят в standby режим (делает это механизм Distributed Power Management), остается один хост на котором сервер vCenter, работающий в виртуальной машине.

Если этот единственный хост VMware ESX погибает - вся инфраструктура остается выключенной, поскольку некому вывести остальные хосты из standby и перезапустить vCenter. Все это потому, что Admission Control в настройках кластера VMware HA выключен и отказоустойчивость кластера не гарантирована. То есть это не баг - а фича. Но...


Таги: VMware, HA, DPM, DRS, Bugs

Как вывести хост ESX из Maintenance Mode из консоли, если vSphere Client не помогает.


Раз уж речь пошла о Maintenance Mode, то расскажем как выйти из DRS Maintenance Mode хоста ESX, когда его не получается вывести оттуда через vSphere Client. Причины могут быть различны, однако такое встречается время от времени. Что нужно сделать, чтобы убрать Maintenance Mode на непокорном хосте VMware ESX:

1. Перезапустить Management Agents на ESX, используя KB1003490, командой # service mgmt-vmware restart и попробовать Exit Maintenance Mode из vSphere Client еще раз.

2. Если не помогло, выполнить команду:

vimsh -n -e /hostsvc/maintenance_mode_exit

из сервисной консоли для выхода из Maintenance Mode, ну а команда...


Таги: VMware, vSphere, ESX, DRS

Проектирование инфраструктуры виртуализации VMware vSphere 4.


Многие из вас уже, должно быть, начинают думать о начале проекта по виртуализации серверов на базе платформы VMware vSphere, которая стала вполне доступной для сектора SMB (издания VMware vSphere Essentials). Кроме того, пакеты VMware vSphere Acceleration Kits со скидками для приобретающих впервые - никто не отменял (скидки 20-30% при покупке лицензий на 3-4 сервера). Но сегодня не о ценах, а о том, как правильно спланировать виртуальную инфраструктуру VMware vSphere с учетом появившихся новых технологий и возможностей VMware.

Итак, если начать планировать по этапам, вот так выглядят составляющие инфраструктуры при проектировании решения VMware vSphere 4...
Таги: VMware, vSphere, ESX, Fault Tolerance, vNetwork, DRS, Backup, ESXi, VMFS, vCenter, PowerShell

Настройка VMware Distributed Power Management (DPM, часть VMware DRS)


Функции по распределенному управлению питанием VMware Distributed Power Management позволяют экономить электроэнергию для серверов VMware ESX в пределах виртуальной инфраструктуры. Это достигается за счет автоматического перевода в Standby-режим хостов ESX Server при падении загрузки виртуального центра обработки данных. Функции автоматического управления питанием DPM позволяют также автоматически включать серверы ESX при возрастрании нагрузки.
Таги: VMware, ESX, DRS

 
Реклама

Advertisement

Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

Быстрый переход:
StarWind VMware Microsoft IT-Grad VMFS RVTools Citrix PowerCLI Veeam 5nine VM Guru Oracle Red Hat Parallels Azure KVM vGate VeeamOn Security Code 1cloud Cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Cisco Google VSI HP Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Horizon Client Host Client VMDK App Volumes vROPs VTL vCloud Update iSCSI Labs IaaS SDDC vCSA NSX Virtual Appliance Backup VSA Whitepaper PowerShell Fusion Appliance DRS VUM Manager VVols V2V Tools Workstation Cache VMworld SRM Support Обучение XenDesktop Web Client Mobile OpenStack Automation Replication Desktop Log Insight Fault Tolerance DR Photon Vanguard SaaS Connector HA SSO Event Free Datacenter SQL VSAN Workspace Lifecycle Sponsorship Finance FT Cloud Computing Converter XenApp esxtop Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification SSD VDP Partners PCoIP RHEV Performance Award Network AWS USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно Nested vExpert Beta SAN Exchange MAP ONE DaaS Networking vNetwork Monitoring VPLEX UCS SDK Poster VSPP SDRS Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Plugin Troubleshooting DPM Director Book Memory Upgrade API SIOC Flex Mac Bug Open Source SSH Air VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS CLI Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Сравнение Oracle VirtualBox и VMware Workstation.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6


Veeam Backup 8


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2017, Александр Самойленко. Правила перепечатки материалов.