centos7, ceph, hdd

ceph установка кластера

Thank you for reading this post, don't forget to subscribe!

Коротко о демонах

OSD (object storage daemon) — в каж­дой ноде кла­сте­ра может быть несколь­ко дис­ков и на каж­дый диск нужен отдель­ный демон OSD.

Демо­ны Ceph OSD сохра­ня­ют дан­ные в виде объ­ек­тов в плос­ком про­стран­стве имён, то есть без иерар­хии в виде ката­ло­гов. Объ­ек­ты обла­да­ют иден­ти­фи­ка­то­ра­ми, бинар­ны­ми дан­ны­ми и мета­дан­ны­ми в виде ключ-зна­че­ние, кото­рые исполь­зу­ет MDS сохра­няя вла­дель­ца фай­ла, вре­мя созда­ния, вре­мя моди­фи­ка­ции и так далее. Иден­ти­фи­ка­тор объ­ек­та уни­ка­лен в пре­де­лах кластера.

Демон OSD в соста­ве кла­сте­ра посто­ян­но сооб­ща­ет о сво­ём ста­ту­се - up или down. Если по ряду при­чин OSD демон не сооб­ща­ет о сво­ём состо­я­нии, демон мони­то­ра пери­о­ди­че­ски сам про­ве­ря­ет ста­тус OSD демо­нов и упол­но­мо­чен обнов­лять кла­стер­ную кар­ту и уве­дом­лять дру­гих демо­нов мони­то­ров о состо­я­нии OSDдемо­нов.

Metadata server (MDS) — вспо­мо­га­тель­ный демон для обес­пе­че­ния син­хрон­но­го состо­я­ния фай­лов в точ­ках мон­ти­ро­ва­ния CephFS. В один момент вре­ме­ни рабо­та­ет толь­ко один MDS в пре­де­лах кла­сте­ра, а дру­гие нахо­дят­ся в режи­ме ожи­да­ния и кто-то ста­нет актив­ным, если теку­щий MDS упадёт.

Мони­то­ры Ceph (Ceph Monitors) под­дер­жи­ва­ют глав­ную копию (master copy) кла­стер­ной кар­ты (cluster map), по кото­рой кли­ен­ты Ceph могут опре­де­лить рас­по­ло­же­ние всех мони­то­ров, OSD демо­нов и сер­ве­ров Metadata (MDS). До того как кли­ен­ты нач­нут что-либо писать или читать у OSD или MDS, они долж­ны впервую оче­редь свя­зать­ся с мони­то­ром Ceph.

С теку­щей кла­стер­ной кар­той и алго­рит­мом CRUSH, кли­ен­ты могут вычис­лить рас­по­ло­же­ние любо­го объ­ек­та. Эта спо­соб­ность поз­во­ля­ет кли­ен­там напря­мую общать­ся с OSD, что явля­ет­ся важ­ным аспек­том в архи­тек­ту­ре Ceph и его спо­соб­но­сти к высо­кой доступ­но­сти и производительности.

Глав­ная зада­ча мони­то­ров - под­дер­жи­вать глав­ную копию кла­стер­ной кар­ты. Поми­мо это­го мони­то­ры зани­ма­ют­ся аутен­ти­фи­ка­ци­ей и журналированием.

Кла­стер­ная кар­та - это ком­плекс­ная кар­та. Она состо­ит из кар­ты мони­то­ров (monitor map), кар­ты OSD (OSD map), кар­ты плей­смент-груп­пы (placement group map) и кар­ты MDS (metadata server map).

При­сту­пим.
Выпол­ня­ем уста­нов­ку ОС на сер­ве­ра и базо­вую настрой­ку сети, так­же отклю­ча­ем IPv6 и SElinux.

