212 lines
18 KiB
Markdown
212 lines
18 KiB
Markdown
|
[Документация](../../README-ru.md#документация) → Использование → Администрирование
|
|||
|
|
|||
|
-----
|
|||
|
|
|||
|
[Read in English](admin.en.md)
|
|||
|
|
|||
|
# Администрирование
|
|||
|
|
|||
|
- [Состояния пулов](#состояния-пулов)
|
|||
|
- [Состояния PG](#состояния-pg)
|
|||
|
- [Базовые состояния PG](#базовые-состояния-pg)
|
|||
|
- [Дополнительные состояния PG](#дополнительные-состояния-pg)
|
|||
|
- [Удаление исправного диска](#удаление-исправного-диска)
|
|||
|
- [Удаление неисправного диска](#удаление-неисправного-диска)
|
|||
|
- [Добавление диска](#добавление-диска)
|
|||
|
- [Восстановление потерянной конфигурации пулов](#восстановление-потерянной-конфигурации-пулов)
|
|||
|
- [Обновление Vitastor](#обновление-vitastor)
|
|||
|
- [Потребление памяти OSD](#потребление-памяти-osd)
|
|||
|
|
|||
|
## Состояния пулов
|
|||
|
|
|||
|
Пул активен — то есть, полностью доступен для клиентского ввода-вывода — когда все его PG
|
|||
|
активны, то есть, имеют статус active, возможно, с любым набором дополнительных флагов.
|
|||
|
|
|||
|
Если хотя бы 1 PG неактивна, пул неактивен и все клиенты зависают и ждут, пока вы почините
|
|||
|
кластер. :-)
|
|||
|
|
|||
|
## Состояния PG
|
|||
|
|
|||
|
Вы можете видеть состояния PG в выводе команды [vitastor-cli status](cli.ru.md#status).
|
|||
|
|
|||
|
Состояние PG состоит из ровно 1 базового флага состояния, плюс любого числа дополнительных.
|
|||
|
|
|||
|
### Базовые состояния PG
|
|||
|
|
|||
|
Состояние PG включает в себя ровно 1 флаг из следующих:
|
|||
|
- **active** — PG активна и обрабатывает запросы ввода-вывода от пользователей.
|
|||
|
- **incomplete** — Недостаточно живых OSD, чтобы включить эту PG.
|
|||
|
То есть, дисков потеряно больше, чем разрешено схемой отказоустойчивости пула и pg_minsize.
|
|||
|
Например, если у пула pg_size=3 и pg_minsize=1, то часть данных может записаться всего на 1 OSD.
|
|||
|
Если потом конкретно этот OSD упадёт, PG окажется **incomplete**.
|
|||
|
- **offline** — PG вообще не активирована ни одним OSD. Либо первичный OSD не назначен вообще
|
|||
|
(если пул только создан), либо в качестве первичного назначен недоступный OSD, либо
|
|||
|
назначенный OSD отказывается запускать эту PG (например, из-за несовпадения block_size),
|
|||
|
либо PG остановлена монитором через флаг `pause: true` в `/vitastor/config/pgs` в etcd.
|
|||
|
- **starting** — первичный OSD захватил блокировку PG в etcd, PG запускается.
|
|||
|
- **peering** — первичный OSD опрашивает вторичные OSD на предмет списков объектов данной PG и рассчитывает её состояние.
|
|||
|
- **repeering** — PG ожидает завершения текущих операций ввода-вывода, после чего перейдёт в состояние **peering**.
|
|||
|
- **stopping** — PG ожидает завершения текущих операций ввода-вывода, после чего перейдёт в состояние **offline** или поднимется на другом OSD.
|
|||
|
|
|||
|
Все состояния, кроме **active**, означают, что PG неактивна и ввод-вывод приостановлен.
|
|||
|
|
|||
|
Состояние **peering** в норме заметно только при перезапуске OSD или переключении первичных
|
|||
|
OSD, на протяжении небольшого периода времени.
|
|||
|
|
|||
|
Состояния **starting**, **repeering**, **stopping** в норме практически не заметны вообще,
|
|||
|
PG должны очень быстро переходить из них в другие. Если эти состояния заметны
|
|||
|
хоть сколько-то значительное время — вероятно, какие-то операции на каких-то OSD зависли.
|
|||
|
Чтобы найти их, ищите "slow op" в журналах OSD — операции, зависшие дольше,
|
|||
|
чем на [slow_log_interval](../config/osd.ru.md#slow_log_interval), записываются в
|
|||
|
журналы OSD как "slow op".
|
|||
|
|
|||
|
Диаграмма переходов:
|
|||
|
|
|||
|
![Диаграмма переходов](pg_states.svg "Диаграмма переходов")
|
|||
|
|
|||
|
### Дополнительные состояния PG
|
|||
|
|
|||
|
Если PG активна, она также может иметь любое число дополнительных флагов состояний:
|
|||
|
|
|||
|
- **degraded** — PG поднята на неполном числе дисков (OSD), избыточность хранения всех объектов снижена.
|
|||
|
- **has_incomplete** — часть объектов в PG неполные (невосстановимые), то есть, у них потеряно
|
|||
|
слишком много EC-частей (больше, чем [parity_chunks](../config/pool.ru.md#parity_chunks) пула).
|
|||
|
- **has_degraded** — часть объектов в PG деградированы, избыточность их хранения снижена по сравнению
|
|||
|
с остальным содержимым данной PG (то есть, PG может одновременно быть degraded+has_degraded).
|
|||
|
Данные объекты должны восстановиться автоматически, если только восстановление не отключено
|
|||
|
через [no_recovery](../config/osd.ru.md#no_recovery).
|
|||
|
- **has_misplaced** — часть объектов в PG сейчас расположена не на целевом наборе OSD этой PG.
|
|||
|
Данные объекты должны переместиться автоматически, если только перебалансировка не отключена
|
|||
|
через [no_rebalance](../config/osd.ru.md#no_rebalance). Объекты, являющиеся одновременно
|
|||
|
degraded и misplaced, считаются просто degraded.
|
|||
|
- **has_unclean** — ещё одно состояние, в норме заметное только очень короткое время при поднятии PG.
|
|||
|
Применяется только к EC и означает, что на каких-то OSD этой PG есть EC-части объектов, для которых
|
|||
|
был начат, но не завершён процесс записи. Все такие объекты первичный OSD либо завершает, либо
|
|||
|
откатывает при поднятии PG первым делом, поэтому состояние и не должно быть заметно. Опять-таки,
|
|||
|
если оно заметно — значит, скорее всего, операции отката или завершения записи на каких-то OSD зависли.
|
|||
|
- **has_invalid** — в PG найдены объекты с некорректными ID части. В норме не проявляется вообще
|
|||
|
никогда, проявляется только если, не удалив данные, создать на месте EC-пула либо реплика-пул,
|
|||
|
либо EC-пул с меньшим числом частей данных.
|
|||
|
- **has_corrupted** — в PG есть повреждённые объекты, обнаруженные с помощью контрольных сумм или
|
|||
|
скраба (сверки копий). Если объекты можно восстановить, они восстановятся автоматически. Если
|
|||
|
не восстанавливаются, используйте команду [vitastor-cli describe](cli.ru.md#describe) для
|
|||
|
выяснения деталей и/или смотрите в журнал первичного OSD данной PG.
|
|||
|
- **has_inconsistent** — в PG есть объекты, у которых не совпадают копии/части данных на разных OSD,
|
|||
|
и при этом автоматически определить, какая копия верная, а какая нет, невозможно. Такое может
|
|||
|
произойти, если вы используете 2 реплики, не включали контрольные суммы, и на одной из реплик
|
|||
|
данные повредились. В этом случае тоже надо использовать команды vitastor-cli [describe](cli.ru.md#describe)
|
|||
|
и [fix](cli.ru.md#fix) для удаления некорректной версии.
|
|||
|
- **left_on_dead** — часть данных PG осталась на отключённом, но не удалённом из кластера окончательно,
|
|||
|
OSD. Вам нужно либо вернуть соответствующий OSD в строй и дать ему очистить лишние данные, либо
|
|||
|
удалить его из кластера окончательно с помощью vitastor-cli [rm-osd](cli.ru.md#rm-osd), если
|
|||
|
известно, что он уже не вернётся (например, если умер диск).
|
|||
|
- **scrubbing** — идёт фоновая проверка данных PG ([скраб](../config/osd.ru.md#auto_scrub)).
|
|||
|
|
|||
|
## Удаление исправного диска
|
|||
|
|
|||
|
Перед удалением исправного диска из кластера установите его OSD вес в 0, чтобы убрать с него данные.
|
|||
|
Для этого добавьте в ключ `/vitastor/config/osd/<НОМЕР_OSD>` в etcd значение `"reweight":0`, например:
|
|||
|
|
|||
|
```
|
|||
|
etcdctl --endpoints=http://1.1.1.1:2379/v3 put /vitastor/config/osd/1 '{"reweight":0}'
|
|||
|
```
|
|||
|
|
|||
|
Дождитесь завершения ребаланса, после чего удалите OSD командой `vitastor-disk purge /dev/vitastor/osdN-data`.
|
|||
|
|
|||
|
## Удаление неисправного диска
|
|||
|
|
|||
|
Если диск уже умер, его OSD, скорее всего, уже будет/будут остановлен(ы).
|
|||
|
|
|||
|
В этом случае просто удалите OSD из etcd командой `vitastor-cli rm-osd НОМЕР_OSD`.
|
|||
|
|
|||
|
## Добавление диска
|
|||
|
|
|||
|
Если сервер новый, установите на него пакеты Vitastor и скопируйте файл конфигурации
|
|||
|
`/etc/vitastor/vitastor.conf`.
|
|||
|
|
|||
|
После этого достаточно выполнить команду `vitastor-disk prepare /dev/nvmeXXX`, разумеется,
|
|||
|
с параметрами, аналогичными другим OSD в вашем кластере.
|
|||
|
|
|||
|
## Восстановление потерянной конфигурации пулов
|
|||
|
|
|||
|
Если удалить или повредить ключ `/vitastor/config/pools` в etcd, все пулы будут удалены.
|
|||
|
Не волнуйтесь, данные потеряны не будут, но вам нужно будет провести специальную
|
|||
|
процедуру восстановления.
|
|||
|
|
|||
|
Сначала нужно будет восстановить конфигурацию пулов, создав пул с таким же ID и
|
|||
|
с такими же параметрами EC/реплик, и подождать, пока PG пула появятся в `vitastor-cli status`.
|
|||
|
|
|||
|
Далее нужно будет добавить все OSD в исторические записи всех PG. Примерно так
|
|||
|
(только подставьте свои PG_COUNT и POOL_ID):
|
|||
|
|
|||
|
```
|
|||
|
PG_COUNT=32
|
|||
|
POOL_ID=1
|
|||
|
ALL_OSDS=$(etcdctl --endpoints=your_etcd_address:2379 get --keys-only --prefix /vitastor/osd/stats/ | \
|
|||
|
perl -e '$/ = undef; $a = <>; $a =~ s/\s*$//; $a =~ s!/vitastor/osd/stats/!!g; $a =~ s/\s+/,/g; print $a')
|
|||
|
for i in $(seq 1 $PG_COUNT); do
|
|||
|
etcdctl --endpoints=your_etcd_address:2379 put /vitastor/pg/history/$POOL_ID/$i '{"all_peers":['$ALL_OSDS']}'; done
|
|||
|
done
|
|||
|
```
|
|||
|
|
|||
|
После этого все PG должны пройти peering и найти все предыдущие данные.
|
|||
|
|
|||
|
## Обновление Vitastor
|
|||
|
|
|||
|
Обычно каждая следующая версия Vitastor совместима с предыдущими и "вперёд", и "назад"
|
|||
|
с точки зрения сетевого протокола и структур данных в etcd.
|
|||
|
|
|||
|
Так что по умолчанию, если на данной странице не указано обратное, считается, что для
|
|||
|
обновления достаточно обновить пакеты и перезапустить все OSD и мониторы Vitastor в
|
|||
|
произвольном порядке.
|
|||
|
|
|||
|
Обновление производится без остановки клиентов (виртуальных машин/контейнеров), для этого
|
|||
|
достаточно обновлять серверы по одному. Однако, конечно, чтобы запущенные виртуальные машины
|
|||
|
начали использовать новую версию клиентской библиотеки, их тоже нужно перезапустить.
|
|||
|
|
|||
|
Исключения (особые указания при обновлении):
|
|||
|
- Обновляться с версий <= 1.1.x до версий >= 1.2.0, если вы используете EC n+k и k>=2,
|
|||
|
рекомендуется с временной остановкой кластера — сначала нужно остановить всех клиентов,
|
|||
|
потом все OSD, потом обновить и запустить всё обратно — из-за нескольких багов, которые
|
|||
|
могли приводить к некорректному чтению данных в деградированных EC-пулах.
|
|||
|
- Версии <= 0.8.7 несовместимы с версиями >= 0.9.0, поэтому при обновлении с <= 0.8.7
|
|||
|
нужно сначала обновиться до 0.8.8 или 0.8.9, а уже потом до любых версий >= 0.9.x.
|
|||
|
Иначе клиентский ввод-вывод зависнет до завершения обновления.
|
|||
|
- Обновление с версий 0.5.x и более ранних до 0.6.x и более поздних не поддерживается.
|
|||
|
|
|||
|
Откат:
|
|||
|
- В версии 1.0.0 поменялся дисковый формат, поэтому OSD, созданные на версии >= 1.0.0,
|
|||
|
нельзя откатить до версии 0.9.x и более ранних.
|
|||
|
- В версиях ранее 0.8.0 нет vitastor-disk, значит, созданные им OSD нельзя откатить
|
|||
|
до 0.7.x или 0.6.x. :-)
|
|||
|
|
|||
|
## Потребление памяти OSD
|
|||
|
|
|||
|
Основное потребление памяти складывается из:
|
|||
|
|
|||
|
- Индекс метаданных: `размер_данных`/[`block_size`](../config/layout-cluster.ru.md#block_size) * `примерно 1.1` * `32` байт.
|
|||
|
Потребляется всегда.
|
|||
|
- Копия дисковой области метаданных: `размер_данных`/[`block_size`](../config/layout-cluster.ru.md#block_size) * `28` байт.
|
|||
|
Потребляется, если не отключена настройка [inmemory_metadata](../config/osd.ru.md#inmemory_metadata).
|
|||
|
- Битмапы: `размер_данных`/[`bitmap_granularity`](../config/layout-cluster.ru.md#bitmap_granularity)/`8` * `2` байт.
|
|||
|
Потребляется всегда.
|
|||
|
- Индекс журнала: от 0 до, приблизительно, размера журнала. Потребляется всегда.
|
|||
|
- Копия дисковой области журнала: в точности размер журнала. Потребляется,
|
|||
|
если не отключена настройка [inmemory_journal](../config/osd.ru.md#inmemory_journal).
|
|||
|
- Контрольные суммы: `размер_данных`/[`csum_block_size`](../config/osd.ru.md#csum_block_size) * `4` байт.
|
|||
|
Потребляется, если включены контрольные суммы и не отключена настройка [inmemory_metadata](../config/osd.ru.md#inmemory_metadata).
|
|||
|
|
|||
|
bitmap_granularity, как правило, никогда не меняется и равен 4 килобайтам.
|
|||
|
|
|||
|
Таким образом, при SSD-настройках по умолчанию (block_size=128k, journal_size=32M, csum_block_size=4k) потребляется:
|
|||
|
|
|||
|
- Метаданные и битмапы: ~600 МБ на 1 ТБ данных
|
|||
|
- Журнал: до 64 МБ на 1 OSD
|
|||
|
- Контрольные суммы: 1 ГБ на 1 ТБ данных
|
|||
|
|
|||
|
При HDD-настройках по умолчанию (block_size=1M, journal_size=128M, csum_block_size=32k):
|
|||
|
|
|||
|
- Метаданные и битмапы: ~128 МБ на 1 ТБ данных
|
|||
|
- Журнал: до 256 МБ на 1 OSD
|
|||
|
- Контрольные суммы: 128 МБ на 1 ТБ данных
|