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

Обзор производительности Ceph

Общий анализ производительности Ceph - уровень аппаратных средств

Настройка производительности Ceph - уровень программных средств

Кодирование удаления Ceph

Создание уровне кэша Ceph

Эталонное тестирование Ceph с применением RADOS bench

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

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

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

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

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

Другим преимуществом Ceph является то,что она поддерживает разнородное оборудование, т.е. Ceph может работать на кластере с аппаратурой от множества производителей. Пользователям разрешается смешивать торговые марки при создании своей инфраструктуры Ceph. Например, при покупке аппаратуры для Ceph, пользователи могут смешивать технические средства от различных производителей, таких как HP, Dell, IBM, Fujitsu, Super Micro и даже не совсем стандартное оборудование. Таким образом клиенты могут достичь огромной экономии денежных средств, получить необходимое оборудование, полный контроль и права принятия решений. {Прим.пер.: не стоит сбрасывать со счетов проблемы технического обслуживания и сопровождения системы; в крупномасштабной системе выход оборудования из строя и контакты с производителем по проблемам его замены штатная ситуация; вам стоит заранее оценить разницу в свои затратах времени и средств на контакты с одним поставщиком/ производителем и множеством таковых }.

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

При этом следует иметь в виду, что выбор аппаратных средств полностью зависит от рабочей нагрузки, которую вы собираетесь разместить в вашем кластере, среды и всей функциональности, которую вы будете использовать. В данном разделе мы изучим некоторые общие правила при выборе оборудования для вашего кластера Ceph. {Прим.пер.: Дополнительную информацию по рекомендациям выбора аппаратуры вы можете получить на странице http://www.mdl.ru/Solutions/Put.htm?Nme=CephHW , являющейся авторским переводом Hardware Recommendations с официального сайта Ceph Documentation. }

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

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

Демоны MDS (сервера метаданных) еще более требовательны к ресурсам процессоров по сравнению с MON и OSD. они должны динамически перераспределять свою нагрузку, что сильно загружает центральные процессоры; вы должны рассмотреть возможность применения четырех-ядерных процессоров для Ceph MDS.

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

Все узлы кластера должны иметь двойные интерфейсы сети для двух различных сетей, а именно: для сети кластера и для сети клиентов. Для кластера среднего размера, в несколько сотен терабайт, должно быть достаточно сетевых соединений 1G. Однако, если размер вашего кластера большой и он обслуживает множество клиентов, вы должны подумать об использовании сети с пропускной способностью 10G или более. Во время восстановления сеть играет важную роль. Если у вас есть хорошее сетевое соединение 10G или более, ваш кластер будет восстанавливаться быстрее, в противном случае это может потребовать некоторого времени. Следовательно, с точки зрения производительности, 10G или более дублированная сеть будет хорошим выбором. Хорошо спроектированный кластер использует две физически разделенные сети, одну для сети кластера (внутренняя сеть), и вторую для сети клиентов (внешняя сеть); обе эти сети должны быть физически разделены на сетевом коммутаторе; настройка точки доступности требует резервированной двойной сети, как это показано на рисунке ниже:

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

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

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

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

Выбор файловой системы также является одним из аспектов производительности кластера. Btrfs является более современной файловой системой, способной записывать объект одной операцией по сравнению с XFS и EXT4, которым необходимо два этапа для записи объекта. Btrfs является файловой системой с копированием при записи (copy-on-write), т.е. при записи объекта в журнал она может одновременно записывать тот же объект в раздел данных, обеспечивая значительное увеличение производительности {Прим. пер.: при изменении новых данных эти данные вначале копируются в новую область }. Тем не менее, в момент написания данного руководства Btrfs не была готова к промышленному применению. Вы можете столкнуться с проблемами несогласованности данных в Btrfs.

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

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

Большинство установок настройки всего кластера определены в файле настройки кластера Ceph. Если вы не изменяли имя вашего кластера и местоположения файла настройки для вашего кластера, то именем по умолчанию будет ceph.conf , а путем к нему /etc/ceph/ceph.conf . Этот файл настройки имеет общий раздел а также несколько разделов для каждого типа служб. Всякий раз при запуске каждого типа служб Ceph, т.е. MON (мониторов), OSD (устройств хранения объектов) и MDS (серверов метаданных), они считывают настройки, определенные в общем разделе, а также в специфичном для них разделе.

Общим разделом является раздел, определенный ; все установки данного раздела воздействуют на все демоны кластера Ceph. Здесь определяются все установки, которые должны быть применены ко всему кластеру. Ниже приводится пример установок в данном разделе:

Public network = 192.168.0.0/24

Установки указанные в разделе применяются ко всем демонам ceph-mon в данном кластере Ceph. Установки, определенные в данном разделе, переопределяют установки, определенные в разделе . Ниже приводится пример установок в данном разделе:

Mon initial members = ceph-mon1

Установки указанные в разделе применяются ко всем демонам ceph-osd в данном кластере Ceph. Установки, определенные в данном разделе, переопределяют установки, определенные в разделе . Ниже приводится пример установок в данном разделе:

Osd mkfs type = xfs

Установки указанные в разделе применяются ко всем демонам ceph-mds в данном кластере Ceph. Установки, определенные в данном разделе, переопределяют установки, определенные в разделе . Ниже приводится пример установок в данном разделе:

Mds cache size = 250000

Установки указанные в разделе применяются ко всем клиентам Ceph. Установки, определенные в данном разделе, переопределяют установки, определенные в разделе . Ниже приводится пример установок в данном разделе:

Rbd cache = true

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

Настоятельно рекомендуется, чтобы вы использовали две физически раздельные сети для своего кластера Ceph. Каждая из этих сетей имеет свое собственное предназначение. В соответствии с принятой в Ceph терминологии эти сети называются общедоступной (public) сетью и сетью кластера (cluster):

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

Public network = {public network / netmask}

Public network = 192.168.100.0/24

Сеть кластера также называется внутренней сетью, которая является выделенной сетью для всех внутренних операций кластера между узлами Ceph. С точки зрения производительности эта сеть должна иметь приличную производительность в 10Gb или 40Gb, поскольку эта сеть отвечает за операции кластера с высокой пропускной способностью, например, репликацию данных, восстановление, ребалансировку, а также за проверку тактовых импульсов. Вы можете определить сеть кластера следующим образом:

Cluster network = {cluster network / netmask}

Пример такого определения приводится ниже:

Cluster network = 192.168.1.0/24

Если этот параметр находится на своем месте и кластер Ceph запущен, он устанавливает определение максимального числа открытых файлов на уровне операционной системы. Это помогает демону OSD (устройства хранения объектов) не выходить за пределы дескрипторов файлов. Значением по умолчанию является 0 ; вы можете установить его в значение любого 64-разрядного целого.

Давайте взглянем на пример:

Max open files = 131072

Параметры, перечисленные в данном разделе, должны быть определены в секции файла настройка вашего кластера Ceph.

Расширенные атрибуты : Они также известны как XATTR, которые очень полезны для хранения метаданных файлов. Некоторые файловые системы предоставляют ограниченное множество байт для хранения XATTR. В некоторых случаях файловой системе могут помочь хорошо определенные расширенные атрибуты. Параметры XATTR необходимо использовать с файловой системой EXT4 для достижения хорошей производительности. Ниже приводится пример:

Filestore xattr use omap = true

Интервал синхронизации файловой системы : Чтобы создать непротиворечивую точку завершения, файловой системе необходимо блокировать операции записи, а также выполнять syncfs, которая синхронизацию данных журнала с разделом данных, и, таким образом, освобождает журнал. Более частое выполнение операций синхронизации уменьшает количество данных, хранимых в журнале. В таком случае журнал становится недозагруженным. Настройка более редких синхронизаций позволяет файловой системе лучше объединять малые записи и мы можем получить увеличение производительности. Следующие параметры определяют минимальный и максимальный промежутки времени между двумя синхронизациями:

Filestore min sync interval = 10 filestore max sync interval = 15

Очередь файловой системы : Следующие установки предоставляют пределы размеров очереди файловой системы. Эти установки могут иметь минимальное воздействие на производительность:

• Filestore queue max ops : Это максимальное число операций, которое файловая система может принять перед блокированием новых операций для присоединения их в очередь. Давайте взглянем на следующий пример:

  Filestore queue max ops = 25000

  Filestore queue max bytes : Это максимальное число байт операций. Ниже приводится пример:

  Filestore queue max bytes = 10485760

  Filestore queue committing max ops : Это максимальное значение операций, которое может фиксировать (commit) файловая система. Пример для этого следующий:

  Filestore queue committing max ops = 5000

  Filestore queue committing max bytes : Это максимальное количество байт, которое может фиксировать файловая система. Взгляните на следующий пример:

  Filestore queue committing max bytes = 10485760000

  Filestore op threads : Это число потоков (thread) операций файловой системы, которые могут выполняться одновременно. Ниже приводится пример:

  Filestore op threads = 32

Настройка журнала OSD : Демоны OSD Ceph поддерживают следующие настройки журналов:

• Journal max write bytes : Это максимальное количество байт, которое журнал может записать за один раз. Далее следует пример:

  Journal max write bytes = 1073714824

  Journal max write entries : Это максимальное значение элементов, которое журнал может записать за один раз. Вот пример:

  Journal max write entries = 10000

  Journal queue max ops : Это максимальное значение операций, разрешенных в очереди журнала в определенный момент времени. Его пример такой:

  Journal queue max ops = 50000

  Journal queue max bytes : Это максимальное число байт, разрешенное очереди журнала в определенный момент времени. Взгляните на следующий пример:

  Journal queue max bytes = 10485760000

Настройка конфигурации OSD : Демоны OSD Ceph поддерживают следующие установки конфигурации OSD:

• Osd max write size : Это максимальный размер в мегабайтах, которое OSD может записывать за один раз. Ниже приводится пример:

  Osd max write size = 512

  Osd client message size cap : Это максимальный размер данных клиента в мегабайтах, который допустим в оперативной памяти. Пример такой:

  Osd client message size cap = 2048

  Osd deep scrub stride : Это размер в байтах, который читается OSD при выполнении глубокой очистки. Взгляните на следующий пример:

  Osd deep scrub stride = 131072

  Osd op threads : Это число потоков операций, используемое демоном OSD Ceph. Например:

  Osd op threads = 16

  Osd disk threads : Это число дисковых потоков для выполнения интенсивных OSD операций, подобных восстановлению (recovery) и очистке (scrubbing). Ниже приводится пример:

  Osd disk threads = 4

  Osd map cache size : Это размер кэша карты OSD в мегабайтах. Ниже приводится пример:

  Osd map cache size = 1024

  Osd map cache bl size : Это размер хранимого в памяти кэша карты OSD в мегабайтах. Пример такой:

  Osd map cache bl size = 128

  Osd mount options xfs : Он позволяет нам поддерживать опции монтирования файловой системы xfs. Во время монтирования OSD он произведет монтирование с предложенными параметрами монтирования. Взглянем на следующий пример:

  Osd mount options xfs = "rw,noatime,inode64,logbsize=256k,delaylog,allocsize=4M"

Настройка восстановления OSD : Эти установки должны быть использованы когда вы предпочитаете производительность над восстановлением или наоборот. Если ваш кластер Ceph неисправен и находится в состоянии восстановления, вы можете не получить его обычной производительности, поскольку OSD будут заняты восстановлением. Если вы все- таки предпочитаете производительность над восстановлением, вы можете уменьшить приоритет восстановления, чтобы OSD были меньше заняты восстановлением. Вы также можете установить эти значения, если вы хотите быстрого восстановления вашего кластера, чтобы помочь OSD выполнять восстановление быстрее.

• Osd recovery op priority : Это установка приоритета доя операций восстановления. Чем ниже значение тем выше приоритет восстановления. Высшие значения приоритета восстановления могут вызвать проблемы деградации производительности пока не будет завершено восстановление. Ниже приведен пример:

  Osd recovery op priority = 4

  Osd recovery max active : Это максимальное число активных запросов восстановления. Чем выше значение, тем быстрее восстановление, что может воздействовать на общую производительность кластера до завершения восстановления. Ниже приведен пример:

  Osd recovery max active = 10

  Osd max backfills : Это максимальное количество операций заполнения разрешенных OSD. Чем выше значение, тем быстрее восстановление, что может воздействовать на общую производительность кластера до завершения восстановления. Ниже приведен пример:

  Osd max backfills = 4

Реализация пространства пользователя блочных устройств Ceph не может применять преимущества кэширования страниц Linux, поэтому в версии Ceph 0.46 был введен новый механизм кэширования в оперативной памяти, который называется кэшированием RDB (RADOS block device, блочных устройств безотказного автономного распределенного хранилища объектов). По умолчанию Ceph не разрешает кэширование RBD; чтобы разрешить эту возможность вам следует обновить раздел в вашем файле настройки кластера Ceph на следующие параметры:

Rbd cache = true : Это разрешает кэширование RBD.

Rbd cache size = 268435456 : Это задает размер кэша RBD в байтах.

Rbd cache max dirty = 134217728 : Это предел измененных данных в байтах; после такого описания предела данные будут сбрасываться на сервер хранения. Если это значение установлено в 0 , Ceph использует метод сквозного кэширования (write-through caching). Если это параметр не используется, механизмом кэширования по умолчанию является сквозное кэширование.

Rbd cache max dirty age = 5 : Это число секунд, на протяжении которых измененные данные будут храниться в кэше до того, как они будут скинуты на сервер хранения.

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

Kernel pid max : Это параметр ядра Linux, который отвечает за максимальное число идентификаторов потоков и процессов. Основная часть ядер Linux имеет относительно небольшое значение kernel.pid_max . Настройка этого параметра с бОльшим значением на узлах Ceph предоставляет в распоряжение бОльшее число OSD (устройств хранения объектов), например, OSD > 20 может помочь в порождении бОльшего числа потоков для более быстрого восстановления и ребалансировки. Для применения этого параметра выполните следующую команду с правами пользователя root:

# echo 4194303 > /proc/sys/kernel/pid_max

Кадры Jumbo : Кадры Ethernet, которые имеют длину более 1500 байт называются кадрами jumbo. Разрешение кадров jumbo для всех ваших сетевых интерфейсов вашего узла кластера Ceph должно обеспечить лучшую пропускную способность сети и общее улучшение производительности. Кадры jumbo настраиваются на уровне операционной системы, однако сетевой интерфейс и базовый коммутатор сети должны поддерживать кадры jumbo. Чтобы разрешить кадры jumbo вы должны настроить ваши интерфейсы стороны коммутатора на их прием, а затем приступить к настройке на уровне операционной системы. Например, со стороны операционной системы для разрешения кадров jumbo на интерфейсе eth0 выполните следующую команду:

# ifconfig eth0 mtu 9000

9000 байт полезной информации является пределом сетевого интерфейса MTU; чтобы изменения носили необратимый характер, вам также следует обновить ваш файл настройки сетевого интерфейса, /etc/sysconfig/network-script/ifcfg-eth0, to MTU=9000 .

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

# cat /sys/block/vda/queue/read_ahead_kb

Чтобы установить для read_ahead бОльшее значение воспользуйтесь командой:

# echo "8192">/sys/block/vda/queue/read_ahead_kb

Обычно установка пользователем read_ahead используется клиентами Ceph, которые используют RBD. Вы должны изменить read_ahead для всех RBD, помеченных для данного хоста; также убедитесь, что вы используете правильное имя пути устройства.

Технологии сохранения данных и их резервирования существовали в течение многих десятилетий. Один из самых популярных методов для предоставления надежности данным является репликация . Метод репликации включает в себя хранение одних и тех же данных в нескольких экземплярах в разных физических местах. Этот метод оказывается хорошим, когда речь заходит о производительности и надежности данных, однако он увеличивает общую стоимость системы хранения. Совокупная стоимость владения (TOC) с применением метода репликаций является достаточно дорогостоящим способом.

Этот метод требует в два раза больше пространства хранения для обеспечения избыточности. Например, если вы планируете решение для хранения 1PB данных с фактором репликаций один. вам потребуется 2PB физического пространства хранения для запоминания 1PB реплицируемых данных. Таким образом, стоимость за гигабайт реплицируемых данных системы хранения значительно увеличивается. Вы можете игнорировать стоимость хранения в небольших кластерах хранения, однако представьте как ударит стоимость, если вы строите гипер- масштабируемое решение хранения данных на основе реплицируемых серверов хранения.

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

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

N = k + m

Следующие пункты объясняют эти термины и их назначение:

k : Это число порций, подлежащих разделению, также называемое частями данных (data chunks).

m : Это дополнительный код, добавляемый к данным для обеспечения их защищенности, также называемый частью кодирования (coding chunk). Для более легкого восприятия вы можете рассматривать его как уровень надежности.

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

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

Восстановление : Во время восстановления Ceph нам требуются любыеk порций из имеющихся n порций для восстановления данных

Уровень надежности : При кодировании затирания Ceph может допускать потерю до m порций

Порядок кодирования (r) : Может быть вычислен по формуле r = k/n , где r < 1

Необходимое пространство хранения : Вычисляется как 1/r

Например, рассмотрим пул Ceph с пятью OSD, который создан с применением правила кодирования затирания (3,2). Каждый объект, сохраняемый в этом пуле, будет разделен на следующие порции данных и кода:

N = k + m по аналогии, 5 = 3 + 2 следовательно n = 5 , k = 3 и m = 2

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

Порядок кодирования (r) = 3 / 5 = 0.6

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

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

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

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

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

Кодирование затирания реализуется путем создания пулов Ceph с типом затирания; каждый такой пул основывается на файле параметров кодирования затирания, который определяет характеристики кодирования затирания. Сейчас мы создадим файл параметров кодирования затирания и пул кодирования затирания на его основе:

Обсуждающаяся в данном разделе команда создаст файл параметров кодирования затирания с именем EC-profile с характеристиками k=3 и m=2 , которые, соответственно, являются числом порций данных и кодирования. Таким образом, каждый подлежащий сохранению объект будет разделен на 3 ( k ) порции данных и к ним будут добавлены 2 ( m ) дополнительные порции кодирования, имея результатом 5 ( k+m ) порций. Наконец,эти 5 ( k+m ) порций распределяются по различным OSD зон отказа.

• Создайте файл параметров кодирования затирания:

  # ceph osd erasure-code-profile set EC-profile rulesetfailure-domain=osd k=3 m=2

  Составьте список файла параметров:

  # ceph osd erasure-code-profile ls

  # ceph osd erasure-code-profile get EC-profile # ceph osd erasure-code-profile set EC-profile ruleset-failure-domain=osd k=3 m=2 # ceph osd erasure-code-profile ls EC-profile # ceph osd erasure-code-profile get EC-profile directory=/usr/lib64/ceph/erasure-code k=3 m=2 plugin=jerasure ruleset-fai1ure-domain=osd technique=reed_sol_van #

Создайте пулс типом затирания, который будет базироваться на файле параметров кодирования затирания, который вы создали на 1 шаге:

# ceph osd pool create EC-pool 16 16 erasure EC-profile

Проверьте состояние вашего вновь созданного пула; вы должны обнаружить, что размер вашего пула 5 ( k+m ), т.е. размер затирания 5. Следовательно, данные будут записываться в пять различных OSD:

# ceph osd dump | grep -i EC-pool # ceph osd pool create EC-pool 16 16 erasure EC-profile pool "EC-pool" created # # ceph osd dump | grep -i EC-pool pool 15 "EC-pool" erasure size 5 min_size 1 crush_ruleset 3 object_hash rjenkins pg_num 16 pgp_num 16 last_change 975 owner 0 flags hashpspool stripe_width 4128 #

Теперь у нас есть новый пул Ceph, который имеет тип затирания. Теперь мы должны поместить некоторые данные в этот пул путем создания файл примера с некоторым случайным содержимым и поместите его во вновь созданный пул кодирования затирания Ceph:

# echo "Mona is now testing Ceph Erasure Coding" > filel.txt # cat filel.txt Mona is now testing Ceph Erasure Coding # rados -p EC-pool ls # rados put -p EC-pool object1 file1.txt # rados -p EC-pool ls object1 #

Проверьте карту OSD для EC-pool и object1. Вывод этой команды сделает детали понятными отображая идентификаторы OSD, в которых хранятся порции объектов. Как объяснялось на 1 шаге, object1 разделяется на 3 (m) порции данных и дополняется 2 (k) кодируемыми порциями; следовательно, совместно пять порций были сохранены в различных OSD по всему кластеру Ceph. В данной демонстрации object1 был сохранен в пяти OSD, а именно osd.7, osd.6, osd.4, osd.8 и osd.5.

# ceph osd map EC-pool object1 osdmap e976 pool "EC-pool" (15) object "object1" -> pg 15.bac5debc (15.c) -> up (, p7) acting (, p7) #

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

Как упоминалось на предыдущем шаге, некоторыми OSD для пула затирания являются osd.4 и osd.5; теперь мы протестируем надежность пула затирания разрушением этих OSD одного за другим.

Выведите из строя osd.4 и проверьте карту OSD для EC-pool и object1. Вы должны заметить, что osd.4 замещается случайным числом 2147483647 , что означает, что osd.4 больше не доступно для данного пула:

# ssh ceph-node2 service ceph stop osd.5 # ceph osd map EC-pool object1 # ssh ceph-node2 service ceph stop osd.4 === osd.4 === Stopping Ceph osd.4 on ceph-node2...kill 4542...done # ceph osd map EC-pool object1 osdmap e980 poo1 ’EC-pool" (15) object "object1" -> pg 15.bac5debc (15.c) -> up (, p7) acting (, p7) #

Аналогично, выведите из строя еще одно OSD, т.е. osd.5, и обратите внимание на карту OSD для EC-pool и object1. Вы должны заметить, что osd.5 замещается случайным числом 2147483647 , что означает, что osd.5 больше не доступен для этого пула:

# ssh ceph-node2 service ceph stop osd.5 === osd.5 === Stopping Ceph osd.5 on ceph-node2...kill 5437...done # # # ceph osd map EC-pool object1 osdmap e982 pool "EC-pool" (15) object "object1" -> pg 15.bac5debc (15.c) -> up (, p7; acting (, p7) #

Теперь пул Ceph работает на трех OSD, что является минимумом, необходимым для данной установки пула затирания. Как уже обсуждалось ранее, для EC-pool будет необходимо любые три порции из пяти для для обслуживания данных. Теперь у нас осталось только три порции, а именно, osd.7, osd.6 и osd.8, а мы все еще имеем доступные данные.

# rados -p EC-pool ls object1 # rados get -p EC-pool object1 /tmp/file1 # cat /tmp/file1 Mona is not testing Ceph Erasure Coding

Таким образом, кодирование затирания предоставляет пулам Ceph надежность и, в то же время, меньшее пространство хранения требуется для обеспечения надежности.

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

В последних двух шагах, обсуждавшихся ранее, мы преднамеренно вывели из строя osd.4 и osd.5. Через некоторое время запускает Ceph восстановление и обновление потерянных порций на различные OSD. Когда операции восстановления завершаются, вы должны проверить для EC-pool и object1; вы будете удивлены увидеть новые идентификаторы, такие как osd.1, osd.2 и osd.3 и, таким образом, пул затирания становится жизнеспособным без вмешательства администратора.

# ceph osd stat osdmap e1025: 9 osds: 7 up, 7 in # # ceph osd map EC-pool object1 osdmap e1025 pool "EC-pool" (15) object "object1" -> pg 15.bac5debc (15.c) -> up (, p7) acting (, P7) #

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

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

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

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

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

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

Уровень кэша реализуется на самых быстрых физических дисках, обычно SSD, что дает быстрый уровень кэша поверх более медленных традиционных пулов, выполненных на шпиндельных дисках. В данном разделе мы создадим два отдельных пула, пул кэша и обычный пул, которые будут соответственно использоваться как уровень кэширования и уровень хранения.

В Главе 7. Эксплуатация и обслуживание Ceph мы обсуждали процесс создания пулов Ceph поверх определенных OSD (устройств хранения объектов) путем изменения карт CRUSH (Управляемых масштабируемым хешированием репликаций, Controlled Replication Under Scalable Hashing). Аналогично мы создадим пул кэша который будет базироваться на osd.0, osd.3 и osd.6. Поскольку у нас нет настоящих SSD для такой установки, мы сделаем предположение, что эти OSD являются SSD и создадим пул кэширования поверх них. Ниже приводится инструкция для создания пула кэширования на osd.0, osd.3 и osd.6.

Получите текущую катру CRUSH и декомпилируйте ее:

# ceph osd getcrushmap -o crushmapdump # crushtool -d crushmapdump -o crushmapdump-decompiled

Измените файл декомпилированной карты CRUSH и добавьте следующий раздел после раздела root default :

# vim crushmapdump-decompiled root cache { id -5 alg straw hash 0 item osd.0 weight 0.010 item osd.3 weight 0.010 item osd.6 weight 0.010 }

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

Rule cache-pool { ruleset 4 type replicated min_size 1 max_size 10 step take cache step chooseleaf firstn 0 type osd step emit }

Скомпилируйте и внедрите новую карту CRUSH в кластер Ceph:

# crushtool -c crushmapdump-decompiled -o crushmapdump-compiled # ceph osd setcrushmap -i crushmapdump-compiled

Поскольку к кластеру Ceph была применена новая карта CRUSH, вам следует проверить состояние OSD, чтобы увидеть новое расположение OSD. Вы найдете новый сегмент root cache:

# ceph osd tree # ceph osd tree # id weight type name up/down reweight -5 0.02998 root cache 0 0.009995 osd.0 up 1 3 0.009995 osd.3 up 1 6 0.009995 osd.6 up 1 -1 0.09 root default -2 0.03 host ceph-node1 1 0.009995 osd.1 up 1 2 0.009995 osd.2 up 1 0 0.009995 osd.O up 1 -3 0.03 host ceph-node2 3 0.009995 osd.3 up 1 5 0.009995 osd.5 up 1 4 0.009995 osd.4 up 1 -4 0.03 host ceph-node3 6 0.009995 osd.6 up 1 7 0.009995 osd.7 up 1 8 0.009995 osd.8 up 1 #

Создайте новый пул и установите значение crush_ruleset равным 4 , следовательно новый пул будет создаваться на дисках SSD:

# ceph osd pool create cache-pool 32 32 # ceph osd pool set cache-pool crush_ruleset 4 # ceph osd pool set cache-pool crush_ruleset 4 set pool 16 crush_ruleset to 4 # ceph osd dump | grep -i cache-pool pool 16 "cache-pool" replicated size 3 min_size 1 crush_ruleset 4 object_hash rjenkins pg_num 32 pgp_num 32 last_change 1142 owner 0 flags hashpspool stripe_width 0 #

Убедитесь что пул создан правильно, т.е. он должен всегда сохранять все свои объекты на osd.0, osd.3 и osd.6:

• Выведите перечень cache-pool для содержания; поскольку это новый пул, он не должен иметь никакого содержания:

  # rados -p cache-pool ls

  Добавьте произвольный объект в cache-pool чтобы убедиться, что он сохраняет объекты в правильных OSD:

  # rados -p cache-pool put object1 /etc/hosts

  # rados -p cache-pool ls

  Проверьте карту OSD для cache-pool и object1 . Если вы настроили катру CRUSH правильно, object1 должен сохраняться в osd.0, osd.3 и osd.6, поскольку его размер репликации равен 3:

  # ceph osd map cache-pool object1

  Удалите объект:

  # rados -p cache-pool rm object1 # rados -p cache-pool ls # rados -p cache-pool put object1 /etc/hosts # rados -p cache-pool ls object1 # ceph osd map cache-pool object1 osdmap e1143 pool "cache-pool" (16) object "object1" -> pg 16.bac5debc (16.1c) -> up (, p3) acting (, p3) #

В предыдущем разделе мы создали пул на базе SSD; теперь мы воспользуемся этим пулом как многоуровневым кэшированием для пула с кодированием затирания с именем EC-pool , который мы создали раньше в этой главе.

Следующие инструкции дадут вам руководство по созданию многоуровневого кэша с режимом обратной записи и установкой наложения на EC-pool :

Установите многоуровневого кэширования чтобы связать пулы хранения с пулами кэша. Синтаксис этой команды: ceph osd tier add

# ceph osd tier add EC-pool cache-pool

Установите режим кэширования в значение writeback или read-only. В данной демонстрации мы используем writeback и синтаксис для этого будет таким ceph osd tier cachemode writeback :

# ceph osd tier cache-mode cache-pool writeback

Чтобы направлять все запросы клиентов из стандартного пула в пул кэширования, установите наложение (overlay) и синтаксис для этого будет следующим ceph osd tier set-overlay :

# ceph osd tier set-overlay EC-pool cache-pool # ceph osd tier add EC-pool cache-pool pool "cache-pool" is now (or already was) a tier of "EC-pool" # ceph osd tier cache-mode cache-pool writeback set cache-mode for pool "cache-pool" to writeback # ceph osd tier set-overlay EC-pool cache-pool overlay for "EC-pool" is now (or already was) "cache-pool" #

При проверке подробностей пула вы отметите, что EC-pool имеет tier , read_tier и write_tier установленными в значение 16 , которое является идентификатором пула для cache-pool .

Аналогично для cache-pool установки будут следующими: tier_of установлен в значение 15 , а cache_mode в значение writeback ; все эти установки подразумевают, что пул кэширования настроен правильно:

# ceph osd dump | egrep -i "EC-pool|cache-pool" # ceph osd dump | egrep -i "EC-pool|cache-pool" pool 15 "EC-pool" erasure size 5 min_size 1 crush_ruleset 3 object_hash rjenkins pg_num 16 pgp_num 16 last_change 1181 owner 0 flags hashpspool tiers 16 read_tier 16 write_tier 16 stripe_width 4128 pool 16 "cache-pool" replicated size 3 min_size 1 crush_ruleset 4 object_hash rjenkins pg_num 32 pg p_num 32 last_change 1181 owner 0 flags hashpspool tier_of 15 cache_mode writeback stripe_width 0 #

Многоуровневое кэширование имеет ряд параметров настройки; вам следует настроить ваше многоуровневое кэширование чтобы установить для него политики. В данном разделе мы настроим политики многоуровневого кэширования:

Включить использование отслеживания попаданий в множество для пула кэширования; многоуровневый кэш производственного уровня использует фильтрации расплываний (bloom):

# ceph osd pool set cache-pool hit_set_type bloom

Сделайте доступным hit_set_count , который является числом попаданий в множество для сохранения в кэшируемом пуле:

# ceph osd pool set cache-pool hit_set_count 1

Сделайте доступным hit_set_period , который является продолжительностью периода попаданий в множество в секундах для кэшируемого пула:

# ceph osd pool set cache-pool hit_set_period 300

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

# ceph osd pool set cache-pool target_max_bytes 1000000 # ceph osd pool set cache-pool hit_set_type bloom set pool 16 hit_set_type to bloom # ceph osd pool set cache-pool hit_set_count 1 set pool 16 hit_set_count to 1 # ceph osd pool set cache-pool hit_set_period 300 set pool 16 hit_set_period to 300 # ceph osd pool set cache-pool targetLjnax_bytes 10000000 set pool 16 target_max_bytes to 10000000 #

Сделайте доступными cache_min_flush_age и cache_min_evict_age , которые являются временем в секундах, по прошествии которого агент многоуровневого кэширования начинает сбрасывать устаревшие объекты из пула кэша в уровень хранения:

# ceph osd pool set cache-pool target_max_objects 10000

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

# ceph osd pool set cache-pool cache_min_flush_age 300 # ceph osd pool set cache-pool cache_min_evict_age 300 # ceph osd pool set cache-pool target_max_objects 10000 set pool 16 target_max_objects to 10000 # ceph osd pool set cache-pool cache_min_flush_age 300 set pool 16 cache_min_flush_age to 300 # ceph osd pool set cache-pool cache_min_evict_age 300 set pool 16 cache_min_evict_age to 300 #

Сделайте доступным cache_target_dirty_ratio , который является процентом "запачканных" (модифицированных) объектов пула кэша содежащего по достижению которого агент многоуровневого кэширования начинает сбрасывает их на уровень хранения:

# ceph osd pool set cache-pool cache_target_dirty_ratio .01

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

# ceph osd pool set cache-pool cache_target_full_ratio .02

Создайте временный файл размером в 500МБ, который мы используем для записи в EC-pool , и который в конечном итоге будет записан в cache-pool :

# dd if=/dev/zero of=/tmp/file1 bs=1M count=500

Следующий снимок экрана отображает предыдущие команды в разделе:

# ceph osd pool set cache-pool cache_target_dirty_ratio .01 set pool 16 cache_target_dirty_ratio to .01 # ceph osd pool set cache-pool cache_targetL_full_ratio .02 set pool 16 cache_target_full_ratio to .02 # # dd if=/dev/zero of=/tmp/file1 bs=1M count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 1.66712 s, 314 MB/s #

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

В предыдущем разделе мы создали тестовый файл размером в 500МБ с именем /tmp/file1 ; теперь мы поместим этот файл в EC-pool :

# rados -p EC-pool put object1 /tmp/file1

Поскольку EC-pool кэшируется cache-pool , file1 не должен быть записан в EC-pool в первом состоянии. Он должен быть записан в cache-pool . Просмотрим каждый пул для получения имен объектов. Используйте команду date для отслеживания времени и изменений:

# rados -p EC-pool ls # rados -p cache-pool ls # date # rados -p EC-pool put object1 /tmp/file1 # rados -p EC-pool ls # rados -p cache-pool ls object1 # # date Sun Sep 14 02:14:58 EEST 2014 #

По истечению 300 секунд (мы настроили cache_min_evict_age на 300 секунд), агент многоуровневого кэширования переместит object1 из cache-pool в EC-pool ; object1 будет удален из cache-pool :

# rados -p EC-pool ls # rados -p cache-pool ls # date # date Sun Sep 14 02:27:41 EEST 2014 # rados -p EC-pool ls object1 # rados -p cache-pool Is #

Как объяснялось в предыдущей выдаче, данные перемещаются из cache-pool в EC-pool через определенное время.

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

Синтаксис использования этого инструментария такой: rados bench -p

Допустимыми параметрами для rados bench являются следующие:

P или --pool : Имя пула

: Это продолжительность в секундах работы теста

: Это тип тестирования; он должен быть одним из: запись, последовательное чтение или случайное чтение.

T : Это число одновременных операций; значение по умолчанию 16

No-cleanup : Временные данные, записанные в пул данных RADOS bench не должны очищаться. Эти данные будут использоваться для операций чтения при использовании с последовательных или случайных чтений. По умолчанию применяется очистка.

С применением приведенного выше синтаксиса мв теперь выполним некоторые тесты RADOS bench :

10- секундный тест записи на пуле данных создаст последующий вывод. Важно заметить, что пропускная способность вывода (МБ/с) RADOS bench , которая для нашей установки составляет 13.412 , что является очень низким показателем, поскольку мы имеем виртуальный кластер Ceph. Другие детали, которые мы отслеживаем, это общее число выполненных записей, записанный объем, средняя латентность и т.п. Поскольку мы использовали флаг --no-cleanup , данные записанные RADOS bench не будут удаляться и они будут использованы в операциях последовательного и случайного чтения RADOS bench :

# rados bench -p data 10 write --no-cleanup # rados bench -p data 10 write --no-cleanup Maintaining 16 concurrent writes of 4194304 bytes for up to 10 seconds or 0 objects Object prefix: benchmark_data_ceph-node1_26928 sec Cur ops started finished avg MB/s cur MB/s last lat avg lat 0 16 16 0 0 0 - 0 1 16 16 0 0 0 - 0 2 15 18 3 4.88541 6 2.4189 2.12187 3 16 24 8 9.21183 20 3.31423 2.59351 4 16 25 9 8.04351 4 1.90747 2.51728 5 16 29 13 9.48749 16 5.37976 3.26326 6 16 29 13 8.02065 0 - 3.26326 7 16 33 17 9.07075 8 5.23925 3.3801 8 16 35 19 8.9441 8 3.31397 3.59352 9 15 39 24 10.0899 20 2.52773 3.98084 10 16 40 24 9.12944 0 - 3.98084 11 15 41 26 9.03055 4 4.05948 4.23526 Total time run: 12.227935 Total writes made: 41 Write size: 4194304 Bandwidth (MB/sec): 13.412 Stddev Bandwidth: 7.60183 Max bandwidth (MB/sec): 20 Min bandwidth (MB/sec): 0 Average Latency: 4.61251 Stddev Latency: 2.54733 Max latency: 11.7108 Min latency: 1.17417 #

Выполните тест последовательного чтения эталонного тестирования пула данных:

# rados bench -p data 10 seq # rados bench -p data 10 seq sec Cur ops started finished avg MB/s cur MB/s last lat avg lat 0 12 12 0 0 0 - 0 1 15 21 6 23.7445 24 0.365323 0.517866 2 15 25 10 19.889 16 1.91165 0.947636 3 16 31 15 19.9216 20 0.832548 1.1234 4 16 36 20 19.8804 20 3.81842 1.623 5 16 41 25 19.9027 20 2.4696 1.94785 6 15 41 26 17.2372 4 1.4177 1.92746 Total time run: 6.807863 Total reads made: 41 Read size: 4194304 Bandwidth (MB/sec): 24.090 Average Latency: 2.48104 Max latency: 6.38046 Min latency: 0.365323 #

Выполните тест случайного чтения эталонного тестирования пула данных:

# rados bench -p data 10 rand # rados bench -p data 10 rand sec Cur ops started finished avg MB/s cur MB/s last lat avg lat 0 12 12 0 0 0 - 0 1 15 22 7 27.8596 28 0.300826 0.468331 2 16 27 11 21.8062 16 0.237253 0.635548 3 16 34 18 23.6913 28 1.52991 1.18525 4 15 36 21 20.7954 12 3.79887 1.53081 5 16 41 25 19.784 16 2.73283 1.91815 6 15 48 33 21.6187 32 1.68679 2.20121 7 16 58 42 23.6049 36 1.84635 2.31201 8 16 63 47 23.0549 20 4.173 2.33454 9 16 69 53 23.1574 24 2.31493 2.294 10 16 73 57 22.4116 16 2.45812 2.32087 11 4 73 69 24.7012 48 3.27041 2.3137 Total time run: 11.206381 Total reads made: 73 Read size: 4194304 Bandwidth (MB/sec): 26.057 Average Latency: 2.38341 Max latency: 5.19721 Min latency: 0.188254 #

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

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

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

Интересный пост на Хабре, описывающий опыт веб-хостера FirstVDS в его попытках сделать кластер на ceph , и честное описание всех значительной части проблем, которые они хапнули в процессе. Полезное и душеспасительное чтение для всех, кто рассматривает ceph как enterprise-grade решение.
Вкратце, бегло о lessons learned:

* Процесс «выучивания уроков» занял примерно два года, на сегодняшний день. Первая версия была собрана осенью 2014 года.

* Не все x86 сервера «одинаково полезны». Купленные специально под кластер сервера оказались глючными.

Чтобы опробовать новую архитектуру и избавиться от прежних недостатков, собрали тестовый стенд. И тут выяснилось интересное - специально купленные для сборки первой версии серверы оказались «палёными». Системная шина всех серверов работала медленно. В результате, все устройства, связанные с северным и южным мостами - карты IB, подключенные по PCI-E, диски, память - также работали медленно. Это объясняло большую часть проблем, с которыми мы столкнулись. В качестве пробы взяли несколько свободных нод, на которых обычно запускаем клиентские VDS. По тех. характеристикам они почти ничем не отличались. Собрали и запустили кластер на этих машинах, стали прогонять тесты. Всё летает! … купили новые серверы на базе Xeon 2630 …

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

Кластер справлялся с задачами - при выходе из строя дисков или нод целиком, он продолжал функционировать. Однако, каждая перебалансировка превращала ситуацию в критическую. При добавлении нового диска сглаживали пик нагрузки, используя веса. Вес отвечает за степень использования конкретного физического носителя. Устанавливаем новый диск, ставим вес 0 - диск не используется. После этого увеличиваем вес постепенно, и перебалансировка происходит маленькими порциями. Если же диск выходит из строя, то веса не срабатывают: ~1 Тб реплик надо «размазать» по оставшимся дискам сразу, и Ceph надолго уходит в режим записи данных, загружая диски «пустой» работой.

* Перестроение кластера ceph на ходу вызывает существенную нагрузку на серверы и влияет на нормальную работу приложений

* Для построения в чистом виде гиперконвергентной системы, когда одни и те же сервера являются и узлами хранения и хостами виртуализации, ceph оказался малопригоден.

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

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

* Сетевая распределенная запись на хранилище, без data locality, одновременно с высокой загрузкой кластера по вводу-выводу — зло.

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

Около 5-ти месяцев система замечательно работала, радуя нас и клиентов. Так было, пока количество клиентов не достигло критического значения. Вместительные диски по 4-8 Тб всё-таки вылезли нам боком. При заполнении диска уже наполовину, он превращался в бутылочное горлышко - большое количество файлов, принадлежащих разным VDS, располагались на одном физическом носителе, и ему приходилось обслуживать большое количество клиентов. При выходе его из строя перебалансировка тоже проходила тяжело - надо перераспределить большой объём информации. SSD-кэш в таких условиях плохо справлялся со своими обязанностями. Рано или поздно диск кэша переполнялся и давал сигнал - с этого момента я ничего не кэширую, а только записываю сохраненную информацию на медленный HDD-диск. HDD-диск испытывает в это время двойную нагрузку - обрабатывает прямые обращения, которые поступают минуя кэш, и записывает сохраненные в кэше данные. Хранилище хорошо работало, пока дело не доходило до изменения дисковой конфигурации. Выпадение диска или добавление нового сильно замедляло общую пропускную способность хранилища.

* Низкое качество кода ceph, может привести к серьезным проблемам с разрушением хранилища данных.

Используйте LTS-выпуски Ceph. Не рассчитывайте, что будете накатывать новую версию с каждым релизом. Обновление - потенциально опасная операция для хранилища. Переход на новую версию повлечёт изменения в конфигах, и не факт, что хранилище заработает после обновления. Отслеживайте багфиксы - они бэктрекаются из новых версий в старые.

* Баги могут уничтожить как работу кластера в целом, так и содержимое хранилища.

18 февраля 2016 мы столкнулись с критическим багом Ceph: в процессе скидывания кэша на диск происходила некорректная запись блока данных. Это приводило к отключению процессов ceph-osd всех дисков, где хранились реплики злосчастного блока. Система сразу лишалась трёх дисков, а значит и всех файлов, размещенных на них. Запускался процесс перебалансировки, но не мог завершиться до конца - ведь из системы пропадали все три копии как минимум одного блока данных (и соответствующего файла), с которого началась проблема. Консистентность хранилища была под угрозой. Мы вручную удаляли ошибочные блоки, перезапускали процессы ceph-osd, но это помогало ненадолго. Ошибочная запись повторялась, балансировка начиналась снова, и хранилище рушилось. …
Напряженный поиск в интернете дал результат - закрытая бага в последнем на тот момент релизе Ceph Hammer. Наше хранилище запущено на предыдущей версии - Firefly.
Предупредили клиентов о недоступности серверов и приступили к обновлению. Переключились на другой репозиторий, в который залит фикс баги, выполнили yum update, перезапустили процессы Ceph - не помогло. Ошибка повторяется. Локализовали источник проблемы - запись из кэша в основное хранилище - и отключили кэширование полностью. Клиентские серверы заработали, но каждая перебалансировка превращалась в ад. Диски не справлялись с обслуживанием системной балансировки и клиентского чтения-записи.
Решили проблему кардинально - отказались от SSD-кэша

* Для полноценной работы кластера ceph требуется allflash конфигурация.

поставили SSD-накопители в качестве основных. Тут помогли ноды с большим количеством дисковых корзин, предусмотрительно купленные для кластера хранения. Заменяли постепенно: сначала добавили по четыре SSD в оставшиеся пустые корзины на каждом сервере, а после балансировки данных, стали по одному заменять старые HDD-диски на SSD. Делали по схеме: удаление диска, установка диска, балансировка данных, удаление, установка, балансировка и так далее по кругу, пока в нодах не остались только SSD. Заменяли на горячую …
Использовали промышленные накопители Samsung 810 размером 1 Тб. Не стали использовать SSD большего размера, чтобы не провоцировать ситуацию «узкого горлышка», когда на одном физическом носителе располагается много данных, и, следовательно на него приходится большое количество обращений.
Таким образом, постепенно мы заменили все накопители на SSD. И наступило счастье

Мои выводы (которые могут не совпадать с выводами авторов оригинального поста): ceph в продакшне — опыт для людей с железными яйцами. Скупой платит. И хорошо если только дважды. И тем более хорошо, если только деньгами. Забудьте об отпусках с семьей и отключенном на ночь звонке телефона. Это не для вас теперь.

Ceph-кластер

Рекомендуется создавать кластер Ceph в соответствии с документацией на проект . На данной странице мы приводим только обобщенную информацию по установке.

Кластер Ceph должен располагаться отдельно от VMmanager. Понятия "узлы" и "кластер" не имеют ничего общего с "узлами кластера" VMmanager"а.

Системные требования

Для создания кластера требуется следующее:

• Физические или виртуальные сервера (минимум - 5): один сервер с данными (OSD ), один сервер для метаданных (MDS ), минимум два сервера-монитора и административный сервер (он же первый клиент);
• Все серверы должны находиться как можно ближе друг к другу. Желательно, в одной стойке и в одном сегменте сети;
• Для кластера Ceph желательно использовать высокоскоростное сетевое подключение, как между узлами кластера, так и с клиентскими узлами;
• На всех серверах должна быть установлена одна операционная система.

Подготовка узлов

На все узлы кластера необходимо:

• Установить openssh ;
• Создать пользователя ceph:

# ssh [email protected] # useradd -d /home/ceph -m ceph # passwd ceph

• Созданному пользователю присвоить все привилегии:

# echo "ceph ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/ceph # chmod 0440 /etc/sudoers.d/ceph

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

• Создать директорию /ceph-client и перейти в нее:

# ssh [email protected] # cd /ceph-client

• Создать ключи ssh:

# ssh-keygen -f ./id_rsa Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in ./id_rsa. Your public key has been saved in ./id_rsa.pub. The key fingerprint is: 23:2c:d9:5c:64:4f:ea:43:5b:48:b3:69:3d:e8:25:a4 [email protected] The key"s randomart image is: +--[ RSA 2048]----+ | * . | | * @ | | E @ * | | = * = . | | o = S | | . . o | | | | | | | +-----------------+ # ls id_rsa id_rsa.pub

• В случае, если узлы кластера не разрешаются в DNS, необходимо обновить /etc/hosts . Шаблон корректного файла выглядит следующим образом:

# getent hosts | grep ceph 172.31.240.91 adm.ceph.ispsystem.net adm 172.31.240.87 mon-1.ceph.ispsystem.net mon-1 172.31.240.84 mon-2.ceph.ispsystem.net mon-2 172.31.240.28 osd-1.ceph.ispsystem.net osd-1 172.31.240.44 osd-2.ceph.ispsystem.net osd-2 172.31.240.90 mds-1.ceph.ispsystem.net mds-1

• Удобно завести переменную:

# nodes=`getent hosts | grep ceph | grep -v "adm" | awk "{print $3}" | xargs echo` # echo $nodes mon-1 mon-2 osd-1 osd-2 mds-1

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

# for i in $nodes; do ssh-copy-id -i /ceph-client/id_rsa.pub [email protected]$i ; done

• Отредактировать файл конфигурации ~/.ssh/config. Шаблон корректного файла выглядит следующим образом:

# cat ~/.ssh/config Host mon-1 Hostname mon-1.ceph.ispsystem.net IdentityFile /ceph-client/id_rsa User ceph Host mon-2 Hostname mon-2.ceph.ispsystem.net IdentityFile /ceph-client/id_rsa User ceph Host osd-1 Hostname osd-1.ceph.ispsystem.net IdentityFile /ceph-client/id_rsa User ceph Host osd-2 Hostname osd-2.ceph.ispsystem.net IdentityFile /ceph-client/id_rsa User ceph Host mds-1 Hostname mds-1.ceph.ispsystem.net IdentityFile /ceph-client/id_rsa User ceph

Установка ПО и создание кластера

• Установка ceph-deploy :

wget -q -O- "https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc" | apt-key add - echo deb http://ceph.com/debian-cuttlefish/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list apt-get update apt-get install ceph-deploy

• Создание кластера: для этого необходимо инициализировать узлы-"мониторы":

ceph-deploy new mon-1 mon-2

• Обратите внимание, что, если вы хотите использовать Ceph-хранилище с одним узлом кластера, вам необходимо в конфигурационном файле Ceph (ceph.conf) значение параметра "osd crush chooseleaf type" по-умолчанию ("1") изменить на "0":

osd crush chooseleaf type = 0

• Установка ceph на узлы кластера:

# ceph-deploy install --stable cuttlefish $nodes OK OK OK OK OK

• Установка ПО для мониторов кластера:

# ceph-deploy mon create mon-1 mon-2

• Получение ключей мониторов кластера:

# ceph-deploy gatherkeys mon-1 # ls -l ... -rw-r--r-- 1 root root 72 Jul 12 05:01 ceph.bootstrap-mds.keyring -rw-r--r-- 1 root root 72 Jul 12 05:01 ceph.bootstrap-osd.keyring -rw-r--r-- 1 root root 64 Jul 12 05:01 ceph.client.admin.keyring ...

• Подготовка хранилища (в случае, рассматриваемом для примера, на узлах хранилища есть пустой диск /dev/sdb):

# ceph-deploy osd prepare osd-1:sdb osd-2:sdb # ceph-deploy osd activate osd-1:sdb osd-2:sdb

• Очистка дисков /dev/sdb на хранилищах. Все данные на дисках будут удалены :

# ceph-deploy disk zap osd-1:sdb osd-2:sdb

• Подготовка узла метаданных:

# ceph-deploy mds create mds-1