А как вы используете разные типы кластеров — глобальный и локальные? То есть в глобальном у вас хранятся диски ВМ которые не критичны к летенси и вы можете подключать их к ВМ в любом DC? А в локальных кластерах хранятся диски ВМ доступные только в этом DC?
Или у вас диски могут перемещаться из глобального кластера в локальный и наоборот?
Просто вы пишите, что глобальный кластер был плох и вы сделали локальные но не поясняете пользовательский сценарий работы при таком разделении кластеров.
И… я пропустил, или в статье ничего про Гео-репликацию не сказано?
(Тоесть вопросы безопасности передачи данных, проблеммы, связанные с высоким пингом, малой скоростью и т.п.)
Если у вас есть подобный опыт, было бы интересно почитать о нем, хотя бы в двух словах.
И… я пропустил, или в статье ничего про Гео-репликацию не сказано?
(Тоесть вопросы безопасности передачи данных, проблеммы, связанные с высоким пингом, малой скоростью и т.п.)
Нет, вы не пропустили, тема гео-репликации и гео-распределенных кластеров не затронута в этой статье в силу отсутствия у нас подобного опыта и необходимости в подобных сетапах.
Будьте добры, укажите цитатой, где я утверждаю, что они плохие и где Вы увидели пафос?
Вот тут я увидел пафос:
Linstor (он же часть Linbit SDS) — DRBD + ZFS/LVM + Java. Серьезный конкурент Ceph? Без шуток?
Вы сравниваете системы в контексте их ТТХ а я в контексте задач которые они могут решать. И ceph и Linstor успешно используются в связке с k8s, например и как следствие они являются конкурентами в этом поле. Есть десятки задач, где не нужно уметь много всего а нужно хорошо уметь что-то одно. Наш пример с ScaleIO снова показателен. Ну не умеет Ceph в быстрый блочный сторадж, и не помогает ему пока ничего.
Можете не сранивать, если DRBD научился Erasure Coding… но ведь он не научился?
На мой взгляд некорректно сравнивать EC и репликацию в отрыве от задачи.
Спасибо, что поделились опытом. Часто применяли в своих проектах DPDK/SPDK или RDMA?
Немного не понятен ваш пафос. В этом комментарии вы ставите Ceph на вершину всего просто потому, что он соответствует RAIN. Если не соответствует RAIN то и в руки брать не нужно? Я не топлю за Linbit SDS, Nexenta, я с ними не работал но допускаю, что они способны справляться с задачами которые перед собой ставят. И то, что они имеют отличную от Ceph (not RAIN) архитектуру не делает их автоматически плохим вариантом.
Опять же, вы упоминаете Gluster. Если я правильно понимаю архитектуру Gluster то в случае репликейтед-волюмов — волюм будет состоят из жестко определенного набора репликейтед групп. Там есть еще нюансы но суть в том, что это такие же замкнутые в себе репликейтед группы как и несколько DRBD-групп в случае с Linbit SDS. Но тут вы топите за Gl.
Ваши доводы выглядят как сугубо теоретические. Поделитесь пожалуйста своим практическим опытом эксплуатации Ceph. Какие возможности Ceph вы используете и как они вам помогают экономить деньги/снижать TCO?
Нет, ну серьезно, зачем нужны DPDK/SPDK, RDMA сейчас когда Ceph выедает два Xeon'а за милую душу в том числе и с этими примочками?
Какой толк в замене диска без ребилда когда вопрос равномерности распределения данных решается присоской на python (mgr, balancer plugin) которая по ночам мигрирует PG?
Это как установить спортивный обвес на жигу ничего не меняя под капотом.
Спасибо большое за ваше мнение и полезнейший перечень возможностей Ceph, правда. Думаю многим будет интересно на него взглянуть. Но, мое мнение не пошатнулось ни на толику.
Очень надеюсь, что все идеи и планы разработчиков постепенно будут реализованы.
в результате которого читатели делают вывод — Ceph это поделка
Если не сложно, в чем конкретно я был не прав рассказывая про Ceph? В чем конкретно я исказил картину? Вы так пишите, как будто я наговариваю и порчу репутацию продукту.
С другой стороны, вы своей «объективностью» не заслужено повышаете хайп вокруг этого продукта. На мой взгляд лучше пусть люди готовятся к худшему чем запускают Ceph в прод в розовых очках.
В вашем комментарии есть три основные мысли:
1. вам видится, что будущее за Ceph или за другими Open source решениями,
2. использовать ScaleIO опасно т.к. вендор не дает никаких технических гарантий,
3. использовать ScaleIO опасно по политическим причинам.
1. Я тоже надеюсь, что так и будет.
2. Хоть я и за Open source, но объективно Ceph тоже ничего вам не гарантирует. Даже при том, что в основе лежат математически доказанные алгоритмы — ничего не мешает потерять данные из-за банального бага. Такого как в версии 12.2.6, например. И с Open source версией, вам могут отказать в помощи даже за деньги.
3. Политика. Я старался не допускать политических моментов в своей статье потому, что суть не них. Суть в том, что есть реальная система X (в данном случае ScaleIO) которая умет быть относительно быстрой, ресурсоэффективной, масштабируемой, простой и приятной в использовании. Эта система X демонстрирует нам успешное решение всех тех проблем которые перед собой ставит Ceph. Я лишь хотел показать, что хайповый Ceph не такой уж и крутой если сравнить с серьезным конкурентом. Я не хотел выделить ScaleIO на фоне Ceph. ScaleIO был нужен в этой статье как референсная система. Других к сожалению я не знаю.
От удаления бакета никакая инфраструктура не спасет, вы правы. Боле того, можно придумать еще десяток ситуаций, при которых можно потерять/удалить данные. Но, повторюсь, мы не делаем резервное копирование пользовательских данных в нашем S3. Причины я описал выше. Наиболее веская из них — экономика. Боле того, я очень сомневаюсь, что кто-либо из публичных облачных провайдеров делает резервное копирование своих объектных хранилищ. У вас есть примеры таких? Может быть AWS или GCP например?
Я не пытаюсь поставить нас в один ряд с Amazon, нет, я лишь говорю о том, что при больших объемах все работает немного иначе. Ставка делается на надежность всего и вся, на жесткие регламенты и на максимальное снижение риска потери данных. При этом сохраняется приемлемая стоимость услуг.
Не совсем так. size — это число копий, которые ceph запишет в синхронном режиме. min_size — это число копий, при котором разрешена запись и как следствие изменение primary копии. Если у вас 3,2, то ceph будет делать всегда реплику 3 в синхронном режиме. При наличие 2х копий он позволит записывать данные. При наличии только одной копии — данные перейдут в readonly пока не будет достигнут min_size.
PS для защиты от логов лучшая мера — отдельный раздел под логи (в том же tmpfs, только ограниченный).
Текущий "/" в tmpfs и ограничен до 6GB. Отдельный раздел в tmpfs избавит от заполнения "/" логами, но при заполнении этого выделенного раздела — OSD также будут останавливаться. Или чего-то не понял?
Мы используем Ceph как S3 (RGW) поверх магнитных дисков. К сожалению дать совет по настройке Ceph для работы поверх SSD или NVMe не могу. Только если порекомендовать vxFlex (это юмор такой). Могу только судить о тенденции, которую я сейчас наблюдаю. Раньше запускать несколько OSD поверх одного диска категорически не рекомендовалось. Сейчас — 2-4 OSD на одном SSD встречаю часто и разработчики уже закрывают на это глаза. Это связано с тем, что за последние годы так никто и не раскусил в чем затык Ceph, а оборудование сильно шагнуло вперед. Поэтому вы можете попробовать, но думаю, что радикально ничего не поменяется.
Я бы про бэкапы лучше поговорил)
Интересует, как вы их реализовывали
Это хороший и одновременно сложный вопрос. Чтобы бекапить например 500 Tb (что не так уж и много), для этого нужно иметь отдельную инфраструктуру приличных размеров. Стоимость этой инфраструктуры и ее обслуживания повлияет на стоимость конечных услуг. Помимо того, что бекапы — дорогое удовольствие, этот процесс оказывают негативное влияние на производительность сервиса. Решение на базе систем (типа Cеph) с сетевой репликацией (что само по себе дорого) — это что-то вроде серебряной пули. Предполагается, что трехкратная репликация поверх инфраструктуры, в которой все задублировано, достаточно надежное решение, чтобы не делать бекапы.
Ели нужен object store то тут не особо богатый выбор. Minio совсем примитивный, OpenStack Swift — ничего, но S3 реализованный сейчас в RGW богаче по возможностям. Плюс S3 более «стандартный» и популярный протокол чем Swift.
Или у вас диски могут перемещаться из глобального кластера в локальный и наоборот?
Просто вы пишите, что глобальный кластер был плох и вы сделали локальные но не поясняете пользовательский сценарий работы при таком разделении кластеров.
Если у вас есть подобный опыт, было бы интересно почитать о нем, хотя бы в двух словах.
Нет, вы не пропустили, тема гео-репликации и гео-распределенных кластеров не затронута в этой статье в силу отсутствия у нас подобного опыта и необходимости в подобных сетапах.
Вы сравниваете системы в контексте их ТТХ а я в контексте задач которые они могут решать. И ceph и Linstor успешно используются в связке с k8s, например и как следствие они являются конкурентами в этом поле. Есть десятки задач, где не нужно уметь много всего а нужно хорошо уметь что-то одно. Наш пример с ScaleIO снова показателен. Ну не умеет Ceph в быстрый блочный сторадж, и не помогает ему пока ничего.
На мой взгляд некорректно сравнивать EC и репликацию в отрыве от задачи.
Спасибо, что поделились опытом. Часто применяли в своих проектах DPDK/SPDK или RDMA?
Опять же, вы упоминаете Gluster. Если я правильно понимаю архитектуру Gluster то в случае репликейтед-волюмов — волюм будет состоят из жестко определенного набора репликейтед групп. Там есть еще нюансы но суть в том, что это такие же замкнутые в себе репликейтед группы как и несколько DRBD-групп в случае с Linbit SDS. Но тут вы топите за Gl.
Ваши доводы выглядят как сугубо теоретические. Поделитесь пожалуйста своим практическим опытом эксплуатации Ceph. Какие возможности Ceph вы используете и как они вам помогают экономить деньги/снижать TCO?
Нет, ну серьезно, зачем нужны DPDK/SPDK, RDMA сейчас когда Ceph выедает два Xeon'а за милую душу в том числе и с этими примочками?
Какой толк в замене диска без ребилда когда вопрос равномерности распределения данных решается присоской на python (mgr, balancer plugin) которая по ночам мигрирует PG?
Это как установить спортивный обвес на жигу ничего не меняя под капотом.
Спасибо большое за ваше мнение и полезнейший перечень возможностей Ceph, правда. Думаю многим будет интересно на него взглянуть. Но, мое мнение не пошатнулось ни на толику.
Очень надеюсь, что все идеи и планы разработчиков постепенно будут реализованы.
Если не сложно, в чем конкретно я был не прав рассказывая про Ceph? В чем конкретно я исказил картину? Вы так пишите, как будто я наговариваю и порчу репутацию продукту.
С другой стороны, вы своей «объективностью» не заслужено повышаете хайп вокруг этого продукта. На мой взгляд лучше пусть люди готовятся к худшему чем запускают Ceph в прод в розовых очках.
1. вам видится, что будущее за Ceph или за другими Open source решениями,
2. использовать ScaleIO опасно т.к. вендор не дает никаких технических гарантий,
3. использовать ScaleIO опасно по политическим причинам.
1. Я тоже надеюсь, что так и будет.
2. Хоть я и за Open source, но объективно Ceph тоже ничего вам не гарантирует. Даже при том, что в основе лежат математически доказанные алгоритмы — ничего не мешает потерять данные из-за банального бага. Такого как в версии 12.2.6, например. И с Open source версией, вам могут отказать в помощи даже за деньги.
3. Политика. Я старался не допускать политических моментов в своей статье потому, что суть не них. Суть в том, что есть реальная система X (в данном случае ScaleIO) которая умет быть относительно быстрой, ресурсоэффективной, масштабируемой, простой и приятной в использовании. Эта система X демонстрирует нам успешное решение всех тех проблем которые перед собой ставит Ceph. Я лишь хотел показать, что хайповый Ceph не такой уж и крутой если сравнить с серьезным конкурентом. Я не хотел выделить ScaleIO на фоне Ceph. ScaleIO был нужен в этой статье как референсная система. Других к сожалению я не знаю.
Я не пытаюсь поставить нас в один ряд с Amazon, нет, я лишь говорю о том, что при больших объемах все работает немного иначе. Ставка делается на надежность всего и вся, на жесткие регламенты и на максимальное снижение риска потери данных. При этом сохраняется приемлемая стоимость услуг.
Конфигурация 3,1 опасна в таких ситуациях:
epoch 10: osd.0, osd.1, osd.2epoch 11: osd.0 (1 and 2 down)
epoch 12: - (osd.0 fails hard)
epoch 13: osd.1 osd.2
Но спасибо за замечание, я учту это в следующий раз. Я не опытен в этом плане.
Текущий "/" в tmpfs и ограничен до 6GB. Отдельный раздел в tmpfs избавит от заполнения "/" логами, но при заполнении этого выделенного раздела — OSD также будут останавливаться. Или чего-то не понял?
Это хороший и одновременно сложный вопрос. Чтобы бекапить например 500 Tb (что не так уж и много), для этого нужно иметь отдельную инфраструктуру приличных размеров. Стоимость этой инфраструктуры и ее обслуживания повлияет на стоимость конечных услуг. Помимо того, что бекапы — дорогое удовольствие, этот процесс оказывают негативное влияние на производительность сервиса. Решение на базе систем (типа Cеph) с сетевой репликацией (что само по себе дорого) — это что-то вроде серебряной пули. Предполагается, что трехкратная репликация поверх инфраструктуры, в которой все задублировано, достаточно надежное решение, чтобы не делать бекапы.
Ооо, вы хотите поговорить о LTS релизах)? А их больше нет. Теперь все релизы "стабильные")
В своём коменте вы говорите о объектном сторе, nfs и судя по всему о блочном сторе тоже. Не совсем понятно, что именно вам нужно)?