Лучший способ распределить нагрузку между несколькими статическими файловыми серверами для равномерного распределения пропускной способности?

Прежде всего, я объясню вам мою ситуацию. Я использую довольно популярный веб-сайт как побочный проект, поэтому я не могу вкладывать в него кучу денег. В настоящее время у меня есть только один сервер с HAProxy, который отправляет нормальные запросы в Apache, и все запросы статических файлов в Lighttpd. Это работает очень хорошо, потому что все запросы php и post обрабатываются Apache, в то время как все изображения отправляются на более быстрый Lighttpd (сайт в основном состоит из изображений, так что это действительно важно). Было бы хорошо, если бы вам не пришлось настраивать поддомен для обслуживания изображений, потому что короткие URL-адреса также очень важны, поэтому я и использую HAProxy.

Я нашел хостинг-провайдера, который предлагает довольно дешевую неизмеримую пропускную способность, которую я использовал, проблема возникает, когда я начинаю выдвигать столько пропускной способности, сколько может выдержать сетевая карта 100 МБ, поэтому нужен второй сервер.

Я много думал о своих вариантах, поэтому объясню каждый из них. Надеюсь, вы могли бы дать некоторое представление о том, какой из них лучший для меня, или, может быть, есть еще один вариант, о котором я еще не думал.

Требования:

• Даже распределение пропускной способности является обязательным. У меня довольно мощный сервер, поэтому масштабирование не вариант. Мне нужно масштабировать, чтобы увеличить пропускную способность.

• Короткие URL. Я действительно не хочу настраивать поддомен, такой как img.example.com, для обслуживания моих изображений. example.com/image.jpg - это то, как оно есть сейчас, и как бы я хотел, чтобы он остался. Но если нет другого пути, тогда я понимаю.

• Самый короткий сервер, обрабатывающий запрос, был бы действительно хорош, но не обязателен. Что-то иметь в виду.

HAProxy to loadbalance:

• Это было бы действительно легко сделать, так как я все равно уже использую HAProxy. Тем не менее, я думаю, что проблема возникает при распределении пропускной способности. Я могу ошибаться в этом, но разве HAProxy не отправляет запрос на сервер, где сервер обрабатывает его, а затем отправляет его обратно через HAProxy клиенту? Таким образом, весь трафик возвращается обратно через балансировщик нагрузки, заставляя его использовать столько пропускной способности, сколько все серверы вместе взятые.

DNS Round Robin:

• Это может быть моим лучшим вариантом. Просто скопируйте сайт на несколько серверов и делайте то, что я делаю сейчас. Недостатком является то, что если один сервер выходит из строя, клиенты по-прежнему отправляются на него. Мне также нужно будет реплицировать сайт на нескольких серверах. Я надеялся, что у меня будет один главный сервер, который обрабатывает все, кроме статических файлов, а затем пара статических файловых серверов. Я также читал, что это было своего рода «балансировкой нагрузки для бедняков», и было бы неплохо иметь что-то более сложное.

Прямой возврат на сервер:

• Это кажется действительно сложным, но может быть хорошим вариантом. Смогу ли я отправлять определенные URL-адреса на определенные серверы? Как и сейчас с HAProxy, каждый URL, заканчивающийся правильным расширением файла, отправляется Lighttpd, в то время как другие расширения отправляются в Apache. Так что мне нужно что-то подобное. Мол, все php-запросы обрабатываются одним и тем же сервером, на котором запущено программное обеспечение для балансировки, а все jpg-запросы отправляются на несколько серверов.

В идеале, если бы HAProxy поддерживал Direct Server Return, тогда моя проблема была бы решена. Я также не хочу использовать CDN, потому что они действительно дорогие, и это всего лишь побочный проект.

Вы понимаете мою проблему? Дайте мне знать, если я что-то не правильно объяснил или вам нужна дополнительная информация.

Нарисуйте свой цикл запроса / ответа для приложения и изолируйте узкое место. Вы правы, что один прокси-сервер, распределяющий нагрузку на многие серверы приложений, потребует совокупной пропускной способности всех серверов приложений. Классическим решением является RR DNS. Google, Yahoo и Amazon все используют эту технику с коротким TTL. Некоторое время назад я провел некоторое расследование и задокументировал свои выводы .

