Datastore vmware что это
Обновлено: 04.07.2024
Представляю вашему вниманию заключительную публикацию о технологиях хранения VMware vSphere 6. В ней будет рассмотрена технология VVOL.
Описание технологии VVOL
Во всех редакциях VMware до vSphere 6 ВМ (виртуальные машины) хранились в виде файлов в файловой системе. В случае массива с блочным доступом использовалась собственная файловая система VMware – VMFS, для файловых хранилищ использовались NFS. Емкость массива делилась на LUNы или NFS-шары и презентовалась (монтировалась к) хостам ESXi в виде датастор (datastore). Датасторы, как правило, имеют большой объем (от 1 ТБ) и размещают на себе множество ВМ (5-10 и более). В первую очередь это связано с тем, что выделение отдельной datastore под каждую ВМ слишком неудобно и трудозатратно в плане администрирования.
При таком подходе гранулярность операций сопровождения хранилища ВМ силами массива находится на уровне datastore (LUN или NFS-шара целиком), а не на уровне отдельных ВМ. Имеются в виду такие операции, как снапшоты, репликация, дедупликация, шифрование, QoS. Они выполняются на уровне СХД, а не средствами гипервизора, что позволяет осуществлять их быстрее, при этом разгружая вычислительные ресурсы хостов и сеть передачи данных. В первую очередь это касается блочного доступа с VMFS, некоторые модели файловых массивов (например, NetApp) дают гранулярность на уровне отдельных ВМ – например, СХД позволяет сделать снапшот отдельной ВМ, а не datastore целиком.
Описанная выше традиционная технология хранения ВМ в vSphere 6 по прежнему поддерживается, но в дополнение к ней была разработана концепция Virtual Volumes (VVOL), предполагающая объектное хранение ВМ на массивах, поддерживающих данную технологию, независимо от их типа (блочные или файловые).
VVOL – это объект, содержащий файлы ВМ, виртуальные диски и их производные. СХД с поддержкой VVOL получает возможность непосредственной работы с данными объектами за счет собственных аппаратных ресурсов. Как правило, каждый VVOL имеет уникальный GUID для идентификации. Нет необходимости заранее выделять пространство под VVOL, они создаются автоматом при выполнении операций с ВМ: создание, клонирование, снапшотинг.
vSphere (хосты ESXi и vCenter) ассоциирует с ВМ один или несколько VVOL:
• VVOL данных, соответствующий файлу виртуального диска (.vmdk);
• VVOL конфигурации — небольшая домашняя директория, содержащая метаданные ВМ (включая файл .vmx, файлы дескрипторы виртуальных дисков, log-файлы и т.п.). Данный тип VVOL форматируется в VMFS или NFS, в зависимости от типа СХД (блочная или файловая).
• Дополнительные VVOL могут создаваться для остальных компонент ВМ (например, VVOL для swap-файла или файла ОЗУ ВМ для снапшота) или производных виртуальных дисков (клоны, реплики, снапшоты).
Благодаря VVOL мы получаем гранулярность управления хранилищем на уровне отдельных ВМ и можем напрямую задействовать для этого ресурсы СХД. VVOL позволяют использовать гибкие возможности управления хранилищем на основе политик SPBM. Деление данных ВМ на VVOL нескольких типов позволяет размещать их на хранилища с разным уровнем сервиса: VVOL данных на производительный tier с высоким уровнем сервиса, VVOL с конфигурацией или второстепенным диском ВМ на более простые tier.
Для хранения VVOL не нужны классические LUNы или NFS-шары. VVOL хранятся на условно «сыром» пространстве СХД в объектах, называемых storage container. Storage container-ы это логические единицы пространства массива, их количество и ёмкость определяются конкретной СХД и инфраструктурой. Как минимум 1 storage container должен быть создан на СХД, нельзя растягивать 1 storage container на несколько физических массивов.
Storage container-ы логически группируют VVOL из соображений администрирования или управления: можно создавать отдельные storage container-ы для разных заказчиков, департаментов или групп ВМ. Один storage container может включать несколько профилей сервиса, таким образом, на одном и том же storage container могут размещаться ВМ с разными требованиями к обслуживанию и политиками хранения.
Для интеграции СХД с vSphere, для того, чтобы vCenter и гипервизоры могли работать с VVOL и подключиться к storage container необходимо развертывание и регистрация на vCenter специального storage provider-а на базе VASA (VMware APIs for Storage Awareness) для VVOL, который должен разрабатываться и предоставляться производителем СХД.
Для доступа хостов ESXi к VVOL используются логические прокси ввода-вывода, называемы protocol endpoints. ESXi использует protocol endpoints для установления data-path по требованию между ВМ и её VVOL. Каждый VVOL подключен к определенному protocol endpoints. Как правило, СХД требует небольшое количество protocol endpoints, поскольку 1 protocol endpoints может обслуживать множество ВМ (сотни и тысячи).
VVOL поддерживают основные протоколы СХД: Fibre Channel, FCoE, iSCSI, и NFS, аналогично традиционном хранилищам vSphere.
Для поддержки VVOL необходимо использование HBA-адаптеров и версий драйверов для них, адаптированных к работе с (поддерживающих) VVOL.
На стороне СХД происходит конфигурирование protocol endpoints – по одному или несколько на storage container. Protocol endpoints являются частью СХД и предоставляются хостам вместе с ассоциированными storage container-ами через storage provider. vSphere Web Client отображает protocol endpoints, подключенные к инфраструктуре, через T10-based LUN WWN для блочных массивов и IP/DNS для файловых. Protocol endpoints поддерживают мультипафинг только для SCSI-вариантов подключений (для NFS не поддерживается).
Storage container-ы подключаются к инфраструктуре в виде virtual datastore, эти сущности являются их прямым отображением в vSphere Web Client. Virtual datastore аналогичны обычным datastore vSphere, могут отображать VVOL по именам ВМ, их можно монтировать и размонтировать. Однако их конфигурирование, в т.ч. изменение размера осуществляется на уровне СХД за пределами vSphere. Virtual datastore могут использоваться совместно с обычными VMFS и NFS datastore, а также с Virtual SAN.
Размещение ВМ на virtual datastore (с использованием VVOL) требует наличия политик хранения (SPBM). Политика хранения ВМ (VM storage policy) содержит наборы правил по размещению и качеству сервиса для ВМ и гарантирует их выполнение. При отсутствии конкретных политик система будет использовать политику по умолчанию без ограничений, в этом случае массив самостоятельно выберет оптимальное размещение ВМ на свое усмотрение.
Преимущества и недостатки VVOL
Важными преимуществами технологии являются поддержка создания снапшотов и клонов отдельных ВМ на уровне и за счет ресурсов СХД, а также обеспечение таких сервисов как репликация, шифрование, дедупликация и сжатие отдельных виртуальных дисков. Отдельно следует отметить поддержку SPBM, которая открывает большой потенциал управления хранением ВМ на основе политик.
Продукты VMware поддерживающие VVOL:
• VMware vSphere 6.0.x
• VMware vRealize Automation 6.2.x
• VMware Horizon 6.1.x
• VMware vSphere Replication 6.0.x
Продукты VMware НЕ поддерживающие VVOL:
• VMware vRealize Operations Manager 6.0.x to 6.1.0
• VMware Site Recovery Manager 5.x to 6.1.0
• VMware vSphere Data Protection 5.x to 6.1.0
• VMware vCloud Director 5
Технологии VMware поддерживающие VVOL:
• High Availability (HA)
• Linked Clones
• Native Snapshots
• NFS version 3.x
• Storage Policy Based Management (SPBM)
• Storage vMotion
• Thin Provisioning
• View Storage Accelerator/Content Based Read Cache (CBRC)
• Virtual SAN (VSAN)
• vSphere Auto Deploy
• vSphere Flash Read Cache
• vSphere Software Development Kit (SDK)
• vSphere API for I/O Filtering (VAIO)
• vMotion
• xvMotion
• VADP
Технологии VMware НЕ поддерживающие VVOL:
• Fault Tolerance (FT)
• IPv6
• Microsoft Failover Clustering
• NFS version 4.1
• Raw Device Mapping (RDM)
• SMP-FT
• Storage Distributed Resource Scheduler (SDRS)
• Storage I/O Control
Есть предположение, что VMware делает ставку на VVOL, их развитие, и в скором будущем технология станет совместима со всеми решениями вендора. Возможно, в перспективе VVOL станут основной технологией хранения VMware, которая приведет к постепенному уходу от устаревших традиционных хранилищ и прекращению их поддержки.
На момент публикации статьи из 200 (примерно) производителей систем хранения, продукты которых совместимых с vSphere (согласно VMware Compatibility Guide), лишь 18 поддерживают VVOL. Реальных отзывов о практическом использовании VVOL мне найти не удалось: ни в Интернетах, ни на форуме VMware VMUG (даже на буржуйском). Отсутствие совместимости VVOL c перечисленными выше технологиями на данном этапе заставит многих заказчиков отказаться от VVOL, поскольку несовместимая с VVOL технология или их набор зачастую могут оказаться важнее для многих инфраструктур.
Из этого можно сделать вывод, что теоретически технология VVOL очень интересная и полезная. Однако, на данном этапе её практичность и необходимость внедрения вызывают сомнения. Нужен положительный опыт применения в продакшене и нужна совместимость с другими важными фичами vSphere, пока этого нет.
Спасибо за внимание, на этом цикл статей по технологиям хранения vSphere 6 закончен. В следующей статье будут рассмотрены решения VMware для репликации и аварийного восстановления (DR): vSphere Replication и Site Recovery Manager (SRM).
Перед тем, как приступить к созданию разделов VMFS , следует уяснить один нюанс: VMFS хранилище может находится только на устройстве хранения SCSI.
Это может быть локальный SCSI диск (с или без RAID), или общее хранилище (shared storage), такое как SAN устройство (iSCSI или Fibre Channel) или же NFS.
Устройство хранения и сервер ESX должны быть настроены таким образом, чтобы хранилище было видно и доступно серверу ESX.
Предварительно рекомендую познакомится со статьями: основы настройки хранилищ iSCSI, а также iSCSI с аутентификацией CHAP.
Мы предполагаем, что эти настройки уже выполнены, поэтому мы можем продолжить.
4. Перед вами появится список еще не задействованных LUN. Выберите LUN, который вы планируете использовать как хранилище VMFS и нажмите Далее.
5. Еще раз познакомьтесь со свойствами диска, после чего нажмите кнопку Далее
6. Укажите имя создаваемого хранилища имя, это имя в дальнейшем будет использоваться вами для его идентификации. Нажмите Далее.
10. Это хранилище теперь видимо и доступно на вкладке «Storage» в разделе настроек сервера.
В этой статье мы опишем типы хранилищ данных, которые используются в VMware vSphere 7.0.
Файловая система виртуальной машины (VMFS)
Вы можете создавать хранилища данных VMFS на Fibre Channel, iSCSI, FCoE и локальных устройствах хранения. ESXi 7.0 поддерживает VMFS версий 5 и 6 для чтения и записи. ESXi 7.0 не поддерживает VMFS версии 3.
При работе с хранилищами данных VMFS в vSphere 7.0 учитывайте следующее:
Размер блока: Размер блока в хранилище данных VMFS определяет максимальный размер файла и объем пространства, занимаемого файлом. Хранилища данных VMFS версий 5 и 6 поддерживают размер блока 1 МБ.
Storage vMotion: Storage vMotion поддерживает миграцию между хранилищами данных VMFS, vSAN и vVols. vCenter Server выполняет проверку совместимости для подтверждения Storage vMotion между различными типами хранилищ данных.
Storage DRS: VMFS версии 5 и версии 6 могут сосуществовать в одном кластере хранилищ данных. Однако все хранилища данных в кластере должны использовать однородные устройства хранения. Не смешивайте устройства разных форматов в одном кластере хранилищ данных.
Форматы разделов устройств: Любое новое хранилище данных VMFS версии 5 или 6 использует таблицу разделов GUID (GPT) для форматирования устройства хранения, что означает возможность создания хранилищ данных размером более 2 ТБ. Если ваше хранилище данных VMFS версии 5 было ранее обновлено с VMFS версии 3, оно продолжает использовать формат разделов Master Boot Record (MBR), характерный для VMFS версии 3. Преобразование в GPT происходит только после расширения хранилища данных до размера более 2 ТБ.
Сетевая файловая система (NFS)
Клиент NFS, встроенный в ESXi, использует протокол Network File System (NFS) через TCP/IP для доступа к тому NFS, расположенному на сервере NAS.
Хост ESXi может смонтировать том и использовать его в качестве хранилища данных NFS.
Вы можете создавать хранилища данных NFS на устройствах NAS. ESXi 7.0 поддерживает NFS версий 3 и 4.1. Для поддержки обеих версий ESXi 7.0 использует два разных клиента NFS.
vSAN объединяет локальные или подключенные напрямую устройства хранения кластера хостов ESXi и создает единый пул хранения, общий для всех хостов в кластере vSAN.
В следующем разделе описаны концепции, преимущества и терминология, связанные с vSAN.
Виртуальные тома VMware vSphere (vVols)
Функциональность VMware vSphere Virtual Volumes (vVols) изменяет парадигму управления хранением данных: от управления пространством внутри хранилищ данных к управлению абстрактными объектами хранения, обрабатываемыми массивами хранения.
С vVols единицей управления хранением становится отдельная виртуальная машина, а не хранилище данных. А оборудование хранения получает полный контроль над содержимым виртуальных дисков, их расположением и управлением.
Вы можете создать хранилище данных vVols в среде с совместимой системой хранения.
Виртуальный том, созданный и управляемый вне группы провайдером vSphere APIs for Storage Awareness (VASA), представляет собой контейнер хранения в vSphere.
Провайдер VASA сопоставляет объекты виртуальных дисков и их производные, такие как клоны, моментальные снимки и реплики, непосредственно с виртуальными томами на системе хранения.
Хосты ESXi получают доступ к виртуальным томам через промежуточную точку в пути данных, называемую конечной точкой протокола.
Конечные точки протокола служат шлюзами для ввода-вывода между хостами ESXi и системой хранения данных, используя Fibre Channel, FCoE, iSCSI или NFS.
Заключение
В программно-определяемой модели хранения ВМ становится единицей предоставления хранилища и может управляться с помощью гибкого механизма на основе политик.
Сегодня мы разберем несколько простых способов получения доступа к данным, хранящимся на файловой системе VMFS хранилища (datastore) гипервизора ESXi (это файлы конфигурации, файлы с данными и снапшотами виртуальных машин). Статья, собственно, основана на реальной ситуации, возникшей у одного из клиентов, когда единственный продуктивный сервер с гипервизором VMware ESXi перестал загружаться.
В том случае, если не работает сам хост ESXi, но локальный диск (или диски) сервера остался работоспособными, вы всегда сможете скопировать файлы виртуальных машин (как диски с данными, так и конфигурационные файлы) с него и запустить ВМ на другом сервере (на VMware Workstation или даже Hyper-V). Основная проблема в том, что «классические» операционные системы (Windows и Linux) по умолчанию не видят раздел с файловой системой VMFS, т.к. в них отсутствует драйвер файловой системы VMFS. В этой статье мы рассмотрим, как получить доступ к файлам виртуальных машин на диске с файловой системой VMFS из разных ОС.
В моем случае проблема была в том, что резервное копирование виртуальных машин VMware настроено не было, как и не было времени на диагностику и решение проблем с загрузкой системы. Поэтому было принято решение вручную скопировать файлы критичной виртуальной машины с хранилища VMFS и запустить ее на другом компьютере на срочно поднятом для этих целей гипервизоре ESXi.
Разберем три сценария доступа к данным на файловой системе VMFS:
Монтирование VMFS раздела в Linux (Ubuntu)
В этой секции мы покажем, как смонтировать раздел с файловой системой VMFS на компьютере с установленной ОС Ubuntu (Live CD с Ubuntu в этом сценарии нам не подойдет).
В первую очередь необходимо подключить физический диск с файловой системой VMFS к компьютеру (серверу) с Ubuntu. Чтобы получить доступ к данным на VMFS томе, нам понадобиться установить специальный сторонний пакет vmfs-tools. Данный пакет позволяет получить доступ к файловой системе раздела VMFS из компьютеров под управлением Linux. Доступ к данным на таком разделе возможен в режиме только на чтение (read-only). Второе важное ограничение, разработчики vmfs-tools официально заявляли о поддержки версий файловой системе VMFS вплоть до VMFS 5.0. Возможность подключения раздела с VMFS 6 (vSphere 6.0 и 6.5.) не гарантируется.
Установим пакет следующей командой
Примечание. В репозитариях Ubuntu пока доступна только версия vmfs-tools 0.2.1, основной ее недостаток – она умеет работать только с файловой системой VMFS v4. Если вам нужно смонтировать датастор с VMFS 5, придется самостоятельно скачать и установить версию vmfs-tools не ниже 0.2.5, например, здесь:
Качаем соответствующую версию пакета так:
И устанавливаем его:
Если нужно будет удовлетворить зависимости, воспользуйтесь командой:
После установки пакета, нужно создать точку монтирования, в которую будет подключен VMFS раздел:
Следующий шаг – нужно разобраться с разделами на дисках. Гипервизор ESXi при установке помимо, собственно, раздела для файлов виртуальных машин (VMFS) создает множество служебных разделов. Если версия ESXi 4 или ниже, или VMFS хранилище было обновлено с версии VMFS 3 до VMFS 5, а его размер не превышает 2 Тб, выведем список дисков и разделов так:
Важно. Т.к. в ESXi 5 используется VMFS v5 с таблицей разделов GPT (таблица GUID Partition Table), которая используется вместо MBR, что позволяет создавать хранилища большего размера и пробрасывать RDM диски в режиме физической совместимости размером более 2 TB. Поэтому для просмотра таблицы разделов придется вместо fdisk использовать команду parted.
Итак, выведем информацию о разделах так:
Осталось смонтировать раздел диска с хранилищем VMFS:
Выведем содержимое смонтированного раздела:
Итак, теперь мы видим все файлы виртуальных машин на VMFS хранилище, которое доступно нам только для чтения, а это значит, что мы можем скопировать каталоги и/или отдельные файлы нужных виртуальных машин на отдельный диск и запустить их на другом гипервизоре ESXi.
Доступ к VMFS разделу из Windows
Для доступа к данным на VMFS разделе из Windows, нам понадобится специальный открытый драйвер Open Source VMFS Driver, написанный на Java. Драйвер требует версию Java не ниже 6 и также позволяет монтировать VMFS-тома в режиме только для чтения.
Примечание. При попытке подключения более новой версии VMFS появится ошибка No VMware File System detected.
- Итак, скачайте Open Source VMFS Driver (fvmfs_r95_dist.zip ) и распакуйте его в произвольный каталог (допустим C:\vmfs)
- Проверить работу java-приложения fvmfs.jar можно так:
- Далее нужно определить номер диска с хранилищем VMFS, подключенный к Windows-компьютеру. Номер диска можно узнать с помощью консоли управление дисками или diskpart. (В нашем примере подключенный диск имеет индекс 1 – Disk1. Для драйвера утилиты fvmfs, этот диск будет именоваться так: \\.\PhysicalDrive1)
- Попытаемся получить информацию о диске:
Подключаем VMFS хранилище на новом ESXi хосте
Как вы видите, в обоих рассмотренных выше случаях сторонние драйверы для VMFS под Linux и Windows не позволяют работать с VMFS 6.0. Поэтому самый универсальный способ получить доступ к данным на VMFS разделе диска вышедшего из стоя сервера – подключить его на новом сервере ESXi (который, благо, устанавливается и настраивается менее чем за час). Это самый простой способ. Таким способом вы сможете переподключить как физический жёсткий диск, так и LUN с устройства хранения (через FC или iSCSI).
Новый хост ESXi должен корректно определить подключенный VMFS датастор и вы сможете получить доступ к файлам на нем.
Итак, как подключить существующее VMFS хранилище на новом ESXi хосте без его форматирования.
Мы уже привыкли к кластерам высокой доступности, где в случае отказа физического сервера, виртуальные машины продолжают работать, перераспределившись между оставшимися серверами.
Такое решение основано на использовании общего хранилища.
Конечно же, элементы хранилища должны быть дублированы.
Представим на минуту, что у нас два здания или более.
И в каждом здании центр обработки данных или просто сервера и системы хранения данных.
Вполне логично расширить кластер таким образом, чтобы он охватывал несколько зданий.
Но тогда встает задача синхронизации хранилищ данных.
Эту задачу можно решать, например, с помощью репликации, vSphere Replication (входящая в vSphere, начиная с Essentials Plus) или Veeam Backup & Replication.
Раз в 15 минут при этом виртуальная машина будет реплицирована на другое хранилище.
Fault Tolerance ограничивает нас 4 -мя vCPU, но это беспрецедентный уровень защиты виртуальной машины.
Другой вариант - сразу получить синхронизируемое хранилище.
Т.е. данные на хранилище в одном здании будут точной копией данных во втором здании в любой момент времени.
Такое распределенное хранилище и позволяет организовать Gluster от Red Hat.
Gluster (или GlusterFS) - это распределенная файловая система, по возможностям не уступающая Amazon S3 или Google File System, но адаптированная для использования в коммерческих компаниях и государственных учреждениях различного масштаба.
Адаптированность заключается в возможности получить поддержку от Red Hat, что гарантирует решение любых проблем, возникших в процессе эксплуатации, в кратчайшие сроки.
Gluster работает поверх основной операционной системы и поддерживает различные типы распределения данных в зависимости от того, какое соотношение производительности и объема данных мы хотим получить.
Datastore для VMware vSphere
На схеме показаны два здания, соединенных между собой каналом с пропускной способностью не менее 1 Gbit.
В каждом здании присутствуют узлы ESXi, на которых работаю виртуальные машины (VM).
В целом схема классическая за исключением прослойки Gluster Datastore.
Для его организации условно взяты 4 сервера с внутренними дисками.
Объем датастора для VMware будет определен в зависимости от типа распределения контента.
На схеме выше мы проиллюстрировали принцип работы GlusterFS.
Сервера, названные условно A1 , A2 , B1 и B2 содержат определенное количество дисков.
Файлы данных делятся на блоки. Каждый блок, в данном случае, хранится на двух серверах.
Обращение может происходить к блоку, находящемуся на любом из серверов - они равноправны.
Запись также происходит на любой сервер. После записи блоки синхронизируются.
В данном случае Gluster создан как распределенный реплицируемый (distributed replicated).
Типы томов Gluster
В зависимости от поставленной задачи мы можем сконфигурировать один из трех видов Gluster:
В этом случае данные реплицируются (зеркалируются) по двум или более узлам Gluster.
При построении распределенного реплицируемого Gluster можно указать количество реплик.
Увеличение количество реплик повышает отказоустойчивость, но снижает доступный объем дискового пространства.
Плохо приспособлен для реальных задач, поскольку выход из строя даже одного диска может привести к серьезной потере данных, поскольку блоки распределяются по дискам случайно.
Файл делится на определенное количество частей (stipe count) при блоки распределены по серверам таким образом, что доступ к частям файла может происходить параллельно.
Если у посетителя сайта есть информация, которая по его мнению может быть интересна читателям, мы готовы обсуждать условия публикации.Мы приложим максимальные усилия, чтобы обеспечить Вас самой передовой информацией по лицензированию и предложить адекватный уровень цен на лицензии и поддержку VMware.
Читайте также: