Комментарии 49
Нравится ваш стиль повествования. Спасибо за статью :)
Картинка — просто первое, что под руку подвернулось? «Казалось бы, причём тут Swordfish?»
На картинке дяденька разворачивает кластер за отведенные ему 10 минут
Строго говоря, в том ролике не кластер он разворачивает. Хотя о вкусах не спорят.
Вы правы, надо было взять фотографию облака и поместить на нее фотографию счастливой семьи, как в лучших традициях рекламы майонеза и облачных технологий.
Ну так поставьте не кадр из ролика — вырванный из контекста — а сам ролик. Посмотрим на реакцию сообщества.
Так давайте я поставлю весь фильм сразу, чтоб не вырывать ролик из контекста фильма? Что вас не устраивает, я не понимаю? Те, кто не смотрел фильм, не поняли шутку и пошли читать дальше, потому что эта статья — не обзор к фильму, а про кластеры. Те, кто уже смотрел фильм, ничего нового даже в вашем ролике не увидят.
А по второму скриншоту из фильма у вас замечаний не будет? Они там между прочим процесс создания детей обсуждают, да простит меня партия.
А по второму скриншоту из фильма у вас замечаний не будет? Они там между прочим процесс создания детей обсуждают, да простит меня партия.
Не знаю как кто, но лично я ролики смотрю крайне редко. Особенно в образовательных целях.
На картинке дяденька разворачивает кластер за отведенные ему 10 минут
ага, как-то так:
Поставил +2!
Теперь снизим size до 2, а min_size до 1
Зачем? Вот зачем ты это делаешь?
Я то обычно знаю, зачем я это делаю, а ты?
Поначитаются инструкций подобных этой, запустят CEPH «О вроде работает, давайте в прод», потом получаем второй кладумаус и нытьё, что CEPH теряет данные и вообще тормозит.
Для тех кто не в курсе. size это количество копий данных в конкретном пуле. В случае size 2 у вас будет хранится в пуле 2 копии. Параметр min_size есть нижнее ограничение при котором останаливается запись в кластер. Сделано это, что бы не поймать не поломать данные до конца.
Ну и что, спросите вы? А то, что при таком конфиге вы не переживете вылета двух дисков из разных нод ибо теряете сразу две копии файла. Ок, для тестов в виртуалках это еще сгодится, но рядом с такими вещами обязательно надо писать, красными буквами, что это только для тестов. А лучше и для тестов использовать тройную реплику и спать спокойно всегда.
p.s. Если у вас есть вопросы по ceph и вы не знаете куда их задать, то присоединяйтесь к нашему сообществу в телеграм https://t.me/ceph_ru
Подскажите, это должны сойтись звезды, чтобы вылетели два диска на разных нодах с одинаковыми блоками? или просто с двух нод вылетело по случайному диску и пул уже неработоспособен?
Какие рекомендации? фактор репликации минимум 3? 60% места уйдет только под копии блоков?
Какие рекомендации? фактор репликации минимум 3? 60% места уйдет только под копии блоков?
Зависит от заполненности пула, количества ОСД и соотношения звезд. Если у вас кластер из 2х нод и 4х осд и size =2 забит на 80%, то да, при выпадении двух дисков вы скорее всего потеряете данные.
Фактор репликации 3, это при 90тб объема хранилища полезного у вас будет 30тб.
Фактор репликации 3, это при 90тб объема хранилища полезного у вас будет 30тб.
разных нодах с одинаковыми блоками?
Сeph не оперирует блоками, а оперирует PG (я их называю группами размещения). Количество репликации как раз указывает на количество копий этих самых PG в пуле.
Какие рекомендации? фактор репликации минимум 3?
Из рекомендаций size=3, min_size=2, при необходимости и осознанности действий на время можно выставлять min_size=1.
по случайному диску и пул уже неработоспособен?
При потере данных из PG, блокируется только PG, а не Pool целиком.
это должны сойтись звезды
К сожалению это случается, и на моей практике тоже. Банально сбой подачи электричества и вы можете получить сбой дисков на серверах. Понятно. что это зависит от построения CRUSH-карты, но для небольших установок, настройки CRUSH по умолчанию более чем достаточно.
Думаете, кто-то тут не понимает, что если из двух дисков вылетят оба, то данные будут потеряны? Что лучше для сохранности данных size=2 min_size=1 или вообще не использовать репликацию?
вы бы статью хоть прочитали, я не знаю
А в чём разница в отказоустойчивости широко применяемого raid10 на hardware raid контроллерах и набора параметров size = 2, а min_size = 1 в ceph?
По моему, это даёт одинаковый уровень отказоустойчивости.
При этом raid10 считается надежным решением, а для программно определяемых хранилищ данных такой уровень считается уже недостаточным.
P.S.
Чтобы спать спокойно всегда, нужно не забывать, что «системные администраторы делятся на тех, кто ещё не делает бэкапы, тех кто уже делает и тех кто ещё и регулярно проверяет создающиеся бэкапы».
По моему, это даёт одинаковый уровень отказоустойчивости.
При этом raid10 считается надежным решением, а для программно определяемых хранилищ данных такой уровень считается уже недостаточным.
P.S.
А лучше и для тестов использовать тройную реплику и спать спокойно всегда.
Чтобы спать спокойно всегда, нужно не забывать, что «системные администраторы делятся на тех, кто ещё не делает бэкапы, тех кто уже делает и тех кто ещё и регулярно проверяет создающиеся бэкапы».
в чём разница в отказоустойчивости широко применяемого raid10 на hardware raid контроллерах
По сути разница в том, что вы отдаете полностью сырой диск Ceph и он уже сам решает, что-куда положить и в каком количестве. В Ceph чем больше дисков, тем выше производительность(при использовании многопоточности конечно), даже при объединении одинакового количества дисков в райд 0. И Ceph позиционируется как «без вендерно»
Чтобы спать спокойно всегда, нужно не забывать, что «системные администраторы делятся на тех, кто ещё не делает бэкапы, тех кто уже делает и тех кто ещё и регулярно проверяет создающиеся бэкапы».Это точно!
— ceph: " отдаем полностью сырой диск Ceph и он уже сам решает, что-куда положить и в каком количестве"
— hardware raid controller: отдаете полностью сырой диск hardware raid controller'у и он уже сам решает, что-куда положить и в каком количестве
— ceph, size = 2: данные дважды размещены на различных дисках
— hardware raid controller raid10: каждый блок данных размещен на 2х различных дисках
По моему, тождественно.
Почему raid10 считается нормальным уровнем отказоустойчивости хранения данных, а для ceph (и других программно определяемых хранилищ в разных статьях) такой уровень считается низким?
— hardware raid controller: отдаете полностью сырой диск hardware raid controller'у и он уже сам решает, что-куда положить и в каком количестве
— ceph, size = 2: данные дважды размещены на различных дисках
— hardware raid controller raid10: каждый блок данных размещен на 2х различных дисках
По моему, тождественно.
Почему raid10 считается нормальным уровнем отказоустойчивости хранения данных, а для ceph (и других программно определяемых хранилищ в разных статьях) такой уровень считается низким?
По занимаемому месту да, но на самом деле не тождественно. Вы не забывайте Ceph распределенное хранилище и все последующие репликации будут хранится на отличных друг от друга серверах. И так же я упоминал про производительность: 10 независимых OSD будут быстрее, чем RAID 0 из 10 HDD но с одним OSD.
Да и зачем нужна лишняя прослойка в виде RAID, которую нужно обслуживать…
Да и зачем нужна лишняя прослойка в виде RAID, которую нужно обслуживать…
К сожалению не могу редактировать свое же сообщение…
Я сейчас подсчитал и получилось, что и по занимаемому пространству не тождественно с size=2, вот с size=3 да. Извиняюсь за качество, на коленке рисовал
Честно сказать, не корректно сравнивать RAID и Ceph.
Я видел в рассылках(к сожалению не могу найти) люди использовали RAID 5/6, но там была сильно специфичная задача.
Я сейчас подсчитал и получилось, что и по занимаемому пространству не тождественно с size=2, вот с size=3 да. Извиняюсь за качество, на коленке рисовал
Заголовок спойлера
Честно сказать, не корректно сравнивать RAID и Ceph.
Я видел в рассылках(к сожалению не могу найти) люди использовали RAID 5/6, но там была сильно специфичная задача.
НЛО прилетело и опубликовало эту надпись здесь
В разделе «Испытания» об этом написано, хотя и короче )
А что скажете про CephFS, кто-нибудь использует в продакшене?
Как производительность?
Как производительность?
Смотря какие цели ты ставишь. Могу сказать точно, что оно быстрее, чем GlusterFS )
У нас «большое» файловое хранилище на 20Тб (в основном сканы документов по от 2 до 20 Мб каждый) было сначала на OCFS2, но после 6Тб скорость записи упала до уровня флешкарты, пришлось подключать горячий резерв на ext4, и переформатировать основное хранилище. Сейчас хранилище поделили на несколько мелких GlusterFS, используемых для некоторых проектов, подключенных по NFS. Скорость нативного fuse драйвера невелика. По NFS еще как-то бегает.
Вот сейчас рассматриваем варианты pNFS через GlusterFS либо CephFS.
Вот сейчас рассматриваем варианты pNFS через GlusterFS либо CephFS.
Насколько эта конструкция устойчива к падению 2 или всех 3 нод?
Год назад ни vsan ни scaleio после таких вылетов собраться не могли.
Год назад ни vsan ни scaleio после таких вылетов собраться не могли.
От многого зависит вообще. Во-первых, что вы понимаете под падением? Просто выключить на время или уничтожить?
Если просто выключить 3 из 3 нод, а потом включить, то это будет просто как перезагрузка кластера.
Если все таки убить 2 из 3 нод, то при факторе репликации 3, и правильной краш-карте оно будет работать на чтение. А если при этом min_size=1 (вместо дефолтного 2), то и на запись. Но такой min_size опасен, и с ним вы рискуете еще больше.
Это что касается данных, но тут еще с мониторами может быть беда. Если у вас три ноды с тремя мониторами, то падением 2 из 3, останется один монитор, который не сможет отличить, связь у него с остальными мониторами пропала, либо сами мониторы сдохли. Кворум не образуется и кластер встанет до поднятия остальных мониторов. Если же мониторы 2 из 3 умерли совсем, то можно остановить кластер, поправить карту мониторов руками в оффлайне и все таки запустить.
В этой же ситуации с мониторами может быть все гораздо лучше, если мониторы у вас на отдельных серверах. Мониторы требуют немного ресурсов, часть их можно запускать даже на виртуалках. И когда вылетят 2 из 3 нод с данными, и лишь на одной был монитор, а два других в других местах, то кластер останется жив.
Кроме того, если значительная часть кластера падает, может начаться сильная ребалансировка, которая не только положит производительность, но и может такой нагрузкой ускорить умирание старых дисков (которые на тот момент являются единственными местами хранения большой доли объектов), находящихся в оставшихся живых нодах. И вот тогда то данные улетят. Я уже два раза слышал о такой ситуации.
И еще частой ситуацией, как я понял, бывает такая: кластер работает нормально, затем происходит какая-нибудь авария (например выключается свет или пожар в одной серверной), часть нод отваливается, кластер пытается все это дело сам разрулить, и в этот момент админы начинают паниковать, менять настройки мониторов, править карты, и тем самым разваливают все к чертям.
Но на виртуальных стендах эти ситуации вполне себе нормально отрабатывают, вы можете попробовать, оно не долго собирается на самом деле.
Короче, как говориться, «а случаи бывают разные...» (с)
Если просто выключить 3 из 3 нод, а потом включить, то это будет просто как перезагрузка кластера.
Если все таки убить 2 из 3 нод, то при факторе репликации 3, и правильной краш-карте оно будет работать на чтение. А если при этом min_size=1 (вместо дефолтного 2), то и на запись. Но такой min_size опасен, и с ним вы рискуете еще больше.
Это что касается данных, но тут еще с мониторами может быть беда. Если у вас три ноды с тремя мониторами, то падением 2 из 3, останется один монитор, который не сможет отличить, связь у него с остальными мониторами пропала, либо сами мониторы сдохли. Кворум не образуется и кластер встанет до поднятия остальных мониторов. Если же мониторы 2 из 3 умерли совсем, то можно остановить кластер, поправить карту мониторов руками в оффлайне и все таки запустить.
В этой же ситуации с мониторами может быть все гораздо лучше, если мониторы у вас на отдельных серверах. Мониторы требуют немного ресурсов, часть их можно запускать даже на виртуалках. И когда вылетят 2 из 3 нод с данными, и лишь на одной был монитор, а два других в других местах, то кластер останется жив.
Кроме того, если значительная часть кластера падает, может начаться сильная ребалансировка, которая не только положит производительность, но и может такой нагрузкой ускорить умирание старых дисков (которые на тот момент являются единственными местами хранения большой доли объектов), находящихся в оставшихся живых нодах. И вот тогда то данные улетят. Я уже два раза слышал о такой ситуации.
И еще частой ситуацией, как я понял, бывает такая: кластер работает нормально, затем происходит какая-нибудь авария (например выключается свет или пожар в одной серверной), часть нод отваливается, кластер пытается все это дело сам разрулить, и в этот момент админы начинают паниковать, менять настройки мониторов, править карты, и тем самым разваливают все к чертям.
Но на виртуальных стендах эти ситуации вполне себе нормально отрабатывают, вы можете попробовать, оно не долго собирается на самом деле.
Короче, как говориться, «а случаи бывают разные...» (с)
Короче, как говориться, «а случаи бывают разные...» (с)Вот хотелось бы сначала где-то почитать хотя бы про самые частые случаи заранее, а не клещами вытаскивать инфу из маркетологов, а потом с дымящимся хвостом разыскивать тех, кто хоть примерно представляет, что там и почему происходит
Если все таки убить 2 из 3 нод, то при факторе репликации 3, и правильной краш-карте оно будет работать на чтение. А если при этом min_size=1 (вместо дефолтного 2), то и на запись. Но такой min_size опасен, и с ним вы рискуете еще больше.
Не будет работать и на чтение. Много-много раз об этом говорил и говорю. Если выставить min_size=1 то будет и чтение и запись, но использовать такое- выстрел в ногу, причем в упор.
Кроме того, если значительная часть кластера падает, может начаться сильная ребалансировка, которая не только положит производительность, но и может такой нагрузкой ускорить умирание старых дисков (которые на тот момент являются единственными местами хранения большой доли объектов), находящихся в оставшихся живых нодах. И вот тогда то данные улетят. Я уже два раза слышал о такой ситуации.
Выставляем соответсвующие параметры задержек для ребалансинга и получаем гораздо меньше рисков как для производительности, так и «умирания старых дисков». И если произошло «умирание старых дисков» никто не запрещает достать необходимые диски от умерших нод и вставить в рабочие ноды и сливать данные с их PG.
И еще частой ситуацией, как я понял, бывает такая: кластер работает нормально, затем происходит какая-нибудь авария (например выключается свет или пожар в одной серверной), часть нод отваливается, кластер пытается все это дело сам разрулить, и в этот момент админы начинают паниковать, менять настройки мониторов, править карты, и тем самым разваливают все к чертям.
Паникующих админов надо успокаивать :). Человеческий фактор всегда был и будет.
Не будет работать и на чтение.
Будет
Если выставить min_size=1 то будет и чтение и запись, но использовать такое- выстрел в ногу, причем в упор.
Об этом я и сказал в своем комменте.
Выставляем соответсвующие параметры задержек для ребалансинга и получаем гораздо меньше рисков
Задержки ребалансинга лишь отложат неприятный момент. Тут нужно крутить настройки количества одновременно восстанавливающихся плейсмент-групп. Или я не понял, о чем вы?
И если произошло «умирание старых дисков» никто не запрещает достать необходимые диски от умерших нод и вставить в рабочие ноды и сливать данные с их PG.
Вот в процессе этого и появляются риски развалить кластер своими руками. Когда он и так больной, и уже занят рекаверингом, а тут ему суют какие-то диски и начинают карты править. Или это можно как-то сделать просто и быстро? Если да, то расскажите подробно, а не как в начале коммента «не будет работать и все», и гадайте сами, почему у кого-то будет, а у кого-то не будет.
del
А мониторинг и gui для ceph имеется?
Быть может этот коммент из другой статьи ответит на ваш вопрос
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кластер хранилища Ceph на VMWare за 10 минут