Возникла задача синхронизации нескольких серверов, обрабатывающих запросы от клиентов. Сервера находятся за load balancing и сессия не привязывается к конкретному серверу.
Проблема возникла абсолютно классическая: клиент шлет запросы на обновления его состояния, они выполняются в различном порядке различными серверами, что, в итоге, приводит к неверному состоянию. Требуется выбирать состояние, проверять очередность и сохранять. Но на период между выборкой и сохранением нужно блокировать состояние. Отсюда и возникает эта задача.
Так как состояние храниться в базе и в кеше (memcached) то неясно, через что производить блокировку.
Если через базу, то в случае масштабирования серверов баз данных (а мы используем MS SQL) master-slave этот подход не будет работать.
В memcached я не нашел механизмов синхронизации (может кто знает?)
И думается мне, что лучше взять еще один сервер БД (или что-то специализированное для этого) и делать через него синхронизацию.
Вопрос состоит в том, как лучше поступить? И какие средства существуют для этого?
Сервер реализован на платформе .NET 3.5.
Здравствуйте, DaDa Cloun, Вы писали:
DC>Приветствую всех!
DC>Возникла задача синхронизации нескольких серверов, обрабатывающих запросы от клиентов. Сервера находятся за load balancing и сессия не привязывается к конкретному серверу. DC>Проблема возникла абсолютно классическая: клиент шлет запросы на обновления его состояния, они выполняются в различном порядке различными серверами, что, в итоге, приводит к неверному состоянию. Требуется выбирать состояние, проверять очередность и сохранять. Но на период между выборкой и сохранением нужно блокировать состояние. Отсюда и возникает эта задача. DC>Так как состояние храниться в базе и в кеше (memcached) то неясно, через что производить блокировку. DC>Если через базу, то в случае масштабирования серверов баз данных (а мы используем MS SQL) master-slave этот подход не будет работать. DC>В memcached я не нашел механизмов синхронизации (может кто знает?) DC>И думается мне, что лучше взять еще один сервер БД (или что-то специализированное для этого) и делать через него синхронизацию. DC>Вопрос состоит в том, как лучше поступить? И какие средства существуют для этого? DC>Сервер реализован на платформе .NET 3.5.
DC>Всем спасибо за ответы.
Лучше всего для такого использовать средства БД, руками такое писать замучаетесь.
Re[2]: Синхронизация серверов через кеш/базу/или еще что-то?
Здравствуйте, DaDa Cloun, Вы писали:
DC>Здравствуйте, gandjustas, Вы писали:
G>>Лучше всего для такого использовать средства БД, руками такое писать замучаетесь.
DC>То есть вы считаете что лучше завести для этих целей базу через которую будет происходить синхронизация?
Я считаю что лучше mirroring\failover натстроить.
Re: Синхронизация серверов через кеш/базу/или еще что-то?
Кеши я предлодил бы обновлять с использованием паттерна асинхронный тригер.
Асинхронный тригер — это обычный тригер на таблице который не делает ничего кроме того, что пишет сообщение в очередь.
Затем сообщение из очереди может быть прочитано приложением, соответственно после прочтения приложение понимает что данные изменились и может обновить или сбросить кеш.
Блокировки — это отдельная тема, тут надо поближе с требованиями познакомиться.
Народная мудрось
всем все никому ничего(с).
Re[4]: Синхронизация серверов через кеш/базу/или еще что-то?
Здравствуйте, Tom, Вы писали:
Tom>Класическая задача = класическое решение.
Tom>Кеши я предлодил бы обновлять с использованием паттерна асинхронный тригер. Tom>Асинхронный тригер — это обычный тригер на таблице который не делает ничего кроме того, что пишет сообщение в очередь. Tom>Затем сообщение из очереди может быть прочитано приложением, соответственно после прочтения приложение понимает что данные изменились и может обновить или сбросить кеш.
Это не та проблема которую мне надо решать. Мне нужно именно синхронизировать несколько серверов. На самом деле для этого существуют системы распределенной блокировки DLM. Вот в этом направлении и будем двигаться.
Re: Синхронизация серверов через кеш/базу/или еще что-то?
Здравствуйте, DaDa Cloun, Вы писали:
DC>А можно чуточку подробней, а то я не понял терминологии и идеи в целом?
Да никакой магии, просто настроить load balancing, чтобы запросы от одного клиента шли к одному и тому же серверу. Если, конечно, у вас это возможно.
Re[3]: Синхронизация серверов через кеш/базу/или еще что-то?
DC>Это не та проблема которую мне надо решать. Мне нужно именно синхронизировать несколько серверов. На самом деле для этого существуют системы распределенной блокировки DLM. Вот в этом направлении и будем двигаться.
Я и прошу, рассказать по подробнее про блокровки которые вам нужны. Что и зачем.
Вообще есть ощущение что присуствует сильное переусложнение, тот же memcached например для чего понадобился?
Народная мудрось
всем все никому ничего(с).
Re[4]: Синхронизация серверов через кеш/базу/или еще что-то?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, DaDa Cloun, Вы писали:
DC>>А можно чуточку подробней, а то я не понял терминологии и идеи в целом? S>Да никакой магии, просто настроить load balancing, чтобы запросы от одного клиента шли к одному и тому же серверу. Если, конечно, у вас это возможно.
Sticked session кажется так это называется. Плохой вариант.
Re[5]: Синхронизация серверов через кеш/базу/или еще что-то?
Здравствуйте, Tom, Вы писали:
DC>>Это не та проблема которую мне надо решать. Мне нужно именно синхронизировать несколько серверов. На самом деле для этого существуют системы распределенной блокировки DLM. Вот в этом направлении и будем двигаться. Tom>Я и прошу, рассказать по подробнее про блокровки которые вам нужны. Что и зачем. Tom>Вообще есть ощущение что присуствует сильное переусложнение, тот же memcached например для чего понадобился?
Для кеширования.
Нужно разграничить доступ серверов к распределенным ресурсам, коими являются memcached и база данных.
Re[5]: Синхронизация серверов через кеш/базу/или еще что-то?
DC>Для кеширования.
Для кеширования чего?
DC>Нужно разграничить доступ серверов к распределенным ресурсам, коими являются memcached и база данных.
Можно по подробнее для чего именно нужны блокировки. Тоесть какую проблемы вы решаете блокировками?
Народная мудрось
всем все никому ничего(с).
Re[6]: Синхронизация серверов через кеш/базу/или еще что-то?
Здравствуйте, Sinix, Вы писали:
S>Так вы напишите, что вас не устраивает?
Можно я напишу? У меня за плечами два проекта в продакшене, где использовался такой подход (BigIP кажется называется). В обоих случаях решение использовать такой подход принималось не мной — я всегда стою на "истинную" кластеризацию — то есть когда запросы могут "бродить" по серверам в произвольном порядке, и всё при этом будет работать.
Основная проблема BigIP — он балансирует не нагрузку на сервер, а пользователей. То есть если пользователь изначально попал на какой-нить сервак, он так на него и будет ходить. Всё плюсы и минусы вытекают отсюда. Минусы: В случае сбоя сервера сессии пользователей теряется. Эта проблема решаемая, но внесёна она именно подходом.
Неравномерное распределение нагрузки по нодам. Если на один сервак попадут десять юзеров с "тяжёлыми" запросами, то они так и будут последовательно укладывать сервак на лопатки, несмотря на то, что стопицот нодов рядом вообще не нагружены. Нормальное решение проблемы мне неизвестно.
Плюс только один — приложение (почти) не нужно специально проектировать для работы в такой среде, ибо с точки зрения приложения оно как бы работает одно (то есть можно на всю катушку юзать сессионные переменные и спокойнто там хранить весь стейт). Однако всё же надо будет учитывать, что будет работать несколько экземпляров параллельно (например, очень аккуратно использовать кэши, иначе возникнет проблема поддержания их когерентности, учитывать возможные "помехи" при доступе к внешним ресурсам и т.п.)
Здравствуйте, koandrew, Вы писали:
K>Можно я напишу? У меня за плечами два проекта в продакшене, где использовался такой подход (BigIP кажется называется). В обоих случаях решение использовать такой подход принималось не мной — я всегда стою на "истинную" кластеризацию — то есть когда запросы могут "бродить" по серверам в произвольном порядке, и всё при этом будет работать.
Такие системы дороже в использовании чем sticky sessions, иногда существенно. Засчет того, что sticky sessions обеспечивают попадание пользователя на один и тот же сервер, кеши этого сервера более "горячие" для него. Поэтому процент попаданий в кеш выше и совокупный throughput выше.
K>Основная проблема BigIP — он балансирует не нагрузку на сервер, а пользователей. То есть если пользователь изначально попал на какой-нить сервак, он так на него и будет ходить. Всё плюсы и минусы вытекают отсюда.
BigIP это отдельный продукт. У него могут быть свои тараканы Ж)
K>Минусы: K> В случае сбоя сервера сессии пользователей теряется. Эта проблема решаемая, но внесёна она именно подходом.
А разве без кластеризации при падении сервера сессия не теряется?
Это отдельна проблема, и будет ли ее решать ваша софт управляющий кластером или нет, это отдельный вопрос. Возможно сделать, чтобы веб сервер просил балансер перевести пользователя на другой нод. Тут никакой особой проблемы нет.
Для ее решения существует 100+ продуктов и способов для ее решения. Coherence*Web, Terracotta, GemFire, многие Enterprise версии контейнеров идут с репликацией сессий. Выбирай — нехочу.
K> Неравномерное распределение нагрузки по нодам. Если на один сервак попадут десять юзеров с "тяжёлыми" запросами, то они так и будут последовательно укладывать сервак на лопатки, несмотря на то, что стопицот нодов рядом вообще не нагружены. Нормальное решение проблемы мне неизвестно.
Ставите на узел пробу, к-ая отсылает балансеру сообщения о загруженности узла. Балансер пересчитывает веса и мигрирует пользователей. Или ручками это делаете, меняя имя узла, на который в следующий раз пойдет запрос. В общем случае, балансер может просто считать среднее время выполнения запроса.
Здравствуйте, Gurney, Вы писали:
G>Такие системы дороже в использовании чем sticky sessions, иногда существенно. Засчет того, что sticky sessions обеспечивают попадание пользователя на один и тот же сервер, кеши этого сервера более "горячие" для него. Поэтому процент попаданий в кеш выше и совокупный throughput выше.
Cache hit rate очень существенно зависит от характера самого приложения. Если состояние приложения преимущественно "пользовательское" — то тут да, вы правы, но у нас состояние было больше общее — то есть показывались общие данные всех пользователей с учётом их изменений другими пользователями в реальном времени. Потому когерентность кэша была большой проблемой, потому мы отказались от кэширования таких данных вообще и переложили эту задачу на кластер MS SQL Server'а (который кстати очень неплохо с этим справлялся) + сделали корректную обработку If-Modified-Since, чтобы по максимуму заюзать клиентское кэширование. Пробовали ставить реверс-прокси, но особенно делу это не помогло — в итоге убрали и его.
По поводу цены разработки — тут вы ИМХО неправы. Если учитывать такое требование при проектировании/разработке приложения и свести сессионное состояние к минимуму (в идеале — вообще от него избавиться), то "на круг" получается не так уж и дорого. Да, важный момент — при разработке девелоперская среда должна быть "уменьшенной копией продакшена" — то есть представлять из себя кластер — тогда будет выловлено больше багов, связанных с "перепрыгиванием" пользователей с сервака на сервак, и потому проектных рисков в целом будет меньше.
G>BigIP это отдельный продукт. У него могут быть свои тараканы Ж)
Ну мне кажется, что проблемы, с которым мы столкнулись, довольно типичны для такого подхода в целом.
K>>Минусы: K>> В случае сбоя сервера сессии пользователей теряется. Эта проблема решаемая, но внесёна она именно подходом. G>А разве без кластеризации при падении сервера сессия не теряется?
Нет, потому что сессия хранится отдельно (у нас скажем она хранилась на кластере БД), запрос просто перебрасывается на другую ноду. Так же обеспечивается невосприимчивость приложения в целом к введению в строй/выведению из строя отдельных нодов, что кардинально упрощает обслуживание системы (обновления ОС, замена железа и т.п.) и делает возможным обновление приложения "на ходу" без остановки путём постепенного вывода нодов из кластера, обновления и ввода их обратно в строй.
G>Это отдельна проблема, и будет ли ее решать ваша софт управляющий кластером или нет, это отдельный вопрос. Возможно сделать, чтобы веб сервер просил балансер перевести пользователя на другой нод. Тут никакой особой проблемы нет.
Тут важно, чтобы приложение поддерживало такой подход. Продукты тут ни при чём. G>Для ее решения существует 100+ продуктов и способов для ее решения. Coherence*Web, Terracotta, GemFire, многие Enterprise версии контейнеров идут с репликацией сессий. Выбирай — нехочу.
K>> Неравномерное распределение нагрузки по нодам. Если на один сервак попадут десять юзеров с "тяжёлыми" запросами, то они так и будут последовательно укладывать сервак на лопатки, несмотря на то, что стопицот нодов рядом вообще не нагружены. Нормальное решение проблемы мне неизвестно.
G>Ставите на узел пробу, к-ая отсылает балансеру сообщения о загруженности узла. Балансер пересчитывает веса и мигрирует пользователей. Или ручками это делаете, меняя имя узла, на который в следующий раз пойдет запрос. В общем случае, балансер может просто считать среднее время выполнения запроса.
Дык там и так есть пробы, но чтобы приложение могло безболезненно мигрировать с ноды на ноду, нужно, чтобы оно такой сценарий поддерживало (например, хранило сессию в каком-то внешнем хранилище).
Забавно, что АФАИК тот же BigIP умеет делать "честную" балансировку нагрузки в реальном времени, но почему-то эта фича не так часто используется. Да, кстати одно из приложений, в которых я учавствовал, в конце концов переделали на "серверонезависимую" работу, так что я вполне представляю объём работ по переделке приложения.
