Разни въпроси към WEB-аджиите...

[Daniel]

Re: Разни въпроси към WEB-аджиите...

Ако един клиент ще работи на един сървер за какво ти е лоад балансинг. Поддомейна сочи ип то на еди кой си сървер и не ти трябва това упражнение. Аз май въобще не мога да ти схвана идеята и схемата на приложението.

[Агоп Серопян]

От: Re: Разни въпроси към WEB-аджиите...

Ако един клиент ще работи на един сървер за какво ти е лоад балансинг. Поддомейна сочи ип то на еди кой си сървер и не ти трябва това упражнение. Аз май въобще не мога да ти схвана идеята и схемата на приложението.

Чета постовете 5 пъти и аз стигам до този извод освен ако под един сървър няма предвид няколко

[persuader]

От: Разни въпроси към WEB-аджиите...

Значи днс-а не може да пренасочва към портове.

От това което разбирам искаш да направиш горе долу картинката е горе долу следната .

Имаш домейн или няколко домейна - в случая е без значение (за няколко домейна облслужващи се от различни app сървъри просто ще се усложни конфигурацията на load balancer-a) всички домейни сочат към едно ип да кажем 1.1.1.1 - на ип 1.1.1.1 е инсталиран линукс/бсд и на 80 ти порт е пуснат Load balancer(nginx, havp, varnish) зад този линукс седят произволен брой application сървъри примерно windows сървъри с iis от мрежа 192.168.0.0/24 .

Кофигурацията на този load balancer трябва да подържа sticky sessions тоест - Клиент а отваря брaузъра пише app.sparky.com рекуеста идва в лоад балнсера който проверява 1. за кой домеин става въпрос 2. има ли session cookie. Ако има session cookie проверява дали app servera който е обслужвал последно този session id е жив ако е жив препраща завката към него. Ако не е жив избира друг сървър посредством round robin друг подобен алгоритъм или изрична настройка и препраща клиента към него където той ще трябва да се оторизира пак и да се създаде сесия (надали ще се случва често но е добре да се предвиди в конфига какво става ако някой от сървърите е down).

На първо четене реализацията ми изгежда най-лесна с havp.

Ако се сещаш нещо питай.

P. S.
Принципно load balancing се прави най-често за две неща. 1. high availability - тоест да не угасне некой сървър и клиентите да не останат без услуга. 2. Разпределение на натоварването - ако имаш много потребители и искаш да намалиш натоварването върху машините.

Ако целта ти не е нито в точка едно нито в точка 2 мисля че нещата могат да се случат без никакъв balancing доста по-елементарно - пробвай да опишеш по-подробно крайната цел защото на мене лично не ми е много ясна.

[sparkybg]

От: Re: Разни въпроси към WEB-аджиите...

Ако един клиент ще работи на един сървер за какво ти е лоад балансинг. Поддомейна сочи ип то на еди кой си сървер и не ти трябва това упражнение. Аз май въобще не мога да ти схвана идеята и схемата на приложението.

1. Имаме например 10 фирми, всяка има база данни, всяка има примерно по 5 юзера, всяка си има поддомейн. Тоест всички юзери от фирма1 работят през firma1.sparky.com и т.н.
2. Имаме да речем 5 идентични web сървъра с load balancer пред тях.

И сценария. Системата се пуска от нула. Няма заявки.
- заявка от firma1.sparky.com - лоад балансера я пращя към сървър1
- заявка от firma2.sparky.com - лоад балансера я праща към сървър2
...
- заявка от firma1.sparky.com - лоад балансера я праща отново към сървър едно
...
- 20 минути няма заявки от firma1.sparky.com - load balancer-a си трие хеша или там квото
...
- по някое време отново заявка от firma1.sparky.com - load balancer-a я праща към най-свободния към момента сървър, да речем сървър 3, всички следващи заявки от firma1.sparky.com се пращат все към сървър 3, освен ако дълго време няма такива и лоад балансера изтрие там каквото си поддържа за firma1.


Демек искам sticky session базирана не на отворен броузър със сешън куки, а на субдомейна. ASP апликейшъна си ползва неговите си сешън кукита и оторизейшън кукита, от които load balancer-а не се интересува.

