Официальный выпуск Ceph Luminous от производителя мы ждём в ноябре 2017, однако Proxmox 5 уже позволяет использовать в промышленных (почти) решениях некую редакцию Ceph Luminous, которая, как и полагается, в качестве основного файлового хранилища по умолчанию предлагает BlueStore. Последнее полноценно поддерживает транзакции с операциями хранения объектов, что делает возможными большое число вкусностей. Одной из них является способность осуществления частичной перезаписи данных в блочных устройствах на основе пулов с удаляющим кодированием (Erasure Coding). Такие пулы, в частности, способны (при наличии достаточного числа физических дисков и серверов) приближать использование имеющегося сырого дискового пространства сколь угодно близко к 100%. Частичная перезапись данных блочных устройств, в свою очередь, активно применяется для реализации операций Copy-On-Write.
Et voila!
Ceph предлагает два вида пулов хранения:
При стандарте допустимости двух отказавших устройств хранения, первый метод предполагает необходимость утроения сырого объема хранилища, в то время как второй допускает впечатляющее повышение эффективности использования пространства, например, до 90% при наличии возможности использовании 20 osd для расщепления данных (18 частей исходных данных + 2 части с избыточным кодом).
Поверх обоих видов пулов хранения можно строить объекты хранения, допускающие блочные операции (например, моментальные снимки). Разница начинает проявляться при операциях записи в такого рода объекты, поскольку одна операция записи в блочное устройство с применением удаляющего кодирования подразумевает в своём составе некоторую неделимую последовательность считывания хранимых данных, их частичного изменения и окончательной записи полученного результата. Атомарно. То есть, если какая- либо часть последовательности остаётся незавершённой, отвергается вся операция. Данная атомарность также именуется транзакцией.
До сих пор предлагалось два способа решения проблемы применимости пулов с удаляющим кодированием под блочные объекты:
Оба метода имеют ограничения вариантов использования.
В основе хранения объектов Ceph в конечном итоге лежит некая файловая система на физическом диске (или разделе диска), которым управляет некий демон. Для решения множества возникающих по ходу дела проблем может применяться журнал в который и записываются данные, прежде чем клиент получит подтверждение о совершении своей операции. Помимо этого демон выполняет необходимые действия в одноранговой сети пула хранения по поддержанию необходимого числа копий данных (стандартно — трёх), причём с подразделением ролей хозяин — подчинённый. Всё это, собственно, и составляет osd (object storage device). Но в конечном итоге сами данные объекта хранятся в «обычном» файле на диске. Несколько осложняет задачу тот факт, что теоретически, сам объект может сопровождаться практически неограниченным числом метаданных. Как то: имя объекта, дата его создания, дата последнего изменения, контрольная сумма, сила вашей привязанности к этим данным и всё что вы можете придумать в добавление к тем метаданным, которыми снабжает этот объект ваш инструмент хранения — файловая система, система управления блочными устройствами или объектами и т.п. Причём изменение метаданных и самого объекта хранения тоже атомарно (всё или ничего).
Долгое время сообщество Ceph пребывало в уверенности, что решить проблемы с транзакциями его объектов на нижнем уровне позволит решить btrfs, которая должна была заменить xfs и ext4, применявшиеся в основной массе случаев для оконечного хранения на физических дисках.
Время шло, проблема оставалась.
Ceph Kraken предлагает вам поэкспериментировать с BlueStore, а Ceph Luminous ставит его по умолчанию. На мой личный вкус это второе существенное новшество помимо ставшей основной в Kraken асинхронной системы обмена сообщениями, которая делает возможной, например, Распределённые вычисления поверх Ceph RADOS и AsyncMessenger и применение RDMA.
Что и как подробнее...
Операцией Copy-On-Write являются действия, при которых все изменения вначале записываются в новое место в хранилище, а по их окончанию выполняются все мероприятия, необходимые для маскирования удаляемых старых копий, что осуществляется несравненно быстрее собственно записи (грубо говоря, подмена ссылок). Это делает для нас возможным такие операции как мгновенное клонирование образов и моментальные снимки. Причём ключевым здесь является именно слово «моментальный», а время этой моментальности измеряется временем замены ограниченного числа ссылок, как правило, находящихся в одном дисковом блоке, ну или в нескольких соседних.
Материалы:
Et voila!
Методы хранения данных и блочные устройства
Ceph предлагает два вида пулов хранения:
- с репликациями
- с удаляющим кодированием
При стандарте допустимости двух отказавших устройств хранения, первый метод предполагает необходимость утроения сырого объема хранилища, в то время как второй допускает впечатляющее повышение эффективности использования пространства, например, до 90% при наличии возможности использовании 20 osd для расщепления данных (18 частей исходных данных + 2 части с избыточным кодом).
Поверх обоих видов пулов хранения можно строить объекты хранения, допускающие блочные операции (например, моментальные снимки). Разница начинает проявляться при операциях записи в такого рода объекты, поскольку одна операция записи в блочное устройство с применением удаляющего кодирования подразумевает в своём составе некоторую неделимую последовательность считывания хранимых данных, их частичного изменения и окончательной записи полученного результата. Атомарно. То есть, если какая- либо часть последовательности остаётся незавершённой, отвергается вся операция. Данная атомарность также именуется транзакцией.
До сих пор предлагалось два способа решения проблемы применимости пулов с удаляющим кодированием под блочные объекты:
- использование объекта для записи только целиком
- применение многоуровневости с пулом удаляющего кодирования в основе и пула репликаций поверх него
Оба метода имеют ограничения вариантов использования.
BlueStore как новое решение основы хранения
В основе хранения объектов Ceph в конечном итоге лежит некая файловая система на физическом диске (или разделе диска), которым управляет некий демон. Для решения множества возникающих по ходу дела проблем может применяться журнал в который и записываются данные, прежде чем клиент получит подтверждение о совершении своей операции. Помимо этого демон выполняет необходимые действия в одноранговой сети пула хранения по поддержанию необходимого числа копий данных (стандартно — трёх), причём с подразделением ролей хозяин — подчинённый. Всё это, собственно, и составляет osd (object storage device). Но в конечном итоге сами данные объекта хранятся в «обычном» файле на диске. Несколько осложняет задачу тот факт, что теоретически, сам объект может сопровождаться практически неограниченным числом метаданных. Как то: имя объекта, дата его создания, дата последнего изменения, контрольная сумма, сила вашей привязанности к этим данным и всё что вы можете придумать в добавление к тем метаданным, которыми снабжает этот объект ваш инструмент хранения — файловая система, система управления блочными устройствами или объектами и т.п. Причём изменение метаданных и самого объекта хранения тоже атомарно (всё или ничего).
Долгое время сообщество Ceph пребывало в уверенности, что решить проблемы с транзакциями его объектов на нижнем уровне позволит решить btrfs, которая должна была заменить xfs и ext4, применявшиеся в основной массе случаев для оконечного хранения на физических дисках.
Время шло, проблема оставалась.
Ceph Kraken предлагает вам поэкспериментировать с BlueStore, а Ceph Luminous ставит его по умолчанию. На мой личный вкус это второе существенное новшество помимо ставшей основной в Kraken асинхронной системы обмена сообщениями, которая делает возможной, например, Распределённые вычисления поверх Ceph RADOS и AsyncMessenger и применение RDMA.
Что и как подробнее...
Зачем нам Copy-On-Write
Операцией Copy-On-Write являются действия, при которых все изменения вначале записываются в новое место в хранилище, а по их окончанию выполняются все мероприятия, необходимые для маскирования удаляемых старых копий, что осуществляется несравненно быстрее собственно записи (грубо говоря, подмена ссылок). Это делает для нас возможным такие операции как мгновенное клонирование образов и моментальные снимки. Причём ключевым здесь является именно слово «моментальный», а время этой моментальности измеряется временем замены ограниченного числа ссылок, как правило, находящихся в одном дисковом блоке, ну или в нескольких соседних.
Материалы:
- Полное руководство работы с сетями на Python Эрик Чоу, июнь 2017, Packt Publishing
- Полное руководство Ceph Ник Фиск, май 2017, Packt Publishing
- Книга рецептов Ceph Каран Сингх, февраль 2016, Packt Publishing
- Изучаем Ceph Каран Сингх, январь 2015, Packt Publishing
- Proxmox. Полное руководство. 2е изд Васим Ахмед, август 2015, Packt Publishing
- Книга рецептов Proxmox Васим Ахмед, май 2016, Packt Publishing
- Zabbix. Полное руководство. 2е изд. Андреа Далле Ваккье, сентябрь 2015, Packt Publishing
- Пример системы виртуализации Юрий Шкандыбин, 14-10-2016
- Обзор рекомендуемых аппаратных средств, sddc.mdl.ru, 01-04-2017
- ZFS для профессионалов, Майкл В. Лукас и Аллан Джуд, Tilted Windmill Press, 10-04-2016
Поделиться с друзьями
lolipop
Краткость — с.т.
OlegBou
many thanx
OlegBou
в ответ на справедливую критику добавил пример того зачем нам всё это. Например, COW.