Уста­нов­ку систе­мы про­из­во­дим на один диск, загруз­чик ста­вим туда же, ника­ких RAID не соби­ра­ем (тоже самое каса­ет­ся аппа­рат­но­го RAID - толь­ко RAID 0 (JBOD)).

  • Ceph-node-admin [192.168.2.67]
  • Ceph-node-mon [192.168.2.68]
  • Ceph-node-00 [192.168.2.69]
  • Ceph-node-01 [192.168.2.70]
  • Ceph-node-02 [192.168.2.71]

Для удоб­ства будем рабо­тать по кано­ни­че­ским име­нам, если нет сво­е­го лич­но­го DNS-сер­ве­ра, то не забы­ва­ем вне­сти соот­вет­ству­ю­щие настрой­ки в файл /etc/hostsна каж­дом сервере.

Настройка NTP

Выпол­ня­ем настрой­ку NTP сер­ве­ра на каж­дой ноде.
Это очень важ­ный шаг, посколь­ку боль­шин­ство про­блем может воз­ник­нуть имен­но из-за некор­рект­ной настрой­ки времени.

Установим NTP

Вно­сим изме­не­ния в кон­фи­гу­ра­ци­он­ный файл /etc/ntp.conf.

Выпол­ним настрой­ку вре­мен­ной зоны, если это не было сде­ла­но при уста­нов­ке системы.

Создаем нового пользователя

Посколь­ку дан­ный пункт я выпол­нил на ста­дии уста­нов­ки, то я сра­зу перей­ду к сле­ду­ю­ще­му шагу.

Изме­ним файл /etc/sudoers на каж­дом сер­ве­ре и доба­вим в него сле­ду­ю­щую строч­ку, что поз­во­лит выпол­нять sudo коман­ды без запро­са паро­ля. Либо созда­дим в пап­ке /etc/sudoers.d/ файл с име­нем поль­зо­ва­те­ля, в кото­рый доба­вим тоже самое.

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

Теперь ско­пи­ру­ем его на все исполь­зу­е­мые сервера.

Напри­мер:

Настройка ядра системы

При нали­чии боль­шо­го коли­че­ства OSD, воз­мож­но созда­ние огром­но­го коли­че­ства тре­дов (threads), осо­бен­но в про­цес­се вос­ста­нов­ле­ния или же при повтор­ной балан­си­ров­ке. Изме­ним в Linux зна­че­ние по умол­ча­нию на необ­хо­ди­мое нам.

kernel.pid_max слу­жит для под­держ­ки боль­ше­го зна­че­ния тре­дов (threads). В тео­рии, мак­си­мум это - 4,194,303.

Вне­сем изме­не­ния в файл /etc/sysctl.conf, доба­вив строчку:

При­ме­ня­ем пара­мет­ры “на лету”:

Настроим правила на файрволле

Для Firewalld

Для Iptables

Так­же уста­но­вим пакет yum-plugin-priorities, что­бы мене­джер паке­тов уста­нав­ли­вал пред­по­чти­тель­ные пакеты.

Установка Ceph Storage Cluster с помощью ceph-deploy

Нач­нем пожа­луй с про­сто­го. Сде­ла­ем кла­стер с дву­мя OSD демо­на­ми и одним мони­то­ром. После дости­же­ния ста­ту­са active+clean доба­вим тре­тий OSD демон в уже рабо­та­ю­щий кла­стер, а так­же резерв­ный MDS и несколь­ко мониторов.

Выполним установку ceph-deploy

Уста­но­вим необ­хо­ди­мые паке­ты и репозитории:

Под­клю­чим репо­зи­то­рий Ceph /etc/yum.repos.d/ceph.repo:

Заме­ним {distro} на наш дис­три­бу­тив, в дан­ном слу­чае el7.
Заме­ним {ceph-release} на ста­биль­ную вер­сию Ceph.
На момент напи­са­ния ста­тьи это mimic.

После всех этих дей­ствий уста­но­вим пакет ceph-deploy:

