Пгс для фундамента: Как сделать бетон из ПГС: виды, пропорции и рекомендации

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

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

Чтобы защитить фундамент от таких нагрузок при его проектировании следует использовать подушку и засыпку из ПГС.

Уменьшаем глубину промерзания

Устойчивость грунта к промерзанию напрямую зависит от количества влаги в его объеме. Поэтому важным условием снижения степени морозного пучения является защита от попадания воды из атмосферы, стоков и подземных источников. Особенно это актуально в местах, расположенных в низинах и близких к болотистой местности.

Выполняем подушку под фундамент из ПГС

Обустройство подушки под фундамент из ПГС позволяет исключить непосредственный контакт фундамента с влажным грунтом. На первоначальном этапе подушка из ПГС представляет собой своеобразный слоеный пирог, в котором слои гравия перемежаются слоями песка. В дальнейшем производится увлажнение и уплотнение подушки. Зачастую, при строительстве небольших домов в целях экономии строители выполняют подушку только из песка, что может отрицательно сказаться на её устойчивости к размыванию. Цены на ПГС в компании ОАО «Промстройкомплект» являются вполне демократичными и очень выгодными для строительства. Подушка из поставляемой нашей компанией ПГС будет прочна, а также радио и химически нейтральна.

Делаем засыпку фундамента

Чтобы уменьшить контакт фундамента с прилегающим к нему влажным грунтом, выполняют специальную засыпку из ПГС. Имея более плотную и тяжелую структуру и меньшую влажность, такая засыпка позволяет значительно снизить боковую нагрузку на фундамент, которая возникает при зимнем охлаждении почвы. Также благодаря применению засыпки из ПГС удается добиться плотности примыкания грунта к фундаменту, а, следовательно, его большей устойчивости, как конструкции.

Однако, следует знать, что к материалам для песчано-гравийной засыпки применяется целый ряд строгих требований, как по качеству, так и по составу и размеру. Компания ОАО «Промстройкомплект» реализует различные виды ПГС, применяемой для обустройства подушки и засыпки фундаментов любого типа. Чтобы заказать у нас интересующий материал достаточно набрать номер телефона нашей менеджерской службы +7(8422) 69-10-82, или написать нам на электронную почту [email protected]. Мы производим доставку смеси в количестве от 1 тонны.

групп размещения — Ceph Documentation

Автоматическое масштабирование групп размещения

Группы размещения (PG) — это внутренняя деталь реализации того, как Ceph распространяет данные. Вы можете разрешить кластеру либо рекомендации или автоматическая настройка PG в зависимости от того, как кластер используется для включения pg-autoscaling .

Каждый пул в системе имеет свойство pg_autoscale_mode , которое можно установить равным от , на или предупреждать .

• off : отключить автоматическое масштабирование для этого пула. Администратор должен выбрать соответствующий номер PG для каждого пула. Пожалуйста, обратитесь к разделу Выбор количества групп размещения для получения дополнительной информации.

• на : Включить автоматическую настройку количества PG для данного пула.

• warn : Поднимите оповещения о работоспособности, когда нужно изменить количество PG

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

 ceph osd pool set <имя-пула> pg_autoscale_mode <режим>
 

Например, чтобы включить автоматическое масштабирование в пуле foo ,:

 ceph osd набор для пула fg_autoscale_mode on
 

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

 ceph config set global osd_pool_default_pg_autoscale_mode 
 

Просмотр рекомендаций по масштабированию PG

Вы можете просмотреть каждый пул, его относительное использование и любые предлагаемые изменения в количество PG с этой командой:

 ceph osd pool, автоматический масштаб-статус
 

будет примерно таким:

 РАЗМЕР БАССЕЙНА РАЗМЕР ЦЕНЫ СВОЙСТВО RAW ЕМКОСТЬ СООТНОШЕНИЕ СООТНОШЕНИЕ ЭФФЕКТИВНОЕ СООТНОШЕНИЕ PG_NUM NEW PG_NUM AUTOSCALE
12900M 3.0 82431M 0,4695 8 128 предупреждений
c 0 3,0 82431M 0,0000 0,2000 0,9884 1 64 предупреждение
b 0 953,6M 3,0 82431M 0,0347 8 предупреждение
 

