Растянутый кластер Ceph: две локации + Tie-breaker. Часть 2 / forpes.ru

Главная
Растянутый кластер Ceph: две локации + Tie-breaker. Часть 2

Растянутый кластер Ceph: две локации + Tie-breaker. Часть 2 +5

10.07.2025 08:29

runity 1 315 Источник

Вступление

В первой части мы представили концепции, лежащие в основе стратегий репликации Ceph, подчеркнув преимущества растянутого кластера для достижения нулевой потери данных (RPO=0). Во второй части мы сосредоточимся на практических шагах — развертывании растянутого кластера на двух локациях + монитора в качестве tie-breaker с использованием cephadm.

Сетевые аспекты

Сетевая архитектура

В растянутой архитектуре сеть играет решающую роль в поддержании общей работоспособности и производительности кластера.

— Ceph использует L3-маршрутизацию, для обеспечения связности между клиентами и компонентами Ceph через подсети/CIDR в каждом дата-центре/локации.

— Автономные или растянутые кластеры Ceph могут быть настроены с использованием двух различных сетей:

Public network: используется для обмена данными между всеми клиентами и службами Ceph, включая мониторы, OSD (Object Storage Daemon), RGW (Rados Gateway) и другие;
Cluster network: Если настроена (т.к. она опциональна), кластерная сеть также известная как сеть репликации, также известная как сеть обмена трафиком, также известная как приватная сеть используется только между OSD для хартбитов, восстановления и репликации. Таким образом, ее необходимо настраивать только в локациях, где расположены OSD. Говоря точнее, эта дополнительная сеть репликации и по умолчанию она не обязана быть маршрутизируемой.

Параметры Public и Cluster network

— Общая Public network должна быть доступна на всех трех локациях, включая расположение tie-breaker — поскольку все службы Ceph полагаются на нее.

— Кластерная сеть необходима только между двумя локациями, на которых размещаются OSD, и ее не следует настраивать в локации tie-breaker.

Надежность сети

Нестабильное соединение между OSD приводит к проблемам в кластере, связанным с доступностью и производительностью:

сеть должна быть не только доступна в течение 100% времени, но и обеспечивать стабильную задержку (низкий jitter);
частые всплески задержки могут привести к нестабильности кластеров — это вызовет проблемы с производительностью клиентов, включая нестабильное поведение OSD, потерю кворума мониторов и SLOW_OPS.

Требования к задержке

— Между локациями, на которых расположены OSD, допустимое время RTT (Round-Trip Time) составляет 10 мс.

— Допустимо до 100 мс RTT для локации с tie-breaker монитором, который может быть развернут в виртуальной машине или у облачного провайдера, если позволяют политики безопасности.

Если узел tie-breaker находится в облаке или удаленной сети через WAN, рекомендуется:

настроить связь между локациями и узлом tie-breaker для Public network;
включить шифрование при передаче с помощью Ceph шифрования в messenger v2, который обеспечивает связь между мониторами и другими компонентами Ceph.

Влияние задержки на производительность

— Каждая операция записи в Ceph обеспечивает строгую согласованность. Записанные данные должны быть сохранены на всех OSD соответствующей PG (Placement Group) до того, как клиент получит подтверждение об успешной записи.

— Это добавляет, как минимум, сетевое время RTT между локациями к задержке каждой клиентской операции записи. Обратите внимание, что эти операции записи репликации (подоперации) из primary OSD в secondary OSD выполняются параллельно.

* Например, если время ожидания между сайтами составляет 6 мс, каждая операция записи будет иметь дополнительную задержку — не менее 6 мс из-за репликации между сайтами.

Аспекты пропускной способности и восстановления

— Пропускная способность между локациями ограничивает:

максимальную пропускную способность клиента;
скорость восстановления при сбое OSD, сервера или локации или их последующем восстановлении доступности.

— В случае отказа узла 67% трафика для восстановления будет удаленным. Это означает, что он будет читать две трети данных с OSD из другой локации, потребляя общую пропускную способность площадок наряду с клиентским вводом-выводом.

— Ceph определяет primary OSD для каждой PG. Все записи клиента проходят через primary OSD, которое может находиться в дата-центре, отличном от клиента, или экземпляра RGW.

Оптимизация операций чтения с read_from_local_replica

— Все операции чтения по умолчанию проходят через primary OSD, что может увеличить задержку между локациями.

