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

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

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

VM Guru | Ссылка дня: PowerCLI Extensions теперь поддерживает PowerCLI 11.0

Как работают политики Storage Policy Based Management (SPBM) для томов Virtual Volumes (VVols) в инфраструктуре VMware vSphere.


Недавно мы писали о политиках хранилищ Storage Policy Based Management (SPBM) на базе тэгов, которые помогают использовать возможности платформы VMware vSphere для назначения виртуальным машинам хранилищ на томах VMFS/NFS с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Сегодня мы поговорим о политиках SPBM для виртуальных томов VVols на хранилищах, которые предоставляют различные возможности через интерфейс VASA (vSphere APIs for Storage Awareness). Механизм VASA реализуется производителем дисковой системы (storage provider) на программно-аппаратном уровне, при этом дисковый массив полностью отвечает за использование его возможностей, а со стороны vSphere возможно только управление ими средствами механизма SPBM.

Через интерфейс VASA Provider устройство хранения сообщает платформе vSphere, какие сервисы оно предоставляет, а через административный том на хранилище Protocol Endpoint (PE) происходит процессинг операций ESXi с массивом:

К таким возможностям в общем случае относятся:

  • Шифрование
  • Дедупликация данных на массиве
  • Репликация данных внутри массива и на другие массивы
  • Функции уровня обслуживания QoS (ограничения по IOPS и Latency)
  • Выбор яруса хранения / типа дисков (регулирование уровня производительности)

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

Самое приятное в использовании механизма SPBM для хранилищ на основе VVols в том, что вам не требуется заботиться о томах LUN, дисковых группах и настройке их параметров - массив сам распорядится размещением данных по ярусам (Tiers) и датасторам, а также обеспечением уровня их производительности (Service levels).

Например, вот так просто выглядят правила (Rules) для первичного размещения виртуальных машин на массиве EMC Unity при выборе уровня обслуживания и производительности для новой политики SPBM:

 

В массивах может быть также реализован QoS в зависимости от критичности приложения (Mission Critical приложения всегда первыми получат ресурсы ввода-вывода):

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

Хранилище может предоставлять не только правила размещения виртуальных машин и обеспечения их функционирования, но и сервисы репликации, как например у Pure Storage (они позволяют, в том числе, настроить репликацию на уровне отдельных VMDK дисков машин):

Также создание политик SPBM для томов VVols можно посмотреть на видео ниже:

А вот так применяются политики SPBM, включая сервисы репликации:


Таги: VMware, SPBM, Storage, vSAN, VVols

Сценарии отказов компонентов дисковой подсистемы кластера VMware vSAN - APD и PDL.


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

Как известно, дублирование дисковых компонентов и объектов в кластере vSAN зависит от политики Failures to tolerate (FTT) и уровня RAID, заданного для политики, которой подчиняется виртуальная машина:

Если для машин хоста задана политика с FTT=1 и RAID-1, то в общем случае, при отказе хоста ESXi, через 60 минут начинается ресинхронизация его дисковых объектов на других хостах, чтобы обеспечить выполнение политики FTT.

В случае сбоя какого-либо из компонентов дисковой подсистемы хранения кластера (от диска до хоста) механизм vSAN делит характер сбоя на 2 состояния: APD (All Paths Down) и PDL (Physical Device Loss). Об этих состояниях мы подробно писали вот тут.

  • APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. Это состояние считается временным и также называется "absent". Иными словами, мы не знаем, что случилось с устройством, может быть оно будет доступно в будущем. В этом случае vSAN не начинает сразу восстановление дисковых компонентов и объектов, а ждет 60 минут, чтобы не тратить напрасно ресурсы в случае, если устройство снова станет доступно. Время до начала восстановления можно регулировать настройкой Object Repair Timer, о которой мы детально писали вот тут
  • PDL (Physical Device Loss) - состояние, когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет. Этот статус считается постоянным и также называется "degraded". В этом случае кластер vSAN сразу начинает восстановление дисковых объектов, несмотря на значение Object Repair Timer. Примером таких состояний является выход из строя дискового массива или его части, поломка HBA/RAID-контроллера и т.п.

Давайте посмотрим, как именно реагирует кластер vSAN на различные варианты отказов и поломок дисковой подсистемы в кластере:

Сценарий отказа  Поведение vSAN  Воздействие на ВМ и поведение HA
Отказ диска в группе кэширования Дисковая группа помечается как "failed", и все ее компоненты перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ диска с данными (функции Dedupe и Compression включены) Дисковая группа помечается как "failed", и все ее компоненты перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ диска с данными (функции Dedupe и Compression отключены

Диск помечается как "failed", и все его компоненты перестраиваются на другом диске группы (rebuild).

ВМ продолжат работать
Отказ дисковой группы Все компоненты группы перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ контроллера RAID/HBA-карточки

Все дисковые группы под контролем карточки HBA/RAID будут помечены как absent и будут перестроены на других дисковых группах (rebuild).

ВМ продолжат работать
Отказ хоста или изоляция хоста

Компоненты на хосте будут помечены как absent и через 60 минут, если хост не вернется в онлайн, будут признаны устаревшими с последующим удалением (stale) после начал процесса перестроения дисковых объектов этого хоста (rebuild).

ВМ других хостов продолжат работать, ВМ этого хоста будут перезапущены HA на других хостах.

А вот графическая иллюстрация того, что происходит через 60 минут в кластере при отказе хоста ESXi. Обратите внимание, что если хост появится снова онлайн после сбоя и начала ресинхронизации (>60 минут) - его дисковые компоненты будут признаны "stale" и удалены механизмом vSAN, чтобы использовать его дисковое пространство в полном объеме.


Таги: VMware, vSAN, HA, Storage, VMachines

Политики хранилищ SPBM (Storage Policy Based Management) на базе тэгов в кластере VMware vSAN.


Мы уже упоминали о политиках хранилищ SPBM, (Storage Policy Based Management) в кластере VMware vSAN, которые представляют собой очень гибкий механизм для выделения виртуальным машинам хранилищ с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Политики SPBM разделяются на 3 основных области:

  • Storage Capabilities and Services - это политики, которые работают, когда хранилище vSAN или VVols представлено через интерфейс VASA производителем дисковой подсистемы (storage provider). Через VASA это устройство сообщает, какие сервисы оно предоставляет.
  • Data Services - это политики, настраиваемые на уровне хоста ESXi, они также реализуются на стороне дискового устройства (storage provider). Эти политики не определяют размещение виртуальных машин, но влияют на их возможности, например, использование шифрования или механизма SIOC.
  • Tags - это политики, которые используются хранилищами, которые не предоставляют каких-либо специфических функций, как правило - это обычные тома VMFS и NFS традиционных дисковых массивов без поддержки VASA.

В этой статье мы рассмотрим использование таких объектов, как тэги (Tags) и категории (Categories). Они могут оказаться полезными, когда вы хотите высокоуровнево определить параметры размещения и конфигурации виртуальных машин и их дисков на хранилищах, хостах, кластерах или в других объектах виртуальной инфраструктуры.

Поддержка правил на базе тэгов определяется при создании политики:

С помощью тэгов можно задать ярусы размещения ВМ, конфигурации дисков и их расположение, тип ОС, департамент, к которому принадлежит ВМ, тип дисков SAS/SATA/SSD и многое другое. Вот какие аспекты размещения внутри объектов виртуальной инфраструктуры можно контролировать через категории и тэги:

Например, вы хотите сделать так, чтобы виртуальные машины с гостевой ОС Linux попадали на определенные хранилища. В этом случае надо создать категорию "OS" для объектов Datastore и Datastore Cluster и тэг "Linux", который надо назначить заданным хранилищам. После этого машины с таким тэгом при выборе соответствующей политики SPBM будут попадать на заданные стораджи.

Так, например, может выглядеть конфигурация тэгов и категорий в вашей инфраструктуре:

В рамках одной политики можно использовать до 128 тэгов - это излишне, но если у вас есть фантазия, то вы можете использовать их все) Например, вы можете использовать категорию Department для отдела, а внутри создать тэги для всех отделов: Financial, HR, Engineering и т.п.

Категории и тэги можно использовать для разных аспектов конфигураций хранилищ. Например, тип ОС или тип дисков, на которых размещены ВМ (Category: Disk Type, Tag: SAS).

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

Весь этот процесс показан на видео ниже:

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

Политики SPBM можно использовать не только отдельно для томов VMFS и NFS, но и для инфраструктуры vSAN и VVols, которые регулируются политиками на уровне хостов (host-based services). Например, можно создать политику, которая позволяет виртуальной машине использовать тома VVols, но только в определенном физическом размещении. Таким образом, с помощью провайдера VASA вы выбираете storage capability как VVols, а с помощью тэгов - физическое размещение ВМ.

Вот как это работает при создании политики:

С помощью PowerCLI вы можете получить информацию о виртуальных машинах или хранилищах, тэгированных определенным тэгом. Вот пример команды для ВМ:

Get-VM -Tag Windows
Name PowerState Num CPUs MemoryGB
---- ------- -------- --------
Windows-VMFS-VM PoweredOff 1 4.000
Win10-3 PoweredOn 2 4.000
jm-ws2016 PoweredOn 2 4.000
Win10-2 PoweredOn 2 4.000

И для хранилища:

Get-Datastore -Tag California
Name FreeSpaceGB CapacityGB
---- --------- ----------
N-VVol-Cali 2,048.000 2,048.000

При использовании механизмов размещения SPBM можно задавать уровень возможности их нарушения (Enforcement). Об этом вы можете прочитать в KB 2142765.

Несколько полезных ресурсов про политики SPBM:


Таги: VMware, SPBM, Storage, VMFS, NFS, VVols, vSAN, VMachines, Blogs

Режим обслуживания хостов кластера VMware vSAN Maintenance Mode - как это работает?


