Тех. помощь в создании зеркала либрусека

Опубликовано сб, 25/10/2008 - 13:10 пользователем Bill_G

Чесно говоря надпись на сайте "sorry overload" в любое время дня и ночи достала.

Один человек готов предоставить под зеркало VPS,
50 Гб объемом,100 мбит канал,

прошу администрацию или близких к ней написать в ЛС - дам контакты

Комментарии

Опубликовано пн, 27/10/2008 - 02:25 пользователем Bill_G

ау! либрусек это пустыня??

Опубликовано пн, 27/10/2008 - 02:31 пользователем OXOTHuK

может стоит написать в личку администрации? а так то что тут напишешь....

Опубликовано пн, 27/10/2008 - 02:45 пользователем Bullfear

Ларин щас путешествует по эквадору. Без него сами понимаете... Приедет, напишите ему. А пока есть движок и база - при желании можно поднять зеркало.
З.Ы. А контакты можно отправить на почту библиотекарей.

Опубликовано вт, 28/10/2008 - 08:35 пользователем bookwarrior

реально сделать Web-версию сайта, чтобы каждый, кому хочется, мог сделать копию либрусека у себя на компе и выставить его в доступ? А список таких зеркал публиковать где-нибудь на главной странице или вообще сделать механизм автоматического форвардинга на наименее загруженные зеркала. Концепция похожая на реализацию http://gen.lib.rus.ec/ - сайт можно в том же виде держать у себя дома. Единственное, синхронизация коллекции пока не прорабатывалась в деталях.

Тогда либрусеков будет сколько хочешь, учитывая наплыв пользователей на сайт, в особенности тех, которые скачивают всё подряд. Плюс разгрузка ответственности, выживаемость и т.п. Пню понятно, что централизованный подход выгоден исключительно на уровне координации (головная база данных должна быть одна). Во всех остальных случаях лучше иметь децентрализованные решения.

bw

Аватар пользователя Mylnicoff

Опубликовано вт, 28/10/2008 - 08:42 пользователем Mylnicoff

bookwarrior написал:
А список таких зеркал публиковать где-нибудь на главной странице или вообще сделать механизм автоматического форвардинга на наименее загруженные зеркала.

Нужен второй вариант. Иначе при невозможности доступа на Либрусек не будет доступа и к списку зеркал.

Опубликовано вт, 28/10/2008 - 11:58 пользователем computers

Для списка - легко. Форумы, почтовые рассылки... Для форвардинга, что наиболее удобно с точки зрения рассредоточения и живучести, нужен, видимо, отдельный сервер, узкоспециализированный. Чем-то система напоминает торрент ;), только нужна поддержка не только скачивания. Не знаю, есть ли аналоги?
ИМХО, вообще, если вынести все лишнее с Либрусека на другой ресурс (чат, форум, ЖЖ и проч.) - не отпадет ли проблема перегрузок? Ну, не может быть, чтобы сервер ложился от 300 посетителей! Специалисты, проконсультируйте, в чем тут дело? Ведь тормозит не скачивание, не канал - только база, т.е. сам сервер. На скачивание ни разу тормозов не видел, а вот на упаковку или на поиск - все время. Конечно, куда лучше было бы, если бы не сообщение о перегрузке выдавать, а ставить запрос в очередь на отсроченную обработку. Ну, кто работает с базами? Помогите Ларину и нам всем найти выход!

Опубликовано вт, 28/10/2008 - 14:40 пользователем fwrz.etc

Для начала, хорошо-бы, создать static.lib.rus.ec с книгами, на отдельном сервере. Используя только "static html"(генерировать скриптом, периодически).
А для "фич" использовать javascript и ajax.
Небудет всех "фич", но такой сервер выдержит, с честью, даже нагрузку на всю ширину канала.
А потом, если понравится, писать что-то вроде StillLife Витуса Вагнера.

Опубликовано вт, 28/10/2008 - 15:49 пользователем bookwarrior

