Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...
Данный Fling представляет собой пакет нативных драйверов для ESXi, которые позволяют поддерживать различные хранилища на базе технологии NVMe. Надо понимать, что community-драйверы не входят в официальный список поддержки VMware HCL, поэтому использовать их можно только в тестовых средах.
Драйверы теперь поддерживают VMware ESXi 7.0 или более поздние версии гипервизора для NVMe-хранилищ не от Apple. Пока список поддерживаемых устройств такой:
Для хранилищ Apple SSD пока поддерживается только ESXi 6.7 до версии Patch 03 (Build 16713306). Более новые версии гипервизора с NVMe-устройствами Apple, к сожалению, не работают. Пока драйверы поддерживают Apple 2018 Intel Mac Mini 8.1 и Apple 2019 Intel Mac Pro 7.1, причем подключение портов Thunderbolt 3 не поддерживется (ESXi может выпасть в PSOD).
Драйверы поставляются в виде VIB-пакета, установить который можно командой:
esxcli software vib install -d /path/to/the offline bundle zip
Скачать Community NVMe Driver for ESXi 1.1 можно по этой ссылке.
Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.
Основные темы документа:
Что такое снапшоты
Какие есть форматы снапшотов
Описание тестового окружения и рабочих нагрузок
Результаты тестирования производительности
Выводы по этим результатам
Итак, для тестирования использовались следующие рабочие нагрузки:
FIO (стандартный тест производительности ввода-вывода)
JVM (бенчмарк SPECjbb 2015)
OLTP database (тест HammerDB)
Давайте взглянем на результаты тестирования производительности с точки зрения гостевой системы и ее приложений:
1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):
В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.
2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:
3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:
4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:
Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.
5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:
Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.
Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:
При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):
Ну и в заключение VMware приводит такую табличку потерь производительности для виртуальных машин с одним снапшотом:
Итак, очевидные выводы:
Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
Хранилищам VVol все равно на снапшоты, производительность не падает.
Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
При удалении снапшотов производительность ВМ возвращается к исходному уровню.
На сайте проекта VMware Labs обновилась утилита HCIBench 2.6, которая до этого обновлялась осенью прошлого года. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.4 мы писали вот тут.
Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду средству Vdbench, содержащую инструкции о том, какие действия необходимо выполнить в кластере хранилищ. Это может вам пригодиться, например, когда вы хотите убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.
Давайте взглянем на новые возможности HCIBench 2.6:
Сервер tomcat обновлен до версии 8.5.68
Поддержка IPv6 для сетей ВМ и Management Network - как для DHCPv6, так и для link-local mode
Поддержка режима развертывания multi-writer disk
Улучшенная пре-валидация за счет перехода на govc
Поддержка спецификации read/write io_limit для fio
Исправлена ошибка при запуске в инфраструктуре VMC
Улучшена система сбора диагностических бандлов в режиме отладки vSAN
Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.
Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:
Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:
NETDUMPER_DIR_MAX_GB
Максимальный его размер может составлять 10GB.
После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:
Вильям Ламм написал интересную статью про USB-устройства на хосте VMware ESXi, когда нужно использовать некоторые устройства как хранилища, а некоторые - для проброса в виртуальные машины. При этом, в рамках данной методики, не нужно останавливать USB Arbitrator Service на хосте.
Итак, для начала выводим список доступных USB-интерфейсов на сервере:
esxcli hardware usb passthrough device list
У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):
Для второго устройства можно отключить именно функции проброса USB (passthrough), чтобы устройство не могло быть презентовано виртуальной машине. Для этого выполняем такую команду:
esxcli hardware usb passthrough device disable -d 2:7:90c:1000
После этого будет вот такая картина:
Далее уже можно подключить это устройство хранения к хосту ESXi, чтобы использовать его для создания VMFS-томов. Процедура описана вот тут, посмотрим на нее вкратце.
Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:
esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1
Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:
vdq -q
Затем создаем переменную с именем устройства, например:
Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:
esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1
После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:
Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.
Итак, что нового появилось в StarWind Virtual SAN v8 for Hyper-V в этом году:
1. Компоненты VTL и Cloud Replication
Поддержка Microsoft Azure - добавлена опция по загрузке файлов в Archive tier напрямую, без необходимости сначала добавлять их в Hot/Cool tier и дальнейшего перемещения в архив.
Возможность Write Protect для виртуальных кассет.
Минимальный размер кассеты установлен в 50 МБ.
Режим VTL file operation mode изменен на принудительное закрытие неиспользуемых файлов. Если в работе слишком много частей виртуальных кассет, то много открытых файлов могло привести к исчерпанию ресурсов. Изменить это поведение теперь можно в параметре closedatafiles в конфиге StarWind.cfg.
Исправлена ошибка при восстановлении кассет, разделенных на части, из облака (некоторые части могли не загружаться).
Пофикшена ошибка в cloud replication, которая могла возникать, если установлена опция "Create new empty tapes automatically when existing tape removed from VTL for replication". Если она была включена, это могло привести к падению сервиса при создании новой виртуальной кассеты.
2. Улучшения синхронной репликации
Исправлена ошибка с отклонением синхронизации HA-узла при перезапуске сервиса на одном из узлов (иногда процедура не стартовала автоматически).
Исправлена ошибка, приводившая к падению сервиса в случае, если соединение с хранилищем или сетевое соединение испытывало падение производительности.
Исправлена реализация алгоритма Node Majority failover strategy. Ранее она работала некорректно в случае, если соединение между узлами было нарушено, но только в одну сторону.
Пофикшена процедура автоматического восстановления для трехсторонней репликации. Ранее она использовала информацию от двух из трех узлов, что некорректно для процедура auto-restore. Теперь учитывается статус от всех трех узлов.
Поправлено некорректное поведение при операции расширения размера хранилища на узле. Это приводило к разрыву соединения для некоторых случаев, когда операции по работе с хранилищем занимали продолжительное время.
Исправлена ошибка, которая вела к полной синхронизации вместо быстрой в некоторых случаях.
Исправлена ошибка с обработкой IO-запросов на одном из хранилищ, приводившая к тому, что в случае зависания запроса на конфигурации с three-way репликацией происходила некорректная работа на всех трех узлах.
3. Основные улучшения
Улучшения производительности для версии VSA (Virtual Storage Appliance).
Исправлена проблема с закрытием сессии в случаях, когда обнаруживался критический недостаток ресурсов.
Исправлена проблема с обработкой операции control connection close - в некоторых случаях это приводило к генерации большого числа нотификаций, а Management Console переставала отвечать.
Исправлена процедура session close при остановке службы - теперь она не зависает в некоторых редких случаях.
Исправлена проблема с зависанием Management Console при накатывании бесплатной лицензии на сервер без интернет-соединения.
Физические устройства теперь есть в общем списке устройств. Их можно использовать для экспорта с физических ленточных устройств.
Добавлено свойство MaintenanceMode для объекта HA Device.
Загрузить пробную версию StarWind Virtual SAN v8 for Hyper-V можно по этой ссылке. Документация доступна здесь, а Release Notes - вот тут.
Отметим также, что обновился и продукт в формате виртуального модуля для платформы VMware - StarWind VSAN for vSphere (OVF Version 20210520, Version 8 build 14120). Release notes доступны тут (список улучшений там практически такой же, за исключением некоторых моментов в мартовской версии).
На сайте проекта VMware Labs появилась запись о том, что утилита App Volumes Packaging Utility 1.3 теперь официально включена в состав VMware App Volumes 4, version 2103. Такое иногда происходит с утилитами проекта Labs, некоторые из которых становятся либо самостоятельными продуктами, либо включаются в состав уже существующих решений.
Напомним, что Packaging Utility позволяет упаковывать приложения для использования с App Volumes. С помощью нее можно добавить необходимые метаданные в приложение MSIX на базе дисков VHD таким образом, чтобы их можно было использовать вместе с пакетами формата AV. Получившиеся VHD формата MSIX будут требовать App Volumes 4 версии 2006 или более поздней, а также Windows 10 версии 2004 или более поздней.
Соответственно сам продукт App Volumes был обновлен, давайте посмотрим на его новые возможности:
Теперь при установке App Volumes Manager можно выбрать пункт "App Volumes Tools" при установке на машину с Windows 10, который и устанавливает Packaging Utility. Далее с помощью команды appcapture.exe можно упаковывать приложения без необходимости использования консоли App Volumes Manager. С помощью appcapture можно автоматизировать процессы упаковки приложений для установщиков в silent-режиме, которые можно получать как в VMDK, так и в VDH форматах (причем одновременно). С помощью appcapture можно конвертировать пакеты между форматами VHD and VMDK, а также работать с пакетами формата MSIX.
Теперь есть возможность использовать глобальную настройку, позволяющую использовать пакет на любой ОС Windows 10. В Advanced Settings можно поставить галочку, которая отключает проверку, что та же самая версия ОС использовалась для создания пакета и его доставки в рабочее окружение пользователя.
Интервал Import Storage Groups по умолчанию был увеличен с 15 минут до 4 часов, чтобы позволить задаче закончить обработку большого числа пакетов на медленных хранилищах. Этот параметр можно изменить в настройках.
На странице Managed Storage Locations хранилище может быть помечено как read-only. В этом случае App Volumes Manager пропускает это хранилище, когда обновляет пакет или AppStack. Так как App Volumes регулярно записывает дополнительные метаданные в пакеты, чтобы отслеживать их обновления, эта опция оказывается очень полезной для некоторых хранилищ.
Также была обновлена подсистема безопасности и исправлены ошибки.
Загрузить VMware App Volumes 4, version 2103 со встроенной утилитой App Volumes Packaging Utility 1.3 можно по этой ссылке.
Не так давно мы писали о механизме VMware vSAN Enhanced Durability, который позволяет еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.
Дункан Эппинг рассказал о том, что происходит, если в нем всего три хоста. Например, если у вас есть 2 площадки, по три хоста ESXi на каждой, но в случае сконфигурированной политикии SFTT=1 (это Stretched FTT) у вас получается RAID-1 для дисковых объектов виртуальной машины на каждой из площадок:
При этом два хоста хранят в себе Data Component виртуальной машины, а третий хост работает для нее как Witness на случай изоляции одного из хостов кластера. Теперь возникает вопрос - а что произойдет с механизмом Enhanced Durability, если один из хостов перевести в Maintenance Mode? Где будет создаваться Durability Component (он хранит все поступающие операции записи Write IO), который защищает машину от сбоя на уровне площадки при переведенном в режим обслуживания хосте?
Ответ тут прост - этот компонент будет создаваться на других хостах, даже если он выполняет функции Witness (но, конечно же, он будет создан на хосте этой площадки):
Ну и небольшое демо процесса тестирования механизма Enhanced Durability в этих условиях от Дункана:
Таги: VMware, vSAN, HA, Storage, DR, Stretched Cluster
Компания StarWind, ведущий производитель программно-аппаратных решений для отказоустойчивых хранилищ под виртуальные машины, представила новое предложение - HCI Evaluation Kit для программно-аппаратных комплексов StarWind HyperConverged Appliance (HCA). С помощью набора для быстрого старта HCI Evaluation Kit вы сможете получить решение на базе вложенных (nested) виртуальных машин, в рамках которого будет работать sandbox-кластер...
Не так давно мы писали о новых возможностях средства для организации отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Среди новых возможностей мы упоминали поддержку служб vSAN File Services для растянутых кластеров (Stretched Clusters).
Дункан Эппинг раскрыл эту тему несколько подробнее. Действительно, службы vSAN File Services, так удобные для ROBO-сценариев при доступе к общим файловым шарам, теперь полностью поддерживаются.
Теперь в vSAN 7 U2 при настройке File Services надо указать, какому сайту принадлежит каждый из IP-адресов серверов файловых служб. Это Affinity rule, но оно не жесткое - при отказе виртуальных машин и рестарте их на другой площадке, оно может быть нарушено.
Но это еще не все. Для каждой файловой шары вам необходимо будет указать Affinity в ее настройках:
Это позволяет точно определить, файловую шару какой площадки следует использовать при соединении с ней клиентов. Опять-таки, это не строгое правило, на что намекает наличие опции "Either".
Ну и небольшой обзор работы файловых служб в растянутом кластере vSAN 7 Update 2 от Дункана:
Таги: VMware, vSAN, File Services, SMB, Storage, HA, Stretched
Недавно мы писали о новых возможностях решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Среди новых функций мы упоминали возможность Enhanced Data Durability, позволяющую еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.
Как знают администраторы vSAN, этот продукт обеспечивает высокую степень защиты данных от сбоев, в том числе встроенным механизмом избыточности, регулируемым политикой FTT (Failures to tolerate).
Однако при отказе одного или нескольких хостов ESXi в кластере vSAN может произойти ситуация, когда дисковый объект есть на одном из хостов, но только в одном экземпляре. Такая ситуация опасна тем, что если произойдет второй сбой, затрагивающий этот объект - данные могут быть безвозвратно утеряны.
Кстати, при переводе хоста в плановый режим обслуживания такая ситуация тоже может возникнуть - но в vSAN этот момент учитывался и раньше, и на время обслуживания все операции записи сохранялись до момента возвращения хоста в строй, после чего происходило накатывание операций, случившихся за это время:
Теперь же такой механизм появился и для внештатных ситуаций:
При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные дискового объекта с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище (durability component), чтобы обеспечить надежность данных, записываемых во время сбоя.
По умолчанию в случае сбоя кластер vSAN ждет 60 минут до начала восстановления дискового объекта на другом хранилище хоста ESXi для обеспечения политики FTT. Это связано с тем, что кластер не начинает емкие по ресурсам операции для сбоев, которые могут оказаться временными. Регулируется это настройкой Object Repair Timer (она же настройка vsan.clomrepairdelay в Advanced Settings, подробнее об этом тут):
Если в этот момент случится еще одна авария, которая затронет единственно выжившую копию данных, то виртуальная машина остановится, но возможность восстановить данные будет - как только хост с последней копией данных восстановится, на них накатятся сохраненные инкрементальные операции записи. Это позволит получить состояние виртуальной машины без потери всех последних операций записи.
Надо сказать, что операции по созданию durability component имеют приоритет над стандартными операциями vSAN, такими как синхронизация дисковых объектов, поэтому это происходит очень быстро, чтобы сразу начать записывать дельта-writes. Операции записи в durability component будут продолжаться (он будет в состоянии active), пока синхронизация дискового объекта с его репликой не завершится удачно (либо на восстановившемся хосте, либо на новом, после операции rebuild). После этого durability component для дискового объекта будет удален.
Еще стоит отметить, что если хост с durability component откажет, то новый хост возьмет на себя его функции и создаст свой durability component (число таких операций не ограничено). Также полезно то, что защита данных с помощью durability component работает и для дисковых объектов с FTT=2 или выше - главное, чтобы у вас было для всех этих операций свободное дисковое пространство в кластере.
На днях мы писали о новых возможностях решения для создания отказоустойчивых хранилищ VMware vSAN 7.0 Update 2. Дункан Эппинг обратил внимание на один из вспомогательных сервисов - VMware Skyline Health, в котором появилось очень полезное нововведение - Health History.
Теперь в сервисе Skyline Health (ранее он назывался Health Check) появилась опция по визуализации пройденных / не пройденных проверок для различных объектов в исторической ретроспективе, которая позволит вам соотнести непройденные проверки с происходившими странностями, ошибками или отказами компонентов инфраструктуры:
Вы можете вернуться до 30 дней назад во времени, указав промежуток, в котором вы хотите посмотреть детали непройденных или успешных проверок. Опцию сохранения этих данных можно отключить на вкладке Configuration.
При клике на красный квадрат, вы можете увидеть какие именно проверки не были пройдены, а также для скольки объектов они прошли успешно, а для скольки нет:
Ну и посмотрите небольшое видео от Дункана, где он показывает, как это работает в его тестовой лаборатории:
Недавно мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а также новой версии средства создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Сегодня мы немного подробнее расскажем о новых возможностях инфраструктуры работы с хранилищами (core storage) в новом обновлении vSphere.
Давайте посмотрим, что именно там нового:
1. Увеличение iSCSI Path Limit
Раньше для одного LUN максимально доступны были только 8 путей, но многим пользователям требовалось существенно больше. Используя несколько портов VMKernel или точек назначения, пользователям иногда было нужно 16 или даже 24 пути. Теперь максимум составляет 32 пути на LUN, что должно хватить всем.
2. Поддержка RDM для RHEL HA
Теперь для для работы Red Hat Enterprise HA можно использовать тома RDM на платформе vSphere. В корневых механизмах работы с хранилищами для этого были сделаны некоторые изменения.
3. Улучшения снапшотов VMFS SESparse
При чтении данных для машин со снапшотами существенно увеличилась производительность, так как чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение.
4. Поддержка нескольких адаптеров Paravirtual RDMA (PVRDMA)
В vSphere 6.7 была анонсирована поддержка RDMA. Одним из ограничений было то, что для одной виртуальной машины можно было использовать только один адаптер PVRDMA. Теперь этой проблемы больше нет.
5. Улучшения производительности для томов VMFS
Здесь были сделаны улучшения первых операций чтения для тонких дисков. Они особенно проявляются при резервном копировании и восстановлении, операциях копирования данных и Storage vMotion.
6. Улучшения работы с NFS-хранилищами
Теперь не обязательно создавать клон ВМ для использования offload'а операций по созданию снапшотов уровня дискового массива. Теперь можно использовать любые виртуальные машины на базе снапшотов без необходимости создавать redo logs.
7. Поддержка High Performance Plugin FastPath для Fabric Devices
Плагин HPP теперь используется по умолчанию для устройств NVMe. В плагине есть 2 опции - SlowPath для legacy-поведения и новый FastPath для большей производительности, но с некоторыми ограничениями. Подробнее рассказано вот в этой статье.
8. HPP - дефолтный плагин для vSAN
Начиная с vSphere 7 Update 2, HPP теперь дефолтный MPP для всех устройств - SAS/SATA/NVMe (и Fabric Devices, как было сказано выше).
9. Улучшения VOMA
Средство vSphere On-disk Metadata Analyzer (VOMA) используется для нахождения и исправления повреждений метаданных томов, которые влияют на файловую систему и логические тома. Теперь это доступно и для spanned VMFS-томов. Более подробно об этом можно узнать тут.
10. Поддержка бОльших значений Queue Depth для vVols Protocol Endpoints
В некоторых случаях параметр Disk.SchedNumReqOutstanding (DSNRO) не соответствует глубине очереди на vVols Protocol Endpoint (PE) (он же VVolPESNRO). Теперь глубина очереди для PE равна 256 или берется максимальная глубина видимого LUN. Поэтому минимум PE QD выставлен в 256.
11. Создание Config vVol больше, чем на 4 ГБ
Теперь это позволяет партнерам VMware хранить образы для автоматических билдов на томах VVols.
12. Улучшения правил SPBM Multiple Snapshot
Движок Storage Policy Based Management позволяет администратору управлять фичами хранилищ VVols на уровне отдельных виртуальных машин. Теперь в рамках одной политики SPBM можно использовать несколько правил для снапшотов (например, интервалы их создания). Эта фича должна поддерживаться на уровне VASA у соответствующего производителя массива.
13. Поддержка снапшотов для Cloud Native Storage (CNS) на базе First Class Disks
Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. Для них теперь есть поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.
14. Маппинг CNS PV на vVol
В некоторых случаях пользователи хотят видеть, какие тома VVols ассоциированы с томами CNS Persistent Volume (PV). Теперь этот маппинг можно увидеть в интерфейсе CNS.
Вчера мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а сегодня расскажем о вышедшем одновременно с ней обновлении решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2.
Нововведения сосредоточены в следующих областях:
Давайте посмотрим, что именно нового в vSAN 7 U2:
Улучшения масштабируемости
HCI Mesh Compute Clusters
Теперь в дополнение к анонсированной в vSphere 7 Update 1 топологии HCI Mesh для удаленного доступа к хранилищам vSAN появилась технология HCI Mesh Compute Clusters, которая позволяет иметь вычислительный кластер vSphere/vSAN без собственных хранилищ, использующий хранилища удаленных кластеров.
Самое интересное, что эти кластеры не нуждаются в лицензиях vSAN, вы можете использовать обычные лицензии vSphere.
Также такие кластеры vSAN могут использовать политики хранилищ, в рамках которых можно получить такие сервисы, как дедупликацию / компрессию или шифрование Data-at-rest:
Также было увеличено число хостов ESXi, которые могут соединяться с удаленным датастором, до 128.
Небольшое видео о том, как создать HCI Mesh Compute Cluster:
Улучшение файловых служб
Службы vSAN file services теперь поддерживают растянутые (stretched) кластеры и двухузловые конфигурации, что позволяет использовать их для ROBO-сценариев.
Улучшения растянутых кластеров
Растянутые кластеры vSAN теперь обрабатывают не только различные сценарии сбоев, но и условия восстановления, которые были определены механизмом DRS до наступления события отказа. DRS будет сохранять ВМ на той же площадке до того, как данные через inter-site link (ISL) будут полностью синхронизированы после восстановления кластера, после чего начнет перемещать виртуальные машины в соответствии со своими правилами. Это повышает надежность и позволяет не загружать ISL-соединение, пока оно полностью не восстановилось.
Технология vSAN over RDMA
В vSAN 7 Update 2 появилась поддержка технологии RDMA over Converged Ethernet version 2 (RCoEv2). Кластеры автоматически обнаруживают поддержку RDMA, при этом оборудование должно находиться в списке совместимости VMware Hardware Compatibility Guide.
Улучшения производительности
В vSAN 7 U2 была оптимизирована работа с RAID 5/6 в плане использования CPU. Также была улучшена производительность яруса буффера. Это позволяет снизить CPU cost per I/O.
Кроме того, были сделаны оптимизации для процессоров AMD EPYC (см. тут).
Улучшения для задач AI and Developer Ready
Здесь появилось 2 основных улучшения:
S3-совместимое объектное хранилище для задач AI/ML и приложений Cloud Native Apps.
На платформе vSAN Data Persistence platform теперь поддерживаются компоненты Cloudian HyperStore и MinIO Object Storage. Пользователи могут потреблять S3-ресурсы для своих AI/ML нагрузок без необходимости долгой настройки интеграций.
Улучшения Cloud Native Storage в vSphere и vSAN
Теперь Cloud Native Storage лучше поддерживает stateful apps на платформе Kubernetes. Также vSAN предоставляет простые средства для миграции с устаревшего vSphere Cloud Provider (vCP) на Container Storage Interface (CSI). Это позволит иметь персистентные тома Kubernetes на платформе vSphere и расширять их по мере необходимости без прерывания обслуживания.
Улучшения безопасности
Службы vSphere Native Key Provider Services
Это механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки. Также для двухузловых конфигураций и Edge-топологий можно использовать встроенный KMS-сервис, который работает с поддержкой ESXi Key Persistence.
Средства для изолированных окружений
VMware предоставляет Skyline Health Diagnostics tool, который позволяет самостоятельно определить состояние своего окружения в условиях изоляции от интернета. Он сканирует критические компоненты на проблемы и выдает рекомендации по их устранению со ссылками на статьи базы знаний VMware KB.
Улучшения Data In Transit (DIT) Encryption
Здесь появилась валидация FIPS 140-2 криптографического модуля для DIT-шифрования.
Упрощение операций
Улучшения vLCM
Для vSphere Lifecycle Manager появились следующие улучшения:
vLCM поддерживает системы Hitachi Vantara UCP-HC и Hitachi Advanced Servers, а также серверы Dell 14G, HPE10G и Lenovo ThinkAgile.
При создании кластера можно указать образ существующего хоста ESXi.
Улучшения защиты данных
При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище, чтобы обеспечить надежность данных, создаваемых во время сбоя. Ранее эта технология применялась для запланированных операций обслуживания.
Поддержка Proactive HA
vSAN 7 Update 2 теперь поддерживает технологию Proactive HA, которая позволяет проактивно смигрировать данные машин на другой хост ESXi.
Улучшения мониторинга
Здесь появились новые метрики и хэлсчеки, которые дают больше видимости в инфраструктуре коммутаторов, к которой подключены хосты vSAN. На физическом уровне появились дополнительные метрики, такие как CRC, carrier errors, transmit и receive errors, pauses. Также для новых метрик были добавлены health alarms, которые предупредят администратора о приближении к пороговым значениям.
Улучшения vSphere Quick Boot
Здесь появилась техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.
Скачать VMware vSAN 7 Update 2 в составе vSphere 7 Update 2 можно по этой ссылке. Release Notes доступны тут.
Бонус-видео обзора новых фичей от Дункана Эппинга:
Таги: VMware, vSAN, Update, ESXi, vSphere, Storage, HA, DR, VMachines
Продолжаем рассказывать о лучшем в отрасли решении для создания программных хранилищ под виртуальные машины на базе хост-серверов ESXi - StarWind Virtual SAN for vSphere. Как многие знают, с какого-то момента StarWind стала поставлять свое решение для платформ VMware в виде виртуального модуля (Virtual Appliance) на базе Linux, который реализует основные сервисы хранения, дедупликации и компрессии, а также отказоустойчивости и обеспечения надежности данных в виртуальных машинах.
Для виртуального модуля StarWind работа механизма дедупликации и компрессии обеспечивается средствами Linux-движка Virtual Data Optimizer (VDO), который появился относительно недавно. Это удобный и надежный способ экономии дискового пространства за счет использования дополнительных емкостей оперативной памяти на хосте.
Для начала вам нужно определиться с оборудованием хостов ESXi, где вы будете развертывать виртуальные модули StarWind. Как вы понимаете, в целях обеспечения отказоустойчивости таких узлов должно быть как минимум два.
Что касается HDD и SSD-дисков, то нужно также спланировать конфигурацию RAID на хранилище хостов. Сделать это можно в соответствии с рекомендациями, описанными в базе знаний StarWind. Вы можете использовать программный или аппаратный RAID, о настройках которого мы расскажем ниже.
Что касается дополнительной оперативной памяти на хосте ESXi, то нужно выбирать ее объем, исходя из следующих критериев:
370 МБ плюс дополнительные 268 МБ на каждый 1 ТБ физического хранилища
Дополнительно 250 МБ на 1 ТБ физического хранилища, если включена дедупликация (UDS index)
То есть для 4 ТБ физического хранилища с дедупликацией вам понадобится:
370 MB + 4 * 268 MB +4 * 250 MB = 2 442 MB RAM
Итого 2,4 ГБ оперативной памяти дополнительно к памяти под ОС виртуального модуля. Вообще, StarWind рекомендует 8 ГБ памяти для виртуального модуля - 4 ГБ на машину и 4 ГБ на движок VDO для работы с хранилищем.
Один VDO-том может работать с хранилищем до 256 ТБ, что покрывает максимум потребностей в рамках хранилищ на базе серверов. Также StarWind очень рекомендует использовать дисковые массивы All-flash или NVMe-оборудование.
Общее правило развертывания таких хранилищ таково:
Под VDO: аппаратный или программный RAID (LVM или mdraid)
Над VDO: "толстые" (thick) диски StarWind Virtual SAN в режиме stand-alone или HA
Надо понимать, что сам том VDO - это тонкий диск, растущий по мере наполнения, поэтому устройство под ним должно иметь расширяемую природу (MD RAID, LVM).
Примерная схема отказоустойчивого решения StarWind Virtual SAN for vSphere на базе 2 узлов выглядит так:
После того, как вы установите StarWind Virtual SAN, настроите виртуальную машину и StarWind Management Console, нужно будет настроить аппаратный или программный RAID для хранилища.
Если вы используете аппаратный RAID, то просто создайте виртуальный диск для ВМ StarWind Virtual SAN на его хранилище, но обязательно типа "Thick Provisioned Eager Zeroed" (также вы можете использовать RDM-диск):
Если же вы будете использовать программный RAID, то нужно будет использовать HBA или RAID-контроллер в режиме DirectPath I/O passthrough, чтобы получить прямой доступ к дискам и собрать на их базе RAID-массив.
Для этого вам нужно будте выбрать правильный HBA/RAID-контроллер как PCI-устройство:
И пробросить его напрямую в виртуальную машину StarWind:
После этого в StarWind Management Console можно будет собрать RAID нужного вам уровня:
Рекомендации тут такие:
После этого в виртуальном модуле StarWind на полученном хранилище нужно будет создать VDO-устройство с нужными вам параметрами:
Здесь мы видим, что создается устройство с включенной дедупликацией, выключенной компрессией, нужным размером индексной памяти и заданного объема.
После создания это устройство надо отформатировать в XFS со следующими параметрами:
Далее вы можете создавать хранилище StarWind на этом устройстве и (опционально) сделать его реплику на партнерском узле в режиме HA. Также рекомендуется выставить настройку Disk.DiskMaxIOSize на хосте ESXi
В значение 512:
Ну и про оптимизацию производительности I/O-планировщика прочитайте вот эту статью базы знаний StarWind. Если вам интересен процесс создания хранилищ с дедупликацией и компрессией на базе StarWind Virtual SAN в стиле "от и до", то рекомендуем прочитать вот эту статью.
Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.
Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.
Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.
К сожалению, все это работает только на хранилищах Fibre Channel.
Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":
Далее нужно понимать следующие условия и ограничения:
Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.
Максимумы конфигураций для таких кластеров WSFC следующие:
Надо помнить еще о следующих ограничениях (более подробно тут):
Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
Горячее расширение VMDK кластерной ВМ не поддерживается.
Не поддерживается Storage vMotion и снапшоты.
VMFS 5 и более ранние версии не поддерживаются.
Таги: VMware, vSphere, WSFC, MSCS, ESXi, VMDK, Storage, Microsoft
Администраторы VMware vSphere в больших инфраструктурах иногда используют кластеры Windows Server Failover Clusters (WSFC) на базе RDM-дисков, которые доступны для хостов VMware ESXi. Ранее они назывались Microsoft Cluster Service (MSCS). При использовании таких кластеров время загрузки хоста ESXi может вырасти аж до целого часа, если не поставить этим LUN статус Perennially reserved.
Суть проблемы в том, что WSFC ставит SCSI-3 reservations для своих LUN, используемых активным узлом, и если ESXi видит эти тома (то есть они не отмаскированы для него), то он безуспешно пытается получить к ним доступ. Для этого он делает несколько попыток при загрузке, пока не решает перейти к следующим томам. Статус этих операций вы можете увидеть, если нажмете Alt+F12 при загрузке хоста:
Xavier Avrillier написал статью о том, как с помощью esxicli/PowerCLI пометить такие тома как Perennially reserved, чтобы ESXi пропускал их при сканировании (об этом также рассказано в KB 1016106).
Сначала вам надо узнать LUN canonical name устройства. Делается это следующей командой PowerCLI:
На сайте virten.net, как обычно, вышла замечательная статья о реальной боли некоторых администраторов VMware vSphere - уменьшении дисков vCenter Server Appliance (vCSA). Так как vCSA работает в виртуальной машине, то иногда возникает необходимость в уменьшении ее дисков в целях простоты перемещения и компактности хранения. Но основная ситуация, когда диски vCSA чрезмерно разрастаются - это апгрейд сервера vCenter - в этом случае его хранилище может увеличиться до 1 ТБ при реально занятом пространстве в 100 ГБ. Тут уже без шринка (shrink) не обойтись.
При апгрейде vCSA установщик смотрит на аллоцированное пространство, а не на занятое, поэтому исходная машина в 416 ГБ может быть преобразована только в целевую ВМ типа Small с 480 ГБ диска:
Метод, описанный ниже, стоит применять только для виртуального модуля vCSA, который вы планируете апгрейдить, поскольку меняется порядок его дисков. Это, в целом, не проблема, но могут возникнуть сложности при взаимодействии с поддержкой VMware, которая может посчитать эту конфигурацию неприемлемой.
Перво-наперво нужно сделать бэкап вашего vCSA или его клон, с которым вы и будете работать. Если что-то не получится, вы просто сможете удалить клон.
Итак, заходим на vCSA по SSH и останавливаем все службы:
# service-control --stop --all
Выбираем файловую систему, для которой будем делать shrink. Например, /storage/seat имеет размер 296 ГБ, но реально используется 67 МБ! Запоминаем файловую систему (/dev/mapper/seat_vg-seat) и точку монтирования хранилища (/storage/seat), которое будем уменьшать.
Также из файловой системы вы можете получить Volume Group (seat_vg) и Logical Volume (seat):
Когда миграция будет закончена, sdh должен остаться пустым (Allocated PE = 0 и нет физических сегментов, только FREE):
# pvdisplay -m /dev/sdh
--- Physical volume ---
PV Name /dev/sdh
VG Name seat_vg
PV Size 300.00 GiB / not usable 7.00 MiB
Allocatable yes
PE Size 8.00 MiB
Total PE 38399
Free PE 38399
Allocated PE 0
PV UUID V7lkDg-Fxyr-qX4x-d3oi-KhNO-XZyT-EHgibI
--- Physical Segments ---
Physical extent 0 to 38398:
FREE
Удаляем sdh из Volume Group:
# vgreduce seat_vg /dev/sdh
Удаляем LVM-метки из sdh:
# pvremove /dev/sdh
Запускаем скрипт autogrow.sh для расширения файловой системы к размеру виртуального диска:
/usr/lib/applmgmt/support/scripts/autogrow.sh
Последний шаг очень важен - удаляем старый диск. Не удалите не тот! Для этого проверяем SCSI ID с помощью lsscsi:
# lsscsi |grep sdh
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
Мы видим, что SCSI ID [2:0:8:0] нам нужно удалить. Помните, что номер диска не всегда совпадает с SCSI ID. Удалите правильный диск (в данном случае 8), не ошибитесь!
Это все, теперь можно перезагрузить виртуальную машину, после чего в качестве опции апгрейда будет доступен вариант апгрейда на Tiny:
Если вы хотите уменьшить другие разделы, то идентифицируйте соответствующие параметры Logical Volume, Volume Group и Virtual Disk, после чего повторите процедуру.
# lsscsi
[0:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0
[2:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[2:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
[2:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
[2:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
[2:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
[2:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
[2:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
[2:0:9:0] disk VMware Virtual disk 1.0 /dev/sdi
[2:0:10:0] disk VMware Virtual disk 1.0 /dev/sdj
[2:0:11:0] disk VMware Virtual disk 1.0 /dev/sdk
[2:0:12:0] disk VMware Virtual disk 1.0 /dev/sdl
[2:0:13:0] disk VMware Virtual disk 1.0 /dev/sdm
Компания VMware опубликовала полезный FAQ, ссылка на который может в любой момент понадобиться администратору VMware vSphere для понимания различных аспектов системного хранилища серверов VMware ESXi.
Давайте посмотрим, на какие вопросы там можно найти ответы:
Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:
Какое хранилище рекомендуется в качестве системного для ESXi?
Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
Что вообще означает Degraded Mode?
Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут
Это гостевой пост нашего спонсора - компании ИТ-ГРАД, предоставляющей в аренду виртуальные машины из облака. Магнитная лента, которая фактически является одним из самых архаичных носителей, недавно получила масштабное обновление. Под катом поговорим о продукте, обсудим технические характеристики и возможную применимость в дата-центрах России и мира.
Не все администраторы VMware vSphere и vSAN знают, что в версии vSAN 6.7 Update 3 появилась утилита vsantop, которая по аналогии с esxtop, используемой для получения метрик с хостов ESXi, позволяет получать метрики с устройств и хранилищ vSAN.
Запускается утилита просто: vsantop
По умолчанию она отображает метрики для сущности host-domclient. Чтобы выбрать нужную вам сущность - устройства, хост или кластер, нужно нажать большую клавишу <E> с шифтом:
После того, как вы выберете нужную сущность, будут отображаться метрики для нее с дефолтными колонками в данной категории. Чтобы выбрать колонки, нужно нажать клавишу <f>:
Для отображения можно выбрать только 10 полей, если хотите добавить какое-то поле, то какое-то из текущих придется убрать.
Также esxtop может работать в пакетном режиме с заданным интервалом и записывать метрики в CSV-файл:
vsantop -b -d [delay] -n [iterations] > [file location & name]
usage: vsantop [-h] [-v] [-b] [-d delay] [-n iterations]
-h prints this help menu.
-v prints version.
-b enables batch mode.
-d sets the delay between updates in seconds.
-n runs vsantop for only n iterations. Use "-n infinity" to run forever.
Например, вот такая команда запустит сбор метрик с 10-секундным интервалом, всего будет 20 таких итераций, а результаты будут записаны в файл CSV:
Многие администраторы решения для создания отказоустойчивых хранилищ VMware vSAN иногда задумываются, чем отличаются политики хранилищ виртуальных машин (Storage Policies) для растянутых кластеров в плане Disaster Tolerance.
Дункан Эппинг написал об этом полезную заметку. Если вы не хотите, чтобы ваша виртуальная машина участвовала в растянутом кластере, то вам следует выбрать один из двух вариантов для настройки Site Disaster Tolerance: хранить все данные на основном сайте или все на резервном:
None – Keep data on preferred (stretched cluster)
None – Keep data on non-preferred (stretched cluster)
Между тем, в интерфейсе есть несколько схожих вариантов:
Например, есть еще два, казалось бы, подходящих:
None – Stretched Cluster
None – Standard Cluster
Но оба этих варианта политик хранилищ для растянутых кластеров не подходят. В первом случае (None – Stretched Cluster) виртуальная машина будет обрабатываться на уровне дисковых объектов, и vSAN будет решать, куда их поместить в растянутом кластере. Вполне может получиться такая ситуация, что один VMDK находится на одной площадке, а второй - на другой. При этом сама машина же может исполняться только на одном ESXi:
Такая ситуация очевидно очень плоха с точки зрения производительности.
Во втором же случае (None – Standard Cluster), если ваша машина настроена с точки зрения хранилищ на RAID-1 и FTT=1, то в растянутом кластере это превращается в SFTT=0 (Stretched FTT), что означает, что данные с одной площадки будут зеркалироваться на другую, но на уровне одной площадки будет храниться только одна копия данных дисковых объектов, что плохо с точки зрения надежности и отказоустойчивости.
Поэтому в растянутых кластерах для машин, которым не нужна "растянутость", используйте настройки Keep data on preferred или Keep data on non-preferred.
Если вы когда-нибудь изучали вопрос, почему дискета в 1.44 МБ дает на самом деле 1.38 МБ дискового пространства, то знаете, что это происходит потому, что мегабайт производителей дискет равен 1024х1000 байт. Поэтому дискета на «1,44 Мб» на самом деле имеет ёмкость в 1,44х1024х1000 байт = 1440 Кб или 1.38 Мб (где 1 Мб = 1024х1024 байт). Подробнее об этом вы можете прочитать вот тут.
"Неправильные" килобайты и мегабайты используют префиксы системы СИ (кило, мега, гига), что сложилось исторически, но неверно по сути. "Правильные" (бинарные) килобайты, мегабайты и гигабайты называются кибибайтами, мебибайтами и гибибайтами, соответственно - эти префиксы определены стандартом IEC. При написании они выглядят как KiB, MiB, GiB, TiB и т.д.
Из-за путаницы (или сознательного преуменьшения) производителей систем хранения данных и операционных систем на сегодняшний день иногда трудно понять, какой объем дискового пространства доступен в байтах и не является ли 1 ТБ емкости на самом деле 931 гигабайтом. Например, Microsoft по-прежнему использует систему СИ для отображения мегабайтов/гигабайтов.
VMware приступила к прояснению этого вопроса, начав со своей облачной инфраструктуры VMware Cloud on AWS. Теперь для отображения доступной емкости в консоли используется бинарная нотация IEC:
В данном случае емкость равно 20.74 тебибайта, что в байтах равняется:
Это не изменяли в vCenter, чтобы не вводить пользователей в заблуждение - ведь гостевые ОС отображают данные о емкости в системе СИ. Но имейте в виду, что из-за этого вы можете видеть разные емкости внутри и снаружи ОС при отображении общего и свободного пространства.
Первый момент - это то, что вам не потребуется Storage Replication Adapter (SRA), чтобы использовать репликацию на уровне дискового массива. Тома VVols изначально поддерживают управление хранилищами и их репликацией за счет механизма Storage Policy-Based Management (SPBM). Когда вы настраиваете репликацию VVols, она устанавливается не на уровне LUN, а на уровне виртуальных машин.
Все это упрощает управление репликацией виртуальных машин (нет необходимости настройки и обслуживания SRA), а также повышает гранулярность управления за счет оперирования на уровне отдельных виртуальных машин, а не всего LUN в рамках настройки SRM Protection Groups:
Второй важный момент - это то, что поскольку репликация VVols происходит на уровне виртуальных машин и их хранилищ, то ввиду меньшей гранулярности ВМ можно параллельно реплицировать на разные хранилища в соответствии с политиками SPBM, но при этом с разной периодичностью в зависимости от места назначения и их Protection Groups:
В традиционной инфраструктуре хранилищ, когда вы делаете тест восстановления хранилищ в SRM, то он должен выполняться для целой Protection Group, что рождает определенные сложности и условия при подготовке к тестированию. Для томов VVols все происходит гораздо проще, с учетом разной частоты репликации для виртуальных машин и большей гранулярности тестирования. Также это дает возможности простого восстановления отдельной ВМ в случае сбоя.
Между тем есть некоторые ограничения использования томов VVols и SRM:
SRM не поддерживает защиту виртуальных машин, которые имеют нереплицируемые виртуальные диски.
SRM не поддерживает защиту виртуальных машин с разными дисками на базе VVols, которые имеют разные политики хранилищ с точки зрения репликации и разные replication groups.
vVols не поддерживают восстановление шаблонов виртуальных машин (templates).
VVols поддерживает применение разных политик SPBM к дискам виртуальной машины, но чтобы эта ВМ поддерживалась со стороны SRM, нужно, чтобы все ее диски были настроены на базе одной политики:
Тома vVols 2 с поддержкой репликации уже поддерживаются на стороне хранилищ Dell EMC (PowerMax), HPE и Pure Storage. Также в ближайшем будущем ожидается существенное расширение этого списка.
Более подробную информацию вы можете получить по следующим ссылкам:
Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.
Поддержка NVMe-oF для доступа к хранилищам появилась еще в VMware vSphere 7, а в обновлении Update 1 была улучшена и оптимизирована. В указанном выше документе рассматривается сравнение производительности традиционного протокола Fibre Channel Protocol (SCSI FCP) с реализацией FC-NVMe в vSphere 7.0 U1.
Для всех бенчмарков использовался тот же HBA-адаптер и инфраструктура сети хранения данных SAN. Для генерации нагрузки использовались утилиты fio (для создания разных по размеру операций ввода-вывода I/O, а также паттернов нагрузки) и Microsoft CDB (бенчмарк для генерации OLTP-нагрузки в SQL Server).
Результат оказался весьма интересным. С точки зрения IOPS протокол NVMe-oF смог выжать почти в два раза больше операций ввода-вывода практически для IO любого размера:
Задержка (Latency) также снизилась практически в два раза:
На картинке ниже приведены результаты теста Microsoft CDB для базы данных в числе транзакций в секунду:
Здесь также виден значительный прирост для NVMe-oF, а для двух виртуальных машин производительность выше почти в раза!
Остальные интересные детали тестирования - в документе.
Многие администраторы уже используют продукт VMware vSAN 7 Update 1 для создания отказоустойчивых кластеров хранилищ на базе серверов ESXi. Некоторое время назад мы писали про технологию Cloud Native Storage (CNS), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.
Давайте посмотрим, что нового появилось в возможностях CNS в обновлении vSAN 7 U1:
1. Расширение томов PersistentVolumeClaim
В Kubernetes v1.11 появились функции расширения томов за счет изменения объекта PersistentVolumeClaim (пока только офлайн). Помните, что уменьшение тома (shrink) не поддерживается.
2. Статический провижининг в Supervisor Cluster
Эта возможность позволяет презентовать существующий том в кластере K8s, который будет интегрирован с vSphere Hypervisor Cluster (он же Supervisor Cluster, vSphere with K8s, Project Pacific).
3. Поддержка vVols для vSphere K8s и TKG Service
Теперь обеспечивается поддержка внешних хранилищ на базе vK8s и TKG с использованием томов vVols.
4. Функции Data Protection for Modern Applications
В vSphere 7.0 U1 появились функции поддержки резервного копирования Dell PowerProtect и Velero для Pacific Supervisor и TKG кластеров. Для Velero вы можете инициировать создание снапшотов через Velero plugin и хранить их в облаке S3.
5. Функции vSAN Direct
Возможность vSAN Direct позволяет использовать Direct Attach Storage (обычно на базе физических HDD-дисков) для хранения виртуальных машин VMware vSphere.
Вы можете создавать vSAN Direct Datastores, которые не являются общими для кластера датасторами, но физические диски таких хранилищ можно, например, напрямую подключать к виртуальным модулям (Virtual Appliances) или к контейнерам, исполняемым в среде vSphere, которым нужно объектное хранилище, но при этом хочется использовать его напрямую, минуя стандартный путь данных vSAN.
На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.
Симптомы переполнения кучи, как правило, следующие:
Датасторы на хостах показывают статус "Not consumed"
Виртуальные машины не могут выполнить vMotion
Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."
В логе vmkernel.log могут появляться следующие сообщения об ошибках:
Heap vmfs3 already at its maximum size. Cannot expand
Heap vmfs3: Maximum allowed growth (#) too small for size (#)
Failed to initialize VMFS distributed locking on volume #: Out of memory
Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory
Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:
Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:
# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done
Результат будет примерно таким:
Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:
Maximum allowed growth * too small for size
Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.
На сайте проекта core.vmware.com появился интересный документ из будущего, описывающий особенности проектирования и сайзинга кластеров хранилищ vSAN, актуализированный 4 декабря этого года - VMware vSAN 7 Update 1 Design Guide:
На самом деле, документ этот очень полезен для администраторов VMware vSAN, планирующих развертывание корпоративной инфраструктуры хранилищ на базе серверов ESXi. В нем рассматриваются все новые возможности версии vSAN 7 Update 1, включая технологию HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):
Основные разделы документа:
vSAN Design Overview
vSAN Limits
Network Design Considerations
Storage Design Considerations
VM Storage Policy Design Considerations
Host Design Considerations
Cluster Design Considerations
Determining if a Workload is Suitable for vSAN
Sizing Examples
vSAN Sizing Tool
VMware vSAN GSS Support
Очень полезная вещь - это наличие рекомендаций и лучших практик по различным аспектам проектирования кластров:
Интересная табличка по рекомендациям выставления опций по реакции на событие изоляции (Isolation Responce / Isolation Policy):
Интересны также указания на часто встречающиеся ошибки проектирования:
В общем, документ мегаполезный. Скачать VMware vSAN 7 Update 1 Design Guide можно вот тут.
Многие администраторы платформы VMware vSphere задаются вопросом - что произойдет, если изменить политику хранилищ (Storage Policy) в кластере vSAN для виртуальной машины? Будет ли после этого выполнена операция по перестроению дисковых объектов (Rebuild), что повлечет дополнительную нагрузку на хранилища и займет время?
Также в некоторых условиях операция Rebuild может не выполняться, но выполняется Resync - добавление новых копий данных, при котором исходные копии данных не изменяются (например, вы увеличиваете значение политики FTT, что влечет создание новых дисковых объектов).
Ответ на этот вопрос зависит от того, какую политику и на что вы меняете. Дункан Эппинг провел полезные тесты в своей лабе, чтобы выяснить, в каких случаях происходит Rebuild/Resync. После каждой операции он через интерфейс командной строки проверял, происходила ли операция ресинхронизации. Далее он свел полученные результаты в таблицу ниже, чтобы при изменении политики администраторы vSAN представляли, что произойдет дальше.
RSS