Как знают многие пользователи решения для создания отказоустойчивых кластеров VMware vSAN, в данном продукте есть возможность перевода хоста в режим обслуживания (Enter Maintenance Mode, EMM), который позволяет вывести его на время из эксплуатации с сохранением работоспособности кластера в целом. При этом происходит взаимодействие vSAN и механизма балансировки нагрузки VMware vSphere Distributed Resource Scheduler (DRS), который эвакуирует виртуальные машины с хоста ESXi.

Давайте посмотрим, как работает EMM для кластера vSAN, и какие есть опции для данной процедуры. Чтобы перевести хост ESXi в режим обслуживания, надо нажать на него правой кнопкой в vSphere Client и выбрать пункт Maintenance Mode > Enter Maintenance Mode.

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

  • Full Data Migration – это миграция всех компонентов дисковых объектов на другие хосты кластера.
  • Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов в этом случае не будет соблюдена политика Failures to tolerate (FTT).
  • No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).

С первым пунктом (Full Data Migration) все ясно - он вызывает долговременную процедуру миграции всех дисковых объектов и не всегда оправдан, когда хост ESXi нужно погасить лишь ненадолго. Но если вы выводите хост ESXi из эксплуатации производственного кластера (либо останавливаете, например, на несколько дней), то нужно выбирать именно Full Data Migration.

Давайте подробнее рассмотрим вариант Ensure Accessibility, который как раз подходит для кратковременного обслуживания хоста и последующего его повторного ввода в эксплуатацию. Если у вас достаточно запаса дисковых ресурсов, и виртуальные диски машин работают в RAID-1, то копии дисковых объектов переводимого в режим обслуживания хоста должны быть на других серверах. На картинке ниже реплика объекта C1 есть на другом хосте, поэтому в режиме Ensure Accessibility никаких миграций данных производиться не будет, кластер продолжит работать в режиме полной производительности:

Если же у вас, например, задана политика кластера FTT=1 на четырех хостах, и компоненты дисковых объектов хранятся в соответствии с политикой RAID-5, то картина будет следующей:

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

Между тем, если vSAN object manager будет наблюдать ситуацию несоответствия политики надежности более чем 60 минут (см. параметр Object repair timer в конце статьи), то он, все-таки, запустит синхронизацию дисковых объектов, чтобы их конфигурация в итоге соответствовала действующим политикам.

Кстати, обратите внимание, что такое поведение кластера vSAN - это одна из причин, почему VMware Update Manager не делает обновление хостов ESXi кластера vSAN в параллельном режиме, а проводит это последовательно. Ведь если бы это происходило параллельно, не факт, что можно было бы выполнить требования опции Ensure Accessibility, а также происходило бы много миграций дисковых компонентов.

Кроме того, перед переходом в режим обслуживания хоста, EMM делает полную симуляцию перемещений данных, которые будут проведены в процессе выключения хоста. Например, у нас есть 3 виртуальные машины: vm01 с политикой RAID-0 (без избыточных копий данных), а также машины vm02 и vm03 в режиме RAID-1 (зеркало).

Обратите внимание на картинку ниже:

Здесь показано, что в соответствии с вариантом No data migration 3 дисковых объекта виртуальной машины vm01 окажутся недоступными, а 30, относящихся к vm02 и vm03, не будут соответствовать действующей политике по обеспечению надежности.

Если мы нажмем на ссылку See detailed report, то увидим подробную картину симуляции EMM:

То есть, vm01 окажется недоступной, а vm02 и vm03 будут Non-compliant, пока хост находится в режиме обслуживания.

Если же вы выберете вариант Ensure Accessibility, то прогноз будет следующим:

440 МБ дисковых объектов, относящихся к vm01 будут перемещены, а 30 объектов не будут соответствовать политике, при этом все ВМ останутся доступными. Также в VMware vSAN 6.7 Update 1 появились новые предупреждения о том, что в кластере есть активные процессы синхронизации, а также переходящие или уже перешедшие в режим обслуживания хосты ESXi.

Ну и напомним о настройке Object Repair Timer, которую мы детально рассматривали вот тут. Она то, как раз, и позволяет вам расширить окно обслуживания хоста ESXi в Maintenance Mode, если вам это требуется для проведения какой-то долгой операции. По умолчанию синхронизация не соответствующих политике дисковых объектов начнется через 60 минут:

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


Таги: VMware, vSAN, HA, ESXi, VMachines, Storage

Полезные расширенные настройки (Advanced Options) кластера VMware vSAN 6.7 Update 1.


Как почти все знают, компания VMware в рамках конференции VMworld 2018 анонсировала доступность новой версии решения для создания отказоустойчивых хранилищ VMware vSAN 6.7 Update 1. В обновленном vSAN появилась масса новых возможностей, но сегодня мы расскажем о трех новых расширенных настройках (Advanced Options), про которые написал Cormac Hogan, и которые стали доступны для редактирования в графическом интерфейсе.

Ранее Кормак рассказывал про следующие расширенные настройки кластера vSAN:

  • VSAN.ClomRepairDelay - задержка перед началом ребилда отсутствующих компонентов.
  • VSAN.DomOwnerForceWarmCache - определяет, должны ли операции чтения производится со всех реплик дисковых объектов, либо с определенных сайтов растянутого (stretched) кластера vSAN.
  • VSAN.SwapThickProvisionDisabled - возможность сделать swap-файлы виртуальных машин тонкими, то есть растущими по мере наполнения данными.

Теперь эти три настройки в новой инкарнации можно найти в разделе:

Cluster > Configure > vSAN > Services > Advanced Options

При нажатии на ссылку EDIT можно открыть интерфейс их изменения:

1. Настройка Object Repair Timer.

Как было сказано выше, она определяет задержку, после которой начинается ребилд отсутствующих дисковых объектов в кластере после произошедшего сбоя. По умолчанию она установлена в 60 минут (время, которое нужно VMware Update Manager для обновления хоста ESXi). Также тут нужно достаточное время, чтобы не происходило ненужных срабатываний при временных проблемах в сети. Если вы просто тестируете продукт vSAN, то можете поставить ее, например, в 15 минут, чтобы посмотреть, как начнется процесс ребилда.

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

2. Настройка Site Read Locality.

Эта настройка определяет, будут ли данные растянутого (stretched) кластера читаться из реплик дисковых объектов на уровне одного сайта (домена отказа), либо будут читаться из всех реплик дисковых объектов ВМ. Второй вариант подходит, когда между площадками у вас налажено высокоскоростное соединение (inter-site link), не отличающееся по скорости от внутреннего. Если же это совсем не так, то Read Locality можно отключить.

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

3. Настройка Thin Swap.

Она определяет, будут ли файлы подкачки виртуальных машин "тонкими", то есть растущими по мере наполнения данными. Тонкие swap-файлы экономят дисковое пространство, но создают совсем маленькую нагрузку по IO при аллоцировании блоков. По умолчанию тонкий своп включен.

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


Таги: VMware, vSAN, Update, Storage, VMachines, DR

Анонсы VMworld Europe 2018, часть 3 - технология VMware vSAN Native Data Protection.


Некоторое время назад мы писали о продуктах и технологиях, анонсированных на конференции VMworld Europe 2018 (часть 1 и часть 2), а сегодня поговорим о еще одной технологии, объявленной в рамках мероприятия - VMware vSAN Native Data Protection. О ней в своей статье рассказал Viktor van den Berg.

Данная технология будет представлять собой репликацию данных виртуальных машин на уровне хранилищ на базе снапшотов (а также будет доступна локально в рамках хранилища) в целях создания резервных копий ВМ. Работать этот механизм будет в соответствии с текущей механикой политик Storage Policy Based Management (SPBM).

Использовать технологию vSAN Native Data Protection можно для трех сценариев:

  • Защита локальных виртуальных машин без использования снапшотов vSphere.
  • Репликация данных машин на стороннее хранилище NFS.
  • Репликация данных машин на другую площадку (другой кластер vSAN) под управлением того же (или другого) сервера vCenter.

Технология vSAN Local Data Protection будет использовать механизм native vSAN snapshots, который почти не оказывает влияние на производительность ВМ (поскольку работает на уровне хранилища). Также будут поддерживаться консистентные с точки зрения приложений снапшоты, которые будут использовать скрипты Microsoft VSS / VMware Tools для "подморозки" приложений.

Вот так эта настройка будет выглядеть в мастере конфигурации политики хранилищ для ВМ:

Как мы видим, можно установить частоту создания снапшотов (по сути, требования RPO). Далее идет настройка про то, с какой периодичностью делать application consistent снапшоты. Ну и в конце - число хранимых снапшотов.

Некоторые снапшотоы можно будет хранить в течение долгого периода времени в архивных целях:

Также расписание снапшотирования и откидывания на NFS-хранилище будет представлено в таблице:

Сточки зрения восстановления машин из локальных снапшотов, будет использоваться технология Linked Clone, с помощью которой процесс поднятия ВМ будет занимать около одной минуты. Восстановление полностью независимой ВМ займет существенно больше времени (в зависимости от объема хранилища). При восстановлении ВМ можно выбрать кластер, куда восстанавливать, а также VM Network.

Также в процессе работы vSAN Native Data Protection можно просматривать информацию о ее состоянии в целом:

И для виртуальных машин:

Также будет несколько интересных моментов:

  • Пока не будет интеграции vSAN Native Data Protection и SRM.
  • В будущем планируется создание резервных копий с помощью снапшотов для групп ВМ (consistency groups), если они, например, располагаются на разных хранилищах.
  • Минимально RPO можно указать как 5 минут.
  • Для обеспечения консистентности бэкапов на уровне приложений можно будет использовать собственные скрипты подготовки и возобновления приложения, а также Microsoft VSS.
  • Технология будет интегрирована со сторонними решениями для резервного копирования и фреймворком VADP.
  • Репликация на удаленное хранилище также будет использовать снапшоты в своей основе.
  • Без application consistent снапшотов (только crash consistent) хранилище будет снапшотиться мгновенно.
  • Будет поддерживаться репликация как между разными кластерами, так и между разными vCenter.
  • В качестве архивного хранилища будет поддерживаться пока только NFS, но потом можно будет использовать и облачный сторадж Amazon S3.
  • Нативные снапшоты будут дедуплицироваться и сжиматься при передаче.