Другое решение заключается в использовании причудливого решения для балансировки корпоративной нагрузки с использованием виртуальной IP-адресации для балансировки запросов между несколькими серверами приложений с реальными IP-адресами. Я работал с продуктами Netscaler и Stonesoft. Оба хорошо работают, но имеют ужасные особенности и довольно сложны.

Некоторые ответы:

• Да, весь трафик проходит через HAProxy, поскольку он работает как прокси уровня HTTP. Это будет то же самое, даже если HAProxy установлен на отдельном сервере, который балансирует нагрузку на несколько внутренних серверов. Таким образом, если ваш хостинг-провайдер предоставляет только 100-мегабитные сетевые порты, а вы уже используете 100-мегабитный, то у вас есть проблема.
• Что касается домена, оптимальным вариантом было бы обслуживание изображений из домена, отличного от вашего веб-приложения - не поддомен, а другой, чтобы файлы cookie не отправлялись вместе с запросами изображений. Посмотрите оригинальную работу Стива Соудерса или реализацию здесь, на Переполнение стека . Если короткие URL-адреса очень важны для вас, возможно, лучше всего было бы убрать веб-приложение с основного URL-адреса, то есть перенести приложение для управления файлами на login.sitename.com?

Вам нужна аутентификация по запросам изображений? Если нет, то как насчет использования чего-то вроде Amazon S3? Он масштабируем, а стоимость передачи данных довольно низкая. В этом случае я бы использовал что-то вроде i.sitename.com в качестве DNS CNAME для имени хоста корзины Amazon S3, см. Документацию Amazons . Кстати, вы не можете использовать имя корневого домена (sitename.com) в качестве CNAME, поэтому для этого вы должны использовать поддомен, например i.sitename.com.

Вы также можете хэшировать свои изображения на нескольких серверах. Т.е. вы создаете структуру DNS, такую ​​как login.sitename.com и a.sitename.com; b.sitename.com; c.sitename.com и так далее. «А» и "б" и т. д. серверы содержат только файловую систему с изображениями и облегченный HTTP-сервер (вы уже используете Lighttpd, поэтому продолжайте использовать его. В будущем проекте я бы предложил использовать nginx как лучшую замену.) Когда пользователь загружает данные На изображении вы создаете хэш уникального идентификатора, возможно, его имени пользователя, возможно, имени файла или комбинации нескольких идентификаторов . Из этого хэша вы определяете, на каком сервере хранить изображение.

Править Я должен был увидеть, что хеширование уже обсуждалось. По сути, я предлагаю просто использовать хеширование для имени хоста, чтобы равномерно распределить сетевой трафик на нескольких хостах.

Я не знаю, как дешево это нужно, но когда вы загружаете 100 Мбит сетевого трафика, тогда «дешево и хорошо» быстро оказывается иллюзией. Может быть, вам стоит взглянуть сначала на получение хорошей бизнес-модели, которая обеспечивает постоянный доход, а затем внедрять соответствующую технологию?

Я предполагаю, что HAProxy находится на том же сервере, что и другие ваши приложения? Вы можете подключить HAProxy к другой системе, чтобы выполнить запросы и заставить его отправлять обычные запросы на один сервер и запросы изображений на другой сервер. Проблема в том, что все запросы по-прежнему направляются в один ящик, и если вы насыщаете его пропускную способность, это может вам не сильно помочь.

Вы говорите, что короткие URL-адреса важны. Почему? Неужели так сложно переключить изображения с «example.com» на «i.example.com»? Вы можете установить «i» на свой собственный IP на своем сервере с Lighttpd и полностью обойти HAProxy, решая проблему пропускной способности. Вы также получили бы преимущество веб-браузера, позволяющего открывать больше запросов одновременно, поскольку он рассматривал бы их как разные доменные имена и мог бы открывать больше одновременных соединений. Если один сервер «i» насыщен, вы можете использовать циклический перебор DNS, чтобы добавить еще один. Надеюсь, к тому времени вы получите достаточно прибыли, чтобы реализовать лучшее решение.

