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

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

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

VM Guru | Ссылка дня: Вышел VMware vCenter Server 6.5 Update 1b

Новая версия калькулятора 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

Несколько советов по дедупликации, компрессии и экономии дискового пространства в кластере VMware vSAN.


John Nicholson написал интересный пост с советами по экономии дискового пространства в кластере VMware vSAN, а также некоторыми рекомендациями по использованию техник дедупликации и сжатия данных.

Вот каким моментам следует уделить внимание:

1. Посмотрите на параметр политики хранения object space reservation (OSR) - если он установлен в 0, то виртуальные диски машин будут тонкими. Если же он будет больше 0, то пространство под диски будет резервироваться и vSAN не сможет эффективно использовать дедупликацию, так как будет вынужден поддерживать фиксированные резервы дискового пространства под ВМ.

2. Помните, что параметр резервирования свопа установлен в 100%, но это можно поменять, как мы писали в этой статье. Уменьшение параметра резервирования свопа оправдано, когда вы не собираетесь использовать memory overcommitment (то есть, ресурсов у вас с запасом), а значит виртуальным машинами не потребуется активно сбрасывать страницы в своп в случае недостатка физической памяти.

3. Помните, что отдельно развертываемые виртуальные машины c дисками типа "thick" или "Eager Zero Thick" (например, со старых клиентов vSphere Client или через консоль) могут перекрывать настройку политики OSR. Чтобы пофиксить это, вы можете переприменить политику хранения (storage policy) на эти хранилища. William Lam написал несколько скриптов, которые позволяют найти такие ВМ и накатить политики по-новой.

4. Убедитесь, что данные записываются на capacity tier - только там они будут дедуплицироваться и сжиматься. Если вы развернули всего 3-4 машины, они могут остаться в буффере (write buffer). Механизмы vSAN не тратят ресурсы на дедупликацию и сжатие объектов, которые долго не живут (то есть, находятся в буффере на запись). Например, 10 машин по 8 ГБ диска каждая тоже могут остаться на стейджинге и, пока не переместятся в постоянное хранилище, не будут дедуплицированы.

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

Ну и вот что Джон рекомендует в плане тестирования дедупликации и компрессии:

  • Самый простой способ организовать тестирование - запустить клонирование 200+ виртуальных машин, они сразу пойдут в capacity tier, и механизм дедупликации включится.
  • Надо помнить, что тестирование этих механизмов и реальное их применение дадут разные результаты, так как при тестировании вы последовательно пишете данные на хранилище и избегаете узких мест, связанных с дестэйджингом из кэша во время размеренного использования кластера vSAN в продакшене.
  • Тестирование алгоритма сжатия на данных, которые плохо сжимаются - плохая идея, так как в этом случае vSAN не будет тратить ресурсы на их сжатие, чтобы записать на хранилище. Это позволит быстрее читать их, а экономия с точки зрения диска будет небольшой (к тому же, алгоритм сжатия LZ4 не такой быстрый, как хотелось бы).
  • При резких всплесках объема записываемых данных и IOPS, которые не помещаются в кэш, видно, что механизмы сжатия и дедупликации приостанавливаются и теряют эффективность. Это связано с тем, что vSAN прежде всего должен обеспечить хороший показатель latency (то есть уровня сервиса), а уже во вторую очередь эффективность механизмов дедупликации и компрессии.

Ну и в довершение, интереснейший документ от VMware - "vSAN Space Efficiency Technologies".


Таги: VMware, Storage, vSAN

Как выбрать дисковый контроллер для VMware vSAN?


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

Дункан Эппинг дает простую рекомендацию - надо брать один из самых недорогих поддерживаемых контроллеров, который имеет большую глубину очереди (Queue Depth). Например, часто в рекомендациях для vSAN можно встретить контроллер Dell H730, который является весьма дорогим устройством, если брать его на каждый сервер.

Но его не обязательно покупать, достаточно будет дискового контроллера Dell HBA 330, который и стоит дешевле, и глубину очереди имеет в 10 раз больше, чем H730 (хотя оба они соответствуют требованиям vSAN). Да, у H730 есть кэш на контроллере, но он в данном случае не требуется. Лучше использовать интерфейс NVMe для подключения отдельного SSD-кэша, не затрагивающего RAID-контроллеры (его нужно размещать как можно ближе к CPU).

Поэтому итоговая рекомендация по выбору дискового контроллера для кластеров vSAN проста - берите любое недорогое устройство из списка совместимости vSAN Compatibility Guide, но с хорошей глубиной очереди (например, HP H240), а на сэкономленные деньги отдельно организуйте кэш на базе NVMe.


