LINUX.ORG.RU

Передача данных между серверами

 , ,


0

1

Добрый день.

Есть сервер «А», занимающийся раздачей сервисов. Сервер пишет данные в табличку со статистикой по факту использования услуг. Таких серверов может быть много.

Есть веб-сервер «Ы», который занимается подключением услуг клиенту, отображением данных и т.д. Дело в том, что сервер А иногда должен спрашивать у Ы информацию по тарифам и услугам (чтобы на месте их тарифицировать), а с веб-морды сервера Ы клиент должен иметь доступ к данным статистики сервера А. Биллинг и статистика в mysql.

Вся информация (кроме файлов, которые будут улетать либо через sshfs, либо ftp) представлена в табличном виде, хранится в мускуле. Меня терзает вопрос: как бы грамотно организовать передачу данных между веб-мордой и серверами, фактически оказывающими услуги? Можно разрешить мускулам А-Ы ремот-логины, чтобы они забирали данные по требованию друг у друга, но это как-то некрасиво. Можно на А-серверы поставить апач (который там вообще-то не нужен) и отдавать запрошенные данные через http-ответы json'ами.

При авторизации на сервере Ы можно выдавать юзер-js токен, с которым будет позволено обращаться к серверу А, и они сами будут забирать данные. Но тут тоже некрасиво получается: если клиент оборзеет, то я не смогу его контролировать (для контроля придется снова обмениваться данными А<->Ы).

Централизованный MySQL поставить нельзя по ТЗ.

Можно на А-серверы поставить апач (который там вообще-то не нужен) и отдавать запрошенные данные через http-ответы json'ами.

Встрой вебсервер в скрипт который будет отдавать данные в json, например.

kernel ★★☆
()
Ответ на: комментарий от kernel

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

К примеру, как с этим могут обстоять дела у гугла? У них же тьма разных взаимо-интегрированных сервисов, которые вполне вероятно находятся на разном железе в разных местах, но функционируют для конечного юзера как одно app.

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

Или какая-то такая тема:

  • собираем query на веб-морде (Ы)
  • генерим request_id
  • запихиваем все это серверу А (либо если не хочется обязывать сервер А отдавать ответ сразу, то можно положить запрос серверу А в redis в виде request_id:sql; либо оставить храниться запрос на веб-морде, а серверу-А пробовать передать request_id, по которому он сам заберет запрос(ы))
  • клиенту в js передаем этот же request_id, отдаем страницу
  • сервер-А, в течение n секунд пытается обработать request_id, полученный от юзера, если все хорошо, отдаем json

Вроде бы как какой вариант не придумай - все просто и понятно. Но потом каким-то образом при первом глюке код обрастает тучей switch/case.

В данном случае клиент может задолбать сервер-А перебором request_id, если request_id - просто инкремент-поле, то сделать это будет как два пальца. Так можно выудить чужие данные. Даже если мы будем генерить рандомный request_id - вероятность сохраняется. Если мы будем сразу убивать ответ для спасения данных юзера, то будем мучать машину обработкой повторных запросов. Можно сделать отдельное хранилище для пары query:result и отдельное для ответов, которые будут одноразовые. Но уже вагон и малая тележка дополнений. А мне ведь *просто* хотелось забрать данные...

P.S. Возможно, это топик а ля «мысли вслух» и место ему в каком-нибудь блоге, а не на лоре..

division_hell
() автор топика
Ответ на: комментарий от division_hell

К примеру, как с этим могут обстоять дела у гугла? У них же тьма разных взаимо-интегрированных сервисов ....

Ну гугл это огромная масса самописного софта. При таких ресурсах выпилить мелкие вебсервера/сервера приложений под каждый используемый язык вроде питона, или даже пускать все в какой урезаной верcии собственного аппэнжина - не проблема.


Возможно, это топик а ля «мысли вслух» и место ему в каком-нибудь блоге, а не на лоре..

На самом деле с вашей задачей на ЛОР лучше в девелопмент. И посмотрите на самом деле какой нибуть MQ еще, zeromq там и тп. Они конечно в основном клиент-серверные, но задача ваша походит на то что там иногда бывает.

kernel ★★☆
()

Можно разрешить мускулам А-Ы ремот-логины, чтобы они забирали данные по требованию друг у друга, но это как-то некрасиво.

Вся информация (кроме файлов, которые будут улетать либо через sshfs, либо ftp)

хорошая шутка про MySQL :) почитай что ли про iptables.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

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

По теме - очередь тебя спасет

boombick ★★★★★
()
Ответ на: комментарий от xpahos

Ясно. Я просто имел в виду не совсем это: если я где-то использовал такую фичу, то максимум в одном влане.

С одним перцем писали как-то онлайн-гамезу (может еще кто-то помнит MUD?:)) Хостинга у меня своего не было, да дело было давно, каналы не то чтобы крутые, и мускульный коннект время от времени подвисал. Т.е. сессия не разрывалась «официально», а природу глюка того я не установил. И эта школьная травма оставила во мне предощущение, что нехорошо так делать. Вот я и не делаю :)

И вероятно один сервак будет в Питере впоследствии. Да и хостера придется поменять, потому что пока сайт на чужой vhost'e, а там iptables они трогать не будут.

division_hell
() автор топика
Ответ на: комментарий от boombick

ага, там в GRANT можно указать, но лучше iptables, чтобы исключить возможность использовать ремоут эксплойты.

xpahos ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.