Книга рецептов Ceph

Каран Сингх

Copyright © 2016 Packt Publishing

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

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

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

Первая публикация на английском языке: февраль 2016

Перевод: ООО "Модуль- Проекты" ("Modue- Pojects" Ltd.)

Copyright © 2016  

Данный документ предоставляется по лицензии Creative Commons Attribution 3.0 License, за исключением разделов со специальными оговорками.

http://creativecommons.org/licenses/by/3.0/legalcode

2016-03-01

Аннотация

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

 Состав исполнителей

Первого издания на английском языке

Автор

Каран Сингх

Рецензенты

Кристиан Айхельман

Харука Ивао

Редактор выпуска

Амарабха Банерджи

Редактор

Мита Раджани

Редактор разработки содержания

Кажал Тхапар

Технический редактор

Менза Мэтью

Литературный редактор

Ангад Сингх

Координатор проекта

Швета Х Бирваткар

Корректоры

Safis Editing

Составитель указателя

Рекха Наир

Координатор производства

Мелвин Дьса

Изготовитель переплёта

Мелвин Дьса

 Предисловие

 Об авторе

Каран Сингх

 Рецензенты

Кристиан Айхельман

Харука Ивао

 www.PacktPub.com

 Содержание

Вводные материалы

Авторские права

Состав исполнителей

Об авторах

Рецензенты

www.PacktPub.com

Оглавление

Предисловие

Что охватывает эта книга

Что вам нужно для этой книги

Для кого эта книга

Соглашения

Обратная связь с читателями

Загрузка кода примеров

Поддержка пользователей

Опечатки

Незаконное тиражирование

Вопросы

1. Введение и за его пределами

Введение

Ceph - начало новой эры

RAID - конец эпохи

Ceph - обзор архитектуры

Планирование развёртывания Ceph

Настройка виртуальной инфраструктуры

Установка и настройка Ceph

Увеличение Ceph в размерах

Практическое применение кластера Ceph

2. Работа с блочными устройствами Ceph

Введение

Работа с блочными устройствами Ceph

Настройка клиента Ceph

Создание блочного устройства Ceph

Отображение блочного устройства Ceph

Изменение размеров RBD Ceph

Работа со снимками RBD

Работа с клонами RBD

Быстрый осмотр OpenStack

Ceph - наилучшее соответствие OpenStack

Настройка OpenStack

Настройка OpenStack в качестве клиента Ceph

Настройка Glance под поддержку Ceph

Настройка Cinder под поддержку Ceph

Настройка Nova для подключения Ceph RBD

Настройка Nova для загрузки экземпляров из Ceph RBD

3. Работа с хранилищем объектов Ceph

Введение

Понимание хранения объектов Ceph

Стандартные наладка, установка и настройка шлюза RADOS

Создание пользователя radosgw

Доступ к хранилищу объектов Ceph с применением S3 API

Доступ к хранилищу объектов Ceph с применением Swift API

Интеграция шлюза RADOS с OpenStack Keystone

Настройка федеративных шлюзов Ceph

Тестирование федеративных настроек radosgw

Построение служб файловой синхронизации и совместного использования с применением RGW

4. Работа с файловой системой Ceph

Введение

Понимание файловой системы Ceph и MDS

Развёртывание MDS Ceph

Доступ к CephFS через драйвер ядра

Доступ к CephFS через клиента FUSE

Экспорт файловой системы Ceph в качестве NFS

ceph-dokan – CephFS для клиентов Windows

CephFS вклинивающаяся замена HDFS

5. Мониторинг кластеров Ceph с применением Calamari

Введение

Мониторинг кластера Ceph - классический путь

Мониторинг кластеров Ceph

Наблюдение за мониторами Ceph

Мониторинг OSD Ceph

Мониторинг MDS Ceph

Введение в Ceph Calamari

Построение пакетов Calamari сервер

Построение пакетов Calamari клиент

Наладка главного сервера Calamari

Добавление узлов Ceph в Calamari

Мониторинг кластера Ceph в инструментальной панели Calamari

Обнаружение ошибок Calamari

6. Работа в кластере Ceph и управление им

Введение

Понимание управления службами Ceph

Координация файла настроек кластера

Выполнение Ceph с применением SYSVINIT

Выполнение Ceph как службы

Сопоставление расширения и увеличения в масштабе

Увеличение в масштабе вашего кластера Ceph

Уменьшение в масштабе вашего кластера Ceph

Замена отказавшего диска в вашем кластере Ceph

Обновление вашего кластера Ceph

Сопровождение вашего кластера Ceph

7. Ceph под колпаком

Введение

Масштабируемость и высокая доступность Ceph

Понимание механизма CRUSH

Карта CRUSH изнутри

Карта кластера Ceph

Мониторы высокой доступности

Аутентификация и авторизация Ceph

Динамическое управление Ceph кластером

Группы размещения Ceph

Состояние групп размещения

Создание пулов Ceph на специфических OSD

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

Введение

Динамика ёмкости, производительности и стоимости

Выбор аппаратных и программных компонентов Ceph

Аппаратная поддержка удаляющего кодирования ASIC ConnectX-4

Рекомендации Ceph и настройка производительности

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

Рекомендуемые цены Intel на некоторые ЦПУ

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

Аппаратная поддержка удаляющего кодирования ASIC ConnectX-4

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

NVMe

Создание пула с удаляющим кодированием

Многоуровневое кэширование Ceph

Создание пула для многоуровневого кэширования

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

Настройка уровня кэша

Тестирование уровня кэша

9. Менеджер виртуального хранения Ceph

Введение

Понимание архитектуры VSM

Сборка среды VSM

Подготовка к VSM

Установка VSM

Создание кластера Ceph с применением VSM

Исследование инструментальной панели VSM

Обновление кластера Ceph с применением VSM

Дорожная карта VSM

Ресурсы VSM

10. Ещё о Ceph

Введение

Эталонное тестирование кластера Ceph

Базовый уровень производительности дисков

Базовый уровень производительности сетевой среды

Показатели Ceph RADOS

RADOS load-gen

Эталонное тестирование блочного устройства Ceph

Эталонное тестирование Ceph RBD с применением FIO

Сокет администратора Ceph

Применение команды ceph tell

Ceph REST API

Профилирование памяти Ceph

Развёртывание Ceph с применением Ansible

Инструментарий ceph-objectstore

Приложения

Понимание разгрузки удаляющего кодирования (Mellanox)

Стек протоколов Mellanox OFED (Mellanox)

Стандарт NVMe Over Fabrics (Mellanox)

Стек протоколов Intel (Intel)

Указатель

 Предисловие

 Что охватывает эта книга

 Что вам нужно для этой книги

 Для кого эта книга

 Соглашения

 Обратная связь с читателями

 Загрузка кода примеров

 Поддержка пользователей

 Опечатки

 Незаконное тиражирование

 Вопросы

Глава 1. Введение и за его пределами

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

Ceph - начало новой эры

RAID - конец эпохи

Ceph - обзор архитектуры

Планирование развёртывания Ceph

Настройка виртуальной инфраструктуры

Установка и настройка Ceph

Увеличение Ceph в размерах

Практическое применение кластера Ceph

Содержание

1. Введение и за его пределами

Введение

Ceph - начало новой эры

RAID - конец эпохи

Ceph - обзор архитектуры

Планирование развёртывания Ceph

Настройка виртуальной инфраструктуры

Установка и настройка Ceph

Увеличение Ceph в размерах

Практическое применение кластера Ceph

 Введение

В настоящее время Ceph является самой востребованной технологией Систем хранения управляемых программным обеспечением (SDS, Software Defined Storage), которая встряхнула всю индустрию хранения данных. Это проект с открытым исходным кодом, которые предоставляет унифицированное решение определяемое программным обеспечением (ПО) для хранения Блоков, Файлов и Объектов. Основная идея состоит в предоставлении распределённой системы хранения, которая является массивно масштабируемой и высокопроизводительной при отсутствии единой точки отказа. С самого начала она разрабатывалась для высокой масштабируемости (до уровня Экзабайт и выше) и при этом способная работать на общедоступном рыночном оборудовании.

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

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

Ceph был выращен и вскормлен на философии архитектуры, которая содержит в себе следующее:

Все компоненты должны масштабироваться линейно

Не должно существовать единой точки отказа

Решение должно быть основано на программном обеспечении, причем с открытым исходным кодом, а также быть адаптивным

Программное обеспечение Ceph должно работать на легко доступном общеупотребимом оборудовании

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

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

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

  Редакции Ceph

Ceph разрабатывается и совершенствуется очень быстрыми темпами. 3 июля 2012 Sage анонсировала первый выпуск LTS Ceph с кодовым именем Argonaut. С этого момента мы уже увидели появление семи новых выпусков. Выпуски Ceph категоризируются как LTS (Long Term Support в терминах долговременной поддержки) и выпусков разработок, а каждая альтернативная редакция является выпуском LTS. За дополнительной информацией, пожалуйста, обращайтесь к https://Ceph.com/category/releases/.

Название редакции Ceph
Версия редакции Ceph
Дата выпуска

Argonaut

V0.48 (LTS)

3 июля 2012

Bobtail

V0.56 (LTS)

1 января 2013

Cuttlefish

V0.61

7 мая 2013

Dumpling

V0.67 (LTS)

14 августа 2013

Emperor

V0.72

9 ноября 2013

Firefly

V0.80 (LTS)

7 мая 2014

Giant

V0.87.1

26 февраля 2015

Hammer

V0.94 (LTS)

7 апреля 2015

Infernalis

V9.0.0

5 мая 2015

Jewel

V10.0.0

ноябрь 2015

[Совет]
Совет

Существует такой факт: имена редакций следуют в алфавитном порядке; следующая будет начинаться с "K".

[Замечание]
Замечание

Термин "Ceph" является общей кличкой осьминогов и рассматривается как сокращение от "Cephalopod", которые являются классом морских животных относящихся к молюскам филумам. Ceph имеет осьминогов в качестве своего талисмана, который представляет сильное распараллеленное поведение Ceph, похожее на поведение осьминогов.

 Ceph - начало новой эры

На протяжении последних нескольких лет требования к хранению данных растут взрывообразно. Исследование показывает, что данные в больших организациях ежегодно растут со скоростью от 40 до 60 процентов, а многие компании ежегодно удваивают отпечатки своих данных. Аналитики IDC оценивают, что по всему миру в 2000 году существовало 54.4 Экзабайт общих данных. В 2007 они выросли до 295 Экзабайт, а к 2020 по всему миру ожидается рост до 44 Зеттабайт. Такой рост данных не способен управляться традиционными системами хранения; нам требуются системы подобные Ceph, которые являются распределёнными, масштабируемыми и, что наиболее важно, экономически жизнеспособными. Ceph разрабатывалась намеренно для соответствия сегодняшнему дню, а также потребностям хранилищ данных будущего.

  Программно определяемые хранилище (SDS)

SDS (Software Defined Storage) это то, что необходимо для уменьшения TCO вашей инфраструктуры хранения. Помимо уменьшения стоимости хранения, SDS может предоставить гибкость, масштабируемость и надёжность. Ceph является полноценным SDS решением; она работает на общедоступном оборудовании без привязок к определённому производителю с низкой стоимостью на ГБ. В отличие от традиционных систем хранения, в которых оборудование заранее обручено с ПО, в SDS вы вольны в выборе доступного на рынке оборудования любых производителей и свободны в проектировании гетерогенных аппаратных решений для ваших собственных нужд. Программно определяемое хранилище Ceph поверх таких аппаратных средств предоставляет всю необходимую вам интеллектуальность и позаботится обо всём, предоставляя всю функциональность корпоративной системы хранения прямо на уровне программного обеспечения.

  Облачное хранилище

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

Ceph стремительно развивается и преодолевает разрыв реальной основы хранения в облачных решениях. Он захватывает центральное место во всех основных облачных платформах с открытым исходным кодом, а именно, OpenStack, CloudStack и OpenNebula {Прим. пер.: а также Proxmox VE и т.п. }. Кроме того, Ceph успешен в создании партнёрских отношений с поставщиками облачных решений, например, с Red Hat, Canonical, Mirantis, SUSE и многими другими. Эти компании уделяют много времени Ceph и включают его в качестве официальной основы хранения для своих дистрибутивов облачных решений OpenStack, тем самым делая Ceph красной горячей технологией в пространстве хранения облачных решений.

OpenStack является одним из лучших примеров ПО с открытым исходным кодом наделяющих мощностью общедоступные и частные облачные решения. Оно зарекомендовало себя как сквозное облачное решение с открытым исходным кодом. OpenStack является набором программных средств таких как cinder, glance и swift, которые предоставляют возможности хранения для OpenStack. Этим компоненты OpenStack требуется надёжное, масштабируемое и всё-в-одном основное хранилище, подобное Ceph. По этой причине OpenStack и Ceph сообщества уже долгие годы проводят совместные работы для разработки полностью совместимой основы хранения Ceph для OpenStack.

Основанная на Ceph облачная инфраструктура обеспечивает поставщикам услуг столь необходимую гибкость для создания решений хранилища- как- службы (Storage-as-a-Service) и инфраструктуры- как- службы (Infrastructure-as-a-Service ), которые они не могут получить у прочих традиционных решений хранения, поскольку они не разработаны для полного соответствия требованиям облачных решений. Применяя Ceph, поставщики служб могут предлагать своим потребителям экономичное, надёжное облачное хранение.

  Единообразная архитектура хранения следующего поколения

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

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

Обычная архитектура хранения системы SAN или NAS является весьма ограниченной. В основном они следуют традиции контроллера высокой доступности, т.е. если один контроллер хранения отказывает, они обслуживают данные вторым контроллером. Но что, если второй контроллер отказал в то же время, или даже хуже, если отказывает вся полка? В большинстве случаев вы в конечном счёте теряете свои данные. Такой вид архитектуры, который не может выдерживать множественные отказы, несомненно не то, что мы хотим видеть сегодня. Другим недостатком традиционных систем хранения является их механизм хранения данных и доступа к ним. Он поддерживает централизованное таблицу поиска для отслеживания метаданных, что означает, что при каждой отправке запроса пользователя на операцию чтения или записи эта система хранения вначале выполняет поиск в гигантской таблице метаданных, а уже после получения действительного местоположения данных выполняет операцию клиента. Для систем хранения небольшого размера вы можете не заметить скачков производительности, однако задумайтесь о больших кластерах хранения - вы, несомненно, будете зажаты рамками производительности при подобном подходе. Это было бы также ограничением вашей масштабируемости.

Ceph не следует подобной традиции архитектуры хранения; на самом деле, архитектура была разработана заново. Вместо того чтобы хранить метаданные и оперировать ими, Ceph вводит новый подход: алгоритм CRUSH. CRUSH является сокращением от Controlled Replication Under Scalable Hashing, Управляемых масштабируемым хешированием репликаций. Вместо выполнения поиска в таблице метаданных для каждого клиентского запроса, алгоритм CRUSH по требованию вычисляет где должны быть записаны данные или откуда их прочитать. За счёт вычисления метаданных отпадает необходимость управления централизованной таблицей метаданных. Современные компьютеры имеют впечатляющую производительность и могут очень быстро выполнять CRUSH просмотр; более того, эта вычислительная нагрузка, которая обычно незначительна, может быть распределена по узлам кластера, применяя мощность распределённого хранения. В дополнение к этому CRUSH имеет уникальное свойство, а именно осведомлённость об инфраструктуре. Он понимает взаимосвязь между различными компонентами вашей инфраструктуры и сохраняет ваши данные в уникальной зоне отказа, такой как диск, узел, стойка, ряд и помещение центра данных, помимо всего прочего. CRUSH хранит все копии ваших данных таким образом, что они будут доступными даже если несколько компонентов в зоне отказа выйдут из строя. Это обусловлено в CRUSH тем, что Ceph может обрабатывать несколько отказов компонентов, тем самым предоставляя надёжность и долговечность.

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

 RAID - конец эпохи

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

  Головная боль перестроения RAID

Основную головную боль в технологии RAID предоставляет её слишком продолжительный процесс перестроения. Производители дисков упаковывают в один диск очень большую ёмкость хранения. В настоящее время они производят дисковые устройства сверхвысокой ёмкости по отношению к его стоимости. Больше мы не говорим о дисках 450ГБ, 600ГБ или даже 1ТБ, поскольку на сегодняшний день доступны диски большей ёмкости. Более новые спецификации дисков уровня предприятия доходят до дисковых устройств в 4ТБ, 6ТБ и даже 10ТБ, причём ёмкость растёт год за годом.

Задумайтесь о системе хранения предприятия на базе RAID которая выполнена на большом количестве дисковых устройств с 4 или 6ТБ. К несчастью, когда такие диски отказывают, контроллеру RAID потребуется несколько часов , порой и дней для восстановления отдельного отказавшего диска. В то же время, если в той же RAID группе откажет другой диск, то ситуация станет непредсказуемой. Восстановление множества больших дисковых устройств при помощи RAID является обременительным процессом.

  Запасные диски RAID увеличивают TCO

RAID система требует несколько дисков в качестве дисков горячей замены. Это всего навсего диски, которые будут использованы только в случае отказа диска, иначе они никогда не будут применяться для хранения данных. Это добавляет дополнительную стоимость в систему и увеличивает стоимость совокупного владения. Более того, если при вашей работе не хватает запасных дисков, а диск сразу выходит из строя в группе RAID, то вам придётся столкнуться с серъёзной проблемой.

  RAID может быть дорогостоящим и зависимым от аппаратных средств

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

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

  Рост группы RAID является вызовом

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

  Модель надёжности RAID больше не является многообещающей

RAID может быть настроен с большим разнообразием типов; наиболее общими типами являются RAID5 и RAID6, которые выдерживают отказ одного и двух дисков соответственно. RAID не может гарантировать надёжность данных после отказа двух дисков. Это одна из основных помех в RAID системах.

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

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

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

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

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

 Ceph - обзор архитектуры

Архитектура Ceph очень проста и мы будем изучать её при помощи следующей схемы:

Рисунок 1.1. Архитектура Ceph

Мониторы Ceph (MON): Мониторы Ceph отслеживают состояние всего кластера поддерживая карту состояния вашего кластера. Они обслуживают информацию об отдельном соответствии для всех компонент, что включает карту OSD, карту MON и карту PG (обсуждаются в последующих главах), а также карту CRUSH. Все узлы кластера предоставляют отчёт узлам Монитора и предоставляют для совместного использования информацию обо всех изменениях своего состояния. Монитор не сохраняет фактические данные; это работа OSD.

Мониторы Ceph (MON): Не должно существовать единой точки отказа

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

Сервер метаданных Ceph (MDS, Metadata Server): MDS поддерживает отслеживание иерархии файлов и хранит метаданные исключительно для вашей файловой системы CephFS. Блочные устройства Ceph и шлюзы RADOS не требуют метаданных, следовательно они не нуждаются в демоне Ceph MDS. MDS не предоставляет данные клиенту напрямую, тем самым удаляя единую точку отказа из вашей системы.

RADOS (Reliable Autonomic Distributed Object Store, Безотказное автономное распределенное хранилище объектов): Является фундаментом вашего кластера хранения Ceph. Всё в Ceph сохраняется в виде объектов, а хранилище объектов RADOS отвечает за сохранение этих объектов вне зависимости от их типов данных. Уровень RADOS гарантирует что данные всегда остаются согласованными. Для этого они выполняют репликацию данных, определение отказов и восстановление,а также миграцию данных и ребалансировку по узлам кластера.

librados: Библиотека librados является удобным путём получения доступа к RADOS с поддержкой языков программирования PHP, Ruby, Java, Python, C и C++. Она предоставляет естественный интерфейс для вашего кластера хранения Ceph (RADOS), а также основу для прочих служб, таких как RBD, RGW и CephFS, которые строятся поверх librados. Librados также поддерживает прямой доступ к RADOS из приложений без накладных расходов на HTTP.

Блочные устройства RADOS (RBD, RADOS Block Devices): RBD, которые также называются блочными устройствами Ceph, предоставляют постоянное блочное хранение, которое является динамично выделяемыми (thin provisioning) {Прим. пер.: http://en.wikipedia.org/wiki/Thin_provisioning, http://habrahabr.ru/post/170389/}, изменяемыми в размере и хранят данные с чередованием по множеству OSD. Служба RBD строится в виде естественного интерфейса поверх librados.

Интерфейс шлюза RADOS (RGW, RADOS Gateway interface): RGW предоставляет службу хранения объектов. Он применяет librgw (библиотеку шлюза RADOS) и librados, позволяя приложениям устанавливать соединения с хранилищем объектов Ceph. RGW обеспечивает RESTful API интерфейсами, которые совместимы с Amazon S3 и OpenStack Swift.

CephFS: Файловая система CephFS предоставляет POSIX- совместимую файловую систему, которая использует кластер хранения Ceph для хранения пользовательских данных в файловой системе. Как и RBD, и RGW, служба CephFS также реализует естественный интерфейс с librados.

 Планирование развёртывания Ceph

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

Рисунок 1.2. Базовый вид кластера Ceph

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

 Настройка виртуальной инфраструктуры

Для установки виртуальной инфраструктуры вам понадобится ПО с открытым исходным кодом подобное Oracle VirtualBox и Vagrant для автоматизации создания для вас виртуальных машин. Проверьте что у вас имеется следующее установленное и корректно работающее программное обеспечение на вашей хост-машине. Процесс установки программного обеспечения выходит за рамки данной книги; вы можете следовать их соответствующим документациям для корректной установки и последующей работы. {Прим. пер.: в предыдущей своей книге, Изучаем Ceph автор даёт некие инструкции, можно попытаться следовать им с учётом того факта, что за прошедший с того времени срок более года произошли серъёзные изменения. Мы постараемся в ближайшее время подготовить свои инструкции по реализации данного стенда в среде Proxmox VE, обращайтесь за консультациями!}

  Приготовление

Для начала вам потребуется следующее программное обеспечение:

Oracle VirtualBox: Это программный пакет виртуализации с открытым исходным кодом для размещения машин на базе x86 и AMD64/Intel64. Он поддерживает размещение операционных систем Microsoft Windows, Linux и Apple MAC OSX. Убедитесь что он установлен и работает соответствующим образом. Дополнительную информацию вы можете найти на https://www.virtualbox.org. После установки VirtualBox выполните следующую команду для проверки установки:

# VBoxManage --version

	HOST:~ksingh$
	HOST:~ksingh$ VBoxManage --version
	4/3/22r98236
	HOST:~ksingh$

Vagrant: Это программное обеспечение предназначено для создания виртуальных сред разработки. Оно работает в качестве обертки вокруг виртуального программного обеспечения подобного VirtualBox, VMware, KVM и тому подобного. Оно поддерживает размещение операционных систем Microsoft Windows, Linux и Apple Mac OSX. Убедитесь, что оно установлен и работает правильно. Более подробную информацию можно найти на сайте https://www.vagrantup.com/. После того как вы установили Vagrant, выполните следующую команду чтобы гарантировать установку:

# vagrant --version

	HOST:~ ksingh$
	HOST:~ ksingh$ vagrant --version
	Vagrant 1.7.2
	HOST:~ ksingh$

Git: Это распределённая система управления редакций, а также наиболее популярная и широко применяемая система управления версиями для разработчиков программного обеспечения. Она поддерживает операционные системы Microsoft Windows, Linux и Apple MAC OSX. Убедитесь, что она установлена и работает правильно. Дополнительную информацию можете получить по адресу http://git-scm.com/. {Прим. пер.: см. Основы Git.} Когда вы установите Git, выполните следующую команду для гарантированности установки:

# git --version

	HOST:~ ksingh$
	HOST:~ ksingh$ git --version
	git version 1.9.3 (Apple Git-50)
	HOST:~ ksingh$

  Как это сделать...

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

Git клонирует репозиторий ceph-cookbook, для вашей машины хоста VirtualBox:

# git clone https://github.com/ksingh7/ceph-cookbook.git

	HOST:~ ksingh$
	HOST:~ ksingh$ git clone https://github.com/ksingh7/ceph-cookbook.git
	Cloning into 'ceph-cookbook'
	remote: Counting objects: 18, done.
	remote: Compressing objects: 100% (11/11), done.
	remote: Total 18 (delta 5), reused 14 (delta 1), pack-reused 0
	unpacking objects : 100% (18/18), done.
	Checking connectivity... done.
	HOST:~ ksingh$

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

$ cd ceph-cookbook ; ls -l

Далее мы запустим три ВМ при помощи Vagrant; они потребуются в данной главе:

$ vagrant up ceph-node1 ceph-node2 ceph-node3

	HOST:ceph-cookbook ksingh$
	HOST:ceph-cookbook ksingh$ vagrant up ceph-node1 ceph-node2 ceph-node3
	Bringing machine 'ceph-node1' up with 'virtualbox' provider...
	Bringing machine 'ceph-node2' up with 'virtualbox' provider...
	Bringing machine 'ceph-node3' up with 'virtualbox' provider...
	===>ceph-node1 Box 'centos7-standard' could not be found. Attempting to find and install...
	       ceph-node1 Box Provider: virtualbox
	       ceph-node1 Box Version: >= 0

Проверьте состояние виртуальных машин:

$ vagrant status ceph-node1 ceph-node2 ceph-node3

	HOST:ceph-cookbook ksingh$ vagrant status ceph-node1 ceph-node2 ceph-node3
	Current machine states:

	ceph-node1                running (virtualbox)
	ceph-node2                running (virtualbox)
	ceph-node3                running (virtualbox)

	This environment represents multiple VMs. The VMs are all listed
	above with their current state. For more information about a specific
	VM, run `vagrant status NAME`.
	HOST:ceph-cookbook ksingh$

[Замечание]
Замечание

Имя и пароль которые Vagrant применяет для настройки виртуальной машины vagrant и Vagrant имеет права sudo. Пароль по умолчанию для пользователя root установлен в vagrant.

По умолчанию Vagrant установит имена хоста в виде ceph-node<node_number>, IP адрес подсети в 192.168.1.X, а также создаст дополнительные диски, которые будут использованы в качестве OSD кластером Ceph. Зарегистрируйте каждую из этих машин одну за другой и проверьте правильно ли установлены Vagrant-ом имя хоста, сетевая среда и дополнительные диски:

$ vagrant ssh ceph-node1
$ ip addr show
$ sudo fdisk -l
$ exit

Vagrant настроен для обновления файла hosts на ваших ВМ. Для удобства измените файл /etc/hosts на вашей машине хоста следующим содержимым.

192.168.1.101 ceph-node1
192.168.1.102 ceph-node2
192.168.1.103 ceph-node3

	HOST:ceph-cookbook ksingh$
	HOST:ceph-cookbook ksingh$ cat /etc/hosts | grep -i ceph-node
	192.168.1.101 ceph-node1
	192.168.1.102 ceph-node2
	192.168.1.103 ceph-node3
	HOST:ceph-cookbook ksingh$

Сгенерируйте ключи SSH для ceph-node1 эти ключи на ceph-node2 и ceph-node3. Пароль для пользователя root на этих ВМ установлен в vagrant. Введите паролль пользователя root после получения запроса от команды ssh-copy-id, затем продолжите со следующими установками:

$ vagrant ssh ceph-node1
$ sudo su -
# ssh-keygen
# ssh-copy-id root@ceph-node2
# ssh-copy-id root@ceph-node3

	[root@ceph-nodel ~]# ssh-copy-id root@ceph-node2
	The authenticity of host 'ceph-node2 (192.168.1.102)' can't be established.
	ECDSA key fingerprint is af:2a:a5:74:a7:0b:f5:5b:ef:c5:4b:2a:fe:ld:30:8e.
	Are you sure you want to continue connecting (yes/no)? yes
	/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
	/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
	root@ceph-node2's password:

	Number of key(s) added: 1

	Now try logging into the machine, with: "ssh iroot@ceph-node21"
	and check to make sure that only the key(s) you wanted were added.

	[root@ceph-nodel ~]#

Когда SSH ключи скопированы на ceph-node2 и ceph-node3, пользователь root на ceph-node1 может выполнять регистрацию ВМ через ssh без ввода пароля:

# ssh ceph-node2 hostname
# ssh ceph-node3 hostname

	[root@ceph-nodel ~]# ssh ceph-node2 hostname
	ceph-node2
	[root@ceph-nodel ~]#
	[root@ceph-nodel ~]# ssh ceph-node3 hostname
	ceph-node3
	[root@ceph-nodel ~]#

Сделайте доступными порты, которые требуются для Ceph MON, OSD и MDS в работающем в системе межсетевом экране. Выполните на всех ВМ следующие команды:

# firewall-cmd --zone=public --add-port=6789/tcp --permanent
# firewall-cmd --zone=public --add-port=6800-7100/tcp --permanent
# firewall-cmd --reload
# firewall-cmd --zone=public --list-all

	[root@ceph-nodel ~]# firewall-cmd --zone=public --add-port=6789/tcp --permanent success
	[root@ceph-nodel ~]# firewall-cmd --zone=public --add-port=6800-7100/tcp --permanent success
	[root@ceph-nodel ~]# firewall-cmd --reload
	success
	[root@ceph-nodel ~]#
	[root@ceph-nodel ~]# firewall-cmd --zone=public --list-all
	public (default, active)
	interfaces: enp0s3 enp0s8
	sources: services: dhcpv6-client ssh
	ports: 6789/tcp 6800-7100/tcp
	masquerade: no
	forward-ports:
	icmp-blocks:
	rich rules:

	[root@ceph-nodel —]#

Запретите SELINUX на всех ваших ВМ:

# setenforce 0
# sed –i s'/SELINUX.*=.*enforcing/SELINUX=disabled'/g /etc/selinux/config

	[root@ceph-nodel ~]# setenforce 0
	[root@ceph-nodel ~]# sed –i s'/SELINUX.*=.*enforcing/SELINUX=disabled'/g /etc/selinux/config
	[root@ceph-nodel ~]# cat /etc/selinux/config | grep =disabled
	SELINUX=disabled
	[root@ceph-nodel ~]#

Установите и настройте ntp на всех ВМ:

# yum install ntp ntpdate -y
# ntpdate pool.ntp.org
# systemctl restart ntpdate.service
# systemctl restart ntpd.service
# systemctl enable ntpd.service
# systemctl enable ntpdate.service

Добавьте на все узлы репозитории для Ceph версии Giant и обновите yum:

# rpm -Uhv http://ceph.com/rpm-giant/el7/noarch/ceph-release-1-0.el7.noarch.rpm
# yum update -y

	[root@ceph-nodel ~]# rpm -Uhv http://ceph.com/rpm-giant/el7/noarch/ceph-release-1-0.el7.noarch.rpm
	Retrieving http://ceph.com/rpm-giant/el7/noarch/ceph-release-1-0.el7.noarch.rpm
	warning: /var/tmp/rpm-tmp.y9SGTx: Header V4 RSA/SHA1 Signature, key ID 17ed316d: NOKEY
	Preparing...                          ################################# [100%]
	updating / installing...
	   1:ceph-release-1-0.el7             ################################# [100%]
	[root@ceph-nodel ~]#

 Установка и настройка Ceph

Чтобы развернуть наш первый кластер Ceph мы воспользуемся инструментарием ceph-deploy для установки и настройки Ceph на всех трёх виртуальных машинах. Инструментарий ceph-deploy является частью программно определяемого хранилища Ceph, которое применяется для более простого развёртывания и управления вашим кластером хранения Ceph. В предыдущем разделе мы создали три виртуальные машины с CentOS7, которые имеют связь с интернетом через NAT, а также с частной сетевой средой только внутри хоста.

Мы настроим эти машины в качестве кластера хранения Ceph, как это отображено на следующей схеме:

Рисунок 1.3. Конфигурация тестового кластера Ceph

  Создание кластера Ceph на ceph-node1

Для начала мы установим Ceph и настроим ceph-node1 в качестве монитора Ceph и узла OSD Ceph. Последующие рецепты введут ceph-node2 и ceph-node3.

  Как это сделать...

Установите ceph-deploy на ceph-node1:

# yum install ceph-deploy -y

Далее мы создадим кластер Ceph используя ceph-deploy выполнив следующие команды на ceph-node1:

# mkdir /etc/ceph ; cd /etc/ceph
# ceph-deploy new ceph-node1

Подкоманда new в ceph-deploy развернёт новый кластер применяя ceph в качестве имени кластера, что является значением по умолчанию; она создаст настройку кластера и файлы ключей. Просмотрите настоящее состояние рабочего каталога; вы найдёте свои файлы ceph.conf и ceph.mon.keyring:

	   [root@ceph-nodel ceph]# ceph-deploy new ceph-nodel
	   [ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf
	   [ceph_deploy.cli][INFO ] Invoked (1.5.22): /usr/bin/ceph-deploy new ceph-nodel
	   [ceph_deploy.new][DEBUG ] creating new cluster named ceph
	   [ceph_deploy.new][INFO ] making sure passwordless SSH succeeds
	   [ceph-node1][DEBUG ] connected to host: ceph-nodel
	   [ceph-nodel][DEBUG ] detect platform information from remote host
	   [ceph-node1][DEBUG ] detect machine type
	   [ceph-node1][DEBUG ] find the location of an executable
	   [ceph-nodel][INFO ] Running command: /usr/sbin/ip link show
	   [ceph-node1][INFO ] Running command: /usr/sbin/ip addr show
	   [ceph-nodel][DEBUG ] IP addresses found: ['192.168.1.101', '10.0.2.15']
	   [ceph_deploy.new][DEBUG ] Resolving host ceph-nodel
	   [ceph_deploy.new][DEBUG ] Monitor ceph-nodel at 192.168.1.101
	   [ceph_deploy.new][DEBUG ] Monitor initial members are ['ceph-nodel']
	   [ceph_deploy.new][DEBUG ] Monitor addrs are ['192.168.1.101']
	   [ceph_deploy.new][DEBUG ] creating a random mon key...
	   [ceph_deploy.new][DEBUG ] writing monitor keyring to ceph.mon.keyring...
	   [ceph_deploy.new][DEBUG ] writing initial config to ceph.conf...
	   [root@ceph-nodel ceph]#

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

# ceph-deploy install ceph-node1 ceph-node2 ceph-node3

Инструментарий ceph-deploy выполнит первую установку всех зависимостей следуя двоичным файлам Ceph Giant. Когда команда успешно завершится, проверьте версию Ceph и его состояние на всех ваших узлах, как показано далее:

# ceph -v

Создайте первый ваш монитор Ceph на ceph-node1:

# ceph-deploy mon create-initial

Когда создание монитора успешно завершится, проверьте ваше состояние кластера. Ваш кластер на текущий момент не должен быть готов:

# ceph -s

	[root@ceph-nodel ceph]# ceph -s
	cluster 975efaaa-387e-4528-9285-3fcc664c117e
	health HEALTH_ERR 64 pgs stuck inactive; 64 pgs stuck unclean; no osds
	monmap el: 1 mons at {ceph-nodel=192.168.1.101:6789/0}, election epoch 2, quorum 0 ceph-nodel
	osdmap el: 0 osds: 0 up, 0 in
	 pgmap v2: 64 pgs, 1 pools, 0 bytes data, 0 objects
	       0 kB used, 0 kB / 0 kB avail
		         64 creating
	[root@ceph-nodel ceph]#

Создайте OSD на ceph-node1:

Выведите список доступных на ceph-node1 дисков:

# ceph-deploy disk list ceph-node1

Аккуратно выберите диски из вывода (отличные от разделов OS) на которых мы должны создать OSD Ceph. В нашем случае диски имеют имена sdb, sdc и sdd.

Подкоманда disk zap разрушит существующую таблицу разделов и содержимое диска. Перед выполнением этой команды убедитесь что вы используете верные имена дисковых устройств:

# ceph-deploy disk zap ceph-node1:sdb ceph-node1:sdc cephnode1:sdd

Подкоманда osd create выполнит начальную подготовку диска, т.е. очистит диск с файловой системой, которой по умолчанию является xfs, а затем активирует первый раздел в качестве раздела данных а второй в качестве журнала:

# ceph-deploy osd create ceph-node1:sdb ceph-node1:sdc ceph-node1:sdd

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

# ceph -s

		[root@ceph-nodel ceph]# ceph -s
		    cluster aade8340-a44b-45f5-9679-39442daeal8d
		     health HEALTH_WARN 64 pgs incomplete; 64 pgs stuck inactive; 64 pgs stuck unclean
			 monmap el: 1 mons at {ceph-nodel=192.168.1.101:6789/0}, election epoch 2, quorum 0 ceph-nodel
			 osdmap ell: 3 osds: 3 up, 3 in
			  pgmap v17: 64 pgs, 1 pools, 0 bytes data, 0 objects
			        67344 kB used, 10152 MB / 10217 MB avail
					      64 incomplete
		[root@ceph-nodel ceph]#

 Увеличение Ceph в размерах

На данный момент у нас есть работающий кластер Ceph с одним MON и тремя OSD настроенными в ceph-node1. Теперь мы масштабируем наш кластер добавляя ceph-node2 и ceph-node1 как узлы MON и OSD.

  Как это сделать...

Кластеру Ceph для работы необходим по крайней мере один монитор. Для достижения высокой доступности кластер хранения Ceph полагается на нечётное число мониторов, причём более одного, например, 3 или 5 для оформления кворума. Он применяет алгоритм Paxos для получения большинства кворума. Поскольку у нас уже есть один монитор, работающий на ceph-node1, давайте создадим два дополнительных монитора для нашего кластера Ceph;

Добавьте в файл /etc/ceph/ceph.conf в ceph-node1:

public network = 192.168.1.0/24

Примените ceph-deploy на ceph-node1 для создания монитора на ceph-node2:

# ceph-deploy mon create ceph-node2

Повторите этот шаг создания монитора на ceph-node3:

# ceph-deploy mon create ceph-node3

Проверьте состояние вашего кластера Ceph; он должен отображать три монитора в разделе MON:

# ceph -s
# ceph mon stat

	[root@ceph-nodel ceph]# ceph -s
	    cluster aade8340-a44b-45f5-9679-39442daeal8d
		 health HEALTH_WARN 64 pgs incomplete; 64 pgs stuck inactive; 64 pgs stuck unclean
		 monmap e3: 3 mons at {ceph-nodel=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0, ceph-node3=192.168.1.103:6789/0}, election epoch 10, quorum 0,1,2 ceph-nodel,ceph-node2,ceph-node3
		 osdmap e11: 3 osds: 3 up, 3 in
		 pgmap v21: 64 pgs, 1 pools, 0 bytes data, 0 objects
		       100792 kB used, 15228 MB / 15326 MB avail
			         64 incomplete
	[root@ceph-nodel ceph]#
	[root@ceph-nodel ceph]#
	[root@ceph-nodel ceph]# ceph mon stat
	e3: 3 mons at {ceph-nodel=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=1 92.168.1.103:6789/0}, election epoch 10, quorum 0,1,2 ceph-nodel,ceph-node2,ceph-node3
	[root@ceph-nodel ceph]#

Вы заметите, что ваш кластер Ceph в настоящий момент показывает HEALTH_WARN; это происходит по той причине, что мы не настроили никаких OSD за пределами ceph-node1. По умолчанию данные в кластере Ceph реплицируются три раза, причём, к тому же, на трёх различных OSD размещающихся на трёх различных узлах. Теперь мы настроим OSD на ceph-node2 и ceph-node3:

Примените ceph-deploy на ceph-node1 для выполнения disk list, disk zap, а также создания OSD на ceph-node2 и ceph-node3:

# ceph-deploy disk list ceph-node2 ceph-node3
# ceph-deploy disk zap ceph-node2:sdb ceph-node2:sdc cephnode2:sdd
# ceph-deploy disk zap ceph-node3:sdb ceph-node3:sdc cephnode3:sdd
# ceph-deploy osd create ceph-node2:sdb ceph-node2:sdc cephnode2:sdd
# ceph-deploy osd create ceph-node3:sdb ceph-node3:sdc cephnode3:sdd

Поскольку мы добавили дополнительные OSD, нам следует настроить значения pg_num и pgp_num для того, чтобы пул rbd достиг статуса HEALTH_OK в нашем кластере Ceph:

# ceph osd pool set rbd pg_num 256
# ceph osd pool set rbd pgp_num 256

[Совет]
Совет

Начиная с редакции Ceph Hammer, rbd является единственным создаваемым по умолчанию пулом. Предшествующие Hammer редакции создавали три различных пула: data, metadata и rbd.

Проверьте состояние вашего кластера Ceph; на данном этапе ваш кластер должен быть работоспособным:

	[root@ceph-nodel ceph]# ceph -s
	    cluster aade8340-a44b-45f5-9679-39442daea18d
	     health HEALTH_OK
		 monmap e3: 3 mons at {ceph-nodel.192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0}, election epoch 10, quorum 0,1,2 ceph-nodel,ceph-node2,c eph-node3
		 osdmap e64: 9 osds: 9 up, 9 in
		  pgmap v189: 256 pgs, 1 pools, 0 bytes data, 0 objects
		        317 MB used, 45663 MB / 45980 MB avail
				     256 active+clean
	[root@ceph-nodel ceph]#

 Практическое применение кластера Ceph

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

  Как это сделать...

Проверьте состояние своей установки Ceph:

# ceph -s
or
# ceph status

Проверьте работосопсобность кластера:

# ceph -w

Проверьте состояние кворума монитора Ceph:

# ceph mon dump

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

# ceph df

Проконтролируйте статистику ваших мониторов, OSD и групп размещения Ceph:

# ceph mon stat
# ceph osd stat
# ceph pg stat

Выведите перечень групп размещения:

# ceph pg dump

Выведите список ваших пулов Ceph:

# ceph osd lspools

Попробуйте просмотреть карту CRUSH OSD:

# ceph osd tree

Выведите перечень ключей аутентификации вашего кластера:

# ceph osd tree

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

Глава 2. Работа с блочными устройствами Ceph

В данной главе мы охватим:

Работу с блочными устройствами Ceph

Настройку клиента Ceph

Создание блочного устройства Ceph

Отображение блочного устройства Ceph

Изменение размеров RBD Ceph

Работу со снимками RBD

Работу с клонами RBD

Быстрый осмотр OpenStack

Ceph - наилучшее соответствие OpenStack

Настройку OpenStack

Настройку OpenStack в качестве клиента Ceph

Настройку Glance под поддержку Ceph

Настройку Cinder под поддержку Ceph

Настройку Nova для подключения Ceph RBD

Настройку Nova для загрузки экземпляров из Ceph RBD

Содержание

2. Работа с блочными устройствами Ceph

Введение

Работа с блочными устройствами Ceph

Настройка клиента Ceph

Создание блочного устройства Ceph

Отображение блочного устройства Ceph

Изменение размеров RBD Ceph

Работа со снимками RBD

Работа с клонами RBD

Быстрый осмотр OpenStack

Ceph - наилучшее соответствие OpenStack

Настройка OpenStack

Настройка OpenStack в качестве клиента Ceph

Настройка Glance под поддержку Ceph

Настройка Cinder под поддержку Ceph

Настройка Nova для подключения Ceph RBD

Настройка Nova для загрузки экземпляров из Ceph RBD

 Введение

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

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

Рисунок 2.1. Форматы хранения Ceph и варианты применения

Мы обсудим в этой книге все варианты, однако в данной главе мы сосредоточимся на блочных хранилищах Ceph.

 Работа с блочными устройствами Ceph

Блочные устройства Ceph (Ceph Block Device), ранее называвшиеся блочными устройствами RADOS, предоставляют клиентам надёжные распределённые и высокопроизводительные блочные диски хранения. Блочные устройства хранения RADOS применяют библиотеку librbd и хранят блоки данных в последовательном виде чередуя их по множеству OSD в кластере Ceph. RBD поддерживаются уровнем RADOS в Ceph, таким образом каждое блочное устройство распределяется по множеству узлов Ceph, поставляя высокую производительность и исключительную надёжность. RBD имеет встроенную поддержку для ядра Linux, что означает, что драйверы RBD хорошо интегрированы с ядром Linux на протяжении последних нескольких лет. Помимо надёжности и производительности RBD также предоставляет функциональность корпоративного уровня подобную полным и инкрементальным снимкам, динамичному выделению (thin provisioning), клонированию копированием при записи (copy on write), динамическое изменение размеров и тому подобное. RBD также поддерживает кэширование в памяти, которое драматично улучшает производительность.

Рисунок 2.2. Форматы хранения Ceph и варианты применения

Лидеры в индустрии гипервизоров с открытым исходным кодом, подобные KVM и Zen {Прим. пер.: а также, например, набирающий популярность Proxmox}, предоставляют полную поддержку RBD и повышают мощь функциональности своих гостевых виртуальных машин. Прочие проприетарные гипервизоры, например, VMWare и Microsoft HyperV будут поддерживать их в скором времени. Для поддержки этих гипервизоров в сообществе была проведена колоссальная работа. Блочные устройства Ceph предоставляют полную поддержку облачным платформам, таким как OpenStack, Cloud Stack и ряду других {Прим. пер.: например, Proxmox}. Для этих облачных платформ были доказаны успешность и функциональная полнота. В OpenStack вы можете применять блочные устройства Ceph с компонентами cinder (для блоков) и glance (для образов). Работая таким образом вы можете раскручивать тысячи Виртуальных Машин (ВМ, VM) за очень короткие промежутки времени, применяя преимущества функциональности копирования при записи блочных устройств Ceph.

Вся эта функциональность делает RBD идеальным кандидатом для облачных платформ OpenStack, CloudStack {Прим. пер.: Proxmox и прочих}. Теперь мы изучим как создавать блочные устройства Ceph и применять их.

 Настройка клиента Ceph

Все обычные хосты Linux (RHEL или основанные на Debian) могут выступать в роли клиентов Ceph. Клиент взаимодействует с кластером хранения Ceph через сетевую среду для сохранения или выборки данных пользователя. Поддержка RBD Ceph была добавлена в магистральное ядро Linux, начиная с 2.6.34 и последующих версий.

  Как это сделать...

Как мы это уже делали ранее, мы установим машину клиента Ceph с применением Vagrant и VirtualBox. Мы воспользуемся тем же самым Vagrantfile, который мы клонировали в нашей прошлой главе. Затем Vagrant запустит виртуальную машину Ubuntu 14.04, которую мы настроим в качестве клиента Ceph:

Из каталога, в который мы клонировали ceph-cookbook git repository, запустим клиентскую машину с помощью Vagrant:

$ vagrant status client-node1
$ vagrant up client-node1

	HOST:ceph-cookbook ksinghS vagrant status client-node1
	Current machine states:

	client-node1              not created (virtualbox)

	The environment has not yet been created. Run `vagrant up` to
	create the environment. If a machine is not created, only the
	default provider will be shown. so if a provider is not listed,
	then the machine is not created for that environment.
	HOST:ceph-cookbook ksinghS vagrant up client-node1
	Bringing machine 'client-node1' up with 'virtualhox' provider...
	==> client-node1: Importing base box 'ubuntu/trusty64'...
	==> client-node1: Matching MAC address for NAT networking...
	==> client-node1: Checking if box 'ubuntu/trusty64' is up to date...
	==> client-node1: setting the name of the vm: client-node1

Зарегистрируйтесь на ceph-node1:

$ vagrant ssh client-node1

[Замечание]
Замечание

Имя и пароль которые Vagrant применяет для настройки виртуальной машины vagrant и Vagrant имеет права sudo. Пароль по умолчанию для пользователя root установлен в vagrant.

Проверьте редакции ОС и ядра (это не является обязательным):

$ lsb_release -a
$ uname -r

Убедитесь что RBD поддерживается ядром:

$ sudo modprobe rbd

	vagrant@client-node1:~$ lsb_release -a
	No LSB modules are available.
	Distributor ID: Ubuntu
	Description: Ubuntu 14.04.2 LTS
	Release: 14.04
	Codename: trusty
	vagrant@client-node1:~$
	vagrant@client-node1:~$ uname -r
	3.13.0-46-generic
	vagrant@client-node1:~$
	vagrant@client-node1:~$ sudo modprobe rbd
	vagrant@client-node1:~$ echo $?
	0
	vagrant@client-node1:~$

Разрешите доступ машины монитора ceph-node1 к client-node1 через ssh. Для этого скопируйте ключи ssh root с ceph-node1 на client-node1 пользователя Vagrant. Выполните следующие команды на машине ceph-node1 если не предписано другого:

## Login to ceph-node1 machine
$ vagrant ssh ceph-node1
$ sudo su -
# ssh-copy-id vagrant@client-node1

Предоставьте одноразовый пароль пользователя Vagrant, т.е. vagrant для ceph-node1. Когда ключи ssh скопированы с ceph-node1 на client-node1, вы должны получить возможность регистрироваться на client-node1 без пароля.

Для установки исполняемых файлов Ceph на client-node1 выполните ceph-deploy на ceph-node1:

# cd /etc/ceph
# ceph-deploy --username vagrant install client-node1

	[root@client-node1 ceph]# ceph-deploy --username vagrant install client-node1
	[ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf
	[ceph_deploy.cli][INFO ] Invoked (1.5.22): /bin/ceph-deploy --username vagrant install client-node1
	[ceph_deploy.install][DEBUG ] Installing stable version giant on cluster ceph hosts client-node1
	[ceph_deploy.install][DEBUG ] Detecting platform for host client-node1
	[client-node1][DEBUG ] connection detected need for sudo
	[client-node1][DEBUG ] connected to host: vagrant@client-node1
	[client-node1][DEBUG ] detect platform information from remote host
	[client-node1][DEBUG ] detect machine type
	[ceph_deploy.install][INFO ] Distro info: ubuntu 14.04 trusty
	[client-node1][INFO ] installing ceph on client-node1

Скопируйте файл настроек (ceph.conf) на client-node1:

# ceph-deploy --username vagrant config push client-node1

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

В нашем случае мы создадим пользователя Ceph client.rbd с правом доступа к пулу rbd. По умолчанию, блочные устройства Ceph создаются в пуле rbd:

# ceph auth get-or-create client.rbd mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=rbd'

	[root@ceph-node1 ceph]# ceph auth get-or-create client.rbd mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=rbd'
	[client.rbd]
	        key = AQCLEg5VeAbGARAAE4ULXC7M$Fwd3BGFDiHRTw==
	[root@client-node1 ceph]#

Добавьте ключ на машине client-node1 для пользователя client.rbd:

# ceph auth get-or-create client.rbd | ssh vagrant@client-node1 sudo tee /etc/ceph/ceph.client.rbd.keyring

	[root@client-node1 ceph]# ceph auth get-or-create client.rbd | ssh vagrant@client-node1 sudo tee /etc/ceph/ceph.client.rbd.keyring
	[client.rbd]
	        key = AQCLEg5VeAbGARAAE4ULXC7M$Fwd3BGFDiHRTw==
	[root@client-node1 ceph]#

На данном этапе client-node1 должен быть готов к работе в качестве клиента Ceph. Проверьте состояние на машине client-node1 предоставив имя пользователя и ключ безопасности:

$ vagrant ssh client-node1
$ sudo su -
# cat /etc/ceph/ceph.client.rbd.keyring >> /etc/ceph/keyring
### Since we are not using the default user client.admin we need
to supply username that will connect to Ceph cluster.
# ceph -s --name client.rbd

	root@client-node1:~# ceph -s --name client.rbd
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
		health HEALTH_OK
		monmap e3: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0, ceph-node3=192.168.1.103:6789/0}, election epoch 82, quorum 0,1,2 ceph-node1,ceph-node2,cep h-node3
		osdmap e142: 9 osds: 9 up, 9 in
		 pgmap v378: 180 pgs, 1 pools, 0 bytes data, 0 objects
		       322 MB used, 134 GB / 134 GB avail
	                180 active+clean
	root@client-node1:~#

 Создание блочного устройства Ceph

На текущий момент у нас имеется настроенный клиент Ceph, и мы сейчас можем продемонстрировать создание блочного устройства Ceph с машины client-node1.

  Как это сделать...

Создайте блочное устройство RADOS с именем rbd1 и размером 10240МБ:

# rbd create rbd1 --size 10240 --name client.rbd

Существует множество вариантов отображения списка образов RBD:

## The default pool to store block device images is "rbd", you can
also specify the pool name with the rbd command using -p option:
# rbd ls --name client.rbd
# rbd ls -p rbd --name client.rbd
# rbd list --name client.rbd

Осмотрите подробности образа rbd:

# rbd --image rbd1 info --name client.rbd

	root@client-node1:~# rbd create rbdl --size 10240 --name client.rbd
	root@client-node1:~# rbd is --name client.rbd
	rbdl
	root@client-node1:~# rbd --image rbdl info --name client.rbd
	rbd image 'rbdl':
	        size 10240 MB in 2560 objects
	        order 22 (4096 kB objects)
	        block_name_prefix: rb.0.14f1.238e1f29
	        format: 1
	root@client-node1:~#

 Отображение блочного устройства Ceph

Теперь когда у нас есть созданное блочное устройство в кластере Ceph, чтобы воспользоваться этим блочным устройством нам надо отобразить его на клиентской машине. Чтобы достичь этого, выполните следующие команды на машине client-node1.

  Как это сделать...

Отобразите ваше блочное устройство на client-node1:

# rbd map --image rbd1 --name client.rbd

Проверьте отображённое блочное устройство:

# rbd showmapped --name client.rbd

	root@client-node1:~# rbd map --image rbdl --name client.rbd /dev/rbdl
	root@client-node1:—# rbd showmapped --name client.rbd
	id pool image snap device
	1  rbd  rbdl  -    /dev/rbdl
	root@client-node1:~#

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

# fdisk -l /dev/rbd1
# mkfs.xfs /dev/rbd1
# mkdir /mnt/ceph-disk1
# mount /dev/rbd1 /mnt/ceph-disk1
# df -h /mnt/ceph-disk1

	root@client-node1:~# df -h /mnt/ceph-diskl
	Filesystem      Size  Used Avail Use% Mounted on
	/dev/rbdl        10G   33M   10G   1% /mnt/ceph-diskl
	root@client-node1:~#

Проверьте блочное устройство записав на него данные:

# dd if=/dev/zero of=/mnt/ceph-disk1/file1 count=100 bs=1M

	root@client-node1:~# dd if=/dev/zero of=/mnt/ceph-disk1/file1 count=100 bs=1M
	100+0 records in
	100+0 records out
	104857600 bytes (105 MB) copied, 7.16309 s, 14.6 MB/s
	root@client-node1:~# df -h /mnt/ceph-disk1
	Filesystem      Size  Used Avail Use% Mounted on
	/dev/rbdl        10G  133M  9.9G   2% /mnt/ceph-disk1
	root@client-node1:~#

Чтобы отображать блочное устройство после перезагрузок, вам следует добавить сценарий init-rbdmap в запуск системы, добавьте пользователя Ceph и подробности кольца ключей (keyring) в /etc/ceph/rbdmap, и, наконец, обновите файл /etc/fstab:

# wget https://raw.githubusercontent.com/ksingh7/ceph-cookbook/master/rbdmap -O /etc/init.d/rbdmap
# chmod +x /etc/init.d/rbdmap
# update-rc.d rbdmap defaults

## Make sure you use correct keyring value in /etc/ceph/rbdmap file, which is generally unique for an environment.
# echo "rbd/rbd1 id=rbd,keyring=AQCLEg5VeAbGARAAE4ULXC7M5Fwd3BGFDiHRTw==" >> /etc/ceph/rbdmap
# echo "/dev/rbd1 /mnt/ceph-disk1 xfs defaults, _netdev 0 0 " >> /etc/fstab
# mkdir /mnt/ceph-disk1
# /etc/init.d/rbdmap start

 Изменение размеров RBD Ceph

Ceph поддерживает динамично выделяемые (thin provisioned) блочные устройства, что означает, что физическое пространство хранения не занимается пока вы не начинаете сохранять данные на свои блочные устройства. Ваши блочные устройства Ceph очень гибки; вы можете увеличивать или уменьшать размер RBD на лету со стороны хранилища Ceph. Однако, лежащие в основе файловые системы должны поддерживать изменение размеров. Современные файловые системы, такие как XFS, Btrfs, EXT, ZFS и другие поддерживают изменение размера файловой системы до определённой степени. Для получения дополнительной информации об изменении размера, пожалуйста, обратитесь к соответствующей документации по файловой системе.

  Как это сделать...

Для увеличения или уменьшения размера образа RBD Ceph воспользуйтесь параметром --size <New_Size_in_MB> в команде rbd resize, она тогда установит новый размер для вашего образа RBD:

Первоначальный размер созданного нами ранее образа RBD составляло 10ГБ. Теперь мы увеличим его размер до 20ГБ:

# rbd resize --image rbd1 --size 20480 --name client.rbd
# rbd info --image rbd1 --name client.rbd

	rootgclient-node1:~# rbd resize --image rbdl --size 20480 --name client.rbd
	Resizing image: 100% complete...done.
	rootgclient-node1:~# rbd info --image rbdl --name client.rbd
	rbd image 'rbdl':
	        size 20480 MB in 5120 objects
	        order 22 (4096 kB objects)
	        block_name_prefix: rb.0.14f1.238e1f29
	        format: 1
	root@client-node1:~#

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

# dmesg | grep -i capacity
# xfs_growfs -d /mnt/ceph-disk1

	root@client-node1:~# xfs_growfs -d /mnt/ceph-diskl
	meta-data=/dev/rbd1              isize=256    agcount=17, agsize=162816 blks
	         =                       sectsz=512   attr=2
	data     =                       bsize=4096   blocks=2621440, imaxpct=25
	         =                       sunit=1024   swidth=1024 blks
	naming   =version 2              bsize=4096   ascii-ci=0
	log      =internal               bsize=4096   blocks=2560, version=2
	         =                       sectsz=512   sunit=8 blks, lazy-count=1
	realtime =none                   extsz=4096   blocks=0, rtextents=0
	data blocks changed from 2621440 to 5242880
	root@client-node1:~# df -h /mnt/ceph-disk1
	Filesystem      Size  Used Avail Use% Mounted on
	/dev/rbdl        20G  134M   20G   1% /mnt/ceph-disk1
	root@client-node1:~#

 Работа со снимками RBD

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

  Как это сделать...

Давайте рассмотрим как работает снимок в Ceph.

Чтобы проверить функциональность снимка Ceph давайте создадим в сделанном нами ранее блочном устройстве некий файл:

# echo "Hello Ceph This is snapshot test" > /mnt/ceph-disk1/snapshot_test_file

	root@client-node1:~# echo "Hello Ceph This is snapshot test" > /mnt/ceph-disk1/snapshot_test_file
	root@client-node1:~# is -1 /mnt/ceph-disk1
	total 102404
	rw r r 1 root root 104857600 Mar 22 16:07 file1
	rw r r 1 root root 33 Mar 22 21:45 snapshot_test_file
	root@client-node1:~#
	root@client-node1:~# cat /mnt/ceph-disk1/snapshot_test_file
	Hello Ceph This is snapshot test
	root@client-node1:~#

Создайте снимок для блочного устройства Ceph:

Синтаксис: rbd snap create <pool-name>/<image-name>@<snap-name>
# rbd snap create rbd/rbd1@snapshot1 --name client.rbd

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

Синтаксис: rbd snap ls <pool-name>/<image-name>
# rbd snap ls rbd/rbd1 --name client.rbd

	root@client-node1:~# rbd snap create rbd/rbdl@snapshotl --name client.rbd
	root@client-node1:~# rbd snap is rbd/rbdl --name client.rbd
	SNAPID NAME              SIZE
	     2 snapshot1     20480 MB
	root@client-node1:~#

Чтобы проверить функциональность восстановления снимка Ceph давайте удалим в файловой системе файлы:

# rm -f /mnt/ceph-disk1/*

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

Синтаксис: rbd snap rollback <pool-name>/<image-name>@<snap-name>
# rbd snap rollback rbd/rbd1@snapshot1 --name client.rbd

По окончанию операции отката снимка перемонтируйте файловую систему RBD Ceph для обновления состояния файловой системы. Вы должны иметь возможность получить назад свои удалённые файлы:

# umount /mnt/ceph-disk1
# mount /dev/rbd1 /mnt/ceph-disk1
# ls -l /mnt/ceph-disk1

	root@client-node1:~# rbd snap rollback rbd/rbd1@snapshot1 --name client.rbd
	Rolling back to snapshot: 100% complete...done.
	root@client-node1:~# umount /mnt/ceph-disk1
	root@client-node1:~# mount /dev/rbd1 /mnt/ceph-disk1
	root@client-node1:~# is /mnt/ceph-disk1
	total 102404
	-rw-r--r-- 1 root root 104857600 Mar 22 16:07 file1
	-rw-r--r-- 1 root root 33 Mar 22 21:45 snapshot_test_file
	root@client-node1:~#

Когда вам больше не нужны снимки, вы можете удалять определённый снимок с применением следующего синтаксиса. Удаление снимка не удаляет текущие данные в вашем образе RBD Ceph:

Синтаксис: rbd snap rm <pool-name>/<image-name>@<snap-name>
# rbd snap rm rbd/rbd1@snapshot1 --name client.rbd

Если у вас имеется множество снимков образов RBD и вы хотите удалить их все одной командой, тогда применяйте подкоманду purge:

Синтаксис: rbd snap purge <pool-name>/<image-name>
# rbd snap purge rbd/rbd1 --name client.rbd

 Работа с клонами RBD

Ceph поддерживает очень приятную возможность для создания копируемых- при- записи (COW, Copy-On-Write {Прим. пер.: при изменении новых данных эти данные вначале копируются в новую область}) клонов из снимков RBD. Эту операцию в Ceph также называют расслоением снимков (Snapshot Layering). Расслоение делает возможным клиентам создавать множественные экземпляры клонов RBD Ceph. Данная функциональность чрезвычайно полезна для облачных и виртуальных платформ, таких как {Прим. пер.: например, OpenStack}, CloudStack, Qemu/KVM и тому подобных {Прим. пер.: например, Proxmox}. Эти платформы обычно предохраняют содержащие отображение ОС/ВМ образы RBD Ceph в виде снимка. Позже этот снимок многократно клонируется для порождения новых виртуальных машин/ экземпляров. Снимки являются доступными только для чтения, однако COW клоны полностью доступны для записи; данная функциональность Ceph предоставляет более высокий уровень гибкости и чрезвычайно полезна в облачных платформах. В последующих главах мы дополнительно исследуем клоны COW при порождении экземпляров OpenStack:

Рисунок 2.3. COW клоны снимка

Каждый клонируемый образ (дочерний образ) сохраняет ссылки своих родительских снимков для чтения данных образа. Следовательно, ваш родительский снимок должен быть защищён перед его применением для клонирования. В момент записи данных в клонируемый COW образ он сохраняет ссылочные данные на себя. Клонируемые COW образы так же хороши как RBD. Они точно так же гибки, как и RBD, что означает, что они доступны для записи, а также поддерживают снимки и дальнейшее клонирование.

Образы в Ceph бывают двух типов: format-1 и format-2. Функциональность RBD доступна в обоих типах, а именно, как в образах RBD format-1, так и в образах RBD format-2. Однако, функциональность расслоения (свойство клонирования COW) доступна только для образа RBD в format-2. Форматом образа RBD по умолчанию является format-1.

  Как это сделать...

Для демонстрации клонирования RBD мы намеренно создадим образ RBD format-2, затем создадим и защитим его снимок и, наконец, создадим из него клоны COW.

Создайте образ RBD format-2 и осмотрите его детали:

# rbd create rbd2 --size 10240 --image-format 2 --name client.rbd
# rbd info --image rbd2 --name client.rbd

	root@client-node1:/# rbd create rbd2 --size 10240 --image-format 2 --name client.rbd
	root@client-node1:/#
	root@client-node1:/# rbd info --image rbd2 --name client.rbd
	rbd image 'rbd2':
	        size 10240 MB in 2560 objects
	        order 22 (4096 kB objects)
	        block_name_prefix: rbd_data.20f42ae8944a
	        format: 2
	        features: layering
	root@client-node1:/#

Создайте снимок этого образа RBD:

# rbd snap create rbd/rbd2@snapshot_for_cloning --name client.rbd

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

# rbd snap protect rbd/rbd2@snapshot_for_cloning --name client.rbd

Далее при помощи этого снимка мы создадим клонированный образ RBD:

Синтаксис: rbd clone <pool-name>/

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

# rbd info rbd/clone_rbd2 --name client.rbd

	root@client-node1:/# rbd snap create rbd/rbd2@snapshot_for_cloning --name client.rbd
	root@client-node1:/# rbd snap protect rbd/rbd2@snapshot_for_cloning --name client.rbd
	root@client-node1:/# rbd clone rbd/rbd2@snapshot_for_cloning rbd/clone_rbd2 --name client.rbd
	root@client-node1:/# rbd info rbd/clone_rbd2 --name client.rbd
	rbd image 'clone_rbd2':
	        size 10240 MB in 2560 objects
	        order 22 (4096 kB objects)
	        block_name_prefix: rbd_data.220b3d1b58ba
	        format: 2
	        features: layering
	        parent: rbd/rbd2@snapshot_for_cloning
	        overlap: 10240 MB
	root@client-node1:/#

На данный момент у нас имеется клонированный образ RBD, который зависит от своего снимка образа родителя. Чтобы сделать клонированный образ RBD независимым от его родителей нам нужно выровнять (flatten) этот образ, которое выполнит копирование данных из родительского снимка в его дочерний образ. Время, которое займет выполнение процесса выравнивания зависит от размера данных, расположенных в родительском снимке. Когда процесс выравнивания завершится, зависимости между клонированным образом и его родительским снимком больше не будет.

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

# rbd flatten rbd/clone_rbd2 --name client.rbd
# rbd info --image clone_rbd2 --name client.rbd

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

	root@client-node1:/# rbd flatten rbd/clone_rbd2 --name client.rbd
	Image flatten: 100% complete...done.
	root@client-node1:/# rbd info --image clone_rbd2 --name client.rbd rbd
	image 'clone_rbd2':
	    size 10240 MB in 2560 objects
		order 22 (4096 kB objects)
		block_name_prefix: rbd_data.220b3d1b58ba
		format: 2
		features: layering
	root@client-node1:/#

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

# rbd snap unprotect rbd/rbd2@snapshot_for_cloning --name client.rbd

Когда со снимка снята защита, вы можете удалить его: purge:

Синтаксис: rbd snap purge <pool-name>/<image-name>
# rbd snap rm rbd/rbd2@snapshot_for_cloning --name client.rbd

 Быстрый осмотр OpenStack

OpenStack является платформой с открытым исходным кодом для построения и управления общедоступной и частной облачной инфраструктуры. Он управляется независимым, некоммерческим фондом, называемым фондом OpenStack. Это самое большое и наиболее активное сообщество, которое поддерживается такими технологическими гигантами как HP, Red Hat, Dell, Cisco, IBM, Rackspace и многими другими. Идея OpenStack для облачных решений состоит в том, что оно должно быть простым в реализации и массивно масштабируемым.

OpenStack рассматривается как облачная операционная система в которой пользователи имеют возможность мгновенно развёртывать сотни виртуальных машин автоматизированным способом. Она также предоставляет эффективный способ заботы о бесплатном управлении этими машинами. OpenStack своим динамичным увеличения и уменьшения в масштабе, а также возможностями распределённой архитектуры, которые делают вашу облачную среду надёжной и готовой к будущему. OpenStack представляет платформу инфраструктуры- как- службы (IaaS, Infrastructure-as-a-Service) для любых ваших потребностей в облачных решениях.

Рисунок 2.4. Компоненты OpenStack

Как показано на приведённой выше схеме, OpenStack состоит из отдельных различных программных компонентов, которые совместно работают для предоставления служб облака. В данной главе из всех этих компонент мы сосредоточимся на Cinder и Glance, которые соответственно предоставляют службы блочного хранения и образов. Для получения дополнительной информации по компонентам, пожалуйста, обращайтесь к http://www.openstack.org/ {Прим. пер.: у нас на сайте вы можете ознакомиться с переводом 2й редакции OpenStack Operations Guide (на момент перевода данной книги доступна 3я редакция: 2016-03-03, последняя версия достуна тут )}.

 Ceph - наилучшее соответствие OpenStack

В последние несколько лет OpenStack приобрёл впечатляющую популярность благодаря своей основанной на программно определяемой поддержке широкого диапазона вычислений, сетевых сред и даже систем хранения. И когда вы рассуждаете о системах хранения для OpenStack, Ceph привлекает всё внимание. Проведённый в сентябре 2015г опрос пользователей OpenStack показал, что Ceph доминирует на рынке устройств блочного хранения с колоссальными 62% применения.

Ceph предоставляет устойчивую, нодёжную основу хранения, которую искал OpenStack. Его бесшовная интеграция с компонентами OpenStack такими, как cinder, glance, nova и keystone предоставляет всю- в- одном основу хранения для OpenStack. Вот некоторые ключевые преимущества, делающие Ceph наилучшим соответствием для OpenStack:

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

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

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

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

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

Она предоставляет томам OpenStack функциональность снимков, которая может также применяться как средство резервного копирования.

Функциональность клонирования копированием- при- записи (COW) Ceph позволяет OpenStack раскручивать множество экземпляров за один раз, что помогает быстрее работать механизму продвижения.

Ceph поддерживает богатые API как для интерфейсов хранения объектов Swift, так и для S3.

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

OpenStack является модульной системой, которая имеет уникальные компоненты для особых наборов задач. Существуют различные компоненты, которым требуется надёжная основа для хранения, подобная Ceph, и расширяющая полную интеграцию в неё, как отображено на следующей схеме. Все эти компоненты используют Ceph для своих собственных потребностей в хранении блочных устройств и объектов. Большинство основанных на OpenStack и Ceph облачных решений применяют интеграцию Cinder, Glance и Swift c Ceph. Интеграция с Keystone применяется когда вам нужна S3- совместимость хранения объектов в вашей поддержке Ceph. Интеграция Nova делает возможной загрузку с томов Ceph для ваших экземпляров OpenStack.

Рисунок 2.5. Интегрированные в Ceph компоненты OpenStack

 Настройка OpenStack

Установка и настройка OpenStack выходят за пределы рассмотрения данной книги, однако, просто для демонстрации мы применим виртуальную машину с предустановленной редакцией OpenStack RDO Juno. Если вы захотите, вы можете использовать вашу собственную среду OpenStack и можете выполнить интеграцию Ceph. {Прим. пер.: отсылаем к нашему переводу Руководства по эксплуатации OpenStack за подробностями инициализации и развертывания.}

  Как это сделать...

В этом рецепте мы продемонстрируем как установить предварительно настроенную среду OpenStack с применением Vagrant и получить к ней доступ через CLI и GUI.

Запустите openstack-node1 применив Vagrantfile как мы это делали для узлов Ceph в предыдущей главе. Убедитесь, что вы находитесь на машине хоста и под репозиторием ceph-cookbook прежде чем поднимете openstack-node1 с помощью Vagrant:

# cd ceph-cookbook
# vagrant up openstack-node1

	HOST:ceph-cookbook ksingh$ vagrant up openstack-node1
	Bringing machine 'openstack-node1' up with 'virtualbox' provider...
	==> openstack-node1: Clearing any previously set forwarded ports...
	==> openstack-node1: Clearing any previously set network interfaces...
	=> openstack-node1: Preparing network interfaces based on configuration...
	      openstack-node1:
	      Adapter 1: nat openstack-node1:
	      Adapter 2: hostonly
	=> openstack-node1: Forwarding ports...
	      openstack-node1: 22
	=> 2222 (adapter 1)
	=> openstack-node1: Running 'pre-boot' VM customizations...
	=> openstack-node1: Booting vm...
	=> openstack-node1: waiting for machine to boot. This may take a few minutes...

Когда openstack-node1 запущен, проверьте состояние Vagrant, а затем зарегистрируйтесь на этом узле:

$ vagrant status openstack-node1
$ vagrant ssh openstack-node1

	HOST:ceph-cookbook ksingh$ vagrant status openstack-node1
	Current machine states:

    openstack-node1           running (virtualbox)

    The VM is running. To stop this vm, you can run `vagrant halt` to
	shut it down forcefully, or you can run `vagrant suspend` to simply
	suspend the virtual machine. In either case, to restart it again,
	simply run `vagrant up`.
	HOST:ceph-cookbook ksingh$
	HOST:ceph-cookbook ksingh$
	HOST:ceph-cookbook ksingh$ vagrant ssh openstack-node1
	Last login: Sat Mar 28 21:38:07 2015 from 10.0.2.2
	[vagrant@os-node1 ~]$

Мы предполагаем, что у вас есть некое понимание OpenStack и представление о его работе. Мы подключим файл keystone_admin, который был размещён в /root, а затем нам нужно переключиться в корень:

$ sudo su -
$ source keystone_admin

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

# nova list
# cinder list
# glance image-list

	[vagrant@os-node1 ~]$ sudo su -
	Last login: Sat Mar 28 22:34:52 EET 2015 on pts/0
	[root@os-node1 ~]# source keystonerc_admin
	[root@os-node1 ~(keystone_admin)]#
	[root@os-node1 ~(keystone_admin)]# nova list
	+----+------+--------+------------+-------------+----------+
	| ID | Name | Status | Task State | Power State | Networks |
	+----+------+--------+------------+-------------+----------+
	+----+------+--------+------------+-------------+----------+
	[root@os-node1 ~(keystone_admin)]#
	[root@os-node1 ~(keystone_admin)]# cinder list
	+----+--------+--------------+------+-------------+----------+-------------+
	| ID | Status | Display Name | Size | Volume Type | Bootable | Attached to |
	+----+--------+--------------+------+-------------+----------+-------------+
	+----+--------+--------------+------+-------------+----------+-------------+
	[root@os-node1 ~(keystone_admin)]# glance image-list
	+--------------------------------------+--------+-------------+------------------+----------+--------+
	| ID                                   | Name   | Disk Format | Container Format | Size     | Status |
	| Sc261af7-9388-44ad-a8ce-f9ebdad2e5cb | cirros I qcow2       | bare             | 13200896 | active |
	+--------------------------------------+--------+-------------+------------------+----------+--------+
	[root@os-node1 ~(keystone_admin)]#

Вы можете также зарегистрироваться в веб- интерфейсе horizon OpenStack https://192.168.1.111/dashboard с именем пользователя admin и паролем vagrant.

После регистрации мы откроем страницу Общего обзора:

 Настройка OpenStack в качестве клиента Ceph

Узлы OpenStack должны быть настроены клиентами Ceph чтобы получить доступ к кластеру Ceph. Для этого установите пакеты Ceph на узлах OpenStack и проверьте что вы можете осуществить доступ к кластеру Ceph.

  Как это сделать...

В данном рецепте мы собираемся настроить OpenStack в качестве клиента Ceph, который позжебудет использоваться для настройки cinder, glance и nova:

Мы воспользуемся ceph-node1 для установки исполняемых файлов Ceph на os-node1 с использованием ceph-deploy, как мы это уже делали ранее в Главе 1. Введение и за его пределами. Чтобы сделать это, мы должны установить регистрацию ssh без пароля для os-node1. Пароль для root опять тот же (vagrant ):

$ vagrant ssh ceph-node1
$ sudo su -
# ping os-node1 -c 1
# ssh-copy-id root@os-node1

	HOST:ceph-cookbook ksingh$ vagrant ssh ceph-node1
	Last login: Sun mar 29 11:27:53 2015 from 10.0.2.2
	[vagrant@ceph-node1 ~]$ sudo su -
	Last login: Sun Mar 29 11:27:57 EEST 2015 on pts/1
	[root@ceph-node1 ~]# ping os-node1 -c 1
	PING os-node1.cephcookbook.com (192.168.1.111) 56(84) bytes of data.
	64 bytes from os-node1.cephcookbook.com (192.168.1.111): icmp_seq=1 tt1=64 time=0.568 ms

	--- os node1.cephcookbook.com ping statistics ---
	1 packets transmitted, 1 received, 0% packet loss, time 0ms
	rtt min/avg/max/mdev = 0.568/0.568/0.568/0.000 ms
	[root@ceph-node1 ~]# ssh-copy-id root@os-node1
	/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
	/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
	root@os-node1's password:

	Number of key(s) added: 1

	Now try logging into the machine, with: "ssh 'root@os-node1'"
	and check to make sure that only the key(s) you wanted were added.

	[root@ceph-node1 ~]#

Далее мы установим пакеты Ceph на os-node1 с применением ceph-deploy:

# cd /etc/ceph
# ceph-deploy install os-node1

	[root@ceph-node1 ~]# cd /etc/ceph
	[root@ceph-node1 ceph]# ceph-deploy install os-node1
	[ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf
	[ceph_deploy.cli][INFO ] Invoked (1.5.22): /bin/ceph-deploy install os-node1
	[ceph_deploy.install][DEBUG ] Installing stable version giant on cluster ceph hosts os-node1
	[ceph_deploy.install][DEBUG ] Detecting platform for host os-node1
	[os-node1][DEBUG ] connected to host: os-node1
	[os-node1][DEBUG ] detect platform information from remote host
	[os-node1][DEBUG ] detect machine type
	[ceph_deploy.install][INFO ] Distro info: centos Linux 7.0.1406 Core
	[os-node1][INFO ] installing ceph on os-node1

Пропихните файл настрое Ceph, ceph.conf с ceph-node1 на os-node1. Этот файл настроек поможет клиентам достигать мониторы Ceph и машины OSD. Заметьте, пожалуйста, что при желании вы также можете скопировать файл ceph.conf вручную на os-node1:

# ceph-deploy config push os-node1

[Замечание]
Замечание

Убедитесь что ваш помещённый на os-node1 файл ceph.conf имеет привилегии, установленные в значение 644.

	[root@ceph-node1 ceph]# ceph-deploy config push os-node1
	[ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf
	[ceph_deploy.cli][INFO ] Invoked (1.5.22): /bin/ceph-deploy config push os-node1
	[ceph_deploy.config][DEBUG ] Pushing config to os-node1
	[os-node1][DEBUG ] connected to host: os-node1
	[os-node1][DEBUG ] detect platform information from remote host
	[os-node1][DEBUG ] detect machine type
	[os-node1][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf
	[root@ceph-node1 ceph]#

Создайте пулы для cinder, glance и nova. Вы можете применить любой доступный пул, однако для компонентов OpenStack рекомендуется чтобы вы создавали отдельные пулы:

# ceph osd pool create images 128
# ceph osd pool create volumes 128
# ceph osd pool create vms 128

	[root@ceph-node1 ceph]# ceph osd pool create images 128
	pool 'images' created
	[root@ceph-node1 ceph]# ceph osd pool create volumes 128
	pool 'volumes' created
	[root@ceph-node1 ceph]# ceph osd pool create vms 128
	pool 'vms' created
	[root@ceph-node1 ceph]# ceph osd lspools
	0 rbd,1 images,2 volumes,3 vms,
	[root@ceph-node1 ceph]#

Установите аутентификацию клиента создав нового пользователя для cinder и glance:

# ceph auth get-or-create client.cinder mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes, allow rwx pool=vms, allow rx pool=images'
# ceph auth get-or-create client.glance mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=images'

	[root@ceph-node1 ceph]# ceph auth get-or-create client.cinder mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes, allow rwx pool=vms, allow rx pool=images'
	[client.cinder]
	        key = AQByVBhVMK2nLxAArOflyalhbc23N2kyZv0EXw==
	[root@ceph-node1 ceph]# ceph auth get-or-create client.glance mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=images'
	[client.glance]
	        key = AQCBVBhVYJEEKBAAhXHTe9Z12O2YyhMOjpga2A==
	[root@ceph-node1 ceph]#

Добавьте кольцо ключей на os-node1 и измените его владельца:

# ceph auth get-or-create client.glance | ssh os-node1 sudo tee /etc/ceph/ceph.client.glance.keyring
# ssh os-node1 sudo chown glance:glance /etc/ceph/ceph.client.glance.keyring
# ceph auth get-or-create client.cinder | ssh os-node1 sudo tee /etc/ceph/ceph.client.cinder.keyring
# ssh os-node1 sudo chown cinder:cinder /etc/ceph/ceph.client.cinder.keyring

	[root@ceph-node1 ceph]# ceph auth get-or-create client.glance | ssh os-node1 sudo tee /etc/ceph/ceph.client.glance.keyring
	[client.glance]
	        key = AQCBVBhVYJEEKBAAhXTe9Z12O2YyhM0jpga2A==
	[root@ceph-node1 ceph]# ssh os-node1 sudo chown glance:glance /etc/ceph/ceph.client.glance.keyring
	[root@ceph-node1 ceph]# ceph auth get-or-create client.cinder | ssh os-node1 sudo tee /etc/ceph/ceph.client.cinder.keyring
	[client.cinder] key = AQByVBhVMK2nLxAAr0f1yalhbc23N2kyZv0EXw==
	[root@ceph-node1 ceph]# ssh os-node1 sudo chown cinder:cinder /etc/ceph/ceph.client.cinder.keyring
	[root@ceph-node1 ceph]#

Процеессу libvirt необходим доступ к кластеру Ceph для присоединения или отсоединения блочных устройств от Cinder. Мы должны создать временную копию ключа client.cinder, который будет нужен для настроек cinder и nova позже в данной главе:

# ceph auth get-key client.cinder | ssh os-node1 tee /etc/ceph/temp.client.cinder.key

На данный момент вы можете проверить предыдущую настройку осуществив доступ к кластеру Ceph с os-node1 применив пользователей Ceph client.glance и client.cinder. Зарегистрируйтесь на os-node1 и выполните следующие команды:

$ vagrant ssh openstack-node1
$ sudo su -
# cd /etc/ceph
# ceph -s --name client.glance --keyring ceph.client.glance.keyring
# ceph -s --name client.cinder --keyring ceph.client.cinder.keyring

	HOST:ceph-cookbook ksingh$ vagrant ssh openstack-node1
	Last login: Sun Mar 29 22:55:20 2015 from 10.0.2.2
	[vagrant@os-node1 ~]$ sudo su -
	Last login: Sun Mar 29 22:55:35 EEST 2015 on pts/0
	[root@os-node1 ~]# cd /etc/ceph
	[root@os-node1 ceph]# ceph -s --name client.glance --keyring ceph.client.glance.keyring
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
		health HEALTH_OK
		monmap e3: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.1 68.1.103:6789/0}, election epoch 134, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
		osdmap e248: 9 osds: 9 up, 9 in
		 pgmap v1189: 564 pgs, 4 pools, 114 MB data, 2629 objects
		      745 MB used, 134 GB / 134 GB avail
			       564 active+clean
	[root@os-node1 ceph]#
	[root@os-node1 ceph]# ceph -s --name client.cinder --keyring ceph.client.cinder.keyring
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
		health HEALTH_OK
		monmap e3: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.1 68.1.103:6789/0}, election epoch 134, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
		osdmap e248: 9 osds: 9 up, 9 in
		 pgmap v1189: 564 pgs, 4 pools, 114 MB data, 2629 objects
		       745 MB used, 134 GB / 134 GB avail
			        564 active+clean
	[root@os-node1 ceph]#

Наконец создадим uuid, затем создадим, определим и установим ключ безопасности для libvirt и удалим временные ключи:

Создайте uuid воспользовавшись следующим:

# cd /etc/ceph
# uuidgen

Создайте файл безопасности и установите это число uuid в нём:

cat > secret.xml <<EOF
<secret ephemeral='no' private='no'>
  <uuid>bb90381e-a4c5-4db7-b410-3154c4af486e</uuid>
  <usage type='ceph'>
    <name>client.cinder secret</name>
  </usage>
</secret>
EOF

[Замечание]
Замечание

Убедитесь что вы используете свой собственный uuid сгенерированный для вашей среды.

Определите пароль и надёжно сохраните сгенерированное секретное значение. На последующих этапах нам понадобится это секретное значение:

# virsh secret-define --file secret.xml

	[root@os-node1 ~]# cd /etc/ceph
	[root@os-node1 ceph]# uuidgen
	bb90381e-a4c5-4db7-b410-3154c4af486e
	[root@os-node1 ceph]# cat > secret.xml <<EOF
	> <secret ephemeral='no' private='no'>
	> <uuid>bb90381e-a4c5-4db7-b410-3154c4af486e</uuid>
	> <usage type='ceph'>
	> <name>client.cinder secret</name>
	> </usage>
	> </secret>
	> EOF
	[root@os-node1 ceph]# virsh secret-define --file secret.xml
	Secret bb90381e-a4c5-4db7-b410-3154c4af486e created

	[root@os-node1 ceph]#

Установите секретное значение которое было сгенерировано на последнем шаге в virsh и удалите временные файлы. Удаление временных файлов не обязательно; оно выполняется просто для очистки системы:

# virsh secret-set-value --secret bb90381e-a4c5-4db7-b410-3154c4af486e --base64 $(cat temp.client.cinder.key) && rm temp.client.cinder.key secret.xml
# virsh secret-list

	[root@os-node1 ceph]# virsh secret-set-value --secret bb90381e-a4c5-4db7-b410-3154c4af486e --base64 $(cat temp.client.cinder.key) && rm temp.client.cinder.key secret.xml
	Secret value set

	rm: remove regular file 'temp.client.cinder.key'? y
	rm: remove regular file 'secret.xml'? y
	[root@os-node1 ceph]#
	[root@os-node1 ceph]# virsh secret-list
	 UUID                                  Usage
	----------------------------------------------------------------------------------
	bb90381e-a4c5-4db7-b410-3154c4af486e       ceph client.cinder secret
	[root@os-node1 ceph]#

 Настройка Glance под поддержку Ceph

Мы выполнили настройку необходимую со стороны Ceph. В этом рецепте мы настроим OpenStack glance для применения поддержки хранения Ceph.

  Как это сделать...

Этот рецепте расскажет о настройке компонентов glance OpenStack для хранения образов виртуальных машин в RBD Ceph:

Зарегистрируйтесь на os-node1, который является нашим узлом glance и отредактируйте /etc/glance/glance-api.conf для следующих изменений:

В разделе [DEFAULT] убедитесь в наличии следующих строк:

default_store=rbd
show_image_direct_url=True

Выполните следующую команду для проверки элементов:

# cat /etc/glance/glance-api.conf | egrep -i "default_store|image_direct"

	[root@os-node1 ceph]# cat /etc/glance/glance-api.conf | egrep -i "default_storelimage_direct"
	default_store=rbd
	show_image_direct_ur1=True
	[root@os-node1 ceph]#

В разделе [glance_store] убедитесь что следующие строки присутствуют в RBD Store Options:

stores = rbd
rbd_store_ceph_conf=/etc/ceph/ceph.conf
rbd_store_user=glance
rbd_store_pool=images
rbd_store_chunk_size=8

Выполните следующую команду для проверки предыдущих элементов:

# cat /etc/glance/glance-api.conf | egrep -v "#|default" | grep -i rbd

	[root@os-node1 ceph]# cat /etc/glance/glance-api.conf | egrep -v "#|default" | grep -i rbd
	stores = rbd
	rbd_store_ceph_conf=/etc/ceph/ceph.conf
	rbd_store_user=glance
	rbd_store_pool=images
	rbd_store_chunk_size=8
	[root@os-node1 ceph]#

Перезапустите службы glance OpenStack:

# service openstack-glance-api restart

Получите файл keystone_admin для OpenStack и выведите список образов glance:

# source /root/keystonerc_admin
# glance image-list

	[root@os-node1 ~]# source keystonerc_admin
	[root@os-node1 ~(keystone_admin)]#
	[root@os-node1 ~(keystone_admin)]# glance image-list
	+--------------------------------------+--------+-------------+------------------+----------+--------+
	| ID                                   | Name   | Disk Format | Container Format | Size     | Status |
	+--------------------------------------+--------+-------------+------------------+----------+--------+
	| 5c261af7-9388-44ad-a8ce-f9ebdad2eScb | cirros | qcow2       | bare             | 13200896 | active |
	+--------------------------------------+--------+-------------+------------------+----------+--------+
	[root@os-node1 ~(keystone_admin)]#

Загрузите из интернет образ cirros, который позже будет сохранён в Ceph:

# wget http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img

Добавьте новый образ glance с помощью следующей команды:

# glance image-create --name cirros_image --is-public=true --diskformat=qcow2 --container-format=bare < cirros-0.3.1-x86_64-disk.img

	[root@os-node1 ~(keystone_admin)]# glance image-create --name cirros_image --is-public=true --disk-format=qcow2 --container-format=bare < cirros-0.3.1-x86_64-disk.img
	+------------------+--------------------------------------+
	| Property         | Value                                |
	+------------------+--------------------------------------+
	| checksum         | d972013792949d0d3ba628fbe8685bce     |
	| container_format | bare                                 |
	| created_at       | 2015-03-30T10:17:58                  |
	| deleted          | False                                |
	| deleted_at       | None                                 |
	| disk_format      | qcow2                                |
	| id               | b2d15e34-7712-4f1d-b48d-48b924e79b0c |
	| is_public        | True                                 |
	| min_disk         | 0                                    |
	| min_ram          | 0                                    |
	| name             | cirros_image                         |
	| owner            | c9f87abe43ea49239313565ca74ebaa0     |
	| protected        | False                                |
	| size             | 13147648                             |
	| status           | active                               |
	| updated_at       | 2015-03-30T10:18:01                  |
	| virtual_size     | None                                 |
	+------------------+--------------------------------------+

Отобразим список образов glanse с использованием следующей команды; отметим, что сейчас существует два образа glance:

# glance image-list

	[root@os-node1 ~(keystone_admin)]# glance image-list
	+--------------------------------------+--------------+-------------+------------------+----------+--------+
	| ID                                   | Name         | Disk Format | Container Format | Size     | Status |
	+--------------------------------------+--------------+-------------+------------------+----------+--------+
	| 5c261af7-9388-44ad-a8ce-f9ebdad2e5cb | cirros       | qcow2       | bare             | 13200896 | active |
	| b2d15e34-7712-4f1d-b48d-48b924e79b0c | cirros_image | qcow2       | bare             | 13147648 | active |
	+--------------------------------------+--------------+-------------+------------------+----------+--------+
	[root@os-node1 ~(keystone_admin)]#

Вы можете проверить что новый образ сохранён в Ceph запросив ID образа в пуле образов вашего Ceph:

# rados -p images ls --name client.glance --keyring /etc/ceph/ceph.client.glance.keyring | grep -i id

	[root@os-node1 ~]# rados -p images ls --name client.glance --keyring /etc/ceph/ceph.client.glance.keyring | grep -i id
	rbd_id.b2d15e34-7712-4f1d-b48d-48b924e79b0c
	[root@os-node1 ~]#

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

$ vagrant ssh ceph-node1

Наконец мы попытаемся запустить экземпляр с применением образа, который мы создали ранее:

ova boot --flavor 1 --image b2d15e34-7712-4f1d-b48d-48b924e79b0c vm1

[Замечание]
Замечание

Когда вы добавляете новые образы glance или создёте некий экземпляр из образа glance, сохранённого в Ceph, вы можете проверить IO кластера Ceph выполнив его мониторинг с применением команды # watch ceph -s.

 Настройка Cinder под поддержку Ceph

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

  Как это сделать...

В последнем рецепте мы изучили настройку glance для применения Ceph. В этом рецепте мы изучим применение RBD Ceph в службе OpenStack Cinder:

Поскольку в данной демонстрации мы не применяем множественную поддержку настроек Cinder, закройте комментарием параметр enabled_backends в файле /etc/cinder/cinder.conf.

Переместитесь в раздел Options defined in cinder.volume.drivers.rbd файла /etc/cinder/cinder.conf и добавьте следующее (замените секрет uuid значением вашей среды:

volume_driver = cinder.volume.drivers.rbd.RBDDriver
rbd_pool = volumes
rbd_user = cinder
rbd_secret_uuid = bb90381e-a4c5-4db7-b410-3154c4af486e
rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_flatten_volume_from_snapshot = false
rbd_max_clone_depth = 5
rbd_store_chunk_size = 4
rados_connect_timeout = -1
glance_api_version = 2

Выполните следующую команду для проверки предыдущих записей:

# cat /etc/cinder/cinder.conf | egrep "rbd|rados|version" | grep -v "#"

	[root@os-node1 ~]# cat /etc/cinder/cinder.conf | egrep "rbd|rados|version" | grep -v "#"
	volume_driver = cinder.volume.drivers.rbd.RBDDriver
	rbd_pool = volumes
	rbd_user = cinder
	rbd_secret_uuid = bb90381e-a4c5-4db7-b410-3154c4af486e
	rbd_ceph_conf = /etc/ceph/ceph.conf
	rbd_flatten_volume_from_snapshot = false
	rbd_max_clone_depth = 5
	rbd_store_chunk_size =4
	rados_connect_timeout = -1
	glance_api_version = 2
	[root@os-node1 ~]#

Перезапустите службы OpenStack Cinder:

# service openstack-cinder-volume restart

Получите файлы keystone_admin для OpenStack:

# source /root/keystonerc_admin
# cinder list

Для проверки настроек создайте ваш первый 2ГБ том Cinder, который должен быть теперь создан в вашем кластере Ceph:

# cinder create --display-name ceph-volume01 --display-description "Cinder volume on CEPH storage" 2

Проверьте ваш том выводом томов пула Cinder и Ceph:

# cinder list
# rados -p volumes --name client.cinder --keyring ceph.client.cinder.keyring ls | grep -i id

	[root@os-node1 ceph(keystone_admin)]# cinder list
	+--------------------------------------+-----------+---------------+------+-------------+----------+-------------+
	| ID                                   | Status    | Display Name  | Size | Volume Type | Bootable | Attached to |
	+--------------------------------------+-----------+---------------+------+-------------+----------+-------------+
	| 1337c866-6ff7-4a56-bfe5-b0b80abcb281 | available | ceph-volume01 |  2   |     None    |  false   |             |
	+--------------------------------------+-----------+---------------+------+-------------+----------+-------------+
	[root@os-node1 ceph(keystone_admin)]#
	[root@os-node1 ceph(keystone_admin)]# rados -p volumes --name client.cinder --keyring ceph.client.cinder.keyring is | grep -i id rbd_id.volume-1337c866-6ff7-4a56-bfe5-b0b80abcb281
	[root@os-node1 ceph(keystone_admin)]#

Аналогично попробуйте создать другой том с применением инструментальной панели OpenStack Horizon.

 Настройка Nova для подключения Ceph RBD

Чтобы подключать RBD Ceph к экземпляру OpenStack нам следует настроить компонент nova OpenStack добавив сведения о пользователе rbd и uuid информацию, поскольку они требуются для соединения с кластером Ceph. Для этого нам нужно изменить /etc/nova/nova.conf на нашем узле OpenStack и выполнить приводимые в следующем разделе шаги.

  Как это сделать...

Настроенная нами в предыдущем рецепте служба Cinder создаёт тома в Ceph, однако для подключения этих томов к экземплярам OpenStack нам нужно настроить Nova:

Переместитесь в раздел Options defined in nova.virt.libvirt.volume и измените следующие строки (замените секрет uuid значением вашего окружения):

rbd_user=cinder
rbd_secret_uuid= bb90381e-a4c5-4db7-b410-3154c4af486e

Перезапустите службы OpenStack Nova:

# service openstack-nova-compute restart

Для проверки этих настроек мы подключим том Cinder к экземпляру OpenStack. Выведем перечни экземпляров и томов для получения их ID:

# nova list
# cinder list

	[root@os-node1 ~(keystone_admin)]# nova list
	+--------------------------------------+------+--------+------------+-------------+---------------------+
	| ID                                   | Name | Status | Task State | Power State | Networks            |
	+--------------------------------------+------+--------+------------+-------------+---------------------+
	| lcadffc0-58b0-43fd-acc4-33764a02a0a6 | vm1  | ACTIVE | -          | Running     | public=172.24.4.229 |
	+--------------------------------------+------+--------+------------+-------------+---------------------+
	[root@os-node1 ~(keystone_admin)]# cinder list
	+--------------------------------------+-----------+---------------+------+-------------+----------+-------------+
	|                  ID                  |   Status  |  Display Name | Size | Volume Type | Bootable | Attached to |
	+--------------------------------------+-----------+---------------+------+-------------+----------+-------------+
	| 1337c866-6ff7-4a56-bfe5-b0b80abcb281 | available | ceph-volume01 |  2   |     None    |  false   |             |
	| 67d76db0-f808-40d8-819b-Of0302df74a0 | available | ceph-volume02 |  1   |     None    |  false   |             |
	+--------------------------------------+-----------+---------------+------+-------------+----------+-------------+

Подключите свой том к вашему экземпляру:

# nova volume-attach 1cadffc0-58b0-43fd-acc4-33764a02a0a61337c866-6ff7-4a56-bfe5-b0b80abcb281
# cinder list

	[root@os-node1 ~(keystone_admin)]# nova volume-attach lcadffc0-58b0-43fd-acc4-33764a02a0a6 1337c866-6ff7-4a56-bfe5-b0b80abcb281
	+----------+--------------------------------------+
	| Property | Value                                |
	+----------+--------------------------------------+
	| device   | /dev/vdb                             |
	| id       | 1337c866-6ff7-4a56-bfe5-b0b80abcb281 |
	| serverId | lcadffc0-58b0-43fd-acc4-33764a02a0a6 |
	| volumeid | 1337c866-6ff7-4a56-bfe5-b0b80abcb281 |
	+----------+--------------------------------------+
	[root@os-node1 -(keystone_admin)]# cinder list
	+--------------------------------------+-----------+---------------+------+-------------+----------+--------------------------------------+
	|                  ID                  |   Status  |  Display Name | Size | Volume Type | Bootable | Attached to                          |
	+--------------------------------------+-----------+---------------+------+-------------+----------+--------------------------------------+
	| 1337c866-6ff7-4a56-bfe5-b0b80abcb281 |   in-use  | ceph-volume01 |  2   |     None    |  false   | lcadffc0-58b0-43fd-acc4-33764a02a0a6 |
	| 67d76db0-f808-40d8-819b-Of0302df74a0 | available | ceph-volume02 |  1   |     None    |  false   |                                      |
	+--------------------------------------+-----------+---------------+------+-------------+----------+--------------------------------------+
	[root@os-node1 ~(keystone_admin)]#

Теперь вы можете применять этот том как обычное блочное устройство из экземпляра OpenStack.

 Настройка Nova для загрузки экземпляров из Ceph RBD

Чтобы загружать все экземпляры OpenStack из Ceph, т.е. для функциональности загрузка- с- тома, нам следует настроить для Nova недолговечную (ephemeral) поддержку. Для этого отредактируйте /etc/nova/nova.conf на нашем узле OpenStack и выполните следующие изменения.

  Как это сделать...

Этот рецепт имеет дело с настройкой Nova для хранения всех виртуальных машин в RBD Ceph:

Переместитесь в раздел Options defined in nova.virt.libvirt.volume и измените следующие строки (замените секрет uuid значением вашего окружения):

rbd_user=cinder
rbd_secret_uuid= bb90381e-a4c5-4db7-b410-3154c4af486e

Переместитесь в раздел [libvirt] и добавьте следующее:

inject_partition=-2
images_type=rbd
images_rbd_pool=vms
images_rbd_ceph_conf=/etc/ceph/ceph.conf

Переместитесь в раздел Options defined in nova.virt.libvirt.volume и измените следующие строки (замените секрет uuid значением вашего окружения):

rbd_user=cinder
rbd_secret_uuid= bb90381e-a4c5-4db7-b410-3154c4af486e

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

# cat /etc/nova/nova.conf|egrep "rbd|partition" | grep -v "#"

	[root@os-node1 ~(keystone_admin)]# cat /etc/nova/nova.conf|egrep "rbd|partition" | grep -v "#"
	inject_partition=-2
	images_type=rbd
	images_rbd_pool=vms
	images_rbd_ceph_conf=/etc/ceph/ceph.conf
	rbd_user=cinder
	rbd_secret_uuid=bb90381e-a4c5-4db7-b410-3154c4af486e
	[root@os-node1 ~(kevstone admin)]#

Перезапустите службы OpenStack Nova:

# service openstack-nova-compute restart

Для загрузки виртуальной машины из Ceph формат образа Glance должен быть RAW. Мы воспользуемся тем же образом cirros, который мы загружали ранее в этой главе и конвертируем этот образ из QCOW в формат RAW (это существенно). Вы также можете использовать любой другой образ если он в формате RAW:

# qemu-img convert -f qcow2 -O raw cirros-0.3.1-x86_64-disk.img cirros-0.3.1-x86_64-disk.raw

	[root@os-node1 ~(keystone_admin)]# qemu-img convert -f qcow2 -0 raw cirros-0.3.1-x86_64-disk.img cirros-0.3.1-x86_64-disk.raw
	[root@os-node1 ~(keystone_admin)]#
	[root@os-node1 ~(keystone_admin)]# is -la cirros-0.3.1-x86_64-disk.raw
	-rw-r--r-- 1 root root 41126400 Apr 3 22:19 cirros-0.3.1-x86_64-disk.raw
	[root@os-node1 ~(keystone admin)]# file cirros-0.3.1-x86_64-disk.raw
	cirros-0.3.1-x86_64-disk.raw: x86 boot sector; GRand Unified Bootloader, stagel version 0x3, stage2 address 0x2000, stage2 segment 0x200; partition 1: ID=0x83, active, starthead 0, startsector 16065, 64260 sectors, code offset 0x48
	[root@os-node1 ~(keystone_admin)]#

Создайте образ Glance при помощи образа RAW:

# glance image-create --name cirros_raw_image --is-public=true --disk-format=raw --container-format=bare < cirros-0.3.1-x86_64-disk.raw

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

# nova image-list
# cinder create --image-id ff8d9729-5505-4d2a-94ad-7154c6085c97 --display-name cirros-ceph-boot-volume 1

	[root@os-node1 ~(keystoneadmin)]# nova image-list
	+--------------------------------------+------------------+--------+--------+
	| ID                                   | Name             | Status | Server |
	+--------------------------------------+------------------+--------+--------+
	| 5c261af7-9388-44ad-a8ce-f9ebdad2e5cb | cirros           | ACTIVE |        |
	| b2d15e34-7712-4f1d-b48d-48b924e79b0C | cirros_image     | ACTIVE |        |
	| ff8O9729-5505-4d2a-94ad-7154c6085c97 | cirros_raw_image | ACTIVE |        |
	+--------------------------------------+------------------+--------+--------+
	[root@os-node1 ~(keystone_admin)]#
	[root@os-node1 ~(keystone_admin)]# cinder create --image-id ff8d9729-5505-4d2a-94ad-7154c6085c97 --display-name cirros-ceph-boot-volume 1
	+---------------------+--------------------------------------+
	|       Property      |                Value                 |
	+---------------------+--------------------------------------+
	|     attachments     |                  []                  |
	|  availability_zone  |                 nova                 |
	|       bootable      |                false                 |
	|      created_at     |      2015-04-03T22:47:52.638434      |
	| display_description |                 None                 |
	|     display_name    |       cirros-ceph-boot-volume        |
	|      encrypted      |                False                 |
	|          id         | 3a0da68c-d00c-459f-8b52-88c45d6e3bfe |
	|       image_id      | ff8d9729-5505-4d2a-94ad-7154c6085c97 |
	|       metadata      |                 {}                   |
	|         size        |                 1                    |
	|     snapshot_id     |                None                  |
	|     source_volid    |                None                  |
	|        status       |              creating                |
	|     volume_type     |                None                  |
	+---------------------+--------------------------------------+
	[root@os-node1 ~(keystone_admin)]#

Выведите перечень томов Cinder для проверки того что поле bootable установлено в значение true:

# cinder list

	[root@os-node1 ~(keystone_admin)]# cinder list
    +--------------------------------------+-----------+-------------------------+------+-------------+----------+--------------------------------------+
	|                   ID                 |   Status  |       Display Name      | Size | Volume Type | Bootable |             Attached to              |
    +--------------------------------------+-----------+-------------------------+------+-------------+----------+--------------------------------------+
	| 1337c866-6ff7-4a56-bfe5-b0b80abcb281 |   in-use  |      ceph-volume01      |  2   |     None    |  false   | 1cadffc0-58b0-43fd-acc4-33764a02a0a6 |
	| 3a0da68c-d00c-459f-8b52-88c45d6e3bfe | available | cirros-ceph-boot-volume |  1   |     None    |   true   |                                      |
	| 67d76db0-f808-40d8-819b-0f0302df74a0 | available |      ceph-volume02      |  1   |     None    |  false   |                                      |
    +--------------------------------------+-----------+-------------------------+------+-------------+----------+--------------------------------------+
	[root@os-node1 ~(keystone_admin)]#

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

# nova boot --flavor 1 --block_device_mapping vda=fd56314be19b-4129-af77-e6adf229c536::0 --image 964bd077-7b43-46eb-8fe1-cd979a3370df vm2_on_ceph --block_device_mapping vda = <cinder bootable volume id > --image = <Glance image associated with the bootable volume>

Наконец, проверьте состояние экземпляра:

 nova list

	[root@os-node1 ~(keystone_admin)]# nova list
	+--------------------------------------+--------------+---------+------------+-------------+---------------------+
	| ID                                   | Name         | Status  | Task State | Power State | Networks            |
	+--------------------------------------+--------------+---------+------------+-------------+---------------------+
	| 1cadffc0-58b0-43fd-acc4-33764a02a0a6 | vm1          | SHUTOFF | -          | Shutdown    | public=172.24.4.229 |
	| 2b35870e-9f7e-4e5f-bd12-9a625797355d | vm2_01n_ceph | ACTIVE  | -          | Running     | public=172.24.4.233 |
	+--------------------------------------+--------------+---------+------------+-------------+---------------------+
	[root@os-node1 ~(kevstone_admin)]#

На данный момент у нас выполняющийся с тома Ceph имеется экземпляр. Попытайтесь зарегистрироваться из инструментальной панели Horizon:

Глава 3. Работа с хранилищем объектов Ceph

В данной главе мы охватим:

Понимание хранения объектов Ceph

Стандартные наладку, установку и настройку шлюза RADOS

Создание пользователя radosgw

Доступ к хранилищу объектов Ceph с применением S3 API

Доступ к хранилищу объектов Ceph с применением Swift API

Интеграцию шлюза RADOS с OpenStack Keystone

Настройку федеративных шлюзов Ceph

Тестирование федеративных настроек radosgw

Построение служб файловой синхронизации и совместного использования с применением RGW

Содержание

3. Работа с хранилищем объектов Ceph

Введение

Понимание хранения объектов Ceph

Стандартные наладка, установка и настройка шлюза RADOS

Создание пользователя radosgw

Доступ к хранилищу объектов Ceph с применением S3 API

Доступ к хранилищу объектов Ceph с применением Swift API

Интеграция шлюза RADOS с OpenStack Keystone

Настройка федеративных шлюзов Ceph

Тестирование федеративных настроек radosgw

Построение служб файловой синхронизации и совместного использования с применением RGW

 Введение

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

 Понимание хранения объектов Ceph

Хранилище объектов не может быть доступно напрямую из операционной системы в качестве дисковой файловой системы. Наоборот, оно может быть доступно только через API на прикладном уровне. Ceph является распределённой системой системой хранения объектов, которая предоставляет интерфейс хранения объектов через шлюз объектов Ceph, также называемый интерфейсом RADOS Gateway (RGW, шлюза Безотказного автономного распределенного хранилища объектов), который строится поверх уровня Ceph RADOS. RGW использует librgw (RADOS Gateway Library) и librados, позволяя приложениям устанавливать соединение с хранилищем объектов Ceph. RGW снабжает приложения API- интерфейсом совместимым с RESTful S3/ Swift для хранения данных в форме приложений в вашем кластере Ceph. Ceph также поддерживает доступное через RESTful API хранение объектов со множеством владельцев (multitenant). В дополнение к этому RGW также предоставляет API администрирования Ceph, который может применяться для управления кластером хранения Ceph с использованием внутренних API вызовов.

Библиотека программного обеспечения librados является очень гибкой и позволяет пользовательским приложениям осуществлять прямой доступ к кластеру хранения Ceph из связываний (binding) C, C++, Java, Python и PHP. Хранилище объектов Ceph также имеет возможности множества площадок, то есть предоставляет решения для восстановления после сбоев.

Следующий рисунок представляет хранение объектов Ceph:

Рисунок 3.1. Хранение объектов Ceph

 Стандартные наладка, установка и настройка шлюза RADOS

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

Рисунок 3.2. Балансировка нагрузки

Начиная с выпуска Ceph Firefly был введён новый интерфейс RGW: Civetweb, который является автономным лёгким веб сервером. Civetweb был непосредственно встроен в службу ceph-radosgw, делая развёртывание хранилища объектов Ceph более быстрым и простым.

В следующих рецептах мы продемонстрируем настройки RGW, применяющие Civetweb на виртуальной машине, которая взаимодействует с тем же кластером Ceph, который мы создали в Главе 1. Введение и за его пределами.

  Сборка узла шлюза RADOS

Для выполнения службы хранения объектов нам необходим работающий кластер Ceph и узел RGW должен иметь доступ к сетевой среде Ceph.

  Как это сделать...

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

Запустите rgw-node1 с помощью Vagrantfile, как мы это делали для узлов Ceph в Главе 1. Введение и за его пределами. Убедитесь что вы находитесь на машине хоста под репозиторием ceph-cookbook перед приведением в действие rgw-node1 с помощью Vagrant:

# cd ceph-cookbook
# vagrant up rgw-node1

	teeri:ceph-cookbook ksinghS vagrant up rgw-node1
	Bringing machine 'rgw-node1' up with 'virtualbox' provider...
	rgw-node1: Importing base box 'centos7-standard'....
	==> rgw-node1: matching MAC address for NAT networking...
	==> rgw-node1: Setting the name of the vm: rgw-node1
	==> rgw-node1: Fixed port collision for 22 ==> 2222. NOW on port 2202.
	==> rgw-node1: Clearing any previously set network interfaces...
	==> rgw-node1: Preparing network interfaces based on configuration...
	       rgw-node1: Adapter 1: nat
		   rgw-node1: Adapter 2: hostonly
	==> rgw-node1: Forwarding ports...
	       rgw-node1: 22 => 2202 (adapter 1)
	==> rgw-node1: Running 'pre-boot' VM customizations...
	==> rgw-node1: Booting vm...

Когда rgw-node1 поднимется, проверьте состояние Vagrant и зарегистрируйтесь на этом узле:

$ vagrant status rgw-node1
$ vagrant ssh rgw-node1

	teeri:ceph-cookbook ksinghS vagrant status rgw-node1
	Current machine states:

	rgw-node1                 running (virtualbox)

	The vm is running. To stop this vm, you can run `vagrant halt` to
	shut it down forcefully, or you can run 'vagrant suspend' to simply
	suspend the virtual machine. In either case, to restart it again,
	simply run `vagrant up`.
	teeri:ceph-cookbook ksinghS vagrant ssh rgw-node1
	Last login: Sun Apr 5 19:31:52 2015
	[vagrant@rgw-node1 ~]$

Проверьте что rgw-node1 может взаимодействовать с кластером Ceph:

# ping ceph-node1 -c 3
# ping ceph-node2 -c 3
# ping ceph-node3 -c 3

Удостоверьтесь в правильности записей локально файла host, имени хоста и FQDN для rgw-node1:

# cat /etc/hosts | grep -i rgw
# hostname
# hostname -f

	[root@rgw-node1 ~]# cat /etc/hosts | grep rgw
	127.0.0.1 rgw-node1.cephcookbook.com rgw-node1 localhost localhost.localdomain localhost4 localhost4.localdomain4
	192.168.1.106 rgw-node1.cephcookbook.com rgw-node1
	[root@rgw-node1 ~]#
	[root@rgw-node1 ~]# hostname rgw-node1.cephcookbook.com
	[root@rgw-node1 ~]#
	[root@rgw-node1 ~]# hostname -f rgw-node1.cephcookbook.com
	[root@rgw-node1 ~]#

  Установка шлюза RADOS

Предыдущий рецепт был посвящён сборке виртуальной машины для RGW. В этом рецепте мы изучим как собрать на этом узле вашу службу ceph-radosgw.

  Как это сделать...

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

Вначале нам нужно установить пакеты Ceph на rgw-node1. Для этого мы воспользуемся инструментарием ceph-deploy с ceph-node1, который является нашим узлом монитора Ceph. Зарегистрируйтесь на ceph-node1 и выполните следующие команды:

Проверьте что для ceph-node1 доступен в сетевой среде rgw-node1 применив следующую команду:

# ping rgw-node1 -c 1

Позвольте ceph-node1 регистрацию SSH без пароля и проверьте соединение.

[Замечание]
Замечание

Пароль для rgw-node1 тот же, что и ранее, то есть vagrant.

# ssh-copy-id rgw-node1
# ssh rgw-node1 hostname

	[root@ceph-node1 ceph]# ping rgw-node1 -c 1
	PING rgw-node1.cephcookbook.com (192.168.1.106) 56(84) bytes of data.
	64 bytes from rgw-node1.cephcookbook.com (192.168.1.106): icmp_seq.1 tt1.64 time.0.745 ms

	--- rgw nodel.cephcookbook.com ping statistics ---
	1 packets transmitted, 1 received, 0% packet loss, time Oms
	rtt min/avg/max/mdev = 0.745/0.745/0.745/0.000 ms
	[root@ceph-node1 ceph]#
	[root@ceph-node1 ceph]# ssh-copy-id rgw-node1 the authenticity of host 'rgw-node1 (192.168.1.106)' can't be established.
	ECDSA key fingerprint is af:2a:a5:74:a7:0b:f5:5b:ef:c5:4b:2a:fe:ld:30:8e.
	Are you sure you want to continue connecting (yes/no)? yes
	/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
	/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@rgw-node1's password:

	Number of key(s) added: 1
	Now try logging into the machine, with: "ssh 'rgw-node1'"
	and check to make sure that only the key(s) you wanted were added.

	[root@ceph-node1 ceph]# ssh rgw-node1 hostname rgw-node1.cephcookbook.com
	[root@ceph-node1 ceph]#

Применяя ceph-node1 установите пакеты Ceph и скопируйте файл ceph.conf на rgw-node1:

# cd /etc/ceph
# ceph-deploy install rgw-node1
# ceph-deploy config push rgw-node1

Наконец, зарегистрируйтесь на rgw-node1 и установите пакет ceph-radosgw:

# yum install ceph-radosgw

  Настройка шлюза RADOS

Так как для RGW мы используем встроенный веб- сервер Civetweb, большинство вещей уже установлено службой ceph-radosgw. В этом рецепте мы создадим ключи аутентификации для пользователя Ceph RGW и обновим файл ceph.conf.

  Как это сделать...

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

Чтобы создать пользователя RGW и кольцо ключей выполните следующие команды с ceph-node1:

Создайте кольцо ключей при помощи следующей команды:

# cd /etc/ceph
# ceph-authtool --create-keyring \
/etc/ceph/ceph.client.radosgw.keyring
# chmod +r /etc/ceph/ceph.client.radosgw.keyring

Сгенерируйте пользователя шлюза и ключ для экземпляра RGW; имя нашего экземпляра RGW gateway:

# ceph-authtool /etc/ceph/ceph.client.radosgw.keyring \
-n client.radosgw.gateway --gen-key

Добавьте ключу возможности:

# ceph-authtool -n client.radosgw.gateway --cap osd 'allowrwx' \
--cap mon 'allow rwx' /etc/ceph/ceph.client.radosgw.keyring

Добавьте ключ в свой кластер Ceph:

# ceph auth add client.radosgw.gateway \
-i /etc/ceph/ceph.client.radosgw.keyring

Распространите ключ на свой узел Ceph RGW:

# scp /etc/ceph/ceph.client.radosgw.keyring \
rgw-node1:/etc/ceph/ceph.client.radosgw.keyring

	[root@ceph-node1 ceph]# ceph-authtool --create-keyring /etc/ceph/ceph.client.radosgw.keyring
	creating /etc/ceph/ceph.client.radosgw.keyring
	[root@ceph-node1 ceph]# [root@ceph-node1 ceph]# chmod +r /etc/ceph/ceph.client.radosgw.keyring
	[root@ceph-node1 ceph]# ceph-authtool /etc/ceph/ceph.client.radosgw.keyring -n client. radosgw.gateway --gen-key
	[root@ceph-node1 ceph]# ceph-authtool -n client.radosgw.gateway --cap osd 'allow rwx' --cap mon 'allow rwx' /etc/ceph ceph.client.radosgw.keyring
	[root@ceph-node1 ceph]# ceph auth add client. radosgw.gateway /etc/ceph/ceph.client.radosgw.keyring
	added key for client.radosgw.gateway
	[root@ceph-node1 ceph]#
	[root@ceph-node1 ceph]# scp /etc/ceph/ceph.client.radosgw.keyring rgw-node1:/etc/ceph/ceph.client.radosgw.keyring ceph.client.radosgw.keyring
	100% 121 0.1KB/s 00:00
	[root@ceph-node1 ceph]#

Добавьте раздел client.radosgw.gateway в ceph.conf на rgw-node1. Убедитесь что имя хоста то же что и в выводе команды # hostname -s:

[client.radosgw.gateway]
host = rgw-node1
keyring = /etc/ceph/ceph.client.radosgw.keyring
rgw socket path = /var/run/ceph/ceph.radosgw.gateway.fastcgi.sock
log file = /var/log/ceph/client.radosgw.gateway.log
rgw dns name = rgw-node1.cephcookbook.com
rgw print continue = false

	[root@rgw-node1 ceph]# tail -7 ceph.conf
	[client.radosgw.gateway]
	host = rgw-node1
	keyring = /etc/ceph/ceph.client.radosgw.keyring
	rgw socket path = /var/run/ceph/ceph.radosgw.gateway.fastcgi.sock
	log file = /var/log/ceph/client.radosgw.gateway.log
	rgw dns name = rgw-node1.cephcookbook.com
	rgw print continue = false
	[root@rgw-node1 ceph]#

По умолчанию сценарий запуска ceph-radosgw выполняется от пользователь по умолчанию, apache. Измените пользователя по умолчанию с apache на root:

# sed -i s"/DEFAULT_USER.*=.*'apache'/DEFAULT_USER='root'"/g /etc/rc.d/init.d/ceph-radosgw

[Замечание]
Замечание

В промышленных средах не выполняйте ceph-radosgw от имени пользователя 'root', вместо этого применяйте 'apache' или другого пользователя не- root.

Запустите службу Ceph radosgw и проверьте её состояние:

# service ceph-radosgw start
# service ceph-radosgw status

Веб-сервер Civetweb который встроен в ваш демон ceph-radosgw теперь должен работать по порту по умолчанию, 7489:

# netstat -nlp | grep -i 7480

	[root@rgw-node1 ceph]# netstat -nlp | grep -i 7480
	tcp        0      0 0.0.0.0:7480            0.0.0.0:*                 LISTEN      3635/radosgw
	[root@rgw-node1 ceph]#

 Создание пользователя radosgw

Для применения хранилища объектов Ceph нам необходимо создать начального пользователя шлюза объектов Ceph для интерфейса S3 и затем создать подпользователя для интерфейса Swift.

  Как это сделать...

Проверьте что rgw-node1 способен осуществлять доступ к кластеру Ceph:

# ceph -s -k /etc/ceph/ceph.client.radosgw.keyring --name client.radosgw.gateway

Создайте пользователя шлюза RADOS для S3 доступа:

# radosgw-admin user create --uid=mona --display-name="MonikaSingh" --email=mona@cephcookbook.com -k /etc/ceph/ceph.client.radosgw.keyring --name client.radosgw.gateway

	[root@rgw-node1 ceph]# radosgw-admin user create --uid=mona --display-name="MonikaSingh" --email=mona@cephcookbook.com -k /etc/ceph/ceph.client.radosgw.keyring --name client.radosgw.gateway
	{ "user_id": "mona",
	  "display_name": "Monika Singh",
	  "email": "mona@cephcookbook.com",
	  "suspended": 0,
	  "max_buckets": 1000,
	  "auid": 0,
	  "subusers": [],
	  "keys": [
	        { "user": "mona",
	    	  "access_key": "C162E2F8w98A0M3KK99",
	    	  "secret_key": "J21mow6EPs6Sz4xtT7h+piDmhQBv1gWqVeicSRMg"}],
	  "swift_keys": [),
	  "caps": [],
	  "op_mask": "read, write, delete",
	  "default_placement": "",
	  "placement_tags": [],
	  "bucket_quota": { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects": -1},
	  "user_quota": { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects": -1},
	  "temp_url_keys": []}
	[root@rgw-node1 ceph]#

Ваши ключи значений (access_key) и ключи (secret_key) понадобятся позже в данной главе для проверки подлинности доступа.

Чтобы применять хранилище объектов Ceph в API Swift нам необходимо создать подпользователя Swift в Ceph RGW:

# radosgw-admin subuser create --uid=mona --subuser=mona:swift --access=full -k /etc/ceph/ceph.client.radosgw.keyring --name client.radosgw.gateway

	[root@rgw-node1 ceph]# radosgw-admin subuser create --uid=mona --subuser=mona:swift --access=full -k /etc/ceph/ceph.client.radosgw.keyring --name client.radosgw.gateway
	{ "user_id": "mona",
	  "display_name": "Monika Singh",
	  "email": "mona@cephcookbook.com",
	  "suspended": 0,
	  "max_buckets": 1000,
	  "auid": 0,
	  "subusers": [
	        { "id": "mona:swift",
	          "permissions": "full-control"}],
	  "keys": [
	        { "user": "mona:swift",
	          "access_key": "580V73F5AXX3CGNEZ9HV",
	          "secret_key": ""},
	        { "user": "mona",
	          "access_key": "C162E2F8WZ98A0M3KK99",
	          "secret_key": "J21mow6EPs6Sz4xtT7h+piDmhQBvlgWqVeicSRMg"}],
	  "swift_keys": [],
	  "caps": [],
	  "op_mask": "read, write, delete",
	  "default_placement": "",
	  "placement_tags": [],
	  "bucket_quota": { "enabled": false,
	       "max_size_kb": -1,
	       "max_objects": -1},
	  "user_quota": { "enabled": false,
	       "max_size_kb": -1,
	       "max_objects": -1},
	  "temp_url_keys": [] }
	[root@rgw-node1 ceph]#

Создайте ключ безопасности для подпользователя mona:swift; они будут применяться позже в этой главе:

# radosgw-admin key create --subuser=mona:swift --key-type=swift --gen-secret -k /etc/ceph/ceph.client.radosgw.keyring --name client.radosgw.gateway

	[root@rgw-node1 ceph]# radosgw-admin key create --subuser=mona:swift --key-type=swift --gen-secret -k /etc/ceph/ceph.client.radosgw.keyring --name client.radosgw.gateway
	{ "user_id": "mona",
	  "display_name": "monika Singh",
	  "email": "mona@cephcookbook.com",
	  "suspended": 0,
	  "max_buckets": 1000,
	  "auid": 0,
	  "subusers": [
	        { "id": "mona:swift",
	          "permissions": "full-control"}],
	  "keys": [
	        { "user": "mona:swift",
	          "access_key": "580V73FSAXX3CGNEz9Hv",
	          "secret_key": ""},
	        { "user": "mona",
	          "access_key": "C162E2F8WZ98A0M3KK99",
	          "secret_key": "J21mow6EPs6Sz4xtT7h+piDmhQBvlgWqVeic5RMg"}],
	  "swift_keys": [
	        { "user": "mona:swift",
	          "secret_key": "6vxGDhuEBsPSyXlE7VYVFrTXLVqoJByMHT+jnXPV"}],
	  "caps": [],
	  "op_mask": "read, write, delete",
	  "default_placement": "",
	  "placement_tags": [],
	  "bucket_quota": { "enabled": false,
	      "max_size_kb": -1,
		  "max_objects": -1},
	  "user_quota": { "enabled": false,
	      "max_size_kb": -1,
		  "max_objects": -1},
	  "temp_url_keys": []}
	[root@rgw-node1 ceph]#

  Смотрите также...

Рецепт Доступ к хранилищу объектов Ceph с применением Swift API.

 Доступ к хранилищу объектов Ceph с применением S3 API

Веб службы Amazon предлагают Simple Storage Service (S3), который предоставляет хранение через веб- интерфейс такой как REST. Ceph расширяет свою совместимость с S3 посредством RESTful API. Приложения клиента S3 могут получать доступ к хранилищу объектов Ceph на основе ключей безопасности.

Для S3 также требуется присутствие службы DNS если она применяет соглашения именования ваших сегментов виртуальных хостов, т.е. <object_name>.<RGW_Fqdn>. Например, если у вас имеется сегмент с именем jupiter, то доступ к нему будет возможен поверх HTTP через URL http://jupiter.rgw-node1.cephcookbook.com.

  Как это сделать...

Для настройки DNS выполните следующие шаги на узле rgw-node1. Если у вас имеется работающий сервер DNS вы можете пропустить настройку DNS и использовать свой сервер DNS.

  Настройка DNS

Установите пакеты bind на вашем узле ceph-rgw:

# yum install bind* -y

Исправьте /etc/named.conf и добавьте информацию для IP адресов, IP диапазонов и зон, которые упоминаются далее. Вы можете следовать изменениям авторской версии файла named.conf предоставляемого данной книгой:

listen-on port 53 { 127.0.0.1;192.168.1.106; }; ### Add DNS IP ###
allow-query { localhost;192.168.1.0/24; }; ### Add IP Range ###

	options {
	        listen-on port 53 { 127.0.0.1;192.168.1.106; }; ### Add DNS IP ###
	        listen-on-v6 port 53 { ::1; };
	        directory       "/var/named";
	        dump-file       "/var/named/data/cache_dump.db";
	        statistics-file "/var/named/data/named_stats.txt";
	        memstatistics-file "/var/named/data/named_mem_stats.txt";
	        allow-query     { localhost;192.168.1.0/24; }; ### Add IP Range ###
	        }

### Add new zone for domain cephcookbook.com before EOF ###
zone "cephcookbook.com" IN {
type master;
file "db.cephcookbook.com";
allow-update { none; };
};

	### Add new zone for domain cephcookbook.com before EOF ###
	zone "cephcookbook.com" IN {
	type master;
	file "db.cephcookbook.com";
	allow-update { none; };
	include "/etc/named.rfc1912.zones";
	include "/etc/named.root.key";

Создайте файл зоны, /var/named/db.cephcookbook.com со следующим содержимым. Вы можете следовать изменениям авторской версии файла db.objectstore.com предоставленного в том же файле каталога с именем named.conf.rtf в котором содержится пакет кодов данной главы:

@ 86400 IN SOA cephcookbook.com. root.cephcookbook.com. (
        20091028 ; serial yyyy-mm-dd
        10800 ; refresh every 15 min
        3600 ; retry every hour
        3600000 ; expire after 1 month +
        86400 ); min ttl of 1 day
@ 86400 IN NS cephbookbook.com.
@ 86400 IN A 192.168.1.106
* 86400 IN CNAME @

	[root@rgw-node1 ~]# cat /etc/db.cephcookbook.com
	@ 86400 IN SOA cephcookbook.com. root.cephcookbook.com. (
	        20091028 ; serial yyyy-mm-dd
	    	10800 ; refresh every 15 min
	    	3600 ; retry every hour
	    	3600000 ; expire after 1 month +
	    	86400 ); min ttl of 1 day
	@ 86400 IN NS cephbookbook.com.
	@ 86400 IN A 192.168.1.106
	* 86400 IN CNAME @
	[root@rgw-node1 ~]#

Измените /etc/resolve.conf и добавьте следующее содержание:

search cephcookbook.com
nameserver 192.168.1.106

Запустите службу named:

# service named start

Проверьте ваши файлы настройки DNS на наличие синтаксических ошибок:

# named-checkconf /etc/named.conf
# named-checkzone cephcookbook.com /var/named/db.cephcookbook.com

	[root@rgw-node1 ~]# service named start
	Redirecting to /bin/systemctl start named.service
	[root@rgw-node1 ~]#
	[root@rgw-node1 ~]# named-checkconf /etc/named.conf
	[root@rgw-node1 ~]# named-checkzone cephcookbook.com /var/named/db.cephcookbook.com zone cephcookbook.com/IN: loaded serial 20091028
	OK
	[root@rgw-node1 ~]#

Проверьте ваш сервер DNS:

# dig rgw-node1.cephcookbook.com
# nslookup rgw-node1.cephcookbook.com

  Настройка вашего клиента s3cmd

Для доступа к хранилищу объектов Ceph через API S3 вам необходимо настроить клиентскую машину при помощи s3cmd а также установки вашего клиента DNS. Выполните следующие шаги для настройки клиентской машины s3cmd:

Поднимите вашу виртуальную машину client-node1 воспользовавшись Vagrant. Эта виртуальная машина будет использоваться в качестве машины клиента для хранилища объектов S3:

$ vagrant up client-node1

На вашей машине client-node1 обновите записями сервера DNS /etc/resolve.conf:

search cephcookbook.com
nameserver 192.168.1.106

Проверьте настройки DNS на client-node1:

# dig rgw-node1.cephcookbook.com
# nslookup rgw-node1.cephcookbook.com

client-node1 должен быть способен разрешать поддомены для rgw-node1.cephcookbook.com:

# ping mj.rgw-node1.cephcookbook.com -c 1
# ping anything.rgw-node1.cephcookbook.com -c 1

	root@client-node1:~# ping mj.rgw-nodel.cephcookbook.com -c 1
	PING cephcookbook.com (192.168.1.106) 56(84) bytes of data.
	64 bytes from 192.168.1.106: icmp_seq=1 tt1=64 time=0.475 ms

	--- cephcookbook.com ping statistics ---
	1 packets transmitted, 1 received, 0% packet loss, time Oms
	rtt min/avg/max/mdev = 0.475/0.475/0.475/0.000 ms
	root@client-node1:~#
	root@client-node1:~# ping anything.rgN-nodeLcephcookbook.com -c 1
	PING cephcookbook.com (192.168.1.106) 56(84) bytes of data.
	64 bytes from 192.168.1.106: icmp_seq=1 tt1=64 time=0.413 ms

	--- cephcookbook.com ping statistics ---
	1 packets transmitted, 1 received, 0% packet loss, time Oms
	rtt min/avg/max/mdev = 0.413/0.413/0.413/0.000 ms
	root@client-node1:~#

Настройте клиента S3 (s3cmd) на client-node1:

Установите s3cmd используя следующую команду:

# apt-get install -y s3cmd

Настройте s3cmd предоставив access_key и secret_key вашего пользователя mona, которого мы создали ранее в этой главе. Выполните следующую команду и следуйте за приглашениями:

# s3cmd --configure

	root@client-node1:Ё# s3cmd --configure

	Enter new values or accept defaults in brackets with Enter.
	Refer to user manual for detailed description of all options.
	{Введите новые значения или примите значения по умолчанию в скобках нажав Ввод.
	За дополнительными пояснениями всех параметров обращайтесь к пользовательской документации.}

	Access key and secret key are your identifiers for Amazon S3
	{Ключ доступа и ключ безопасности являются вашими идентификаторами для Amazon S3}
	Access Key: С162E2F8wZ98A0M3KK99
	Secret Key: 321mow6EPs6Sz4xtT7h+rpiDmhQBvlgwqVeic5RMg

	Encryption password is used to protect your files from reading
	by unauthorized persons while in transfer to S3
	{Пароль шифрования применяется для защиты ваших файлов от чтения
	неавторизованым персоналом при передаче на S3}
	Encryption password:
	Path to GPG program [/usr/bin/gpg]:

	When using secure HTTPS protocol all communication with Amazon S3
	servers is protected from 3rd party eavesdropping. This method is slower
	than plain HTTP and can't be used if you're behind a proxy
	{При использовании безопасного протокола HTTPS всё взаимодействие с серверами
	Amazon S3 защищено от подслушивания 3ми сторонами. Этот метод медленнее
	чем простой HTTP и не может применяться если вы используете proxy}
	use HTTPS protocol [No]:

	On some networks all internet access must go through a HTTP proxy.
	Try setting it here if you can't connect to S3 directly
	{В некоторых сетевых средах весь доступ в интернет должен проходить сквозь HTTP proxy.
	Попробуйте настроить его здесь если вы не можете соединиться с S3 напрямую}
	HTTP Proxy server name:

	New settings:
	 Access Key: C162E2F8wZ98A0M3KK99
	 Secret Key: 321mow6EPs6Sz4xtT7h+rpiDmhQBvlgwqVeic5RMg
	 Encryption password:
	 Path to GPG program: /usr/bin/gpg
	 Use HTTPS protocol: False
	 HTTP Proxy server name:
	 HTTP Proxy server port: 0

	Test access with supplied credentials? [Y/n] n

	Save settings? [y/N] y
	configuration saved to '/root/.s3cfg'
	root@client-node1:~#

Команда ~# s3cmd --configure command создаст /root/.s3cfg. Измените этот файл для внесения подробностей вашего хоста RGW. Измените host_base и host_bucket, как показано далее. Убедитесь что эти строки не имеют пробельных символов в конце:

host_base = rgw-node1.cephcookbook.com:7480
host_bucket = %(bucket)s.rgw-node1.cephcookbook.com:7480

Вы можете взять за основу авторскую версию файла /root/.s3cfg предоставленного в пакете кода данной главы.

	root@client node1:~# cat /root/.s3cfg
	[default] access_key = C162E2F8WZ98A0M3KK99
	bucket_location = US
	cloudfront_host = cloudfront.amazonaws.com
	default_mime_type = binary/octet-stream
	delete_removed = False
	dry_run = False
	enable_multipart = True
	encoding = UTF-8
	encrypt = False
	follow_symlinks = False
	force = False
	get_continue = False
	gpg_command = /usr/bin/gpg
	gpg_decrypt = %(gpg_command)s -d --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
	gpg_encrypt = %(gpg_command)s -c --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
	gpg_passphrase =
	guess_mime_type = True
	host_base = rgw
	node1.cephcookbook.com:7480
	host_bucket = %(bucket)s.rgw
	node1.cephcookbook.com:7480
	human_readable_sizes = False
	invalidate_on_cf = False
	list_mdS = False
	log_target_prefix =
	mime_type =
	multipart_chunk_size_mb = 15
	preserve_attrs = True
	progress_meter = True
	proxy_host =
	proxy_port = 0
	recursive = False
	recv_chunk = 4096
	reduced_redundancy = False
	secret_key = 321mow6EPs6Sz4xtT7h+rpiDmhQBvlgwqVeic5RMg
	send_chunk = 4096
	simpledb_host = sdb.amazonaws.com
	skip_existing = False
	socket_timeout = 300
	urlencoding_mode = normal
	use_https = False
	verbosity = WARNING
	website_endpoint = http://%(bucket)s.s3-website-%(location)s.amazonaws.com/
	website_error =
	website_index = index.html

Наконец мы создаём пакеты (buckets) и помещаем объекты в них:

# s3cmd mb s3://first-bucket
# s3cmd ls
# s3cmd put /etc/hosts s3://first-bucket
# s3cmd ls s3://first-bucket

	root@client-node1:~# s3cmd mb s3://first-bucket
	Bucket 's3://first-bucket/' created
	root@client-node1:~#
	root@client-node1:~# s3cmd ls
	2015-04-11 23:55  s3://first-bucket
	root@client-node1:~#
	root@client-node1:~# s3cmd put /etc/hosts s3://first-bucket
	WARNING: Module python-magic is not available. Guessing MIME types based on file extensions.
	/etc/hosts -> s3://first-bucket/hosts [1 of 1]
	601 of 601    100% in    ls   436.06 B/s  done
	root@client-node1:~#
	root@client-node1:~#
	root@client-node1:~# s3cmd ls s3://first-bucket
	2015-04-11 23:55       601   s3://first-bucket/hosts
	root@client-node1:~#

 Доступ к хранилищу объектов Ceph с применением Swift API

Ceph поддерживает RESTful API который совместим с основной моделью доступа API Swift. В последнем разделе мы рассказывали о доступе к кластеру Ceph через API S3; в этом разделе мы изучим доступ через API Swift.

  Как это сделать...

Чтобы использовать хранилище объектов Ceph при промощи API Swift нам необходим подпользователь Swift и ключ безопасности который мы создали ранее в этой главе. Эта информация о пользователе будет затем передана с применением интструментария Swift CLI чтобы осуществить доступ к хранилищу объектов Ceph:

На client-node1 виртуальная машина установит вашего клиента python Swift:

# apt-get install python-setuptools
# easy_install pip
# pip install --upgrade setuptools
# pip install --upgrade python-swiftclient

Получите подпользователя Swift и ключи безопасности:

# radosgw-admin user info --uid mona

Получите доступ к хранилищу объектов Ceph просмотрев список сегмента (bucket) по умолчанию:

# swift -A http://192.168.1.106:7480/auth/1.0 -U mona:swift -K 6vxGDhuEBsPSyX1E7vYvFrTXLVqoJByMHT+jnXPV list

Добавьте новый сегмент, second-bucket:

# swift -A http://192.168.1.106:7480/auth/1.0 -U mona:swift -K 6vxGDhuEBsPSyX1E7vYvFrTXLVqoJByMHT+jnXPV post second-bucket

Выведите перечень сегментов (bucket); он также отобразит ваш новый second-bucket:

# swift -A http://192.168.1.106:7480/auth/1.0 -U mona:swift -K 6vxGDhuEBsPSyX1E7vYvFrTXLVqoJByMHT+jnXPV list

	root@client-node1:~# swift -A http://192.168.1.106:7480/auth/1.0 -U mona:swift -K 6vxGDhuEBsPSyX1E7vYvFrTXLVqoJByMHT+jnXPV list
	first-bucket
	root@client-node1:~#
	root@client-node1:~# swift -A http://192.168.1.106:7480/auth/1.0 -U mona:swift -K 6vxGDhuEBsPSyX1E7vYvFrTXLVqoJByMHT+jnXPV post second-bucket
	root@client-node1:~# swift -A http://192.168.1.106:7480/auth/1.0 -U mona:swift -K 6vxGDhuEBsPSyX1E7vYvFrTXLVqoJByMHT+jnXPV list
	first-bucket
	second-bucket
	root@client-node1:~#

  Смотрите также...

Рецепт Создание пользователя radosgw.

 Интеграция шлюза RADOS с OpenStack Keystone

Ceph может быть интегрирован с вашей службой управления идентификацией OpenStack, 'Keystone'. При такой интеграции RGW Ceph настраивается принимать маркеры (token) Keystone для авторизации пользователей. Таким образом, все удостоверенные Keystone пользователи получат права для доступа к RGW.

  Как это сделать...

Выполните следующие команды на вашем openstack-node1, если не предписано иное:

Настройте OpenStack для указания на Ceph RGW создав соответствующую службу и её терминалы:

# keystone service-create --name swift --type object-store --description "ceph object store"
# keystone endpoint-create --serviceid 6614554878344bbeaa7fec0d5dccca7f --publicurl
http://192.168.1.106:7480/swift/v1 --internalurl
http://192.168.1.106:7480/swift/v1 --adminurl
http://192.168.1.106:7480/swift/v1 --region RegionOne

	[root@os-node1 ~(keystone_admin)]# keystone service-create --name swift --type object-store --description "ceph object store"
	+-------------+----------------------------------+
	|   Property  |              Value               |
	+-------------+----------------------------------+
	| description |        ceph object store         |
	|   enabled   |               True               |
	|      id     | 6614554878344bbeaa7fec0d5dccca7f |
	|     name    |              swift               |
	|     type    |           object-store           |
	+-------------+----------------------------------+
	[root@os-node1 ~(keystone_admin)]#
	[root@os-node1 ~(keystone_admin)]# keystone endpoint-create --service-id 6614554878344bbeaa7fec0d5dccca7f --publicurl http://192.168.1.106:7480 /swift/vl --internalurl http://192.168.1.106:7480/swift/v1 --adminurl http://192.168.1.106:7480/swift/v1 --region RegionOne
	+-------------+------------------------------------+
	|  Property   |              Value                 |
	+-------------+------------------------------------+
	|  adminurl   | http://192.168.1.106:7480/swift/v1 |
	|      id     |  1f962773df6c438e9658fc8cc027d86f  |
	| internalurl | http://192.168.1.106:7480/swift/v1 |
	|  publicurl  | http://192.168.1.106:7480/swift/v1 |
	|    region   |            RegionOne               |
	|  service_id |  6614554878344bbeaa7fec0d5dccca7f  |
	+-------------+------------------------------------+
	[root@os-node1 ~(keystone_admin)]#

Получите свой маркер администратора Keystone, который будет использоваться для настройки RGW:

# cat /etc/keystone/keystone.conf | grep -i admin_token

Создайте каталог для сертификатов:

# mkdir -p /var/ceph/nss

Сгененрируйте сертификаты openssl:

# openssl x509 -in /etc/keystone/ssl/certs/ca.pem -pubkey|certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"
# openssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"

	[root@os-node1 ~(keystone_admin)]# mkdir -p /var/ceph/nss
	[root@os-node1 ~(keystone_admin)]# openssl x509 -in /etc/keystone/ssl/certs/ca.pem -pubkey|certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"
	Notice: Trust flag u is set automatically if the private key is present.
	[root@os-node1 ~(keystone_admin)]#
	[root@os-node1 ~(keystone_admin)]# openssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"
	[root@os-node1 ~(keystone_admin)]# ls -1 /var/ceph/nss/
	total 76
	-rw------- 1 root root 65536 Apr 17 00:40 cert8.db
	-rw------- 1 root root 16384 Apr 17 00:40 key3.db
	-rw------- 1 root root 16384 Apr 17 00:38 secmod.db
	[root@os-node1 ~(keystone_admin)]#

Создайте /var/ceph/nss directory на rgw-node1:

# mkdir -p /var/ceph/nss

Скопируйте openssl сертификаты с openstack-node1 на rgw-node1. Если вы регистрируетесь в первый раз, вы получите кведомление SSH; наберите yes, затем введите пароль root, который установлен в значение vagrant для всех ваших машин:

# scp /var/ceph/nss/* rgw-node1:/var/ceph/nss

На rgw-node1 создайте каталоги и измените их владельца на Apache:

# mkdir /var/run/ceph
# chown apache:apache /var/run/ceph
# chown -R apache:apache /var/ceph/nss

На client-node1 rgw-node1 :

# apt-get install python-setuptools

Измените /etc/ceph/ceph.conf на rgw-node1 следующими записями в разделе [client.radosgw.gateway]:

rgw keystone url = http://192.168.1.111:5000
rgw keystone admin token = f72adb0238d74bb885005744ce526148
rgw keystone accepted roles = admin, Member, swiftoperator
        rgw keystone token cache size = 500
        rgw keystone revocation interval = 60
        rgw s3 auth use keystone = true
nss db path = /var/ceph/nss

[Замечание]
Замечание

rgw keystone url должен быть вашим URL управления кольцом ключей который может быть получен командой # keystone endpoint-list.

rgw keystone admin token является значением маркера который мы сохранили на 2 шаге этого рецепта.

Наконец запустите службу ceph-radosgw:

# systemctl restart ceph-radosgw

Теперь чтобы протестировать интеграцию Keystone и Ceph, переключимся назад на openstack-node1 и выполним основные команды Swift, причём они не должны запрашивать у нас никаких ключей пользователей:

# swift list
# swift post swift-test-bucket
# swift list

	[root@os-node1 ~(keystone_admin)]# swift list
	[root@os-node1 ~(keystone_admin)]# swift post swift-test-bucket
	[root@os-node1 ~(keystone_admin)]# swift list swift-test-bucket
	[root@os-node1 ~(keystone_admin)]#

Вы должны быть в состоянии выполнять любые операции с сегментами (bucket) с применением как swift cli, так и из инструментальной панели OpenStack Horizon, в разделе Object storage, без каких- либо запросов полномочий для пользователя RGW Ceph; это обусловлено выполненными нами изменениями настроек, проверяемые Keystone маркеры (token) теперь принимаются вашим RGW Ceph.

 Настройка федеративных шлюзов Ceph

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

Рисунок 3.3. Гографически разделённое развёртывание экземпляров radosgw

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

Рисунок 3.4. 

В данном рецепте мы изучим как размещать последним методом федерации Ceph radosgw. В соответствии с этим, мы создадим главный (master) регион, US,который будет размещать две зоны: master zone: us-east, содержащую экземпляр RGW us-east-1, и secondary zone: us-west, содержащую экземпляр RGW us-west-1. Далее приводятся параметры и их значения, которые мы будем применять:

Главный Регион → Соединённые Штаты: us

Главная Зона → зона восточного региона Соединённых Штатов: us-east

Вторичная Зона → зона западного региона Соединённых Штатов: us-west

Экземпляр-1 radosgw → Экземпляр1 зоны восточного региона Соединённых Штатов: us-east-1

Экземпляр-2 radosgw → Экземпляр1 зоны западного региона Соединённых Штатов: us-west-1

  Как это сделать...

На вашей машине хоста поднимите виртуальные машины us-east-1 и us-west-1 с применением Vagrant:

$ cd ceph-cookbook
$ vagrant status us-east-1 us-west-1
$ vagrant up us-east-1 us-west-1
$ vagrant status us-east-1 us-west-1setuptools

	teeri:ceph-cookbook ksingh$ vagrant status us-east-1 us-west-1
	Current machine states:

	us-east-1       running (virtualbox)
	us-west-1       running (virtualbox)

	This environment represents multiple vms. The vms are all listed
	above with their current state. For more information about a specific
	VM, run `vagrant status NAME`.
	teeri:ceph-cookbook ksingh$

С этого момента мы будем выполнять все команды с любой из ваших машин монитора Ceph пока не определено иное. В нашем случае мы будем применять ceph-node1. Далее мы создадим пулы Ceph, которые будут применяться для хранения пучка критически важной информации о данных хранилища объектов, такие как сегмент (bucket), индекс сегмента, глобального каталога, журналов, идентификаторов пользователя S3, учётных записей пользователя Swift, адресов электронной почты и тому подобного.

Создайте пулы Ceph для вашей зоны us-east:

# ceph osd pool create .us-east.rgw.root 32 32
# ceph osd pool create .us-east.rgw.control 32 32
# ceph osd pool create .us-east.rgw.gc 32 32
# ceph osd pool create .us-east.rgw.buckets 32 32
# ceph osd pool create .us-east.rgw.buckets.index 32 32
# ceph osd pool create .us-east.rgw.buckets.extra 32 32
# ceph osd pool create .us-east.log 32 32
# ceph osd pool create .us-east.intent-log 32 32
# ceph osd pool create .us-east.usage 32 32
# ceph osd pool create .us-east.users 32 32
# ceph osd pool create .us-east.users.email 32 32
# ceph osd pool create .us-east.users.swift 32 32
# ceph osd pool create .us-east.users.uid 32 32

Создайте пулы Ceph для вашей зоны us-west:

# ceph osd pool create .us-west.rgw.root 32 32
# ceph osd pool create .us-west.rgw.control 32 32
# ceph osd pool create .us-west.rgw.gc 32 32
# ceph osd pool create .us-west.rgw.buckets 32 32
# ceph osd pool create .us-west.rgw.buckets.index 32 32
# ceph osd pool create .us-west.rgw.buckets.extra 32 32
# ceph osd pool create .us-west.log 32 32
# ceph osd pool create .us-west.intent-log 32 32
# ceph osd pool create .us-west.usage 32 32
# ceph osd pool create .us-west.users 32 32
# ceph osd pool create .us-west.users.email 32 32
# ceph osd pool create .us-west.users.swift 32 32
# ceph osd pool create .us-west.users.uid 32 32

Проверьте только что созданные пулы Ceph:

# ceph osd lspools

	[root@ceph-node1 ~]# ceph osd lspools
	0 rbd,1 images,2 volumes,3 vms,4 .rgw.root,5 .rgw.contro1,6 .rgw,7 .rgw.gc,8 .users.uid,9 .users.emai1,10 .users,11 .users.swift,12 .rgw.buckets.index,13 .rgw.buckets,14 .us-east.rgw.root,15 .us-east.rgw.contro1,16 .us-east.rgw.gc,1 7 .us-east.rgw.buckets,18 .us-east. rgw.buckets.index,19 .us-east.rgw.buckets.extra,20 .us-east.log,21 .us-east.inten t-log,22 .us-east.usage,23 .us-east.users,24 .us-east.users.emai1,25 .us-east.users.swift,26 .us-east.users.uid,27 . us-west.rgw.root,28 .us-west.rgw.contro1,29 .us-west.rgw.gc,30 .us-west.rgw.buckets,31 .us-west.rgw.buckets.index,32 .us-west.rgw.buckets.extra,33 .us-west.log,34 .us-west.intent-log,35 .us-west.usage,36 .us-west.users,37 .us-west.0 sers.emai1,38 .us-west.users.swift,39 .us-west.users.uid,
	[root@ceph-node1 ~]#

Экземпляру RGW требуется пользователь и ключ для общения с вашим кластером хранения Ceph:

При помощи следующей команды создайте кольцо ключей:

# ceph-authtool --create-keyring /etc/ceph/ceph.client.radosgw.keyring
# chmod +r /etc/ceph/ceph.client.radosgw.keyring

Сгенерируйте имя пользователя и ключ шлюза для каждого экземпляра:

# ceph-authtool /etc/ceph/ceph.client.radosgw.keyring -n client.radosgw.us-east-1 --gen-key
# ceph-authtool /etc/ceph/ceph.client.radosgw.keyring -n client.radosgw.us-west-1 --gen-key

Добавьте возможности ключам:

# ceph-authtool -n client.radosgw.us-east-1 --cap osd 'allow rwx' --cap mon 'allow rwx' /etc/ceph/ceph.client.radosgw.keyring
# ceph-authtool -n client.radosgw.us-west-1 --cap osd 'allow rwx' --cap mon 'allow rwx' /etc/ceph/ceph.client.radosgw.keyring

Добавьте ключи в ваш кластер хранения Ceph:

# ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.radosgw.us-east-1 -i /etc/ceph/ceph.client.radosgw.keyring
# ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.radosgw.us-west-1 -i /etc/ceph/ceph.client.radosgw.keyring

	[root@ceph-node1 ~]# ceph-authtool --create-keyring /etc/ceph/ceph.client.radosgw.keyring
	creating /etc/ceph/ceph.client.radosgw.keyring
	[root@ceph-node1 ~]# chmod +r /etc/ceph/ceph.client.radosgw.keyring
	[root@ceph-node1 ~]# ceph-authtool /etc/ceph/ceph.client.radosgw.keyring -n client.radosgw.us-east-1 --gen-key
	[root@ceph-node1 ~]# ceph-authtool /etc/ceph/ceph.client.radosgw.keyring -n client.radosgw.us-west-1 --gen-key
	[root@ceph-node1 ~]# ceph-authtool -n client.radosgw.us-east-1 --cap osd 'allow rwx' --cap mon 'allow rwx' /etc/ceph/ceph.client.radosgw.keyring
	[root@ceph-node1 ~]# ceph-authtool -n client.radosgw.us-west-1 --cap osd 'allow rwx' --cap mon 'allow rwx' /etc/ceph/ceph.client.radosgw.keyring
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.radosgw.us-east-1 /etc/ceph/ceph.client.radosgw.keyring
	added key for client.radosgw.us-east-1
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.radosgw.us-west-1 	/etc/ceph/ceph .client.radosgw.keyring
	added key for client. radosgw.us-west-1
	[root@ceph-node1 ~]#

Добавьте экземпляры RGW в ваш файл настроек Ceph, то есть /etc/ceph/ceph.conf:

[client.radosgw.us-east-1]
host = us-east-1
rgw region = us
rgw region root pool = .us.rgw.root
rgw zone = us-east
rgw zone root pool = .us-east.rgw.root
keyring = /etc/ceph/ceph.client.radosgw.keyring
rgw dns name = rgw-node1
rgw socket path = /var/run/ceph/client.radosgw.us-east-1.sock
log file = /var/log/ceph/client.radosgw.us-east-1.log

[client.radosgw.us-west-1]
host = us-west-1
rgw region = us
rgw region root pool = .us.rgw.root
rgw zone = us-west
rgw zone root pool = .us-west.rgw.root
keyring = /etc/ceph/ceph.client.radosgw.keyring
rgw dns name = rgw-ndoe1
rgw socket path = /var/run/ceph/client.radosgw.us-west-1.sock
log file = /var/log/ceph/client.radosgw.us-west-1.log

	[root@ceph-node1 ceph]# tail -22 ceph.conf

	[client.radosgw.us-east-1]
	host = us-east-1
	rgw region = us
	rgw region root pool = .us.rgw.root
	rgw zone = us-east
	rgw zone root pool = .us-east.rgw.root
	keyring = /etc/ceph/ceph.client.radosgw.keyring
	rgw dns name = rgw-node1
	rgw socket path = /var/run/ceph/client.radosgw.us-east-1.sock log file = /var/log/ceph/client.radosgw.us-east-1.log

	[client. radosgw.us-west-1]
	host = us-west-1
	rgw region = us
	rgw region root pool = .us.rgw.root
	rgw zone = us-west
	rgw zone root pool = .us-west.rgw.root
	keyring = /etc/ceph/ceph.client.radosgw.keyring
	rgw dns name = rgw-node1
	rgw socket path = /var/run/ceph/client.radosgw.us-west-1.sock log file = /var/log/ceph/client.radosgw.us-west-1.log
	[root@ceph-node1 ceph]#

Далее мы установим пакеты Ceph на узлы us-east-1 и us-west-1 с помощью ceph-deploy с вашей машины ceph-node1. Наонец, мы добавим файлы настроек на эти узлы:

Позволим cep-node1 выполнять регистрацию на ваших узлах RGW без паролей. Пароль root установлен по умолчанию, то есть vagrant:

# ssh-copy-id us-east-1
# ssh-copy-id us-west-1

Установите пакеты Ceph на ваши экземпляры RGW:

# ceph-deploy install us-east-1 us-west-1

Когда пакеты Ceph установятся на ваш экземпляр RGW, поместите файлы настроек Ceph:

# ceph-deploy --overwrite-conf config push us-east-1 uswest-1

Скопируйте кольца ключей RGW с ceph-node на экземпляр шлюза:

# scp ceph.client.radosgw.keyring us-east-1:/etc/ceph
# scp ceph.client.radosgw.keyring us-west-1:/etc/ceph

Далее установите пакеты ceph-radosgw и radosgw-agent на экземпляры radosgw us-east-1 и us-west-1:

# ssh us-east-1 yum install -y ceph-radosgw radosgw-agent
# ssh us-west-1 yum install -y ceph-radosgw radosgw-agent

Для простоты мы запретим межсетевые экраны на ваших узлах:

# ssh us-east-1 systemctl disable firewalld
# ssh us-east-1 systemctl stop firewalld
# ssh us-west-1 systemctl disable firewalld
# ssh us-west-1 systemctl stop firewalld

Создайте регион us. Зарегистрируйтесь на us-east-1 и выполните следующие команды:

Создайте infile региона с названием us.json в каталоге /etc/ceph со следующим содержимым. Вы можете использовать для справки авторскую версию вашего файла us.json поставляемого с пакетом кода данной главы:

{ "name": "us",
  "api_name": "us",
  "is_master": "true",
  "endpoints": [
    "http:\/\/us-east-1.cephcookbook.com:7480\/"],
  "master_zone": "us-east",
  "zones": [
  { "name": "us-east",
    "endpoints": [
      "http:\/\/us-east-1.cephcookbook.com:7480\/"],
    "log_meta": "true",
    "log_data": "true"},
  { "name": "us-west",
    "endpoints": [
      "http:\/\/us-west-1.cephcookbook.com:7480\/"],
    "log_meta": "true",
    "log_data": "true"}],
  "placement_targets": [
  {
    "name": "default-placement",
    "tags": []
  }
  ],
  "default_placement": "default-placement"}

	[root@us-east-1 ceph]# cat us.json
	{ "name": "us",
	  "api_name": "us",
	  "is_master": "true",
	  "endpoints": [
	        "http:\/\/us-east-1.cephcookbook.com:7480\/"],
	  "master_zone": "us-east",
	  "zones": [
	       { "name": "us-east",
	         "endpoints": [
	               "http:\/\/us-east-1.cephcookbook.com:7480\/"],
	         "log_meta": "true",
	         "log_data": "true"},
	       { "name": "us-west",
	         "endpoints": [
	               "http:\/\/us-west-1.cephcookbook.com:7480\/"],
	         "log_meta": "true",
	         "log_data": "true"}],
	  "placement_targets": [
	  {
	    "name": "default-placement",
	    "tags": []
	  }
	  ],
	  "default_placement": "default-placement"}
	[root@us-east-1 ceph]#

Создайте регион us с только что созданным вами infile us.json:

# cd /etc/ceph
# radosgw-admin region set --infile us.json --name client.radosgw.us-east-1

Удалите регион по умолчанию, если он существует:

# rados -p .us.rgw.root rm region_info.default --name client.radosgw.us-east-1

Установите регион us в качестве региона по умолчанию:

# radosgw-admin region default --rgw-region=us --name client.radosgw.us-east-1

Наконец, обновите карту региона:

# radosgw-admin regionmap update --name client.radosgw.us-east-1

Сгенерируйте access_keys и secret_keys для зон us-east и us-west:

Сгенерируйте access_keys для вашей зоны us-east:

# < /dev/urandom tr -dc A-Z-0-9 | head -c${1:-20};echo;

Сгенерируйте secret_keys для вашей зоны us-east:

# < /dev/urandom tr -dc A-Z-0-9-a-z | head -c${1:-40};echo;

	[root@us-east-1 ceph]# < /dev/urandom tr -dc A-Z-0-9 | head -c$11:-20};echo;
	XNK0ST8WXTMWZGN29NF9
	[root@us-east-1 ceph]#
	[root@us-east-1 ceph]# < /dev/urandom tr -dc A-Z-0-9-a-z | head -c$11:-40};echo;
	7VJm8uAp7lxKQZkjoPZmHu4sACA1SY8jTjay9dP5
	[root@us-east-1 ceph]#

Сгенерируйте access_keys для вашей зоны us-west:

# < /dev/urandom tr -dc A-Z-0-9 | head -c${1:-20};echo;

Сгенерируйте secret_keys для вашей зоны us-west:

# < /dev/urandom tr -dc A-Z-0-9-a-z | head -c${1:-40};echo;

	[root@us-east-1 ceph]# < /dev/urandom tr -dc A-Z-0-9 | head -c${1:-20};echo;
	AAK0ST8WXTMWZGN29NF9
	[root@us-east-1 ceph]# < /dev/urandom tr -dc A-Z-0-9-a-z | head -c${1:-40};echo;
	AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dPS
	[root@us-east-1 ceph]#

Создайте infile зоны с названием us-east.json для вашей зоны us-east. Вы можете применять для справки авторский файл us-east.json предоставляемый пакетом кода данной главы:

{ "domain_root": ".us-east.domain.rgw",
  "control_pool": ".us-east.rgw.control",
  "gc_pool": ".us-east.rgw.gc",
  "log_pool": ".us-east.log",
  "intent_log_pool": ".us-east.intent-log",
  "usage_log_pool": ".us-east.usage",
  "user_keys_pool": ".us-east.users",
  "user_email_pool": ".us-east.users.email",
  "user_swift_pool": ".us-east.users.swift",
  "user_uid_pool": ".us-east.users.uid",
  "system_key": { "access_key": " XNK0ST8WXTMWZGN29NF9",
                  "secret_key": "7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"},
  "placement_pools": [
    { "key": "default-placement",
      "val": { "index_pool": ".us-east.rgw.buckets.index",
               "data_pool": ".us-east.rgw.buckets"}
     }
  ]
}

	[root@us-east-1 ceph]#  cat us-east.json
	{ "domain_root": ".us-east.domain.rgw",
	  "control_pool": ".us-east.rgw.control",
	  "gc_pool": ".us-east.rgw.gc",
	  "log_pool": ".us-east.log",
	  "intent_log_pool": ".us-east.intent-log",
	  "usage_log_pool": ".us-east.usage",
	  "user_keys_pool": ".us-east.users",
	  "user_email_pool": ".us-east.users.email",
	  "user_swift_pool": ".us-east.users.swift",
	  "user_uid_pool": ".us-east.users.uid",
	  "system_key": { "access_key": "XNK0ST8WXTMWZGN29NF9",
	                            "secret_key": "7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"},
	  "placement_pools": [
        { "key": "default-placement",
          "val": { "index_pool": ".us-east.rgw.buckets.index",
                             "data_pool": ".us-east.rgw.buckets"}
        }
	  ]
	}
	[root@us-east-1 ceph]#

Добавьте применение infile зоны us-east и в east, и в west пулы:

# radosgw-admin zone set --rgw-zone=us-east --infile us-east.json --name client.radosgw.us-east-1

	[root@us-east-1 ceph]# radosgw-admin zone set --rgw-zone.us-east --infile us-east.json --name client.radosgw.us-east-1
	2015-05-03 21:56:38.878117 7fc365bd5880 0 couldn't find old data placement pools config, setting up new ones for the zone
	{ "domain_root": ".us-east.domain.rgw",
	  "control pool": ".us-east.rgw.control",
	  "gc_pool": ".us-east.rgw.gc",
	  "log_pool": ".us-east.log",
	  "intent_log_pool": ".us-east.intent-log",
	  "usage_log_pool": ".us-east.usage",
	  "user_keys_pool": ".us-east. users",
	  "user_email_pool": ".us-east.users.email",
	  "user_swift_pool": ".us-east.users.swift",
	  "user_uid_pool": ".us-east.users.uid",
	  "system_key": {
	    "access_key": "XNK0ST8WXTMWZGN29NF9",
	    "secret_key": "7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5",
	    "placement_pools": [
	      { "key": "default-placement",
	        "van { "index_pool": ".us-east.rgw.buckets.index",
	                    "data_pool": ".us-east.rgw.buckets",
	                    "data_extra_pool": ""}
	      }]
	}
	[root@us-east-1 ceph]#
	[root@us-east-1 ceph]#

Теперь выполните следующую команду:

# radosgw-admin zone set --rgw-zone=us-east --infile us-east.json --name client.radosgw.us-west-1

	[root@us-east-1 ceph]# radosgw-admin zone set --rgw-zone=us-east --infile us-east.json --name client.radosgw.us-west-1
	2015-05-03 21:58:58.982509 7f4b14f47880 0 couldn't find old data placement pools config, setting up new ones for the zone
	{ "domain_root": ".us-east.domain.rgw",
	  "control_pool": ".us-east.rgw.control",
	  "gc_pool": ".us-east.rgw.gc",
	  "log_pool": ".us-east.log",
	  "intent_log_pool": ".us-east.intent-log",
	  "usage_log_pool": ".us-east.usage",
	  "user_keys_pool": ".us-east.users",
	  "user_email_pool": ".us-east.users.email",
	  "user_swift_pool": ".us-east.users.swift",
	  "user_uid_pool": ".us-east.users.uid",
	  "system_key": {
	    "access_key": "XNK0ST8WXTMWZGN29NF9",
	    "secret_key": "7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"},
	    "placement_pools": [
	      "key": "default-placement",
	      "val": { "index_pool": ".us-east.rgw.buckets.index",
	               "data_pool": ".us-east.rgw.buckets",
	               "data_extra_pool": ""}
	             }]
	}
	[root@us-east-1 ceph]#
	[root@us-east-1 ceph]#

Аналогично, для зоны us-west создайте infile us-west.json со следующим содержимым. Вы можете для справки использовать авторскую версию файла us-west.json предоставляемую пакетом кода для данной главы:

{ "domain_root": ".us-west.domain.rgw",
  "control_pool": ".us-west.rgw.control",
  "gc_pool": ".us-west.rgw.gc",
  "log_pool": ".us-west.log",
  "intent_log_pool": ".us-west.intent-log",
  "usage_log_pool": ".us-west.usage",
  "user_keys_pool": ".us-west.users",
  "user_email_pool": ".us-west.users.email",
  "user_swift_pool": ".us-west.users.swift",
  "user_uid_pool": ".us-west.users.uid",
  "system_key": {
    "access_key": "AAK0ST8WXTMWZGN29NF9",
    "secret_key": "AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"},
    "placement_pools": [
    { "key": "default-placement",
      "val": { "index_pool": ".us-west.rgw.buckets.index",
               "data_pool": ".us-west.rgw.buckets"}
    }]
}

	[root@us-east-1 ceph]# cat us-west.json
	{ "domain_root": ".us-west.domain.rgw",
	  "control_pool": ".us-west.rgw.control",
	  "gc_pool": ".us-west.rgw.gc",
	  "log_pool": ".us-west.log",
	  "intent_logpool": ".us-west.intent-log",
	  "usage_log_pool": ".us-west.usage",
	  "user_keys_pool": ".us-west.users",
	  "user_email_pool": ".us-west.users.email",
	  "user_swift_pool": ".us-west.users.swift",
	  "user_uid_pool": ".us-west.users.uid",
	  "system_key": {
	    "access_key": "AAK0ST8WXTMWZGN29NF9",
	    "secret_key": "AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"},
	    "placement_pools": [
	    {"key": "default-placement",
	     "val:
	     {"index_pool": ".us-west.rgw.buckets.index",
	      "data_pool": ".us-west.rgw.buckets"}
	    }]
	}
	[root@us-east-1 ceph]#

Добавьте зону us-west с использованием infile в east и west пулы:

# radosgw-admin zone set --rgw-zone=us-west --infile us-west.json --name client.radosgw.us-east-1

	[root@us-east-1 ceph]# radosgw-admin zone set --rgw-zone=us-west --infile us-west.json --name client.radosgw.us-east-1
	2015-05-03 22:03:16.279758 7f4ac6bd4880 0 couldn't find old data placement pools config, setting up new ones for the zone
	{ "domain_root": ".us-west.domain.rge",
	  "control_pool": ".us-west.rgw.control",
	  "gc_pool": ".us-west.rgw.gc",
	  "log_pool": ".us-west.log",
	  "intent_log_pool": ".us-west.intent-log",
	  "usage_log_pool": ".us-west.usage",
	  "user_keys_pool": ".us-west.users",
	  "user_email_pool": ".us-west.users.email",
	  "user_swift_pool": ".us-west.users.swift",
	  "user_uid_pool": ".us-west.users.uid",
	  "system_key":
	  {"access_key": "AAK0ST8WXTMWZGN29NF9",
	   "secret_key": "AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"},
	  "placement_pools": [
	  { "key": "default-placement",
	    "val":
	    { "index_pool": ".us-west.rgw.buckets.index",
	      "data_pool": ".us-west.rgw.buckets",
	      "data_extra_pool": ""}
	  }]
	}
	[root@us-east-1 ceph]#
	[root@us-east-1 ceph]#

# radosgw-admin zone set --rgw-zone=us-west --infile us-west.json --name client.radosgw.us-west-1

	[root@us-east-1 ceph]# radosgw-admin zone set --rgw-zone=us-west --infile us-west.json --name client.radosgw.us-west-1
	2015-05-03 22:04:48.050644 7f74fd327880 0 couldn't find old data placement pools config, setting up new ones for the zone
	{ "domain_root": ".us-west.domain.rgw",
	  "control_pool": ".us-west.rgw.control",
	  "gc_pool": ".us-west.rgw.gc",
	  "log_pool": ".us-west.log",
	  "intent_log_pool": ".us-west.intent-log",
	  "usage_log_pool": ".us-west.usage",
	  "user_keys_pool": ".us-west.users",
	  "user_email_pool": ".us-west.users.email",
	  "user_swift_pool": ".us-west.users.swift",
	  "user_uid_pool": ".us-west.users.uid",
	  "system_key":
	  { "access_key": "AAKOST8WXTMWZGN29NF9",
	    "secret_key": "AA3m8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"},
	    "placement_pools": [
	      { "key": "default-placement",
	        "val": { "index_pool": ".us-west.rgw.buckets.index",
	        "data_pool": ".us-west.rgw.buckets",
	        "data_extra_pool": ""}
	      }]
	}
	[root@us-east-1 ceph]#
	[root@us-east-1 ceph]#

Удалите зону по умолчанию, если она существует:

# rados -p .rgw.root rm zone_info.default --name client.radosgw.us-east-1

Обновите карту региона:

# radosgw-admin regionmap update --name client.radosgw.us-east-1

После настройки зон создайте пользователей зон:

Создайте своего пользователя зоны us-east для вашего экземпляра шлюза us-east-1. Применяйте те же access_key и secret_key, которые мы сгенерировали ранее для зоны us-east:

# radosgw-admin user create --uid="us-east" --displayname="Region-US Zone-East" --name client.radosgw.useast-1 --access_key="XNK0ST8WXTMWZGN29NF9" --secret="7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5" --system

	[root@us-east-1 ceph]# radosgw-admin user create --uid="us-east" --displayname="Region-US Zone-East" --name client.radosgw.useast-1 --access_key="XNK0ST8WXTMWZGN29NF9" --secret="7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5" --system
	{ "user_id": "us-east",
	  "display_name": "Region-US Zone-East",
	  "email": "",
	  "suspended": 0,
	  "max_buckets": 1000,
	  "auid": 0,
	  "subusers": [],
	  "keys": [
	    { "user": "us-east",
	      "access_key": "XNK0ST8WXTMWZGN29NF9",
	      "secret_key": "7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"}],
	  "swift_keys": [],
	  "caps": [],
	  "op_mask": "read, write, delete",
	  "system": "true",
	  "default_placement": "",
	  "placement_tags" : [],
	  "bucket_quota":
	    { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects": -1},
	  "user_quota":
	    { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects": -1},
	  "temp_url_keys": []
	}
	[root@us-east-1 ceph]#

Создайте своего пользователя зоны us-west для вашего экземпляра шлюза us-west-1. Применяйте те же access_key и secret_key, которые мы сгенерировали ранее для зоны us-west:

# radosgw-admin user create --uid="us-west" --displayname="Region-US Zone-West" --name client.radosgw.uswest-1 --access_key="AAK0ST8WXTMWZGN29NF9" --secret="AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5" --system

	[root@us-east-1 ceph]# radosgw-admin user create --uid="us-west" --displayname="Region-US Zone-West" --name client.radosgw.uswest-1 --access_key="AAK0ST8WXTMWZGN29NF9" --secret="AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5" --system
	{ "user_id": "us-west",
	  "display_name": "Region-US zone-West",
	  "email": "",
	  "suspended": 0,
	  "max_buckets": 1000,
	  "auid": 0,
	  "subusers": [],
	  "keys": [
	    { "user": "us-west",
	      "access_key": "AAK0ST8WXTMWZGN29NF9",
	      "secret_key": "AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"}],
	  "swift_keys": [],
	  "caps": [],
	  "op_mask": "read, write, delete",
	  "system": "true",
	  "default_placement": "",
	  "placement_tags": [],
	  "bucket_quota":
	    { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects": -1},
	  "user_quota":
	    { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects": -1},
	  "temp_url_keys": []
	}
	[root@us-east-1 ceph]#

Создайте своего пользователя зоны us-east для вашего экземпляра шлюза us-west-1. Применяйте те же access_key и secret_key, которые мы сгенерировали ранее для зоны us-east:

# radosgw-admin user create --uid="us-east" --displayname="Region-US Zone-East" --name client.radosgw.uswest-1 --access_key="XNK0ST8WXTMWZGN29NF9" --secret="7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5" --system

	[root@us-east-1 ceph]# radosgw-admin user create --uid="us-east" --displayname="Region-US Zone-East" --name client.radosgw.uswest-1 --access_key="XNK0ST8WXTMWZGN29NF9" --secret="7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5" --system
	{ "user_id": "us-east",
	  "display_name" : "Region-US zone-East",
	  "suspended": 0,
	  "max.buckets" : 1000,
	  "auid" : 0,
	  "subusers": [] ,
	  "keys": [
	    { "user": "us-east",
	      "access_key" : "XNK0ST8WXTMWZGN29NF9",
	      "secret_key" : "7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"}] ,
	  "swift-keys": [],
	  "caps": [],
	  "op_mask" : "read, write, delete",
	  "system" : "true",
	  "default_placement" : "" ,
	  "placement_tags": [] ,
	  "bucket_guota" :
	    { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects, -1}",
	  "user_guota":
	    { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects": -1},
	  "temp_url_keys": []
	}
	[root@us-east-1 ceph]#

Создайте своего пользователя зоны us-west для вашего экземпляра шлюза us-east-1. Применяйте те же access_key и secret_key, которые мы сгенерировали ранее для зоны us-west:

# radosgw-admin user create --uid="us-west" --displayname="Region-US Zone-West" --name client.radosgw.useast-1 --access_key="AAK0ST8WXTMWZGN29NF9" --secret="AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5" --system

	[root@us-east-1 ceph]# radosgw-admin user create --uid="us-west" --displayname="Region-US Zone-West" --name client.radosgw.useast-1 --access_key="AAK0ST8WXTMWZGN29NF9" --secret="AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5" --system
	{ "user_id": "us-west",
	  "display_name" : "Region-US zone-west",
	  "suspended" : 0,
	  "max_buckets" : 1000,
	  "auid" : 0,
	  "subusers" : [] ,
	  "keys": [
	    { "user" : "us-west",
	      "access_key" : "AAK0ST8WXTMWZGN29NF9" ,
	      "secret_key" : "AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"}] ,
	  "swift_keys" : [] ,
	  "caps" : [] ,
	  "op_mask" : "read, write, delete",
	  "system" : "true",
	  "default_placement" : "" ,
	  "placement_tags" : [] ,
	  "bucket_guota" :
	    { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects" : -1} ,
	  "user_quota" :
	    { "enabled": false,
	      "max_size_kb" : -1,
	      "max_objects" : -1} ,
	  "temp_url _keys" : []
	}
	[root@us-east-1 ceph]#

Обновите сценарий инициализации ceph-radosgw и установите пользователем по умолчанию root. По умолчанию выполнение ceph-radosgw применяет пользователя Apache и вы можете столкнуться с ошибками если пользователь Apache отсутствует:

# sed -i s"/DEFAULT_USER.*=.*'apache'/DEFAULT_USER='root'"/g /etc/rc.d/init.d/ceph-radosgw

	[root@us-east-1 ceph]# cat /etc/rc.d/init.d/ceph-radosgw | grep -i root
	DEFAULT_USEIR = 'root'
	[root@us-east-1 ceph]#

Зарегистрируйтесь на ваших узлах us-east-1 и us-west-1 и перезапустите службу ceph-radosgw:

# systemctl restart ceph-radosgw

Проверьте что настройки региона, зоны и ceph-radosgw верны, выполните следующие команды с узла us-east-1:

# radosgw-admin regions list --name client.radosgw.us-east-1
# radosgw-admin regions list --name client.radosgw.us-west-1
# radosgw-admin zone list --name client.radosgw.us-east-1
# radosgw-admin zone list --name client.radosgw.us-west-1
# curl http://us-east-1.cephcookbook.com:7480
# curl http://us-west-1.cephcookbook.com:7480

	[root@us-east-1 ceph]# radosgw-admin regions list --name client.radosgw.us-east-1
	{ "default_info": {"default_region": "us"},
	  "regions": [
	       "us"]}
	[root@us-east-1 ceph]# radosgw-admin regions list --name client.radosgw.us-west-1
	{ "default_info": "default_region": "us"},
	  "regions": [
	       "us"]}
	[root@us-east-1 ceph]# radosgw-admin zone list --name client.radosgw.us-east-1
	{ "zones": [
	       "us-west",
	       "us-east"]}
	[root@us-east-1 ceph]# radosgw-admin zone list --name client.radosgw.us-west-1
	{ "zones": [
	      "us-west",
	      "us-east"]}
	[root@us-east-1 ceph]# curl http://us-east-1.cephcookbook.com:7480
	<?xml version="1.0" encoding="UTF-8"?>
	  <ListAllMyBucketsResult xmlns="http://s3.amazona ws.com/doc/2006-03-01/">
	  <Owner>
	  <ID>anonymous</ID>
	  <DisplayName></DisplayName>
	  </Owner>
	  <Buckets></Buckets>
	  </ListAllMyBucketsResult>
	[root@us-east-1 ceph]#
	[root@us-east-1 ceph]# curl http://us-west-1.cephcookbook.com:7480
	<?xml version="1.0" encoding="UTF-8"?>
	 <ListAllMyBucketsResult xmlns="http://s3.amazona ws.com/doc/2006-03-01/">
	 <Owner>
	 <ID>anonymous</ID>
	 <DisplayName></DisplayName>
	 </Owner>
	 <Buckets></Buckets>
	 </ListAllMyBucketsResult>
	[root@us-east-1 ceph]#
	[root@us-east-1 ceph]#

Настройте репликацию множества площадок создав файл cluster-data-sync.conf со следующим содержимым:

src_zone: us-east
source: http://us-east-1.cephcookbook.com:7480
src_access_key: XNK0ST8WXTMWZGN29NF9
src_secret_key: 7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5
dest_zone: us-west
destination: http://us-west-1.cephcookbook.com:7480
dest_access_key: AAK0ST8WXTMWZGN29NF9
dest_secret_key: AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5
log_file: /var/log/radosgw/radosgw-sync-us-east-west.log

	[root@us-east-1 ceph]# cat cluster-data-sync.conf
	srczone: us-east
	source: http://us-east-1.cephcookbook.com:7480
	src_access_key: XNK0ST8WXTMWZGN29NF9
	src_secret_key: 7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5
	dest_zone: us-west
	destination: http://us-west-1.cephcookbook.com:7480
	dest_access_key: AAK0ST8WXTMWZGN29NF9
	dest_secret_key: AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5
	/var/log/radosgw/radosgw-sync-us-east-west.log
	[root@us-east-1 ceph]#

Активируйте агента синхронизации данных. Когда синхронизация данных запустится, вы должны увидеть вывод аналогичный показанному ниже:

# radosgw-agent -c cluster-data-sync.conf

Рисунок 3.5. 

 Тестирование федеративных настроек radosgw

Для того, чтобы протестировать федеративную конфигурацию мы вначале добавим некоторые объекты в нашу зону us-east через экземпляр radosgw, us-east-1, используя Swift. Затем, после синхронизации данных между зонами us-east и us-west, мы получим доступ к тем же объектам из зоны us-west через интерфейс шлюза us-west-1.

  Как это сделать...

Создайте подпользователя Swift для пользователя зоны us-east:

# radosgw-admin subuser create --uid="us-east" --subuser="useast:swift" --access=full --name client.radosgw.us-east-1 --keytype swift --secret="7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"
# radosgw-admin subuser create --uid="us-east" --subuser="useast:swift" --access=full --name client.radosgw.us-west-1 --keytype swift --secret="7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"

	[root@us-east-1 ceph]# radosgw-admin subuser create --uid="us-east" --subuser="useast:swift" --access=full --name client.radosgw.us-east-1 --keytype swift --secret="7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"
	{ "user_id": "us-east",
	  "display_name:" "Region-US Zone-East",
	  "email": "",
	  "suspended": 0,
	  "max_buckets": 1000,
	  "avid": 0,
	  "subusers": [
	    { "id": "us-east:swift",
	      "permissions": "full-control"}],
	  "keys": [
	    { "user": "us-east",
	      "access_key": "XNK0ST8WXTMWZGN29NF9",
	      "secret_key": "7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"}],
	  "swiftkeys": [
	  { "user": "us-east:swift",
	    "secret_key": "7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"}],
	  "caps" : [],
	  "op_mask" : "read, write, delete",
	  "system": "true",
	  "default_placement":
	  "placement_tags": [],
	  "bucket_quota":
	    { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects": -1},
	  "user_quota":
	    { "enabled": false,
	      "max_size_kb": -1,
	      "max_objects": -1},
	  "temp_url_keys.: []
	}
	[root@us-east-1 ceph]#

Аналогично, создадим подпользователя Swift для пользователя зоныus-west:

# radosgw-admin subuser create --uid="us-west" --subuser="us-west:swift" --access=full --name client.radosgw.us-east-1 --key-type swift --secret="AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"
# radosgw-admin subuser create --uid="us-west" --subuser="us-west:swift" --access=full --name client.radosgw.us-west-1 --key-type swift --secret="AAJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5"

Установите клиента python-swift на узлах us-east-1 и us-west-1:

# yum install python-swift
# yum install python-setuptools
# easy_install pip
# pip install --upgrade setuptools
# pip install python-swiftclient

Соберите python-swiftclient на узле us-east-1:

# export ST_AUTH="http://us-east-1.cephcookbook.com:7480/auth/1.0"
# export ST_KEY=7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5
# export ST_USER=us-east:swift

Выведите перечень и создайте некоторые объекты на узле us-east-1:

# swift list
# swift upload container-1 us.json
# swift list
# swift list container-1

	[root@us-east-1 ceph]# export ST_AUTH="http://us-east-l.cephcookbook.com:7480/auth/1.0"
	[root@us-east-1 ceph]# export ST_KEY=7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5
	[root@us-east-1 ceph]# export ST_USER=us-east:swift
	[root@us-east-1 ceph]# swift list
	[root@us-east-1 ceph]# swift upload container-1 us.json
	us.json
	[root@us-east-1 ceph]# swift list
	container-1
	[root@us-east-1 ceph]#
	[root@us-east-1 ceph]# swift list container-1
	us.json
	[root@us-east-1 ceph]#

Активируем агента синхронизации данных:

# radosgw-agent -c cluster-data-sync.conf

Когда синхронизация данных завершится, попытайтесь осуществить доступ из зоны us-west применяя экземпляр шлюза us-west-1. На данном этапе данные должны быть доступными для вас из экземпляра шлюза us-west-1:

# export ST_AUTH="http://us-west-1.cephcookbook.com:7480/auth/1.0"
# export ST_KEY=7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5
# export ST_USER=us-east:swift
# swift list

	[root@us-west-1 ceph]# export ST_AUTH="http://us-west-1.cephcookbook.com:7480/auth/1.0"
	[root@us-west-1 ceph]# export ST_KEY=7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5
	[root@us-west-1 ceph]# export ST_USER=us-east:swift
	[root@us-west-1 ceph]# swift list
	container-1
	[root@us-west-1 ceph]# swift list container-1
	us.json
	[root@us-west-1 ceph]#

 Построение служб файловой синхронизации и совместного использования с применением RGW

Сслужбы синхронизации и совместного использования файлов, такие как Dropbox, Box, Google Drive и многие прочие, становятся чрезвычайно популярными в последние несколько лет. При помощи Ceph вы можете развёртывать локальную синхронизацию файлов и службы совместного использования применяя любые интерфейсы приложений на основе S3 или Swift, в этом рецепте мы продемонстрируем как построить синхронизацию файлов и службы совместного использования на основе Ceph и ownCloud.

Для построения такой службы нам понадобятся работающий кластер, экземпляр RGW, способный осуществлять дотуп к хранилищу Ceph через S3 и интерфейс среды ownClowd, как это показано ниже:

Рисунок 3.6. Схема служб файловой синхронизации и совместного использования Ceph и ownCloud

  Приготовление

В последнем рецепте мы настроили экземпляр radosgw, us-east-1; мы будем использовать тот же экземпляр шлюза в этом разделе для построения службы синхронизации файлоы и их совместного использования. Мы также применяем службу DNS, которая настроена на rgw-node1 для поддержки вызовов поддомена S3 для нашего экземпляра RGW us-east-1; однако, мы также можем применять любой другой DNS сервер если он позволяет разрешать поддомены для us-east-1.

  Как это сделать...

Зарегистриуйтесь на rgw-node1, который также является нашим сервером DNS и создайте файл /var/named/us-east-1.cephcookbook.com со следующим содержимым:

@ 86400 IN SOA cephcookbook.com. root.cephcookbook.com. (
	    20091028 ; serial yyyy-mm-dd
	    10800 ; refresh every 15 min
	    3600 ; retry every hour
	    3600000 ; expire after 1 month +
	    86400 ); min ttl of 1 day
@ 86400 IN NS cephbookbook.com.
@ 86400 IN A 192.168.1.107
* 86400 IN CNAME @

	[root@rgw-node1 ~]# cat /var/named/us-east-1.cephcookbook.com
	@ 86400 IN SOA cephcookbook.com. root.cephcookbook.com. (
	        20091028 ; serial yyyy-mm-dd
	        10800 ; refresh every 15 min
	        3600 ; retry every hour
	        3600000 ; expire after 1 month +
	        86400 ); min ttl of 1 day
	@ 86400 IN NS cephbookbook.com.
	@ 86400 IN A 192.168.1.107
	* 86400 IN CNAME @
	[root@rgw-node1 ~]#

Настройте ваш узел us-east-1 на применение вашего сервера DNS. Измените /etc/resolve.conf своими адресами rgw-node1 и выполните ping любого поддомена; это должно разрешить адрес us-east-1.

	[root@us-east-1 ~]# cat /etc/resolv.conf
	# Generated by NetworkManager
	search cephcookbook.com
	nameserver 192.168.1.106
	[root@us-east-1 ~]#
	[root@us-east-1 ~]# ping anything.us-east-l.cephcookbook.com -c 1
	PING us-east-l.cephcookbook.com (192.168.1.107) 56(84) bytes of data.
	64 bytes from us-east-l.cephcookbook.com (192.168.1.107): icmp_seq=1 tt1=64 time=0.038 ms

	--- us east-1.cephcookbook.com ping statistics ---
	1 packets transmitted, 1 received, 0% packet loss, time Oms
	rtt min/avg/max/mdev = 0.038/0.038/0.038/0.000 ms
	[root@us-east-1 ~]#

Убедитесь, что ваш узел us-east-1 может соединиться с кластером хранения Ceph поверх S3. В последнем рецепте мы создали пользователя с именем us-east и воспользуемся его доступом и ключом безопасности с помощью s3cmd:

Установите s3cmd:

# yum install -y s3cmd

Настройте s3cmd и предоставьте access_key установленный в XNK0ST8WXTMWZGN29NF9 и secret_key установленный в 7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5:

# s3cmd --configure

Измените /root/.s3cmd подробностями хоста:

host_base = us-east-1.cephcookbook.com:7480
host_bucket = %(bucket)s.us-east-1.cephcookbook.com:7480

Проверьте соединение s3cmd:

# s3cmd ls

Создайте сегмент (bucket) для ownCloud, который будет применяться для сохранения его объектов:

# s3cmd mb s3://owncloud

Далее мы установим ownCloud, который снабдит нас внешним и пользовательским интерфейсами для службы синхронизации и совместного применения файлов:

Поднимите виртуальную машину ownCloud с помощью Vagrant и зарегистрируйтесь на этой ВМ:

# vagrant up owncloud
# vagrant ssh owncloud

Установите репозиторий ownCloud следующим образом:

# cd /etc/yum.repos.d/
# wget http://download.opensuse.org/repositories/isv:ownCloud:community/CentOS_CentOS-7/isv:ownCloud:community.repo

Установите ownCloud как показано ниже:

# yum install owncloud -y

Поскольку это пробная сборка, запретим межсетевой экран:

# systemctl disable firewalld
# systemctl stop firewalld

Попытайтесь получитьдоступ к веб- интерфейсу ownCloud набрав на своём хосте в веб браузере http://192.168.1.120/owncloud/. Создайте учётную запись администратора с именем owncloud и паролем owncloud:

Рисунок 3.7. 

Первый экран регистрации будет выглядеть как это отображено ниже; в любое время мы можем применять ownClowd в качестве рабочего стола или мобильного приложения:

Рисунок 3.8. 

Настройте ownCloud для применения Ceph в качестве внешнего хранилища S3:

Из учётной записи администратора ownClowd сделайте доступным внешнее хранилище переместившись в Files | Apps | Not enabled | External Storage и кликнув на Enable it.

Далее настройте внешнее хранилище на применение Ceph. Для этого переместитесь в правую сторону окна и выберите пользователя ownCloud, затем выберите admin, а потом переместитесь в панель с левой стороны и выберите External Storage.

Настройте Amazon S3 и соответствующее хранилище под ownCloud, выбрав Enable User External Storage, а затем переместившись в Amazon S3 and compliant | Add Storage | Amazon S3 and Compliant.

Снабдите пользователя Ceph radosgw подробностями ключей доступа и безопасности, а также имени хоста:

Folder name: Введите имя вашей папки, которую вы хотите показывать на своей странице файлов ownCloud.

Access key: Введите ваш код доступа S3, XNK0ST8WXTMWZGN29NF9

Secret key: Введите ваш код безопасности S3, 7VJm8uAp71xKQZkjoPZmHu4sACA1SY8jTjay9dP5

Bucket: Введите имя вашего S3 сегмента, который мы создали на 3м шаге

: Введите us-east-1.cephcookbook.com

Port: Введите 7480

Region (не обязательно): Введите US

Available for: Введите owncloud (не обязательно)

Рисунок 3.9. 

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

Далее загрузите файлы через ownCloud своим пользовательским веб- интерфейсом. Для выполнения этого переместитесь в Files | External Storage и кликните на свой ceph-s3 загрузки файлов или каталогов.

Убедитесь что файлы были добавлены в ваш кластер хранения Ceph переключившись на узел us-east-1 и выполнив команду s3cmd ls s3://owncloud; вы должны получить файл, который вы загрузили через пользовательский веб- интерфейс ownCloud.

	[root@us-east-1 ~]# s3cmd ls s3://owncloud
	                       DIR   s3://owncloud/mona/
	2015-05-05 21:32    148481   s3://owncloud/eknumber.jpg
	[root@us-east-1 ~]#

Поздравляем! Вы научились строить свои частные службы синхронизации и совместного применения файлов с использованием хранилища объектов Ceph S3 и ownCloud.

  Смотрите также...

Для получения дополнительной информации по ownCloud, посетите https://owncloud.org/.

Глава 4. Работа с файловой системой Ceph

В данной главе мы охватим:

Понимание файловой системы Ceph и MDS

Развёртывание MDS Ceph

Доступ к CephFS через драйвер ядра

Доступ к CephFS через клиента FUSE

Экспорт файловой системы Ceph в качестве NFS

ceph-dokan – CephFS для клиентов Windows

CephFS вклинивающаяся замена HDFS

Содержание

4. Работа с файловой системой Ceph

Введение

Понимание файловой системы Ceph и MDS

Развёртывание MDS Ceph

Доступ к CephFS через драйвер ядра

Доступ к CephFS через клиента FUSE

Экспорт файловой системы Ceph в качестве NFS

ceph-dokan – CephFS для клиентов Windows

CephFS вклинивающаяся замена HDFS

 Введение

Файловая система Ceph, также называемая CephFS, является совместимой с POSIX файловой системой, которая применяет кластер хранения Ceph для хранения данных пользователя. CephFS пооддерживает внутренний драйвер ядра Linux, что делает CephFS высоко адаптивной для ОС Linux на любой вкус. В этой главе мы обсудим в деталях файловую систему Ceph, включая её развёртывание, понимание драйвера ядра и FUSE, а также клиентов CephFS для Windows.

 Понимание файловой системы Ceph и MDS

Файловая система Ceph предлагает POSIX- совместимую распределённую файловую систему любого размера, которая применяет для хранения своих данных Ceph RADOS. Для реализации файловой системы Ceph вамнужен работающий кластер хранения Ceph и по крайней мере один сервер метаданных Ceph (MDS, Metadata Serer) для управления его метаданными и их хранения в отдельности от данных, что помогает уменьшить сложность и улучшить надёжность. Следующая схема изображает взгляд на архитектуру CephFS и ее интерфейсы

Рисунок 4.1. Архитектура CephFS и ее интерфейсы

Библиотеки libcephfs играют важную роль в поддержке её реализаций множественности клиентов. Она имеет внутреннюю поддержку драйвера ядра Linux и таким образом клиенты могут использовать естественное монтирование файловой системы, например, с помощью команды mount. Она имеет тесную интеграцию с SAMBA и поддержку для CIFS и SMB. CephFS расширяет свою поддержку на файловую систему в пространстве пользователя (FUSE, Filesystem in USErspace) применяя модули cephfuse. Она также делает возможной прямой доступ из приложений в кластер RADOS с помощью библиотек libcephfs. CephFS приобретает популярность в качестве замены для Hadoop HDFS. Предыдущие версии HDFS поддерживали только единственный узел имён, что оказывало влияние на масштабируемость и создавало единую точку отказа; однако, это было изменено в современной версией HDFS. В отличие от HDFS, CephFS может быть реализована поверх множества MDS в состоянии активный-активный, предоставляя тем самым высочайшую масштабируемость, высокую производительность и отсутствие единой точки отказа.

Ceph MDS ставится для сервера метаданных и нужна только для файловой системы Ceph (CephFS); прочие методы блочного и объектового хранения не нуждаются в службах MDS. MDS Ceph работает в качестве демона, что позволяет клиенту монтировать файловую систему любого размера. MDS не передаёт никакие данные вашему клиенту напрямую; предоставление данных выполняется только OSD. MDS предоставляет совместно используемую когерентную файловую систему с уровнем интеллектуального кэширования, следовательно радикально уменьшая чтения и записи. Он расширяет свои преимущества на динамичное разделение поддеревьев и отдельных MDS для частей метаданных. Он динамичен по своей природе; демоны могут присоединяться и уходить, а также быстро захватывать отказавшие узлы.

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

CephFS на текущий момент не готов к промышленной эксплуатации, поскольку ему не хватает надёжных функций проверки/ восстановления fsck, множества активных MDS, а также снимков. Его развитие идёт очень быстро и мы можем ожидать, что он будет готов для промышленной эксплуатации начиная с Ceph Jewel. {Прим. пер.: на момент перевода (10 марта 2016) надёжный fsck пока недоступен, следите за CephFS for early adopters.} Для ваших не очень критически важных рабочих нагрузок рассмотрите возможность применения CephFS с единственным MDS без каких- либо снимков.

 Развёртывание MDS Ceph

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

  Как это сделать...

На ceph-node1 примените ceph-deploy для настройки MDS на ceph-node2:

# ceph-deploy --overwrite-conf mds create ceph-node2

	[root@ceph-node1 ceph]# ceph-deploy --overwrite-conf mds create ceph-node2
	[ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf
	[ceph_deploy.cli][INFO ] Invoked (1.5.22): /usr/bin/ceph-deploy --overwrite-conf mds create ceph-node2
	[ceph_deploy.mds][DEBUG ] Deploying mds, cluster ceph hosts ceph-node2:ceph-node2
	[ceph-node2][DEBUG ] connected to host: ceph-node2
	[ceph-node2][DEBUG ] detect platform information from remote host
	[ceph-node2][DEBUG ] detect machine type
	[ceph_deploy.mds][INFO ] Distro info: centOS Linux 7.0.1406 Core
	[ceph_deploy.mds][DEBUG ] remote host will use sysvinit
	[ceph_deploy.mds][DEBUG ] deploying mds bootstrap to ceph-node2
	[ceph-node2][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf
	[ceph-node2][DEBUG ] create path if it doesn't exist
	[ceph-node2][INFO ] Running command: ceph --cluster ceph --name client.bootstrap-mds --keyring /var/lib/c eph/bootstrap-mds/ceph.keyring auth get-or-create mds.ceph-node2 osd allow rwx mds allow mon allow profile mds -o /var/lib/ceph/mds/ceph-ceph-node2/keyring
	[ceph-node2][INF0 ] Running command: service ceph start mds.ceph-node2
	[ceph-node2][DEBUG ] === mds.ceph-node2 ===
	[ceph-node2][DEBUG ] Starting Ceph mds.ceph-node2 on ceph-node2...
	[ceph-node2][WARNIN] Running as unit run-4697.service.
	[ceph-node2][INF0 ] Running command: systemctl enable ceph
	[ceph-node2][WARNIN] ceph.service is not a native service, redirecting to /sbin/chkconfig.
	[ceph-node2][WARNIN] Executing /sbin/chkconfig ceph on
	[ceph-node2][WARNIN] The unit files have no [Install] section. They are not meant to be enabled
	[root@ceph-node1 ceph]#

Эта команда должна развернуть ваш MDS и запустить его демон на ceph-node2; однако нам потребуется выполнить ещё несколько шагов чтобы сделать CephFS доступным:

# ssh ceph-node2 service ceph status mds

	[root@ceph-node1 ceph]# ssh ceph-node2 service ceph status mds
	=== mds.ceph-node2 ===
	mds.ceph-node2: running {"version":"0.87.1"}
	[root@ceph-node1 ceph]#

Создайте пулы данных и метаданных для файловой системы Ceph:

# ceph osd pool create cephfs_data 64 64
# ceph osd pool create cephfs_metadata 64 64

Наконец, создайте файловую систему Ceph; после выполнения этой команды MDS должен получить активное состояние, а CephFS должна быть готова к применению:

# ceph fs new cephfs cephfs_metadata cephfs_data

	[root@ceph-node1 ceph]# ceph osd pool create cephfs_data 64 64
	pool 'cephfs data' created
	[root@ceph-node1 ceph]# ceph osd pool create cephfs_metadata 64 64
	pool 'cephfs_metadata' created
	[root@ceph-node1 ceph]#
	[root@ceph-node1 ceph]# ceph fs new cephfs cephfs_metadata cephfs_data
	new fs with metadata pool 44 and data pool 43
	[root@ceph-node1 ceph]#

Чтобы проверить состояние CephFS и MDS примените следующие команды:

# ceph mds stat
# ceph fs ls

	[root@ceph-node1 ceph]# ceph mds stat
	e10: 1/1/1 up {0=ceph-node2=up:active}
	[root@ceph-node1 ceph]# ceph fs ls
	name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
	[root@ceph-node1 ceph]#

Не рекомендуется использовать кольцо ключей пользователя client.admin совместно с клиентами Ceph, поэтому мы создадим пользователя client.cephfs в вашем кластере Ceph и позволим этому пользователю осуществлять доступ к пулу CephFS:

# ceph auth get-or-create client.cephfs mon 'allow r' osd 'allow rwx pool=cephfs_metadata,allow rwx pool=cephfs_data' -o /etc/ceph/client.cephfs.keyring
# ceph-authtool -p -n client.cephfs /etc/ceph/client.cephfs.keyring > /etc/ceph/client.cephfs
# cat /etc/ceph/client.cephfs

	[root@ceph-node1 ~]# ceph auth get-or-create client.cephfs mon 'allow r' osd 'allow rwx pool=cephfs_metadata,allow rwx pool=cephfs_data' -o /etc/ceph/client.cephfs.keyring
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph-authtool -p -n client.cephfs /etc/ceph/client.cephfs.keyring > /etc/ceph/client.cephfs
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# cat /etc/ceph/client.cephfs AQAGSF5VMIDWHhAAox9s/oHg/6FPzf4xRQV73Q==
	[root@ceph-node1 ~]#

 Доступ к CephFS через драйвер ядра

В ядро Linux 2.6.34 и более поздние версии была добавлена внутренняя поддержка для Ceph. В данном рецепте мы продемонстрируем то, как получить доступ к CephFS через драйвер ядра Linux на ceph-client1

  Как это сделать...

Проверьте версию ядра Linux вашего клиента:

# uname -r

Создайте точку монтирования каталога:

# mkdir /mnt/cephfs

Получите ключи для пользователя client-cephfs, которого мы создали в предыдущем разделе. С вашего узла монитора Ceph выполните следующую команду для получения ключей пользователя:

# ceph auth get-key client.cephfs

Смонтируйте CephFS применив внутренний вызов Linux mount со следующим синтаксисом::

Синтаксис:
	 mount -t ceph <Monitor_IP>:<Monitor_port>:/ <mount_point_name> -o name=admin,secret=<admin_user_key>

# mount -t ceph ceph-node1:6789:/ /mnt/cephfs -o name=cephfs,secret=AQAGSF5VMIDWHhAAox9s/oHg/6FPzf4xRQV73Q==

	root@client-node1:/etc/ceph# mount -t ceph ceph-node1:6789:/ /mnt/cephfs -o name=cephfs,secret= AQAGSF5VMIDWHhAAox9s/oHg/6FPzf4xRQV73Q==
	root@client-node1:/etc/ceph# df -h /mnt/cephfs
	Filesystem             Size Used Avail Use% Mounted on
	192.168.1.101:6789:/   135G 7.3G 128G    6% /mnt/cephfs
	root@client-node1:/etc/ceph#

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

# echo AQAGSF5VMIDWHhAAox9s/oHg/6FPzf4xRQV73Q== > /etc/ceph/cephfskey
# mount -t ceph ceph-node1:6789:/ /mnt/cephfs -o name=cephfs,secretfile=/etc/ceph/cephfskey

	root@client-node1:/etc/ceph# echo AQAGSF5VMIDWHhAAox9s/oHg/6FPzf4xRQV73Q== > /etc/ceph/cephfskey
	root@client-node1:/etc/ceph# umount /mnt/cephfs
	root@client-node1:/etc/ceph# mount -t ceph ceph-node1:6789:/ /mnt/cephfs -o name=cephfs,secretfile= /etc/ceph/cephfskey
	rootgclient-node1:/etc/ceph# df -h /mnt/cephfs
	Filesystem            Size  Used Avail Use% Mounted on
	192.168.1.101:6789:/  135G  7.3G  128G   6% /mnt/cephfs
	root@client-node1:/etc/ceph#

Чтобы сделать возможным монтирование CephFS во время запуска ОС, добавьте следующие строки в ваш файл /etc/fstab на ceph-client1:

Синтаксис: <Mon_ipaddress>:<monitor_port>:/ <mount_point> <filesystem-name> [name=username,secret=secretkey|secretfile=/path/to/secretfile],[{mount.options}]

# echo "ceph-node1:6789:/ /mnt/cephfs cephname=cephfs,secretfile=/etc/ceph/cephfskey,noatime 02" >> /etc/fstab

Размонтируйте CephFS и смонтируйте заново:

# umount /mnt/cephfs
# mount /mnt/cephfs

	root@client-node1:/etc/ceph# echo "ceph-node1:6789:/ /mnt/cephfs ceph name=cephfs,secretfile =/etc/ceph/cephfskey,noatime 02" >> /etc/fstab
	root@client-node1:/etc/ceph# cat /etc/fstab 1 grep cephfs
	ceph-node1:6789:/ /mnt/cephfs ceph name=cephfs,secretfile=/etc/ceph/cephfskey,noatime 02
	root@client-node1:/etc/ceph# umount /mnt/cephfs
	root@client-node1:/etc/ceph# mount /mnt/cephfs
	root@client-node1:/etc/ceph# df -h /mnt/cephfs
	Filesystem            Size  Used Avail Use% Mounted on
	192.168.1.101:6789:/  135G  7.3G  128G   6% /mnt/cephfs
	root@client-node1:/etc/ceph#

Выполните какие- нибудь операции ввода/ вывода в вашей файловой системе Ceph, а затем размонтируйте её:

# dd if=/dev/zero of=/mnt/cephfs/file1 bs=1M count=1024
# umount /mnt/cephfs

	root@client-node1:~# dd if=/dev/zero of=/mnt/cephfs/file1 bs=1M count=1024
	1024+0 records in
	1024+0 records out
	1073741824 bytes (1.1 GB) copied, 58.9853 s, 18.2 MB/s
	root@client-node1:~#
	root@client-node1:~# ls -1 /mnt/cephfs/file1
	-rw-r--r-- 1 root root 1073741824 May 20 21:15 /mnt/cephfs/file1
	root@client-node1:~#

 Доступ к CephFS через клиента FUSE

Файловая система Ceph внутренне поддерживается ядром Linux; однако, если ваш хост работает с более ранними версиями ядра, или у вас существует зависимость от каких- то приложений, то вы всегда можете воспользоваться клиентом FUSE (Filesystem User Space) для Ceph чтобы смонтировать CephFS.

  Как это сделать...

Установите пакет Ceph FUSE на своей машине client-node1:

# uname -r

Создайте файл кольца ключей своей CephFS, /etc/ceph/client.cephfs.keyring со следующим содержимым:

[client.cephfs]
key = AQAGSF5VMIDWHhAAox9s/oHg/6FPzf4xRQV73Q==

Смонтируйте CephFS используя своего клиентаCeph FUSE :

# ceph-fuse --keyring /etc/ceph/client.cephfs.keyring --name client.cephfs -m ceph-node1:6789 /mnt/cephfs

	root@client-node1:/etc/ceph# ceph-fuse --keyring /etc/ceph/client.cephfs.keyring --name client.cephfs
	-m ceph-node1:6789 /mnt/cephfs
	ceph-fuse[3356]: starting ceph client
	2015-05-21 21:46:05.599027 7fc80ea017c0 -1 init, newargv = 0x45663a0 newargc=11
	ceph-fuse[3356]: starting fuse
	root@client-node1:/etc/ceph#
	root@client-node1:/etc/ceph# df -h /mnt/cephfs
	Filesystem      Size  Used Avail Use% Mounted on
	ceph-fuse       135G  7.3G 128G    6% /mnt/cephfs
	root@client-node1:/etc/ceph#

Чтобы монтировать CephFS при загрузке ОС, добавьте следующие строки в свой файл /etc/fstab на client-node1:

id=cephfs,keyring=client.cephfs.keyring        /mnt/cephfs fuse.ceph defaults 00

Размонтируйте CephFS и смонтируйте заново:

# umount /mnt/cephfs
# mount /mnt/cephfs

 Экспорт файловой системы Ceph в качестве NFS

Network Filesystem (NFS) является одним из самых популярных протоколов совместно используемых файловых систем, который может применяться в любой системе на базе Unix. Клиенты на основе Unix, которые не понимают вашу CephFSмогут всё же получить доступ к файловой системе Ceph применяя NFS. Для этого нам понадобится сервер NFS в месте, которое может реэкспортировать CephFS в качестве разделяемого ресурса NFS. NFS-Ganesha является сервером NFS, который работает в пользовательском пространстве и поддерживает CephFS FSAL (File System Abstraction Layer, уровень абстракции файловой системы) пр помощи libcephfs.

В данном рецепте мы продемонстрируем создание ceph-node1 в качестве сервера NFS-Ganesha и экспорт CephFS в виде NFS, а также её монтирование на client-node1.

  Как это сделать...

На ceph-node1 установите необходимые nfs-Ganesha пакеты:

# yum install -y nfs-utils nfs-ganesha nfs-ganesha-fsal-ceph

Поскольку это тестовая сборка, запретите межсетевой экран. Для ваших промышленных установок вы должны рассмотреть разрешение необходимых вам портов в межсетевом экране, обычно это 2049:

# systemctl stop firewalld; systemctl disable firewalld

Сделайте доступными необходимые NFS службы rpc:

# systemctl start rpcbind; systemctl enable rpcbind
# systemctl start rpc-statd.service

Создайте свой файл настроек NFS-Ganesha, /etc/ganesha.conf, со следующим содержимым:

EXPORT
{
	Export_ID = 1;
	Path = "/";
	Pseudo = "/";
	Access_Type = RW;
	NFS_Protocols = "3";
	Squash = No_Root_Squash;
	Transport_Protocols = TCP;
	SecType = "none";
	FSAL {
		Name = CEPH;
	}
}

Наконец, запустите демон ganesha nfs снабдив его файлом ganesha.conf, который мы создали на нашем последнем шаге. Вы можете проверить экспортированные совместные ресурсы NFS применив команду showmount:

# ganesha.nfsd -f /etc/ganesha.conf -L /var/log/ganesha.log -N NIV_DEBUG -d
# showmount -e

	[root@ceph-node1 ~]# ganesha.nfsd -f /etc/ganesha.conf -L /var/log/ganesha.log -N NIVDEBUG -d
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ps -ef | grep nfs
	root      7975     1  0 00:55 ?     00:00:00 ganesha.nfsd -f /etc/ganesha.conf -L /var/log/ganesha.log -N NIVJEBUG -d
	root      8023  5901  0 00:56 pts/O 00:00:00 grep --color=auto -i nfs
	[root@ceph-node1 ~]#

Давайте повторим те шаги, которые мы только что проделали: ceph-node2 был настроен в качестве Ceph MDS, а ceph-node1 был настроен в качестве сервера NFS-Ganesha.

Далее, чтобы смонтировать совместно используемые ресурсы NFS на машинах клиентов, нам нужно просто установить пакеты клиентов NFS и смонтировать наши разделяемые ресурсы экспортируемые ceph-node1 как показано далее:

Установите пакеты своего клиента nfs на ceph-node1 и выполните mount:

# apt-get install nfs-common
# mkdir /mnt/cephfs
# mount -o rw,noatime 192.168.1.101:/ /mnt/cephfs

	root@client-node1:~# mount -o rw,noatime 192.168.1.101:/ /mnt/cephfs
	root@client-node1:~# df -h
	Filesystem       Size  Used Avail Use% Mounted on
	/dev/sdal         40G  1.1G   37G   3% /
	none             4.0K     0  4.0K   0% /sys/fs/cgroup
	udev             241M   12K  241M   1% /dev
	tmpfs             49M  356K   49M   1% /run
	none             5.0M     0  5.0M   0% /run/lock
	none             245M     0  245M   0% /run/shm
	none             100M     0  100M   0% /run/user
	192.168.1.101:/  135G  7.3G  128G   6% /mnt/cephfs
	root@client-node1:~#

 ceph-dokan – CephFS для клиентов Windows

До текущего момента мы изучали различные методы доступа к CephFS,такие как Ceph FUSE, драйвер Ceph ядра и NFS Ganesha; однако, эти методы могут применяться только в системах на базе Linux и их работа не поддерживается на машинах клиентов на основе Windows.

Проекты с открытым исходным кодом наподобие Ceph имеют свои собственные преимущества; Ceph развил вокруг себя благоденствующее сообщество. ceph-dokan является внутренним клиентом Windows Ceph, разработанным Менг Шенджи (Meng Shengzhi), работающим главным инженером по системам хранения в UnitedStack. Помимо разработок OpenStack и Ceph, Менг управляет проектом ceph-dokan.

ceph-dokan позволяет доступ к CephFS с платформы Windows. Для этого ceph-dokan применяет два ключевых компонента: libcephfs.dll, который является приложением для доступа к CephFS и ceph-dokan.exe, который основан на проекте Dokan по предоставлению службы файловой системы, подобной FUSE, на платформе Windows, что помогает в монтировании CephFS в качестве локального диска в системах Windows. В своей основе ceph-dokan.exe использует dokan.dll и libcephfs.dll для реализации вашего пользовательского пространства файловой системы win32. Как и Ceph, ceph-dokan также является проектом с открытым исходным кодом и доступен на GitHub по адресу https://github.com/ceph/ceph-dokan. Запросы на помощь для этого проекта могут посылаться в любое время. Вы можете построить ceph-dokan из исходного кода доступного на GiHub; однако для простоты вы можете воспользоваться ceph-dokan.exe, который может быть найден в каталоге ceph-dokan репозитория GitHub ceph-cookbook, который вы уже клонировали в предыдущей главе.

  Как это сделать...

Настройте машину Windows 7 или 8 иподключите ее в своюсеть, ту же гда находится ваш кластер Ceph (192.168.1.0/24).

Убедитесь, что вы можете связаться с узлами монитора Ceph проверив доступ с применением команды telnet из командной строки:

telnet 192.168.1.101 6789

Когда вы убедились, что имеете возможность доступа к кластеру Ceph, загрузите ceph-dokan.exe и DokanInstall_0.6.0.exe с https://github.com/ksingh7/cephcookbook/tree/master/ceph-dokan на свой клиент Windows.

Установите DokanInstall_0.6.0.exe; если вы используете ОС Windows 8, вы должны установить его в режим совместимости.

Рисунок 4.2. Установка библиотеки Dokan

Откройте командную строку Windows и смените каталог на абсолютный путь в каталог с установленным ceph-dokan.exe.

В клиенте Windows cоздайте файл ceph.conf со следующим содержимым, которое известит ceph-dokan о ваших мониторах кластера Ceph:

[global]
auth client required = none
log_file = dokan.log
mon_initial_members = ceph-node1
mon_host = 192.168.1.101
[mon]
[mon.ceph-node1]
mon addr = 192.168.1.101:6789

[Замечание]
Замечание

Так как ceph-dokan может читать ceph.conf только если он записан в формате Unix, вам следует преобразовать ceph.conf в формат Unix с помощью утилиты dos2unix. {Прим. пер.: Или воспользоваться в своём редакторе режимом Unix для сохранения файлов (символ конца строки #0A, вместо #0D#0A для Windows)}. За дополнительной информацией по утилите обратитесь к http://sourceforge.net/projects/dos2unix/.

В настоящее время ceph-dokan не поддерживает аутентификацию cephx. Поэтому, для применения nfs-Ganesha вам понадобится запретить cephx на всех ваших машинах монитора кластера Ceph.

Чтобы запретить cephx в кластере Ceph измените свой файл /etc/ceph/ceph.conf в элементах, связанных с аутентификацией на none:

auth_cluster_required = none
auth_service_required = none
auth_client_required = none

После изменения ceph.conf, перезапустите службы ceph на всех своих узлах мониторов:

# service ceph restart

Убедитесь, что cephx запрещён:

# ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok config show | grep -i auth | grep -i none

	[root@ceph-node1 ceph]# ceph --admin-daemon /var/run/ceph/ceph-osd.O.asok config show | grep auth | grep -i none
	  "auth_cluster_required": "none",
	  "auth_service_required": "none",
	  "auth_client_required": "none",
	  [root@ceph-node1 ceph]#

Наконец, в клиенте Windows выполните ceph-dokan.exe для монтирования CephFS в качестве диска. В командной строке выполните:

ceph-dokan.exe -c ceph.conf -l m

	[root@ceph-node1 ~]# ganesha.nfsd -f /etc/ganesha.conf -L /var/log/ganesha.log -N NIV_DEBUG -d
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ps -ef | grep -i nfs
	root      7975     1  0 00:55 ?         00:00:00 ganesha.nfsd -f /etc/ganesha.conf -L /var/log/ganesha.log -N NIV_DEBUG -d
	root      8023  5901  0 00:56 pts/0     00:00:00 grep --color.auto nfs
	[root@ceph-node1 ~]#

Эта команда должна смонтировать CephFS как локальный диск в вашем клиенте Windows.

Рисунок 4.3. CephFS в качестве локального диска

И CephFS, и ceph-dokan требуют дополнительного участия и развития для достижения достаточной зрелости в поддержке рабочих нагрузок с промышленным применением. Однако, они являются хорошими претендентами на тестирование и на присутствие в роли концептуального прототипа (PoC).

 CephFS вклинивающаяся замена HDFS

Hadoop является программной инфраструктурой которая поддерживает обработку и хранение больших наборов данных в распределённых вычислительных средах. Ядро Hadoop содержит механизм аналитики Map-Reduce и распределённую файловую систему, называемую HDFS ((Hadoop Distributed File System), которая имеет ряд слабых мест, перечисленных здесь:

Она имеет единую точку отказа, за исключением только что вышедшей версии HDFS

Она не является POSIX совместимой

Она хранит по крайней мере 3 копии данных

Она имеет централизованный сервер имён, делающий проблематичным в результате её масштабирование

Проект Apache Hadoop и прочие производители программного обеспечения независимо работают над заполнением этих пробелов в HDFS.

Сообщество Ceph выполнило некоторые разработки в этом пространстве и оно имеет встраиваемый системный модуль (plugin) для Hadoop который возможно преодолеет ограничения HDFS и может быть использован как вклинивающаяся замена для этого проекта. Существуют три требования для использования CephFS с Hadoopж; это:

Работа вашего кластера Ceph

Работа кластера Hadoop

Установка встраиваемого модуля (plugin) CephFS Hadoop

Реализация Hadoop и HDFS выходят за рамки данной книги, однако в этом разделе мы поверхностно обсудим как CephFS может быть использована совместно с HDFS. Клиенты Hadoop могут получать доступ к CephFS через встраиваемый модуль (plugin) на основе java с именем hadoop-cephfs.jar. Для поддержки связи Hadoop с CepfFS необходимы два приводимых ниже класса java.

libcephfs.jar: Этот файл должен быть помещён в /usr/share/java/, а его путь должен быть добавлен в HADOOP_CLASSPATH в файле Hadoop_env.sh.

libcephfs_jni.so: Этот файл должен быть добавлен в ваш параметр окружения LD_LIBRARY_PATH и помещён в /usr/lib/hadoop/lib. Вам следует также программно привязать (soft link) его в /usr/lib/hadoop/lib/native/Linux-amd64-64/libcephfs_jni.so.

Кроме того, встроенный клиент CephFS должен быть установлен на каждом узле кластера Hadoop. Для дополнительной и самой последней информацмм использования CephFS для Hadoop, пожалуйста, обращайтесь к официальной документации Ceph на http://ceph.com/docs/master/cephfs/hadoop и к GitHub Ceph на странице https://github.com/ceph/cephfs-hadoop.

Глава 5. Мониторинг кластеров Ceph с применением Calamari

В данной главе мы охватим:

Мониторинг кластера Ceph - классический путь

Мониторинг кластеров Ceph

Введение в Ceph Calamari

Построение пакетов Calamari сервер

Построение пакетов Calamari клиент

Наладка главного сервера Calamari

Добавление узлов Ceph в Calamari

Мониторинг кластера Ceph в инструментальной панели Calamari

Обнаружение ошибок Calamari

Содержание

5. Мониторинг кластеров Ceph с применением Calamari

Введение

Мониторинг кластера Ceph - классический путь

Мониторинг кластеров Ceph

Наблюдение за мониторами Ceph

Мониторинг OSD Ceph

Мониторинг MDS Ceph

Введение в Ceph Calamari

Построение пакетов Calamari сервер

Построение пакетов Calamari клиент

Наладка главного сервера Calamari

Добавление узлов Ceph в Calamari

Мониторинг кластера Ceph в инструментальной панели Calamari

Обнаружение ошибок Calamari

 Введение

Вне зависимости от того есть ли у вас небольшой, средний или экзамасштабный кластер, мониторинг является наиболее критически важной частью вашей инфраструктуры. После окончания вами проектирования, развёртывания и реализации промышленных служб вашего кластера Ceph, мониторинг становится главной обязанностью администратора системы хранения. В данной главе мы узнаем о различных подходах к наблюдению за вашим кластером Ceph и его компонентами. Мы рассмотрим как мониторинг через командную строку (CLI), так и через графический интерфейс (GUI), использующий встроенный инструментария CLI; мы также внедрим Calamari, являющийся инструментальной панелью управления кластером Ceph с открытым исходным кодом.

 Мониторинг кластера Ceph - классический путь

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

Наблюдение за кластером Ceph является повседневной задачей, которая включает в себя мониторинг MON, OSD, MDS, PG, а также подготовку служб хранения таких, как RBD, Radosgw, CephFS и клиентов Ceph. По умолчанию Ceph поставляется с богатым набором инструментария командной строки и API для выполнения наблюдения за этими компонентами. Кроме того, существуют проекты с открытым исходным кодом которые интенсивно развиваются для целей мониторинга кластеров Ceph в инструментальной панели единого обзора с GUI. В следующем рецепте мы сосредоточимся на инструментах CLI Ceph для мониторинга кластера.

 Мониторинг кластеров Ceph

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

  Как это сделать...

Здесь мы распространяемся о мониторинге вашего кластера Ceph. Далее шаги раскрываются в поясняющих темах.

Проверка жизнеспособности кластера

Для проверки жизнеспособности вашего кластера примените команду ceph с последующим health в качестве параметра:

# ceph health

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

	[root@ceph-node1 ~]# ceph health
	HEALTH_WARN 64 pgs degraded; 1408 pgs stuck unclean; recovery 1/5744 objects degraded (0.017%)
	[root@ceph-node1 ~]#

Первый раздел вывода показывает что ваш кластер находится в состоянии предостережения, HEALTH_WARN, поскольку 64 группы размещения (PG, placement groups) деградировали. Второй раздел представляет, что 1408 PG не очищены, третий раздел вывода представляет, что кластер выполняет восстановление 1 из 5744 объектов и этот кластер на 0.017% деградировал. Если ваш кластер жизнеспособен, вы получите вывод, что HEALTH_OK.

Для получения дополнительных деталей по состоянию вашего кластера примените команду ceph health detail. Эта команда сообщит вам обо всех PG, которые не активны и не очищены, т.е. здесь будут выведены с подробностями все PG, которые не очищены, не согласованы и деградировали. Если ваш кластер в жизнеспособен, вы получите вывод, что HEALTH_OK.

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

	[root@ceph-node2 ceph]# ceph health detail
	HEALTH_ERR 61 pgs degraded; 6 pgs inconsistent; 1312 pgs stuck unclean; recovery 3/5746 objects degraded (0.052%); 8 scrub errors
	pg 9.76 is stuck unclean since forever, current state active+remapped, last acting [7,3,2]
	pg 8.77 is stuck unclean since forever, current state active+remapped, last acting [4,6,8]
	pg 7.78 is stuck unclean for 788849.714074, current state active+remapped, last acting [6,5,1]
	pg 6.79 is stuck unclean since forever, current state active+remapped, last acting [4,7,8]
	pg 5.7a is stuck unclean since forever, current state active+remapped, last acting [7,4,2]
	pg 4.7b is stuck unclean since forever, current state active+remapped, last acting [7,3,1]
	pg 11.74 is stuck unclean for 788413.925336, current state active+remapped, last acting [4,7,8]
	pg 10.75 is stuck unclean for 788412.797947, current state active+remapped, last acting [7,3,0]

Мониторинг событий кластера

Вы можете наблюдать за событиями кластера применяя команду ceph с параметром -w. Эта команда высветит сообщения обо всех событиях вашего кластера, включая информационные (INF), предостерегающие (WRN) и сообщения об ошибках (ERR) в реальном времени. Вывод данной команды будет непрерывным, изменяемым кластеров вживую; для возврата в оболочку вы можете применить Ctrl + C:

# ceph -w

	[root@ceph-node1 ~]# ceph -w
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
	     health HEALTH_OK
	     monmap e3: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0}, election epoch 640, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
	     mdsmap e68: 1/1/1 up {0=ceph-node2=up:active}
	     osdmap e1821: 9 osds: 9 up, 9 in
	      pgmap v20731: 1628 pgs, 45 pools, 2422 MB data, 3742 objects
	            7605 MB used, 127 GB / 134 GB avail
	                1628 active+clean

	2015-06-06 20:13:27.047075 mon.0 [INF] pgmap v20731: 1628 pgs: 1628 active+clean; 2422 MB data, 7605 MB used, 127 GB / 134 GB avail; 7931 kB/s, 1 objects/s recovering
	2015-06-06 20:14:25.958762 mon.0 [INF] from.'client.? 192.168.1.103:0/1008239' entity='cli ent.admin' cmd.[{"prefix": "pg repair", "pgid": "43.29"}]: dispatch
	2015-06-06 20:14:32.031029 mon.0 [INF] pgmap v20732: 1628 pgs: 1628 active+clean; 2422 MB data, 7605 MB used, 127 GB / 134 GB avail
	2015-06-06 20:14:57.541278 mon.0 [INF] pgmap v20733: 1628 pgs: 1628 active+clean; 2422 MB data, 7621 MB used, 127 GB / 134 GB avail
	2015-06-06 20:15:02.371735 mon.0 [INF] pgmap v20734: 1628 pgs: 1628 active+clean; 2422 MB data, 7633 MB used, 127 GB / 134 GB avail

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

--watch-debug: для отслеживания сообщений отладки

--watch-info: для отслеживания информационных сообщений

--watch-sec: для отслеживания сообщений безопасности

--watch-warn: для отслеживания предупреждающих сообщений

--watch-error: для отслеживания сообщений об ошибке

Статистика использования кластера

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

# ceph df

	[root@ceph-node1 ..]# ceph df
	GLOBAL:
	    SIZE     AVAIL      RAW USED       %RAW USED
		134G       127G        7440M            5.39
	POOLS:
	    NAME                              ID      USED      %USED     MAX AVAIL     OBJECTS
	    rbd                               0         114M     0.08        42924M        2629
	    images                            1       53002k     0.04        42924M          12
	    volumes                           2           47        0        42924M           8
	    vms                               3         208M     0.15        42924M          31
	    .rgw.root                         4          162        0        42924M           2
	    .rgw.control                      5            0        0        42924M           8
	    .rgw                              6         2731        0        42924M          15
	    .rgw.gc                           7            0        0        42924M          32
	    .users.uid                        8          736        0        42924M           4
	    .users.email                      9            8        0        42924M           1
	    .users                            10          16        0        42924M           2
	    .users.swift                      11           8        0        42924M           1
	    .rgw.buckets.index                12           0        0        42924M           9
	    .rgw.buckets                      13        1744        0        42924M           4

Проверка состояния кластера

Проверка состояния кластера является наиболее общей и наиболее частой операцией при управлении кластером Ceph. Вы можете проверить состояние вашего кластера с применением команды ceph и status в качестве параметра:

# ceph status

Вместо подкоманды status вы можете применить более короткую версию, -s, как опцию:

# ceph -s

Следующий снимок экрана покажет состояние нашего кластера:

	[root@ceph-node1 ~]# ceph -s
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
	    health HEALTH_OK
	    monmap e3: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0}, election epoch 640, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
	    mdsmap e73: 1/1/1 up {0=ceph-node2=up:active}
	    osdmap el823: 9 osds: 9 up, 9 in
	     pgmap v20762: 1628 pgs, 45 pools, 2422 MB data, 3742 objects
	           7440 MB used, 127 GB / 134 GB avail
	               1628 active+clean
	[root@ceph-node1 ~]#

Эта команда выводит на экран массу полезной информации для вашего кластера Ceph:

cluster: Эта команда представляет ваш уникальный идентификатор кластера Ceph.

health: Эта команда показывает жизнеспособность кластера

monmap: Эта команда представляет версию эпохи карты монитора, информацию о мониторе, версию эпохи выбора монитора и состояние кворума монитора.

mdsmap: Эта команда представляет вашу версию эпохи mdsmap и ваше состояние mdsmap.

osdmap: Эта команда представляет вашу эпоху osdmap, общее число OSD (total), число работающих OSD (up) и число OSD в наличии (in).

pgmap: Эта команда показывает вашу версию pgmap, общее число PG, число пулов, используемая ёмкость для одной копии, а также общее число объектов. Она также отображает информацию об использовании кластера, включая размер использования, размер свободного пространства и общий размер. Наконец, она отображает состояние PG.

[Замечание]
Замечание

Чтобы увидеть состояние кластера в реальном времени, вы можете применить ceph status в команде Linux watch:

# watch ceph -s

Записи аутентификации вашего кластера

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

# ceph auth list

[Замечание]
Замечание

Чтобы узнать больше об операциях команды вы можете использовать help в качестве дополнительного параметра. Например, выполните # ceph auth --help и примените команду согласно предписаниям подсказки.

 Наблюдение за мониторами Ceph

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

  Как это сделать...

Мы сосредоточимся сейчас на командах для наблюдения за мониторами. Шаги будут раскрываться в поясняющих темах.

Проверка состояния монитора

Для отображения состояния монитора кластера и карты MAP воспользуйтесь командой ceph с дополнительным параметром либо mon stat либо mon dump:

# ceph mon stat
# ceph mon dump

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

	[root@ceph-node1 ~]# ceph mon stat
	e3: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3 =192.168.1.103:6789/0}, election epoch 640, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph mon dump
	dumped monmap epoch 3
	epoch 3
	fsid 9609b429-eee2-4e23-af31-28a24fcf5cbc
	last_changed 2015-03-18 00:20:07.092486
	created 0.000000
	0: 192.168.1.101:6789/0 mon.ceph-node1
	1: 192.168.1.102:6789/0 mon.ceph-node2
	2: 192.168.1.103:6789/0 mon.ceph-node3
	[root@ceph-node1 ~]#

Проверка состояния кворума мониторов

Для поддержания кворума между мониторами Ceph кластер всегда должен иметь более половины доступных в кластере мониторов. Проверка состояния кворума вашего кластера очень полезна во время определения проблем с мониторами. Вы можете проверить состояние кворума при помощи команды ceph с подкомандой quorum_status:

# ceph quorum_status -f json-pretty

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

	[root@ceph-node1 ~]# ceph quorum_status -f json-pretty

	{ "election_epoch": 640,
	  "quorum": [
	        0,
	        1,
	        2],
	  "quorum_names": [
	        "ceph-node1",
	        "ceph-node2",
	        "ceph-node3"],
	  "quorum_leader_name": "ceph-node1",
	  "monmap": { "epoch": 3,
	      "fsid": "9609b429-eee2-4e23-af31-28a24fcf5cbc",
	      "modified": "2015-03-18 00:20:07.092486,
	      "created": "0.000000",
	      "mons": [
		        { "rank": 0,
	              "name": "ceph-node1",
	              "addr": "192.168.1.101:6789\/0"},
	            { "rank": 1,
				  "name": "ceph-node2",
	              "addr": "192.168.1.102:6789\/0},
	            { "rank": 2,
	              "name": "ceph-node3",
	              "addr": "192.168.1.103:6789\/0"}]}}
	[root@ceph-node1 ~]#

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

[Замечание]
Замечание

Для генерации форматированного вывода команды Ceph применяйте параметр -f json-pretty.

 Мониторинг OSD Ceph

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

  Как это сделать...

Мы сосредоточимся сейчас на командах для наблюдения за OSD. Шаги будут раскрываться в последующих поясняющих темах:

Обзор дерева OSD

Обзор дерева OSD очевидно полезен для получения информации о состояниях OSD таких как IN или OUT и UP или DOWN. Обзор дерева OSD отображает все узлы со всеми их OSD и их местоположение в карте CRUSH. Вы можете попробовать отображение своего дерева OSD с применением следующей команды:

# ceph osd tree

	[root@ceph-node1 ~]# ceph osd tree
	# id    weight  type name       up/down reweight
	-1      0.08995 root default
	-2      0.02998         host ceph-node1
	0       0.009995                        osd.0   up      1
	1       0.009995                        osd.1   up      1
	2       0.009995                        osd.2   up      1
	-3      0.02998         host ceph-node2
	3       0.009995                        osd.3   up      1
	4       0.009995                        osd.4   up      1
	5       0.009995                        osd.5   up      1
	-4      0.02998         host ceph-node3
	6       0.009995                        osd.6   up      1
	7       0.009995                        osd.7   up      1
	8       0.009995                        osd.8   up      1
[root@ceph-node1 ~]#

эта команда отображает различную полезную информацию для OSD Ceph, такую как вес, состояние UP/DOWN и IN/OUT. Выдача будет прекрасно отформатирована в виде вашей карты Ceph CRUSH. Если вы сопровождаете большой кластер, этот формат даст вам преимущества определения местоположения OSD и его сервера хоста в длинном перечне.

Статистика OSD

Чтобы проверить статистику OSD, примените # ceph osd stat; эта команда поможет вам получить эпоху карты, общее число OSD и их состояния IN и UP.

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

# ceph osd dump

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

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

Для отображения клиентов в чёрном списке выполните следующую команду:

# ceph osd blacklist ls

Проверка вашей карты CRUSH

Вы можете запрашивать свою карту CRUSH непосредственно из команд # ceph osd. Утилита командной строки карты CRUSH может сохранить много времени системного администратора, по сравнению с обычным способом просмотра и её редактирования после декомпиляции вашей карты CRUSH:

Для просмотра карты CRUSH выполните следующую команду:

# ceph osd crush dump

Для просмотра правил карты CRUSH выполните следующую команду:

# ceph osd crush rule list

Для просмотра подробностей правил карты CRUSH выполните следующую команду:

# ceph osd crush rule dump <crush_rule_name>

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

	[root@ceph-node1 ~]# ceph osd crush rule list
	[
	  "replicated_rulesee]
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph osd crush rule dump replicated_ruleset
	{ "rule_id": 0,
	  "rule_name": "replicated_ruleset",
	  "ruleset": 0,
	  "type": 1,
	  "min_size": 1,
	  "maxsize": 10,
	  "steps": [
	        { "op": "take",
	          "item": -1,
	          "item_name": "default"},
	        { "op": "chooseleaf_firstn",
	          "num": 0,
	          "type": "host"},
	        { "op": "emit"}]}
	[root@ceph-node1 ~]#

Если вы управляете большим кластером с несколькими сотнями OSD, иногда бывает трудно найти местоположение определённого OSD в карте CRUSH. Это также трудно сделать, если ваша карта CRUSH содержит множественную иерархию сегментов (bucket). Вы можете воспользоваться ceph osd find для поиска некоего OSD и определении его местоположения в карте CRUSH:

# ceph osd find <Numeric_OSD_ID>

	[root@ceph-node1 ~]# ceph osd find 4
	{ "osd": 4,
	  "ip": "192.168.1.102:6811\/3897",
	  "crush_location": { "host": "ceph-node2",
	      "root": "default}}
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]#

Мониторинг PG

OSD хранят PG, причём каждая PG содержит объекты. Общая жизнеспособность кластера в основном зависит от PG. Кластер будет оставаться в состоянии HEALTH_OK только если все PG находятся в состоянии active + clean. Если ваш кластер Ceph испытывает проблемы с жизнеспособностью, то существует вероятность, что ваши группы размещения не active + clean. Группы размещения могут существовать в различных состояниях, и даже в комбинации состояний. Вот некоторые состояния, в которых могут находиться PG:

Creating: PG создана.

Peering: Процесс приведения в действие всех ваших OSD которые хранят PG в соответствие между состоянием всех объектов включая их метаданные в этой PG {Прим. пер.: одноранговый обмен}.

Active: когда операция однорангового обмена завершится, Ceph отображает все PG как активные. В активном состоянии данные в вашей PG доступны в первичной PG и её реплике для операций вводо/ вывода.

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

Down: Это означает, что реплика со своими необходимыми данными отключена, поэтому PG выключена.

Degraded: Когда OSD переходит в DOWN, Ceph изменяет состояние всех своих PG, которые назначены на этот OSD на DEGRADED. После того как OSD становится UP, оно должно выполнить одноранговый обмен вновь чтобы очистить деграировашие PG. Если OSD остаётся DOWN и OUT более чем 300 секунд, Ceph выполняет восстановление всех своих деградировавших PG из PG их реплик для поддержания необходимого количества реплик. Клиенты могут выполнять ввод/ вывод даже после того как PG находятся в деградировавшем состоянии.

Recovering: Когда OSD переходит в DOWN, содержимое этих PG такого OSD берётся из содержимого PG реплик в других OSD. Когда OSD возвращается в UP, Ceph инициирует операцию восстановления этой PG чтобы поддержать её актуальность с PG реплики и прочих OSD.

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

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

[Замечание]
Замечание

Под действующим набором (acting set) понимается группа OSD отвечающая за PG. Первичный OSD называется первым OSD из действующего набора и он отвечает за ваши операции одорангового обмена для каждой PG с их вторичными/ третичными OSD. Он также принимает операции записи от клиентов. Ваш OSD, будучи включённым UP, остаётся в активном наборе. Как только первичный OSD становится DOWN, вначале он удаляется из набора включённых (UP); ваш вторичный OSD переводится в состояние первичного OSD.

Stale: OSD Ceph выдают сообщение о своей статистике монитору Ceph каждые 0.5 секунд; если их первичные OSD действующего набора OSD возможно отказывают в предоставлении сообщений своей статистики мониторам, или прочие OSD сообщили что первичный OSD перешёл в DOWN, монитор рассматривает эту PG как утратившую силу (stale).

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

Чтобы получить состояние PG, выполните # ceph pg stat:

	[root@ceph-node1 ~]# ceph pg stat
	v20780: 1628 pgs: 1628 active+clean; 2422 MB data, 7440 MB used, 127 GB / 134 GB avail
	[root@ceph-node1 ~]#

Вывод команды pg stat отобразит много информации в специфическом формате: vNNNN: X pgs: Y active+clean; R MB data, U MB used, F GB / T GB avail.

Где переменные определены следующим образом:

vNNNN: Это номер версии карты вашей PG

X: Общее число PG

Y: Число PG, которые имеют состояние active+clean

R: сохранённые сырые данные

U: реально сохранённые после репликаций данные

F: оставшаяся свободная ёмкость

T: Общая ёмкость

Для получения списка PG, выполните следующее:

# ceph pg dump -f json-pretty

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

Чтобы запросить подробную информацию для определённой PG выполните следующую команду, имеющую такой синтаксис ceph pg <PG_ID> query:

# ceph pg 2.7d query

Чтобы выдать перечень застрявших (stuck) PG выполните следующую команду, имеющую такой синтаксис ceph pg dump_stuck < unclean | Inactive | stale > query:

# ceph pg dump_stuck unclean

 Мониторинг MDS Ceph

Серверы метаданных используются исключительно для CephFS, которая пока не готова к промышленному применению на настоящий момент. Сервер метаданных имеет различные состояния, такие как, UP, DOWN, ACTIVE и INACTIVE. При выполнении мониторинга MDS вам следует проверять что состояние MDS UP и ACTIVE. Следующие команды помогут вам получит информацию связанную с MDS Ceph.

  Как это сделать...

Мы сосредоточимся сейчас на командах для наблюдения за OSD. Шаги будут раскрываться в последующих поясняющих темах:

Проверьте перечень файловых систем CephFS:

# ceph fs ls

Проверьте состояние MDS:

# ceph mds stat

Отобразите подробности вашего сервера метаданных:

# ceph mds dump

	[root@ceph-node1 ~]# ceph fs ls
	name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph mds stat
	e73: 1/1/1 up {O=ceph-node2=up:active}
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph mds dump
	dumped mdsmap epoch 73 epoch 73
	flags 0
	created 2015-05-19 00:18:45.398790
	modified        2015-06-06 20:15:21.386153
	tableserver     0
	root    0
	session_timeout 60
	session_autoclose       300
	max_file_size   1099511627776
	last failure    0
	last_failure_osd_epoch  1822
	compat compat={},rocompat=11,incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,8=no anchor table}
	max_mds 1
	in      0
	up      {0=47181}
	failed
	stopped
	data_pools     43
	metadata_pool  44
	inline_data    disabled
	47181: 192.168.1.102:6800/7314 'ceph-node2' mds 0.15 up:active seq 6
	[root@ceph-node1 ~]#

 Введение в Ceph Calamari

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

Frontend: Это основанный на браузере графический интерфейс пользователя, который в основном реализован на JavaScript. Часть внешнего интерфейса (Frontend) применяет Calamari REST API и строится на модульной основе, поэтому каждый компонент внешнего интерфейса может обновляться независимо. Внешний интерфейс Calamari стал открытым исходным кодом с лицензией MIT; вы можете найти его в репозитории https://github.com/ceph/calamari-clients.

Backend: Серверная часть (Backend) Calamari является ядром платформы, которое написано на Python. Она также применяет прочие компоненты, такие как SaltStack, ZeroRPC, graphite, Django-rest-framework, Django, gevent и тому подобные, а также предоставляет новый REST API для интеграции с Ceph и другими системами. Calamari был переделан в своей новой версии, в которой он использует REST API для взаимодействия сосвоим кластером Ceph. Предыдущая редакция Calamari применяла Ceph REST API, который является слегка ограничительным для этих целей. Серверная часть Calamari является открытым исходным кодом с лицензией LGPL2+; вы можете найти её репозиторий по адресу; https://github.com/ceph/calamari.

Calamari имеет хорошую документацию доступную на http://calamari.readthedocs.org; являетесь ли вы оператором или разработчиком, работающим над Calamari или разработчиком, применяющим Calamati REST API, эта документация является хорошим источником информации для начала вашей работы с Calamari. Как и Ceph, Calamari разрабатывается как восходящий продукт; вы можете включиться в Calamari на IRC по адресу irc://irc.oftc.net/ceph, зарегистрироваться в почтовой рассылке на ceph-calamari@ceph.com, или послав запрос на учётную запись Calamari GitHub на https://github.com/ceph/calamari и https://github.com/ceph/calamariclients.

В настоящее время Calamari не предоставляет готовых к установке пакетов, поэтому вам придётся построить их для своей среды. В этом рецепте мы изучим построение пакетов сервера Calamari Ceph из исходных кодов. Построение таких пакетов иногда является серъёзным вызовом, поскольку вы можете не выполнить его одним ударом. Поэтому, чтобы уменьшить сложность, я построил такие пакеты для вас и вы можете их загрузить с https://github.com/ksingh7/cephcalamari-packages, поэтому можете пропустить следующие два рецепта, напрямую перескочив на необходимые условия для установки. Для тех, кому интересно построение пакетов из исходных кодов, давайте приступим. {Прим. пер.: также см. Глава 15. Инструменты разработки в нашем переводе "Как работает Linux" Брайана Варда}.

 Построение пакетов Calamari сервер

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

  Как это сделать...

Клонируйте репозиторий сервера Calamari с применением следующей команды:

$ git clone https://github.com/ceph/calamari.git

Diamond является демоном Python, который собирает метрики системы и публикует их в Graphite. Он способен собирать метрики ЦПУ, оперативной памяти, сетевой среды, ввода/ вывода, нагрузок и дисков. Для дополнительной информации по Diamond обратитесь к http://diamond.readthedocs.org/. В настоящее время Calamari производит своё собственное ответвление Diamond. Для получения Diamond клонируйте следующий репозиторий:

$ cd calamari/vagrant/centos-build

В репоитории calamari вы найдёте каталог vagrant, который предоставляет среду разработки для различных типов операционных систем. Переместитесь в следующий путь для CentOS:

	teeri:git ksinghS git clone https://github.com/ceph/calamari.git
	Cloning into 'calamari'...
	remote: Counting objects: 11265, done.
	remote: Total 11265 (delta 0), reused 0 (delta 0), pack-reused 11265
	Receiving objects: 100% (11265/11265), 20.83 MiB 1 1.62 MiB/s, done.
	Resolving deltas: 100% (6064/6064), done.
	Checking connectivity... done.
	teeri:git ksinghS
	teeri:git ksinghS git clone https://github.com/ceph/Diamond.git --branch.calamari
	Cloning into 'Diamond'...
	remote: Counting objects: 18182, done.
	remote: Total 18182 (delta 0), reused 0 (delta 0), pack-reused 18182
	Receiving objects: 100% (18182/18182), 4.15 MiB 1 2.28 MiB/s, done.
	Resolving deltas: 100% (7151/7151), done.
	Checking connectivity... done.
	teeri:git ksinghS
	teeri:git ksinghS cd calamari/vagrant/centos-build
	teeri:centos-build ksinghS
	teeri:centos-build ksinghS ls -l
	total 8
	-rw-r--r--  1 ksingh  staff  1114 Jun  7 21:05 Vagrantfile
	drwxr-xr-x  4 ksingh  staff   136 Jun  7 21:05 salt
	teeri:centos-build ksinghS

На момент написания этой главы Vagrant не предоставлял скомпонованной настройки для CentOS7. {Прим. пер.: На момент перевода calamari/vagrant/centos7-build присутствует, так что следующие два шага можно пропустить}. Итак, мы модифицируем среду CentOS6 Vagrant, установив config.vm.box как config.vm.box = "boxcutter/centos71".

Поднимем блок Vagrant воспользовавшись следующей командой:

$ vagrant up

	=> default: Running provisioner: salt...
	Copying salt minion config to vm.
	Checking if salt-minion ls installed
	salt-minion was not found.
	Checking if salt-call is installed
	salt-call was not found.
	Bootstrapping Salt... (this, may take a while)

	Salt successfully configured and installed!
	run_overstate set to false. Not running state.oyerstate.
	run_highstate set to false. Not running state.highstate.

На данный момент наша среда разработки CentOS7 готова; мы должны зарегистрироваться на этой машине и выполнить salt-call для начала построения пакетов:

$ vagrant ssh
$ sudo salt-call state.highstate

	[vagrant@local host ~] $
	[vagrant@local host ~] $ sudo salt-call state .highstate
	[INFO ] Loading fresh modules for state activity
	[INFO ] Fetching file from saltenv 'base', ** done ** 'top.sls'

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

	Summary
	------------
	Succeeded: 9 (changed=6)
	Failed:    0
	------------
	Total states run:      9
	[vagrant@local host ~]$

На данный момент у вас имеется окончательно скомпонованные пакеты для сервера Calamari и Diamond. Вы можете найти установочные файлы RPM на один каталог выше вашего клонированного репозитория calamari.

 Построение пакетов Calamari клиент

В этом рецепте мы изучим построение пакетов клиента Calamari. Большинство шагов аналогичны тому, что мы делали в предыдущем разделе, то есть при построении пакета сервера.

  Как это сделать...

Клонируйте репозиторий клиента Calamari:

$ git clone https://github.com/ceph/calamari-clients.git

Измените рабочий каталог на тот, который предоставляет среду Diamond Centos:

$ cd calamari-clients/vagrant/centos-package

Измените среду Vagrantfile и установите config.vm.box следующим образом: config.vm.box = "boxcutter/centos71". {Прим. пер.: На момент перевода calamari/vagrant/centos7-build присутствует, так что это шаг можно пропустить}.

Далее поднимем нашу машину:

$ vagrant up

На данный момент наша среда разработки CentOS7 готова; мы должны зарегистрироваться на этой машине и выполнить salt-call для начала построения пакетов:

$ vagrant ssh
$ sudo salt-call state.highstate

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

	-----------
	           ID: copyout_build_product
	     Function: cmd.run
	       Result: True
	      Comment: Command "cp calamari-clients*tar.gz /git/" run
	      Changes:
	               ----------
	               pid:
	                   25090
	               retcode:
	                   0
	               stderr:
	               stdщге:
	Summary
	-------------
	Succeeded: 13
	Failed:     0
	-------------
	Total:      13
	[vagrant@local host ~]$

На данный момент у вас имеется окончательно скомпонованные пакеты для клиента Calamari и вы можете найти установочные файлы RPM на один каталог выше вашего клонированного репозитория calamari.

 Наладка главного сервера Calamari

В последних рецептах мы скомпилировали необходимые для Calamari пакеты, которые включают в себя calamari-server, calamari-client и diamond. Если вы не компилировали эти пакеты, вы можете загрузить их из моего репозитория GitHub: https://github.com/ksingh7/ceph-calamari-packages/tree/master/CentOS-el7:

  Как это сделать...

В данной демонстрации мы настроим ceph-node1 в качестве главного (master) сервера, а также как узел salt-minion, а ceph-node2 и ceph-node3 только как подчинённые (minion) узлы salt-minion. На момент написания этого рецепта Calamari не поддерживал salt версии 2015, поэтому я умышленно применил версию salt 2014.

Давайте начнём установку сервера Calamari:

На ceph-node1 установите зависимости пакетов требующиеся salt и серверу Calamari:

yum install -y python-crypto PyYAML systemd-python yum-utils m2crypto pciutils python-msgpack systemd-python python-zmq

ceph-node1 сервера Calamari:

$ git clone https://github.com/ceph/calamari-clients.git

По умолчанию, CentOS7 установит самую последнюю версию salt, поэтому, чтобы установить версию salt 2014, настройте salt repo:

# wget https://copr.fedoraproject.org/coprs/saltstack/salt/repo/epel-7/saltstack-salt-epel-7.repo -O /etc/yum.repos.d/saltstacksalt-epel-7.repo

Установите salt master и salt minion версии 2014.7.5:

# yum --disablerepo="*" --enablerepo="salt*" install -y saltmaster-2014.7.5-1.el7.centos

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

# systemctl stop firewalld
# systemctl disable firewalld

Далее установим пакет сервера Calamari. Убедимся что это не обновит версию salt до 2015:

# yum install https://github.com/ksingh7/ceph-calamari-packages/raw/master/CentOS-el7/calamari-server-1.3.0.1-49_g828960a.el7.centos.x86_64.rpm

Далее установим пакет сервера Calamari, который устанавливает компоненты инструментальной панели Calamari:

# yum install -y https://github.com/ksingh7/ceph-calamaripackages/raw/master/CentOS-el7/calamari-clients-1.2.2-32_g931ee58.el7.centos.x86_64.rpm

Сделаем доступной и запустим службу salt-master:

# systemctl enable salt-master
# systemctl restart salt-master

На данный момент сервер Calamari установлен и мы должны настроить его выполнив следующую команду:

# calamari-ctl initialize

	[root@ceph-node1 ~]# calamari-ctl initialize
	[INFO] Loading configuration..
	[INFO] Starting/enabling salt...
	[INFO] Starting/enabling postgres...
	[INFO] Initializing database...
	[INFO] You will now be prompted for login detai1s for the administrative user account.
	This is the account you will use to log into the web interface once setup is complete.
	username (1eave blank to use 'root') : root
	Email address: karan_singhl@live.com
	Password:
	Password (again):
	Superuser created successfully.
	[INFO] Initializing web interface...
	[INFO] Starting/enabling services...
	[INFO] Restarting services...
	[INFO] Complete.
	[root@ceph-node1 ~]#

На момент написания этого раздела Calamari имел известный баг (обновление подключённого подчинённого), который завершался с ошибкой в процессе шага инициализации Calamari. Вы можете пропустить этот шаг если ваша команда инициализации calamari-ctl прошла успешно. Для коррекции этого бага измените файл /opt/calamari/venv/lib/python2.7/site-packages/calamari_cthulhu-0.1-py2.7.egg/cthulhu/calamari_ctl.py update_connected_minions(), закомментировав строку 255, которая выдаёт сообщение сервера Calamari:

	[root@ceph-node1 cthulhu]# cat calamari_ctl.py | grep "update_connectedminions()" | grep -v def # update_connected_minions()
	[root@ceph-node1 cthulhul#

Далее переместитесь в инструментальную панель Calamari набрав в своём браузере http://192.168.1.101/dashboard/ и предоставив имя пользователя root и пароль, который вы установили на последнем шаге.

Рисунок 5.1.

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

Рисунок 5.2.

 Добавление узлов Ceph в Calamari

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

[Замечание]
Замечание

Так как ceph-node1 играет двойную роль и главного сервера Calamari и узла Calamari Ceph, мы уже выполнили первые два шага на узле ceph-node1. Выполняйте первые два шага на узлах ceph-node2 и ceph-node3, пока не будет предписано иного:

  Как это сделать...

На ceph-node2 и ceph-node3 сделайте доступными репозитории salt 2014 yum:

# wget https://copr.fedoraproject.org/coprs/saltstack/salt/repo/epel-7/saltstack-salt-epel-7.repo -O /etc/yum.repos.d/saltstack-salt-epel-7.repo

Установите зависимости пакетов вручную:

# yum install -y python-crypto PyYAML systemd-python yum-utils m2crypto pciutils python-msgpack systemd-python python-zmq

Теперь выполняем эти шаги на ceph-node1, ceph-node2, а также как и на ceph-node3:

Установите пакет salt-minion-2014:

# yum --disablerepo="*" --enablerepo="salt*" install -y saltminion-2014.7.5-1.el7.centos

Установите пакет Diamond:

# yum install -y https://github.com/ksingh7/ceph-calamaripackages/raw/master/CentOS-el7/diamond-3.4.582-0.noarch.rpm

Сделайте доступной и запустите службу Diamond:

# systemctl enable diamond
# systemctl restart diamond

Далее настройте подчинённые salt на применение ceph-node1 в качестве главного узла Calamari:

# echo "master: ceph-node1" > /etc/salt/minion.d/calamari.conf

Сделайте доступной и запустите службу salt-minion:

ctl enable salt-minion
# systemctl restart salt-minion

Теперь salt-minion, т.е. узлы Calamari Ceph настроены для применения главным сервером Calamari. Далее нам необходимо зарегистрироваться на главном сервере Calamari, т.е. на ceph-node1 чтобы перечислить и принять ключи salt от подчинённых.

На ceph-node1 выведем следующим образом список salt-key:

# salt-key -L

Далее примем salt-key подчинённых:

# salt-key -A

Проверим приём ключей подчинённых:

# salt-key -L

	[root@ceph-node1 etc]# salt-key -L
	Accepted Keys:
	ceph-node1
	ceph-node2
	ceph-node3
	Unaccepted Keys:
	Rejected Keys:

Наконец, откроем свой браузер и посетим инструментальную панель Calamari для проверки вашего кластера:

[Предостережение]
Предостережение

Иногда случается, что Calamari не может найти кластер Ceph сразу после приёма ключей подчинённых salt. В этом случае дайте некоторое время Calamari и salt изучить кластер Ceph.

 Мониторинг кластера Ceph в инструментальной панели Calamari

Наблюдение за кластером Ceph из инструментальной панели Calamari достаточно непосредственное. Давайте посмотрим как:

  Как это сделать...

Инструментальная панель отображает массу полезной информации:

Рисунок 5.3. Инструментальная панель

OSD могут наблюдаться с помощью параметра рабочего места OSD:

Рисунок 5.4. Рабочее место OSD

Calamari даёт некоторые прекрасные возможности наблюдения использования ресурсов хоста в форме графиков. Следующий график представляет сводку ЦПУ для ceph-node1:

Рисунок 5.5. Использование ЦПУ ceph-node1

Этот график представляет среднюю загруженность ceph-node1; для лучшего понимания изучите условные обозначения (legend):

Рисунок 5.6. Средняя загруженность ceph-node1

Наконец, далее представлен график использования оперативной памяти на ceph-node2. Вы также можете смотреть на использование памяти во временном представлении выравнивая параметр Time Axis в правой стороне панели:

Рисунок 5.7. Использование оперативной памяти ceph-node2

 Обнаружение ошибок Calamari

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

  Как это сделать...

Проверьте, доступны ли для сервера Calamari, т.е. salt-master, его подчинённые, т.е salt-minor:

'*' test.ping

Убедитесь что salt-master может опрашbвать ваш кластер Ceph и получать от кластера информацию:

# salt '*' ceph.get_heartbeats output

Проверьте, что salt-minor узел (узел кластера Ceph) может связаться с salt-minor:

# salt-minion -l debug

Если salt-minor выдаёт ошибку The Salt Master server's public key did not authenticate! в файл журнала salt-minor, т.е. /var/log/salt:

	2015-06-26 09:57:27,531 [salt.crypt][CRITICAL] The Salt Master server's public key did not authenticate!
	The master may need to be updated if it is a version of Salt lower than 2014.7.5, or
	If you are confident that you are connecting to a valid Salt Master, then remove the
	master public key and restart the Salt Minion.
	The master public key can be found at:
	/etc/salt/pki/minion/minion_master.pub

Чтобы решить эту проблему, нам нужно удалить salt-key minion а также общедоступный ключ главного сервера и посторно созать их оба с применением следующих команд:

# rm -rf /etc/salt/pki/minion/minion_master.pub
# systemctl stop salt-minion

Теперь выполним следующий набор шагов:

На salt-master удалим ключ подчинённого:

# salt-key -L
# slat-key -D <minion name>

Запустим службу salt-minion:

# systemctl start salt-minion

На salt-master примем новый ключ подчинённого:

# salt-key -L
# salt-key -A

Наконец, на salt-minion применим # salt-minion -l и убедимся, что не получаем ошибку вновь.

Выполнение команды calamari-ctl initialize распространяет ошибку could not connect to server: Connection refused следующим образом:

	[root@ceph—node1]# calamari—ctl initialize
	[INFO] Loading configuration..
	[INFO] Starting/enabling salt...
	[INFO] Starting/enabling postgres...
	[ERROR] (OperationalError) could not connect to server: Connection refused
	  Is the server running on host "localhost" (::1) and accepting
	  TCP/IP connections on port 5432?
	сould not connect to server: Connection refused
	  Is the server running on host "localhost" (127.0.0.1) and accepting
	  TCP/IP connections on port 5432?
	 None None
	[ERROR] We are sorry, an unexpected error occurred. Debugging information has
	been written to a file at '/tmp/2015-06-24_1919.txti', please include this when seeking technical support.
	[root@ceph—node1]#

Тогда выполним приводимый ниже набор шагов:

Вначале проверим, что служба postgres выполняется:

# systemctl status postgres

Зарегистрируемся на postgres и проверим существует ли база данных Calamari или нет:

# sudo -u postgres psql
List postgres databases # \l

	[root@ceph-node1]# sudo -u postgres psql
	psql (9.2.10)
	Type "help" for help.
	postgres=#
	postgres=# \l
	                                  List of databases
	   Name    |  Owner   | Encoding |   Collate   |     Ctype   |   Access privileges
	-----------+----------+----------+-------------+-------------+-----------------------
	postgres   | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
	template@  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
	           |          |          |             |             | postgres=CTc/postgres
	templatel  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
	           |          |          |             |             | postgres=CTc/postgres
	(3 rows)
	postgres=#

Вы можете увидеть что не существует базы данных с именем calamari; тогда вам необходимо выполнить salt для создания пользователя и базы данных calamari в postgres:

# salt-call --local state.template /opt/calamari/salt-local/postgres.sls

Наконец, повторно выполним # calamari-ctl initialize; теперь это должно работать.

Командная строка calamari-ctl initialize не отрабатывается и распространяет ошибку Updating already connected nodes. failed with rc=2 как показано ниже на снимке экрана:

	[root@ceph-node1 ~]# calamari-ctl initialize
	[INFO] Loading configuration..
	[INFO] Starting/enabling salt...
	[INFO] Starting/enabling postgres...
	[INFO] Initializing database...
	[INFO] You will now be prompted for login details for the administrative user account.
	This is the account you will use to log into the web interface once setup is complete.
	Username (leave blank to use 'root'):
	Email address: karan_singhl@live.com
	Password:
	Password (again):
	Superuser created successfully.
	[INFO] Initializing web interface...
	[INFO] Starting/enabling services...
	[INFO] Updating already connected nodes.
	[ERROR] Updating already connected nodes. failed with rc=2
	[ERROR] We are sorry, an unexpected error occurred. Debugging information has
	been written to a file at 'tmp/2015-06-22_1855.txt', please include this when seeking technical support.

Чтобы исправить эту ошибку, измените файл /opt/calamari/venv/lib/python2.7/sitepackages/calamari_cthulhu-0.1-py2.7.egg/cthulhu/calamari_ctl.py и уберите комментарий в строке 255, который выводит ceph-node3 сделайте доступными репозитории salt 2014 update_connected_minions():

	[root@ceph-node1 cthulhu]# cat calamari_ctl.py | grep "update_connected_minions()" | grep -v def
	   # update_connected_minions()
	[root@ceph-node1 cthulhul#

Глава 6. Работа в кластере Ceph и управление им

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

Понимание управления службами Ceph

Координация файла настроек кластера

Выполнение Ceph с применением SYSVINIT

Выполнение Ceph как службы

Сопоставление расширения и увеличения в масштабе

Увеличение в масштабе вашего кластера Ceph

Уменьшение в масштабе вашего кластера Ceph

Замена отказавшего диска в вашем кластере Ceph

Обновление вашего кластера Ceph

Сопровождение вашего кластера Ceph

Содержание

6. Работа в кластере Ceph и управление им

Введение

Понимание управления службами Ceph

Координация файла настроек кластера

Выполнение Ceph с применением SYSVINIT

Выполнение Ceph как службы

Сопоставление расширения и увеличения в масштабе

Увеличение в масштабе вашего кластера Ceph

Уменьшение в масштабе вашего кластера Ceph

Замена отказавшего диска в вашем кластере Ceph

Обновление вашего кластера Ceph

Сопровождение вашего кластера Ceph

 Введение

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

 Понимание управления службами Ceph

Все компоненты Ceph, будь то MON, OSD, MDS или RGW выступают в роли служб поверх лежащей в основе операционной системы. Как администратору хранения Ceph, вам необходимо знать о ваших службах Ceph и том, как их обрабатывать. В дистрибутивах на основе Red Hat, демоны Ceph могут управляться различными способами: как традиционным SYSVINIT, так и в качестве службы. {Прим. пер.: подробнее см. Глава 6. Как запускается пользовательское пространство в нашем переводе книги Брайана Варда "Как работает Linux".} Всякий раз, когда вы start, restart и stop демоны Ceph (или весь кластер целиком), вы обязаны предписывать по крайней мере один параметр и одну команду. Вы можете также определить тип демона или экземпляра демона. Общий синтаксис для этого следующий:

{ceph service command} [options] [command] [daemons]

Параметры Ceph включают в себя:

--verbos или -v: Применяется для регистрации с подробностями

--valgrind: (Используется исключительно для Dev и QA.) Применяется для отладки valgrind

--allhosts или -a: Действие выполняется на всех узлах, которые приведены в ceph.conf, вслучае их отсутствия на localhost.

--conf или -c: Применяется, причём в качестве замены, как файл настроек.

--restart: Автоматически перезапускать, в случае падения его ядра.

--norestart: Эта команда сообщает об отсутствии необходимости перезапуска в случае падения его ядра.

Команды Ceph включают в свой состав:

status: Отобразить состояние демона

start: Запустить демон

stop: Остановить демон.

restart: Остановить и после этого запустить демон.

forcestop: Принудительно остановить демон; аналогично kill-9.

killall: Уничтожить все демоны определённого типа.

cleanlogs: Очистить ваш каталог журналов.

cleanalllogs: Очистить всё в вашем каталог журналов.

Демоны Ceph состоят из:

mon

osd

msd

 Координация файла настроек кластера

Кода вы управляете большим кластером, будет хорошей практикой сохранять в вашем файле настроек кластера (/etc/ceph/ceph.conf) все изменения информации об узлах мониторов кластера, OSD, MDS и RGW. При наличии таких записей на своём месте вы сможете управлять всеми вашими службами кластера с одного узла.

  Как это сделать...

Чтобы лучше понять сказанное, мы обновим файл настроек Ceph на ceph-node1 и добавим подробности обо всех узлах мониторов, OSD и MDS.

Добавление узлов монитора в ваш файл настроек Ceph

Поскольку у нас есть три узла монитора, добавим подробности о них в ваш файл /etc/ceph/ceph.conf на ceph-node1.

	[mon]
		mon data = /var/lib/ceph/mon/Scluster-$id
	[mon.ceph-node1]
		host = ceph-node1
		mon addr = ceph-node1:6789
	[mon.ceph-node2]
		host = ceph-node2
		mon addr = ceph-node2:6789
	[mon.ceph-node3]
		host = ceph-node3
		mon addr = ceph-node3:6789

Добавление узлов MDS в ваш файл настроек Ceph

Как и в случае для монитора добавим узел MDS в ваш файл /etc/ceph/ceph.conf на ceph-node1.

	[mds]

	[mon.ceph-node2]
		host = ceph-node2

Добавление узлов монитора в ваш файл настроек Ceph

Теперь давайте добавим подробности об узлах OSD в ваш файл /etc/ceph/ceph.conf на ceph-node1.

	[osd]
		osd data = /var/lib/ceph/osd/Scluster-$id
		osd juurnal = /var/lib/ceph/osd/Scluster-$id/journal
	[osd.0]
		host = ceph-node1
	[osd.1]
		host = ceph-node1
	[osd.2]
		host = ceph-node1
	[osd.3]
		host = ceph-node2
	[osd.4]
		host = ceph-node2
	[osd.5]
		host = ceph-node2
	[osd.6]
		host = ceph-node3
	[osd.7]
		host = ceph-node3
	[osd.8]
		host = ceph-node3

 Выполнение Ceph с применением SYSVINIT

SYSVINIT всё ещё является традиционно рекомендуемым методом управления демонами Ceph в системах на основе Red Hat, а также для некоторых более старых дистрибутивов на основе Debian/ Ubuntu. {Прим. пер.: подробнее проблемы запуска служб см. в Глава 6. Как запускается пользовательское пространство в нашем переводе книги Брайана Варда "Как работает Linux".} Общий синтаксис дл управления демонами Ceph с использованием SYSVINIT такой: /etc/init.d/ceph [options] [command] [daemons].

  Запуск и останов всех демонов

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

  Как это сделать...

Давайте рассмотрим как запустить и остановить все демоны Ceph:

Для запуска вашего кластера Ceph выполните команду start. Эта команда запустит все службы которые вы развернули для всех хостов приведённых в вашем файле ceph.conf.

# /etc/init.d/ceph -a start

Для останова вашего кластера Ceph выполните команду stop. Эта команда остановит все службы Ceph развёрнутые вами на всех хостах приведённых в вашем файле ceph.conf. Параметр -a служит для выполнения на всех узлах:

# /etc/init.d/ceph -a stop

[Предостережение]
Предостережение

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

  Запуск и останов всех демонов определённого типа

Чтобы запустить и остановить все демоны Ceph по их типу выполните следующий набор команд.

  Как это сделать...

Давайте рассмотрим как запустить и остановить все демоны Ceph определённого типа:

Запуск демонов определённого типа

Для запуска демонов монитора на локальном хосте выполните Ceph с командой start и последующим типом демона:

# /etc/init.d/ceph start mon

Для запуска демонов монитора на всех ваших хостах выполните ту же команду с параметром -a:

# /etc/init.d/ceph -a start mon

Аналогично вы можете запускать демоны других типов, то есть osd, mds и ceph-radosgw:

# /etc/init.d/ceph -a start osd
# /etc/init.d/ceph start mds
# /etc/init.d/ceph start ceph-radosgw

Останов демонов определённого типа

Чтобы остановить демоны монитора на локальном хосте выполните Ceph с командой stop и последующим типом демона:

# /etc/init.d/ceph stop mon

Для останова демонов монитора на всех ваших хостах выполните ту же команду с параметром -a:

# /etc/init.d/ceph -a stop mon

Аналогично вы можете останавливать демоны других типов, то есть osd, mds и ceph-radosgw:

# /etc/init.d/ceph -a stop osd
# /etc/init.d/ceph stop mds
# /etc/init.d/ceph stop ceph-radosgw

  Запуск и останов определённого демона

Чтобы запустить и остановить определённый демон Ceph выполните следующий набор команд.

  Как это сделать...

Давайте рассмотрим как запускать и останавливать определённые демоны.

Запуск определённого демона

Для запуска определённого демона на локальном хосте выполните Ceph с командой start и последующим {тип_демона}.{экземпляр}, например:

Для запуска демона mon.0:

# /etc/init.d/ceph start mon.ceph-node1

Аналогично вы можете запускать прочие демоны и их экземпляры:

# /etc/init.d/ceph start osd.1
# /etc/init.d/ceph -a start mon.ceph-node2
# /etc/init.d/ceph start ceph-radosgw.gateway1

Останов определённого демона

Для останова определённого демона на локальном хосте выполните Ceph с командой stop и последующим {тип_демона}.{экземпляр}, например:

Для запуска демона mon.0:

# /etc/init.d/ceph stop mon.ceph-node1

Аналогично вы можете запускать прочие демоны и их экземпляры:

# /etc/init.d/ceph stop osd.1
# /etc/init.d/ceph -a stop mon.ceph-node2
# /etc/init.d/ceph stop ceph-radosgw.gateway1

 Выполнение Ceph как службы

В предыдущем рецепте мы изучили управление службой Ceph с применением SYSVINIT; в данном рецепте мы получим понимание об управлении Ceph в качестве служб, то есть при помощи команды Linux service. Начиная с выпуска Ceph Argonaut мы можем управлять демонами Ceph при помощи команды Linux service, имеющей следующий синтаксис:

ervice ceph [options] [command] [daemons]

  Запуск и останов всех демонов

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

  Как это сделать...

Давайте рассмотрим как запустить и остановить все демоны Ceph:

Для запуска вашего кластера Ceph выполните команду start. Эта команда запустит все службы которые вы развернули для всех хостов приведённых в вашем файле ceph.conf. Раз вы запускаете Ceph с параметром -a, Ceph должен начать работать:

# service ceph -a start

Для останова вашего кластера Ceph выполните команду stop. Эта команда остановит все службы Ceph развёрнутые вами на всех хостах приведённых в вашем файле ceph.conf. Раз вы останавливаете Ceph с параметром -a, Ceph должен выключиться:

# service ceph -a stop

  Запуск и останов всех демонов определённого типа

Чтобы запустить и остановить все демоны Ceph по их типу выполните следующий набор команд.

  Как это сделать...

Давайте рассмотрим как запустить и остановить все демоны определённого типа:

Запуск демонов определённого типа

Для запуска демонов монитора на локальном хосте выполните службу Ceph с командой start и последующим типом демона:

# service ceph start mon

Для запуска демонов монитора на всех ваших хостах выполните ту же команду с параметром -a:

# service ceph -a start mon

Аналогично вы можете запускать демоны других типов, то есть osd, mds и ceph-radosgw:

# service ceph start osd
# service ceph start mds
# service ceph start ceph-radosgw

Останов демонов определённого

Для останова демонов монитора на локальном хосте выполните service ceph с командой stop и последующим типом демона:

# service ceph stop mon

Для останова демонов монитора на всех ваших хостах выполните ту же команду с параметром -a:

# service ceph -a stop mon

Аналогично вы можете останавливать демоны других типов, то есть osd, mds и ceph-radosgw:

# service ceph stop -a osd
# service ceph stop mds
# service ceph stop ceph-radosgw

  Запуск и останов определённого демона

Чтобы запустить и остановить определённый демон Ceph выполните следующий набор команд.

  Как это сделать...

Давайте рассмотрим как запускать и останавливать определённые демоны.

Запуск определённого демона

Для запуска определённого демона на локальном хосте выполните службу Ceph с командой start и последующим {тип_демона}.{экземпляр}, например:

Для запуска демона mon.0:

# service ceph start mon.ceph-node1

Аналогично вы можете запускать прочие демоны и их экземпляры:

# service ceph start osd.1
# service ceph -a start mds.ceph-node2
# service ceph start ceph-radosgw.gateway1

Останов определённого демона

Для останова определённого демона на локальном хосте выполните службу Ceph с командой stop и последующим {тип_демона}.{экземпляр}, например:

Для запуска демона mon.0:

# service ceph start mon.ceph-node1

Аналогично вы можете запускать прочие демоны и их экземпляры:

# service ceph stop osd.1
# service ceph -a stop mds.ceph-node2
# service ceph stop ceph-radosgw.gateway1

 Сопоставление расширения и увеличения в масштабе

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

Традиционные системы хранения базировались на архитектуре расширения (scale-up) и были ограничены ёмкостью хранения. Если вы расширяете эти системы хранения сверх некоего предела, вам могут потребоваться компромиссы между производительностью, надёжностью и доступностью. Методология расширения для хранилища включает добавление дисковых ресурсов в существующие системы контроллеров, которые становятся узким местом для производительности, ёмкости и управляемости по достижению определённого уровня.

С другой стороны, архитектура увеличения в масштабе (scale-out) сосредотачивается на добавлении целиком нового устройства, содержащего диски, ЦПУ, оперативную память и прочие ресурсы в ваш существующий кластер хранения. При таком типе архитектуры вы не столкнётесь с вызовами, которые мы наблюдаем при архитектуре расширения; более того,в качестве преимущества мы получаем линейное улучшение производительности. Следующая схема поясняет архитектуру систем хранения с расширением и увеличением в масштабе:

Рисунок 6.1. Архитектура систем хранения с расширением и увеличением в масштабе

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

 Увеличение в масштабе вашего кластера Ceph

С самых своих корней Ceph разрабатывался для роста от нескольких узлов до нескольких сотен и при этом предполагалось его масштабирование на лету без какого быто ни было времени простоя. В этом рецепте мы погрузимся глубже в функциональность Ceph увеличения в масштабе путём добавления узлов MON, OSD,MDS и RGW.

  Добавление OSD Ceph

Добавление узла OSD в кластер Ceph является процессом реального времени. Для его демонстрации нам потребуется новая виртуальная машина с именем ceph-node4, имеющую три диска,которые будут работать как OSD. Этот новый узел затем будет добавлен в ваш существующий кластер Ceph.

  Как это сделать...

Выполняйте следующие команды на узле ceph-node1, если не предписано иное:

Создайте новый узел, ceph-node4, с тремя дисками (OSD). Вы можете последовать процессу создания новой виртуальной машины с дисками и настройки ОС, приведённом в рецепте Настройка виртуальной инфраструктуры в Главе 1. Введение и за его пределами, и убедитесь, что ceph-node1 имеет SSH доступ к ceph-node4.

Перед добавлением нового узла в кластер Ceph давайте проверим текущее дерево OSD. Как показано на следующем снимке экрана, кластер имеет три узла с общим числом OSD в количестве девяти:

# ceph osd tree

	[root@ceph-node1 ~]# ceph osd tree
	# id    weight  type name        up/down reweight
	-1      0.08998 root default
	-3      0.03            host ceph-node2
	3       0.009995                         osd.3    up       1
	4       0.009995                         osd.4    up       1
	5       0.009995                         osd.5    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
	-2      0.02998         host ceph-node1
	0       0.009995                         osd.0    up       1
	1       0.009995                         osd.1    up       1
	2       0.009995                         osd.2    up       1
	[root@ceph-node1 ~]#

Убедитесь, что новые узлы имеют установленные пакеты Ceph. Рекомендуемой практикой является сохранение на всех узлах кластера одной и той же версии Ceph. С узла ceph-node1 установите пакеты Ceph на ceph-node4:

# ceph-deploy install ceph-node4 --release giant

[Замечание]
Замечание

Мы намеренно устанавливаем редакцию Ceph Giant здесь чтобы можно было изучить как обновлять кластер Ceph с Giant на Hammer позже в этой же главе.

Выведите перечень дисков для ceph-node4:

# ceph-deploy disk list ceph-node4

Давайте добавим диски с ceph-node4 в имеющийся у нас кластер Ceph:

# ceph-deploy disk zap ceph-node4:sdb ceph-node4:sdc cephnode4:sdd
# ceph-deploy osd create ceph-node4:sdb ceph-node4:sdc cephnode4:sdd

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

 watch ceph -s

Наконец, когда добавление дисков ceph-node4 завершено, вы отметите новую ёмкость хранения вашего кластера:

# rados df

Проверьте своё дерево OSD; это даст вам лучшее понимание вашего кластера. Вы должны заметить свои новые OSD на ceph-node4, которые только что были добавлены:

# ceph osd tree

	[root@ceph-node1 ~]# ceph osd tree
	# id    weight  type name        up/down reweight
	-1      0.12    root default
	-3      0.03            host ceph-node2
	3       0.009995                         osd.3    up       1
	4       0.009995                         osd.4    up       1
	5       0.009995                         osd.5    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
	-2      0.02998         host ceph-node1
	0       0.009995                         osd.0    up       1
	1       0.009995                         osd.1    up       1
	2       0.009995                         osd.2    up       1
	-5      0.02998         host ceph-node4
	0       0.009995                         osd.9    up       1
	1       0.009995                         osd.10   up       1
	2       0.009995                         osd.11   up       1
	[root@ceph-node1 ~]#

Эта команда выводит некоторую полезную информацию, такую как вес OSD, какой узел Ceph размещает какие OSD, состояние UP/DOWN OSD, а также состояние IN/OUT ваших OSD, представляемое 1 или 0.

Прямо сейчас мы изучили как добавлять новый узел в существующий кластер Ceph. Теперь пришло хорошее время для понимания того, что поскольку число OSD возрастает, выбор правильного значения для групп размещения (PG) становится более важным, поскольку оно имеет значительное влияние на поведение вашего кластера. Увеличение числа PG на большом кластере может быть затратной операцией. Я рекомендую вам взглянуть на http://docs.ceph.com/docs/master/rados/operations/placement-groups/#choosing-the-number-of-placement-groups для получения некоей новой информации по PG (Placement Groups).

  Добавление MON Ceph

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

Поскольку мы имеем тестовый кластер Ceph, мы добавим ceph-node4 в качестве четвёртого узла монитора, однако в промышленной сборке вам всегда следует иметь нечётное число узлов монитора в вашем кластере Ceph; это улучшает устойчивость к сбоям.

  Как это сделать...

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

# ceph-deploy mon create ceph-node4

Когда ceph-node4 настроен в качестве узла монитора, проверьте состояние вашего Ceph для просмотра состояния кластера. Заметьте, пожалуйста, что ceph-node4 является вашим новым узлом монитора:

	[root@ceph-node1 ceph]# ceph -s
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
	    health HEALTH_OK
	    monmap e6: 4 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0,ceph-node4=192.168.1.104:6789/0}, election epoch 958, quoru m 0,1,2,3 ceph-node1,ceph-node2,ceph-node3,ceph-node4
	    mdsmap e217: 1/1/1 up {0=ceph-node2=up:active}
	    osdmap e3951: 12 osds: 12 up, 12 in
	     pgmap v32414: 1628 pgs, 45 pools, 2422 MB data, 3742 objects
	           7920 MB used, 172 GB / 179 GB avail
	              1628 active+clean
	[root@ceph-node1 ceph]#

Проверьте состояние монитора Ceph и отметьте ceph-node4 в качестве нового узла монитора.

	[root@ceph-node1 ceph]# ceph mon stat
	e6: 4 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0,ceph-node4 =192.168.1.104:6789/0}, election epoch 958, quorum 0,1,2,3 ceph-node1,ceph-node2,ceph-node3,ceph-node4
	[root@ceph-node1 ceph]#

  Добавление вашего RGW Ceph

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

Рисунок 6.2. Множество экземпляров RGW Ceph.

Масштабирование RGW аналогично добавлению дополнительных узлов RGW; для справки обращайтесь, пожалуйста, к рецепту Стандартные наладка, установка и настройка шлюза RADOS в Главе 3. Работа с хранилищем объектов Ceph для добавления дополнительных узлов RGW в вашу среду Ceph.

 Уменьшение в масштабе вашего кластера Ceph

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

Ceph является абсолютно гибкой системой которая поддерживает изменения на лету в ёмкости хранения, причём безотносительно в сторону расширения или уменьшения. В последнем рецепте мы изучили как легко увеличивать в масштабе (scale-out) кластер Ceph. В данном рецепте мы уменьшим в масштабе кластер Ceph без какого бы то ни было воздействия на его доступность, просто удалив ceph-node4 из вашего кластера Ceph.

  Удаление OSD Ceph

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

  Как это сделать...

Выполняйте следующие команды на узле ceph-node1, если не предписано иное:

Поскольку нам нужно уменьшить масштаб нашего кластера, мы удалим ceph-node4 и все связанные с ним OSD из нашего кластера. OSD Ceph должны быть установлены на удаление чтобы Ceph смог выполнить восстановление данных. На любом из узлов Ceph выведите OSD из вашего кластера:

# ceph osd out osd.9
# ceph osd out osd.10
# ceph osd out osd.11

	[root@ceph-node1 ~]# ceph osd out osd.9
	marked out osd.9.
	[root@ceph-node1 ~]# ceph osd out osd.10
	marked out osd.10.
	[root@ceph-node1 ~]# ceph osd out osd.11
	marked out osd.11.
	[root@ceph-node1 ~]#

Как только вы пометите OSD на вывод из кластера, Ceph начнёт ребалансировку вашего кластера путём миграции своих групп размещения (PG) с этого OSD, который выводится из кластера, на другие OSD внутри вашего кластера. Состояние вашего кластера на какое- то время станет опасным (unhealthy), но он будет по прежнему в состоянии обслуживать данные клиентов. В зависимости от числа удаляемых OSD может существовать провал в производительности кластера до полного завершения восстановления. Как только кластер снова станет жизнеспособным (healthy), онбуде работать как прежде.

# ceph -s

	[root@ceph-node1 ~]# ceph -s
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
	    health HEALTH_WARN 65 pgs degraded; 8 pgs recovering; 22 pgs stuck unclean; recovery 1594/11226 objects degraded (14.199%)
	    monmap e6: 4 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2-192.168.1.102:6789/0,ceph-node3-192.168.1.103:6789/0,ceph-node4-192.168.1.104:6789/0}, election epoch 978, quorum 0,1,2,3 ceph-node1,ceph-node2,ceph-node3,ceph-node4
	    mdsmap e222: 1/1/1 up {0=ceph-node2=up:active}
	    osdmap e4081: 12 osds: 12 up, 9 in
	     pgmap v32727: 1628 pgs, 45 pools, 2422 MB data, 3742 objects
	           8065 MB used, 127 GB / 134 GB avail
	           1594/11226 objects degraded (14.199%)
	               1563 active+clean
	                 57 active+degraded
	                  8 active+recovering+degraded
	recovery io 27934 kB/s, 2 keys/s, 35 objects/s
	  client io 297 kB/s wr, 0 op/s
	[root@ceph-node1 ~]#

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

# ceph -w

	[root@ceph-node1 ~]# ceph -w
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
	     health HEALTH_OK
	     monmap e6: 4 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0,ceph-node4=192.168.1.104:6789/0}, election epoch 978, quorum 0,1,2,3 ceph-node1,ceph-node2,ceph-node3,ceph-node4
	     mdsmap e222: 1/1/1 up {0=ceph-node2=up:active}
	     osdmap e4081: 12 osds: 12 up, 9 in
	      pgmap v32734: 1628 pgs, 45 pools, 2422 MB data, 3742 objects
	            8514 MB used, 126 GB / 134 GB avail
	                1628 active+clean

	2015-07-26 23:01:05.012972 mon.0 [INF] pgmap v32734: 1628 pgs: 1628 active+clean; 2422 MB data, 8514 MB used, 126 GB / 134 GB avail; 38045 kB/s, 35 objects/s recovering
	2015-07-26 23:01:54.896226 mon.0 [INF] pgmap v32735: 1628 pgs: 1628 active+clean; 2422 MB d ata, 8514 MB used, 126 GB / 134 GB avail

Поскольку мы пометили osd.9, osd.10 и osd.11 на выведение из нашего кластера, они не принимают участия в сохранении данных, однако их службы всё ещё работают {Прим. пер.: и могут обслуживать чтение!}. Давайте остановим эти OSD:

# ssh ceph-node4 service ceph stop osd

	[root@ceph-node1 ~]# ssh ceph-node4 service ceph stop osd
	=== osd.11 ===
	Stopping Ceph osd.11 on ceph-node4...kill 4721...kill 4721...done
	=== osd.10 ===
	Stopping Ceph osd.10 on ceph-node4...kill 2341...kill 2341...done
	=== osd.9 ===
	Stopping Ceph osd.9 on ceph-node4...kill 4319...kill 4319...done
	[root@ceph-node1 ~]#

Когда OSD отключатся, проверьте ваше дерево OSD; вы будете наблюдать, что OSD выключены DOWN и выведены (OUT):

# Ceph osd tree

	[root@ceph-node1 ~]# ceph osd tree
	# id    weight  type name       up/down  reweight
	-1      0.12    root default
	-3      0.03            host ceph-node2
	3       0.009995                         osd.3   up     1
	4       0.009995                         osd.4   up     1
	5       0.009995                         osd.5   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
	-2      0.02998         host ceph-node1
	0       0.009995                         osd.0   up     1
	1       0.009995                         osd.1   up     1
	2       0.009995                         osd.2   up     1
	-5 0.02998              host ceph-node4
	9       0.009995                         osd.9   down   0
	10      0.009995                         osd.10  down   0
	11      0.009995                         osd.11  down   0
	[root@ceph-node1 ~]#

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

# ceph osd crush remove osd.9
# ceph osd crush remove osd.10
# ceph osd crush remove osd.11

	[root@ceph-node1 ~]# ceph osd crush remove osd.9
	removed item id 9 name 'osd.9' from crush map
	[root@ceph-node1 ~]# ceph osd crush remove osd.10
	removed item id 10 name 'osd.10' from crush map
	[root@ceph-node1 ~]# ceph osd crush remove osd.11
	removed item id 11 name 'osd.11' from crush map
	[root@ceph-node1 ~]#

Как только эти OSD удалены из вашей карты CRUSH, кластер CEPH становится жизнеспособным (health). Вам следует также просмотреть карту ваших OSD; так как мы не удалили эти OSD, мы вё ещё видим 12 OSD, причём 9 UP и 9 IN.

Удалим ключи аутентификации этих OSD:

# ceph auth del osd.9
# ceph auth del osd.10
# ceph auth del osd.11

	[root@ceph-node1 ~]# ceph auth del osd.9
	updated
	[root@ceph-node1 ~]# ceph auth del osd.10
	updated
	[root@ceph-node1 ~]# ceph auth del osd.11
	updated [root@ceph-node1 ~]#

Наконец, удалим эти OSD и проверим состояние вашего кластера; вы должны наблюдать 9 OSD, причём 9 UP и 9 IN, а жизнесопсобность (helth) кластера должна быть OK.

# ceph osd rm osd.9
# ceph osd rm osd.10
# ceph osd rm osd.11

	[root@ceph-node1 ~]# ceph osd rm osd.9
	removed osd.9
	[root@ceph-node1 ~]# ceph osd rm osd.10
	removed osd.10
	[root@ceph-node1 ~]# ceph osd rm osd.11
	removed osd.11
	[root@ceph-node1 ~]#

Чтобы оставить ваш кластер очищнным, выполните некую работу по домоводству; поскольку мы удалили все эти OSD из нашей карты CRUSH, ceph-node4 больше не содержит никаких элементов. Удалите ceph-node4 из карты CRUSH; это удалит все следы данного узла из кластера Ceph: :

# ceph osd crush remove ceph-node4
# ceph -s

	[root@ceph-node1 ~]# ceph -s
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
	    health HEALTH_OK
	    monmap e6: 4 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0,ceph-node4=192.168.1.104:6789/01, election epoch 980, quorum 0,1,2,3 ceph-node1,ceph-node2,ceph-node3,ceph-node4
	    mdsmap e222: 1/1/1 up {0=ceph-node2=up:active}
	    osdmap e4095: 9 osds: 9 up, 9 in
	     pgmap v32801: 1628 pgs, 45 pools, 2422 MB data, 3742 objects
	           8185 MB used, 126 GB / 134 GB avail
	               1628 active+clean
	[root@ceph-node1 ~]#

  Удаление MON Ceph

Удаление монитора Ceph обычно не часто востребованная задача. Когда вы удаляете мониторы из некого кластера, имейте в виду, что мониторы Ceph используют алгоритм PAXOS для установления консенсуса о вашей главной карте кластера. Вы должны иметь достаточное число мониторов для установления некоего кворума для согласия по ваше карте кластера. В данном рецепте мы изучим как удалить монитор ceph-node4 из вашего кластера Ceph.

  Как это сделать...

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

# ceph mon stat

	[root@ceph-node1 ~]# ceph mon stat
	e6: 4 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0,ceph-node4=192.168.1.104:6789/0}, election epoch 996, quorum 0,1,2,3 ceph-node1,ceph-node2,ceph-node3,ceph-node4
	[root@ceph-node1 ~]#

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

# ceph-deploy mon destroy ceph-node4

	[root@ceph-node1 ceph]# ceph-deploy mon destroy ceph-node4
	[ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf
	[ceph_deploy.cli][INFO ] Invoked (1.5.25): /bin/ceph-deploy mon destroy ceph-node4
	[ceph_deploy.mon][DEBUG ] Removing mon from ceph-node4
	[ceph-node4][DEBUG ] connected to host: ceph-node4
	[ceph-node4][DEBUG ] detect platform information from remote host
	[ceph-node4][DEBUG ] detect machine type
	[ceph-node4][DEBUG ] get remote short hostname
	[ceph-node4][INFO ] Running command: ceph --cluster=ceph -n mon. -k /var/lib/ceph/mon/ceph-ceph-node4/keyring mon remove ceph-node4
	[ceph-node4][WARNIN] removed mon.ceph-node4 at 192.168.1.104:6789/0, there are now 3 monitors
	[ceph-node4][INFO ] polling the daemon to verify it stopped
	[ceph-node4][INFO ] Running command: service ceph status mon.ceph-node4
	[ceph-node4][INFO ] Running command: mkdir -p /var/lib/ceph/mon-removed
	[ceph-node4][DEBUG ] move old monitor data
	[root@ceph-node1 ceph]#

Выполните проверку чтобы увидеть что ваши мониторы покинули кворум:

# ceph quorum_status --format json-pretty

	[root@ceph-node1 ceph]# ceph quorum_status --format json-pretty

	{ "election_epoch": 998,
	  "quorum": [
	        0,
	        1,
	        2],
	  "quorum_names": [
	        "ceph-node1",
	        "ceph-node2",
	        "ceph-node3"],
	  "quorum_leader_name": "ceph-node1",
	  "monmap": -{ "epoch": 7,
	      "fsid": "9609b429-eee2-4e23-af31-28a24fcf5cbc",
	      "modified": "2015-07-27 21:22:38.523853",
	      "created": "0.000000",
	      "mons": [
	            { "rank": 0,
	              "name": "ceph-node1",
	              "addr": "192.168.1.101:6789\/0"},
	            { "rank": 1,
	              "name": "ceph-node2",
	              "addr": "192.168.1.102:6789\/0"},
	            { "rank": 2,
	              "name": "ceph-node3",
	              "addr": "192.168.1.103:6789\/0"}]}}
	[root@ceph-node1 ceph]#

Наконец, проверьте состояние мониторов; ваш кластер должен иметь три монитора:

# ceph mon stat

	[root@ceph-node1 ceph]# ceph mon stat
	e7: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0}, election epoch 998, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
	[root@ceph-node1 ceph]#

 Замена отказавшего диска в вашем кластере Ceph

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

  Как это сделать...

Давайте проверим жизнеспособность(health) кластера; так как этот кластер не имеет никаких состояний отказавших дисков, оно будет HEALTH_OK:

# ceph status

	[root@ceph-node1 ceph]# ceph -s
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
	     health HEALTH_OK
	     monmap e7: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0}, election epoch 998, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
	     mdsmap e232: 1/1/1 up {0=ceph-node2=up:active}
	     osdmap e4118: 9 osds: 9 up, 9 in
	      pgmap v33667: 1628 pgs, 45 pools, 2422 MB data, 3742 objects
	            7718 MB used, 127 GB / 134 GB avail
	                1628 active+clean
	[root@ceph-node1 ceph]#

Так как мы демонстрируем этот пример на виртуальных машинах, нам необходимо принудительно выполнить отказ диска переведя ceph-node1 в отключённое (DOWN) состояние, отключив диск и включив эту виртуальную машину опять. Выполните следующие команды на машине вашего хоста:

 storageattach ceph-node1 --storagectl "SATA" --port 1
--device 0 --type hdd --medium none
# VBoxManage startvm ceph-node1

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

	teeri:ceph-cookbook ksingh$ vBoxManage controlvm ceph-node1 poweroff
	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
	teeri:ceph-cookbook ksingh$
	teeri:ceph-cookbook ksingh$ vBoxManage storageattach ceph-node1 --storagectl "SATA" --port 1 --device 0 --type hdd --medium none
	teeri:ceph-cookbook ksingh$ vBoxManage startvm ceph-node1
	waiting for vm "ceph-node1" to power on...
	VM "ceph-node1" has been successfully started.
	teeri:ceph-cookbook ksingh$

Теперь ceph-node1 содержит отказавший диск, osd.0, который должен быть заменён:

# ceph osd tree

	[root@ceph-node1 ~]# ceph osd tree
	# id    weight  type name       up/down  reweight
	-1      0.08998 root default
	-3      0.03            host ceph-node2
	3       0.009995                         osd.3   up      1
	4       0.009995                         osd.4   up      1
	5       0.009995                         osd.5   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
	-2      0.02998         host ceph-node1
	0       0.009995                         osd.0   down    1
	1       0.009995                         osd.1   up      1
	2       0.009995                         osd.2   up      1
[root@ceph-node1 ~]#

Вы также отметите, что osd.0, находится в DOWN, однако, он всё ещё помечен как IN, кластер Ceph не переключит восстановление данных для этого диска. По умолчанию, кластер Ceph будет ждать 300 секунд перед тем как пометит выключенный диск как OUT, а после этого переключится на восстановление данных. Причина для данного таймаута заключается в попытке избежать не нужного перемещения данных обусловленных краткосрочными перерывами, например, перезагрузкой сервера. Можно увеличить или даже уменьшить этот таймаут при такой необходимости.

Вы должны подождать 300 секунд для переключения на восстановление данных или иначе вы можете вручную пометить этот диск как OUT:

# ceph osd out osd.0

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

# ceph status

Теперь давайте удалим этот отказавший диск OSD из вашей карты CRUSH:

# ceph osd crush rm osd.0

Удаляем ключи аутентификации вашей Ceph для этого OSD:

# ceph auth del osd.0

Наконец, удаляем этот OSD из вашего кластера Ceph:

# ceph osd rm osd.0

	[root@ceph-node1 ~]# ceph osd crush rm osd.0
	removed item id 0 name 'osd.0' from crush map
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph auth del osd.0 updated
	[root@ceph-node1 ~]# ceph osd rm osd.0
	removed osd.0
	[root@ceph-node1 ~]#

Так как один из ваших OSD недоступен, жизнеспособность (heath) кластера не будет OK и ваш кластер будет выполнять восстановление. Не стоит беспокоиться об этом; это нормальное действие Ceph. Когда операция восстановления завершится, ваш кластер получит опять HEALTH_OK:

# ceph -s
# ceph osd stat

	[root@ceph-node1 ~]# ceph -s
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
	     health HEALTH_OK
	     monmap e7: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0}, election epoch 1028, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
	     mdsmap e246: 1/1/1 up {0=ceph-node2=up:active}
	     osdmap e4164: 8 osds: 8 up, 8 in
	      pgmap v33855: 1628 pgs, 45 pools, 2422 MB data, 3742 objects
	            7918 MB used, 112 GB / 119 GB avail
	                1628 active+clean
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph osd stat
	osdmap e4164: 8 osds: 8 up, 8 in
	[root@ceph-node1 ~]#

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

Поскольку мы симулировали это на виртуальной машине, нам необходимо выключить нашу ВМ, добавить новый диск и перезапустить эту ВМ. Когда новый диск вставлен, сделайте замечание о его идентификаторе устройства OC:

# VBoxManage controlvm ceph-node1 poweroff
# VBoxManage storageattach ceph-node1 --storagectl "SATA" --port 1 --device 0 --type hdd --medium ceph-node1_disk2.vdi
# VBoxManage startvm ceph-node1

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

# ceph-deploy disk list ceph-node1

Перед добавлением этого диска в ваш кластер Ceph выполним disk zap:

# ceph-deploy disk zap ceph-node1:sdb

Наконец, создадим OSD на этот диск и Ceph добавит его как osd.0:

# ceph-deploy --overwrite-conf osd create ceph-node1:sdb

Когда этот OSD добавлен в ваш кластер Ceph, Ceph выполнит операцию наполнения и запустит перемещение PG со вторичных OSD на этот новый OSD. Операция восстановления потребует некоторого времени, однако по её завершению ваш кластер Ceph будет снова HEALTHY_OK:

# ceph -s
# ceph osd stat

	[root@ceph-node1 ceph]# ceph -s
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc
	     health HEALTH_OK
	     monmap e7: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0}, election epoch 1032, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
	     mdsmap e248: 1/1/1 up {0-ceph-node2=up:active}
	     osdmap e4191: 9 osds: 9 up, 9 in
	      pgmap v33983: 1628 pgs, 45 pools, 2422 MB data, 3742 objects
	            8160 MB used, 126 GB / 134 GB avail
	                1628 active+clean
	[root@ceph-node1 ceph]#
	[root@ceph-node1 ceph]# ceph osd stat
	osdmap e4191: 9 osds: 9 up, 9 in
	[root@ceph-node1 ceph]#

 Обновление вашего кластера Ceph

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

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

Инструментарий ceph-deploy

Демоны монитора Ceph

Демоны OSD Ceph

Выполнение Ceph как службы

Серверы метаданных Ceph

Шлюзы объектов Ceph

В качестве общего правила, рекомендуется чтобы вы обновляли все свои демоны определённого типа (например, все демоны ceph-mon, все демоны ceph-osd и так далее), чтобы гарантировать, что у них увсех одна и та же редакция.

[Замечание]
Замечание

Когда вы обновите демон Ceph, вы уже не сможете понизить его назад. Каждая редакция Ceph может иметь дополнительные шаги; очень сильно рекомендуется изучать справочную информацию разделов специфических для различных редакций http://docs.ceph.com/docs/master/release-notes/ для идентификации специфичных для редакции процедур при обновлении вашего кластера Ceph.

  Как это сделать...

В этом рецепте мы обновим наш кластер Ceph, который работает в редакции Giant (0.84.2) на самую последнюю стабильную редакцию Hammer.

Перед запуском процесса обновления давайте проверим нашу текущую версию ceph-deploy, монитора Ceph, OSD, MDS и демона ceph-rgw:

# ceph-deploy --version
# for i in 1 2 3 ; do ssh ceph-node$i service ceph status; done | grep -i running

		[root@ceph-node1 ~]# ceph-deploy --version
	1.5.25
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# for i in 1 2 3 ; do ssh ceph-nodeSi service ceph status; done I grep -i running mon.ceph-node1: running {"version":"0.87 2"}
	osd.0: running {"version":"0.87.2"}
	osd.1: running {"version":"0.87.2"}
	osd.2: running {"version":"0.87.2"}
	mon.ceph-node1: running {"version":"0.87.2"}
	osd.0: running {"version":"0.87.2"}
	osd.1: running {"version":"0.87.2"}
	osd.2: running {"version":"0.87.2"}
	mon.ceph-node2: running {"version":"0.87 2"}
	osd.3: running {"version":"0.87.2"}
	osd.4: running {"version":"0.87.2"}
	osd.5: running {"version":"0.87.2"}
	mds.ceph-node2: running {"version":"0.87.2"}
	mon.ceph-node3: running {"version":"0.87.2"}
	osd.6: runwing {"version":"0.87.2"}
	osd.7: running {"version":"0.87.2"}
	osd.8: running {"version":"0.87.2"}
	[root@ceph-node1 ~]#

Обновите ceph-deploy на его самую последнюю версию:

# yum update -y ceph-deploy
# ceph-deploy --version

Обновите репозитории yum своего Ceph на целевую редакцию Hammer. Обновите baseurl в /etc/yum.repos.d/ceph.repo на Hammer, как показано далее:

	[root@ceph-node1 ~]# cat /etc/yum.repos.d/ceph.repo
	[Ceph]
	name=Ceph packages for $basearch
	baseurl=http://ceph.com/rpm-hammer/e17/$basearch
	enabled=1
	gpgcheck=1
	type=rpm-md
	gpgkey=https://ceph.com/git/?p=ceph.git;a=blob_plainj=keys/release.asc
	priority=1

	[Ceph-noarch]
	name=ceph noarch packages
	baseurl=http://ceph.com/rpm-hammer/e17/noarch
	enabled=1
	gpgcheck=1
	type=rpm-md
	gpgkey=https://ceph.com/git/?p=ceph.git;a=blob_plainj=keys/release.asc
	priority=1

	[ceph-source]
	name=ceph source packages
	baseurl=http://ceph.com/rpm-hammer/e17/SRPmS
	enabled=1
	gpgcheck=1
	type=rpm-md
	gpgkey=https://ceph.com/git/?p=ceph.git;a=blob_plainj=keys/release.asc
	priority=1

	[root@ceph-node1 ~]#

Скопируйте репозитории yum вашего Ceph на остальные узлы Ceph:

# scp /etc/yum.repos.d/ceph.repo ceph-node2:/etc/yum.repos.d/ceph.repo
# scp /etc/yum.repos.d/ceph.repo ceph-node3:/etc/yum.repos.d/ceph.repo

	[root@ceph-node1 ~]# scp /etc/yum.repos.d/ceph.repo ceph-node2:/etc/yum.repos.d/ceph.repo
	ceph.repo                                                                        100%  611       0.6KB/s    00:00
	[root@ceph-node1 ~]# scp /etc/yum.repos.d/ceph.repo ceph-node3:/etc/yum.repos.d/ceph.repo
	ceph.repo                                                                        100%  611       0.6KB/s    00:00
	[root@ceph-node1 ~]#

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

[Замечание]
Замечание

В промышленной среде вам следует придерживаться последовательности обновления Ceph, как это предписывалось в начале главы, во избежание проблем. {Прим. пер.: подробнее см. раздел Модернизация вашего кластера Ceph в нашем переводе первой книги Карана Сингха Изучаем Ceph.}

Обновите Ceph с Giant (0.87.2) на стабильную редакцию Hammer (0.94.2):

# ceph-deploy install --release hammer ceph-node1 ceph-node2 ceph-node3

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

# service ceph restart mon

Давайте проверим жизнеспособность(health) кластера; так как этот кластер не имеет никаких состояний отказавших дисков, оно будет HEALTH_OK:

# ceph status

Перезапустите демоны OSD Ceph на всех узлах OSD Ceph один за другим:

# service ceph restart osd

Перезапустите демон MDS Ceph на узле MDS Ceph:

# service ceph restart mds

Наконец, когда все службы были успешно перезапущены, проверьте вашу версию Ceph:

# ceph -v
# for i in 1 2 3 ; do ssh ceph-node$i service ceph status; done | grep -i running

		[root@ceph-node1 ~]# for i in 1 2 3 ; do ssh ceph-node$i service ceph status; done 1 grep -i running
		mon.ceph-node1: running {"version":"0.94.2"}
		osd.0: running {"version":"0.94.2"}
		osd.1: running {"version":"0.94.2"} osd.2: running {"version":"0.94.2"}
		mon.ceph-node1: running {"version":"0.94.2"}
		osd.0: running {"version":"0.94.2"}
		osd.1: running {"version":"0.94.2"}
		osd.2: running {"version":"0.94.2"}
		mon.ceph-node2: running {"version":"0.94.2"}
		osd.3: running {"version":"0.94.2"}
		osd.4: running {"version":"0.94.2"}
		osd.5: running {"version":"0.94.2"}
		mds.ceph-node2: running {"version":"0.94.2"}
		mon.ceph-node3: running {"version":"0.94.2"}
		osd.6: running {"version":"0.94.2"}
		osd.7: running {"version":"0.94.2"}
		osd.8: running {"version":"0.94.2"}
		[root@ceph-node1 ~]#

 Сопровождение вашего кластера Ceph

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

  Как это сделать...

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

Однако, ситуация становится очень критичной когда она происходит на сборке, находящейся в промышленной эксплуатации, где вам следует применять некоторые из под команд/ флагов ceph osd, которые приводятся ниже, перед добавлением новогоузла в ваш кластер, например, noin, nobackfill и тому подобных. Это делается для того, чтобы ваш кластер не приступал к процессу заполнения немедленно после установки нового узла. Далее вы можете изменить установку этих флагов в промежуток не пиковых часов, и кластер выполнит в это время перебалансировку:

Применение этих флагов так же просто как установка и сброс. Например, чтобы установить флаг, примените следующую командную строку:

# ceph osd set <flag_name>
# ceph osd set noout
# ceph osd set nodown
# ceph osd set norecover

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

# ceph osd unset <flag_name>
# ceph osd unset noout
# ceph osd unset nodown
# ceph osd unset norecover

  Как это работает...

Здесь мы изучим чем эти флаги являются и зачем они применяются.

noout: Это принуждает ваш кластер Ceph не помечать любой OSD как покинувший (out) кластер, безотносительно к его состоянию. Это гарантирует, что все такие OSD останутся внутри вашего кластера.

nodown: Это принуждает ваш кластер Ceph не помечать любой OSD как отключённый (down), безотносительно к его состоянию. Это гарантирует, что все такие OSD останутся UP и никто из них не перейдёт в DOWN.

noup: Это принуждает ваш кластер Ceph не помечать любой OSD как включённый (UP). Следовательно, любой OSD, который помечен DOWN сможет перейти в состояние UP только после переустановки этого флага. Это также применимо к новым OSD, которые присоединились к вашему кластеру.

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

norecover: Это принуждает ваш кластер Ceph не выполнять восстановление кластера.

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

norebalance: Это принуждает ваш кластер Ceph не выполнять ребалансировку кластера.

noscrub: Это принуждает ваш кластер Ceph не выполнять чистку OSD.

nodeep-scrub: Это принуждает ваш кластер Ceph не выполнять глубокую чистку OSD.

notieragent: Это запрещает ваш агент многоуровневого кэширования.

Дополнительно к этим флагам вы также можете использовать следующие команды для восстановления OSD и PG:

ceph osd repair: Это выполнит восстановление на предписанном OSD.

ceph pg repair: Это выполнит восстановление на предписанной PG. Применяйте эту команду с предосторожностью; в зависимости от состояния вашего кластера эта команда способна воздействовать на данный пользователя, если применяется не должным образом.

ceph pg scrub: Это выполнит очистку предписанной PG.

ceph deep-scrub: Это выполнит глубокую очистку предписанной PG.

Ceph CLI обладает чрезвачайной мощностью для сквозного управления кластером. Вы можете получить дополнительную информацию здесь: http://ceph.com/docs/master/man/8/ceph/.

Глава 7. Ceph под колпаком

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

Масштабируемость и высокая доступность Ceph

Понимание механизма CRUSH

Карта CRUSH изнутри

Карта кластера Ceph

Мониторы высокой доступности

Аутентификация и авторизация Ceph

Динамическое управление Ceph кластером

Группы размещения Ceph

Состояние групп размещения

Создание пулов Ceph на специфических OSD

Содержание

7. Ceph под колпаком

Введение

Масштабируемость и высокая доступность Ceph

Понимание механизма CRUSH

Карта CRUSH изнутри

Карта кластера Ceph

Мониторы высокой доступности

Аутентификация и авторизация Ceph

Динамическое управление Ceph кластером

Группы размещения Ceph

Состояние групп размещения

Создание пулов Ceph на специфических OSD

 Введение

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

 Масштабируемость и высокая доступность Ceph

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

Рисунок 7.1. Традиционная архитектура систем хранения

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

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

Рисунок 7.2. Архитектура распределённого взаимодействия с устройствами хранения

Демоны OSD Ceph создают объекты и их реплики на других узлах Ceph чтобы гарантировать сохранность данных и высокую доступность. Ceph также применяет кластер мониторов для гарантированности высокой доступности и устранения централизации, Ceph применяет алгоритм, называемый CRUSH, что является аббревиатурой от Controlled Replication Under Scalable Hashing (Управляемых масштабируемым хешированием репликаций). С помощью CRUSH клиент по запросу вычисляет где должны быть записаны его данные или откуда их следует считать. В следующем рецепте мы исследуем подробности алгоритма CRUSH в Ceph.

 Понимание механизма CRUSH

Когда дело доходит до хранения и управления данными, Ceph применяет алгоритм CRUSH, который является интеллектуальным механизмом распределения данных Ceph. Как уже обсуждалось в предыдущем рецепте, традиционные системы хранения применяют централизованную таблицу метаданных/ индексов для знаний о том гда хранятся данные пользователя. Ceph, с другой стороны, применяет алгоритм CRUSHЮ который детерминированно вычисляет где ваши данные должны быть записаны и откуда считаны. Вместо сохранения метаданных CRUSH вычисляет метаданные по запросу, тем самым удаляя необходимость централизованного сервера/ шлюза в качестве брокера. Он уполномачивает клиентов Ceph вычислять метаданные, что называется просмотром CRUSH (CRUSH lookup), и взаимодействовать с OSD напрямую.

Для операций чтения и записи в кластере Ceph клиенты вначале взаимодействуют с монитором Ceph и извлекают копию карты кластера, которая содержит 5 карт, а именно карты монитора, OSD, MDS, а также CRUSH и PG; мы обсудим эти карты позже в данной главе. Эти карты кластера помогают клиентам знать состояние и конфигурацию вашего кластера Ceph. Далее данные преобразуются в объекты с помощью имени объекта, а также имени/ идентификатора пула. Этот объект затем хэшируется с номером группы размещения (PG) для выработки окончательной PG в пределах требуемого пула Ceph. Эта вычисленная группа размещения затем проходит через функцию просмотра CRUSH для определения первичного, вторичного и третичного местоположений OSD для хранения и извлечения данных.

Когда клиент получает точный идентификатор OSD, он взаимодействует с OSD напрямую и сохраняет свои данные. Все эти операции Создание линейно масштабируемых программно- управляемых систем хранения данных (FusionStorage/Ceph) {Прим. пер.: Ceph не одинок в своём подходе к вычислению местоположения данных взамен хранения метаданных такого местоположения, аналогично работает FusionStorage - проприетарное решение Huawei. Здесь вместо CRUSH применяется DHT, а вместо объектов хранятся блоки. Подробнее со сравнением FusionStorage и Ceph можно ознакомиться в нашей 2й презентации, 二(yee) НСКФ-2015 (Создание линейно масштабируемых программно- управляемых систем хранения данных). } Следующая диаграмма иллюстрирует весь этот процесс:

Рисунок 7.3. Вычисление места размещения данных

 Карта CRUSH изнутри

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

Рисунок 7.4. Круговорот карты CRUSH

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

  Как это сделать...

Сейчас мы взглянем на такую карту CRUSH нашего кластера Ceph:

Выделите вашу карту CRUSH с любого из своих узлов монитора:

# ceph osd getcrushmap -o crushmap_compiled_file

Когда вы получите вашу карту CRUSH, декомпилируйте её в читаемую человеком/ редактируемую форму:

# crushtool -d crushmap_compiled_file -o crushmap_decompiled_file

На данный момент файл вывода, crushmap_decompiled_file, может быть просмотрен/ отредактирован вами в предпочитаемом вами редакторе. В нашем следующем рецепте мы изучим как вносить изменения в вашу карту CRUSH.

Когда изменения внесены, вам следует скомпилировать эти изменения:

# crushtool -c crushmap_decompiled_file -o newcrushmap

Наконец, внедрите обновлённую скомпилированную карту CRUSH в свой кластер Ceph:

# ceph osd setcrushmap -i newcrushmap

  Как это работает...

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

Devices (устройства): Этот раздел карты CRUSH хранит перечень всех OSD в вашем кластере. OSD является физическим диском, соответствующим демону ceph-osd. Чтобы отображать группы размещения (PG) в ваши устройства OSD, для CRUSH необходим список устройств OSD. Этот перечень устройств появляется в начале карты CRUSH для объявления ваших устройств в карте CRUSH. Ниже приводится пример списка устройств:

	#devices
	device 0 osd.0
	device 1 osd.1
	device 2 osd.2
	device 3 osd.3
	device 4 osd.4
	device 5 osd.5
	device 6 osd.6
	device 7 osd.7
	device 8 osd.8

Bucket types (типы сегментов): Здесь определяются типы сегментов, применяемые в вашей иерархии CRUSH. Сегменты состоят из логической агрегации физического местоположения (например, рядов, стоек, шасси, хостов и тому подобного) и связанных с ними весов. Они способствуют иерархии узлов (nodes) и листьев (nodes), при которой сегмент node представляет физическое местоположение и может объединять другие сегменты узлов и листьев в вашей иерархии. Сегмент leaf представляет демон ceph-osd и лежащее в его основе физическое устройство. Следующая таблица приводит перечень типов сегментов по умолчанию:

Номер
Bucket
Описание

0

OSD

Демон OSD (например, osd.1, osd.2 и так далее).

1

Host

Имя хоста, содержащего одно или более OSD.

2

Rack

Вычислительная стойка, содержащая один или более хостов.

3

Row

Ряд в последовательности стоек.

4

Room

Помещение, содержащее стойки и их ряды с хостами.

5

Data Center

Физический центр обработки данных, состоящий из помещений.

6

Root

Это начало иерархии сегментов.

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

Bucket instances (экземпляры сегмента): Когда вы определяете тип сегмента, вы должны определить экземпляры для ваших хостов. Экземпляр сегмента требует тип сегмента, уникальное имя (строка), уникальный идентификатор, отображаемый отрицательным целым, вес относительно общей ёмкости его элементов, алгоритс сегмента (по умолчанию, straw), а также хэш (по умолчанию, 0, отражающий CRUSH Hash rjenkins1). Сегмент может иметь один или более элементов, а эти элементы могут состоять из прочих сегментов или OSD. Элемент должен иметь вес, который отражает относительный вес этого элемента. Общий синтаксис типа сегмента выглядит следующим образом:

[bucket-type] [bucket-name] {
  id [a unique negative numeric ID]
  weight [the relative capacity the item]
  alg [ the bucket type: uniform | list | tree | straw |
    straw2]
  hash [the hash type: 0 by default]
  item [item-name] weight [weight]
}

Сейчас мы вкратце обсудим параметры, применяемые для экземпляров сегментов CRUSH:

bucket-type: Это тип сегмента, в котором мы должны определить местоположение OSD в иерархии CRUSH.

bucket-name: Уникальное имя сегмента.

id: идентификатор, выраженный как отрицательное целое.

weight: Ceph записывает данные произвольным образом по всем дискам в вашем кластере, что помогает в производительности и лучшем распределении данных. Вес заставляет все ваши диски участвовать в вашем кластере и гарантировать, что все диски кластера используются одинаково, вне зависимости от их ёмкости. Для обеспечения этого Ceph применяет механизм весов. CRUSH назначает вес каждому OSD. Чем выше вес какого-то OSD, тем большую физическую ёмкость он имеет. Вес является относительной разницей между ёмкостями устройств. Мы рекомендуем применять 1.00 как относительный вес устройства хранения 1ТБ. Аналогично, вес 0.5 будет представлять примерно 500ГБ, а вес 3.00 будет соответствовать приблизительно 3ТБ.

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

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

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

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

Straw: Чтобы выбрать элемент с применением сегмента списков или деревьев, должно быть вычислено ограниченное число хэшей и сравнено по весу. они используют стратегию разделяй и властвуй, которая отдаёт предпочтение определённым элементам (например, находящимся в начале списка). Это повышает вашу производительность процесса размещения реплик, однако вносит умеренную реорганизацию при изменении содержимого сегмента из- за добавления, удаления или изменения веса.

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

Straw2: Это улучшенный сегмент соломинки, который корректно исключает любое перемещение данных между элементами A и B когда не изменяются веса ни A, ни B. Другими словами, если мы выравниваем вес элемента C, добавляя к нему новое устройство, или удаляя его совсем, перемещение данных будет иметь место только на C или с него, и никогда между прочими элементами в вашем сегменте. Таким образом, алгоритм Straw2 уменьшает необходимый объём миграции данных при внесении изменений в ваш кластер.

hash: Все сегменты применяют алгоритм хэширования. В настоящее время Ceph поддерживает rjenkins1. Введите 0, если ваш хэш установлен на выбор rjenkins1.

item: Сегмент может иметь один или более элементов. Эти элементы могут состоять из сегментов узлов или листьев. Элементы могут иметь вес, который отражает относительный вес этого элемента.

Следующий снимок экрана иллюстрирует экземпляр сегмента CRUSH. Здесь у нас присутствуют три экземпляра хоста сегмента. Эти экземпляры сегмента хоста состоят из сегментов OSD:

	# buckets
	host ceph-node2 {
	        id -3           # do not change unnecessarily
	        # weight 0.030
	        alg straw
	        hash 0 # rjenkinsl
	        item osd.3 weight 0.010
	        item osd.4 weight 0.010
	        item osd.5 weight 0.010
	}
	host ceph-node3 {
	        id -4           # do not change unnecessarily
	        # weight 0.030
	        alg straw
	        hash 0 # rjenkinsl
	        item osd.6 weight 0.010
	        item osd.7 weight 0.010
	        item osd.8 weight 0.010
	}
	host ceph-node1 {
	        id -2           # do not change unnecessarily
	        # weight 0.030
	        alg straw
	        hash 0 # rjenkinsl
	        item osd.1 weight 0.010
	        item osd.2 weight 0.010
	        item osd.0 weight 0.010
	}

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

	rule <rulename> {
	    ruleset <ruleset>
		type [ replicated | erasure ]
		min_size <min-size>
	    max_size <max-size>
	    step take <bucket-type>
	    step [choose|chooseleaf] [firstn] <num>
	      <bucket-type>
	    step emit
	}

Теперь мы кратко объясним эти используемые в правилах CRUSH параметры:

ruleset: Целое значение; классифицирует некое правило, как относящееся к набору правил.

type: Строковое значение; определяет тип пула который может быть либо replicated, либо erasure coded.

min_size: Целое значение; если пул делает меньшее число реплик, чем предписывает это значение, CRUSH не выбирает это правило.

max_size: Целое значение; если пул делает большее число реплик, чем предписывает это значение, CRUSH не выбирает это правило.

step take: Берёт имя сегмента и начинает итерировать дерево вниз.

step choose firstn {num} type {bucket-type}: Выбирает число (N) сегментов заданного типа, где число (N) обычно число реплик в данном пуле (т.е. размер пула):

Если num == 0, то выбрать N сегментов

Если num > 0 && < N, то выбрать num сегментов

Если num < 0, то выбрать N - num сегментов

Пример: step choose firstn 1 type row

В этом примере num = 1 и если предположить что размер пула равен 3, то CRUSH будет вычислять это условие как 1 > 0 && < 3. Следовательно, он выберет тип сегмента 1 row.

step chooseleaf firstn {num} type {bucket-type}: Это правило вначале выберет набор сегментов bucket-type, а затем выберет узел листа из поддерева каждого сегмента в нашем наборе сегментов. Число сегментов в наборе (N) обычно число реплик в данном пуле (т.е. размер пула):

Если num == 0, то выбрать N сегментов

Если num > 0 && < N, то выбрать num сегментов

Если num < 0, то выбрать N - num сегментов

Пример: step chooseleaf firstn 0 type row

В этом примере num = 0 и если предположить что размер пула равен 3, то CRUSH будет вычислять это условие как 0 == 0 и затем выберет узел листа из своего поддерева каждого сегмента. Таким образом, CRUSH выберет 3 листовых узла.

step emit: Этот первый вывод текущего значения и освобождение стека. Как правило, применяется в конце правила, но может также применяться для формирования различных деревьев в том же правиле.

 Карта кластера Ceph

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

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

# ceph mon dump

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

# ceph osd dump

PG map (карта групп размещения): Содержит версию PG, временной штамп, последнюю эпоху карты OSD, полное отношение, а также информацию связанную с этим отношением (весовым коэффициентом). Она также содержит отслеживание всех идентификаторов PG, количество объектов, состояние, штамп состояния, наборы работающих (up) и активных OSD, а также, наконец, подробности очистки. Для проверки карты PG кластера выполните:

# ceph pg dump

CRUSH map (карта Управляемых масштабируемым хешированием репликаций): Содержит информацию о ваших устройствах кластера, сегментах (bucket), иерархии доменов отказа, а также определённых для этого домена отказа с хранящимися данными правил. Для проверки вашей карты CRUSH выполните:

# ceph osd crush dump

MDS map (карта сервера метаданных): Она хранит информацию о текущей эпохе карты MDS, создании карты и времени изменения идентификатор пула данных и метаданных, количество MDS кластера, а также состояние вашего MDS. Для проверки вашей карты MDS выполните:

# ceph mds dump

 Мониторы высокой доступности

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

Кластер хранения Ceph может работать с одним монитором, однако, это создаёт риск единственной точки отказа для вашего кластера; то есть, если монитор отключается, клиенты Ceph не смогут читать и записывать данные. Чтобы преодолеть это, обычный кластер Ceph состоит из кластера мониторов Ceph. Архитектура Ceph со многими мониторами вырабатывает кворум и обеспечивает консенсус для распределённого принятия решений в кластере с применением алгоритма Paxos {см. также habrahabr} Число мониторов в вашем кластере должно быть нечётным числом; абсолютным необходимым минимумом является один узел монитора, а рекомендуемое число три. Поскольку мониторы работают в кворуме, более половины от общего числа мониторов должны быть всегда доступны для предотвращения проблем раздвоения сознания. Один из мониторов кластера выступает в роли ведущего (leader). Если ведущий монитор недоступен, другие узлы монитора имеют право стать ведущими. Промышленный кластер должен иметь по крайней мере три узла мониторов для предоставления высокой доступности.

 Аутентификация и авторизация Ceph

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

Рисунок 7.5. Потоки взаимодействия клиентов с демонами кластера

Ceph предоставляет два режима аутентификации. Это:

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

auth cluster required = none
auth service required = none
auth client required = none

Cephx: Для идентификации пользователей и проектов с целью предотвращения атак злоумышленников в роли посредника, Ceph предоставляет систему аутентификации Cephx для удостоверения подлинности пользователей и демонов. Протокол Cephx работает в некоторой степени аналогично Kerberos и позволяет клиентам получать доступ к кластеру Ceph. Следует знать, что gротокол Cephx не шифрует данные. В кластере Ceph протокол Cephx разрешён по умолчанию. Если вы отключили Cephx добавив в свой файл настроек конфигурации кластера предыдущие параметры аутентификации, то вы можете включить Cephx двумя способами. Одним из них будет простое удаление всех записей auth из вашего файла настроек конфигурации кластера, содержащих none, или вы можете в явном виде разрешить Cephx добавив следующие параметры в ваш файл настроек кластера и перезапустив ваши службы Ceph:

auth cluster required = cephx
auth service required = cephx
auth client required = cephx

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

  Аутентификация Ceph

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

Для применения Cephx администратор, т.е. client.admin должен создать учётную запись в вашем кластере Ceph. Для создания учётной записи пользователя, пользователь client.admin вызывает команду ceph auth get-or-create key. Подсистема аутентификации Ceph генерирует имя пользователя и ключ безопасности, сохраняя эту информацию в вашем мониторе Ceph и возвращая ключ безопасности пользователя пользователю client.admin, который вызвал команду создания данного пользователя. Системный администратор Ceph должен сделать доступным для совместного применения эти имя и ключ безопасности тем клиентам Ceph, которые хотят применять службу хранения Ceph безопасным образом. Следующая схема отображает весь этот процесс:

Рисунок 7.6. Процесс создания пользователя и его ключа безопасности

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

Чтобы получить доступ к вашему кластеру Ceph, клиент вначале должен связаться со своим узлом монитора и переслать только своё имя пользователя. Протокол Cephx работает таким образом, что обе части имеют возможность подтвердить что они имеют копию данного ключа без его реального обнажения. Это та причина, почему клиент отсылает только имя пользователя а не свой ключ безопасности.

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

С помощью ключ сеанса данный пользователь запрашивает маркер (ticket) у монитора Ceph. Монитор Ceph проверяет этот ключ сеанса и затем генерирует маркер (ticket), закодированный ключом безопасности пользователя и отсылает его данному пользователю. Клиент декодирует маркер и применяет его для подписи запросов к OSD и серверам метаданных по всему кластеру.

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

Рисунок 7.7. Процесс аутентификации

  Авторизация Ceph

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

{daemon-type} 'allow {capability}' [{daemon-type} 'allow {capability}']

Monitor caps: Включает параметры r, w, x, а также allow profiles {cap}. Например:

mon 'allow rwx' or mon 'allow profile osd'

OSD caps: Включает параметры r, w, x, class-read, class-write и profile osd. Например:

osd 'allow rwx' or osd 'allow class-read, allow rwx pool=rbd'

MDS caps: Требует только allow. Например:

mds 'allow'

Давайте изучим все такие возможности:

allow: Подразумевает только rw для MDS.

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

w: Предоставляет пользователю доступ по записи в объекты.

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

[Замечание]
Замечание

Ceph может быть расширен путём создания классов объектов для совместного использования, называемых Ceph Classes. Ceph может загружать классы .so, хранимые в вашем OSD классе dir. Для класса вы можете создать новые методы объекта, которые имеют возможность вызывать встроенные методы в вашем хранилище объектов Ceph, например, объекты, которые вы определили в своём классе, могут вызывать встроенные методы наподобие read и write.

class-read: Это подмножество x, которое позволяет пользователям вызывать методы чтения класса.

class-write: Это подмножество x, которое позволяет пользователям вызывать методы записи класса.

*: Предоставляет пользователям полные права (r, w и x) на определяемом пуле, а также выполнять команды администратора.

profile osd: Позволяет пользователям соединяться в качестве OSD с другими OSD или мониторами. Применяется для трафика проверки жизнеспособности (heartbeat) OSD и отчётов о состоянии.

profile mds: Позволяет пользователям соединяться в качестве MDS с другими MDS.

profile bootstrap-osd: Позволяет пользователям выполнять самозагрузку OSD. Например, инструменты ceph-deploy и ceph-disk применяют пользователя client.bootstrap-osd, который имеет права добавлять ключи и выполнять самозагрузку OSD.

profile bootstrap-mds: Позволяет пользователям выполнять самозагрузку сервера метаданных. Например, инструменты ceph-deploy и ceph-disk применяют пользователя client.bootstrap-mds, который имеет права добавлять ключи и выполнять самозагрузку сервера метаданных.

Пользователь может быть индивидуальным пользователем или приложением, например, cinder/ nova в случае OpenStack. Создание пользователей позволяет вам управлять тем, кто может иметь доступ к вашему кластеру хранения Ceph, его пулам и данным в пределах этих пулов. В Ceph пользователь должен иметь тип, который всегда client, а также идентификатор, который может быть любым именем. Поэтому допустимым синтаксисом в Ceph является TYPE.ID, или client.<name>, например, client.admin или client.cinder.

  Как это сделать...

В следующем рецепте мы дополнительно обсудим управление пользователем Ceph путём выполнения некоторых команд:/p>

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

# ceph auth list

Вывод этой команды покажет их для каждого типа демона, Ceph создаёт пользователей с различными возможностями. Она также отобразит пользователя client.admin, который является пользователем администратором кластера.

Для извлечения определённого пользователя, например, client.admin, выполните:

# ceph auth get client.admin

	[root@ceph-node1 ~]# ceph auth get client.admin
	exported keyring for client.admin
	[client.admin]
		key = AQAfgAhvmExcGBAAfRAg084RHNtmfK83iheelg==
		caps mds = "allow"
		caps mon = "allow *"
		caps osd = "allow *"
	[root@ceph-node1 ~]#

Создайте пользователя client.hari:

# ceph auth get-or-create client.hari

	[root@ceph-node1 ~]# ceph auth get-or-create client.hari
	[client.hari]
		key = AQBm5W1ineFHRAAhzvxxEkzn9D98HCxIu9EyQ==
	[root@ceph-node1 ~]#

Это создаёт пользователя client.hari без каких бы то ни было возможностей, а пользователь без таковых не может применяться.

Добавьте возможности пользователю client.hari:

# ceph auth caps client.hari mon 'allow r' osd 'allow rwx pool=rbd'

	[root@ceph-node1 ~]# ceph auth caps client.hari mon 'allow r' osd 'allow rwx pool=rbd'
	updated caps for client.hari
	[root@ceph-node1 ~]#

Выведем перечень возможностей нашего пользователя:

# ceph auth get client.hari

	[root@ceph-node1 ~]# ceph auth get client.hari
	exported keyring for client.hari
	[client.hari]
		key = AQBmSN1VZCeFHRAAhZvXXEkZn9D98HCXIu9EyQ==
		caps mon = "allow r"
		caps osd = "allow rwx pool=rbd"
	[root@ceph-node1 ~]#

 Динамическое управление Ceph кластером

Давайте быстро повторим вкратце как клиенты получают доступ к кластеру Ceph. Чтобы выполнить операцию записи в вашем кластере Ceph, клиент получает самую последнюю копию карты кластера от своего монитора Ceph (если он ещё не имеет её). Карта кластера предоставляет информацию о компоновке этого кластера Ceph. Затем данный клиент записывает/ считывает объект, который хранится в пуле Ceph. Следующая схема демонстрирует этот процесс целиком:

Рисунок 7.8. Процесс записи/ чтения объекта

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

Рисунок 7.9. Процесс сохранения объектов в кластере

 Группы размещения Ceph

Группа размещения (PG, Placement Group) является логической коллекцией объектов, которые реплицированы по OSD для обеспечения надёжности в системе хранения. В зависимости от установленного уровня репликаций пула Ceph, каждая группа размещения реплицируется и распределяется на более чем одно OSD кластера Ceph. Вы можете рассматривать PG как логический контейнер, содержащий множество объектов таким образом, что этот логический контейнер соответствует множеству OSD.

Рисунок 7.10. Группы размещения

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

Каждой группе размещения необходимы некоторые ресурсы системы, поскольку они управляют множеством объектов. Число PG в кластере должно педантично подсчитываться, и эта процедура обсуждается позднее в данной книге. Обычно, увеличение числа групп размещения в вашем кластере выполняет повторную балансировку нагрузки OSD. Рекомендуемое значение PG на OSD составляет от 50 до 100 во избежание высокого использования ресурсов на узле OSD. По мере возрастания объёмов данных на кластере Ceph, вам необходимо подстраивать ваш кластер выравнивая значение ваших PG. Когда устройства в кластере добавляются или удаляются устройства, CRUSH управляет перемещением групп размещения наиболее оптимальным образом.

Теперь мы получили представление о том, как группы размещения Ceph хранят свои данные на множестве OSD для обеспечения надёжности и высокой доступности. Эти OSD называются первичным, вторичным, третичным и так далее, и они относятся к набору, который называется действующим набором (acting set) для этой группы размещения. Для каждого действующего набора PG первый OSD является первичным, а последующие вторичным и третичным.

  Как это сделать...

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

Добавим в пул rbd временный объект с именем hosts:

# rados put -p rbd hosts /etc/hosts

Проверим имя PG для объекта hosts:

# ceph osd map rbd hosts

	[root@ceph-node1 ~]# rados put -p rbd hosts /etc/hosts
	[root@ceph-node1 ~]# [root@ceph-node1 ~]# rados is -p rbd | grep -i hosts
	hosts
	[root@ceph-node1 ~]# ceph osd map rbd hosts
	osdmap e4376 pool 'rbd' (0) object 'hosts' -> pg 0.ealb298e (0.8e) -> up ([8,2,4], p8) acting ([8,2,4], p8)
	[root@ceph-node1 ~]#

Когда вы рассмотрите вывод, Placement Group (0.8e) имеет up set [8,2,4] и acting set [8,2,4]. Следовательно, здесь osd.8 первичный OSD, а osd.2 и osd.4 являются вторичным и третичным OSD. Первичное OSD является единственным OSD, которое принимает операции записи клиента. Когда получается запрос read, по умолчанию он также приходит на первичное OSD, но мы можем изменить такое поведение, установив ассоциированное чтение (read affinity).

Включенное (up) OSD остаётся в рабочем наборе (up set), так же как и в активном наборе. Если первичное OSD выходит из строя, оно вначале удаляется из рабочего набора (up set), а затем из активного набора. Вторичное устройство после этого продвигается на место первичного OSD. Ceph восстанавливает группы размещения отказавшего OSD на новое OSD, а затем добавляет его в рабочий и активный наборы для гарантирования высокой доступности. В кластере Ceph некое OSD может быть первичным OSD для некоторых PG и в то же время оно может быть вторичным или третичным OSD для других PG.

 Состояние групп размещения

Группы размещения Ceph могут представлять различные состояния на основе того что происходит в вашем кластере в данный момент времени. Чтобы узнать состояние PG вы можете просмотреть вывод команды ceph status. В данном рецепте мы рассмотрим эти различные состояния поясним что означает на самом деле каждое состояние.

Creating: Эта PG создётся. Обчычно это происходит при создании пула или когда в пуле увеличивается число PG.

Active: Все PG активны, и запросы к этой PG будут обработаны.

Clean: Все объекты в этой PG реплицированы необходимое число раз.

Down: Реплика с необходимыми данными отключена, поэтому PG выключена (down).

Replay: Эта PG ждёт клиентов для операций воспроизведения после краха OSD.

Splitting: Данная PG разделяется на множество PG. Обычно PG достигает такого состояния когда для существующего пула увеличивается число групп размещения. Например, если вы увеличиваете число PG пула rbd c 64 до 128, существующие PG расщепляются и некоторые из их объектов будут перемещены в новые PG.

Scrubbing: Данная PG проверяется на непротиворечивость.

Degraded: Некоторые объекты в этой PG не реплицированы должное число раз.

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

Peering: В данной PG выполняется процесс однорангового обмена (Peering), в котором осуществляется попытка привести OSD, которое хранит реплики данной PG в соответствие с состоянием объектов и метаданных в этой PG.

Repair: Эта PG проверяется и все найденные противоречия будут устранены (по возможности).

Recovering: Объекты мигрируют/ синхронизируются с репликами. В случае останова OSD его содержимое может отставать от текущего состояния прочих реплик в данной PG. Поэтому PG переходит всостояние восстановления и объекты будут мигрировать/ синхронизироваться с репликами.

Backfill: Когда новое OSD присоединяется к вашему кластеру, CRUSH переназначает PG с существующих OSD в вашем кластере на вновь добавленное OSD. По завершению заполнения такое новое OSD начнёт обслуживать запросы по их возникновению.

Backfill-wait: PG ожидает в очереди начала заполнения.

Incomplete: PG утратила необходимый период истории из своего журнала. Это обычно происходит когда содержащее необходимую информацию OSD отказывает или не доступно.

Stale: Данная PG находится в неизвестном состоянии - мониторы не получили для неё обновления поскольку отображение PG изменилось. Когда вы запускаете свой кластер, обычно можно увидеть такое устаревшее состояние пока не завершится процесс однорангового обмена.

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

 Создание пулов Ceph на специфических OSD

Кластер Ceph обычно состоит из ряда узлов имеющих множество дисковых устройств. Причём, эти дисковые устройства могут быть различных типов. Например, ваши узлы Ceph могут содержать диски ATA, NL-SAS, SAS, SSD или даже PCIe, и тому подобное. Ceph предоставляет вам гибкость создавать пулы на определённых типах устройств. Например, вы можете создать высокопроизводительный пул SSD из набора дисков SSD, или вы можете создать пул с большой ёмкостью и низкой стоимостью с применением дисков SATA.

В данном рецепте мы узнаем как создать пул с именем ssd-pool на основе SSD дисков, а также другой пул с именем sata-pool, который базируется на SATA дисках. Достигнув этого, мы изменим карту CRUSH и выполним необходимые настройки.

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

Для последующей демонстрации давайте предположим, что osd.0, osd.3 и osd.6 являются SSD дисками и мы будем создавать на этих дисках пул SSD. Аналогично, osd.1, osd.5 и osd.7 являются SATA дисками, которые будут размещать пул SATA.

  Как это сделать...

Давайте приступим к настройке:

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

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

	[root@ceph-node1 ~]# ceph osd getcrushmap -o crushmapdump
	got crush map from osdmap epoch 4443
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# crushtool -d crushmapdump -o crushmapdump-decompiled
	[root@ceph-node1 ~]# ls -l crushmapdump-decompiled
	-rw-r--r-- 1 root root 1360 Sep  1 21:41 crushmapdump-decompiled
	[root@ceph-node1 ~]#

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

	root ssd {
		id -5
		alg straw
		hash 0
		item osd.0 weight 0.010
		item osd.3 weight 0.010
		item osd.6 weight 0.010
	}
	root sata {
		id -6
		alg straw
		hash 0
		item osd.1 weight 0.010
		item osd.4 weight 0.010
		item osd.7 weight 0.010
	}

Создадим правила CRUSH добавив следующие правила в разделе правил вашей карты CRUSH, затем сохраним и завершим редактирование:

	rule ssd-pool {
		ruleset 1
		type replicated
		min_size 1
		max_size 10
		step take ssd
		step chooseleaf firstn 0 type osd
		step emit
	}
	rule sata-pool {
		ruleset 2
		type replicated
		min_size 1
		max_size 10
		step take sata
		step chooseleaf firstn 0 type osd
		step emit
	}

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

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

После того, как карта CRUSH применена к вашему кластеру Ceph, проверьте обзор его дерева OSD на предмет новой систематизации и отметьте сегменты (bucket) корня ssd и sata:

# ceph osd tree

	[root@ceph-node1 ~]# ceph osd tree
	ID WEIGHT  TYPE NAME           UP/DOWN REWEIGHT PRIMARY-AFFINITY
	-6 0.02998 root sata
	 1 0.00999     osd.1                up  1.00000          1.00000
	 4 0.00999     osd.4                up  1.00000          1.00000
	 7 0.00999     osd.7                up  1.00000          1.00000
	-5 0.02998 root ssd
	 0 0.00999     osd.0                up  1.00000          1.00000
	 3 0.00999     osd.3                up  1.00000          1.00000
	 6 0.00999     osd.6                up  1.00000          1.00000
	-1 0.09000 root default
	-3 0.03000      host ceph-node2
	 3 0.00999     osd.3                up  1.00000          1.00000
	 4 0.00999     osd.4                up  1.00000          1.00000
	 5 0.00999     osd.5                up  1.00000          1.00000
	-4 0.03000      host ceph-node3
	 6 0.00999     osd.6                up  1.00000          1.00000
	 7 0.00999     osd.7                up  1.00000          1.00000
	 8 0.00999     osd.8                up  1.00000          1.00000
	-2 0.03000      host ceph-node1
	 1 0.00999     osd.1                up  1.00000          1.00000
	 2 0.00999     osd.2                up  1.00000          1.00000
	 0 0.00999     osd.0                up  1.00000          1.00000
[root@ceph-node1 ~]#

Создайте и проверьте ваш ssd-pool.

[Замечание]
Замечание

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

Создайте ssd-pool:

# ceph osd pool create ssd-pool 8 8

Проверьте ssd-pool; заметьте, что crush_ruleset установлен в значение 0, что является значением по умолчанию:

# ceph osd dump | grep -i ssd

	[root@ceph-node1 ~]# ceph osd pool create ssd-pool 8 8
	pool 'ssd-pool' created
	[root@ceph-node1 ~]# ceph osd dump | grep ssd
	pool 45 'ssd-pool' replicated size 3 min_size 2 crush_ruleset 0 object hash rjenkins pg_num 8 pgp_num 8 last_change 4446 flags hashpspool stripe,idth 0
	[root@ceph-node1 ~]#

Давайте изменим значение crush_ruleset на 1, поскольку этот новы пул создан на дисках SSD:

# ceph osd pool set ssd-pool crush_ruleset 1

Проверим пул и отметим изменения в crush_ruleset:

# ceph osd dump | grep -i ssd

	[root@ceph-node1 ~]# ceph osd pool set ssd-pool crush_ruleset 1
	set pool 45 crush_ruleset to 1
	[root@ceph-node1 ~]# ceph osd dump | grep ssd
	pool 45 'ssd-pool' replicated size 3 minimize 2 crush_ruleset 1 object_hash rjenkins pg_num 8 pgp.num 8 last_change 4448 flags hashpspool stripe_width 0
	[root@ceph-node1 ~]#

Аналогично создаём и проверяем sata-pool.

	[root@ceph-node1 ~]# ceph osd pool create sata-pool 8 8
	pool 'sata-pool' created
	[root@ceph-node1 ~]# ceph osd dump | grep -i sata
	pool 46 'sata-pool' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 8 pgp_num 8 last_change 4450 flags hashpspool stripe_width 0
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph osd pool set sata-pool crush_ruleset 2
	set pool 46 crush_ruleset to 1
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph osd dump | grep -i sata
	pool 46 'sata-pool' replicated size 3 min_size 2 crush_ruleset 2 object_hash rjenkins pg_num 8 pgp_num 8 last_change 4452 flags hashpspool stripe_width 0
	[root@ceph-node1 ~]#

Давайте добавим некоторые объекты в эти пулы:

Поскольку данные пулы новые, они не должны содержать никаких объектов, однако, давайте проверим это применив команду rados list:

# rados -p ssd-pool ls
# rados -p sata-pool ls

Сейчас мы добавим некий объект вэти пулы используя команду rados put. Её синтаксис таков: rados -p <pool_name> put <object_name> <file_name>.

# rados -p ssd-pool put dummy_object1 /etc/hosts
# rados -p sata-pool put dummy_object1 /etc/hosts

Применяя команду rados list, выведем перечень этих пулов. Вы должны получить имена объектов, сохранённых на предыдущем этапе.

# rados -p ssd-pool ls
# rados -p sata-pool ls

	[root@ceph-node1 ~]# rados -p ssd-pool ls
	[root@ceph-node1 ~]# rados -p sata-pool ls
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# rados -p ssd-pool put dummy_object1 /etc/hosts
	[root@ceph-node1 ~]# rados -p sata-pool put dummy_object1 /etc/hosts
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# rados -p ssd-pool is dummy_object1
	[root@ceph-node1 ~]# rados -p sata-pool is dummy_object1
	[root@ceph-node1 ~]#

Теперь вставка всего этого раздела должна проверить что эти объекты были сохранены в правильном наборе OSD:

Для нашего ssd-pool, у нас применяются OSD 0, 3 и 6. Проверьте osd map c ssd-pool, применяя следующий синтаксис: ceph osd map <pool_name> <object_name>.

# ceph osd map ssd-pool dummy_object1

Аналогично, проверьте объекты в sata-pool:

# ceph osd map sata-pool dummy_object1

	[root@ceph-node1 ~]# ceph osd map ssd-pool dummy_object1
	psdmap e4455 pool 'ssd-pool' (45) object 'dummy_objectl' -> pg 45.71968e96 (45.6) -> up ([3,0,6], p3) acting ([3,0,6], p3)
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph osd map sata-pool dummy_objectl1
	osdmap e4455 pool 'sata-pool' (46) object 'dummy_objectl' -> pg 46.71968e96 (46.6) -> up ([1,7,4], pl) acting ([1,7,4], pl)
	[root@ceph-node1 ~]#

Как показано на предыдущем снимке экрана, объект, который создан в ssd-pool на самом деле хранится в наборе OSD [3,0,6], а объекты, которые созданы в пуле sata-pool, были сохранены в наборе OSD [1,7,4]. Этот вывод был ожидаем, и он подтверждает, что созданный нами пул верно использует набор OSD, как это было предписано. Такой тип настроек может быть очень полезным в промышленных установках, в которых вам захочется создать быстрый пул только на базе SSD и пул со средней/ малой производительностью основанный на шпиндельных дисках.

[Совет]
Совет

{Прим. пер.: чтобы полностью использовать полосу пропускания SSD, они должны расщепляться примерно между 5 OSD (по опыту Mirantis), для включения такой возможности вам необходимо удалить OSD, созданные на этих SSD при установке, разделить каждый SSD на пять разделов и создать на них OSD. см., например, раздел 6.1 Эталонной архитектуры для компактного облачного решения с применением Mirantis OpenStack 9.1 и оборудования Dell EMC.}

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

В данной главе мы охватим такие рецепты:

Динамика ёмкости, производительности и стоимости

Выбор аппаратных и программных компонентов Ceph

Рекомендации Ceph и настройка производительности

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

Создание пула с удаляющим кодированием

Многоуровневое кэширование Ceph

Создание пула для многоуровневого кэширования

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

Настройка уровня кэша

Тестирование уровня кэша

Содержание

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

Введение

Динамика ёмкости, производительности и стоимости

Выбор аппаратных и программных компонентов Ceph

Рекомендуемые цены Intel на некоторые ЦПУ

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

Аппаратная поддержка удаляющего кодирования ASIC ConnectX-4

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

NVMe

Рекомендации Ceph и настройка производительности

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

Учебное пособие по алгоритмам Рида- Соломона

Создание пула с удаляющим кодированием

Многоуровневое кэширование Ceph

Создание пула для многоуровневого кэширования

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

Настройка уровня кэша

Тестирование уровня кэша

 Введение

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

 Динамика ёмкости, производительности и стоимости

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

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

Рисунок 8.1. Наилучшая область

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

Рисунок 8.2. Вариант определения потребностей хранения

IOPS Optimized (оптимизированные под IOPS): Основным моментом такого типа конфигурация является наивысшая IOPS (количество операций ввода/ вывода в секунду) при низкой TCO (совокупной стоимости владения) операции ввода/ вывода (IO). Обычно реализуется с применением для хранения высокопроизводительных узлов, содержащих самые быстрые диски SSD, PCIe SSD, NVMe и тому подобного. Обычно применяется для хранения блоков, однако вы можете применять их и для других рабочих нагрузок, нуждающихся в высоких IOPS.

Throughput Optimized (оптимизированные под пропускную способность): Их изюминка состоит в наивысшей пропускной способности при её низкой стоимости. Они обычно реализуются с применением дисков SSD и PCIe SSD для ведения журналов OSD с физически дублированной сетевой средой высокой пропускной способности. В основном применяются для блочных устройств. Если ваши варианты применения требуют высокопроизводительного хранения объектов или файлов, то вам следует рассмотреть такой вариант.

Capacity Optimized (оптимизированные под ёмкость): Его привлекательная сторона заключается в низкой стоимости за ТБ и низкой стоимости из расчёта на юнит стойки или физическое пространство центра обработки данных. Оно также известно как экономичное хранилище, хранилище с низкой стоимостью, а также как архивное/ долговременное хранилище, и оно обычно реализуется с применением плотных серверов, наполненных шпиндельными дисками, обычно от 36 до 72 физических дисков на сервер с ёмкостью физических дисков 4 или 6ТБ. Они обычно применяются как хранилища объектов или файловых систем большой ёмкости с низкой стоимостью. Это хорошие претенденты на применение удаляющего кодирования для максимизации используемой ёмкости.

[Замечание]
Замечание

{Прим. пер.: Это может показаться забавным, однако с некоторых пор стало возможным построение бесплатной среды виртуализации на основе гипервизора Hyper-V с бесплатной же системой хранения Storage Spaces, обладающей современными функциональностью и мощностью сопоставимыми, например, с Ceph. Хотя она и ограничена в масштабировании применением аппаратных технологий SAS/ FC. Остаётся дождаться смещения Storage Spaces Direct (S2D) в сферу халявного применения, чтобы имеющаяся в Непосредственно подключаемых пространствах хранения Программно определяемая шина хранения (Software Storage Bus), заменяющая собой SAS/FC, смогла составить конкуренцию системам хранения уровня 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.

Процессор Intel® Xeon® E5-2620 v3 (2.40 ГГц, 6 ядер)

1 * 6 * 2.4= 14.4 предполагает, что его достаточно для узла Ceph с общим числом OSD до 14.

Процессор Intel® Xeon® E5-2680 v3 (2.50 ГГц, 12 ядер)

1 * 12 * 2.5= 30 предполагает, что его достаточно для узла Ceph с общим числом OSD до 30.

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

[Замечание]
Замечание

Если вы планируете применять пул Ceph с удаляющим кодированием, то будет полезным получить более мощные ЦПУ, поскольку OSD Ceph, которые размещают пулы с удаляющим кодированием больше используют ЦПУ чем размещающие пулы с репликациями OSD Ceph.

[Совет]
Совет переводчика

{Cтоит воздерживаться от применения в одном кластере ЦПУ разных поколений (например Intel® Xeon® E5-2620 v3 и Intel® Xeon® E5-2620 v2) и, тем более, разных производителей (Intel/ Amd) или даже архитектур (x86/ ARM/ Sparc/ Power). Это может стать причиной проблем с применяемым программным обеспечением, а также существенно осложнит возможности миграции и сопровождения. Если уж деваться некуда, необходимо убедиться в совместимости применяемого вами в режиме совместимости кода.}

[Замечание]
Замечание переводчика

{Ядра многих современных ЦПУ поддерживают Hyper-threading (гиперпоточность), позволяющую демонам разделять ядро на аппаратном уровне. Хотя эта технология, как правило, проигрывает в производительности от долей процента до нескольких процентов по сравнению с работой ядра при выключенной гиперпоточности, не стоит сбрасывать со счетов эту возможность для аппаратной изоляции демонов с прицелом на повышение высокой доступности. Испытывающий проблемы OSD будет конкурировать за ресурс с нормально работающими OSD и даже может "подвешивать" их, разделение ресурсов на аппаратном уровне способно помогать в подобной ситуации.}

{Прим. пер.: приведём для справки:
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ТБ диска. Вам следует принимать такое решение разумно, с тем, чтобы оперативная память не стала узким местом в производительности вашего кластера.

[Замечание]
Замечание

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

[Совет]
Совет переводчика

{Для увеличения пропускной способности обмена ЦПУ и оперативной памяти современные системы применяют более одного канала памяти на разъём процессора. Серверы с процессорами Intel® Xeon® E5-2600 v2 использовали, как правило, 3 канала памяти, а процессоры Intel® Xeon® E5-2600 v3 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 применяет две раздельные сетевые среды: одну для сетевой среды кластера (внутренняя сеть) и другую для сетевой среды клиентов (внешняя сеть); обе эти сетевые среды должны быть физически разделены прямо начиная с вашего сервера вплоть до сетевого коммутатора и всё в промежутке, как показано на следующей схеме:

Рисунок 8.3. Рекомендованные две сетевые среды 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

Наименование
Число основных портов
/портов расширения
Общая производ. коммутации
/производ. передачи
Рекоменду- емая цена

Важно: см. сноску ¹

Allied Telesis AT-DC2552XS/L3

48x SFP+ 10GbE

4x QSFP+ 40GbE

1.28Tbps

952.32 Mpps

$16 000¹

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 000¹

Dell S6000-ON

96x SFP+ 10GbE

8x QSFP+ 40GbE

/ 32x QSFP+ 40GbE

1.44Tbps

1 080 Mpps

?¹

Dell S4048-ON

48x SFP+ 10GbE

6x QSFP+ 40GbE

1.44Tbps

1 080 Mpps

?¹

Dell N4064F

48x SFP+ 10GbE

4x QSFP+ 40GbE

1.28Tbps

952 Mpps

$15 000¹

Dell N4032F

24x SFP+ 10GbE

2x QSFP+ 40GbE

0.64Tbps

476 Mpps

$9 900¹

Dlink DXS-1210-12SC

10x SFP+ 10GbE + 2x Base-T/SFP+ 10GbE

0.24Tbps

178.56 Mpps

$1 500¹

Edge-Core AS5610-52X (ONIE) WhiteBox

48x 10GbE SFP+

4x 40GbE QSFP+

1.28 Tbps

960 Mpps

$5 100¹

Edge-Core AS6701-32X (ONIE) WhiteBox

20x 40GbE SFP+

(+ 12x 40GbE через слоты расширения)

2.56 Tbps

1.92 Bpps

$7 900¹

Huawei CE6851-48S6Q-HI

48*10GbE SFP+

6*40GbE QSFP+

1.44Tbps

1 080Mpps

$16 000¹

Huawei S6720-54C-EI-48S-AC

48*10GbE SFP+/SFP

2*40GbE QSFP+

2.56Tbps

1 080Mpps

$16 000¹

Huawei S6720-30C-EI-24S-AC

24*10GbE SFP+/SFP

2*40GbE QSFP+

2.56Tbps

720Mpps

$12 800¹

Huawei CE7850-32Q-EI

32*40GbE QSFP+

-

2.56Tbps

1 440Mpps

$32 000¹

Huawei CE8860-4C-EI

4 слота обслуживания x(8x100GbE QSFP28/
16x 40GE QSFP+/
24x 25GE SFP28/
24x 10GE SFP+)

6.4Tbps

2 976Mpps

$40 000¹

Huawei S12804S

4 слота до 36x 40GbE (2016Q3: 100GbE)

40/80Tbps

17 280 Mpps

$69 624¹

Juniper OCX1100-48SX

48x 10GbE SFP+

6x 40GbE портов QSFP+

1.44Bbps

1 080 Mpps

$32 000¹

Juniper QFX5100-24Q

24x 40GbE QSFP+

2.56Tbps

1.44Bpps

$40 000¹

Juniper QFX5200-32С

32x40GbE QSFP+/ 28QSFP

3.2Tbps

2.44Bpps

$35 000¹

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 009¹

Mellanox SX6036F

10/20/40/56 4X IB

36x QSFP

4.032 Tbps

?

$15 373¹

Mellanox SX1024

48x 10GbE SFP+

12x/4x 40GbE QSFP+

2.0 Tbps

3 Mpps

$17 769¹ / $15 234¹

Mellanox SX1012

12x 40/56GbE SFP+ портов

2.0 Tbps

3 Bpps

$11 425¹

Mellanox SX6015F

18x QSFP+ FDR 56G

2.0 Tbps

3 Bpps

$11 995¹

Mellanox SX6005F

12x QSFP+ FDR 56G

1.3 Tbps

1.5? Bpps

$5 361¹

Mellanox SX6005T

12x QSFP+ FDR10 40G

1.3 Tbps

1.5? Bpps

$6 652¹

Mellanox SX6005T

12x QSFP+ FDR10 40G

1.3 Tbps

1.5? Bpps

$6 652¹

¹ Стоимостные оценки приводятся по прайс- листам рекомендованных производителями цен при не сопоставимых условиях и поэтому не могут служить основанием для сравнения цен различных производителей в пределах этой таблицы!
При наличии необходимости сопоставления цен различных производителей под конкретный проект обращайтесь к нашим специалистам!

Сопоставлять в пределах таблицы можно исключительно цены одного производителя!

}

{Прим. пер.: приведём таблицу оценки времён, необходимых для обмена данных объёмом в 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⁻¹⁵ - 10⁻¹⁶.}

Плотность ваших узлов 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 выполняет своё журналирование при записи в файловую систему, а затем файловая система делает свой журнал при записи на лежащие в её основе диски.

 Рекомендации Ceph и настройка производительности

В этом рецепте мы изучим некоторые параметры настройки для кластера Ceph. Такие параметры всего кластера опеределяются в вашем файле настроек кластера Ceph, следовательно, когда запускается какой-то демон Ceph, он будет соблюдать соответствующие настройки. По умолчанию именем файла настроек является файл с именем ceph.conf, который размещён в каталоге /etc/ceph. Этот файл настроек имеет раздел глобальных установок, а также некоторые разделы для каждого типа служб. При запуске каждого типа служб он применяет заданные в разделе [global] настройки, а также специфичные для определённого демона разделы. Файл настроек 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

Теперь мы обсуждаем роль каждого раздела файла настроек.

Global section: Общий раздел файла настроек вашего кластера начинается с ключевого слова [global]. Все определённые в этом разделе настройки применяются ко всем демонам в данном кластере Ceph. Ниже приводятся параметры, определяемые в разделе [global].

public network = 192.168.0.0/24

раздел Monitor section: Определённые в разделе [mon] файла настройки в разделе конфигураций применяются ко всем демонам монитора Ceph в вашем кластере. Определённые в этом разделе параметры переопределяются параметрами, определёнными в разделе [global]. Далее приводится пример параметров, обычно определяемых в вашем разделе [mon].

mon initial members = ceph-mon1

Раздел OSD: Настройки, определяемые в разделе [osd] применяются ко всем демонам OSD в вашем кластере OSD. Определяемые в этом разделе настройки аналогичны установкам, перезаписывающим аналогичные настройки, определённые в разделе в разделе [global]. Далее приводится пример установок в данном разделе:

osd mkfs type = xfs

Раздел MDS: Настройки, определяемые в разделе [mds] применяются ко всем демонам MDS в вашем кластере Ceph. Определяемые в этом разделе настройки переопределяют аналогичные настройки, определённые в разделе в разделе [global]. Далее приводится пример установок в данном разделе:

mds cache size = 250000

Раздел Client: Настройки, определяемые в разделе [client] применяются ко всем вашим клиентам Ceph. Определяемые в этом разделе настройки переопределяют аналогичные настройки, определённые в разделе в разделе [global]. Далее приводится пример установок в данном разделе:

rbd cache size = 67108864

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

  Глобальная настройка кластера

Общие параметры должны быть определены в разделе [global] вашего файла настроек кластера Ceph:

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

Общедоступная сетевая среда: для определения общедоступной сетевой среды применяется такой синтаксис: public network = {public network / netmask}:

public network = 192.168.100.0/24

Сетевая среда кластера: для определения общедоступной сетевой среды применяется такой синтаксис: cluster network = {cluster network / netmask}:

cluster network = 192.168.1.0/24

max open files: Если этот параметр находится на месте и кластер Ceph запускается, он устанавливает максимальное число дескрипторов открытых файлов на уровне ОС. Это предотвращает выход демонов OSD за установленные пределы для дескрипторов файлов. Значением по умолчанию для этого параметра является 0 {Прим. пер.: без ограничения}; вы можете установить его в значение 64- битного целого:

max open files = 131072

osd pool default min size: это уровень репликаций при состоянии деградации. Он устанавливает минимальное число реплик для объектов в пуле которые должны подтверждать операцию клиентов write. По умолчанию установлено значение 0 {Прим. пер.: все}:

osd pool default min size = 1

osd pool default pg и osd pool default pgp: Убедитесь что ваш кластер реалистичное число групп размещения. Рекомендуемое значение групп размещения на OSD равно 100. Для вычисления числа групп размещений применяйте следующую формулу: (Total number of OSD * 100)/number of replicas.

Для варианта с 10 OSD при 3 репликах значение для PG должно быть равно (10*100)/3 = 333:

osd pool default pg num = 128
osd pool default pgp num = 128

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

osd pool default min size: Это значение уровня репликаций в деградировавшем состоянии, которое должно быть установлено в значение ниже чем osd pool default size. Оно устанавливает минимальное число реплик для объектов пула и тем самым сможет подтверждать операции write даже при деградации кластера. Если текущее значение минимального размера не соответствует установленному значению, Ceph не будет подтверждать write клиенту:

osd pool default min size = 1

osd pool default crush rule: Набор правил CRUSH по умолчанию для применения при создании пула:

osd pool default crush rule = 0

Запрет ведения журналов в памяти: Каждая подсистема имеет уровень ведения журналов для выдаваемых ею регистрационных записей, и они ведутся в оперативной памяти. Мы можем устанавливать различные значения для каждой из этих подсистем устанавливая уровень файла журнала и уровень памяти для отладочного ведения журналов по шкале от 1 до 20, где 1 это краткий (terse), а 20 - подробный (verbose). Первой установкой является уровень журнала, а второй - уровень памяти. Вы можете разделять их прямым слешем (/): debug_<subsystem> = <log-level>/<memory-level>.

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

debug_lockdep = 0/0
debug_context = 0/0
debug_crush = 0/0
debug_buffer = 0/0
debug_timer = 0/0
debug_filer = 0/0
debug_objecter = 0/0
debug_rados = 0/0
debug_rbd = 0/0
debug_journaler = 0/0
debug_objectcatcher = 0/0
debug_client = 0/0
debug_osd = 0/0
debug_optracker = 0/0
debug_objclass = 0/0
debug_filestore = 0/0
debug_journal = 0/0
debug_ms = 0/0
debug_monc = 0/0
debug_tp = 0/0
debug_auth = 0/0
debug_finisher = 0/0
debug_heartbeatmap = 0/0
debug_perfcounter = 0/0
debug_asok = 0/0
debug_throttle = 0/0
debug_mon = 0/0
debug_paxos = 0/0
debug_rgw = 0/0

  Настройка монитора

Настройка параметров монитора должна выполняться в разделе [mon] вашего файла настройки кластера Ceph:

mon osd down out interval: Определяет число секунд, которое Ceph ожидает прежде чем пометить OSD Ceph как "down" и "out" если они не отвечают. Этот параметр понадобится когда ваши узлы OSD претерпят аварию и перезагрузятся самостоятельно или после некоторого краткосрочного сбоя в сетевой среде. Вы не захотите чтобы ваш кластер приступал к перебалансировке сразу при возникновении проблемы, а скорее подождёте несколько минут и посмотрите не исправится ли эта проблема:

mon_osd_down_out_interval = 600

mon allow pool delete: Во избежание случайного удаления пула Ceph установите этот параметр в значение false. Это может быть полезно если у вас много администраторов управляющих кластером Ceph и вы не хотите принимать никакие риски для данных клиента:

mon_allow_pool_delete = false

mon osd min down reporters: OSD демон Ceph может сообщать MON о своих одноранговых OSD в случае их отключения; по умолчанию это значение равно 1. При помощи этого параметра вы можете изменять минимальное число демонов OSD Ceph необходимое для генерации отчёта об отключении OSD Ceph монитору Ceph. В большом кластере рекомендуется иметь это значение выше установленного по умолчанию; значение 3 должно быть приемлемым:

mon_osd_min_down_reporters = 3

  Настройка OSD

В этом рецепте мы дадим представление об общей настройке параметров OSD, которые должны определяться в разделе [osd] вашего файла настройки кластера Ceph:

Общие установки OSD

Следующие настройки позволяют демону OSD Ceph определять тип файловой системы, параметры монтирования, а также некоторые другие полезные установки:

osd mkfs options xfs: При создании OSD Ceph применит эти параметры xfs для создания своей файловой системы OSD:

osd_mkfs_options_xfs = "-f -i size=2048"

osd mount options xfs: Предоставляет параметры монтирования файловой системы xfs для OSD. Когда Ceph монтирует некое OSD, она будет использовать следующие параметры для монтирования файловой системы OSD:

osd_mount_options_xfs = "rw,noatime,inode64,logbufs=8,logbsize=256k,delaylog,allocsize=4M"

osd max write size: Максимальный размер данных в мегабайтах, которые OSD может записывать за раз:

osd_max_write_size = 256

osd client message size cap: Наибольшее сообщение клиентских данных в байтах, допускаемое в оперативной памяти:

osd_client_message_size_cap = 1073741824

osd map dedup: Удалять дублирующиеся записи в карте OSD:

osd_map_dedup = true

osd op threads: Число потоков для обслуживания работы демона OSD Ceph. Установка значения в 0 запрещает его. Увеличение данного значения может увеличить скорость обработки запросов:

osd_op_threads = 16

osd disk threads: Число потоков дисков которые применяются для выполнения фоновой работы интенсивного дискового обмена такого как очистка (scrubbing) и подрезка снимка (snap trimming):

osd_disk_threads = 1

osd disk thread ioprio class: Применяется совместно с osd_disk_thread_ioprio_priority. Эта регулировка может изменять класс расписаний вашего ввода/ вывода дискового потока и может работать только с планировщиками CFQ. Возможными значениями являются idle, be или rt:

idle: Ваши дисковые потоки будут иметь более низкий приоритет чем прочие потоки в ваших OSD. Это полезно когда вы хотите замедлить свою очистку в некотором OSD, который занят обработкой клиентских запросов.

be: Дисковые потоки имеют тот же приоритет, что и прочие потоки в этом OSD.

rt: Дисковые потоки будут иметь больший приоритет чем все прочие потоки. Это полезно когда очень нужна очистка и она может иметь приоритет за счёт работы клиента.

osd_disk_thread_ioprio_class = idle

osd disk thread ioprio priority: Применяется совместно с osd_disk_thread_ioprio_class. Эта регулировка может изменять приоритет вашего планировщика ввода/ вывода дискового потока от 0 (наивысший) до 7 (наинизший). Если все OSD на данном хосте находятся в классе idle и соперничают за ввод/ вывод и не выполняют много операций, этот параметр может быть применён для замедления приоритета потока диска одного OSD до 7, таким образом, что другой OSD с приоритетом 0 может выполнить очистку быстрее. Как и osd_disk_thread_ioprio_class, это также работает только с планировщиком CFQ ядра Linux.

osd_disk_thread_ioprio_priority = 0

Установки журнала OSD

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

osd journal size: Значение Ceph этого параметра по умолчанию равно 0; вам следует применять параметр osd_journal_size для установки размера журнала. Размер журнала должен быть по крайней мере удвоенным произведением ожидаемой скорости диска и максимального интервала сохранения файлов. Если вы используете журналы SSD, обычно хорошо создавать журналы более 10ГБ и увеличивать минимальный/ максимальный интервал синхронизации сохранения файлов:

osd_journal_size = 20480

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

journal dio: Разрешение операций прямого ввода/ вывода в журнал. Требует установления в значение true параметра journal block align:

journal_dio = true

journal aio: Разрешает применение libaio для асинхронной записи в журнал. Требует установления journal dio в значение true:

journal_aio = true

journal block align: Блочно выравнивает операции write. Требуется для dio и aio.

Установки сохранения файлов OSD

Существует несколько установок сохранения файлов, которые могут быть настроены для ваших демонов OSD Ceph:

filestore merge threshold: Разрешает применение libaio для асинхронной записи в в ваш журнал. Требует чтобы journal dio был установлен в значение true:

filestore_merge_threshold = 40

filestore split multiple: Максимальное число файлов в подкаталоге перед расщеплением на два дочерних каталога:

filestore_split_multiple = 8

filestore op threads: Число потоков операций файловой системы которые выполняются одновременно:

filestore_op_threads = 32

filestore xattr use omap: Применяет карту объектов для XATTRS (расширенных атрибутов). Требует установки в значение true для файловой системы ext4:

filestore_xattr_use_omap = true

filestore sync interval: Чтобы создать непротиворечивую точку фиксации, сохранение файлов требует заморозить операции write и выполнить операцию syncfs(), которая синхронизирует данные журнала с данными раздела и тем самым освободит этот журнал. Более частое выполнение операций синхронизации уменьшает объём данных, сохраняемых в журнале. В этом случае журнал становится недоиспользованным. Настройка на менее частые синхронизации позволяет файловой системе лучше объединять малые записи и мы можем получить улучшение производительности. Следующие параметры определяют минимальный и максимальный периоды между двумя синхронизациями:

filestore_min_sync_interval = 10
filestore_max_sync_interval = 15

filestore queue max ops: Максимальное число операций, которое сохранений файлов может принять перед блокированием новых операций для их присоединения к очереди:

filestore_queue_max_ops = 2500

filestore queue max bytes: Максимальное число байт в одной операции:

filestore_queue_max_bytes = 10485760

filestore queue committing max ops: Максимальное число операций, которое может фиксировать сохранение файлов:

filestore_queue_committing_max_ops = 5000

filestore queue committing max bytes: Максимальное число байт, которое может фиксировать сохранение файлов:

filestore_queue_committing_max_bytes = 10485760000

Установки восстановления OSD

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

osd recovery max active: Число активных запросов восстановления на OSD на определённый момент времени:

osd_recovery_max_active = 1

osd recovery max single start: Применяется совместно с osd_recovery_max_active. Чтобы понять механизм, предположим, что osd_recovery_max_single_start установлено в значение 1 , а osd_recovery_max_active равно 3. В данном случае это означает, что OSD запустит максимально одну операцию восстановления за раз, в то время, когда активны в сумме три операции:

osd_recovery_max_single_start = 1

osd recovery op priority: Установка приоритета для операции восстановления. Чем ниже число,тем выше приоритет восстановления:

osd_recovery_op_priority = 50

osd recovery max chunk: Максимальный размер порции восстановления данных в байтах:

osd_recovery_max_chunk = 1048576

osd recovery threads: Число потоков, необходимое для восстановления данных:

osd_recovery_threads = 1

Установки заполнения OSD

Настройки наполнения OSD позволяют устанавливать операции заполнения на более низкую приоритетность чем read и write .

osd max backfills: Максимальное число заполнений разрешённое к или от одного OSD:

osd_max_backfills = 2

osd backfill scan min: Минимальное число объектов на сканирование заполнения:

osd_backfill_scan_min = 8

osd backfill scan max: Максимальное число объектов на сканирование заполнения:

osd_backfill_scan_max = 64

Установки очистки OSD

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

osd max scrubs: Максимальное число одновременных операций очистки для одного демона OSD Ceph:

osd_max_scrubs = 1

osd scrub sleep: Время в секундах которое очистка выжидает между двумя последовательными чистками:

osd_scrub_sleep = .1

osd scrub chunk min: Минимальное число фрагментов данных с которыми OSD должно выполнять:

osd_scrub_chunk_min = 1

osd scrub chunk max: Максимальное число фрагментов данных с которыми OSD должно выполнять очистку:

osd_scrub_chunk_max = 5

osd deep scrub stride: Размер read в байтах при выполнении глубокой очистки:

osd_deep_scrub_stride = 1048576

osd scrub begin hour: Самый ранний час, когда очистка может быть начата. Применяется совмесно с osd_scrub_end_hour для определения временного окна очистки:

osd_scrub_begin_hour = 19

osd scrub end hour: Самый поздний час, когда очистка может выполняться. Работает совмесно с osd_scrub_begin_hour для определения временного окна очистки:

osd_scrub_end_hour = 7

Настройка клиента

Параметры настройки клиента должны быть определены в разделе [client] вашего файла настроек Ceph. Обычно этот раздел [client] также должен присутствовать в файле настроек Ceph, размещённом на узле клиента:

rbd cache: Разрешает кэширование для RADOS Block Device (RBD):

rbd_cache = true

rbd cache writethrough until flush: Запускается в режиме write-through и переключается на writeback после принятия первого запроса на сброс:

rbd_cache_writethrough_until_flush = true

rbd concurrent management ops: Число одновременных операций управления которые могут выполняться в rbd:

rbd_concurrent_management_ops = 10

rbd cache size: Размер кэша rbd в байтах:

rbd_cache_size = 67108864 #64M

rbd cache max dirty: Предел в байтах, при котором кэш должен переключаться на writeback. Должен быть меньше чем rbd_cache_size:

rbd_cache_max_dirty = 50331648 #48M

rbd cache target dirty: Изменение получателя перед тем, как кэш начнёт записывать данные в лежащее в основе хранилище:

rbd_cache_target_dirty = 33554432 #32M

rbd cache max dirty age: Число секунд, которое изменённые данные могут находиться в кэше перед запуском writeback:

rbd_cache_max_dirty_age = 2

rbd default format: Применяет второй формат rbd, который поддерживается librbd и ядром Linux начиная с версии 3.11. Добавляет поддержку для клонирования и более просто расширяется, допуская больше функциональности в будущем:

rbd_default_format = 2

Настройка операционной системы

В предыдущих рецептах мы рассматривали параметры настройки для Ceph MON, OSD и клиентов. В данном рецепте мы рассмотрим ряд общих параметров настройки, которые могут быть применены к операционной системе.

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

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

file max: Максимальное число открытых файлов в системе Linux. Обычно неплохо иметь большее значение этого параметра:

# echo 26234859 > /proc/sys/fs/file-max

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

Фреймы Jumbo должны быть разрешены на хосте а также стороне коммутатора сетевой среды, в противном случае несоответствие в размере MTU приведёт к потере пакетов. Для разрешения фреймов jumbo в вашем интерфейсе eth0 выполните следующую команду:

# ifconfig eth0 mtu 9000

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

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

Давайте предположим, что диск vda является RBD, который смонтирован на узле клиента. Воспользуйтесь следующей командой для проверки его значения read_ahead, которое является установленным по умолчанию в большинстве случаев:

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

Чтобы установить read_ahead в большее значение, то есть 8МБ для RBD vda, выполните следующую команду:

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

Настройка read_ahead применяется на клиентах Ceph которые используют смонтированные RBD. Для получения повышения производительности read вы можете установить его на несколько МБ, в зависимости от ваших аппаратных средств, причём на всех устройствах RBD.

Virtual memory: Из-за сильно загруженного профиля ввода/ вывода применение подкачки может повлечь в целом к получению недоступности сервера. Для высоких рабочих нагрузок ввода/ выода рекомендуется более низкое значение swappiness. Установите vm.swappiness в ноль в /etc/sysctl.conf для предотвращения подобного:

echo quot;vm.swappiness=0" >> /etc/sysctl.conf

min_free_kbytes: Определяет минимальное число килобайт оставляемых свободными в файловой системе. Вы можете сохранить от 1 до 3% общей системной памяти свободной применив min_free_kbytes с помощью выполнения следующей команды:

# echo 262144 > /proc/sys/vm/min_free_kbyt

I/O Scheduler: Linux предоставляет нам возможность выбора планировщика ввода/ вывода и он также может быть изменён без перезагрузки. Он предоставляет три параметра для планировщиков ввода/ вывода, а именно:

Deadline: Планировщик ввода/ вывода Deadline заменяет CFQ как применяемый по умолчанию в Red Hat Enterprise Linux 7 и его производных, а также в Ubuntu Trusty. Планировщик Deadline предпочитает чтение перед записью посредством применения отдельных очередей ввода/ вывода для каждого. Этот планировщик удобен для большинства вариантов применения, однако в особенности для тех, при которых операции read происходят чаще операций write. Выстроенные в очередь запросы на ввод/ вывод сортируются в пакеты read и write а затем планируются для выполнения в порядке возрастания LBA. Пакеты read имеют преимущество перед пакетами write по умолчанию, поскольку приложения более вероятно блокируют ввод/ вывод read. Для рабочих нагрузок OSD Ceph планировщик ввода вывода Deadline выглядит многообещающим.

CFQ: Планировщик полностью справедливых очередей (CFQ, Completely Fair Queuing) был планировщиком по умолчанию в Red Hat Enterprise Linux (4, 5 и 6) и его производных. Планировщик по умолчанию применяется только к устройствам, определяемым как диски SATA. Планировщик CFQ делит процессы натри различных класса: реального времени (real time), наилучших усилий (best efforts) и незанятых (idle). Процессы в классе реального времени всегда выполняются до процессов класса наилучших усилий, которые, в свою очередь, всегда выполняются до процессов класса незанятых. Это означает, что процессы класса реального времени могут заморозить время ЦПУ и для процессов наилучших усилий, и для незанятых процессов. По умолчанию процессы назначаются в класс наилучших усилий.

Noop: Планировщик Noop реализует алгоритм простейшего планирования первый- пришёл- первый- выполнен (FIFO, first-in first-out). Запросы объединяются в общий блок уровня простым кэшем последнего попадания. Он может быть наилучшим планировщиком для систем с ограниченными возможностями ЦПУ, использующими быстрые хранилища. Для SSD планировщик ввода/ вывода Noop может уменьшить латентность ввода/ вывода и увеличить пропускную способность, а также исключить затраты ЦПУ на переупорядочение запросов ввода/ вывода. Этот планировщик обычно хорошо работает с SSD, виртуальными машинами и даже с платами NVMe. Таким образом, планировщик ввода/ вывода Noop может быть хорошим выбором для дисков SSD, применяемых для журналов SSD.

Выполните следующую команду для определения планировщика ввода/ вывода дискового устройства sda по умолчанию. Планировщик по умолчанию должен быть заключён в []:

# cat /sys/block/sda/queue/scheduler

Измените планировщика ввода/ вывода дискового устройства sda по умолчанию на Deadline:

# echo deadline > /sys/block/sda/queue/scheduler

Измените планировщика ввода/ вывода дискового устройства sda по умолчанию на Noop:

# echo noop > /sys/block/sda/queue/scheduler

[Замечание]
Замечание

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

I/O Scheduler queue: Размер очереди по умолчанию установлен в значение 128. Очередь планировщика сортируется и записывается с целью оптимизации последовательного ввода/ вывода и уменьшения времени позиционирования. Изменение глубины очереди до 1024 может увеличить соотношение выполняемого дисками последовательного ввода/ вывода и улучшить общую пропускную способность.

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

# cat /sys/block/sda/queue/nr_requests

Для увеличения глубины планирования до 1024 примените:

# echo 1024 > /sys/block/sda/queue/nr_requests

 Удаляющее кодирование 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 поддерживает следующие модули:

 Jerasure erasure code plugin: Встраиваемый модуль Jerasure является наиболее общим и гибким. Он также является применяемым по умолчанию для пула удаляющего кодирования Ceph. Встраиваемый модуль Jerasure инкапсулирует библиотеку Jerasure. Jerasure применяет технику кода Рида Соломона. Следующая схема иллюстрирует Jerasure Code (3, 2). Как уже объяснялось, вначале данные делятся на три порции и добавляются две вычисляемые (coded) порции, а в конце концов они сохраняются в своей уникальной зоне отказа (failure zone) вашего кластера Ceph:

Рисунок 8.15. Jerasure erasure code:

Применяя встраиваемый модуль Jerasure, при сохранении удаляюще кодированного объекта во множестве OSD, восстановление из одного OSD требует чтения из всех остальных. Например, если Jerasure настроен с k = 3 и m = 2, потеря одного OSD потребует чтения из пяти OSD для восстановления, что не очень эффективно в процессе регенерации.

 Locally repairable erasure code plugin: Поскольку удаляющее кодирование Jerasure (Рида Соломона) было не эффективно для восстановления, оно было улучшено методом локальных вычислений, так что новый метод называется Locally repairable erasure code (LRC). Встраиваемый модуль локального восстанавливающего удаляющего кодирования создаёт локально вычисляемые порции, которые способны восстанавливать применяя меньше OSD, что делает его эффективным для восстановления.

Для его лучшего понимания давайте предположим, что мы настроили LRC с k = 8, m = 4 и l = 4 (locality, близость), он создаёт дополнительные вычисляемые порции для всех четырёх OSD. Когда утрачивается отдельное OSD, может быть восстановлено только четыре OSD вместо одиннадцати, как это было в случае с Jerasure.

Рисунок 8.16. LRC:

Локальные восстанавливающие коды спроектированы для уменьшения вашей полосы пропускания при восстановлении в случае утраты отдельного OSD. Как было показано выше, локально вычисляемая порция (L) генерируется длякаждых четырёх порций данных (K). Когда теряется K3, вместо восстановления всех [(K+M)-K3] порций, то есть 11 фрагментов, при использовании Локального восстанавливающего кода будет достаточно провести восстановление из порций K1, K2, K4 и L1.

 Shingled erasure code plugin: Локальные восстанавливающие коды оптимизированы для одиночных отказов OSD. При множественных отказах OSD накладные расходы на восстановление при LRC становятся больше, так как они не имеют глобальных вычислений (global parity, M) для восстановления. Давайте ещё раз рассмотрим предыдущий сценарий и предположим, что утрачено множество порций данных, K3 и K4. Для восстановления потерянных порций с применением LRC необходимо проводить восстановление из K1, K2, L1 (ваша локально вычисляемая порция) и M1 (ваша глобально вычисляемая порция). Таким образом, LRC включает в себя накладные расходы с множеством отказов дисков.

Для решения этой проблемы был предложен SHEC (Shingled Erasure Code). Встраиваемый модуль SHEC инкапсулирует множество библиотек SHEC и позволяет Ceph восстанавливать данные более эффективно чем Jerasure и LRC. Цель SHEC состоит в эффективной обработке множественных отказов дисков. Применяя этот метод, диапазон вычислений для локальных кодов был смещён и вычисляемые коды перекрывают друг друга (как черепицы или дранки на крыше), предоставляя достаточную живучесть (durability).

Давайте рассмотрим это на примере, SHEC (10,6,5), где k = 10 (порции данных), m = 6 (вычисляемые порции), а l = 5 (диапазон вычислений, locality). В этом случае схема представления SHEC выглядит следующим образом:

Рисунок 8.17. SHEC (10,6,5)

Эффективность восстановления является одной из самых выдающихся функциональностей SHEC. Он минимизирует количество чтений данных с диска в процессе восстановления. Если утрачены порции K6 и K9, SHEEC воспользуется для восстановления вычисляемыми (parity) порциями M3 и M4, а также порциями данных K5, K7,K8 и K10. Это показано на следующей схеме:

Рисунок 8.18. Процесс восстановления SHEC

При множественных отказах дисков, ожидается, что SHEC будет проводить восстановление более эффективно чем прочие методы. Время восстановления SHEC было на 18.6% быстрее чем в случае применения кода Соломона при двух отказах дисков. {Прим. пер.: подробнее см. наш перевод статьи авторов метода}

 ISA-I erasure code plugin: Встраиваемый модуль Intelligent Storage Acceleration (ISA, интеллектуального ускорения хранилищ) инкапсулирует библиотеку ISA. ISA-I был оптимизирован для платформ Intel с применением специфичных для платформ Intel инструкций и, тем самым, работает исключительно на архитектурах Intel. ISA может применяться водной из двух форм Рида Соломона, а именно, Вандермонда или Коши.

 Создание пула с удаляющим кодированием

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

  Как это сделать...

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

Создайте профиль удаляющего кодирования:

# 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

	[root@ceph-node1 ~]# ceph osd erasure-code-profile set EC-profile rulesetfailure-domain=osd k=3 m=2
	[root@ceph-node1 ~]# ceph osd erasure-code-profile ls
	EC-profile
	default
	[root@ceph-node1 ~]# ceph osd erasure-code-profile get EC-profile
	directory=/usr/1ib64/ceph/erasure-code
	k=3
	m=2
	plugin=jerasure
	rulesetfailure-domain=osd
	technique=reed_sol_van
	[root@ceph-node1 ~]#

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

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

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

# ceph osd dump | grep -i EC-pool

	[root@ceph-node1 ~]# ceph osd pool create EC-pool 16 16 erasure EC-profile
	pool 'EC-pool' created
	[root@ceph-node1 ~]# ceph osd dump | grep EC-pool
	pool 47 'EC-pool' erasure size 5 min_size 3 crush_ruleset 3 object_hash rjenkins pg_num 16 pgp_num 16 last_change 4504 flags hashpspool stripe_width 4128
	[root@ceph-node1 ~]#

Давайте добавим какие- нибудь данные в только что созданный пул Ceph. Для этого мы создадим фиктивный файл, hello.txt, и добавим этот файл в пул EC-pool.

	[root@ceph-node1 ~]# echo "Hello Ceph" >> hello.txt
	[root@ceph-node1 ~]# cat hello.txt
	Hello Ceph
	[root@ceph-node1 ~]# rados -p EC-pool ls
	[root@ceph-node1 ~]# rados -p EC-pool put objectl hello.txt
	[root@ceph-node1 ~]# rados -p EC-pool ls
	object1
	[root@ceph-node1 ~]#

Для проверки правильной работы пула удаляющего кодирования мы проконтролируем карту OSD для EC-pool и object1.

	[root@ceph-node1 ~]# ceph osd map EC-pool object1
	osdmap e4601 pool 'EC-pool' (47) object 'objectl' -> pg 47.bac5debc (47.c) -> up ([5,3,2,8,0], p5) acting ([5,3,2,8,0], p5)
	[root@ceph-node1 ~]#

Если вы изучите приведённый выше вывод, вы отметите, что object1 сохранён в группе размещения 47.c, которая в свою очередь хранится в EC-pool. Вы также отметите, что группа размещения хранится в пяти OSD, а именно, в osd.5, osd.3, osd.2, osd.8 и osd.0. Если вы вернётесь к 1 шагу, вы вспомните, что мы создали наш профиль удаляющего кодирования (3, 2). Это объясняет почему object1 хранится в пяти OSD.

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

Теперь мы попытаемся сломать osd.5 и osd.3 один за другим.

[Замечание]
Замечание

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

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

# ssh ceph-node2 service ceph stop osd.5
# ceph osd map EC-pool object1

	[root@ceph-node1 ~]# ssh ceph-node2 service ceph stop osd.5
	=== osd.5 ===
	Stopping Ceph osd.5 on ceph-node2...kill 23469...kill 23469...done
	[root@ceph-node1 ~]# ceph osd map EC-pool object1
	osdmap e4603 pool 'EC-pool' (47) object 'objectl' -> pg 47.bac5debc (47.c) -> up ([2147483647,3,2,8,0], p3) acting ([2147483647,3,2,8,0], p3)
	[root@ceph-node1 ~]#

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

# ssh ceph-node2 service ceph stop osd.3
# ceph osd map EC-pool object1

	[rootcdceph-node1 ~]# ssh ceph-node2 service ceph stop osd.3
	=== osd.3 ===
	Stopping Ceph osd.3 on ceph-node2...kill 22954...kill 22954...done
	[root@ceph-node1 ~]# ceph osd map EC-pool object1
	osdmap e4605 pool 'EC-pool' (47) object 'objectl' -> pg 47.bac5debc (47.c) -> up ([2147483647,2147483647,2,8,0], p2) acting ([2147483647,214748 3647,2,8,0], p2)
	[root@ceph-node1 ~]#

Теперь EC-pool работает на трёх OSD, что является требуемым минимумом для такой сборки пула erasure. Как уже обсуждалось ранее, EC-pool потребует любые три порции для чтения данных. Теперь мы имеем оставшимися только три порции, а именно osd.2, osd.8 и osd.0 и мы всё ещё имеем доступ к данным. Давайте проверим это прочитав наши данные:

# rados -p EC-pool ls
# rados -p EC-pool get object1 /tmp/object1
# cat /tmp/object1

	[root@ceph-node1 ~]# rados -p EC-pool is object1
	[root@ceph-node1 ~]# rados -p EC-pool get object1 /tmp/object1
	[root@ceph-node1 ~]# cat /tmp/object1
	Hello Ceph
	[root@ceph-node1 ~]#

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

В последних двух обсуждавшихся шагах мы намеренно разрушили osd.5 и osd.3. После всего этого Ceph запустит восстановление и регенерирует утраченные порции на различные OSD. Когда операция восстановления завершится, нам следует проверить нашу карту OSD для EC-pool и object1. Мы будем поражены увидев свои новые идентификаторы OSD, например, osd.7 и osd.4. И, таким образом, пул erasure становится жизнеспособным без административного вмешательства.

	[root@ceph-node1 ~]# ceph osd stat
	     osdmap e4645: 9 osds: 7 up, 7 in; 336 remapped pgs
	[root@ceph-node1 ~]# ceph osd map EC-pool object1
	osdmap e4645 pool 'EC-pool' (47) object 'objectl' -> pg 47.bac5debc (47.c) -> up ([7,4,2,8,0], p7) acting ([7,4,2,8,0], p7)
	[root@ceph-node1 ~]#

 Многоуровневое кэширование Ceph

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

Рисунок 8.19. Многоуровневое кэширование 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 и создадим пул кэша поверх них, как показано на следующей схеме:

Рисунок 8.20. Построение многоуровневого кэширования

Давайте проверим нашу компоновку 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 и установите crush_ruleset в значение 1, таким образом ваш новый пул будет создан на дисках SSD:

# ceph osd pool create cache-pool 16 16
# ceph osd pool set cache-pool crush_ruleset 1

	[root@ceph-node1 ~]# ceph osd pool create cache-pool 16 16
	pool 'cache-pool' created
	[root@ceph-node1 ~]# ceph osd pool set cache-pool crush_ruleset 1
	set pool 48 crush_ruleset to 1
	[root@ceph-node1 ~]#

Убедитесь что ваш пул создан правильно, что означает, что он всегда должен сохранять все свои объекты в 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; он должен храниться в osd.0, osd.3 и osd.6:

# ceph osd map cache-pool object1

Наконец, удалите объект:

# rados -p cache-pool rm object1

	[root@ceph-node1 ~]# rados -p cache-pool ls
	[root@ceph-node1 ~]# rados -p cache-pool put object1 /etc/hosts
	[root@ceph-node1 ~]# rados -p cache-pool ls
	object1
	[root@ceph-node1 ~]# ceph osd map cache-pool object1
	osdmap e4767 pool 'cache-pool' (48) object 'objectl' -> pg 48.bac5debc (48.c) -> up ([3,6,0], p3) acting ([3,6,0], p3)
	[root@ceph-node1 ~]# rados -p cache-pool rm object1
	[root@ceph-node1 ~]# rados -p cache-pool is
	[root@ceph-node1 ~]#

  Смотрите также...

Также смотрите Создание уровня кэша в этой главе.

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

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

Рисунок 8.21. Многоуровневое кэширование

writeback EC-pool

  Как это сделать...

Создайте уровень кэша, который будет ассоциировать пулы хранения с пулами кэша. Синтаксис таков: ceph osd tier add <storage_pool> <cache_pool>:

# ceph osd tier add EC-pool cache-pool

Установите режим кэширования либо как writeback, либо как read-only. В нашей демонстрации мы применяем writeback, а синтаксис такой: ceph osd tier cachemode <cache_pool> writeback:

# ceph osd tier cache-mode cache-pool writeback

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

# ceph osd tier set-overlay EC-pool cache-pool

	[root@ceph-node1 ~]# ceph osd tier add EC-pool cache-pool
	pool 'cache-pool' is now (or already was) a tier of 'EC-pool'
	[root@ceph-node1 ~]# ceph osd tier cache-mode cache-pool writeback set cache-mode for pool 'cache-pool' to writeback
	[root@ceph-node1 ~]# ceph osd tier set-overlay EC-pool cache-pool
	overlay for 'EC-pool' is now (or already was) 'cache-pool'
	[root@ceph-node1 ~]#

Проверяя подробности пула, вы заметите, что EC-pool имеет tier, read_tier и write_tier установленные в значение 48, что является идентификатором пула для вашего cache-pool. Аналогично, для cache-pool установки будут: tier_of назначено на 47, а cache_mode установлен как writeback. Все эти установки подразумевают, что пул кэша настроен правильно:

# ceph osd dump | egrep -i "EC-pool|cache-pool"

	[root@ceph-node1 ~]# ceph osd dump | egrep "EC-poollcache-pool"
	pool 47 'EC-pool' erasure size 5 min_size 3 crush_ruleset 3 object_hash rjenkins pg_num 16 pgp_num 16 last_change 4770 lfor 4770 flags hashpspool tiers 48 read_tier 48 write_tier 48 stripe_width 4128
	pool 48 'cache-pool' replicated size 3 min_size 2 crush_ruleset 1 object_hash rjenkins pg_num 16 pgp_num 16 last_change 4770 flags hashpspool,incomplete clones tier of 47 cache node writeback stripe width 0
	[root@ceph-node1 ~]#

 Настройка уровня кэша

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

  Как это сделать...

Для промышленного развёртывания вам следует применять структуру данных 'bloom filters': ceph osd tier add <storage_pool> <cache_pool>:

# ceph osd pool set cache-pool hit_set_type bloom

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

# ceph osd pool set cache-pool hit_set_count 1
# ceph osd pool set cache-pool hit_set_period 300

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

# ceph osd pool set cache-pool target_max_bytes 1000000
# ceph osd pool set cache-pool target_max_objects 10000

	[root@ceph-node1 ~]# ceph osd pool set cache-pool hit_set_type bloom
	set pool 48 hit_set_type to bloom
	[root@ceph-node1 ~]# ceph osd pool set cache-pool hit_set_count 1
	set pool 48 hit_set_count to 1
	[root@ceph-node1 ~]# ceph osd pool set cache-pool hit_set_period 300
	set pool 48 hit_set_period to 300
	[root@ceph-node1 ~]# ceph osd pool set cache-pool targetmax_bytes 1000000
	set pool 48 targetmax_bytes to 1000000
	[root@ceph-node1 ~]#

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

# ceph osd pool set cache-pool cache_min_flush_age 300
# ceph osd pool set cache-pool cache_min_evict_age 300

	[root@ceph-node1 ~]# ceph osd pool set cache-pool target_max_objects 10000
	set pool 48 target_max_objects to 10000
	[root@ceph-node1 ~]# ceph osd pool set cache-pool cache_min_flush_age 300
	set pool 48 cachemin_flush_age to 300
	[root@ceph-node1 ~]# ceph osd pool set cache-pool cache_min_evict_age 300
	set pool 48 cache_min_evict_age to 300
	[root@ceph-node1 ~]#

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

# 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

	[root@ceph-node1 ~]# ceph osd pool set cache-pool cache_target_dirty_ratio .01
	set pool 48 cache_target_dirty_ratio to .01
	[root@ceph-node1 ~]# ceph osd pool set cache-pool cache_target_full_ratio .02
	set pool 48 cache_target_full_ratio to .02
	[root@ceph-node1 ~]# dd if=/dev/zero of=/tmp/file1 bs=1m count=500
	500+0 records in
	500+0 records out
	524288000 bytes (524 MB) copied, 5.81312 s, 90.2 MB/s
	[root@ceph-node1 ~]#

 Тестирование уровня кэша

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

  Как это сделать...

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

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

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

# rados -p EC-pool ls
# rados -p cache-pool ls
# date

	[root@ceph-node1 ~]# rados -p EC-pool put objectl /tmp/file1
	[root@ceph-node1 ~]# rados -p EC-pool ls
	[root@ceph-node1 ~]# rados -p cache-pool ls
	object1
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# date
	Sun Sep 14 02:14:58 EEST 2014
	[root@ceph-node1 ~]#

Через 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

	[root@ceph-node1 ~]# date
	Sun Sep 14 02:27:41 EEST 2014
	[root@ceph-node1 ~]# rados -p EC-pool ls
	object1
	[root@ceph-node1 ~]# rados -p cache-pool ls
	[root@ceph-node1 ~]#

Если вы пристальнее вглядитесь вшаги 2 и 3, вы отметите, что данные мигрировали из cache-pool в EC-pool после определённого промежутка времени, причём это абсолютно прозрачно для наших пользователей.

Глава 9. Менеджер виртуального хранения Ceph

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

Понимание архитектуры VSM

Сборка среды VSM

Подготовка к VSM

Установка VSM

Создание кластера Ceph с применением VSM

Исследование инструментальной панели VSM

Обновление кластера Ceph с применением VSM

Дорожная карта VSM

Ресурсы VSM

Содержание

9. Менеджер виртуального хранения Ceph

Введение

Понимание архитектуры VSM

Сборка среды VSM

Подготовка к VSM

Установка VSM

Создание кластера Ceph с применением VSM

Исследование инструментальной панели VSM

Обновление кластера Ceph с применением VSM

Дорожная карта VSM

Ресурсы VSM

 Введение

Virtual Storage Manager (VSM, Менеджер виртуального хранения) является программным обеспечением изначально инициированным и разработанным Intel для управления кластером Ceph; позже оно был переведено Intel в ПО с открытым исходным кодом по лицензии Apache 2.0. Ceph поставляется с инструментарием командной строки ceph-deploy для развёртывания кластера и он также предоставляет богатый CLI для управления кластером. VSM с другой стороны предоставляет веб- интерфейс чтобы упростить создание и управление кластером Ceph.Применяя VSM GUI кластера Ceph оператор может наблюдать за жизнеспособностью всего кластера, управлять аппаратными средствами кластера и ёмкостью хранения, а также подключать пулы хранения Ceph к Cinder OpenStack.

VSM разработан на Python с применением OpenStack Horizon в качестве основы для каркаса приложений. Он имеет знакомый внешний вид и интуитивное понимание OpenStack Horizon как для разработчиков программного обеспечения, так и для администраторов OpenStack. Некоторые основные функции VSM включают в себя:

Пользовательский интерфейс на веб- основе для лёгкого администрирования вашего кластера Ceph

Он лучше организовывает и управляет устройства сервера и хранения

Он служит развёртыванию кластера Ceph и его масштабированию добавляя узлы MON, OSD и MDS.

Он помогает мониторингу компонентов и ёмкости вашего кластера Ceph

Он полезен при мониторинге производительности всего кластера и индивидуального узла

Он позволяет создавать пулы удаляющего кодирования и кэширующего уровня

Он способствует в создании и подключении пулов к Cinder OpenStack

Он привносит в кластер Ceph многопользовательский интерфейс управления пользователем

[Замечание]
Замечание

В настоящее время VSM не способен управлять вашим кластером Ceph, если тот не создан им. {Прим. пер.: 29 января 2016 выпущена версия VSM 2.1, решившая эту проблему.}

 Понимание архитектуры VSM

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

  Контроллер VSM

VSM является приложением на основе веб- интерфейса, которое типично размещается на машине контроллера, которая обычно называется узлом контроллера VSM. Программное обеспечение контроллера VSM является ядром VSM, которое связывается с кластером Ceph через агентов VSM. Контроллер VSM собирает все поступающие от агентов VSM и мониторов вашего кластера Ceph данные. Для операций, подобных созданию кластера, созданию пула и тому подобных контроллер VSM отправляет инструкции агентам VSM для выполнения необходимых действий. Как показано на схеме ниже, администраторы/ операторы Ceph связываются с узлом контроллера VSM через HTTP или API и они могут применять программное обеспечение VSM. Узел контроллера VSM также связан с контроллером OpenStack для настройки OpenStack на применение Ceph. В дополнение к службе пользовательского веб- интерфейса, контроллер VSM также размещает MariaDB и RabbitMQ.

  Агент VSM

Агент VSM является процессом, который выполняется на всех узлах кластера Ceph. Задание агента VSM состоит в отправке настроек сервера, информации о жизнеспособности/ состоянии кластера, а также данных о производительности на контроллер VSM. Агент VSM использует файл манифеста сервера для идентификации узла контроллера VSM, проверки его подлинности и определения настроек сервера.

Следующая схема иллюстрирует взаимодействие различных компонентов VSM друг с другом а также со инфраструктурой OpenStack и операторами VSM:

Рисунок 9.1. Взаимодействие компонентов VSM

 Сборка среды VSM

Чтобы применять VSM вам необходимо построить кластер Ceph используя VSM. VSM не может контролировать и управлять существующим кластером Ceph. В этом рецепте мы применим Vagrant для запуска четырёх виртуальных машин с именами vsm-controller, vsm-node1, vsm-node2 и vsm-node3. Виртуальная машина vsm-controller будет работать в качестве контроллера VSM, а vsm-nodes {1,2,3} будут действовать как узлы агенты выполняющие кластер Ceph.

  Как это сделать...

Vagrantfile для запуска виртуальных машин VSM доступен в репозитории GitHub ceph-cookbook. Клонируйте этот репозиторий, если вы этого ещё не сделали:

$ git clone https://github.com/ksingh7/ceph-cookbook.git

Vagrantfile для запуска узлов VSM размещается в каталоге vsm:

$ cd vsm

Запустите виртуальные машины:

$ vagrant up vsm-controller vsm-node1 vsm-node2 vsm-node3

	teeri:vsm ksingh$ vagrant up vsm-controller vsm-node1 vsm-node2 vsm-node3
	Bringing machine 'vsm-controller' up with 'virtualbox' provider...
	Bringing machine 'vsm-node1' up with 'virtualbox' provider...
	Bringing machine 'vsm-node2' up with 'virtualbox' provider...
	Bringing machine 'vsm-node3' up with 'virtualbox' provider...

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

	teeri:vsm ksingh$ vagrant status
	Current machine states:

	vsm-node1                running (virtualbox)
	vsm-node2                running (virtualbox)
	vsm-node3                running (virtualbox)
	vsm-controller           running (virtualbox)

	This environment represents multiple VMs. The VMs are all listed
	above with their current state. For more information about a specific
	VM, run `vagrant status NAME`.

Чтобы зарегистрироваться на этих ВМ, воспользуйтесь cephuser и в качестве имени пользователя, и пароля. Для регистрации root применяйте пароль vagrant. Vagrant автоматизирует настройку сетевой среды между этими ВМ со следующими параметрами:

192.168.123.100 vsm-controller
192.168.123.101 vsm-node1
192.168.123.102 vsm-node2
192.168.123.103 vsm-node3

 Подготовка к VSM

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

Следует отметить, что применяя Vagrant мы выполнили большую часть предполётной настройки с помощью файла сценария ceph-cookbook/vsm/post-deploy.sh, имеющегося в репозитории GIT, который мы клонировали в нашем последнем рецепте. Вы можете не захотеть повторять эти четыре шага, поскольку Vagrant уже выполнил их. Мы объясняем эти шаги здесь, чтобы вы могли узнать что Vagrant выполнил в фоновом режиме.

  Как это сделать...

Создайте пользователя cephuser на всех узлах, которые будут применяться для развёртывания VSM. Для простоты мы установим пароль этого пользователя как cephuser. Вы всегда можете применять имя пользователя по своему усмотрению. Также предоставьте этому пользователю права sudo:

# useradd cephuser
# echo 'cephuser:cephuser' | chpasswd
# echo "cephuser ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

Убедитесь, что NTP настроен:

# systemctl stop ntpd
# systemctl stop ntpdate
# ntpdate 0.centos.pool.ntp.org > /dev/null 2> /dev/null
# systemctl start ntpdate
# systemctl start ntpd

Установите пакеты tree (не обязательно), git и epel:

# yum install -y tree git epel-release

Добавьте информацию о хостах в ваш файл /etc/hosts:

192.168.123.100 vsm-controller
192.168.123.101 vsm-node1
192.168.123.102 vsm-node2
192.168.123.103 vsm-node3

[Замечание]
Замечание

Это именно те шаги, которые мы автоматически выполнили с помощью Vagrant, который использовал сценарий post-deploy.sh. Если вы воспользовались предписанным GitHub ceph-cookbook, который я создал для VSM, вам не нужно выполнять эти четыре шага.

Следующие шаги должны быть выполнены на ваших узлах как это предписано:

Зарегистрируйтесь на узле vsm-controller, а также создайте и сделайте совместно доступными для использования с другими узлами VSM ключи SSH. В процессе этого шага вам следует ввести пароль для cephuser, который установлен в значение cephuser:

# ssh cephuser@192.168.123.100
$ mkdir .ssh;ssh-keygen -f .ssh/id_rsa -t rsa -N ''
$ ssh-copy-id vsm-node1
$ ssh-copy-id vsm-node2
$ ssh-copy-id vsm-node3

С помощью Vagrant мы присоединили три виртуальных диска VirtualBox к каждой vsm-nodes {1,2,3}, которые будут использоваться в качестве дисков OSD Ceph. Нам нужно вручную создать разделы на этих дисках для OSD и журнала Ceph, чтобы VSM мог применять их в Ceph. Выполните следующие команды на всех vsm-nodes {1,2,3}:

$ sudo parted /dev/sdb -- mklabel gpt
$ sudo parted -a optimal /dev/sdb -- mkpart primary 10% 100%
$ sudo parted -a optimal /dev/sdb -- mkpart primary 0 10%
$ sudo parted /dev/sdc -- mklabel gpt
$ sudo parted -a optimal /dev/sdc -- mkpart primary 10% 100%
$ sudo parted -a optimal /dev/sdc -- mkpart primary 0 10%
$ sudo parted /dev/sdd -- mklabel gpt
$ sudo parted -a optimal /dev/sdd -- mkpart primary 0 10%
$ sudo parted -a optimal /dev/sdd -- mkpart primary 10% 100%

	[cephuser@vsm-node1 ~]$ sudo parted /dev/sdb -- mklabel gpt
	Warning: The existing disk label on /dev/sdb will be destroyed and all data on this disk will be lost. Do you want to continue?
	Yes/No? yes
	Information: You may need to update /etc/fstab.
	[cephuser@vsm-node1 ~]$
	[cephuser@vsm-node1 ~]$ sudo parted -a optimal /dev/sdb mkpart primary 10% 100%
	Information: YOU may need to update /etc/fstab.

	[cephuser@vsm-node1 ~]$ sudo parted -a optimal /dev/sdb -- mkpart primary 0 10%
	Warning: The resulting partition is not properly aligned for best performance.
	Ignore/cancel? Ignore
	Information: You may need to update /etc/fstab.

	[cephuser@vsm-node1 ~]$

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

$ lsblk

Рисунок 9.2. Список блочных устройств

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

	teeri:vsm ksingh$ for i in controller nodel node2 node3 ; do vBoxmanage snapshot vsm-$i take good-state ; done
	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
	0%...10%...20%...30%...40%...50%...60%...70X...80%...90%...100%
	0%...10%...20%...30%...40%...50%...60%...70X...80%...90%...100%
	teeri:vsm ksingh$

 Установка VSM

В последнем рецепте мы выполнили все приготовления необходимые для развёртывания VSM. В этом рецепте мы изучим как автоматически развернуть VSM на все узлы.

  Как это сделать...

В данной демонстрации мы используем CentOS7 в качестве основной операционной системы; давайте загрузим репозиторий VSM для CentOS7. Зарегистрируемся на вашем узле vsm-controller в качестве cephuser и получим VSM:

$ wget https://github.com/01org/virtual-storage-manager/releases/download/v2.0.0/2.0.0-216_centos7.tar.gz

[Замечание]
Замечание

VSM также доступен для OS Ubuntu и может быть загружен с https://github.com/01org/virtual-storage-manager.

Разверните VSM:

$ tar -xvf 2.0.0-216_centos7.tar.gz
$ cd 2.0.0-216
$ ls -la

	[cephuser@vsm-controller 2.0.0-216]$ ll
	total 500
	-rw-r--r--. 1 cephuser cephuser  27471 Sep 30 09:44 CHANGELOG.md
	-rw-r--r--. 1 cephuser cephuser 124686 Sep 30 09:44 CHANGELOG.pdf
	-rwxr-xr-x. 1 cephuser cephuser     94 Sep 30 09:44 get_pass.sh
	-rw-r--r--. 1 cephuser cephuser  29959 Sep 30 09:44 INSTALL.md
	-rw-r--r--. 1 cephuser cephuser 251846 Sep 30 09:44 INSTALL.pdf
	-rw-r--r--. 1 cephuser cephuser    684 Sep 30 09:44 installrc
	-rw-r--r--. 1 cephuser cephuser  21758 Sep 30 09:44 install.sh
	-rw-r--r--. 1 cephuser cephuser    580 Sep 30 09:44 LICENSE
	drwxr-xr-x. 2 cephuser cephuser     65 Sep 30 09:44 manifest
	-rw-r--r--. 1 cephuser cephuser    320 Sep 30 09:44 NOTICE
	-rwxr-xr-x. 1 cephuser cephuser   1155 Sep 30 09:44 prov_node.sh
	-rw-r--r--. 1 cephuser cephuser   3121 Sep 30 09:44 README.md
	-rw-r--r--. 1 cephuser cephuser      3 Sep 30 09:44 RELEASE
	-rw-r--r--. 1 cephuser cephuser   1176 Sep 30 09:44 rpms.lst
	-rwxr-xr-x. 1 cephuser cephuser   1353 Sep 30 09:44 uninstall.sh
	-rw-r--r--. 1 cephuser cephuser      5 Sep 30 09:44 VERSION
	drwxr-xr-x. 3 cephuser cephuser   4096 Sep 30 09:44 vsmrepo
	[cephuser@vsm-controller 2.0.0-216]$

Установите адрес ваших узла контроллера и агента; добавьте следующие строки в файл installrc:

AGENT_ADDRESS_LIST="192.168.123.101 192.168.123.102 192.168.123.103"
CONTROLLER_ADDRESS="192.168.123.100"

Пооверьте файл installrc:

$ cat installrc | egrep -v "#|^$"

	[cephuser@vsm-controller 2.0.0-216]$ cat installrc | egrep -v "#1A$"
	AGENT_ADDRESS_LIST="192.168.123.101 192.168.123.102 192.168.123.103"
	С0NTR0LLER_ADDRESS="192.168.123.100"
	[cephuser@vsm-controller 2.0.0-216]$

В папке manifest создайте создайте каталоги использующие имена управляемых вами IP vsm-controller и vsm-nodes:

$ cd manifest
$ mkdir 192.168.123.100 192.168.123.101 192.168.123.102 192.168.123.103

Скопируйте пример файла манифеста кластера на 192.168.123.100/cluster.manifest, который является вашим узлом vsm-controller:

$ cp cluster.manifest.sample 192.168.123.100/cluster.manifest

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

$ vim 192.168.123.100/cluster.manifest

	[management_addr]
	192.168.123.0/24

	[ceph_public_addr]
	192.168.123.0/24

	[ceph_cluster_addr]
	192.168.123.0/24

Вам следует знать, что в промышленной среде вам рекомендуется иметь раздельные сетевые среды для обмена в среде управления Ceph, общедоступном Ceph и среде кластера Ceph. Применяя файл cluster.manifest, VSM может быть проинструктирован применять эти различные сети для вашего кластера Ceph:

Измените ваш файл manifest/server.manifest.sample, и сделайте следующие правки:

В раздел [vsm_controller_ip] добавьте IP вашего контроллера VSM, 192.168.123.100.

$ cp cluster.manifest.sample 192.168.123.100/cluster.manifest

Добавьте имена дисковых устройств для [sata_device] и [journal_device], как показано на следующем снимке экрана. Убедитесь, что имена sata_device и journal_device разделены пробелом.

	[7200_rpm_sata]
	#format [sata_device] [journal_device]
	/dev/sdbl /dev/sdb2
	/dev/sdcl /dev/sdc2
	/dev/sddl /dev/sdd2

[Замечание]
Замечание

Файл server.manifest предоставляет некоторые необязательные параметры настройки для различных типов дисков. В промышленных средах вам рекомендуется применять применять правильный тип на основании ваших аппаратных средств.

Если вы не используете OSD диски 10krpm_sas и журналы по дисковому пути, закомментируйте строки %osd-by-path-1% %journal-by-path-1% в вашем разделе [10krpm_sas], как это показано на следующем экранном снимке:

	[10krpm_sas]
	#format [sas_device] [journal_device]
	#%osd-by-path-l% %journal-by-path-1%
	#%osd-by-path-2% %journal-by-path-2%
	#%osd-by-path-3% %journal-by-path-3%
	#%osd-by-path-4% %journal-by-path-4%
	#%osd-by-path-5% %journal-by-path-5%
	#%osd-by-path-6% %journal-by-path-6%
	#%osd-by-path-7% %journal-by-path-7%

Когда вы внесёте правки в свой файл manifest/server.manifest.sample, проверьте все изменения:

$ cat server.manifest.sample | egrep -v "#|^$"

	[cephuser@vsm-controller manifest]$ cat server.manifest.sample | egrep -v "
	[vsm_controller_ip]
	192.168.123.100
	[role]
	storage
	monitor
	[auth_key]
	token-tenant
	[ssd]
	[7200_rpm_sata]
	/dev/sdbl /dev/sdb2
	/dev/sdcl /dev/sdc2
	/dev/sddl /dev/sdd2
	[10krpm_sas]
	[ssd_cached_7200rpm_sata]
	[ssd_cached_10krpm_sas]
	[ceohuser@vsm-controller manifest]$

Скопируйте свой файл manifest/server.manifest.sample, который мы изменили на предыдущем шаге, на всеваши узлы vsm-node, то есть, vsm-node {1,2,3}:

$ cp server.manifest.sample 192.168.123.101/server.manifest
$ cp server.manifest.sample 192.168.123.102/server.manifest
$ cp server.manifest.sample 192.168.123.103/server.manifest

Проверьте структуру каталога манифеста:

$ tree

	[cephuser@vsm-controller manifest] $ tree

	├─ 192.168.123.100
	│  └— cluster.manifest
	├─ 192.168.123.101
	│  └— server.manifest
	├─ 192.168.123.102
	│  └— server.manifest
	├─ 192.168.123.103
	│  └— server.manifest
	├─ cluster.manifest.sample
	└─ server.manifest.sample

	4 directories, 6 files
	[cephuser@vsm-controller manifest] $

Для начала установки VSM предоставьте права на выполнение для файла install.shr:

$ cd ..
$ chmod +x install.sh

Наконец, установите VSM, выполнив файл install.shr с параметрами --check-dependence-package, которые загрузят необходимые для установки VSM пакеты из https//github.com/01org/vsm-dependencies:

$ ./install.sh -u cephuser -v 2.0 --check-dependence-package

	[cephuser@vsm-controller 2.0.0-216]$ ./install.sh -u cephuser -v 2.0 --check-dependence-package
	+ echo 'Before auto deploy the vsm, please be sure that you have set the manifest
	such as manifest/192.168.100.100/server.manifest. And you have changed the file, too.'
	Before auto deploy the vsm, please be sure that you have set the manifest
	such as manifest/192.168.100.100/server.manifest. And you have changed the file, too.
	+ sleep 5
	+++ dirname ./install.sh
	++ cd .
	++ pwd
	+ TOPDIR=/home/cephuser/2.0.0-216

[Замечание]
Замечание

Установка VSM займёт несколько минут. Процесс установки может потребовать ввода пароля cephuser для узла vsm-controller. В этом случае, пожалуйста, вводите в качестве пароля cephuser.

В случае, если вы столкнётесь с какой бы то ни было ошибкой и захотите перезапустить установку VSM, рекомендуется чтобы вы очистили вашу систему перед повтором. Для очистки системы выполните файл сценария uninstall.sh.

Вы также можете пересмотреть авторскую версию установки VSM проверив файл журнала установки, расположенный в пути репозитория ceph-cookbook: ceph-cookbook/vsm/vsm_install_log.

Когда ваша установка VSM завершится, извлеките ваш пароль для своего пользователя admin выполнив get_pass.sh на узле vsm-controller:

$ ./get_pass.sh

	[cephuser@vsm-controller 2.0.0-216]$ ./get_pass.sh
	f409fc062564b9a937d1
	[cephuserCdvsm-controller 2.0.0-216]$

Наконец, зарегистрируйтесь в инструментальной панели VSM, , https://192.168.123.100/dashboard/vsm, под именем пользователя admin с паролем, извлечённым на предыдущем шаге.

Рисунок 9.3. Регистрация в инструментальной панели VSM

Стрница загрузки vsm-dashboard выглядит следующим образом:

Рисунок 9.4. vsm-dashboard

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

Рисунок 9.5. VSM мониторинг кластера

 Создание кластера Ceph с применением VSM

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

  Как это сделать...

Для создания кластера из инструментальной панели VSM, перейдите в Cluster Management | Create Cluster и затем кликните на кнопку Create Cluster:

Рисунок 9.6. Создание кластера

Выберите все узлы кликнув по флаговой кнопке, с последующими идентификаторами, и, наконец, кликните по кнопке Create Cluster:

Рисунок 9.7. Выберите узлы

Создание кластера Ceph займёт несколько мнут. VSM будет очень кратко сообщать о том, что он делает в фоновом режиме в поле состояния вашей инструментальной панели, как показано далее:

Рисунок 9.8. Очистка

После очистки он смонтирует диски как показано в поле состояния инструментальной панели на следующем экранном снимке: :

Рисунок 9.9. Монтирование

Когда развёртывание кластера Ceph завершится, VSM отобразит состояние ваших узлов как Active:

Рисунок 9.10. Изменение состояния узлов на активное

Наконец, проверьте состояние кластера из Dashboard | Cluster Status:

Рисунок 9.11. Состояние кластера

 Исследование инструментальной панели VSM

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

Dashboard: Предоставляет полное состояние вашей системы включая:

VSM Status: Предоставляет вам версию вашего VSM, время его работы, версию Ceph и тому подобное

Cluster Summary: Предоставляет состояние кластера Ceph, аналогично выводу ceph -s

OSD Summary

Monitor Summary

MDS Summary

PG Summary

Также предоставляет метрики производительности такие как IOPS, латентность, пропускная способность и использование ЦПУ для всех узлов Ceph

Server Management: включает следующее:

Manage Servers: функции описываются так:

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

Предоставляет параметры для добавления или удаления серверов, мониторов Ceph, а также запуска и останова серверов.

Рисунок 9.12. Управление серверами

Manage Devices: функции описываются так:

Предоставляет список всех OSD Ceph включая их состояние, вес, сервер размещения, а также класс хранения.

Позволяет создавать новые OSD, а также перезапускать, удалять и восстанавливать OSD.

Рисунок 9.13. Управление устройствами

Cluster Management

Этот раздел инструментальной панели VSM предоставляет определённые возможности для управления кластером Ceph:

Create Cluster

Upgrade Cluster

Manage Pools: помогает вам создавать пулы с репликациями и удаляющим кодированием, добавлять/ удалять уровень кэширования и тому подобное.

Manage Storage Group: Добавляет новые группы хранения.

Cluster Monitoring: Этот раздел инструментальной панели VSM предоставляет полный мониторинг кластера, включая все его компоненты:

Storage Group Status:

Pool Status:

OSD Status:

Monitor Status:

MDS Status:

PG Status:

RBD Status:

Рисунок 9.14. Мониторинг кластера

OpenStack Integration: Этот раздел инструментальной панели VSM позволяет нам выполнять интеграцию хранилища Ceph в OpenStack добавляя терминалы OpenStack и предоставляя пулы RBD для OpenStack.

Manage RBD Pools: предоставляет пулы для OpenStack

OpenStack Access: Добавляет терминалы OpenStack

Рисунок 9.15. Интеграция с OpenStack

VSM Management: Этот раздел инструментальной панели VSM позволяет нам управлять самой инструментальной панелью VSM:

Add/Remove User: Создаёт или удаляет пользователя и изменяет его пароль.

Settings: различные установки, относящиеся к Ceph.

Рисунок 9.16. Управление VSM

 Обновление кластера Ceph с применением VSM

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

  Как это сделать...

Перед запуском своего процесса обновления проверьте версию своего текущего кластера перейдя к VSM | Dashboard | Cluster Status. Она должна быть Ceph Firefly Version 0.80.7.

Для обновления вашего кластера перейдите к VSM | Cluster Management | Ceph Upgrade.

Обеспечьте следующие детали для обновления своего Ceph:

Package URL: http://download.ceph.com/rpm-hammer/el7/.

Key URL: по умолчанию добавляется самим VSM.

Proxy URL: в случае, когда необходим прокси интернета для доступа к нему. В нашем случае не требуется.

SSH User Name: относится к нашему имени пользователя cephuser, которого мы создали для управления VSM.

Рисунок 9.17. Детали обновления

Поскольку вы предоставили все необходимые детали для VSM, нажмите Submit, это запустит процесс обновления вашего кластера и для его завершения потребуется несколько минут. Пожалуйста, будьте терпеливы, к тому же при желании вы можете наблюдать свои журналы VSM в /var/log/vsm.

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

Рисунок 9.18. Подтверждение обновления

Чтобы удостовериться в завершении обновления, перейдите к VSM | Dashboard | Cluster Status. Вашей версией Ceph должна быть 0.94.5, что является Ceph Hammer.

Рисунок 9.19. Проверка новой версии

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

 Дорожная карта VSM

На момент написания этой книги текущей стабильной версией VSM была 2.0. Это та же версия, которая была продемонстрирована в данной главе. Благодаря лёгкости в использовании, мощности и интерфейсом с богатой функциональностью VSM становится чрезвычайно популярным в сообществе Ceph. Следующая редакция VSM должна быть 2.1, которая выйдет с некоторыми исправлениями ошибок и новыми функциями. {Прим. пер.: 29 января 2016 выпущена версия 2.1, на 27 мая 2016 заявлен выпуск версии 2.2.} Перечислим некоторые из них:

Новыми функциями VSM 2.1 являются:

Сообщение имени вашего сервера, который выполняет демон монитора

Prototype — реализация Ceph Calamari/VSM

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

Идентификация физического местоположения отказавшего диска

Удаление неиспользуемого пути диска в процессе добавления нового OSD

Отображение логического пути дисков вместо физического при добавлении нового OSD

Подключение и управление существующего кластера Ceph

Улучшения страницы мониторинга и состояния

Отображение информации SMART для устройств хранения

Исправления ошибок, необходимые в VSM 2.1:

Кнопка мониторов должна быть перемещена в Управление серверами и она должна вывешиваться когда узел монитора также имеет демон MDS

Версия VSM и время его работы должны отображаться даже если кластер не создан

Он даёт доступ к прочим опциям инструментальной панели VSM в процессе создания кластера

Высвечивается предостережение Number of PG in each OSD is too large после обновления кластера Ceph на версию Ceph Hammer.

Пароль для доступа к OpenStack отображается простым текстом

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

Если сервер отключается, это не отображается в VSM

Это очень ограниченный список новых функциональностей и исправлений ошибок, для последней информации по дорожной карте VSM обращайтесь, пожалуйста к проекту Virtual Storage Manager по адресу: https://01.org/jira/browse/VSM

 Ресурсы VSM

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

Официальный репозиторий исходного кода: https://github.com/01org/virtual-storage-manager.

VSM Wiki: https://github.com/01org/virtual-storage-manager/wiki.

Выпуски VSM, отслеживание разработки и дорожной карты: https://01.org/jira/browse/VSM.

Список почтовой рассылки VSM: http://vsm-discuss.33411.n7.nabble.com/.

Как вы уже знаете, VSM является проектом с открытым исходным кодом, полезно отметить, что усилия по разработке VSM восходят к Intel при поддержке его сообщества.

Я хочу выразить благодарность Дену Ферберу и Ягуангу Вонгу из Intel а также всему сообществу VSM за предоставление в наше распоряжение прекрасного образчика программного обеспечения для развёртывания и управления нашим кластером Ceph. Чтобы помочь дальнейшей разработке VSM, пожалуйста, становитесь активными участниками этого сообщества и рассмотрите вопрос о предоставлении обратного значительного вклада.

Глава 10. Ещё о Ceph

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

Эталонное тестирование кластера Ceph

Базовый уровень производительности дисков

Базовый уровень производительности сетевой среды

Показатели Ceph RADOS

RADOS load-gen

Эталонное тестирование блочного устройства Ceph

Эталонное тестирование Ceph RBD с применением FIO

Сокет администратора Ceph

Применение команды ceph tell

Ceph REST API

Профилирование памяти Ceph

Развёртывание Ceph с применением Ansible

Инструментарий ceph-objectstore

Содержание

10. Ещё о Ceph

Введение

Эталонное тестирование кластера Ceph

Базовый уровень производительности дисков

Базовый уровень производительности сетевой среды

Показатели Ceph RADOS

RADOS load-gen

Эталонное тестирование блочного устройства Ceph

Эталонное тестирование Ceph RBD с применением FIO

Сокет администратора Ceph

Применение команды ceph tell

Ceph REST API

Профилирование памяти Ceph

Развёртывание Ceph с применением Ansible

Инструментарий ceph-objectstore

 Введение

В предыдущих главах мы рассматривали различные способы развёртывания, предоставления и администрирования Ceph. В этой главе мы изучим эталонное тестирование имеющегося кластера Ceph, что является необходимым для выполнения этапом перед перемещением решения в промышленное применение. Мы также обсудим расширенные методы администрирования и обнаружения неисправностей Ceph с применением разъёма администратора, REST API и инструментария ceph-objectstore. Наконец мы изучим профилирование памяти Ceph, а также развёртывание Ceph с применением Ansible, который является очень эффективным способом развёртывания Ceph.

 Эталонное тестирование кластера Ceph

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

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

 Базовый уровень производительности дисков

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

[Замечание]
Замечание

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

  Производительность отдельного диска на запись

Для получения производительности дисковых чтения и записи мы воспользуемся командой dd с oflag установленным в значение direct для достижения обхода дискового кэша с целью получения реалистичных результатов.

  Как это сделать...

Прекратите кэширование.

# echo 3 > /proc/sys/vm/drop_caches

Используйте dd для записи файла с именем deleteme и размером 10ГБ заполненным нулями /dev/zero в качестве входного файла if в каталог, в который смонтирован OSD Ceph, т.е. /var/lib/ceph/osd/ceph-0/.

# dd if=/dev/zero of=/var/lib/ceph/osd/ceph-0/deleteme bs=10G count=1 oflag=direct

В идеале вы должны повторить шаги 1 и 2 несколько раз и получить среднее значение. В нашем случае среднее значение для операций записи приближается к 319 МБ/с, как показано на следующем экранном снимке:

	[root@ceph-node1 ~]# dd if=/dev/zero of=/var/lib/ceph/osd/ceph-0/deleteme bs=10G count=1 oflag=direct
	0+1 records in
	0+1 records out
	2147479552 bytes (2.1 GB) copied, 6.66535 s, 322 MB/s
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# dd if=/dev/zero of=/var/lib/ceph/osd/ceph-0/deleteme bs=10G count=1 oflag=direct
	0+1 records in
	0+1 records out
	2147479552 bytes (2.1 GB) copied, 7.09217 s, 303 MB/s
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# dd if=/dev/zero of4var/lib/ceph/osd/ceph-0/deleteme bs=10G count=1 oflag=direct
	0+1 records in
	0+1 records out
	2147479552 bytes (2.1 GB) copied, 6.45077 s, 333 MB/s
	[root@ceph-node1 ~]#

  Производительность множества дисков на запись

В качестве следующего шага мы выполним dd на всех ваших дисках OSD используемых Ceph на этом узле, ceph-node1, для получения суммарной производительности дисковой записи предоставляемой отдельным узлом.

  Как это сделать...

Получите общее число дисков, используемых на вашем OSD Ceph, в моём случае это 25 дисков:

# mount | grep -i osd | wc -l

Прекратите кэширование.

# echo 3 > /proc/sys/vm/drop_caches

Следующая команда выполнит команду dd на всех дисках OSD Ceph:

# for i in `mount | grep osd | awk '{print $3}'`; do (dd if=/dev/zero of=$i/deleteme bs=10G count=1 oflag=direct &) ; done

Для получения средней суммарной производительности записи возьмите среднее значение от всех скоростей записи. В моём случае среднее значение достигло 60 МБ/с.

  Производительность отдельного диска на чтение

Для получения производительности дискового чтения отдельного диска мы снова воспользуемся командой dd.

  Как это сделать...

Прекратите кэширование.

# echo 3 > /proc/sys/vm/drop_caches

Используйте dd для записи файла с именем deleteme, который мы создале в процессе тестирования записи. Мы будем читать наш файл deleteme в /dev/null с iflag установленным в значение direct:

# dd if=/var/lib/ceph/osd/ceph-0/deleteme of=/dev/null bs=10G count=1 iflag=direct

В идеале вы должны повторить шаги 1 и 2 несколько раз и получить среднее значение. В нашем случае среднее значение для операций записи приближается к 178 МБ/с, как показано на следующем экранном снимке:

	[root@ceph-node1 ~]# echo 3 > /proc/sys/vm/drop_caches
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# dd if=/var/lib/ceph/osd/ceph-0/deleteme of=/dev/null bs=10G count=1 iflag=direct
	0+1 records in
	0+1 records out
	2147479552 bytes (2.1 GB) copied, 12.0557 s, 178 MB/s
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# dd if=/var/lib/ceph/osd/ceph-O/deleteme of=/dev/null bs=10G count=1 iflag=direct
	0+1 records in
	0+1 records out
	2147479552 bytes (2.1 GB) copied, 12.0452 s, 178 MB/s
	[root@ceph-node1 ~]# dd if=/var/lib/ceph/osd/ceph-O/deleteme of=/dev/null bs=10G count=1 iflag=direct
	0+1 records in
	0+1 records out
	2147479552 bytes (2.1 GB) copied, 12.0408 s, 178 MB/s
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]#

  Производительность множества диска на чтение

Аналогично производительности отдельного диска на чтение мы используем dd для получения суммарной производительности на чтение множества дисков.

  Как это сделать...

Получите общее число дисков, используемых на вашем OSD Ceph, в моём случае это 25 дисков:

# mount | grep -i osd | wc -l

Прекратите кэширование.

# echo 3 > /proc/sys/vm/drop_caches

Следующая команда выполнит команду dd на всех ваших дисках Ceph OSD:

# for i in `mount | grep osd | awk '{print $3}'`; do (dd if=$i/deleteme of=/dev/null bs=10G count=1 iflag=direct &); done

Для получения суммарной производительности дискового чтения возьмите среднее всех ваших скоростей чтения. В моём случае среднее значение приближается к 123 МБ/с.

  Результаты

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

Операция
на диск
агрегированная

чтение

178МБ/с

123МБ/с

запсиь

319МБ/с

60МБ/с

 Базовый уровень производительности сетевой среды

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

Для запуска эталонного тестирования сети выполните iperf с параметром сервера на своём первом узле, а с параметром клиента на своём втором узле.

  Как это сделать...

На Ceph-node1 выполните iperf с -s для вашего сервера и -p для прослушивания определённого порта:

# iperf -s -p 6900

	[root@ceph-node1 ~]# iperf -s -p 6900
	-----------------------------------------------------------
	Server listening on TCP port 6900
	TCP window size: 85.3 KByte (default)
	-----------------------------------------------------------
	[ 4] local 10.100.1.201 port 6900 connected with 10.100.1.202 port 39630
	[ ID] Interval Transfer Bandwidth
	[ 4] 0.0-10.0 sec  11.5 GBytes  9.87 Gbits/sec
	^C[root@ceph-node1 ~]#
	[root@ceph-node1 ~]#

[Замечание]
Замечание

Вы можете опустить параметр -p если порт TCP 5201 открыт или вы можете любой другой порт который открыт и не используется.

На Ceph-node2 выполните iperf с параметром клиента, -c:

# iperf -c ceph-node1 -p 6900

	[root@ceph-node2 ~]# iperf -c ceph-node1 -p 6900
	-----------------------------------------------------------
	Client connecting to 10.100.1.201, TCP port 6900
	TCP window size: 95.8 KByte (default)
	-----------------------------------------------------------
	[ 3] local 10.100.1.202 port 39630 connected with 10.100.1.201 port 6900
	[ ID] Interval Transfer Bandwidth
	[ 3] 0.0-10.0 sec  11.5 GBytes  9.87 Gbits/sec
	[root@ceph-node2 ~]#

[Замечание]
Замечание

Вы можете также применить параметр -p в своей команде iperf для определения числа параллельных соединений потоков создаваемых с вашим сервером. Это вернёт реалистичные результаты если у вас имеется техника связывания каналов, например, LACP.

Результаты показывают, что у нас есть привлекательное сетевое соединение с 9.8Gb/s между нашими узлами Ceph. Аналогично мы можем выполнять проверку пропускной способности сети для всех других узлов в вашем кластере Ceph. Полоса пропускания сетевой среды в реальности зависит от применяемой вами между узлами Ceph сетевой инфраструктуры.

  Смотрите также...

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

 Показатели Ceph RADOS

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

  Как это сделать...

Давайте выполним некоторые тесты при помощи rados bench:

Для выполнения 10 секундного теста записи в ваш пул rbd без очистки выполните следующую команду:

# rados bench -p rbd 10 write --no-cleanup

После выполнения данной команды мы получим следующий снимок экрана:

	[root@ceph-node1 ~]# rados bench -p rbd 10 write --no-cleanup
	Maintaining 16 concurrent writes of 4194304 bytes for up to 10 seconds or 0 objects
	Object prefix: benchmarkdata_ceph-node1_3124629
	  sec Cur ops   started finished  avg MB/s   cur MB/s  last lat   avg lat
	    0       0         0        0         0          0         -         0
	    1      16       118      102    407.85        408 0.0584212  0.127569
	    2      16       207      191   381.895        356   0.20105  0.150813
	    3      16       279      263   350.581        288  0.141772  0.168736
	    4      16       351      335   334.921        288   0.57108  0.181988
	    5      16       420      404    323.13        276 0.0724497   0.19139
	    6      16       479      463   308.601        236  0.137025  0.194498
	    7      16       547      531   303.367        272  0.253194  0.206116
	    8      16       615      599   299.441        272  0.172813  0.208689
	    9      16       692      676   300.386        308   0.48298  0.209028
	   10      16       747      731   292.345        220  0.123282  0.211807
	Total time run:         10.721111
   Total writes made:      747
   Write size:             4194304
   Bandwidth (MB/sec):     278.702

   Stddev Bandwidth:       102.44
   Max bandwidth (MB/sec): 408
   Min bandwidth (MB/sec): 0
   Average Latency:        0.227756
   Stddev Latency:         0.234691
   Max latency:            1.5534
   Min latency:            0.041106
   [root@ceph-node1 ~]#

Аналогично, для выполнения 10 секундного теста чтения в вашем пуле rbd, выполните следующую команду:

# rados bench -p rbd 10 seq

	[root@ceph-node1 ~]# rados bench -p rbd 10 seq
	   sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
	     0       0         0         0         0         0         -         0
	     1      16       247       231   923.573       924  0.181625 0.0620505
	     2      16       489       473   945.703       968 0.0366547 0.0645318
	     3      16       648       632   698.411       636  0.306308 0.0814809
	 Total time run:        4.223407
	Total reads made:     747
	Read size:            4194304
	Bandwidth (MB/sec):   707.486

	Average Latency:      0.0901875
	Max latency:          1.03252
	Min latency:          0.00977891
	[root@ceph-node1 ~]#

[Замечание]
Замечание

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

Аналогично выполните тестирование случайного чтения при помощи rados bench, исполнив следующую команду:

# rados bench -p rbd 10 rand

  Как это работает...

Синтаксис для rados bench таков:

# rados bench -p <pool_name> <seconds> <write|seq|rand> -b <block size> -t --no-cleanup

-p или --pool: определяет имя пула

<seconds>: время тестирования в секундах

<write|seq|rand>: тип тестирования, {а именно}: запись, последовательное чтение или случайное чтение

-b: для определения размера блока; по умолчанию он 4M

-t: число параллельных потоков; по умолчанию 16

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

[Замечание]
Замечание

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

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

 RADOS load-gen

Слегка похожий на rados bench, rados load-gen является другим интересным инструментом, предоставляемым Ceph, который работает сразу после вынимания из коробки. Как подсказывает его название, инструмент rados load-gen может применяться для генерации нагрузки и может оказаться полезным при симуляции сценариев с высокой нагрузкой.

  Как это сделать...

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

# rados -p rbd load-gen \
   --num-objects 50 \
   --min-object-size 4M \
   --max-object-size 4M \
   --max-ops 16 \
   --min-op-len 4M \
   --max-op-len 4M \
   --percent 5 \
   --target-throughput 2000 \
   --run-length 60

  Как это работает...

Синтаксис rados load-gen таков:

# rados -p <pool-name> load-gen

--num-objects: общее число объектов

--min-object-size: минимальный размер объекта в байтах

--max-object-size: максимальный размер объекта в байтах

--min-ops: минимальное число операций

--max-ops: максимальное число операций

--min-op-len: минимальная длина операции

--max-op-len: максимальная длина операции

--max-backlog: максимум незавершённых заданий (в МБ)

--percent: процент операций чтения

--target-throughput: пропускная способность получателя (в МБ)

--run-length: общее время работы в секундах

Эта команда сгенерирует нагрузку на ваш кластер Ceph посредством записи 50 объектов в пул rbd. Длина каждого из этих объектов и операций составит в размере 4M с 5% чтения и временем тестирования 60 секунд.

	[root@ceph-node1 ~]# rados -p rbd load-gen \
	> --num-objects 50 \
	> --min-object-size 4M \
	> --max-object-size 4M \
	> --max-ops 16 \
	> --min-op-len 4M \
	> --max-op-len 4M \
	> --percent 5 \
	> --target-throughput 2000 \
	> --run-length 60
	run length 60 seconds
	preparing 50 objects
	load-gen will run 60 seconds
	    1: throughput=0MB/sec pending data=0
	READ : oid=obj-xtuVtifS5zQ55da off=0 len=4194304
	READ : oid=obj-0NvPNB07Lz1rTra off=0 len=4194304
	WRITE : oid=obj-UeV2NunBsTSrYUw off=0 len=4194304
	op 17 completed, throughput=4MB/sec
	READ : oid=obj-fL1p0c_7CgEtjlk off=0 len=4194304
	op 18 completed, throughput=8MB/sec

Вывод был усечён для краткости мотивации. Когда команда load-gen завершится, она вычистит за собой все объекты, которые она создавала для тестирования и выведет рабочую пропускную способность.

	op 5519 completed, throughput=373MB/sec
	waiting for all operations to complete
	cleaning up objects
	op 5522 completed, throughput=367MB/sec
	op 5521 completed, throughput=367MB/sec
	[root@ceph-node1 ~]#

  Есть кое-что еще...

Также вы можете наблюдать за состоянием вашего кластера на предмет скорости/ операций чтения и записи с помощью команды watch ceph -s, в то время, пока будет работать rados load-gen, просто чтобы смотреть что происходит.

 Эталонное тестирование блочного устройства Ceph

Описанные в последнем рецепте инструменты rados bench и rados load-gen применяются для эталонного тестирования пула вашего кластера Ceph. В данном рецепте мы сосредоточимся на эталонном тестировании блочного устройства Ceph пи помощи инструмента rbd bench-write.

  Ceph rbd bench-write

Интерфейс командной строки ceph rbd предоставляет параметр, называемый bench-write, который является инструментом для выполнения операций эталонного тестирования в ваше блочное устройство RADOS Ceph.

  Как это сделать...

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

Создайте блочное устройство с именем block-device1 и размером 1ГБ, а потом отобразите его:

# rbd create block-device1 --size 10240
# rbd info --image block-device1
# rbd map block-device1
# rbd showmapped

	[root@ceph-client1 ~]# rbd create block-device1 --size 10240
	[root@ceph-client1 ~]# rbd info --image block-device1
	rbd image 'block-device1':
	        size 10240 MB in 2560 objects
	        order 22 (4096 kB objects)
	        block_name_prefix: rb.0.4cbacc.238e1f29
	        format: 1
	[root@ceph-client1 ~]# rbd map block-device1
	/dev/rbd0
	[root@ceph-client1 ~]# rbd showmapped
	id pool image         snap device
	0  rbd  block-device1 -    /dev/rbd0
	[root@ceph-client1 ~]#

Создайте файловую систему на вашем блочном устройстве и смонтируйте её.

# mkfs.xfs /dev/rbd0
# mkdir -p /mnt/ceph-block-device1
# mount /dev/rbd0 /mnt/ceph-block-device1
# df -h /mnt/ceph-block-device1

	[root@ceph-client1 ~]# mkfs.xfs /dev/rbd0
	log stripe unit (4194304 bytes) is too large (maximum is 256KiB)
	log stripe unit adjusted to 32KiB
	meta-data=/dev/rbd0              isize=256    agcount=17, agsize=162816 blks
	         =                       sectsz=512   attr=2, projid32bit=1
	         =                       crc=0        finobt=0
	data     =                       bsize=4096   blocks=2621440, imaxpct.25
	         =                       sunit=1024   swidth=1024 blks
	naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
	log      =internal log           bsize=4096   blocks=2560, version=2
	         =                       sectsz=512   sunit=8 blks, lazy-count=1
	realtime =none                   extsz=4096   blocks=0, rtextents=0
	[root@ceph-client1 ~]# mkdir -p /mnt/ceph-block-device1
	[root@ceph-client1 ~]# mount /dev/rbd0 /mnt/ceph-block-device1
	[root@ceph-client1 ~]# df -h /mnt/ceph-block-device1
	Filesystem      Size  Used Avail Use% Mounted on
	/dev/rbd0        10G   33M   10G   1% /mnt/ceph-block-device1
	[root@ceph-client1 ~]#

Для выполнения эталонного тестирования block-device1 на запись общей длиной выполните следующую команду:

# rbd bench-write block-device1 --io-total 5368709200

	[root@ceph-client1 ~]# rbd bench-write block-device1 --io-total 5368709200
	bench-write  io_size 4096 io_threads 16 bytes 5368709200 pattern seq
	  SEC       OPS   OPS/SEC   BYTES/SEC
	    1     67285  67304.27  275678272.46
	    2    145469  72743.93  297959122.08
	    3    224701  74906.90  306818647.61
	    4    301802  75427.40  308950632.76
	    5    372142  74432.24  304874445.83
	    6    444010  75344.90  308612698.37
	    7    517287  74363.64  304593457.23
	    8    599236  74906.98  306818990.26
	    9    672587  74178.98  303837121.67
	   10    732910  72153.50  295540718.90
	   11    784764  68150.81  279145733.52
	   12    852044  66951.41  274232980.96
	   13    918326  63817.89  261398064.96
	   14    982399  61962.40  253797984.31
	   15   1047148  62847.78  257424494.92
	   16   1107514  64550.09  264397152.44
	   17   1163126  62216.51  254838831.07
	   18   1226368  61607.43  252344039.05
	   19   1286892  60898.32  249439520.77
	elapsed: 51 ops: 1310721 ops/sec: 25221.56 bytes/sec: 103307522.97
[root@ceph-client1 ~]#

Как вы можете увидеть, вывод результатов rbd bench-write хорошо форматирован.

  Как это работает...

Синтаксис rbd bench-write выглядит следующим образом:

# rbd bench-write <RBD image name>

--io-size: размер записи в байтах; по умолчанию 4М

--io-threads: число потоков; по умолчанию 16

--io-total: общее число байт для записи; по умолчанию 1024M

--io-pattern <seq|rand>: шаблон записи, по умолчанию установлен seq

  Есть кое-что еще...

Для подстройки ваших размера блока, количества потоков и шаблонов ввода/ вывода вы можете применять с rbd bench-write различные параметры.

  Смотрите также...

Глава 2. Работа с блочными устройствами Ceph подробно рассматривает создание блочного устройства Ceph.

 Эталонное тестирование Ceph RBD с применением FIO

FIO является аббревиатурой для Flexible I/O; это одно из самых популярных средств для создания рабочей нагрузки ввода/ вывода и эталонного тестирования. FIO имеет только что добавленную встроенную поддержку RBD. FIO является высоко настраиваемым и может применяться для эмуляции и эталонного тестирования практически любых видов нагрузок. В данном рецепте мы изучим то, как FIO может применяться для эталонного тестирования вашего RBD Ceph.

  Как это сделать...

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

Установите пакет FIO на свой узел, на который вы отобразили свой образ RBD Ceph. В нашем случае это узел ceph-client1:

# yum install -y fio

Так как FIO поддерживает RBD IOengine нам не нужно монтировать образ RBD как файловую систему. Для эталонного тестирования RBD нам нужно просто предоставить имя вашего образа RBD, пул и пользователя Ceph, которые будут использоваться для соединения с кластером Ceph. Создайте профиль FIO со следующим содержанием:

[write-4M]
description="write test with block size of 4M"
ioengine=rbd
clientname=admin
pool=rbd
rbdname=block-device1
iodepth=32
runtime=120
rw=write
bs=4M

	[root@ceph-client1 ~]#
	[root@ceph-client1 ~]# cat write.fio
	[write-4m]
	description="write test with block size of 4M"
	ioengine=rbd
	clientname=admin
	pool=rbd
	rbdname=block-device1
	iodepth=32
	runtime=120
	rw=write
	bs=4M
	[root@ceph-client1 ~]#

Для запуска эталонного тестирования FIO, выполните команду FIO, предоставив ей в качестве аргумента файл профиля FIO:

# fio write.fio

	[root@ceph-client1 ~]#
	[root@ceph-client1 ~]# fio write.fio
	write-4M: (g=0) rw=write, bs=4M-4M/4M-4M/4M-4M, ioengine=rbd, iodepth=32
	fio-2.2.8
	Starting 1 process
	rbd engine: RBD version: 0.1.9
	Jobs: 1 (f=0): [w(1)] [100.0% done] [0K8/107.7MB/0K8 /s] [0/26/0 iops] [eta 00m:00s]
	write-4m: (groupid=0, jobs=1): err= 0: pid=2146255: Wed Dec 9 00:54:40 2015
	  Description : ["write test with block size of 4M"]
	  write: io=010240MB, bw=314736KB/s, ops=76, runt= 33316msec
	    slat (usec) : min=129 , max=15181, avg=473.98, stdev=888.02
	    clat (msec) : min=102 , max=2949 avg=409.87, stdev=263.06
	     lat (msec) : min=102, max=2949 , avg=410.35 , stdev=263.06
	    clat percentiles (msec):
	     |  1.00th=[  131],  5.00th=[ 155], 10.00th=[ 180], 20.00th=[ 219],
	     | 30.00th=[  258], 40.00th=[ 310], 50.00th=[ 351], 60.00th=[ 392],
	     | 70.00th=[  441], 80.00th=[ 545], 90.00th=[ 693], 95.00th=[ 906],
	     | 99.00th=[ 1369], 99.50th=[1762], 99.90th=[2409], 99.95th=[2474],
	     | 99.99th=[ 2966]
	  bw (KB /s): min=74908, max=568888, per=100.00%, avg=327349.43, stdev=99611.29
	  lat (msec) 250=27.70%, 500=47.19%, 750=17.42%, 1000=4.30%, 2000=3.20%
	  lat (msec) : >=2000=0.20%
	cpu          : usr=3.04%, sys=0.59%, ctx=268, majf=0, minf=52854
	IO depth     : 1=0.3%, 2=1.2%, 4=4.7%, 8=19.4%, 16=68.5%, 32=5.8%, >=64=0.0%
	   submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
	   complete  : 0=0.0%, 4=95.9%, 8=0.1%, 16=0.8%, 32=3.3%, 64=0.0%, >=64=0.0%
	   issued	 : total=r=0/w=2560/d=0, short=r=0/w=0/d=0, dror=r=0/w=0/d=0
	   latency   : target=0, window=0, percentile=100.00%, depth=32

	Run status group 0 (all jobs):
	 WRITE: io=10240MB, aggrb=314736KB/s, minb=314736KB/s, maxb=314736K8/s, mint=33316msec, maxt=33316msec
	Disk stats (read/write):
	    dm-0: ios=0/5, merge0/0, ticks=0/10, in_queue=10, util=0.01%, aggrios=56/5, aggrmerge=0/0, aggrticks=0/0, aggrin_gueue=0, aggrutil=0.00%
	    mdl: ios=56/5, merge0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=3/13, aggrmerge=24/0, aggrticks=1/6, aggrinqueue=7, aggrutil=0.01%
	sdbi : ios=7/13, merge=49/0, ticks=2/6, in_queue=8, util=0.01%
	sdbj : ios=0/13, merge=0/0 , ticks=0/6, in_queue=6, util=0.01% ]
	[root@ceph-client1 ~]#

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

  Смотрите также...

Глава 2. Работа с блочными устройствами Ceph подробно рассматривает создание блочного устройства Ceph.

Для получения дополнительной информации по FIO посетите https://github.com/axboe/fio.

 Сокет администратора Ceph

Компоненты Ceph являются демонами и Сокетами домена UNIX (Unix domain socket, UDS, или IPC-сокетами сокетами межпроцессного взаимодействия). Ceph делает возможным для нас использовать эти сокеты для построения очередей демонов. Сокет администратора Ceph является мощным инструментом для получения и сборки настроек демона Ceph во время его выполнения. С применением этого инструмента изменение значений настроек демона становится намного проще даже в сравнении с изменением вашего файла настроек Ceph, который требует перезапуска демона.

Чтобы выполнить это, нам необходимо зарегистрироваться на нашем узле, выполняющем демонов Ceph и выполнить команды ceph daemon.

  Как это сделать...

Существует два способа доступа к вашему сокету администратора:

Воспользовавшись именем вашего демона Ceph:

$ sudo ceph daemon {daemon-name} {option}

Используя абсолютный путь к файлу сокета; его местоположение по умолчанию такое: /var/run/ceph:

$ sudo ceph daemon {absolute path to socket file} {option}

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

Вывести список всех доступных вашему сокету администратора команд для OSD:

# ceph daemon osd.0 help

Вывести список всех доступных вашему сокету администратора команд для MON:

# ceph daemon mon.ceph-node1 help

Проверить установки настроек OSD для osd.0.

# ceph daemon osd.0 config show

Проверить установки настроек MON для mon.ceph-node1.

# ceph daemon mon.ceph-node1 config show

[Замечание]
Замечание

Ваш демон администратора Ceph позволяет вам изменять установки настроек вашего демона во время его выполнения. Однако эти изменения временные. Для изменения настроек вашего демона на постоянно, измените ваш файл настроек Ceph.

Для получения текущего значения настроек для osd воспользуйтесь параметром _recover_max_chunk для демона osd.0:

# ceph daemon osd.0 config get osd_recovery_max_chunk

Чтобы изменить ваше значение osd_recovery_max_chunk для osd.0 выполните:

# ceph daemon osd.0 config set osd_recovery_max_chunk 1000000

	[root@ceph-node1 ~]# ceph daemon osd.0 config get osd_recovery_max_chunk
	{
		"osd_recoverymax_chunk": "8388608"
	}
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph daemon osd.0 config set osd_recovery_max_chunk 1000000
	{
		"success": "oscLrecoveryjnaxchunk = '1000000' "
	}
	[root@ceph-node1 ~]#

 Применение команды ceph tell

Другим эффективным способом изменения выполняющихся настроек для демона Ceph без дополнительных накладных расходов на регистрацию на этом узле является применение команды ceph tell:

  Как это сделать...

Команда ceph tell избавляет вас от затрат на регистрацию на том узле где выполняется ваш демон. Эта команда проходит через узел монитора, поэтому вы можете выполнять её с любого узла в вашем кластере:

Чтобы изменить установки osd_recovery_threads на ceph tell выполните:

ceph tell osd.0 injectargs '--osd_recovery_threads=2'

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

ceph tell osd.* injectargs '--osd_recovery_threads=2'

Также вы можете изменять множество установок в одной строке:

ceph tell osd.* injectargs '--osd_recovery_max_active=1 --osd_recovery_max_single_start=1 --osd_recovery_op_priority=50'

  Как это работает...

Синтаксис команды ceph tell следующий:

ceph tell {daemon-type}.{id or *} injectargs --{config_setting_name} {value}

 Ceph REST API

Ceph поставляется с мощным интерфейсом доступа REST API, который позволяет вам программно адимнистрировать ваш кластер. Он может работать как WSGI приложение или в качестве автономного сервера, по умолчанию прослушивая порт 5000. Он предоставляет функциональность аналогичного вида с предлагаемой инструментарием командной строки через интерфейс доступа HTTP. Команды передаются как HTTP запросы GET и PUT, а результат может возвращаться в форматах JSON, XML и текстовом. В этом рецепте я быстро покажу вам как установить Ceph REST API и как с ним взаимодействовать.

  Как это сделать...

Создайте в своём кластере Ceph пользователя client.restapi с соответствующим доступом к mon, osd и mds:

# ceph auth get-or-create client.restapi mds 'allow' osd 'allow *' mon 'allow *' > /etc/ceph/ceph.client.restapi.keyring

Добавьте в свой файл ceph.conf следующий раздел:

[client.restapi]
log file = /var/log/ceph/ceph.restapi.log
keyring = /etc/ceph/ceph.client.restapi.keyring

Выполните следующую команду для запуска ceph-rest-api в качестве отдельного веб-сервера в фоновом режиме:

# nohup ceph-rest-api > /var/log/ceph-rest-api &> /var/log/cephrest-api-error.log &

[Замечание]
Замечание

Вы также можете выполнить ceph-rest-api без его продвижения, подавляя его в фоновый режим.

ceph-rest-api теперь должен прослушивать по адресу 0.0.0.0:5000; выполните curl чтобы запросить ceph-rest-api жизнеспособность вашего кластера:

# curl localhost:5000/api/v0.1/health

Аналогично проверьте состояние osd и mon через rest-api Чтобы изменить установки osd_recovery_threads на ceph tell выполните:

# curl localhost:5000/api/v0.1/osd/stat
# curl localhost:5000/api/v0.1/mon/stat

	[root@ceph-node1 ~]# nohup ceph-rest-api > /var/log/ceph-rest-api &> /var/log/ceph-rest-api-error.log &
	[1] 3334321
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# curl localhost:5000/api/v0.1/health
	HEALTH_OK
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# curl localhost:5000/api/v0.1/osd/stat
	     osdmap e989: 9 olds: 9 up, 9 in
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# curl localhost:5000/api/v0.1/mon/stat
	e5: 3 mons at {ceph-node1.192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789 /0}, election epoch 3648, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
	[root@ceph-node1 ~]#

ceph-rest-api поддерживает большинство команд CLI Ceph. Чтобы проверить перечень доступных ceph-rest-api команд выполните:

# curl localhost:5000/api/v0.1

[Замечание]
Замечание

Эта команда вернёт результаты в формате HTML; вам будет лучше зайти через свой веб- браузер на localhost:5000/api/v0.1 для выстраивания вашего HTML в читаемый вид.

Это базовая реализация ceph-rest-api. Для применения её в промышленной реализации хорошей мыслью будет развернуть её болеечем в одном экземпляре в виде приложения WSGI обёрнутого веб- сервером и с балансровкой нагрузки на входе. ceph-rest-api является масштабируемой, обладающей малым весом службой, которая делает возможным для вас администрировать вашим кластером Ceph на уровне профессионала.

 Профилирование памяти Ceph

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

  Как это сделать...

Запустите профилировщик памяти для определённого демона:

# ceph tell osd.0 heap start_profiler

[Замечание]
Замечание

Для автоматического запуска профилировщика при старте этого демона OSD ceph установите соответствующее значение переменной окружения CEPH_HEAP_PROFILER_INIT=true.

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

Далее выведите статистики кучи о собранных профилировщиком отпечатках памяти:

# ceph tell osd.0 heap stats

	[root@ceph-node1 ~]# ceph tell osd.0 heap start_profiler
	osd.0 started profiler
	[root@ceph-node1 ~]#
	[root@ceph-node1 ~]# ceph tell osd.0 heap stats
	osd.0 tcmalloc heap stats:------------------------------------------------
	MALLOC:      238029520 (  227.0 MiB) Bytes in use by application
	MALLOC: +            0 (    0.0 MiB) Bytes in page heap freelist
	MALLOC: +     13789912 (   13.2 MiB) Bytes in central cache freelist
	MALLOC: +      4454720 (    4.2 MiB) Bytes in transfer cache freelist
	MALLOC: +     28537112 (   27.2 MiB) Bytes in thread cache freelists
	MALLOC: +      2863264 (    2.7 MiB) Bytes in malloc metadata
	MALLOC:   ------------
	MALLOC: =    287674528 (  274.3 MiB) Actual memory used (physical + swap)
	MALLOC: +      2031616 (    1.9 MiB) Bytes released to OS (aka unmapped)
	MALLOC:   ------------
	MALLOC:      289706144 (  276.3 MiB) Virtual address space used
	MALLOC:
	MALLOC:          13148              Spans in use
	MALLOC:            424              Thread heaps in use
	MALLOC:           8192              Tcmalloc page size
	------------------------------------------------
	Call ReleaseFreeMemory() to release freelist memory to the OS (via madvise()).
	Bytes released to the OS take up virtual address space but no physical memory.
	[root@ceph-node1 ~]#

Вы также можете сделать дамп статистик кучи в файл, который может быть использован позже; по умолчанию он создаётся в файле дампа /var/log/ceph/osd.0.profile.0001.heap:

# ceph tell osd.0 heap dump

	[root@ceph-node1 ~]# ceph tell osd.0 heap dump
	osd.0 dumping heap profile now.
	------------------------------------------------
	MALLOC:      238031808 (  227.0 MiB) Bytes in use by application
	MALLOC: +            0 (    0.0 MiB) Bytes in page heap freelist
	MALLOC: +     13589456 (   13.0 MiB) Bytes in central cache freelist
	MALLOC: +      4258112 (    4.1 MiB) Bytes in transfer cache freelist
	MALLOC: +     28964656 (   27.6 MiB) Bytes in thread cache freelists
	MALLOC: +      2863264 (    2.7 MiB) Bytes in malloc metadata
	MALLOC:   ------------
	MALLOC: =    287707296 (  274.4 MiB) Actual memory used (physical + swap)
	MALLOC: +      1998848 (    1.9 MiB) Bytes released to OS (aka unmapped)
	MALLOC:   ------------
	MALLOC: =    289706144 (  276.3 MiB) Virtual address space used
	MALLOC:
	MALLOC:          13152              Spans in use
	MALLOC:            424              Thread heaps in use
	MALLOC:           8192              Tcmalloc page size
	------------------------------------------------
	Call ReleaseFreeMemory() to release freelist memory to the OS (via madvise()).
	Bytes released to the OS take up virtual address space but no physical memory.
	[root@ceph-node1 ~]#

Чтобы прочитать этот файл дампа вам понадобится google-perftools:

# yum install -y google-perftools

Для просмотра журналов профайлера:

# pprof --text {path-to-daemon} {log-path/filename}
# pprof --text /usr/bin/ceph-osd /var/log/ceph/osd.0.profile.0001.heap

Для гранулированного сравнения сгенерируйте несколько файлов дампов профайлера для одного и того жедемона и примените инструмент профайлера Google для их сравнения:

# pprof --text --base /var/log/ceph/osd.0.profile.0001.heap /usr/bin/ceph-osd /var/log/ceph/osd.0.profile.0002.heap

Освободите память, которую выделил TCMALLOC, однако она не используется Ceph:

# ceph tell osd.0 heap release

По завершению остановите профайлер:

# ceph tell osd.0 heap stop_profiler

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

 Развёртывание Ceph с применением Ansible

В этой книге мы уже обсудили развёртывание Ceph множеством способов, которые включают Ceph-deploy и Virtual Storage Manager (VSM, Менеджер виртуальных хранилищ). Оба этих метода требуют ручной установки и настройки вашего кластера Ceph. Однако существуют и другие инструменты и методы которые могут устанавливать и развёртывать Ceph для вас высоко автоматизированным образом. При помощи таких методов вам большене понадобится набирать докучливые команды для развёртывания Ceph; по вашему желанию инструменты управления настройкой, такие как Ansible, Puppet, Chef и прочие могут настраивать ваш кластер Ceph.

  Приготовление

В этом рецепте мы пройдем сквозь Ansible, который является очень простым инструментом автоматизации ИТ и управления настройкой; для дополнительной информации окиньте взглядом http://www.ansible.com/how-ansible-works. Экосистема Ceph имеет живое сообщество вокруг него, которое разрабатывает готовые к применению модули Ansible для Ceph. Мы будем применять эти модули ceph-ansible (отсылаем к https://github.com/ceph/ceph-ansible) для развёртывания вашего кластера Ceph с помощью Ansible.

  Как это сделать...

Существует два способа которыми вы можете развернуть Ceph с применением модулей ceph-ansible:

Применить модуль ceph-ansible для первого запуска нескольких виртуальных машин с применением Vagrent и VirtualBox/VMware, а затем установить и настроить Ceph с помощью Ansible.

Применить модуль ceph-ansible для установки и настройки кластера Ceph с применением сборников сценариев Ansible на машинах голого железа.

В этом рецепте мы применим первый метод, то есть применим модуль ceph-ansible для запуска виртуальных машин VirtualBox и Ansible для установки и развёртывания вашего кластера Ceph.

[Замечание]
Замечание

Модули ceph-ansible являются местом средоточения сообщества и достаточно зрелые для вас чтобы вы могли использовать их для развёртывания Ceph в промышленном применении. Я хотел бы дать высокую оценку сообществу ceph-ansible за великолепно проделанную работу в разработке, совершенствовании и поддержке модулей ceph-ansible.

На своей машине хоста VirtualBox клонируйте Git самый последний модуль ceph-ansible:

$ git clone https://github.com/ceph/ceph-ansible.git
$ cd ceph-ansible

ceph-ansible использует Vagrant. Для этой цели он поставляется вместе с Vagrantfile, который сообщает Vagrant как раскручивать ВМ. Этот файл требует некоторых переменных, которые определены в другом файле: vagrant_variables.yml. Модуль ceph-ansible приходит с vagrant_variables.yml.sample, который может быть использован напрямую с минимальными изменениями:

$ cp vagrant_variables.yml.sample vagrant_variables.yml

Настройки по умолчанию для Vagrant определены в vagrant_variables.yml и тоже достаточно хороши. Если вы пожелаете, вы можете подстроить конфигурацию отредактировав этот файл. Поскольку это тестовый кластер, мы уменьшим число мониторов с 3 до 1 изменив переменную mon_vms на значение 1.

Модуль ceph-ansible принуждает Vagrant использовать Ansible как своего снабженца; для этой цели скопируйте файл site.yml.sample под именем site.yml в ту же иерархию:

$ cp site.yml.sample site.yml

Наконец, мы выполним vagrant up, который запустит 4 ВМ (1 монитор Ceph и 3 OSD Ceph), а после этого он запустит установку и развёртывание Ceph при помощи инструмента управления настройкой, Ansible:

$ vagrant up

Предоставление ВМ и развёртывание Ceph займут несколько минут; после завершения вы должны увидеть примерно вот это:

	PLAY RECAP ********************************************************************
	mon0                     : ok=82   changed=15   unreachable=0    failed=0
	osd0                     : ok=67   changed=9    unreachable=0    failed=0
	osdl                     : ok=67   changed=9    unreachable=0    failed=0
	osd2                     : ok=67   changed=9    unreachable=0    failed=0

После успешного завершения вы закончите с работающим кластером Ceph, установленным и настроенным при помощи Ansible. Зарегистрируйтесь на своём узле mon0 и проверьте состояние вашего кластера:

$ vagrant ssh mon0
$ sudo ceph -s

	vagrant@ceph-mon0:-$ sudo ceph -s
	    cluster 4a158d27-f750-41d5-9e7f-26ce4c9d2d45
	     health HEALTH_OK
	     monmap el: 1 mons at {ceph-mon0=192.168.42.10:6789/0}
	            election epoch 2, quorum 0 ceph-mon0
	     mdsmap e2: 0/0/1 up
	     osdmap e21: 6 osds: 6 up, 6 in
	            flags sortbitwise
	      pgmap v27: 320 pgs, 3 pools, 0 bytes data, 0 objects
	            212 MB used, 65121 MB / 65333 MB avail
	                 320 active+clean
	vagrant@ceph-mon0:-S

  Есть кое-что еще...

Сборка Vagrant может быть удалена при помощи vagrant destroy -f и повторно создана в любое время в течение нескольких минут автоматизированным, интеллектуальным образом. Вы можете отметить как просто, быстро и бесшовно было выполнено это развёртывание Ceph в сравнении с ручным. Для промышленного применения следует на самом деле рассматривать инструменты управления настройкой, подобные Ansible, для развёртывания Ceph для сохранения всех узлов в том же состоянии с точки зрения настройки. К тому же они очень удобны для управления большими кластерами с несколькими десятками узлов.

 Инструментарий ceph-objectstore

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

  Как это сделать...

ceph-objectstore-tool может быть рискованной операцией и команда обязаны выполняться либо пользователем root, либо с sudo. Не пытайтесь делать это на вашем промышленном кластере без привлечения поддержки Red Hat Ceph Storage, если вы не уверены в том, что вы делаете. Это может вызвать необратимую потерю данных в вашем кластере.

Найдите незавершённую группу размещения в вашем кластере Ceph. Примените следующую команду и получите идентификатор вашей PG и её наборы действия:

# ceph health detail | grep incomplete

С помощью действующего набора определите местоположение хоста OSD:

# ceph osd find <osd_number>

Зарегистрируйтесь на этом узле OSD и остановите OSD с которым вы собираетесь работать:

# service ceph stop <osd_ID>

Следующиеразделы описывают функции с вашими OSD и группами размещения, которые вы можете применять с ceph-objectstore-tool:

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

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --op list

Чтобы идентифицировать ваш объект внутри группы размещения выполните:

# ceph-objectstore-tool --data-path >/path/to/osd> --journal-path >/path/to/journal> --pgid <pgid> --op list

Для вывода перчня групп размещения, хранящихся на некоем OSD выполните:

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --op list-pgs

Если вы знаете идентификатор объекта который вы ищете, задайте его для определения идентификатора его PG:

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --op list <object-id>

Извлеките информацию об определённой группе размещения:

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --pgid <pg-id> --op info

Извлеките журнал операций в группе размещения:

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --pgid <pg-id> --op log

Удаление группы размещения является рискованной операцией и может вызвать потерю данных; применяйте эту функциональность с предосторожностью. Если вы разрушите группу размещения в OSD это не допустит одноранговый обмен или запуск службы OSD, перед удалением вашей группы размещения убедитесь что у вас имеется рабочая копия группы размещения на другом OSD. В качестве предосторожности перед удалением вашей PG вы можете также сделать резервную копию этой группы размещения экспортировав её в файл:

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

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --pgid <pg-id> --op remove

Для экспорта группы размещения в файл выполните следующую команду:

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --pgid <pg-id> --file /path/to/file --op export

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

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --file </path/to/file> --op import

OSD может иметь объект, помеченный как "lost". Для вывода списка "lost" или "unfound" объектов выполните:

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --op list-lost

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

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --pgid <pgid> --op list-lost

Инструмент ceph-objectstore-tool специально используется для фиксации ваших PG утраченных объектов. OSD может иметь объекты, помеченные как "lost". Для удаления этих объектов из группы размещения выполните:

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --op fix-lost

Для фиксации потерянных объектов в определённой группе размещения определите pgid:

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --pgid <pg-id> --op fix-lost

Если вы уверены в подлинности потерянного объекта, который вы хотите фиксировать, определите идентификатор этого объекта:

# ceph-objectstore-tool --data-path </path/to/osd> --journal-path </path/to/journal> --op fix-lost <object-id>

  Как это работает...

Синтаксис для ceph-objectstore-tool следующий: ceph-objectstore-tool <options>.

Значения для <options> могут быть следующими:

--data-path: путь к вашему OSD

--journal-path: путь к вашему журналу

--op: операция

--pgid: идентификатор группы размещения

--skip-journal-replay: применяйте в случае разрушения вашего журнала

--skip-mount-omap: применяйте когда ваш leveldb хранимых данных разрушен и не может быть смонтирован

--file: путь к вашему файлу, применяется с операцией импорта/ экспорта

Для лучшего понимания этого инструмента, давайте рассмотрим пример: пулимеет две копии объекта и PG размещаются в osd.1 и osd.2. На данный момент, если случится отказ, произойдёт следующая последовательность:

osd.1 отключается.

osd.2 обрабатывает все операции записи в деградированном состоянии.

osd.1 возвращается и выполняет одноранговый обмен с osd.2 для репликации данных.

Внезапно osd.2 отключается до выполнения репликации всех необходимых объектов на osd.1.

На данный момент у вас есть данные на osd.1, но они просрочены.

В результате поиска неисправностей вы определите, что вы можете прочитать свои данные osd.2 из файловой системы, но его служба osd не запускается. В такой ситуации вам следует применить ceph-objectstore-tool для экспорта/ извлечения данных с отказавшего osd. ceph-objectstore-tool предоставит вам достаточные возможности для изучения, модификации и извлечения данных объекта и метаданных.

[Замечание]
Замечание

Вам следует избегать применения средств Linux подобных cp и rsync для восстановления данных с отказавшего OSD, поскольку эти инструменты не примут во внимание все необходимые метаданные и восстановленные объекты могут быть неиспользуемыми.

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

Продолжайте Изучение, Продолжайте исследования, Продолжайте совместное применение...

Ура!

 Приложения

Перевод Understanding Erasure Coding Offload, hani, 15.02.2016.

Понимание разгрузки удаляющего кодирования

Ссылки

Что такое удаляющее кодирование Рида- Соломона?

Программные модули разгрузки удаляющего кодирования

Вычисления программным обеспечением (без разгрузки)

Аппаратная разгрузка

Синхронное кодирование вычислений

Асинхронное кодирование вычислений

Асинхронное кодирование и рассылка вычислений

Стек протоколов Mellanox OFED

Стандарт NVMe Over Fabrics

Стек протоколов Intel®

 Ссылки

Reed Solomon Tutorial: Reed Solomon Encoding Example Case (Учебное пособие по алгоритмам Рида Соломона: на примере кодирования Рида Соломона)

http://www.snia.org/sites/default/files/Luse_Kevin_SNIATutorialSwift_Object_Storage2014_final.pdf

http://www.mellanox.com/related-docs/prod_software/RDMA_Aware_Programming_user_manual.pdf

 Что такое удаляющее кодирование Рида- Соломона?

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

 Программные модули разгрузки удаляющего кодирования

Существуют различные программные модели,которые приложения могут выбрать для реализации разгрузки RAID и удаляющего кодирования (EC, Erasure Coding). Мы продемонстрируем пример кодирования 5-2 (5 блоков данных и 2 вычисляемых избыточных блока). Аппаратная реализация разгрузки удаляющих кодирования и декодирования поддерживается адаптерами Mellanox ConnectX-4.

  Вычисления программным обеспечением (без разгрузки)

Большинство приложений сегодня выполняет вычисления удаляющего кодирования (EC), после чего отправляет свои данные и избыточные блоки на соответствующие узлы/ диски (OSD). В этом случае вычисления выполняются ЦПУ и, таким образом, не существует аппаратной разгрузки. Использование ЦПУ в этом случае будет высоким в дополнение к операциям ввода/ вывода.

  Аппаратная разгрузка

При помощи адаптеров Mellanox ConnectX-4 вычисления удаляющего кодирования могут быть разгружены на ASIC адаптера. Существуют различные модели аппаратной разгрузки описываемые ниже.

Синхронное кодирование вычислений

Синхронное вычисление EC может применяться существующим программным обеспечением путём простой замены API аналогичного JErasure для применения аппаратно проводимых вычислений EC.

Шаги программирования:

Вызовите API encode_sync(data, code, block_size) - влокировка.

Отошлите данные буферов на соответствующие узлы (не существует порядковой зависимости с 1 шагом {Прим. пер.: могут выполняться одновременно}).

После возврата encode_sync() отошлите кодированные буферы на соответствующие узлы.

{Прим. пер.: снятие блокировки}.

Преимуществами здесь являются:

Лёгкое преобразование кода для работы с выполняемыми аппаратно вычислениями

Предотвращение использования ЦПУ благодаря разгрузке ваших вычислений EC

[Замечание]
Замечание

Маловероятно что латентность и скорость обмена сообщениями и/ или пропускная способность напрямую улучшатся.

Асинхронное кодирование вычислений

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

Шаги программирования:

Отошлите encode_async(data, code, block_size, ...).

Отошлите данные буферов на соответствующие узлы (не существует порядковой зависимости с 1 шагом {Прим. пер.: могут выполняться одновременно}).

Ожидайте завершения encode_async() (асинхронно), вольны тем временем выполнять задачи.

Отошлите вычисленные буферы на соответствующие узлы.

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

Асинхронное кодирование и рассылка вычислений

Обычно EC применяется для распределения хранимых объектов по множеству узлов (OSD) в кластере - эта операция называется чередованием (stripping) объекта. Использующие такую модель приложения способны отсылать структуру задания, которое включает в себя все операции чередования на адаптер и продолжать выполнение следующей задачи. Адаптер разгрузит и EC вычисления и отсылку соответствующих блоков на подходящие узлы.

Шаги программирования:

Отошлите структуру операции encode_send(data, code, block_size, nodes, ...).

Отошлите данные буферов на соответствующие узлы (не существует порядковой зависимости с 1 шагом {Прим. пер.: могут выполняться одновременно}).

Вольны продолжать выполнение задач.

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

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

 Приложения

Частичный перевод Mellanox OFED for Linux User Manual, Rev. 3.20 и связанных материалов.

Понимание разгрузки удаляющего кодирования

Стек протоколов Mellanox OFED

Введение

Обзор

Архитектура стека

Драйвер mlx4 VPI

Драйвер mlx5

Ядро среднего уровня

ULP

IP поверх IB (IPoIB)

Расширения iSCSI для RDMA (iSER)

Sockets Direct Protocol (SDP)

SCSI RDMA Protocol (SRP)

User Direct Access Programming Library (uDAPL)

MPI

InfiniBand Subnet Manager

Утилиты диагностики

Инструменты встроенного ПО Mellanox

Пакет Mellanox OFED{-}

Параметры модулей{-}

Возможности устройств

Установка{-}

Обзор функциональности и настройка{~}

Сетевая среда Ethernet{-}

Сетевая среда InfiniBand{-}

Протоколы хранилищ{~}

Протокол SCSI RDMA (SRP){~}

Sockets Direct Protocol (SDP){~}

iSCSI Extensions for RDMA (iSER){~}

Lustre{-}

Виртуализация{~}

Single Root IO Virtualization (SR-IOV){~}

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

Сборка SR-IOV{-}

Дополнительная настройка SR-IOV{-}

Деинсталяция SR-IOV{-}

Разрешение паравиртуализации{~}

Разгрузка оборудования VXLAN без запоминания состояния{~}

Разрешение разгрузки оборудования VXLAN без запоминания состояния для ConnectX®-3 и ConnectX®-3 Pro{-}

Разрешение разгрузки оборудования VXLAN без запоминания состояния для семейства устройств ConnectX®-4{-}

Важные замечания{-}

Эластичность{~}

Reset Flow{~}

ULP ядра{-}

Приложения пространства пользователя (IB/RoCE){-}

SR-IOV{-}

Принудительный сброс виртуального интерфейса (VF){-}

Усовершенствованные сообщения об ошибках (AER) для ConnectX®-3 и ConnectX®-3 Pro{-}

Расширенная обработка ошибок (EEH) {~}

HPC-X®

Утилиты системы коммуникации InfiniBand{-}

Обнаружение неисправностей{-}

Стек протоколов Intel®

 Введение

  Обзор

Mellanox OFED является единым программным стеком Virtual Protocol Interconnect (VPI), который работает на всех решениях сетевых адаптеров Mellanox для поддержания следующих восходящих связей с серверами:

Восходящая связь/ HCA
Скорость восходящей линии

ConnectX®-4

InfiniBand: SDR, QDR, FDR, EDR

Ethernet: 1GigE, 10GigE, 25GigE, 40GigE, 50GigE, 56GigE и 100GigE

ConnectX®-4 Lx

Ethernet: 1GigE, 10GigE, 25GigE, 40GigE, 50GigE

Connect-IB®

InfiniBand: SDR, QDR, FDR10, FDR

ConnectX®-3/ ConnectX®-3 Pro

InfiniBand: SDR, QDR, FDR10, FDR

Ethernet: 10GigE, 40GigE and 56GigE¹

ConnectX®-2

InfiniBand: SDR, DDR

Ethernet: 10GigE, 20GigE

PCI Express 2.0

2.5 или 5.0 GT/s

PCI Express 3.0

8 GT/s

¹ 56 GbE является внутренним стандартом Mellanox и может быть получен при использовании плат адаптеров Mellanox соединяемых коммутаторами серий Mellanox SX10XX или соединением плат адаптеров Mellanox друг с другом.

Все платы сетевых адаптеров Mellanox совместимы с протоколами на основе OpenFabrics RDMA и программного обеспечения, которое поддерживается основными дистрибутивами операционных систем.

Mellanox OFED сертифицирован со следующими продуктами:

Программное обеспечение Mellanox Messaging Accelerator (VMA®): Библиотека ускорения сокетов которая выполняет проброс операционной системы для приложений на основе стандартных сокетов.

Заметьте, пожалуйста, что поддержка VMA осуществляется отдельно от поддержки Mellanox OFED. За дополнительной информацией, пожалуйста, пользуйтесь документацией по VMA, расположенной на: www.mellanox.com > Accelerator Software > VMA

Программное обеспечение Mellanox Unified Fabric Manager (UFM®): Мощная платформа для управления масштабирования по запросу вычислительной сетевой среды окружения, построенный поверх механизма маршрутизации промышленного стандарта OpenSM.

Fabric Collective Accelerator (FCA) - FCA является пакетом программного обеспечения Mellanox объединяемого при помощи MPI, который применяет технологию CORE-Direct для реализации коллективного взаимодействия на уровне MPI.

  Архитектура стека

Рисунок 1 отображает стек Mellanox OFED и то, как протоколы верхнего уровня (ULP) взаимодейтсвуют с аппаратными средствами, а также с пространствами ядра и пользователя. Прикладной уровень также показывает универсальность рынков, к которым применим Mellanox OFED.

Рисунок 1. Стек Mellanox OFED для семейства плат адаптеров ConnectX®

Последующие подразделы вкратце описывают различные компоненты стека Mellanox OFED.

Драйвер mlx4 VPI

mlx4 является реализацией драйвера нижнего уровня для семейства адаптеров ConnectX®, разработанных Mellanox Technologies. ConnectX®2 и ConnectX®3 могут работать как адаптеры InfiniBand или как NIC Ethernet. Драйвер OFED поддерживает конфигурации InfiniBand и Ethernet. Для обеспечения конфигураций данный драйвер разветвляется на следующие модули:

mlx4_core

Обрабатывает функции нижнего уровня, такие как инициализация устройства и выполнение команд встроенного ПО. Также управляет выделением ресурсов таким образом, что InfiniBand и Ethernet могут совместно использовать одно устройство без взаимодействия друг с лругом.

mlx4_ib

Обрабатывает специфичные для InfiniBand функции и встроен в средний уровень InfiniBand

mlx4_en

Драйвер 10/40GigE под drivers/net/ethernet/mellanox/mlx4, который обрабатывает специфичные для Ethernet функции и подключается к среднему уровню netdev

Драйвер mlx5

mlx5 является реализацией драйвера нижнего уровня для семейства адаптеров Connect-IB® и ConnectX®-4, разработанных Mellanox Technologies. Connect-IB® работает как адаптер InfiniBand, в то время как и ConnectX®-4 работает как адаптер VPI (InfiniBand и Ethernet). Драйвер mlx5 включает в себя следующие модули ядра:

mlx5_core

Действует как библиотека общих функций (т.е. инициализирует устройство после его сброса) необходимых платам адаптера Connect-IB® и ConnectX®-4. Драйвер mlx5_core также реализует интерфейсы Ethernet для ConnectX®-4. В отличие от mlx4_en/core, драйверам mlx5 не требуется модуль mlx4_en, поскольку функциональность Ethernet встроена в сам модуль mlx5_core.

mlx5_ib

Обрабатывает специфичные для InfiniBand функции и встроен в средний уровень InfiniBand

libmlx5

libmlx5 является поставщиком библиотеки, которая реализует аппаратную функциональность специфичную для пространства пользователя. Если отсутствует совместимость между встроенным ПО и данным драйвером, драйвер не загрузится и в dmesg будет выведено некое сообщение.

Далее приводятся переменные окружения libmlx5:

MLX5_FREEZE_ON_ERROR_CQE:

В случае завершения с ошибкой вызывает обработку данного процесса в цикле, что не возбуждает ошибку или возникновения переполнения повторов

В противном случае запрещён

MLX5_POST_SEND_PREFER_BF:

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

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

MLX5_SHUT_UP_BF:

Запрещает функцию голубой вспышки

В противном случае не запрещает

MLX5_SINGLE_THREADED:

Любые циклы с ожиданием ресурса (spinlock) запрещены

В противном случае spinlock разрешены

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

MLX5_CQE_SIZE:

64 - размер записи очереди выполнения (CQE, completion queue entry) установлен в 64 байта (по умолчанию)

128 - размер записи очереди выполнения установлен в 128 байта

MLX5_SCATTER_TO_CQE:

Небольшие буферы рассеиваются по записи очереди выполнения и обрабатываются данным драйвером. Имеет силу для транспорта с гарантированным соединением (RC, Reliable Connected).

Значение по умолчанию 1, в противном случае запрещено

MLX5_ENABLE_CQE_COMPRESSION:

Сберегает пропускную способность PCIe сжимая несколько CQE в меньшее количество байт в PCIe. Установка в значение 1 делает возможным сжатие CQE.

Значение по умолчанию 0 (запрещёно)

Ядро среднего уровня

Службы центральной части (core) включают: интерфейс управления (MAD), интерфейс менеджера соединений (CM), а также интерфейс администратора подсети (SA). Стек включает компоненты приложений как для режима пользователя, так и ядра. Службы центральной части выполняются в ядре (kernel) и представляют интерфейс режиму пользователя для редактирования, CM и управления.

Протоколы верхнего уровня (ULP)

IP поверх IB (IPoIB)

Драйвер IP поверх IB (IPoIB) является реализацией сетевого интерфейса над InfiniBand. IPoIB инкапсулирует сетевые дейтаграммы в соединения InfiniBand или в службу транспорта дейтаграмм. IPoIB предваряет дейтаграмму IP инкапсулирующим заголовком и отправляет сквозь имеющуюся службу транспорта Infiniband. По умолчанию службой транспорта является ненадёжная доставка (UD, Unreliable Datagram), однако она может быть настроена на надёжную доставку (RC, Reliable Connected). Данный интерфейс поддерживает индивидуальную (unicast), групповую (multicast) и широковещательную (broadcast) передачи. Подробнее в разделе 3.5.2.1, "IP over IB (IPoIB)".

Расширения iSCSI для RDMA (iSER)

Расширения iSCSI для RDMA (iSER) распространяют протокол ISCSI на RDMA. Это делает возможной пересылку данных напрямую в буферы SCSI и из них без промежуточного копирования данных. Для дополнительных подробностей смотрите раздел 3.3.3, "Расширения iSCSI для RDMA (iSER)".

Sockets Direct Protocol (SDP)

Протокол непосредственных сокетов (SDP, Sockets Direct Protocol) является транспортным протоколом потоков байт, который предоставляет семантику потоков TCP. SDP использует возможности разгрузки современного протокола InfiniBand. Благодаря этому SDP может потреблять меньше ресурсов пропускной способности ЦПУ и оперативной памяти в сравнении с обычными реализациями TCP при сохранении API и семантики TCP, которые необходимы большинству современных сетевых приложений. Для дополнительных подробностей смотрите раздел 3.3.2, "Sockets Direct Protocol (SDP)".

SCSI RDMA Protocol (SRP)

SCSI RDMA Protocol (SRP) разработан для получения всех преимуществ разгрузки данного протокола и функциональности RDMA предоставляемой архитектурой InfiniBand. Драйвер SRP - называемый инициатором (Initiator) SRP - отличается от обычных драйверов нижнего уровня SCSI в Linux. Инициатор (Initiator) SCSI не управляет локальным HBA; вместо этого он управляет соединением с контроллером ввода/ вывода - называемого получателем (Target) SCSI - для предоставления доступа к удалённым устройствам хранения поверх среды коммутации InfiniBand. Получатель (Target) SRP располагается в устройстве ввода/ вывода и предоставляет службы хранения. Для дополнительных подробностей смотрите раздел 3.3.1, "SCSI RDMA Protocol (SRP)".

User Direct Access Programming Library (uDAPL)

Библиотека программирования непосредственного доступа пользователя (uDAPL, User Direct Access Programming Library) является стандартным API, который предлагает приложениям центра обработки данных производительность, масштабируемость и надёжность обмена сообщениями данных поверх интерконнекта RDMA: InfiniBand и RoCE. Интерфейс uDAPL определяется сообществом DAT.

Данная редакция пакета эталонной реализации uDAPL для обеих спецификаций DAT, и для 1.2, и для 2.0 приурочена к выпуску программного стека OFED для открытой среды коммутации (Open Fabrics www.openfabrics.org). За дополнительной информацией о сообществе DAT обратитесь к его сайту: http://www.datcollaborative.org.

MPI

Интерфейс обмена сообщениями (MPI, Message Passing Interface) является спецификацией библиотеки, которая делает возможной разработку библиотек параллельно выполняемого программного обеспечения для применения параллельных компьютеров, кластеров и разнородных сред. Mellanox OFED включает в себя следующие реализации MPI поверх InfiniBand:

Open MPI – реализацию MPI-2 с открытым исходным кодом в рамках проекта Open MPI

OSU MVAPICH – реализацию MPI-1 государственного университета Огайо (Ohio State University)

Также Mellanox OFED включает в себя эталонные тесты MPI, такие как OSU BW/LAT, Intel MPI Benchmark и Presta.

InfiniBand Subnet Manager

Всем протоколам верхнего уровня (ULP) совместимым с InfiniBand необходим соответствующим образом работающий менеджер подсети (SM, Subnet Manager), выполняющийся в среде коммутации InfiniBand, причём постоянно. SM может выполняться на любом узле или в коммутаторе IB. OpenSM является InfiniBand- совместимым менеджером подсети и поставляется как часть Mellanox OFED (По умолчанию OpenSM отключён. Подробности его подключения в раздел 3.2.2, "OpenSM").

Утилиты диагностики

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

ibutils – диагностические утилиты Mellanox Technologies

infiniband-diags – диагностические утилиты OpenFabrics Alliance InfiniBand

Инструменты встроенного ПО Mellanox

Пакет Mellanox Firmware Tools (MFT) является набором инструментария управления встроенным ПО для отдельного узла InfiniBand. MFT может применяться для:

Создания стандартного или настроенного под пользователя образа встроенного ПО Mellanox

Записи образа встроенного ПО на отдельном узле InfiniBand

MFT содержит следующие инструменты:

mlxburn – предоставляет такую функциональность:

Создания стандартного или настроенного под пользователя образа встроенного ПО Mellanox для его записи - в формате .bin или .img

Записи образа в Flash/EEPROM подключённого Mellanox HCA или устройства коммутации

Запроса версии встроенного ПО, загруженного на плату HCA

Отображение VPD (Vital Product Data) платы HCA

flint

Данный инструмент записывает двоичный образ или расширение образа ROM в Flash устройства сетевого адаптера/ моста/ коммутатора Mellanox. Он содержит функции запроса прописанного образа встроенного ПО и к файлу двоичного образа.

Утилиты отладки

Набор утилит отладки (т.е. itrace, fwtrace, mlxtrace, mlxdump, mstdump, mlxmcg, wqdump, mcra, mlxi2c, i2c, mget_temp, and pckt_drop)

За дополнительными подробностями, пожалуйста, обращайтесь к руководству пользователя MFT в docs/.

  Пакет Mellanox OFED{-}

См. источник, Mellanox OFED for Linux User Manual

  Параметры модулей{-}

См. источник, Mellanox OFED for Linux User Manual

  Возможности устройств{-}

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

В особенности, при создании QP пользователям необходимо определить максимальное число необработанных рабочих запросов, поддерживаемых QP {Прим. пер.: QP, читай: пар очередей: -цитата из osp.ru- "В основе архитектуры IB лежит способность создавать очереди команд, которые выполняются IB-устройствами. Рабочие очереди всегда создаются парами (queue pair, QP): одна — для операций посылки, другая — для операций получения. Пары идентифицируются номером.", также см. Архитектура Infiniband и OFED того же источника. Иллюстрация для наглядности:}

Рисунок 2. Стек InfiniBand

пара очередей (QP) транспортного уровня IB, источник: Introduction to InfiniBand от Mellanox

Данное значение не должно превышать возможности обслуживания очередей. Однако, даже если вы определяете вы определяете значение, которое не превышает возможности, операций (verbs) могут всё ещё отвергаться, так как тербуются некоторые другие факторы наподобие записей рассеивания/ накопления (scatter/gather) или необходимого в реальном масштабе размера данных влияют на максимальное значение возможных запросов. Следовательно приложение должно попытаться уменьшить этот размер (хорошим новым значением будет уменьшение в два раза) и повторять попытку до достижения результата.

 Установка{-}

См. источник, Mellanox OFED for Linux User Manual

 Обзор функциональности и настройка{~}

  Сетевая среда Ethernet{-}

См. источник, Mellanox OFED for Linux User Manual

Поддержка RSS{~}

Поддержка операций RSS для HCA ConnectX®-4{~}

Технология Масштабирование на стороне приема (RSS, Receive Side Scaling) позволяет распределять приходящую сетевую нагрузку между различными принимающими очередями дескрипторов. Назначение каждой очереди различным ядрам ЦПУ улучшает балансировку входящей нагрузки и улучшает производительность.

Данная технология была расширена на пространство пользователя уровнем операций (verbs) и может применяться для RAW ETH QP.

  Сетевая среда InfiniBand{-}

См. источник, Mellanox OFED for Linux User Manual

  Протоколы хранилищ{~}

Существует несколько протоколов, которые используют преимущества Infiniband и RDMA по причинам производительности (высокая пропускная способность, низкая латентность и небольшая загрузка ЦПУ). В данной главе мы обсудим следующие протоколы:

SCSI RDMA Protocol (SRP): разработан для получения всех преимуществ разгрузки протокола и функциональности RDMA предоставляемых архитектурой InfiniBand.

Sockets Direct Protocol (SDP): является транспортным протоколом потоков байт InfiniBand, предоставляющим семантику потоков TCP.

iSCSI Extensions for RDMA (iSER): является расширением модели передачи данных iSCSI, сетевого стандарта хранилищ для TCP/IP. Применяет компоненты iSCSI, при том что получает все преимущества комплекта протокола RDMA. ISER реализован на различных таргетах хранения, таких как TGT, LIO, SCST, но это выходит за пределы данного руководства.

Для этапов настройки, нахождения неисправностей и отладки различных таргетов ISER, а также прочих реализаций протоколов хранения поверх RDMA (например, NFS поверх RDMA, Ceph поверх RDMA, nbdx, и прочих) отсылаем к решениям хранения, сообщества Mellanox

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

Для получения дополнительной информации обращайтесь, пожалуйста, к решениям хранения сообщества Mellanox (https://community.mellanox.com).

Протокол SCSI RDMA (SRP){~}

Протокол SCSI RDMA (SRP) разработан для получения полного преимущества разгрузки этого протокола и функциональности RDMA, предоставляемых архитектурой Infiniband. SRP позволяет большой массе программного обеспечения SCSI легко применяться в архитектуре InfiniBand. Инициатор SRP управляет соединением с таргетом SRP для предоставления доступа к удалённым устройствам хранения через среду коммутации InfiniBand. Таргет kSRP располагается на устройстве ввода-вывода и предоставляет службы хранения.

Инициатор SRP основан на открытом программном коде OpenFabrics (www.openfabrics.org), который реализует SCSI RDMA Protocol-2 (SRP-2). SRP-2 описан в документе # T10/1524-D, доступном по адресу http://www.t10.org.

Инициатор SRP поддерживает

Основные SCSI Primary Commands -3 (SPC-3) (www.t10.org/ftp/t10/drafts/spc3/spc3r21b.pdf).

Основные SCSI Block Commands -2 (SBC-2) (www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf).

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

[Замечание]
Замечание

Данный пакет, однако, не включает таргет SRP.

Дальнейшие подробности, см. источник, Mellanox OFED for Linux User Manual

Sockets Direct Protocol (SDP){~}

[Замечание]
Замечание

Поддерживается только в ConnectX®3 и ConnectX®3 Pro.

Дальнейшие подробности, см. источник, Mellanox OFED for Linux User Manual

iSCSI Extensions for RDMA (iSER){~}

iSCSI Extensions for RDMA (iSER) распространяет протокол iSCSI на RDMA. Он делает возможной передачу данных непосредственно в буферы SCSI и из них без промежуточного копирования данных.

iSER применяет комплект протокола RDMA для поддержки наивысшей пропускной способности для обмена данных блочных хранилищ (режим работы с нулевым временем копирования). Для этого обстоятельства он прекращает обработку накладных расходов TCP/IP при сохранении полной совместимости с протоколом SCSI.

Рисунок 3. Место iSER в стеке протоколов

Существует три реализации таргета ISER:

Linux SCSI target framework (tgt)

Linux-IO target (LIO)

Generic SCSI target subsystem for Linux (SCST)

Каждый из этих таргетов может работать в транспортном режиме TCP или iSER.

iSER также поддерживает RoCE без каких либо дополнительных требований настройки. Для скрепления (bond) с интерфейсами RoCE установите параметр fail_over_mac в связываемом драйвере (см. раздел Section 3.2.5.1.5, "Bonding IPoIB" в Mellanox OFED for Linux User Manual)

RDMA/RoCE размещается ниже блока iSER в стеке сетевой среды. Для выполнения iSER уровень RDMA должен быть настроен и подтверждён (без разницы: поверх Ethernet или InfiniBand). Для поиска неисправностей RDMA, пожалуйста, обращайтесь к "HowTo Enable, Verify and Troubleshoot RDMA" в сообществе Mellanox.

Lustre{-}

См. источник, Mellanox OFED for Linux User Manual

  Виртуализация{~}

Single Root IO Virtualization (SR-IOV){~}

Single Root IO Virtualization (SR-IOV) является технологией, которая позволяет физическим устройствам PCIe представлять себя многократно через шину PCIe. Данная технология делает возможными множество экземпляров одного устройства с различными ресурсами. Адаптеры Mellanox способны выставлять в платах адаптеров ConnectX®-3 до 126 виртуальных экземпляров, называемых виртуальными функциями (VF, Virtual Functions), а платы адаптеров ConnectX®-4/ConnectX-IB до 62 виртуальных экземпляров. Эти виртуальные функции далее могут предоставляться раздельно. Каждая VF может рассматриваться как дополнительное устройство, подсоединённое к физической функции (PF, Physical Function). Они совместно используют одни и те же ресурсы в физической функции, а их общее число портов равно числу портов физической функции.

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

В данном разделе мы продемонстрируем сборку и настройку SR-IOV в среде Red Hat с применением семейства плат адаптеров ConnectX® VPI.

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

Для установки окружения SR-IOV необходимы:

Драйвер MLNX_OFED

Сервер/ блейд с BIOS материнской платы, поддерживающим SR-IOV

Гипервизор, который поддерживает SR-IOV, например: Red Hat Enterprise Linux Server Version 6.*

Плату адаптера семейства Mellanox ConnectX® VPI с возможностью SR-IOV

Сборка SR-IOV{-}

Дополнительная настройка SR-IOV{-}

Деинсталяция SR-IOV{-}

Подробности, см. источник, Mellanox OFED for Linux User Manual

Разрешение паравиртуализации{-}

См. источник, Mellanox OFED for Linux User Manual

Разгрузка оборудования VXLAN без запоминания состояния{~}

Технология VXLAN предоставляет бросающие вызов решения масштабируемости и безопасности. Она требует расширений для обычных разгружающих процедур без запоминания состояния для исключения падения производительности. Семейства адаптеров ConnectX®-3 Pro и ConnectX®-4 предлагают приводимые ниже процедуры разгрузки без запоминания состояния для пакетов VXLAN, аналогичные процедурам, предлагаемым для не инкапсулируемых пакетов. Протокол VXLAN инкапсулирует свои пакеты используя внешний заголовок UDP.

Доступные аппаратные процедуры разгрузки без запоминания состояния:

Генерация контрольной суммы (Inner IP и Inner TCP/UDP)

Подтверждение контрольной суммы (Inner IP и Inner TCP/UDP). Это позволит применять GRO (только для плат ConnectX®-3 Pro) для содержимого пакетов TCP

Разгрузка сегментации TCP (TSO, TCP Segmentation Offload) для содержимого пакетов TCP

Масштабирование на стороне приема (RSS, Receive Side Scaling) в соответствии с внутренними атрибутами пакетов

Выбор принимающей очереди - внутренние кадры могут направляться в специфические QP ( пары очередей)

Для аппаратных процедур разгрузки VXLAN без запоминания состояния необходимо выполнение следующих предварительных требований:

HCA и их минимальное встроенное ПО требуют:

ConnectX-3 Pro - Firmware v2.32.5100

ConnectX-4 - Firmware v12.14.xxxx

ConnectX-4 Lx - Firmware v14.14.xxxx

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

RHEL7, Ubuntu 14.04 или восходящее ядро 3.12.10 (или выше)

Функции, поддерживаемые upstream kernel:

DMFS enabled

A0 static mode disabled

Разрешение разгрузки оборудования VXLAN без запоминания состояния для ConnectX®-3 и ConnectX®-3 Pro{-}

Разрешение разгрузки оборудования VXLAN без запоминания состояния для семейства устройств ConnectX®-4{-}

Важные замечания{-}

См. источник, Mellanox OFED for Linux User Manual

  Эластичность{~}

Reset Flow{~}

Поток сброса (Reset Flow) активируется по умолчанию при обнаружении ошибки "fatal device" (а именно: это может быть таймаут по команде втроенного ПО, ошибка закрытия команды встроенного ПО, отсутствие ответа коммуникационного канала в виртуальном интерфейсе -VF, а также тому подобное). И HCA, и программное обеспечение выполняют сброс, а ULP и приложения пользователя получают об этом уведомления, после чего выполняется процесс восстановления. "Reset Flow" активируется параметром модуля mlx4_core 'internal_err_reset' и его значение по умолчанию установлено в 1.

ULP ядра{-}

Приложения пространства пользователя (IB/RoCE){-}

SR-IOV{-}

Принудительный сброс виртуального интерфейса (VF){-}

Усовершенствованные сообщения об ошибках (AER) для ConnectX®-3 и ConnectX®-3 Pro{-}

Расширенная обработка ошибок (EEH){-}

См. источник, Mellanox OFED for Linux User Manual

  HPC-X®

Для получения информации отсылаем вас к руководству пользователя HPC-X® www.mellanox.com > Products > Software > HPC-X > HPC-X toolkit

 Утилиты системы коммуникации InfiniBand{-}

См. источник, Mellanox OFED for Linux User Manual

 Обнаружение неисправностей{-}

См. источник, Mellanox OFED for Linux User Manual

 Приложения

Частичный перевод Руководства пользователя для сетевых адаптеров Intel®, Rev. 20.7.1 (4/5/2016) и связанных материалов.

Понимание разгрузки удаляющего кодирования

Стек протоколов Mellanox OFED

Стек протоколов Intel®

Введение

 Введение

 Приложения

09 июня 2016. Роб Дэвис

Перевод блога Mellanox

Сегодня организация NVM Express опубликовала 1 версию стандарта NVM Express over Fabrics (NVMf). Усилия по его разработке были запущены 3го сентября 2014 и благодаря стараниям большого числа компаний, включая Mellanox, были завершены. Хотя стандарт и был опубликован только сегодня, мы осуществляли испытания концепции и выполняли демонстрацию NFMf совместно с рядом партнёров и первичных потребителей адаптеров на протяжении более года.

NVMf делает возможным для нового высокопроизводительного интерфейса SSD, NVMe (Non-Volatile Memory Express) осуществлять соединения в сетевых средах, допускающих RDMA. Это первая построенная с нуля технология сетевого хранения, которая будет развиваться на протяжении 20 лет. Соединяясь с новыми скоростями Ethernet и InfiniBand которые теперь превысили 100Гб/с, NVMf не просто будет впечатляюще улучшать производительность существующих приложений сетевого хранения, но также ускорит приспособление новых и грядущих технологий, подобных горизонтальному масштабированию, определяемых ПО хранилищ, гиперконвергентных инфраструктур и рассредоточение вычислений/ хранения.

 Зачем мне хотеть этого? Потому что "быстрым хранилищам необходимы самые быстрые сети!"

Производительность технологий хранения возросла в сотни раз за последние пять лет, поскольку на рынок пришли твердотельные диски (SSD) на основе флеш- памяти и, в особенности, SSD соединяющиеся через NVMe.

Технологии носителей хранения®

Рисунок 1. Более новые хранилища экспоненциально быстрее более старых

Новые технологии Non-Volatile Memory (NVM) и Persistent Memory (PM) не за горами, что вновь даст прирост производительности в сотни раз по отношению к SSD сегодняшнего дня. Без более высокоскоростных технологий сетей и протоколов, подобных NVMf, такие новые технологии SSD и NVM окажутся запертыми внутри вашего сервера.

®

Рисунок 2. По мере уменьшения латентности хранения становятся относительно более важными латентности протоколов и сетевых сред, и они подлежат уменьшению

Так как производительность хранилищ растёт, сетевые кабели и протоколы становятся бутылочным горлышком. Мы можем ускорить кабельные соединения последними скоростями Ethernet и InfiniBand, однако также необходимы новые, более эффективные протоколы. К счастью, NVMf может быть усилен RDMA (Remote Direct Memory Access), который позволяет возвысить NVMf в сетевой среде.

®

Рисунок 3. RDMA делает возможным прямой обмен данными с отсутствием копирования, причём с аппаратным ускорением, между ОЗУ серверов, уменьшая сетевую латентность и разгружая ЦПУ этих систем.

RDMA over InfiniBand и RoCE (RDMA over Converged Ethernet) делают возможным обмен данными по сети между устройствами компьютеров и хранилищ из оперативной памяти с минимальным применением ЦПУ или даже без них. Это осуществляется при помощи аппаратной разгрузки обмена в сетевых адаптерах, которые поддерживают RDMA.

 Насколько это быстро?

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

®

Рисунок 4. Предваряющая стандарт демонстрация NVMf с сетевой средой 100GbE Mellanox показывает очень низкую латентность коммутации в сравнении с применением тех же самых NVMe локально.

Наиболее интересными данными являются добавленные значения латентности. Это разницы в латентности между SSD тестируемыми локально в сервере получателя в сопоставлении с удалённым тестированием по нашей сети с NVMf. Следует отметить, что это была ранняя версия до введения стандарта и применялись высоко оптимизированные системы инициатора и получателя, тесно интегрирующие с SSD, при дуальном 100GbE соединении с использованием адаптеров Ethernet Mellanox ConnectX-4. Однако даже удвоение или утроение этих значений демонстрирует впечатляющую производительность недостижимую при современных технологиях сетевого хранения.

 Mellanox предлагает самые лучшие сетевые среды для NVMf

Этот новый стандарт вдвойне интересен для меня, поскольку Mellanox является безусловным лидером в обеих высокоскоростных средас с RDMA. Мы владеем более чем 90 процентами рынка как для адаптеров 40GbE, так и для InfiniBand и мы были первыми на рынке с адаптерами и коммутаторами 25/50/100Гб/с Ethernet. Высокая производительность сетевых решений Mellanox помогает более быстрым NVMe SSD и более эффективным NVMf протоколам воссиять. Кроме этого, Mellanox только что анонсировал BlueField, систему с большим числом ядер на микросхемах, которые идеальны для управления и соединения полок NVMf.

®

Рисунок 5. BlueField Mellanox включает в себя высокоскоростую сетевую среду, разгрузку RDMA, множество ядер ЦПУ, большое число каналов (lane) PCIe, а также DRAM, делая его идеальным контроллером NVMe over Fabric.

 Выводы

Мне весьма повезло, или я достаточно стар, быть вовлечённым и работать над версией спецификации 1.0 Fibre Channel в 1994. Поэтому я не выдумываю, когда говорю: "Это первая новая построенная с нуля сетевая технология хранения данных на ближайшие 20 лет." Уровень возбуждения и интереса в компьютерной индустрии на более высоком уровне чем это было тогда. NVMf является идеальной технологией для заполнения недавно возникшей зияющей дыры между производительностью систем хранения и производительностью сети хранения данных. У нас в Mellanox имеется набор продуктов для заполнения этой пропасти, который мы разрабатывали и тестировали совместно с партнёрами на протяжении последних нескольких лет.

 Ресурсы

NVM Express, Inc. NVMe Over Fabrics 1.0 Specification

NVMe Over Fabrics: Open Source Linux Drivers

Mellanox Ethernet NICs: ConnectX-4 EN and ConnectX-4 Lx EN

Mellanox Bluefield Multi-core System on Chip (SoC)

Early NVMf demo with Mangstor Blog

RoCE Initiative NVMe over Fabrics using RDMA Blog

PMC Sierra (now Microsemi) Demonstrating NVMe over Fabrics Blog

Mangstor Blog

HGST+Mellanox with PCM Blog

Flash Memory Summit 2015

Flash Memory Summit 2015 Mellanox demonstrations

HGST Demo

E8 Whitepaper

The Register’s "Sexy Beast" HGST+Mellanox

 Указатель