[FATHER_FBI]

Коллеги добрый вечер.

Так как никогда не сталкивался с подобным, прошу помощи коллективного разума.

Хочу разместить сайт на нескольких серверах, одну копию у себя на техплощадке а вторую копию на за бугорном хостере. Что бы пользователи моей сети попадали на сайт который расположен у меня на сервере а пользователи с мира попадали на сайт который на хостере. И что бы изменения в базах данных отражались сразу на обе копии сайтов. Сталкивался кто нибудь с таким?

[ttttt]

Сталкивались, сталкивались.

Тут главное с какой целью это все затевается? Чего хотите добиться в результате? Отказоустойчивости?

 

И что бы изменения в базах данных отражались сразу на обе копии сайтов.

Это вопрос для выбора базы данных или уже что-то типа mysql используется?

Если есть возможность не пользоваться sql базами для такого, то лучше не пользоваться.

Изменено 30 июля, 2015 пользователем ttttt

[grifin.ru]

Поднимали кластер на MariaDB Galera Claster, работает хорошо, но очень желательно не две, а три площадки.

Для самих файлов сайта планируем сделать dbrd или тупо две копии, т.к. меняется редко. Но пока руки не дошли )

[FATHER_FBI]

Тут главное с какой целью это все затевается? Чего хотите добиться в результате? Отказоустойчивости?

Отказоустойчивость

 

Поднимали кластер на MariaDB Galera Claster, работает хорошо, но очень желательно не две, а три площадки.

Для самих файлов сайта планируем сделать dbrd или тупо две копии, т.к. меняется редко. Но пока руки не дошли )

А какая схема у вас галеры? Мастерм-мастер?

[ttttt]

1. Переключение между серверами.

Самое простое - поднимаете днс серверы на всех нодах, прописываете у каждого A запись указывающую на себя с маленьким ttl. Когда сервер не будет доступен, клиенты не будут получать его запись и будут попадать на рабочий. Но не будет нормально работать, если сессии где-то локально хранятся на сервере, а не, допустим, только в куке с цифровой подписью или в распределенной базе.

Чуть сложнее - днс серверы отдельно с healthcheck'ами, проверяющими доступность всех серверов, можно через прокси, чтобы точнее, и если что, меняющие адреса в A записях и инкрементящие серийный номер зоны (ttl тоже должен быть маленький). Так сразу довольно просто получится иметь и разные view'ы и переключаться на разные серверы для разных клиентов и приклеивать клиентов, чтобы, например, оставить локальные сессии.

 

2. Cинхронизация файлов.

Самое простое - rsync, но какой-то сервер должен быть главным и нужно убедиться в том, чтобы юзеры новые файлы не создавали вообще, все только в базу.

Штуки, типа drbd доставят много гемороя на удаленных друг от друга серверах. Проблемы у них точно такие же, как у баз.

 

3. База данных.

Это самое сложное из всего. Проблема тут какая - то, что сейчас называют strong consistency абсолютно несовместимо с высокой доступностью. В strong consistency все серверы должны пользоваться одним мастером, как бы далеко он не находился. А с репликацией на другие серверы любая транзакция еще и не будет коммититься при любых кратковременных проблемах доступности со слейвами, она может закоммититься только когда на все слейвы дошла и то, если это хоть немного правильно сделано и там есть хотя бы two phase commit. А может вообще подвиснуть и сработает алгоритм выбора нового мастера, если он там вообще есть. Все это плохо и с тормозами работает, когда серверы далеко друг от друга. Некоторые балуются асинхронной master-master репликацией, чтобы как-то это решить, но тогда получают еще проблемы потери данных, конфликты данных и постоянно ломающуюся репликацию.

 

Поэтому есть смысл смотреть только на базы с eventual consistency, сейчас они слава богу есть - это и кассандра и риак, например.

Изменено 31 июля, 2015 пользователем ttttt

[FATHER_FBI]

А если тогда сделать такую конфигурацию?

На одной техплощадке находится главный сервер, на котором БД в качестве мастера, а на хостерах разместить слейвы и сайты копировать или через DRDB/rsync/ручками.

[^rage^]

HA из говна и палок?

[ttttt]

Смотря на сколько страшно терять данные. Если не страшно - то что угодно сойдет.

[grifin.ru]

А какая схема у вас галеры? Мастерм-мастер?

Галера-кластер. Это синхронная репликация. Там нет мастеров и слейвов. Там есть ноды )

[stas_k]

1. Переключение между серверами.

Самое простое - поднимаете днс серверы на

самое простое на 80,443 frontend proxy, например nginx. а сам backend на другом порту

[FATHER_FBI]

А какая схема у вас галеры? Мастерм-мастер?

Галера-кластер. Это синхронная репликация. Там нет мастеров и слейвов. Там есть ноды )

Что произойдет если 1 нода потеряет связь с нодой 2, и в этот момент произойдут изменения в базе данных на обех нодах. При восстановлении связи, база развалится?

[ttttt]

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

У галеры такого быть не должно вообще. Если нода потеряла связь, не будет достигнут консенсус на транзакции и по идее после таймаута весь галера кластер будет просто недоступен с обоих нод, пока связь не вернется и они не пересинхронизируются.

В некоторой конфигурации можно сделать, чтобы одна нода становилась главной, так сказать, и продолжала работать, а вторая нет. Т.е. часть системы будет работать, а часть нет.