Таги: VMware, SSD, Hardware, vSAN, NVMe, Storage

Новая жизнь снапшотов и сессия "Tech Preview of Integrated Data Protection for vSAN" на VMworld 2017.


На конференции VMworld 2017 компания VMware представила интересную сессию "Tech Preview of Integrated Data Protection for vSAN", где рассказывалось о новых уровнях защиты данных в кластерах VMware vSAN.

Сейчас защита кластера обеспечивается за счет избыточности дисковых объектов, которые размещены на разных хостах, и, в зависимости от степени дублирования эти объектов (политика failures to tolerate), кластер vSAN переживает отказы некоторого количества хостов ESXi в случае сбоя. Но сбои бывают и другого характера: например, повреждение данных, которое будет отреплицировано на все дисковые объекты.

Поэтому на VMworld было рассказано о Integrated Data Protection - технологии, которая защищает данные во времени и позволяет обеспечить исполнение политик RPO (recovery point objective). Работает она за счет создания снапшотов виртуальных машин - локально или удаленно.

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

Во-вторых, работать все это будет на уровне политики хранения механизма storage policy based management (SPBM), в рамках которой можно будет задать и откидывание снапшотов в удаленные локации, например, NFS-шары, Data Domain или облако Amazon S3 (remote protection).

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

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

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

VMware обещает сделать Integrated Data Protection в ближайших версиях VMware vSAN, будем смотреть за анонсами VMworld Europe 2017 в ближайшие дни.


Таги: VMware, vSAN, Data Protection

Переделка "толстых" файлов подкачки виртуальных машин в кластере VMware vSAN на "тонкие".


Некоторые из вас знают, что, начиная с версии vSAN 6.2, стало возможно создание "тонких" (thin) файлов подкачки. В более ранних версиях vSAN было возможно создавать только reserved своп-файлы, что требовало довольно больших объемов дисковой памяти. То есть, если у машины 16 ГБ оперативной памяти, то в два раза больше будет занято и на диске под своп (32 ГБ), так как при FTT=1 (failures to tolerate) дисковые объекты дублируются в рамках кластера.

Поэтому для сред, в которых достаточно памяти у хостов, и отсутствует Memory Overcommitment, сделали параметр в настройках кластера SwapThickProvisionDisabled, позволяющий виртуальным машинам создавать тонкие файлы подкачки.

Чтобы выставить эту настройку, есть специальный скрипт PowerCLI, который применяет ее ко всем хостам ESXi кластера vSAN.

Однако выставить настройку недостаточно - ведь, чтобы файлы подкачки стали тонкими, то есть пересоздались, надо перезагрузить (выключить и включить) виртуальные машины с толстыми swap-файлами. Найти такие машины позволит вот этот Python-сценарий. Ну а дальше уже перезагрузите машины по списку - это позволит вам сэкономить значительный объем дискового пространства кластера.


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

Пара интересных новых документов о VMware vSAN 6.6.1.


На сайте документации VMware, касающейся хранилищ - storagehub.vmware.com, появилось два интересных документа, посвященных последней версии продукта для создания отказоустойчивых кластеров VMware vSAN 6.6.1.

Первый - vSAN 6.6.1 Upgrade Considerations, он рассказывает о том, как нужно проводить апгрейд на vSAN 6.6.1 с предыдущих версий. Основные разделы документа посвящены вопросам состава операций и последовательности апгрейда хранилищ, подготовке сетевой инфраструктуры, а также шагам процесса обновления версии vSAN.

Второй документ - "VMware vSAN Design and Sizing Guide". Это уже более серьезный док, где на 73 страницах рассказывается о том, как нужно строить архитектуру решения, а также планировать под нее необходимые емкости хранилищ.

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


Таги: VMware, vSAN, Whitepaper

Демо-видео VMware vSAN 6.6.1 Performance Diagnostics.


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

По результатам исполнения бенчмарков выдаются рекомендации по увеличению производительности кластера хранилищ, такие как увеличение размера дисковой группы, добавление новых дисковых групп или изменение числа виртуальных машин. Тест проводится около 1 часа, после чего делается вывод о том, достигнуты ли значения параметров maximum IOPS, maximum throughtput и minimum latency. Если нет - то будут выписаны рекомендации.

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

Надо сказать, что данные, собираемые на стороне кластера vSAN, в обезличенном виде передаются на сторону облака VMware, там анализируются и ответ обратно передается на сторону vSphere Web Client. Поэтому и требуется, чтобы Customer Experience Improvement Program (CEIP) была включена (в последних версиях она включена по умолчанию).

