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

Вступление

В первой части мы представили концепции, лежащие в основе стратегий репликации 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 за поддержку сообщества и уделенное время для создания этих статей.