Созда­дим рабо­чую дирек­то­рию на адми­ни­стра­тив­ной ноде для гене­ра­ции кон­фи­гу­ра­ци­он­ных фай­лов и клю­чей, даль­ней­шие дей­ствия необ­хо­ди­мо выпол­нять нахо­дясь в ней.

 

Очень важ­но!
Не выпол­няй­те коман­ду ceph-deploy с sudo или же от root, если авто­ри­зо­ва­ны под дру­гим пользователем.

На неко­то­рых дис­три­бу­ти­вах, в част­но­сти CentOS, при выпол­не­нии коман­ды ceph-deploy воз­мож­ны ошиб­ки, для это­го изме­ни­те пара­метр Defaults requiretty с помо­щью sudo visudo в /etc/sudoers.d/ceph на Defaults:ceph !requiretty для того, что­бы ceph-deploy мог под­клю­чать­ся с помо­щью поль­зо­ва­те­ля ceph и выпол­нять коман­ды с sudo.

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

Для уда­ле­ния пакетов:

Если выпол­ня­лась коман­да purge, то необ­хо­ди­мо пере­уста­но­вить паке­ты Ceph.

Создаем кластер Ceph Storage Cluster

С админ­ской ноды из дирек­то­рии, кото­рую мы созда­ли для хра­не­ния кон­фи­гу­ра­ци­он­ных фай­лов, выпол­ня­ем коман­ду для созда­ния кластера:

Напри­мер:

После это­го в пап­ке появит­ся кон­фи­гу­ра­ци­он­ный файл и ключ мони­то­ра. Убе­ди­тесь в этом.
По умол­ча­нию имя кла­сте­ра будет ceph. Если вы хоти­те на одном и том же обо­ру­до­ва­нии исполь­зо­вать несколь­ко кла­сте­ров, то для каж­до­го из них нуж­но зада­вать имя, исполь­зуя ceph-deploy –cluster {cluster-name} new …

Изме­ним зна­че­ние по умол­ча­нию для коли­че­ства реплик в Ceph. По умол­ча­нию зна­че­ние рав­но 3, изме­ним его на 2, что­бы Ceph мог достичь ста­ту­са Active+Clean с помо­щью двух OSD. Доба­вим сле­ду­ю­щую стро­ку в дирек­ти­ву [global] фай­ла ceph.conf.

Зада­дим зна­че­ния для плей­смент групп (Placement Groups) и плей­смент групп для раз­ме­ще­ния (Placement Groups for Placement) в дирек­ти­ве [global]. Для неболь­ших кла­сте­ров (менее 5 OSDs) реко­мен­ду­ет­ся 128 плей­смент группы.
  • менее 5 OSD - зна­че­ние pg_num и pgp_num ста­вим 128;
  • от 5 до 10 OSD - зна­че­ние pg_num и pgp_num ста­вим 512;
  • от 10 до 50 OSD - зна­че­ние pg_num и pgp_num ста­вим 4096;
  • от 50 OSD и выше пара­мет­ры pg_num и pgp_num рас­счи­ты­ва­ем по сле­ду­ю­щей формуле:

osd_pool_default_size зна­че­ние, кото­рое мы уста­нав­ли­ва­ли на преды­ду­щем шаге.

Уста­но­вим мак­си­маль­ное коли­че­ство плей­смент груп на OSD. По умол­ча­нию это зна­че­ние рав­но 300. Несколь­ко пулов могут исполь­зо­вать один и тот же набор пра­вил CRUSH. Когда OSD име­ют слиш­ком мно­го плей­смент групп это может ска­зать­ся на производительности.

Уста­нов­ка типа CRUSH для отка­зо­устой­чи­во­сти. По умол­ча­нию это зна­че­ние рав­но 1. Если мы хотим сде­лать как мини­мум для 3-х объ­ек­тов репли­ки, то необ­хо­ди­мо изме­нить пара­метр на 3.
  • Тип 0 - osd
  • Тип 1 - host
  • Тип 2 - chassis
  • Тип 3 - rack
  • Тип 4 - row
  • Тип 5 - pdu
  • Тип 6 - pod
  • Тип 7 - room
  • Тип 8 - datacenter
  • Тип 9 - region
  • Тип 10 - root

