так устроен жж

[avva]

Под лж-катом — красивая картинка внутренней сетки ЖЖ (как устроены все сервера и как они между собой общаются). Если что-то непонятно или интересно, можно спрашивать.

Comments

в целом интересно, но не понятно

[bobhott.livejournal.com]

Можно, пожалуйста, подробнее. Особенно интересно чем это особым отмечены Исус и Акамай.

Re: в целом интересно, но не понятно

[avva.livejournal.com]

На Иисусе нарисовано полено. Полено по-английски - лог. Иисус отвечает за логи всех обращений к веб-серверам.

Акамай - это компания, которая предоставляет быстрый, качественный и распределённый по всему миру (юзер автоматически попадает на ближайший к нему сервер) сервис доступа к файлам через веб. У нас с ними контракт, и через них юзеры получают все юзерпики. Если Вы заметили, все картинки юзерпиков сгружаются с сервера userpic.livejournal.com ; этот адрес ведёт на серверы Akamai. Когда юзер загружает новую картинку, она попадает первоначально в базу данных внутри ЖЖ; но как только её кто-то запрашивает для показа, серверы Akamai берут её у нас и загружают к себе, и после этого запросы на неё к нам больше не приходят. Это удобно (картинки составляют очень большую часть траффика ЖЖ, а выдача их наружу раньше занимала ещё и много серверных ресурсов).

Поэтому картинка Akamai - это не один сервер, а логическая абстракция этого сервиса, находящегося вне livejournal.com (обратите внимание, что юзер туда попадает через Internet, не заходя на нашу внутреннюю сетку). Если не ошибаюсь, на ней облако нарисовано, символизирующее большую распределённую сеть серверов.

[dimrub.livejournal.com]

1. Что за машина - MEMCACHE?
2. Почему часть кластеров - кластеры, а часть - одиночные машины?
3. Кто такой Jesus? (Jesus saved your life. Save? Abort? Ignore?)
4. Стрелочки даны без направлений, поэтому непонятно, например, что mail идет только наружу.

[avva.livejournal.com]

4. Майл идёт не только наружу (письма на username@livejournal.com для платных юзеров, а также с недавнего времени posting by email).

3. Jesus когда-то был самым главным DB-сервером, а сейчас он всего лишь отвечает за logging всех веб-риквестов.

2. Одиночные кластеры - те, на которых запланировано относительно мало юзеров. Один для всех RSS accounts, другой для всех inactive users (те юзеры, которые давно ничего не писали, в него автоматически переводятся. Это никак не влияет на их ЖЖ-возможности, просто так удобнее группировать данные).

1. Memcache - это не одна машина, а много машин, на которых бегут демоны memcached. На самом деле большинство из них не dedicated машины для memcached, а другие машины (обычно веб-серверы), на которых впридачу к их обычным обязанностям бегут демоны memcached (веб-серверы обычно CPU-intensive but relatively light on memory; memcached daemons are CPU-light but memory-hungry. It's a good match).

[maksimka.livejournal.com]

О. Нужно такую татуировку сделать :)))

[sheb.livejournal.com]

а уж майки-то точно можно продавать за бешеные деньги )

[karmanova.livejournal.com]

у меня много идиотских вопросов!!!
1) что такое memcache?
2) cluster?
3) Jesus?
4) Akamai?

если можно, доступным языком объясните, я лично лох!

[object.livejournal.com]

Интересно было бы узнать количественные характеристики: например, количество Web-серверов, объем памяти, процессоры и т.д.

[avva.livejournal.com]

Web-серверов сейчас 17 штук. DB-серверов - см. кластеры на картинке; каждый кластер, состоящий из одно прямоугольника - один сервер; из нескольких - два или три (раньше было три, один мастер и два слейва, но по мере всё более усиленного использования memcached нагрузка на чтение DB падает и мы переводим кластеры на схему один мастер, один слейв, а в будущем, возможно, вообще получится отказаться от MySQL-репликации, и будет всего один сервер на кластер).

NetApp - это свежекупленный storage server мощный с каким-то охренительным количеством дисков. Мы его будем использовать для хранения юзерпиков (вместо базы данных), новых аудио-записей, которые вот-вот начнут работать, и бэкапов.

Памяти у DB-серверов обычно 4Gb, у веб-серверов - 2, кажется (не уверен). У Иисуса 12Gb памяти, он монстр (когда-то он был главным DB-сервером, ещё до перехода большинства данных на кластеры, и на него была огромная нагрузка).

Процессоры - не знаю, выясню. Думаю, какие-нибудь стандартные Пентиумы.