Доступность технологии vSAN Native Data Protection ожидается в первом квартале 2019 года, а пока вы можете запросить доступ к vSAN Beta, где эта технология уже имеется.

Также полистайте вот эту презентацию и посмотрите вот эту запись с сессии VMworld Europe 2018.


Таги: VMware, vSAN, Update, Beta, Snapshots, Backup, Replication

3 очень серьезных бага VMware vSphere - обязательно накатите обновления!


Совсем недавно стало известно о трех очень серьезных багах в платформе VMware vSphere, которые затронули, как платформу vSphere 5.x/6.x, так и средство создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 6.6/6.7.

1. Повреждение данных виртуальных дисков снапшотов формата SEsparse.

Начиная с VMware ESXi 5.5, диски стапшотов виртуальных машин стали создаваться в формате SEsparse. Такой диск создается в ESXi 5.5 если диск машины более 2 ТБ, а начиная с ESXi 6.0 / VMFS6 - он используется для снапшотов всех машин. Так что под угрозой практически все виртуальные машины со снапшотами. А ведь снапшоты используются всеми ВМ, для которых применяется резервное копирование через механизм vSphere API for Data Protection (например, с помощью продукта Veeam Backup and Replication).

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

Баг и возможные способы решения описаны в KB 59216. В vSphere 6.7 Update 1 баг уже пофикшен. Для остального есть следующие апдейты:

Для ESXi 5.5 обновления нет, но вы можете отключить функцию "IO coalescing" для формата дисков SEsparse. Делается это следующей командой:

esxcli system settings advanced set -i 0 -o /COW/COWEnableIOCoalescing

2. Проблема консистентности виртуальных дисков машин на платформе vSAN 6.6.

Аналогично багу из прошлого пункта, здесь может произойти неприятность с целостностью данных виртуальных машин, которые работают в кластере хранилищ VMware vSAN 6.6. Это может случиться в следующих обстоятельствах:

  • vSAN начинает процесс ресинхронизации
  • В этот момент вы расширяете диск VMDK виртуальной машины
  • vSAN снова начинает ресинхронизировать уже расширенный диск виртуальной машины

Проблема описана в KB 58715. В этом случае вы сможете только восстановить консистентность виртуальных машин, но сами данные приложений вы уже не вернете.

Для устранения бага накатите патчи на vSAN:

Также вы можете временно избежать проблемы, выполнив такую команду на каждом хосте ESXi:

esxcfg-advcfg -s 0 /VSAN/ClomEnableInplaceExpansion

3. Получение доступа root к хосту ESXi из виртуальной машины.

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

Кстати, это было публично показано впервые:

Информация об этой уязвимости опубликована в VMware advisory VMSA-2018-0027. Там же есть и названия необходимых вам патчей (обратите внимание, что багу подвержены также и платформы Workstation / Fusion).


Таги: VMware, vSphere, Bug, Bugs, vSAN, Security, VMachines, Storage, Networking

Документ о тестировании работы баз данных Oracle в All-Flash кластере VMware vSAN 6.7.


Компания VMware выпустила документ, касающийся работы баз данных Oracle Database 12c на платформе VMware vSAN - Oracle Database on VMware vSAN 6.7. Основная тема дока - тестирование числа операций ввода-вывода (IOPS) и latency операций СУБД на хостах в All-Flash конфигурации, когда и ярус кэширования, и ярус хранения реализован на SSD-дисках:

В документе рассматривается 4 ключевых аспекта для реализации тяжелых баз данных:

  • Производительность OLTP-нагрузок в кластере all-flash vSAN.
  • Политики Storage Policy Based Management (SPBM) для управления хранилищами.
  • Построение платформы для бизнес-критичных задач уровня Tier-1.
  • Валидация архитектуры для уменьшения времени развертывания и операционных рисков.

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

В тестах использовалось два типа рабочих нагрузок (R1 и R15), отличающихся конфигурацией ВМ, а также включенными или выключенными технологиями дедупликации и компрессии на стороне vSAN:

Описание рабочей нагрузки:

Базовые результаты по IOPS и latency для операций чтения и записи:

После результатов тестирования в документе есть секция с рекомендациями по исполнению Oracle на хранилищах vSAN, которые будет полезно почитать администратору БД и vSphere (большая их часть приведена в vSAN Design and Sizing Guide).


Таги: VMware, vSAN, Performance, Oracle, AWS, Cloud, Storage, Flash, SSD, Whitepaper

Платформа VMware vSphere 6.7 Update 1 и решение vSAN 6.7 Update 1 доступны для скачивания!


Спустя несколько недель ожидания после анонса обновленной версии платформы виртуализации VMware vSphere 6.7 Update 1, компания VMware сделала ее доступной для загрузки. Скачать продукт, включая ESXi 6.7 Update 1 и vCenter 6.7 Update 1, можно по этой ссылке:

https://my.vmware.com/en/web/vmware/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/6_7

Напомним, что обо всех новых возможностях этого решения мы писали вот тут. Кроме того, в составе vSpher 6.1 Update 1 стал доступен и VMware vSAN 6.7 Update 1, про который мы писали вот тут.

Ну и главная новость этого релиза - это, бесспорно, полнофункциональный vSphere Client на базе HTML5! Мы ждали этого годами, и это сбылось. Вот пост об этом от VMware, там много подробностей, о которых мы скоро тоже расскажем.

Для него, кстати, доступна темная тема (см. последние наши новости о vSphere Client 3.42):

Клиент на HTML5 включает в себя не только все старые рабочие процессы, но и новые возможности, такие как упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).

Вкратце суммаризуем все новые возможности VMware vSphere 6.7 Update 1:

  • Полнофункциональный VMware vSphere Client на базе HTML5
  • Утилита vCenter Server Converge Tool для миграции на внедренный (embedded) PSC
  • Новая версия vSAN и улучшения HCI (обновления микрокода через Update Manager)
  • Улучшения Content Library
  • vMotion для карточек NVIDIA Quadro vDWS и поддержка Intel FPGA

Отдельно давайте посмотрим, а что нового появилось в VMware vSAN 6.7 Update 1:

  • Новый мастер Cluster quickstart
  • Обновление драйверов и firmware через Update Manager
  • Механизмы защиты при выводе хостов из эксплуатации и переводе в режим обслуживания
  • Разные представления vROPs для обычных и растянутых кластеров vSAN
  • Улучшенные возможности Capacity reporting
  • Поддержка TRIM/UNMAP
  • Поддержка режима Mixed MTU для растянутых кластеров
  • Обновленные средства для сайзинга инфраструктуры
  • Улучшенные функции Health Check
  • Улучшенная диагностика для персонала поддержки VMware GSS

Обновить VMware vCenter Server Appliance 6.7 на Update 1 можно через интерфейс VAMI (vCenter Appliance Management Interface, он же Appliance Management User Interface или MUI):

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


Таги: VMware, vSphere, Update, vSAN, ESXi, vCenter

VMware TestDrive - реальное тестирование различных продуктов для партнеров и клиентов VMware.


Многие из вас пользуются лабораторными работами VMware Hands-on Labs, которые позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Но это подходит только для целей обучения работе в интерфейсе этих решений, а если хочется полноценно запустить какой-нибудь продукт (например, vSAN, NSX или PKS) в реальных условиях и посмотреть на его производительность - то для этого есть портал VMware TestDrive, о котором недавно написал Дункан Эппинг.

Сервис TestDrive доступен для сотрудников VMware и ее партнеров, но хорошая новость в том, что партнеры могут давать туда доступ своим потенциальным и действующим заказчикам.

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

TestDrive работает в облаке Softlayer от IBM и доступен во всех глобальных регионах по миру (US, EMEA, APJ). При этом, работая с инфраструктурой, вы можете делать множество интересных вещей под аккаунтом SuperUser, свободу сильно не ограничивают, за исключением удаления объектов. VMware говорит, что TestDrive в этом году использовали уже 344 тысячи раз.

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

Чтобы партнерам VMware использовать данный сервис, им нужна компетенция VTSP HCI, после чего TestDrive будет доступен через Partner Central. Для начала получения компетенции зайдите в Partner University и подпишитесь на аккредитацию Hyper-Converged Infrastructure accreditation:

Одно из самых интересных на портале - возможность тестирования кластеров хранилищ vSAN (на данный момент это vSAN 6.7, но скоро окружение будет обновлено до vSAN 6.7 Update 1). Там доступно управление виртуальной инфраструктурой десктопов Horizon и машинами, а также есть доступ к средству тестирования нагрузки HCIBench. С помощью решений vSAN Health and Performance Service и vROPs можно замерять задержки (latency) и число операций ввода-вывода в секунду (IOPS) в различных условиях эксплуатации виртуальных машин:

Надо понимать, что в качестве аппаратной среды используется All-Flash конфигурация хостов, поэтому все работает довольно шустро.

Для доступа к сервису нужно попросить его у своего поставщика, являющегося партнером VMware, который должен зарегистрироваться на портале vmtestdrive.com.

Бонус для дочитавших до этого места! Дункан выбил возможность всем желающим использовать VMware TestDrive в течение 30 дней, для этого надо зарегистрироваться с промо-кодом DUNCANYB или использовать вот эту ссылку.


Таги: VMware, vSAN, TestDrive, Performance

Возвращение дискового пространства гостевой ОС в VMware vSAN 6.7 Update 1 в сторону аппаратного хранилища (TRIM / UNMAP).


