Изпечатай

[wfw]

Здравейте,
въпроса ми е по-скоро теоретичен, отколкото практически, защото в момента правя нещо като малко проучване по въпроса. Тъй като нямам почти никакъв опит с балансиране на товара, бих се радвал да споделите мнения и опит.

Идеята е следната (теоретично): Имаме уеб сайт, който ползва PHP/MySQL, работи под някакъв Linux, примерно Debian.

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

1) Предполагам всички сървъри трябва да споделят обща мрежова файлова система. Някой да даде примери за такава файлова система? Предполагам, че е по-добре файловете да се намират на всеки нод, така че при спиране на един другите да продължат да работят? Как става синхронизирането при запис на някой от нодовете?

2) MySQL сървъра: според вас е по-добре на всеки нод да работи mysql server или не? ако mysql-a работи на всеки нод, как ще става репликацията? предполагам базата трябва да бъде на локална файлова система?

3) Нямам идея каква трябва да е топологията на мрежата. Предполагам 1 сървър, през който минава целия трафик и се разпределя трафика м/у нодовете на клъстера. Трябва ли нодовете да бъдат отделени в някаква вътрешна мрежа? Четох, че простия лоад балансинг на базата на BIND не е много удачен, защото при отпадане на нод, ДНС сървъра продължава да праща заявки към спрения нод + това ако някой доставчик кешира записа от ДНС сървъра, то няма да има никакъв балансинг за въпросния доставчик.

4) Ако има такъв сървър, който балансира трафика м/у отделните нодове, не е ли твърде опасно всичко да замре при евентуално спиране на главния съврър?

Всякакви аргументирани коментари са добре дошли. Интересува ме всичко по темата.

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

Какъв софтуер за балансиране на трафика? Има ли такива, които следят натоварването на нодовете?

Брой нодове? Оптимални конфигурации? С 1 дума всичко по темата.

Надявам се да се получи интересна дискусия и обмяна на опит.

[Acho]

Спомена думата КЛЪСТЕР. Сега, за ЕДИН сървър (една физическа машина) ли става дума, или за няколко, вързани в клъстер ? Или пък за един сървър, който ще прави лоад балансинга между доставчиците, и след него няколко други машини, работещи в клъстер (които ще носят http-то и mysql-а) ? А и не е казано какво ще е натоварването ма тоя http сървър, защото явно ще е е голямо щом и клъстер ще се прави (поне нещо ориентировъчно, то е ясно, че не го знаеш с точност отсега). И колко доставчика ще се балансират ? Все важни неща за заданието. Аз лично нямам опит с такава голяма клъстерна система, но за да се искат идеи за конфигурации, за софтуер, за файлови системи, все нещо трябва да е подадено като информация. Да има на какво да се стъпи и вече да се мисли, кое, как, колко и т.н. Предполагам ме разбираш колега, просто въпросите за такава система са много.

[wfw]

Почти съм сигурен, че не съм се изразил правилно. Трафика м/у моята мрежа и клиентите не е определящ, по-скоро ме интересува какви са вариантите за разпределяне на трафика м/у 2 и повече уеб сървъра и 2 и повече MySQL сървъра.

Най-общо казано натоварването на уеб сървъра е по-голямо от натоварването, с което може да се справи 1 физическа машина, аналогично за mysql.

Примерно, средно уеб приложенията използват 80-90% SELECT срещу 10-20% update. От тази гледна точка дали е по-добре да има 1 мастер mysql и 2 slave-a, от които да се теглят заявките или да има 2 мастер-а, без slave.

Примерно дали разпределението на трафика с BIND е толкова зле, че няма никакъв смисъл да се прави. Какъв хардуер и софтуер съществува за разпределяне на трафика м/у уеб сървърите.

Дали ако имаш само 2 машини е по-добре едната да е mysql сървър, а другата уеб сървър или двете да вършат 2те неща едновременно, като ще се жертва някаква производителност с цел при отпадане на едната машина, да може да се продължи работа  въпреки при много по-ниска скорост поради голямото натоварване.


edit: друго, което ми е интересно дали има някаква по-универсална схема, при която просто се добавят сървъри при необходимост, без голяма промяна на избраната от нас конфигурация.

[morbid_viper]

До голяма степен зависи от приложението. ако е някой голям и крив сайт (например за торрент), където стават свински големи таблици. В един случай можеш да минеш и без клъстър, а само с репликации на дадени таблици.
Относно уеб трафика ползваме едно наше решение:
* всяка уеб машина си има външно ip
* основната балансираща машина върти един много, много прост php скрипт, който решава към коя машина да препрати новата заявка (и с това ѝ се приключват задълженията)… и тя си върши работата наистина бързо. използваме memcache за да се държи сметка коя машина колко е натоварена (колко страници прави в секунда) и се препраща към най-малко натоварената.

