я от балды размер сказал, если чо

10К нодов это не космически много (наверно)

10К нодов это не космически много (наверно)

не космически

ну так а размер осдмапа зависит же от числа нодов

он же местоположение обжекта ВЫЧИСЛЯЕТ а не хранит

или я протупил ?

скажем так, если бы я имел задачу построить кластер под что-то наподобие региона в aws, скорее всего, я бы имел кластера фиксированного среднего размера с асинхронной реплиацией в соседнюю зону отказоустойчивости.

объекта - да, вычисляет. а сам osdmap - хранит и постоянно обновляет.

объекта - да, вычисляет. а сам osdmap - хранит и постоянно обновляет.

эмммм. про вторую фразу можно подробнее?

скажем так, если бы я имел задачу построить кластер под что-то наподобие региона в aws, скорее всего, я бы имел кластера фиксированного среднего размера с асинхронной реплиацией в соседнюю зону отказоустойчивости.

вместо огромного кластера на регион

ой, я имел в виду pgmap.

легче не стало

насколько я понимаю, каждый osd репортит монам о состоянии pg, которые сейчас на нем живут. это происходит с определенным интервалом (на моем кластере - ровно каждую секунду), не уверен, что он конфигурируемый. информация о каждой pg, ее статусе, местоположении и т.п. - стекается на мониторы. все мониторы имеют общий paxos-кворум и полностью копируют эту информацию друг между другом. соответственно, чем больше у нас pg в кластере, тем больше информации в единицу времени приходит на монитор. в определенный момент нам потребуется шардить мониторы. и что-то мне подсказывает, что произойдет это в районе нескольких десятков или сотен тысяч сообщений в секунду (потому что для обработки миллионов сообщений в секунду на одном сервере нужно уже очень сильно возиться).

в определенный момент в нашем сторадже, когда мы стали слишком жирными, нам пришлось организовать шардирование аналогов мониторов.

А зачем мониторам знать где какая пг ?

прост я не очень понял как это всё работает. только часть понял и то не факт что правильно. где б почитать

Each map maintains an iterative history of its operating state changes. Ceph Monitors maintain a master copy of the cluster map including the cluster members, state, changes, and the overall health of the Ceph Storage Cluster.

http://docs.ceph.com/docs/master/architecture/#cluster-map

А зачем мониторам знать где какая пг ?

хороший вопрос. :) я думаю потому что osd не участвуют в paxos и соответственно не умеют в кворум.

хороший вопрос. :) я думаю потому что osd не участвуют в paxos и соответственно не умеют в кворум.

но ведь каждый врайт не проходит скажем так через монитор. поэтому и кворум там кагбе не причём. обращения к монитору я так понимаю эпиздоические от клиента. и если клиент благодаря старому мапу запишет не туда, то потом оно перемапится на нужны осд само. как? ну на осд рано илипоздно будет адекватный крушмап и он поймт что эта пг — не там где надо

http://docs.ceph.com/docs/master/architecture/#cluster-map

такая дока блин. как книжки по программирвоанию. "Если вам нужен синглтон — то он программируется вот так". А ты такой сидишь и думаешь — а мне нужен синглтон ? ХЗ

но ведь каждый врайт не проходит скажем так через монитор. поэтому и кворум там кагбе не причём. обращения к монитору я так понимаю эпиздоические от клиента. и если клиент благодаря старому мапу запишет не туда, то потом оно перемапится на нужны осд само. как? ну на осд рано илипоздно будет адекватный крушмап и он поймт что эта пг — не там где надо

интересный факт, кстати. щас расскажу историю, а выводы делай сам :)

такая дока блин. как книжки по программирвоанию. "Если вам нужен синглтон — то он программируется вот так". А ты такой сидишь и думаешь — а мне нужен синглтон ? ХЗ

дадада!

был у меня кластер. был в нем CRUSH, обычный, плоский. было в кластере около сотни osd. я очень сильно изменил CRUSH (долго объяснять куда и как, да и я не помню уже). 85% данных потребовалось перебалансить. кластер нашел все нужные данные. у меня были высокие цифры tries и ceph нашел _все_ данные, даже учитывая что они лежали совсем не там, где должны были лежать в первые несколько попыток.

был у меня кластер. был в нем CRUSH, обычный, плоский. было в кластере около сотни osd. я очень сильно изменил CRUSH (долго объяснять куда и как, да и я не помню уже). 85% данных потребовалось перебалансить. кластер нашел все нужные данные. у меня были высокие цифры tries и ceph нашел _все_ данные, даже учитывая что они лежали совсем не там, где должны были лежать в первые несколько попыток.

про триес я видел настройку. но не понял к чему это она

про триес я видел настройку. но не понял к чему это она

ну вот у тебя есть chooseleaf, который выбирает три хоста например.

ну

если первый хост, который был выбран, в дауне, то будет выбран четвертый.

второй станет первым, а третий - вторым

и т.д.

ээээ

этот процесс может продолжаться tries раз.

не понятно

я даже не уверен, что это правильно, но это согласуется с поведением, которое я наблюдал.

чтение или запись?

или оба?

а это неважно. тебе надо найти osd, на котором эта PG acting

работает-то всегда только одна osd.

и вот ты получил из CRUSH первый osd. идешь в osdmap, а там говно - osd в ауте.

