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

[jmail]

Przepraszam, ze tego trupa odgrzebuję, ale miałbym coś do powiedzenia w tym temacie. Delikatnie.

Pierwsze i zasadnicze jestem przede wszystkim programistą takich technologii jak ColdFusion czy ASP.NET i tam loadbalancing nie jest problemem. Pythona nie dotykałem więc nie wiem. Ale wracając do brzegu (IMG:style_emoticons/default/winksmiley.jpg) Opiszę jak to wygląda na serwerze ColdFusion i jakie rozwiązanie zastosowalem.

ColdFusion:

1. Tworzony jest plik application.cfm i jeżeli taki istnieje jest dołaczany do każdego wywołania - dzięki temu zmienne aplikacyjne mogą być trzymane w jednym miejscu i mogą być WSPÓLNE dla wszystkich wywołań skryptu, przez dowolnego użytkownika, a to oznacza, że mamy ponad użytkownikowe rozwiązanie.
2. Istnieje coś takiego jak Client Scope - takie zmienne sesyjne dla klienta, dla przeglądarki. Jak to jest rozwiązane nie mam bladego pojęcia. Ważne że przeglądarka - ta sama instancja jest rozpoznawalna. Wewnątrz jest utrzymywany stan sesji i na wywołaniu z tego samego klienta stan jest odwtarzany.
3. Trzeba dodać, że jak się skorzysta ze zmiennych sesyjnych serwera Java (który jest pod spodem ColdFusion) to można clustrować dowoli serwery, a one sobie ze sobą poradzą

Napotkałem ten problem w jednym grubym projekcie intranetowym na serwerze PHP. Ponieważ za specjalnie nie potrafiłem sobie poradzić, więc podszedłem do tematu z innej strony. Pierwsze opisałem sobie czego mi w PHP brakuje z lepsiejszych (no cóż wygoda programowania CF czy .NET nie do porównania z PHP ^^) rozwiązań. Wypisalem sobie i się okazało, że wcale nie jest tak źle ^^. Cold Fusion daje możliwość składowania ciastek dla klienta po stronie serwera, a u klienta leży jedna zmienna z id ciastka (IMG:style_emoticons/default/biggrin.gif) i CF jakoś to robi, ze rozpoznaje że to ten user (klient) był.

Zakasałem rękawy i przeryłem stado dokumentacji do PHP i .NET i do tworzenia modułów do PHP. Po miesiącu prób i błędów udało mi się wyprodukować dll'kę która zwracała hello world! (IMG:style_emoticons/default/smile.gif) Ale to już był gotowy przepis na rozwiązanie moich problemów. Jak się udało wypluć hello world to da się cokolwiek zrobić. Wykonałem więc dll'kę, która odczytywała zmienne sesji z bazy danych i wrzucała je do skryptu PHP. Voile'a - między serwerowe rozwiązanie (IMG:style_emoticons/default/winksmiley.jpg) Co prawda potrzebna była taka maszyna, która to w bazie utrzyma, wysokiej dostępności i na pewno nie MyShitQL (sorry jeżeli kogoś urażam, ale to moja opinia). I znalazła się. Jakiś tam Echange stał, który tylko pocztę serwował z 16 procesorów oO. SQL Server Workgroup się znalazł i zaczeło gadać.

Pozostała jeszcze kwestia rozpoznawania klienta. W tym wypadku było to o tyle prostsze, że to był intranet, więc ciastko zapodałem i dowidienia.

Zapytacie na pewno jak z wydajnością. No cóż. Okazało się, że początek nie był radosny. Opóźnienie skryptu z jednej maszyny o jakieś 200%. Niestety, ale to mnie na chwilę znowu zatrzymało. Okazało się, że problemem stało się dochodzenie do zmiennych sesji $_SESSION przez dll. Znowu drobna przebudowa dll i extend replace na skrypty php ze zamianą $_SESSION na $_SESS (i przestawinie się w głowie na takie używanie zmiennych).

Kolejna sprawa, że stało się dla mnie niezbędne korzystanie ze zmiannych aplikacyjnych globalnych dla wszystkich użytkowników. TO akurat było prosto rozwiązać.

Napisałem skrypcik ładujący dane do tabeli $_APP (znowu naleciałości z coldka) i dodalem .htaccess z wpisem:

php_value auto_prepend_file "/sciezka/do/application.php"

oczywiscie, że próbowało dopisywać do każdego pliku. Proste rozwiązanie:

if(!$_APP)

i już. Mam zmienne aplikacyjne, mam załatwiony load balancing i mam sprawny intranet - kodu dll nie zapodam - kupę kapuchy za to położyli.

Na zakończenie tego wtrącenia trzeba dodać parę uwag:

1. Jak chcesz tak zrobić wybierz DOBRY serwer bazodanowy. Najlepiej nadają się do tego SQL Server w wersji Workgroup lub wyższej, ORACLE lub PostgreSQL.
2. NIGDY nie próbuj zmuszać serwery do komunikacji między sobą. Postaw maszynę, dającą sesje ale niech maszyny ze sobą nie współpracują w jakiś "zacieśniony" sposób - niepotrzebnie zużyjesz zasoby. PHP jest nieclustrowalny w sposób prosty i trzeba się z tym pogodzić dopóki programiści czegoś nie wysmażą.
3. Przy tworzeniu dll'ki dałem jej parę parametrów konfiguracyjnych ładowanych przez php.ini:
- nazwa clustra
- id serwera
- dane dostępowe do bazy danych z sesjami - dzięki nazwie clustre'a taka maszyna może obsługiwać ileś clustrów i ją samą też można clustrować - to już naprawdę na poziomie very high lodaed applications - ale wtedy weźmiecie coś lepszego nie PHP (IMG:style_emoticons/default/biggrin.gif)
4. Regularnie usuwaj sesje, które wygasły. Najlepiej jakiś sprytny trigerek on insert. ALbo Scheduled Task w Windows lub cron w UX

To porada dla naprawdę bardzo potrzebujących i muszących łączyć DUŻĄ ilość serwerów. Jest jednak sprytniejsze rozwiązanie. Może mniej wydajne, ale zawsze. Ustaw jedną maszynę z serwerem obsługującym dane aplikacyjne sesyjne i inne cuda. Jak nie chcecie IIS z .NET może być zwykły Debian z JBoss'em. Zmienne Javy bardzo dobrze się sprawdzają.

Przy odpaleniu dowolnego skryptu wywołujesz jeden jedyny plik z tamtego serwera (zmienne aplikacji nie będą się zmieniać zbyt często), który PRZEPISUJE Ci zmienne do php. eval i dowidienia (IMG:style_emoticons/default/winksmiley.jpg)


Tak teraz mi dwie aplikacje na po trzy serwery chodzą. Z tyłu stoi .NET, który stoi na windzinie XP i się sprawdza. A to najważniejsze. Sprawdza się na tyle, ze nie zamierzam znowu jakichś karkołomnych skoków robić - dodam, że aplikacje obciążane są średnio dziennie na jakieś 45k wywołań przez ok 3k użytkownków. Raporty finansowe, cuda wianki, wnisoki i inne duperele. Żeby jeden workflow przejść trzeba zrobić jakieś 10 wywołań.

To tak tytułem odgrzewania trupów (IMG:style_emoticons/default/smile.gif) trafiłem tu bo znowu robie high loaded i myślałem, że może coś się zmieniło w tym temacie. A że klient chce PHP na Linuxie.... .NET odpada, Javy nie wystawię, zostaje lip w C++. Trzeba się przeprosić...