Полезно, что если вы не знаете, как интерпретировать результаты тестов, вы можете нажать ссылку Ask VMware и попасть на статью KB, где описывается, как должны выглядеть оптимальные значения, и что предпринять, если полученные результаты вас не устраивают.


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

Новые возможности VMware vSAN 6.6.1 - да, их немало.


Недавно мы писали о выходе первого пакета обновления платформы VMware vSphere 6.5 Update 1, в рамках которого также было выпущено еще несколько апдейтов продуктовой линейки VMware, в том числе обновление решения для создания отказоустойчивых кластеров хранилищ vSAN 6.6.1.

Основная новая функция vSAN, о которой мы уже писали - это возможность использования vSphere Update Manager для обновления кластеров vSAN 6.6.1. О ней хорошо рассказывается в следующем видео:

Между тем, в vSAN 6.6.1 появилось еще несколько интересных фич, которые обычно присущи среднему (а не минорному) обновлению:

1. Раздел vSAN Performance Diagnostics.

Теперь на вкладке vSAN в Web Client появился пункт Performance Diagnostics, в котором можно запускать различные бенчмарки и сравнивать полученные результаты с предыдущими их выполнениями:

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

Тест проводится около 1 часа, после чего делается вывод о том, достигнуты ли значения параметров maximum IOPS, maximum throughtput и minimum latency. Если нет - то будут выписаны рекомендации.

Для работы этой возможности необходимо, чтобы были включены фичи Customer Experience Improvement Program (CEIP) и vSAN Performance Service.

2. Поддержка Config Generation.

С переходом vSAN 6.6 на юникастовую коммуникацию с vCenter, последний воспринимается как единственный источник доверительной конфигурации. Однако, если vCenter становился недоступным, а конфигурация кластера менялась, то при возобновлении доступности vCenter конфигурация откатывалась к прежней. Теперь же есть параметр Config Generation, содержащих GUID и время последних изменений конфига.

3. Хэлсчеки для VUM.

Так как vSAN теперь обновляется через VMware Update Manager (VUM), то в разделе Health появились новые проверки состояний:

4. Поддержка миганий индикаторов для HP Gen9.

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

Эта фича работает как в режиме RAID, так и в режиме pass-through.

Загрузить VMware vSAN 6.6.1 можно по этой ссылке. Release Notes доступны тут. А вот тут можно скачать документ с описаниями новых возможностей.


Таги: VMware, vSAN, Update

Улучшения производительности VMware vSAN 6.6 по сравнению с 6.5.


Весной этого года вышло обновление решения для создания отказоустойчивых кластеров для виртуальных машин на платформе vSphere - VMware vSAN 6.6. Прошлая версия продукта Virtual SAN 6.5 вышла еще осенью 2016 года, и vSAN 6.6 заметно продвинулся в плане функционала. Но, оказывается, это решение стало еще и существенно лучше в плане производительности. И на эту тему есть полезный документ "vSAN 6.6 Performance Improvements", описывающий результаты тестирования обеих версий продукта.

Для тестов использовалось одинаковое оборудование (кластер All-Flash) и 3 типа симуляции рабочей нагрузки:

  • Random Read
  • Random Write
  • Mixed random Read/Write (70/30%)

Посмотрим на графики, показывающие улучшения в различных аспектах:

Большое рабочее множество данных (Large Working Set)

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

Так выглядит суммаризованный график улучшения по числу IOPS для трех типов нагрузок и различных уровнях RAID:

Вот так выглядит уменьшение задержек при обращении к дискам (Latency). Чем ниже столбик - тем сильнее уменьшилась задержка:

Так выглядит отдельный график по IOPS для типа нагрузки 70% чтения и 30% записи:

Так выглядит Latency для этого типа нагрузки:

IOPS для Random Writes:

Latency для Random Writes:

Малое рабочее множество данных (Small Working Set)

Этот вариант использования хранилища меньше зависит от аппаратных особенностей и больше способен показать улучшения, сделанные в программных компонентах. Несмотря на то, что он не встречается в чистом виде (как впрочем и Large Working Set), малые рабочие множества встречаются в среде, где работают много небольших задач одновременно, обращения которых к хранилищам перемешиваются в потоке ввода-вывода.

Так выглядит суммаризованный график улучшения по числу IOPS для трех типов нагрузок и различных уровнях RAID (заметьте, что процент улучшений здесь значительно выше, чем для Large Working Set):

Вот так выглядит уменьшение задержек при обращении к дискам (Latency). Чем ниже столбик - тем сильнее уменьшилась задержка (также улучшения более существенны, чем для Large Working Set):

Так выглядит отдельный график по IOPS для типа нагрузки 70% чтения и 30% записи:

Так выглядит Latency для этого типа нагрузки:

