8.7 KiB
Документация → Конфигурация → Дисковые параметры уровня кластера
Дисковые параметры уровня кластера
Данные параметры используются клиентами и OSD, задаются в момент инициализации диска OSD и не могут быть изменены после этого без потери данных.
OSD с разными значениями данных параметров (например, SSD и гибридные SSD+HDD OSD) могут сосуществовать в одном кластере Vitastor в разных пулах. Один пул может включать только OSD с одинаковыми настройками этих параметров.
Данные параметры, отличаясь от значения по умолчанию, должны также быть заданы в etcd, чтобы клиенты могли узнать их значение, либо в глобальной конфигурации /vitastor/config/global, либо в настройках пулов. Настройки пула переопределяют глобальное значение. Если значение в настройках пула не будет соответствовать конфигурации OSD, OSD откажется запускать PG данного пула.
block_size
- Тип: целое число
- Значение по умолчанию: 131072
Размер объектов (блоков данных), на которые делятся физические и виртуальные диски в Vitastor (в рамках каждого пула). Одна из ключевых на данный момент настроек, влияет на потребление памяти, объём избыточной записи (write amplification) и эффективность распределения нагрузки по OSD.
Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 4 мегабайта для HDD. В принципе, для SSD можно тоже использовать 4 мегабайта, это понизит использование памяти, но ухудшит распределение нагрузки и в среднем увеличит WA.
Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт), т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при стандартном 128 КБ блоке.
bitmap_granularity
- Тип: целое число
- Значение по умолчанию: 4096
Требуемое выравнивание записи на виртуальные диски (размер их "сектора"). Должен быть кратен disk_alignment. Называется гранулярностью битовой карты потому, что Vitastor хранит битовую карту для каждого объекта, содержащую по 2 бита на каждые (bitmap_granularity) байт.
Не может быть меньше размера сектора дисков данных OSD.
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-кэш, хотя это и не
указано в спецификациях).
Указание "all" или "small" в настройках / командной строке OSD требует включения disable_journal_fsync и disable_meta_fsync, значение "all" также требует включения disable_data_fsync.
Итого, вкратце: для оптимальной производительности установите immediate_commit в значение "all", если вы используете в кластере только SSD с суперконденсаторами и для данных, и для журналов. Если вы используете такие SSD для всех журналов, но не для данных - можете установить параметр в "small". Если и какие-то из дисков журналов имеют волатильный кэш записи - оставьте параметр пустым.