Уста­но­вим max_open_files для того что­бы задать мак­си­маль­ное зна­че­ние откры­тых дескрип­то­ров фай­лов на уровне ОС:

XATTR пара­мет­ры исполь­зу­ют­ся с фай­ло­вой систе­мой ext4 для улуч­ше­ния производительности.

Как уже и гово­ри­лось в нача­ле ста­тьи, реко­мен­ду­ет­ся пра­виль­ная настрой­ка вре­ме­ни на сервере.

Уста­но­вим full_ratio и near_full_ratio на при­ем­ле­мые зна­че­ния. Пол­ную мощ­ность на 95% и почти запол­нен­ную на 85%.

При­мер ceph.conf

Если на сер­ве­ре име­ет­ся и исполь­зу­ет­ся боль­ше одно­го сете­во­го интер­фей­са, то доба­вим public_network в сек­цию [global] кон­фи­гу­ра­ци­он­но­го фай­ла Ceph. ( Подроб­нее о сете­вой кон­фи­гу­ра­ции )

Уста­но­вим Ceph:

Напри­мер:

В про­цес­се уста­нов­ки может появить­ся сле­ду­ю­щая ошибка:

Устра­ня­ем про­бле­му командой:

Настройка CRUSH карты с SSD кэшированием

В фай­ле кон­фи­гу­ра­ции ceph запре­ща­ем обнов­лять кар­ту автоматически:

Сохра­ним теку­щую кар­ту и пере­ве­дем её в тек­сто­вый формат:

Обра­ти­те вни­ма­ние на то, что я создал два root для SSD и HDD, а так­же два пра­ви­ла ruleset.

Ском­пи­ли­ру­ем обрат­но и запу­стим CRUSH-карту

Добавим первоначальные мониторы и соберем ключи

Для обес­пе­че­ния высо­кой доступ­но­сти необ­хо­ди­мо запу­стить Ceph как мини­мум с 3-мя мони­то­ра­ми. Ceph исполь­зу­ет алго­ритм, кото­рый тре­бу­ет кон­сен­су­са сре­ди боль­шин­ства мони­то­ров в кворуме.
Под­счет мони­то­ров осу­ществ­ля­ет­ся при­бли­зи­тель­но сле­ду­ю­щим обра­зом: 1:1, 2:3, 3:4, 3:5, 4:6, etc. Необя­за­тель­но, но жела­тель­но, что­бы коли­че­ство мони­то­ров в кла­сте­ре было нечёт­ным чис­лом для улуч­ше­ния рабо­ты алго­рит­ма Paxos при сохра­не­нии кворума.

В иде­а­ле, раз­ра­бот­чи­ки Ceph сове­ту­ют ноды-мони­то­ры не сов­ме­щать с нода­ми OSD, так как мони­то­ры актив­но исполь­зу­ют fsync() и это пагуб­но вли­я­ет на про­из­во­ди­тель­ность OSD.

После выпол­не­ния дан­но­го про­цес­са в локаль­ной дирек­то­рии ceph-adminпро­ве­рим нали­чие всех ключей:

Напри­мер:

Добавление OSD

Пер­во­на­чаль­ный вари­ант преду­смат­ри­ва­ет OSD в виде дирек­то­рий на дис­ке, я же буду исполь­зо­вать дис­ки полностью.

Добав­ле­ние и уда­ле­ние OSD демо­нов в кла­стер может зани­мать несколь­ко шагов, осо­бен­но если исполь­зу­ет­ся запись на диск и в журнал.

Для листин­га дис­ков ноды исполь­зу­ем сле­ду­ю­щую команду:

Напри­мер:
Затираем диски

Опре­де­лив­шись с дис­ка­ми зати­ра­ем все дан­ные на них (в т.ч. таб­ли­цу раз­де­лов) и под­го­то­вим для исполь­зо­ва­ния Ceph.

Напри­мер:

Подготовим диски

Раз­ра­бот­чи­ки Ceph реко­мен­ду­ют исполь­зо­вать фай­ло­вую систе­му XFS. ( см. Ceph Docs ), поэто­му поза­боть­тесь о том, что­бы пакет xfsprogs был уста­нов­лен на всех нодах кластера.

При под­го­тов­ке дис­ков ceph-deploy авто­ма­ти­че­ски фор­ма­ти­ру­ет дис­ки в XFS. Если уста­нов­ка про­из­во­дит­ся на раз­де­лы, то отфор­ма­ти­ро­вать его мож­но коман­дой sudo mkfs.xfs -i size=512 /dev/sdX.

После созда­ния кла­сте­ра и уста­нов­ки Ceph паке­тов, а так­же созда­ния клю­чей, можем выпол­нить под­го­тов­ку OSD и раз­вер­нуть их на OSD нодах. Коман­да prepareтоль­ко под­го­то­вит OSD!

Активация OSD

После успеш­ной под­го­тов­ки дис­ков акти­ви­ру­ем OSD. (Обра­ти­те вни­ма­ние, что необ­хо­ди­мо ука­зать раз­де­лы диска.)

Напри­мер:

 

Для того что­бы под­го­то­вить, раз­вер­нуть и акти­ви­ро­вать OSD мож­но вос­поль­зо­вать­ся одной коман­дой create:

Ско­пи­ру­ем клю­чи и кон­фи­гу­ра­ци­он­ный файл на ноды:

Напри­мер:

Убе­дим­ся в кор­рект­ных при­ви­ле­ги­ях ceph.client.admin.keyring:

Про­ве­ря­ем состояние:

Полу­ча­ем ста­тус Ceph:

При полу­че­нии пре­ду­пре­жде­ния, например:

Ищем реше­ние Ceph Troubleshooting.

Создание OSD с SSD кэшированием

К сожа­ле­нию OSD авто­ма­ти­че­ски в кон­фи­гу­ра­ци­он­ный файл не запи­шут­ся. Кро­ме того даже после запи­си в кон­фи­гу­ра­цию авто­ма­ти­че­ское мон­ти­ро­ва­ние этих точек тоже не работает.
Что­бы под­нять OSD демон при загруз­ке необ­хо­дим файл ключ, кото­рый лежит на не при­мон­ти­ро­ван­ном раз­де­ле. Поэто­му допол­ня­ем кон­фи­гу­ра­ци­он­ный файл ceph.conf:

Кро­ме это­го смот­рим на каж­дом узле где есть osd:

Добав­ля­ем запи­си в /etc/fstab для надежности:

Пере­за­пи­сы­ва­ем конфигурацию:

На теку­щем момен­те у нас есть кла­стер с един­ствен­ным и пока не настро­ен­ным пулом.

Полу­ча­ем:

RBD мож­но счи­тать неко­то­рым ана­ло­гом жест­ко­го дис­ка на кото­ром необ­хо­ди­мо будет наре­зать разделы.
Напри­мер для Opennebula потре­бу­ет­ся три пула: files, system и images.

