BlueStore в Ceph.
BlueStore - это новый бэкенд хранилища для Ceph. Он обладает лучшей производительностью (до 2х при операциях записи), обладает контрольными суммами для всего и встроенной поддержкой сжатия. BlueStore становится хранилищем по умолчанию с релиза Luminous v12.2.z и используется при настройке новых OSD с помощью команд ceph-disk, ceph-deploy и ceph-ansible.
Скорость
Грубо говоря, BlueStore примерно в два раза быстрее FileStore и производительность более согласуется с задержками в худших случаях. Реальность, конечно, сложнее и поэтому разъяснение:
- Для больших операций записи избегается эффект двойной записи, которую осуществляет FileStore (пишет вначале в свой журнал, потом собственно на диск-OSD). Поэтому можно быть в 2 раза быстрее.
- ... исключая тех, кто развёртывал FileStore с выносом журнала на SSD. Для них вышестоящий довод может нивелирован.
- Случайные мелкие операции записи теперь делаются быстрее, даже если сравнивать с FileStore + журнал.
- ... исключая тех, кто использует под журнал NVMe.
- С BlueStore и данными ключ-значение (key/value data) можно избегать некоторых уродливых операций для FileStore. Для некоторых рабочих нагрузок RGW была улучшена производительность в операциях записи аж в 3 раза!
- Небольшие последовательные запросы на чтение данных с помощью librados будут медленнее в BlueStore, так как не реализован свой собственный механизм опережающего чтения (readahead). Поскольку вышестоящие интерфейсы (RBD и CephFS) обладают своей реализацией readahead, то последовательное чтение небольших порций данных, как правило, осуществляется на должном уровне.
- В отличие от FileStore, BlueStore - это "копирование при записи" (Copy on Write). Такие операции как создание снимков (snapshot) будут делаться намного быстрее.
Более глубокое погружение в вопросы быстродействия будут рассмотрены в следующих статьях. Работа над BlueStore находится в процессе и первый его релиз - это начало, а не конец всего путешествия.
Неподходящий инструмент
OSD в Ceph выполняет 2 функции:
- Реплицирует данные по сети на другие OSD при операциях балансировки, восстановления данных и т.д
- Сохранение данных на устройствах (HDD, SSD или их сочетаниях).
Вторая функция реализовывалась до этого момента через FileStore и данные-объекты сохранялись в виде файлов в рекомендованной файловой системе XFS. В данном моменте следует знать, что работа OSD вращается вокруг транзакционных обновлений, а реализация их поверх файловой системы не эффективна и не удобна.
Если честно рассмотреть архитектуру FileStore, то там полно грязных хаков для адаптации интерфейса с POSIX и это не было проблемой Ceph и XFS по отдельности. XFS - прекрасная файловая система, просто неправильный инструмент для Ceph и всё.
Как работает BlueStore?
BlueStore - это реализация внутреннего интерфейса ObjectStore, основываясь и ориентируясь на те рабочие нагрузки, которых от них ждут. BlueStore опирается на использование сырых блочных устройств и базу данных RocksDB (ключ-значение) для управления своими внутренними метаданными. Небольшой внутренний компонент адаптера под названием BlueFS реализует интерфейс, схожий с файловой системой и обеспечивающий достаточную функциональность, чтобы RocksDB смог хранить свои "файлы" и совместно использовать одно и то же необработанное устройство с BlueStore.
Самое большое отличие между FileStore и BlueStore в итоговом отображении примонтированных разделов.
Для FileStore можно видеть что-то типа
$ lsblk
... sdb 8:16 0 931.5G 0 disk ├─sdb1 8:17 0 930.5G 0 part /var/lib/ceph/osd/ceph-56 └─sdb2 8:18 0 1023M 0 part ...
$ df -h
... /dev/sdb1 931G 487G 444G 53% /var/lib/ceph/osd/ceph-56 ...
$ ls -al /var/lib/ceph/osd/ceph-56
... drwxr-xr-x 180 root root 16384 Aug 30 21:55 current lrwxrwxrwx 1 root root 58 Jun 4 2015 journal -> /dev/disk/by-partuuid/538da076-0136-4c78-9af4-79bb40d7cbbd ...
В примере мы видим небольшой раздел под журнал (часто находящийся на SSD) и символическая ссылка journal внутри каталога с данными указывает на него. Каталог current/ хранит все объекты в виде файлов. Команда df показывает занятое место.
С BlueStore всё по-другому.
$ lsblk
... sdf 8:80 0 3.7T 0 disk ├─sdf1 8:81 0 100M 0 part /var/lib/ceph/osd/ceph-75 └─sdf2 8:82 0 3.7T 0 part ...
$ df -h
... /dev/sdf1 97M 5.4M 92M 6% /var/lib/ceph/osd/ceph-75 ...
$ ls -al /var/lib/ceph/osd/ceph-75
... lrwxrwxrwx 1 ceph ceph 58 Aug 8 18:33 block -> /dev/disk/by-partuuid/80d28eb7-a7e7-4931-866d-303693f1efc4 ...
Заметьте, что каталог с данными теперь представляет собой крошечный (100 Мб) раздел, содержащий несколько файлов, а остальная часть устройства выглядит как большой неиспользуемый раздел с символической ссылкой block на него. В данном разделе BlueStore сохраняет данные и выполняет через libaio операции ввода-вывода напрямую в устройство. Для возможности видеть процент использования устройством вы по-прежнему можете вызывать команду ceph osd df .
Убрав файловую систему из игры, объекты-файлы уже просто так вы не увидите, но есть возможность "заглянуть за сцену". При остановленном OSD можно "примонтировать" его данные через FUSE.
mkdir /mnt/foo
ceph-objectstore-tool --op fuse --data-path /var/lib/ceph/osd/ceph-75 --mountpount /mnt/foo
Настоятельно не рекомендуется, но возможно через параметр конфигурации osd_objectstore_fuse включить постоянное отображение содержимого в подкаталоге fuse/ в каталоге данных OSD.
Множество устройств
BlueStore легко может работать с комбинацией медленных и быстрых устройств, подобно FileStore, но BlueStore более эффективно работает с быстрыми устройствами. При использовании FileStore, устройство под журнал (часто это SSD) используется только лишь для операций записи. В ситуации с BlueStore, внутренний механизм журналирования более лековесен и похож на журналирование метаданных, применяя его только для мелких операций записи. Остальную часть быстрого устройства можно использовать для хранения (и извлечения) внутренних метаданных.
BlueStore может управлять тремя устройствами:
- Обязательное основное (main) устройство для хранения объектов, а также (обычно) метаданных. Символическая ссылка block указывает на это устройство.
- Опциональное устройство db может быть отдано для хранения метаданных (RocksDB). Если раздел будет мал и со временем места не будет хватать, то автоматически информация "перельётся" на устройство main. Символическая ссылка block.db указывает на это устройство.
- Опциональное устройство WAL используется для внутреннего журнала (RocksDB write-ahead log). Символическая ссылка block.wal указывает на это устройство.
Общая рекомендация состоит в том, чтобы взять SSD под хранение block.db. Можно использовать команду ceph-disk с параметром --block.db
ceph-disk prepare /dev/sdb --block.db /dev/sdc
По умолчанию на устройстве sdc будет создан раздел с размером в 1% от устройства main. Параметр bluestore_block_db_size в конфигурационном файле изменяет и переопределяет это значение. В более экзотичных вариантах можно задействовать все 3 устройства: main на HDD, db на SSD и WAL на Non-Volatile Dual In-line Memory Module (NVDIMM). Старайтесь, чтобы скорости устройств удовлетворяли правилу WAL > DB > MAIN.
Все возможности BlueStore внедряются в инструмент ceph-volume, который со временем заменит ceph-disk.
Более подробную информацию вы найдёте в BlueStore configuration guide. DEVICES.
Использование памяти
Для разработчиков тот факт, что FileStore использует обычную файловую систему Linux, оборачивался в приятную особенность, когда ядро само отвечало за вопросы управления памяти при кешировании данных и метаданных. Ядро могло использовать всю доступную ОЗУ в качестве кеша и высвобождать её по мере надобности.
BlueStore не использует файловую систему и должна опираться в своей работе на свою реализацию кеша и на свои параметры к ним. Есть параметр bluestore_cache_size, который контролирует объём ОЗУ что будет доступен каждому OSD под кеш. По умолчанию это 1 Гб для HDD и 3 Гб для SSD, но вы можете переопределить значение под своё рабочее окружение. Более подробно в BlueStore configuration guide. CACHE SIZE.
Предостерегаем вас, что пока учёт памяти несовершенен. Используемый tcmalloc несёт некоторые накладные расходы, фрагментируя кучу (heap) с течением времени, а фрагментация препятствует освобождению памяти обратно в операционную систему. Как результат, наблюдается некоторое несоответствие между тем, что использует BlueStore и фактическим потреблением ОЗУ (RSS). Расхождения могут достигать 1,5х. Вы это можете наблюдать, сравнивая колонку RSS процесса ceph-osd и вывод ceph daemon osd.<id> dump_mempools
Повышение точности учёта - приоритет №1 для разработчиков.
Контрольные суммы
BlueStore вычисляет, хранит и проверяет контрольные суммы для всех данных и метаданных. Всегда при чтении с диска происходит проверка контрольных сумм. По умолчанию используется crc32c и доступны вам xxhash32, xxhash64. Так же можно за счёт ухудшения надёжности использовать усечённые варианты crc32c (8, 16, 32 бит). Или даже совсем отключить контрольные суммы, но это настоятельно не рекомендуется.
Более подробно в BlueStore configuration guide. CHECKSUMS.
Сжатие
BlueStore может призрачно сжимать данные, используя алгоритмы zlib, snappy, lz4. Опция отключена по умолчанию и можно включить глобально, для определённых пулов или если клиенты RADOS "подсказывают" что данные хорошо сжимаются.
Более подробно в BlueStore configuration guide. INLINE COMPRESSION.
Конвертирование существующего кластера на использование BlueStore
Выбор бэкенда затрагивает только конкретный OSD, поэтому в кластере может сосуществовать различные FileStore OSD и BlueStore OSD. Новые OSD будут развёрнуты с использованием BlueStore и обновлённый кластер будет работать так же как и раньше.
Многие захотят существующие OSD "конвертировать" в новый бэкенд BlueStore. Есть путь более безопасный и есть рискованные шаги.
Руководство BLUESTORE MIGRATION описывает все возможности, если вы решитесь мигрировать существующие OSD.
Вывод
BlueStore предоставляет преимущество с точки зрения производительности, надёжности и функциональности по сравнению предыдущей надстройки над файловой системой. Взята под контроль важная часть - хранение данных в сыром блочном устройстве. Бо́льшее контролирование потоков ввода-вывода даёт повышение производительности и функциональности, вкупе с безопасностью. Разработчики довольны надёжностью, которую наблюдали последний год при тестировании и официально рекомендуют использовать новый BlueStore с релиза Luminous.
Дополнительные материалы:
Цикл статей про программно-определяемое хранилище Ceph.
Процедура проверки жёстких дисков в кластере Ceph.
Что плохого в FileStore? Негативные моменты и накладные расходы, связанные с наличием такого понятия как файловая система.
Оригинал New in Luminous: BlueStore
Разбираемся с BlueStore