РАЗМЕР — это объем данных, хранящихся в пуле. РАЗМЕР ЦЕЛИ , если настоящее время — это количество данных, которое администратор указал, что они ожидают, что в конечном итоге будут храниться в этом пуле.Система использует большее из двух значений для его расчета.

RATE — множитель для пула, который определяет, сколько сырой емкость хранения потребляется. Например, пул из 3 реплик будет имеют отношение 3,0, в то время как a k = 4, m = 2 стираемый кодированный пул будет иметь соотношение 1,5.

RAW CAPACITY — это общий объем хранилища сырья на OSD, которые отвечают за хранение этого пула (и, возможно, других данные пулов. RATIO — это отношение общей емкости, которая этот пул потребляет (т.е.соотношение = размер * норма / сырая емкость).

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

ЭФФЕКТИВНОЕ СООТНОШЕНИЕ — это целевое соотношение после корректировки двумя способами:

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

2. нормализует целевые отношения среди пулов с целевым соотношением, установленным так они все вместе нацелены на остальное пространство.По примеру 4 у пулов с target_ratio 1.0 было бы эффективное отношение 0.25.

Система использует большее из фактического и эффективного коэффициента для его расчета.

PG_NUM — текущее количество PG для пула (или текущий количество PG, к которым работает пул, если pg_num изменения в процессе). NEW PG_NUM , если имеется Система считает, что пул pg_num следует изменить на.это всегда степень 2, и будет присутствовать, только если «идеальное» значение отличается от текущего значения более чем в 3 раза.

Последний столбец, AUTOSCALE , это пул pg_autoscale_mode , и будет на , на или на .

Автоматическое масштабирование

Разрешение кластеру автоматически масштабировать PG в зависимости от использования самый простой подход. Ceph будет смотреть на общее доступное хранилище и целевое количество PG для всей системы, посмотрите, сколько данных хранятся в каждом пуле, и попробуйте соответственно распределить PG. система относительно консервативна с ее подходом, только делая изменяется на пул, когда текущее количество PG ( pg_num ) больше чем в 3 раза от того, что он думает, что это должно быть.

Целевое количество PG на OSD основано на mon_target_pg_per_osd настраивается (по умолчанию: 100), который может быть скорректировано с помощью:

 ceph config set global mon_target_pg_per_osd 100
 

Autoscaler анализирует пулы и корректирует для каждого поддерева.Потому что каждый пул может сопоставляться с другим правилом CRUSH, и каждое правило может Ceph рассмотрит распределение данных между различными устройствами использование каждого поддерева иерархии независимо. Для Например, пул, который отображается на OSD класса SSD и пул, который отображается OSD класса HDD будет иметь оптимальное количество PG, которое зависит от количество этих соответствующих типов устройств.

Указание ожидаемого размера пула

При первом создании кластера или пула он будет доля общей емкости кластера и появится в системе как будто ему нужно только небольшое количество групп размещения.Тем не менее, в большинстве случаев администраторы кластеров имеют хорошую идею, которая Ожидается, что со временем пулы будут занимать большую часть емкости системы. Предоставляя эту информацию Ceph, более подходящее число PG можно использовать с самого начала, предотвращая последующие изменения в pg_num и накладные расходы, связанные с перемещением данных, когда эти корректировки сделаны.

Целевой размер пула можно указать двумя способами: либо в условия абсолютного размера пула (т.е.в байтах) или как вес относительно других пулов с набором target_size_ratio .

Например:

 ceph osd pool set mypool target_size_bytes 100T
 

сообщит системе, что mypool , как ожидается, потребит 100 ТиБ пространство. В качестве альтернативы:

 ceph osd pool set mypool target_size_ratio 1.0
 

сообщит системе, что mypool , как ожидается, будет потреблять 1,0 относительно в другие пулы с target_size_ratio .Если Mypool является единственный пул в кластере, это означает ожидаемое использование 100% общая вместимость. Если есть второй пул с target_size_ratio 1.0, оба пула будут использовать 50% емкости кластера.

Вы также можете установить целевой размер пула во время создания с помощью необязательных аргументов --target-size-bytes или --target-size-ratio для создания пула ceph osd. командование.

Обратите внимание, что при невозможности указываются значения целевого размера (например, емкость больше, чем общий кластер), то предупреждение о работоспособности ( POOL_TARGET_SIZE_BYTES_OVERCOMMITTED ) будет повышен.

Если указаны target_size_ratio и target_size_bytes для пула учитывается только соотношение и предупреждение о вреде для здоровья. ( POOL_HAS_TARGET_SIZE_BYTES_AND_RATIO ) будет выпущено.

Задание границ для PGs пула

Также возможно указать минимальное количество PG для пула. Это полезно для установления нижней границы количества Параллелизм клиент увидит при выполнении ввода-вывода, даже когда пул в основном опорожнить.Установка нижней границы предотвращает снижение Ceph (или Рекомендую уменьшить) номер PG ниже настроенного номера.

Вы можете установить минимальное количество PG для пула с:

 ceph osd pool set <имя-пула> pg_num_min <номер>
 

Вы также можете указать минимальное количество PG во время создания пула с помощью необязательный аргумент --pg-num-min для пула ceph osd создать команду .

Предварительный выбор pg_num

При создании нового пула с:

 ceph osd pool create {имя-пула} [pg_num]
 

необязательно выбирать значение pg_num .Если вы этого не сделаете укажите pg_num , кластер может (по умолчанию) автоматически настроить его для вас в зависимости от того, сколько данных хранится в пуле (см. выше, «Масштабирование групп размещения»).

В качестве альтернативы, pg_num может быть предоставлено явно. Тем не мение, указываете ли вы значение pg_num или нет, не влияет ли значение автоматически настраивается кластером после факта. к включить или отключить автонастройку:

 ceph osd pool set {имя-пула} pg_autoscale_mode (on | off | warn)
 

«Практическое правило» для PG на OSD традиционно составляет 100.С участием дополнительный балансировщик (который также включен по умолчанию), значение более 50 ПГ на OSD, вероятно, является разумным. Задача (которую обычно делает для вас автоскалер):

• имеют PG на пул, пропорциональный данным в пуле, и

• в конечном итоге с 50-100 PGs на OSD, после репликации или стирание-кодирование разветвления каждого PG через OSD принимается во рассмотрение

Как используются группы размещения?

Группа размещения (PG) объединяет объекты в пуле, потому что отслеживание размещения объекта и метаданных объекта для каждого объекта является вычислительно дорогой — я.система с миллионами объектов не может реально отслеживать размещение на основе объекта.

Клиент Ceph рассчитает, к какой группе размещения должен относиться объект быть в. Это делается путем хеширования идентификатора объекта и применения операции на основе количества PG в определенном пуле и идентификатора пула. См. Отображение PG в OSD для деталей.

Содержимое объекта в группе размещения хранится в наборе OSDS. Например, в реплицированном пуле размера два, каждое размещение group будет хранить объекты в двух OSD, как показано ниже.

В случае сбоя OSD # 2, другая группа будет назначена группе размещения № 1 и будут заполнены копиями всех объектов в OSD # 1. Если размер пула изменено с двух на три, дополнительное экранное меню будет назначено группа размещения и получит копии всех объектов в группа размещения.

Группы размещения не владеют экранным меню; они делятся этим с другими группы размещения из того же пула или даже из других пулов. Если OSD # 2 Сбой, группе размещения № 2 также придется восстанавливать копии объекты, используя OSD # 3.

Когда количество групп размещения увеличивается, новое место размещения группам будут назначены OSD. Результат функции CRUSH будет также изменится, и некоторые объекты из прежних групп размещения будут скопированы в новые группы мест размещения и удалены из старых.

Группы размещения Компромиссы

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

Надежность данных

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

• Отказ экранного меню и все копии объекта, который он содержит, будут потеряны. Для всех объектов в группе размещения номер реплики внезапно падает с трех до двух.

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

• Еще одно экранное меню в той же группе размещения выходит из строя перед новым Экранное меню полностью заполнено третьей копией. Некоторые объекты будут тогда есть только одна сохранившаяся копия.

• Ceph выбирает еще одно OSD и продолжает копировать объекты для восстановления желаемое количество копий.

• Третий OSD, в той же группе размещения, происходит сбой до восстановления завершено. Если это OSD содержало единственную оставшуюся копию объект, он навсегда потерян.

В кластере, содержащем 10 OSD с 512 группами размещения в трех Пул реплик, CRUSH даст каждой группе размещения три OSD. в В конце концов, все OSD будут размещаться (512 * 3) / 10 = ~ 150 Placement Группы. При выходе из строя первого OSD приведенный выше сценарий начать восстановление для всех 150 групп размещения одновременно.

150 восстанавливаемых групп размещения, вероятно, будут равномерно распределены по 9 оставшимся экранным меню. Каждое оставшееся экранное меню поэтому, вероятно, отправит копии объектов всем остальным, а также получить некоторые новые объекты для хранения, потому что они стали частью новая группа размещения.

Время, необходимое для полного восстановления зависит от архитектуры кластера Ceph. Допустим, каждое OSD размещены на 1 ТБ SSD на одной машине, и все они подключены до 10 Гбит / с, и восстановление для одного OSD завершается в течение М минут Если на машине есть два OSD, использующих счетчики без Журнал SSD и 1 Гбит / с коммутатор, по крайней мере, будет порядка величина медленнее.

В кластере такого размера количество групп размещения имеет почти не влияет на долговечность данных.Это может быть 128 или 8192 и восстановление не будет медленнее или быстрее.

Однако растет тот же кластер Ceph до 20 OSD вместо 10 OSD может ускорить восстановление и, следовательно, повысить надежность данных значительно. Каждое OSD теперь участвует только в ~ 75 группах размещения вместо ~ 150, когда было только 10 OSD, и это все еще потребует все 19 оставшихся OSD для выполнения одинакового количества копий объектов в Чтобы восстановить. Но где 10 OSD пришлось скопировать примерно 100 ГБ каждый, теперь они должны скопировать 50 ГБ каждый вместо этого.Если сеть была узкое место, восстановление произойдет в два раза быстрее. Другими словами, восстановление происходит быстрее, когда увеличивается количество OSD.

Если этот кластер вырастет до 40 OSD, в каждом из них будет только ~ 35 группы размещения. Если OSD умирает, восстановление будет продолжаться быстрее если это не заблокировано другим узким местом. Однако если этот кластер увеличивается до 200 OSD, каждое из которых будет содержать только ~ 7 групп размещения. Если OSD умирает, восстановление происходит между большинством из ~ 21 (7 * 3) OSD в этих группах размещения: восстановление займет больше времени, чем когда было 40 OSD, то есть количество групп размещения должно быть вырос.

Независимо от того, насколько короткое время восстановления, есть шанс второе экранное меню не работает во время его выполнения. В кластере 10 OSD описано выше, если какой-либо из них потерпит неудачу, то ~ 17 групп размещения (т.е. ~ 150/9 восстанавливаемых групп размещения) будет иметь только одну сохранившаяся копия. И если какой-либо из 8 оставшихся OSD выходит из строя, последний объекты двух групп размещения могут быть потеряны (т.е. ~ 17/8 группы размещения с восстановлением только одной оставшейся копии).

Когда размер кластера увеличивается до 20 OSD, количество мест размещения Группы повреждены потерей трех OSD капель.Второе OSD потеряно будет ухудшаться ~ 4 (то есть ~ 75/19 восстанавливаемых групп размещения) вместо ~ 17 и третье потерянное OSD потеряет данные, только если оно из четырех OSD, содержащих сохранившуюся копию. Другими словами, если вероятность потери одного OSD составляет 0,0001% за время восстановления фрейм, он идет от 17 * 10 * 0,0001% в кластере с 10 OSD до 4 * 20 * 0,0001% в кластере с 20 OSD.

Короче говоря, больше OSD означает более быстрое восстановление и меньший риск каскадные сбои, ведущие к постоянной потере места размещения Группа.Наличие 512 или 4096 групп размещения примерно эквивалентно в кластер с менее чем 50 OSD, что касается надежности данных.

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

Распределение объектов в бассейне

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

Например, если была одна группа размещения для десяти OSD в три пула реплик, только три OSD будут использоваться, потому что CRUSH будет другого выбора нет. Когда доступно больше групп мест размещения, объекты с большей вероятностью будут равномерно распределены между ними.CRUSH также прилагает все усилия для равномерного распределения экранных меню среди всех существующих мест размещения Группы.

До тех пор, пока на один или два порядка больше Группы, чем OSD, распределение должно быть четным. Например, 256 группы размещения для 3 OSD, 512 или 1024 группы размещения для 10 OSD и т. д.

Неравномерное распределение данных может быть вызвано другими факторами, кроме отношения между OSD и группами размещения. Так как CRUSH не принимает во учитывая размер объектов, несколько очень больших объектов могут создавать дисбаланс.Допустим, один миллион 4K-объектов общим объемом 4 ГБ равномерно распределены среди 1024 групп размещения на 10 OSD. Они будут использовать 4GB / 10 = 400 МБ на каждом OSD. Если один объект 400 МБ добавлен в пул, три OSD, поддерживающие группу размещения, в которой находился объект будет заполнено 400 МБ + 400 МБ = 800 МБ, а семь другие останутся заняты только 400 МБ.

Память, использование процессора и сети

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

Минимизация количества групп размещения экономит значительные суммы Ресурсы.

Выбор количества групп размещения

Если у вас более 50 OSD, мы рекомендуем приблизительно 50-100 размещение групп в OSD для балансировки использования ресурсов, данных долговечность и распределение. Если у вас менее 50 экранных меню, выберите среди вышеупомянутого отбора лучше всего.Для одного пула объектов, Вы можете использовать следующую формулу, чтобы получить базовый уровень:

 (OSDs * 100)
Всего ПГ = ------------
              размер бассейна
 

Где размер пула — это число реплик для реплицируемого пулы или сумма K + M для кодированных пулов стирания (как возвращено ceph osd erasure-code-profile получить ).

Затем вы должны проверить, имеет ли результат смысл с тем, как вы спроектировал ваш кластер Ceph для обеспечения максимальной надежности данных, Распределение объектов и минимизация использования ресурсов.

Результат всегда должен быть округлен до до ближайшей степени двух .

Только сила двух равномерно уравновесит количество объектов среди группы размещения. Другие значения приведут к неравномерному распределению данные через ваши OSD. Их использование должно быть ограничено постепенно переходя от одной степени двух к другой.

Например, для кластера с 200 OSD и размером пула 3 Реплики, вы бы оценили свое количество PG следующим образом:

 (200 * 100)
----------- = 6667.Ближайшая сила 2: 8192
     3
 

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

Например, кластер из 10 пулов каждый с 512 группами размещения на десять OSD — это 5120 групп размещения, распределенных по десяти OSD, это 512 групп размещения в OSD.Это не использует слишком много Ресурсы. Однако, если 1000 пулов были созданы с 512 размещением группы, OSD будет обрабатывать ~ 50 000 групп размещения, и это потребует значительно больше ресурсов и времени для пиринга.

Вам может пригодиться инструмент PGCalc.

Установить количество групп размещения

Чтобы задать количество групп мест размещения в пуле, необходимо указать количество групп размещения на момент создания пула. См. Создание пула для деталей.Даже после создания пула вы также можете изменить количество групп мест размещения с помощью:

 ceph osd pool set {имя пула} pg_num {pg_num}
 

После увеличения количества групп размещения необходимо также увеличить количество групп размещения для размещения ( pgp_num ) прежде чем ваш кластер будет сбалансирован. pgp_num будет числом группы размещения, которые будут рассмотрены для размещения CRUSH алгоритм. Увеличение pg_num разбивает группы мест размещения, но данные не будут перенесены в новые группы мест размещения до момента их размещения группы для размещения, т.е. pgp_num увеличено. pgp_num должно быть равно pg_num . Увеличить количество группы размещения для размещения, выполните следующие действия:

 ceph osd pool set {имя пула} pgp_num {pgp_num}
 

При уменьшении количества PG настраивается pgp_num автоматически для вас.

Получить количество групп размещения

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

 ceph osd pool get {pool-name} pg_num
 

Получите статистику PG кластера

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

 ceph pg dump [--format {format}]
 

Допустимые форматы: , обычный (по умолчанию) и , json .

Получить статистику для Stuck PGs

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

 ceph pg dump_stuck неактивно | unclean | устаревшее | недооценено | ухудшено [--format <формат>] [-t | --threshold <секунд>]
 

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

Unclean Группы размещения содержат объекты, которые не реплицируются нужного номера раз.Они должны поправляться.

Stale Группы размещения находятся в неизвестном состоянии — OSD, в которых они размещены, не имеют сообщается в кластер монитора через некоторое время (настроено mon_osd_report_timeout ).

Допустимые форматы: , обычный (по умолчанию) и , json . Порог определяет минимальное количество секунд группа размещения застревает перед включением ее в возвращаемую статистику (по умолчанию 300 секунд).

Получить карту PG

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

Например:

Ceph вернет карту группы мест размещения, группу мест размещения и статус экранного меню:

 osdmap e13 pg 1.6c (1.6c) -> вверх [1,0] действующий [1,0]
 

Получить статистику PGs

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

Скраб группы размещения

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

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

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

 ceph osd pool scrub {имя-пула}
 

Приоритетная засыпка / восстановление группы (мест) размещения

Вы можете столкнуться с ситуацией, когда для группы мест размещения потребуется восстановление и / или обратная засыпка, а некоторые конкретные группы хранят данные более важными чем другие (например, эти PG могут содержать данные для изображений, используемых при запуске машины и другие PG могут использоваться неактивными машинами / менее важными данными).В этом случае вы можете расставить приоритеты для восстановления этих групп, чтобы производительность и / или доступность данных, хранящихся в этих группах, восстанавливается ранее. Для этого (отметьте определенную группу (ы) мест размещения как приоритетные во время засыпка или восстановление), выполните следующее:

 ceph pg force-recovery {pg-id} [{pg-id # 2}] [{pg-id # 3} ...]
ceph pg force-backfill {pg-id} [{pg-id # 2}] [{pg-id # 3} ...]
 

Это заставит Ceph выполнить восстановление или обратную засыпку в указанном месте размещения группы в первую очередь, перед другими группами размещения.Это не прерывает в настоящее время текущие засыпки или восстановление, но приводит к обработке указанных PG как можно скорее. Если вы передумали или расставили приоритеты в неправильных группах, использование:

 ceph pg cancel-force-recovery {pg-id} [{pg-id # 2}] [{pg-id # 3} ...]
ceph pg cancel-force-backfill {pg-id} [{pg-id # 2}] [{pg-id # 3} ...]
 

Это удалит флаг «force» из этих PG, и они будут обработаны в порядке по умолчанию. Опять же, это не влияет на текущее обработанное место размещения. группа, только те, которые все еще стоят в очереди.

Флаг «принудительно» сбрасывается автоматически после восстановления или обратной засыпки группы сделано.

Точно так же вы можете использовать следующие команды, чтобы заставить Ceph выполнить восстановление или сначала засыпьте все группы мест размещения из указанного пула:

 ceph osd pool принудительное восстановление {имя пула}
ceph osd pool force-backfill {имя-пула}
 

или:

 ceph osd pool cancel-force-recovery {имя пула}
ceph osd pool cancel-force-backfill {имя пула}
 

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

Обратите внимание, что эти команды могут нарушить порядок внутренних приоритетные вычисления, поэтому используйте их с осторожностью! Особенно, если у вас есть несколько пулов, которые в настоящее время совместно используют один и тот же лежащие в основе OSD и некоторые конкретные пулы содержат данные более важные, чем другие, мы рекомендуем использовать следующую команду для перестановки всех пулов приоритет восстановления / обратной засыпки в лучшем порядке:

 ceph osd pool set {имя-пула} recovery_priority {значение}
 

Например, если у вас есть 10 пулов, вы можете сделать самый важный приоритет 10, следующие 9 и т. д.Или вы можете оставить большинство пулов в покое и, скажем, 3 важных пула все приоритеты 1 или 3, 2, 1 соответственно.

Вернуть Потерянный

Если кластер потерял один или несколько объектов, и вы решили отказаться от поиска потерянных данных, необходимо пометить найденные объекты как потерял .

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

В настоящее время единственная поддерживаемая опция — «вернуться», которая либо откатится к предыдущая версия объекта или (если это был новый объект) забыть об этом полностью. Чтобы пометить «не найденные» объекты как «потерянные», выполните следующее:

 ceph pg {pg-id} mark_unfound_lost вернуться | удалить
 

Важно

Используйте эту функцию с осторожностью, потому что она может запутать приложения, которые ожидают, что объект (ы) существует.