135 lines
9.8 KiB
Markdown
135 lines
9.8 KiB
Markdown
|
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Дисковые параметры уровня кластера
|
|||
|
|
|||
|
-----
|
|||
|
|
|||
|
[Read in English](layout-cluster.en.md)
|
|||
|
|
|||
|
# Дисковые параметры уровня кластера
|
|||
|
|
|||
|
Данные параметры используются клиентами и OSD, задаются в момент инициализации
|
|||
|
диска OSD и не могут быть изменены после этого без потери данных.
|
|||
|
|
|||
|
- [block_size](#block_size)
|
|||
|
- [bitmap_granularity](#bitmap_granularity)
|
|||
|
- [immediate_commit](#immediate_commit)
|
|||
|
- [client_dirty_limit](#client_dirty_limit)
|
|||
|
|
|||
|
## 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.
|