Не так давно мы писали про новые возможности решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 1. Одной из новых возможностей этого продукта стала функция возвращения неиспользуемого гостевыми ОС дискового пространства в сторону физической дисковой подситсемы. Ранее эта возможность не работала, о чем мы писали вот тут.

Все понимают, что современные операционные системы стараются писать новые данные в новые пустые блоки, чтобы оставалась возможность восстановить старые, помеченные как удаленные. vSAN поддерживает технологию thin provisioning, что позволяет создавать хранилища растущие по мере наполнения данными. Но дело в том, что такие хранилища растут всегда, даже когда в гостевых системах освобождается место, что следует из первого предложения этого абзаца.

В этом случае очень бы хотелось это место вернуть опять как свободное на сторону дискового хранилища, так вот функции TRIM и UNMAP именно это и делают. vSAN 6.7 U1 теперь полностью обрабатывает SCSI/ATA-команды TRIM/UNMAP и автоматически возвращает дисковое пространство хранилищу. При этом, поскольку vSAN не использует тома LUN или VMFS, в рамках этой процедуры не требуется прохождения рабочего процесса через эти уровни абстракции.

Помимо очевидного преимущества очистки хранилища, процесс возвращения дисковых блоков имеет еще 3 позитивных эффекта:

  • Блоки, вышедшие из пространства vSAN, не нужно реплицировать между хостами и тратить на это ресурсы.
  • Эти блоки не надо обрабатывать со стороны систем резервного копирования.
  • Очистка грязных страниц из кэша на чтение, что уменьшает число копируемых блоков между кэшем и ярусом хранения (capacity tier).

VMware говорит, что в целом TRIM/UNMAP не влияет на производительность, но если происходит большое число команд UNMAP, то надо посматривать за производительностью.

Для включения этого механизма можно использовать команду:

vsan.unmap_support VSAN-Cluster -e

Windows Server 2012 и более поздние версии ОС поддерживают автоматическое возвращение дискового пространства. Чтобы проверить работу этой функции, надо выполнить команду:

Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\FileSystem" -Name DisableDeleteNotification

Для включения этой возможности на уровне гостевой ОС надо выполнить команду:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\FileSystem" -Name DisableDeleteNotification -Value 0

Надо отметить, что процесс возвращения блоков происходит асинхронно, поэтому результат проявляется не сразу. Чтобы в Windows запустить TRIM для диска можно выполнить команду PowerShell:

PS C:\>Optimize-Volume -DriveLetter H -ReTrim -Verbose

Результат будет, например, таким:

Также TRIM можно сделать и с помощью утилиты дефрагментации, запустив ее с флагом /L:

Defrag C: D: /L

За производительностью процесса TRIM/UNMAP можно наблюдать в консоли vSAN, в разделе Monitor->vSAN->Performance.

Здесь два основных параметра на нижнем графике:

  • UNMAP Throughput - скорость прохождения команд UNMAP к дисковым группам хоста.
  • Recovery UNMAP Throughput - скорость прохождения команд UNMAP, которые выполняются как часть процесса object repair при отсутствующем или испорченном дисковом объекте.

Таги: VMware, vSAN, Storage, Performance

Анонсы VMworld 2018: масса новых возможностей VMware vSAN 6.7 Update 1.


Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 6.7 Update 1, которая была анонсирована на прошедшей конференции VMworld 2018. Одновременно с этим было объявлено и о скором релизе обновленной версии решения для создания отказоустойчивых хранилищ на базе серверов VMware vSAN 6.7 Update 1.

Напомним, что о прошлой версии VMware vSAN 6.7 мы писали вот тут, а теперь давайте посмотрим, что нового появилось в Update 1 к этой версии:

1. Новый мастер Cluster quickstart.

Новый мастер создания кластера включает в себя следующие процессы:

  • Развертывание сервисов, таких как vSphere HA, vSphere DRS и vSAN.
  • Добавление хостов (несколько хостов одновременно).
  • Тип развертывания vSAN.
  • Сетевая конфигурация, включая vSphere Distributed Switching и Enhanced vMotion Compatibility (EVC).
  • Конфигурация дисковых групп.
  • Сервисы дедупликации, компрессии и шифрования.

Посмотреть в деле этот мастер создания кластера можно вот тут.

2. Обновление драйверов и firmware через Update Manager.

Теперь через vSphere Update Manager (VUM) можно обновить микрокод контроллера ввода-вывода с помощью утилиты обновления драйверов от вендора сервера. Таким образом, обновление драйвера I/O-адаптера можно включить в цикл обновления хоста и не заниматься этим отдельно.

Также VUM будет поддерживать кастомные OEM-образы от производителей серверов, а также офлайн процедуры обновления хостов ESXi.

Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее (можно использовать как дефолтный, так и свой репозиторий):

3. Механизмы защиты при выводе хостов из эксплуатации и переводе в режим обслуживания.

Теперь в vSAN 6.7 U1 появились предварительные проверки при переводе хостов в режим обслуживания (Maintenance mode) и выводе из эксплуатации (Decomission). В этом случае с помощью симуляции проверяется, смогут ли все машины хоста успешно переместиться на другие серверы, и только в этом случае запускается реальный процесс.

Это устраняет временные затраты на потенциально неуспешные попытки операций с хост-серверами.

Также были добавлены новые оповещения о том, что идет процесс синхронизации и о том, что в режиме обслуживания нет других серверов в кластере. Кроме этого, была добавлена настройка "object repair timer delay", которая задает интервал времени до начала операций по ребилду кластера vSAN для приведения в соответствие с политиками хранилища.

4. Разные представления vROPs для обычных и растянутых кластеров vSAN.

Теперь при интеграции с решением vRealize Operations 7.0 в интерфейсе vCenter есть два разных представления для обычных и растянутых кластеров, в которых показываются разные метрики и инсайты:

Более подробно об этом можно почитать тут.

5. Улучшенные возможности Capacity reporting.

Отчеты по используемой емкости (Capacity reporting) дают информацию о доступном хранилище, в зависимости от выбранной политики хранилищ (Storage policy):

Также можно посмотреть, сколько хранилища потребуется, если отключить функции дедупликации и компрессии:

Ну и можно посмотреть историю использования пространства в кластере vSAN с учетом изменений в коэффициентах дедупликации и компрессии:

6. Поддержка TRIM/UNMAP.

Это возможности по возвращению неиспользуемого дискового пространства обратно в доступную емкость vSAN. Возможности TRIM/UNMAP позволяют вернуть пространство в кластер для множества гостевых ОС и конфигураций машин.

7. Поддержка режима Mixed MTU для растянутых кластеров.

В vSAN 6.7 появилась возможность выделить трафик Witness на отдельный аплинк серверов, а в Update 1 добавили функцию конфигурации MTU Size для трафика Witness отдельно от MTU Size для межсайтового трафика:

8. Обновленные средства для сайзинга инфраструктуры.

vSAN 6.7 Update 1 предоставляет пользователям улучшенные средства по планированию инфраструктуры и определения ее будущих характеристик. Отчет по окружению и производительности (HCI Assessment):

Планирование узлов ReadyNode для поддержания заданных нагрузок (vSAN Sizer):

9. Улучшенные функции Health Check.

Теперь они охватывают еще и firmware контроллеров хранилищ, интеграция с которыми появилась в этой версии vSAN:

Также с помощью тестов сетевого окружения vSAN можно получить отчет о том, какая пропускная способность доступна в сети. Кроме этого, в Health Check появилась проверка недоступности swap-объектов (см. на картинке выше).

10. Улучшенная диагностика для персонала поддержки VMware GSS.

Напомним, что в vSAN есть встроенные средства диагностики и поддержки vSAN Support Insight, которые получили развитие в этом обновлении. Теперь в vSAN 6.7 Update 1 есть детализированные графики производительности в различных аспектах (особенно полезны в плане сетевого взаимодействия):

Функция Network diagnostic mode предоставляет инженерам VMware GSS данные о состоянии сети, что облегчает работу с обращениями в техподдержку и уменьшает объем собираемых и передаваемых в VMware саппорт-бандлов.

Как ожидается, обновленное решение VMware vSAN 6.7 Update 1 будет доступно одновременно с VMware vSphere 6.7 Update 1 до ноября этого года. Будем держать вас в курсе.


Таги: VMware, vSAN, Update, Storage, VMworld2018

Анонсы VMworld 2018: обновление платформы виртуализации VMware vSphere 6.7 Update 1. Полноценный клиент на HTML5!


На днях в Лас-Вегасе началась конференция VMworld 2018 - главное в году событие в сфере виртуализации. Компания VMware уже в первый день представила немало анонсов новых продуктов и решений, но одним из главных стало объявление о выпуске обновления серверной платформы виртуализации VMware vSphere 6.7 Update 1.

На картинке выше приведены 5 основных новых возможностей vSphere 6.7 U1, давайте посмотрим на них поближе:

1. Полнофункциональный VMware vSphere Client на базе HTML5.

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

Теперь клиент на HTML5 включает в себя не только все старые рабочие процессы, но и новые возможности, такие как упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM). Теперь нет нескольких рабочих процессов, делающих то же самое (раньше были Basic и Advanced), а также улучшились функции работы с Content Library, появился расширенный поиск, упростилась настройка запланированных задач и появились графики top-N (топы по использованию ресурсов).

2. Утилита 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.

Теперь вам не нужны сложные HA-топологии PSC с балансировщиками на разных площадках, серверы vCSA с внедренными PSC на них можно просто соединить между собой.

Утилита vCenter Server Converge Tool работает из командной строки (команда vcsa-converge-cli) и поставляется в комплекте с установщиком vCSA. Ее можно запускать в ОС Windows, macOS и Linux, а конфигурируется она через файл в формате JSON:

Еще одна задача, которая была решена - vCenter Server с компонентом embedded PSC теперь можно перенаправить на другой домен vSphere SSO (это позволяет более гибко распределять и разделять домены SSO в корпоративной инфраструктуре). Ранее это было сделано только для внешних SSO, а теперь доступно и для vCSA.

