Показанные схемы в статье отображают задний фон в виде серверов и коммутаторов. Это необходимо для ассоциативного восприятия, приближенного к тому, как программные сервисы архитектуры связаны с оборудованием, а также для понимания разницы в логических компонентах программных архитектур хранилищ на основе одного и того же минимального аппаратного набора.
Отличается фон только классическим исполнением хранения и программно-определяемым под гиперконвергенцию или дезагрегированную среду.
Каждая архитектура требует тонны текста для описания. В статье я выбрал, на наш взгляд, определенные моменты: это организация блоков грубыми мазками на уровне компонентов или сервисов.
Надеюсь, это поможет хотя бы поверхностно ознакомиться с разнообразием подходов и, возможно, навести мысли на новую архитектуру или функционал.
Заранее извиняюсь, если не раскрыл значение некоторых терминов. Рассчитываю, что Гугл поможет, если нет, тогда Яндекс, а в других случаях — чат «ИИ».
Рассматривать будем такие решения, как VMFS, LVM, vSAN, S2D, Nutanix Storage, Р-Хранилище, CEPH и частично затронем GlusterFS, vStack SDS, Vitastor и т.д.
В заключении приведу пример сравнения производительности между CEPH и Р-Хранилищем, а также нагрузки с данными.
Начнем с классики.
Классические системы хранения данных (СХД)
1. VMFS от VMware
схема VMFS от VMware
Перед вами картинка-схема организации кластерной файловой системы VMFS от VMware, которая является эталоном в области отказоустойчивой виртуализации.
Это распространённый сценарий классики, где как минимум одна система хранения данных с двумя контроллерами и для каждого как минимум по два интерфейса FC в соответствии с избыточностью.
Работает это за счет кластерной файловой системы VMFS, которая является сложным комплексным модулем зависимым от других модулей и состоящий из многих компонентов.
чуть подробнее
Контроллеры соединены с двумя SAN-коммутаторами для отказоустойчивости канала и организации Multipath. Сервера подключены к SAN-коммутаторам через соединения по FC и получают от СХД расшаренные LUN (shared LUN), которые доступны одновременно всем серверам.
LUN на стороне СХД — это единый физический том, под которым находится набор дисков, объединённых в уровень RAID-массива за счёт контроллеров, которых не менее двух для отказоустойчивости. На схеме показан вариант алгоритма RAID 10, который делает массив отказоустойчивым при выходе из строя определённого количества дисков.
Чтобы разделить работу одного и того же LUN между серверами-гипервизорами, требуется кластерная файловая система, которая содержит набор компонентов, как показано на схеме.
Присутствует блокировщик, который выписывает аренды ввода-вывода, то есть разрешение на запись серверу, на котором находится виртуальная среда, использующая файл — виртуальный образ диска, под который и выписывается аренда. До блокировщика блоки хранятся на LVM, то есть физический том, который LUN, помечается как раздел логического тома. Такая абстракция позволяет добавлять несколько LUN в одну логическую группу и расширять объем выделяемого пространства без остановки.
В старых версиях кластерной файловой системы использовался вариант конкурентного доступа по очереди, что сильно влияло на производительность. Теперь применяется параллельный доступ, когда каждый гипервизор кластера использует только отдельную часть или область, на которой размещены файлы от общей логической группы массива, доступной всем участникам кластера. Такие режимы работы предоставляет VMFS.
Кроме этого, VMFS все данные записывает в журнал чтобы в случае сбоя восстановить данные из него. Карты расположения блоков хранятся в области метаданных кластерной файловой системы, где также области хранения доступности файловой системы heartbeat на сервере для сервиса HA, который необходим для отказоустойчивости. Метаданные также записываются в журнал.
Когда хост терпит сбой, он может оставить устаревшие блокировки на хранилище данных VMFS. Настроенный HA пытается включить защищенные виртуальные машины на одном из выживших хостов в кластере. Однако из-за устаревших блокировок это может оказаться невозможным. Чтобы эта операция была успешной, хост, пытающийся включить виртуальную машину, выполняет следующие действия:
По такому же принципу работают и другие файловые системы, например NTFS в кластерном исполнении и такие свободно распространяемые кластерные файловые системы как GFS2 и OCFS2. Последние правда имеют много ограничений и недостатков по производительности, где ограничено возможное количество хостов в кластере, а службы HA и блокировщик имеют сложные конструкции, а также имеется потребность в кластерной CLVM. Чем сильно уступают перед VMFS и NTFS.
LUN на стороне СХД — это единый физический том, под которым находится набор дисков, объединённых в уровень RAID-массива за счёт контроллеров, которых не менее двух для отказоустойчивости. На схеме показан вариант алгоритма RAID 10, который делает массив отказоустойчивым при выходе из строя определённого количества дисков.
Чтобы разделить работу одного и того же LUN между серверами-гипервизорами, требуется кластерная файловая система, которая содержит набор компонентов, как показано на схеме.
Присутствует блокировщик, который выписывает аренды ввода-вывода, то есть разрешение на запись серверу, на котором находится виртуальная среда, использующая файл — виртуальный образ диска, под который и выписывается аренда. До блокировщика блоки хранятся на LVM, то есть физический том, который LUN, помечается как раздел логического тома. Такая абстракция позволяет добавлять несколько LUN в одну логическую группу и расширять объем выделяемого пространства без остановки.
В старых версиях кластерной файловой системы использовался вариант конкурентного доступа по очереди, что сильно влияло на производительность. Теперь применяется параллельный доступ, когда каждый гипервизор кластера использует только отдельную часть или область, на которой размещены файлы от общей логической группы массива, доступной всем участникам кластера. Такие режимы работы предоставляет VMFS.
Кроме этого, VMFS все данные записывает в журнал чтобы в случае сбоя восстановить данные из него. Карты расположения блоков хранятся в области метаданных кластерной файловой системы, где также области хранения доступности файловой системы heartbeat на сервере для сервиса HA, который необходим для отказоустойчивости. Метаданные также записываются в журнал.
Когда хост терпит сбой, он может оставить устаревшие блокировки на хранилище данных VMFS. Настроенный HA пытается включить защищенные виртуальные машины на одном из выживших хостов в кластере. Однако из-за устаревших блокировок это может оказаться невозможным. Чтобы эта операция была успешной, хост, пытающийся включить виртуальную машину, выполняет следующие действия:
- Он проверяет область heartbeat в хранилище VMFS данных на наличие идентификатора владельца блокировки.
- Через несколько секунд он проверяет, была ли обновлена запись в области heartbeat для этого хоста.
- Хост восстановления помечает блокировки устаревшими, оставленные этим хостом. После этого другие хосты в кластере не пытаются снять эти устаревшие блокировки.Поскольку владелец блокировки вышел из строя, он не может обновить свою запись в области heartbeat.
- Хост восстановления воспроизводит журнал VMFS heartbeat, чтобы очистить и затем получить блокировки.
- Когда аварийный хост перезагружается, он очищает свою собственную запись heartbeat и получает новую (с новым номером поколения). В результате он не
пытается заблокировать свои исходные файлы, поскольку он больше не является владельцем блокировки.
По такому же принципу работают и другие файловые системы, например NTFS в кластерном исполнении и такие свободно распространяемые кластерные файловые системы как GFS2 и OCFS2. Последние правда имеют много ограничений и недостатков по производительности, где ограничено возможное количество хостов в кластере, а службы HA и блокировщик имеют сложные конструкции, а также имеется потребность в кластерной CLVM. Чем сильно уступают перед VMFS и NTFS.
В дополнение к VMFS или даже вместо используется технология VVOLS – виртуальные тома, которые чем-то похожи на схему с lvm, без кластерной файловой системы. На монтируемых устройствах по iSCSI/FC/NFS нарезаются виртуальные логические тома, где каждый том это как папка или путь для расположения виртуальных дисков виртуальных машин. Следующая схема как раз про LVM.
2. LVM от Linux
схема LVM от Linux
На этой схеме отсутствует кластерная файловая система и вместо нее только lvm. Это тоже очень распространённая классическая схема среди виртуализации на базе гипервизора kvm-qemu. Преимущества в том, что нет файловой системы с журналами записи и метаданными и поэтому на эту абстракцию нет издержек, производительность лучше, но зато нет такой возможности восстановления в случае сбоя как у журналируемой кластерной файловой системы. Нет ограничений связанных с фс, можно большое количество хостов в кластере использовать.
чуть подробнее
На подключаемом расшаренном LUN создается VG логическая группа, далее LV логические тома. Каждый том LV это один виртуальный диск виртуальной машины в формате QCOW2.
Блокировку обеспечивает обычно sanlock, на схеме он изображен как DLM. Далее для такой конструкции необходим хороший HA, на данный момент один из распространенных это на базе движка управления Ovirt.
Блокировку обеспечивает обычно sanlock, на схеме он изображен как DLM. Далее для такой конструкции необходим хороший HA, на данный момент один из распространенных это на базе движка управления Ovirt.
Противоположность классики это SDS. Далее схемы с этой архитектурой.
Программно-определяемые системы хранения данных (SDS)
1. Р-Хранилище от Росплатформы
схема Р-Хранилища — SDS от Росплатформы
На схеме Р-хранилища изображено три сервера и два ethernet коммутатора. Это минимальная конфигурация почти для любого программно-определяемого хранилища. На каждом сервере имеются два диска для гипервизора, настроенные в RAID1 от аппаратного RAID контроллера на борту. Остальные три диска каждого сервера презентуются по JBOD/passthrough.
чуть подробнее
Р-хранилище имеет компонент клиент в виде точки монтирования для датасторов-папок, которые предоставляют хранение в них файлов-образов виртуальных дисков ВМ, файлов конфигураций ВМ и сервисов экспорта для внешних систем такие как iSCSI или кластер s3. От этого компонента клиента как видно на схеме есть связь со службой метаданных, которая содержит в себе карту расположения всех блоков и есть связь непосредственно с «чанк серверами» или другими словами «чанк сервисами», которые хранят эти блоки.
Служба метаданных обычно располагается на том же диске что и гипервизор, но может быть и на диске с ролью кэш, который используется в гибридной конфигурации.
Возвращаясь к клиенту-точке монтирования все данные записываются, используя лог структурированную файловую систему и делятся на блоки, где каждый блок записывается на своем диске, на котором его принимает чанк сервер, назначенный на этот диск.
Блоки и их копий раскладываются по разным дискам серверов по умолчанию, чтобы блок и его копия не встретились на одном сервере, но можно и переключать на более крупные локации такие как группы серверов или менее на диски.
Как показано на схеме ВМ или, другими словами, файлы образа диска ВМ и файл конфигурации ВМ все это для хранилища блоки данных. Р-хранилище размечает данные блоками по 256МБ для репликации и 1МБ для кодирования по типу EC. Первое обращение на запись проходит через службу метаданных, которая определит на какие чанк сервера лучше всего записать данные, а далее клиент работает с чанк серверами на прямую.
Так как на рисунке изображена минимальная конфигурация, то там реплика 2. Масштабируя кластер или, другими словами, увеличивая количество серверов можно переключать на другие виды реплики или избыточности EC по типу RAID6, где используются коды Рида Соломона.
В аварийной ситуации, когда у нас выходит из строя диск или более согласно возможному количеству, система продолжает работать используются копии, которые на других дисках на других серверах. Воспроизведение недостающей реплики начинается не сразу и только при наличии свободно места. Когда происходит воспроизведение, то для той порции блоков, которые имеют недостающие копии они создаются, для новых данных по-прежнему работает в полное количество реплик, поэтому может ощущаться как будто система работает не в 2 реплики как настроили, а в 3.
Данные, которые были на упавшем сервере или более в зависимости от общего количества нод и вида избыточности автоматический перезапускаются на других рабочих серверах благодаря сервису высокой доступности. Где в этот момент аренда блокировки освобождается от упавшего сервера и выдается новому серверу, который соответствует параметрам по достаточному количеству ресурсов.
В случае наличия высокоскоростных дисков журналы записи можно разместить на них, а на чанк серверах оставить только блоки, считанные с журналов. Все что не успело сбросится на чанк сервера будет считано с этих журналов в качестве кэша. Разные диски можно определять в уровни тиры, всего может быть 4 логических тира.
Служба метаданных обычно располагается на том же диске что и гипервизор, но может быть и на диске с ролью кэш, который используется в гибридной конфигурации.
Возвращаясь к клиенту-точке монтирования все данные записываются, используя лог структурированную файловую систему и делятся на блоки, где каждый блок записывается на своем диске, на котором его принимает чанк сервер, назначенный на этот диск.
Блоки и их копий раскладываются по разным дискам серверов по умолчанию, чтобы блок и его копия не встретились на одном сервере, но можно и переключать на более крупные локации такие как группы серверов или менее на диски.
Как показано на схеме ВМ или, другими словами, файлы образа диска ВМ и файл конфигурации ВМ все это для хранилища блоки данных. Р-хранилище размечает данные блоками по 256МБ для репликации и 1МБ для кодирования по типу EC. Первое обращение на запись проходит через службу метаданных, которая определит на какие чанк сервера лучше всего записать данные, а далее клиент работает с чанк серверами на прямую.
Так как на рисунке изображена минимальная конфигурация, то там реплика 2. Масштабируя кластер или, другими словами, увеличивая количество серверов можно переключать на другие виды реплики или избыточности EC по типу RAID6, где используются коды Рида Соломона.
В аварийной ситуации, когда у нас выходит из строя диск или более согласно возможному количеству, система продолжает работать используются копии, которые на других дисках на других серверах. Воспроизведение недостающей реплики начинается не сразу и только при наличии свободно места. Когда происходит воспроизведение, то для той порции блоков, которые имеют недостающие копии они создаются, для новых данных по-прежнему работает в полное количество реплик, поэтому может ощущаться как будто система работает не в 2 реплики как настроили, а в 3.
Данные, которые были на упавшем сервере или более в зависимости от общего количества нод и вида избыточности автоматический перезапускаются на других рабочих серверах благодаря сервису высокой доступности. Где в этот момент аренда блокировки освобождается от упавшего сервера и выдается новому серверу, который соответствует параметрам по достаточному количеству ресурсов.
В случае наличия высокоскоростных дисков журналы записи можно разместить на них, а на чанк серверах оставить только блоки, считанные с журналов. Все что не успело сбросится на чанк сервера будет считано с этих журналов в качестве кэша. Разные диски можно определять в уровни тиры, всего может быть 4 логических тира.
В отличие от классической схемы у SDS все держится на микросервисах клиент серверного сценария без кластерной файловой системы, а диски используются на борту серверов.
2. vSAN от VMware
схема vSAN — SDS от VMware
Эта схема почти похожа по архитектуре на предыдущую, но тем не менее имеет некоторые отличия. Диски объединяются в пул хранения на каждой ноде, в предыдущих версиях этого продукта это было немного по-другому использовались дисковые группы и тиры. В этой версии все диски одинаковые под один тир и на каждом располагаются лог из которого потом данные переливаются в раздел хранения и есть сегмент расположения метаданных.
чуть подробнее
Блоки данных, которые попадают сначала в лог под названием «durable log» после датастора располагаются в так называемой performance leg в желтой области, нарисованной на схеме. Эта область имеет избыточность по типу RAID1 или по-другому реплику 2, а те данные, которые попадают после лога в область хранения под названием capacity leg могут иметь другой вид избыточности в зависимости от конфигурации.
Так как на рисунке минимальный набор железа, то избыточность для блоков также RAID1, но при добавлении серверов возможно переключать на другие виды избыточности EC.
Таким образом данные и метаданные, которые сначала попадают в лог они не затрачивают время на подтверждение записи от большого количество копий кроме RAID1, а блоки, которые сбрасываются на «capacity leg» могут хранится в большем количество копий.
Блоки данных, которые попадают сначала в лог под названием «durable log» после датастора располагаются в так называемой performance leg в желтой области, нарисованной на схеме. Эта область имеет избыточность по типу RAID1 или по-другому реплику 2, а те данные, которые попадают после лога в область хранения под названием capacity leg могут иметь другой вид избыточности в зависимости от конфигурации.
Так как на рисунке минимальный набор железа, то избыточность для блоков также RAID1, но при добавлении серверов возможно переключать на другие виды избыточности EC.
Таким образом данные и метаданные, которые сначала попадают в лог они не затрачивают время на подтверждение записи от большого количество копий кроме RAID1, а блоки, которые сбрасываются на «capacity leg» могут хранится в большем количество копий.
3. Хранилище от Nutanix
схема Хранилища от Nutanix
Не менее интересный подход у Nutanix. Здесь нет клиента-точки монтирования или, другими словами, датасторов. Вместо этого на каждом сервере контроллер виртуальная машина «CVM», в которую подключены на прямую «DMA» все диски, а потом экспортируется от CVM в сторону гипервизора виртуальные LUN-ы по iSCSI или предоставляется хранение по протоколам NFS и SMB. Гипервизор может быть разный как от Nutanix так и от VMware или Hyper-V от Microsoft, для каждого из них используется свой протокол.
чуть подробнее
Внутри CVM уже выполняется вся магия по распределению блоков. Запись сначала попадает в область «optlog» на этом же этапе она реплицируется на другие «optlog» по сети на других серверах пока не подтвердится последняя записанная реплика блока, далее в фоновом режиме данные сбрасываются в область «extent stor», отмеченную синим цветом или в оранжевую на быстрые диски, которые в tier0. Где будут располагаться данные на быстрых или медленных определяет механизм «Intelligent Lifecycle Management» на основе шаблона доступа.
Последовательная запись может сразу записываться в область extent stor минуя optlog, а рандомная всегда идет в optlog. Чтение осуществляется, с того, что не успело сбросится с optlog с быстрых дисков, а то, что давно записано считывается напрямую с extent stor либо с того что попало в кэш памяти от CVM.
За всей координацией следят также области метаданных, которые размещаются на быстрых дисках и делятся на локальные мета, которые знают про расположение блоков на дисках этого сервера и глобальные, которые имеют карту расположения серверов.
Внутри CVM уже выполняется вся магия по распределению блоков. Запись сначала попадает в область «optlog» на этом же этапе она реплицируется на другие «optlog» по сети на других серверах пока не подтвердится последняя записанная реплика блока, далее в фоновом режиме данные сбрасываются в область «extent stor», отмеченную синим цветом или в оранжевую на быстрые диски, которые в tier0. Где будут располагаться данные на быстрых или медленных определяет механизм «Intelligent Lifecycle Management» на основе шаблона доступа.
Последовательная запись может сразу записываться в область extent stor минуя optlog, а рандомная всегда идет в optlog. Чтение осуществляется, с того, что не успело сбросится с optlog с быстрых дисков, а то, что давно записано считывается напрямую с extent stor либо с того что попало в кэш памяти от CVM.
За всей координацией следят также области метаданных, которые размещаются на быстрых дисках и делятся на локальные мета, которые знают про расположение блоков на дисках этого сервера и глобальные, которые имеют карту расположения серверов.
4. S2D от Microsoft
схема S2D от Microsoft
В S2D принцип такой же как у vSAN и Р-хранилища, но в деталях, конечно, есть отличия. Блоки и метаданные передаются по SMB, на стороне гипервизора или, другими словами, хостовой операционной системы имеются точки монтирования на CSV, которая предоставляет уже единое хранилище для расположения виртуальных дисков виртуальных машин.
Для ускорения блочного ввода вывода между серверами рекомендуется ethernet+RDMA. Для вышеописанных решений SDS также имеется возможность использовать RDMA, но для S2D это необходимость, для лучшей производительности.
ReFS позволяет распределять блоки в зависимости от интенсивности использования, то есть на горячие и холодные массивы или, другими словами, медленные диски и на быстрые диски.
5. CEPH от Opensource
схема CEPH от Opensource
CEPH имеет похожую архитектуру как у Р-хранилища, но в деталях отличается своей уникальностью.
чуть подробнее
RBD — блочный девайс, кусок хранилища, который можно напрямую прокинуть в виртуальную машину.
Данные, которые записываются в это блочное устройство распределяются на блоки и их копии с помощью компонента CRUSH средствами хеширования и вычисления местоположения, где должны быть записаны данные, то есть на каких физических дисках и на каких серверах.
Каждый диск управляется сервисом хранения данных OSD — Object Storage Device,
но кроме простого хранения фрагментов они также группируются в логические абстракции PG – placement group – группы размещения, а устройства RBD в свою очередь определяются в pool, где каждый пул может иметь свой вид избыточности и свое количество групп PG, которые ассоциированы по определенным OSD.
Вырисовывается сложная абстракция, группировка фрагментов данных чем не желе у вышеописанных решений и это вносит больше гибкости, и в тоже время минусы в виде издержек на распределение данных по этим уровням абстракций, а также сложность управления.
RBD — блочный девайс, кусок хранилища, который можно напрямую прокинуть в виртуальную машину.
Данные, которые записываются в это блочное устройство распределяются на блоки и их копии с помощью компонента CRUSH средствами хеширования и вычисления местоположения, где должны быть записаны данные, то есть на каких физических дисках и на каких серверах.
Каждый диск управляется сервисом хранения данных OSD — Object Storage Device,
но кроме простого хранения фрагментов они также группируются в логические абстракции PG – placement group – группы размещения, а устройства RBD в свою очередь определяются в pool, где каждый пул может иметь свой вид избыточности и свое количество групп PG, которые ассоциированы по определенным OSD.
Вырисовывается сложная абстракция, группировка фрагментов данных чем не желе у вышеописанных решений и это вносит больше гибкости, и в тоже время минусы в виде издержек на распределение данных по этим уровням абстракций, а также сложность управления.
Заключение
В заключение можно сказать, что все подходы важно более детальнее изучить, что может помочь при разработке своего хранилища или в изучении, или тестировании новых продуктов, но при глубоком изучении станет сложнее сравнивать все эти решения между собой и вот почему:
Каждый из вариантов был разработан под определенные задачи, масштабы и занимает свою нишу. Лидеры по использованию в виртуализации это классические подходы от VMware(vmfs), RedHAt(lvm) и на третьем месте NTFS от Microsoft.
После классики идут уже программно-определяемые решения (SDS) и продвигается тенденция, что классика будет заменена на них, но пока что больше всего это используется у сервис и хостинг провайдеров. Среди SDS лидирует VMware vSAN, далее Nutanix, потом Ceph и на РФ рынке Р-хранилище. Реже использование S2D от Microsoft.
чуть подробнее
По поводу Nutanix тоже спорный момент так, как в другом ракурсе становится лидером за счет того, что агрегирует в себе использование четырех видов гипервизоров.
Ceph и Р-хранилище используются под такие задачи, которые не умеют другие решения это объектное хранение s3. Если Ceph больше под дезагрегированные сценарии использования, то Р-хранилище изначально заточено под гиперконвергентное решение, хотя используется и в дезагрегированном исполнении.
Агрегатором или гибридом классики и программно-определяемого исполнения выступает такое решение, например, как облачная оркестрация OpenStack, где отдельные сервера работают в классическом сценарии, а другие сервера с SDS и это в пределах одного кластера за счет компонента cinder.
После обзора статьи может сложится впечатление, что все схемы одинаковые. Это в первую очередь из-за фона и однообразности аппаратного набора, который в действительности имеет меньше сценариев, чем разновидность архитектур программных компонентов, но и сами программы похожи друг на друга. Где они преследуют одни и те же две цели, балансируя между производительностью и отказоустойчивостью.
Описание каждого решения обладает своей терминологией, что сбивает столку при попытке разобрать все эти продукты в одной статье, тут могут помочь сами схемы.
Кроме описания компонентов, абстракций и организации взаимодействия между ними, много проблем, которые решаются при создании хранилища для виртуализации это:
а еще такое дополнение как дедупликация и сжатие.
Каждая из этих проблем описывается лекцией или документацией, состоящей из проблем меньшего объема, подходов, и решений.
Также кроме перечисленных видов хранения используются и экспериментальные или кандидаты на продуктивное использование это: GlusterFS про него писал в своей старой статье; далееLustre; Vitastor от отечественного энтузиаста; vStack SDS на базе FreeBSD с предположительным решением на базе ZFS+NBD и т.д.
Читатели воскликнут зачем было в начале упоминать западные решения, описанные в этой статье, которые ушли с РФ рынка. Ну во-первых ностальгия, приятно и легко описывать софт, который наделен интересным подходом и в тоже время надежной технологией, а во-вторых, чтобы разрабатывать надо учится у тех, у кого это получается лучше.
Кроме создания, изучение архитектур помогает легче ориентироваться при выборе решения для собственной инфраструктуры, но узнавая подробности сложнее выбрать, так как каждое решение своеобразно и подходит под разные задачи, и между собой не равны на прямую.
Взять перечень функционала одного решения и в столбец таблицы сравнивать с перечнем другого решения не совсем получится. Потому что у каждого решения кроме каких-то общих, отличающихся подходами, будут еще свои уникальные возможности и в этом случае выбирать придется, уже ориентируясь своими предпочтениями и опытом. Где так же может помочь сравнение решений по производительности как ниже в примере.
По поводу Nutanix тоже спорный момент так, как в другом ракурсе становится лидером за счет того, что агрегирует в себе использование четырех видов гипервизоров.
Ceph и Р-хранилище используются под такие задачи, которые не умеют другие решения это объектное хранение s3. Если Ceph больше под дезагрегированные сценарии использования, то Р-хранилище изначально заточено под гиперконвергентное решение, хотя используется и в дезагрегированном исполнении.
Агрегатором или гибридом классики и программно-определяемого исполнения выступает такое решение, например, как облачная оркестрация OpenStack, где отдельные сервера работают в классическом сценарии, а другие сервера с SDS и это в пределах одного кластера за счет компонента cinder.
После обзора статьи может сложится впечатление, что все схемы одинаковые. Это в первую очередь из-за фона и однообразности аппаратного набора, который в действительности имеет меньше сценариев, чем разновидность архитектур программных компонентов, но и сами программы похожи друг на друга. Где они преследуют одни и те же две цели, балансируя между производительностью и отказоустойчивостью.
Описание каждого решения обладает своей терминологией, что сбивает столку при попытке разобрать все эти продукты в одной статье, тут могут помочь сами схемы.
Кроме описания компонентов, абстракций и организации взаимодействия между ними, много проблем, которые решаются при создании хранилища для виртуализации это:
- Параллельный доступ;
- журналирование;
- репликация;
- кодирование EC;
- удаление данных;
- дефрагментация;
- копирование при записи;
- высокая доступность;
- отказоустойчивость;
- блокировка доступа с арендой;
- согласованность участников работы кластера;
- метаданные;
- кэширование;
- балансировка;
- ребаланс;
- datalocality;
- тиринг и т.д.,
а еще такое дополнение как дедупликация и сжатие.
Каждая из этих проблем описывается лекцией или документацией, состоящей из проблем меньшего объема, подходов, и решений.
Также кроме перечисленных видов хранения используются и экспериментальные или кандидаты на продуктивное использование это: GlusterFS про него писал в своей старой статье; далееLustre; Vitastor от отечественного энтузиаста; vStack SDS на базе FreeBSD с предположительным решением на базе ZFS+NBD и т.д.
Читатели воскликнут зачем было в начале упоминать западные решения, описанные в этой статье, которые ушли с РФ рынка. Ну во-первых ностальгия, приятно и легко описывать софт, который наделен интересным подходом и в тоже время надежной технологией, а во-вторых, чтобы разрабатывать надо учится у тех, у кого это получается лучше.
Кроме создания, изучение архитектур помогает легче ориентироваться при выборе решения для собственной инфраструктуры, но узнавая подробности сложнее выбрать, так как каждое решение своеобразно и подходит под разные задачи, и между собой не равны на прямую.
Взять перечень функционала одного решения и в столбец таблицы сравнивать с перечнем другого решения не совсем получится. Потому что у каждого решения кроме каких-то общих, отличающихся подходами, будут еще свои уникальные возможности и в этом случае выбирать придется, уже ориентируясь своими предпочтениями и опытом. Где так же может помочь сравнение решений по производительности как ниже в примере.
Сравнение производительности между Ceph и Р-Хранилищем.
По производительности пока удалось сравнить только два решения между собой это Ceph и Р-хранилище. Ниже на фото показаны версии продуктов на момент сравнения и конфигурация железа.
конфигурация железа и версии сравниваемых продуктов
Профили нагрузки c описанием, следующие:
/*Последовательная запись sync и async*/
Fio #– имя общеизвестной широко используемая программы для тестирования производительности. Далее параметры ее запуска.
--name seqsyncwrite_jobs1_1m #– имя запускаемой задачи.
--rw write #– вид операции.
--size 262144M #– два гигабайта памяти умноженное на объем памяти хоста и деленное на количество ядер процессора. Если увеличивается кол-во потоков или процессов, то обратно пропорционально уменьшается датасет или размер файла, но должен быть как минимум в два раза больше размера оперативной памяти.
--numjobs 1 #– количество потоков может быть равное количеству ядер процессора, чтобы нагрузить весь процессор.
--ioengine sync # – используемая библиотека или движок для синхронных или асинхронных операций. Последовательные операции от записи видео, например синхронные, а случайные операции, например для базы данных асинхронные.
--bs 1m # – размер блока.
--time_based --runtime 120 # - время выполнение нагрузки.
--direct=1 # -параметр операции на прямую без использования кэш.
--directory /dev # - путь к устройству или датастору в Р-хранилище это /mnt/vstorage/…
--filename_format=rbd'$jobnum' # - имя файла или устройства.
--percentile_list=50:95:99:99.9:100 # - сообщить о задержках при тесте в процентах при определенных порогах, перечисленных через двоеточие.
--thread # - тип задачи. Если не задано, вместо потоков будут созданы процессы.
--clat_percentiles=1 # - задержка завершения отчета, которая показывает, сколько времени в процентах прошло между отправкой в ядро и завершением ввода-вывода (исключая задержку отправки).
--group_reporting # - для отображения в отчете статистики по всем потокам или процессам.
-output-format=json # - отображение отчета в формате json для использования в программах построения графиков.
/*В профиле случайных операций, например 70/30 почти тоже самое кроме некоторых параметров:*/
--name randsyncrw_jobs1_4k # - имя операции.
--rw randrw # - вид операции.
--norandommap # - Если указана эта опция, fio просто получит новое случайное смещение, не глядя на предыдущую историю ввода-вывода.
--randrepeat 0 # - случайных повторений не выполнять.
--rwmixread 70 # - процент чтения.
--rwmixwrite 30 # - процент записи.
--bs 4k # - размер блока.
чуть подробнее
Методика тестирования SDS отличается от тестирования СХД в том смысле, что СХД можно тестировать как единую точку в виде LUN или диска со стороны виртуальной машины. SDS тоже также можно тестировать со стороны ВМ, но есть также возможность выполнить тестовую нагрузку со стороны точки монтирования или другими словами датастора, нагружая его с каждой ноды всего кластера.
Таким образом мы увидим производительность самого SDS исключая потерю производительности в копировании при записи на уровне виртуального диска вм, потерю при фс от гостевой ОС, потерю на эмуляцию шины виртуального диска, ограниченное количество потоков вм, памяти и т.д.
Сложность замера со стороны ВМ еще в том, что требуется достаточное количество ВМ чтобы дойти до пиковой нагрузки потоков и памяти на хостах.
Если по отдельности делать замеры с обеих сторон со стороны ВМ и со стороны SDS, то увидим разницу из-за издержек на виртуализацию и при каком количестве нагруженных ВМ показатели близки к пиковой производительности SDS. Издержки на слой виртуализации не должны превышать 25%.
Методика тестирования SDS отличается от тестирования СХД в том смысле, что СХД можно тестировать как единую точку в виде LUN или диска со стороны виртуальной машины. SDS тоже также можно тестировать со стороны ВМ, но есть также возможность выполнить тестовую нагрузку со стороны точки монтирования или другими словами датастора, нагружая его с каждой ноды всего кластера.
Таким образом мы увидим производительность самого SDS исключая потерю производительности в копировании при записи на уровне виртуального диска вм, потерю при фс от гостевой ОС, потерю на эмуляцию шины виртуального диска, ограниченное количество потоков вм, памяти и т.д.
Сложность замера со стороны ВМ еще в том, что требуется достаточное количество ВМ чтобы дойти до пиковой нагрузки потоков и памяти на хостах.
Если по отдельности делать замеры с обеих сторон со стороны ВМ и со стороны SDS, то увидим разницу из-за издержек на виртуализацию и при каком количестве нагруженных ВМ показатели близки к пиковой производительности SDS. Издержки на слой виртуализации не должны превышать 25%.
Синтетические замеры производительности реплики 3
Графики на изображении — это не непрерывная линия замеров производительности одного профиля, а на самом деле каждый график это 13 замеров производительности, где каждый замер выполнялся по 5 итераций с продолжительностью каждой итерации в 120 секунд. Сами замеры отличаются количеством нагружаемых потоков и запросов.
Получается каждый такой замер отображался с ровно проходящей линией без перепадов и таких графиков много, поэтому решено было скомпоновать это в 5 общих графиков для “репликации 3” и 5 общих графиков для помехоустойчивого “кодирования 3+2”.
В результате получилось, что при пиковой нагрузке в самом часто используемом профиле на практике случайное чтение/запись 70/30 c блоком 4к при реплике 3, где 48 потоков и 32 запроса у Р-хранилища 739200IOPS, а у Ceph на этом же железе 253000IOPS. Замер запускался на Р-хранилище непосредственно в датастор – точку монтирования для хранения виртуальных дисков виртуальных машин, а на стороне Ceph это RBD устройства.
Синтетические замеры производительности кодирование EC 3+2
Помехоустойчивое кодирование 3+2 медленнее чем реплика 3 и выглядит это при профиле случайное чтение/запись 70/30 c блоком 4к как 329200IOPS c 48 потоками 32 запроса на Р-хранилище, а у Ceph 70400IOPS.
На практике чаще происходят случайные операции, но, например для видео наблюдения работают последовательные операции и если посмотреть на графики кодирования 3+2, то у Ceph лучше показатели в остальном Р-хранилище опережает по производительности.
Последовательная скорость записи при нагрузке с ВМ VMware
На этой картинке уже боевая нагрузка от системы видео наблюдения с приложениями на виртуальных машинах VMware, подключенных к Р-хранилищу по iSCSI. При пиковой нагрузке скорость последовательной записи кластера хранения достигла 9Гигабайт в секунду.
Конфигурация железа, следующая:
6 нод(DEPO Storm 3470E1A), 2x480SSD для ОС, в каждой 56 ядер ЦПУ(2xG6348) и 1ТБ памяти, и по 60 HDD(ST18000NM000J) дисков(не рекомендуется такое количество на ноду) и по три MZQL215THBLA-00A07 NVMe по 15ТБ в качестве кэш. Логически было разделено на три уровня, где каждый по 20 дисков HDD и по одному кэш. То есть по факту на картинке производительность одного уровня.
Для подключения дисков использовалась полка DEPO Storage 2360 JBOD/4U60/60T18000G7/RMK/123ONS3DS.
Р-хранилище использовалось в виде экспорта по iSCSI, где было по 10 LUN на каждую ноду. Размер каждого LUN по 60ТБ(не рекомендуется). Сеть была 4*25Гбит одним каналом, где разделение трафика iSCSI и интерконекта было на уровне VLAN (не рекомендуется так делать). Объем лицензии хранилища был на 6 Петабайт, заливали данные на пару Петабайт.
Такая конфигурация не типична и не совсем корректная для Р-хранилища, но так захотел боярин вопреки рекомендациям.
Последовательная скорость записи
Здесь уже другая конфигурация, достигшая начальную пиковую скорость в 22Гигабайта в секунду, а конфигурация, следующая:
6 серверов(VEGMAN S220), где на каждом 32 ядра ЦПУ 754ГБ памяти по 2 штуки NVMe(MZQL23T8HCLS-00A07) — роли КЭШ и 12 шпинделей SATA 8ТБ и интерконект 2x25Гбит, и 2x25Гбит сеть доступа по s3 и управления.
случайные операции чтения/запись
Далее нагрузка случайным профилем на этом же железе.
Последовательная скорость записи
А здесь уже непрерывно записывались данные, где кроме операции записи и чтения еще параллельно выполнялось удаление. Нагрузка уже шла по протоколу s3 поэтому само хранилище SDS не сильно было нагружено.
чуть подробнее
Удаление отложенное, особенно если это s3, так как в объектном хранении файлы-объекты делятся на блоки различных размеров. Для самых больших объектов хранятся в пуле-файле с размером блоков по 8МБ, а для самых мелких это 4КБ.
Когда удаляется объект, то остаются пустые блоки на уровне пулов-файлов, а так как s3 относится к хранению не структурированных данных, то еще применяется помехоустойчивое кодирование, где размеры экстентов-блоков на блочном уровне по 1МБ и включение очистки пустых блоков происходит по внутренней команде sync при условии, что пустых данных не меньше 75%, чтобы не создавать перекладку блоков во время операций записи или чтения данных.
Если переформулировать, то когда выполняется удаление s3 объектов, образуется фрагментация, которая препятствует физическому освобождению блоков.
Для виртуализации чаще всего применяется репликация, а в ней используются блоки размером 256 МБ. Во время удаления файлов очистка таких блоков происходит намного быстрее.
Удаление отложенное, особенно если это s3, так как в объектном хранении файлы-объекты делятся на блоки различных размеров. Для самых больших объектов хранятся в пуле-файле с размером блоков по 8МБ, а для самых мелких это 4КБ.
Когда удаляется объект, то остаются пустые блоки на уровне пулов-файлов, а так как s3 относится к хранению не структурированных данных, то еще применяется помехоустойчивое кодирование, где размеры экстентов-блоков на блочном уровне по 1МБ и включение очистки пустых блоков происходит по внутренней команде sync при условии, что пустых данных не меньше 75%, чтобы не создавать перекладку блоков во время операций записи или чтения данных.
Если переформулировать, то когда выполняется удаление s3 объектов, образуется фрагментация, которая препятствует физическому освобождению блоков.
Для виртуализации чаще всего применяется репликация, а в ней используются блоки размером 256 МБ. Во время удаления файлов очистка таких блоков происходит намного быстрее.
На этой интересной ноте пока все и низкой поклон всем кто дочитал такую сложную тему. Как появятся новые возможности тестирования с результатами или сравнениями, которые можно детально описать в статье, а также желание читателей и наличие вдохновения, то я напишу что-то новое.
Полезные ссылки
- Описание работы VMFS https://core.vmware.com/resource/vmware-vsphere-vmfs#section1
- Описание работы VVOLS https://vm-guru.com/news/vmware-vsphere-6-vvols
- Статья по LVM https://habr.com/ru/companies/ruvds/articles/493696/
- Документация Р-хранилища https://updates.rosplatforma.ru/docs/7.0.13/r-virt_install.pdf или ссылка на ближайший вебинар webinar.rosplatforma.ru или отставить заявку на сайте rosplatforma.ru
- Описание работы vSAN 8 https://vm-guru.com/news/vmware-vsan-8-where-are-disk-groups
- Библия Nutanix https://www.nutanixbible.com/11b-book-of-storage-services-files.html
- Описание работы S2D https://learn.microsoft.com/en-us/azure-stack/hci/concepts/storage-spaces-direct-overview
- Описание работы CEPH http://onreader.mdl.ru/LearningCeph/content/Ch03.html"
- Сравнение CEPH c Gluster https://habr.com/ru/articles/486392/
- Описание работы Lustre https://doc.lustre.org/lustre_manual.xhtml
- Презентация по Vitastor https://vitastor.io/presentation/highload/highload.html#/
- Сайт по vStack https://ru.vstack.com/products/hcp/
Комментарии (21)
jingvar
02.11.2024 14:09Все в одну кучу. Классические схд это дорады, нетапы и тд. Какой юзкейс вы решали? Как оцениваете плюсы и минусы относительно вашей задачи?
mrospax Автор
02.11.2024 14:09Какое отношение имеет куча разновидностей таких СХД как: Дорадо, Нетапы и т.д.? Ещё раз, в статье обзор архитектуры программных абстракций и сервисов, без которых железо просто мусор. Классический подход с кластерной файловой системой для виртуализации фундаментален для любой железяки, будь то Дорадо, Нетап или IBM и т.д.
jingvar
02.11.2024 14:09Классические системы хранения данных (СХД) это же не я написал. Еще раз какие задачи вы ставили? Какой sla, для чего? Какие стораж тайпы нужны ? Что на счет стоимости решения как по железу так и по лицензиям? До какого размера масштабируется? Для пода на 60 гиперов одни решения, для 1000 другие.
mrospax Автор
02.11.2024 14:09Вы задаете правильные вопросы, но все эти вопросы справедливы и для SDS при решении определенной задачи. В статье я пытался донести разницу в подходах и архитектуре при использовании хранилищ для виртуализации, не опускаясь до уровня конкретной задачи, иначе не получится описывать всю кучу, а по каждому продукту неизбежно придется делать отдельную огромную статью. Куча позволяет посмотреть на все решения сразу, не зацикливаясь на каком-то одном, чтобы иметь маломальское представление о разных вариантах грубыми мазками, далее выбрать интересный вариант для себя и углубиться в его детали через предоставленные ссылки или самому поискать. На мой взгляд, это важно сейчас, особенно для тех, кто пытается разработать свой продукт виртуализации или выбрать для работы, а статей по выбору хранилищ под виртуализацию не так много. Мне сложно было искать некоторые сценарии, информации очень мало, а куча может помочь кому-то при поиске. В начале также обозначил, что сравнение идет по минимальной конфигурации железа, которая определена для большинства перечисленных продуктов, но, есть те решения, которые могут с меньшим количеством нод работать или использовать СХД напрямую без SAN-коммутаторов.
vmcore
02.11.2024 14:09а что значит "классический подход с кластерной файловой системой" ?
mrospax Автор
02.11.2024 14:09В моем понимании, ранее в большинстве использовались СХД для хранения виртуализации в корпоративной среде, затем появились SDS, после чего СХД стали именовать классическими или, помягче, традиционными. В статье я не пытаюсь сказать, что СХД в сценарии с кластерной файловой системой или с логическими томами — плохой вариант, но в каждом варианте есть свои плюсы и минусы. Учитывая, что в РФ начинают использовать альтернативные решения из-за сложностей с СХД, связанных с разными факторами, такими как цена, качество и т.д., плюс сами решения виртуализации, на которые осуществляется переход, не имеют таких аналогов, как VMFS и NTFS (CSV). Если отказываться в пользу каких-то простых производительных вариантов, то теряется качество и отказоустойчивость, и наоборот. Разработка кластерной файловой системы была актуальна в те годы, когда начинали развиваться VMFS и NTFS (CSV), а сейчас, когда уже прошли десятилетия, это зрелые решения. Идти по их пути значит делать копию, которая долго не будет популярной, если вообще будет интересна как минмум самим разработчикам. В связи с этим и не только, SDS для разработчиков выглядит как перспективный вариант, но и про СХД забывать не стоит, хотя бы в плане развития интеграции или решений на уровне LVM, или NFS. Но если каким-то чудом появится новая кластерная файловая система или нам поставят задачу "кровь из носу" сделать такую, то я только за!
post_ed
02.11.2024 14:09Отличная статья! Добавлю, как мне кажется, очень важный момент - в SDS от Microsoft, если создаём кластер, нужно использовать именно SAS-диски.
mrospax Автор
02.11.2024 14:09Спасибо, подбодрили! На самом деле у каждого решения много особенностей. Для упоминания всех статья сильно разрастается, даже сейчас она не маленькая, а хотелось бы для каждого продукта сделать компактное описание в равной доле. С этим у меня не совсем получилось, дело это нетривиально, особенно когда, кроме статьи, много других задач по разработке своего продукта. Несмотря на это, надеюсь, статья будет полезна всем, кто интересуется хранилищами для виртуализации. По поводу SAS-дисков спасибо, перепроверю это, и если будет возможность, добавлю в статью. Буду благодарен, если кто-то еще заметит что-то важное, так как в многозадачном режиме действительно мог где-то что-то упустить, хотя перепроверял неоднократно.
vmcore
02.11.2024 14:09статья интересная, спасибо. правда не понял зачем в последнем списке Lustre :)
mrospax Автор
02.11.2024 14:09хороший вопрос тоже задавал его себе, когда добавлял Lustre) задумка была упомянуть это решение в качестве еще одного вида архитектуры, но разобрать это не успел. Если прям глаз режет и его нельзя для виртуализации использовать, то могу убрать:)
Dante4
А откуда выводы, что у LVM производительность лучше (чем VMFS?)? Это как-то тестировалось? Проверялось? Какие замеры брались?
Или это *на основе умозаключения*?
mrospax Автор
На основе, например, вот этой статьи https://habr.com/ru/companies/ruvds/articles/493696/ плюс умозаключения. Если у вас есть опровержения этому, прошу предоставить замеры или объяснения.
Dante4
Не наблюдаю там ничего про VMFS.
То есть никаких доказательств Ваших слов что LVM быстрее, чем VMFS у вас нет и тестов Вы не делали?
mrospax Автор
а у вас есть доказательства что это не так? покажите их, и я исправлю.
Dante4
Мы вроде не в детском саду? Или Вы считаете, что утверждающий не должен предоставлять никаких доказательств своего мнения?
Можем обратиться к этому
«доказывание лежит на том, кто утверждает, а не на том, кто отрицает, на отрицающем нет обязанности доказывать» (c) Рим - https://ru.wikipedia.org/wiki/Бремя_доказывания
mrospax Автор
Будут доказательства, тогда добавлю или исправлю, но пока есть умозаключение, и выше указанная статья — цитирую из нее текст: "Слой LVM потребляет значительно меньше процессорных ресурсов, чем файловая система. Одна из причин этого то, что блоки в нём значительно больше, чем типичный блок файловой системы (4КБ). Чем больше блок (extent) на физическом устройстве LVM, тем более быстро происходит IO и тем меньше фрагментация. "
Dante4
Да, только VMFS это вам не классическая ФС с которой в той статье сравнивается LVM. Рекомендую ознакомиться с Deep Dive по VMFS, прежде чем делать пустые, ничем не подкреплённые, умозаключения. Либо хотя бы подкрепить их тестами, а не *Я так думаю, значит так и есть*
Более того Вас никак не напрягает, что в статье тесты проводятся на nvme 970 PRO? Даже не PM9A3 или PM983?
mrospax Автор
VMFS — это кластерная файловая система, LVM — это логические тома, которые находятся ниже такого абстрактного слоя, как файловая система.
В своей статье я явно описал, почему LVM может быть лучше. "Преимущества в том, что нет файловой системы с журналами записи и метаданными, и поэтому на эту абстракцию нет издержек, производительность лучше, но зато нет такой возможности восстановления в случае сбоя, как у журналируемой кластерной файловой системы. Нет ограничений, связанных с файловой системой, можно использовать большое количество хостов в кластере."
Речь идет о разнице между такими логическими абстракциями, как LVM и VMFS. Причем тут модели дисков?
В статье, при описании VMFS, чтобы сильно не отклоняться, я использовал такой документ, как "VMware Press Technology Mostafa Khalil Storage Design and Implementation (A Technology Deep Dive)". Чем вам не Deep Dive? Некоторые формулировки, если кто заметил, взяты прямо из этого документа.
Если вы хотели сказать, что VMFS имеет режим работы, который позволяет не использовать слой LVM и отключает запись в журнал самой файловой системы, что позволяет добиться хорошей производительности без потерь при записи, то так и надо было об этом писать, и сразу же тогда упоминать минусы, такие как потеря надежности и гибкости в таком случае.
useribs
Сомнительное утверждение конечно. IO в вакууме быстрее, но есть еще write amplification которое тот еще overhead добавит