[(Anonymous)]

Безобразие - где мой любимый "Inactive Cluster"?

[avva.livejournal.com]

По-моему, это BigBoned. Хотя я не уверен на 100%, уточню у нашей сисадминши и напишу здесь, если это не так ;)

[dinozavr.livejournal.com]

Круто. Спасибо!!!

[faeton.livejournal.com]

Akamai - мой никнейм )))

[paltus-lj.livejournal.com]

Да, вот Akamai особенно непонятен...

[avva.livejournal.com]

См. мой ответ на первый коммент выше.

Akamai - это уже третья попытка решить проблему юзерпиков, надеюсь, последняя. Проблема юзерпиков в том, что они: а) жрут очень много траффика б) их нецелесообразно выдавать наружу тем же веб-сервером, который у нас обрабатывает обычные динамические запросы (apache+mod_perl), т.к. это всё равно, что палить из пушки по воробьям, слишком много уходит памяти и CPU power. Вначале мы перенесли юзерпики на другого провайдера, на восточном побережье США, который намного меньше денег берёт за траффик; там у нас бежал лёгкий веб-сервер thttpd (который мы ещё сами немного облегчили и видоизменили), который выдавал наружу юзерпики. Но провайдер оказался паршивеньким. Потом мы заключили контракт со Speedera - это конкурент Akamai (практически единственный большой его конкурент, Akamai контролирует большинство этого рынка); это оказалось решением получше, но, во-первых, служба поддержки у Speedera оказалась весьма бестолковой, и во-вторых, Akamai стала усердно переманивать нас к себе от Speedera, обещая большие скидки по сравнению со своей обычной ценой. В конце концов мы перешли к ним, и вот сейчас юзерпики раздают серверы Akamai.

[bars.livejournal.com]

Занятно.
А картиночка руками рисовалась или это какое-то средство так штатно красиво диаграммы рисует?

[avva.livejournal.com]

Рисовал xevinx, наш штатный дизайнер. Не знаю, чем, хотя думаю, что не руками всё же ;)

[piggymouse.livejournal.com]

А чем занимается Global cluster?

[avva.livejournal.com]

Несколько упрощая, user clusters хранят данные, которые легко разбить per user. Global cluster хранит данные, которые трудно разбить per user (например, стили, интерфейс на всех языках, таблица отношений френдшипа, итп.), а также данные, к которым нужен быстрый централизованный доступ, и которые неэффективно было бы качать с per-user кластеров. К этим последним относится в первую очередь таблица user, в которой хранятся основные данные каждого юзера, включая номер его кластера (чтобы знать, какой user cluster хранит всю остальную его информацию).

[papapadlo.livejournal.com]

Спасибо за интересную инфу :)
Да, монстрик у вас еще тот.
Однако очень познавательно.
Особенно хорошо решение с Акамаи и юзерпиками.

спасибо, захватывающая картинка

[meshko.livejournal.com]

НетАпп это зверь.

Я давно хотел спросить -- почему вы не делаете как Slashdot, не было ли бы логично сделать страницы комментов статическими? Или memcached это полностью покрывает? Или они и есть статические, но это не заметно?

Re: спасибо, захватывающая картинка

[avva.livejournal.com]

Страницы комментов не могут быть статическими, т.к. разные люди видят их по-разному (некоторые вообще их не могут увидеть, если запись для них закрыта, другие видят/не видят заскриненные комменты, далее, юзер получает картинку удаления комментов только на своих комментах, а не на чужих, итд. итп.).

[limbakh.livejournal.com]

Анатолий, извините за оффтопик, но: почему с сегодняшней ночи (по MSK), в стиле Component (S2) у платных пользователей перестали работать free text?

