Комментарии 19
Т.е. судя по вашему конфигу сервера по 90 секунд будут долбиться к друг-другу? Ужас!
Это если файл будет отсутствовать на обоих серверах. Проще перечислить все сервера в одном upstream'е, и второй пометить как backup. Тогда nginx сначала будет искать на локальном, и только потом на удаленном. (maxfails должно быть равно 0)
Согласен. Приведенный конфиг писался не с продакшен серверов и приведен просто как пример, что такие варианты возможны. Вариантов решения проблем, на самом деле, очень много :)
НЛО прилетело и опубликовало эту надпись здесь
Два варианта. Либо встроенный перл, либо catap.ru/blog/2009/05/13/nginx-crc32_name-and-md5_name/?reply_to=504
Сталкивался и реализовал подобную задачу. В вашем варианте недостаток в том, что на перебор вариантов тоже тратится время. В очень загруженных проектах это может быть существенно.
Если страница, на которой расположен контент, который показывается в виде файлов, динамическая, можно использовать другой вариант. Тогда на странице лучше формировать прямые ссылки на локейшен, привязанный к определенному серверу с данным файлом. Тогда логику поиска файла будет определять скрипт на этапе формирования страницы, а при обращении к файлу будет просто прямое обращение без затрат времени.
Другой вариант — использовать скрипт для определения местоположения файла и выдачи его через хидер 'X-Accel-Redirect'. В каких-то случаях тоже может подойти, но по ресурсам он, вероятно, будет похуже чем ваш вариант.
Если страница, на которой расположен контент, который показывается в виде файлов, динамическая, можно использовать другой вариант. Тогда на странице лучше формировать прямые ссылки на локейшен, привязанный к определенному серверу с данным файлом. Тогда логику поиска файла будет определять скрипт на этапе формирования страницы, а при обращении к файлу будет просто прямое обращение без затрат времени.
Другой вариант — использовать скрипт для определения местоположения файла и выдачи его через хидер 'X-Accel-Redirect'. В каких-то случаях тоже может подойти, но по ресурсам он, вероятно, будет похуже чем ваш вариант.
так же можно организовать CDN и все пути к картинкам давать относительно него, а он уже сам будет выплевывать правильный редирект.
Таким образом, схема будет такая:
клиент -> cdn -> отдача картинки с сервера
Таким образом, схема будет такая:
клиент -> cdn -> отдача картинки с сервера
отключение access.log при наличии в кампании отделов QA и Support — это, мягко выражаясь, — не правильно.
Не очень вас понял.
Если файлы статические — то положите их на оба фронта и все. И никаких проблем.
У нас была похожая задача: возможно несколько миллионов вариантов картинок, какие будут заранее не известно. Решили, что будем генерировать по запросу и класть в кеш nginx на срок действия проекта. Сервера друг про друга ничего не знают и работают независимо — это сразу устраняет ряд проблем. Самый большой минус нашего решения — то, что картинка будет генерироваться дважды. Но это гораздо меньшее зло, чем долбежка по кругу.
Если файлы статические — то положите их на оба фронта и все. И никаких проблем.
У нас была похожая задача: возможно несколько миллионов вариантов картинок, какие будут заранее не известно. Решили, что будем генерировать по запросу и класть в кеш nginx на срок действия проекта. Сервера друг про друга ничего не знают и работают независимо — это сразу устраняет ряд проблем. Самый большой минус нашего решения — то, что картинка будет генерироваться дважды. Но это гораздо меньшее зло, чем долбежка по кругу.
Еще вариант решения
— вынести картинки на отдельный домен и ip
— поставить squid-ы, настроить их общение по ICP. Теперь, если сквид может брать картинки их кеша другого сервера
— profit!
— вынести картинки на отдельный домен и ip
— поставить squid-ы, настроить их общение по ICP. Теперь, если сквид может брать картинки их кеша другого сервера
— profit!
Проще статику синхронизировать с помощью lsyncd как в статье
habrahabr.ru/post/132098/
А балансировку между серверами делать с помощью ipvs, или с помощью ДНС на худой конец.
habrahabr.ru/post/132098/
А балансировку между серверами делать с помощью ipvs, или с помощью ДНС на худой конец.
ай яй яй вебсервер начинать с 192.168.0.1 :)
В последний раз делал проще домен files.site.com под файлы, site.com под сайт.
Дальше балансируем днсами и/или поддоменами.
Дальше балансируем днсами и/или поддоменами.
Каким образом клиенту отдать эту картинку, если у вас нет единой файловой системы и файлы не синхронизируются между серверами?
Залить картинку на сервер вконтакта!
На счет динамики… Не знаю, о каких топовых приложениях вы говорите, но виджеты, которые имели 2кк уников в сутки, работали на 1м не очень мощном сервере, на котором хранились все картинки, JS'ки, php файлы, мускуль, и все работало как часики, обрабатывая тысячи заходов в минуту, проводя различные анализы с этими данными. В ВК, на данный момент, нет приложений (про игры молчу) с подобным хайлоадом (если, конечно, в топовых приложениях не говнокод внутри, который при меньшем дау творит больше ЛА).
Залить картинку на сервер вконтакта!
На счет динамики… Не знаю, о каких топовых приложениях вы говорите, но виджеты, которые имели 2кк уников в сутки, работали на 1м не очень мощном сервере, на котором хранились все картинки, JS'ки, php файлы, мускуль, и все работало как часики, обрабатывая тысячи заходов в минуту, проводя различные анализы с этими данными. В ВК, на данный момент, нет приложений (про игры молчу) с подобным хайлоадом (если, конечно, в топовых приложениях не говнокод внутри, который при меньшем дау творит больше ЛА).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Балансировка статических файлов средствами nginx