Изпечатай

[malone]

Blue, човека не казва, че има нещо против компанията да е българска, а да е такава, да е компания отвсякъде, все пак не бива да се излагаме пред "чехкинчетата".
Не съм трол, но в момента те размазва с практически познания и теоритична подготовка, а ти му говориш празни приказки за връзки, покани, позиции и т. н.
Аз лично не съм против инициативността и българщината в добрия смисъл, но все пак трябва да се преценява лъжицата, съобразно големината на устата, не мислиш ли?

[gat3way]

Весо, съгласен съм с голяма част от твоята лекция и затова съм склонен да не се заяждам, честно '>

Има само един спорен момент, не че се заяждам де. ама как да се изразя...мисля че не е особено изяснен.

По-долният цитат имам предвид '>

Цитат

Това са две или повече машини (възли), които се виждат като една навън. Така, ако някой от възлите отпадне поради технически проблеми, другите поемат натоварването. За целта вътре в автономната система на кореновия сървър се използват динамични протоколи за маршрутизация, които да са "link state" или да се обвързани с работособността на процеса на DNS демона (щом процеса на демона спред да общува със сокета, се спира анонсирането на възела - ако всички възли са неналични, се спира BGP анонса). Ако се изпълнят тези условия, то услугата е на практика непрекъсваема поради локални технически проблеми. Подобна тестова структура беше градена в мрежата на СУ "Климент Охридски" с учебна цел.

Интересна идея за load-balancing на HA услуга. Предполагам имплементацията на link-state динамичния рутинг протокол, нека бъде OSPF, работи доста независимо от named демона, т.е падне ли по някаква причина DNS услугата, заявки идващи отвън ще продължават да бъдат прерутирани до fail-налия node, мм? Ок, да речем че някой напише някакъв скрипт и при падане на named това се отразява и на рутинга (локалната имплементация на динамичният рутинг протокол на всеки node е просто още един потенциален point of failure, но както и да е). Това поставя още няколко проблема, именно:

1) Как zone информацията ще бъде обща за всички машини зад loadbalancer-a във всеки един момент, т.е изисква се някаква консистентност на данните на всички машини. Да речем че проблема се решава с някакъв shared storage и подходящата файлова система (и определено не чрез NFS, поради ред причини).

2) Понятието "сокет" не е правилно използвано в контекста. При умиране на един процес, умират всички сокети асоцирани с него. Да не говорим че няма механизъм по който един процес да разбере друг процес "комуникира" ли през сокетите, които е създал. И това че bind създава един listening сокет не означава, че при всяка нова заявка отвън, accept() не създава по един нов сокет, как мислиш да наглеждаш по всеки един сокет какво минавало (да не говорим и че това са UDP sockets - SOCK_DGRAM - при което "състоянието" им е малко спорна материя)

3) Да речем ъпдейтваш една зона динамично, защото не е практично да променяш zone информацията по сървърите върху техния, както уточнихме, споределен storage, та после да ги рестартираш всичките за да захапят. Стигаме до още един забавен момент. Балансъра ще те реферира dynamic update заявката към един от сървърите и ще го ъпдейт-неш. Обаче това ще си важи за него, не и за останалите. С другите сървъри обаче какво ще правиш? Дори да пуснеш много заявки за ъпдейтване на зоната, как можеш да си сигурен че си ги ъпдейтнал всичките nodes, така че да не се случи при една заявка единия да ти отговори едно, при втора заявка другият да ти отговори друго?

Предполагам си мислил по въпроса, така че ще ми е интересно до какво решение си стигнал '>

Между другото не знам защо ви е трябвало да си правите такива занимавки в СУ - балансирането чрез някакъв динамичен рутинг протокол е как да кажа...глуповата идея. Най-малкото нямаш никаква сесийност, което прави този метод абсолютно непригоден за балансиране на уеб приложения. Представи си че така балансираш 5 webapp сървъра за един интернет магазин. На всеки 2-3 request ще ходиш на сървър, който няма грам идея за твоята сесия, да речем за това с какъв потребител си се лог-нал и какво има в shopping cart-a ти. И това е само един частен случай, има още сума ти issues свързани с това.

Освен което е в пъти по-усложнено и натруфено решение в сравнение с LVS да речем. Просто не виждам никакъв смисъл да си утежняваш живота с динамично рутиране, когато нещата стават доста по-лесно '>