Т.е. у пользователей счетчиков появилась надпись "Об этом ЖЖ", а весь sourse free text`a попал.

[avva.livejournal.com]

Понятия не имею, по правде говоря.

[godegisel.livejournal.com]

1. а в чем функции BigIP? forwarding и все? traffic shaping?
2. какие OS?
3. что на Secure Server? apache+mod_ssl? или hardware ssl acceleration?
4. что на Proxy Web? oops/squid/...?
5. что на Web Servers? это только backend'ы или статика там тоже?

[avva.livejournal.com]

BigIP - firewall, load balancer (его главная функция).

2. Практически везде Debian Linux, stable. Исключение - NetApp и BigIP, на которых бежит их специальный софт (что не NetApp, я не знаю, а на BigIP старая сильно модифицированная BSDi, если не ошибаюсь).

3. apache+mod_ssl. Вообще этот сервер простаивает, он практически только для платежей и используется пока что. В будущем, наверное, будет secure login итп.

4. proxy web - apache + mod_proxy + mod_rewrite . Эти машины ничего не кэшируют, они работают как reverse proxy: получают запрос, выбирают один из свободных веб-серверов (раньше этот выбор шёл через load balancing BigIP, но недавно я написал rewriter balancer, демон, который бежит на них и получает нотификации от апачей на веб-серверах насчёт их занятости. apache на proxy-web машине обращается (через mod_rewrite) к rewrite balancer'у и тот переписывает ему URL на один свободных веб-серверов), пересылают запрос ему, получают полностью ответ, и после этого отсылают юзеру. Смысл их существования в сокращении времени работы тяжёлых mod_perl-овских веб-серверов: они принимают на себя общение с end-юзером на его относительно медленной скорости. Этих машин сейчас три или четыре штуки, не помню точно.

5. apache+mod_perl. Всё дерево сайта (htdocs, перловские библиотеки итп.) они видят через NFS с одного центрального места. Статики на сайте очень мало, в основном всякие мелкие иконки (юзерпики не считаем, они особь статья). Вся эта статика есть в рабочем дереве, так что веб-серверы её видят и могут выдавать, но на практике статика напрявляется на отдельный сервер (здесь не указанный ради экономии места) на уровне BigIP.

база данных

[(Anonymous)]

Если не секрет - какая база данных используется?

Re: база данных

[avva.livejournal.com]

Не секрет, MySQL 3.x или 4.x (на сайте мы в основном используем 4.x, но на уровне исходников продолжаем поддерживать 3.x тоже).

если не секрет.

[deka.livejournal.com]

Чем делается logging на jesus?

Re: если не секрет.

[avva.livejournal.com]

MySQL. В коде, который обрабатывает каждый запрос на веб-серверах, есть callback, к-й вызывается в самом конце запроса, и он кидает информацию о запросе в базу данных на jesus. Т.к. он делает INSERT DELAYED (и т.к данные туда только пишутся, не читаются постоянно), это происходит достаточно быстро (для того, чтобы один jesus мог обрабатывать логи всех веб-серверов).

[avva.livejournal.com]

Если все компьютеры считать, не только веб-серверы?
Беря примерно 40 компьютеров, получается где-то 150 килобайт/секунду/компьютер.
Так примерно (это не самые точные данные и не самые последние).

Re: OS?

[avva.livejournal.com]

Debian Linux, да.

[chuzhoy.livejournal.com]

мнение:
если бы лет через эдак 30-40 livejournal.com продолжал существовать, было бы просто здорово читать то, что ты писал лет эдак в 18-20.
вопросы:
1. какова вероятность того, что livejournal.com внезапно закончит свое существование?

2.что может положить конец существованию livejournal.com?

3. 66.150.15.150 - это Internap на схеме?
(на случай пингов в истерике :)))))

p.s. извиняюсь за слишком сложные (наверное?) вопросы не по теме.

[avva.livejournal.com]

1. очень и очень мала.
2. Брэд внезапно умирает/сходит с ума, и никого не находится, чтобы заменить его.
Террористы взрывают здание, в котором все серверы.
Кто-то подаёт в суд на LJ непонятно по какому поводу и выигрывает дело на сумму много миллионов долларов.

Все остальные сценарии смерти LJ не быстрые а медленные, например, люди перестают покупать paid accounts, постепенно кончаются деньги итп.

3. Нет, это наш BigIP, т.е. уже наш сервер. Но он находится физически в colocation facility Internap'а.

картинка красивая,

[qub.livejournal.com]

но в Key я только с пятого раза понял чем отличается обозначение Pool of Peers от Pool of Slaves.
скажи что ли дизайнеру, если будет удобный случай.

[toxa.livejournal.com]

Акамаи все ясно, а вот по остальные машинки хотелось бы узнать про физическое размещение :) Где, сколько, фотки :)

front end

[alexpolt.livejournal.com]

извините, а вы могли бы рассказать в кратце - как организуется front end, который перенаправляет все эти потоки... Ну, к примеру, userpiс? на базе apache?

[oversider-kosma.livejournal.com]

Анатолий, а не могли бы Вы рассказать, где, на каком этапе и как часто происходит резервное копирование?

Это свершается раз в нексколько минут для всего ЖЖ? Это делается покластерно? Или, если пользователь пишет пост/коммент, то его копия сразу отправляется в бэкап?
И сколько копий делается?

Заранее спасибо!