Именно такой вариант и запланирован в будущем. А GAE насколько сильно тормозит с откликом — у них ведь тоже распределённая система, насколько я понимаю?
Расскажите подробности — наверняка не мне одному будет интересно. LA я приводил для сервера, который обслуживает 2 админки, а не нод.
То, что спокойно можно построить сервер, который справится с 100к визитов в сутки я и нигде не оспаривал — нам по условию задачи требовался распределённый сервер. А то мало ли что :)
Упс, да, на порядок ошибся. Нет, объединяем, но не всё. Даже индусы делают скрытые пустые циклы в коде, которые корни квадратные считают. Надо же оставить себе что-нибудь для допиливания ;-)
Если серьёзно — то та часть, которая не меняется — очень хорошо кэшируется браузером. Ну а та, что меняется — не объединяется по определению. :)
Чего-то мне не верится, что в бородатые 2000-е на одном выделенном сервере можно было раздавать контент со скоростью 3 Гигабита в секунду. Да и сейчас мне это представляется хоть и возможным, но несколько ненадёжным решением.
Ну вот клиенты уже озаботились своей AS и так далее. Так что со временем мы планируем эволюционировать — мне это интересно хотя бы потому, что тут просто практически нет клиентов, которые понимают важность развития и планирования роста. :)
Мой ответ по сути не меняется — если требовать географического раскидывания узлов сервера и НЕ иметь при этом высокоскоростной инфраструктуры, которая это всё объединяет — то тогда я не представляю себе, как решить подобную задачу.
Если же речь не идёт о том, чтобы раскидывать сервера и всё находится в одной стойке у одного провайдера — то тогда мы приближаемся к задаче построить свой фейсбук с блэкджеком и далее по тексту :) А его архитектура уже описана, насколько я знаю.
Кстати, именно объяснить заказчику, что не имеет смысла требовать от нас «нажал — и тут же появилось» — было одной из самых сложных задач в этом проекте. Пока не придумали простую аналогию — это НЕ прямой эфир. А для прямого эфира (для тех же яблодевайсов я описывал наше решение тут).
1. Средняя страница состоит из 100-120 элементов, 29 ноября, к примеру, суммарно было около 600к pageviews. Т.е. около 6М запросов к серверам в этот день.
2. Не знаю, никогда не проверяли, изначально была выбрана такая архитектура.
3. Синхронизация стартует раз в 5 минут, среднее время до появления новости 2.5 минуты при нормальной связи и несколько больше при перебоях (это непрогнозируемо).
4. Возникали, но редко и в основном это происходит, когда колбасит связь между серверами. Имено потому, что мы делаем синхронизацию в 2 прохода (сначала видео и картинки. потом текст) — это возникает очень редко на практике, так как ноды синхронизируются в параллели — то может быть ситуация, когда одна нода полностью синхронизирована, посетитель попадает на нее, но видео браузер решает подгрузить с другой ноды.
По поводу кода самой синхронизации — там вообще нет ничего интересного, вот, например, кусок, который синхронизирует текст:
#syncing text
for mirror in $MIRRORS
do
STAT_STRING="${STAT_STRING} `date +%s`,"
for datadir in $DIRLIST2
do
echo -n $SYNCDIR$datadir;
echo -n "->";
echo -n $mirror$datadir;
echo;
/usr/bin/rsync -avlrpz --delete --copy-links --force --timeout=120 --exclude-from=./excludes.rsync $SYNCDIR$datadir $mirror$datadir
done
STAT_STRING="${STAT_STRING} `date +%s`,"
done
Для видео то же самое, только можно сэкономить процессорное время. если отключить сжатие — так как его смысла жать не имеет вообще.
Это >2.0, насколько я понимаю значение, которое munin-овский модуль отдаёт. Т.е. в среднем, доступ к телу диска мечтали получить 2 процесса. Там обычные SATA винты и софтварное зеркало.
:) Ну тут ещё и требовалось сделать сервера географически распределёнными. По поводу гигабитной сетевухи — в нашем случае, её недостаточно, во время выборов только видео тянулось на общей скорости примерно 3 гигабита в секунду. Нельзя впихнуть невпихуемое :)
Ну и я не претендую на то, что у нас получился «решатель всего» — под каждую задачу — своё решение.
Почему много? Де-факто их 1+N, где N — количество нод, которые мы хотим задействовать и 1 — это сервер админки. Остальное — это резерв на случай «бадабум». 2 DNS сервера всё равно учасвуют в любой схеме — просто в данном случае их предоставлял не провайдер (регистрант) а мы сами, так как нам требуется полный контроль над DNS.
Мне как раз ваш вариант кажется сложнее в плане поддержки логической целостности. Содержимое текстовой версии портала — более 200 тыс файлов статики. Разруливать что и где обновилось децентрализованно мне кажется много сложнее, чем на главном сервере генерировать мастер-копию сайта.
Резервирование канала сделано просто — приоритеты у ssh и http протоколов разные и исходящий траффик ограничен 90% пропускной сопсобности сервера на уровне iptables (используем arno iptables firewall).
Я не знаю примеров динамических сайтов, которые были бы географически разбросаны по миру и при этом не использовали бы собственной инфраструктуры для связи серверов. По условию задачи каналы между серверами могут вообще отсутствовать некоторое время.
Если бы всё было изначально в одной стойке — то тогда проблем нет — ставим кучу проксирующих nginx-ов и никаких проблем :)
У добавленной страницы поле generation_id будет больше значения генератора на момент последней синхронизации. Соответственно, при следующей синхронизации, она попадёт в список страниц, которые требуется (пере)создать на диске. Точно то же самое происходит со страницами, которые обновляются каскадно — значение генератора же всегда растёт вверх.
Конечно же задача была решена — решение используется до сих пор (хотя мы его постоянно дорабатываем в плане оптимизации).
Со счётчиками в реальном времени дело обстоит хуже. Любой вменяемый клиент понимает, что любые счётчики в реальном времени (даже те, которые показывают на Евровидении) — профанация и шоу (знаю на личном опыте). Тут пришлось бы оговаривать, что мы понимаем под реальным временем.
Навскидку я бы предложил использовать выделенный сервер только для счётчиков, которые бы хранились целиком в оперативке (что-нибудь из Memcached/Redis вполне бы подошло). В случае аврала — отключаем счётчики, меняя конфиг в JS-файле и просто не обращаемся к серверу.
Ну а невменяемому клиенту пришлось бы объяснять, что потребуется создать орбитальную группировку спутникв с мыслесканерами — но так как это дорого, то даже Пентагон этого себе позволить не может :)
Да, так как де-факто народ привык к локальному быстрому анлиму. У нас только-только начинает стираться разница между «внешкой» и «локалкой» — приведённые выше цифры по траффику касаются только «внешки» — т.е. траффика у Netdirekt/Hetzner. Локальный траффик никто не считает, но не думаю, что там будет меньше 20Тб в месяц.
Простое кэширование поверх логики не подходит — связь между узлами по условиям поставленной задачи может быть нестабильной или вовсе отсутствовать. Ничего хитрого в логике не вижу — как раз наоборот, триггеры мне кажутся как раз самым простым решением для отслеживания изменений.
Да, в этом случае де-факто для владельца ботнет бесплатен. Мне как-то пришла в голову мысль, что если в код той же «фермы» в соцсетях внедрить код, который делает невинную вещь — переодически раз в минуту или около того — пытается скачать «как бы рисунок» с сайта жертвы — это же какой ботнет получается?
Я немного неточно выразился — защита не должна быть дороже стоимости атаки для _атакуемого_, т.е. финансовые потери из-за атаки не должны быть дороже защиты. Но что-то мне кажется подозрительно низкими цены на DDoS, приведённые ниже по треду.
То, что спокойно можно построить сервер, который справится с 100к визитов в сутки я и нигде не оспаривал — нам по условию задачи требовался распределённый сервер. А то мало ли что :)
Если серьёзно — то та часть, которая не меняется — очень хорошо кэшируется браузером. Ну а та, что меняется — не объединяется по определению. :)
Если же речь не идёт о том, чтобы раскидывать сервера и всё находится в одной стойке у одного провайдера — то тогда мы приближаемся к задаче построить свой фейсбук с блэкджеком и далее по тексту :) А его архитектура уже описана, насколько я знаю.
Кстати, именно объяснить заказчику, что не имеет смысла требовать от нас «нажал — и тут же появилось» — было одной из самых сложных задач в этом проекте. Пока не придумали простую аналогию — это НЕ прямой эфир. А для прямого эфира (для тех же яблодевайсов я описывал наше решение тут).
2. Не знаю, никогда не проверяли, изначально была выбрана такая архитектура.
3. Синхронизация стартует раз в 5 минут, среднее время до появления новости 2.5 минуты при нормальной связи и несколько больше при перебоях (это непрогнозируемо).
4. Возникали, но редко и в основном это происходит, когда колбасит связь между серверами. Имено потому, что мы делаем синхронизацию в 2 прохода (сначала видео и картинки. потом текст) — это возникает очень редко на практике, так как ноды синхронизируются в параллели — то может быть ситуация, когда одна нода полностью синхронизирована, посетитель попадает на нее, но видео браузер решает подгрузить с другой ноды.
По поводу кода самой синхронизации — там вообще нет ничего интересного, вот, например, кусок, который синхронизирует текст:
#syncing text
for mirror in $MIRRORS
do
STAT_STRING="${STAT_STRING} `date +%s`,"
for datadir in $DIRLIST2
do
echo -n $SYNCDIR$datadir;
echo -n "->";
echo -n $mirror$datadir;
echo;
/usr/bin/rsync -avlrpz --delete --copy-links --force --timeout=120 --exclude-from=./excludes.rsync $SYNCDIR$datadir $mirror$datadir
done
STAT_STRING="${STAT_STRING} `date +%s`,"
done
Для видео то же самое, только можно сэкономить процессорное время. если отключить сжатие — так как его смысла жать не имеет вообще.
Ну и я не претендую на то, что у нас получился «решатель всего» — под каждую задачу — своё решение.
Я не знаю примеров динамических сайтов, которые были бы географически разбросаны по миру и при этом не использовали бы собственной инфраструктуры для связи серверов. По условию задачи каналы между серверами могут вообще отсутствовать некоторое время.
Если бы всё было изначально в одной стойке — то тогда проблем нет — ставим кучу проксирующих nginx-ов и никаких проблем :)
Со счётчиками в реальном времени дело обстоит хуже. Любой вменяемый клиент понимает, что любые счётчики в реальном времени (даже те, которые показывают на Евровидении) — профанация и шоу (знаю на личном опыте). Тут пришлось бы оговаривать, что мы понимаем под реальным временем.
Навскидку я бы предложил использовать выделенный сервер только для счётчиков, которые бы хранились целиком в оперативке (что-нибудь из Memcached/Redis вполне бы подошло). В случае аврала — отключаем счётчики, меняя конфиг в JS-файле и просто не обращаемся к серверу.
Ну а невменяемому клиенту пришлось бы объяснять, что потребуется создать орбитальную группировку спутникв с мыслесканерами — но так как это дорого, то даже Пентагон этого себе позволить не может :)