Оказывается, еще в начале мая компания HP совместно с VMware выпустила кастомизированный образ гипервизора vSphere - HPE Customized ESXi May 2017, предназначенного для установки на серверы HP.
Этот релиз для многих администраторов является важным событием, так как прошлый кастомизированный образ HPE Custom ESXi от ноября 2016 года содержал в себе некоторые проблемы, касающиеся драйверов и работы с хранилищами (в частности, наблюдалась низкая скорость записи на локальные диски). Возможно, в этом релизе данные проблемы решены, по крайней мере новый набор драйверов должен улучшить некоторые вещи.
HPE Customized ESXi May 2017 доступен для скачивания по этой ссылке. Предыдущие образы (для более ранних версий гипервизора) можно также скачать с сайта VMware по этим ссылкам:
Номера билдов и их содержимое приведены вот в этом документе HPE (там же есть ссылки на соответствующие драйвера и офлайн бандлы ESXi). Ну а руководство по кастомизированным билдам HPE Custom ESXi находится вот тут.
Многим из вас известен продукт для организации отказоустойчивых кластеров хранилищ под виртуальную инфраструктуруру StarWind Virtual SAN. Он выпускается уже в течение многих лет и давно зарекомендовал себя как лучшее в отрасли решение для создания программных хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Его основные возможности приведены тут и вот тут. А сегодня мы расскажем о том, что продуктом и всеми его функциями стало можно пользоваться фактически бесплатно!
Многие пользователи небольших виртуальных инфраструктур ищут надежные решения для организации программных хранилищ, при этом им бы не хотелось покупать отдельную лицензию на Windows Server под узлы хранения.
Специально для них компания StarWind, известная своим продуктом Virtual SAN, позволяющим организовать отказоустойчивые кластеры хранилищ, создала виртуальный модуль StarWind Virtual Storage Appliance (VSA) на базе Linux.
StarWind VSA представляет собой полностью готовую к импорту в вашу виртуальную среду виртуальную машину, реализующую все необходимые сервисы Virtual SAN. Развертывается она буквально в пару кликов, а далее управляется через удобную веб-консоль (StarWind Web console).
Чтобы узнать больше о возможностях продукта и вживую увидеть его демонстрацию (а также позадавать вопросы на русском языке) - регистрируйтесь на вебинар. Скачать StarWind Virtual Storage Appliance можно по этой ссылке.
Те из вас, кто следят за обновлениями решения для организации кластеров хранилищ 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% исходной емкости.
В довершение нужно обязательно отметить, что администратор не может контролировать, где будут размещаться дисковые объекты ВМ в пределах одного сайта (то есть не получится обеспечить распределение дублированных копий объектов на уровне серверных стоек одной площадки).
В феврале мы писали о средстве IOInsight, которое позволяет детально взглянуть на характеристики взаимодействия виртуальных машин с хранилищами и провести анализ метрик ввода-вывода на уровне отдельных VMDK-дисков.
На днях на сайте проекта VMware Labs появилось обновление этого виртуального модуля - IOInsight 1.1.
Давайте посмотрим на новые возможности последней версии:
Утилита командной строки для установки статического IP-адреса или DHCP.
Опция для установки NTP-севреров.
Опция в интерфейсе, позволяющая настроить отсылку логов и результатов вывода IOInsight разработчикам для последующего решения проблем.
Вот какие ошибки были исправлены и улучшения добавлены:
На интересную проблему обратил внимание Anthony Spiteri в своем блоге - у него после развертывания платформы VMware ESXi 6.5 на сервере с SSD-дисками ISO-образ Windows 2016 полчаса заливался на датастор (интересно, что нам некоторые читатели писали о подобной проблеме). Потом он создал новую виртуальную машину и поставил устанавливаться Windows, а ESXTOP показывал скорость записи 10-20 МБ/с, в то время как она должна была быть на уровне 400-500 МБ/с.
Он стал ковырять проблему дальше и раскопал драйвер, который используется для SATA-контроллера:
Далее он проверил, какие драйверы подсистемы хранения сейчас загружены и используются. Оказалось их два: приведенный выше драйвер и нативный драйвер VMware:
Как видим, он затем вывел список системных модулей и увидел, что нативный драйвер отключен. После того, как он перезагрузил хост ESXi, все стало летать - гостевая ОС установилась за 5 минут, а тесты внутри ВМ показали высокую скорость чтения-записи.
HyperConverged Appliance - это собственная гиперконвергентная платформа StarWind для организации хранилищ, которая может быть использована самыми различными способами в инфраструктурах на базе различных гипервизоров. Больше об этом решении можно узнать тут и тут.
Посмотрите запись вебинара, чтобы узнать, как этот программно-аппаратный комплекс на базе GRID-архитектуры позволит вам с максимальной эффективностью размещать виртуальные машины любых гипервизоров и управлять инфраструктурой хранения из единой точки.
Как некоторые знают, в VMware vSphere 6.5 появилась (а точнее вернулась снова) возможность Automatic VMFS UNMAP - возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически. Работает UNMAP только для "тонких" (Thin Provisioned) LUN, на которых размещаются тома VMFS.
Из GUI vSphere Web Client можно управлять только UNMAP'ом для томов VMFS 6, для пятой версии файловой системы это нужно делать вручную с помощью ESXCLI. Кроме того, механизм UNMAP работает в асинхронном режиме, а иногда хочется почистить хранилища от неиспользуемых блоков прямо сейчас.
Поэтому весьма кстати, что на сайте EnterpriseDaddy обнаружился полезный PowerCLI-скрипт, который возвращает дисковое пространство в LUN для заданного хранилища хоста ESXi.
Эта функция принимает на вход имя хоста ESXi и Datastore, а также отключает таймаут на исполнение операций, так как возврат дискового пространства LUN может занять часы.
Function Perform-VMFSUnmap {
[CmdletBinding()]
param(
[Parameter(
Mandatory=$true)]
[String[]]$Datastore,
[String]$ESXiHost
)
Set-PowerCLIConfiguration -WebOperationTimeoutSeconds -1 -Scope Session -Confirm:$false
$ESXHost = Get-VMHost $ESXiHost
$DatastoreName = Get-Datastore $Datastore
Write-Host 'Using ESXCLI and connecting to $VMHost' -ForegroundColor Green
$esxcli = Get-EsxCli -VMHost $ESXHost
Write-Host 'Unmapping $Datastore on $VMHost' -ForegroundColor Green
$esxcli.storage.vmfs.unmap($null,$DatastoreName,$null)
}
Гостевой пост компании ИТ-ГРАД. Этой статьей мы продолжим традиционную рубрику в стиле unboxing и уделим внимание системе хранения данных нового поколения в лице NetApp AFF A300, презентованной в конце сентября прошлого года во время ежегодной конференции для партнеров и заказчиков NetApp Insight. Пришедшая на смену AFF8040 и AFF8060 новая all-flash-система успела порадовать техническими характеристиками и успешно разместилась на облачной площадке «ИТ-ГРАД»...
Многие пользователи применяют платформу XenServer ввиду ее бесплатности и легковесности, но сталкиваются с проблемами обеспечения высокой доступности хранилищ на случай сбоев оборудования. В этой сфере могут помочь программные решения StarWind Virtual SAN, которые позволяют организовать HA-хранилище с синхронизацией данных на нескольких узлах и высокоскоростной доступ на базе протокола iSCSI.
В документе описана HA-конфигурация серверов - вам потребуется как минимум 2 сервера с XenServer/XenCenter для запуска виртуальных машин и 2 сервера для организации кластера хранилищ StarWind HA, они могут быть физическими или виртуальными. То есть, всего нужно будет 2-4 физических сервера.
Также в документе рассмотрена пошаговая конфигурация узлов StarWind и настройка сетевого взаимодействия в консоли XenCenter для организации канала синхронизации между узлами хранилищ. Кроме того, вы узнаете, как настроить iSCSI Initiator в XenServer и механизм доступа по нескольким путям (Multipathing).
Таги: StarWind, iSCSI, XenServer, Storage, Virtual SAN
На сайте проекта VMware Labs появилась действительно достойная внимания утилита - IOInsight, доступная в виде готового к развертыванию виртуального модуля на платформе vSphere. Она позволяет детально взглянуть на характеристики взаимодействия виртуальных машин с хранилищами и провести анализ метрик ввода-вывода на уровне отдельных VMDK-дисков.
Все это позволит принимать решения о тюнинге производительности и планировании емкостей по пропускной способности на основе данных, выводимых в графиках и отчетах:
В решении каких проблем может помочь IOInsight:
Самостоятельная оптимизация производительности и планирование хранилищ пользователями vSphere.
Отчет из IOInsight может помочь при обращении в техподдержку VMware, что ускорит решение проблемы.
Сотрудники VMware Engineering могут подсказать решения по оптимизации ваших продуктов.
IOInsight собирает все метрики с хостов ESXi по вводу-выводу и представляет их в агрегированном виде для анализа. При этом в отчете IOInsight нет никакой чувствительной информации о приложениях и системах, так что можно смело отдавать его сотрудникам VMware.
Кроме того, предполагается, что администраторы и разработчики сами будут писать плагины к IOInsight, поскольку в состав решения включены SDK и development guide (как видите на картинке, два плагина уже есть). Руководство для обычных пользователей доступно вот тут.
Лучшие практики по использованию IOInsight:
2-4 виртуальных процессора на виртуальный модуль (vCPU)
2 ГБ и более оперативной памяти
Желательно разместить IOInsight в той же сети, что и хосты, которые планируется мониторить
Нужно выбирать не более 8 VMDK, чтобы не было слишком высокой нагрузки
Рекомендуемый период анализа данных - 10-30 минут
Cache Simulation analyzer создает нагрузку на процессор, поэтому его нужно запускать для 1 или 2 симулируемых конфигураций кэша (не более)
Утилита IOInsight работает, начиная с версии VMware vSphere 5.5, а скачать ее можно по этой ссылке.
В январе компания StarWind проводила вебинар о виртуальном модуле StarWind VSA на базе Linux, который позволит вам создавать программные хранилища iSCSI/NFS для ваших виртуальных машин.
Сейчас стала доступна запись этого вебинара, где Богдан рассказывает о том, для чего предназначен StarWind VSA и наглядно в консоли показывает, каким образом с ним нужно работать:
Ожидается, что продукт StarWind VSA for Linux будет доступен в течение пары месяцев.
Вебинар пройдет 9 февраля в 19-00 по московскому времени.
Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
Помимо этого, LSFS имеет следующие полезные функции:
Встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут).
Поддержка непрерывной дефрагментации (она идет в фоне).
Дедупликация данных "на лету" (то есть, перед записью на диск).
Улучшения производительности за счет комбинирования операций записи.
Поддержка overprovisioning.
Использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов.
В новом билде StarWind Virtual SAN у LSFS появилось несколько новых экспериментальных возможностей, которые позволят вам получить больше от этой технологии:
Передача операций по работе с метаданными на SSD (что снижает требования к RAM).
Оптимизация производительности операций чтения и записи, что сокращает время на них до 4-5 раз.
Напомним, что у компании StarWind есть аппаратно-программные решения для создания готовых к эксплуатации кластеров хранилищ под виртуальные машины - StarWind Storage Appliance. Также есть и чисто программное решение - StarWind Virtual Storage Appliance (VSA), который представляет собой готовый виртуальный модуль с сервисами хранилищ.
Ну а обо всем, что касается StarWind Storage Appliance, можно узнать на специальном сайте - https://www.starwindstorageappliance.com/, где собрано множество различных материалов об этих модулях.
На сайте вы узнаете, как из дорогой инфраструктуры слева получить значительно менее затратную инфраструктуру справа, повысив ее гибкость и не потеряв в производительности:
Компания StarWind выпускает новый продукт - виртуальный модуль для создания программных хранилищ на базе ОС Linux (StarWind Virtual Storage Appliance, VSA), который будет работать на любом гипервизоре в виде готовой к использованию виртуальной машины.
Вебинар пройдет в этот четверг, 19 января в 17-00 по московскому времени. Обратите внимание, что у StarWind новый спикер - Алекс Быковский (вопросы можно задавать на русском языке).
К сожалению, нету «прямого» пути для миграции шаблонов (VM Templates) с одного датастора на другой (т.н. процедура Storage VMotion). Представляю вашему вниманию функцию Move-Template2Datastore из моего PowerCLI Vi-Module модуля. Функция принимает объект(ы) Template и один объект датастора и производит 3 действия...
Компания VMware сделала доступным весьма полезный ресурс StorageHub, который будет интересен всем тем, кто хочет узнать все об использовании виртуальных и физических хранилищ под виртуальные машины на базе платформы VMware vSphere. Также на StorageHub есть документы и об инструментах обеспечивающих доступность виртуальных сервисов (например, VMware Site Recovery Manager):
Недавно компания VMware выпустила новую версию платформы vSphere 6.5, о новых возможностях которой мы писали вот тут. Между тем, в плане хранилищ было сделано несколько важных улучшений, которые заслуживают отдельного поста. Большинство из этого реализуемо только на базе файловой системы VMFS 6.0, которая также появилась в vSphere 6.5.
1. Возврат дискового пространства хранилищу (Storage UNMAP).
Эта возможность была еще в VMware ESXi 5.0, но пропала по некоторым техническим причинам в следующих версиях. Теперь она полноценно была реализована в двух вариантах:
Automatic UNMAP
Поддержка Linux-based In-Guest UNMAP
Automatic UNMAP - это возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически.
Для работы этой возможности вам понадобятся:
ESXi 6.5+
vCenter 6.5+
VMFS 6
Дисковый массив с поддержкой UNMAP
Если мы в настройках хранилища откроем вкладку Configure:
И далее нажмем Edit в разделе Space Reclamation Priority, то мы увидим вот такую настройку:
Здесь устанавливается приоритет, в соответствии с которым свободные блоки будут автоматически возвращены к LUN. Надо понимать, что UNMAP - это асинхронный процесс, который выполняет специальный crawler, потому и задается его приоритет. Понятное дело, что если задать высокий приоритет, то создастся дополнительная нагрузка на хранилища.
Кстати, для немедленного возврата дискового пространства можно воспользоваться командой esxcli storage vmfs unmap.
Поддержка Linux-based In-Guest UNMAP в vSphere 6.5 появилась впервые. Для ее работы нужна поддержка со стороны гостевой ОС Linux и ее файловой системы. Ну и работает это все только для тонких (thin) дисков.
Работает она не полностью автоматически, а запустить ее можно тремя способами:
Смонтировать файловую систему с опцией discard. Это будет возвращать простраство автоматически, когда будут удаляться файлы.
Выполнение команды sg_unmap. Это запустит механизм UNMAP для выбранных LBA.
Выполнение fstrim. Это вызовет команды trim, которые ESXi конвертирует в операции механизма UNMAP на уровне слоя vSCSI.
2. Функция Thin Hot Extend.
Это очень полезная штука была несколько ранее - она позволяла на горячую увеличить размер тонкого диска.
Вся загвоздка была в том, что диск можно было увеличить только до 2 ТБ, иначе возникала вот такая ошибка:
Теперь же можно задавать виртуальный диск любого размера.
3. Поддержка 4K-дисков в режиме 512e.
Теперь расширенный формат дисковых устройств 4K поддерживается со стороны vSphere 6.5, однако в режиме эмуляции 512e (то есть для 4к-девайсов эмулируются 512-байтные сектора). Такая же поддержка есть и в VMware Virtual SAN 6.5.
Полная поддержка 4k-устройств в нативном режиме ожидается в ближайшем будущем.
4. Поддержка до 512 устройств и 2000 путей.
Ранее платформа vSphere поддерживала 256 устройств и 1024 пути к одному хранилищу. И некоторые умудрялись упираться в лимиты, поэтому для таких клиентов и было сделано увеличение максимумов.
5. Увеличение лимита CBRC (он же View Storage Accelerator).
Про механизм кэширования Content Based Read Cache (CBRC) мы писали вот тут. Он позволяет увеличить производительность операций чтения для наиболее часто читаемых блоков виртуальных ПК за счет кэширования в оперативной памяти хоста VMware ESXi.
Ранее он был ограничен объемом в 2 ГБ, а теперь увеличился до 32 ГБ:
Теперь в vSphere 6.5 есть механизм для переподписки так называемых unresolved volumes, то есть томов, которые отвязались от основного по каким-то причинам, и теперь их метаданные являются не соответствующими текущей структуре файловой системы. Так, например, бывает в процессе резервного копирования, когда остается какой-нибудь повисший на диске снапшот, который не видно из GUI клиента vSphere.
В этом плане была проделана существенная работа и сделано множество улучшений, о которых можно прочитать тут.
Это основные, но не все улучшения VMware vSphere 6.5 в плане хранилищ, а если хочется узнать обо всех, то почитайте документ "vSphere 6.5 Storage", где очень много всего интересного.
В этом документе описывается подход компании StarWind к работе с кэшем уровня L1 (RAM buffer) и L2 (SSD-кэш), а также подробно раскрываются методики кэширования Write-Back и Write-Through, о которых мы также писали ранее.
Кэширование StarWind для уровней L1 и L2 основывается на одном механизме, поэтому множество вещей из документа вполне применимы к обоим уровням кэширования. Данные из кэша, кстати, удаляются в соответствии с политикой LRU (least recently used), то есть наименее используемые данные стираются из кэша первыми.
Остальные интересные технические вещи о кэшировании StarWind (которых немало) читайте в документе.
Как мы уже писали, в новой версии VMware vSphere 6.5 компания VMware существенно улучшила функции виртуального модуля VMware vCenter Server Appliance (vCSA). В частности, в него был добавлен VMware Update Manager (VUM), который по традиции также идет отдельным разделом и диском VMDK, как и остальные сервисы. Расскажем ниже об увеличении раздела диска vCSA, которое описано в статье Вильяма Лама.
Давайте взглянем на таблицу разделов vCSA 6.5, каждому из которых соответствует диск VMDK, в сравнении с vSphere 6.0:
Disk
6.0 Size
6.5 Size
Назначение
Mount Point
VMDK1
12GB
12GB
/ and Boot
/ and Boot
VMDK2
1.2GB
1.8GB
Temp Mount
/tmp
VMDK3
25GB
25GB
Swap
SWAP
VMDK4
25GB
25GB
Core
/storage/core
VMDK5
10GB
10GB
Log
/storage/log
VMDK6
10GB
10GB
DB
/storage/db
VMDK7
5GB
15GB
DBLog
/storage/dblog
VMDK8
10GB
10GB
SEAT (Stats Events and Tasks)
/storage/seat
VMDK9
1GB
1GB
Net Dumper
/storage/netdump
VMDK10
10GB
10GB
Auto Deploy
/storage/autodeploy
VMDK11
N/A (Previously InvSrvc 5GB)
10GB
Image Builder
/storage/imagebuilder
VMDK12
N/A
100GB
Update Manager
/storage/updatemgr
Как мы видим, кое-где изменились размеры стандартных разделов, для Image Builder поменялась точка монтирования, а также добавился отдельный раздел VUM на 100 гигабайт, которого не было раньше.
Размер каждого из разделов можно менять на горячую в настройках ВМ, ну а потом нужно из гостевой ОС vCSA расширить раздел на образовавшееся свободное пространство диска. Вот какие изменения произошли в версии vSphere 6.5 на эту тему:
Теперь вместо команды vpxd_servicecfg для расширения логического тома нужно использовать следующий скрипт: /usr/lib/applmgmt/support/scripts/autogrow.sh
Посмотрим на расширение раздела с Net Dumper (VMDK9) с помощью нового VAMI API.
Выполним команду df -h, чтобы вывести таблицу разделов на vCSA:
Теперь в vSphere Client идем в настройки виртуальной машины vCSA и переходим в раздел управления дисками, где увеличиваем размер девятого виртуального диска с 1 ГБ до 5 ГБ:
Затем идем в браузере по адресу https://[VCSA-HOSTNAME]/apiexplorer, где выбираем пункт "appliance" в разделе Select API и нажимаем кнопку Login, после чего вводим логин/пароль от vCenter Server:
Скроллим до операции POST /appliance/system/storage/resize и раскрываем ее, чтобы увидеть детали:
Теперь нажимаем кнопку "Try it out!" и, в случае успешного выполнения, код ответа (Response Code) будет 200. Также эту же операцию можно выполнить и через PowerCLI:
Компания StarWind, производящая лучший продукт Virtual SAN, предназначенный для создания отказоустойчивых iSCSI-хранилищ под виртуализацию, выпустила интересный документ, который будет полезен всем администраторам платформы Hyper-V - "VHD Set in MS Windows Server 2016".
Как некоторые из вас знают, в Windows Server 2016 появился новый тип виртуального диска VHD set, который предназначен для организации общего доступа к диску со стороны нескольких виртуальных машин (для баз данных SQL Server, файловых серверов и прочего):
На самом деле, это не новый диск, а улучшенный диск типа Shared VHDX, который получил новые возможности, но сохранил ту же самую логику и архитектуру. Вот что нового появилось в VHD set:
Возможность бэкапа и репликации VHD set на уровне хоста
Изменения размера диска VHD Set на лету, без остановки виртуальной машины
Возможность горячей миграции
Создание снапшотов такого диска
Этот диск состоит из двух основных файлов:
vhds - конфигурационный файл, который содержит метаданные
avhdx ("automatic .vhdx") - данные виртуального диска, он может быть fixed
или dynamic
Как мы недавно писали, в новой версии платформы виртуализации VMware vSphere 6.5 появившийся очень давно механизм VMware Storage IO Control (SIOC) теперь работает посредством политик хранилищ (Storage Policies) на базе интерфейса vSphere APIs for IO Filtering (VAIO). О том, как раньше работал SIOC на практическом примере мы уже писали вот тут. А тут мы упоминали о Storage Policy Based Management (SPBM).
Давайте теперь посмотрим, как все это взаимодействует вместе. Во-первых, надо сказать, что Storage IO Control начинает работать, когда на хосте ощущается недостаток ресурсов хранилища (пропускной способности) и виртуальные машины начинают конкурировать между собой. По умолчанию этот механизм выключен, поэтому машины разбираются между собой на общих основаниях.
Давайте включим SIOC для отдельного хранилища. Для этого в vSphere Client нажмем на него правой кнопкой и выберем "Configure SIOC":
Тут мы видим, что есть некоторый Congestion Threshold - это зачение в процентах загруженности хранилища (по пропускной способности) или по Latency (задается вручную), при превышении которого будет включен механизм борьбы за ресурсы SIOC. Также важна галка "Exclude I/O statistics from SDRS" - это Network-Aware DRS, то есть теперь механизм балансировки нагрузки по хранилищам SDRS по умолчанию не перемещает машины на загруженные в плане сети хосты (это можно отключить при желании).
Далее посмотрим на политики хранилищ. Для этого пойдем в раздел VM Storage Policy и далее в Storage Policy Components, где посмотрим параметры дефолтной политики "Normal":
Вот тут-то мы и видим параметры VMware SIOC, которые можно регулировать для данной политики, которая впоследствии будет применена к виртуальной машине или ее отдельным виртуальным дискам. Все то же самое - резервация и лимиты по IOPS, а также shares - то есть доли, которые будут иметь от общего объема shares объекты данной политики.
При создании новой политики хранения можно задать предопределенный набор Reservation, Limit и Shares в качестве компонента Datastore IO Control:
Также в политики хранения можно в качестве правил (rules) задавать определенные сервисы предоставляемые хостом (это понятие Line of Service) - например, шифрование дисков, кэширование, репликация и прочее. Все это доступно для редактирования при задании правил в рамках новой политики хранения (VM Storage Policy):
Ну а для назначения политики надо использовать пункт VM Policies в контекстном меню виртуальной машины, далее выбрать пункт Edit VM Storage Policies:
И далее назначаем стандартную или кастомную политику хранения для всех объектов виртуальной машины (Apply to all) или для отдельных виртуальных дисков (по умолчанию стоит политика, назначенная для всего датастора):
Таким образом, теперь SIOC и SPBM интегрированы в рамках единого рабочего процесса и удобны в использовании при управлении классами обслуживания в плане хранилищ для виртуальных машин и отдельных дисков VMDK.
Технологии NVMe и 3DXpoint flash являются будущим технологий хранения с самой высокой пропускной способностью. Эти технологии будут легко справляться с самыми I/O-интенсивными нагрузками приложений, такими как обработка транзакций OLTP, анализ данных в режиме реального времени, а также, в более широком масштабе - обработкой больших объемов данных.
В современных All-Flash-датацентрах существующие протоколы хранения серьезно устарели и создают узкие места. Эта проблема решается с помощью недавно разработанных передовых протоколов, таких как NVMe-over-fabrics (NVMf), iSER или SMB Direct. Они используют RDMA для улучшения производительности по сравнению с существующими протоколами, такими как NFS и iSCSI.
Регистрируйтесь на вебинар StarWind и Kazan Networks, чтобы узнать, как можно реализовать хранилище NVMe уже сегодня с NVMf-таргетами от Kazan Networks и инициаторами NVMf от компании StarWind.
Как-то один из наших читателей спросил, как можно узнать, какие из хостов VMware ESXi в кластере используют данное виртуальное хранилище (датастор)? Ведь использовать они его могут не только для хранения виртуальных машин, исполняемых на нем, но и для хартбитов - то есть сигналов доступности VMware HA, передаваемых через лок-файлы на этих датасторах.
Для этой цели можно использовать утилиту vSphere On-disk Metadata Analyzer (VOMA), которая умеет проверять консистентность метаданных тома VMFS, а также покажет вам информацию о том, какие хосты ESXi его используют.
Для начала нужно узнать имя датастора в формате определения устройства. Посмотрим список имен устройств через esxcli:
esxcli storage vmfs extent list
Мы увидим вот такую картину:
В колонке Device name мы видим имя устройства - eui.5adcee56739fb3ea:1. Теперь с помощью VOMA проведем проверку этого девайса и выведем метаданные этого тома VMFS:
Если том не в порядке, то будет выведено вот такое сообщение:
Error: Missing LVM Magic. Disk doesn’t have a valid LVM Device Error: Failed to Initialize LVM Metadata
Ну а если все окей, то вот что мы получим:
Тут мы видим, что устройство (том VMFS/датастор) используется одним хостом с соответствующим MAC-адресом. Дальше уже дело техники найти этот хост ESXi.
Если вы хотите вывести результаты работы данной команды VOMA в файл, то можно использовать ключ -s:
Продолжаем серию заметок об анонсах прошедшего VMworld Europe 2016, где компания VMware рассказала о ближайших обновлениях своей продуктовой линейки. Напомним основные из них:
Как многие из вас знают, у VMware есть технология Virtual Volumes (VVols), которая позволяет более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.
По сути, Virtual Volumes - это новый способ организации хранилищ в виде удобном для массива, когда используется не традиционная файловая система VMFS, а массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин, выделяя для их объектов (виртуальные диски и прочее) отдельные логические тома (VVols).
Между тем, многие администраторы крупных инфраструктур не спешили использовать VVols, так как эта технология, несмотря на ее поддержку некоторыми дисковыми массивами, не позволяла реализовать некоторые возможности, например, репликацию на уровне дискового массива.
Ну и, соответственно, анонсированные возможности новой версии VVols 2.0:
1. Поддержка репликации на уровне дискового массива.
Ранее для томов VMFS в целях обеспечения отказо- и катастрофоустойчивости, а также достижения нулевого RPO, менеджеры датацентров применяли технологию репликации на уровне СХД (Array-based replication, ABR). Для виртуальных машин на базе VVols 2.0 эта технология становится лучше - теперь можно реплицировать не весь том VMFS целиком, а отдельную виртуальную машину (и даже отдельные виртуальные диски). Также несколько ВМ можно реплицировать в рамках одной Replication Group.
Эта группа виртуальных машин может быть объединена, например, по признаку принадлежности единому сервису, а не по признаку "машины лежат на одном томе", как это было с хранилищами VMFS.
Вот как это работает:
Технология репликации конкретного вендора коммуницирует с vSphere посредством механизма VASA (vSphere APIs for Storage Awareness).
Администраторы виртуальной инфраструктуры создают политики хранилищ ВМ, содержащие желаемые требования к репликации, которые должны обеспечиваться системой хранения.
Когда машина развертывается, администратор:
Выбирает политику хранилищ, для которой доступна репликация
Выбирает совместимый датастор
Задает Replication Group, в которую нужно поместить ВМ
Завершает процедуру развертывания.
Replication Group, которую задает пользователь, позволяет добавить несколько ВМ в единую группу доступности. Эти группы обслуживаются со стороны компонента VASA Provider (он содержит в себе структуру томов VVols и реализован на уровне дискового массива или отдельной ВМ).
Интересно, что одна Replication Group поддерживает несколько целевых хранилищ. Одну и ту же группу можно реплицировать, например, сразу в две географически разнесенных локации:
2. Автоматизация аварийного восстановления (Disaster Recovery).
VMware vSphere 6.5 предоставляет расширенный API и команды PowerCLI, которые позволяют обеспечить окрестрацию процесса аварийного восстановления. Вот какие рабочие процессы (Replication Workflows) поддерживаются этими средствами:
Replication Discovery – это средства, с помощью которых технология VVol disaster recovery обнаруживает текущие связи между двумя доменами.
Sync Replication Group - синхронизация между основной площадкой и резервными сайтами.
Test Failover – способ убедиться, что восстановленные сервисы на резервной площадке будут нормально работать после восстановления. После теста администратор может переместить тестируемые сервисы в продакшен.
Disaster Recovery and Planned Migration – для запланированной миграции сервисов с одной площадки на другую процесс синхронизации может быть инициирован с резервной площадки.
Setting up protection after a DR event – после восстановления сервисов на резервной площадке, администратор может запустить репликацию в обратном направлении, обеспечив защиту площадки, теперь ставшей основной.
3. Концепция Line of Service.
Спецификация интерфейса VASA 3.0 вводит понятие линии сервиса (Line of Service). Это группа связанных сущностей, таких как inspection, compression, encryption, replication, caching или persistence, выполняющих определенную задачу. Например, для сущности Replication можно создать и сконфигурировать линию сервиса и назначить ее некоторым политикам хранилищ (storage policies), которые уже будут назначаться виртуальным машинам. Это упростит настройку новых сервисов для больших инфраструктур.
4. Поддержка Virtual Volumes для Oracle RAC.
В дополнение к репликации на уровне дисковых массивов, технология VVols 2.0 будет полностью поддерживаться для кластеров Oracle RAC (как сейчас это поддерживается для томов VMFS). Это позволит защитить еще больше бизнес-критичных приложений.
Как и большинство других продуктов, анонсированных на VMworld Europe 2016, доступность технологии Virtual Volumes ожидается до конца этого года. А вот ее поддержка на уровне систем хранения - уже дело 2017 и более поздних лет.
На проходящей сейчас конференции VMworld Europe 2016 в Барселоне компания VMware анонсировала даже больше продуктов, чем на VMworld 2016 в Лас-Вегасе (там было больше про технологии). Напомним анонсы уже этого, европейского VMworld:
Ну а сейчас мы расскажем про обновление средства для создания отказоустойчивых кластеров хранения VMware Virtual SAN 6.5. Напомним, что о прошлой версии Virtual SAN 6.2 мы писали здесь, а про VSAN 6.0 можно почитать вот тут.
Давайте посмотрим, что нового в VMware VSAN 6.5:
1. Обновленные Virtual SAN API и vSphere PowerCLI.
Теперь интерфейсы доступа из командной строки и внешних систем были существенно обновлены и доработаны. Стало возможным автоматизировать конфигурацию и управление настройками кластера, дисковых групп, доменов отказа (fault domains) и растянутых кластеров. Также можно управлять различными активностями, такими как режим обслуживания и выключение кластера. Более подробно можно все это увидеть вот в этом видео:
Также через PowerCLI можно отслеживать состояние кластера Virtual SAN.
2. Поддержка двухузловой конфигурации через кросс-кабели.
Ранее кластер Virtual SAN можно было собрать только из трех или более узлов, что препятствовало внедрению технологии в небольших компаниях и филиалах. Теперь же можно создать двухузловую конфигурацию, где хосты соединены между собой кросс-кабелями (без коммутаторов) и там развертывать и виртуальную инфраструктуру, и хранилища виртуальных машин.
Также важно отметить, что теперь лицензирование Virtual SAN for ROBO поддерживает All-Flash конфигурации. Лицензия называется Virtual SAN for ROBO Advanced и позволяет использовать компрессию, дедупликацию и защиту от ошибок (erasure coding).
3. Увеличенная гибкость Virtual SAN 6.5.
Теперь таргеты Virtual SAN можно использовать для физических серверов, что дает решению намного больше гибкости в плане хранения данных предприятия. Функциональность iSCSI targets для Virtual SAN управляется таким же образом, как и виртуальные объекты через механизм Storage Policy Based Management (SPBM).
Также поддерживаются дедупликация, компрессия, мирроринг и erasure coding. Для аутентификации используется CHAP и Mutual CHAP.
4. Поддержка контейнеров.
Средствами механизма vSphere Integrated Containers Engine технология Virtual SAN 6.5 поддерживает контейнеры Docker и другие. Специальный драйвер Docker Volume Driver для vSphere позволяет управлять данными контейнеров, которые размещены на хранилищах VMFS, NFS и Virtual SAN.
Кроме того, в рамках данной новой функции предоставляется API для развертывания контейнеров на хранилищах Virtual SAN, а также средства перемещения виртуальных машин с контейнерами между хостами без перемещения их данных.
5. Поддержка нового аппаратного обеспечения.
Вместе с VMware vSphere 6.5 средства Virtual SAN 6.5 поддерживают новое аппаратное обеспечение, такое как диски 512e очень большой емкости, а также протоколы доступа к SSD-накопителям по шине PCIe - NVMe. Это на идеальных тестах дает до 150 тысяч IOPS на один хост. Также теперь полноценно поддерживается большой спектр хранилищ All-Flash.
Обновленная версия решения VMware Virtual SAN 6.5 будет доступна для загрузки до конца 2016 года.
Вебинар пройдет 20 октября в 21-00 по московскому времени.
На вебинаре сотрудники компании расскажут о том, как решения StarWind работают с технологией VMware Virtual Volumes (VVOLs). Также будет живое демо работы продукта Virtual SAN.
В этом вебинаре было рассказано поддержке iSER (iSCSI Extensions for RDMA) - расширении модели транспорта iSCSI с RDMA. iSER работает в разы быстрее, чем iSCSI и весьма прост в управлении. В рамках набора протоколов RDMA, эта технология обеспечивает более высокую пропускную способность при передаче для блочных хранилищ.
На днях стала доступной видеозапись этого вебинара:
Посмотрите - всего 15 минут интересной информации об iSER. Не каждый день такое рассказывают.
В блоге CTO компании StarWind Антона Коломейцева есть интересный тест файловой системы ReFS, которая появилась в серверной ОС Windows Server 2016. В статье "ReFS: Performance" Антон детально рассматривает различные аспекты производительности ReFS, а также подробно описывает конфигурацию среды тестирования и сам процесс его проведения.
Интересен вывод о том, что ReFS с включенной фичей FileIntegrity работает как файловая система Log-Structured File System (LSFS), что очень хорошо для виртуальных машин, так как мелкие команды ввода-вывода объединяются в большие пачки, что позволяет избежать эффекта I/O-блендера.
StarWind традиционно поддерживает все новейшие технологии и протоколы работы с хранилищами, а в этом вебинаре будет рассказано о поддержке iSER (iSCSI Extensions for RDMA) - расширении модели транспорта iSCSI с RDMA.
Вебинар пройдет 15 сентября в 22-00 по московскому времени.
iSER работает в разы быстрее, чем iSCSI и весьма прост в управлении. В рамках набора протоколов RDMA, эта технология обеспечивает более высокую пропускную способность при передаче для блочных хранилищ. Он имеет самую низкую задержку и низкую загрузку процессора. Кроме того, эта технология на сегодняшний день стабильна и сохраняет все основные преимущества протокола iSCSI, такие как безопасность и высокая доступность.
Регистрируйтесь на вебинар, чтобы узнать о работе iSER в решении StarWind Virtual SAN.