Изменено 1 августа, 2015 пользователем ttttt

[grifin.ru]

FATHER_FBI

Если нода выпадает из кластера то она перестает выполнять SQL запросы. Поэтому и желательно чтоб было минимум три ноды, чтб две оставшиеся понимали что они все еще кластер. В принципе можно и на двух настроить, тогда одной надо дать больший вес. При разваливании кластера та, у которой вес больше 50% будет считать себя кластером, а вторая будет в пассиве до восстановления свзяи. Как связь восстановится - она реплицируется с кластером и потом включится в него.

ttttt

Только не консенсус, а кворум )))

[ttttt]

Вообще-то консенсус, а кворум - это способ достижения консенсуса, не путайтесь ))

 

Ну и по теме - проблема в том, что галера и все, что на базе mysql - это CP системы, а не AP и следовательно высокую доступность ими достичь невозможно.

Изменено 1 августа, 2015 пользователем ttttt

[pavel.odintsov]

Всем, кто хочет строить HA (high availibility) из костылей и палок у меня всегда один вопрос: реально ли простой Вашего сервиса стоит таких огромных денег, чтобы потратить на обеспечение надежности _вдвое_ больше ресурсов (и материальных и технических), чтобы добиться избавления от простоя в какие-то полчаса в год?

 

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

 

Поэтому самое лучшее пожелание что я могу дать - разместиться на хорошей площадке и хорошем _серверном_ оборудовании (не забывая про холодный склад!), где учтены такие устоявшиеся практики как - резервироанный блок питания, ECC память и по-возможности хорошо резервированная сетка :)

Изменено 3 августа, 2015 пользователем pavel.odintsov

[stas_k]

всегда один вопрос: реально ли простой Вашего сервиса стоит таких огромных денег, чтобы потратить на обеспечение надежности _вдвое_ больше ресурсов (и материальных и технических), чтобы добиться избавления от простоя в какие-то полчаса в год?

Это вопрос престижу.

 

Поэтому самое лучшее пожелание что я могу дать - разместиться на хорошей площадке и хорошем _серверном_ оборудовании

Одно другого не исключает.

 

Ну и на самом деле, поддерживать один LAMP скучно. нужно расти над собой, изучать новые технолгии и быть в струе.

[pavel.odintsov]

Так или иначе - идеального варианта растащить сайт на две машины и заставить их работать одновременно, который был спроектирован без "reliability in mind" - не существует.

 

Это будут костыли, палки и SPoF, который просто не увидели в новой красивой надежной схеме.

 

Если сайт статичсекий и не подразумевает частого обновления - эникаст (не забываем про /24ку) и просто синхронинзация чем-то класса rsyn.

[ttttt]

чтобы добиться избавления от простоя в какие-то полчаса в год?

Все намного хуже. Полчаса в год даже теоретически типичные "хорошие" таер3 датацентры не позволяют добиться. А на практике простои на порядок хуже, пол дня, а то и день не работать - в порядке вещей.

 

реально ли простой Вашего сервиса стоит таких огромных денег,

Потери от простоя для сайтов нельзя переоценить, они не вычисляются по формуле, если сайт, конечно, не говно сеошное с 80% аудиторией из поисковиков.

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

 

эникаст (не забываем про /24ку)

Эникаст не дешево и не просто заставить хорошо работать, сайты такое себе позволить не могут, только крупные CDN могут.

[FATHER_FBI]

Коллеги пока что пришел к выводу что идеальным решением будет на каждом из своих ДЦ развестить по серверу БД в схеме Master-Master. Пока что еще не придумал как более корректно к БД прикрутить сайты. Что бы пользователь мог зайти например на сайт который будет размещен в Германии, оставить пост на форуме и он упал в БД. Вот тут вопрос. Или схема что бы к каждому мастеру прилагался свой web сервер, или сайты пустить через какой нибудь фронтенд.

[ttttt]

Коллеги пока что пришел к выводу что идеальным решением будет на каждом из своих ДЦ развестить по серверу БД в схеме Master-Master.

Если только для форума, то может и сойдет асинхронная мастер-мастер репликация и получится жалкое подобие AP систем. Конфликты новых постов можно резолвить разными значениями авто инкрементов на разных мастерах. Апдейтов с разных серверов у форума не должно быть, но если вдруг будут, то они, конечно, иногда будут затираться и данные будут теряться. Если с таким можно мириться, то пробуйте. Не забудьте еще время синхронизировать между серверами.

Изменено 3 августа, 2015 пользователем ttttt

[grifin.ru]

Смотреть надо по нагрузке.

Мастер-мастер не самое лучшее решение, при малой нагрузке БД на запись лучше сделать синхронную репликацию (Galera). В разы надежнее.

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

Так же можно делать мастер мастер, но пиать всегда в одну базу только и опять же переключать вручную при аварии.

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

[ttttt]

Кстати о падениях - у вк сегодня оборвался линк между датацентрами, все лежало :)

Изменено 4 августа, 2015 пользователем ttttt

[rdntw]

Кстати о падениях - у вк сегодня оборвался линк между датацентрами, все лежало :)

и до сих пор вроде

[FATHER_FBI]

Ну вот примерно такого эффекта хочется избежать. Поэтому и думаю разместить сайт на нескольких серверах)

[nu11]

ТС, опишите сначала проблему, которую вы хотите решить.