Хранилище на базе Ceph: что нужно знать для эффективного использования
Ceph – это свободная программная сеть хранения, которая может работать как в файловой системе, так и с блоками. Для нас актуален именно второй случай.
Стоит отметить, что Ceph – это программное обеспечение с открытым кодом, то есть оно само по непрерывно дорабатывается силами IT-энтузиастов. Для конечного пользователя это гарантирует периодическое исправление возможных ошибок и ликвидацию уязвимостей. Работая с Ceph, вы получаете в свое распоряжение «живой» инструмент, который становится совершеннее практически в режиме реального времени.
Но вернемся к сути – Ceph представляет собой целый кластер узлов, выполняющих различные функции:
- надежное хранение данных и оперативный доступ к ним;
- репликация данных для минимизации рисков их утраты;
- балансировка нагрузки на технические мощности для обеспечения высокой отказоустойчивости.
Алгоритм работы Ceph
Ceph – это система, призванная сделать хранилище, на котором она используется, максимально гибким, масштабируемым, надежным и отказоустойчивым. Рассмотрим принципы ее работы на функциях, которые описали выше.
- Хранение данных и доступ к ним
Ceph отвечает не только за сохранность данных в хранилище, но и за его гибкое масштабирование, согласно вашим потребностям. Речь идет о возможности оперативного масштабирования до уровня эксабайт, что само по себе впечатляет. Также важную роль играет автономность в управлении компонентами кластера.
- Репликация данных
Репликация данных для гарантии их сохранности осуществляется, согласно так называемой политике репликации, которую вы можете настроить самостоятельно, определяя нужное количество копий и области их хранения.
- Балансировка нагрузки
В вашем распоряжении – кластер облачного хранилища, состоящий из отдельных технических элементов. Ceph самостоятельно распределяет по ним данные, оценивает их текущее состояние и работоспособность, а в случае выхода одного из таких элементов из строя – за считанные секунды перераспределяет нагрузку между штатно работающими компонентами системы таким образом, чтобы вы никоим образом не ощутили, что что-то пошло не так. Этот алгоритм работает и в обратную сторону – если вы подключаете к кластеру новое оборудование, Ceph практически мгновенно распознает его и дает на него равномерную нагрузку, что позволяет ускорить общую работу системы.
Преимущества работы с Ceph
Предлагая вам новый инструмент для работы с нашими сервисами, мы всегда тщательно анализируем преимущества, которые он способен предоставить.
Вот лишь краткий перечень преимуществ Ceph:
- Высокая производительность при впечатляющей емкости хранилища
С Ceph любые операции выполняются практически мгновенно, а емкость хранилища масштабируется до сотен петабайт и миллиардов объектов. Тот случай, когда в вашем распоряжении будут такие ресурсы, которые даже сложно представить.
- Упрощенная установка и автоматизация
Специалисты Rusonyx позаботились о том, чтобы установка системы была доступна вам всего в несколько кликов, а нужные обновления устанавливались автоматически. К тому же, если вы дочитаете эту статью до конца, то получите все нужные данные для эффективного старта работы с Ceph, даже если это ваш первый опыт взаимодействия с этим ПО.
- Безопасность, гарантируемая сложным шифрованием
Ceph шифрует данные как на уровне клиента, так и на уровне каждого объекта в вашем хранилище – можете быть уверены, что вся информация под надежной защитой.
- Оптимизация расходов
Гибкие возможности масштабирования вашего хранилища с Ceph, а также оптимизация использования технических ресурсов с помощью балансировки нагрузки на оборудование позволят вам существенно сэкономить на поддержке своей IT-инфраструктуры и грамотно перераспределить средства на ее развитие.
- Гарантия отказоустойчивости
Автоматизированная балансировка нагрузки на технические компоненты вашего хранилища позволит забыть о простоях работы по причине сбоев и всех негативных последствиях, которые они за собой влекут.
Термины для работы с Ceph
Работа с Ceph не отнимет у вас много времени, например, кластер можно создать с нуля всего за 5-10 минут, но при условии, что вы выполняете все необходимые действия корректно, а для этого нужно иметь представление о терминологии, которой оперирует это ПО.
Вот ключевые понятия, знание которых существенно упростит вам работу с Ceph:
- FUSE (File System in User Space) – файловая система в распоряжении пользователя хранилища.
- RADOS (Reliable Autonomic Distributed Object Store) – распределённая объектная система хранения данных файловой системы Ceph, которая состоит из самостоятельных узлов.
- OSD (Object Storage Daemon) – процесс обслуживания каждого конкретного компонента (юнита) в RADOS-кластере.
- RADOS Pool – группа OSD, которые объединены общим сводом правил. Это пространство имен для объектов, не имеющее разветвленной структуры – подкаталогов.
- PG (Placement Group) – группа, объединяющая несколько объектов, связанных логически.
- CRUSH – механизм распределения объектов на OSD в RADOS-кластере.
- MON – программное обеспечение для мониторинга Ceph.
- MGR –программное обеспечение для управления Ceph, собирающее данные о состоянии объектов со всего кластера в одном месте.
- LIBRADOS – библиотека, позволяющая приложениям обращаться непосредственно к RADOS с использованием языков C, C++, Java, Ruby, PHP.
Команды для работы с Ceph
Ознакомившись с ключевыми понятиями Ceph, самое время перейти к набору базовых команд, которые помогут вам эффективно управлять хранилищем на базе этой системы:
Команда «ceph status» позволит оперативно проверить состояние вашего кластера и корректность его работы, а «ceph -w» — продемонстрирует активность кластера в режиме реального времени.
С помощью этой команды отображается использование данных в кластере и их распределение между блоками – какой объем памяти использует каждый из них.
Команда для проверки статистики групп вашего кластера.
Команда для создания или удаления юнита в вашем кластере.
С помощью этой команды вы сможете восстановить нужный юнит, указав его идентификатор.
Важно: мы привели эти данные для того, чтобы максимально облегчить работу с, возможно, новой для вас системой, но если у вас возникнут какие-либо трудности или вопросы, специалисты технической поддержки Rusonyx всегда оперативно придут на помощь – просто обратитесь к нам по любому удобному для вас каналу связи и получите квалифицированный ответ.
Вывод
Запуск использования Ceph как системы управления блочными устройствами для облачных хранилищ Rusonyx – это взвешенный и осознанный шаг нашей команды на пути к тому, чтобы предоставлять вам лучшие сервисы, сочетающие передовые технологии, понятный интерфейс и высочайшую степень надежности. Просто попробуйте, а мы – всегда рядом, чтобы помочь.
Глава 1. Введение в систему хранения Ceph
Ceph является проектом с открытым кодом, который предоставляет определяемые программным обеспечением унифицированные решения для хранения данных. Ceph является распределенной системой хранения, которая является массивно масштабируемой и высокопроизводительной и при этом не имеет единой точки отказа. С самого начала она разрабатывалась для высокой масштабируемости, до уровней эксабайт и выше, при работе на общеупотребимых аппаратных средствах.
Ceph получил наибольшее звучание в индустрии хранения благодаря своей природе открытости, масштабируемости и распределенности. Сегодня общедоступные, частные и гибридные облачные модели являются доминирующими стратегиями для целей обеспечения массивной инфраструктуры, и Ceph становится популярной в соответствующих решениях облачных систем хранения данных. Облака рассчитывают на общеупотребимых аппаратные средства и Ceph выполняет наилучшим образом использование таких рыночных аппаратных средств для предоставления вам отказоустойчивых и высоконадежной системы хранения корпоративного уровня.
Ceph вырос и впитал в себя архитектурные принципы которые включают в себя следующие свойства:
- Все компоненты должны быть масштабируемыми
- Историю и эволюцию Ceph
- Не должно быть единой точки отказа
- Решение должно быть основано на открытом и адаптируемом программном обеспечении
- Программное обеспечение Ceph должно работать на общедоступных аппаратных средствах
- Все должно быть самоуправляемым, где это возможно
Ceph обеспечивает предприятиям огромную производительность, неограниченную масштабируемость, мощность и гибкость, тем самым помогая им избавиться от дорогих фирменных бункеров хранения. Ceph является унифицированным решением для хранения данных уровня предприятия, определяемым программным обеспечением, которое работает на стандартных аппаратных средствах, что делает его наиболее экономически эффективной и многофункциональной системой хранения. Универсальная система хранения Ceph предоставляет блочные, файловые и объектные системы хранения под одной капотом, что позволяет клиентам использовать систему хранения так, как они хотят.
Основой Ceph являются объекты, которые являются основными строительными блоками. Любойформат данных, будь то блок, объект или файл сохраняется в виде объекта внутри группы размещения кластера Ceph. Хранилища объектов, подобные Ceph, являются ответом на потребности в хранении неструктурированных данных сегодня и в будущем. Объектно ориентированная система хранения имеет свое преимущества перед над традиционными решениями на основе файлов, поскольку с использованием хранения объектов мы можем достичь независимости от платформ и аппаратных средств. Ceph разумно обращается с объектами и реплицирует каждый объект по кластерам для повышения надежности. В Ceph объекты не привязаны к физическому пути, что делает их гибкими и не зависящими от местоположения. Это делает возможным линейное масштабирование от уровня петабайт до уровня эксабайт.
История и эволюция Ceph
Ceph был разработан в Университете Калифорнии, Санта-Крус, Сейджем Вейлем в 2003 году как часть проекта его докторской диссертации. Первоначальный прототип проекта был файловой системой Ceph, написанной примерно в 40 000 строк кода на С++, который был сделан открытым в 2006 году с Lesser GNU Public License License (LGPL), чтобы для эталонной реализации и научно-исследовательской платформы. Ливерморская национальная лаборатория поддержала начальную разработку Сейджа. Период с 2003 по 2007 год был научно-исследовательским периодом для Ceph. К этому времени его основные компоненты были выявлены и началась ускоренная работа сообщества с проектом. Ceph не последовал модели двойного лицензирования, и не имеет ни одного набора свойств только для предприятий.
В конце 2007 Ceph достиг зрелости и ожидал инкубации. В этот момент в действие вошла компания DreamHost, поставщик услуг веб- хостинга и регистрации доменных имен из Лос Анджелеса. DreamHost растила Ceph с 2007 по 2011. В течение этого периода Ceph получила свою форму, существующие компоненты стали более стабильными и надежными, были реализованы различные новые функции, а также были разработаны будущие дорожные карты. Здесь Ceph обрела подлинные свойства и дорожные карты уровня предприятия. В этот период времени в проект Ceph начали вносить вклад многие разработчики, некоторыми из них были Иегуда Саде, Вейнрауб, Григорий Фарнум, Джорж Дургин, Сэмуэл Жюст, Вайдо ден Холландер и Лойк Дачари, которые присоединились к побеждающей партии Ceph.
В апреле 2012 Сейдж Вейль основал новую компанию, Inktank, которую финансировала DreamHost. Inktank была создана для широкого внедрения служб Ceph и поддержки. Inktank является компанией в поддержку Ceph, основной задачей которой является предоставление компетенций, технологических процессов инструментов и поддержки для своих корпоративных подписчиков, что позволяет им эффективно осваивать и управлять системами хранения Ceph. Сейдж был техническим директором и основателем Inktank. В 2013г Inktank привлекла для финансирования $13.5 млн. 30 апреля 2014г, Red Hat, Inc. — ведущий в мире поставщик решений с открытым кодом дал согласие на приобретение Inktank за примерно $175 млн. наличными. Некоторые клиенты Inktank включают Cisco, CERN и Deutsche Telekom, а также ее партнерами являются Dell и Alcatel-Lucent, которые все теперь стали партнерами Red Hat в области решений программно определяемых систем хранения Ceph. Для получения дополнительной информации, пожалуйста, посетите www.inktank.com
Термин Ceph является общим прозвищем, данным осьминогам; Ceph можно рассматривать как короткую форму для Cephalopod, которое относится к семейству морских животных моллюсков. Ceph имеет осьминогов в качестве своих талисмана, который представляет поведение Ceph сравнимое с осьминогом.
Слово Inktank в некотором роде связано с головоногими моллюсками. Рыбаки иногда называют головоногих моллюсков чернильными рыбами из-за их способности брызгаться чернилами. Это поясняет почему головоногие моллюски (Ceph, cephalopods), имеют какое-то отношение к чернильным рыбам (Inktank). Кроме того, Ceph и Inktank имеют много общего. Вы можете рассматривать Inktank как ThInkTank («мозговой центр») для Ceph.
Сейдж Вейль является одним из соучредителей DreamHost.
Редакции Ceph
В конце 2007 года, когда начался проект Ceph, она сначала взращивался в DreamHost. 7 мая 2008 года, Сейдж выпустил редакцию Ceph 0.2 и после этого стадии развития стали быстро развиваться. Промежутки между новыми редакциями стали короткими и Ceph теперь имеет новые обновления версий каждый следующий месяц. 3 июля 2012 года, Сейдж объявил о редакции с кодовым названием Argonaut (v0.48).Ниже перечислены основные редакции Ceph, включающие в себя долгосрочную поддержку редакций ( LTS, Long Term Support ). Для получения более подробной информации, пожалуйста, посетите https://ceph.com/category/releases/.
< Прим.пер.:29 октября 2014 >
Названия редакций Ceph следуют в алфавитном порядке; название следующей редакции будет начинаться с I < Прим.пер.: так в оригинале, наверное, правильно H (Hummer?) >.
Ceph и будущее систем хранения
Последние годы требования к системам хранения предприятий растут взрывообразным образом. Исследования показали, что данные крупных предприятий растут со скоростью от 40 до 60 процентов в год, и многие компании удваивают масштабы своих данных каждый год. По оценкам аналитиков IDC, во всем мире в 2000 году было 54.4 эксабайт общих данных в цифровом виде. В 2007 году эта величина достигла значения в 295 эксабайт, а к концу 2014 года ожидается, что она превысит 8`591 эксабайт.
Хранилища во всем мире требуют систем,которые являются единообразными, распределенными, надежными, обладающими высокой производительностью, и, что самое главное, массивно масштабируемые до уровня эксабайт и выше. Система хранения Ceph является правильным решением для растущего взрыва данных на этой планете. Причина, по которой Ceph развивается со скоростью молнии в его живом сообществе и пользователях, которые верят в мощность Ceph. Создание данных — процесс не имеющий конца. Мы не можем остановить генерацию данных, но мы должны преодолеть разрыв между созданием данных и их хранением.
Ceph заполняет именно этот зазор, его унифицированная, распределенная, экономически эффективная и масштабируемая природа является потенциальным решением для потребностей хранения данных сегодня и в будущем. Сообщество открытого кода Linux предвидело потенциал Ceph задолго, еще в 2008г оно добавило поддержку Ceph в основную ветвь ядра Linux. Это было важной вехой для Ceph, поскольку не существует его конкурента для присоединения к нему здесь.
Ceph как решение для облачного хранилища
Одной из самых проблематичных областей в развитии облачной инфраструктуры являются системы хранения. Облачная среда нуждается в хранилищах, которые могут масштабироваться и при этом иметь низкую стоимость, а также они могут быть легко интегрированы с другими компонентами структуры данной облачной среды. Необходимость такой системы хранения является жизненно важным аспектом для решения общей стоимости владения (TCO) всем проектом облака. Существует ряд традиционных производителей систем хранения, которые утверждают, что обеспечивают интеграцию в рамках облаков, однако сегодня нам нужны дополнительные функции помимо простой поддержки интеграции. Эти традиционные решения для хранения данных, возможно, казались успешными несколько лет назад, но в настоящее время они не являются хорошим кандидатом на унифицированное решение хранения для облака. Кроме того, традиционные системы хранения стоят слишком дорого для развертывания и поддержки в долгосрочной перспективе, а масштабирование вверх и наружу является для них серой зоной. Сегодня нам необходимо решение для хранения данных, которое было бы полностью пересмотрено для выполнения текущих и будущих потребностей, система, которая была бы создана на основе программного обеспечения с открытым исходным кодом и техническими средствами, которые могут обеспечить требуемую масштабируемость экономически эффективным способом.
Ceph быстро развивался в этом пространстве чтобы заполнить этот пробел для настоящего серверного облака хранения. Он занял центральное место во всех основных платформах облаков с открытым кодом, таких, как OpenStack, CloudStack и OpenNebula. Кроме того, Ceph выстроил партнерские отношения с Canonical, Red Hat и SUSE, гигантами в пространстве Linux. Эти компании уделяют много внимания Ceph — распределенным, надежным и масштабируемым кластерам хранения для их дистрибутивов Linux и программного обеспечения облаков. Ceph тесно сотрудничает с этими гигантами Linux для обеспечения надежного многофункционального серверного обеспечения систем хранения в своих облачных платформах.
Общедоступные и частные облака получают большой импульс благодаря реализации проекта OpenStack. OpenStack зарекомендовал себя как облачное решение полного цикла. Он имеет свои внутренние компоненты хранения с названием Swift для хранилища облака и Nova-Volume, также известного как Cinder, который поддерживает тома блочного хранилища для виртуальных машин.
В отличие от Swift, который ограничивается только хранением объектов, Ceph является универсальным решением для хранения блочных данных, файлов, а также объектов, и, таким образом приносит пользу OpenStack, предоставляя различные типы носителей в одном кластере хранения. Таким образом, вы можете легко и эффективно управлять хранением вашего облака OpenStack. Сообщества OpenStack и Ceph уже сотрудничали в течение многих лет в разработке полностью поддерживаемой облаком OpenStack системе хранения данных Ceph. Начиная с Folsom, который является шестой основной редакцией OpenStack, Ceph был полностью интегрирован с ним. Разработчики Ceph заверил, что Ceph хорошо работает с последней версией OpenStack, и одновременно способствуют появлению новых функций, а также корректировке ошибок. OpenStack использует одно из самых требовательных свойств Ceph, блочное устройство RADOS ( RBD, RADOS block device ), с применением своих компонентов cinder и glance. Ceph RBD помогает OpenStack c быстрой инициализации сотен экземпляров виртуальных машин, предоставляя тома- моментальные снимки и клоны, которые являются индивидуальной настройкой, и, следовательно, требуют менее требовательны к объему и чрезвычайно быстры.
Облачные платформы с Ceph в качестве механизма хранения данных обеспечивает столь необходимую гибкость для поставщиков услуг при построении решений системы хранения-как-службы и инфраструктуры-как-службы (IaaS), которые они не способны получить от других традиционных решений корпоративного уровня, поскольку они не предназначены для удовлетворения потребностей облаков. Используя Ceph в качестве механизма для платформ облаков, поставщики услуг могут предложить недорогие облачные службы для своих потребителей. Ceph позволяет им предоставлять относительно низкие цены для хранения данных при корпоративном функционале по сравнению с другими поставщиками услуг хранения, такими, как Amazon
Dell, SUSE и Canonical предлагают и предоставляют инструменты поддержки настройки и управления, такие как Dell Crowbar и Juju для автоматизированного и легкого развертывания систем хранения Ceph для своих корпоративных облачных решений OpenStack. Другие инструменты управления настройкой, такие как Puppet, Chef, SaltStack и Ansible являются довольно популярным для автоматизированного развертывания Ceph. Каждый из этих инструментов имеет открытый код, а также готовые модули Ceph, которые могут быть легко использованы для развертывания Ceph. В распределенной среде, такой как облачная, каждый компонент должен масштабироваться. Эти инструменты управления настройкой имеют важное значение для быстрого наращивания вашей инфраструктуры.
В настоящее время Ceph полностью совмести в этими инструментами, что позволяет пользователям мгновенно развертывать и расширять кластер Ceph.
Начиная с редакции OpenStack Folsom, компонента nova-volume стала называться cinder.
Ceph как определяемое программным обеспечением решение
Все клиенты, которые хотят сэкономить деньги на инфраструктуре хранения, скорее всего, очень скоро рассмотрят определяемую программным обеспечением систему хранения данных ( SDS, Software-defined Storage ). SDS может предложить хорошее решение для клиентов с крупными инвестициями в наследуемые системы хранения, которым пока еще не требуется гибкость и масштабируемость. Ceph является правильным решением SDS, которое является программным обеспечением с открытым исходным кодом, работает на любых доступных аппаратных средствах, что означает, что ни один производитель не может привязать только на себя, а также обеспечивает низкую стоимость в расчете на ГБайт. Решение SDS обеспечивает очень необходимую гибкость в отношении выбора оборудования. Пользователи могут выбрать любое доступное оборудование любого производителя и свободно проектировать гетерогенное аппаратное решение для собственных нужд. Определяемая программным обеспечением система хранения Ceph поверх этого оборудования обо всем позаботится. Она также предоставляет все свойства корпоративных систем хранения данных прямо на уровне программного обеспечения. Низкая стоимость, надежность и масштабируемость являются ее основные особенностями.
Ceph как универсальное решение для хранения данных
Определение единого решения для хранения с точки зрения поставщика системы хранения состоит из доступа на основе файлов и блоков с отдельной платформы. Окружение хранения уровня предприятие обеспечивает NAS плюс SAN с единой платформы, которая рассматривается в качестве единого решения для хранения данных. NAS и SAN технологии доказали свою успешность в конце 90-х и начале 20-х годов, но, если мы думаем о будущем, уверены ли мы, что NAS и SAN смогут управлять хранением, требующим в конечном итоге 50 лет? Имеется ли у них достаточный потенциал, чтобы управляться с многими эксабайтами данных? Вероятно нет.
В Ceph, термин унифицированные системы хранения данных является более значимым, чем то, на что претендуют существующие производители систем хранения. Ceph был разработан с нуля, чтобы быть в готовым к будущему; его строительные блоки сконструированы таким образом, что они работают с огромными объемами данных. Ceph является истинным унифицированным решение хранения данных, которое обеспечивает хранение объектов, блоков и файлов в одном едином программном уровне. Когда мы говорим о Ceph как готовой к будущему, мы прежде всего имеем в виду внимание к ее возможностям хранения объектов, которые лучше подходят для существующего сегодня замеса неструктурированных данных, чем блочные или файловые хранилища. Все в Ceph опирается на интеллектуальные объекты, будь то даже блочные или файловые хранилища.
Вместо того, чтобы управлять блоками и файлами на нижнем уровне, Ceph управляет объектами и поддерживает системы хранения на основе блоков и файлов поверх объектов. Если вы вспомните традиционную систему хранения на основе файлов, файлы адресуются с помощью пути к файлу, и таким же образом, объекты в Ceph адресуются уникальным идентификатором, и хранятся в однородном адресном пространстве. Объекты предоставляют безграничное масштабирование с повышенной производительностью за счет устранения операций с метаданными. Ceph использует алгоритм динамического вычисления того, где объект должен быть сохранен и откуда его извлечь.
Архитектура следующего поколения
Традиционные системы хранения не имеют интеллектуального способа управления метаданными. Метаданные информация (данные) о данных, которые решает, где будут записаны данные и откуда будут считаны. Традиционные системы хранения поддерживают центральную справочную таблицу для отслеживания своих метаданных; то есть, всякий раз, когда пользователь отправляет запрос на операцию чтения или записи, система хранения сначала выполняет поиск в огромной таблице метаданных, а уже после получения результатов, она выполняет операцию пользователя. Для небольших системы хранения данных вы можете не заметить падения производительности, но полагаю, что для большого кластера хранения при таком подходе Вы, несомненно, будете ограничены пределами производительности. Это также ограничивает вашу масштабируемость.
Ceph не следует за традиционными архитектурами хранения; она был создана заново с использованием архитектуры следующего поколения. Вместо того чтобы хранить метаданными и манипулировать ими, Ceph предлагает новый метод, алгоритм CRUSH. CRUSH является аббревиатурой для управляемых масштабируемым хешированием репликаций (Controlled Replication Under Scalable Hashing). Для получения более подробной информации, посетите http://ceph.com/resources/publications/. Вместо выполнении поиска в таблице метаданных для каждого клиентского запроса, алгоритм CRUSH, вычисляет по требованию где должны быть записаны данные или откуда их считывать. При наличии вычисляемых метаданных больше нет необходимости в управлении централизованной таблицей для них. Современные компьютеры удивительно быстрые и могут выполнять поиск CRUSH очень быстро. Кроме того, для уменьшения вычислительная нагрузка может быть распределена по узлам кластера, используя всю мощность распределенного хранения. CRUSH означает управление метаданными вчистую, что лучше, чем методы традиционных систем хранения.
В дополнение к этому, CRUSH имеет уникальное свойство осведомленности об инфраструктуре. Он понимает взаимодействия между различными компонентами инфраструктуры, начиная с системного диска, пула, узла, стойки, блоков распределения питания, коммутатора, и ряда в центре обработки данных, вплоть до помещения центра обработки данных и далее. Это зоны отказа для любой инфраструктуры. CRUSH сохраняет первичную копию данных и ее реплики таким образом, что данные будут доступны, даже если некоторые компоненты откажут в зоне отказа. Пользователи имеют полный контроль над определении таких зон отказа для своей инфраструктуры внутри карты CRUSH в Ceph. Это предоставляет администратору Ceph мощные средства эффективного управления данными об их собственной среде.
CRUSH придает Ceph самоуправляемсть и самовосстановливаемость. В случае отказа компоненты в зоне разрушения, CRUSH понимает какой компонент вышел из строя, и определяет эффект такого отказа в кластере.Без какого-либо административного вмешательства CRUSH осуществляет самоуправление и самовосстановление путем выполнения операции восстановления для утраченных в результате сбоя данных. CRUSH восстанавливает данные из поддерживаемых кластером копий репликаций. В каждой точке во времени кластер будет иметь более чем одну копию данных, которые будут распределены в нем.
С применением CRUSH, мы можем спроектировать весьма надежную инфраструктуру хранения не имеющей единой точки отказа. Это делает Ceph высоко масштабируемой и крайне надежной системой хранения, которая готова к будущему.
RAID — конец эпохи
Raid технология была основным строительным блоком для систем хранения данных в течение многих лет. Она оказалась успешной почти для всех видов данных, которые создавались в течение последних 30 лет. Тем не менее, все эпохи должны иметь свой конец, и на этот раз пришло время для RAID. Системы хранения на основе RAID начали проявлять ограничения и не способны обеспечивать будущие потребности в хранении.
Технология производства дисков зрела на протяжении многих лет. Производители в настоящее время выпускают диски уровня предприятия большей емкости по более низким ценам. Мы больше не говорим о дисках 450 ГБ, 600 ГБ или даже 1 ТБ, поскольку существует много других вариантов дисков с большей емкостью, лучшей производительностью доступных сегодня. Новейшие технические характеристики дисков уровня предприятия предлагают диски с объемом до 4 ТБ и даже 6 ТБ. Емкость будет продолжать увеличивается из года в год.
Подумайте о RAID-системах хранения данных корпоративного класса, которые состоят из многочисленных 4 или 6 ТБ дисков. В случае сбоя диска, RAID может потребовать многих часов и даже до нескольких дней для восстановления одного неисправного диска. Между тем, если выйдет из строя другой диск, то это приведет к хаосу. Ремонт нескольких больших дисковых накопителей с использованием RAID является обременительным процессом.
Кроме того, RAID потребляет много дисков целиком в качестве резервных. Это опять-таки влияет на совокупную стоимость владения, а если вы работаете при недостаче запасных дисков, то вы снова в беде. Механизм RAID требует набор идентичных дисков в одной группе RAID; если вы измените размер диска, скорость вращения и тип диска, вы будете сталкиваться с штрафами. Такая замена отрицательно скажется на емкости и производительности вашей системы хранения.
Основанные на RAID системы уровня предприятия часто требуют дорогостоящих аппаратных компонентов, известных как RAID- адаптеры, что опять-таки увеличивает общие затраты. RAID может столкнуться с безвыходной ситуацией, при которой ему не удается увеличить свой размер в случае, когда по достижению определенного предела у него нет возможности ни внутреннего масштабирования, ни масштабирования наружу. Вы не можете добавить больше емкости, даже если у вас есть деньги. RAID 5 может отработать отказ одного диска, а RAID 6 обрабатывает отказ двух дисков, что является максимальным для любого уровня RAID. Во время операций по восстановлению RAID если клиенты выполняют операцию, они будут скорее всего испытывать недостаток в операциях ввода/вывода, пока не завершится процесс восстановления. Наиболее лимитирующим фактором в RAID является то, что он защищает только от сбоев диска; он не может защитить от сбоя сети, серверного оборудования, ошибок операционной системы, коммутатора или территориальной аварии. Максимальная защита, которую вы можете получить от RAID это продолжение работы в случае отказа двух дисков. Вы не можете продолжать работу в случае отказа более чем двух дисков при любых обстоятельствах.
Таким образом, нам нужна система, которая может преодолеть все эти недостатки с производительностью, причем экономически эффективным способом. На сегодняшний день система хранения Ceph является лучшим ответом для решения этих проблем. Чтобы обеспечить надежность хранения данных, Ceph использует метод репликации данных; то есть, она не использует RAID, и благодаря этому просто не встречает все проблемы, с которыми можно столкнуться в системе с RAID уровня предприятия. Ceph является определяемой программным обеспечением системой хранения, поэтому нам не требуются специализированного оборудования для репликации данных. Более того, уровень репликации глубоко и индивидуально настраивается с помощью команд. Таким образом, администратор системы хранения Ceph может легко управлять фактором репликации в соответствии со своими требованиями и имеющейся инфраструктурой. В случае сбоя одного или более дисков, репликация Ceph является лучшим процессом чем восстановление в RAID. Когда диск выходит из строя, все данные расположенные на этом диске в данный момент времени начинают восстанавливаться со дисков своего уровня. Поскольку Ceph является распределенной системой, все первичные копии, а также реплицированные копии данных разбросаны по всем дисков кластера, так что никакие основные и реплицированные копии не должны располагаться на одном и том же диске, а более того, должны находиться в различных зонах отказа определяемых картой CRUSH. Таким образом, все диски кластера участвуют в восстановлении данных. Это делает операцию восстановления удивительно быстрой, причем без узких мест производительности. Такая операция восстановления не требует каких-либо запасных дисков. Данные просто реплицируются на другие диски Ceph в кластере. Ceph использует механизм весов для своих дисков. Таким образом, различия в размерах дисков не являются проблемой. Ceph хранит основанные на весе диска данные, который используются для управляемой Ceph, а также ими можно управлять с помощью пользовательских карт CRUSH.
В дополнение к методу репликаций, Ceph также поддерживает другой современный способ сохранности данных при помощи техники кодирования очистки. Пулы кодирования очистки требуют меньше места для хранения данных по сравнению с пулами репликаций. В этом процессе данные восстанавливаются или регенерируются алгоритмически путем расчета кода стирания. Вы можете использовать обе техники обеспечения надежности, а именно, репликации и кодирование стирания в одном и том же кластере Ceph, но c разными пулами устройств хранения данных. Мы узнаем больше о технике кодирования стирания в последующих главах.
Портфолио совместимости
Ceph является законченной системой хранения данных корпоративного уровня, что обеспечивает поддержку для широкого диапазона протоколов и методов доступа. Единая системы хранения Ceph поддерживает блочный и файловый доступ, а также хранение объектов. Однако, во время написания данной книги, блочные хранилища и хранилища объектов Ceph рекомендуются для промышленного использования, в то время как файловая система Ceph находится этапе проверки качества (QA) и будет готова в ближайшее время. Рассмотрим каждую из них вкратце.
Блочное хранилище Ceph
Блочные системы хранения является классом хранилищ, используемых для хранения данных в сети хранения данных. В этом типе, данные хранятся в виде томов, которые находятся в форме блоков и присоединяются к узлам. Это обеспечивает большую емкость хранения, требуемую приложениями с высокой степенью надежности и производительности. Такие блоки, в качестве томов отображаются в операционную систему и управляются ее структурой файловой системы.
Ceph представила новый протокол RBD, который теперь известен как блочное устройство Ceph. RBD обеспечивает надежные, распределенные и высоко производительные диски хранения блоков для клиентов. RBD блоки чередуются с многочисленными объектами, которые по своей природе разбросаны по всему кластеру Ceph, тем самым обеспечивая клиентам надежность хранения данных и производительность. RBD имеет встроенную поддержку ядра Linux. Другими словами, драйверы RBD прошли хорошую интеграцию с ядром Linux за последние несколько лет. Почти все разновидности операционных систем Linux имеют встроенную поддержку RBD. В дополнение к надежности и производительности, RBD также обеспечивает такие функции уровня предприятия как полные и инкрементальные моментальные снимки, слабую инициализацию (динамическое выделение), клонирование копии при записи, а также ряд других свойств. RBD также поддерживает кэширование в памяти, что резко повышает его производительность.
Ceph RBD поддерживает образы с размером достигающим 16 эксабайт. Эти образы могут быть отображены как диски в машинах Bare Metal, виртуальных машинах или в обычных машинах хостов. Ведущие в отрасли гипервизоры с открытым кодом, такие как KVM и Zen обеспечивают полную поддержку RBD и используют ее возможности для своих гостевых виртуальных машин. Другие проприетарные гипервизоры, таких как VMware и Microsoft HyperV будут поддерживаться в ближайшее время. В сообществе проводится большая работа для поддержки этих гипервизоров.
Блочное устройство Ceph обеспечивает полную поддержку облачных платформ, таких как OpenStack, CloudStack, а также другие. Были продемонстрированы успешность и многофункциональность для таких облачных платформ. В OpenStack вы можете использовать блочное устройство Ceph с компонентами cinder (для блоков) и glance (для образов). Делая это, вы можете раскручивать тысячи виртуальных машин в очень сжатые сроки, воспользовавшись функциональностью блочного хранилища Ceph копирования при записи.
Файловая система Ceph
Файловая система Ceph, также имеющая название CephFS, является POSIX-совместимой файловой системой, которая использует кластерную систему хранения Ceph для хранения пользовательских данных. CephFS имеет поддержку собственного драйвера ядра Linux, что делает CephFS высоко адаптивный через любую разновидность ОС Linux. CephFS хранит данные и метаданные раздельно, обеспечивая тем самым увеличение производительности и надежности приложениям размещающимся поверх.
Внутри кластера Ceph библиотека файловой системы Ceph (libcephfs) работает поверх библиотеки RADOS (librados), который является протоколом кластера хранения Ceph, и является общей для файловых, блочных и объектных хранилищ. Чтобы использовать CephFS, вам потребуется, по крайней мере, один настроенный на любом из узлов кластера Ceph сервер метаданных ( MDS, metadata server ). Тем не менее стоит иметь в виду, что наличие только один сервер MDS будет единая точка отказа для файловой системы Ceph. После настройки MDS клиенты могут использовать CephFS различными способами. Для установки Ceph как файловой системы, клиенты могут использовать встроенные возможности ядра Linux или могут воспользоваться драйвером ceph-fuse (файловой системой в пространстве пользователя), поставляемым сообществом Ceph.
В дополнение к этому, клиенты могут воспользоваться программами с открытым исходным кодом сторонних производителей, такими как Ganesha для NFS и Samba для SMB/CIFS. Эти программы взаимодействуют с libcephfs для хранения данных пользователя в надежном и распределенном кластере хранения Ceph. CephFS также может быть использован в качестве замены для Apache Hadoop File System (HDFS) . Это также выполняет компонент libcephfs для хранения данных в кластере Ceph. Для бесшовной реализации сообщество Ceph обеспечивает необходимый CephFS Java интерфейс для Hadoop и подключаемых программ (plugin) Hadoop. Компоненты libcephfs и librados очень гибкие, и вы можете даже создать свою собственную программу, которая взаимодействует с ними и хранит данные в оборудовании кластера хранения Ceph.
CephFS является единственным компонентом системы хранения Ceph, который на момент написания этой книги не готов для промышленного использования. Он улучшается в очень высоком темпе и, как ожидается, будет готов к промышленной эксплуатации очень скоро. В настоящее время он довольно популярен для тестирования, а также в качестве среды разработки, и был развит с функциями, необходимыми для корпоративного уровня, например, такими как динамическая ребалансировка и моментальный снимок подкаталога. Следующая диаграмма показывает различные способы использования CephFS:
Хранилище объектов Ceph
Хранение объектов является подходом к хранению данных в виде объектов, отличающимся от традиционных файлов и блоков. Хранение на основе объектов получило значительное внимание со стороны промышленности. Организации, которые ищут гибкость для своих огромных данных быстро адаптируют решения для объектного хранения данных. Ceph, как известно, истинная система хранения на основе объектов.
Ceph является распределенной системой хранения объектов, которая предоставляет интерфейс для хранения объектов через шлюз объектов Cepр, также известный как шлюз RADOS (radosgw). Шлюз RADOS использует библиотеки, такие как librgw (библиотеки шлюза RADOS) и librados , что позволяет приложению устанавливать соединение с хранилищем объектов Ceph. Ceph поставляет один из самых стабильных решений с многими владельцами для хранения объектных данных с доступом через RESTful API.
Шлюз RADOS обеспечивает интерфейс RESTful пользовательскому приложению для хранения данных в кластере хранения Ceph.
-
Интерфейсами шлюза Rados являются:
- Совместимость с Swift : Это функциональность хранения объектов для OpenStack Swift API
- Совместимость с S3 : Это функциональность хранения объектов для API Amazon S3
- API Администратора : Также известно как API управления или естественный API, который может быть использован непосредственно в приложении для получения доступа к системе хранения с целью управления
Для доступа к системе хранения объектов Ceph вы можете также обойти слой шлюза RADOS, что делает доступность более гибкой и быстрой. Библиотеки программного обеспечения librados позволяют пользовательским приложениям прямой доступ к хранилищам объектов Ceph через C, C ++, Java, Python и PHP. Хранилища объектов Ceph имеют многоузловые возможности. Таким образом, они предоставляют решения для аварийного восстановления. Многоузловая настройка хранилища объектов может быть достигнута с применением RADOS или шлюзов федерализации. Следующая диаграмма показывает различные системы API, которые могут быть использованы с Ceph:
Ceph в противовес остальным
Рынок систем хранения нуждается в переменах; проприетарные системы хранения не в состоянии обеспечить будущие потребности в хранении данных при относительно низком бюджете. После проведения закупок оборудования, лицензирования, поддержки и управления издержками проприетарные системы стоят очень дорого. В отличие от этого, технологии хранения с открытым исходным кодом хорошо зарекомендовали себя сприсущей им производительностью, надежностью, масштабируемостью и низкой совокупной стоимостью владения. Многочисленные организации с государственной собственностью, а также частные компании, университеты, научно-исследовательские и медицинские центры, а также системы высокопроизводительных вычислений уже используют некоторые решения систем хранения с открытым исходным кодом.
Тем не менее, Ceph получает потрясающую обратную связь и набирает популярность, оставляя позади другие решения для хранения данных как с открытым исходным кодом, так и проприетарные. Ниже приведены некоторые решения для хранения данных с открытым кодом < Прим. пер.: так в тексте, GPFS, например, является проприетарной файловой системой > в конкуренции с Ceph. Мы кратко обсудим недостатки этих решений для хранения данных, которые адресованы к Ceph.
GPFS
General Parallel File System (GPFS) представляет собой распределенную файловую систему, разработанную и принадлежащую компании IBM. Это проприетарная система с закрытым кодом, что делает ее менее привлекательным и трудно адаптируемой. Лицензирование и стоимость поддержки после закупки оборудования для хранения делает ее очень дорогостоящей. Кроме того, она имеет очень ограниченный набор интерфейсов хранилищ данных. Она не обеспечивает ни блочное хранение, ни доступ RESTful к системе хранения, так что это является очень ограничительным. Даже максимальная репликация данных ограничивается только тремя экземплярами, что снижает надежность системы в случае более чем одного одновременного сбоя. < Прим. пер.: получить дополнительные сведения на русском языке вы можете, например, на нашем сайте http://www.mdl.ru/Solutions/Put.htm?Nme=GPFS >
iRODS
iRODS является акронимом для интегрированной, ориентированной на правила системы хранения данных (Integrated Rule-Oriented Data System), которая является программным обеспечением управления данными с открытым исходным кодом, распространяемое согласно 3-й статье лицензии BSD. iRods не очень надежная система хранения, поскольку ее сервер метаданных iCAT является SPOF (единой точкой отказа) и это не допускает настоящей высокой доступности. Кроме того, она имеет очень ограниченный набор интерфейсов хранилищ данных. Она не обеспечивает ни блочные хранилища, ни RESTful доступ к системе хранения, что делает ее очень ограниченной. Она больше подходит для хранения небольшого количества крупных файлов, а не для одновременного хранения как файлов с малым, так и с большим размером. iRods работает в традиционном стиле, поддерживая индексы физического расположения, которое связаны с именем. Проблема возникает при множественных запросах клиентов к местоположению файла с сервера метаданных, накладывая большую вычислительную нагрузку на сервер метаданных, в результате чего возрастает зависимость от одной машины и узкие места в производительности.
HDFS
HDFS является распределенной масштабируемой файловой системой написана на Java для платформы Hadoop. HDFS не полностью POSIX-совместимая файловая система и не поддерживает блочные храниилища, что делает ее менее удобной, чем Ceph. Надежность HDFS является вопросом для обсуждения, поскольку она не очень доступная файловая система. Отдельный NameNode в HDFS является основной причиной для ее единой точки отказа и узким местом для проблем производительности. Она больше подходит для хранения небольшого количества крупных файлов, а не для одновременного хранения как малых, так и больших файлов.
Lustre
Lustre является параллельной распределенной файловой системой управляемой сообществом с открытым исходным кодом и доступно в соответствии с GNU General Public License. В Lustre один сервер отвечает за хранение и управление метаданными. Таким образом, запрос ввода/вывода от клиента полностью зависит от вычислительной мощности одного сервера, что является довольно плохим для использования на уровне предприятия. Как iRODS и HDFS, Lustre подходит для хранения небольшого количества крупных файлов, а не для одновременного хранения как малых, так и больших файлов. Как и iRODS, Lustre управляет индексным файлом, который поддерживает физические адреса, отображенные на именах файлов, что делает его архитектуру традиционной и склонной к узким местам производительности. Lustre не имеет никакого механизма для обнаружения и исправления сбоя узла. В случае отказа узла, клиенты должны подключаться к другому узлу самостоятельно. < Прим. пер.: получить дополнительные сведения на русском языке вы можете, например, на нашем сайте http://onreader.mdl.ru/Lustre/ru-lustre_manual-Part1.pdf >
Gluster
GlusterFS была первоначально разработана Gluster, которая затем был приобретена Red Hat в 2011 году. GlusterFS является масштабно подключаемой к сети файловой системой. В Gluster администраторы должны определить, стратегию размещения, используемую для хранения данных реплик в различных географических стойках. Gluster не обеспечивает блочный доступ, файловую систему и удаленную репликацию в качестве собственных встроенных функций; скорее, она предоставляет эти возможности в виде дополнений.
Ceph
Если мы сделаем сравнение между Ceph и другими решениями для хранения данных, доступными сегодня, Ceph явно выделяется из всего множества благодаря своему набору функций. Она была разработана, чтобы преодолеть ограничения существующих систем хранения, и она оказалось идеальной заменой для старых и дорогих проприетарных систем хранения данных. Она является определяемой программным обеспечением решением с открытым исходный кодом для хранения данных поверх любого доступного оборудования, что делает ее экономичным решением для систем хранения. Ceph предоставляет разнообразные интерфейсы для подключения клиентов к кластеру Ceph, тем самым увеличивая гибкость для клиентов. Для защиты данных Ceph не полагается на технологии RAID которые становятся ограниченными по различным причинам, упомянутым ранее в этой главе. Она более полагается на репликации и кодирование стирания что, как было доказано, является лучшим решением по сравнению с RAID.
Все компоненты Ceph является надежными и поддерживают высокую доступность. Если вы настроите компоненты Ceph сохраняя в виду резервирование, мы можем с уверенностью сказать, что Ceph не имеет никакой единой точки отказа, что является серьезной проблемой для других доступных сегодня решений хранения данных. Одним из самых больших преимуществ Ceph является единая природа, при которой она предоставляет встроенную функциональность решений для хранения блочных, файловых и объектных данных, в то время как другие системы хранения по-прежнему не в состоянии обеспечить такие возможности. Ceph подходит для хранения как малых, так и больших файлов без какой-либо сбоев производительности.
Ceph является распределенной системой хранения; клиенты могут выполнять быстрые транзакции с использованием Ceph. Она не следуют традиционным способам хранения данных, а именно, хранения метаданных, которые привязываются к физическому местоположению и имени файла. Она, скорее, вводит новый механизм, который позволяет клиентам динамически вычислять местоположение необходимых им данных. Это дает прирост производительности для клиента, поскольку ему больше не нужно ждать получения данные о местоположении и содержании с центрального сервера метаданных. Кроме того, размещение данных внутри кластера Ceph абсолютно прозрачно и при этом автоматическое. Ни клиент, ни администраторы не должны беспокоиться о размещении данных в другой зоне отказов. Об этом заботится интеллектуальная система Ceph.
Ceph предназначен для самоисцеления и самостоятельного управления. В случае стихийного бедствия, когда другие системы хранения не могут обеспечить надежность при множественных отказах, Ceph стоит как скала. Ceph обнаруживает и исправляет сбой в каждой зоне отказов, таких как диск, узел, сеть, стойки, ряд ЦОД, центр обработки данных и даже разных географических областях. Ceph пытается автоматически управлять ситуацией и устранять неполадки там, где это возможно, без отключения данных. Другие решения для хранения данных могут обеспечить надежность только на уровне до диска или при выходе из строя узла.
Когда дело доходит до сравнения, это лишь некоторые особенности Ceph для овладения представлением и выделением из всего множества.
Заключение
Ceph является определяемым программным обеспечением решением для хранения данных с открытым исходным кодом, которое работает на стандартных аппаратных средствах, что позволяет предприятиям избавиться от дорогих ограничительных, проприетарных систем хранения данных. Она обеспечивает единое распределенное, масштабируемое и надежное решение для хранения объектов, которое столь необходимо современным и будущим потребностям для неструктурированных данных. Необходимость хранения в мире стремительно развивается, поэтому нам необходима система хранения данных, которая является масштабируемой до уровня многих эксабайт, и при этом не затрагивает надежность хранения данных и производительность. Ceph готова к будущему и обеспечивает решение всех этих проблем с данными. Ceph пользуется спросом, поскольку она является истинным решением облачных систем хранения данных с поддержкой для почти любых облачной платформ. С любой точки зрения, Ceph является великолепным решением для хранения доступное уже сегодня.
Файловая система Ceph | Гибкие решения для хранения корпоративных данных | Ambedded
Ceph File System (CephFS) — это файловая система, совместимая с POSIX, построенная поверх распределенного объектного хранилища Ceph, RADOS. CephFS предоставляет современное, многофункциональное, высокодоступное и производительное файловое хранилище для различных приложений, включая традиционные случаи использования, такие как общие домашние каталоги, пространство для временных файлов HPC и распределенное хранилище для общих рабочих процессов. Нагрузка может линейно масштабироваться с размером базового объектного хранилища RADOS; то есть, нет шлюза или посредника, регулирующего ввод-вывод данных для клиентов.Ambedded — это поставщик высококачественного хранилища Ceph End-to-End, Файловая система Ceph, кластера Ceph, хранилищного устройства Ceph, SUSE Enterprise Storage, хранилища ARM, хранилища Kubernetes, программно-определяемого хранилища, сервера ARM, подписки SUSE на 3 года, распределенного хранилища на ARM, поставщика кластера Ceph в 3x 1U шасси из Тайваня с 2013 года.Ambedded предлагает решение для хранения данных Ceph на рынке, включая хранилище Ceph Appliance на микросерверах ARM и хранилище SUSE Enterprise на микросерверах ARM.В дополнение к решению Ceph, Ambedded также предлагает полную поддержку программного обеспечения Ceph для клиента, чтобы помочь неопытным пользователям освоить эту новую технологию без колебаний.С более чем 20-летним опытом в области программно-определяемого хранения данных, Ambedded с талантливой командой, имеющей опыт в проектировании и производстве аппаратных средств хранения данных на базе ARM.
- Главная страница
- Компания
- О Ambedded
- Новости
- Процедура послепродажного обслуживания
- Политика гарантии
- Часто задаваемые вопросы
- Privacy Policy
- Матрица хранения данных Ceph от Ambedded
- Устройство Mars 400SES SUSE Enterprise Storage
- Хранилище Ceph Appliance
- Аппаратное хранилище Ceph на HDD
- Устройство хранения NVME All Flash Ceph
- Внедрение хранения Ceph на серверах с низким энергопотреблением
- Почему Ceph-аппаратное обеспечение лучше программного решения
- Микросервер на базе ARM
- Настройка устройства
- Распределенное хранилище
- Блочное хранилище Ceph
- Файловая система Ceph
- Хранилище объектов и совместимое хранилище Amazon S3
- Простая замена оборудования
- Высокая доступность и надежность данных
- Какие сценарии использования хочет применить телекоммуникационная компания с помощью Ceph?
- Используйте хранилище Mars 400 Ceph в Edge-датацентре.
- DataComm внедряет Ceph с OpenStack для своего облачного сервиса
- Используйте Cephfs и S3 для медицинского приложения
- Используйте Ceph в качестве хранилища iSCSI с Hyper-V.
- Хранилище Ceph для многодоступного вычисления на краю сети
- Используйте Mars 400 Ceph для резервного копирования с диска на диск, восстановления после катастрофы с многоплощадочной системой RGW
- Как Mars 400 Ceph Storage защищает корпоративные данные от рэнсомваре
- Использование Ceph в среде OpenStack
- Постоянное хранение контейнеров
- Veeam резервное копирование и архивирование для работы с Ceph
- Наши офисы
- Где купить и стать партнером Ambedded
- Отправить запрос на демонстрацию и отчет о производительности.
- Отправить запрос
- Станьте партнером Ambedded.
Масштабируемое NAS, сетевое хранилище с присоединением по сети | Решения хранения Ceph | Решения хранения данных | Ambedded
Знакомство с хранилищем Ceph в картинках
Облачные файловые хранилища продолжают набирать популярность, и требования к ним продолжают расти. Современные системы уже не в состоянии полностью удовлетворить все эти требования без значительных затрат ресурсов на поддержку и масштабирование этих систем. Под системой я подразумеваю кластер с тем или иным уровнем доступа к данным. Для пользователя важна надежность хранения и высокая доступность, чтобы файлы можно было всегда легко и быстро получить, а риск потери данных стремился к нулю. В свою очередь для поставщиков и администраторов таких хранилищ важна простота поддержки, масштабируемость и низкая стоимость аппаратных и программных компонентов.
Знакомьтесь: Ceph
Ceph — это программно определяемая распределенная файловая система с открытым исходным кодом, лишенная узких мест и единых точек отказа, которая представляет из себя легко масштабируемый до петабайтных размеров кластер узлов, выполняющих различные функции, обеспечивая хранение и репликацию данных, а также распределение нагрузки, что гарантирует высокую доступность и надежность. Система бесплатная, хотя разработчики могут предоставить платную поддержку. Никакого специального оборудования не требуется.
При выходе любого диска, узла или группы узлов из строя Ceph не только обеспечит сохранность данных, но и сам восстановит утраченные копии на других узлах до тех пор, пока вышедшие из строя узлы или диски не заменят на рабочие. При этом ребилд происходит без секунды простоя и прозрачно для клиентов.
Роли узлов и демоны
Поскольку система программно определяемая и работает поверх стандартных файловых систем и сетевых уровней, можно взять пачку разных серверов, набить их разными дисками разного размера, соединить всё это счастье какой-нибудь сетью (лучше быстрой) и поднять кластер. Можно воткнуть в эти серверы по второй сетевой карте, и соединить их второй сетью для ускорения межсерверного обмена данными. А эксперименты с настройками и схемами можно легко проводить даже в виртуальной среде. Мой опыт экспериментов показывает, что самое долгое в этом процессе — это установка ОС. Если у нас есть три сервера с дисками и настроенной сетью, то поднятие работоспособного кластера с дефолтными настройками займет 5-10 минут (если все делать правильно).
Поверх операционной системы работают демоны Ceph, выполняющие различные роли кластера. Таким образом один сервер может выступать, например, и в роли монитора (MON), и в роли хранилища данных (OSD). А другой сервер тем временем может выступать в роли хранилища данных и в роли сервера метаданных (MDS). В больших кластерах демоны запускаются на отдельных машинах, но в малых кластерах, где количество серверов сильно ограничено, некоторые сервера могут выполнять сразу две или три роли. Зависит от мощности сервера и самих ролей. Разумеется, все будет работать шустрее на отдельных серверах, но не всегда это возможно реализовать. Кластер можно собрать даже из одной машины и всего одного диска, и он будет работать. Другой разговор, что это не будет иметь смысла. Следует отметить и то, что благодаря программной определяемости, хранилище можно поднять даже поверх RAID или iSCSI-устройства, однако в большинстве случаев это тоже не будет иметь смысла.
В документации перечислено 3 вида демонов:
- Mon — демон монитора
- OSD — демон хранилища
- MDS — сервер метаданных (необходим только в случае использования CephFS)
Структура хранения
Для начала коротко и непонятно. Кластер может иметь один или много пулов данных разного назначения и с разными настройками. Пулы делятся на плейсмент-группы. В плейсмент-группах хранятся объекты, к которым обращаются клиенты. На этом логический уровень заканчивается, и начинается физический, потому как за каждой плейсмент-группой закреплен один главный диск и несколько дисков-реплик (сколько именно зависит от фактора репликации пула). Другими словами, на логическом уровне объект хранится в конкретной плейсмент-группе, а на физическом — на дисках, которые за ней закреплены. При этом диски физически могут находиться на разных узлах или даже в разных датацентрах.
Далее подробно & понятно.
Фактор репликации (RF)
Фактор репликации — это уровень избыточности данных. Количество копий данных, которое будет храниться на разных дисках. За этот параметр отвечает переменная size. Фактор репликации может быть разным для каждого пула, и его можно менять на лету. Вообще, в Ceph практически все параметры можно менять на лету, мгновенно получая реакцию кластера. Сначала у нас может быть size=2, и в этом случае, пул будет хранить по две копии одного куска данных на разных дисках. Этот параметр пула можно поменять на size=3, и в этот же момент кластер начнет перераспределять данные, раскладывая еще одну копию уже имеющихся данных по дискам, не останавливая работу клиентов.
Пул — это логический абстрактный контейнер для организации хранения данных пользователя. Любые данные хранятся в пуле в виде объектов. Несколько пулов могут быть размазаны по одним и тем же дискам (а может и по разным, как настроить) с помощью разных наборов плейсмент-групп. Каждый пул имеет ряд настраиваемых параметров: фактор репликации, количество плейсмент-групп, минимальное количество живых реплик объекта, необходимое для работы и т. д. Каждому пулу можно настроить свою политику репликации (по городам, датацентрам, стойкам или даже дискам). Например, пул под хостинг может иметь фактор репликации size=3, а зоной отказа будут датацентры. И тогда Ceph будет гарантировать, что каждый кусочек данных имеет по одной копии в трех датацентрах. Тем временем, пул для виртуальных машин может иметь фактор репликации size=2, а уровнем отказа уже будет серверная стойка. И в этом случае, кластер будет хранить только две копии. При этом, если у нас две стойки с хранилищем виртуальных образов в одном датацентре, и две стойки в другом, система не будет обращать внимание на датацентры, и обе копии данных могут улететь в один датацентр, однако гарантированно в разные стойки, как мы и хотели.
Плейсмент-группа (PG)
Плейсмент-группы — это такое связующее звено между физическим уровнем хранения (диски) и логической организацией данных (пулы).
Каждый объект на логическом уровне хранится в конкретной плейсмент-группе. На физическом же уровне, он лежит в нужном количестве копий на разных физических дисках, которые в эту плейсмент-группу включены (на самом деле не диски, а OSD, но обычно один OSD это и есть один диск, и для простоты я буду называть это диском, хотя напомню, за ним может быть и RAID-массив или iSCSI-устройство). При факторе репликации size=3, каждая плейсмент группа включает в себя три диска. Но при этом каждый диск находится во множестве плейсмент-групп, и для каких то групп он будет первичным, для других — репликой. Если OSD входит, например, в состав трех плейсмент-групп, то при падении такого OSD, плейсмент-группы исключат его из работы, и на его место каждая плейсмент-группа выберет рабочий OSD и размажет по нему данные. С помощью данного механизма и достигается достаточно равномерное распределение данных и нагрузки. Это весьма простое и одновременно гибкое решение.
Мониторы
Монитор — это демон, выполняющий роль координатора, с которого начинается кластер. Как только у нас появляется хотя бы один рабочий монитор, у нас появляется Ceph-кластер. Монитор хранит информацию о здоровье и состоянии кластера, обмениваясь различными картами с другими мониторами. Клиенты обращаются к мониторам, чтобы узнать, на какие OSD писать/читать данные. При разворачивании нового хранилища, первым делом создается монитор (или несколько). Кластер может прожить на одном мониторе, но рекомендуется делать 3 или 5 мониторов, во избежание падения всей системы по причине падения единственного монитора. Главное, чтобы количество оных было нечетным, дабы избежать ситуаций раздвоения сознания (split-brain). Мониторы работают в кворуме, поэтому если упадет больше половины мониторов, кластер заблокируется для предотвращения рассогласованности данных.
OSD (Object Storage Device)
OSD — это юнит хранилища, который хранит сами данные и обрабатывает запросы клиентов, обмениваясь данными с другими OSD. Обычно это диск. И обычно за каждый OSD отвечает отдельный OSD-демон, который может запускаться на любой машине, на которой установлен этот диск. Это второе, что нужно добавлять в кластер, при разворачивании. Один монитор и один OSD — минимальный набор для того, чтобы поднять кластер и начать им пользоваться. Если на сервере крутится 12 дисков под хранилище, то на нем будет запущено столько же OSD-демонов. Клиенты работают непосредственно с самими OSD, минуя узкие места, и достигая, тем самым, распределения нагрузки. Клиент всегда записывает объект на первичный OSD для какой-то плейсмент группы, а уже дальше данный OSD синхронизирует данные с остальными (вторичными) OSD из этой же плейсмент-группы. Подтверждение успешной записи может отправляться клиенту сразу же после записи на первичный OSD, а может после достижения минимального количества записей (параметр пула min_size). Например если фактор репликации size=3, а min_size=2, то подтверждение об успешной записи отправится клиенту, когда объект запишется хотя бы на два OSD из трех (включая первичный).
При разных вариантах настройки этих параметров, мы будем наблюдать и разное поведение.
Если size=3 и min_size=2: все будет хорошо, пока 2 из 3 OSD плейсмент-группы живы. Когда останется всего лишь 1 живой OSD, кластер заморозит операции данной плейсмент-группы, пока не оживет хотя бы еще один OSD.
Если size=min_size, то плейсмент-группа будет блокироваться при падении любого OSD, входящего в ее состав. А из-за высокого уровня размазанности данных, большинство падений хотя бы одного OSD будет заканчиваться заморозкой всего или почти всего кластера. Поэтому параметр size всегда должен быть хотя бы на один пункт больше параметра min_size.
Если size=1, кластер будет работать, но смерть любой OSD будет означать безвозвратную потерю данных. Ceph дозволяет выставить этот параметр в единицу, но даже если администратор делает это с определенной целью на короткое время, он риск берет на себя.
Диск OSD состоит из двух частей: журнал и сами данные. Соответственно, данные сначала пишутся в журнал, затем уже в раздел данных. С одной стороны это дает дополнительную надежность и некоторую оптимизацию, а с другой стороны — дополнительную операцию, которая сказывается на производительности. Вопрос производительности журналов рассмотрим ниже.
Алгоритм CRUSH
В основе механизма децентрализации и распределения лежит так называемый CRUSH-алгоритм (Controlled Replicated Under Scalable Hashing), играющий важную роль в архитектуре системы. Этот алгоритм позволяет однозначно определить местоположение объекта на основе хеша имени объекта и определенной карты, которая формируется исходя из физической и логической структур кластера (датацентры, залы, ряды, стойки, узлы, диски). Карта не включает в себя информацию о местонахождении данных. Путь к данным каждый клиент определяет сам, с помощью CRUSH-алгоритма и актуальной карты, которую он предварительно спрашивает у монитора. При добавлении диска или падении сервера, карта обновляется.
Благодаря детерминированности, два разных клиента найдут один и тот же однозначный путь до одного объекта самостоятельно, избавляя систему от необходимости держать все эти пути на каких-то серверах, синхронизируя их между собой, давая огромную избыточную нагрузку на хранилище в целом.
Клиент хочет записать некий объект object1 в пул Pool1. Для этого он смотрит в карту плейсмент-групп, которую ему ранее любезно предоставил монитор, и видит, что Pool1 разделен на 10 плейсмент-групп. Далее с помощью CRUSH-алгоритма, который на вход принимает имя объекта и общее количество плейсмент-групп в пуле Pool1, вычисляется ID плейсмент-группы. Следуя карте, клиент понимает, что за этой плейсмент-группой закреплено три OSD (допустим, их номера: 17, 9 и 22), первый из которых является первичным, а значит клиент будет производить запись именно на него. Кстати, их три, потому что в этом пуле установлен фактор репликации size=3. После успешной записи объекта на OSD_17, работа клиента закончена (это если параметр пула min_size=1), а OSD_17 реплицирует этот объект на OSD_9 и OSD_22, закрепленные за этой плейсмент-группой. Важно понимать, что это упрощенное объяснение работы алгоритма.
По умолчанию наша CRUSH-карта плоская, все ноды находятся в одном пространстве. Однако, можно эту плоскость легко превратить в дерево, распределив серверы по стойкам, стойки по рядам, ряды по залам, залы по датацентрам, а датацентры по разным городам и планетам, указав какой уровень считать зоной отказа. Оперируя такой новой картой, Ceph будет грамотнее распределять данные, учитывая индивидуальные особенности организации, предотвращая печальные последствия пожара в датацентре или падения метеорита на целый город. Более того, благодаря этому гибкому механизму, можно создавать дополнительные слои, как на верхних уровнях (датацентры и города), так и на нижних (например, дополнительное разделение на группы дисков в рамках одного сервера).
Кэширование
Ceph предусматривает несколько способов увеличения производительности кластера методами кэширования.
Primary-Affinity
У каждого OSD есть несколько весов, и один из них отвечает за то, какой OSD в плейсмент-группе будет первичным. А, как мы выяснили ранее, клиент пишет данные именно на первичный OSD. Так вот, можно добавить в кластер пачку SSD дисков, сделав их всегда первичными, снизив вес primary-affinity HDD дисков до нуля. И тогда запись будет осуществляться всегда сначала на быстрый диск, а затем уже не спеша реплицироваться на медленные. Этот метод самый неправильный, однако самый простой в реализации. Главный недостаток в том, что одна копия данных всегда будет лежать на SSD и потребуется очень много таких дисков, чтобы полностью покрыть репликацию. Хотя этот способ кто-то и применял на практике, но его я скорее упомянул для того, чтобы рассказать о возможности управления приоритетом записи.Вынос журналов на SSD
Вообще, львиная доля производительности зависит от журналов OSD. Осуществляя запись, демон сначала пишет данные в журнал, а затем в само хранилище. Это верно всегда, кроме случаев использования BTRFS в качестве файловой системы на OSD, которая может делать это параллельно благодаря технике copy-on-write, но я так и не понял, насколько она готова к промышленному применению. На каждый OSD идет собственный журнал, и по умолчанию он находится на том же диске, что и сами данные. Однако, журналы с четырёх или пяти дисков можно вынести на один SSD, неплохо ускорив операции записи. Метод не очень гибкий и удобный, но достаточно простой. Недостаток метода в том, что при вылете SSD с журналом, мы потеряем сразу несколько OSD, что не очень приятно и вносит дополнительные трудности во всю дальнейшую поддержку, которая скалируется с ростом кластера.Кэш-тиринг
Ортодоксальность данного метода в его гибкости и масштабируемости. Схема такова, что у нас есть пул с холодными данными и пул с горячими. При частом обращении к объекту, тот как бы нагревается и попадает в горячий пул, который состоит из быстрых SSD. Затем, если объект остывает, он попадает в холодный пул с медленными HDD. Данная схема позволяет легко менять SSD в горячем пуле, который в свою очередь может быть любого размера, ибо параметры нагрева и охлаждения регулируются.С точки зрения клиента
Ceph предоставляет для клиента различные варианты доступа к данным: блочное устройство, файловая система или объектное хранилище.
Блочное устройство (RBD, Rados Block Device)
Ceph позволяет в пуле данных создать блочное устройство RBD, и в дальнейшем смонтировать его на операционных системах, которые это поддерживают (на момент написания статьи были только различные дистрибутивы linux, однако FreeBSD и VMWare тоже работают в эту сторону). Если клиент не поддерживает RBD (например Windows), то можно использовать промежуточный iSCSI-target с поддержкой RBD (например, tgt-rbd). Кроме того, такое блочное устройство поддерживает снапшоты.Файловая система CephFS
Клиент может смонтировать файловую систему CephFS, если у него linux с версией ядра 2.6.34 или новее. Если версия ядра старше, то можно смонтировать ее через FUSE (Filesystem in User Space). Для того, чтобы клиенты могли подключать Ceph как файловую систему, необходимо в кластере поднять хотя бы один сервер метаданных (MDS)Шлюз объектов
С помощью шлюза RGW (RADOS Gateway) можно клиентам дать возможность пользоваться хранилищем через RESTful Amazon S3 или OpenStack Swift совместимое API.И другие.
Все эти уровни доступа к данным работают поверх уровня RADOS. Список можно дополнить, разработав свой слой доступа к данным с помощью librados API (через который и работают перечисленные выше слои доступа). На данный момент есть биндинги C, Python, Ruby, Java и PHPRADOS (Reliable Autonomic Distributed Object Store), если в двух словах, то это слой взаимодействия клиентов и кластера.
Википедия гласит, что сам Ceph написан на C++ и Python, а в разработке принимают участие компании Canonical, CERN, Cisco, Fujitsu, Intel, Red Hat, SanDisk, and SUSE.
Впечатления
Зачем я все это написал и нарисовал картинков? Затем что не смотря на все эти достоинства, Ceph либо не очень популярен, либо люди кушают его втихомолку, судя по количеству информации о нем в интернете.
То, что Ceph гибкий, простой и удобный, мы выяснили. Кластер можно поднять на любом железе в обычной сети, потратив минимум времени и сил, при этом Ceph сам будет заботиться о сохранности данных, предпринимая необходимые меры в случае сбоев железа. В том, что Ceph гибкий, простой и масштабируемый сходится множество точек зрения. Однако отзывы о производительности встречаются весьма разнообразные. Возможно кто-то не справился с журналами, кого-то подвела сеть и задержки в операциях ввода/вывода. То есть, заставить кластер работать — легко, но заставить его работать быстро — возможно, сложнее. Посему, я взываю к ИТ-специалистам, которые имеют опыт использования Ceph в продакшене. Поделитесь в комментариях о своих отрицательных впечатлениях.
Ссылки