IOPS для Random Writes:

Latency для Random Writes:

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


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

VMware vSAN Sizer - утилита для подбора оборудования и расчета объема хранилищ под кластеры vSAN.


Компания VMware сделала доступной небольшую онлайн-утилиту для сайзинга серверов хранения виртуальных машин, работающих в отказоустойчивых кластерах хранилищ - VMware vSAN Sizer. Также она производит подбор необходимых конфигураций серверов (для расчетов принимается, что все узлы будут использовать конфигурацию All-Flash SSD).

VMware vSAN Sizer доступен по адресу: https://vsansizer.vmware.com/

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

На первом этапе нам показывают, сколько нужно серверов и неразмеченного хранилища (Raw Storage):

Ниже мы видим технические характеристики каждого из хостов ESXi:

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

В утилите VMware vSAN Sizer расположена ссылка на расширенную версию, которая доступна для партнеров, но когда я зашел под партнерским аккаунтом, то увидел там только пустую белую страницу с шапкой меню.


Таги: VMware, vSAN, Sizing, VMachines, Storage, Hardware

Особенности шифрования кластеров VMware vSAN при апгрейде с прошлых версий.


Как вы знаете, в новой версии решения организации отказоустойчивых кластеров VMware vSAN 6.6 появилась возможность шифрования хранилищ. В целях увеличения эффективности и скорости работы в этой технологии используется концепция "encryption at rest". Сначала данные в незашифрованном виде идут по сети (в целях ускорения и работы сжатия), затем они в зашифрованном виде падают в кэш. После чего, перед тем, как отправиться на постоянное хранение (destaging), они будут расшифрованы, дедуплицированы/сжаты и снова зашифрованы уже на целевом устройстве.

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

Для работы шифрования vSAN нужно, чтобы в кластере была версия on-disk format 5 или выше, при этом пятая версия появилась только в vSAN 6.6. Здесь возможны 3 сценария использования шифрования vSAN:

  • Развертывание кластера с нуля на vSAN 6.6.
  • Апгрейд кластера с vSAN 5.x./6.x на 6.6 со сменой on-disk format на версию 5.
  • Апгрейд кластера с vSAN 5.x./6.x на 6.6 без изменения версии on-disk format.

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

Во втором случае мастер миграции может выполнить процедуру DFC (disk format change), что поменяет on-disk format на версию 5. Далее также можно будет включить шифрование в любой момент, и с этого момента новые данные тома будут шифроваться. При этом не потребуется убирать виртуальные машины с хранилища

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


Таги: VMware, Encryption, vSAN, Security, Upgrade

VMware vSAN 6.6 Configuration Assist - помощь в настройке среды для кластеров хранилищ.


В статье о новой версии продукта для организации отказоустойчивых кластеров хранилищ vSAN 6.6 мы писали о том, что появилась утилита Configuration Assist, созданная для того, чтобы после установки кластера правильно сконфигурировать среду vSphere, чтобы все работало корректно и соответствовало необходимой конфигурации платформы.

Первоначальные задачи по настройке кластера, развертываемого через Easy Install или vSphere Web Client, включают в себя настройку порта VMkernel для трафика vSAN, выделение дисков и т.п. Как часть процесса установки, мастер vSAN Setup Wizard заботится о таких специфических вещах, как дедупликация и компрессия, число узлов, растянутый это будет кластер или нет, но не заботится об общих настройках среды VMware vSphere.

Для этого и был сделан раздел vSAN Configuration Assist, который вам поможет со следующими операциями:

  • Настройка высокой доступности vSphere High Availability.
  • Настройка балансировщика vSphere Distributed Resource Scheduler (DRS).
  • Конфигурация vSphere Distributed Switch для трафика vSAN.
  • Настройка vMotion для ВМ.
  • Позволит убедиться в том, что все доступные накопители используются для кластера.
  • Есть средства конфигурации хостового контроллера.
  • Есть необходимая версия микрокода (firmware) хостового контроллера.

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

Вот как это примерно делается (приведен пример, как настроить для vSAN или vMotion интерфейсы VMKernel):

Выделение дисков под кластер идет в момент его развертывания, но после установки это уже можно сделать через Configuration Assist:

Конечно же, необходима настройка vSphere HA/DRS:

Ну и последнее, но не менее важное - утилита позволяет вам обновлять микрокод узлов различных OEM-производителей, таких как Dell, Lenovo, Fujitsu и SuperMicro:

Поэтому первым делом после развертывания кластера vSAN идите в раздел Configuration Assist клиента Web Client.


Таги: VMware, vSAN, vNetwork, VMachines, Storage, HA, Web Client

