Глава 8. Планирование промышленного применения и настройка производительности Ceph

В этой главе мы изучим некоторые очень интересные концепции относительно Ceph. Они содержат рекомендации по аппаратным и программным средствам, настройку производительности компонентов Ceph (т.е. Ceph MON, OSD), а также клиентов, включая тюнинг ОС. Наконец мы узнаем об удаляемом кодировании и многоуровневом кэшировании, охватив различные технологии обоих.

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

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

Различные организации имеют различные рабочие нагрузки, которые обычно требуют некоторых общих компромиссов между производительностью, ёмкостью и ТСО. Ceph является универсальным хранилищем, то есть, оно может предоставлять хранение Файлов, Блоков и Объектов в одном и том же кластере. Ceph также способен предоставлять различные типы пулов хранения в пределах одного и того же кластера, которые предназначены для различных рабочих нагрузок. Может существовать множество способов определения ваших потребностей в хранении; следующая схема один из вариантов их определения:

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

Ceph не зависит от аппаратных средств; организации вольны выбирать любое оборудование по своему усмотрению основываясь на их бюджете, требованиях к производительности/ ёмкости или способам применения. Они получают полное управление над их кластером хранения и лежащей в его основе инфраструктуре. Кроме того, одним из основных преимуществ Ceph является то, что она поддерживает разнородное оборудование. Вы можете мешать торговые марки при создании инфраструктуры кластера Ceph. Например, при построении своего кластера Ceph вы можете смешивать оборудование от различных производителей, таких как HP, Dell, Supermicro и так далее {Fujitsu, Huawei, Inspur, Mdl...}, а также даже уже имеющееся в наличии оборудование, что может приводить к значительной экономии средств. {Прим. пер.: не следует, однако, забывать об усложнении технической поддержки и сопровождения при росте вашего зоопарка.}

Вам следует иметь в виду, что выбор для Ceph управляется рабочими нагрузками, которые вы планируете размещать в вашем кластере хранения, вашей среде и используемой вами функциональности. В данном рецепте мы изучим некоторые основные практические подходы по выбору оборудования для вашего кластера Ceph. {Прим. пер.: см. также наш перевод официальных Рекомендаций по оборудованию Ceph.}

Ваш демон монитора Ceph поддерживает карты вашего кластера и не обслуживает никакие данные клиентов, следовательно он легковесен и не имеет очень сильных требований к процессору. В большинстве случаев средний одноядерный процессор выполнит работу монитора Ceph. Сдругой стороны, MDS Ceph слегка более требователен к ресурсам. Ему требуется значительно более мощный ЦПУ с четырьмя ядрами или даже больше. Для небольшого кластера Ceph или для среды проверки концепции вы можете совмещать мониторы Ceph с прочими его компонентами, такими как OSD, Radosgw или даже MDS Ceph. Для окружений с размером от среднего и выше, вместо совместного использования мониторы Ceph должны размещаться на выделенных машинах. {Прим. пер.: с точки зрения единообразия и взаимозаменяемости стоит рассмотреть и возможность применения однотипных ЦПУ!}

Демон OSD требует достаточный объём вычислительной мощности, так как он обслуживает данные клиентов. Для оценки требований к ЦПУ для OSD Ceph важно знать сколько OSD будет размещать данный сервер. Обычно рекомендуется чтобы каждый демон OSD располагал как минимум одним ГГц на ядро ЦПУ. Вы можете применять следующую формулу для оценки потребностей ЦПУ OSD:

((разёмы ЦПУ * число ядер на разъём ЦПУ * тактовая частота ЦПУ в ГГц) / число OSD) >=1
	   

Например, сервер с одним сокетом ЦПУ, 6 ядрами по 2.5ГГц должен быть достаточно хорош для 12 OSD Ceph, причём каждый OSD получит примерно 1.25ГГц вычислительной мощности: ((1*6*2.5)/12)= 1.25.

Если вы планируете применять функциональность удаляющего кодирования (erasure coding, EC), будет более выгодным получить более мощные ЦПУ, поскольку работа удаляющего кодирования требует больших вычислительных потребностей.

{Прим. пер.: приведём для справки:
31 марта 2016 Intel объявил о начале приёма заказов на новую линейку процессоров Intel® Xeon® E5-2600 v4, совместимых с v3 (необходимо обновление firmware материнской платы). Ждём новый чипсет материнских плат для PCIe 4.0.

Рекомендуемые цены Intel на некоторые ЦПУ, 1 апреля 2016

Наименование	Число ядер Рекомендуемое число OSD	Расчётная мощность	Рекомендуемая цена Cтоимость OSD
Intel® Xeon® E5-2699 v4 (55M Кэш, 2.20 ГГц)	22 48	145Вт	$4 115 $85.7
Intel® Xeon® E5-2697 v4 (45M Кэш, 2.30 ГГц)	18 41	145Вт	$2 702 $65.9
Intel® Xeon® E5-2680 v4 (35M Кэш, 2.40 ГГц)	14 33	120Вт	$1 745 $70.5
Intel® Xeon® E5-2650 v4 (30M Кэш, 2.20 ГГц)	12 26	105Вт	$1 166 $44.9
Intel® Xeon® E5-2640 v4 (25M Кэш, 2.40 ГГц)	10 24	90Вт	$939 $39.1
Intel® Xeon® E5-2630 v4 (25M Кэш, 2.20 ГГц)	10 22	85Вт	$667 $30.3
Intel® Xeon® E5-2620 v4 (20M Кэш, 2.10 ГГц)	8 16	85Вт	$417 $26.1
Intel® Xeon® E5-2609 v4 (20M Кэш, 1.70 ГГц)	8 13	85Вт	$310 $23.5
Intel® Xeon® E5-2680 v3 (30M Кэш, 2.50 ГГц)	12 30	120Вт	$1745 $58.2
Intel® Xeon® E5-2650 v3 (25M Кэш, 2.30 ГГц)	10 23	105Вт	$1166 $50.7
Intel® Xeon® E5-2630 v3 (20M Кэш, 2.40 ГГц)	8 19	85Вт	$667 $34.7
Intel® Xeon® E5-2620 v3 (15M Кэш, 2.40 ГГц)	6 14	85Вт	$417 $29.8
Intel® Xeon® E5-2603 v3 (15M Кэш, 1.60 ГГц)	6 9	85Вт	$213 $23.7
Рекомендуемая розничная цена (РРЦ) представляет собой рекомендуемую цену для продуктов Intel. Цены указаны для прямых клиентов Intel, обычно для заказов партий из 1000 шт. и могут быть изменены без уведомления. Налоги, расходы на доставку и прочие расходы не включены. Цены могут отличаться для других типов упаковки и объёмов поставок, а также могут действовать условия специальных акций. Если продаётся в оптовой партии, цена относится к единице продукции. Указание рекомендуемых розничных цен не является официальной ценовой офертой Intel. Обратитесь к своему представителю Intel, чтобы получить официальное подтверждение цены.

(Более полная таблица xls). Также отметим ссылки на цены РРЦ процессоров Intel® Xeon® E7 v4 и Phi x200 }

