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

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

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

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

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

Задумайтесь о системе хранения предприятия на базе RAID которая выполнена на большом количестве дисковых устройств с 4 или 6ТБ. К несчастью, когда такие диски отказывают, контроллеру 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 создаётся поверх общедоступных аппаратных средств. Такое общедоступное оборудование включает сервера промышленного стандарта загружаемые физическими дисковыми устройствами которые предоставляют ёмкость хранения и некоторую стандартную сетевую инфраструктуру. Такие сервера выполняют стандартные дистрибутивы Linux и программное обеспечение Ceph поверх них. Следующая схема поможет вам понять базовый вид кластера Ceph:

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

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

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

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

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

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

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

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

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

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

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