Погружение в VMware vSAN 6.6 на 80 минут.


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

Хорошим дополнением к этому будет видео ниже, в котором в течение 80 минут рассказывается о тонкостях возможностей продукта с технической стороны (правда там нет обзора фич последних версий 6.5/6.6).

Видео предназначено для тех, кто хочет понять, как работает кластер vSAN, что такое Disk Object, Storage Policies, как работает флэш-кэш, растянутый кластер и другие штуки. Если вас не раздражает индусский английский, то видео вполне интересное.

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

Ну и не забывайте про плейлист о VMware vSAN на ютубе.


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

Почему Witness VM нельзя перекрестно размещать на двух площадках для двух растянутых кластеров.


Интересный пост написал Cormac Hogan, касающийся конфигурации растянутых кластеров VMware vSphere Stretched Clusters и размещения компонентов Witness VM для них. Если у вас есть 2 площадки и два растянутых кластера VMware vSAN между ними, то сама собой напрашивается следующая конфигурация:

Но так делать, конечно же, нельзя - и вот почему. Допустим у вас отказал сайт 2, на котором не было Witness-машин. Только в этом случае у вас будет все хорошо - для каждого из кластеров будет кворум (Witness VM+узел), и они продолжат нормальную работу.

Но если у вас откажет сайт 1, то вы лишитесь сразу двух Witness VM (и WA, и WB), узлы на площадке 2 окажутся изолированными, и все виртуальные машины на них будут недоступны (нет кворума):

А что для случая, если машины Witness VM разместить на разных площадках?

Да тоже ничего хорошего - откажет сайт 1, вследствие чего виртуальные машины выжившего сайта 2 кластера A будут недоступны (не будет кворума, ведь WA, присматривающий за эти узлом умер на первой площадке). Ну а поскольку WB является как раз виртуальной машиной, данного узла кластера A ставшего недоступным, то и у выжившего узла кластера B также не будет кворума. В итоге и виртуальные машины кластера B при данном сбое будут недоступны.

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


Таги: VMware, vSphere, HA, DR, vSAN, Blogs

Как планировать дисковые емкости для растянутых кластеров VMware vSAN 6.6 (Stretched Clusters).


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

Напомним, что для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1 (на обычных дисках), а также RAID-5 или RAID-6 (для архитектуры All-Flash).

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

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

Традиционно, до введения политик избыточности на уровне каждой из площадок, планирование емкости было простым - надо было просто удвоить исходную емкость одной площадки. В vSAN 6.2 появилась не только защита RIAD-1 (mirroring), но и RIAD-5/6 (erasure coding), что позволяет в рамках растянутых кластеров организовать различные схемы размещения данных. Отметим, что алгоритм erasure coding между площадками пока не реализуем ввиду ограничений на уровне домена отказа (Fault Domain). Поэтому между площадками - только Mirroring.

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

В поле PFTT для растянутых кластеров мы видим 1, а для обычных 0. FTM (Failure Tolerance Mode) - это режим обеспечения отказоустойчивости на уровне каждого из сайтов. Напомним, что для обычных дисков он может быть только Mirroring, а для All-Flash архитектур - Mirroring или Erasure Coding.

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

Таким образом, если вы организуете растянутый кластер хранилищ на базе архитектуры All-Flash со средствами защиты Erasure Coding в рамках площадки и Mirroring между площадками, то вам потребуется 266% исходной дисковой емкости виртуальных машин (ее можно скорректировать на экономию от Thin Provisioning).

Ну а если вы будете использовать обычные диски и защиту Mirroring как внутри площадки, так и между площадками - вам потребуется 400% исходной емкости.

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


Таги: VMware, vSAN, Storage, Enterprise, Stretched

Доступен для скачивания VMware vSAN 6.6, а также соответствующие обновления ESXi 6.5d и vCenter 6.5d.


Недавно мы писали об анонсированных новых возможностях продукта для организации кластеров хранилищ VMware vSAN 6.6, а вчера он стал официально доступен для скачивания. Так как VMware vSAN работает в рамках инфраструктуры серверной виртуализации VMware vSphere, были также выпущены обновления ESXi 6.5d и vCenter 6.5d, поддерживающие vSAN 6.6.

Обратите внимание, что VMware Horizon 7.1 уже поддерживает VMware vSAN 6.6.

Напомним также, что совсем недавно выходил апдейт VMware vCenter 6.5c, в котором была исправлена уязвимость компонента Apache BlazeDS. Что касается обновления ESXi 6.5d, то оно включает в себя поддержку vSAN 6.6, исправления некоторых ошибок а также отображения статусов VMware vSAN health checks в интерфейсе клиента ESXi Host Client (он же Embedded Host Client).

