2022-01-26 02:38:00 +03:00
|
|
|
|
- name: etcd_report_interval
|
|
|
|
|
type: sec
|
|
|
|
|
default: 5
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Interval at which OSDs report their state to etcd. Affects OSD lease time
|
|
|
|
|
and thus the failover speed. Lease time is equal to this parameter value
|
2022-02-01 22:46:13 +03:00
|
|
|
|
plus max_etcd_attempts * etcd_quick_timeout because it should be guaranteed
|
2022-01-26 02:38:00 +03:00
|
|
|
|
that every OSD always refreshes its lease in time.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Интервал, с которым OSD обновляет своё состояние в etcd. Значение параметра
|
|
|
|
|
влияет на время резервации (lease) OSD и поэтому на скорость переключения
|
|
|
|
|
при падении OSD. Время lease равняется значению этого параметра плюс
|
2022-02-01 22:46:13 +03:00
|
|
|
|
max_etcd_attempts * etcd_quick_timeout.
|
2022-01-26 02:38:00 +03:00
|
|
|
|
- name: run_primary
|
|
|
|
|
type: bool
|
|
|
|
|
default: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Start primary OSD logic on this OSD. As of now, can be turned off only for
|
|
|
|
|
debugging purposes. It's possible to implement additional feature for the
|
|
|
|
|
monitor which may allow to separate primary and secondary OSDs, but it's
|
|
|
|
|
unclear why anyone could need it, so it's not implemented.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Запускать логику первичного OSD на данном OSD. На данный момент отключать
|
|
|
|
|
эту опцию может иметь смысл только в целях отладки. В теории, можно
|
|
|
|
|
реализовать дополнительный режим для монитора, который позволит отделять
|
|
|
|
|
первичные OSD от вторичных, но пока не понятно, зачем это может кому-то
|
|
|
|
|
понадобиться, поэтому это не реализовано.
|
|
|
|
|
- name: osd_network
|
|
|
|
|
type: string or array of strings
|
|
|
|
|
type_ru: строка или массив строк
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Network mask of the network (IPv4 or IPv6) to use for OSDs. Note that
|
|
|
|
|
although it's possible to specify multiple networks here, this does not
|
|
|
|
|
mean that OSDs will create multiple listening sockets - they'll only
|
|
|
|
|
pick the first matching address of an UP + RUNNING interface. Separate
|
|
|
|
|
networks for cluster and client connections are also not implemented, but
|
|
|
|
|
they are mostly useless anyway, so it's not a big deal.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Маска подсети (IPv4 или IPv6) для использования для соединений с OSD.
|
|
|
|
|
Имейте в виду, что хотя сейчас и можно передать в этот параметр несколько
|
|
|
|
|
подсетей, это не означает, что OSD будут создавать несколько слушающих
|
|
|
|
|
сокетов - они лишь будут выбирать адрес первого поднятого (состояние UP +
|
|
|
|
|
RUNNING), подходящий под заданную маску. Также не реализовано разделение
|
|
|
|
|
кластерной и публичной сетей OSD. Правда, от него обычно всё равно довольно
|
|
|
|
|
мало толку, так что особенной проблемы в этом нет.
|
|
|
|
|
- name: bind_address
|
|
|
|
|
type: string
|
|
|
|
|
default: "0.0.0.0"
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Instead of the network mask, you can also set OSD listen address explicitly
|
|
|
|
|
using this parameter. May be useful if you want to start OSDs on interfaces
|
|
|
|
|
that are not UP + RUNNING.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Этим параметром можно явным образом задать адрес, на котором будет ожидать
|
|
|
|
|
соединений OSD (вместо использования маски подсети). Может быть полезно,
|
|
|
|
|
например, чтобы запускать OSD на неподнятых интерфейсах (не UP + RUNNING).
|
|
|
|
|
- name: bind_port
|
|
|
|
|
type: int
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
By default, OSDs pick random ports to use for incoming connections
|
|
|
|
|
automatically. With this option you can set a specific port for a specific
|
|
|
|
|
OSD by hand.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
По умолчанию OSD сами выбирают случайные порты для входящих подключений.
|
|
|
|
|
С помощью данной опции вы можете задать порт для отдельного OSD вручную.
|
|
|
|
|
- name: autosync_interval
|
|
|
|
|
type: sec
|
|
|
|
|
default: 5
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Time interval at which automatic fsyncs/flushes are issued by each OSD when
|
|
|
|
|
the immediate_commit mode if disabled. fsyncs are required because without
|
|
|
|
|
them OSDs quickly fill their journals, become unable to clear them and
|
|
|
|
|
stall. Also this option limits the amount of recent uncommitted changes
|
|
|
|
|
which OSDs may lose in case of a power outage in case when clients don't
|
|
|
|
|
issue fsyncs at all.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Временной интервал отправки автоматических fsync-ов (операций очистки кэша)
|
|
|
|
|
каждым OSD для случая, когда режим immediate_commit отключён. fsync-и нужны
|
|
|
|
|
OSD, чтобы успевать очищать журнал - без них OSD быстро заполняют журналы и
|
|
|
|
|
перестают обрабатывать операции записи. Также эта опция ограничивает объём
|
|
|
|
|
недавних незафиксированных изменений, которые OSD могут терять при
|
|
|
|
|
отключении питания, если клиенты вообще не отправляют fsync.
|
|
|
|
|
- name: autosync_writes
|
|
|
|
|
type: int
|
|
|
|
|
default: 128
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Same as autosync_interval, but sets the maximum number of uncommitted write
|
|
|
|
|
operations before issuing an fsync operation internally.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Аналогично autosync_interval, но задаёт не временной интервал, а
|
|
|
|
|
максимальное количество незафиксированных операций записи перед
|
|
|
|
|
принудительной отправкой fsync-а.
|
|
|
|
|
- name: recovery_queue_depth
|
|
|
|
|
type: int
|
|
|
|
|
default: 4
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Maximum recovery operations per one primary OSD at any given moment of time.
|
|
|
|
|
Currently it's the only parameter available to tune the speed or recovery
|
|
|
|
|
and rebalancing, but it's planned to implement more.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Максимальное число операций восстановления на одном первичном OSD в любой
|
|
|
|
|
момент времени. На данный момент единственный параметр, который можно менять
|
|
|
|
|
для ускорения или замедления восстановления и перебалансировки данных, но
|
|
|
|
|
в планах реализация других параметров.
|
2022-12-30 01:53:29 +03:00
|
|
|
|
- name: recovery_pg_switch
|
|
|
|
|
type: int
|
|
|
|
|
default: 128
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-12-30 01:53:29 +03:00
|
|
|
|
info: |
|
|
|
|
|
Number of recovery operations before switching to recovery of the next PG.
|
|
|
|
|
The idea is to mix all PGs during recovery for more even space and load
|
|
|
|
|
distribution but still benefit from recovery queue depth greater than 1.
|
|
|
|
|
Degraded PGs are anyway scanned first.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Число операций восстановления перед переключением на восстановление другой PG.
|
|
|
|
|
Идея заключается в том, чтобы восстанавливать все PG одновременно для более
|
|
|
|
|
равномерного распределения места и нагрузки, но при этом всё равно выигрывать
|
|
|
|
|
от глубины очереди восстановления, большей, чем 1. Деградированные PG в любом
|
|
|
|
|
случае сканируются первыми.
|
2022-01-26 02:38:00 +03:00
|
|
|
|
- name: recovery_sync_batch
|
|
|
|
|
type: int
|
|
|
|
|
default: 16
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-26 02:38:00 +03:00
|
|
|
|
info: Maximum number of recovery operations before issuing an additional fsync.
|
|
|
|
|
info_ru: Максимальное число операций восстановления перед дополнительным fsync.
|
|
|
|
|
- name: readonly
|
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Read-only mode. If this is enabled, an OSD will never issue any writes to
|
|
|
|
|
the underlying device. This may be useful for recovery purposes.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Режим "только чтение". Если включить этот режим, OSD не будет писать ничего
|
|
|
|
|
на диск. Может быть полезно в целях восстановления.
|
|
|
|
|
- name: no_recovery
|
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Disable automatic background recovery of objects. Note that it doesn't
|
|
|
|
|
affect implicit recovery of objects happening during writes - a write is
|
|
|
|
|
always made to a full set of at least pg_minsize OSDs.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Отключить автоматическое фоновое восстановление объектов. Обратите внимание,
|
|
|
|
|
что эта опция не отключает восстановление объектов, происходящее при
|
|
|
|
|
записи - запись всегда производится в полный набор из как минимум pg_minsize
|
|
|
|
|
OSD.
|
|
|
|
|
- name: no_rebalance
|
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Disable background movement of data between different OSDs. Disabling it
|
|
|
|
|
means that PGs in the `has_misplaced` state will be left in it indefinitely.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Отключить фоновое перемещение объектов между разными OSD. Отключение
|
|
|
|
|
означает, что PG, находящиеся в состоянии `has_misplaced`, будут оставлены
|
|
|
|
|
в нём на неопределённый срок.
|
|
|
|
|
- name: print_stats_interval
|
|
|
|
|
type: sec
|
|
|
|
|
default: 3
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Time interval at which OSDs print simple human-readable operation
|
|
|
|
|
statistics on stdout.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Временной интервал, с которым OSD печатают простую человекочитаемую
|
|
|
|
|
статистику выполнения операций в стандартный вывод.
|
|
|
|
|
- name: slow_log_interval
|
|
|
|
|
type: sec
|
|
|
|
|
default: 10
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Time interval at which OSDs dump slow or stuck operations on stdout, if
|
|
|
|
|
they're any. Also it's the time after which an operation is considered
|
|
|
|
|
"slow".
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Временной интервал, с которым OSD выводят в стандартный вывод список
|
|
|
|
|
медленных или зависших операций, если таковые имеются. Также время, при
|
|
|
|
|
превышении которого операция считается "медленной".
|
2022-06-04 00:37:52 +03:00
|
|
|
|
- name: inode_vanish_time
|
|
|
|
|
type: sec
|
|
|
|
|
default: 60
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-06-04 00:37:52 +03:00
|
|
|
|
info: |
|
|
|
|
|
Number of seconds after which a deleted inode is removed from OSD statistics.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Число секунд, через которое удалённые инод удаляется и из статистики OSD.
|
2022-01-26 02:38:00 +03:00
|
|
|
|
- name: max_write_iodepth
|
|
|
|
|
type: int
|
|
|
|
|
default: 128
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Parallel client write operation limit per one OSD. Operations that exceed
|
|
|
|
|
this limit are pushed to a temporary queue instead of being executed
|
|
|
|
|
immediately.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Максимальное число одновременных клиентских операций записи на один OSD.
|
|
|
|
|
Операции, превышающие этот лимит, не исполняются сразу, а сохраняются во
|
|
|
|
|
временной очереди.
|
|
|
|
|
- name: min_flusher_count
|
|
|
|
|
type: int
|
|
|
|
|
default: 1
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Flusher is a micro-thread that moves data from the journal to the data
|
|
|
|
|
area of the device. Their number is auto-tuned between minimum and maximum.
|
|
|
|
|
Minimum number is set by this parameter.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Flusher - это микро-поток (корутина), которая копирует данные из журнала в
|
|
|
|
|
основную область устройства данных. Их число настраивается динамически между
|
|
|
|
|
минимальным и максимальным значением. Этот параметр задаёт минимальное число.
|
|
|
|
|
- name: max_flusher_count
|
|
|
|
|
type: int
|
|
|
|
|
default: 256
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Maximum number of journal flushers (see above min_flusher_count).
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Максимальное число микро-потоков очистки журнала (см. выше min_flusher_count).
|
|
|
|
|
- name: inmemory_metadata
|
|
|
|
|
type: bool
|
|
|
|
|
default: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
This parameter makes Vitastor always keep metadata area of the block device
|
|
|
|
|
in memory. It's required for good performance because it allows to avoid
|
|
|
|
|
additional read-modify-write cycles during metadata modifications. Metadata
|
|
|
|
|
area size is currently roughly 224 MB per 1 TB of data. You can turn it off
|
|
|
|
|
to reduce memory usage by this value, but it will hurt performance. This
|
|
|
|
|
restriction is likely to be removed in the future along with the upgrade
|
|
|
|
|
of the metadata storage scheme.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Данный параметр заставляет Vitastor всегда держать область метаданных диска
|
|
|
|
|
в памяти. Это нужно, чтобы избегать дополнительных операций чтения с диска
|
|
|
|
|
при записи. Размер области метаданных на данный момент составляет примерно
|
|
|
|
|
224 МБ на 1 ТБ данных. При включении потребление памяти снизится примерно
|
|
|
|
|
на эту величину, но при этом также снизится и производительность. В будущем,
|
|
|
|
|
после обновления схемы хранения метаданных, это ограничение, скорее всего,
|
|
|
|
|
будет ликвидировано.
|
|
|
|
|
- name: inmemory_journal
|
|
|
|
|
type: bool
|
|
|
|
|
default: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
This parameter make Vitastor always keep journal area of the block
|
|
|
|
|
device in memory. Turning it off will, again, reduce memory usage, but
|
|
|
|
|
hurt performance because flusher coroutines will have to read data from
|
|
|
|
|
the disk back before copying it into the main area. The memory usage benefit
|
|
|
|
|
is typically very small because it's sufficient to have 16-32 MB journal
|
|
|
|
|
for SSD OSDs. However, in theory it's possible that you'll want to turn it
|
|
|
|
|
off for hybrid (HDD+SSD) OSDs with large journals on quick devices.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Данный параметр заставляет Vitastor всегда держать в памяти журналы OSD.
|
|
|
|
|
Отключение параметра, опять же, снижает потребление памяти, но ухудшает
|
|
|
|
|
производительность, так как для копирования данных из журнала в основную
|
|
|
|
|
область устройства OSD будут вынуждены читать их обратно с диска. Выигрыш
|
|
|
|
|
по памяти при этом обычно крайне низкий, так как для SSD OSD обычно
|
|
|
|
|
достаточно 16- или 32-мегабайтного журнала. Однако в теории отключение
|
|
|
|
|
параметра может оказаться полезным для гибридных OSD (HDD+SSD) с большими
|
|
|
|
|
журналами, расположенными на быстром по сравнению с HDD устройстве.
|
2023-07-14 23:32:07 +03:00
|
|
|
|
- name: cached_io_data
|
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
|
|
|
|
info: |
|
|
|
|
|
Read and write *data* through Linux page cache, i.e. use a file descriptor
|
|
|
|
|
opened with O_SYNC, but without O_DIRECT for I/O. May improve read
|
|
|
|
|
performance for hot data and slower disks - HDDs and maybe SATA SSDs.
|
|
|
|
|
Not recommended for desktop SSDs without capacitors because O_SYNC flushes
|
|
|
|
|
disk cache on every write.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Читать и записывать *данные* через системный кэш Linux (page cache), то есть,
|
|
|
|
|
использовать для данных файловый дескриптор, открытый без флага O_DIRECT, но
|
|
|
|
|
с флагом O_SYNC. Может улучшить скорость чтения для относительно медленных
|
|
|
|
|
дисков - HDD и, возможно, SATA SSD. Не рекомендуется для потребительских
|
|
|
|
|
SSD без конденсаторов, так как O_SYNC сбрасывает кэш диска при каждой записи.
|
|
|
|
|
- name: cached_io_meta
|
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
|
|
|
|
info: |
|
|
|
|
|
Read and write *metadata* through Linux page cache. May improve read
|
|
|
|
|
performance only if your drives are relatively slow (HDD, SATA SSD), and
|
|
|
|
|
only if checksums are enabled and [inmemory_metadata](#inmemory_metadata)
|
|
|
|
|
is disabled, because in this case metadata blocks are read from disk
|
|
|
|
|
on every read request to verify checksums and caching them may reduce this
|
|
|
|
|
extra read load.
|
|
|
|
|
|
|
|
|
|
Absolutely pointless to enable with enabled inmemory_metadata because all
|
|
|
|
|
metadata is kept in memory anyway, and likely pointless without checksums,
|
|
|
|
|
because in that case, metadata blocks are read from disk only during journal
|
|
|
|
|
flushing.
|
|
|
|
|
|
|
|
|
|
If the same device is used for data and metadata, enabling [cached_io_data](#cached_io_data)
|
|
|
|
|
also enables this parameter, given that it isn't turned off explicitly.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Читать и записывать *метаданные* через системный кэш Linux. Может улучшить
|
|
|
|
|
скорость чтения, если у вас медленные диски, и только если контрольные суммы
|
|
|
|
|
включены, а параметр [inmemory_metadata](#inmemory_metadata) отключён, так
|
|
|
|
|
как в этом случае блоки метаданных читаются с диска при каждом запросе чтения
|
|
|
|
|
для проверки контрольных сумм и их кэширование может снизить дополнительную
|
|
|
|
|
нагрузку на диск.
|
|
|
|
|
|
|
|
|
|
Абсолютно бессмысленно включать данный параметр, если параметр
|
|
|
|
|
inmemory_metadata включён (по умолчанию это так), и также вероятно
|
|
|
|
|
бессмысленно включать его, если не включены контрольные суммы, так как в
|
|
|
|
|
этом случае блоки метаданных читаются с диска только во время сброса
|
|
|
|
|
журнала.
|
|
|
|
|
|
|
|
|
|
Если одно и то же устройство используется для данных и метаданных, включение
|
|
|
|
|
[cached_io_data](#cached_io_data) также включает данный параметр, при
|
|
|
|
|
условии, что он не отключён явным образом.
|
|
|
|
|
- name: cached_io_journal
|
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
|
|
|
|
info: |
|
|
|
|
|
Read and write *journal* through Linux page cache. May improve read
|
|
|
|
|
performance if [inmemory_journal](#inmemory_journal) is turned off.
|
|
|
|
|
|
|
|
|
|
If the same device is used for metadata and journal, enabling [cached_io_meta](#cached_io_meta)
|
|
|
|
|
also enables this parameter, given that it isn't turned off explicitly.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Читать и записывать *журнал* через системный кэш Linux. Может улучшить
|
|
|
|
|
скорость чтения, если параметр [inmemory_journal](#inmemory_journal)
|
|
|
|
|
отключён.
|
|
|
|
|
|
|
|
|
|
Если одно и то же устройство используется для метаданных и журнала,
|
|
|
|
|
включение [cached_io_meta](#cached_io_meta) также включает данный
|
|
|
|
|
параметр, при условии, что он не отключён явным образом.
|
2022-01-26 02:38:00 +03:00
|
|
|
|
- name: journal_sector_buffer_count
|
|
|
|
|
type: int
|
|
|
|
|
default: 32
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Maximum number of buffers that can be used for writing journal metadata
|
|
|
|
|
blocks. The only situation when you should increase it to a larger value
|
|
|
|
|
is when you enable journal_no_same_sector_overwrites. In this case set
|
|
|
|
|
it to, for example, 1024.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Максимальное число буферов, разрешённых для использования под записываемые
|
|
|
|
|
в журнал блоки метаданных. Единственная ситуация, в которой этот параметр
|
|
|
|
|
нужно менять - это если вы включаете journal_no_same_sector_overwrites. В
|
|
|
|
|
этом случае установите данный параметр, например, в 1024.
|
|
|
|
|
- name: journal_no_same_sector_overwrites
|
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Enable this option for SSDs like Intel D3-S4510 and D3-S4610 which REALLY
|
|
|
|
|
don't like when a program overwrites the same sector multiple times in a
|
2022-02-01 22:46:13 +03:00
|
|
|
|
row and slow down significantly (from 25000+ iops to ~3000 iops). When
|
2022-01-26 02:38:00 +03:00
|
|
|
|
this option is set, Vitastor will always move to the next sector of the
|
|
|
|
|
journal after writing it instead of possibly overwriting it the second time.
|
2022-01-29 23:43:22 +03:00
|
|
|
|
|
|
|
|
|
Most (99%) other SSDs don't need this option.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-02-01 22:46:13 +03:00
|
|
|
|
Включайте данную опцию для SSD вроде Intel D3-S4510 и D3-S4610, которые
|
|
|
|
|
ОЧЕНЬ не любят, когда ПО перезаписывает один и тот же сектор несколько раз
|
|
|
|
|
подряд. Такие SSD при многократной перезаписи одного и того же сектора
|
|
|
|
|
сильно замедляются - условно, с 25000 и более iops до 3000 iops. Когда
|
|
|
|
|
данная опция установлена, Vitastor всегда переходит к следующему сектору
|
|
|
|
|
журнала после записи вместо потенциально повторной перезаписи того же
|
|
|
|
|
самого сектора.
|
2022-01-29 23:43:22 +03:00
|
|
|
|
|
|
|
|
|
Почти все другие SSD (99% моделей) не требуют данной опции.
|
2022-01-26 02:38:00 +03:00
|
|
|
|
- name: throttle_small_writes
|
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Enable soft throttling of small journaled writes. Useful for hybrid OSDs
|
|
|
|
|
with fast journal/metadata devices and slow data devices. The idea is that
|
|
|
|
|
small writes complete very quickly because they're first written to the
|
|
|
|
|
journal device, but moving them to the main device is slow. So if an OSD
|
|
|
|
|
allows clients to issue a lot of small writes it will perform very good
|
|
|
|
|
for several seconds and then the journal will fill up and the performance
|
|
|
|
|
will drop to almost zero. Throttling is meant to prevent this problem by
|
|
|
|
|
artifically slowing quick writes down based on the amount of free space in
|
|
|
|
|
the journal. When throttling is used, the performance of small writes will
|
|
|
|
|
decrease smoothly instead of abrupt drop at the moment when the journal
|
|
|
|
|
fills up.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Разрешить мягкое ограничение скорости журналируемой записи. Полезно для
|
|
|
|
|
гибридных OSD с быстрыми устройствами метаданных и медленными устройствами
|
|
|
|
|
данных. Идея заключается в том, что мелкие записи в этой ситуации могут
|
|
|
|
|
завершаться очень быстро, так как они изначально записываются на быстрое
|
|
|
|
|
журнальное устройство (SSD). Но перемещать их потом на основное медленное
|
|
|
|
|
устройство долго. Поэтому если OSD быстро примет от клиентов очень много
|
|
|
|
|
мелких операций записи, он быстро заполнит свой журнал, после чего
|
|
|
|
|
производительность записи резко упадёт практически до нуля. Ограничение
|
|
|
|
|
скорости записи призвано решить эту проблему с помощью искусственного
|
|
|
|
|
замедления операций записи на основании объёма свободного места в журнале.
|
|
|
|
|
Когда эта опция включена, производительность мелких операций записи будет
|
|
|
|
|
снижаться плавно, а не резко в момент окончательного заполнения журнала.
|
|
|
|
|
- name: throttle_target_iops
|
|
|
|
|
type: int
|
|
|
|
|
default: 100
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Target maximum number of throttled operations per second under the condition
|
|
|
|
|
of full journal. Set it to approximate random write iops of your data devices
|
|
|
|
|
(HDDs).
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Расчётное максимальное число ограничиваемых операций в секунду при условии
|
|
|
|
|
отсутствия свободного места в журнале. Устанавливайте приблизительно равным
|
|
|
|
|
максимальной производительности случайной записи ваших устройств данных
|
|
|
|
|
(HDD) в операциях в секунду.
|
|
|
|
|
- name: throttle_target_mbs
|
|
|
|
|
type: int
|
|
|
|
|
default: 100
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Target maximum bandwidth in MB/s of throttled operations per second under
|
|
|
|
|
the condition of full journal. Set it to approximate linear write
|
|
|
|
|
performance of your data devices (HDDs).
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Расчётный максимальный размер в МБ/с ограничиваемых операций в секунду при
|
|
|
|
|
условии отсутствия свободного места в журнале. Устанавливайте приблизительно
|
|
|
|
|
равным максимальной производительности линейной записи ваших устройств
|
|
|
|
|
данных (HDD).
|
|
|
|
|
- name: throttle_target_parallelism
|
|
|
|
|
type: int
|
|
|
|
|
default: 1
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Target maximum parallelism of throttled operations under the condition of
|
|
|
|
|
full journal. Set it to approximate internal parallelism of your data
|
|
|
|
|
devices (1 for HDDs, 4-8 for SSDs).
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Расчётный максимальный параллелизм ограничиваемых операций в секунду при
|
|
|
|
|
условии отсутствия свободного места в журнале. Устанавливайте приблизительно
|
|
|
|
|
равным внутреннему параллелизму ваших устройств данных (1 для HDD, 4-8
|
|
|
|
|
для SSD).
|
|
|
|
|
- name: throttle_threshold_us
|
2022-02-01 22:46:13 +03:00
|
|
|
|
type: us
|
2022-01-26 02:38:00 +03:00
|
|
|
|
default: 50
|
2023-04-21 02:18:37 +03:00
|
|
|
|
online: true
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Minimal computed delay to be applied to throttled operations. Usually
|
|
|
|
|
doesn't need to be changed.
|
2022-01-29 11:01:33 +03:00
|
|
|
|
info_ru: |
|
2022-01-26 02:38:00 +03:00
|
|
|
|
Минимальная применимая к ограничиваемым операциям задержка. Обычно не
|
|
|
|
|
требует изменений.
|
2022-02-02 01:40:22 +03:00
|
|
|
|
- name: osd_memlock
|
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
2023-04-22 02:44:10 +03:00
|
|
|
|
info: |
|
2022-02-02 01:40:22 +03:00
|
|
|
|
Lock all OSD memory to prevent it from being unloaded into swap with
|
|
|
|
|
mlockall(). Requires sufficient ulimit -l (max locked memory).
|
2023-04-22 02:44:10 +03:00
|
|
|
|
info_ru: |
|
2022-02-02 01:40:22 +03:00
|
|
|
|
Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку
|
|
|
|
|
в пространство подкачки. Требует достаточного значения ulimit -l (лимита
|
|
|
|
|
заблокированной памяти).
|
2023-05-21 12:52:30 +03:00
|
|
|
|
- name: auto_scrub
|
2023-04-22 02:44:10 +03:00
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
|
|
|
|
online: true
|
|
|
|
|
info: |
|
2023-05-21 12:52:30 +03:00
|
|
|
|
Data scrubbing is the process of background verification of copies to find
|
|
|
|
|
and repair corrupted blocks. It's not run automatically by default since
|
|
|
|
|
it's a new feature. Set this parameter to true to enable automatic scrubs.
|
|
|
|
|
|
|
|
|
|
This parameter makes OSDs automatically schedule data scrubbing of clean PGs
|
|
|
|
|
every `scrub_interval` (see below). You can also start/schedule scrubbing
|
|
|
|
|
manually by setting `next_scrub` JSON key to the desired UNIX time of the
|
|
|
|
|
next scrub in `/pg/history/...` values in etcd.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Скраб - процесс фоновой проверки копий данных, предназначенный, чтобы
|
|
|
|
|
находить и исправлять повреждённые блоки. По умолчанию эти проверки ещё не
|
|
|
|
|
запускаются автоматически, так как являются новой функцией. Чтобы включить
|
|
|
|
|
автоматическое планирование скрабов, установите данный параметр в true.
|
|
|
|
|
|
|
|
|
|
Включённый параметр заставляет OSD автоматически планировать фоновую
|
|
|
|
|
проверку чистых PG раз в `scrub_interval` (см. ниже). Вы также можете
|
|
|
|
|
запустить или запланировать проверку вручную, установив значение ключа JSON
|
|
|
|
|
`next_scrub` внутри ключей etcd `/pg/history/...` в UNIX-время следующей
|
|
|
|
|
желаемой проверки.
|
|
|
|
|
- name: no_scrub
|
2023-04-22 02:44:10 +03:00
|
|
|
|
type: bool
|
|
|
|
|
default: false
|
|
|
|
|
online: true
|
|
|
|
|
info: |
|
2023-05-21 12:52:30 +03:00
|
|
|
|
Temporarily disable scrubbing and stop running scrubs.
|
2023-04-22 02:44:10 +03:00
|
|
|
|
info_ru: |
|
2023-05-21 12:52:30 +03:00
|
|
|
|
Временно отключить и остановить запущенные скрабы.
|
2023-04-22 02:44:10 +03:00
|
|
|
|
- name: scrub_interval
|
|
|
|
|
type: string
|
|
|
|
|
default: 30d
|
|
|
|
|
online: true
|
|
|
|
|
info: |
|
|
|
|
|
Default automatic scrubbing interval for all pools. Numbers without suffix
|
|
|
|
|
are treated as seconds, possible unit suffixes include 's' (seconds),
|
|
|
|
|
'm' (minutes), 'h' (hours), 'd' (days), 'M' (months) and 'y' (years).
|
|
|
|
|
info_ru: |
|
|
|
|
|
Интервал автоматической фоновой проверки по умолчанию для всех пулов.
|
|
|
|
|
Значения без указанной единицы измерения считаются в секундах, допустимые
|
|
|
|
|
символы единиц измерения в конце: 's' (секунды),
|
|
|
|
|
'm' (минуты), 'h' (часы), 'd' (дни), 'M' (месяца) или 'y' (годы).
|
|
|
|
|
- name: scrub_queue_depth
|
|
|
|
|
type: int
|
|
|
|
|
default: 1
|
|
|
|
|
online: true
|
|
|
|
|
info: |
|
|
|
|
|
Number of parallel scrubbing operations per one OSD.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Число параллельных операций фоновой проверки на один OSD.
|
|
|
|
|
- name: scrub_sleep
|
|
|
|
|
type: ms
|
|
|
|
|
default: 0
|
|
|
|
|
online: true
|
|
|
|
|
info: |
|
|
|
|
|
Additional interval between two consecutive scrubbing operations on one OSD.
|
|
|
|
|
Can be used to slow down scrubbing if it affects user load too much.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Дополнительный интервал ожидания после фоновой проверки каждого объекта на
|
|
|
|
|
одном OSD. Может использоваться для замедления скраба, если он слишком
|
|
|
|
|
сильно влияет на пользовательскую нагрузку.
|
|
|
|
|
- name: scrub_list_limit
|
|
|
|
|
type: int
|
|
|
|
|
default: 1000
|
|
|
|
|
online: true
|
|
|
|
|
info: |
|
|
|
|
|
Number of objects to list in one listing operation during scrub.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Размер загружаемых за одну операцию списков объектов в процессе фоновой
|
|
|
|
|
проверки.
|
2023-05-21 12:15:37 +03:00
|
|
|
|
- name: scrub_find_best
|
|
|
|
|
type: bool
|
|
|
|
|
default: true
|
|
|
|
|
online: true
|
|
|
|
|
info: |
|
|
|
|
|
Find and automatically restore best versions of objects with unmatched
|
|
|
|
|
copies. In replicated setups, the best version is the version with most
|
|
|
|
|
matching replicas. In EC setups, the best version is the subset of data
|
|
|
|
|
and parity chunks without mismatches.
|
|
|
|
|
|
|
|
|
|
The hypothetical situation where you might want to disable it is when
|
|
|
|
|
you have 3 replicas and you are paranoid that 2 HDDs out of 3 may silently
|
|
|
|
|
corrupt an object in the same way (for example, zero it out) and only
|
|
|
|
|
1 HDD will remain good. In this case disabling scrub_find_best may help
|
|
|
|
|
you to recover the data! See also scrub_ec_max_bruteforce below.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Находить и автоматически восстанавливать "лучшие версии" объектов с
|
|
|
|
|
несовпадающими копиями/частями. При использовании репликации "лучшая"
|
|
|
|
|
версия - версия, доступная в большем числе экземпляров, чем другие. При
|
2023-05-21 18:36:44 +03:00
|
|
|
|
использовании кодов коррекции ошибок "лучшая" версия - это подмножество
|
2023-05-21 12:15:37 +03:00
|
|
|
|
частей данных и чётности, полностью соответствующих друг другу.
|
|
|
|
|
|
|
|
|
|
Гипотетическая ситуация, в которой вы можете захотеть отключить этот
|
|
|
|
|
поиск - это если у вас 3 реплики и вы боитесь, что 2 диска из 3 могут
|
|
|
|
|
незаметно и одинаково повредить данные одного и того же объекта, например,
|
|
|
|
|
занулив его, и только 1 диск останется неповреждённым. В этой ситуации
|
|
|
|
|
отключение этого параметра поможет вам восстановить данные! Смотрите также
|
|
|
|
|
описание следующего параметра - scrub_ec_max_bruteforce.
|
2023-04-22 02:44:10 +03:00
|
|
|
|
- name: scrub_ec_max_bruteforce
|
|
|
|
|
type: int
|
|
|
|
|
default: 100
|
|
|
|
|
online: true
|
|
|
|
|
info: |
|
|
|
|
|
Vitastor can locate corrupted chunks in EC setups with more than 1 parity
|
|
|
|
|
chunk by brute-forcing all possible error locations. This configuration
|
|
|
|
|
value limits the maximum number of checked combinations. You can try to
|
|
|
|
|
increase it if you have EC N+K setup with N and K large enough for
|
|
|
|
|
combination count `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!` to be greater
|
|
|
|
|
than the default 100.
|
|
|
|
|
|
|
|
|
|
If there are too many possible combinations or if multiple combinations give
|
|
|
|
|
correct results then objects are marked inconsistent and aren't recovered
|
|
|
|
|
automatically.
|
|
|
|
|
|
|
|
|
|
In replicated setups bruteforcing isn't needed, Vitastor just assumes that
|
|
|
|
|
the variant with most available equal copies is correct. For example, if
|
|
|
|
|
you have 3 replicas and 1 of them differs, this one is considered to be
|
|
|
|
|
corrupted. But if there is no "best" version with more copies than all
|
|
|
|
|
others have then the object is also marked as inconsistent.
|
|
|
|
|
info_ru: |
|
|
|
|
|
Vitastor старается определить повреждённые части объектов при использовании
|
|
|
|
|
EC (кодов коррекции ошибок) с более, чем 1 диском чётности, путём перебора
|
|
|
|
|
всех возможных комбинаций ошибочных частей. Данное значение конфигурации
|
|
|
|
|
ограничивает число перебираемых комбинаций. Вы можете попробовать поднять
|
|
|
|
|
его, если используете схему кодирования EC N+K с N и K, достаточно большими
|
|
|
|
|
для того, чтобы число сочетаний `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!`
|
|
|
|
|
было больше, чем стандартное значение 100.
|
|
|
|
|
|
|
|
|
|
Если возможных комбинаций слишком много или если корректная комбинаций не
|
|
|
|
|
определяется однозначно, объекты помечаются неконсистентными (inconsistent)
|
|
|
|
|
и не восстанавливаются автоматически.
|
|
|
|
|
|
|
|
|
|
При использовании репликации перебор не нужен, Vitastor просто предполагает,
|
|
|
|
|
что вариант объекта с наибольшим количеством одинаковых копий корректен.
|
|
|
|
|
Например, если вы используете 3 реплики и 1 из них отличается, эта 1 копия
|
|
|
|
|
считается некорректной. Однако, если "лучшую" версию с числом доступных
|
|
|
|
|
копий большим, чем у всех других версий, найти невозможно, то объект тоже
|
|
|
|
|
маркируется неконсистентным.
|