Comments 18
«Вывод 1: Сeph полностью заменяет все решения по резервному копированию»
Это серьезно?
Я дальше читать пока не буду, а то подгорает…
Это серьезно?
Я дальше читать пока не буду, а то подгорает…
UFO just landed and posted this here
Да уж…
Для тех кто не понял — данные могут теряться не только из-за сбоя системы хранения, но и из-за злонамеренных/идиотских действий. И тогда rm -rf /any_folder будет чистой совестью реплицирован на весь кластер.
Так что бэкап бэкапом, а высокая доступность высокой доступностью.
Для тех кто не понял — данные могут теряться не только из-за сбоя системы хранения, но и из-за злонамеренных/идиотских действий. И тогда rm -rf /any_folder будет чистой совестью реплицирован на весь кластер.
Так что бэкап бэкапом, а высокая доступность высокой доступностью.
Да классической схемы резервной копии и восстановления после сбоя или к моменту во времени нету и едва ли это нужно для всего кластера, который может быть очень и очень большим. От злонамеренных действий, логических ошибок в структурах хранения в результате программных ошибок и прочего резервирование конечно не спасёт, спасёт от аппаратного сбоя или физического повреждения узла.
Нет конечно, это не серьёзно, а скорее провокационно. Ceph конечно не заменяет решения для резервного копирования всего (баз данных, почтовых очередей и т.п.), речь скорее о том, что объёмы которые обычно находятся в Ceph не подходят для обычных «автомобилей» т.е. систем резервного копирования – это дорого и долго. В Ceph нет бэкапов в классическом понимании – есть другие способы обеспечить сохранность данных – резервирование разнесение узлов – про что и написано в разделе с «провокационным» заголовком. Это конечно не классический бэкап – восстановить состояние хранилища к прошедшему моменту времени или восстановить ошибочно удалённый объект не получиться (если «корзина» удерживающая удалённые объекты не предусмотрена в решении, которое использует Ceph).
Самый простой способ оправдать ошибку — объявить ее намеренной. Особенно в интернете. Провокация, эксперимент, etc.
У организации, которую вы представляете на хабре, такой же уровень понимания разницы между резервным копированием данных и резервированием элементов хранилища? Если да — то я бы никому не рекомендовал с вами иметь дело.
Да, тоже подгорело. Сначала такую пургу льют в уши бизнесу, а потом он приходит с этим бредом к нам.
То, что ceph умеет все вышенаписанное, это известно всем, кто собственно слышал про него. Интересней как прикладной софт, внезапно, вместо Postgres начал использовать rados. Обычно именно этот вопрос интересует, как прозрачно переехать из какой-либо субд в хранилище.
Как уже выше заметили, совершенно не раскрыт вопрос, как защищаться от аналога rm -rf / data или delete from table —where 1=2
Как уже выше заметили, совершенно не раскрыт вопрос, как защищаться от аналога rm -rf / data или delete from table —where 1=2
Никто из присутствующих не в курсе, можно ли сделать копию версионируемого бакета с сохранением идентификаторов версий в новый бакет/другой кластер?
Это на тему «Бекапы не нужны»:
Сейчас мы имеем волшебную ситуацию когда в Ceph Jewel репликация работает некорректно и «воскрешает» удаленные версии (не объекты помеченные как удаленные, а именно удаленные конкретные версии документов). Обновить Jewel до Luminous на бою очень боязно (бекапов то нет), потому что апгрейд stage кластера развалил его чуть более чем полностью (что не удивительно, кластер старенький, часть данных протерялось, часть индексов не соответствует действительности, потому что он уже пережил несколько минорных обновлений чтобы починить то что сломали в предыдущих версиях)
Это на тему «Бекапы не нужны»:
Сейчас мы имеем волшебную ситуацию когда в Ceph Jewel репликация работает некорректно и «воскрешает» удаленные версии (не объекты помеченные как удаленные, а именно удаленные конкретные версии документов). Обновить Jewel до Luminous на бою очень боязно (бекапов то нет), потому что апгрейд stage кластера развалил его чуть более чем полностью (что не удивительно, кластер старенький, часть данных протерялось, часть индексов не соответствует действительности, потому что он уже пережил несколько минорных обновлений чтобы починить то что сломали в предыдущих версиях)
При внедрении Сeph резервное копирование получается как бы «в виде бонуса». Просто задаем при настройке параметры репликации – количество копий и локации их размещения.
Когда уже переведутся «инженеры», которые считают что реплику или снепшот можно хотя бы близко называть «бекапом» данных.
Какая-то очередная маркетинговая статья. Да ещё с ошибками про бэкапы…
Что, нет нормальных технарей написать с какими проблемами столкнулись и как решали?
Что, нет нормальных технарей написать с какими проблемами столкнулись и как решали?
Как говорил один футбольный комментатор: «Я сейчас закончу вообще все!».
> Вывод 1: Сeph полностью заменяет все решения по резервному копированию
Не вводите людей в заблуждение! Никакая супер-мега-отказоустойчивая хранилка никогда не была и не будет решением для бэкапов. Почитайте про одного облачного провайдера Cloud Mouse, и то, как бесславно они закончили свой путь. У них был Цеф и не было бэкапов. Действительно, зачем бэкапы, когда есть Цеф? Разве что-то может в Цефе пойти не так? Конечно же, нет, думали они. Разве в Цефе могут быть баги? Конечно нет, думали они.
Я сам лично имел опыт с Цефом, когда в нем что-то шло очень сильно не так (собственно, был серьезный баг в самом Цефе, пришлось за кучу денег вызывать Red Hat). И бэкапов у нас тоже не было, вернее до них просто не дошли руки. Не повторяйте наших ошибок.
> Вывод 4: Когда он уже настроен, управлять Сeph может любой администратор Linux
По моему опыту успешно управлять Цефом может только сисадмин с большим опытом Линукса и отличным знанием на низком уровне архитектуры Цефа. Любой другой просто не сможет справиться с проблемами, которые обязательно будут.
> катастрофоустойчивая конфигурация, которая просто не требует дополнительного резервного копирования при наличии – 3-4 копий данных на разных дисках и серверах. Работает такая система гарантировано лучше, чем любое аппаратное решение
И такая система не только работает лучше, но и стоит больше чем, наверное, добрая часть аппаратных решений на рынке. При огромных объемах данных репликация становится чрезмерно дорогостоящим удовольствием, несмотря на все ее очевидные преимущества. Сколько данных вы храните?
И последнее. Вас ждет множество сюрпризов с Цефом, которые заставят вас изменить точку зрения, высказанную в статье.
> Вывод 1: Сeph полностью заменяет все решения по резервному копированию
Не вводите людей в заблуждение! Никакая супер-мега-отказоустойчивая хранилка никогда не была и не будет решением для бэкапов. Почитайте про одного облачного провайдера Cloud Mouse, и то, как бесславно они закончили свой путь. У них был Цеф и не было бэкапов. Действительно, зачем бэкапы, когда есть Цеф? Разве что-то может в Цефе пойти не так? Конечно же, нет, думали они. Разве в Цефе могут быть баги? Конечно нет, думали они.
Я сам лично имел опыт с Цефом, когда в нем что-то шло очень сильно не так (собственно, был серьезный баг в самом Цефе, пришлось за кучу денег вызывать Red Hat). И бэкапов у нас тоже не было, вернее до них просто не дошли руки. Не повторяйте наших ошибок.
> Вывод 4: Когда он уже настроен, управлять Сeph может любой администратор Linux
По моему опыту успешно управлять Цефом может только сисадмин с большим опытом Линукса и отличным знанием на низком уровне архитектуры Цефа. Любой другой просто не сможет справиться с проблемами, которые обязательно будут.
> катастрофоустойчивая конфигурация, которая просто не требует дополнительного резервного копирования при наличии – 3-4 копий данных на разных дисках и серверах. Работает такая система гарантировано лучше, чем любое аппаратное решение
И такая система не только работает лучше, но и стоит больше чем, наверное, добрая часть аппаратных решений на рынке. При огромных объемах данных репликация становится чрезмерно дорогостоящим удовольствием, несмотря на все ее очевидные преимущества. Сколько данных вы храните?
И последнее. Вас ждет множество сюрпризов с Цефом, которые заставят вас изменить точку зрения, высказанную в статье.
Sign up to leave a comment.
Сeph как подключаемое хранилище: 5 практических выводов из крупного проекта