У мене є маса запитань щодо ssl, локальних сеансів та балансування навантаження, які, здається, пов'язані між собою, тому я заздалегідь вибачаюся за тривалість цього питання.
У мене є веб-сайт, який використовує файлові сеанси. Природа сайту полягає в тому, що більшість з них є http, але деякі розділи - ssl. Наразі через сеанси на основі файлів необхідно, щоб будь-які запити ssl потрапляли на той же сервер, що і будь-які попередні http-запити.
Через часові обмеження, я хочу зробити найпростішу можливу річ, щоб завантажити баланс збільшеного http та ssl трафіку.
Здається, є два варіанти алгоритмів балансування навантажень:
- на основі ip
- на основі печива
Рішення на базі ip, ймовірно, спрацює, але алгоритм хешування потенційно змінить сервер, до якого користувач переходить, коли сервер закривається або додається, що небажано при поточній установці сеансу на основі файлів. Я також припускаю, що технічно можливо, щоб користувач законно міняв ips під час перегляду веб-сайту.
Алгоритм на основі файлів cookie здається кращим, але неможливість перевірити файл cookie при шифруванні ssl, здавалося б, представляє власні проблеми.
Я гуглив приклади того, як завантажувати баланс ssl, і я не можу знайти явних прикладів налаштувань, які можуть робити балансування завантаження на основі файлів cookie.
Більшість ясних прикладів, які я бачив, мають декодер ssl (зазвичай апаратний, apache_mod_ssl або nginx), що сидить між клієнтом браузера та балансиром завантаження. Приклади, як правило, мають щось подібне (змінено з http://haproxy.1wt.eu/download/1.3/doc/architecture.txt ):
192.168.1.1 192.168.1.11-192.168.1.14
------- + ----------- + ----- + ----- + ----- +
| | | | |
+ - + - + + - + - + + - + - + + - + - + + - + - +
| LB1 | | А | | Б | | C | | Д |
+ ----- + + --- + + --- + + --- + + --- +
apache 4 дешевих веб-серверів
mod_ssl
гапрокси
Частина декодування ssl у наведеному вище прикладі здається потенційним вузьким місцем, яке не горизонтально масштабується.
Я переглянув haproxy, і, здається, є опція 'mode tcp', яка дозволила б щось подібне, що дозволило б мати кілька декодерів ssl:
гапрокси
|
-------------
| |
ssl-декодер-1 ssl-декодер2
| |
-------------------
| | |
web1 web2 web3
Однак у такому налаштуванні, схоже, ви втратите клієнтський ip, оскільки haproxy не декодує ssl: https://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -для
Я також переглянув nginx, і також не бачу явних прикладів горизонтально масштабованих ssl-декодерів. Здається, є багато прикладів людей, які мають nginx як потенційне вузьке місце. І, принаймні, це посилання, начебто, говорить про те, що nginx навіть не має можливості установки, подібної до гапрокси, де ви втратите ip, сказавши, що nginx "не підтримує прозоро передачу TCP-з'єднань до бекенду" Як передати Apache SSL трафік через nginx проксі? .
Запитання:
- Чому, здається, не буде більше прикладів налаштувань, що додають більше декодерів ssl для боротьби зі збільшенням трафіку?
- Це тому, що крок декодування ssl є лише теоретичним вузьким місцем, і практично кажучи, одного декодера по суті буде достатньо, за винятком сайтів зі смішним трафіком?
- Іншим можливим рішенням, яке спадає на думку, можливо, хтось із такими підвищеними потребами ssl також має централізований сесійний магазин, тому не має значення, який веб-сервер клієнт звертається за послідовними запитами. Тоді ви можете включити mod_ssl або еквівалент на кожному веб-сервері.
- Згадане вище рішення haproxy, здається, працює (окрім проблеми з клієнтською IP-адресою), але хто-небудь стикався з клейким рішенням, що базується на завантаженні програмного забезпечення на основі файлів cookie, яке би працювало, збільшуючи кількість декодерів, зберігаючи IP-адресу клієнта, або це, можливо, технічно не можливо (оскільки вам потрібно розшифрувати запит, щоб отримати клієнтський IP, і в цьому випадку у нас є вузьке місце декодера).
Якщо припустити, що все, що я сказав, є правдою, це, здається, є моїми варіантами:
- використовувати хеш-версію ip (погано для користувачів, які потенційно легітимно змінюють ips, а також для сценаріїв додавання та видалення серверів)
- використовувати nginx або mod_ssl як першу програму, що торкається запиту ssl, це буде потенційним вузьким місцем декодування ssl
- використовуйте haproxy як першу програму, що торкається запиту ssl, отримуючи горизонтальну масштабованість ssl, але живіть без ips, що заносяться на рівні веб-сервера для запитів ssl (можливо, тимчасово в порядку)
- у довгостроковій перспективі рухайтеся до мобільного або централізованого магазину сесій, роблячи липкі сесії непотрібними