9.8 KiB
Документация → Конфигурация → Дисковые параметры уровня кластера
Дисковые параметры уровня кластера
Данные параметры используются клиентами и OSD, задаются в момент инициализации диска OSD и не могут быть изменены после этого без потери данных.
block_size
- Тип: целое число
- Значение по умолчанию: 131072
Размер объектов (блоков данных), на которые делятся физические и виртуальные диски в Vitastor. Одна из ключевых на данный момент настроек, влияет на потребление памяти, объём избыточной записи (write amplification) и эффективность распределения нагрузки по OSD.
Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 4 мегабайта для HDD. В принципе, для SSD можно тоже использовать 4 мегабайта, это понизит использование памяти, но ухудшит распределение нагрузки и в среднем увеличит WA.
OSD с разными размерами блока (например, SSD и SSD+HDD OSD) на данный момент могут сосуществовать в рамках одного etcd только в виде двух независимых кластеров Vitastor с разными etcd_prefix.
Также размер блока нельзя менять после инициализации OSD без потери данных.
Если вы меняете размер блока, обязательно прописывайте его в etcd в /vitastor/config/global, дабы все клиенты его знали.
Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт), т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при стандартном 128 КБ блоке.
bitmap_granularity
- Тип: целое число
- Значение по умолчанию: 4096
Требуемое выравнивание записи на виртуальные диски (размер их "сектора"). Должен быть кратен disk_alignment. Называется гранулярностью битовой карты потому, что Vitastor хранит битовую карту для каждого объекта, содержащую по 2 бита на каждые (bitmap_granularity) байт.
Данный параметр нельзя менять после инициализации OSD без потери данных. Также он фиксирован для всего кластера Vitastor, т.е. разные значения не могут сосуществовать в одном кластере.
Клиенты ДОЛЖНЫ знать правильное значение этого параметра, так что если вы его меняете, обязательно прописывайте изменённое значение в etcd в ключ /vitastor/config/global.
immediate_commit
- Тип: строка
- Значение по умолчанию: false
Ещё один важный для производительности параметр.
Модели SSD для настольных компьютеров очень быстрые (100000+ операций в секунду) при простой случайной записи без сбросов кэша. Однако они очень медленные (всего порядка 1000 iops), если вы пытаетесь сбрасывать кэш после каждой записи, то есть, если вы пытаетесь гарантировать, что каждое изменение физически записывается в энергонезависимую память.
С другой стороны, серверные SSD с конденсаторами - функцией, называемой "Advanced/Enhanced Power Loss Protection" или просто "Supercapacitor-based Power Loss Protection" - одинаково быстрые и со сбросом кэша, и без него, потому что их кэш защищён от потери питания встроенным "источником бесперебойного питания" на основе суперконденсаторов и на самом деле они его никогда не сбрасывают.
Некоторые программные СХД всегда сбрасывают кэши дисков при каждой записи и поэтому работают очень медленно с настольными SSD. Vitastor, однако, может откладывать fsync до явного его вызова со стороны клиента и таким образом эффективно утилизировать настольные SSD.
Данный параметр влияет как раз на это. Когда он установлен в значение "all", весь кластер Vitastor мгновенно фиксирует каждое изменение на физические носители и клиенты могут просто игнорировать запросы fsync, т.к. они точно знают, что fsync-и не нужны. Это уменьшает число необходимых обращений к OSD по сети и улучшает производительность. Поэтому даже с Vitastor лучше всегда использовать только серверные модели SSD с суперконденсаторами, особенно учитывая то, что стоят они ненамного дороже настольных.
Также в прошивках SATA SSD (и даже HDD!) очень часто встречается либо баг,
либо просто особенность логики, из-за которой серверные SSD, имеющие
конденсаторы и защиту от потери питания, всё равно медленно работают с
fsync. Чтобы понять, подвержены ли этой проблеме ваши SSD, сравните
результаты тестов fio -name=test -ioengine=libaio -direct=1 -bs=4k -rw=randwrite -iodepth=1 без и с опцией -fsync=1. Результаты должны
быть одинаковые. Если результат с fsync=1 хуже, вы можете попробовать
обойти проблему, "отключив" кэш записи диска командой hdparm -W 0 /dev/sdXX
либо echo write through > /sys/block/sdXX/device/scsi_disk/*/cache_type
(ВАЖНО: не перепутайте с /sys/block/sdXX/queue/write_cache - этот параметр
менять руками небезопасно). Такая же проблема может встречаться и в новых
HDD-дисках с внутренним SSD или "медиа" кэшем - например, она встречается во
многих дисках Seagate EXOS (у них есть внутренний SSD-кэш, хотя это и не
указано в спецификациях).
Данный параметр нужно указывать и в etcd в /vitastor/config/global, и в командной строке или конфигурации OSD. Значения "all" и "small" требуют включения disable_journal_fsync и disable_meta_fsync, значение "all" также требует включения disable_data_fsync.
Итого, вкратце: для оптимальной производительности установите immediate_commit в значение "all", если вы используете в кластере только SSD с суперконденсаторами и для данных, и для журналов. Если вы используете такие SSD для всех журналов, но не для данных - можете установить параметр в "small". Если и какие-то из дисков журналов имеют волатильный кэш записи - оставьте параметр пустым.
client_dirty_limit
- Тип: целое число
- Значение по умолчанию: 33554432
При работе без immediate_commit=all - это лимит объёма "грязных" (не зафиксированных fsync-ом) данных, при достижении которого клиент будет принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду, что в этом случае до момента fsync клиент хранит копию незафиксированных данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
Параметр не влияет на сами OSD.