Циф­ра в кон­це коман­ды - коли­че­ство PG и PGP для пула. Мож­но счи­тать, что PG это мини­маль­ный реп­ли­ци­ру­ю­щий­ся кусок про­стран­ства, в кото­рое мы можем запих­нуть обьект (файл) или кусок от него. PGP - мак­си­маль­ное коли­че­ство PG групп для пула.
По ману­а­лам есть фор­му­ла обще­го коли­че­ство PG (ука­за­но выше): ((коли­че­ство OSD)100)/(osd pool default size). То есть 3100/2 = 150. полу­чен­ное чис­ло ещё необ­хо­ди­мо округ­лить вверх до сте­пе­ни двой­ки - то есть у нас полу­ча­ет­ся 256. Делим это чис­ло на коли­че­ство пулов, округ­ля­ем вверх до сте­пе­ни 2 - полу­ча­ем иско­мую настрой­ку. 256/2 (system,rbd)=128.

Полу­ча­ем инфор­ма­цию о плей­смент группах:

Зада­ем зна­че­ния PG вручную:

Ceph нахо­дит­ся в зави­си­мо­сти от Ceph кли­ен­тов и Ceph OSD демо­нов, будучи осве­дом­лен­ных о кла­стер­ной топо­ло­гии, кото­рые вклю­ча­ют в себя 5 отдель­ных карт, кол­лек­тив­но назы­ва­е­мых как “Cluster Map”:

  1. Мони­тор: Содер­жит FSID кла­сте­ра, поло­же­ние, адре­са и порт каж­до­го мони­то­ра. Он так же ука­зы­ва­ет на теку­щую вер­сию сер­ве­ра мони­то­ра, когда кар­та была созда­на и когда в послед­ний раз изме­ня­лась. Что­бы про­смот­реть кар­ту мони­то­ра необ­хо­ди­мо выпол­нить коман­ду: ceph mon dump
  2. OSD: Содер­жит FSID кла­сте­ра, когда кар­та была созда­на и послед­ние изме­не­ния, спи­сок пулов, раз­мер репли­ка­ций, коли­че­ство PGs, спи­сок OSD и их теку­щее состо­я­ние. Для про­смот­ра OSD кар­ты необ­хо­ди­мо выпол­нить коман­ду: ceph osd dump
  3. PG: Содер­жит вер­сию PG, его мет­ки вре­ме­ни, послед­нию вер­сию OSD, пол­ные соот­но­ше­ния и подроб­ную инфор­ма­цию о каж­дой груп­пе раз­ме­ще­ния, такие как PG ID, состо­я­ние PG (напри­мер active+clean) и т.д. Для про­смот­ра PG кар­ты необ­хо­ди­мо выпол­нить коман­ду: ceph pg dump
  4. CRUSH: Содер­жит спи­сок устройств хра­не­ния, отка­зо­устой­чи­вую иерар­хию доме­на (device,host,rack,row,room,datacenter) и пра­ви­ла для иерар­хий при хра­не­ний дан­ных. Для про­смот­ра струк­ту­ры CRUSH алго­рит­ма необ­хо­ди­мо выпол­нить коман­ду: ceph osd tree
  5. MDS: Содер­жит теку­щую MDS вер­сию кар­ты, когда кар­та была созда­на и когда в послед­ний момент изме­ня­лась. Так же содер­жит­ся pool для хра­не­ния мета­дан­ных, спи­сок сер­ве­ров мета­дан­ных и какие сер­ве­ра вклю­че­ны и выклю­че­ны. Для про­смот­ра MDS кар­ты, необ­хо­ди­мо выпол­нить ceph mds dump

Терминология

Metadata server (MDS) — вспо­мо­га­тель­ный демон для обес­пе­че­ния син­хрон­но­го состо­я­ния фай­лов в точ­ках мон­ти­ро­ва­ния CephFS. Рабо­та­ет по схе­ме актив­ная копия + резер­вы, при­чем актив­ная копия в пре­де­лах кла­сте­ра толь­ко одна.