computers написал:
Для списка - легко. Форумы, почтовые рассылки... Для форвардинга, что наиболее удобно с точки зрения рассредоточения и живучести, нужен, видимо, отдельный сервер, узкоспециализированный. Чем-то система напоминает торрент ;), только нужна поддержка не только скачивания. Не знаю, есть ли аналоги?
ИМХО, вообще, если вынести все лишнее с Либрусека на другой ресурс (чат, форум, ЖЖ и проч.) - не отпадет ли проблема перегрузок? Ну, не может быть, чтобы сервер ложился от 300 посетителей! Специалисты, проконсультируйте, в чем тут дело? Ведь тормозит не скачивание, не канал - только база, т.е. сам сервер. На скачивание ни разу тормозов не видел, а вот на упаковку или на поиск - все время. Конечно, куда лучше было бы, если бы не сообщение о перегрузке выдавать, а ставить запрос в очередь на отсроченную обработку. Ну, кто работает с базами? Помогите Ларину и нам всем найти выход!

для того, чтобы выбрать конкретную схему расчленения либрусека нужно, чтобы ларин замерил сколько процессора ужирается форумом (это обязано быть дохера, с мускула берётся каждая строчка на форуме, каждый раз новый запрос), сколько камня жрут какие-то другие отделяемые части сайта. При наличии карты распределения нагрузки станет понятна схема разделения.

По идее форум и скачивание книг абсолютно ортогональны друг другу и разнести их на разные сервера особых сложностей представлять не должно.

Ещё меня вот какой вопрос волнует: кэшируются ли как-то страницы (читай "запросы к базе данных") или для каждого юзера каждая страница, включая главную, собирается за ново из данных базы? Мне кажется сам сайт может сам контент кэшировать, обновляя кэш только при вносимых изменениях. Тогда для каждого юзера страницы будут не собираться, а только высылаться.

Опубликовано ср, 29/10/2008 - 15:19 пользователем jno

Кешируются - иногда 502 ошибку ловлю от ngeix'а (вроде как).

Опубликовано ср, 29/10/2008 - 15:18 пользователем jno

Называется "лоад балансер".
Самый тупой, на сколько мне известно, делается из "раунд робин ДНС" - поднимаем свой ДНС (или конфигурим имеющийся) так, чтобы на запрос lib.rus.ec отдавались разные IP.
Это хорошо, конечно, когда у зеркал свои постоянные IP.
Если нет - хуже, но можно попробовать отдавать CNAME'ы...
Вот.

Опубликовано ср, 29/10/2008 - 19:26 пользователем bookwarrior

условия, как я понимаю, как раз такие, что стандартное решение не прицепишь, а именно: IP может быть произвольным и зеркало может исчезнуть в любой момент. Главный сервер можно заставить вести подписку зеркал следующим образом:

1) чел, у которого копия сайта (скажем исключительно download-часть) заходит на lib.rus.ec/mirrors/subscribe?now, чем его IP вносится в живой список зеркал и участвует далее в механизме распределения нагрузки.
2) либрусек с того момента начинает пинговать сервер раз в минуту и выносит его IP из списка, если сервер не пронинговался 3 раза подряд с таймаутом в 10 секунд.
3) выбор зеркала делать на основе отчёта ps (unix) и данных о ширине канала (тут некоторый задел для творчества): загрузка . Где зеркала на виндах, либо разгрузку делать по рандому, либо придумать простой критерий выбора. Либо вообще всегда выбирать по рандому, но в данной задаче это может оказаться неэффективным, но для запуска пойдёт. Впрочем, всё зависит от того, какие каналы, какие вычислительные мощности, какие ОС будут у зеркал и сколько их будет. Возможно рандом окажется более оправданной концепцией и более простой в реализации.

Вот всё, что нужно. Демиургам сайта нужно лишь определить, какие части кода сайта жрут больше 1) трафика 2) камня, а затем определить, что из этого можно разделить без массивного кодирования.

Для начала хотя бы обрисуйте цифры, какие части сайта сколько каких ресурсов жрут, чтобы все видели и думали предметно, нежели абстрактно.

