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

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

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

Рисунок 2.1. Форматы хранения 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 и применять их.

Все обычные хосты 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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, последняя версия достуна тут ) >.

В последние несколько лет 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