Демонам монитора и метаданных требуется обслуживать свои данные быстро, следовательно они должны иметь достаточно памяти для более быстрой работы. Практический способ - необходимо иметь 2ГБ или более памяти на экземпляр демона- этого должно быть достаточно и для MDS Ceph, и для монитора. MDS Ceph сильно зависят от кэширования данных; так как им необходимо обслуживать данные быстро, им необходимо достаточно оперативной памяти. Чем больше оперативной памяти для для MDS Ceph, тем лучше будет производительность CephFS.

Для OSD обычно требуется приличный объём физической памяти. При средней рабочей нагрузке 1ГБ памяти на экземпляр демона OSD должно быть достаточно; однако с точки зрения производительности 2ГБ на демон OSD будет хорошим выбором, а ещё больший объём также поможет при восстановлении и будет лучше для кэширования. Эта рекомендация предполагает, что вы применяете один демон для одного физического диска. Если вы применяете более одного физического диска на OSD, ваши требования к памяти также возрастут. Обычно больший объём физической памяти это хорошо, поскольку в процессе восстановления кластера значительно повышается потребление оперативной памяти. Следует знать, что потребление памяти OSD увеличится, если вы учитываете сырую ёмкость лежащего в основе физического диска. Поэтому требования OSD для 6ТБ диска будут больше чем в случае 4ТБ диска. Вам следует принимать такое решение разумно, с тем, чтобы оперативная память не стала узким местом в производительности вашего кластера.

