Комментарии 73
все самое интересное на потом, эх, а так хотелось узнать о NoSQL и web-сокетах
зато умудрились выбрать кривой хостинг картинок :) не грузятся
Довольно странный подход с хранением статики на web1. Что будет если он ляжет? Да и бэкенды получаются неравнозначными (как вы, кстати, деплоите код?). Расскажите поподробнее чем не устроил подход с NFS?
Отвечу за автора.
Во-первых статику можно локально кешировать на фронтах. Во-вторых автор написал что раз в сутки она синкается на все бэкэнды. А вот тема деплоя не раскрыта. Вариантов масса, мы к примеру храним скрипты либо на фронте, либо на выделенном сервере с которого они отдаются на бэки по NFS. Нагрузка на NFS минимальная (конечно отдается оно по внутренней между серверной сетке на других физических интерфейсах)
Во-первых статику можно локально кешировать на фронтах. Во-вторых автор написал что раз в сутки она синкается на все бэкэнды. А вот тема деплоя не раскрыта. Вариантов масса, мы к примеру храним скрипты либо на фронте, либо на выделенном сервере с которого они отдаются на бэки по NFS. Нагрузка на NFS минимальная (конечно отдается оно по внутренней между серверной сетке на других физических интерфейсах)
Спасибо :)
Код проекта хранится в GIT. По нажатию на ссылку deploy в Redmine запускается скрипт, который делает «git pull» на заданных вебах.
Подобная задача так же красиво решается с помощью capistrano — это добавляет возможность делать быстрый rollback, а так же делать деплой как из командной строки разработчика, так и через Redmine плагин, если деплой делает менеджер проекта после согласования и тестирования.
Подобная задача так же красиво решается с помощью capistrano — это добавляет возможность делать быстрый rollback, а так же делать деплой как из командной строки разработчика, так и через Redmine плагин, если деплой делает менеджер проекта после согласования и тестирования.
Во-первых статику можно локально кешировать на фронтах. Во-вторых автор написал что раз в сутки она синкается на все бэкэнды.
А зачем весь этот геморрой, если можно просто хранить статику на шаре? Да и вообще, мне казалось что уже давно устоялась практика не хранить какое-либо состояние на сервере приложений (статика, кэш и т.д идет на отдельные сервера). Автор упомянул, что они пробовали использовать подобный подход, но столкнулись с проблемами NFS, вот я и хотел узнать какого рода были проблемы.
Основная проблема с NFS это ее неправильное развертывание. NFS на отдельных хардверных интерфейсах с jumbo-frames, маунты с _netdev,tcp и т.п. решают большинство их них, тюнинг NFS это отдельная тема, сложноватая даже для меня :-)
Как говорят, чем проще конфигурация, тем стабильнее работает. При работе с nginx все получилось максимально прозрачно и стабильно.
NFS можно заставить работать хорошо. Но стоит ли это того? Зависит от проекта.
NFS можно заставить работать хорошо. Но стоит ли это того? Зависит от проекта.
Да че там сложного то? nfs-kernel-server работает себе и работает. Тюнить не его надо на самом деле, а стабильность линка. Зато в некоторых случах удобство неоспоримо, ибо шарить на уровне FS под *NIX особо больше и нечем. В моем случае есть некоторое количество серверов с дисковыми полками, которые «шарят» свои тома на фронты и бэки по NFS. Любой бэк может принять файл и засунуть его куда надо (только вот не надо говорить про локи, общий доступ и т.п., это решается в приложении by design). Любой фронт может его отдать оттуда как с локального диска (а может и в кеш положить на реально локальный диск-ramdisk-etc)
если web1 ляжет после того как он уже принял файл но до того, как прошла сихнронизация, то все равно будет проблема.
Конечно будет. В случае локального кеша на фронте пользователи увидят некоторое количество популярной статики если ее кешировать. Вообще у авторов тут ошибка проектирования, это да.
Вообще тема mysql тоже не очень раскрыта. Некоторые люди (мы тоже) поисковые запросы и некоторые селекты вытаскивают на slave сервера, что помогает серьезно снижать нагрузку на основную БД.
В некоторых случаях выигрыши в десятки раз достигаются кешированием частоиспользуемых данных в memcache целиком, у нас к примеру это имена пользователей (в тех же комментариях нет смысла дергать для каждого комментария на странице новую инфу о пользователе, быстрее класть в кеш и доставать оттуда в случае повтора) — хотя это по моему уже ликбез
Вообще тема mysql тоже не очень раскрыта. Некоторые люди (мы тоже) поисковые запросы и некоторые селекты вытаскивают на slave сервера, что помогает серьезно снижать нагрузку на основную БД.
В некоторых случаях выигрыши в десятки раз достигаются кешированием частоиспользуемых данных в memcache целиком, у нас к примеру это имена пользователей (в тех же комментариях нет смысла дергать для каждого комментария на странице новую инфу о пользователе, быстрее класть в кеш и доставать оттуда в случае повтора) — хотя это по моему уже ликбез
Деплой осуществляется самописным плагином под redmine сразу на все вебы.
Грубо говоря, скрипт делает git pull на всех вебах.
Грубо говоря, скрипт делает git pull на всех вебах.
А sql-миграциями как?
Я пожалуй дополню вопрос, чтобы было понятно к чему я веду. Допустим, деплоится новая фича содержащая в себе sql-миграцию (скажем, CREATE TABLE foo...) и код который без этой миграции не будет работать (SELECT… FROM foo). Понятно что если код задеплоится раньше чем sql-миграция или наоборот, то мы получим неработающее приложение на некоторое время. Собственно, меня интересует как происходит синхронизация миграций и кода при деплое (особенно при наличии множества бэкендов, время выполнения git pull на них может быть разным).
А какую нагрузку держит Openfire и какая версия его установленна если не секрет? Openfire тащит пользователей из mysql базы?
Да из MySQL, БД openfire синхронизируется с основной базой пользователей.
Нагрузка Jabber сервер не столь существенна, запас большой, здесь как раз трудностей не возникает :)
Версия последняя — 3.7.1
Нагрузка Jabber сервер не столь существенна, запас большой, здесь как раз трудностей не возникает :)
Версия последняя — 3.7.1
Просто в последнее время Openfire 3.7.1 стал падать, похоже из-за того что возросла нагрузка(300 постоянных подключений) с пользователями как раз в БД mysql. Но у вас я как понимаю они во внутреней базе Openfire?
У Openfire своя mysql БД, в которую заливаются данные о пользователях из основной базы проекта.
По поводу падений, возможно у Вас заполнился какой-нибудь кэш в Openfire, посмотрите в админке. Давно как-то у нас была проблема, из-за того, что переполнился кэш ростера и openfire начал грузить сервер на 100% CPU.
300 постоянных подключений для openfire это, впринципе, не нагрузка, должно быть причина в другом. Наблюдайте за логами.
По поводу падений, возможно у Вас заполнился какой-нибудь кэш в Openfire, посмотрите в админке. Давно как-то у нас была проблема, из-за того, что переполнился кэш ростера и openfire начал грузить сервер на 100% CPU.
300 постоянных подключений для openfire это, впринципе, не нагрузка, должно быть причина в другом. Наблюдайте за логами.
Кэш родстеров вообще отключен, так как он вносит ощутимую задержку между тем когда пользователь добавлен в базу mysql и когда может зайти на сервер! Вообще да скорее всего упирается в 700mb памяти выделенной для java(Использовано памяти Java: 650,76 MB of 704,50 MB (92,4%) used )! Попробую поигратся с этим значением!
В данном случае, от тысяч консультантов находящихся одновременно в онлайне через определенное количество секунд приходят HTTP-запросы на предмет обновлений (новый клиент, сообщение, изменение различных статусов) это тоже потребляет огромное количество ресурсов HTTP-серверов и серверов БД.
Если не секрет, почему не websockets? Все-таки консультант это не сферическая домохозяйка в вакууме, он в состояни свой IE6 обновить?
Я бы даже спросил, почему не SignalR, который умеет автоматически выбирать наиболее эффективную схему в зависимости от установленного браузера.
Тут можно даже без включения телепатии предположить, что у авторов теплый ламповый PHP, а у SignalR — богомерзкий .NET. А вот с вебсокетами непонятно, потому как они параллельны используемой платформе. И приписка у авторов в конце — «в светлом будующем будут вебсокеты». Вот и интересно — почему не сразу?
Тут можно даже без включения телепатии предположить, что у авторов теплый ламповый PHP, а у SignalR — богомерзкий .NET.
… а вот тут возникает вопрос «нахрена», если можно сделать ощутимо легче.
С другой стороны, я не очень верю, что для PHP нет аналогичных решений с фолбэком.
связать php и node.js с socket.io дело пяти минут. Ну а там тоже шахматы и девушки из гарема (websockets,flashsockets,longpooling etc)
Для таких вещей уже давно придумали Long-polling. Зачем на этом сервисе до сих пор используется метод из Кайнозоя, забивающий бесполезным трафиком канал — не понятно.
Да и не highload это на самом деле, а неправильно спроектированный и построенный проект. У них нет постоянного потока объемных данных (фоточки, видео, голос etc.), нет масштабного хранилища, нет ничего из того, что действительно могло бы создать большие проблемы с трафиком, местом, памятью и т.д. и т.п. Тот же Round Robin — неоптимальнейшее из возможных решений, Keepalived + HAProxy дадут фору такому подходу ого-го, Memcache используется вообще деревянно как-то, не говоря уже о действительно продуманной отказоустойчивости.
И пусть меня сейчас заплюют минусами, но у меня сложилось чувство, что просто кому-то захотелось поиграть в «крутой хайлоад», но из-за недостатка знаний получилось как обычно.
Да и не highload это на самом деле, а неправильно спроектированный и построенный проект. У них нет постоянного потока объемных данных (фоточки, видео, голос etc.), нет масштабного хранилища, нет ничего из того, что действительно могло бы создать большие проблемы с трафиком, местом, памятью и т.д. и т.п. Тот же Round Robin — неоптимальнейшее из возможных решений, Keepalived + HAProxy дадут фору такому подходу ого-го, Memcache используется вообще деревянно как-то, не говоря уже о действительно продуманной отказоустойчивости.
И пусть меня сейчас заплюют минусами, но у меня сложилось чувство, что просто кому-то захотелось поиграть в «крутой хайлоад», но из-за недостатка знаний получилось как обычно.
Keepalived + HAProxy дадут фору такому подходу ого-го
Да даже еще один nginx сверху с ip_hash балансиром справятся, нафиг туда еще haproxy городить?
Все-таки nginx, прежде всего — веб-сервер, HAProxy — лоад-балансер. Лучше отделять мух от котлет сразу, чтобы после не было мучительно больно питаться фаршем с крылышками и лапками.
Так я не заставляю, просто в случае nginx получаем балансер + много «фишек». Пусть даже балансер более простой, чем HAProxy, но уж куда более лучший, чем dns-round-robin. Да и начинающим проще разобраться с уже знакомым nginx и получить почти тоже самое, чем разбираться с еще одним инструментом.
P.S. HAProxy конечно хороший тоже! Использовали его когда nginx не было еще в природе.
P.S. HAProxy конечно хороший тоже! Использовали его когда nginx не было еще в природе.
Это не так. Никаких «прежде всего» по этому вопросу не существует. Балансировка также очень важное направление развития, и если вы проследите за изменениями в последних версиях, то можете отметить появление нового метода балансировки и улучшение старого алгоритма.
Nginx прежде всего веб-сервер, затем уже балансер, прокся, кэш статики и т.д. и т.п.
Используйте те инструменты, которые предназначены для решения задач. Чего же тогда вы не используете Apache? Тоже замечателньый балансировщик там есть, все дела. В чем проблема? Если вам нужна кофеварка — пожалуйста, только не нужно говорить, что никаких «прежде всего» не существует.
Веб-сервер лучше всего будет выполнять функции веб-сервера, лоад-балансер будет лучше всего выполнять функции лоад-балансера. Without exceptions.
Используйте те инструменты, которые предназначены для решения задач. Чего же тогда вы не используете Apache? Тоже замечателньый балансировщик там есть, все дела. В чем проблема? Если вам нужна кофеварка — пожалуйста, только не нужно говорить, что никаких «прежде всего» не существует.
Веб-сервер лучше всего будет выполнять функции веб-сервера, лоад-балансер будет лучше всего выполнять функции лоад-балансера. Without exceptions.
Nginx прежде всего веб-сервер, затем уже балансер, прокся, кэш статики и т.д. и т.п.Кто эти «прежде всего» определил? Почему вы расставили так приоритеты? Особенно это занимательно с учетом того факта, что nginx можно собрать вообще без поддержки http.
p.s. Apache хороший инструмент, если вас устраивает его производительность, вы отлично знакомы с нюансами конфигурирования и его функциональности достаточно для вашей задачи. Почему нет?
Вы либо издеваетесь, либо просто троллите. Приоритеты я так расставляю, очевидно, на основе того, что заглядываю в документацию разных утилит и инструментов не реже, чем читаю хабр.
Nginx:
Где здесь написано, что это, прежде всего, лоад-балансер?
HaProxy:
Где здесь написано, что это, прежде всего, http-сервер?
Эти «прежде всего», которые я озвучил, определили Игорь Сысоев и Willy Tarreau.
Nginx:
Официальная документация
nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым.
Где здесь написано, что это, прежде всего, лоад-балансер?
HaProxy:
Официальная документация
HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications.
Где здесь написано, что это, прежде всего, http-сервер?
Эти «прежде всего», которые я озвучил, определили Игорь Сысоев и Willy Tarreau.
Да что вы, никакого издевательства или троллинга с моей стороны.
Я лишь хотел обратить ваше внимание на тот факт, что nginx активно используется и развивается в направлении балансировки. Не хотелось бы, чтобы у кого-то были какие-то предубеждения против nginx в качестве балансировщика. Более того, настоящий хайлоад не стесняется отдавать ему предпочтение. Глупо было бы отрицать, что по ряду вещей nginx пока уступает таким более специализированным инструментам, как haproxy, но мы работаем над этим.
Страница на nginx.org далека от репрезентативной выборки актуальных фич и приоритетных направлений развития.
Я лишь хотел обратить ваше внимание на тот факт, что nginx активно используется и развивается в направлении балансировки. Не хотелось бы, чтобы у кого-то были какие-то предубеждения против nginx в качестве балансировщика. Более того, настоящий хайлоад не стесняется отдавать ему предпочтение. Глупо было бы отрицать, что по ряду вещей nginx пока уступает таким более специализированным инструментам, как haproxy, но мы работаем над этим.
Страница на nginx.org далека от репрезентативной выборки актуальных фич и приоритетных направлений развития.
Мы написали в конце статьи, что планируем переход на веб-сокеты в ближайшее время.
Консультант не домохозяйка, а вот обычные посетители, которые заходят на сайты и пишут в консультант не всегда имеют «нормальный» браузер. Но это конечно же можно определять, поэтому не проблема.
Консультант не домохозяйка, а вот обычные посетители, которые заходят на сайты и пишут в консультант не всегда имеют «нормальный» браузер. Но это конечно же можно определять, поэтому не проблема.
А БД у вас никак не делится? Все на одной машине?
Все на одной машине, этого достаточно.
При росте нагрузки можно будет сделать шардинг или просто разнести базы с разным предназначением на разные машины.
При росте нагрузки можно будет сделать шардинг или просто разнести базы с разным предназначением на разные машины.
Зашел внутрь, хайлоада не нашел. Где он?
Здесь описана схема, по которой можно наращивать мощности при необходимости для обработки высоких нагрузок.
Групон тоже на центос+опенвз переводили?
Не переводили.
Это был стартап на начальном этапе, потому просто разворачивали.
Это был стартап на начальном этапе, потому просто разворачивали.
Групон на дебиане работает с самого начала.
На дебиан они перешли позднее.
А со старта и по декабрь 2011 года был центос.
Если мы про groupon.ru говорим, конечно.
А со старта и по декабрь 2011 года был центос.
Если мы про groupon.ru говорим, конечно.
ага, про него. Т.е. вашу команду выгнали через год?
Не выгоняли. Расстались мирно.
Евтухович не слишком лестно отзывался )
Когда над проектом работает много людей, всегда будет столько же и мнений — это нормально.
В нашей компании текучка клиентов — меньше 1% и мы делаем технически все, чтобы клиенты были довольны и думали о своих бизнес процессах, а не о серверной составляющей.
В нашей компании текучка клиентов — меньше 1% и мы делаем технически все, чтобы клиенты были довольны и думали о своих бизнес процессах, а не о серверной составляющей.
Почему сразу выгнали? Сейчас администрированием занимается команда Evil Martians ( www.siliconrus.com/2013/01/centos-admin-ru-ili-kak-startapu-spravitsya-s-rastushhey-nagruzkoy-bez-administratora-v-shtate/#comment-775537840 ) — у них появился собственный ресурс, а учитывая, что они же занимаются и разработкой, так было удобнее обеим сторонам.
Уточнение — не переводили, а сразу разворачивали на центосе и опенвз
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура highload проекта на примере веб-консультанта