Компания Red Hat представила (http://ceph.com/releases/v10-2-0-jewel-released/) релиз проекта Ceph 10.2.0 (http://ceph.com/), предоставляющего инфраструктуру для создания блочных устройств и файловых систем, распределенных по тысячам машин и способных хранить эксабайты данных. Выпуск позиционируется как новый значительный релиз, который послужит основой для формирования новой ветки с длительным циклом поддержки (LTS). Пакеты сформированы для CentOS 7.x, Debian Jessie 8.x, Ubuntu 14.04/16.04 и Fedora 22+.Благодаря отсутствию единой точки отказа и репликации с хранением нескольких экземпляров данных на разных узлах Ceph позволяет добиться очень высокого уровня отказоустойчивости хранилища. При добавлении или удалении новых узлов, массив данных автоматически ребалансируется с учетом изменения конфигурации. Обработку данных и метаданных выполняют различные группы узлов в кластере, примерно как это сделано в Lustre, с тем различием, что обработка производится на уровне пользователя, не требуя какой-либо особой поддержки от ядра. В Ceph имеется поддержка снапшотов, причём снапшот может быть создан не только для ФC, но и для отдельных директорий. Ceph может работать поверх блочных устройств, внутри одного файла или через размещение данных в существующих ФС.
<center><a href="http://140.120.7.21/LinuxRef/IMG/ceph-arch-fig1.png">... src="https://www.opennet.me/opennews/pics_base/0_1461573816.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
Ceph 10.2.0 примечателен стабилизацией реализации POSIX-совместимой файловой системы CephFS (http://docs.ceph.com/docs/master/cephfs/). Как и в случае блочного устройства и объектного хранилища Ceph, файловая система CephFS разворачивается поверх распределённого кластера хранения Ceph, включающего как минимум один сервер мета-данных. Предлагается два варианта клиентской части файловой системы CephFS: модуль ядра Linux и реализация в пространстве пользователя через подсистему FUSE. В связи с переводом CephFS в разряд стабильный подсистем, некоторые возможности теперь отключены по умолчанию, например, недоступны снапшоты и конфигурации с несколькими активными серверами метаданных. До полнофункционального состояния доведена утилита для восстановления целостности ФС после сбоя. В состав включен новый модуль cephfs-volume-manager, позволяющий управлять хранилищами для OpenStack. Добавлена экспериментальная поддержка развёртывания нескольких ФС в одном кластере.
<center><a href="http://www.ibm.com/developerworks/library/l-ceph/">&... src="https://www.opennet.me/opennews/pics_base/0_1461573862.gif&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
В реализации блочного устройства RBD (Ceph Block Device) добавлена поддержка зеркалирования разделов (асинхронной репликации) с привлечением нескольких разных кластеров хранения. Репликация основана на трансляции в другой кластер журнала изменений и может использоваться для организации зеркала в территориально разнесённом хранилище, доступном через глобальную сеть. Из других новшеств отмечается поддержка динамического управления включением таких возможностей, как эксклюзивные блокировки, object-map, fast-diff и журналирование. Добавлена возможность переименования снапшотов RBD. Полностью переписан интерфейс командной строки, добавлена поддержка автодополнения ввода в bash.
В объектном хранилище RADOS (Reliable Autonomic Distributed Object Store), позволяющем организовать хранение данных из приложений на различных языках программирования и служащем основой для RBD и CephFS, представлен новый OSD-бэкенд BlueStore (Object Storage Device), который пока рассматривается как экспериментальная возможность, но в будущем запланирован для включения по умолчанию. В RADOS Gateway, прослойке для организации доступа к объектному хранилищу RADOS через типовые RESTful API (Amazon S3, OpenStack Swift), переписана и перепроектирована система межкластерного взаимодействия, что позволило реализовать возможность создания active/active конфигураций и двунаправленного восстановления (bidirectional fail-over). Добавлена экспериментальная поддержка доступа ка данным через NFS. Реализована поддержка протокола AWS4 и OpenStack Keystone v3 API.<center><a href="http://docs.ceph.com/docs/master/_images/stack.png">... src="https://www.opennet.me/opennews/pics_base/0_1461573633.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
URL: http://ceph.com/releases/v10-2-0-jewel-released/
Новость: http://www.opennet.me/opennews/art.shtml?num=44303
Отличный чертёж:
У колобков есть цилиндры и кубики. И иногда необходимо делать из кубов цилиндры и наоборот. Эта задача решается с помощью линуксового ядра в котором есть фитиль (не рванёт хоть?).
Хотя нет, мне кажется я неправильно понял иллюстрацию.
У колобков есть лишь цилиндры, но чтобы взять цилиндр в нагрузку приходится брать куб. И ещё куб можно взять отдельно без цилиндра.
Круто... Я тоже такое хочу...
Ого! С выходных не отпустило.
там клавиатура от спектрума!
снизу квадратные от спектрума плюс дырка для кассеты, а сверху цилиндрические от самодельного совецкого конпутера из чего пришлось сделанного
Кто-нибудь может рассказать что такое "новый OSD-бэкенд BlueStore"?
Попытка избавиться от прослойки в виде ФС на диске?
Да, именно так.
Кто-нибудь пробовал это использовать для локального многодискового хранилища с зеркалированием данных вместо ZFS или Btrfs?
Локальный многодисковый Ceph? Мммм, это как? :)Ceph не локальный многодисковый. Это целая инфраструктура с абсолютным минимумом в 3 ноды. Сравнение с традиционными ФС, как минимум некорректно.
Просто хочется, чтобы у всех данных были две копии на разных дисках.ZFS хреново работает с дисками непредсказуемых размеров (то есть с домашними файлопомойками и подобным зоопарком), а Btrfs ещё не отладили.
Я правильно понимаю, что Ceph тут плохая идея, с ним только совсем через задницу типа колхоза с виртуалками?
Все как и описали "совсем через задницу типа колхоза с виртуалками" :)
Тебе знакомо слово RAID 1?
Тебе знакомо слово разные размеры дисков? А добавление дисков по одному?
Тебе знакома аксиома про "Дураки должны мучиЦЦо!?"
Или семь раз отрежь, один раз отмерь?Впрочем если уж совсем подгорает пробуй Леффс http://leo-project.net/leofs/
Только ЧУР! потом никогда! никому! не говори! что я это советовал :-/
> Тебе знакома аксиома про "Дураки должны мучиЦЦо!?"Не стОит злоупотреблять словом "дурак". Тем более, в данном чисто клиническом случае.
Эээыымм?! Led - либо я ... не буду злоупотреблять, да :) но - не распарсил.
Вряд ли тебя простота слога покоробила, тут конечно не ЛОР, но и не Смольный 1916г :)
Хотя ладно, заменим на другую аксиому:
"Если пытаться автоматизировать бардак, то на выходе бардак и будет ... автоматический"
btrfs решает, я пользую. несколько лет, несколько инстансов. не прод - хобби, да.
ещё можно делать через mirroring в lvm.
ну и множество решений уровня FUSE.
Будет посложнее чем с файловой системой, но да, Сеф можно и удобно юзать когда нужно из зоопарка сделать один большой и надежный трэшкэн.
Ceph вещь хорошая, но для нормальной производительности нужно много машин и мнооого дисков.
вот поэтому надо юзать sheepdog
> Ceph вещь хорошая, но для нормальной производительности нужно много машин и мнооого
> дисков.Неверно, все зависит от метода/типа записи/чтения. Ceph очень не любит (не с BlueStore): threads =1 and depth=1. На rbd данная проблема решается созданием RAID0 на виртуальных машинах.
Отличная новость! За 5 лет работы архитектором в крупнейшем операторе связи России лично внедрил с сопроводил более 3-х проектов с Ceph. Было дело, что писал ней патчи, но баги были не критичные!
> Отличная новость! За 5 лет работы архитектором в крупнейшем операторе связи России
> лично внедрил с сопроводил более 3-х проектов с Ceph. Было дело,
> что писал ней патчи, но баги были не критичные!Что за патчи? Хочется глянуть ). Спасибо
> более 3-х проектов4?
В ceph контрольные суммы данных уже появились?ЗЫ:Крупнейший оператор связи это ведь rostelecom? Вот почему он так хреново работает...
> Крупнейший оператор связи это ведь rostelecom? Вот почему он так хреново работает...Врядли из-за этого одного анонима.
Оно всегда вообще-то было, уважаемый...
Два года назад точно не было.
Можно пруф на появление?
BeeGFS говорят лучше.
> BeeGFS говорят лучше.А работают как?
>>> недоступны ... конфигурация с несколькими активными серверами метаданныхДалее не интересно.
Зачем, если есть gluster?
Там файлы, тут блоки.
Red Hat вроде продвигали GlusterFS, а теперь уже взялись на Ceph...
Интересно.
Это под разные задачи решения.
Приветствую всех!Тема для меня интересная, а можно тут узнать, кто и что использует в продакшене, напишите пожалуйста, если не секрет. Есть задача, виртуализация всего и вся, и мы тут больше склоняемся к установке GlusterFS + oVirt. Но может быть есть более интересные решения, опробованные кем то еще!? Заранее спасибо! )
Мы используем, два ЦОДА разнесенных данных(планируется еще один). Суммарный сырой объем 1 ПБ, с тремя репликациями и кэш пулами на PCI-SSD
Конечно же есть вопросы по производительности thread=1,depth=1,sync=1 но решаемо хитрым способом - созданием RAID0 на виртуалке. Если что обращайтесь.
А вообще мы довольны и используем порядка 2 лет RBD и S3 1.5 года (под бекапы)
Как порекомендуете собрать кластер из 6 физических серверов: на каждом 16 дисков +
два физических сервера с 2 дисками. Хотелось бы собрать хранилище ceph с iscsi шлюзом для vmware
> Как порекомендуете собрать кластер из 6 физических серверов: на каждом 16 дисков
> +
> два физических сервера с 2 дисками. Хотелось бы собрать хранилище ceph с
> iscsi шлюзом для vmwareна серверах хранения есть raid контроллеры с кэшем
> на серверах хранения есть raid контроллеры с кэшемУгу. На которых батарейка через год приказывает долго жить, со всеми вытекающими.
В oVirt со стабильностью всё плохо, это все таки тестовый продукт. Пару раз пробовал, то оно со свежим ядром не хочет работать, то по NFS дико тормозит.
Плюс к этому, лично я не люблю такие ентерпраз решения которые сами ставят и настраивают кучу пакетов, сами правят сетевые и прочие конфиги на машине. В итоге сходу не понятно как это все работает и как это потом вычистить. Такое ораклоподобное решение, под которое нужно отдельного специалиста воспитывать.
Лично я бы смотрел в сторону ProxMox кластер + drbd(или ceph). В последний раз когда я пробовал хранить вируталки в glusterfs, они раз в какое-то время лочились после чего приходилось всех их перегружать.
Glusterfs максимум для хранения бэкапов. Хотя сама файловая система очень интересная, она не размазывает файл по куче серверов, а целеком хранит отдельный файл на отдельном сервере. Для восстановления после сбоя и некоторых задач это важно.
Если у вас уже образовалась гетерогенная среда, то смотрите в сторону OpenNebula.
> В oVirt со стабильностью всё плохо, это все таки тестовый продукт. Пару
> раз пробовал, то оно со свежим ядром не хочет работать, то
> по NFS дико тормозит.Начал пользовать oVirt с релиза 3.5, сейчас все мчит на актуальной версии - 3.6.4, если не ошибаюсь. NFS пользую только для экспорта/импорта виртуальных машин, так что по тормозам не скажу. Но вот с ядром ни разу не испытывал проблем.
О том, что продукт совсем безпроблемый я сказать не могу, более того - продукт таки сырой, но при определенной сноровке можно пользовать и вполне успешно. Можно привести аналогию с велосипедом: кто-то вообще не может на нем передвигаться, а кто-то при определенной сноровке может ехать и достаточно быстро.
> Плюс к этому, лично я не люблю такие ентерпраз решения которые сами
> ставят и настраивают кучу пакетов, сами правят сетевые и прочие конфиги
> на машине. В итоге сходу не понятно как это все работает
> и как это потом вычистить.1. Продукт заточен на то, что в ОС никто лезть не должен вообще. Контроль над ОС должен быть только в руках oVirt. Много ли позволено на гипервизоре администратору vmware?
2. Продукт открыт, если есть желание понять как работать - проблем в этом нет.
3. Для вычислительных узлов я бы и вовсе делал бездисковые ноды, и грузил бы их со специально подготовленной ОС (iso есть на сайте), а не ставил бы centosы/fedorы.> Такое ораклоподобное решение, под которое нужно
> отдельного специалиста воспитывать.Думаю, отдельного специалиста нужно воспитывать для любой системы виртуализации, если это не отдельный сервер с virtualbox на борту.
> Лично я бы смотрел в сторону ProxMox кластер + drbd(или ceph). В
> последний раз когда я пробовал хранить вируталки в glusterfs, они раз
> в какое-то время лочились после чего приходилось всех их перегружать.
> Glusterfs максимум для хранения бэкапов. Хотя сама файловая система очень интересная, она
> не размазывает файл по куче серверов, а целеком хранит отдельный файл
> на отдельном сервере. Для восстановления после сбоя и некоторых задач это
> важно.
> Если у вас уже образовалась гетерогенная среда, то смотрите в сторону OpenNebula.
Не "пользовать", а "использовать".
Поделюсь личной практикой по использованию oVirt - две платформы по 7 и 10 серверов, на пару десятков виртуальных машин каждая.Начну с того, что обозначу какие есть в наличии драйверы бэкенда для СХД - это NFS, GlusterFS, iSCSI и с недавних пор через куски OpenStack'а (через Cinder, если быть точнее) умеет Ceph.
Я лично отказался от хранения блочных устройств на NFS/GlusterFS: для NFS нужно избыточность городить сторонними средствами, при этом плюсов не дает никаких, GlusterFS же умеет избыточность, но работает в пространстве пользователя и при приличной нагрузке на дисковую подсистему виртуальных машин, жжем процессоры хостов.
Прикручивать Ceph к oVirt не доводилось, так что по этому пункту ничего не скажу.
Остается только iSCSI. Самый простой путь - это купить готовую полку. Но я понимаю, что тот, кто пользует oVirt денег на полку не имеет.
Я пошел по пути создания СХД в ручную - слепил из двух серверов средствами DRBD распределенное блочное устройство, которое экспортирую по протоколу iSCSI в oVirt. Так же поставил ssd и средствами dm-cache сделал кэш для жестких дисков. За работу кластера СХД отвечает стэк ПО Pacemaker/Corosync. Благодаря multipath получил доступ к СХД через две независимые физические сети с одной стороны, и увеличение пропускной способности - с другой (все построено на гигабитной сети, два линка в сторону СХД дают 2Gb/s, чего для того количества машин вполне достаточно).
К недостаткам такоого решения могу только отнести масштабируемость - она на уровне нуля. Горизонтальной масштабируемости нет вообще, вертикально - ограничиваемся числом корзин в сервере. С другой стороны oVirt не ограничивает количество СХД, поэтому можно создавать клоны и подключать как независимые.Кратко вывод. Я считаю, что любая небольшая компания, у которой число серверов перевалило за 5 штук, должна использовать виртуализацию, и oVirt+iSCSI+DRBD в качестве бесплатного решения годиться как нельзя лучше.
PS. Имею опыт построения облака OpenStack (кстати c Ceph'ом, потому, собственно, и пришел почитать новость :) ), для небольшой компании городил бы oVirt.