поэтому получаешь второй - идешь в osdmap, а оно снова в ауте.

так вот я понял что триес — это он такой по крушмапу почитал, обратился, а там хуй. он опять скачал мап, опять посчитал и так далее. не так ?

о, точно

а таймаут какой между попытками ?

или говорит "нет у меня этой PG, нахуй иди" (насколько я понимаю, это как раз о misplaced, и информация о том, что PG misplaced берется из сравнения текущей osdmap, crushmap и pgmap)

или говорит "нет у меня этой PG, нахуй иди" (насколько я понимаю, это как раз о misplaced, и информация о том, что PG misplaced берется из сравнения текущей osdmap, crushmap и pgmap)

блять . я интуитивно даже понял примерно как работает. но в мапах запутался. чото их там много

так вот я понял что триес — это он такой по крушмапу почитал, обратился, а там хуй. он опять скачал мап, опять посчитал и так далее. не так ?

crush - это алгоритм. а crushmap - это та небольшая фигня, которую ты правишь руками и которая меняется при изменении топологии кластера. проще говоря когда ты делаешь in/out - crushmap не меняется.

это я успел понять :)

но вот поменял ты crushmap, а PG сразу не переехала на новое место туда, где она должна жить. и информация о том, где эта PG щас живет хранится в pgmap.

а нахера она там хранится

там же пинцет сколько записей

чтобы эта PG была доступна, даже если лежит не там, где ей положено лежать по CRUSH

должно быть. а нахуа если все выяисляемо (кроме момента перестройки)

потому что иначе ты меняешь CRUSH - и пиздык твоим данным

:)

потому что они есть, но кластер больше не знает, где.

ну не пиздык же а временные затык

НЕТ

не временный

если оно полностью вычисляемо - то кластер не может вычислить.

как нет-то. по крушмапу всегда можно посчитать

только на базе предыдущих состояний osdmap/crushmap

а вот это не понятно

ну у тебя раньше краш показывал "пиздуй в стойку 5, возьми оттуда три любых хоста" а щас ты поправил краш и он стал показывать "пиздуй в зал 7, возьми три любых стойки и возьми из каждой стойки по одному хосту".

чтобы кластер смог отмигрировать данные он должен знать, где эти данные были и есть. где они должны быть - можно посчитать. но где они были и есть - хуюшки, нужно знать.

http://lists.ceph.com/pipermail/ceph-users-ceph.com/2014-April/039339.html - тут вот говорят, что osd репортят о том, какие pg на них есть и какое у них состояние.

пг тоесть

да, опечатка.

так. с вами очень интересно, но у меня есть незаконченное дельце с кроватью и подушкой.

так. с вами очень интересно, но у меня есть незаконченное дельце с кроватью и подушкой.

а нехочешь написать ил рассказать про то как работает цеф ?

а то докладов до ебени матери с той ебучей картинкой про то как либы ссылаются друг на друга

баяны перебояны

я долбоеб и на самом деле в сеф не особо умею.

а как вовнутрях работает — нихера нет

я долбоеб и на самом деле в сеф не особо умею.

ну уж побольше чем я например, очевидно

у меня был небольшой кластер, и многие мои представления крайне интуитивны и далеки от истины. Миша и ребята шарят намного больше.

поэтмоу мне пиздец интересно послушать

у меня был небольшой кластер, и многие мои представления крайне интуитивны и далеки от истины. Миша и ребята шарят намного больше.

они чото не очень разговорчивы.

они обещали устроить митап или что-то такое

уже с полгода обещают :)))

митап - это в нерезиновой поди ?

митап - это в нерезиновой поди ?

два часа лёту, чего ты.

да блин.

Когда и где ?)

Я схожу

пацаны, извините, я вас спалил :(

скажем так, если бы я имел задачу построить кластер под что-то наподобие региона в aws, скорее всего, я бы имел кластера фиксированного среднего размера с асинхронной реплиацией в соседнюю зону отказоустойчивости.

кстати https://www.nextplatform.com/2015/04/16/inside-the-ceph-exascale-storage-at-yahoo/

Each cluster has 54 of these nodes for a total capacity of 3.2 PB. To scale out the service, Yahoo replicates these pods and uses a hashing algorithm to break the unstructured data across the pods and across the nodes using erasure coding.

Each cluster has 54 of these nodes for a total capacity of 3.2 PB. To scale out the service, Yahoo replicates these pods and uses a hashing algorithm to break the unstructured data across the pods and across the nodes using erasure coding.

тоесть кластер кластеров. я правильно понял ?

Йеп

Цэф цэфов собрать? :)

Оно для объектного уровня только сработает нормально

In a blog post that discussed Yahoo’s move from MObStor to Ceph for its Flickr photo-sharing service, the company said that it have over 250 billion objects and around 500 PB of photos, videos, emails, and blog posts that it stores for its users, and that this object storage is growing at 20 percent to 25 percent annually.

в рот мне ноги. я б очканул нахер

это же ёбаный насос сколько данных

у наебнуть их проще простого

а забекапить нельзя

Прикольно, яб там пожил

Прикольно, яб там пожил

с разорванным анусом — это не жизнь. (если накосячишь)

с разорванным анусом — это не жизнь. (если накосячишь)

Я не боюсь мелочей жизни. Мне б железа поинтереснее...