Пока я знаю только один способ увидеть Arcanum и его окружение в действии: пройти собеседование в Яндекс) Еще коллеги подсказали, что уже были статьи на Хабре с некоторым описанием как это все работает, например: habr.com/ru/company/yandex/blog/428972 — это чуть более быстрый способ посмотреть на то, как сотрудники Яндекса работают с кодом)
он на базе самого себя. Для удобства пользователей в разное время были созданы клиентские интерфейсы к git, Mercurial и svn (то есть можно было работать как с git, hg или svn репозиторием), но, насколько я знаю, сейчас идет активное развитие и клиентской части, поэтому в некоторой перспективе будет собственный клиент, реализующий полный функционал. Будут ли при этом убираться слои совместимости с остальными системами, это сложно предсказать.
В реальной работе: Yandex Arcanum, можно вынести как отдельный пункт голосования и посчитать сколько работников Яндекса на Хабре)
а до Яндекса и в своих pet-project-ах: Git, но в текущих реалиях это банально. Возможно и голосовалку нужно было делать: какой системой контроля версий вы пользуетесь помимо git, ну или хотя бы давать выбирать два варианта ответа или больше.
Либо я оптимист, либо не понимаю в чем сложность. Если мы имеем ноду, где Ceph сжирает терайбат оперативы, значит на этой ноде уже находится 1 PB данных на дисках. И даже в рекомендациях к Ceph-у говорится, что если данные умещаются на одну ноду, то лучше не городить Ceph, а собрать RAID.
Если на ноде данных меньше, и у нас кластер допустим на 20 узлов, то и памяти требуется в 20 раз меньше (ну или может в 10 если учитываем репликацию), и то есть от терабайта RAM мы на Ceph тратим только 5-10%, все остальное отдаем под ML.
А про замену диска: тут не про CephFS должна быть речь, за работу с диском отвечает Ceph. И сколько времени это займет, на зависит от объема и скорости диска и занятых данных. Я тут предпочитаю провести эксперимент и замеры, а не говорить оценочно. Но не вижу причин, почему Ceph может или должен быть медленее HDFS-а.
В общем, думаю ближе к 6 или 7-ой части дойдем и до экспериментов с Hadoop-ом и CephFS-ом, тогда замерим и сравним.
Про память я не согласен что дорого: сейчас память стоит порядка 5-10$ за гигабайт, у ssd порядок цен 100$ за терайбат. Ну то есть да, в Петабайтном кластере оперативной памяти будет на пару десятков тысяч долларов. Но это все-равно будут проценты от остальной стоимости кластера.
В зависимости от задач, можно перевести CAPEX в OPEX, но это тоже надо считать от проекта и задач, но как ориентир 1 PB в AWS S3 это порядка 25k $ в месяц.
А про диски я вот совсем не понял вопрос: ну умер физический диск, его надо так же заменить, ceph отреплицирует данные как в момент выхода диска из строя, так и после установки нового.
Варианта CephFS as a Service я пока не встречал, даже не буду гадать какие SLA и времена реакции там могут быть.
Когда я смотрел на CephFS, там очень сильно пугало количество багов с ним связанных, и это останавливало от того, чтобы даже его посмотреть на QA. Но после чтения release notes от последних версий ceph-а, уже складывается ощущение что там стало сильно лучше. И когда Андрей нам обновит кластер до 13 или 14-ой версии, то еще раз посмотрим на применимость CephFS под наши задачи. Но как люди опытные, будем помнить о бэкапе и не будем туда класть данные которые нельзя потерять.
Опять же чисто на уровне идеи: мы получаем kernel module для CephFS вместо userland-а для HDFS, плюс мы все лучше и лучше умеем тюнить Ceph и его компоненты, так что такой эксперимент выглядит оправданным.
Но финальный ответ только по итогам тестов, причем как нагрузочных, так и функциональных. Мы не настолько хорошо знаем Ceph, чтобы давать какие-то теоретические оценки его надежности и производительности.
а в каком смысле «Hadoop-on-Ceph»? Если CephFS вместо HDFS, то мы так еще не пробовали, но идеологически выглядит нормальным решением. Но нужно проверить на практике как это будет работать. Если же просто держать данные в Ceph-е, то тут ломается основная идея близости данных к вычислительной ноде. Ну или нужен очень быстрый Ceph, чтобы нивелировать эту удаленность данных.
container_name: conteiner_a
ну как тут можно было допустить ошибку в слове «container». я читаю статью, и кровь из глаз.
извините за несодержательный и эмоциональный комментарий.
а до Яндекса и в своих pet-project-ах: Git, но в текущих реалиях это банально. Возможно и голосовалку нужно было делать: какой системой контроля версий вы пользуетесь помимо git, ну или хотя бы давать выбирать два варианта ответа или больше.
Если на ноде данных меньше, и у нас кластер допустим на 20 узлов, то и памяти требуется в 20 раз меньше (ну или может в 10 если учитываем репликацию), и то есть от терабайта RAM мы на Ceph тратим только 5-10%, все остальное отдаем под ML.
А про замену диска: тут не про CephFS должна быть речь, за работу с диском отвечает Ceph. И сколько времени это займет, на зависит от объема и скорости диска и занятых данных. Я тут предпочитаю провести эксперимент и замеры, а не говорить оценочно. Но не вижу причин, почему Ceph может или должен быть медленее HDFS-а.
В общем, думаю ближе к 6 или 7-ой части дойдем и до экспериментов с Hadoop-ом и CephFS-ом, тогда замерим и сравним.
В зависимости от задач, можно перевести CAPEX в OPEX, но это тоже надо считать от проекта и задач, но как ориентир 1 PB в AWS S3 это порядка 25k $ в месяц.
А про диски я вот совсем не понял вопрос: ну умер физический диск, его надо так же заменить, ceph отреплицирует данные как в момент выхода диска из строя, так и после установки нового.
Варианта CephFS as a Service я пока не встречал, даже не буду гадать какие SLA и времена реакции там могут быть.
Опять же чисто на уровне идеи: мы получаем kernel module для CephFS вместо userland-а для HDFS, плюс мы все лучше и лучше умеем тюнить Ceph и его компоненты, так что такой эксперимент выглядит оправданным.
Но финальный ответ только по итогам тестов, причем как нагрузочных, так и функциональных. Мы не настолько хорошо знаем Ceph, чтобы давать какие-то теоретические оценки его надежности и производительности.
а есть какие-нибудь бенчмарки? как было, как стало?
container_name: conteiner_aну как тут можно было допустить ошибку в слове «container». я читаю статью, и кровь из глаз.
извините за несодержательный и эмоциональный комментарий.