Загрузить VMware vSAN 6.6 в составе платформы VMware vSphere 6.5 и ее компонентов можно по этой ссылке.

Ну и одновременно с этими релизами была выпущена также обновленная версия платформы VMware vSphere Integrated Containers 1.1.

Давайте посмотрим на новые возможности VIC 1.1:

  • Унифицированный OVA-установщик для всех трех компонентов решения.
  • Возможность апгрейда с версии 1.0.
  • Официальная поддержка vSphere Integrated Containers Management Portal.
  • Унифицированный пользовательский интерфейс для vSphere Integrated Containers Registry и vSphere Integrated Containers Management Portal.
  • Отдельный плагин для HTML5 vSphere Client (он же vSphere Client теперь).
  • Поддержка Docker Client 1.13 и Docker API версии 1.25.
  • Поддержка использования компонента Notary совместно с vSphere Integrated Containers Registry.
  • Поддержка дополнительных команд Docker, которые можно найти в документации.

Загрузить VMware vSphere Integrated Containers 1.1 можно по этой ссылке.


Таги: VMware, vSAN, Update, ESXi, vCenter, VIC, Docker

Пара интересных видео о VMware vSAN 6.6 от Дункана Эппинга и подробный технический обзор.


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

Первое - это общий обзор VMware vSAN 6.6, в котором Дункан проходится по основным нововведениям, наглядно демонстрируя их в интерфейсе:

Во втором видео Дункан подробно останавливается на технологии шифрования vSAN 6.6, показывая ее в деле:

Ну и в довершение - интересный документ с детальным рассмотрением технических особенностей новой версии VMware vSAN 6.6 (уже не от Дункана, но очень подробный и полезный для администраторов решения):


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

Вышел VMware vSAN 6.6 - что нового? Да много всего!


Осенью прошлого года компания VMware на конференции VMworld Europe 2016 представила новую версию продукта VMware Virtual SAN 6.5, которая была приведена в соответствие с версией vSphere 6.5. На днях, спустя полгода после этого релиза, была представлена обновленная версия этого продукта для создания кластеров хранилищ - VMware vSAN 6.6 (обратите внимание, что он теперь называется не Virtual SAN, а vSAN).

Несмотря на малое продвижение версии, в VMware vSAN 6.6 появилось весьма много новых возможностей:

1. Шифрование.

В vSAN 6.6 появился механизм DARE – Data At Rest Encryption. Несмотря на то, что для ВМ на платформе vSphere 6.5 есть собственное шифрование, ранее для такого сценария не были доступны дедупликация и компрессия. Теперь за счет того, что шифрование vSAN работает на более позднем уровне - эти механизмы экономии дискового пространства теперь поддерживаются.

Кроме того, эта возможность использует механизм AESNI (Advanced Encryption Standard Native Instruction), который есть во всех современных процессорах, что увеличивает производительность. Также появились новые healthchecks касающиеся того, что сервер KMS доступен (не забудьте обеспечить его резервирование), а также хосты поддерживают AESNI.

2. Механизм локальной защиты для растянутых кластеров (vSAN Stretched Clusters).

Теперь средствами политик можно определить уровень защиты как на уровне локального сайта, так и на уровне межсайтового кластера. Для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1, RAID-5 или RAID-6.

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

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

3. Возможность Site Affinity для растянутых кластеров.

Теперь машину можно привязать к определенной площадке для растянутого кластера, но только в том случае, если у нее установлено Primary level of failures to tolerate в значение 0 (то есть она не защищена на уровне кластера vSAN, а администратор сам заботится о средствах ее защиты).

4. Режим Unicast Mode.

Теперь вместо мультикаста используется юникаст для коммуникации между узлами кластера. Как только вы обновите все хосты кластера vSAN да версии 6.6 - он сам переключится на режим Unicast:

Вот этой командой можно проверить режим Ubnicast на узлах кластера:

[root@esxi-dell-j:~] esxcli vsan cluster unicastagent list
NodeUuid IsWitness Supports Unicast IP Address Port Iface Name
------------------------------------ --------- ---------------- ------------ ----- ----------
58d29c9e-e01d-eeea-ac6b-246e962f4ab0 0 true 172.4.0.121 12321
58d8ef12-bda6-e864-9400-246e962c23f0 0 true 172.3.0.123 12321
58d8ef61-a37d-4590-db1d-246e962f4978 0 true 172.3.0.124 12321
00000000-0000-0000-0000-000000000000 1 true 147.80.0.222 12321
[root@esxi-dell-j:~]

5. Больше информации об объектах в интерфейсе.

