Comments 12
А так как в информации о Colossus очень часто звучит, что в ячейке Master-серверов может находится до 8 узлов, то решение конфликтов с помощью кворума ставится под сомнение.
Может быть что-то типа Арбитра в Mongodb
Арбитр
Также совершенно не ясно, каким образом одна SCI знает, какими данными оперирует другая SCI.
Может быть какие-то дополнительные config-сервера (опять же, пример из mongodb).
Остается только догадываться...
При четном количестве голосующих вполне годится стратегия выбора первого варианта.
Согласно официальной информации:
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 и не интерактивной аналитики
То есть вторая часть статьи неточна
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 и не интерактивной аналитики
То есть вторая часть статьи неточна
> Не поддерживает репликацию между несколькими датацентрами (маловероятно)
Уточните, Вы о репликации critical state (метаданные системы) или о репликации всех данных хранилища?
Речь о репликации всех данных хранилища в статье и не шла. А способа не синхронизировать critical state в распределенных системах совсем я еще не знаю (если не синхронизировать state, то в конце концов узлы, входящие в распределенную систему, станут независимыми системами).
> Поддерживает 1) асинхронную репликацию в расположенные недалеко друг от друга датацентры с целью DR и 2) не интерактивной аналитики
Ничего, из написанного в посте, не противоречит первому утверждению. Про интерактивную аналитику (2-ое утверждение) также упоминания в статье нет.
> вторая часть статьи неточна
Поэтому, что 'неточно' по не ясно.)
Уточните, Вы о репликации critical state (метаданные системы) или о репликации всех данных хранилища?
Речь о репликации всех данных хранилища в статье и не шла. А способа не синхронизировать critical state в распределенных системах совсем я еще не знаю (если не синхронизировать state, то в конце концов узлы, входящие в распределенную систему, станут независимыми системами).
> Поддерживает 1) асинхронную репликацию в расположенные недалеко друг от друга датацентры с целью DR и 2) не интерактивной аналитики
Ничего, из написанного в посте, не противоречит первому утверждению. Про интерактивную аналитику (2-ое утверждение) также упоминания в статье нет.
> вторая часть статьи неточна
Поэтому, что 'неточно' по не ясно.)
Зачем нужно синхронизировать critical state? Два кластера Colossus просто не знают о существовании друг друга, и знать им об этом не нужно. Посмотрите, например, на архитектуру Spanner (источник). Информация о местоположении находится на уровне location proxies и управляет ей placement driver, то есть это приложениезнает о том, в каком из датацентров находятся какие данные, а не файловая система
Про синхронизацию внутри пула мастер-серверов не скажу, но для этой задачи вполне подойдет шардинг метаданных по хэшу пути и синхронная master-slave репликация, хотя тут могут быть нюансы
Про синхронизацию внутри пула мастер-серверов не скажу, но для этой задачи вполне подойдет шардинг метаданных по хэшу пути и синхронная master-slave репликация, хотя тут могут быть нюансы
Интересно, хотя читать из-за курсива тяжело: мало того, что курсив у шрифта без засечек несколько странно смотрится, так еще и выделяя каждое пятое слово, автор будто тыкает читателя, сбивая обычный тому темп чтения и попросту не доверяя, что читатель способен выбрать в тексте нужные слова.
Sign up to leave a comment.
Colossus. Распределенная файловая система от Google