3. Новая версия vSAN и улучшения HCI.

В новой версии vSAN появилась функция Cluster Quickstart, которая позволяет инициализировать кластер, добавить в него хосты и накатить идентичную конфигурацию на них. Она включает в себя настройку механизмов HA и DRS, Enhanced vMotion Compatibility (EVC), датасторов vSAN и сетевого взаимодействия, включая Virtual Distributed Switch (VDS).

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

Также появилась интеграция микрокода контроллера ввода-вывода с vSphere Update Manager (VUM), который использует утилиту обновления драйверов от вендора сервера. Таким образом, обновление драйвера I/O-адаптера можно включить в цикл обновления хоста и не заниматься этим отдельно.

Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее (можно использовать как дефолтный, так и свой репозиторий):

4. Улучшения Content Library.

Теперь OVA-шаблоны можно импортировать из HTTPS-источника или с локального хранилища. Также содержимое OVA-пакетов можно синхронизировать между несколькими серверами vCSA (сами шаблоны синхронизировать пока нельзя). Content Library обрабатывает сертификаты и файлы манифеста, входящие в OVA-пакеты в соответствии с лучшими практиками безопасности.

Content Library также нативно поддерживает формат шаблонов VMTX и ассоциирует с ними операции, такие как развертывание ВМ напрямую из Content Library.

5. vMotion для карточек NVIDIA Quadro vDWS и поддержка Intel FPGA.

Теперь технология NVIDIA Quadro vDWS (ранее она называлась GRID) для vGPU поддерживается со стороны vSphere 6.7 Update 1. Напомним, что ранее была введена поддержка операций Suspend/Resume для GRID, а теперь появилась и поддержка горячей миграции vMotion для машин с привязкой к карточкам NVIDIA Quadro vDWS. Это позволит обновлять хосты с тяжелыми операциями (например, десктопы с CAD-приложениями) без прерывания работы пользователей.

Также VMware объявила о поддержке карточек Intel Programmable Acceleration Card с технологией Intel Arria 10 GX FPGA. Эта технология позволяет получить прямой доступ к оборудованию с помощью механизма VMware DirectPath I/O через Intel Acceleration Stack для процессоров Intel Xeon CPU с FPGA.

Также в рамках VMworld 2018 было анонсировано новое издание - vSphere Platinum, которое предоставляет расширенные функции обеспечения безопасности для корпоративной инфраструктуры. О нем мы расскажем в следующей статье.

О дате доступности для загрузки обновления VMware vSphere 6.7 Update 1 пока не сообщается.


Таги: VMware, vSphere, Update, VMworld2018, ESXi, vCenter, vCSA, vSAN

VMware vSAN Stretched Cluster и архитектура Horizon View.


Cormac Hogan, специалист по отказоустойчивым серверным хранилищам на базе хостов VMware vSAN, написал интересный пост о "растянутых кластерах" (vSAN Stretched Clusters). Это кластеры, которые образуют единое пространство хранения между двумя географически разделенными площадками, в котором продолжают работать различные механизмы обеспечения доступности виртуальной инфраструктуры, например, VMware HA (он восстанавливает отдельные ВМ в рамках площадок, а также всю площадку целиком в случае ее сбоя).

Если вы используете виртуальные ПК на базе полных клонов с инфраструктуре VMware Horizon View, то вы можете исполнять их на растянутом кластере в конфигурации Active/Passive в рамках одного View Pod (набора серверов Connection Server):

Это именно Active/Passive конфигурация, которая поддерживает пользовательские соединения только на одной площадке, вторая находится в резерве, а вся инфраструктура десктопов управляется одним набором серверов View Pod, размещенном на основном сайте:

Такая архитектура позволяет поддерживать единое пространство хранения и репликации в рамках растянутого кластера, реплицируемого на уровне дисковых объектов vSAN между площадками, а не виртуальных машин, как в случае с vSphere Replication.

В случае сбоя нужно будет только запустить серверы View Connection Servers, которые будут управлять виртуальными машинами на резервной площадке, находящимися в актуальном состоянии с точки зрения дисков. Обо всем этом отлично написано в Appendix H соответствующего раздела документации.

Надо отметить, что архитектура Active/Active (когда десктопы активно работают на обеих площадках) в решении Horizon View не поддерживается для растянутых кластеров. Причина в том, что группа серверов Connection Servers в рамках одного сайта (Pod) должна иметь отличное соединение по сети LAN, чему нет гарантий в среде растянутого кластера, когда они разместятся на обеих площадках.

При этом ничего не мешает вам использовать Active/Active-конфигурацию не для растянутого кластера, а для двух Pods с разными кластерами vSAN на каждой из площадок в рамках архитектуры Cloud Pod Architecture (CPA).

Ну а если вы используете non-persistent виртуальные десктопы и связанные клоны (Linked Clones) или мгновенные клоны (Instant Clones), то рекомендация VMware тут та же самая - не использовать растянутый кластер vSAN. Потому что, в отличие от полных клонов, данные дисковых объектов могут создаваться и уничтожаться на лету в больших объемах, что пока еще не поддерживается для единого пространства хранения vSAN.

Вместо этого нужно создавать View Pod на каждой из площадок и поддерживать свой кластер vSAN на уровне каждого сайта, как показано на картинке выше.

Ну и еще момент - решение VMware AppVolumes также не поддерживается в растянутых кластерах VMware vSAN.


Таги: VMware, vSAN, Stretched, DR, HA, View, Horizon

Опция Erase disks before use при включении шифрования в кластере VMware vSAN.


Многие пользователи кластера отказоустойчивости хранилищ VMware vSAN замечали, что в настройках служб кластера есть такая опция "Erase disks before use", которая доступна при шифровании хранилища (vSAN Encryption).

Эта настройка позволяет очистить диск перед использованием шифрования на нем, чтобы соблюсти требования к безопасности хранения и обслуживания данных, например, NIST 800-88 Revision 1, определение "Clear":

Clear applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques; typically applied through the standard Read and Write commands to the storage device, such as by rewriting with a new value or using a menu option to reset the device to the factory state (where rewriting is not supported).

В приложении A приведенного выше документа есть такая таблица (приведены только 2 строки из нее):

Media Type Media Types Guidance for Clear Operations
SCSI Hard Disk Drives Parallel SCSI, SAS, FC, UAS, and SCSI Express Overwrite media by using organizationally approved and validated overwriting technologies/methods/tools. The Clear procedure should consist of at least one pass of writes with a fixed data value, such as all zeros. Multiple passes or more complex values may optionally be used.
SCSI Solid State Drives (SSSDs) Parallel SCSI, SAS, FC, UAS, and SCSI Express Overwrite media by using organizationally approved and tested overwriting technologies/methods/tools. The Clear procedure should consist of at least one pass of writes with a fixed data value, such as all zeros. Multiple passes or more complex values may alternatively be used.
Note: It is important to note that overwrite on flash-based media may significantly reduce the effective lifetime of the media and it may not sanitize the data in unmapped physical media (i.e., the old data may still remain on the media).

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

Ставя галку "Erase disks before use" надо понимать, что процесс заполнения блоков случайными значениями занимает значительное время, которое зависит от типа используемого хранилища и инфраструктуры хранения в целом.

Также важно помнить, что включение vSAN Encryption влечет за собой шифрование только новых создаваемых дисковых объектов и не применяется к существующим на хранилище блокам (то есть их потенциально можно считать с диска, расшифровка их не потребуется). Таким образом, использование vSAN Encryption с настройкой "Erase disks before use" имеет смысл только при добавлении устройств, где ранее существовали данные.

Поэтому:

  • Включайте опцию "Erase disks before use", когда:
    • Включаете vSAN Encryption для существующуего vSAN кластера, в котором требуется вычистить свободные блоки.
    • Добавляете хост, который имел ранее данные на локальных дисках, в кластер vSAN.
    • Выполняете операцию rekey для инициации процедуры deep rekey (запрос нового KEK и новых уникальных DEKs для каждого устройства vSAN).
  • Не обязательно включать "Erase disks before use", когда:
    • Включаете vSAN Encryption для полностью нового кластера vSAN, в котором ранее не было данных на добавляемых дисках.
    • Добавляете в кластер vSAN хост, у которого на локальных дисках не было чувствительных данных.
    • Выполняете операцию rekey для инициации процедуры shallow rekey (только запрос нового KEK).

Таги: VMware, vSAN, Encryption, Storage, Hardware, Security

Улучшения служб мониторинга производительности в VMware vSAN 6.7.


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

Служба vSAN performance service все еще является опциональной в кластере vSAN, однако уже содержит в себе ряд сервисов, играющих ключевую роль для мониторинга виртуальной инфраструктуры.

На каждом из серверов VMware ESXi служба vSAN performance service развертывается отдельно и позволяет независимо от сервера vCenter собирать данные о производительности кластера и предоставлять их внешним потребителям - CLI, PowerCLI, различным SDK и серверам vCenter:

Такая архитектура позволяет не создавать большой нагрузки на сервер vCenter, который бы в одиночку собирал и обрабатывал эти данные.

Данные о производительности собираются на уровне дисковых объектов, которым назначена определенная политика хранения (Storage Policy). Посмотреть эти объекты можно в разделе vSAN->Virtual Objects:

Так как сервис отслеживания производительности vSAN на хосте ESXi глубоко интегрирован с гипервизором, он позволяет получать метрики для всего стека работы с хранилищем на различных уровнях - виртуальной машины, хоста ESXi и кластера vSAN в целом.

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

В зависимости от того, какой вид просмотра группы или устройства вы выберете, будут доступны те или иные графики производительности. Например, для дисков хранения (capacity devices) будут показаны дополнительные графики "vSAN Layer IOPS" и "vSAN Layer Latency".