— Функция read_from_local_replica позволяет клиентам RGW и RBD (Ceph Block Device) считывать данные с реплики на одной и той же локации вместо того, чтобы всегда считывать данные с primary OSD, который с вероятностью 50% может находиться на другом сайте.

— Это сводит к минимуму задержку между локациями и снижает использование пропускной способности при больших нагрузках на чтение.

— Начиная с Squid, доступно как для блочного (RBD), так и для объектного (RGW) хранилища. Локальное чтение еще не реализовано для клиентов CephFS.

Требование к оборудованию

Требования к оборудованию и рекомендации для растянутых кластеров идентичны традиционным требованиям развертывания, за некоторыми исключениями, рассмотрим их ниже:

в растянутых кластерах Ceph следует использовать All-flash (SSD) конфигурации, а HDD — не рекомендуется. Вы предупреждены;
Ceph в растянутом режиме требует репликации с параметром size=4, в соответствии с политикой репликации данных. Erasure Coding или репликация с меньшим количеством копий не поддерживаются. Планируйте соответствующим образом сырую и доступную емкости, которые необходимо предоставить;
кластеры с несколькими классами устройств не поддерживаются. Также не будет работать CRUSH-правило с type replicated class hdd. Если это правило определяет класс устройства (SSD или NVMe), то все правила CRUSH должны указывать этот класс устройства;
только локальные не растянутые пулы не поддерживаются. То есть, ни на одной локации не может быть пула, который не имел бы данных в другой локации.

Размещение компонентов

Службы Ceph, включая мониторы, OSD и RGW, должны размещаться так, чтобы исключить единые точки отказа и гарантировать, что кластер сможет выдержать потерю локации целиком, без ущерба для доступа клиентов к данным.

Мониторы (Mon): требуется как минимум пяти мониторов: по два в каждой локации с данными и один для tie-breaker. Эта стратегия поддерживает кворум, обеспечивая доступность более 50% мониторов, даже в случае отключения всей площадки.

Менеджер (Mgr): мы можем настроить по два или четыре Менеджера в каждой локации с данными. Рекомендуется использовать четыре, чтобы обеспечить высокую доступность с помощью пары “active/passive” на уцелевшей локации в случае отказа локации с данными.

OSD: равномерно распределены по всем локациям. При настройке растянутого режима необходимо создать CRUSH-правила, разместив по две копии на каждом сайте — всего четыре.
RGW: рекомендуется использовать как минимум четыре экземпляра RGW, по два на локацию, для высокой доступности хранилища объектов с оставшейся локации в случае сбоя.

MDS: минимальное рекомендуемое количество экземпляров сервера метаданных CephFS — четыре, по два на локацию. В случае сбоя у нас все равно будут две службы MDS на оставшейся площадке: одна будет активной, а вторая — резервной.

NFS: рекомендуется использовать как минимум четыре экземпляра сервера NFS — по два на площадку, для обеспечения высокой доступности общей файловой системы при отключении.

Практика: развертывание в растянутом режиме для двух дата-центров

Для обработки большей части конфигурации кластера за один шаг, в начале загрузки кластера с помощью cephadm мы можем использовать YAML-файл.

Приведенный ниже файл stretched.yaml содержит пример шаблона для развертывания кластера Ceph, настроенного в растянутом режиме. Это всего лишь пример — его необходимо сконфигурировать в соответствии с вашими потребностями.

Развернуть код

service_type: host
addr: ceph-node-00.cephlab.com
hostname: ceph-node-00
labels:
  - mon
  - osd
  - rgw
  - mds
location:
  root: default
  datacenter: DC1
---

service_type: host
addr: ceph-node-01.cephlab.com
hostname: ceph-node-01
labels:
  - mon
  - mgr
  - osd
  - mds
location:
  root: default
  datacenter: DC1
---

service_type: host
addr: ceph-node-02.cephlab.com
hostname: ceph-node-02
labels:
  - osd
  - rgw
location:
  root: default
  datacenter: DC1
---

service_type: host
addr: ceph-node-03.cephlab.com
hostname: ceph-node-03
labels:
  - mon
  - osd
location:
  root: default
  datacenter: DC2
---

service_type: host
addr: ceph-node-04.cephlab.com
hostname: ceph-node-04
labels:
  - mon
  - mgr
  - osd
  - mds
location:
  root: default
  datacenter: DC2
---

service_type: host
addr: ceph-node-05.cephlab.com
hostname: ceph-node-05
labels:
  - osd
  - rgw
  - mds
location:
  root: default
  datacenter: DC2
---

