Найкращий спосіб завантажити баланс на декілька статичних файлових серверів для рівномірного розподілу пропускної здатності?

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

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

Я багато вдумався у свої варіанти, тому я поясню вам кожен. Сподіваємось, ви зможете дати зрозуміти, який із них найкращий варіант для мене, а може, є ще один варіант, про який я ще не думав.

Вимоги:

• Навіть розподіл пропускної здатності є обов'язковим. У мене досить потужний сервер, тому масштабування не є варіантом. Мені потрібно масштабувати, щоб отримати більшу пропускну здатність.

• Короткі URL-адреси. Я дійсно не хочу налаштовувати піддомен, наприклад img.example.com, для обслуговування своїх зображень. example.com/image.jpg - це як зараз, і як я дуже хотів би, щоб це залишилося. Але якщо іншого шляху немає, то я розумію.

• Найбільш близький сервер, що обробляє запит, був би дуже приємним, але не обов'язковим. Щось мати на увазі.

HAProxy для балансування навантаження:

• Це було б дуже просто, оскільки я вже використовую HAProxy. Однак, я думаю, проблема виникає при розподілі пропускної здатності. Я можу помилитися з цим, але хіба HAProxy не надсилає запит на сервер, де сервер обробляє його, а потім надсилає його назад через HAProxy клієнту? Таким чином, весь трафік виходить назад через балансир навантаження, що змушує використовувати стільки пропускної здатності, скільки всі сервери разом.

DNS Round Robin:

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

Пряме повернення сервера:

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

В ідеалі, якби HAProxy підтримував пряме повернення сервера, тоді моя проблема була б вирішена. Я також не хочу використовувати CDN, тому що вони дійсно дорогі, і це лише побічний проект.

Ви розумієте мою проблему? Повідомте мене, якщо я щось не пояснив правильно чи вам потрібна додаткова інформація.

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

Іншим рішенням є використання рішення для балансування завантаження навантаження для підприємств з використанням віртуальної IP-адреси для врівноваження запитів серед декількох серверів додатків з реальними IP-адресами. Я працював з продуктами Netscaler та Stonesoft. Обидва працюють добре, але мають жахливі ідіосинкразії і досить складні.

Деякі відповіді:

• Так, весь трафік проходить через HAProxy, оскільки він працює як проксі-сервер рівня HTTP. Це буде те саме, навіть якщо HAProxy встановлений на окремому сервері, який завантажує балансування декількох серверів зворотнього зв'язку. Таким чином, якщо ваш хостинг-провайдер постачає тільки 100MBit мережеві порти, а ви вже натискаєте 100MBit, тоді у вас є проблема.
• Щодо домену, оптимальною річчю було б подавати зображення з іншого домену, ніж ваш веб-сервер - не субдомен, інший, щоб файли cookie не надсилалися разом із запитами на зображення. Дивіться оригінальну роботу Стіва Суудера або його реалізацію тут у "Переповнення стека" . Якщо для вас дуже важливі короткі URL-адреси, можливо, найкраще було б перемістити веб-сторінку з головної URL-адреси, тобто перемістити додаток для управління файлами на login.sitename.com?

Вам потрібна автентифікація на запити зображення? Якщо ні, то як щодо використання чогось типу 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 et cetera. "А" і "б". і т.д. сервери просто містять файлову систему із зображеннями та легкий HTTP-сервер (ви вже використовуєте Lighttpd, тому продовжуйте використовувати це. Для майбутнього проекту я б запропонував розглянути nginx як кращу заміну.) Коли користувач завантажить зображення, ви створюєте хеш унікального ідентифікатора, можливо його ім'я користувача, можливо ім'я файлу або комбінацію декількох ідентифікаторів . З цього хеша ви визначаєте, на якому сервері зберігати зображення.

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

Я не знаю, наскільки це вам потрібно дешево - але коли ви наполягаєте на 100 Мбіт мережевого трафіку, то "дешево і добре" швидко виявляється ілюзією. Можливо, вам варто спочатку розглянути можливість отримання хорошої бізнес-моделі, що забезпечує постійний дохід, а потім впровадити відповідну технологію?

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

Ви кажете, що короткі URL-адреси важливі. Чому? Це дійсно велика справа переключити зображення з "example.com" на "i.example.com"? Ви можете встановити "i" на власний IP на власному сервері за допомогою Lighttpd і повністю обійти HAProxy, вирішивши проблему пропускної здатності. Ви також отримаєте перевагу веб-браузера, що дозволяє відкривати більше запитів відразу, оскільки він вважатиме їх різними доменними іменами та може відкривати більше одночасних з'єднань. Якщо єдиний сервер "i" перенаситився, ви можете використати DNS-круговик, щоб додати ще одного. Сподіваємось, до цього часу ви генеруєте достатній дохід для впровадження кращого рішення.

Чи надає ваш хостинг-провайдер послуги з балансування навантаження? Я думаю, що це найкраще рішення.

Ще один спосіб зробити це, але це потрібно перевірити, - переписати (у легкій або апаші) запити. Наприклад: example.com/file.html залишається в апачі, а example.com/image.jpg переспрямовує на i.example.com/image.jpg. Усіма запитами керуватиметься через apache, але репозенти (пропускна здатність вище) передаються на сервер lighttpd. Домен прозорий для користувача. Ще потрібно перевірити, чи може апаш обробляти всі запити чи, можливо, дозволити 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 може бути найкращим варіантом, але вас турбує невдача одного сервера ...

Якщо це так, подивіться на Простий відмову від JH Software. Я використовував його в минулому, і він працює дуже добре.

http://www.simplefailover.com

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

Ось фрагмент з їх веб-сайту:

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

Він працює з веб-серверами (HTTP), поштовими серверами (SMTP, IMAP, POP3), FTP-серверами та практично будь-яким іншим сервером на основі TCP / IP.

Як уже згадувалося раніше, я використовував його в минулому для веб-сайтів та поштових серверів. Це виступило досить добре. Перехід у аварійний режим у більшості випадків був досить швидким (здогадуючись про 2-5 хв.), І я б сказав, що майже всі провалилися менш ніж за 15 хвилин.

Не обов'язково досконало ... але, безумовно, швидко та легко.

ПРИМІТКА. Це продукт Windows. Я не впевнений, чи є у них версія Linux чи ні, але ви можете перейти на будь-який сервер, який вам подобається, оскільки його базується на DNS.

У нашому випадку ми просто перекинули його на машину XP, сказали машині перезавантажуватися один раз на ніч, і вона працювала нормально роками.