- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
День добрый уважаемая редакция,
Интересует вот такой вот интересный вопрос, есть Cisco 7204 которая занимается раздачей l2tp для ADSL клиентов, есть RADIUS сервер(а), а так же есть MySQL сервер(а) в котором собственно хранится база радиуса, и откуда получаем ответы в случае успешных авторизаций.
Собственно, все работает, вопросов нет, но есть интересная ситуация, в MYSQL используется Multi Master Replication, т.е базы на самом деле две, они завязаны друг на друга (оба мастера), а так же Radius достукивается к ним через балансировщик трафика (с целью распределения нагрузки).
В случае рассинхронизации баз данных приходится по штатной процедуре лочить таблицы, переливать данные и восстанавливать репликацию по бинарным логам. Все ка как-бы тоже хорошо, НО! База на сегодня весит около 6 GB!!!! Это и есть самая важная проблема и основной аспект моего вопроса.
Есть ли люди которые работают с Radius + MySQL (пусть без репликации) ну и что бы было хотя бы 2k++ пользователей.... проблема в том, что восстановление занимает около 40 минут ..... то есть пока я переливаю базу с 1го сервера на другой для восстановления репликации на рабочем залочены таблицы и частично теряются данные о сессиях и прочем.
Хотелось бы понять \ рассмотреть альтернативные методики хранения этих данных. Может кто-то использует для этого LDAP или другие какие-то вещи? Просто я теряюсь в догадках, ну а допустим у меня завтра еще +2k клиентов наступит.... база станет 12 GB и при репликации придется ждать 2 часа..... надо как-то уходить от этого, но в тот же момент ввиду отказоустойчивости не хочется переходить на один SQL сервер..... (И так уже програмистов заставили с периодической регулярностью "откачивать" часть данных в статическую базу для дальнейшего анализа)
В поисках решения в мозгу всплывала реализация некого врапера для SQL запросов, который будет например информацию о сессиях складывать в одну базу, а информацию об авторизациях держать в другой базе... что бы при рассинхронизации надо было синкать минимальный набор данных исключая сессии и логи например..... но готового решения я не нашел, а так же не нашел описания возможности работы Radius сервера например с двумя и более базами данных. Такой вариант тоже рассматриваю в общем, нестандартные подходы - уместны :D
Поделитесь информацией, как уйти от такой проблемы, или как аналогичные реализации работают к примеру у огромных ADLS провайдеров где количество клиентов шкалит за десятки тысяч.
Схема выглядит так:
Upstream -> Cisco 7204 -> (Ферма Radius) -> (Ферма MySQL)
Фермы - основаны на железном балансировщике , который бросает случайным образом запросы в 1 из радиус серверов, а тот в свою очередь бросает запрос в 1 из MYSQL серверов, ну а SQL сервера по схеме описанной выше представляют из себя одно целое. В общем ничего сложного.
С Уважением,
! База на сегодня весит около 6 GB!!!!
че, 6гб логинов и паролей ? это должно быть миллионы пользователей.
просто выкинь из оперативной базы все что не относится к логинам и паролям.
И продавай только анлим - не придется оперативный учет сессий делать вообще. Только отключение по графику.
Да я тоже думаю там лишнего много, наверное статы хранят ещё за лет 10 =)
NDB кластер поднять, не?
че, 6гб логинов и паролей ? это должно быть миллионы пользователей.
просто выкинь из оперативной базы все что не относится к логинам и паролям.
И продавай только анлим - не придется оперативный учет сессий делать вообще. Только отключение по графику.
Во первых, продавать безлимит не возможно по ряду причин, во первых это не выгодно, а во вторых с Февраля месяца планировалось Канадским законодательством ввести лимиты для всех ADSL пользователей, т.е принудительно.... Этот вариант отпадает на проч. Т.е "просто выкинуть" часть данных... нет возможности.
Romka_Kharkov добавил 23.02.2011 в 11:00
Да я тоже думаю там лишнего много, наверное статы хранят ещё за лет 10 =)
Ошибаешься, программисты "откачивают" из актуальной базы раз в неделю данные которые уже как бы не играют никакой роли и служат статистикой, т.е 6 GB это база приблизительно за 1-2 недели.. Да, там реально движение. А насчет "отключать по графику" не совсем понял, у меня во первых есть два пула, 1 статический, другой динамика, о каких графиках речь, предлагаете стоить графики по 2k++ Virtual-Template интерфейсам ?? :D У меня и так 7204 при пиковой нагрузке уже 70-80% CPU и это как бы при условии NPE-G2
Romka_Kharkov добавил 23.02.2011 в 11:02
NDB кластер поднять, не?
Честно говоря ранее сталкивался с NDB очень поверхностно, можешь пояснить какие бонусы будут получены в результате перехода на NDB , а так же если не ошибаюсь с синхронизацией там еще все сложнее.... ? И возможно ли в NDB репликации использовать систему MultiMaster, т.е что бы все MYSQL сервера участники были одновременно мастерами, и любой из них мог принять на себя входящий query и следом раздать его остальным. Так же буду весьма признателен за ссылки на толковую документацию на любом внятном языке.
Во первых, продавать безлимит не возможно по ряду причин, во первых это не выгодно, а во вторых с Февраля месяца планировалось Канадским законодательством ввести лимиты для всех ADSL пользователей, т.е принудительно.... Этот вариант отпадает на проч. Т.е "просто выкинуть" часть данных... нет возможности.
Ошибаешься, программисты "откачивают" из актуальной базы раз в неделю данные которые уже как бы не играют никакой роли и служат статистикой, т.е 6 GB это база приблизительно за 1-2 недели.. Да, там реально движение. А насчет "отключать по графику" не совсем понял, у меня во первых есть два пула, 1 статический, другой динамика, о каких графиках речь, предлагаете стоить графики по 2k++ Virtual-Template интерфейсам ?? :D У меня и так 7204 при пиковой нагрузке уже 70-80% CPU и это как бы при условии NPE-G2
График - в смысле расписания. Я имел ввиду, что при анлиме заранее известно время когда пользователя нужно выключить. А значит не нужны оперативные расчеты.
Вообще интересно, каким образом логика этого биллинга работает? Считаются ли оставшиеся лимиты на байты и время ?
А что бывает, когда пользователь в последние минуты расчетного периода докладывает деньги, доступ прекращается ?
pipelined functions в mysql нет. Сложную логику не закодировать.
Честно говоря ранее сталкивался с NDB очень поверхностно, можешь пояснить какие бонусы будут получены в результате перехода на NDB , а так же если не ошибаюсь с синхронизацией там еще все сложнее.... ? И возможно ли в NDB репликации использовать систему MultiMaster, т.е что бы все MYSQL сервера участники были одновременно мастерами, и любой из них мог принять на себя входящий query и следом раздать его остальным. Так же буду весьма признателен за ссылки на толковую документацию на любом внятном языке.
Репликация в случае с NDB вообще не нужна. Все нормально там с синхронизацией и устойчивостью. Оно специально проектировалось для отказоустойчивости. Корни NDB как раз растут из какого-то продукта для телекома.
Часто при переносе приложений на NDB возникает куча проблем, но для этой задачи NDB должно подойти. Поэтому статистику лучше выгружать в обычный mysql и там анализировать.
Ну и помимо прочего, остается вариант с mysql-proxy, который запросы на авторизацию обрабатывал бы на локальном, а аккаунтинг исполнял бы на другом сервере.
График - в смысле расписания. Я имел ввиду, что при анлиме заранее известно время когда пользователя нужно выключить. А значит не нужны оперативные расчеты.
Теперь понял.
Вообще интересно, каким образом логика этого биллинга работает? Считаются ли оставшиеся лимиты на байты и время ?
А что бывает, когда пользователь в последние минуты расчетного периода докладывает деньги, доступ прекращается ?
pipelined functions в mysql нет. Сложную логику не закодировать.
Тут не совсем так, логика несколько проще выглядит, клиент платит x$ в месяц пока таки за безлимит, но считать его мы обязаны, потому как по внутренним TOS ему не сильно позволено качать, а ввиду новых законов так и отключать еще будем при превышении лимита, то есть на сегодня (если взять текущий день) в принципе можно убрать вообще статистику .... но завтра она понадобится, да и вообще статистика это весьма мощный инструмент который помогает жить :D
Репликация в случае с NDB вообще не нужна. Все нормально там с синхронизацией и устойчивостью. Оно специально проектировалось для отказоустойчивости. Корни NDB как раз растут из какого-то продукта для телекома.
Часто при переносе приложений на NDB возникает куча проблем, но для этой задачи NDB должно подойти. Поэтому статистику лучше выгружать в обычный mysql и там анализировать.
Ну а я вот читал читал вчера ночью, сегодня, многие говорят что NDB это шлак, мол не трогайте ..... очкую я как-то (C) :))))
Ну и помимо прочего, остается вариант с mysql-proxy, который запросы на авторизацию обрабатывал бы на локальном, а аккаунтинг исполнял бы на другом сервере.
Я рассматривал вариант с прокси, но это не совсем на сколько я понимаю решает задачу, в хорошем варианте хотелось бы таблицы с авторизацией оставить в 1й базе, а всякие сессии \ логи и прочую складируемую муть складывать в другую базу.... Так как основная проблема как я писал выше это репликация, ее процесс.... а если оставить в базе пусть сотню метров с логинами\паролями то репликация будет занимать считанные минуты и вполне даже может происходить автоматически. Ну а хранение логов вообще может быть на отдельном SQL сервере который без репликации и прочего..... чисто статика....
Я рассматривал вариант с прокси, но это не совсем на сколько я понимаю решает задачу, в хорошем варианте хотелось бы таблицы с авторизацией оставить в 1й базе, а всякие сессии \ логи и прочую складируемую муть складывать в другую базу.... Так как основная проблема как я писал выше это репликация, ее процесс.... а если оставить в базе пусть сотню метров с логинами\паролями то репликация будет занимать считанные минуты и вполне даже может происходить автоматически. Ну а хранение логов вообще может быть на отдельном SQL сервере который без репликации и прочего..... чисто статика....
Ну если прокси не нравится, можно можно создать таблицы типа federated и писать аккаунтинг на удаленный сервер не меняя ничего в софте. Пожалуй, это самое простое решение.
С прокси можно соорудить еще и надежный аккаунтинг с резервными серверами.
Romka_Kharkov, ты еще забыл добавить что у вас там еще мультисессии работают. Или уже этого нету? :) NDB можно пользоваться, но там есть свои ограничения. Помоему проще аккаунтинг хранить в одной базе(ах), а данные по аунтификации во второй. И синхронизировать только аунтификационные данные с балансом (или с количеством оставшегося трафика), а не все сразу, а тем более аккаунтинг.
Romka_Kharkov, ты еще забыл добавить что у вас там еще мультисессии работают. Или уже этого нету? :) NDB можно пользоваться, но там есть свои ограничения. Помоему проще аккаунтинг хранить в одной базе(ах), а данные по аунтификации во второй. И синхронизировать только аунтификационные данные с балансом (или с количеством оставшегося трафика), а не все сразу, а тем более аккаунтинг.
Игорь привет, ML тоже есть, но не думаю что это будет проблемой, хотя.....
Так а каким путем достигается хранение в разных базах? Radius то в две разные базы писать не умеет?
Romka_Kharkov, Postgres использовать непробовали ?