Комментарии 20
в первом кейс не очень понятна зачем монитор удаляете. По выводу команд осмелюсь предположить что у вас кластер из 3 нод и вы на каждую ноду заводите монитор. Опасная схема получается. У вас остается 2 монитора — один флапнул по сети и кластер встает колом. кмк безопасней завести 3 монитор на доп хосте т.к. сефу для наличия калстера необходимо строго больше 50% мониторов(т.е. 1 из 2 стоим колом)
сторого говоря, можно загасить одну ноду без ребаланса предварительного(если состояние кластера без дегрэйдов конечно). тогда у вас остается 2 реплики из 3 и вы по перфомансу не просядете во время ребаланса. а когда заводите новый сервер, то него пойдут данныу и этот процесс не будет афектить запись в кластер(афектить в том смысле, что дожидаться синхронизации объектов в рамках Pg)
Касательно ситуации с количеством мониторов: мы всегда стараемся добавлять их в большем количестве, устанавливая на системные ноды для большей отказоустойчивости. В этой же статье все было сделано в рамках проекта-песочницы — он не боевой, поэтому нет необходимости в добавлении дополнительных мониторов.
если не секрет, какие аргументы делать более 3 мониторов? а как следите что бы мониторов не было четное колличество?
Есть 4 монитора. 2 упало. Что с кластером будет?
Да, проблем нет, если только не считать, что конфиги с четным числом мониторов заметно менее надёжны, чем аналогичные на одну ноду меньше
По очень грубой прикидке, если взять надежность (вероятность того, что за некий период времени все будет хорошо) одной ноды за 0.9, то получается:
- для системы из одной ноды вероятность сломаться 0.1
- система из 2 нод будет работать только если с обеими нодами все хорошо, т.е. надежность
0.9*0.9 = 0.81, и вероятность сломаться 0.19 — почти в два раза выше, чем в случае с одной нодой - система из 3 нод будет работать только если либо со всем нодами все хорошо, либо сломалось не более одной ноды, т.е. надежность
0.9^3+3*0.9^2*0.1=0.972, и вероятность сломаться 0.028 — существенно меньше чем с одной нодой - система из 4 нод по прежнему переживает выход из строя только одной ноды, поэтому тут надежность
0.9^4+4*0.9^3*0.1=0.9477, и вероятность сломаться 0.0523 — все еще меньше, чем с одной нодой, но в два раза выше, чем с тремя - система из 5 нод уже может пережить выход из строя двух нод, надежность
0.9^5+5*0.9^4*0.1+10*0.9^3*0.1^2=0.99144, вероятность сломаться 0.00856 — существенно лучше, чем для трех нод
Продолжать можно до бесконечности, но думаю и так видно, что прирост количества нод дает существенное повышение надежности на нечетных количествах, но так же заметно проседает на четных.
при прочих равных все будет одинаково — у вас либо умрет два хоста и кластер встанет колом в обоих случаях, либо умрет один хост и кластер не встанет в обоих случаях.
Если считать приближённо, то две ноды из трёх могут сломаться тремя разными способами (1 и 2, 1 и 3, 2 и 3), а две ноды из четырёх — шестью (1 и 2, 1 и 3, 1 и 4, 2 и 3, 2 и 4, 3 и 4).
При прочих равных вероятность смерти двух хостов из четырех заметно выше смерти двух хостов из трех. Это если совсем на пальцах.
Определите, пожалуйста, «нагруженный» и «большой объём» в каких-нибудь числах, характеризующих непосредственно хранилище? Ceph используете как блочное хранилище, или объектное/CephFS тоже?
Давайте побыстрому пробежимся, и начнем с малого: «Плавная балансировка необходима, чтобы не потерять данные. Это особенно актуально, если в OSD находится большой объем данных». Пока вы не выключили OSD, количество реплик данных не уменьшается и вы ничего не потеряете.
Поэтому всё, что можно добиться «плавной балансировкой» — это пустой потери времени.
Наиболее быстрый алгоритм — запретить ребаланс (norebalance):
ceph osd set norebalance
Добавить в CRUSH новые OSD и сделать вес 0 старым. При этом у вас появятся remapped PG, которые по-прежнему удерживают реплики данных — поэтому у вас не возникает degraded/undersized PG.
Для полноты картины можно установить primary affinity удаляемым и добавляемым OSD равным 0:
ceph osd primary-affinity osd.$OLD 0
ceph osd primary-affinity osd.$NEW 0
Затем снижаете backfill до 1:
ceph tell osd.* injectargs --osd_max_backfill=1
Снимаете norebalance:
ceph osd unset norebalance
И данные поехали. При этом происходит примерно одно копирование данных, в то время как при «плавном уменьшении» веса у вас перемещений будет сильно больше. Если вам нужно остановить плановую миграцию — просто ставите снова norebalance. При этом если OSD откажет — у вас начнется срочный бакфил всех PG для которых количество реплик меньше заданного — и только их. Те который проосто «не на своих местах» никуда не двигаются пока стоит norebalance.
То же самое при выводе OSD (не замене). Меняем primary affinity, придавливаем бакфилл, сбрасываем вес OSD до 0 и в одну итерацию двигаем данные.
P.S.: я специально указывал norebalance а не nobackfill, потому что norebealance более щадящая опция — она останавливает ребаланс только тех PG, которые имеют достаточное количество реплик.
Tips & tricks в работе с Ceph в нагруженных проектах