Контекст:
Допустим, мы разрабатываем новый распределенный сервис с нуля, скажем, аналогичный по набору функций Dropbox или Microsoft Office Online. Основные моменты, на которые следует обратить внимание:
- У нас будет N центров обработки данных (далее D C). Мы хотели бы хранить данные как можно ближе к пользователю, чтобы сократить время прохождения туда-обратно (а также потенциально соответствовать законодательству о местонахождении данных, требуя, чтобы контроллеры домена, хранящие пользовательские данные, находились в той же стране, где проживает пользователь). В момент регистрации пользователь выбирает свое местоположение, так что, скажем, одна эта вещь достаточно хороша, чтобы определить, какие контроллеры домена мы должны выбрать для хранения пользовательских данных.
- Мы бы хотели обрабатывать сбои D C. В случае сбоя одного D C мы бы хотели как-то перенаправить пользователя на другой D C.
- Мы хотели бы найти баланс между рентабельностью и отказоустойчивостью. Итак, все в порядке, чтобы пользовательские данные находились в трех верхах DC. Скажем, что-нибудь еще становится слишком дорогим с точки зрения хранения.
- Мы должны помнить, что перекрестная репликация D-1048 * стоит дорого, поэтому вполне нормально иметь некоторую возможную согласованность между данными в «основной» D C, с которым пользователь в основном взаимодействует, и «резервный» D C. «Резервный» D C для одного пользователя может быть «основным» D C для другого пользователя.
- Пользователь потенциально может хранить огромные объемы информации, которые могут составлять сотни гигабайт. Тем не менее, можно предположить, что запросы на запись будут составлять менее 1%, остальные операции будут считываться.
Вопрос:
Учитывая вышесказанное, каковы хорошие стратегии для Вы разрабатываете функциональность, предоставляющую сервисы, описанные выше, и нацелены на достижение отказоустойчивости?
Примечание:
Пытаясь ответить на этот вопрос самостоятельно, кажется, что одним из наиболее практичных подходов является поддержание состояния, отображающего пользователей к соответствующим «основным» и двум «резервным» DC.
Каждый «D C» будет хранить эти данные, поэтому первоначальный запрос будет перенаправлен на «main» D C и, если «main» «D C недоступен, откат к любому другому« двум »DC.
Похоже, что это позволит изящно поддерживать:
- Окончательно удалить один из существующие контроллеры домена.
- Добавление нового D C.
Обе эти операции потребуют задания обновления, которое в конечном итоге достигнет всех контроллеров домена, и сопоставления обновлений пользователей с контроллерами домена. .
Однако Этот подход, похоже, все еще страдает от проблемы «переизбрания» главного D C в случае длительного сетевого раздела. Также не очень понятно, как действовать, если сетевой раздел изолирует группу пользователей от доступа к определенному D C, в то время как остальной мир, включая другие контроллеры домена, все еще способен обращаться к «главному» D C.
Думая об этом больше, кажется, что распределенные согласованные протоколы, такие как Paxos, мало помогут из-за конкретной проблемы, описанной выше, например, вероятно, никогда не должен быть пользователь, который "выбирает", с каким "мастером" D C они будут работать.
Еще одна вещь, от которой страдает этот дизайн - что делать, если пользователь часто перемещается по всему миру? Кажется, что самый простой ответ состоял бы в том, чтобы по-прежнему сохранять данные в месте назначения по своему выбору, а затем, возможно, перезапускать «резервные» контроллеры домена один за другим с течением времени и, наконец, переизбирать «мастер» D C.
Мне было бы интересно узнать, каковы наиболее практичные подходы к решению проблемы выше. Используют ли люди Paxos для решения этой ситуации? Должен ли я рассмотреть какой-то другой подход к проблеме, отличный от того, что я описал выше?