Действительно похоже на P2P, однако это скорее ad-hoc симбиоз централизованного Web-подхода и P2P распределения. Для юзера всё прозрачно, для исполнителей (повелителей зеркал) элементарно, для либрусека - самомасштабируемая подмога за цену минимальных пальцодвижений. Живучесть великолепная, масштабируемость замечательная. Единственное, уход серверов в любой момент конечно даст о себе знать, но хуже, чем сейчас, будет вряд ли.

Списки зеркал, кстати, всё-равно хорошо бы иметь в явном виде, чтобы FlashGet-ом, например, выкачивать со всех зеркал одновременно - там можно задавать список зеркал.

Беда с мускулом в такой схеме не решается кстати. Предложенное очевидно помогло бы разгрузить проблемы трафика, которые пока остро не стоят. Из реализуемого для мускула наверное только разделение форумов на корню - разные машины, разные базы данных - всё отдельно. Но опять же: нужны конкретные цифры по загрузке ЦПУ, - всё станет очевидно.

bw

Опубликовано чт, 30/10/2008 - 03:07 пользователем jno

Ну, тут ещё можно посмотреть в сторону технологий а ля DynDNS - зеркало регистрирует свой текущий IP на центральном ресурсе, который обновляет балансер на своём round-robin DNS.
rrDNS, в свою очередь, отдаёт на запрос, скажем, download.lib.rus.ec, сразу пачку А-записей.
При этом эту пачку он каждый раз тасует (да хотя бы и просто круговым сдвигом), чтобы тупые клиенты ломились в "следующее" зеркало, а умные - могли сами обнюхать весь список.
При этом само зеркало может (мы же туда по HTTP попрёмся, так?) при перегрузке вместо запрошенного файла отдать Location-редирект на, скажем, "следующее" зеркало. При кольцевой организации списка зеркал вероятность бесконечного залупления редиректов будет невелика.

Только для этого свой DNS нужен...
Правда, небольшой и специализированный.
Можно и самопал слепить.

Впрочем гугель даёт довольно много релевантных ответов, типа этого и вот этого.

Опубликовано вт, 28/10/2008 - 11:59 пользователем Bullfear

Цитата:
реально сделать Web-версию сайта, чтобы каждый, кому хочется, мог сделать копию либрусека у себя на компе и выставить его в доступ?

Да реально, реально... Сколько уж можно об этом рассуждать? Движок есть, бд есть, апдейты ежедневные тоже есть, даже хостер и тот есть. Осталось найти знания веб програмирования и можно хоть сегодня поднимать :) Только вот знаний то нету...

Опубликовано вт, 28/10/2008 - 14:31 пользователем Stager

Ну у меня есть знания. Но чёта я не въехал в проблему? Что программировать-то надо?

Опубликовано вт, 28/10/2008 - 15:14 пользователем Bullfear

Да хз... Есть сервер. Че на нем вообще делать надо, чтобы зеркало заработало? Че на нем сделать надо, чтобы сервер автоматом синхронизировал бд? Ну и т.д... Проще говоря: как правильно прикрутить движок к "пустому" серверу :)

Опубликовано вт, 28/10/2008 - 16:05 пользователем bookwarrior

синхронизация баз описана лариным в ветке allbooks.

движок вообще-то не нужно уж сильно прикручивать. Зеркала могут нести и пассивную функцию, не нужно создавать 10 сайтов, каждый из которых пытается рулить всё. Пусть рулит один, а остальные синхронизируются кэшированно, т.е. с некоторой задержкой. Тут всё-равно нужен анализ того, что работает синхронно (т.е. отправили мессагу - появилась по прибытии), а что асинхронно (т.е. отправляется сейчас, а во все клоны базы попадает раз в день, в 03:00). Эти две части определят, чему нужна мгновенная реакция, а что можно обновлять оптом раз в неделю.

