Растянутый кластер на двух локациях: обработка сбоев
Во 2 части этой серии мы рассмотрели практическое развертывание кластера Ceph на двух площадках с отдельной tie-breaker локацией, с использованием пользовательского файла спецификации для компонентов Ceph, CRUSH-правил и мест размещения компонентов.
В финальной части мы протестируем эту конфигурацию и изучим, что происходит, когда весь дата-центр выходит из строя.
Вступление
Главная цель любого растянутого кластера на двух площадках — обеспечить полную работоспособность приложений, даже если один из дата-центров отключится. Благодаря синхронной репликации кластер может прозрачно обрабатывать запросы клиентов, поддерживая нулевое значение RPO (Recovery Point Objective) и предотвращая потерю данных даже при полном сбое локации.
Синхронная репликация позволяет кластеру прозрачно обрабатывать запросы клиентов, поддерживая нулевое значение RPO (Recovery Point Objective) и предотвращая потерю данных даже при полном сбое локации.
В третьей и заключительной статье из этой серии рассмотрим, как Ceph автоматически обнаруживает и изолирует дата-центр, в котором произошел сбой. Растянутый кластер переходит в stretch degraded mode, а монитор tie-breaker обеспечивает кворум. В этот момент временно применяются ограничения репликации, чтобы сохранить доступность сервисов на оставшейся площадке.
После восстановления автономного дата-центра, мы продемонстрируем, как кластер плавно переходит обратно к полноценной работоспособности, возвращая полное резервирование и операции синхронизации без ручного вмешательства. Конечные пользователи и администраторы хранилища сталкиваются с минимальными сбоями в работе и нулевой потерей данных на всем процессе.
Мы потеряли целый дата-центр!
Кластер работает, наши мониторы имеют кворум, а действующий набор для наших PG (Placement Group) включает в себя четыре OSD (Object Storage Daemon), по два с каждого сайта. Наши пулы настроены с правилом репликации с параметрами size=4 и min_size 2.
# ceph -s
cluster:
id: 90441880-e868-11ef-b468-52540016bbfa
health: HEALTH_OK
services:
mon: 5 daemons, quorum ceph-node-00,ceph-node-06,ceph-node-04,ceph-node-03,ceph-node-01 (age 43h)
mgr: ceph-node-01.osdxwj(active, since 10d), standbys: ceph-node-04.vtmzkz
osd: 12 osds: 12 up (since 10d), 12 in (since 2w)
data:
pools: 2 pools, 33 pgs
objects: 23 objects, 42 MiB
usage: 1.4 GiB used, 599 GiB / 600 GiB avail
pgs: 33 active+clean
# ceph quorum_status --format json-pretty | jq .quorum_names
[
"ceph-node-00",
"ceph-node-06",
"ceph-node-04",
"ceph-node-03",
"ceph-node-01"
]
# ceph pg map 2.1
osdmap e264 pg 2.1 (2.1) -> up [1,3,9,11] acting [1,3,9,11]
# ceph osd pool ls detail | tail -2
pool 2 'rbdpool' replicated size 4 min_size 2 crush_rule 1 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change 199 lfor 199/199/199 flags hashpspool,selfmanaged_snaps stripe_width 0 application rbd read_balance_score 3.38Мы покажем диаграмму для каждой фазы, чтобы описать различные этапы во время сбоя. В этот момент происходит что-то непредвиденное, и мы теряем доступ ко всем нодам в DC1:
Вот выдержка из логов монитора на одной из оставшихся площадок — мониторы в DC1 считаются отключенными и удаляются из кворума:
2025-02-18T14:14:22.206+0000 7f05459fc640 0 log_channel(cluster) log [WRN] : [WRN] MON_DOWN: 2/5 mons down, quorum ceph-node-06,ceph-node-04,ceph-node-03
2025-02-18T14:14:22.206+0000 7f05459fc640 0 log_channel(cluster) log [WRN] : mon.ceph-node-00 (rank 0) addr [v2:192.168.122.12:3300/0,v1:192.168.122.12:6789/0] is down (out of quorum)
2025-02-18T14:14:22.206+0000 7f05459fc640 0 log_channel(cluster) log [WRN] : mon.ceph-node-01 (rank 4) addr [v2:192.168.122.179:3300/0,v1:192.168.122.179:6789/0] is down (out of quorum)Монитор, работающий на ceph-node-03 в DC2, призывает к выбору монитора, предлагает свою кандидатуру и принимается в качестве нового лидера:
2025-02-18T14:14:33.087+0000 7f0548201640 0 log_channel(cluster) log [INF] : mon.ceph-node-03 calling monitor election
2025-02-18T14:14:33.087+0000 7f0548201640 1 paxos.3).electionLogic(141) init, last seen epoch 141, mid-election, bumping
2025-02-18T14:14:38.098+0000 7f054aa06640 0 log_channel(cluster) log [INF] : mon.ceph-node-03 is new leader, mons ceph-node-06,ceph-node-04,ceph-node-03 in quorum (ranks 1,2,3)Каждый OSD посылает сигнал другим OSD со случайными интервалами менее шести секунд. Если соседний OSD не отправляет хартбит в течение 20-секундного периода ожидания, проверяющий OSD отмечает его как down и сообщает об этом монитору, который затем обновляет карту кластера.
По умолчанию два OSD с разных хостов должны сообщать мониторам о том, что другой OSD не работает, прежде чем мониторы подтвердят сбой. Это предотвращает ложные тревоги, нестабильное поведение и каскадные проблемы. Все оповещающие OSD могут размещаться в стойке с неисправным коммутатором, а это влияет на подключение к другим OSD. Чтобы избежать ложных тревог, мы рассматриваем сообщающие устройства как потенциальный подкластер, испытывающий проблемы.
Уровень «поддерева» Monitors OSD reporter объединяет пиры в подкластер по типу их общих родителей в CRUSH-карте. По умолчанию для объявления отключения OSD необходимы два отчета из разных «поддеревьев».
2025-02-18T14:14:29.233+0000 7f0548201640 1 mon.ceph-node-03@3(leader).osd e264 prepare_failure osd.0 [v2:192.168.122.12:6804/636515504,v1:192.168.122.12:6805/636515504] from osd.10 is reporting failure:1
2025-02-18T14:14:29.235+0000 7f0548201640 0 log_channel(cluster) log [DBG] : osd.0 reported failed by osd.10
2025-02-18T14:14:31.792+0000 7f0548201640 1 mon.ceph-node-03@3(leader).osd e264 we have enough reporters to mark osd.0 down
2025-02-18T14:14:31.844+0000 7f054aa06640 0 log_channel(cluster) log [WRN] : Health check failed: 2 osds down (OSD_DOWN)
2025-02-18T14:14:31.844+0000 7f054aa06640 0 log_channel(cluster) log [WRN] : Health check failed: 1 host (2 osds) down (OSD_HOST_DOWN)
Если вывести команду ceph status, мы видим, что кворум поддерживают ceph-node-06, ceph-node-04 и ceph-node-03:
# ceph -s | grep mon
2/5 mons down, quorum ceph-node-06,ceph-node-04,ceph-node-03
mon: 5 daemons, quorum ceph-node-06,ceph-node-04,ceph-node-03 (age 10s), out of quorum: ceph-node-00, ceph-node-01С помощью команды ceph osd tree видим, что экранные меню в DC1 выделены:
# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.58557 root default
-3 0.29279 datacenter DC1
-2 0.09760 host ceph-node-00
0 hdd 0.04880 osd.0 down 1.00000 1.00000
1 hdd 0.04880 osd.1 down 1.00000 1.00000
-4 0.09760 host ceph-node-01
3 hdd 0.04880 osd.3 down 1.00000 1.00000
7 hdd 0.04880 osd.7 down 1.00000 1.00000
-5 0.09760 host ceph-node-02
2 hdd 0.04880 osd.2 down 1.00000 1.00000
5 hdd 0.04880 osd.5 down 1.00000 1.00000
-7 0.29279 datacenter DC2
-6 0.09760 host ceph-node-03
4 hdd 0.04880 osd.4 up 1.00000 1.00000
6 hdd 0.04880 osd.6 up 1.00000 1.00000
-8 0.09760 host ceph-node-04
10 hdd 0.04880 osd.10 up 1.00000 1.00000
11 hdd 0.04880 osd.11 up 1.00000 1.00000
-9 0.09760 host ceph-node-05
8 hdd 0.04880 osd.8 up 1.00000 1.00000
9 hdd 0.04880 osd.9 up 1.00000 1.00000Ceph предупреждает о сбое работоспособности с помощью OSD_DATACENTER_DOWN, когда вся локация выходит из строя. Это сигнализирует, что один datacenter в CRUSH-карте недоступен из-за сбоя в сети, потери питания или другой проблемы. Запись из логов монитора:
2025-02-18T14:14:32.910+0000 7f054aa06640 0 log_channel(cluster) log [WRN] : Health check failed: 1 datacenter (6 osds) down (OSD_DATACENTER_DOWN)То же самое мы можем увидеть из команды ceph status:
# ceph -s
cluster:
id: 90441880-e868-11ef-b468-52540016bbfa
health: HEALTH_WARN
3 hosts fail cephadm check
We are missing stretch mode buckets, only requiring 1 of 2 buckets to peer
2/5 mons down, quorum ceph-node-06,ceph-node-04,ceph-node-03
1 datacenter (6 osds) down
6 osds down
3 hosts (6 osds) down
Degraded data redundancy: 46/92 objects degraded (50.000%), 18 pgs degraded, 33 pgs undersized
Когда весь дата-центр выходит из строя в сценарии с двумя локациями, Ceph переходит в режим stretch degraded mode. Вы увидите запись в логах монитора, подобную этой:
2025-02-18T14:14:32.992+0000 7f05459fc640 0 log_channel(cluster) log [WRN] : Health check failed: We are missing stretch mode buckets, only requiring 1 of 2 buckets to peer (DEGRADED_STRETCH_MODE)Stretch degraded mode
Stretch degraded mode — это самоуправляемый режим работы кластера Ceph. Он начинает действовать, когда мониторы подтверждают, что весь дата-центр в CRUSH-карте недоступен. Администраторам не нужно вручную включать или выключать локацию или дата-центр. Оркестратор Ceph автоматически обновляет карту OSD и состояния PG. Как только кластер переходит в Stretch degraded mode, эти действия происходят автоматически.
Stretch degraded mode означает, что Ceph для завершения операций записи или перевода PG в активное состояние больше не требует подтверждения от недоступных OSD в отказавшем дата-центре.
Смягченное правило пиринга в растянутом режиме
В растянутом режиме Ceph использует специальное правило растянутого пиринга: необходимо участие по крайней мере одного OSD с каждой площадки — только тогда PG сможет перейти в состояние active+clean. Правило гарантирует, что новые операции записи не повредятся, если одна локация полностью отключена — предотвращаем split-brain сценарии и обеспечиваем консистентную репликацию.
Перейдя в режим деградации, Ceph временно изменяет CRUSH-правило, так что для активации PG требуется только доступная локация, чтобы продолжить работу с клиентами без препятствий.
# ceph pg dump pgs_brief | grep 2.11
dumped pgs_brief
2.11 active+undersized+degraded [8,11] 8 [8,11] 8min_size всех пулов уменьшен до 1
Когда одна локация переходит в автономный режим, Ceph автоматически понижает атрибут min_size у пулов с 2 до 1 и позволяет каждой PG оставаться active и clean только с одной доступной репликой. Если значение min_size останется равным 2, сохранившаяся площадка не сможет поддерживать активные PG после потери половины своих локальных реплик, что приведет к остановке клиентского ввода-вывода. Временно уменьшив min_size до 1, Ceph гарантирует, что кластер сможет выдержать сбой OSD на оставшейся локации и продолжит выполнять операции чтения/записи до тех пор, пока не вернется работоспособность площадки.
Временный запуск с min_size=1 означает, что до восстановления автономной локации должна быть доступна только одна копия данных. Хотя так сервис работает, но увеличивается риск потери данных при дополнительных сбоях на работающей площадке. Кластер Ceph с SSD-носителями быстро возобновляют работу и снижают риск недоступности или потери данных в случае отказа дополнительного компонента в режиме stretch degraded.
# ceph osd pool ls detail
pool 1 '.mgr' replicated size 4 min_size 1 crush_rule 1 object_hash rjenkins pg_num 1 pgp_num 1 autoscale_mode on last_change 302 lfor 302/302/302 flags hashpspool stripe_width 0 pg_num_max 32 pg_num_min 1 application mgr read_balance_score 11.76
pool 2 'rbdpool' replicated size 4 min_size 1 crush_rule 1 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change 302 lfor 302/302/302 flags hashpspool,selfmanaged_snaps stripe_width 0 application rbd read_balance_score 2.62Все PG, для которых происходит сбой OSD, испытают кратковременный отказ в операциях клиента пока соответствующие OSD не объявятся down и действующий набор не изменится для каждого растянутого режима.
Клиенты продолжают считывать и записывать данные из двух сохранившихся копий локации, обеспечивая доступность сервиса и RPO=0 для всех операций записи.
Восстановление из stretch degraded mode
Когда недоступный дата-центр возвращается в рабочее состояние, его OSD присоединяются к кластеру, и Ceph автоматически переходит из режима деградации в полноценный растянутый режим. Процесс включает возобновление работы и backfill, чтобы вернуть для каждой PG правильное количество реплик, равное 4.
Когда OSD содержит консистентные журналы PG (и только ненадолго отключался), Ceph производит инкрементальное восстанавливление, копируя только новые изменения из других реплик. Когда OSD долго не работал и журналы PG не содержат полного набора изменений, Ceph инициирует операцию backfill для копирования всей PG. Этот процесс проверяет все объекты RADOS (Reliable Autonomic Distributed Object Store) в репликах и обновляет возвращаемые OSD с учетом случившихся изменений за то время, пока они были недоступны.
Восстановление и backfill влекут за собой дополнительные операции ввода-вывода — данные передаются между локациями для возвращения полной избыточности. Вот почему важно учитывать пропускную способность для восстановления сети при расчетах и планировании. Ceph регулирует эти операции с помощью настройки конфигурации mClock recovery/backfill, чтобы не перегружать клиентский ввод-вывод. Мы хотим вернуться к HEALTH_OK как можно скорее, чтобы обеспечить доступность и сохранность данных, поэтому решающее значение имеет адекватная пропускная способность между площадками. Это касается не только ежедневных операций чтения и записи, но и пиковых нагрузок при выходе из строя компонентов или расширении кластера.
После завершения восстановления или backfill всех затронутых PG, они возвращаются в статусе active+clean с двумя обновленными копиями, доступными для каждого центра. Затем Ceph возвращает временные изменения, внесенные во время режима деградации (например, min_size=1 снова в min_size=2). Предупреждение о растянутом режиме деградации исчезает после завершения — и сигнализирует о возобновлении полной избыточности.
Краткая демонстрация сбоя и восстановления сайта
В этой краткой демонстрации мы запускаем приложение, которое постоянно выполняет операции чтения и записи из RBD (Ceph Block Device). Синяя и зеленая точки обозначают операции чтения и записи приложения, а также задержку. Слева и справа от дашборда отображается статус дата-центров, а отдельные серверы будут обозначаться как отключенные, когда они недоступны. В этом демо мы видим, как теряем всю локацию, а наше приложение сообщает о задержке ввода-вывода всего на 27 секунд: время, необходимое для обнаружения и подтверждения, что OSD не работают. Как только локация вернется в строй, мы сможем увидеть, что PG восстанавливаются, используя реплики на оставшейся площадке.
Выводы
В финальной части мы увидели, как растянутый кластер на двух локациях реагирует на сбой в работе дата-центра. Он автоматически переходит в режим деградации, чтобы поддерживать сервисы в рабочем состоянии, а также без проблем восстанавливается при возвращении работоспособности площадки. Автоматическое отключение, упрощенные правила пиринга, уменьшенные значения min_size и синхронизация измененных данных после возобновления связности позволяют Ceph обрабатывать эти события с минимальным ручным вмешательством и без потери данных.
Авторы благодарят IBM за поддержку сообщества и за то, что они позволили уделить время созданию этих публикаций.