Если раньше можно было просматривать только объекты VMDK и VM Home, то теперь добавился Swap и объекты дельта-дисков ВМ для снапшотов (см., например, диск с именем Hard disk 9 -vcsa-06.rainpole.com_8.vmdk):

6. Возможности Smart Rebuilds.

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

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

Также при высоком заполнении дискового пространства (более 80%) дисковые объекты могут разбиваться на более мелкие чанки, чтобы можно было отбалансировать распределение этих кусочков по хостам кластера в целях более эффективного использования дискового пространства.

7. Механизм Partial Repairs.

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

8. Функция Resync Throttling.

Это давно ожидаемая фича - она позволяет задать ширину канала для ресинхронизации в Mbps:

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

9. Новые пречеки для режима обслуживания.

Теперь перед переводом кластера в режим обслуживания vSAN делает предпроверки на доступную емкость, чтобы не попасть в ситуацию нарушения политик на время обслуживания:

10. Новые пречеки для удаления дисковых групп и дисков.

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

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

11. Новый помощник установки и развертывания.

Теперь процедура развертывания кластера vSAN стала значительно проще благодаря улучшенному установщику:

А для проверки конфигурации кластера vSAN появилась утилита "Configuration Assist", которая позволяет убедиться, что все настроено правильно:

12. Средства для проактивного предупреждения ошибок.

Теперь за счет механизма CEIP (Customer Experience Improvement Program) информация о кластере vSAN посылается в VMware, облачные системы которой могут выдавать предварительные предупреждения о возможных проблемах в инфраструктуре хранилищ и рекомендации по их настройке.

13. Интеграция с HTML5 Host Client.

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

Также, например, можно прямо из клиента HTML5 управлять средствами дедупликации vSAN.

14. Новые команды ESXCLI.

Были добавлены следующие пространства команд для управления кластером vSAN и его новыми фичами:

  • esxcli vsan debug
  • esxcli vsan health cluster
  • esxcli vsan resync bandwidth
  • esxcli vsan resync throttle

15. Возможность заменить компонент Witness прямо из GUI.

Теперь в интерфейсе для этого появилась специальная кнопка:

Скачать VMware vSAN 6.6 можно по этой ссылке.


Таги: VMware, vSAN, Update

Документ о производительности платформы vSphere 5.5: Performance Best Practices for VMware vSphere 5.5.


Сразу после релиза обновленной версии платформы vSphere 5.5 компания VMware выпустила очень интересный и полезный документ Performance Best Practices for VMware vSphere 5.5, в котором рассматриваются аспекты производительности серверов VMware ESXi и виртуальных машин уже с учетом функциональности новой версии.

Например, теперь в документе описаны следующие фичи в контексте производительности:

  • Функции кэширования на SSD-накопителях vSphere Flash Read Cache, о которых мы писали вот тут. Они увеличивают производительность за счет применения кэша на чтение для операций ввода-вывода виртуальных машин.
  • Возможность VMware Virtual SAN (VSAN), о которой мы писали тут. Она позволяет использовать локальные ресурсы хостов ESXi для построения распределенной инфраструктуры хранения виртуальных машин.
  • База данных VMware vFabric Postgres database (vPostgres).

Кроме того, были обновлены и дополнены следующие темы в документе (который уже можно смело называть книгой, так как занимает он 90 страниц):

  • Использование нагрузок в ВМ, чувствительных к скорости подсистемы ввода-вывода и сетевому взаимодействию (интересна также статья в тему)
  • Техники NUMA и Virtual NUMA (vNUMA)
  • Техники экономии памяти хоста (Memory overcommit)
  • Технология Large memory pages
  • Техника Receive-side scaling (RSS), как в гостевых ОС, так и для адаптеров 10 Gigabit Ethernet
  • Средства миграции VMware vMotion, Storage vMotion, а также Cross-host Storage vMotion
  • Техники балансировки нагрузки VMware Distributed Resource Scheduler (DRS) и экономии электропитания Distributed Power Management (DPM)
  • Обновленный (а точнее полностью переписанный) VMware Single Sign-On Server (об этом у нас тут)


Таги: VMware, vSphere, Performance, Whitepaper, ESXi, VMachines, vCenter, vSAN, SSD

Интерактивные демо продуктов VMware: vSphere AppHA, vSphere 5.5 Replication и другое.


Некоторое время назад мы уже выкладывали интерактивные демо продуктов VMware, но с тех пор уже много воды утекло, и демки устарели. На прошедшей конференции VMworld 2013 компания VMware анонсировала новые версии своих продуктов, например, VMware vSphere 5.5 и vCloud Director 5.5, а к ним она приложила интерактивные демо, воспользоваться которыми в целях обучения может любой желающий.