Также претерпели изменения разделы "VMkernel Adapters" и "VMkernel Adapters Aggregation" сетевых ресурсов хостов ESXi, которые были объединены в едином представлении Host Network:

Теперь можно выбрать просмотр агрегированных статистик по всем VMkernel адаптерам на хосте, либо выбрать отдельный адаптер. Надо помнить, что статистика по IO в данном разделе - это весь трафик VMkernel, а не только трафик vSAN (например, еще vMotion).

Кстати, интересно, что метрика packet loss, отображаемая как в формате, например, 23%o - это на самом деле не проценты, а так называемое permille-значение. То есть количество потерянных пакетов из одной тысячи (а не из ста, как в случае с процентами). Таким образом, 23%o соответствует значению 2.3% потерянных пакетов.

Еще одно полезное нововведение службы performance service в vSAN 6.7 - это возможность перестраивать размещение графиком в соответствии с разрешением экрана устройства. Например, на небольших устройствах графики будут идти последовательно вниз друг за другом, а на больших экранах показывается вот такой дэшборд:

Ну и последнее приятное улучшение - это возможность выбрать временной отрезок на любом графике и прозуммироваться в этот диапазон. Чтобы вернуться к изначальному представлению, надо нажать Zoom Out:


Таги: VMware, vSAN, Performance, Storage, Troubleshooting

Как узнать детальную статистику по использованию дискового пространства виртуальными машинами кластера VMware vSAN?


В графическом интерфейсе по управлению отказоустойчивым кластером VMware vSAN на платформе VMware vSphere отсутствует детальная информация о том, какая машина сколько физического пространства потребляет на уровне своих объектов (VMDK, vSWP и т.п.). Между тем, это может иногда оказаться полезным для администраторов, которые анализируют использование хранилищ и их рост.

Вильям Лам написал полезный PowerCLI-крипт, который позволяет такую статистику вывести - VSANVMDetailedUsage.ps1. Этот скрипт использует VSAN Management API, а в частности метод VsanQueryObjectIdentities() и свойство includeSpaceSummary.

Сценарий работает напрямую с хостом ESXi (поэтому надо предварительно установить переменные $ESXiHostUsername= "пользователь" и $ESXiHostPassword = "пароль"), а в качестве входного параметра для функции Get-VSANVMDetailedUsage надо указать имя кластера vSAN.

Соответственно, использовать скрипт нужно так:

Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster"

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

Кроме того, скрипт можно использовать и для просмотра информации по дисковым объектам конкретной ВМ, например, так:

Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster" -VM "Ubuntu-SourceVM"

Возможно, эта информация скоро появится в графическом интерфейсе следующих версий VMware vSAN.


Таги: VMware, vSAN, Storage, VMachines, PowerCLI

Онлайн-калькулятор визуализации эффективной емкости VMware vSAN.


На сайте проекта kauteetech.github.io есть интересный калькулятор vSAN Effective Capacity для показа распределения емкости отказоустойчивых хранилищ VMware vSAN. Он показывает размещение различных областей данных в общем пространстве хранения, организованных на серверных узлах All-flash (все SSD диски) или гибридной модели (SSD для кэша, HDD для данных):

Это очень простая утилита для самой примерной визуализации расчетов. Напомним, что для точного вычисления всех параметров есть VMware vSAN Sizer (он также умеет рассчитывать необходимое число узлов vSAN).

В качестве исходных параметров для vSAN Effective Capacity могут быть использованы:

  • Число узлов кластера (хостов ESXi)
  • Число дисковых групп
  • Соотношение дисков с данными на группу
  • Запас по емкости кластера в процентах
  • Затраты на хранение контрольных сумм RAID
  • Размер диска с данными
  • Тип обеспечения отказоустойчивости FTT (число избыточных копий данных)

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


Таги: VMware, vSAN, Calculator, Storage

Механизм Degraded Device Handling в VMware vSAN.


Как знают пользователи решения для создания отказоустойчивых кластеров VMware vSAN, этот продукт имеет множество средств для обработки ситуаций отказа физических устройств - дисков HDD и SSD. В vSAN есть специальный механизм Degraded Device Handling (DDH), который приводит кластер в жизнеспособное сосотояние при отказе одного диска или всей дисковой группы. При этом отказом устройства считается не только его полная физическая поломка, но и резкое снижение производительности, что ведет к ухудшению качества обслуживания пользователей.

Давайте посмотрим, как это работает:

1. Механизм DDH в VMware vSAN 6.1.

vSAN 6.1 ищет устройства, на которых операции ввода-вывода вызывают задержки более 50 мс. Если такое поведение на устройстве сохраняется в течение 10 минут, то vSAN отключает это устройство и вызывает аларм. Если таким устройством является кэш-диск, то в офлайн выводится вся дисковая группа (к счастью, современные SSD-диски весьма надежны).

Вот что будет в этом случае в логах:

2015-09-15T02:21:27.270Z cpu8:89341)VSAN Device Monitor: WARNING – READ Average Latency on VSAN device naa.6842b2b006600b001a6b7e5a0582e09a has exceeded threshold value 50 ms 1 times.
2015-09-15T02:21:27.570Z cpu5:89352)VSAN Device Monitor: Unmounting VSAN diskgroup naa.6842b2b006600b001a6b7e5a0582e09a

Компоненты на такой дисковой группе механизм DDH помечает как "Absent". Ребилд для таких компонентов начнется через 60 минут после отказа устройства, когда истечет rebuild timer. Если этот компонент не является частью группы RAID-1 или RAID-5/6, то он становится недоступным.

В случае с RAID-1 все продолжает работать, и если компонент witness работает, то вы получите только оповещение в vSphere Client:

Однако по некоторым причинам выдача больших latency для операций ввода-вывода на диске в течение более чем 10 минут может быть обусловлена некоторыми рабочими моментами, а начинать rebuild дисковой группы в этом случае нежелательно. Поэтому в vSAN 6.2 появились следующие улучшения DDH.

2. Улучшения DDH в vSAN 6.2.

Здесь появилось 4 новых момента:

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

2. По умолчанию DDH не размонтирует кэш-девайсы и в случае превышения latency на запись. Поскольку это ведет к выводу в офлайн всей дисковой группы, было сделано решение, что такое поведение несет больше вреда, чем медленная работа кэш-устройства. Но это дефолтное поведение можно изменить следующей командой (затрагивает не только кэш, но и диски с данными):

esxcfg-advcfg –set 1 /LSOM/lsomSlowTier1DeviceUnmount

После ее выполнения кэш-устройства и их дисковые группы будут размонтироваться при привышении порога latency на запись.

3. DDH мониторит устройства в рамках случайных 10-минутных интервалов и учитывает несколько таких интервалов. Это предотвращает ложные срабатывания механизма в случае таких операций, как vSAN component recovery, ремапинг секторов HDD-дисков, сбор мусора на SSD и прочее. Теперь для срабатывания DDH нужно 4 превышения latency в непоследовательных 10-минутных интервалах, которые случайно распределены в окне 6-7 часов.

4. DDH пытается снова смонтировать устройства vSAN, которые были ранее размонтированы по превышению latency. Число таких попыток - 24 в окне 24 часа (то есть примерно раз в час). Если условие размонтирования сохраняется, то попытки обратного монтирования прекратятся через сутки.

3. Улучшения DDH в vSAN 6.6 и более поздних версиях.

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

Для HDD дисков был сделан threshold 500 миллисекунд на запись, для SSD - 50 миллисекунд на чтение и 200 миллисекунд на запись.

Теперь, если вышедший из строя диск является последней копией данных, но с него еще как-то можно получить данные, то vSAN не пометит диск как Absent, но начнет эвакуацию данных, таймер vSAN CLOM Rebuild Timer не включится.

В этом процессе есть 4 стадии:

1. Preventative evacuation in progress - желтый аларм сработает, чтобы дать администратору знать о проблеме. vSAN сам превентивно эвакуирует данные, без необходимых действий со стороны администратора.

2. Preventative evacuation is incomplete due to lack of resources - превентивная эвакуация данных не удалась вследствие недостатка ресурсов. В этом случае будет показан красный аларм. Администратору нужно будет высвободить дисковое пространство, например, удалить ВМ или добавить больше дисков, чтобы завершить эвакуацию данных. Разработчики vSAN рекомендуют на такие случаи держать 25-30% кластера свободными.

3. Preventative evacuation is incomplete due to inaccessible objects - это самая плохая ситуация, говорящая о том, что дисковые объекты degraded-устройства недоступны. Если добавление новых ресурсов не помогает, то остается только удалить этот диск из конфигурации vSAN, выбрав опцию "no data migration".

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


Таги: VMware, vSAN, Performance, Monitoring, Hardware

Новый документ - VMware vSAN PoC Performance Checklist.


Компания VMware сделала доступным интересный документ VMware vSAN PoC Performance Checklist, в котором рассматриваются различные аспекты производительности кластеров хранилищ VMware vSAN, которые пользователи развертывают в рамках PoC (proof of concept).

Сначала в рамках чеклиста нам предлагают прочесть следующие документы:

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

Разделы документа:

  • "Before you Start" Tasks
  • Host Based Tasks after vSAN is Deployed
  • Choosing An Appropriate Policy to Test
  • Choosing Data Services
  • Prepping for the HCIBench Benchmark
  • Initial Functional Test -HCIBench Easy Run
  • HCI Bench - Further Tuning

Надо сказать, что эти проверки могут оказаться полезными всем тем, кто испытывает проблемы с производительностью vSAN и поиском их причин. Также в онлайн-документе VMware vSAN PoC Performance Checklist есть возможность скачать его в формате PDF. Ну и если ничего не помогло, то всегда есть почта для обращений - vsanperformance@vmware.com.


Таги: VMware, vSAN, Performance, Storage, Whitepaper

Новые возможности VMware vSAN 6.7 в составе vSphere 6.7.


