Здравствуйте, __SPIRIT__, Вы писали:
__S>Очень сложная конструкция. Большая вероятность ошибок из-за постоянного мержа состояний. Неустранимые проблемы с выходом ноды в офлайн. Самое неприятное, когда авария на магистрали и локальная нода доступна пользователям, а вся система нет.
1. Надо обеспечить HA каждой ноды. Т.е. ситуации, что в локальную ноду загрузили данные, а она умерла, не успев синхронизоваться с остальными, быть не должно. На пальцах: локальная "нода" — трёхмашинный кластер, коммит в который требует кворума 2/3. Вероятностью split brain в локальном кластере можно пренебречь.
2. Надо обеспечить более-менее избыточное подключение региональной ноды к интернету. Штука не очень нужная, т.к. современные магистрали как правило лежат редко, а чинятся — быстро. Найти точку на карте интернета, которая может остаться без связи с большой землёй на 48 часов — это какая-то экзотика в труднодоступных местах. Если вам повезло иметь ноду в таком месте, то купите резервный канал. GPRS через другого провайдера, спутник, что угодно.
__S>Не понятно что делать с одновременным изменением одной сущности на разных нодах
Это отдельный большой вопрос. Я знаю три стратегии:
1. Pessimistic locking. Т.е. перед началом изменения мне нужно захватить блокировку на объект, которая получается путём кворума.
2. Разрешение конфликтов.
3. Workflow-based locking. Это разновидность п.1. — когда у документа всегда есть единственный owner, и передача права на редактирование происходит при репликации. При этом забрать право нельзя — можно только отдать.
__S>Долгий апдейт, если на одну ноду загрузили 100Гигов, другие ноды получат данные очень не скоро.
С этим придётся смириться. Это интернет, детка (tm). Альтернатива — одеа центральная нода. Те же 100 гигов до неё доедут очень нескоро — по ровно той же причине. Введение региональных нод позволяет хотя бы местным пользователям оперативно насладиться 100 гигами.
__S>Очень большой уровень дублирования. Большая часть данных дублируется бессмысленно, они просто не будут использованы. Не оптимально
4. Это решается только семантически. Т.е. вы должны уметь хорошо предсказывать, какие данные будут не нужны локальному пользователю. В общем случае — неразрешимо, т.к. если есть возможность порезать связи данных, то вы сразу получаете набор локальных самодостаточных приложений. Которые могут обмениваться какой-то общей информацией, но только в специальных случаях. Ну, типа локальный офис торгует со своего склада; в тех редких случаях, когда нужного товара на локальном складе нет, мы делаем запросы к коллегам и инициируем дорогостоящий процесс перемещения между складами. Если локальных офисов слишком много, то мы можем завести глобальную базу остатков для ускорения поиска — и все будут реплицироваться в неё. Опять таки, решение построено на доскональном знании не только предметной области, но и относительных частот различных сценариев. Получить обобщённый вариант такого решения не представляется возможным.
__S>Это навскидку, уверен проблем будет больше.
Альтернатив, по большому счёту, нету никаких. Либо 1 центральная нода — страдаем от проблем ширины и надёжности канала к ней. Либо локальные ноды = страдаем от проблем ширины и надёжности канала между ними
Чем кончилось-то?
