Jump to content
Калькуляторы

Сайт на нескольких серверах

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

Edited by ttttt

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

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

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

 

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

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

 

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

Edited by ttttt

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
1. Переключение между серверами.

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by ttttt

Share this post


Link to post
Share on other sites

FATHER_FBI

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

ttttt

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

Share this post


Link to post
Share on other sites

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

 

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

Edited by ttttt

Share this post


Link to post
Share on other sites

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

 

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

 

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

Edited by pavel.odintsov

Share this post


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

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Edited by ttttt

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Edited by ttttt

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this