Вот какие функции продуктов VMware можно посмотреть онлайн, не устанавливая их на свои серверы:

  • vSphere Data Protection 5.5 (VDP) – резервное копирование виртуальных машин.
  • vSphere 5.5 AppHA (AppHA) - мониторинг доступности приложений в виртуальных машинах (новая функция vSphere 5.5).
  • vCloud Director 5.5 (VCD) - новая версия решения для управления облачной инфраструктурой.
  • vSphere 5.5 Replication (VR) - техника репликации виртуальных машин.
  • vSphere 5.5 vFlash Read Cache (VFRC) - новая возможность использования кэша на флэш-дисках, о которой мы писали вот тут.
  • VMware Virtual SAN (vSAN) - возможности распределенного хранения виртуальных машин на локальных дисках серверов, о которых мы писали вот тут.

Традиционно, демо продуктов VMware - это графическая консоль с инструкциями куда нажимать и зачем. Очень удобно:


Таги: VMware, vSphere, Demo, Update, ESXi, vCenter, AppHA, vCloud, Director, vSAN

VMware Distributed Storage и концепция vSAN для построения хранилищ VMware vSphere.


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

Там же, на VMworld 2012, компания VMware представила технологию vSAN, реализующую распределенное хранение данных ВМ на локальных хранилищах хост-серверов VMware ESXi (Distributed Storage):

Концепция vSAN, включающая в себя Distributed Storage, является продолжением существующего подхода к организации общих хранилищ виртуальных машин на базе локальных дисков серверов - VMware vStorage Appliance. Работает это средство обеспечения отказоустойчивости хранилищ за счет полного дублирования хранилищ одного из узлов кластера, а также репликации данных между ними:

Теперь же, в скором времени в гипервизор VMware ESXi будет включена технология Distributed Storage, которая позволит агрегировать вручную или автоматически дисковые емкости (HDD и SSD) хост-серверов в единый пул хранения с функциями отказоустойчивости и кэширования:

Разрабатывается эта концепция на волне распространения SSD-накопителей в серверном оборудовании и СХД. Единый пул хранения кластера Distributed Storage будет не только объединять диски серверов (туда добавляются диски без созданных разделов с определенным администратором вкладом емкости в общий пул) и предоставлять пространство хранения виртуальным машинам на любом из хостов, но и будет управляем средствами политик механизма Policy-Based Storage Management. Интересно то, что размер кластера хранилища для Distributed Storage будет равен размеру кластера хостов (сейчас 32), в рамках которого все хосты имеют возможность использовать агрегированную емкость пула, даже те серверы, что не имеют дисков вовсе.

Все это будет интегрировано с механизмами HA, vMotion и DRS в целях обеспечения отказоустойчивости и балансировки нагрузки на хост-серверы. Кроме этого, агрегированный пул хранилищ будет поддерживать все основные технологии VMware для работы с хранилищами: снапшоты ВМ, связанные клоны, vSphere Replication (vR) и vStorage APIs for Data Protection (vADP).

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

  • Доступная емкость и объем ее резервирования.
  • Уровень отказоустойчивости (степень дублирования данных на узлах = количество реплик).
  • Уровень производительности (какое количество SSD-кэша выделить для обслуживания реплик, а также число страйпов для диска ВМ, если необходимо).

Данные в кластере VMware Distributed Storage хранятся на локальных дисках узлов по схеме RAID-1, так как это дает максимальный экономический эффект с точки зрения затрат на 1 IOPS при условии комбинирования HDD-хранилищ данных и SSD-хранилищ кэша и данных (подробнее тут). SSD-кэш работает как фронтэнд для HDD-дисков, обрабатывая кэширование чтений и буферизацию записи для операций кластера, при этом сделано множество оптимизаций кэша для увеличения вероятности попаданий в кэш при чтении данных ВМ с дисков различных узлов.

Ну а на практике vSAN уже работает в лабораториях VMware, где инженеры демонстрируют возможности Distributed Storage:

Информации о времени доступности технологии VMware Distributed Storage пока нет. Возможно, базовые функции vSAN будут реализованы в VMware vSphere 6.0.


Таги: VMware, Storage, vSAN, vSphere, ESXi, VSA, SSD, SAN, VMachines, Update

 
Реклама





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

02/12/2017:  AZURE DAY 2017 (Минск)
06/03/2018:  ИТ-стратегия 2018
24/05/2018:  IT&SECURITY FORUM (Казань)

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

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

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

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

Постер VMware vCloud Networking:

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

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


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


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

Видео про Citrix Xen

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

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

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

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

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

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


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