Сигурно е имало някаква причина да са упорствали да реализират такова нещо. Интересно ми е каква ли е била тя '>

[vesselinkolev]

Цитат (gat3way @ Дек. 21 2006,17:22)

Весо, съгласен съм с голяма част от твоята лекция и затова съм склонен да не се заяждам, честно '> Има само един спорен момент, не че се заяждам де. ама как да се изразя...мисля че не е особено изяснен. По-долният цитат имам предвид '> Цитат Това са две или повече машини (възли), които се виждат като една навън. Така, ако някой от възлите отпадне поради технически проблеми, другите поемат натоварването. За целта вътре в автономната система на кореновия сървър се използват динамични протоколи за маршрутизация, които да са "link state" или да се обвързани с работособността на процеса на DNS демона (щом процеса на демона спред да общува със сокета, се спира анонсирането на възела - ако всички възли са неналични, се спира BGP анонса). Ако се изпълнят тези условия, то услугата е на практика непрекъсваема поради локални технически проблеми. Подобна тестова структура беше градена в мрежата на СУ "Климент Охридски" с учебна цел. Интересна идея за load-balancing на HA услуга. Предполагам имплементацията на link-state динамичния рутинг протокол, нека бъде OSPF, работи доста независимо от named демона, т.е падне ли по някаква причина DNS услугата, заявки идващи отвън ще продължават да бъдат прерутирани до fail-налия node, мм? Ок, да речем че някой напише някакъв скрипт и при падане на named това се отразява и на рутинга (локалната имплементация на динамичният рутинг протокол на всеки node е просто още един потенциален point of failure, но както и да е). Това поставя още няколко проблема, именно: 1) Как zone информацията ще бъде обща за всички машини зад loadbalancer-a във всеки един момент, т.е изисква се някаква консистентност на данните на всички машини. Да речем че проблема се решава с някакъв shared storage и подходящата файлова система (и определено не чрез NFS, поради ред причини). 2) Понятието "сокет" не е правилно използвано в контекста. При умиране на един процес, умират всички сокети асоцирани с него. Да не говорим че няма механизъм по който един процес да разбере друг процес "комуникира" ли през сокетите, които е създал. И това че bind създава един listening сокет не означава, че при всяка нова заявка отвън, accept() не създава по един нов сокет, как мислиш да наглеждаш по всеки един сокет какво минавало (да не говорим и че това са UDP sockets - SOCK_DGRAM - при което "състоянието" им е малко спорна материя) 3) Да речем ъпдейтваш една зона динамично, защото не е практично да променяш zone информацията по сървърите върху техния, както уточнихме, споределен storage, та после да ги рестартираш всичките за да захапят. Стигаме до още един забавен момент. Балансъра ще те реферира dynamic update заявката към един от сървърите и ще го ъпдейт-неш. Обаче това ще си важи за него, не и за останалите. С другите сървъри обаче какво ще правиш? Дори да пуснеш много заявки за ъпдейтване на зоната, как можеш да си сигурен че си ги ъпдейтнал всичките nodes, така че да не се случи при една заявка единия да ти отговори едно, при втора заявка другият да ти отговори друго? Предполагам си мислил по въпроса, така че ще ми е интересно до какво решение си стигнал '> Между другото не знам защо ви е трябвало да си правите такива занимавки в СУ - балансирането чрез някакъв динамичен рутинг протокол е как да кажа...глуповата идея. Най-малкото нямаш никаква сесийност, което прави този метод абсолютно непригоден за балансиране на уеб приложения. Представи си че така балансираш 5 webapp сървъра за един интернет магазин. На всеки 2-3 request ще ходиш на сървър, който няма грам идея за твоята сесия, да речем за това с какъв потребител си се лог-нал и какво има в shopping cart-a ти. И това е само един частен случай, има още сума ти issues свързани с това. Освен което е в пъти по-усложнено и натруфено решение в сравнение с LVS да речем. Просто не виждам никакъв смисъл да си утежняваш живота с динамично рутиране, когато нещата стават доста по-лесно '> Сигурно е имало някаква причина да са упорствали да реализират такова нещо. Интересно ми е каква ли е била тя '>

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

[gat3way]

Мерси за изчерпателният отговор '>

А мога ли да намеря в Интернет резултата от този "експеримент" в СУ, много ми е интересен '>