Спасибо - отличная статья, даже не столько про именно авторизацию, сколько про архитектуру большой кафки. Вопрос: получилось, что повезло, что авторизация в чистом поле строилась, и до этого не было ничего, а как аналогичный процесс провернуть для тех, кто вырос, и пытается съехать с легаси ACL на RBAC?
Интересно, а у них уже есть планы по увеличению числа женщин, небинарных личностей и расового разнообразия в списке ментейнеров по рекомендации юристов страны, в которой находится фаундейшн?
привет, интересная история, сразу тут встречный вопрос: а в каком смысле поверх OMAP? Вы двигали значение osd_max_object_size или хватает дефолта 128Mb? Листинг реализован как листинг всех объектов пула и внешние индексы вообще не используются?
на счет того, какие настройки и как крутить, чтобы Ceph вывозил большие нагрузки на родном индексе, боюсь, так в комментарии не ответить - тянет на отдельную захватывающую историю от команды его эксплуатации. Часть более-менее понятных пунктов типа шардирования-решардирования есть в статье, ну и плюс - очень много делают разработчики Ceph в новых версиях в плане оптимизации.
Хотелось бы для возврата в конструктивное обсуждение уточнить, читали ли вы статью. Потому что она описывает не вопрос выбора между распределенной файловой системой и объектным хранилищем, а повышение производительности уже развитого, масштабного и нагруженного S3 совместимого объектного хранилища.
Для всех задач свои инструменты и та же hdfs у нас успешно параллельно используется.
Это вы опрос среди разработчиков провели: что им нужно, а что нет?
листинг 25 миллионов объектов - никому не нужная блажь.
К счастью все гораздо проще, у нас есть метрики по использованию объектного хранилища в компании за несколько лет, и мы вполне понимаем, какие задачи актуальны, где можно попросить разработчиков не делать глупостей, а где действительно проблемы из реального мира, или особенности работы софта от внешних вендоров.
RADOS как объектный протокол, конечно, крут и решает очень много задачек для распределенных систем (атомарность, защита от перезаписи, ...) но как стандарт он примерно никем не поддерживается, поэтому надо че-то изобретать поверх.
Дальше вы можете его использовать как CephFS (определенно не самое производительное решение уже на сотнях тысяч объектов), или использовать какие-то решения поверх LibRADOS (или идущие из коробки демоны, или что-то свое), эти решения существенно производительнее для большого числа объектов, ну или для объектов большого размера, типа каких-нибудь бекапов.
Делать свою файловую систему даже и не пытались, и для наших задач POSIX совместимая файловая система явно бессмысленный оверхед. При этом S3 хранилище является сейчас стандартом для большей части как коммерческих, так и OpenSource решений (PostgreSQL, Clickhouse, Prometheus, Gitlab, Allure TestOps, ...), что позволяет строить систему хранения компании на единой платформе, а кроме того эффективно контролировать по стандартным дашбордам профили нагрузки на хранилище.
Ну и раз уж мы используем единую платформу хранения, то начиная с определенных масштабов начинаем сталкиваться с тем, что некоторые системы (Prometheus для семплирования данных, Allure или Gitlab для фоновых индексаций или очистки артефактов) дают нагрузку, которую не переварит никакой FUSE, и даже с трудом переваривает RGW шлюз к Ceph, хотя в версии Reef они провели много крутых оптимизаций, и там, кажется, есть шансы все-таки продержаться на нативном решении.
Ну и отвечая на вопрос - GlusterFS, SeaweedFS и прочие не смотрели, по ряду причин: на больших масштабах смущает уровень зрелости и поддержки проектов относительно Ceph, необходимость перевода всей инфраструктуры на новые рельсы и т.д.
вообще странный на вид наброс, честно сказать вызывает подозрение, сами понимаете какое(?)
primary зона ок, какой-то самоизобретенный термин, но для реплицированного (не EC) кластера ситуация описана валидно: S3 как не работало с репликами, так и не работает, думаю, тут вопрос же в гарантиях консистентности (если кинешь опровергающую информацию - с интересом почитаю)
про EC как решение без оверхеда по диску, которое часто выбирают: тут точно не хватает длинного пояснения про скорость чтения, про расход на CPU и прочие причины, почему можно не выбирать EC для S3
ну и как SO пост про RBD связан со статьей про объектные интерфейсы вообще неясно
а кроме того, статья же явно не про настройку Ceph, а про проектирование системы, своего решения, для которого Ceph используется чисто как blob storage
Так у Ceph фактически все хорошо: они отлично работают с embedded базой для хранения индекса, после того, как добавили функционал шардирования жизнь уж точно заиграла новыми красками, а в Reef они применили какую-то черную магию и еще больше производительность индекса подтянули. Так что как коробочное решение - близко к идеальному. Проблема тут в том, что embeded это ограничение на уровне архитектуры: не можем сами оптимально настроить хранилище, какой бы уровень экспертизы у команды эксплуатации ни был.
Ceph напрямую это как, Librados? Если вы работаете не в CERN, которые вроде как справлялись с этим, и у вас задачи мира бизнеса, работать в терминах нетипизированных объектов небольшого размера будет затруднительно.
Ну тут есть еще часть: так исторически сложилось. Хорошо, что современный MinIO умеет в ребалансировку (честно сказать, не проверял на больших объемах), но когда начинали строить архитектуру достаточно быстро оказались в ситуации, когда MinIO размножался добавлением маленьких MinIO, что было фатально несовместимо с построением централизованной инфраструктуры управления кластером. А такая задача по сути и решалась. Решал эту задачу вполне только Ceph. По ходу дела выяснилось, что если его научиться готовить, то он закрывает более-менее все вопросы:
горизонтальное масштабирование
равномерное распределение нагрузки
(почти)все требуемые домены отказа
а еще имеет ветку развития - блочка (RBD)
Из вопросов к нему было слабое observabiltiy в смысле работы с S3, но с этим и у MinIO было никак.
Вот прям буквально выйдя из Шанхайского Маглева мгновенно попадаешь в мир, где по английски не говорит никто. При том, что в целом люди дружелюбны и стараются помочь, проблема с коммуникацией ощутимая. И это еще международный экономический центр, казалось бы, где как не там.
какой учебник взять для разговорного / современного языка
А HSK Course book - обратная история, совсем без грамматики. Т.е. просто постепенно вводятся слова, подходящие под соответствующий HSK. Ну тогда можно просто на ютубе слушать диалоги к HSK твоего уровня с английскими субтитрами (чисто подготовка к сдаче теста), и при этом учиться по какому-то учебнику, где грамматика все-таки есть.
Если человек не умеет писать по-русски он не является грамотным.
До критериев грамотности носителя языка человеку, который где-то на уровне двух Кондрашевских, честно сказать, как до луны. Т.е. от человека, который подходит и спрашивает: "Я мавзолей видеть хотеть" я вряд ли буду ожидать, что он, например, будучи китайцем, пишет по-русски.
В нем есть фонетические диктанты, плюс пособия по иероглифам дают более глубокое внутреннее устройства языка.
Фонетические диктанты на первом уровне есть много где. Пособия по иероголифам вообще не являются неотъемлемой частью учебника "Практический курс китайского языка". А вот их проблема - странноватый выбор базовых слов уже где-то с середины первого учебника. И нужна обязательно корректировка от преподавателя, чтобы не нахвататься неадекватных выражений и слов. Если что, я тоже изучал по этому курсу, грамматику приходилось корректировать по листочкам от преподавателя, по "Грамматика китайского языка в таблицах" (сперва) и по Румянцева М. В. - "Пособие по переводу на закрепление и повторение грамматики к Практическому курсу китайского языка" (потом). Т.е. фактически сам курс Кондрашевского использовался как точка синхронизации с программой вузов (где он все еще базовый). Для самоизучения точно плохой выбор.
Читать статьи
Ок, там, где я попытался читать в своей области - у меня без электронного переводчика и близко нет шансов. Тогда, спрашивается, зачем тратить столько времени на изучение. Я все-таки в плане чтения где-то на уровне адпатированных книжек "Китайский бриз". И до оригинальных статей отсюда очень далеко.
самое простое это смотреть Ютуб
Это да, но тут скорее обратная история: не "я хочу узнать что-то по теме A поэтому смотрю видео-блог китайца B", а "я хочу хоть что-то понимать на языке, который учу, поэтому мне подходит только C"
А автор может добавить чуть больше своего контекста?
Цель изучения это хобби? Иначе неочень понятен фокус на написании иероглифов. Если далее мы говорим про измерение своего уровня через HSK тесты, то ближайший, на котором понадобится что-то писать - это HSK3 (хотя в целом согласен, с какого-то момента приходит озарение, что очень часто знание, как пишется, помогает вспомнить, как читается, но это уже словарный запас ближе к HSK3+).
До какого уровня HSK такой алгоритм довел автора? По моим ощущениям, HSK2 -> HSK3 это первый маленький барьерчик для людей с невысокой мотивацией, HSK3 -> HSK4 - это уже достаточно жесткий водораздел, и высота ступеньки подростает экспоненциально (а дальше я еще не смог заглянуть).
Почему первым выбран очень спорный Кондрашевский? Для самостоятельного обучения он и близко не самый рекомендуемый, и его лексика типа “为实现四个现代化努力工作” уже источник локальных мемов.
Как раз сам сейчас нахожусь в точке изучения, когда первый вау-эффект от того, что у меня получается писать иероглифы, поздороваться со стюардессой и попросить завтрак в отеле схлынул, и пока не готов честно ответить себе на вопрос - зачем IT-шнику китайский. Я изучаю пока в группе, и это позволяет держаться. Т.е. если английский я вижу и использую каждый день, то китайский в свою жизнь приходится втаскивать искусственно: пока изучаю простенькие сериалы и поп.музыку. С удивлением натыкался на снипеты кода с kubeapi и обсуждениями на китайском вокруг, но чтобы их читать, мой уровень и близко не подходит, так что это пока скорее забавное совпадение.
Будет классно, если кто-то сможет подкинуть пример того, что мотивирует к изучению.
а хаб `DevOps`, лонг-рид статья с тегом kafka - это точно то самое место, где можно получить ответ на вопрос о работе техподдержки заказов озона?
Спасибо - отличная статья, даже не столько про именно авторизацию, сколько про архитектуру большой кафки. Вопрос: получилось, что повезло, что авторизация в чистом поле строилась, и до этого не было ничего, а как аналогичный процесс провернуть для тех, кто вырос, и пытается съехать с легаси ACL на RBAC?
Несколько уточняющих вопросов:
High-IOPS-кластера с точки зрения реализации - это что-то похожее на DRBD?
а что происходит при уменьшении объема диска - есть ли какая-то механика дефрагментации?
а как собирается том из фрагментов? Stripe?
Интересно, а у них уже есть планы по увеличению числа женщин, небинарных личностей и расового разнообразия в списке ментейнеров по рекомендации юристов страны, в которой находится фаундейшн?
привет, интересная история, сразу тут встречный вопрос: а в каком смысле поверх OMAP? Вы двигали значение
osd_max_object_sizeили хватает дефолта 128Mb? Листинг реализован как листинг всех объектов пула и внешние индексы вообще не используются?на счет того, какие настройки и как крутить, чтобы Ceph вывозил большие нагрузки на родном индексе, боюсь, так в комментарии не ответить - тянет на отдельную захватывающую историю от команды его эксплуатации. Часть более-менее понятных пунктов типа шардирования-решардирования есть в статье, ну и плюс - очень много делают разработчики Ceph в новых версиях в плане оптимизации.
Хотелось бы для возврата в конструктивное обсуждение уточнить, читали ли вы статью. Потому что она описывает не вопрос выбора между распределенной файловой системой и объектным хранилищем, а повышение производительности уже развитого, масштабного и нагруженного S3 совместимого объектного хранилища.
Для всех задач свои инструменты и та же hdfs у нас успешно параллельно используется.
К счастью все гораздо проще, у нас есть метрики по использованию объектного хранилища в компании за несколько лет, и мы вполне понимаем, какие задачи актуальны, где можно попросить разработчиков не делать глупостей, а где действительно проблемы из реального мира, или особенности работы софта от внешних вендоров.
Кажется, у вас изначально неверные представления о Ceph: Ceph - это архитектурно совсем не CephFS, это RADOS:
RADOS как объектный протокол, конечно, крут и решает очень много задачек для распределенных систем (атомарность, защита от перезаписи, ...) но как стандарт он примерно никем не поддерживается, поэтому надо че-то изобретать поверх.
Дальше вы можете его использовать как CephFS (определенно не самое производительное решение уже на сотнях тысяч объектов), или использовать какие-то решения поверх LibRADOS (или идущие из коробки демоны, или что-то свое), эти решения существенно производительнее для большого числа объектов, ну или для объектов большого размера, типа каких-нибудь бекапов.
Делать свою файловую систему даже и не пытались, и для наших задач POSIX совместимая файловая система явно бессмысленный оверхед. При этом S3 хранилище является сейчас стандартом для большей части как коммерческих, так и OpenSource решений (PostgreSQL, Clickhouse, Prometheus, Gitlab, Allure TestOps, ...), что позволяет строить систему хранения компании на единой платформе, а кроме того эффективно контролировать по стандартным дашбордам профили нагрузки на хранилище.
Ну и раз уж мы используем единую платформу хранения, то начиная с определенных масштабов начинаем сталкиваться с тем, что некоторые системы (Prometheus для семплирования данных, Allure или Gitlab для фоновых индексаций или очистки артефактов) дают нагрузку, которую не переварит никакой FUSE, и даже с трудом переваривает RGW шлюз к Ceph, хотя в версии Reef они провели много крутых оптимизаций, и там, кажется, есть шансы все-таки продержаться на нативном решении.
Ну и отвечая на вопрос - GlusterFS, SeaweedFS и прочие не смотрели, по ряду причин: на больших масштабах смущает уровень зрелости и поддержки проектов относительно Ceph, необходимость перевода всей инфраструктуры на новые рельсы и т.д.
вообще странный на вид наброс, честно сказать вызывает подозрение, сами понимаете какое(?)
primary зона ок, какой-то самоизобретенный термин, но для реплицированного (не EC) кластера ситуация описана валидно: S3 как не работало с репликами, так и не работает, думаю, тут вопрос же в гарантиях консистентности (если кинешь опровергающую информацию - с интересом почитаю)
про EC как решение без оверхеда по диску, которое часто выбирают: тут точно не хватает длинного пояснения про скорость чтения, про расход на CPU и прочие причины, почему можно не выбирать EC для S3
ну и как SO пост про RBD связан со статьей про объектные интерфейсы вообще неясно
а кроме того, статья же явно не про настройку Ceph, а про проектирование системы, своего решения, для которого Ceph используется чисто как blob storage
Так у Ceph фактически все хорошо: они отлично работают с embedded базой для хранения индекса, после того, как добавили функционал шардирования жизнь уж точно заиграла новыми красками, а в Reef они применили какую-то черную магию и еще больше производительность индекса подтянули. Так что как коробочное решение - близко к идеальному. Проблема тут в том, что embeded это ограничение на уровне архитектуры: не можем сами оптимально настроить хранилище, какой бы уровень экспертизы у команды эксплуатации ни был.
Ceph напрямую это как, Librados? Если вы работаете не в CERN, которые вроде как справлялись с этим, и у вас задачи мира бизнеса, работать в терминах нетипизированных объектов небольшого размера будет затруднительно.
Ну тут есть еще часть: так исторически сложилось. Хорошо, что современный MinIO умеет в ребалансировку (честно сказать, не проверял на больших объемах), но когда начинали строить архитектуру достаточно быстро оказались в ситуации, когда MinIO размножался добавлением маленьких MinIO, что было фатально несовместимо с построением централизованной инфраструктуры управления кластером. А такая задача по сути и решалась. Решал эту задачу вполне только Ceph. По ходу дела выяснилось, что если его научиться готовить, то он закрывает более-менее все вопросы:
горизонтальное масштабирование
равномерное распределение нагрузки
(почти)все требуемые домены отказа
а еще имеет ветку развития - блочка (RBD)
Из вопросов к нему было слабое observabiltiy в смысле работы с S3, но с этим и у MinIO было никак.
Вот прям буквально выйдя из Шанхайского Маглева мгновенно попадаешь в мир, где по английски не говорит никто. При том, что в целом люди дружелюбны и стараются помочь, проблема с коммуникацией ощутимая. И это еще международный экономический центр, казалось бы, где как не там.
А HSK Course book - обратная история, совсем без грамматики. Т.е. просто постепенно вводятся слова, подходящие под соответствующий HSK. Ну тогда можно просто на ютубе слушать диалоги к HSK твоего уровня с английскими субтитрами (чисто подготовка к сдаче теста), и при этом учиться по какому-то учебнику, где грамматика все-таки есть.
До критериев грамотности носителя языка человеку, который где-то на уровне двух Кондрашевских, честно сказать, как до луны. Т.е. от человека, который подходит и спрашивает: "Я мавзолей видеть хотеть" я вряд ли буду ожидать, что он, например, будучи китайцем, пишет по-русски.
Фонетические диктанты на первом уровне есть много где. Пособия по иероголифам вообще не являются неотъемлемой частью учебника "Практический курс китайского языка". А вот их проблема - странноватый выбор базовых слов уже где-то с середины первого учебника. И нужна обязательно корректировка от преподавателя, чтобы не нахвататься неадекватных выражений и слов. Если что, я тоже изучал по этому курсу, грамматику приходилось корректировать по листочкам от преподавателя, по "Грамматика китайского языка в таблицах" (сперва) и по Румянцева М. В. - "Пособие по переводу на закрепление и повторение грамматики к Практическому курсу китайского языка" (потом). Т.е. фактически сам курс Кондрашевского использовался как точка синхронизации с программой вузов (где он все еще базовый). Для самоизучения точно плохой выбор.
Ок, там, где я попытался читать в своей области - у меня без электронного переводчика и близко нет шансов. Тогда, спрашивается, зачем тратить столько времени на изучение. Я все-таки в плане чтения где-то на уровне адпатированных книжек "Китайский бриз". И до оригинальных статей отсюда очень далеко.
Это да, но тут скорее обратная история: не "я хочу узнать что-то по теме A поэтому смотрю видео-блог китайца B", а "я хочу хоть что-то понимать на языке, который учу, поэтому мне подходит только C"
А автор может добавить чуть больше своего контекста?
Цель изучения это хобби? Иначе неочень понятен фокус на написании иероглифов. Если далее мы говорим про измерение своего уровня через HSK тесты, то ближайший, на котором понадобится что-то писать - это HSK3 (хотя в целом согласен, с какого-то момента приходит озарение, что очень часто знание, как пишется, помогает вспомнить, как читается, но это уже словарный запас ближе к HSK3+).
До какого уровня HSK такой алгоритм довел автора? По моим ощущениям, HSK2 -> HSK3 это первый маленький барьерчик для людей с невысокой мотивацией, HSK3 -> HSK4 - это уже достаточно жесткий водораздел, и высота ступеньки подростает экспоненциально (а дальше я еще не смог заглянуть).
Почему первым выбран очень спорный Кондрашевский? Для самостоятельного обучения он и близко не самый рекомендуемый, и его лексика типа “为实现四个现代化努力工作” уже источник локальных мемов.
Как раз сам сейчас нахожусь в точке изучения, когда первый вау-эффект от того, что у меня получается писать иероглифы, поздороваться со стюардессой и попросить завтрак в отеле схлынул, и пока не готов честно ответить себе на вопрос - зачем IT-шнику китайский. Я изучаю пока в группе, и это позволяет держаться. Т.е. если английский я вижу и использую каждый день, то китайский в свою жизнь приходится втаскивать искусственно: пока изучаю простенькие сериалы и поп.музыку. С удивлением натыкался на снипеты кода с kubeapi и обсуждениями на китайском вокруг, но чтобы их читать, мой уровень и близко не подходит, так что это пока скорее забавное совпадение.
Будет классно, если кто-то сможет подкинуть пример того, что мотивирует к изучению.