service_type: host
addr: ceph-node-06.cephlab.com
hostname: ceph-node-06
labels:
  - mon
---
service_type: mon
service_name: mon
placement:
  label: mon
spec:
  crush_locations:
    ceph-node-00:
    - datacenter=DC1
    ceph-node-01:
    - datacenter=DC1
    ceph-node-03:
    - datacenter=DC2
    ceph-node-04:
    - datacenter=DC2
    ceph-node-06:
    - datacenter=DC3

---
service_type: mgr
service_name: mgr
placement:
  label: mgr
---

service_type: mds
service_id: cephfs
placement:
  label: "mds"

---
service_type: osd
service_id: all-available-devices
service_name: osd.all-available-devices
spec:
  data_devices:
    all: true
placement:
  label: "osd"

Запустите команду cephadm bootstrap, используя файл спецификации, настроенный для вашего развертывания. Обратите внимание, что мы передаем файл спецификации YAML с расширением --apply-spec stretched.yml — так все службы будут развернуты и сконфигурированы за один шаг.

# cephadm bootstrap --registry-json login.json --dashboard-password-noupdate --mon-ip 192.168.122.12 --apply-spec stretched.yml --allow-fqdn-hostname

После завершения убедитесь, что кластер распознает все хосты и их соответствующие метки:

# ceph orch host ls
HOST          ADDR             LABELS                  STATUS
ceph-node-00  192.168.122.12   _admin,mon,osd,rgw,mds
ceph-node-01  192.168.122.179  mon,mgr,osd
ceph-node-02  192.168.122.94   osd,rgw,mds
ceph-node-03  192.168.122.180  mon,osd,mds
ceph-node-04  192.168.122.138  mon,mgr,osd
ceph-node-05  192.168.122.175  osd,rgw,mds
ceph-node-06  192.168.122.214  mon

Добавьте метку _admin как минимум к одному узлу в каждом дата-центре — запустите команды Ceph CLI. Таким образом, даже если вы потеряете всю локацию, то сможете выполнять команды администратора Ceph с уцелевшего хоста. Нередко всем узлам кластера присваивается метка _admin.

# ceph orch host label add ceph-node-03 _admin
Added label _admin to host ceph-node-03
# ceph orch host label add ceph-node-06 _admin
Added label _admin to host ceph-node-06
# ssh ceph-node-03 ls /etc/ceph
ceph.client.admin.keyring
ceph.conf

Практика: Как Ceph записывает две копии данных в локации?

Настроенный растянутый Ceph требует использования всеми пулами стратегии защиты данных репликации с параметром size=4. Это означает, что в каждой локации должно быть две копии данных, чтобы обеспечивать доступность в случае отключения всего дата-центра.

Ceph использует CRUSH-карту для определения места размещения реплик данных. Эта карта отображает расположение физического оборудования, организованного в иерархию типов бакетов. Они включают дата-центры, помещения и, чаще всего, стойки и хосты. Чтобы настроить CRUSH-карту в растянутом режиме, мы определяем два дата-центра в CRUSH root по умолчанию, а затем помещаем бакеты хоста внутри соответствующего сегмента CRUSH дата-центра.

Ниже показан пример CRUSH-карты в растянутом режиме: два дата-центра (DC1 и DC2), в каждом — по три хоста Ceph OSD.

Мы получаем эту топологию прямо из коробки, благодаря файлу спецификации, который мы использовали во время начальной загрузки, где мы указываем местоположение каждого хоста на CRUSH-карте.

Развернуть код

# 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              up   1.00000  1.00000
 1    hdd  0.04880              osd.1              up   1.00000  1.00000
-4         0.09760          host ceph-node-01
 3    hdd  0.04880              osd.3              up   1.00000  1.00000
 7    hdd  0.04880              osd.7              up   1.00000  1.00000
-5         0.09760          host ceph-node-02
 2    hdd  0.04880              osd.2              up   1.00000  1.00000
 5    hdd  0.04880              osd.5              up   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.00000

Здесь у нас два дата-центра: DC1 and DC2. В третьем, DC3, находится монитор tie-breaker на ceph-node-06, но нет OSD.

Чтобы достичь нашей цели — сделать по две копии на локацию, мы определяем растянутое CRUSH-правило для назначения наших RADOS-пулов Ceph.

Установите ceph-base, чтобы получить двоичный crushtool, который показан здесь в системе RHEL:

# dnf -y install ceph-base

Экспортируйте CRUSH-карту в двоичный файл:

# ceph osd getcrushmap > crush.map.bin

