Duże aplikacje i load balancing, Czyli co i jak zrobic jak maszyna nie daje rady Opcje

[kwiateusz]

Temat założony na prośbę SHIPa oraz normanosa traktujący o rozkładaniu obciążenia na wiele maszyn

[djhors]

Witam Wszystkich.

Z braku czasu niezagladam tu za wiele bo nie mam nawet na to czasu ale trafiłem na ten temat. Pozwolcie że napisze wam jak wygląda sprawa teoretycznie ze strony 'korporacyjnej' tegoz problemu. - teoria

Powiedzmy że mamy swoja strone php/mysql i pliki. Podzielimy to oczywiście na:

1. Baza danych MySQL
2. Baza plików aplikacji (Core Aplication)
3. Pliki storage (Multimedia itp.)

Sytuacje jakie tu piszecie maja zastosowanie przy tzw. uzytkowaniu lokalnemu. Oczywiście sprawdza się tutaj Load Balancing. Prawda praktyczna jest taka że jesli liczymy uzytkowników w milionach SLB mozna wyrzucić do kosza ze względu że sam serwer SLB by tego nie wytrzymał. Analiza ruchu i obiażenia tez potrzebuje zasobów i czasu. Serwery Google, YouTube itp. stosuja własne techniki rozdziału swoich aplikacji mniej lub bardziej skuteczne. Napomkne jednak że cały czas mówimy o użytkowaniu lokalnym. Inny motyw jest gdy mamy kilka milionów uzytkowników w Europie i nastepne kilka w Azji Wschodniej. Choćbyśmy posiadali łącza kilku Giga bitowe to i tak wartośc transferowa spada i to powaznie do 20-10%. Po ostatnim zerwaniu lini na dnie morza śródziemnego miało swoje przykre konsekwencje dla wielu wznoszących się portali ogólnoświatowych lub kontynentalnych. A i interes w tym mają pewne korporacje... mniejsza z tym.

Przy uzytkowaniu lokalnym, sprawdza się dobrze SLB jednak jak już wspomniałem (np. w przypadku naszej-klasy) miało to później nie miłe konsekwencje dla użytkowników o czym rozpisywały się nawet gazety.

Na pierwszy rzut oka roziwazaniem staja się osobne serwer na bazę MYSQL - osobny na Core Aplication i osobny na Storage. Do parunastu tysięcy użytkowników lokalnych jest oki. Póxniej zaczynają się schody poniewaz jest to mało opłacalne przy próbie tworzenia mirrorów na każdy punkt z osobna. Dlatego tez najpraktyczniejszym rozwiązaniem jest tworznie całego mirrory jednego serwera ze wszystkimi punktami 1,2,3. WIelu twierdzi że ta metoda jest przestarzała zapoczatkowana przez mirrory serwerów użytkowanych przez dystrybutorów Linuxów itp. ale ma to pewne zalety. Otóz w ten sposób serwer bedzie sie najszybciej komunikował z własnymi punktami PHP <-> SQL. No to chyba zrozumiałe.

Prawda jest tak że nie poto sa od niedawna takie zawody jak 'Network Analist' żeby koles liczyl sobie bajty na ekranie. Wiąże się to z analizą np. rozkładu uzytkowników na pewne grupy. A najprostrza grupą podziałową jest obszar geograficzny.

W sytuacji gdy nasz serwer nie radzi sobie z ilościa uzytkowników wpada taki Analityk i tworzy nam raport gdzie mozna by umiejscowić nowy serwer lustrzany tak aby odciążyć ten co mamy a jednoczesnie objąć taka ilośc użytkowników żeby sam nie stał bezczynnie.

Dla początkujących tworzenie serwera lustrzanego może polegac na zasadzie Copy-Paste - napisania odpowiednich skryptów które będą automatytcznie monitorowały stan plików 'wzorcowych' i samej bazy i aktualizowały automatycznie serwery lustrane. Ze strony bazy danych i Storage dział to te·z wdruga stronę. Dobrze jest też aby taki wzorcowy serwer dobrze jakby był osobna jednostką serwerową (ale nie developerską - tzn nie miejscem gdzie piszemy nasza aplikacje). Dobrze by było aby nasz serwer lustrzany znajdował się w obrębie danego obszaru geograficznego aby połączenia były jak najkrótsze.