Как вы знаете, на прошлой неделе компания VMware выпустила обновление платформы виртуализации VMware vSphere 6.7. Одновременно с этим было выпущено и обновление средства создания отказоустойчивых кластеров VMware vSAN 6.7 (оно идет в комплекте с vSphere). Напомним, что о прошлой версии vSAN 6.6.1 мы писали вот тут.

Давайте посмотрим, что нового появилось в vSAN 6.7:

1. Новый интерфейс vSphere Client.

Теперь vSAN можно управлять через HTML5-клиент vSphere Client, который построен на базе фреймворка Clarity, что делает использование рабочих процессов для кластеров хранилищ простым и понятным. Надо отметить, что эти рабочие процессы не были перенесены напрямую из Web Client, а разработаны с самого начала, поэтому выглядят современно и просты в использовании.

2. Поддержка vRealize Operations для vCenter и разделов vSAN.

Традиционно пользователи vSAN должны были использовать две консоли - консоль vCenter и консоль vRealize Operations. Теперь в новой версии vSphere 6.7 появилась функция "vRealize Operations within vCenter", которая позволяет просматривать информацию о кластере vSAN, его параметрах и проблемах через vSphere Client в разделе vRealize Operations:

Вся базовая аналитика кластеров vSAN видна здесь, а если вам потребуется более детальная информация для изучения проблемы - вы можете запустить соответствующий раздел vRO прямо отсюда в два клика.

3. Поддержка других кластерных решений.

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

Среди поддерживаемых кластерных решений для vSAN уже были следующие продукты: Microsoft SQL Always-on Availability Groups (AAG), Microsoft Exchange Database Availability Groups (DAG) и Oracle Real Application Clusters (RAC). Таргеты для этих решений предоставляются средствами технологии vSAN iSCSI.

Теперь в этот набор добавилась технология Windows Server Failover Clusters (WSFC) - она также поддерживается со стороны vSAN 6.7. На эту тему VMware выпустила отдельное видео:

4. Функция Adaptive Resync.

В vSAN 6.7 появилась абсолютно новая фича Adaptive Resync, которая позволяет адаптивно регулировать ширину канала для операций ввода-вывода VM I/O и Resync I/O, в зависимости от загрузки производственной системы.

 

Эта возможность также позволяет гарантировать, что из-за выедания канала каким-то вида трафика, использующего его, остальные типы трафика (см. на картинке выше) не будут блокированы. Также Adaptive Resync выделяет каналам ввода вывода для ВМ и синхронизации кластера vSAN необходимые ресурсы, когда известно, что их использование не скажется на производительности в целом.

5. Оптимизированный механизм de-staging.

В vSAN 6.7 было сделано множество улучшений в плане оптимизации путей данных, а именно дестейджинга данных из кэша на запись (Write Cache) в сторону дисков. Вследствие этого все работает намного быстрее, теперь кэш на запись быстрее "дренируется" на диски, освобождая место для следующих операций ввода-вывода. Это ускоряет не только работу виртуальных машин, но и каналов ресинхронизации.

6. Улучшенные проверки состояний (хэлсчеки).

В vSAN самодиагностика поднялась на новый уровень. Теперь данные о конфигурации кластера собираются с помощью vSAN Support Insight и визуализуются в vSphere Client.

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

  • Верификация перехода в режим Maintenance mode (позволяет убедиться в правильности вывода хоста из эксплуатации на время или навсегда).
  • Проверка консистентности конфигураций для раздела advanced settings.
  • Улучшенные тесты сетевой доступности для сетей vSAN и vMotion.
  • Улучшенная проверка установки vSAN Health service.
  • Теперь улучшенные проверки физических дисков можно комбинировать с другими несколькими проверками в рамках единой нотификации.
  • Проверка Firmware теперь независима от проверки драйверов.

Скачать VMware vSAN 6.7 можно теперь в составе платформы VMware vSphere 6.7. Ну и, напоследок, технический обзор решения VMware vSAN 6.7:


Таги: VMware, vSAN, Update, vSphere

Как правильно выключить кластер VMware vSAN и включить его обратно.


На сайте nolabnoparty.com появилась отличная статья о том, как нужно выключать и включать кластер отказоустойчивых хранилищ VMware vSAN таким образом, чтобы не повредить данных, и включить его потом без особых проблем. Инструкция может оказаться полезной тем администраторам, которым необходимо остановить кластер vSAN целиком в целях обслуживания оборудования (серверы, коммутаторы, стойка и т.п.).

Выключение кластера vSAN

1. Для начала вам нужно выключить все виртуальные машины, кроме сервера VMware vCenter (неважно, обычный это VC или vCSA):

2. Мигрируем с помощью vMotion сервер vCenter на хост ESXi01 (тот хост, который вы считаете своим первым хостом в виртуальной инфраструктуре):

Также на первый хост ESXi настоятельно рекомендуется перевести контроллер домена Active Directory.

3. Теперь надо убедиться, что в данный момент в кластере vSAN нет процессов ресинхронизации (Resyncing Components). Для этого надо зайти в соответствующий раздел на вкладке Monitor:

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

4. Переводим все хосты VMware ESXi (кроме ESXi01) в режим обслуживания (Maintenance Mode):

В настройках режима обслуживания уберите галку с варианта переместить машины (Move powered-off and suspended virtual machines...), а также выберите вариант не перемещать данные кластера vSAN (No data evacuation):

5. Выключите гостевую ОС виртуальной машины c VMware vCenter. Для этого в контекстном меню vCenter или vCSA выберите пункт Shut Down Guest OS:

После этого у вас, само собой, отпадет соединение с VMware vSphere Web Client:

