FATHER_FBI Posted July 30, 2015 Posted July 30, 2015 Коллеги добрый вечер. Так как никогда не сталкивался с подобным, прошу помощи коллективного разума. Хочу разместить сайт на нескольких серверах, одну копию у себя на техплощадке а вторую копию на за бугорном хостере. Что бы пользователи моей сети попадали на сайт который расположен у меня на сервере а пользователи с мира попадали на сайт который на хостере. И что бы изменения в базах данных отражались сразу на обе копии сайтов. Сталкивался кто нибудь с таким? Вставить ник Quote
ttttt Posted July 30, 2015 Posted July 30, 2015 (edited) Сталкивались, сталкивались. Тут главное с какой целью это все затевается? Чего хотите добиться в результате? Отказоустойчивости? И что бы изменения в базах данных отражались сразу на обе копии сайтов. Это вопрос для выбора базы данных или уже что-то типа mysql используется? Если есть возможность не пользоваться sql базами для такого, то лучше не пользоваться. Edited July 30, 2015 by ttttt Вставить ник Quote
grifin.ru Posted July 31, 2015 Posted July 31, 2015 Поднимали кластер на MariaDB Galera Claster, работает хорошо, но очень желательно не две, а три площадки. Для самих файлов сайта планируем сделать dbrd или тупо две копии, т.к. меняется редко. Но пока руки не дошли ) Вставить ник Quote
FATHER_FBI Posted July 31, 2015 Author Posted July 31, 2015 Тут главное с какой целью это все затевается? Чего хотите добиться в результате? Отказоустойчивости? Отказоустойчивость Поднимали кластер на MariaDB Galera Claster, работает хорошо, но очень желательно не две, а три площадки. Для самих файлов сайта планируем сделать dbrd или тупо две копии, т.к. меняется редко. Но пока руки не дошли ) А какая схема у вас галеры? Мастерм-мастер? Вставить ник Quote
ttttt Posted July 31, 2015 Posted July 31, 2015 (edited) 1. Переключение между серверами. Самое простое - поднимаете днс серверы на всех нодах, прописываете у каждого A запись указывающую на себя с маленьким ttl. Когда сервер не будет доступен, клиенты не будут получать его запись и будут попадать на рабочий. Но не будет нормально работать, если сессии где-то локально хранятся на сервере, а не, допустим, только в куке с цифровой подписью или в распределенной базе. Чуть сложнее - днс серверы отдельно с healthcheck'ами, проверяющими доступность всех серверов, можно через прокси, чтобы точнее, и если что, меняющие адреса в A записях и инкрементящие серийный номер зоны (ttl тоже должен быть маленький). Так сразу довольно просто получится иметь и разные view'ы и переключаться на разные серверы для разных клиентов и приклеивать клиентов, чтобы, например, оставить локальные сессии. 2. Cинхронизация файлов. Самое простое - rsync, но какой-то сервер должен быть главным и нужно убедиться в том, чтобы юзеры новые файлы не создавали вообще, все только в базу. Штуки, типа drbd доставят много гемороя на удаленных друг от друга серверах. Проблемы у них точно такие же, как у баз. 3. База данных. Это самое сложное из всего. Проблема тут какая - то, что сейчас называют strong consistency абсолютно несовместимо с высокой доступностью. В strong consistency все серверы должны пользоваться одним мастером, как бы далеко он не находился. А с репликацией на другие серверы любая транзакция еще и не будет коммититься при любых кратковременных проблемах доступности со слейвами, она может закоммититься только когда на все слейвы дошла и то, если это хоть немного правильно сделано и там есть хотя бы two phase commit. А может вообще подвиснуть и сработает алгоритм выбора нового мастера, если он там вообще есть. Все это плохо и с тормозами работает, когда серверы далеко друг от друга. Некоторые балуются асинхронной master-master репликацией, чтобы как-то это решить, но тогда получают еще проблемы потери данных, конфликты данных и постоянно ломающуюся репликацию. Поэтому есть смысл смотреть только на базы с eventual consistency, сейчас они слава богу есть - это и кассандра и риак, например. Edited July 31, 2015 by ttttt Вставить ник Quote
FATHER_FBI Posted August 1, 2015 Author Posted August 1, 2015 А если тогда сделать такую конфигурацию? На одной техплощадке находится главный сервер, на котором БД в качестве мастера, а на хостерах разместить слейвы и сайты копировать или через DRDB/rsync/ручками. Вставить ник Quote
ttttt Posted August 1, 2015 Posted August 1, 2015 Смотря на сколько страшно терять данные. Если не страшно - то что угодно сойдет. Вставить ник Quote
grifin.ru Posted August 1, 2015 Posted August 1, 2015 А какая схема у вас галеры? Мастерм-мастер? Галера-кластер. Это синхронная репликация. Там нет мастеров и слейвов. Там есть ноды ) Вставить ник Quote
stas_k Posted August 1, 2015 Posted August 1, 2015 1. Переключение между серверами.Самое простое - поднимаете днс серверы на самое простое на 80,443 frontend proxy, например nginx. а сам backend на другом порту Вставить ник Quote
FATHER_FBI Posted August 1, 2015 Author Posted August 1, 2015 А какая схема у вас галеры? Мастерм-мастер? Галера-кластер. Это синхронная репликация. Там нет мастеров и слейвов. Там есть ноды ) Что произойдет если 1 нода потеряет связь с нодой 2, и в этот момент произойдут изменения в базе данных на обех нодах. При восстановлении связи, база развалится? Вставить ник Quote
ttttt Posted August 1, 2015 Posted August 1, 2015 (edited) Что произойдет если 1 нода потеряет связь с нодой 2, и в этот момент произойдут изменения в базе данных на обех нодах. У галеры такого быть не должно вообще. Если нода потеряла связь, не будет достигнут консенсус на транзакции и по идее после таймаута весь галера кластер будет просто недоступен с обоих нод, пока связь не вернется и они не пересинхронизируются. В некоторой конфигурации можно сделать, чтобы одна нода становилась главной, так сказать, и продолжала работать, а вторая нет. Т.е. часть системы будет работать, а часть нет. Edited August 1, 2015 by ttttt Вставить ник Quote
grifin.ru Posted August 1, 2015 Posted August 1, 2015 FATHER_FBI Если нода выпадает из кластера то она перестает выполнять SQL запросы. Поэтому и желательно чтоб было минимум три ноды, чтб две оставшиеся понимали что они все еще кластер. В принципе можно и на двух настроить, тогда одной надо дать больший вес. При разваливании кластера та, у которой вес больше 50% будет считать себя кластером, а вторая будет в пассиве до восстановления свзяи. Как связь восстановится - она реплицируется с кластером и потом включится в него. ttttt Только не консенсус, а кворум ))) Вставить ник Quote
ttttt Posted August 1, 2015 Posted August 1, 2015 (edited) Вообще-то консенсус, а кворум - это способ достижения консенсуса, не путайтесь )) Ну и по теме - проблема в том, что галера и все, что на базе mysql - это CP системы, а не AP и следовательно высокую доступность ими достичь невозможно. Edited August 1, 2015 by ttttt Вставить ник Quote
pavel.odintsov Posted August 3, 2015 Posted August 3, 2015 (edited) Всем, кто хочет строить HA (high availibility) из костылей и палок у меня всегда один вопрос: реально ли простой Вашего сервиса стоит таких огромных денег, чтобы потратить на обеспечение надежности _вдвое_ больше ресурсов (и материальных и технических), чтобы добиться избавления от простоя в какие-то полчаса в год? А второй вопрос - что стоит понимать, что _любая_ HA схема крушится на порядки мощнее и эпичеее, чем простой серверочек на LAMP стоящий где-то в углу. И тут предпочтительнее (с любой стороны - и техники и финансов) иметь надежный бэкап и полу либо полностью автоматизированный процесс развертывания железа и софта в случае сбоя сервиса. Поэтому самое лучшее пожелание что я могу дать - разместиться на хорошей площадке и хорошем _серверном_ оборудовании (не забывая про холодный склад!), где учтены такие устоявшиеся практики как - резервироанный блок питания, ECC память и по-возможности хорошо резервированная сетка :) Edited August 3, 2015 by pavel.odintsov Вставить ник Quote
stas_k Posted August 3, 2015 Posted August 3, 2015 всегда один вопрос: реально ли простой Вашего сервиса стоит таких огромных денег, чтобы потратить на обеспечение надежности _вдвое_ больше ресурсов (и материальных и технических), чтобы добиться избавления от простоя в какие-то полчаса в год? Это вопрос престижу. Поэтому самое лучшее пожелание что я могу дать - разместиться на хорошей площадке и хорошем _серверном_ оборудовании Одно другого не исключает. Ну и на самом деле, поддерживать один LAMP скучно. нужно расти над собой, изучать новые технолгии и быть в струе. Вставить ник Quote
pavel.odintsov Posted August 3, 2015 Posted August 3, 2015 Так или иначе - идеального варианта растащить сайт на две машины и заставить их работать одновременно, который был спроектирован без "reliability in mind" - не существует. Это будут костыли, палки и SPoF, который просто не увидели в новой красивой надежной схеме. Если сайт статичсекий и не подразумевает частого обновления - эникаст (не забываем про /24ку) и просто синхронинзация чем-то класса rsyn. Вставить ник Quote
ttttt Posted August 3, 2015 Posted August 3, 2015 чтобы добиться избавления от простоя в какие-то полчаса в год? Все намного хуже. Полчаса в год даже теоретически типичные "хорошие" таер3 датацентры не позволяют добиться. А на практике простои на порядок хуже, пол дня, а то и день не работать - в порядке вещей. реально ли простой Вашего сервиса стоит таких огромных денег, Потери от простоя для сайтов нельзя переоценить, они не вычисляются по формуле, если сайт, конечно, не говно сеошное с 80% аудиторией из поисковиков. Сервисы, например, юзеры сравнивают с гуглами, привыкли к их стабильности и ожидают, что все всегда будет работать. Пол дня простоя выливается в сломанные ожидания и большой ущерб лояльности - потерю самых активных юзеров, самых активных клиентов, самых евангелистов, что для многих сайтов очень критично и может вообще похоронить весь бизнес (примеры есть). эникаст (не забываем про /24ку) Эникаст не дешево и не просто заставить хорошо работать, сайты такое себе позволить не могут, только крупные CDN могут. Вставить ник Quote
FATHER_FBI Posted August 3, 2015 Author Posted August 3, 2015 Коллеги пока что пришел к выводу что идеальным решением будет на каждом из своих ДЦ развестить по серверу БД в схеме Master-Master. Пока что еще не придумал как более корректно к БД прикрутить сайты. Что бы пользователь мог зайти например на сайт который будет размещен в Германии, оставить пост на форуме и он упал в БД. Вот тут вопрос. Или схема что бы к каждому мастеру прилагался свой web сервер, или сайты пустить через какой нибудь фронтенд. Вставить ник Quote
ttttt Posted August 3, 2015 Posted August 3, 2015 (edited) Коллеги пока что пришел к выводу что идеальным решением будет на каждом из своих ДЦ развестить по серверу БД в схеме Master-Master. Если только для форума, то может и сойдет асинхронная мастер-мастер репликация и получится жалкое подобие AP систем. Конфликты новых постов можно резолвить разными значениями авто инкрементов на разных мастерах. Апдейтов с разных серверов у форума не должно быть, но если вдруг будут, то они, конечно, иногда будут затираться и данные будут теряться. Если с таким можно мириться, то пробуйте. Не забудьте еще время синхронизировать между серверами. Edited August 3, 2015 by ttttt Вставить ник Quote
grifin.ru Posted August 3, 2015 Posted August 3, 2015 Смотреть надо по нагрузке. Мастер-мастер не самое лучшее решение, при малой нагрузке БД на запись лучше сделать синхронную репликацию (Galera). В разы надежнее. Если нагрузка большая то, в первую очередь нужно рассмотреть мастер-слейв с ручнымы переключением на слейв в случае падения мастера. Так же можно делать мастер мастер, но пиать всегда в одну базу только и опять же переключать вручную при аварии. Решение Мастер-Мастер можно использовать только если ты понимаешь что ты делаешь и твой софт это предусматривает. Вставить ник Quote
ttttt Posted August 4, 2015 Posted August 4, 2015 (edited) Кстати о падениях - у вк сегодня оборвался линк между датацентрами, все лежало :) Edited August 4, 2015 by ttttt Вставить ник Quote
rdntw Posted August 4, 2015 Posted August 4, 2015 Кстати о падениях - у вк сегодня оборвался линк между датацентрами, все лежало :) и до сих пор вроде Вставить ник Quote
FATHER_FBI Posted August 4, 2015 Author Posted August 4, 2015 Ну вот примерно такого эффекта хочется избежать. Поэтому и думаю разместить сайт на нескольких серверах) Вставить ник Quote
nu11 Posted August 9, 2015 Posted August 9, 2015 ТС, опишите сначала проблему, которую вы хотите решить. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.