Декомпилируйте CRUSH-карту в текстовый файл:

# crushtool -d crush.map.bin -o crush.map.txt

Отредактируйте файл crush.map.txt, чтобы добавить новое правило в конец файла, также проследите, что числовой атрибут id правила — уникальный:

rule stretch_rule {
        id 1
        type replicated
        step take default
        step choose firstn 0 type datacenter
        step chooseleaf firstn 2 type host
        step emit
}

Внедрите расширенную CRUSH-карту, чтобы сделать правило доступным для кластера:

# crushtool -c crush.map.txt -o crush2.map.bin
# ceph osd setcrushmap -i crush2.map.bin

Проверьте, что новое правило доступно:

# ceph osd crush rule ls
replicated_rule
stretch_rule

Практика: настройка мониторов для работы в растянутом режиме

Благодаря файлу спецификации Bootstrap мониторы помечены в соответствии с дата-центром, которому они принадлежат. Такая маркировка гарантирует, что Ceph сможет поддерживать кворум, даже если в одном из ЦОД произойдет сбой. В таких случаях монитор tie-breaker в DC 3 действует совместно с мониторами на сохранившейся локации, чтобы поддерживать кворум мониторов кластера.

# ceph mon dump | grep location
0: [v2:192.168.122.12:3300/0,v1:192.168.122.12:6789/0] mon.ceph-node-00; crush_location {datacenter=DC1}
1: [v2:192.168.122.214:3300/0,v1:192.168.122.214:6789/0] mon.ceph-node-06; crush_location {datacenter=DC3}
2: [v2:192.168.122.138:3300/0,v1:192.168.122.138:6789/0] mon.ceph-node-04; crush_location {datacenter=DC2}
3: [v2:192.168.122.180:3300/0,v1:192.168.122.180:6789/0] mon.ceph-node-03; crush_location {datacenter=DC2}
4: [v2:192.168.122.179:3300/0,v1:192.168.122.179:6789/0] mon.ceph-node-01; crush_location {datacenter=DC1}

При запуске растянутого кластера с тремя локациями асимметричная сетевая ошибка влияет только на связь между первой и второй площадкой. Это может привести к неразрешимой ситуации шторма сообщений при выбора монитора, когда ни один из них не может быть выбран в качестве лидера.

Чтобы избежать эту проблемы, мы изменим нашу стратегию выбора с классического подхода на connectivity-based. Режим связи оценивает показатели подключения, которые каждый монитор предоставляет соседним узлам, и выбирает монитор с наивысшей оценкой. Эта модель специально разработана для управления сетевым разделением, также известным как netsplit. Сетевое разделение может возникнуть, когда ваш кластер распределен по нескольким дата-центрам, и все связи, соединяющие одну локацию с другой, потеряны.

# ceph mon dump | grep  election
election_strategy: 1
# ceph mon set election_strategy connectivity
# ceph mon dump | grep  election
election_strategy: 3

Вы можете проверить результаты мониторинга с помощью следующей команды:

# ceph daemon mon.{name} connection scores dump

Чтобы узнать больше о стратегии выбора монитора на основе оценки подключения, посмотрите отличное видео Грега Фарнума. Дополнительная информация также доступна здесь.

Практика: включение режима растянутого Ceph

Чтобы включить растянутый режим, следуйте следующим командам:

# ceph mon enable_stretch_mode ceph-node-06 stretch_rule datacenter

Где:

ceph-node-06 — это tie-breaker-монитор в DC3;
stretch_rule — это CRUSH-правило, которое устанавливает две копии в каждом дата-центре;
дата-центр — это наш домен отказов.

Проверьте обновленную MON-конфигурацию:

# ceph mon dump
epoch 20
fsid 90441880-e868-11ef-b468-52540016bbfa
last_changed 2025-02-11T14:44:10.163933+0000
created 2025-02-11T11:08:51.178952+0000
min_mon_release 19 (squid)
election_strategy: 3
stretch_mode_enabled 1
tiebreaker_mon ceph-node-06
disallowed_leaders ceph-node-06
0: [v2:192.168.122.12:3300/0,v1:192.168.122.12:6789/0] mon.ceph-node-00; crush_location {datacenter=DC1}
1: [v2:192.168.122.214:3300/0,v1:192.168.122.214:6789/0] mon.ceph-node-06; crush_location {datacenter=DC3}
2: [v2:192.168.122.138:3300/0,v1:192.168.122.138:6789/0] mon.ceph-node-04; crush_location {datacenter=DC2}
3: [v2:192.168.122.180:3300/0,v1:192.168.122.180:6789/0] mon.ceph-node-03; crush_location {datacenter=DC2}
4: [v2:192.168.122.179:3300/0,v1:192.168.122.179:6789/0] mon.ceph-node-01; crush_location {datacenter=DC1}

