Маштабируемость проекта

Как была одна точка отказа так и осталась. Только теперь это сервер балансер.

ИМХО вот такая схема лучше:

0. DNS round robin+load failover (у dnsmadeeasy или dyn или ещё куча вариантов)

1. сервер балансер.

2. сервер балансер.

3. файлы сайта и база.

4. файлы сайта и база.

Это понятно, два балансера в разных дц, днс вторичный/первичный.

Но чем лучше файлы сайта синхронизировать между серверами?

Думаю использовать для синхронизации файлов сайта lsyncd.

baas, 1 Реально облачный впс решит вашу задачу без гемороя, но придётся раскошелиться:)

Можно ceph использовать, если каналы хорошие.

Как варианты:

1) Простое, но с задержкой - csync2

2) Сложнее, но в реальном времени - кластерная FS (glusterfs,ceph и т.п.)

База мастер-мастер не надёжное решение. Теряется связь между серверами и каждый сам себе мастер. Пойдёт запись в соседний, пока на предыдущем висят запросы - и split brain.

Балансеры тоже. Либо два, либо ни одного (балансировка на уровне DNS и низким TTL и с health check. Типа Amazon route53)

Сплит брейна в мульти-мастере не бывает) сплит-брейн это когда в master/slave где всего один мастер, возникает два мастера (вернувшася нода после промоута).

С этим согласен, если речь про MySQL.

Так это ж и есть суть мультимастера, чтобы каждый сам себе мастер.

Запись в соседний сама не пойдет, если нету роутера. А в их схеме я не вижу роутера запросов. Секрет прост: писать в свою же ноду в том ДЦ, где работает приложение.

Но тут есть несколько но:

во-первых, если это синхронный мультимастер, то при падении одной ноды упадет весь кластер, это раз, скорость записи будет потеряна - это два.

во-вторых, если это асинхронный мультимастер, то при падении ноды мы все равно сможем писать, но если сделать два апдейта на разных серверах одной записи, то получим конфликт, который нужно решать ручками.

ну и с auto_increment_increment нужно заморочиться.

про синхронизацию файлов я бы на вашем месте меньше парился, чем про мультимастер.

я бы взял ceph.

Хмм, пока в раздумье как быть.

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

Если речь за исходники приложения - синхронно деплоить из системы контроля версий (git или что там)

если за всякий аплоад - то можно попробовать glusterfs (только не делайте очень много файлов (5к+) на каталог

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

Поддержу предыдущего оратора.

Если загружаются только картинки, лучше их загружать во внешнее объектное хранилище.

Большинство CMS уже так или иначе умеют это делать.

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

Городить тут ceph избыточно судя по вводным данным.