6. Зайдите на хост ESXi через ESXi Host Client (ссылка https://<ip esxi>/ui) и переведите сервер в режим обслуживания, выбрав из контекстного меню пункт Enter maintenance mode:

Аналогично укажите, что не нужно переносить данные кластера vSAN:

Также это можно сделать следующей командой esxcli в консоли сервера:

# esxcli system maintenanceMode set -e true -m noAction

Включение кластера VMware vSAN

1. Сначала последовательно выводим хосты ESXi из режима обслуживания, начав с первого:

Сделать это также можно командой esxcli:

# esxcli system maintenanceMode set -e false

2. Включаем на хосте ESXi01 сервер vCenter и контроллер домена Active Directory:

3. Идем на вкладку Monitor и там в разделе Health убеждаемся, что все узлы в порядке и кластер vSAN прошел все проверки:

4. Только после этого включаем все виртуальные машины:


Таги: VMware, vSAN, Troubleshooting, Blogs, Enterprise

Новые материалы по VMware vSAN 6.6 - видео, whitepaper и виртуальная лаба.


За последнее время у компании VMware вышло несколько материалов по продукту для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.6.

Во-первых, вышло хорошее обзорное видео:

Во-вторых, был опубликован полезный технический документ "VMware vSAN 6.6 Technical Overview", где с технической точки зрения рассматриваются возможности vSAN 6.6:

Ну и, в-третих, вышла лабораторная работа (Hands-On Lab) для администраторов - vSAN 6.6 – Getting Started Hands-on Lab, пройдя которую можно узнать основные возможности продукта и обучиться приемам работы с кластерами vSAN:


Таги: VMware, vSAN, Whitepaper, Video, Labs

Куда делись проактивные тесты VMware vSAN?


Многие из вас знают, что одной из новых возможностей решения для организации отказоустойчивых кластеров хранения VMware vSAN стали проактивные тесты, которые доступны через VMware vSphere Web Client. Раньше их было три штуки:

Но недавно некоторые из вас, возможно, заметили, что в новой версии VMware vSAN (которая доступна с VMware vSphere 6.5 Update 1 Patch 02) остался только одиноко болтающийся тест на создание виртуальной машины:

Дункан Эппинг пишет, что это обусловлено двумя факторами:

  • Тест Multicast performance ушел, так как мультикаст-режим был убран из VMware vSAN (еще в версии vSAN 6.6), соответственно, ушел и тест на его производительность. Теперь когда вы используете vSAN в режиме юникаст, то тест показан не будет, но если будете использовать все же мультикаст - тест появится.
  • А вот тест Storage Performance ушел вот почему: у VMware есть методика тестирования HCI Bench, которая позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ vSAN, а также других конфигураций виртуальной инфраструктуры. Это очень гибкий инструмент, который позволяет проводить наиболее точное тестирование и настраивать различные аспекты методики и среды тестирования. Соответственно, VMware решила поддерживать только один инструмент, а Storage Performance Test убрать из клиента для управления виртуальной инфраструктурой.

Таги: VMware, vSAN, Web Client, Performance

Бесплатная книга "VMware vSAN Essentials" доступна для скачивания.


Дункан Эппинг и Кормаг Хоган решили сделать своим подписчикам подарок на Рождество - бесплатную книгу VMware vSAN Essentials, которая доступна всем желающим по этой ссылке. Книга, правда, о довольно старой версии vSAN 6.2, вышедшей в начале прошлого года, но большинство информации в ней по-прежнему актуально.

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

Содержание:

  • Chapter 1 - Introduction to vSAN
  • Chapter 2 - vSAN Prerequisites and Requirements for Deployment
  • Chapter 3 - vSAN Installation and Configuration
  • Chapter 4 - VM Storage Policies on vSAN
  • Chapter 5 - Architectural Details
  • Chapter 6 - VM Storage Policies and Virtual Machine Provisioning
  • Chapter 7 - Management and Maintenance
  • Chapter 8 - Stretched Cluster
  • Chapter 9 - Designing a vSAN Cluster
  • Chapter 10 - Troubleshooting, Monitoring, and Performance

Скачать книгу можно в разных форматах:


Таги: VMware, vSAN, Book, Бесплатно

Вышел VMware ESXi 6.5 Update 1 Patch 2 - новые возможности vSAN.


На днях компания VMware выпустила пакет обновления к VMware ESXi 6.5 Update 1, именуемый как Patch 02, добавляющий несколько новых возможностей к решению для создания отказоустойчивых кластеров хранилищ VMware vSAN. Более подробно об этом патче написано в KB 51891.

Новое обновление ESXi включaет в себя следующие фичи vSAN:

  • Продукт vSAN Support Insight - эта фича показана в видео выше. Она позволяет пользователям, участвующим в программе CEIP (Customer Experience Improvement Program) получить доступ к расширенной аналитике vSAN в целях решения проблем. Средствами Support Insight сотрудники техподдержки VMware могут исследовать окружения пользователей, понимать их конфигурацию, статус исполнения, производительность и прочие детали в масштабе времени близком к реальному. Документация по этой фиче доступна тут.

Выглядит это примерно следующим образом:

  • Технология Adaptive resynchronization – функция Adaptive Resync адаптивно изменяет долю полосы пропускания, выделенную для канала ресинхронизации Resync I/O, чтобы минимизировать негативное влияние на работу клиентского канала ввода-вывода. За счет этого в периоды меньшей загрузки (выходные) канал для ресинхронизации используется больше, а во время часов пик - меньше.
  • Поддержка доступа по нескольким путям для SAS-систем. Теперь из коробки поддерживается multipathing для SAS c запасными путями. Пример такого хранилища - HPE Synergy.

Скачать VMware ESXi 6.5 Patch 2 можно c VMware Patch Portal по этой ссылке (надо выбрать релиз ESXi650-201712001 с номером билда 7388607).

Более детальная информация об обновлении приведена тут.

Также вышел и vCenter Server 6.5 Update 1d - там ничего нового, кроме обновлений отдельных компонентов.


Таги: VMware, ESXi, Update, vSAN, Support

Как расходуется дисковое пространство в кластере VMware vSAN при удалении файлов?


Cormac Hogan написал занимательный пост о об использовании дискового пространства в кластере VMware vSAN. Всех интересует - умеет ли vSAN возвращать дисковое пространство хранилищу при удалении файлов в гостевой ОС виртуальной машины? Ответ - пока нет, но над этим работают.

Cormac провел вот какой эксперимент: взял виртуальную машину в кластере vSAN с гостевой ОС Windows Server 2012 R2, у которой было 386.7 ГБ занятого места (сама ВМ была развернута на тонких дисках):

Затем он скопировал туда данные на 800 МБ, после чего увидел, что занятое место увеличилось до 388.37 ГБ, то есть выросло на 1,6 ГБ. Это логично, так как vSAN работал в режиме RAID-1 (зеркалированные VMDK-диски):

Далее он удалил только что скопированные файлы и убедился, что занятое дисковое пространство осталось тем же самым (то есть, в vSAN нет поддержки UNMAP/TRIM изнутри гостевой системы):

Между тем, он снова скопировал те же 800 МБ и к радости администраторов заметил, что дисковое пространство увеличилось лишь на 20 МБ (в совокупности на 40 МБ с учетом RAID-1).

То есть занятые после прошлого копирования блоки были использованы повторно:

Такая штука есть у Windows Server, но у Linux в файловой системе ext4 такой трюк не прокатит - все равно при повторном копировании блоки разместятся в другом месте, и пространство будет использовано повторно. Но это особенность файловой системы ext4, об этом подробно написано тут и тут. Для ФС ext3 и XFS это не актуально, там блоки тоже будут переиспользоваться.

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


Таги: VMware, vSAN, Storage, vSphere, VMachines

Новая версия калькулятора VMware vSAN 6.5 и vSAN 6.6.1 Resource Calculator.


Летом мы писали о калькуляторе для сайзинга хранилищ инфраструктуры VMware vSAN 6.2. С тех пор вышли новые версии vSAN 6.5 и vSAN 6.6.1, в которых было реализовано несколько новых возможностей, соответственно, обновился и калькулятор - его новая версия доступна по этой ссылке. Новая версия построена на базе документов VMware vSAN Design and Sizing Guide 6.5 и 6.6.1 (глава 10.2 Capacity Sizing Example II).

Калькулятор представляет собой Excel-таблицу, в которой есть поля для ввода исходных данных (черные - это аппаратные параметры инфраструктуры и данные по консолидации ВМ, синие и зеленые - остальные параметры). Ранее этот калькулятор представлял собой Excel-документ в облаке OneDrive, но теперь любой может скачать его.

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

В левой области таблицы данные параметры рассчитываются для All-Flash архитектуры кластера Virtual SAN, а правая часть предназначена для расчетов гибридной архитектуры (обычные HDD-диски для данных, а SSD-носители - для кэша).

Более подробно о калькуляторе написано вот тут.


Таги: VMware, vSAN, Calculator, Storage

Как работает изоляция хостов ESXi в кластере VMware vSAN и HA.


Дункан написал интересный пост про работу кластера откзоустойчивых хранилищ VMware vSAN совместно с технологией отказоустойчивости хост-серверов VMware HA. Суть проблемы заключается в том, что кластер vSAN, как правило, организуется на базе обычной Ethernet-сети, которая не подразумевает наличие дополнительных хранилищ Heartbeat Datastores (на которых создаются специальные локи на файлы со стороны хостов).

А эти хранилища очень важны для кластеров VMware HA, так как по ним через сеть хранения данных (например, общие FC-хранилища) он определяет остались ли хосты работающими в случае отказа/разделения сети передачи данных, а также продолжают ли там работать виртуальные машины.

Если таких хранилищ в кластере vSAN нет (а их, скорее всего, нет), то могут возникнуть проблемы вот какого плана. В случае изоляции хоста (например, разделилась сеть или отказали порты коммутатора), сам кластер vSAN обрабатывает ситуацию корректно, но виртуальные машины продолжают быть запущены на изолированных хостах. В то же время, главная часть кластера HA (та, в которой остался Master) имеет копии этих же виртуальных машин и может запустить их, подумав, что они уже недоступны вместе с хостами, а это уже может привести к ситуации с дубликатами машин и их MAC/IP адресов, когда сеть восстановится.

Чтобы этого не происходило, на хостах ESXi нужно настроить реакцию на событие изоляции (isolation response). Хост декларирует себя изолированным при совместном наступлении двух событий:

  • Он не получает коммуникации от хоста Master
  • Он не может достучаться до isolation address

Если вы ничего не настраивали дополнительно в кластере HA, то ваш isolation address находится в Management network, которая и есть та сеть, в которой работает кластер vSAN (и которая, как мы помним, упала). И, на самом деле, это хорошо! Ведь если бы этот адрес продолжал быть доступен, то изолированная часть кластера не считала бы себя изолированной и случился бы split-brain с появлением возможных дубликатов машин.

Из этой всей ситуации можно сделать 3 вывода:

  • Используйте отдельные от кластера vSAN хранилища Heartbeat Datastores, работающие в другой сети или по другим интерфейсам (если это возможно, конечно, в вашей инфраструктуре). Для этого нужно выбрать опцию "Use datastore from only the specified list" в настройках HA и добавить расширенную настройку "das.ignoreInsufficientHbDatastore = true" в advanced HA settings.
  • Всегда ставьте действие isolation response в Power Off, чтобы машины выключились в случае изоляции хостов кластера HA, а главная часть кластера могла их перезапустить.
  • Делайте isolation address в той же сети, что и основная сеть vSAN (интерфейсы VMkernel хостов), чтобы в случае изоляции хост ESXi считал себя изолированным, а не продолжающим нормально пинговать какой-то сторонний адрес. Для этого можно использовать Switch Virtual Interface (SVI) на физическом коммутаторе (если у вас немаршрутизируемая сеть vSAN).

Ну и напомним тут нашу подробную статью о совместном существовании vSAN и HA.


Таги: VMware, vSAN, HA, ESXi

Как правильно вывести хост VMware ESXi из кластера vSAN.


Иногда администратору решения по организации отказоустойчивых кластеров VMware vSAN требуется вывести отдельный хост VMware ESXi из кластера, после чего использовать его диски для организации томов VMware VMFS виртуальных машин уже не в рамках кластера.

Правильно делать это следующим образом.

1. Проверяем, является ли хост членом кластера vSAN:

esxcli vsan cluster get

2. Выводим хост ESXi из кластера:

esxcli vsan cluster leave

3. Убедимся, что хост вышел из кластера:

esxcli vsan cluster get

мы должны получить сообщение:

Virtual SAN Clustering is not enabled on this host

4. После этого надо очистить конфигурацию vSAN для дисков на хосте.

Для начала найдем все диски командой:

esxcli vsan storage list

далее идентифицируем диски vSAN, выполнив команду:

partedUtil getptbl <путь к устройству>

Здесь мы видим, что один из разделов еще видит себя частью vSAN. Сначала надо снять лок с диска, отключив автоуправление со стороны кластера vSAN (то есть, разрешаем ручные операции с хранилищами vSAN):

esxcli vsan storage automode set --enabled false

Если этого не сделать, мы получим такую ошибку:

Unable to remove device: Can not destroy disk group for SSD naa.6000c29c581358c23dcd2ca6284eec79 : storage auto claim mode is enabled

5. После этого можно окончательно вывести диск из кластера vSAN следующей командой:

esxcli vsan storage remove -s naa.50026b724712194a

здесь опция -s значит SSD-диск (так отключаются устройства кэширования), а если мы хотим вывести обычный диск, то вместо -s надо использовать опцию -d.


Таги: VMware, vSAN, Обучение, Storage, ESXi

1 | 2    >   >>
Реклама







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

31/01/2019:  Бизнес и ИТ. Вокруг ЦОД (Ростов-на-Дону)
14/02/2019:  Облака 2019: бурный рост в цифровую эпоху
14/03/2019:  Информационная безопасность бизнеса и госструктур

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


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


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

Видео про Citrix Xen

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

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

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

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

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

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


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