Во-первых, я объясню вам свою ситуацию. Я веду довольно популярный веб-сайт в качестве побочного проекта, поэтому я не могу вложить в него кучу денег. В настоящее время у меня есть только один сервер с HAProxy, который отправляет обычные запросы в Apache, а все запросы статических файлов - в Lighttpd. Это работает очень хорошо, потому что все запросы php и post обрабатываются Apache, в то время как все изображения отправляются в более быстрый Lighttpd (сайт в основном состоит из изображений, поэтому это действительно важно). Было бы неплохо не создавать поддомен для обслуживания изображений, потому что короткие URL-адреса также очень важны, поэтому я использую HAProxy.
Я нашел хостинг-провайдера, который предлагает довольно дешевую неограниченную полосу пропускания, которую я использовал, проблема возникает, когда я начинаю расширять полосу пропускания, которую может обработать сетевая карта 100 Мбит / с, поэтому мне нужен второй сервер.
Я много обдумывал свои варианты, поэтому объясню вам каждый из них. Надеюсь, вы могли бы дать некоторое представление о том, какой вариант для меня лучший, или, может быть, есть другой вариант, о котором я еще не думал.
Требования:
Равномерное распределение полосы пропускания является обязательным. У меня довольно мощный сервер, поэтому масштабирование - не вариант. Мне нужно масштабировать, чтобы получить больше пропускной способности.
Короткие URL-адреса. Я действительно не хочу настраивать поддомен, например img.example.com, для обслуживания моих изображений. example.com/image.jpg - это то, как сейчас, и как мне бы хотелось, чтобы он остался. Но если другого выхода нет, то я понимаю.
Самый близкий сервер, обрабатывающий запрос, было бы действительно хорошо, но не обязательно. Что нужно иметь в виду.
HAProxy для балансировки нагрузки:
Циклический перебор DNS:
Прямой возврат сервера:
В идеале, если бы HAProxy поддерживал Direct Server Return, моя проблема была бы решена. Я также не хочу использовать CDN, потому что они очень дороги, а это всего лишь побочный проект.
Вы понимаете мою проблему? Дайте мне знать, если я что-то не объяснил правильно или вам нужна дополнительная информация.
Некоторые ответы:
Вам нужна аутентификация по запросам изображений? Если нет, как насчет использования чего-то вроде Amazon S3? Он очень масштабируемый, а стоимость передачи данных довольно дешевая. В этом случае я бы использовал что-то вроде i.sitename.com в качестве DNS CNAME для имени хоста корзины Amazon S3, см. документы Amazons. AFAIK у вас не может быть корневого доменного имени (sitename.com) в качестве CNAME, поэтому для этого вы должны использовать поддомен, например i.sitename.com.
Вы также можете хэшировать свои изображения на нескольких серверах. Т.е. вы создаете структуру DNS, такую как login.sitename.com и a.sitename.com; b.sitename.com; c.sitename.com и так далее. Буква «а». и "б." Серверы etc просто содержат файловую систему с изображениями и облегченный HTTP-сервер (вы уже используете Lighttpd, поэтому продолжайте его использовать. Для будущего проекта я бы предложил взглянуть на nginx как на лучшую замену.) Когда пользователь загружает образ, вы создаете хеш уникального идентификатора, возможно, его имени пользователя, возможно, имени файла или комбинации нескольких идентификаторов. По этому хешу вы определяете, на каком сервере хранить изображение.
редактировать Я должен был видеть, что хеширование уже обсуждалось. По сути, я предлагаю просто использовать хеширование для имени хоста, чтобы равномерно распределить сетевой трафик на нескольких хостах.
Я не знаю, насколько это дешево тебе нужно. - но когда вы загружаете 100 Мбит сетевого трафика, то «дешево и хорошо» быстро оказывается иллюзией. Может быть, вам стоит сначала подумать о том, чтобы получить хорошую бизнес-модель, которая обеспечивает постоянный доход, а затем внедрить соответствующую технологию?
Нарисуйте картину цикла запроса / ответа для приложения и выделите узкое место. Вы правы, что один прокси-сервер, распределяющий нагрузку на множество серверов приложений, потребует совокупной пропускной способности всех серверов приложений. Классическое решение - RR DNS. Google, Yahoo и Amazon используют эту технику с коротким TTL. Некоторое время назад я провел расследование и задокументировал мои выводы.
Другое решение - использовать модное решение для балансировки нагрузки предприятия с использованием виртуальной IP-адресации для балансировки запросов между несколькими серверами приложений с реальными IP-адресами. Я работал с продуктами Netscaler и Stonesoft. Оба работают хорошо, но имеют ужасные особенности и довольно сложны.
Предлагает ли ваш хостинг-провайдер услуги по балансировке нагрузки? Думаю, это лучшее решение.
Другой способ сделать это, но его нужно протестировать, - это переписать (в lighty или apache) запросы. Например: example.com/file.html остается в apache, а example.com/image.jpg перенаправляет на i.example.com/image.jpg. Все запросы будут обрабатываться через apache, но ответы (пропускная способность восходящего потока) будут отправляться на сервер lighttpd. Домен прозрачен для пользователя. Тем не менее, вам нужно проверить, может ли apache обрабатывать все запросы или, возможно, позволить lighttpd выполнять эту работу.
Вы правы, все данные проходят через HAProxy, поэтому вы не можете (насколько я знаю) выполнить прямой возврат с сервера.
ОБНОВИТЬ
Ищу в Документация HAproxy Я нашел параметр "redir". Я не знаю, может ли это работать как перезапись apache, но может быть полезно. В документации говорится:
Основное использование состоит в увеличении пропускной способности статических серверов за счет прямого подключения клиентов к ним.
Может, в твоем случае это сработает.
Я предполагаю, что HAProxy находится на том же сервере, что и другие ваши приложения? Вы можете разбить HAProxy на другую систему, чтобы выполнять запросы и отправлять обычные запросы на один сервер, а запросы изображений на другой сервер. Проблема в том, что все запросы по-прежнему отправляются в один ящик, и если вы перегружаете его пропускную способность, это может вам не сильно помочь.
Вы говорите, что короткие URL-адреса важны. Зачем? Неужели переключить изображения с "example.com" на "i.example.com" так уж сложно? Вы можете установить «i» на собственный IP-адрес на собственном сервере с помощью Lighttpd и полностью обойти HAProxy, решив проблему с пропускной способностью. Вы также получите преимущество веб-браузера, позволяющего открывать больше запросов одновременно, поскольку он будет рассматривать их как разные доменные имена и может открывать больше одновременных подключений. Если один сервер «i» становится перегруженным, вы можете использовать циклический перебор DNS, чтобы добавить еще один. Надеюсь, к тому времени вы получите достаточно дохода, чтобы внедрить лучшее решение.
Я предполагаю, что с любым значительным набором изображений вы не сохраняете изображения на основе их исходных имен файлов, так как вы довольно быстро столкнетесь с конфликтами имен.
Многие приложения, которые решают такие проблемы, используют хэш файла и структуру каталогов на основе этого хэша. Структура каталогов выглядит следующим образом, где путь к каталогу - это первые два символа хеша, а каталог 2-го уровня - это следующие два символа хеша.
/image root/AA/AA/images
/image root/AA/AB/images
Преимущество здесь в том, что хэши позволяют равномерно распределять файлы и предоставляют пространство имен, которое легко разделить на несколько серверов. В основном вы обслуживаете части хэш-пространства с разных серверов, и по мере масштабирования вы можете разделить его по мере необходимости.
Обратной стороной является то, что хеши не идеальны и могут быть коллизии. Я не знаю, как с этим бороться. Так что с вашей стороны может потребоваться небольшое исследование. Я предполагаю, что правило перезаписи в прокси-сервере должно иметь возможность принимать хэш, скажем, A3A8BBC83261.jpg, и переписывать его на http://img3.domain.com/A3/A8/BBC83261.jpg. Вы можете не считать это коротким URL-адресом.
В своем сообщении вы упомянули, что считаете, что круговой обход DNS может быть вашим лучшим вариантом, но вы были обеспокоены отказом одного сервера ...
Если это так, взгляните на Simple Failover от JH Software. Я использовал его раньше, и он работает очень хорошо.
В основном он контролирует ваши серверы и, когда видит, что один из них выходит из строя, быстро перезаписывает DNS, чтобы вывести мертвый сервер из ротации.
Вот отрывок с их сайта:
Simple Failover постоянно отслеживает ваши серверы, чтобы определить, какие из них работают, а какие не работают, а затем динамически обновляет ваши записи DNS соответствующим образом, чтобы ваше доменное имя всегда указывало на работающий сервер.
Он работает с веб-серверами (HTTP), почтовыми серверами (SMTP, IMAP, POP3), FTP-серверами и практически с любыми другими типами серверов на основе TCP / IP.
Как упоминалось ранее, я использовал его раньше как для веб-сайтов, так и для почтовых серверов. Он работал довольно хорошо. В большинстве случаев переключение происходило довольно быстро (предположительно, 2–5 минут), и я бы сказал, что почти все отключались менее чем за 15 минут.
Не обязательно ИДЕАЛЬНО ... но определенно быстро и легко.
ПРИМЕЧАНИЕ. Это продукт для Windows. Я не уверен, есть ли у них версия для Linux или нет, но вы можете переключиться на любой сервер, который вам нравится, поскольку он основан на DNS.
В нашем случае мы просто бросили его на машину XP, сказали машине перезагружаться раз в ночь, и она работала нормально в течение многих лет.