{Прим. пер.: современные процессоры Intel® Xeon® E5-2600 v3 применяют память DDR4 SDRAM, согласно спецификации имеющую предел пропускной способности 25.6ГБ/c на канал. С учётом потерь на взаимодействие модулей памяти, это около 100ГБ/c при эффективной частоте 3.2ГГц, что даёт оценку времени обмена данными в 1ТБ порядка 10 секунд. Имеющаяся на рынке в марте 2016г работает с эффективной частотой 2.133ГГц, что допускает предел пропускной способности порядка 68ГБ/с и оценку времени обмена данными с объёмом в 1ТБ порядка 15 секунд. Стоимость оперативной памяти очень сильно подвержена биржевым колебаниям. Точнее всего их динамику отслеживает ресурс http://dramexchange.com/ (оценка стоимости для больших партий снизу). Приведём пример методики оценки текущей стоимости памяти для 16ГБ модуля M393A2G40DB1 производства Samsung. Согласно спецификации, этот модуль памяти содержит 36 кристаллов 4Gb (1Gx4) 2133МГц. Биржевая стоимость 4Gb DDR4 DRAM в марте 2016 составляет порядка $2 (см. строка "DDR4 4Gb 512Mx8 2133 MHz" на http://dramexchange.com/). Разброс стоимости доступного на рынке модуля памяти составит от $2 * 36 * [1.5-2], где [1.5-2] - оценка коэффициента пересчёта. Т.е. рыночная стоимость такого модуля памяти будет в пределах $110-$140. Проверяем по amazon.com: $126.5 на момент проверки. Согласен, данная методика даёт слишком большой разброс, однако она позволяет следить за динамикой при часто возникающих турбулентных процессах на рынке памяти.}

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

Для небольшой проверки концепции или для тестирования будет достаточно кластера Ceph из нескольких узлов с сетевой средой, работающей на 1Gbps. Если у вас имеется кластер с размером выше среднего (несколько десятков узлов), вам следует думать о применении сетевой среды с пропускной способностью 10Gbps или выше. На момент восстановления/ ребалансировки сетевая среда играет решающую роль. Если у вас имеются хорошие соединения с пропускной способностью сетевой среды 10Gbps или выше, ваш кластер будет восстанавливаться быстро, в противном случае это займёт определённое время. Поэтому, с точки зрения производительности, Дублированная сеть с 10Gbps или выше будет хорошим параметром. Хорошо спроектированный кластер Ceph применяет две раздельные сетевые среды: одну для сетевой среды кластера (внутренняя сеть) и другую для сетевой среды клиентов (внешняя сеть); обе эти сетевые среды должны быть физически разделены прямо начиная с вашего сервера вплоть до сетевого коммутатора и всё в промежутке, как показано на следующей схеме:

{Прим. пер.: Часто в качестве бонуса в наличии имеется некая сеть на встроенных в материнские платы 1GbE адаптерах. Эту сеть мы рекомендуем выделять в третью, административную, способную работать с оборудованием на уровне IPMI и выполнять другие административные функции (например, функциональность Ограждения /Fencing/ для предоставления высокой доступности и управление прочими системами контроля оборудования). Причём, обращаем внимание на возможность наличия дублирования функциональности IPMI в других имеющихся в наличии сетевых средах, в том числе с выделением полосы пропускания (очень сильно зависит от производителя конкретного оборудования). За дополнительными консультациями обращайтесь к нашим специалистам.

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

В отношении вашей сетевой среды другой темой дискуссий является обсуждение того, что лучше применять: сетевую среду Ethernet или Infiniband, или, более определённо: сеть 10GbE, 40GbE или ещё больших пропускных способностей. Это зависит от ряда факторов, таких как рабочая нагрузка, размер вашего кластера Ceph, плотность и число узлов OSD Ceph и тому подобное. В некоторых реализациях я видел как пользователи применяли и 10GbE и 40GbE сетевые среды в Ceph. В этом случае их кластеры Ceph относились к уровню нескольких Петабайт и нескольких сотен узлов, причём они применяли 10GbE в качестве клиентской сети, а внутренняя сетевая среда имела более высокую пропускную способность и более низкую латентность 40GbE. Тем не менее, стоимость сетевых сред Ethernet стремительно падает; основываясь на вашем варианте применения, вы можете определять тип сетевой среды, которой вы хотите обладать.

{Прим. пер.: На протяжении последних лет я неустанно рассказывал своим заказчикам о несомненных преимуществах 56/100G IB перед 10/40/100GbE, пока не наткнулся на препятствие, которое представители Mellanox объяснили исключительно требованиями спецификации Infiniband. А именно: невозможность объединять в транки несколько линий IB для повышения пропускной способности как на аппаратном уровне, так и на уровне программного управления каналом (драйверы, etc.). Понятно, что это можно выполнить на более высоком уровне, например, на прикладном. Но это сродни забиванию гвоздей микроскопом.}

{Прим. пер.: приведём таблицу экономичных коммутаторов различных производителей, применяемых нами (или которые мы бы рады были применить в ваших решениях) для построения сетей в кластерах:

Рекомендуемые нами экономичные сетевые коммутаторы для сетевых сред Ceph, март 2016

Наименование	Число основных портов /портов расширения	Общая производ. коммутации /производ. передачи	Рекоменду- емая цена Важно: см. сноску 1
Allied Telesis AT-DC2552XS/L3	48x SFP+ 10GbE 4x QSFP+ 40GbE	1.28Tbps 952.32 Mpps	$16 0001
Allied Telesis AT-XS916MX(T/S)	12x/4x Base-T 10GbE 4x/12 SFP+ 10GbE	320Gbps 238 Mpps	-
Brocade VDX 6940-144S	96*10GbE SFP+ 4*100GbE QSFP+	2.88Tbps 2.16 Bpps	?
Dell Z9100-ON/ S6100-ON	32x 100GbE / 64x 50GbE / 64x/32x 40GbE (S6100/Z9100) /128x SFP+ 25GbE /128x SFP+ 10GbE	6.4Tbps 4.4 Bpps	~$50 000/ ~$60 0001
Dell S6000-ON	96x SFP+ 10GbE 8x QSFP+ 40GbE / 32x QSFP+ 40GbE	1.44Tbps 1 080 Mpps	?1
Dell S4048-ON	48x SFP+ 10GbE 6x QSFP+ 40GbE	1.44Tbps 1 080 Mpps	?1
Dell N4064F	48x SFP+ 10GbE 4x QSFP+ 40GbE	1.28Tbps 952 Mpps	$15 0001
Dell N4032F	24x SFP+ 10GbE 2x QSFP+ 40GbE	0.64Tbps 476 Mpps	$9 9001
Dlink DXS-1210-12SC	10x SFP+ 10GbE + 2x Base-T/SFP+ 10GbE	0.24Tbps 178.56 Mpps	$1 5001
Edge-Core AS5610-52X (ONIE) WhiteBox	48x 10GbE SFP+ 4x 40GbE QSFP+	1.28 Tbps 960 Mpps	$5 1001
Edge-Core AS6701-32X (ONIE) WhiteBox	20x 40GbE SFP+ (+ 12x 40GbE через слоты расширения)	2.56 Tbps 1.92 Bpps	$7 9001
Huawei CE6851-48S6Q-HI	48*10GbE SFP+ 6*40GbE QSFP+	1.44Tbps 1 080Mpps	$16 0001
Huawei S6720-54C-EI-48S-AC	48*10GbE SFP+/SFP 2*40GbE QSFP+	2.56Tbps 1 080Mpps	$16 0001
Huawei S6720-30C-EI-24S-AC	24*10GbE SFP+/SFP 2*40GbE QSFP+	2.56Tbps 720Mpps	$12 8001
Huawei CE7850-32Q-EI	32*40GbE QSFP+ -	2.56Tbps 1 440Mpps	$32 0001
Huawei CE8860-4C-EI	4 слота обслуживания x(8x100GbE QSFP28/ 16x 40GE QSFP+/ 24x 25GE SFP28/ 24x 10GE SFP+)	6.4Tbps 2 976Mpps	$40 0001
Huawei S12804S	4 слота до 36x 40GbE (2016Q3: 100GbE)	40/80Tbps 17 280 Mpps	$69 6241
Juniper OCX1100-48SX	48x 10GbE SFP+ 6x 40GbE портов QSFP+	1.44Bbps 1 080 Mpps	$32 0001
Juniper QFX5100-24Q	24x 40GbE QSFP+	2.56Tbps 1.44Bpps	$40 0001
Juniper QFX5200-32С	32x40GbE QSFP+/ 28QSFP	3.2Tbps 2.44Bpps	$35 0001
Mellanox SN2700	до 32x 40/56/100GbE или 64x 10/25GbE или 64x 50GbE	6.4Tbps 4 770 Mpps	-
Mellanox SN2410	48x 25GbE 8x 100GbE	6.4Tbps 4 770 Mpps	-
Mellanox SB7790-E	10/20/40/56/100G 4X IB 36x QSFP28 портов	7.2Tbps 7 020 Mpps	$22 0091
Mellanox SX6036F	10/20/40/56 4X IB 36x QSFP	4.032 Tbps ?	$15 3731
Mellanox SX1024	48x 10GbE SFP+ 12x/4x 40GbE QSFP+	2.0 Tbps 3 Mpps	$17 7691 / $15 2341
Mellanox SX1012	12x 40/56GbE SFP+ портов	2.0 Tbps 3 Bpps	$11 4251
Mellanox SX6015F	18x QSFP+ FDR 56G	2.0 Tbps 3 Bpps	$11 9951
Mellanox SX6005F	12x QSFP+ FDR 56G	1.3 Tbps 1.5? Bpps	$5 3611
Mellanox SX6005T	12x QSFP+ FDR10 40G	1.3 Tbps 1.5? Bpps	$6 6521
Mellanox SX6005T	12x QSFP+ FDR10 40G	1.3 Tbps 1.5? Bpps	$6 6521
1 Стоимостные оценки приводятся по прайс- листам рекомендованных производителями цен при не сопоставимых условиях и поэтому не могут служить основанием для сравнения цен различных производителей в пределах этой таблицы! При наличии необходимости сопоставления цен различных производителей под конкретный проект обращайтесь к нашим специалистам! Сопоставлять в пределах таблицы можно исключительно цены одного производителя!

}

{Прим. пер.: приведём таблицу оценки времён, необходимых для обмена данных объёмом в 4ТБ (условно говоря, выход из строя 6ТБ диска в системе с "приличной" загруженностью):

Оценка снизу времени обмена 4ТБ данных

Скорость обмена	Оценка необходимого времени
10GbE	55 минут
25GbE	22 минуты
40GbE	14 минут
56G IB	10 минут
PCIe v.3 8x lane	8+2/3 минут
100GbE/ IB	5.5 минут
PCIe v.3 16x lane	4+1/3 минуты

}

{ Прим. пер.: Следует иметь в виду, что устройства сетевого обмена имеют большой объем функционала, позволяющий сделать вашу жизнь легче. Это и объединение каналов в "транки", и различные виды поддержки RDMA (например, RDMA over Converged Ethernet), а также, Mellanox анонсировал аппаратную поддержку Erasure Coding в своих ASIC ConnectX-4. Следовательно в августе 2016 можно ждать новые драйверы Infiniband и Mellanox Ethernet с аппаратной поддержкой EC для Ceph, освобождающей от этой задачи ЦПУ узлов (подробности по возможности асинхронной работы таких методик). Большой интерес также представляет инициатива 25GbE. Помимо снижения стоимости пропускной способности и повышения ее общедоступного нижнего порога для сетевой среды кластера Ceph (c 10GbE на 25GbE), она улучшает арифметику деления ядра сети: 100 делится на 25 без остатка! Стоит отметить, что 25GbE уже - 31 марта 2016 - доступны к заказу! Повторим: они призваны заменить собой 10GbE. В качестве лёгкого отстутпления от темы: все мы пользуемся WiFi, следовательно и добравшееся своими 2.5/5GbE до стандарта Ethetrnet- сообщество радует нас!}

  Диск

Производительность и экономичность для кластеров Ceph совместно сильно зависят от эффективного выбора носителей для хранения. Вам следует понимать вашу рабочую нагрузку и возможные требования перед выбором носителей хранения для вашего кластера Ceph. Ceph применяет носители хранения двумя способами: часть Ceph ведущая журналы и часть данных Ceph. Как объяснялось в предыдущих главах, каждая операция write в Ceph является в настоящее время двухшаговым процессом. Когда OSD получает запрос на запись объекта, он вначале записывает этот объект в журнальную часть OSD в его активном наборе и отправляет подтверждение write клиентам. Вскоре после этого журнальные данные синхронизируются с разделом данных. Следует знать, что репликации также являются важным фактором в процессе исполнения write. Коэффициент (factor) репликаций обычно является компромиссом между надёжностью, производительностью и совокупной стоимостью владения (TCO). В этом случае вся производительность кластера вращается вокруг разделов журнала и данных OSD.

  Раздел журнала OSD Ceph

Если рабочая нагрузка сосредоточена вокруг производительности, то рекомендуется применять для журналов SSD. При использовании SSD вы можете получить значительное улучшение за счёт уменьшения времени доступа и латентности write. Для использования SSD в качестве журнала мы создаём множество логических разделов на каждом физическом SSD так, что каждый логический раздел SSD (журнал) соответствует одному разделу OSD. В этом случае ваш раздел данных размещается на шпиндельном диске и имеет собственный журнал в более быстром разделе SSD. Следующая схема иллюстрирует такую конфигурацию:

 

Рисунок 8.4. Применение одного SSD в качестве журнала множества разделов данных OSD

При подобном типе компоновки вам следует иметь в виду, что не следует перегружать SSD хранением множества журналов свыше их пределов. Обычно для большинства вариантов применения должно быть достаточно размера журнала от 10 до 20ГБ, если у вас SSD большего размера вы можете создавать устройства журнала большего размера; в этом случае не забывайте увеличивать максимальный и минимальный интервалы синхронизации сохранения файлов для OSD.

Двумя наиболее распространёнными типами энергонезависимых быстрых устройств хранения применяемыми в Ceph являются SATA или SAS SSD и PCIe или NVMe SSD. Для получения хорошей производительности ваших SATA/ SAS SSD, ваше соотношение SSD к OSD должно быть 1 : 4, т.е. один SSD применяется совместно 4мя дисками данных OSD. При использовании вами флеш- устройств PCIe или NVMe, в зависимости от производительности, соотношение SSD к OSD может варьироваться от 1 : 12 до 1 : 18, т.е. одно флеш- устройство разделяется между дисками данных в количестве от 12 до 18.

	Замечание
	Приведённые здесь рекомендации соотношения SSD к OSD очень общие и в большинстве случаев хорошо работают. Однако я призываю вас протестировать ваши SSD/PCIe именно на специфичных для вас нагрузок и окружениях для получения наилучшего соотношения.

Тёмной стороной применения одного SSD для нескольких журналов состоит в том, что если вы теряете ваш SSD, размещающий множество журналов, все те OSD, которые связанные с этим OSD выйдут из строя и вы можете утратить ваши данные. Однако вы можете преодолеть эту проблему применяя RAID 1 в для ведения журнала, что, однако, приведёт к повышению стоимости вашего хранилища. К тому же стоимость за гигабайт примерно в 10 раз выше по сравнению с HDD {Прим. пер.: спорное утверждение, см. приводимые ниже справочные данные по состоянию на март 2016.} Поэтому, если вы строите кластер с SSD, вы увеличиваете стоимость за Гигабайт для вашего кластера Ceph. Однако, если вы ищете пути значительного улучшения производительности вашего кластера Ceph, инвестиции в SSD для журналов будут достойны внимания.

Мы получили сведения о журналах SSD и понимании того вклада, который они вносят в улучшение вашей производительности write. Однако, если вы не беспокоитесь о значительном улучшении производительности, а стоимость за ТБ является для вас решающим фактором для вас, то вам следует рассмотреть настройку раздела данных журнала на том же самом дисковом устройстве. Это означает, что вы будете выделять на вашем большом шпиндельном диске несколько ГБ для журнала OSD и применять оставшееся пространство того же диска для данных OSD. Такой вид установки может оказаться не столь производительным как аналогичная установка на основе SSD журнала, однако совокупная стоимость за ТБ будет значительно ниже.

  Раздел данных OSD Ceph

OSD являются реальными рабочими лошадками, хранящими все ваши данные. В промышленной среде Вам следует применять для вашего кластера Ceph жёсткие диски класса предприятия, облака или архива. Обычно жесткие диски уровня настольных компьютеров не очень хорошо подходят для промышленного кластера Ceph. Причина состоит в том, что в кластере Ceph несколько сот вращающихся жёстких дисков установлены очень близко и комбинация вибраций от вращения может стать проблемой для жёстких дисков уровня настольных компьютеров. Это увеличивает скорость отказа диска и может ухудшать общую производительность. Жёсткие диски корпоративного уровня намеренно имеют многие другие конструктивные решения для обработки вибраций и при этом они сами по себе генерируют очень малые уровни вибрации. Кроме того, их среднее время безотказной работы (MTBF) значительно выше чем показатели жёстких дисков уровня настольных решений.

{Прим. пер.: более дорогостоящие жёсткие диски имеют на управляющем контроллере несколько датчиков ускорений и схему управления обратной связью с системой позиционирования блока головок над считывающими дорожками, которые до определённой степени компенсируют внешние вибрации. Не следует также пренебрегать и прочими конструктивными особенностями шасси при размещении ваших шпиндельных устройств, позволяющих снижать уровень вибраций. Однако вибрации - не единственный фактор, вносящий различия между шпиндельными дисками с низкой стоимостью и дисками, предназначенными для работы в режиме 24x7. К таковым можно отнести качество применяемых подшипников, материалов корпуса, их уровня теплопроводности, устойчивости к перепадам температур и тем же вибрациям, применяемая элементная база и многие другие конструктивные решения, нагляднее...}.

Другим подлежащим рассмотрению моментом для диска данных OSD Ceph является интерфейс, то есть SATA или SAS. Жёсткие диски NL-SAS имеют дублированные порты SAS 12Гб/с и они обычно более высоко производительны чем интерфейсы жёстких дисков SATA 6Гб/c с одиночным портом. Кроме того, дублированные порты SAS предоставляют отказоустойчивость и допускают одновременные чтение и запись. Дополнительным фактором устройств SAS также является то, что они имеют более низкое значение невосстановимых ошибок чтения (unrecoverable read errors, URE) в сравнении с устройствами SATA. Чем ниже уровень URE, тем меньше ошибок очистки и операций по восстановлению групп размещения. {Прим. пер.: см. также обзор ETegro SAS vs SATA, для справки: значения URE для современных дисков составляют величины порядка 10^-15 - 10^-16.}

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

Например, в кластере Ceph с размером 1ПБ вам следует избегать применения узлов OSD 4x 250ТБ, в которых каждый узел содержит 25% ёмкости кластера. Вместо этого вы можете располагать узлами OSD 13x 80ТБ, в которых размер каждого узла меньше 10% от ёмкости всего кластера. Однако это может увеличить вашу стоимость совокупного владения и может оказывать воздействие на прочие факторы планирования вашего кластера.

{Прим. пер.: приведём таблицу топовых характеристик устройств хранения некоторых производителей, применяемых нами (или которые мы бы рады были применить в ваших решениях) для построения OSD в кластерах:

Топовые характеристики устройств хранения, март 2016

Наименование серии макс. ёмкость осн. характеристики	Макс. скорость обмена МБ/с чтение/ запись	Макс. IOPS чтение/ запись	Латентность
HGST HUH7210 10ТБ 256МБ/ 7200rpm/ 3.5"	249	- -	4.16мс
Seagate ST8000NM 8ТБ 256МБ/ 7200rpm/ 3.5"	237	165 380	4.16мс
HGST HUC1018 1.8ТБ 128МБ/ 10Krpm/ 2.5"	247	- -	2.85мс
Seagate ST1800MM 1.8ТБ 128МБ/ 10Krpm/ 2.5"	241	- -	2.9мс
HGST HUC1560 0.6ТБ 128МБ/ 15Krpm/ 2.5"	271	- -	<2.0мс
Seagate ST600MP 0.6ТБ 128МБ/ 15Krpm/ 2.5"	233	- -	2.0мс
Seagate ST2000NT 2.0ТБ 128МБ/ 7200rpm/ 2.5"	136	- -	4.16мс
HGST SN100 3.2ТБ NVMe/ PCIe SSD	3000/ 1600	743000 140000	512мкс
HGST FlashMaxII/III 4.8ТБ/ 2.2ТБ eMLC/ PCIe SSD	2200/ 1400	531000/ 269000 59000/ 51000	19/22мкс
HGST SSD800MH 0.8ТБ eMLC/ 2.5"	1100/ 765	130000 110000	-
Seagate ST1600FM 1.6ТБ eMLC/ 2.5"	1900/ 625	200000 80000	115мкс
бытовой SSD .96ТБ MLC/ 2.5"	560/ 455	79000 75000	-

}

{ Прим. пер.: по состоянию на март 2016г стоимость NL SATA/SAS дисков начинается от 50$/ТБ, общедоступные MLC диски могут предоставлять Терабайт за стоимость менее $500, для eMLC дисков стоимость Терабайта начинается от $2000. Интересным представляется обсуждение проблемы необходимости eMLC (Enterprise Multi-level cell, многоуровневые ячейки памяти). Один из производителей бытовых SSD на основе MLC NAND, предоставил нам информацию о количестве гарантируемых им циклов перезаписи, на основании которой мы пришли к выводу, что исходя из пропускной способности этого устройства на запись нам потребуется 3 месяца для выполнения полной последовательной записи всего диска указанное число раз в режиме 24 x 7. В любом случае, мы предоставляем расширенную гарантию на замену SSD диска в случае его выхода из строя по причине израсходованием ресурса количества перезаписи в течение гарантийного срока. За подробностями обращайтесь к нашим специалистам!}

{ Прим. пер.: Достаточно простой и внятный обзор NVMe, нового интерфейса для систем хранения, приводится в новой книге М.В.Лукаса и А.Джуда ZFS для профессионалов (Mastery FreeBSD: Advanced ZFS). В частности, становятся понятными неудачи ранних тестирований NVMe: см., например, озор тестирования NVMe Андрея Кожемяко на iXBT.

Действительно, NVMe представляет собой совершенно новый интерфейс, призванный заменить собой SAS/SATA/SCSI для безшпиндельных устройств хранения. Вот некоторые основные преимущества NVMe:

• Он полностью отказывается от представления данных в виде головки-цилиндры-сектора.

• Вместо единственной очереди для AHCI, к тому же ограниченной 32-64 командами, NVMe поддерживает до 64k очередей по 64k команд в каждой! Это позволяет максимально загружать работой все имеющиеся в накопителе ячейки памяти с макимально доступным уровнем параллелизма!

• Он выделяет пространство имён, делая возможной раздельную работу с ним и относящимися к нему данными. В NVMe уровня предприятия заявлена функциональность множественности разделяемых пространств имён, что предоставит дополнительные возможности роста производительности!

Исходя из этого, становится понятным, что новые интерфейсы устройств требуют новых подходов для построения оптимальных режимов работы. Прежде всего необходима грамотная организация достаточного числа (для организации загруженности NVMe устройства) очередей. А именно: предлагается создавать не менее одной очереди на чтения и одной очереди на запись для каждого доступного ядра ЦПУ. Следующий этап лежит в оптимозации размера блока. Для NVMe предначертано спецификацией применение блоков с максимально возможными размерами. Уже эти два мероприятия быстро дают выход на пики производительности, как это демонстрируют М.В.Лукас и А.Джуд в своей новой книге, см. наш перевод.}

{Прим. пер.: приведём таблицу оценки времён, необходимых для обмена данных объёмом в 4ТБ (условно говоря, выход из строя 6ТБ диска в системе с "приличной" загруженностью):

Оценка снизу времени обмена 4ТБ данных

Скорость обмена	Оценка необходимого времени
HDD 130МБ/с	9 часов
HDD 240МБ/с	5 часов
SSD 455МБ/с	2.5 часа
SATA 6G	1.5 часа
SAS 12G	45 минут
SSD 2200МБ/с	30 минут
NVMe 3000МБ/с	23 минуты
PCIe v.3 8x lane	8+2/3 минут
PCIe v.3 16x lane	4+1/3 минуты

}

  Операционная система

Ceph является определяемой программным обеспечением системой, которая работает поверх операционной системы на основании Linux. Ceph поддерживает большинство основных дистрибутивов Linux. На текущий момент допустимым выбором операционной системы для работы кластера Ceph являются RHEL, CentOS, Fedora, Debian, Ubuntu, OpenSuse и SLES. Что касается версии ядра Linux, рекомендуется чтобы вы выполняли равёртывание Ceph на последних редакциях ядра Linux. Мы также рекомендуем развёртывать её на редакциях с долговременной поддержкой (LTS, long-term support). На момент написания этой книги рекомендовались версии ядра Linux v3.16.3 или более поздние в качестве хорошей отправной точки. {Прим. пер.: на момент перевода рекомендуется применять ядро Linux v4.1.4 или более поздние.} Хорошей идеей будет заглянуть на http://docs.ceph.com/docs/master/start/os-recommendations. Согласно документации, CentoS 7 и Ubuntu 14.04 являются дистрибутивами 1 уровня, для которого выполнены исчерпывающие функциональные, регрессивные и нарузочные испытания соответствия на постоянной основе и, несомненно, RHEL является наилучшим выбором, если вы применяете продукт enterprise Red Hat Ceph Storage.

  Файловая система OSD

Демон OSD Ceph работает поверх файловой системы, которой может быть XFS, EXT4 или даже Btrfs. Однако выбор правильной файловой системы является критическим моментом, поскольку демоны OSD основываются на стабильности и производительности лежащей в их основе файловой системы. Помимо стабильности и производительности файловая система также предоставляет расширенные атрибуты (XATTR, extended attributes), преимуществами которых пользуются демоны OSD Ceph. XATTR предоставляют внутреннюю информацию о состоянии объекта, снимках, метаданны[, а также ACL вашему демону Ceph, который помогает в управлении данными.

Вот почему лежащая в основе файловая система должна предоставлять достаточную ёмкость для XATTR. Btrfs предоставляет значительно больше метаданных xattr, которые хранятся с файлом. XFS имеет относительно большой предел (64kB),с которым большинство приложений не столкнётся, однако ext4 слишком мал для применения. Если вы применяете файловую систему ext4 для вашего OSD Ceph, вы всегда должны добавлять filestore xattr use omap = true в последующие настройки вашего файла ceph.conf. Выбор файловой системы чрезвычайно важен для промышленных рабочих нагрузок, а в отношении Ceph данные файловые системы отличаютсядруг от друга следующим:

• XFS: Является надёжной, зрелой и очень стабильной файловой системой, которая рекомендуется для промышленного использования в кластерах Ceph. Тем не менее, XFS находится ниже при сравнении с Btrfs. XFS имеет некоторые проблемы с производительностью при масштабировании метаданных. Кроме того, XFS является файловой системой с журналированием, то есть, когда клиент отправляет данные для записи в кластер Ceph, они вначале записываются в пространство журнала, а уже потом в файловую систему XFS. Это в два раза увеличивает накладные расходы на запись и тем самым делает выполнение XFS медленнее в сравнении с Btrfs, которая не применяет журналы. Однако, благодаря своей надёжности и стабильности XFS является наиболее популярной и рекомендуемой файловой системой для реализаций Ceph.

• Btrfs: OSD с файловой системой Btrfs в его основе предоставляет наилучшую производительность в сравнении с OSD на основе файловых систем XFS и ext4. Одним из основных преимуществ применения Btrfs состоит в её поддержке копирования при записи и снимков с поддержкой записи. При применении файловой системы Btrfs Ceph применяет параллельное ведение журналов, иными словами: Ceph записывает данные в соответствующий журнал OSD и собственно данные OSD одновременно, что является существенным усилением для производительности write. Она также поддерживает прозрачные сжатие и всеобъемлющие контрольные суммы, а также она объединяет управление множеством устройств в файловой системе. Она также имеет привлекательный функционал FSCK в реальном масштабе времени. Тем не менее, Btrfs в настоящее время не готова к промышленному применению, однако является хорошим претендентом для тестового развёртывания.

• Ext4: Четвёртая расширенная файловая система также является файловой системой с журналированием, которая является готовой к промышленному применению для OSD Ceph. Однако она не так популярна как XFS. С точки зрения производительности ext4 находится далеко от Btrfs.

	Замечание
	Не путайтесь между ведением журналов Ceph и файловыми системами с журналированием (XFS, EXt4); они различаются. Ceph выполняет своё журналирование при записи в файловую систему, а затем файловая система делает свой журнал при записи на лежащие в её основе диски.

	[global] 
		fsid                     = {UUID} 
		public network           = 192.168.0.0/24 
		cluster network          = 192.168.0.0/24 
		osd pool default pg num  = 128 
	[mon] 
	[mon.alpha] 
		host                     = alpha 
		mon addr                 = 192.168.0.10:6789 
	[mds] 
	[mds.alpha] 
		host                     = alpha 
	[osd] 
		osd recovery max active    = 3 
		osd max backfills          = 5 
	[osd.0] 
		host                       = delta 
	[osd.1] 
		host                       = epsilon 
	[client] 
		rbd cache                  = true 
	[client. radosgw.gateway] 
		host                       = ceph-radosgw 
	   

osd_disk_thread_ioprio_priority = 0
	   

 Удаляющее кодирование Ceph

В Ceph механизмом защиты данных по умолчанию являются репликации. Он испытан и является одним из самых популярных методов защиты данных. Однако изнанкой репликаций является то, что она требует удвоения вашего объёма пространства хранения для предоставления избыточности. Например, если вы планируете построить решение хранения с 1ПБ используемой ёмкости с фактором репликаций равным трём, то вам понадобится 3ПБ сырой ёмкости хранения для 1ПБ используемой ёмкости, то есть, 200% или более. Таким образом, при механизме репликаций значительно возрастает стоимость за гигибайт системы хранения. Для небольшого кластера вы можете игнорировать накладные расходы репликаций, однако для больших сред они становятся значительными.

Начиная с редакции Ceph Firefly был введён другой метод защиты данных, называемый удаляющим кодированием (erasure coding). Этот метод защиты данных совершенно отличается от метода репликаций. Он гарантирует, защищённость данных разбиением каждого объекта на фрагменты меньшего размера, называемые порциями данных (data chunk), и в конце концов сохраняя все эти порции в различных зонах отказа (failure zone) кластера Ceph. Концепция удаляющего кодирования вращается вокруг уравнения n = k + m. Что объясняется так:

• k: Это число фрагментов, на который поделён оригинальный объект; также называется порциями данных.

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

• n: Это общее число порций, создаваемое в процессе кодирования.

{ Прим. пер.: Метод удаляющего кодирования основывается на методе Рида- Соломона, демонстрирующегося в видео Примера удаляющего кодирования Рида- Соломна. Вкратце, в виде слайдшоу (один элемент данных является байтом):

 

Рисунок 8.5. Рассмотрим последовательность данных, которую необходимо сохранить в 6 фрагментах

 

Рисунок 8.6. Причём 4 порции будут хранить сами данные, а 2 некий код.

 

Рисунок 8.7. Теперь воспользуемся магией математики.

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

 

Рисунок 8.8. Заполняем пустовавшие порции.

 

Рисунок 8.9. Соответствие частей кодирующей и результирующей матриц.

 

Рисунок 8.10. Вырезая среднюю часть мы получаем:

 

Рисунок 8.11. Единичная матрица:

Вспоминаем матричную алгебру: розовая матрица является обратной для нашей кодирующей матрицы.

 

Рисунок 8.12. Умножим единичную матрицу на исходные данные:

Учитываем результат умножения Рисунка 8.10.

 

Рисунок 8.13. Выделим нужное нам:

 

Рисунок 8.14. Вернёмся к нашим фрагментам:

и наложим на них нашу матричную алгебру. Утратив две средние порции мы всё ещё восстанавливаем исходные данные! Можно проверить: это сохраняется при утрате ЛЮБЫХ двух порций.

}

Основываясь на приведённом ранее уравнении, каждый объект в пуле удаляющего кодирования будет сохраняться в виде k + m порций, причём каждая порция сохраняется в уникальном OSD с действующим набором. Таким образом, все ваши порции объекта распределяются по всему кластеру Ceph предоставляя более высокую степень надёжности. Теперь давайте обсудим некоторые полезные термины, относящиеся к удаляющему кодированию:

• Восстановление (Recovery): На момент восстановления нампонадобятся любые k порций (chunk) из {имевшихся} n для восстановления ваших данных.

• Уровень отказоустойчивости (Reliability level): При удаляющем кодировании Ceph может вынести утрату до m порций.

• Соотношение кодирования (r) (Encoding Rate): Может быть определено согласно формуле r = k / n, где r меньше 1.

• Необходимый обёъм хранения (Storage required): Может быть определено согласно формуле 1 / r.

Для лучшего понимания этих терминов давайте рассмотрим пример. Пул Ceph создаётся с пятью OSD на основе правила erasure code (3, 2). Каждый сохраняемый в пуле объект буедет делиться на множество и кодировать порции в соответствии с формулой: n = k + m.

Положим 5 = 3 + 2, тогда n = 5, k = 3, а m = 2. Таким образом, каждый объект будет делиться на три порции данных и к нему будут добавляться две дополнительные порции удаляющего кодирования, делая в сумме пять порций, которые будут распределённо сохраняться в пяти OSD пула удаляющего кодирования кластера Ceph. При возникновении отказа для построения исходного файла нам нужно (k порций), три фрагмента из пяти (n порций) для восстановления. Таким образом, мы можем допустить отказ любых (m) двух OSD, поскольку данные могут быть восстановлены с применением трёх OSD.

• Соотношение кодирования (Encoding Rate, r) = 3 / 5 = 0.6 < 1

• Необходимый обёъм хранения (Storage required) = 1 / r = 1 / 0.6 = 1.6 размеров исходного файла.

Давайте предположим, что существует файл размером 1ГБ. Для хранения этого файла в кластере Ceph в пуле удаляющего кодирования (3, 5) вам понадобится 1.6ТБ пространства хранения, причём он предоставит вам хранение файла устойчивое к отказам двух OSD.

В отличие от метода репликаций, при котором если файл хранится в пуле с репликациями, то для предоставления устойчивости пула к отказу двух OSD, Ceph понадобится пул с размеров реплики 3, что в конечном итоге потребует 3ГБ пространства хранения для надёжного хранения файла размером в 1ГБ. Таким образом, мы можем уменьшить стоимость хранения приблизительно на 40 процентов с применением функциональности удаляющего кодирования Ceph при получении тойже отказоустойчивости, что и в случае репликаций.

Пулы удаляющего кодирования требуют меньшее пространство хранения по сравнению с пулами репликаций, однако, такое сбережение пространства хранения происходит за счёт стоимости производительности, поскольку процесс удаляющего кодирования подразделяет каждый объект на множество более мелких порций данных и некоторых вычисляемых порций перемешиваемых с этими порциями данных. В конечном итоге эти порции сохраняются в различных зонах отказа (failure zone) кластера Ceph. Весь этот механизм требует немного больше вычислительной мощности от узлов OSD. Более того, на момент восстановления декодирование порций данных также требует множества вычислений. Поэтому вы можете найти механизм хранения данных удаляющим кодированием несколько более медленным чем механизм репликаций. Удаляющее кодирование во многом зависит от вариантов использования и вы можете получить очень многого от удаляющего кодирования на основании требований вашего хранения данных.

{Прим. пер.: Ситуация с требованиями к ресурсам ЦПУ со стороны удаляющего кодирования стремительно меняется. Перечислим некоторые технологии решающие эту проблему:

• SHEC, Shingled Erasure Code (Черепичное удаляющее кодирование, см. обзор ниже , а также переводы рабочих материалов и статьи авторов метода) позволяет применять вычисления к частям сохраняемых объектов, что в разы снижает накладные расходы на вычисления при сохранении уровня эффективности использования пространства на тех же значениях, что и при оригинальном удаляющем кодировании.

• Lazy Means Smart (Интеллектуальные средства задержки, см. переводы рабочих материалов) позволяет снижать в разы нагрузку на пропускную способность сети и вычисления за счёт группирования дисковых операций.

• Аппаратная поддержка EC в ConnectX-4 анонсированная 02 февраля 2016 позволит практически полностью решить проблему загрузки ЦПУ удаляющим кодированием подробнее ...

}

Ceph предоставляет нам параметры выбора встраиваемого модуля (плагина) удаляющего кодирования при создании профиля вашего удаляющего кодирования. {Прим. пер.: вы легко можете создать свой собственный встраиваемый модуль.} Можно создать множество профилей удаляющего кодирования, причём вкаждом случае можно использовать различные встраиваемые модули. Для удаляющего кодирования Ceph поддерживает следующие модули:

Удаляющее кодирование реализуется посредством создания пула Ceph с типом erasure. Этот базируется на профиле удаляющего кодирования, который определяет характеристики удаляющего кодирования. Вначале мы создадим профиль удаляющего кодирования, а затем, на основании этого профиля, мы создадим пул удаляющего кодирования.

Как и удаляющее кодирование, функциональность многоуровневого кэширования (cache tiering) также была введена в Ceph в редакции Firefly. Уровни кэша снабжают клиентов Ceph лучшей производительностью ввода/ вывода для подмножеств ваших данных, сохраняемых на уровне кэша. Многоуровневое кэширование создаёт пул поверх самых быстрых дисков, обычно SSD. Такой кэширующий пул должен быть размещён перед обычным пулом, с реплиукациями или удаляющим кодированием, таким образом, чтобы все операции клиентского ввода/ вывода вначале обрабатывались бы кэширующим пулом; позже эти данные сбрасываются в существующие пулы данных. Клиенты обладают высокой производительностью своего кэширующего пула, а их данные прозрачно записываются в обычные пулы. Следующая схема иллюстрирует многоуровненвое кэширование Ceph:

Уровень кэша строится поверх дорогостоящих, самых быстрых SSD/ NVMe, таким образом он снабжает клиентов наилучшей производительностью ввода/ вывода. Уровень кэша имеет в основе уровень хранения, который выполнен на HDD с типом репликаций или удаляющего кодирования. Все запросы ввода/ вывода клиентов приходят на уровень кэширования и получают самый быстрый отклик вне зависимости будет это read или write; самый быстрый уровень кэша обслуживает ваш запрос клиента. На основе ваших политик, которые мы создали для уровня кэша, он сбрасывает все свои данные на лежащий в его основе уровень хранения, так что он может кэшировать новые запросы от клиентов. Вся миграция данных между уровнями кэша и хранения происходит автоматически и является прозрачной для клиентов. Агент многоуровневого кэширования обрабатывает миграцию данных между уровнем кэша и уровнем хранения. Администраторы имеют возможность настраивать то как такая миграция осуществляется. Существует два основных сценария.

Когда многоуровневое кэширование настроено на режим writeback (отложенной записи), клиенты Ceph записывают свои данные в имеющийся пул уровня кэша, то есть, в самый быстрый пул и, следовательно, получают подтверждение моментально. Основываясь на политике сброса/ выселения, которую вы установили для вашего уровня кэша, данные мигрируют с уровня кэша на уровень хранения и в конечном счёте удаляются со своего уровня кэширования агентом многоуровневого кэширования. В процессе операции клиента read данные вначале пересылаются с уровня хранения на уровень кэширования агентом многоуровневого кэширования а затем предоставляются клиентам. Данные сохраняются в своём уровне кэширования пока они не становятся неактивыми или неиспользуемыми (cold). Уровень кэширования с режимом writeback идеален для изменяемых данных, таких как редактирование фото и видео, транзакционных данных и тому подобного. Режим writeback идеален для изменяемых данных.

Когда многоуровневое кэширование настроено в режиме read-only, оно работает только для клиентских операций read. Операции write не обслуживаются в этом режиме и они сохраняются на уровне хранения. Когда клиент выполняет операцию read, агент многоуровневого кэширования копирует запрашиваемые данные с уровня хранения на свой уровень кэширования. Основываясь на политике которую вы настроили для своего уровня кэширования, просроченные объекты удаляются с уровня кэширования. Такой подход идеален для множества клиентов с потребностями чтения больших объёмов аналогичных данных, например, содержимого социальных медиа. Неизменяемые данные являются хорошими претендентами для уровня кэширования доступного только для чтения.

Для получения наилучших результатов функциональности многоуровневого кэширования Ceph вамследует применять более быстрые диски, такие как SSD и делать быстрый кэширующий пул поверх медленного/ обычного пула выполненного на шпиндельных дисках. В Главе 7. Ceph под колпаком мы рассматривали процесс создания пулов на специфических OSD путём модификации карты CRUSH. Чтобы собрать уровень кэшав вашей среде вам вначале необходимо изменить вашу карту CRUSH и создать набор правил для своих дисков SSD. Поскольку мы уже обсуждали это ранее, мы воспользуемся тем же набором правил для SSD, который базируется на osd.0, osd.3 и osd.6. Поскольку это тестовая сборка, нам не нужно иметь настоящие SSD, мы предположим, что OSD 0, 3 и 6 являются SSD и создадим пул кэша поверх них, как показано на следующей схеме:

Давайте проверим нашу компоновку CRUSH применив команду ceph osd crush rule ls, как показано на следующем снимке экрана. У нас уже есть правила CRUSH SSD пула, которые мы создали в Главе 7. Ceph под колпаком. Вы можете получить дополнительную информацию выполнив команду ceph osd crush rule dump ssd-pool:

	[root@ceph-node1 ~]# ceph osd crush rule ls 
	[ 
	    "replicated_ruleset", 
	    "ssd-pool", 
	    "sata-pool", 
	    "EC-pool" 
	]
	[rootgceph-node1 ~]# 
	   

В этом рецепте мы создадим пул, cache-pool EC-pool

writeback EC-pool

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

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