Ceph специально запрещает монитору tie-breaker когда-либо брать на себя роль лидера. Единственная цель tie-breaker — обеспечить дополнительное голосование для поддержания кворума в случае сбоя на одной из основных локаций, предотвращая тем самым split-brain-сценарии. По замыслу, он располагается в отдельной, часто меньшей среде (возможно, в облачной виртуальной машине), и обладает более высокой задержкой и меньшими ресурсами. Если позволить стать ему лидером, производительность и согласованность могут нарушиться. Поэтому Ceph помечает монитор tie-breaker как disallowed\leader, гарантируя, что контроль над кластером сохранится на стороне основных локаций, а голос tie-breaker будет использован для достижения кворума.

Практика: проверка репликации и размещения пула при включенном растянутом режиме

Если включен расширенный режим, Object Storage Daemons (OSD) активируют PG только при условии, что они соединены с пирами в дата-центрах, и оба доступны. Применяются следующие ограничения:

количество реплик (атрибут размера пула size) увеличится с 3 по умолчанию до 4, при этом ожидается, что в каждой локации будет по две копии;
OSD могут подключаться только к мониторам в пределах одного дата-центра;
новые мониторы не могут присоединиться к кластеру, если не указано их местоположение.

# ceph osd pool ls detail
pool 1 '.mgr' replicated size 4 min_size 2 crush_rule 1 object_hash rjenkins pg_num 1 pgp_num 1 autoscale_mode on last_change 199 lfor 199/199/199 flags hashpspool stripe_width 0 pg_num_max 32 pg_num_min 1 application mgr read_balance_score 12.12
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

Проверьте PG на наличие определенного ID пула и подтвердите, какие OSD входят в действующий набор:

# ceph pg dump pgs_brief | grep 2.c
dumped pgs_brief
2.c      active+clean   [2,3,6,9]           2   [2,3,6,9]               2

В этом примере PG 2.c содержит OSD 2 и 3 из DC1, а также OSD 6 и 9 из DC2. Вы можете подтвердить расположение этих OSD с помощью команды ceph osd tree:

# ceph osd tree | grep -Ev '(osd.1|osd.7|osd.5|osd.4|osd.0|osd.8)'
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
-4         0.09760          host ceph-node-01
 3    hdd  0.04880              osd.3              up   1.00000  1.00000
-5         0.09760          host ceph-node-02
 2    hdd  0.04880              osd.2              up   1.00000  1.00000
-7         0.29279      datacenter DC2
-6         0.09760          host ceph-node-03
 6    hdd  0.04880              osd.6              up   1.00000  1.00000
-8         0.09760          host ceph-node-04
-9         0.09760          host ceph-node-05
 9    hdd  0.04880              osd.9              up   1.00000  1.00000

Здесь каждая PG обладает двумя копиями в DC1 и двумя в DC2, что и является основной целью растянутого режима.

Выводы

При развертывании растянутого кластера в двух локациях с монитором tie-breaker на третьей, вы обеспечиваете высокую доступность данных даже при отключении дата-центра. Использование единого файла спецификации позволяет автоматически и последовательно размещать сервисы на обеих площадках — включая мониторы, OSD и другие компоненты Ceph. Стратегия выборов по подключению помогает поддерживать стабильный кворум, отдавая приоритет надежно подключенным мониторам. Сочетание этих элементов: тщательной CRUSH-конфигурации, правильной маркировки и соответствующей стратегии защиты данных — создает устойчивую архитектуру хранилища, которая справляется со сбоями без ущерба для целостности данных или непрерывности обслуживания.

В заключительной части нашей серии мы протестируем растянутый кластер в реальных условиях сбоев. Мы рассмотрим, как Ceph автоматически переходит в нерабочее состояние при отключении всей локации, как это влияет на ввод-вывод во время сбоя, а также процесс восстановления после перезапуска, гарантирующий невозможность потери данных.

Авторы хотели бы поблагодарить компанию IBM за поддержку сообщества и уделенное время для создания этих статей.

Комментарии (1)

outlingo
10.07.2025 10:11
#28553092
Ммм... Растянутый ceph. Но зачем?