Colossus. Распределенная файловая система от Google

[aivus]

А так как в информации о Colossus очень часто звучит, что в ячейке Master-серверов может находится до 8 узлов, то решение конфликтов с помощью кворума ставится под сомнение.

Может быть что-то типа Арбитра в Mongodb

Арбитр

Также совершенно не ясно, каким образом одна SCI знает, какими данными оперирует другая SCI.

Может быть какие-то дополнительные config-сервера (опять же, пример из mongodb).

Остается только догадываться...

[kibergus]

В mongodb нет голосования. Там есть timestamp последнего изменения. У кого он больше, тот и master. Но чтобы не допустить split brain ситуации, master'а может выбирать только группа серверов, видящая более половины всех серверов.

[Antiarchitect]

Есть замечательный человек, который пишет по поводу consistency в распределенных системах и о распределенных ситсемах:
Блог
Спич
В общем суть такова, что решения в общем виде нет и CRDT — это наше все.

[mynameco]

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

[miolini]

или последнего?

[mynameco]

Нет, именно первого! Такая стратегия, без каких либо вариантов.

[ElleSolomina]

Именно! А ещё у Google в ДЦ всё очень строго с синхронизацией времени, так что данная схема наиболее вероятна.

[0x0FFF]

Согласно официальной информации:
1. «The Spanner servers in each datacenter in turn retrieve their data from the Colossus File System (CFS) [14] in the same datacenter. Unlike Spanner, CFS is not a globally replicated service and therefore Spanner servers will never communicate with remote CFS instances» (источник)
2. «Storage Software: Colossus… Client-driven replication, ...» (источник)

Итого разумно предположить, что сам по себе Colossus:
а. Не поддерживает репликацию между несколькими датацентрами (маловероятно)
б. Поддерживает асинхронную репликацию в расположенные недалеко друг от друга датацентры с целью DR и не интерактивной аналитики
То есть вторая часть статьи неточна

[codezombie]

> Не поддерживает репликацию между несколькими датацентрами (маловероятно)
Уточните, Вы о репликации critical state (метаданные системы) или о репликации всех данных хранилища?
Речь о репликации всех данных хранилища в статье и не шла. А способа не синхронизировать critical state в распределенных системах совсем я еще не знаю (если не синхронизировать state, то в конце концов узлы, входящие в распределенную систему, станут независимыми системами).

> Поддерживает 1) асинхронную репликацию в расположенные недалеко друг от друга датацентры с целью DR и 2) не интерактивной аналитики
Ничего, из написанного в посте, не противоречит первому утверждению. Про интерактивную аналитику (2-ое утверждение) также упоминания в статье нет.

> вторая часть статьи неточна
Поэтому, что 'неточно' по не ясно.)

[0x0FFF]

Зачем нужно синхронизировать critical state? Два кластера Colossus просто не знают о существовании друг друга, и знать им об этом не нужно. Посмотрите, например, на архитектуру Spanner (источник). Информация о местоположении находится на уровне location proxies и управляет ей placement driver, то есть это приложениезнает о том, в каком из датацентров находятся какие данные, а не файловая система

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

[achekalin]

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

[SkyRE]

Не GFS — а Google File System
GFS это от RedHat