Задача:
Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы.
Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных.
Если схемотично то выглядит так:
1) balancer смотрит на IP и редиректит на ближайший сервер
2) пользователь работает с серваком
3) система на фоне перегонят обновления на другие сервера.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Задача: __S>Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы.
__S>Но все это выглядит тупиковой веткой.
__S>Есть какие-то известные подходы?
Все ровно так и делают, никаких проблем обычно не возникает.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Задача: __S>Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы.
__S>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных.
__S>Если схемотично то выглядит так:
__S>1) balancer смотрит на IP и редиректит на ближайший сервер
Можно ещё попробовать Anycast DNS, тогда балансер не будет единой точкой сбоя (у вас же несколько датацентров, как я понимаю?)
Здравствуйте, __SPIRIT__, Вы писали:
__S>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных. __S>Есть какие-то известные подходы?
Так и делают обычно. Весь вопрос в том, как правильно нагородить синхронизацию баз данных. Ответ очень зависит от вашей бизнес задачи.
Здравствуйте, Gurney, Вы писали:
__S>>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных. __S>>Есть какие-то известные подходы? G>Так и делают обычно. Весь вопрос в том, как правильно нагородить синхронизацию баз данных. Ответ очень зависит от вашей бизнес задачи.
Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду
А если серьезно, как-то это не оптимально.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду __S>А если серьезно, как-то это не оптимально.
Представьте Фейсбук. Вася лайкает фотку китайца Чу. В этот момент Джон лайкает эту же фотку Чу.
Вопрос: Увидят ли Вася и Джон лайки друг друга?
Ответ: если и да, то далеко не сразу. А вообще 100% гарантии нет, потому что Вася лайкает копию на российском ноде, а Джон — на штатовском. Чу загрузил фотку неделю назад, поэтому репликация успела пройти по всем нодам.
Бонусный вопрос для самостоятельного разбора: Что увидит Чу?
Сходить с планеты не надо, ибо подобные проблемы испытывает в том числе и маршрутизация всего интернета. Когда где-то происходит изменение конфигурации подсети, остальной интернет узнаёт об этом не сразу, а постепенно, в процессе BGP-обмена. Причём любой BGP-маршрутизатор может держать у себя копию BGP full view, а может и не держать (но знать куда за ним сходить при случае, или просто делегировать всё, что не понял, куда-то "к терапевту").
Здравствуйте, Mr.Delphist, Вы писали:
MD>Представьте Фейсбук. Вася лайкает фотку китайца Чу. В этот момент Джон лайкает эту же фотку Чу.
MD>Вопрос: Увидят ли Вася и Джон лайки друг друга? MD>Ответ: если и да, то далеко не сразу. А вообще 100% гарантии нет, потому что Вася лайкает копию на российском ноде, а Джон — на штатовском. Чу загрузил фотку неделю назад, поэтому репликация успела пройти по всем нодам.
MD>Бонусный вопрос для самостоятельного разбора: Что увидит Чу?
Я очень сомневаюсь что мордокнига использует РСУБД и как-то ее синхронизирует. Я бы ожидал скорее увидеть шарды + кэш с других шардов. Соответственно будет лаг на обновление кэша.
MD>Сходить с планеты не надо, ибо подобные проблемы испытывает в том числе и маршрутизация всего интернета. Когда где-то происходит изменение конфигурации подсети, остальной интернет узнаёт об этом не сразу, а постепенно, в процессе BGP-обмена. Причём любой BGP-маршрутизатор может держать у себя копию BGP full view, а может и не держать (но знать куда за ним сходить при случае, или просто делегировать всё, что не понял, куда-то "к терапевту").
Это вариант кэша. А значит не полная копия и даже то что копируется к себе, делается не на всегда.
MD>Этот мир асинхронен, смиритесь
Все ок пока не появляются общие ресурсы. У нас, например практически все общее. И если одновременно(с разницей в секунду) Куй в Китае, Джон в штатах и Густав в Германии редактируют одну и туже сущность, потом ее смерджить не получится.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы.
__S>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных.
Клиенты пишут в местные копии базы, или только читают? Нельзя сделать чтение из локальных копий и запись только в центральную?
__S>Но все это выглядит тупиковой веткой.
А почему тупиковой?
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, __SPIRIT__, Вы писали:
__S>Я очень сомневаюсь что мордокнига использует РСУБД и как-то ее синхронизирует. Я бы ожидал скорее увидеть шарды + кэш с других шардов. Соответственно будет лаг на обновление кэша.
MD>>Сходить с планеты не надо, ибо подобные проблемы испытывает в том числе и маршрутизация всего интернета. Когда где-то происходит изменение конфигурации подсети, остальной интернет узнаёт об этом не сразу, а постепенно, в процессе BGP-обмена. Причём любой BGP-маршрутизатор может держать у себя копию BGP full view, а может и не держать (но знать куда за ним сходить при случае, или просто делегировать всё, что не понял, куда-то "к терапевту").
__S>Это вариант кэша. А значит не полная копия и даже то что копируется к себе, делается не на всегда.
MD>>Этот мир асинхронен, смиритесь
__S>Все ок пока не появляются общие ресурсы. У нас, например практически все общее. И если одновременно(с разницей в секунду) Куй в Китае, Джон в штатах и Густав в Германии редактируют одну и туже сущность, потом ее смерджить не получится.
[quote]
Как обычно во время полета, представители всех служб космодрома, отряда космонавтов и конструкторов, посменно дежурили, чтобы всегда была возможность организовать консультацию и принять ответственное решение. В нашей смене в тот раз был и Ю. Гагарин. Обычно в два-три часа ночи поступление информации заканчивается, космический аппарат «на той стороне» Земли. Смена, около девяти утра, делать нечего, но спать невозможно, потому что очень сильное напряжение. И начинается треп, всякие байки... Так было и в тот раз. А утром нам из Симферополя, а это первый измерительный пункт, над которым пролетал Быковский, поступает радиограмма. И в конце, после всех параметров кабины: «Имел космический стук».
Переполох страшный! Представляете, что может стучать в космосе?! Что-то оторвалось и стучит? Как звук распространяется? Непонятно. Масса разных предположений. Королева решили не будить, разбудили Каманина, командира отряда космонавтов. Примчался он к нам в радиорубку, туда уже набилась вся смена. А Быковский уже подлетает к нам и вот-вот войдет в связь на коротких волнах. Каманин Гагарину и говорит: -Давай, составляй радиограмму, и как только он войдет в связь, ты ему все открытым текстом и передашь. И диктует: -Космонавту Быковскому. Сообщите характер наблюдавшегося Вами космического стука: шипящий, стучащий, скрежещущий и прочая. Быковский подлетает и, в соответствии с регламентом, начинает с параметров кабины. Обычно связь летающего космонавта с наземным центром, была на уровне дружеской беседы, никакой официальности, по имени, все эти позывные придуманы, я не знаю для кого. А тут Гагарин перебивает Быковского и обращается «на Вы»:
-"Примите радиограмму!" В космосе повисает тишина. Гагарин начинает диктовать, что у него написано.
И вдруг раздается дикий смех: -Какой стук! Стул! Понятно?
На мгновение в радиорубке устанавливается гробовая тишина, а потом...
[/quote]
Здравствуйте, ins-omnia, Вы писали:
__S>>Есть web-приложение B2B, развернуто в штатах на наших серверах. Клиенты используют его по подписке. И есть компании, работающие по всему миру. Нужно им обеспечить быструю работу с намм из Китая, Австралии и Европы. __S>>Сейчас для этого разворачивают несколько отдельных инсталяций + нагородили огород с синхронизацией баз и данных. IO>Клиенты пишут в местные копии базы, или только читают? Нельзя сделать чтение из локальных копий и запись только в центральную?
проблемы с записью в первую очередь. Как бы я хотел все видеть, еще не сформулировал(в процессе). Если интересно могу выложить как будет готово.
__S>>Но все это выглядит тупиковой веткой. IO>А почему тупиковой?
Очень сложная конструкция. Большая вероятность ошибок из-за постоянного мержа состояний. Неустранимые проблемы с выходом ноды в офлайн. Самое неприятное, когда авария на магистрали и локальная нода доступна пользователям, а вся система нет.
Не понятно что делать с одновременным изменением одной сущности на разных нодах
Долгий апдейт, если на одну ноду загрузили 100Гигов, другие ноды получат данные очень не скоро.
Очень большой уровень дублирования. Большая часть данных дублируется бессмысленно, они просто не будут использованы. Не оптимально
Это навскидку, уверен проблем будет больше.
Здравствуйте, __SPIRIT__, Вы писали:
__S>проблемы с записью в первую очередь. Как бы я хотел все видеть, еще не сформулировал(в процессе).
Но схема уже реализована в каком-то виде, значит какой-то анализ уже был? Значит известно, что именно необходимо ускорить.
Как я понимаю, там в основном интерактивная работа юзеров с какими-то данными. При таком сценарии веб-приложение в основном читает данные из базы, и только от случая к случаю записывает. Нельзя ли читать данные из местного кеша и просто игнорировать тормоза при записи?
__S>Если интересно могу выложить как будет готово.
Интересно.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
G>>Так и делают обычно. Весь вопрос в том, как правильно нагородить синхронизацию баз данных. Ответ очень зависит от вашей бизнес задачи.
MSSQL peer-to-peer transaction replication
__S>Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду __S>А если серьезно, как-то это не оптимально.
Childish volume. I have such database at home in my basement.
Здравствуйте, Lepsik, Вы писали:
G>>>Так и делают обычно. Весь вопрос в том, как правильно нагородить синхронизацию баз данных. Ответ очень зависит от вашей бизнес задачи.
L>MSSQL peer-to-peer transaction replication
Из штатов в Австралию? Сколько будет идти транзакция? Что будет если одна нода вывалилась и через 2 дня вернулась?
__S>>Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду __S>>А если серьезно, как-то это не оптимально.
L>Childish volume. I have such database at home in my basement.
По русски разучился писать? Или писькомерство на английском идет с коэфициентом?
Ок, у тебя дома десятки терабайт порно, на серверных винтах с рэйдом, раскиданных по всему миру. Плюс запасная копия в каждой точке в соседнем датацентре.
Ок, видимо ты маньяк.
З.Ы.
В следующий раз можешь понтануться перед зеркалом, порадоваться и пройти мимо.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Есть какие-то известные подходы?
А если поглядеть на возможности Azure в этой области?
Плюс еще идея — если клиентам нет необходимости (или даже возможности) видеть данные друг друга, то развернуть независимые приложения. Т.е. как делают иногда для игровых серверов — свой независимый от других "мирок" для отдельных частей реального мира.
Здравствуйте, __SPIRIT__, Вы писали:
SPI> Все ок пока не появляются общие ресурсы. У нас, например практически все общее. И если одновременно(с разницей в секунду) Куй в Китае, Джон в штатах и Густав в Германии редактируют одну и туже сущность, потом ее смерджить не получится.
Может быть, именно в этом ваша проблема. В распределенных системах стараются делать общим кк можно меньше.
__S>Т.е. все хранят полную копию базы и все данные(в нашем случае это файлы в несколько десятков теробайт) во всех точках мира? Остановите планету я сойду __S>А если серьезно, как-то это не оптимально.