[Daniel]

Re: Разни въпроси към WEB-аджиите...

Апликейшъна един ли е или за всяка фирма си е отделен, отделна база данни ще рече че всеки си има табличка в дб сървера или че всеки си има дб сървер.
Ако апп то е едно и се достъпва на един ИП адрес - всички поддомейни в ДНС а сочат него - лоад балансера. Ако са различни съответно всички сочат лоад балансер стека. Не ти е нужно стики куки в случая - ползвай си ИП хеш а за сесия - така всички клиенти на фирма ще си работят на един сървер докато има заявки.
NGINX а може да прави форурдинг по портове ДНС а няма как. Въпреки че в момента не виждам за какво ти е

http://nginx.com/resources/admin-guide/load-balancer/

Иначе се дефинират сърверите и се проксира трафика през дефинираната група сървери.

upstream mywebsite1 {
ip_hash;
server xxx.xxx.xxx.196 weight=1 max_fails=3 fail_timeout=15s;
server xxx.xxx.xxx.67 weight=1 max_fails=3 fail_timeout=15s;
server xxx.xxx.xxx.201 weight=1 max_fails=3 fail_timeout=15s;
}

server {
listen 80;
server_name mywebsite1.com;

access_log /var/log/nginx/proxy.log;

location / {
proxy_pass http://mywebsite1;
}

server {
listen 80;
server_name mywebsite2.com;

access_log /var/log/nginx/proxy.log;

location / {
proxy_pass http://mywebsite1;
}

Дефакто всичко дошло за mywebsite1.com ще бъде проксирано през mywebsite1 стека. Същото може да се дефинира и за останалите домейни.


Изчети тази документация има и за сешън персистенс http://nginx.com/resources/admin-gui...lancer/#sticky Няма къде в линукс - по принцип всичко си се дефинира в конфиг файловете. Демек цялата конфигурация си я пишеш там.

Ето още малко полезна информация - да се ориентираш как стават нещата.
http://nginx.com/blog/load-balancing...nx-plus-part2/

ето така става за няколко домейна с различни клъстера.
upstream site_a {
server 192.168.1.21;
server 192.168.1.31;
}

upstream site_b {
server 192.168.1.22;
server 192.168.1.32;
}

# site_a backend with public IP 5.6.7.8:80
server {
access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log;
index index.html;
limit_conn gulag 50;
listen 5.6.7.8:80 default; # public IP here
root /usr/local/www/nginx;
server_name _;
# get full domain
location / {
proxy_pass http://site_a;
proxy_cache cache;
proxy_cache_valid 200 24h;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_ignore_headers Expires Cache-Control;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

# site_b backend with public IP 1.2.3.4:80
server {
access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log;
index index.html;
limit_conn gulag 50;
listen 1.2.3.4:80 default; # public IP here
root /usr/local/www/nginx;
server_name _;
# get full domain
location / {
proxy_pass http://site_b;
proxy_cache cache;
proxy_cache_valid 200 24h;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_ignore_headers Expires Cache-Control;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

Като в случая не пречи proxy_pass да сочи един и същ клъстер. Важното е добре да си настроиш сървер директивите и съответно клъстер частта - със опциите weight=1 max_fails=3 fail_timeout=15s; и т.н.

[persuader]

От: Разни въпроси към WEB-аджиите...

Както каза Даниел http://nginx.com/resources/admin-gui...lancer/#sticky това е правилния метод. Аз лично бих използвал шернат сторидж за сесиите от който да четат всички сървъри например memcached но това си е твое решение.

[sparkybg]

От: Разни въпроси към WEB-аджиите...

Аз лично бих използвал шернат сторидж за сесиите от който да четат всички сървъри например memcached но това си е твое решение.

Е то целия зор е точно за да избегна това, със все недостатъците му като ниска скорост, изисквания за серизлизируеми обекти ако искам да слагам мои данни в сешъна и т.н. В крайна сметка ако не може друго, ще се прави така. Един вид хем да имам твърдо фирма->сървър, хем тоя сървър да се определя кой да е физичеки от лоад балансъра.

Линка го чета в момента, за което отново благодаря.

[Daniel]

Re: Разни въпроси към WEB-аджиите...

Ами не ползвай сесии. Ползвай ИП хеш. И без това няма смисъл от сесии след като, ще ги караш всички сесии на един клиент да ходят на един сървър.

[persuader]

От: Разни въпроси към WEB-аджиите...

Доколкото разбирам всеки "клиент" има по няколко потребителя които трябва да ходят на един апп сървър ако е сигурно че всички потребители са от едно ip давай с хеш.

[sparkybg]

От: Разни въпроси към WEB-аджиите...

Доколкото разбирам всеки "клиент" има по няколко потребителя които трябва да ходят на един апп сървър ако е сигурно че всички потребители са от едно ip давай с хеш.

Еми точно там е работата че не само че не е сигурно, ами и не трябва да е. Сигурното е че всички потребители на даден клиент са с един и същ поддомейн в заявките. Нищо друго не е сигурно. Тоест ако с хеш, хеша трябва да е по субдомейн, а не по IP.

[sparkybg]

От: Разни въпроси към WEB-аджиите...

User defined hash е решението. Сега нов въпрос - как да взема само хоста от request URI-то. Самото uri е налично като $request_uri, но няма нещо като $request_host или от сорта. Има $host и $http_host, които обаче не мога да вдяна дали се отнасят за рикуеста или за нещо друго.

Ако е това, нещо такова би свършило работа:

upstream mywebsite1 {
hash $host;
server xxx.xxx.xxx.196 weight=1 max_fails=3 fail_timeout=15s;
server xxx.xxx.xxx.67 weight=1 max_fails=3 fail_timeout=15s;
server xxx.xxx.xxx.201 weight=1 max_fails=3 fail_timeout=15s;
}

Да речем sparky.com e е на 80-ти порт на 1.2.3.4. На него слуша load balancer-а. Идва рекуест да речем към firma1.sparky.com\login\default. Ако при това положение в $host има "firma1.sparky.com" резултантния хеш ще е точно това, което ми трябва. Сега остава да се пробва някъде си.

Правилно ли се ориентирам?

[persuader]

От: Разни въпроси към WEB-аджиите...

Не мисля че с хост ще стане това което искаш. Ако за един домейн имаш няколко апп сървъра ще трябва да ползваш cookie persisstance.

Всъщност даже и да ползваш cookie persisstance не е ясно дали няма да има проблем ако не пазиш сесиите някъде на споделен ресурс.
cookie persisstance гарантира че usera няма да се прехвърля от сървър на сървър докато не му изтече сисията но не гарантира че всички useri от даден домейн ще са на един app сървър (ако си описал повече от един в app backend в конфига).

Всъщност вобще ползването на лоад балансинг изисква backend-a да е проектиран затова (шернати бази данни , сесии , файлове) ако не е проектиран ползването на няколко сървъра се обезмисля.

[sparkybg]

От: Разни въпроси към WEB-аджиите...

Добре де, хеша по IP тогава какво гарантира? Не гарантира ли че всички заявки от дадено IP ще отиват към определен сървър, освен ако известно време заявки не е имало и елемента в хеша за това IP не е изтекъл/изтрит?

[persuader]

От: Разни въпроси към WEB-аджиите...

Гарантират това че примерно от потребител на клиент 1 с ип 1.1.1.1 всички заявки ще отиват към един сървър но друг потребител на същия клиент примерно с регионален офис в Шумен с ип 2.2.2.2 не е ясно дали ще отидат към същия сървър. Поне аз разбирам от казаното досега че "клиент" е клиент който ти плаща за услугата а той може да има n на брой потребители от различни места (ip-та)

[sparkybg]

От: Разни въпроси към WEB-аджиите...

Гарантират това че примерно от потребител на клиент 1 с ип 1.1.1.1 всички заявки ще отиват към един сървър

Именно де, затова и мисля че хеш по домейн би направил същото по отношение на домейна, тоест всички от firma1.sparky.com ще ходят на един сървър, всички от firma2.sparky.com пак на един (същия или друг), и т.н. Лоад балансъра слуша "sparky.com", със всичките му поддомейни.