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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.