Изменения

Задержки часто обычно важнее простой пиковой производительности случайного чтения/записи, так как далеко не каждое приложение может загрузить диск при большом параллелизме / глубокой очереди (32-128 запросов).

Ceph — это SDS, его задержки всегда выше, чем у устройств при прямом доступе, и от этого никуда не денешься=== Тестирование дисков === [https://docs. В интернете есть доклад Nick Fisk «Lowgoogle.com/spreadsheets/d/1E9-Latency Ceph», в его исполнении Low latency это 0.7ms, то есть на лучший результат рассчитывать особенно не приходится. 0.7ms — это всего лишь примерно ~1500 iops в 1 поток.eXjzsKboiCCX-0u0r5fAjjufLKayaut_FOPxYZjc SSD Bench Google Docs]

{{Box|[[Файл:Warning icon.svg|32px|link=]] {{red|ВНИМАНИЕ!}} Для тех, кто в танке — fio-тест записи на диск ДЕСТРУКТИВНЫЙ. Не вздумайте запускать его на дисках/разделах, на которых есть нужные данные… например, журналы OSD (был прецедент).}} * Перед тестированием отключите попробуйте отключить кэш записи диска: {{Cmd|hdparm -W 0 /dev/sdX}} (SATA-диски через SATA или HBA), {{Cmd|1=sdparm --set WCE=0 /dev/sdX}} (SAS-диски). Не совсем ясно, почему, но эта операция на серверных SSD может увеличить IOPS-ы на 2 порядка(а может НЕ увеличить, поэтому пробуйте оба варианта — и W0, и W1). Также см.ниже [[#Картина маслом «Тормозящий кэш»]].

* Задержка случайного чтения: {{Cmd|1=fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX}}* Пиковые IOPS случайной записи: {{Cmd|1=fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=60 -filename=/dev/sdX}}* Задержка записи в журнал: {{Cmd|1=fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=write -runtime=60 -filename=/dev/sdX}} — также стоит повторить тот же тест с <tt>-fsync=1</tt> вместо <tt>-sync=1</tt> и принять худший результат, так как иногда бывает, что одним из методов sync игнорируется (зависит от контроллера).

«А почему так мало…» — см.нижесагу про конденсаторы. [[Файл:Warning icon.svg|32px|link=]] Когда разворачиваете Ceph OSD на SSD — очень разумно не отдавать её под Ceph целиком, а оставить небольшой раздел (10-20 гб) пустым для будущего использования под бенчмаркинг. Ибо SSD имеют свойство со временем (или при забивании данными под 80%) начинать тормозить. Очень удобно иметь возможность гонять fio на пустом никем не используемом разделе. ==== Лирическое отступление ==== Почему нужно тестировать именно так? Ведь в целом производительность диска зависит от многих параметров:* Размер блока* Режим — чтение, запись или смешанный режим чтение+запись в разных пропорциях* Параллелизм — размер очереди и число потоков, то есть, в целом число одновременно запрашиваемых у диска операций* Длительность теста* Исходное состояние — пуст, заполнен линейной записью, заполнен случайной записью, заполнен случайной записью на протяжении какого-то времени и т. п.* Распределение данных — например, 10% горячих данных и 90% холодных — или, например, определённое расположение горячих данных (в начале диска)* Другие смешанные режимы тестов, например, тестирование одновременно с разными размерами блоков Также и результаты можно интерпретировать с разной степенью детализации — вместо простого среднего числа операций или мегабайт в секунду можно также приводить графики, гистограммы, перцентили и так далее — это, естественно, даст больше информации о поведении тестируемого образца. Есть и философская сторона тестов — например, производители серверных SSD иногда заявляют о необходимости подготовки диска к тестам путём 2-х кратной полной случайной перезаписи, чтобы нагрузить слой трансляции адресов диска, а я считаю, что это на самом деле ставит SSD в неправдоподобно плохие по сравнению с реальной нагрузкой условия; есть сторонники рисования графиков формата «задержка в зависимости от числа операций в секунду», что я считаю немного странным, но тоже возможным подходом — в нём, по сути, строится график F1(q) в зависимости от F2(q) и график обычно получается достаточно замысловатый — но для каких-то применений, может быть, и тоже разумный. В общем, бенчмаркингом заниматься можно бесконечно, и уж несколько дней, чтобы предоставить полную информацию, точно уйдёт. Этим обычно и занимаются ресурсы типа 3dnews в своих обзорах SSD. А мы не хотим сидеть несколько дней. Мы хотим обозначить набор тестов, которые можно провести быстро и сразу составить примерное представление о производительности. Посему общая идея — выделить несколько наиболее «крайних» режимов, протестировать диск в них и представить, что остальная часть «амплитудно-скоростной характеристики» диска является некоторой гладкой функцией в пределах изменения параметров между крайними точками. Тем более, что каждому из крайних режимов соответствует и реальное применение в своей категории приложений:# Использующих в основном линейный или крупноблочный доступ. Для таких приложений наиболее важная характеристика — производительность линейного доступа в мегабайтах в секунду. Отсюда режим тестирования линейным доступом 4 МБ блоком со средней очередью — 16-32 операции. Результаты — только в МБ/с.# Использующих случайный доступ мелким блоком и при этом способных к распараллеливанию. Отсюда — режимы тестирования случайным доступом 4 КБ блоком (стандартный блок для большинства ФС и, плюс-минус, СУБД) с большой очередью — 128 операций или, если диск не удаётся нагрузить одним потоком CPU с глубиной очереди 128 — тогда в несколько (2-4-8 или больше) потоков по 128 операций. Результаты — только в iops. Задержку (latency) указывать не нужно, так как в данном тесте её можно произвольно увеличить, просто подняв размер очереди — задержка жёстко связана с iops формулой latency=queue/iops.# Использующих случайный доступ мелким блоком и при этом НЕспособных к распараллеливанию. Таких приложений больше, чем вы могли подумать — например, в части записи сюда относятся все транзакционные СУБД. Отсюда вытекают режимы тестирования случайным доступом 4 КБ блоком с очередью 1 и, для записи, с fsync после каждой операции, чтобы диск/СХД не могли нас обмануть и положить запись во внутренний кэш. Результаты — iops или latency, по желанию — но выберите что-то одно, так как числа, опять же, жёстко связанные. === Тестирование кластера Ceph === Как тестировать Ceph после сборки. ==== RBD ==== fio -ioengine=rbd. Нужно сделать следующее:# fio -ioengine=rbd -direct=1 -name=test -bs=4M -iodepth=16 -rw=write -pool=rpool_hdd -runtime=60 -rbdname=testimg# fio -ioengine=rbd -direct=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -pool=rpool_hdd -runtime=60 -rbdname=testimg# fio -ioengine=rbd -direct=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -pool=rpool_hdd -runtime=60 -rbdname=testimg# ...и потом то же самое для read/randread. Смысл в том, чтобы протестировать а) задержку в идеальных условиях б) линейную пропускную способность в) случайные iops-ы. Перед тестами чтения образ сначала нужно заполнить линейной записью, так как чтение из пустого образа очень быстрое :) Запускать нужно оттуда, где будут реальные пользователи RBD. В целом, с другого узла результаты обычно лучше. Также всё то же самое можно повторить изнутри виртуалки или через krbd:# fio -ioengine=libaio -direct=1 -name=test -bs=4M -iodepth=16 -rw=write -runtime=60 -filename=/dev/rbdX# fio -ioengine=libaio -direct=1 -sync=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -runtime=60 -filename=/dev/rbdX# fio -ioengine=libaio -direct=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=60 -filename=/dev/rbdX Заметьте, что при тестировании задержки через libaio добавилась опция -sync=1. Это не случайно, а соответствует режиму работы СУБД (транзакционная запись в 1 поток). В ioengine=rbd понятие sync отсутствует, там всё всегда «sync». ==== Отдельные OSD ==== ceph-gobench: https://github.com/rumanzo/ceph-gobench/ Либо https://github.com/vitalif/ceph-bench, что примерно то же самое. Родоначальник идеи — @socketpair Марк Коренберг ([https://github.com/socketpair/ceph-bench оригинал]). Бенчилка тестирует ''отдельные OSD'', что очень помогает понять, кто же из них тупит-то. Перед запуском надо создать пул без репликации {{Cmd|ceph osd pool create bench 128 replicated; ceph osd pool set bench size 1; ceph osd pool set bench min_size 1}} и с числом PG, достаточным, чтобы при случайном выборе туда попали все OSD (ну или прибить их вручную к каждому OSD upmap-ами). ==== CephFS ==== «Нормальных» инструментов для тестирования ФС, сцуко, нет!!! «Нормальный» инструмент — это такой инструмент, который вёл бы себя, как файловый сервер: случайно открывал, создавал/писал/читал и закрывал маленькие файлы среди большого общего количества, разбитые по набору каталогов Всё, что есть, какое-то кривожопое: bonnie++, например, зачем-то тестирует запись по 1 байту. iometer, fs_mark не обновлялись лет по 10, но и паттерн файл сервера не умеют. Лучшее, что умеют — это тест создания файлов. Пришлось написать свой ioengine для fio: https://github.com/vitalif/libfio_fileserver :) ==== S3 (rgw) ==== Предпочтительный вариант: [https://github.com/vitalif/hsbench hsbench] — ссылка дана на исправленную версию (!). Максимально простой, консольное Golang приложение. Оригинальная версия пока что имеет 2 неприятных бага: во-первых, вместо чтения объектов целиком читает только первые 64 КБ, во-вторых, производит последовательное, а не случайное, чтение. Что, например, с minio приводит к слишком оптимистичным результатам тестов. В моей данные баги исправлены. [https://github.com/intel-cloud/cosbench cosbench] — очень толстый, Java с Web-интерфейсом, XML-настройки. [https://github.com/minio/warp minio warp] — тестов чуть больше, чем в hsbench, но зато тестирует только 1 бакет и при каждом тесте загружает данные заново. ==== Что использовать не надо ==== * dd и hdparm для бенчмаркинга не использовать вообще никогда!!!* rados bench использовать тоже не надо, так как он создаёт для тестирования очень мало объектов (в 1 поток всего 2, в 128 — несколько сотен). «Случайная» запись в такое число объектов не очень-то и случайная.* rbd bench лучше тоже не использовать. В принципе, он адекватен, но fio всё равно лучше.* Не надо удивляться, если Ceph не может загрузить диски на 100 % при случайной записи. Он тормоз :) ==== Про RBD и параллелизм ==== [[File:Warning icon.svg|32px|link=]] Тестировать запись несколькими параллельными процессами (fio numjobs > 1) в один RBD-образ бесполезно. Из-за особенностей реализации RBD, в частности, из-за object-map, при параллельной записи из нескольких источников производительность СИЛЬНО проседает (в 2-10 раз). Можно отключить object-map, но это будет некорректный тест, т.к. в реальной эксплуатации в 99% случаев он нужен, так что с отключенным object-map вы лишь получите неправильный (слишком хороший) результат. Если вы не можете загрузить кластер одним процессом fio, то нужно создать несколько отдельных RBD-образов и запустить несколько процессов fio параллельно, каждый на своём RBD-образе. === Тестирование сети === sockperf. На одной ноде запускаем сервер: <tt>sockperf sr -i IP --tcp</tt>. На другой клиент в режиме ping-pong: <tt>sockperf pp -i SERVER_IP --tcp -m 4096</tt>. ВНИМАНИЕ: В выводе фигурирует '''половина''' задержки (задержка в одну сторону). Таким образом, для получения RTT её стоит умножить на 2. Нормальный средний RTT - в районе 30-50 микросекунд (0.05ms). <s>Также qperf. На одной ноде просто <tt>qperf</tt>. На второй <tt>qperf -vvs -m 4096 SERVER_IP tcp_lat</tt>.</s> qperf написан криво: 1) всегда использует для tcp_lat размер сообщения 1 байт!!! 2) не использует TCP_NODELAY. Так что его юзать, только если возьмёте его с моим патчем отсюда: [[Мой Debian репозиторий]].

Как тестировать Ceph после сборки[[Файл:Warning icon.svg|32px|link=]] Внимание: в Ubuntu на сетевую задержку негативно влияет AppArmor, его лучше отключить. Картина примерно такая (Intel X520-DA2):

* rados bench лучше не использовать — он создаёт для тестирования очень мало объектов (в 1 поток всего 2, в 128 — несколько сотен)centos 3. Из-за этого, например, на заполненном HDD результаты будут сильно оптимистичнее, так как снимается необходимость постоянного поиска метаданных в RocksDB.* fio в RBD10: {{Cmd|1rtt min/avg/max/mdev =fio -ioengine=rbd -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -pool=rpool_hdd -runtime=60 -rbdname=testimg}}** лучше запускать с другого узла — результат будет в 10.5 раза лучше, видимо, из-за отсутствия переключения контекстов между ceph OSD и fio039/0. можно запускать два теста параллельно, bluestore любит параллелизм — суммарный результат вполне может оказаться ещё в 2 раза лучше053/0.132/0.012 ms** для мазохистов — параметр iodepth=128 поменять на iodepthubuntu 4.x + apparmor: rtt min/avg/max/mdev =10. цифра будет раз в 20 хуже и она будет отражать то, сколько примерно TPS сможет выполнить ваша OLTP СУБД изнутри Ceph068/0.* Встроенной утилитой {{Cmd|rbd bench --io-size 4096 --io-threads 64 --io-total 10G --io-pattern rand --io-type write rpool_hdd163/testimg}}* Можно тестировать и fio изнутри виртуалки, rbd драйвер нормально создаёт параллельную нагрузку — проверено0.230/0.029 ms* Производительность может отличаться на заполненном и незаполненном RBD-образеubuntu 4. Но отличия небольшие, думать, что там будет разница в несколько раз — не нужно.* При тестировании случайной записи в ceph в один поток (fsyncx: rtt min/fdatasyncavg/syncmax/iodepthmdev =10.037/rados bench -t 1) вы фактически всё время тестируете ОДИН диск0. То есть, всё время тестируются разные диски, но в каждый отдельный момент времени запрос идёт '''только к одной placement group''' (тройке-четвёрке-пятёрке дисков)071/0.* Соответственно, вы '''не увидите''' 100 % утилизации дисков на хостах при тестировании в один поток, однопоточная нагрузка '''не может''' полностью загрузить кластер157/0.018 ms

== Производительность случайной О транзакционности записи ==

{{[[Файл:Warning}} Сначала плохая icon.svg|32px|link=]] Плохая новость!

Важная особенность Ceph — ''вся запись, даже та, для которой никто этого явно не просит, ведётся транзакционно''. То есть, никакая операция записи не завершается, пока она не записана в журналы всех OSD и не сделан fsync() диска. Так сделано, чтобы предотвращать [[#RAID WRITE HOLE]]-подобные ситуации рассинхронизации данных между репликами при отключении питания, потере сети и т.п…

Сама запись на устройство и репликация с других OSD происходит отложенно и асинхронноЕсли конкретизировать сильнее, но какая разница — это означает, что Ceph не использует никакие буферы записи дисков (наоборот, он делает всё, чтобы эти буферы всё время очищать). Это не значит, что буферизации записи нет вообще — она все равно создаёт дополнительную нагрузку есть на уровне клиентов (page cache в linux, кэш RBD устройства и притормаживает последующие запросына уровне драйвера librbd qemu…). Но именно внутренние дисковые буферы не используются.

Всё это Это приводит к тому, что типичная настольная SSD-шка под журналом в Ceph выдаёт '''неприлично низкие IOPS-ы''' — обычно от 500 до 2000. И это при том, что при обычном тестировании почти любая SSD выдаёт > 20000 iops. Даже самый паршивый китайский noname выдаёт не менее 10000 iops. NVMe легко выжимает 150000 и больше. Но стоит начать использовать fsync… и та же NVMe выдаёт 600 iops (на 2.5 порядка меньше).

{{Box|1={{Note}} Старый FileStore В общем, чтобы понять, сколько у вас теоретически может быть IOPS-ов на плохих дисках быстрее BlueStore где-то запись в Ceph, диски под него нужно тестировать с опциями fio '''sync=1iodepth=1'''.5 раза. На хороших FileStore менее латентный, то есть, даёт больше iops в один поток Это даст «журнальные» иопсы (меньше задержки). Но это не значит, что его надо использовать — производительность последовательного коммита операций по остальным параметрам FileStore устарел. Например, снапшоты там работают со скоростью снапшотов LVM (очень медленноодной), нет частичной перезаписи объектов в EC-пулах, нет контрольных сумм (вследствие чего вообще нельзя использовать size=2). Также CPU filestore жрёт сильнее и пиковые параллельные IOPS-ы у него хуже bluestore.}}

В общем, чтобы понять, сколько у вас будет IOPS-ов на запись в Ceph, диски под него нужно тестировать с опцией fio '''fsync=1'''. Или Другие почти идентичные варианты: fdatasync=1, если тестируете (в файле поверх ФС. Или можно sync=1 iodepth=1, эффект обычно почти тот же, что от ) либо fsync=1(на голом девайсе). Разница между опциями (см. man fio):* fsync=1 синхронизирует данные и метаданные тестируемого файла отдельным запросом после каждой операции записи. Именно так Так работает BlueStore. Именно поэтому мы будем использовать именно эту опцию.

* sync=1 использует O_SYNC и синхронный ввод/вывод, то есть, каждая операция начинается только после завершения предыдущей. Но штука в том, что почти все движки fio при этом открывают файл с O_SYNC. А вот O_SYNC уже означает, что каждая операция записи внутри сопровождается аналогом fsyncТак работает FileStore. *: Но при этом если ещё нужна опция iodepth > =1, то иначе в очередь диска до синхронизации «пролезает» несколько операций и IOPS-ы растут, тест перестаёт быть эквивалентным записи с fsync=1тестом журнала.

== Конденсаторы! ==

Нас спасёт такое чудо инженерной мысли, как '''SSD с конденсаторами''' (точнее, обычно или с суперконденсаторами — ионисторами). Которые на M.2 SSD, кстати, прекрасно видны невооружённым глазом(только тут это не ионисторы :)):

При этом '''IOPS-ы транзакционной записи становятся равны IOPS-ами ам нетранзакционной'''.

И ещё один вариант — Intel Optane. Это тоже SSD, но они основаны не на Flash памяти (не NAND и не NOR), а вообще на другой технологии, называющейся 3D XPointPhase-Change-Memory «3D XPoint». Хз, как она работает, но По спецификации заявляются 550000 iops при полном отсутствии необходимости в стирании блоков, кэше и конденсаторах. Но если даже задержка такого диска и равна 0.005мс (она действительно равна), то задержка Ceph всё равно 0.5-1мс, соответственно, с Ceph оптаны использовать чуть менее, чем бессмысленно — за большие деньги (1500$ за 960 гб, 500$ за 240 гб) вы получите не сильно лучший результат. == Bluestore vs Filestore == Блюстор — «новое» хранилище. От «нового» хранилища честно ожидаешь лучшей или хотя бы не худшей производительности во всех сценариях. Однако это, увы, не совсем так. Что лучше в Bluestore? * Ликвидирована двойная запись при линейной записи. Линейная запись быстрее в честных 2 раза практически в любых конфигурациях.* Отложенная запись, эффективная для HDD (и, частично, для очень плохих SSD). iops случайной записи в HDD-only конфигурациях почти в 2 раза больше, чем в Filestore. Правда, речь об iops на HDD не идёт в принципе, поэтому вся разница — 33 или 66 iops на 1 HDD.* Возможность использования EC под CephFS и RBD благодаря реализованной частичной перезаписи объектов в EC-пулах.* Эффективные снапшоты (благодаря «виртуальным клонам»): после снятия снапшота iops практически не падают, в отличие от Filestore, в котором они падают до считанных сотен даже на NVMe, так как при перезаписи даже 4 КБ после снятия снапшота в Filestore копируется целый 4 МБ объект.*: [[Файл:Warning icon.svg|32px|link=]] Увы, это относится только к '''rbd snapshot''', но не к '''rbd clone'''. Клоны неэффективны в Bluestore точно так же, как и в Filestore. Запись 4 КБ в клон точно так же выливается в копирование 4 МБ.* Это не так критично, но в Bluestore есть поддержка сжатия и контрольных сумм данных. А что хуже? В целом, претензии сводятся к производительности: * Гораздо хуже производительность случайной записи на SSD+HDD, SSD-раздел не работает как буфер для быстрой записи. Bluestore не пишет быстрее, чем может в среднем сам HDD. То есть, с SSD-журналом и Filestore будет 1000—2000 иопс случайной записи, ас Bluestore (и без bcache)  — 200—300. 1000—2000, конечно, упадёт до 100 или даже ниже, когда у Filestore забьётся журнал и его придётся сбрасывать — но тем не менее, «буфер» для сглаживания пиков Filestore предоставляет. А Bluestore — нет.*: И проблема не только в применении том, что параметры по умолчанию — deferred_batch_ops и max_deferred_txc — задают частый сброс операций на медленный диск (раз в 64 операции). Проблема ещё в том, что в Bluestore отсутствуют механизмы фоновой очистки «журнала» (очереди отложенной записи). Поэтому, когда очередь забивается, производительность просто падает до HDD-шной до перезапуска OSD. Ну и сама очередь находится в RocksDB, поэтому сильно поднимать её размер, по идее, неполезно.* До 1.5-2 раз хуже latency случайной записи на SSD/NVMe (All-Flash), ибо накладных расходов на каждую операцию записи у Bluestore больше.* Жор памяти больше. Да, у Filestore много занимал pagecache, но Bluestore меньше 2 ГБ памяти не жрёт вообще никогда. Причиной тому — RocksDB (одни только memtable-ы с дефолтными настройками съедают 1 ГБ памяти) и собственный кэш метаданных и данных (Bluestore не может использовать pagecache).* Фрагментация приводит к Ceph — нужно проверять — снижению скорости чтения. Также BlueStore делает огромное количество fsync-ов (что очень смешно — даже больше, чем запросов записи), из-за чего не факттерпит десктопных SSD под журналом. Но FileStore работает похоже, и кардинальных различий производительности это не вносит. Как полечить высокие задержки на SSD+HDD? * Либо вместо журнала (или рядом с журналом) сделать на SSD bcache для HDD.* Либо использовать HDD с SSD Cache, Media Cache или аналогом (перманентным кэшем случайной записи на пластинах). Например, в старых дисках HGST это включается при отключении волатильного кэша командой `hdparm -W 0 /dev/sdXX`. В новых, похоже, включено всё время. === Тест на 1 NVMe === Threadripper 2920X, NVMe Intel P4500, localhost. 1 OSD без репликации, 8 PG, чтобы не упираться в блокировки, 1 маленький RBD образ 10 Гб. Журнал Filestore 1 GB, чтобы в тестах успевал начинаться сброс. Bluestore 4k — это min_alloc_size и prefer_deferred_size = 4096 (4k запись идёт через redirect-write), Bluestore 16k — 16384 (4k запись идёт через deferred). <tab sep="bar" head="topleft" class="wikitable">| Filestore | Bluestore 16k | Bluestore 4k |bs=4M iodepth=16 rw=write | 950 MB/s | 1700 MB/s | 1700 MB/s |bs=4M iodepth=16 rw=read | 1250 MB/s | 1300 MB/s | 1300 MB/s | После полной линейной перезаписи + drop_cachesbs=4M iodepth=16 rw=read | 1250 MB/s | 450 MB/s | 320 MB/s | После 33 % случайной перезаписи блоком min_alloc_sizebs=4k iodepth=1 rw=randwrite | 3900 iops | 3200 iops | 2500 iops |bs=4k iodepth=128 rw=randwrite | 19100 iops | 19500 iops | 25500 iops |bs=4k iodepth=1 rw=randwrite | 180 iops | 2800 iops | 2500 iops | Сразу после снятия snapshot-а RBDbs=4k iodepth=128 rw=randwrite | 180 iops | 8800 iops | 15600 iops | Сразу после снятия snapshot-а RBDbs=4k iodepth=1 rw=randread | 3900 iops | 4500 iops | 4500 iops | После drop_caches / перезапуска OSDbs=4k iodepth=1 rw=randread | 6300 iops | 4500 iops | 4500 iops | Прогретый кэшbs=4k iodepth=128 rw=randread | 33000 iops | 32000 iops | 33000 iops |RAM | 270 MB | 2 GB + | | Filestore также использует произвольный объём page cacheCPU randwrite Q=128 | 600 % | 550 % | |</tab> === Про размер block.db === '''Внимание:''' актуально до Ceph 14. Начиная с Ceph 15, благодаря добавленным «allocation hints» RocksDB, Bluestore стал нормально утилизировать раздел block.db. Для истории — это коммит 5f72c376deb64562e5e88be2f22339135ac7372b, там добавили опцию bluestore_volume_selection_policy. Дальше стоит читать, только если у вас всё ещё проблемы со spillover-ами. Спилловер — это когда вы собрали Bluestore на SSD+HDD, выделив SSD под базу (block.db), но при этом эта самая база постоянно частично утекает на HDD. При этом она, вроде бы, даже влезает в SSD с запасом — но всё равно утекает. Начиная с Ceph 14 Nautilus о спилловерах предупреждает <tt>ceph -s</tt>. Когда случается спилловер в SSD+HDD конфигурациях, работа кластера замедляется — в большей или меньшей степени, в зависимости от размеров RocksDB и паттерна нагрузки, так как когда метаданных не очень много, они влезают в кэш OSD — либо onode cache, либо rocksdb cache, либо, если включено bluefs buffered io — то ещё и в системный page cache. Если кэш-промахов достаточно много, или если OSD упирается в compaction RocksDB, могут даже появляться slow ops-ы. Так в чём же дело и как это победить? А дело в том, что с выбором раздела для очередного файла БД (RocksDB организована в виде набора файлов) «есть нюанс», точнее, даже два. '''Нюанс № 1:''' RocksDB кладёт файл на быстрый диск только когда считает, что на быстром диске хватит места под все файлы этого же уровня (для тех, кто ещё не в курсе — RocksDB это [https://github.com/facebook/rocksdb/wiki/Leveled-Compaction LSM база]). Дефолтные настройки цефа:* 1 Гб WAL = 4x256 Мб* max_bytes_for_level_base и max_bytes_for_level_multiplier не изменены, поэтому равны 256 Мб и 10 соответственно* соответственно, L1 = 256 Мб* L2 = 2560 Мб* L3 = 25600 Мб и т. д. …Соответственно! Rocksdb положит L2 на block.db, только если раздел имеет размер хотя бы 2560+256+1000 Мб — округлим вверх до '''4 ГБ'''. А L3 она положит на block.db, только если block.db размером хотя бы 25600+2560+256+1000 МБ = около '''30 ГБ'''. А L4, соответственно, если ещё +256 ГБ, то есть итого '''286 ГБ'''. Иными словами, имеют смысл только размеры раздела block.db 4 ГБ, 30 ГБ, 286 ГБ. Все промежуточные значения бессмысленны — место сверх предыдущего граничного значения использоваться не будет. Например, если БД занимает 10 ГБ, а раздел SSD — 20 ГБ, то фактически на SSD ляжет только WAL (1 ГБ), L1 и L2 (256 МБ + 2.56 ГБ). L3, составляющий бОльшую часть базы, уедет на HDD и будет тормозить работу. При этом 4 ГБ — слишком мало, 286 ГБ — слишком много. Так что, по сути, правильно делать block.db размером 30 ГБ для OSD любого размера. Ещё раз повторюсь: это актуально до Ceph 14, с Ceph 15 уже не актуально. Кстати, из этого же следует то, что официальная рекомендация — выделять под block.db то ли 2 %, то ли 4 % от размера устройства данных — полный отстой. Но что делать, если у вас разделы другого размера? Например, 80 ГБ, и вы по каким-то причинам не хотите делать bcache, но хотите использовать эти 80 ГБ по максимуму. В этом случае можно поменять базовый размер уровня RocksDB (max_bytes_for_level_base). multiplier менять не будем, оставим по умолчанию 10 — его значение влияет на итоговое количество уровней RocksDB, а это уже более тонкая материя. Теоретически, меньшее число уровней снижает read и space amplification, но замедляет compaction и из-за этого может сильно повысить итоговый write amplification. Также есть тема с уменьшением размера отдельных memtable и кратным увеличением общего их числа, то есть, например, установки 32*32 МБ вместо дефолтных 4*256 МБ и min_write_buffer_to_merge=8, но эффект от этого тоже не совсем понятен (возможно, немного экономится CPU при compaction-е), так что это тоже пока лучше не трогать. Так как каждый уровень отличается от предыдущего в 10 раз, общий размер раздела БД должен быть равен k*X, где k — коэффициенты из ряда: 1, 11, 111, 1111 и т. п. (по числу уровней RocksDB). Значит, мы можем взять размер нашего block.db, вычесть из него 1 ГБ WAL (лучше даже вычесть с запасом 2 ГБ) и делить его последовательно на каждую из цифр до тех пор, пока не получим значение, близкое к 256 МБ … 1 ГБ. Это значение округлить вниз, принять за базовый размер уровня RocksDB и прописать в конфиг как max_bytes_for_level_base. База компактится по 256 МБ за раз, так что меньше 256 МБ размер первого уровня ставить точно смысла нет. Например, для 80 ГБ раздела это будет 719 МБ, только не забываем считать всё в двоичных мегабайтах — MiB. Остаётся прописать это значение в конфигурацию (bluestore_rocksdb_options = …,max_bytes_for_level_base=719MB), перезапустить OSD и сделать ручной compaction (можно дважды). '''Нюанс № 2:''' При ручном compaction-е RocksDB переписывает уровни целиком. Если при этом на SSD нет запаса места в размере этого уровня, то уровень, опять-таки, утечёт на HDD и так там и останется, ибо перемещать после compaction-а его обратно она не умеет. Теоретически, если после этого сделать compaction ещё раз, то уровень должен вернуться на SSD (поэтому выше дана рекомендация делать ручной compaction дважды). Однако по сведениям из чата якобы бывает так, что один-два файла *.sst на SSD не возвращается. Чтобы это побороть на 100 %, можно предусмотреть на SSD-разделе ещё и запас в размере первого + последнего уровня БД. В этом случае коэффициенты вместо 1-11-111-1111 превращаются в 2-22-212-2112 и т. п. == RGW vs Minio == Вопрос частый, так как Ceph и Minio — две наиболее распространённые реализации S3. Сравнение, как всегда, не совсем честное, так как в Minio «бесконечного масштабирования» и произвольных схем избыточности нет. Есть только erasure коды, которые оперируют группами дисков, кратными по количеству 4 или 16 дискам. Расширения кластера в Minio раньше не было вообще сможет выжать , потом в каком-то смысле появилось через создание дополнительных зон. Таких же гарантий целостности, как в Ceph, в Minio тоже нет. Minio работает поверх обычных ФС, даже не делая fsync данных. На практике ext4, правда, делает sync автоматически раз в 5 секунд, да и Minio пишет с O_DIRECT, так что не совсем всё плохо — но тем не менее, потенциально небольшие потери при отключении питания возможны. Особенно классный перл был в баге https://github.com/minio/minio/issues/3478: <blockquote>Minio in this case is working as intended, minio cannot be expanded or shrinkable in this manner. Minio is different by design. It is designed to solve all the needs of a single tenant. Spinning minio per tenant is the job of external orchestration layer. Any addition and removal means one has to rebalance the nodes. When Minio does it internally, it behaves like blackbox. It also adds significant complexity to Minio. Minio is designed to be deployed once and forgotten. We dont even want users to be replacing failed drives and nodes. Erasure code has enough redundancy built it. By the time half the nodes or drives are gone, it is time to refresh all the hardware. If the user still requires rebalancing, one can always start a new minio server on the same system on a different port and simply migrate the data over. It is essentially what minio would do internally. Doing it externally means more control and visibility. Minio is meant to be deployed in static units per tenant.</blockquote> Короче, всё работает как надо, в минио нет возможности расширения, если у вас будут ломаться диски — не меняйте, просто дождитесь, пока из них строя выйдет половина дисков и пересоздайте кластер. На самом деле всё не так печально, можно заменить диск и запустить heal, но, конечно, без той же прозрачности, что в Ceph — оно будет просто сканировать все объекты и проверять отсутствующие. Если дисков много, это очень накладно. Ещё Minio хранит объекты в виде обычных файлов, даже не шардируя каталоги (соответствующие бакетам) по подкаталогам, плюс на каждый объект ещё создаёт директорию с парой файлов метаданных. Ну а директории в ФС по миллиону файлов — это, естественно, удовольствие ниже среднего. Хотя просто для раздачи оно, благодаря всяким dir_index-ам, работает. Для представления о производительности проведём простой тест Ceph (bluestore) vs Minio (ext4) на 1 HDD. Да, я знаю, что это тупо и нужно ещё хотя бы посравнивать их iopsна SSD. Но всё-ы бтаки результаты довольно показательны. Да и объектное хранилище чаще холодное/прохладное и строится на HDD, а не на SSD. Тест делался через [https://github.com/vitalif/hsbench hsbench]. Заключался в заливке примерно 1.1 миллиона объектов в 1 бакет, потом сброса кэшей и перезапуска Ceph/Minio, и потом — их раздачи в случайном порядке, а также проверки скорости выполнения операций листингов. Результаты:* Заливка в 32 потока: Minio — 305 объектов в секунду, RGW — 135 объектов в секунду. RGW indexless — 288 объектов в секунду.* Раздача в 32 потока: Minio — 45 объектов в секунду, RGW — 78 объектов в секунду* Листинги в 32 потока: Minio — после сброса кэша 35 сек, после прогрева — 2.9 сек с разбросом от 0.5 до 16 сек. RGW — стабильно — 0.4 сек Да, заливка в Minio быстрее. Но, во-первых, меньшая скорость заливки — это цена, во-первых, консистентности (fsync) вариант дорогой, раза а во-вторых, bucket index-а и bucket index log-а, которые позволяют RGW, например, делать геосинхронизацию (multisite), чего в 3 дороже типичной Minio нет. Кроме того, индексы в RGW можно положить на отдельные SSD (1500$ как обычно все и делают), а если же вам совсем не нужны листинги, синхронизация и прочее, в Ceph бакеты можно сделать безиндексными (indexless), и тогда оверхед bucket index-а вообще исчезает, как и возможные проблемы с его шардированием. == Снапшоты == В реализации снапшотов в Ceph есть целый ворох проблем из-за 960 гбколичества параллельных реализаций и общего накопленного архитектурного бардака: * На уровне RADOS снапшоты свои и их уже 2 вида: снапшоты пулов и снапшоты объектов.* На уровне RBD тоже свои снапшоты, причём они отличаются от RADOS-снапшотов, хоть внутри и реализованы частично через них. RBD снапшоты, можно сказать, не юзабельны ни для чего, кроме быстрого снятия бэкапов, 500$ за 240 гбкоторым тут же следует удаление снапшота. Откат к RBD снапшотам очень медленный и реализован не просто ужасно, а отвратительно — копированием содержимого снапшота поверх образа, ''даже неизменённых частей''. Кроме того, при откате цепочка последующих снапшотов уничтожается. Кроме того, есть прикол с жором места — см. на 2 пункта ниже.* В Bluestore снапшоты эффективны — после снятия снапшота случайная запись практически не замедляется, в отличие от Filestore, где принцип работы снапшотов схож со старым LVM и при записи даже 4 КБ после снятия снапшота соответствующий 4 МБ объект копируется целиком.* Но при этом эта оптимизация снапшотов — «виртуальные клоны» — реализована именно на уровне Bluestore, ни клиент, ни OSD о ней ничего не знают и поэтому она… ломается при ребалансе. Выглядит это так: ты добавляешь в кластер диск, он заполняется, а доступного места больше не становится. Почему? Потому что изначально, при записи, Bluestore получил запрос «клонировать 4 МБ объект в новую версию» и сделал это внутри себя, реально не копируя данные, а потом перезаписал 4 КБ. А при ребалансе эта связь порвалась и объект стал занимать все 4 МБ… Fail.* Также на уровне RBD есть клоны, которые, с одной стороны, более юзабельны — реализованы они через ссылку на родительский образ, соответственно, откат к такому «снапшоту» быстрый — достаточно просто создать новый клон. С другой стороны, для клонов не работает эта самая блюсторовская оптимизация, поэтому они опять-таки копируют объекты целиком при любой записи… что выливается в 40 иопс на запись (QD=1)в свежий клон даже в NVMe кластере.* В CephFS ещё одна реализация снапшотов, и там отката нет вообще. В общем, наговнокодили — мама не горюй… == EC == EC ещё больше снижает iops-ы, так как добавляется цикл Read-Modify-Write. [[#RAID WRITE HOLE]] в цефе закрыт, поэтому при записи все OSD сначала делают вторые копии объекта (по-видимому, виртуальные, через тот же механизм virtual clone bluestore), а потом удаляют старые. В моём примере на NVMe-шках — write iops с репликацией Q=1 примерно 1500, а с EC — примерно 500. Q=128 — примерно 25000 с репликацией и 10000 с EC. === Про вероятность потери данных === Смотрите мой калькулятор вероятности потери данных в кластере: https://yourcmc.ru/afr-calc/

* Если не выкинули RAID — отключайте все кэши контроллера, чтобы уменьшить влияние прослойки и не страдать при разряде батарейки / перемещении диска в другой сервер... и молитесь :). Наверное, в теории можно выжить и с включенным кэшем, но это стрельба себе в ногу.* Даже если у вас HBA — имейте в виду, что некоторые HBA (в частности, Adaptec) могут всё равно не сбросить кэш корректно и устроить вам Cloudmouse при отключении питания. Но по крайней мере точно известно, что LSI ведут себя нормально.* Хороший пост про RAID-кэши в списке рассылки: http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-July/036237.html - если вкратце - человек, админивший 6000 OSD, пишет, что никогда больше не свяжется с RAID0-режимами.

* При подключении через SATA или HBA контроллер не забывайте для '''серверных''' SATA дисков сделать {{cmd|hdparm -W 0 /dev/sdX}}, для SAS — {{cmd|1=sdparm --set WCE=0 /dev/sdX}}.* Для SAS и NVMe можно попробовать включить включайте blk-mq(ну или юзайте свежие ядра, в районе 4. Для 18 оно включается по умолчанию). Но для SATA blk-mq обычно бесполезно бесполезен или почти бесполезнобесполезен.

* Оценка производительности кластера просто по спецификациям входящих в него SSD не совсем верна, причём в обе стороны:дисков — абсолютно неправильна.** Речь о Bluestore. Под iops понимаются iops случайного чтения/записи блоками по 4 кб. 1 HDD (обычный, видимо7200 rpm, за счёт параллелизмане SMR, выдаёт чуть больше iops-ов даже на SSD без конденсаторов, чем просто те же ssd могут выдать с fsync — я лично смог добиться от тестового пула на 3-х Intel SSDSC2KW256G8 8000 iops (случайная записькэша), хотя сами ssd с fsync выдают примерно 5500 — это:*~100-120 iops при QD=128* И обратно, даже если SSD мегабыстрая, цеф — это огромный оверхед, он жрёт проц и никаких 220000 ~66 iops из одной SSD не выжмет. См. ниже [[#Пример теста от Micron]] — там в суперкрутом сетапе у них вышло всего 8750 iops в пересчёте на при QD=1 * ~40 MB/s линейного чтения/записи* При недостатке памяти показатели будут хуже, так как будут cache miss по метаданным 1 быстрый SSD или NVMe SSD (но это у них без SPDK/DPDKс конденсаторами, write iops >= 25000).:* Правильное применение для всяких оптанов ~1000 iops на запись при QD=1, в зависимости от частоты CPU и супербыстрых NVMe этонастроек может быть от 300 до, видимов самом идеальном случае, журналы, но какое на практике увеличение ~2500 iops.* Максимум до ~10000-ов 20000 iops на запись при добавлении условно оптана к тем же обычным серверным ssd — опять же, сходу не ясноQD=128 на 1 OSD.* Увеличение IOPSНа чтение показатели примерно в 2-ов Ceph обычно сопровождается увеличением жора CPU. CPU нужны хорошие2. 5 раза лучше:QD=1 ~2000 iops (максимум до ~4000), QD=128 ~20000, максимум до 50000.** Примечание: лучше Естественно, показатель QD=128 не может быть больше гигагерцев, но меньше сокетов (и возможно ядер, если они неравноправныечем показатель самого диска :). Но так как хорошие SSD в параллельном режиме обычно быстрые — этого не замечаешь.* Однопоточные IOPS-ы целиком и полностью зависят от задержекСоздав несколько OSD на одном диске, можно умножить число QD=128 iops на число OSD (пока диск позволяет). Важно всё — дискиЕстественно, процессор, контроллер, сетевая карта, коммутатор, Infiniband и SPDKценой аналогичного увеличения жора CPU.* Скорость линейного чтения/DPDK по возможностизаписи примерно равна скорости линейного чтения/записи самого диска. Да * Кардинальной разницы по iops между SATA SSD и сам Bluestore латентнеедаже NVMe, чем Filestore… хотяесли у обоих есть конденсаторы — нет. Это не отменяет того, с другой сторонычто NVMe лучше, разница — условных 280 или 350 iops но на дискахслучайном доступе это заметить трудно.* На актуальных SSD чтение QD=1 часто бывает медленнее записи QD=1, которые сами по себе могут так как писать можно в быстрый кэш, а читать можно только из реальной памяти. Разница бывает примерно такая: на порядок-два большечтение при QD=1 8000 iops, что, имхо, непринципиальноа на запись 40000 iops.* Лайфхак для ускорения однопоточной нагрузкиИтоговые показатели: mdadm RAID 0 * Линейное чтение из RBDкластера = Число OSD * MB/s одного OSD* Линейная запись в реплицированный пул = Число OSD / Репликация * MB/s одного OSD* Линейная запись в EC-образов внутри самой виртуалки.пул = Число OSD / (K+M) * K * MB/s одного OSD* Лайфхак для очень быстрых дисковС iops всё сложнее, так как репликация вносит нелинейный эффект в масштабирование. Но, условно говоря: несколько ** iops QD=1 — усредняются по всем OSD , а iops QD=128 — суммируются** При этом на одном диске.1 RBD клиента можно получить лишь до ~30000 iops на чтение и ~15000 iops на запись* Гипотетический монстр производительности в вакууме: мощные процыЕстественно, Intel NVMe, Infiniband или Intel 25если что-40GbE, SPDK/DPDK.то упирается в сеть — соответствующая цифра обрезается показателем сети

Дано=== O_SYNC vs fsync vs hdparm -W 0 === У SATA и SCSI дисков есть два способа сброса кэша: 3 компа команда FLUSH CACHE и флаг FUA (Force Unit Access) на команде записи. Первый — это явный сброс кэша, второй — это указание записать операцию на диск, минуя кэш. Точнее, у SCSI оно есть, а с 3x 7200rpm SATA HDD (ситуация точно не ясна: в одном 4x HDDспецификации NCQ бит FUA есть, но по факту FUA большинством дисков вроде как не суть важноподдерживается и, соответственно, эмулируется ядром/контроллером (если контроллер не кривой). По всей видимости, fsync() отправляет диску команду FLUSH CACHE, а открытие файла с O_SYNC устанавливает бит FUA на все команды записи. Есть ли разница? Обычно нет. Но на некоторых контроллерах и/или с некоторыми настройками различия по неустановленным причинам встречаются. И тогда fio -sync=1 и fio -fsync=1 начинают давать разные результаты — возможно, даже на порядки разные результаты. Кроме того, у дисков есть команда отключения кэша. Когда он отключен, запросы сброса (fsync) Linux диску не отправляет. Казалось бы, такой режим тоже должен быть эквивалентен выполнению fsync и/или O_SYNC после каждой команды. Но и это не всегда так! На SSD с конденсаторами (то есть серверных моделях с Advanced Power Loss Protection) при отключении кэша iops-ы случайной записи часто вырастают на порядок (например, с 5000 до 40000). Но не всегда, так как это, опять-таки, зависит от контроллера. Почему? По-видимому, потому, что команда FLUSH CACHE трактуется диском как «сбрось все кэши» (включая энергонезависимый), а отключение кэша — как «отключи энергозависимый кэш» (а энергонезависимый можешь оставить включенным). Соответственно, запись со сбросом кэша становится медленнее, чем просто отключённый кэш. А что с NVMe? В NVMe разнообразие чуть меньше — возможность отключить кэш в спецификации не предусмотрена вообще, но точно так же есть команды FLUSH CACHE и бит FUA. При этом по личным наблюдениям FUA часто игнорируется то ли диском, то ли Linux-ом, и <tt>fio -sync=1</tt> выдаёт с NVMe такие же результаты, как и без sync вообще. <tt>-fsync=1</tt> при этом ведёт себя как надо и приземляет производительность туда, где ей самое место (на десктопных NVMe — до тех же 1000—2000 iops). P.S: Bluestore использует fsync. Filestore использует O_SYNC. === Серверные SSD === Disabling cache is not a joke! <tt>fio -ioengine=libaio -name=test -filename=/dev/sdb -(sync|fsync)=1 -direct=1 -bs=(4k|4M) -iodepth=(1|32|128) -rw=(write|randwrite)</tt> '''Micron 5100 Eco 960GB''' <div style="float: left"><div>'''Запись'''</div><tab sep="bar" head="top" class="wikitable">sync или fsync | bs | iodepth | rw | hdparm -W 1 | hdparm -W 0sync | 4k | 1 | write | 612 iops | 22200 iopssync | 4k | 1 | randwrite | 612 iops | 22200 iopssync | 4k | 32 | randwrite | 6430 iops | 59100 iopssync | 4k | 128 | randwrite | 6503 iops | 59100 iopssync | 4M | 32 | write | 469 MB/s | 485 MB/sfsync | 4k | 1 | write | 659 iops | 25100 iopsfsync | 4k | 1 | randwrite | 671 iops | 25100 iopsfsync | 4k | 32 | randwrite | 695 iops | 59100 iopsfsync | 4k | 128 | randwrite | 701 iops | 59100 iopsfsync | 4M | 32 | write | 384 MB/s | 486 MB/s</tab></div><div style="float: left; margin-left: 10px"><div>'''Чтение'''</div><tab sep="bar" head="top" class="wikitable">bs | iodepth | rw | результат4k | 1 | randread | 6000 iops4k | 4 | randread | 15900 iops4k | 8 | randread | 18500 iops4k | 16 | randread | 24800 iops4k | 32 | randread | 37400 iops4M | 1 | read | 460 MB/s4M | 16 | read | 514 MB/s</tab></div><div style="clear:both"></div> Результаты по чтению не отличаются на hdparm -W 0 и 1. '''Seagate Nytro 1351 XA3840LE10063''' Диск заполнен почти полностью, на 90-100 %. <div style="float: left"><div>'''Запись'''</div><tab sep="bar" head="top" class="wikitable">sync или fsync | bs | iodepth | rw | hdparm -W 1 | hdparm -W 0sync | 4k | 1 | randwrite | 18700 iops | 18700 iopssync | 4k | 4 | randwrite | 49400 iops | 54700 iopssync | 4k | 32 | randwrite | 51800 iops | 65700 iopssync | 4M | 32 | write | 516 MB/s | 516 MB/sfsync=1 | 4k | 1 | randwrite | {{red|288 iops}} | 18100 iopsfsync=1 | 4k | 4 | randwrite | {{red|288 iops}} | 52800 iopsfsync=4 | 4k | 4 | randwrite | 1124 iops | 53500 iopsfsync=1 | 4k | 32 | randwrite | {{red|288 iops}} | 65700 iopsfsync=32 | 4k | 32 | randwrite | 7802 iops | 65700 iopsfsync=1 | 4M | 32 | write | 336 MB/s | 516 MB/s</tab></div><div style="float: left; margin-left: 10px"><div>'''Чтение'''</div><tab sep="bar" head="top" class="wikitable">bs | iodepth | rw | результат4k | 1 | randread | 8600 iops4k | 4 | randread | 21900 iops4k | 8 | randread | 30500 iops4k | 16 | randread | 39200 iops4k | 32 | randread | 50000 iops4M | 1 | read | 508 MB/s4M | 16 | read | 536 MB/s</tab></div><div style="clear:both"></div> Если не хотите 288 иопс — отключайте кэш. === Ceph HDD+SSD === Дано: 3 компа с 4x 7200rpm SATA HDD, с 1 SSD (десктопным) под систему и ceph-mon и с 1 SSD (старым, но серверным, 25000 iops) под журналы. Не самая быстрая 10-гигабитная сеть — флуд пингом средний RTT (задержка) 0.098ms. Развёрнут Ceph + OpenNebula с KVM. Диски под Ceph отформатированы в Bluestore утилитой ceph-volume (то есть используется LVM). Диски виртуалок лежат в обычном реплицированном ceph pool с size=3.

Ведь старалисьБолее свежие тесты бенчилкой ceph-старалисьgobench на том же самом стенде. Версия Ceph Mimic 13.2.2, уходили от двойной записи и журналирования журнала в filestoreBluestore, журналы на SSD. И опять то же самое…

Речь о random iopsosd. Вкратце: потому что писано всё кривым **ем1 и osd.3 без выноса журналов на SSD оба показывали 75-80 iops вне зависимости от отключения кэша.

Все мы знаем, что В таблице показаны однопоточные IOPS с глубиной очереди Q=1 7200rpm HDD может выдать примерно 100—120 iops. Дальше нам говорят — ну, там типа журналированиебез репликации.

Ну ок, как мы рассуждаем — ну, типа, есть журнал, есть диск<tab sep="bar" class="wikitable" head="topleft">Номер OSD | Патч + кэш | Кэш выкл | Кэш вкл | Модель диска | Номер моделиosd. Значит типа вроде как синхронно записало в журнал, потом асинхронно постепенно перенесло на диск0 | 365 | 308 | 226 | Seagate Constellation ES.2 | ST32000645NSosd. Значит, берём 100, умножаем на число дисков в кластере, делим на фактор репликации (3), делим на 1| 322 | 325 | 234 | Hitachi Ultrastar 7K3000 | HUA723020ALA640osd.5-2 (данные+журнал), мы же держим в уме, что наверняка там всё асинхронно и оптимизировано… Получаем, скажем, 100 * | 1278 | 1392 | 230 | Seagate Enterprise Capacity | ST8000NM0055osd.4 | 198 | 244 | 140 | Hitachi Ultrastar A7K2000 | HUA722020ALA330osd.5 | 251 | 185 | 154 | Hitachi Ultrastar A7K2000 | HUA722020ALA330osd.7 | 1351 | 1129 | 253 | Seagate Enterprise Capacity | ST8000NM0055osd.9 дисков / 2 / | 399 | 315 | 184 | Hitachi Ultrastar 7K3000 | HUA723020ALA640osd.13 | 226 | 212 | 142 | Hitachi Ultrastar A7K2000 | HUA722020ALA330osd.3 = 150 iops| 393 | 386 | 241 | Hitachi Ultrastar 7K3000 | HUA723020ALA640osd. Запускаем тест на собранном кластере — ОЙ8 | 340 | 323 | 156 | Hitachi Ultrastar A7K2000 | HUA722020ALA330osd. 30 iops10 | 1461 | 1319 | 273 | Seagate Enterprise Capacity | ST8000NM0055osd. Как так-то?14 | 302 | 229 | 135 | Hitachi Ultrastar A7K2000 | HUA722020ALA330</tab>

Журнала собственного нетToshiba MG07ACA14TE тоже замечены в подобном поведении, вместо него RocksDBсм. Она как бы keyvalue база, но она же LSM, она же так и работает — типа до лимита пишет обсуждение в память+журнал, потом когда упирается в лимит — делает compaction по уровнямсписке рассылки: https://www. По сути как бы БДspinics.net/lists/ceph-журнал. Вот они её как журнал и юзаютusers/msg60753.html

# Пришла транзакция — писнулась Вкратце ситуация такова: После того, как хранилище Ceph переписали с упоротой архитектуры с хранением объектов в журнал. Sync.# Если запись мелкаяФС XFS и дополнительным журналом, она откладывается и на время «откладывания» записывается в ту же rocksdb в отдельное место. Sync.# Упёрлись в лимит сброса отложенных транзакций. Прочитали порцию из rocksdbкоторой, смержилипо идее, отправили был дикий оверхед — быстрее (в дисксмысле random write iops) оно практически не стало. С*ка опять sync, чтобы понимать, когда уже можно будет обновить метаданные.'''Логичный ответ на вопрос «какого х# Обновляем метаданные. Sync.# Если запись крупнаяра» такой: то ли XFS на самом деле написана очень хорошо, то она сразу отправляется ли Bluestore на дисксамом деле написан очень плохо. Потом Sync''' Сразу скажу: оба ответа верны.:-))). и потом тоже обновляем метаданные. Sync.

И ещё Все мы держим в уме, что 1x 7200rpm HDD может выдать примерно 100—120 iops. Дальше нам говорят — ну, там типа журналирование. Ну ок, как мы рассуждаем — ну, типа, есть журнал, есть диск. Значит типа вроде как синхронно записало в журнал, потом асинхронно постепенно перенесло на диск. Значит, берём 100, умножаем на число дисков в кластере, делим на фактор репликации (3), делим на 1.5-2 (данные+журнал), мы же держим в уме, что наверняка там всё это приправлено тредамиасинхронно и оптимизировано… Получаем, скажем, 100 * 9 дисков / 1.5-2 / 3 = 150—200 iops. Запускаем fio iodepth=128 на собранном кластере — ОЙ, блокировками…30 iops. Как так?

То есть получается, что есть как бы журнал, есть данные Отчаиваемся и есть метаданныепо советам знатоков прикручиваем туда SSD под wal+db. И ещё если мелкие записи то есть очередь отложенной записи (в той же бддумаем: ну, но отдельная)теперь у нас быстрая SSD с конденсаторами под журналом, её сначала надо писатьлатенси записи 50 микросекунд, а потом сбрасывать и очищатьзначит должно быть много иопсов — ну, в устоявшемся режиме хотя бы 300 (9 * 100 / 3). Тестируем. В итоге получается на 1 входящую транзакцию штук 5 реальных транзакцийпоток получаем ну… 60 иопс. Во много — где-то 200. Опять плохо.

Без Смысл в том, что собственной реализации журнала у блюстора нет, есть очередь отложенной записи (на SSD это дефолт) поэтому всё и легче — остаётся только журнал, данные и метаданные — живущая прямо в RocksDB. RocksDB — это хотя бы 3 транзакцииLSM keyvalue база, а не 5по сути база-журнал. А когда нет SSDВ принципе, то казалось бы журнал хоть немного должен помогатьэто достаточно разумно, авотх*йтак как всё равно нужно журналировать изменения метаданных, потому что seek-ов то меньшекоторые там держит блюстор. Когда очередь отложенной записи засунута туда же, но зато транзакций не 3изменение можно коммитить одной транзакцией (соответственно, а 5одним fsync-ом).

Смысл видимо именно И в отсутствии собственного журналаэтой схеме есть одно большое отличие от filestore — оно заключается в том, что в filestore журнал работал как буфер для временного повышения нагрузки на запись. Если бы он был Пока в журнале было место, случайная запись была очень быстрой, а журналы обычно делали размеров в несколько гигабайт. В bluestore же «очередь отложенной записи» очень маленькая и они работали как традиционная СУБДсбрасывается через каждые 64 запроса. То есть, то по идееbluestore не пишет быстрее, они могли бы делать примерно так:чем в среднем может медленное устройство (HDD).

* приняли Плюс к этому на практике (при просмотре strace) оказывается, что fsync-ов на каждую операцию* BEGIN* UPDATE метаданные* UPDATE данные* COMMIT = ОДНА синхронная запись записи делается не 1, а 2. Второй fsync — это лишняя транзакция записи в журнал* ответили клиенту «ок»BlueFS, сводящаяся к обновлению размера лог-файла RocksDB. Это нафиг не нужно, так как в опциях RocksDB в цефе по умолчанию стоит wal_recovery_mode=kTolerateCorruptedTailRecords и recycle_log_number=4, но это так, потому что без этого у них из-за другого бага корраптятся данные при падении OSD. Что на самом деле исправляется легко, я им даже отправил фикс — https://tracker.ceph.com/issues/38559 https://github.com/ceph/ceph/pull/26909 - и они даже вроде как обещают его влить. С фиксом на HDD ускорение случайной записи при глубине очереди 1 — двукратное (с 33 % до 66 % возможностей самого HDD, обычно как раз с 33 до 66 иопс). При глубине очереди 128 — почти нулевое.

Ну а потом журнал просто потихоньку чистимОК, ладно. А у них В конце концов мы решаем — гулять так не получается — у них rocksdb, данные гулять и метаданные собираем кластер на серверных SSD (или вообще NVMe). Думаем — ну теперь-то?!… Бенчим в логически разных местах, а журналирование — фактически отдельная транзакция1 поток.300 иопс. Охреневаем окончательно и идём гуглить эту статью :)

Вот простой эксперимент: «кластер» из 2 SSDЗдесь смысл в том, по 4 OSD что в голове у всех сидит мысль «а, ну да, оно медленное, потому что слишком много пишет на SSDдиск — диск же относительно медленный, чуть подкрученные SSD-настройки (shards=1а софт быстрый». А вот хрен. :) оказывается, threads=Ceph довольно сложно разогнать до latency < 1ms, min_alloc_size=4096и виной тому не диски, bluestore_sync_submit_transaction=trueа сам Ceph. То есть да, Ceph при записи мелкими блоками порождает WA (Write Amplification)3. Делаю .5 на каждой OSD — это легко посчитать через тот же strace одной из 4-х osd . Но на одной из двух хороших SSD во время запуска теста fio это практически не занимает времени, одна операция 4кб записи занимает условно 20 микросекунд. Проблема именно в 1 поток на 60 секундС++ коде Ceph.

<pre>root@m2:~# ceph daemon osdПричём даже не до конца понятно, что конкретно там тормозит — такое ощущение, что всё целиком.0 perf dump | jq '.osd.op Выявить какие-то «горячие точки» при профилировании трудно, просто при записи выполняется много всякой C+ +ной мелочи, которая суммарно отъедает достаточно много времени.osd.subop'6193root@m2:~# grep -P 'io_submit\Одно горячее место — вычисление цифровых подписей пакетов (' osd0-trace.txt |wc -l12383root@m2:~# grep -P 'io_submit\включено по умолчанию, можно отключить), другое — сериализация/десериализация (код обрабатывает каждое поле пакета, чуть ли не каждый байт, отдельным вызовом функции).*iov_len=4096' osd0Дальше идут уже malloc-traceи, которых тоже происходят тонны.txt |wc -l12382root@m2:~# grep -P 'pwritev\(' osd0-traceПричём всё это происходит в несколько потоков.txt |wc На это ещё навёрнута какая-l6203root@m2:~# grep -P 'syncто странная смесь буферизованного и прямого I/O.*\(' osd0-trace.txt |wc -l24776root@m2:~# grep -P 'pwritev.*= 4096$' osd0-trace.txt |wc -l3163root@m2:~# grep -P 'pwritev.*= 8192$' osd0-trace.txt |wc -l2991root@m2:~# grep -P 'pwritev.*= 12288$' osd0-trace.txt |wc -l49</pre>

То есть эта тварь RocksDB не виновата — её я пробовал бенчить, она быстрая, ~8000 транзакций в секунду на 6193 запроса записи сделала 18585 записей (суммарно 21674*4к) NVMe в 1 поток она даёт и 24776 (!!!) синков! (sync_file_range и fdatasync)даже масштабируется до ~120000 tps в 256 потоков. А Ceph OSD даже с максимальным параллелизмом на той же NVMe даёт только 10-20 тысяч iops.

Итого Write Amplification Сеть тоже не виновата — её я пробовал бенчить с SSDпомощью nbd (network block device). При прямом доступе диск выдаёт 50000 iops, при пробросе диска с одного сервера на другой через nbd — 8000 iops. То есть, добавленная latency сети — примерно 0.1ms. Это не много. И даже Bluestore не совсем виноват. На NVMe Bluestore с некоторыми тюнами всё-настройками = 3таки осиливает завершить запись примерно за 0.3мс.И в то же время код самого Ceph сжирает ещё 0. О чём и шла речь: данные4мс. По сути, метаданныенужно было бы добиться ситуации, журналв которой Ceph бы отъедал 0. Но fsync-ов просто море — больше1ms и Bluestore ещё 0.1ms. Сеть съест ещё 0.1ms и тогда на хорошей NVMe получится latency ~ 0.33ms, чем запросов что в 1 поток соответствует 3000 операциям записи в секунду. До локальной SSD это всё равно не дотянуло бы, но, тем не менее, было бы уже очень-очень неплохо. Тогда, скажем, можно будет бороться за CPU:поставив самолётные CPU по 20000$ каждый, настроив ядро и снизив время Ceph+Bluestore ещё в 2 раза, вы получите уже 0.23ms = ~4350 iops. А допилив поддержку Infiniband, может, получите и все 6000 iops. Пока же код не оптимизирован… всё это — мёртвому припарки. Авторы сейчас пытаются пилить новую реализацию OSD на асинхронном фреймворке Seastar (Crimson OSD), так что у нас есть теоретические шансы увидеть Ceph, который будет в несколько раз быстрее. Хотя, конечно, там вопрос далеко не только в многопоточности и блокировках — по идее, много съедает именно программная логика. Но так как её они фактически тоже частично переписывают с нуля — она тоже может улучшиться.

* SPDK включается для NVMe-шек передачей в качестве пути девайса spdk:<серийный номер pcie устройства>и ручным созданием OSD по инструкции Manual Deployment* Это в теории — на практике (проверялся Mimic 13.2.x) НИ ХРЕНА не работает, ни DPDK, ни SPDK** С DPDK Ceph «из коробки» даже не собирается — это в общем-то довольно легко исправить, но даже когда добиваешься сборки и запуска — OSD падают после обработки ~50 пакетов** С SPDK Ceph собирается и даже собран по умолчанию — но оно опять-таки не работает — вскоре после запуска OSD просто виснет в пространстве** Code is there, так что, вероятно, всё это можно исправить, если подебажить подольше** Есть сообщения, что SPDK всё-таки работает из коробки, просто не даёт никакого выигрыша производительности. Но мне пока завести его не удалось* Однако в силу неоптимальной реализации самого Ceph ни от DPDK, ни от RDMA ожидать ускорения не приходится. Задержка Ceph в 10-100 раз выше сетевой задержки, так что, уменьшая сетевую задержку, добиться практически нечего. Один чувак даже проводил эксперимент — отрезал код AsyncMessenger-а от всего остального цефа и пробовал бенчить его отдельно: https://www.spinics.net/lists/ceph-devel/msg43555.html — и получил всего лишь ~80000 iops.* В перспективе SPDK будет на хрен не нужен, так как в ядро приняли штуку под названием io_uring: https://lore.kernel.org/linux-block/20190116175003.17880-1-axboe@kernel.dk/ - с ней обычный код прокачивает через Optane-ы практически столько же iops, сколько и SPDK, при заметно меньшем объёме геморроя на поддержку работы с SPDK/DPDK == RAID WRITE HOLE == В RAID-е есть один интересный момент: при отказе диска и одновременном отключении питания RAID 5 может кораптить данные. Суть такая: допустим, есть три диска в рейд5. Есть какая-то пара блоков данных A и B. Соответственно на дисках хранятся: A, B, A xor B. Теперь представим, что мы пишем в блок B данные B2. Для этого нам надо обновить данные на двух дисках: B -> B2, A+B -> A+B2. Теперь представим, что один из них успел записать, а второй не успел. Тут вырубилось питание и одновременно сдох диск A (или диск сдох от умирания питания, или контроллер повис и ядро в панику упало...). Что мы имеем на дисках? ?, B2, A+B либо ?, B, A+B2. Теперь при попытке восстановить A мы получим A+B+B2 => опа! Покорраптились данные, которые даже не записывались! Из-за этого raid всегда делает полный resync после нештатного вырубания питания. И, собственно, такая же потеря данных возможна при отказе диска до завершения resync. mdadm RAID5 в таких ситуациях (когда одновременно потерян диск и массив помечен как грязный) просто отказывается стартовать. И именно чтоб этого избежать, в цефе сделано полное журналирование всех данных на уровне отдельных дисков (т.е. OSD). Потому что других способов борьбы с этой проблемой НЕТ, а при работе по сети отказы гораздо более вероятны, чем при работе RAID-массива на локальных дисках. Даже write intent bitmap может только сказать вам, потеряли вы какие-то данные или нет, но не может помочь их восстановить, если они потеряны. Так что Ceph надёжнее RAID-а. :) медленнее (на SSD). Но надёжнее и не требует resync-а.

Особенность NAND флеш-памяти (NAND/NOR) заключается в том, что пишется она мелкими блоками , а стирается большими. Актуальное соотношение для Micron 3D NAND — страница (обычно 512 байтpage)16 КБ, но перед тем, как писать — блок нужно стереть. А вот стирать она умеет только крупные блоки стирания («erase unit»block) — 16 или 24 МБ (1024 или 1536 страниц, размером обычно 2-4 мегабайтаMLC/TLC соответственно). Случайное чтение страницы быстрое. Запись тоже, и но писать можно только в предварительно стёртую область — а стирание довольно медленное по отношению к записи. Кроме того, каждый erase unit ограничен числом да ещё и число стираний. После каждого блока ограничено — после нескольких тысяч стираний (типичное значение для MLC) он блок физически выходит из строя. В более дешёвых чипах и плотных (MLC, TLC , QLC — 2-4 бита на ячейку) чипах лимит стираний меньше, в более дорогих и SLC — менее плотных (SLC, один бит на ячейку) — больше. Таким образомСоответственно, при «тупом» подходе перезапись подходе — если при записи каждого блока его просто стирать и перезаписывать — случайная запись во флеш-памятипамять, во-первых, была бы будет очень медленной, а во-вторых, она бы будет быстро выходила выводить её из строя.

Но почему тогда SSD быстрые? А потому, что внутри SSD на самом деле есть очень мощный и умный контроллер (1-2 гигагерца, типично 4 ядра или больше, примерно как процессоры мобильников), и на нём выполняется нечто, называемое Flash Translation Layer — прошивка, которая переназначает каждый мелкий логический сектор в произвольное место диска. FTL всё время поддерживает некоторое количество свободных стёртых блоков, каждая случайная и направляет каждую мелкую случайную запись на самом деле идёт в новое место диска — диска, в заранее стёртую область. Поэтому запись быстрая. Одновременно FTL делает дефрагментацию свободного места и Wear Leveling (распределение износа), направляя запись и перемещая данные так, чтобы все блоки диска стирались примерно одинаковое количество раз. Кроме того, во всех SSD некоторый % реального места зарезервирован под Wear Leveling и не виден пользователю («overprovision»), а в хороших серверных SSD этот процент весьма большой — например, в Micron 5100 Max это +60 % ёмкости(в Micron 5100 Eco — всего лишь +7.5 %, 1.92 ТБ SSD содержит 10 чипов NAND по 1.5 терабита и 2 по 768 гигабит).

А почему тогда USB-флешки такие медленные? Случайная запись на флешку 512-байтными (или 4 Кб) блоками обычно идёт со скоростью 2-3 iops. А флеш-память там ровно примерно та же, что в SSD — ну, может, более дешёвые вариациии мелкие чипы с меньшими размерами страницы и блока (часто 4 КБ страница и 4 МБ блок), но разница принцип тот же и разница в скорости не на порядки. Ответ кроется в том, что на флешках тоже есть FTL (и даже Wear Leveling), но по сравнению с SSD-шным он маленький и тупой. У него слабый процессор и мало памяти. Из-за малого объёма RAM контроллеру флешки, в отличие от контроллера SSD, негде хранить полную таблицу сопоставления виртуальных и реальных секторов — поэтому отображаются не сектора, а крупные блоки где-то по мегабайту или больше, а и при записи есть лимит на количество «открытых» блоков. Как это происходит:

Для копирования больших файлов на флешку, отформатированную в любую из стандартных файловых систем, двух блоков достаточно: в один открытый блок пишутся блок пишутся данные, во второй — метаданные записываемого файла. Запись последовательная, всё быстро. А вот при случайной записи вы перестаёте попадать в уже «открытые» блоки и каждая операция записи превращается в полное стирание. Тут-то и начинаются тормоза…

Пример самолётного сетапа от Micron с процами по полляма (2x Xeon GoldPlatinum 8168), 1002x100-гбит сетью (точнее 2x2x100, так как 2 карты по 2 порта) и 10x топовыми NVMe (с конденсаторами, ага) в каждом узле, 4 узла, репликация 2x: https://www.micron.com/resource-details/30c00464-e089-479c-8469-5ecb02cfe06f

Всего 350000 367011 iops на запись в пике на весь кластер, при 100 % загрузке CPU. Казалось бы, довольно много, но если поделить 350000367000/40 osd — получится 8750 9175 иопс на 1 osd. С учётом репликации на диски нагрузка двойная, выходит, 17500 18350 иопс. Ок, журналы тоже удваивают нагрузку, итого — 35000 36700 iops на запись смог выжать ceph из одной NVMe… которая сама по спеке может 260000 иопс в одиночку. Вот такой вот overhead.

UPDДанных по задержкам в 1 поток нет (а было бы интересно узнать). Примечание: ПоправкаPDF-ка по ссылке обновлена, новый результат с теми же тюнами, что ниже, составил 479882 iops на запись и 2277453 iops на чтение. Старая [[: в чём микрон неправ — они Media:Micron_9200_ceph_3.0_reference_architecture.pdf|тут]]. Что и подтверждает, что разница между Micron 9200 и 9300 для Ceph незаметна. === Апдейт === https://www.micron.com/-/media/client/global/documents/products/other-documents/micron_9300_and_red_hat_ceph_reference_architecture.pdf NVMe обновились до Micron 9300 (максимальной ёмкости 12.8 ТБ). iops-ов такие диски дают даже не использовали SPDK 260 тыс., а 310 тыс. Всё остальное осталось прежним. Итого 100 клиентами на запись сняли 477029 iops. Однако надо понимать, что каждому клиенту при этом досталось лишь 4770 iops. 10 клиентами сняли 294000 iops — то есть на 1 клиента 29400 иопс, что всё-таки поприличней. Почему стало лучше? Предположительно, благодаря тюнингу. По сравнению с прошлым тестом они:* отключили чексуммы мессенджера (ms_crc_data=false) и DPDKчексуммы блюстора (bluestore_csum_type=none)* затюнили rocksdb: <tt>bluestore_rocksdb_options = compression=kNoCompression,max_write_buffer_number=64,min_write_buffer_number_to_merge=32,recycle_log_file_num=64,compaction_style=kCompactionStyleLevel,<br />write_buffer_size=4MB,target_file_size_base=4MB,max_background_compactions=64,level0_file_num_compaction_trigger=64,level0_slowdown_writes_trigger=128,<br />level0_stop_writes_trigger=256,max_bytes_for_level_base=6GB,compaction_threads=32,flusher_threads=8,compaction_readahead_size=2MB</tt>** 64x32x4 MB memtable (number x merge x size) вместо стандартных 4x1x256 MB. Есть большая вероятностьСкорее всего, это и сыграло основную роль. Эффект не совсем очевиден, но, вероятно, это снижает нагрузку на CPU, потому что поиск в их случае выигрыш мог быть 64 маленьких memtable быстрее, чем поиск в несколько 1 (или 4) больших.** сильно изменён max_bytes_for_level_base — с 256 мб он поднят до 6 гб!** добавлены потоки compaction-а.* выдали 14 гб RAM каждому OSD* osd_max_pg_log_entries=osd_min_pg_log_entries=osd_pg_log_dups_tracked=osd_pg_log_trim_min = 10 (хз, по-моему, ничего не даёт) Также надо отметить, что:* cephx у них уже был отключён. В этот раззачем-то добавили и отключение подписей — видимо, читали мою статью.Но это нафиг не надо, при отключенном cephx подписи можно уже не отключать.* debug objecter = 0/0 и вообще отключенные дебаги у них тоже уже были* с prefer_deferred_size и min_alloc_size они, видимо, не игрались* обновлённые диски не играют никакой роли гарантированно. 260000 или 310000 iops — для цефа никакой разницы нет. === Бонус: висян (vSAN) === [https://media-www.micron.com/-/media/client/global/documents/products/other-documents/micron_vsan_6,-d-,7_on_x86_smc_reference_architecture.pdf Micron Accelerated All-Flash SATA vSAN 6.7 Solution] Конфигурация серверов: * 384 GB RAM 2667 MHz* 2X Micron 5100 MAX 960 GB (randread: 93k iops, randwrite: 74k iops)* 8X Micron 5200 ECO 3.84TB (randread: 95k iops, randwrite: 17k iops)* 2x Xeon Gold 6142 (16c 2.6GHz)* Mellanox ConnectX-4 Lx* Connected to 2x Mellanox SN2410 25GbE switches «Соответствует конфигурации VMWare AF-6, по заявлениям дающей от 50K iops чтения на каждый сервер» * 2 реплики (аналог size=2 в цефе)* 4 сервера* 4 ВМ на каждом сервере* 8 диска на каждую ВМ* 4 потока на каждый дискСуммарный параллелизм ввода/вывода: 512 100%/70%/50%/30%/0% write* «Baseline» (данные умещаются в кэш): 121k/178k/249k/314k/486k iops* «Capacity» (не умещаются): 51k/66k/90k/134k/363k* Задержка равна 1000*512/IOPS миллисекунд во всех тестах (1000мс * параллелизм / iops)* '''Нет тестов задержки с низким параллелизмом'''* '''Нет тестов линейного чтения/записи''' Заключение:* ~3800 iops на запись в пересчёте на каждый диск данных* ~1600 iops на запись в пересчёте на диск, если данные не влезают в кэш* ~15000 iops на чтение в пересчёте на каждый диск данных* ~11400 iops на чтение в пересчёте на диск, если данные не влезают в кэш* Итого: при параллельной нагрузке в данном тесте vSAN смотрится хуже, чем Ceph* С другой стороны, vSAN гиперконвергентный, а Ceph, в идеале, нет — или тормозит сильнее, чем мог бы

* Micron серий 5100/5200, 9300. Возможно также 5300, 7300