Przy zasięgu globalnym to jednak nie wypali. Powiedzmy że użytkownik X z Ameryki zarejestrował się na serwerze który tam się znajduje i użytkownik Y z Polski który będzie minutę póżniej szukał swojego przyjaciela z Ameryki zapewne się rozczaruje bo system aktualizacji będzie potrzebował trochę czasu aby zauktalizowac wszystkie serwery lustrzane (a konkretnie ten Polski). Wiele firm praktycznie olewa ta sprawe bo nie chca wydawać pieniędzy na nowych lub douczanie aktualnych programistów o wiedże z zakresu modelowania rozproszonego baz danyn a czesto początkujące firmy internetowe nie inwestuja w dobrych Senior Programmers - co jest zrozumiałe.

Więc cała sprawa zmierza tak na prawde do tego jak piszemy nasza aplikację. Poczatkujacy programisci a i nawet Ci z duzym stażem nie biora pod uwagę czegoś takiego jak zasięg aplikacji. To pozwala nam w pewien sposób zobaczyć pewna subtelna różnice między 10 letnim programistą freelance i w małej firmie. A programistą z tym samym stażem w większej firmie czy korporacji - nie bez powodu w CV czytaja informacje o poprzednich pracach i wypytuja o nie. Dzisiaj dobre referencje z 'Dobrej' firmy to prawdziwy skarb. Dlatego tez taka rada poza tematem - nie ma zadnego sensu obsypywaniem potencjalnego pracodawcy workiem portfolio z tysiaca i jednej strony dla sklepó, gier i innych temu podobnych - no chyba że startujecie na Designera.

Ale wracając do tematu, do naszego przypadku zastosowanie baz rosproszonych jest naszym roziazaniem. Taki moze ciągły przykład. Kiedy uzytkownik X z Ameryki się u nas zarejestruje - informacje na jego temat zostana zapisane na naszym serwerze lokalnym i wyśle prosty index do innych serwerów na całym świecie (często przez serwery posredniczace np. na dany kontynent). Metoda ta pozwala w 'dość' szybki sposób zaktualizować dane na całym świecie. A 'index. jest poprosty prosta tabelą w której wpisujemy id usera i adres serwera na którym sa przechowywane pełne dane na temat uzytkownika X. Więc kiedy nasz Uzytkownik Y z Polski będzie szukał swojego przyjaciela powinien go w bardzo szybkiem czasie tam odnaleść poniewaz jego lokalny serwer lustrzany (no nie dokońca juz lustrany) połaczy się i pobierze dane z zserwera w Ameryce. Myśle że jest to dość zrozumiałe. Oczywiście w praktyce te serwery nie sa teraz juz takie 'lustrzane'. Obok Core Aplication dodawane jest Local Aplication czy cos w tym stylu powodujace że nasza strona dla Polski będzie nieco inaczej wygladał niz dla Ameryki. Zapewne to wam tłumaczy dlaczego chiny moga sobie sprawnie blokowa tresci dla swoich 'podwładnych' - poprostu filtruja tylko serwry lokalne np YouTube.

A teraz taka praktyka w praktyce.

Powiedzmy że mamy super portal i serwery poroztsawiane na całym świecie. SLB jest stosowane w obszarze powiedzmy jednego kraju lub stany/województwa. SPecjalne serwery krajowe/wojewodzkie/stanowe posredniczą w statycznym rozdysponowaniu obciążenia. Natomiast między krajami nie ma żadnego rozdysponowywania poprostu w ramach potrzeby stawia się serwery w danym regionie poniewaz nie ma to sensu jesli na dany kraj założymy sobie domenę z krajowa końcówką (pl, de, my).

Z pingujcie sobie serwer google.pl i google.my dla prównania.

Kazdy serwer jest jednocześnie takim 'lustrzanym' z dodatkami (s001.mojastrona.pl, s002.mojastrona.pl s001.mojastrona.de s002.mojastrona.de etc.)

Zapewne gdyby nagle cały świat się rzucił i w przegladarkach wpisali google.pl to pewnie mieliby niezły zator. - choć mozliwe ze się przed tym zabezpieczyli - powinni.

Oczywiście żaden wielki portal nie bawi się robienie typowych luster serwerów. Pliki Storage tak jak dane sa poprostu indexowane w bazie danych. Dlatego tez w iększej firmie programista stosujacy metode listowania folderu dla plików dostał by po uszach.

Oczywiście jest to tylko takie liźnięcie tematu bo rozbija się to jeszcze o wiele kwesti lokalnych i samego transferowania danych poprzez dns'y, routowanie połączeń globalnych etc.
Trochę sie rozpisałem ale mam nadzieję że jakoś wam przedstawiłem zagadnienie z nieco innej strony.


Pozdrawiam

Ten post edytował djhors 29.12.2008, 11:25:44