Wysokodostępna i wydajna architektura dla LAMP – tutorial (cz. 3.)

Serwery aplikacyjne – Apache, LightHTTPd, IIS, Nginx, NodeJS

Istotną częścią naszej układanki są serwery aplikacyjne, na których osadzone będą strony WWW. Ponieważ nie miałem z góry określonej technologii wykonania aplikacji WWW, postanowiłem podejść do tematu bardziej ogólnie i sprawdzić różne serwery HTTP dostępne na rynku oraz możliwość ich współpracy z haproxy.

1. Podział  zadań na konkretne serwery

Postanowiłem, że sprawdzę serwery, które umożliwiają serwowanie stron napisanych w językach / frameworkach takich jak: HTML, PHP, Django, JS, .NET.

Większość z Was na pewno spotkało się z tymi nazwami: Apache, Nginx, IIS oraz z trochę mniej popularnymi: LightHTTPd oraz NodeJS. Przetestowanie ich pod kątem działania z haproxy pozwoli mi na stwierdzenie, czy aplikacje napisane w dowolnej technologii będą działały w omawianym środowisku.

Założyłem, że aplikacje napisane w PHP, Django będą serwowane przez Apache, pliki statyczne oraz HTML przez Nginxa lub LightHTTPd, aplikacje webowe napisane w ASP.NET zostaną uruchomione na serwerach IIS, natomiast strony w technologii JS będą serwowane przez NodeJS.

2.   Serwery HTTP i ich możliwości

• Apache – jest najbardziej znanym i najczęściej stosowanym serwerem HTTP w Internecie. Posiada bardzo dużo modułów, działa stabilnie i pozwala na bardzo skomplikowane konfiguracje. Nadaje się idealnie do serwowania stron napisanych w PHP (niektóre strony nie działają dobrze z php jako fastcgi i wtedy chyba najlepszym rozwiązaniem jest właśnie użycie Apache) oraz Django, RoR itd.
• Nginx – bardzo szybki, wymagający o wiele mniejszych zasobów sprzętowych niż Apache, pozwala na obsługę PHP w trybie fastcgi, głównie stosowany jest do serwowania kontentu statycznego.
• LightHTTPd – bardzo lekki, szybki serwer HTTP, obsługujący PHP w trybie fastcgi oraz języki takie jak: Python, Perl, RoR, Lua. Obsługuje bardzo dużą liczbę jednoczesnych połączeń z jednym serwerem (około 10 000). Zdecydowałem się na użycie go jako zamiennika dla Nginxa.
• IIS – jest zbiorem usług internetowych dla systemów z rodziny MS Windows pełniącym funkcje serwera FTP, HTTP, HTTPS, NNTP, SMTP. IIS HTTP/S. Stosowany jest głównie do serwowania storn napisanych w technologii ASP.NET i taką funkcję będzie pełnił w opisywanej architekturze.
• Node.js – to środowisko programistyczne zaprojektowane do tworzenia wysoce skalowalnych aplikacji internetowych, szczególnie serwerów HTTP napisanych w języku JavaScript. Node.js umożliwia tworzenie aplikacji sterowanych zdarzeniami wykorzystującymi asynchroniczny system wejścia-wyjścia.

 3. Konfiguracja serwerów aplikacyjnych

Postanowiłem nie opisywać tutaj konfiguracji serwerów HTTP, bo nie o to chodzi w całym doświadczeniu. Ponadto zastosowane przeze mnie rozszerzenia, dodatki mogą być niepotrzebne w przypadku zastosowania innej aplikacji WWW. Chciałbym zwrócić uwagę na kilka szczegółów, które mogą mieć wpływ na szybkość działania samych serwerów oraz po części na bezpieczeństwo.

Jeżeli planujemy współdzielić źródła stron WWW z jednego miejsca pomiędzy serwery takie jak np.: Apache i Nginx, pamiętajmy o zablokowaniu dostępu do takich plików jak: .htaccess (serwer Nginx tych plików nie obsługuje). Podobnie sprawa wygląda z plikami i katalogami GIT, SVN itp. – mogą one zdradzić informacje wrażliwe dla napastnika (swoją drogą polecam też sekurakowy tekst o kilku prostych sposobach zabezpieczania aplikacji webowych + tag: websecurity).

Pragnę również zwrócić uwagę na to, że skonfigurowanie w podobny sposób wszystkich serwerów z jednej rodziny pozwoli nam na łatwiejsze zarządzanie całą infrastrukturą. Do zarządzania serwerami polecam użycie takich narzędzi jak Puppet. Do monitoringu świetnie sprawdzają się Nagios, Munin, Zabbix, które pozwolą na późniejsze dostrojenie parametrów serwerów.

4. NFS, SMB – współdzielenie źródeł aplikacji

Skoro mamy już zainstalowane i skonfigurowane całe środowisko do serwowania strony lub stron WWW,przyszedł czas, aby zastanowić się, w jaki sposób będziemy dystrybuować kod źródłowy na poszczególne serwery. Przyszły mi do głowy dwa sposoby:

• wspólny zasób dla wszystkich serwerów,
• przechowywanie źródeł lokalnie na każdym serwerze.

Pierwsze podejście jest dość ciekawe i kuszące, ponieważ ułatwia zarządzanie źródłami, czyli: wgrywanie nowych stron, aktualizowanie już działających, oszczędność przestrzeni dyskowej. Wadami, jakie zauważyłem, będzie dość duży problem w przypadku włamania na jeden z serwerów, ponieważ automatycznie wszystkie serwery zaczynają serwować zainfekowaną stronę. Kolejnym utrudnieniem będzie brak możliwości wgrania nowej wersji aplikacji na jeden z serwerów (lub zmiana konfiguracji samego serwera), wyłączenie ruchu klientów do niego i finalne przetestowanie w środowisku produkcyjnym, co może okazać się w niektórych przypadkach bardzo cenną zaletą.

Drugi z proponowanych sposobów do zarządzania źródłami aplikacji wydaje się o wiele lepszy niż wspólne źródła dla wszystkich serwerów, ale co w przypadku aplikacji z dużą liczbą np.: plików multimedialnych. Waga źródeł może dochodzić wtedy czasami nawet do wartości w okolicy kilkuset gigabajtów, duplikacja takiej ilości danych pomiędzy serwerami nie jest optymalnym rozwiązaniem.

5. Testowanie poprawnej obsługi przez haproxy

Gdy całe środowisko już działa, przyszedł czas na testy. Znalazłem proste sposoby, aby sprawdzić skuteczność działania tak zainstalowanego środowiska. Narzędzia, których użyłem do realizacji tego celu, to: FireBug oraz CookiEditor, dodatki dostępne dla przeglądarki Firefox. Przed przystąpieniem do testowania należy pamiętać o umieszczeniu plików check.txt w głównym katalogu strony – to z ich pomocą haproxy będzie badał, czy serwer działa poprawnie.

1. Pierwszy test polegał na wyłączaniu backendów oraz sprawdzaniu ich statusów na stronie monitoringu wbudowanej w HAProxy, w plikach konfiguracyjnych, które załączone zostały do poprzedniej części, oraz zalogowaniu się na: root:toor. Oczywiście wystarczy zatrzymać serwer HTTP, a HAProxy powinno oznaczyć serwer jako nieaktywny oraz zaprzestać kierowania do niego ruchu klientów. Po ponownym włączeniu serwera HTTP HAProxy wykrywa poprawne działanie serwera i zaczyna ponownie wysyłać do niego klientów.
2. Drugi test to sprawdzenie w dodatku Firebug, z jakiego serwera są serwowane różne rodzaje plików. Jeżeli konfiguracja działa poprawnie, w nagłówkach zapytań o pliki PHP w polu Server powinna widnieć nazwa Apache, natomiast przy plikach takich jak .js,css,png,jpg itp. powinniśmy zauważyć, że w polu Server widnieje nazwa Nginx lub LightHTTPd. Jeżeli zaobserwowaliście działanie opisane powyżej, oznacza to, że HAProxy(ACL) zostało skonfigurowane poprawnie i ruch jest dzielony w taki sposób, jak to sobie założyliśmy, czyli skrypty PHP/Django itp. obsługuje Apache, a pliki statyczne Nginx/LightHTTPd.
3. Ostatnim testem było sprawdzenie, czy sesja jest powiązana z jednym serwerem i co się stanie w przypadku wyłączenia serwera, do którego jesteśmy przypisani. Zrealizować to można w łatwy sposób przez edycję plików cookie. Można tu wykorzystać dodatek do przeglądarki Firefox o nazwie Cookie Editor. W plikach konfiguracyjnych dołączonych do części poświęconej HAProxy możemy zauważyć, że HAProxy rozróżnia serwery przy pomocy wstrzykiwanego ciasteczka o parametrze: IDA: A01/A02/… dla serwerów aplikacyjnych oraz IDS:S01/S02/… Aby sprawdzić, czy jesteśmy powiązani z jednym serwerem, wystarczy odwiedzić witrynę kilka razy, przeklikać ją i monitorować, czy wartość ciasteczka się nie zmieniła. Jeżeli ciasteczko ma taką samą wartość przez cały czas, oznacza to, że HAProxy trzyma sesję użytkownika z dobranymi przy pierwszych odwiedzinach serwerami. Aby sprawdzić, co się stanie, gdy nagle serwer, na którym pracujemy, przejdzie w tryb offline, wystarczy zmienić wartość ciasteczka, np. z IDA:A01 na IDA:02, i obserwować, jak zareaguje nasza witryna.

Musze przyznać, że nie testowałem konfiguracji HAProxy w połączeniu z serwerem IIS, jednak w Internecie są dostępne artykuły na ten temat. Jeżeli ktoś stosuję taką konfigurację, proszę o opinię na temat jej działania w komentarzach.

– OiSiS [oisisk<sekurak>gmail.com]