Сравнение архитектуры отказоустойчивых хранилищ для виртуализации в картинках
Показанные схемы в статье отображают задний фон в виде серверов и коммутаторов. Это необходимо для ассоциативного восприятия, приближенного к тому, как программные сервисы архитектуры связаны с оборудованием, а также для понимания разницы в логических компонентах программных архитектур хранилищ на основе одного и того же минимального аппаратного набора.
Отличается фон только классическим исполнением хранения и программно-определяемым под гиперконвергенцию или дезагрегированную среду.
Каждая архитектура требует тонны текста для описания. В статье я выбрал, на наш взгляд, определенные моменты: это организация блоков грубыми мазками на уровне компонентов или сервисов.
Надеюсь, это поможет хотя бы поверхностно ознакомиться с разнообразием подходов и, возможно, навести мысли на новую архитектуру или функционал.
Заранее извиняюсь, если не раскрыл значение некоторых терминов. Рассчитываю, что Гугл поможет, если нет, тогда Яндекс, а в других случаях — чат «ИИ».
Рассматривать будем такие решения, как VMFS, LVM, vSAN, S2D, Nutanix Storage, Р-Хранилище, CEPH и частично затронем GlusterFS, vStack SDS, Vitastor и т.д.
В заключении приведу пример сравнения производительности между CEPH и Р-Хранилищем, а также нагрузки с данными.
Начнем с классики.
Классические системы хранения данных (СХД)
1. VMFS от VMware
схема VMFS от VMware
Перед вами картинка-схема организации кластерной файловой системы VMFS от VMware, которая является эталоном в области отказоустойчивой виртуализации.
Это распространённый сценарий классики, где как минимум одна система хранения данных с двумя контроллерами и для каждого как минимум по два интерфейса FC в соответствии с избыточностью.
Работает это за счет кластерной файловой системы VMFS, которая является сложным комплексным модулем зависимым от других модулей и состоящий из многих компонентов.
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.
Противоположность классики это SDS. Далее схемы с этой архитектурой.
Программно-определяемые системы хранения данных (SDS)
1. Р-Хранилище от Росплатформы
схема Р-Хранилища — SDS от Росплатформы
На схеме Р-хранилища изображено три сервера и два ethernet коммутатора. Это минимальная конфигурация почти для любого программно-определяемого хранилища. На каждом сервере имеются два диска для гипервизора, настроенные в RAID1 от аппаратного RAID контроллера на борту. Остальные три диска каждого сервера презентуются по JBOD/passthrough.
Служба метаданных обычно располагается на том же диске что и гипервизор, но может быть и на диске с ролью кэш, который используется в гибридной конфигурации.
Возвращаясь к клиенту-точке монтирования все данные записываются, используя лог структурированную файловую систему и делятся на блоки, где каждый блок записывается на своем диске, на котором его принимает чанк сервер, назначенный на этот диск.
Блоки и их копий раскладываются по разным дискам серверов по умолчанию, чтобы блок и его копия не встретились на одном сервере, но можно и переключать на более крупные локации такие как группы серверов или менее на диски.
Как показано на схеме ВМ или, другими словами, файлы образа диска ВМ и файл конфигурации ВМ все это для хранилища блоки данных. Р-хранилище размечает данные блоками по 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» могут хранится в большем количество копий.
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.
За всей координацией следят также области метаданных, которые размещаются на быстрых дисках и делятся на локальные мета, которые знают про расположение блоков на дисках этого сервера и глобальные, которые имеют карту расположения серверов.
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.
Вырисовывается сложная абстракция, группировка фрагментов данных чем не желе у вышеописанных решений и это вносит больше гибкости, и в тоже время минусы в виде издержек на распределение данных по этим уровням абстракций, а также сложность управления.
Заключение
В заключение можно сказать, что все подходы важно более детальнее изучить, что может помочь при разработке своего хранилища или в изучении, или тестировании новых продуктов, но при глубоком изучении станет сложнее сравнивать все эти решения между собой и вот почему:
Каждый из вариантов был разработан под определенные задачи, масштабы и занимает свою нишу. Лидеры по использованию в виртуализации это классические подходы от VMware (vmfs), RedHAt (lvm) и на третьем месте NTFS от Microsoft.
После классики идут уже программно-определяемые решения (SDS) и продвигается тенденция, что классика будет заменена на них, но пока что больше всего это используется у сервис и хостинг провайдеров. Среди SDS лидирует VMware vSAN, далее Nutanix, потом Ceph и на РФ рынке Р-хранилище. Реже использование S2D от Microsoft.
По поводу 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%.
Синтетические замеры производительности реплики 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), 2×480SSD для ОС, в каждой 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ТБ и интерконект 2×25Гбит, и 2×25Гбит сеть доступа по s3 и управления.
случайные операции чтения/запись
Далее нагрузка случайным профилем на этом же железе.
Последовательная скорость записи
А здесь уже непрерывно записывались данные, где кроме операции записи и чтения еще параллельно выполнялось удаление. Нагрузка уже шла по протоколу s3 поэтому само хранилище SDS не сильно было нагружено.
Удаление отложенное, особенно если это s3, так как в объектном хранении файлы-объекты делятся на блоки различных размеров. Для самых больших объектов хранятся в пуле-файле с размером блоков по 8МБ, а для самых мелких это 4КБ.
Когда удаляется объект, то остаются пустые блоки на уровне пулов-файлов, а так как s3 относится к хранению не структурированных данных, то еще применяется помехоустойчивое кодирование, где размеры экстентов-блоков на блочном уровне по 1МБ и включение очистки пустых блоков происходит по внутренней команде sync при условии, что пустых данных не меньше 75%, чтобы не создавать перекладку блоков во время операций записи или чтения данных.
Если переформулировать, то когда выполняется удаление s3 объектов, образуется фрагментация, которая препятствует физическому освобождению блоков.
Для виртуализации чаще всего применяется репликация, а в ней используются блоки размером 256 МБ. Во время удаления файлов очистка таких блоков происходит намного быстрее.
На этой интересной ноте пока все и низкой поклон всем кто дочитал такую сложную тему. Как появятся новые возможности тестирования с результатами или сравнениями, которые можно детально описать в статье, а также желание читателей и наличие вдохновения, то я напишу что-то новое.