Зеркала также можно построить так, чтобы они были абсолютно пассивными, т.е. банально на них перекидывался бы трафик. Но насколько я помню, ларин жаловался именно на перегруз мускула - для этого был куплен новый сервер. Т.е. анализировать надо, что нагружает мускул и как это минимизировать и разделять. Схема деления на сервер форума и download-сервер при такой задаче вряд ли сильно поможет: мускул-то всё-равно останется на одной машине и будет всю её нагружать безраздельно.

Опубликовано чт, 30/10/2008 - 09:06 пользователем arteume

А не получится ли так, что до тех пор пока обновления дойдут до зеркал, много народу будет пастись в обновлениях. Я например, уже давно хожу именно за обновлениями?

Опубликовано вт, 28/10/2008 - 08:51 пользователем Ulenspiegel

Если только для скачивания книг - идеология P2P подходит лучше... наверное.

Опубликовано вт, 28/10/2008 - 15:14 пользователем Bill_G

http://thepiratebay.org/search/lib%20rus%20ec/0/99/0

Опубликовано вт, 28/10/2008 - 15:39 пользователем kv

Bill_G написал:
http://thepiratebay.org/search/lib%20rus%20ec/0/99/0
ну, такого у меня, например, уже накачано полно.

А вот чтоб с интерфейсом, как у корейца, да чтоб можно только обновления получить/отдать, да из нескольких источников, да все в одной базе, да... Вобчем, могу и продолжить, а впрочем, если хотя бы это скажешь где взять - уже ого-го!

Опубликовано ср, 29/10/2008 - 01:20 пользователем Ulenspiegel

Я бы вообще предложил на вспомогательных сайтах оставить интерфейс типа веб-сервиса -
туда HTTP GET ... /download&book_id=2128507&format=fb2 , оттуда - OK 200 + собственно скачивание. Выбор сервера пользователем.... Вопрос неочевидный, либо ослиная схема (центральный сервер, на котором регистрируются вспомогательные) либо схема sourceforge, с preffered-серверами и переключением ручками. Единственное обязательное условие - не должен требоваться какой-то специфичный для Либрусека тонкий клиент, ибо и с платформонезависимостью, и с версиями, и с сопровождением - намаемся по самую нехочуху.

Что касается форумов.... Изрядную нарузку, имхо, дают именно блоги - то есть персональные ЖЖ наиболее плодовитых участников. М.б. имеет смысл заводить их на отдельных серверах (пусть Гугль за нас отдувается), а на странице Либрусека публиковать только ссылку/дату последней измененной записи ? Такое технически реализуемо ?

Опубликовано ср, 29/10/2008 - 05:55 пользователем arteume

В интернете существует много различных рассылок. Может быть сделать рассылку "лист либрусека", которая приходила бы подписчикам листа. А в эту рассылку вкладывать файлы с книгами или прямые ссылки на скачивание. Тогда постоянные качатели будут иметь те же книги, не заходя сюда.

ЗЫ: Сорри если сказал глупость;) образование у меня гуманитарное;)

Опубликовано ср, 29/10/2008 - 06:51 пользователем Ulenspiegel

Вложения делать не надо, побъют-с. А вот с прямыми ссылками, да еще с аннотациями... Здравое зерно есть...
Кстати, 2All - а что, если при синхронизации данных между основным сервером и вспомогательными использовать иерархическую структуру FTN ?

Опубликовано чт, 30/10/2008 - 11:21 пользователем Ulenspiegel

"пастись в обновлениях" - имеется в виду на центральном сервере? Сервер ляжет, и все пользователи волей-неволей расползутся по зеркалам. Или Вы что-то другое имели в виду ?

Опубликовано ср, 05/11/2008 - 04:53 пользователем Branox

Готов предложить свою помощь. Волею случая по роду деятельности занимаюсь как раз разработкой высокопроизводительных систем высокой надежности. С разгрузкой и тюнингом MySQL, nginx и т.п. постоянно занимаюсь. Есть множество вариантов разгрузки системы даже без приобретения дополнительного железа.

Опубликовано ср, 05/11/2008 - 13:03 пользователем soshial

это хорошо. мы передадим ларину. спасибо
X