Подскажите, какие существуют на данный момент отказоустойчивые решения для веб-приложений? Архитектура приложения на данный момент такая - клиент (веб и десктопный) - nginx (отдельный виртуалхост с поддоменом на логическую группу клиентов) - tomcat (одно здоровенное ява-приложение на спринге) - mysql (отдельная база на ту же логическую группу клиентов плюс общесистемная база). Сейчас всё довольно бодро крутится на одном medium-инстансе на амазоне плюс small-инстанс rds (даже без multi-az). Планировалось после раскрутки проекта нарастить мощность и использовать некоторые фичи амазона вроде балансировщика и route 53, но законы и курс доллара вынуждают переезжать в Россию, где хостингов с подобной инфраструктурой нет. Так что надо изобразить что-то минимальное самому.
Вариант 1, классический. Основной сервер с приложением и базой в одном дата-центре, слэйв-база в другом датацентре. В случае падения основного сервера поднимаем резервный в другом датацентре, переключаем dns на него. Простой составит от десяти минут до часа. В особо тяжёлых случаях игнорирования ttl у dns-записей провайдерами - до нескольких часов.
Вариант 2. Round-robin на днсах. Два равноценных сервера в разных датацентрах, mysql в режиме мастер-мастер либо же galera с арбитром. В случае падения одного сервера или датацентра опять слушаем ругань клиентов, но уже вдвое меньше. Опять же, до тех пор, пока не обновятся днсы либо пока не воспрянет упавший сервер/датацентр. Из минусов ещё и то, что само приложение не рассчитано и не тестировалось на параллельную работу, возникают потери сессий и тому подобное непотребство. Но это можно минимально пофиксить, отправляя на nginx'ах одних и тех же клиентов на один и тот же апстрим. Ну и скорость работы при синхронной репликации будет заметно ниже.
Вариант 3, вариация классического. Добавляем перед основным сервером парочку фронт-эндов, этакий недо-cdn. В это случае, имея один сервер приложения в горячем резерве, простой можно свести ко времени таймаута ожидания ответа от апстрима. Но если падает фронт-энд, всё опять же сводится к первому варианту.
Всякие фишки вроде CARP и распределённых файловых систем выглядят интересно, но, как мне кажется, это из пушки по воробьям. Например, чем репликация на уровне базы данных хуже репликации на уровне файловой системы? Файловая система ведь ещё и оверхэд будет давать некоторый.
UPD. Работал всего с двумя российскими хоситнг-провайдерами, у обоих регулярно падала маршрутизация (это не считая иных проблем, напрямую к теме не относящихся).