Иначе веднага мога да ти кажа, че е драматично по-добре уеб и база да са на отделни машини. Да, повишава се рискът ако се срине едната – цялата услуга да падне, но пък производителността е много по-добра. все пак при базите най-тясното място е скоростта на дисковите масиви, докато при уеб от диска почти не се чете нищо (ОС кешира в паметта доста от нещата).

всъщност съм споделил моя опит (в малко по-общ план) ето тук:
http://www.openfestruse.org/downloads/openfest09/OpenFest_Ruse_Nov-2009.odp
както и на видео ето тук:
http://ofrousse.net/video09

[wfw]

Благодаря за коментара и линковете, но май първия има някаква драма с резолва:

Код:

whois openfestruse.org
Name Server:NS1.DREAMHOST.COM
Name Server:NS2.DREAMHOST.COM

ping openfestruse.org
ping: unknown host openfestruse.org

host openfestruse.org NS1.DREAMHOST.COM
openfestruse.org A record not found at NS1.DREAMHOST.COM, server failure

host openfestruse.org NS2.DREAMHOST.COM
openfestruse.org A record not found at NS2.DREAMHOST.COM, server failure

а междувременно, какво ви е мнението за happroxy?

[morbid_viper]

Тъй като не отговарям за сайта на OpenFest в Русе, а само бях лектор там, то и неразборията с този домейн ми е малко встрани…
Все пак презентацията може да се свали от http://viper.tkzs.org/misc/OpenFest_Ruse_Nov-2009.odp

Да ти кажа и едно време проучвах haproxy, но така и не стигнахме до внедряването му, защото си решихме проблемите по друг начин… все пак каквото и да прочетях – само положителни отзиви…

[lod]

тук съм подкарал да документирам нещо което съм правил и отговаря горе долу на твоите намерения:
http://myboot.lordofdeath.net/2013/02/part1-load-balancing-web-cluster-with.html
ако има въпроси питай, не е идеално но не успях да го довърша

[gat3way]

1) Предполагам всички сървъри трябва да споделят обща мрежова файлова система. Някой да даде примери за такава файлова система? Предполагам, че е по-добре файловете да се намират на всеки нод, така че при спиране на един другите да продължат да работят? Как става синхронизирането при запис на някой от нодовете?

В зависимост от нуждите дори NFS може да свърши работа. Споделеният storage върху FC или iSCSI и някаква клъстерна файлова система от сорта на GFS2 или OCFS е доста по-скъпо и по-сложно за съпортване решение, така че има доста фактори и трябва да си решиш какво искаш и на каква цена.

2) MySQL сървъра: според вас е по-добре на всеки нод да работи mysql server или не? ако mysql-a работи на всеки нод, как ще става репликацията? предполагам базата трябва да бъде на локална файлова система?

Може би е по-добре да въведеш един кеширащ слой (memcached) вместо да се занимаваш с това. Репликацията е грозна.

3) Нямам идея каква трябва да е топологията на мрежата. Предполагам 1 сървър, през който минава целия трафик и се разпределя трафика м/у нодовете на клъстера. Трябва ли нодовете да бъдат отделени в някаква вътрешна мрежа? Четох, че простия лоад балансинг на базата на BIND не е много удачен, защото при отпадане на нод, ДНС сървъра продължава да праща заявки към спрения нод + това ако някой доставчик кешира записа от ДНС сървъра, то няма да има никакъв балансинг за въпросния доставчик.

DNS-базираното балансиране или LVS може да не са много разумни решения предвид това че трябва да държиш сесиите към същия backend и следователно трябва малко по-интелигентен load-balancer, който е aware за layer7 особеностите (алтернативно комплексността се измества към бекендите и обикновено става по-грозно мазало). Пробвай за начало haproxy или apache работещ като reverse proxy с няколко бекенда (по спомени можеше да stick-ва сесии към бекенди, но с тези неща не съм се занимавал от години, така че не знам.

4) Ако има такъв сървър, който балансира трафика м/у отделните нодове, не е ли твърде опасно всичко да замре при евентуално спиране на главния съврър?

Решения има за всичко - преди много години примерно трафика на my.globul.bg се терминираше на единия от два cisco load-balancer-а, като единия беше активен, другия standby и се разбираха по HSRP протокола. Такова решение струва скъпо разбира се. Въпросът е ти какво точно искаш и какви са ти рамките. В зависимост от това, може да се мисли вече върху евентуално решение.