Ваш хостинг-провайдер предлагает услуги балансировки нагрузки? Я думаю, что это лучшее решение.

Другой способ сделать это, но это нужно проверить, - переписать (в облегченном или apache) запросах. Например: example.com/file.html находится в apache, а example.com/image.jpg перенаправляет на i.example.com/image.jpg. Все запросы будут обрабатываться через Apache, но ответы (пропускная способность восходящего канала) отправляются на сервер lighttpd. Домен прозрачен для пользователя. Тем не менее, вам нужно проверить, может ли apache обрабатывать все запросы или, возможно, позволить lighttpd выполнить эту работу.

Вы правы, все данные проходят через HAProxy, поэтому вы не можете (насколько я знаю) сделать прямой возврат сервера с ним.

ОБНОВИТЬ

Просматривая документацию HAproxy, я нашел параметр "redir". Я не знаю, может ли это работать как переписать Apache, но это может быть полезно. Документация гласит:

Основное использование заключается в увеличении пропускной способности статических серверов за счет прямого подключения клиентов к ним.

Может быть, это работает для вашего случая.

Я предполагаю, что с любым значительным набором изображений вы не сохраняете изображения на основе их исходного имени файла, поскольку вы довольно быстро столкнетесь с конфликтами имен.

Многие приложения, которые занимаются этими типами проблем, используют хэш файла и структуру каталогов, основанную на этом хэше. Структура каталогов выглядит следующим образом: путь к каталогу - это первые два символа хэша, затем каталог второго уровня - это следующие два символа в хэше.

/image root/AA/AA/images  
/image root/AA/AB/images

Преимущество заключается в том, что хэши обеспечивают равномерное распределение файлов и предоставляют пространство имен, которое легко разделить на несколько серверов. В основном вы обслуживаете части хеш-пространства с разных серверов, и по мере масштабирования вы можете поделить это далее по мере необходимости.

Недостатком является то, что хеши не идеальны и могут быть столкновения. Я не уверен, как это происходит. Так что это может занять немного исследований с вашей стороны. Я полагаю, что правило перезаписи в прокси должно быть в состоянии взять хэш, скажем, A3A8BBC83261.jpg и переписать его на http://img3.domain.com/A3/A8/BBC83261.jpg . Вы можете не считать это коротким URL.

В своем посте вы упомянули, что вам кажется, что DNS round robbin может быть вашим лучшим вариантом, но вы были обеспокоены ошибкой одного сервера ...

Если это так, взгляните на Simple Failover от JH Software. Я использовал это в прошлом, и это работает очень хорошо.

http://www.simplefailover.com

По сути, он контролирует ваши серверы, и когда он видит, что один из них выходит из строя, он быстро переписывает DNS, чтобы вытащить мертвый сервер из ротации.

Вот фрагмент их сайта:

Simple Failover непрерывно отслеживает ваши серверы, чтобы определить, какие из них работают, а какие нет, а затем динамически обновляет ваши записи DNS, чтобы ваше доменное имя всегда указывало на работающий сервер.

Он работает с веб-серверами (HTTP), почтовыми серверами (SMTP, IMAP, POP3), FTP-серверами и практически любыми другими типами серверов на базе TCP / IP.

Как упоминалось ранее, я использовал его в прошлом для веб-сайтов и почтовых серверов. Он работал довольно хорошо. Отработка отказа в большинстве случаев была довольно быстрой (примерно 2-5 минут), и я бы сказал, что почти все отказались менее чем за 15 минут.

Не обязательно идеально ... но определенно быстро и легко.

ПРИМЕЧАНИЕ. Это продукт для Windows. Я не уверен, есть ли у них версия для Linux или нет, но вы можете переключиться на любой сервер, который вам нравится, поскольку он основан на DNS.

В нашем случае мы просто выбросили его на компьютер с XP, сказали машине перезагружаться раз в ночь, и он работал нормально в течение многих лет.