Mon (Monitor) — эле­мент инфра­струк­ту­ры Ceph, кото­рый обес­пе­чи­ва­ет адре­са­цию дан­ных внут­ри кла­сте­ра и хра­нит инфор­ма­цию о топо­ло­гии, состо­я­нии и рас­пре­де­ле­нии дан­ных внут­ри хра­ни­ли­ща. Кли­ент, жела­ю­щий обра­тить­ся к блоч­но­му устрой­ству rbd или к фай­лу на при­мон­ти­ро­ван­ной cephfs, полу­ча­ет от мони­то­ра имя и поло­же­ние rbd header — спе­ци­аль­но­го объ­ек­та, опи­сы­ва­ю­ще­го поло­же­ние про­чих объ­ек­тов, отно­ся­щих­ся к запро­шен­ной абстрак­ции (блоч­ное устрой­ство или файл) и далее обща­ет­ся со все­ми OSD, участ­ву­ю­щи­ми в хра­не­нии файла.

Объ­ект (Object) — блок дан­ных фик­си­ро­ван­но­го раз­ме­ра (по умол­ча­нию 4 Мб). Вся инфор­ма­ция, хра­ни­мая в Ceph, кван­ту­ет­ся таки­ми бло­ка­ми. Что­бы избе­жать пута­ни­цы под­черк­нем — это не поль­зо­ва­тель­ские объ­ек­ты из Object Storage, а объ­ек­ты, исполь­зу­е­мые для внут­рен­не­го пред­став­ле­ния дан­ных в Ceph.

OSD (object storage daemon) — сущ­ность, кото­рая отве­ча­ет за хра­не­ние дан­ных, основ­ной стро­и­тель­ный эле­мент кла­сте­ра Ceph. На одном физи­че­ском сер­ве­ре может раз­ме­щать­ся несколь­ко OSD, каж­дая из кото­рых име­ет под собой отдель­ное физи­че­ское хра­ни­ли­ще данных.

Кар­та OSD (OSD Map) — кар­та, ассо­ци­и­ру­ю­щая каж­дой плей­смент-груп­пе набор из одной Primary OSD и одной или несколь­ких Replica OSD. Рас­пре­де­ле­ние placement groups (PG) по нодам хра­ни­ли­ща OSD опи­сы­ва­ет­ся сре­зом кар­ты osdmap, в кото­рой ука­за­ны поло­же­ния всех PG и их реплик. Каж­дое изме­не­ние рас­по­ло­же­ния PG в кла­сте­ре сопро­вож­да­ет­ся выпус­ком новой кар­ты OSD, кото­рая рас­про­стра­ня­ет­ся сре­ди всех участников.

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

Primary OSD — OSD, выбран­ная в каче­стве Primary для дан­ной плей­смент-груп­пы. Кли­ент­ское IO все­гда обслу­жи­ва­ет­ся той OSD, кото­рая явля­ет­ся Primary для плей­смент груп­пы, в кото­рой нахо­дит­ся инте­ре­су­ю­щий кли­ен­та блок дан­ных (объ­ект). rimary OSD в асин­хрон­ном режи­ме реп­ли­ци­ру­ет все дан­ные на Replica OSD.

RADOS Gateway (RGW) — вспо­мо­га­тель­ный демон, испол­ня­ю­щий роль прок­си для под­дер­жи­ва­е­мых API объ­ект­ных хра­ни­лищ. Под­дер­жи­ва­ет гео­гра­фи­че­ски раз­не­сен­ные инстал­ля­ции (для раз­ных пулов, или, в пред­став­ле­нии Swift, реги­о­нов) и режим active-backup в пре­де­лах одно­го пула.

Replica OSD (Secondary) — OSD, кото­рая не явля­ет­ся Primary для дан­ной плей­смент-груп­пы и исполь­зу­ет­ся для репли­ка­ции. Кли­ент нико­гда не обща­ет­ся с ними напрямую.

Фак­тор репли­ка­ции (RF) — избы­точ­ность хра­не­ния дан­ных. Фак­тор репли­ка­ции явля­ет­ся целым чис­лом и пока­зы­ва­ет, сколь­ко копий одно­го и того же объ­ек­та хра­нит кластер.