Как развернуть несколько отказоустойчивых серверов?

Question

[Денис Лысенко]

Есть веб-приложение. Нужно добиться максимальной отказоустойчивости. Будем использовать несколько серверов. Сначала два сервера, потом, возможно, еще больше. То есть, если один сервер выходит из строя (например, пожар в датацентре), то приложение продолжает работать за счет второго/третьего сервера в других датацентрах.

Какие варианты разворачивания здесь будут? Не хотелось бы вручную настраивать каждый сервер (установка и настройка Nginx, Ruby, Rails, PostgreSQL). Есть ли вариант настроить один сервер и склонировать его на остальные?

Плюс нужна синхронизация баз данных PostgreSQL (master - master, чтобы могли писать оба сервера в БД) и файлов приложения между серверами. Какие решения здесь лучше использовать?

Есть ли возможность синхронизировать все файлы между серверами? Чтобы достаточно было сделать обновление ПО на одном сервере и все обновления подтянулись на остальные серверы?

Answer 1

[Алексей Черемисин]

По пунктам:

Какие варианты разворачивания здесь будут?

Применяются средства администрирования и конфигурирования, такие как puppet, chif, ansible. Т.е. один раз создаем сценарий на выбранном инструменте, а потом его "проигрываем" на нужный сервер.

Плюс нужна синхронизация баз данных PostgreSQL

Я бы с мастер-мастер не стал делать, настоятельно не стал бы! Лучше запусить несколько баз данных и шардировать данные на них. Про шардинг почитать например здесь - ruhighload.com/index.php/2009/05/06/%D1%88%D0%B0%D...
А еще лучше некоторые (если не все данные) хранить в базах данных ключ/значение типа memcache/ redis, или в объектных типа hadoop/mongodb.

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

Лучше всего сделать распределенную файловую систему типа glusterfs, GPFS, cephfs, lustre. А самый простой - просто использовать rsync, но это медленно, большой лаг, и, неэффективно.

Comments

[mgyk]

Статические фаилы лучше сразу в S3 вынести и не заморачиваться.

[Алексей Черемисин]

Не, пока мы трём за архитектуру, а оптимизировать - это потом...

[Денис Лысенко]

Большой лаг в принципе не критичен, т.к. файлы обновляются на часто, хотим попробовать rsync + lsyncd. Для репликации pg хотели использовать bucardo (habrahabr.ru/sandbox/65312/)

[Алексей Черемисин]

Ну, вот :-( Всё, что не стоит делать, мы и делаем. Забег по граблям объявляем открытым?

PS. Поставьте glusterfs и избавьтесь от репликации и шардируйте базы данных.
И да, это потребует некоторого вмешательства в код (для шардинга), но это на порядок, именно на порядок, лучшее решение, чем городить промежуточный слой с кучей проблем в дальнейшем.

[Денис Лысенко]

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

[Денис Лысенко]

И еще, можете привести типичные проблемы master - master репликации? Чем это грозит?

[Алексей Черемисин]

Отказоустойчивости - никак, а про нее в изначальном вопросе ничего и не было сказано. А если про нее говорить, то делайте мастер-слейв репликацию, вот отказоустойчивость и появится. Или для таких случаем держите бакап-базу (две-три если нужно), куда раз в сколько-то сливайте все изменения со всех серверов, и когда шардинг рассыпается, то подключайтесь к ней на чтение. В любом случае политик здесь будет гораздо больше, чем непрерывно лить изменения со всех на все. Или как политика, если какой-то кусок шардинга недоступен, то льем данные в локальную базу, а потом переливаем куда нужно, при этом кусок данных упавшего сервера будет конечно недоступен, а вот критично это или нет - все зависит как построить приложение...

[Алексей Черемисин]

Проблемы? Да их есть куча!!! вот например с мускулом - habrahabr.ru/company/bitrix/blog/146490
Для ростгреса практически все также актуально, как собственно и для оракла сайбейса и всех остальных.
Тем более, что в изначальном вопросе был намек на быстрое добавление новых нод (в том числе, как я понял и баз данных), что в случае с мастер-мастер приведет к лавионобразному росту трафика, блокировакам, рассинхронизации данных и всему остальному хорошему.
Попробуйте для себя разбить задачу на три:
- добавление новых нод
- резервирование данных
- восстановление после сбоя
И мир будет без мастер-мастер репликации.
Мастер-мастер иногда нужна, когда есть приложение, а программистов для него уже нет. Вот тут ничего другого и не остается, увы... Но делать так с самого начала - увольте.

[Денис Лысенко]

Да, спасибо за аргументы :) В целом согласен, первая задача - восстановление после сбоя. Есть два-три сервера, если на одном пропало питание, все должно работать дальше без потери данных. Но мы не можем себе позволить пока что держать несколько серверов для БД. То есть, как я поимаю, это должны быть два-три идентичных сервера, каждый из которых будет независим от других (т.е. иметь и приложение и базу данных внутри себя). В прицнипе мастер - слейв должен подойти. Когда приложения на обеих серверах будут писать в мастер и читать со слейва, но если вдруг мастер умирает, то один из слевов становится новым мастером.

Answer 2

[Rrooom]

Нанять админа?

Для настройки понадобятся слова вроде chef, ansible. Для файлов rsync.
Если нравится хипстерство, то может быть еще mesos, docker.