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

Wstęp

Każdemu administratorowi serwerów stron WWW życzę, aby kiedyś Apache, MySQL i PHP postawione na jednej maszynie mimo przeprowadzanych optymalizacji usług przestały się wyrabiać. I nie są to życzenia złośliwe, ponieważ, jeżeli się spełnią, będzie to oznaczało, że strona, którą administruje, ma bardzo dużą liczbę odwiedzin. Biznes w firmie będzie zadowolony, a administrator będzie miał przed sobą nowe wyzwania związane z  architekturą odpowiadającą na nową rzeczywistość.

Pierwsza myśl, która zapewne przyjdzie mu do głowy, to rozdzielenie serwerów aplikacyjnych od bazodanowych, wymiana mod_php na mod_fastcgi, wymiana serwera Apache na coś szybszego… Gdy i to zacznie zawodzić, trzeba będzie sobie zadać pytanie, jak rozwiązać i ten problem. Jak przygotować się na kolejne zwiększenie ruchu w przyszłości.

Ostatnio poproszono mnie o rozpoznanie tego tematu i zaproponowanie jakiegoś rozwiązania.

Założenia projektowe

Głównymi założeniami projektu były:

• wysoka wydajność,
• wysoka dostępność,
• skalowalność,
• wykorzystanie różnych technologii do tworzenia stron WWW,
• możliwość podłączania serwerów o różnej konfiguracji sprzętowej,
• optymalne wykorzystanie posiadanego sprzętu.

Ponieważ technologia wykonania serwisu nie jest jeszcze bliżej znana (jest to przygotowanie do start-upu), poza kilkoma przyjętymi założeniami (wymienionymi powyżej), poszukiwana architektura powinna dawać możliwość podłączania serwerów z różnymi rodzajami aplikacji napisanych w różnych technologiach. Kolejnym założeniem była możliwość zmieniania dociążenia na poszczególnych serwerach. Załóżmy, że aplikacje są mniej lub bardziej „sezonowe”, a godziny/dni/miesiące maksymalnych odwiedzin per aplikacja nie nakładają się na siebie – idealnym rozwiązaniem byłoby dociążenie „śpiących” serwerów, a nie dokładanie nowego sprzętu, który przez jakiś czas zużywa tylko prąd, a wykorzystanie CPU i RAM przez niego oscyluje w okolicach zera.

Po zapoznaniu się z kilkoma artykułami na temat budowy środowisk HA (High Availability – wysoka dostępność), HP (Hight Preformance – wysoka wydajność) i S (Scalable – skalowalność), postanowiłem spróbować swoich sił w tej dziedzinie. Rozwiązanie, które chcę zaprezentować, jest w fazie PoC (Proof of Concept) i testuję je na swoim domowym środowisku. Wykorzystałem w nim następujące oprogramowanie i sprzęt:

• Foxconn Nettop nT-A3500 + 4GB RAM + 350GB SATA II,
• ESXi v 5.1 (najnowsza wersja nie posiada sterowników do karty sieciowej w nT-A3500),
• Debian GNU/Linux – 7.1.

Całość architektury postanowiłem podzielić na pięć warstw:

1. loadbalancery,
2. serwery aplikacyjne,
3. serwery bazodanowe,
4. serwery plików statycznych(CDN),
5. serwery plików(NFS).

Dodatkową warstwą, która warto wprowadzić, jest cache zarówno aplikacji, jak i zapytań do bazy danych. Niestety nie zostało to uwzględnione na tym etapie projektu i zostanie dodane później, myślę tu o wykorzystaniu takich narzędzi jak: Solr, Sphinx, Varnish, Memcached.

1.   Dlaczego warto wdrożyć takie rozwiązanie

Jeżeli zastanawiacie się, dlaczego warto wdrożyć taką architekturę u siebie, odpowiadam oto jej zalety. Według mnie zyskujemy:

• brak Single Point of Failure,
• obsługę dużej liczby klientów,
• skalowalność,
• optymalne wykorzystanie sprzętu,
• możliwość dołączania kolejnych nodów bez przerw w działaniu strony,
• regulację natężenia ruchu na konkretne nody,
• budowę środowiska zróżnicowanego sprzętowo,
• automatyczne odłączanie uszkodzonych nodów,
• możliwość wyłączenia konkretnych serwerów w celu przeprowadzenia konserwacji/wymiany/naprawy bez przerwy w działaniu aplikacji WWW,
• optymalne wykorzystanie różnego rodzaju aplikacji, np.: Apache+PHP, Nginx+static.

2. Schemat architektury

Poniższy schemat przedstawia połączenie serwerów, rozmieszczenie ich w sieci, np. DMZ, oraz role, jakie pełnią pojedyncze bloki w całym rozwiązaniu. Na rysunku widać, że każdy rodzaj serwera występuje podwójnie za wyjątkiem firewalla. Nie oznacza to, że nie można dodać dowolnej liczby serwerów do każdego z bloków. Opisywane rozwiązanie będzie działało do momentu, gdy z każdego bloku pozostanie co najmniej jedna maszyna.

3.   Wykorzystywane narzędzia

Cały projekt opiera się na następującym oprogramowaniu:

• Firewall – Shorewall,
• Linux Virtual Server – Keepalived,
• LoadBalancer – HAProxy,
• Serwery aplikacyjne – Apache,
• Serwery DB – MySQL,
• Serwery kontentu statycznego (CDN) – Nginx,
• Serwery plików – NFS,
• Replikacja urządzeń blokowych – DRDB (Distributed Replicated Block Device).

Oczywiście wybrane przeze mnie oprogramowanie nie jest jednie słusznym rozwiązaniem, można jako serwer aplikacyjny wykorzystać dowolny serwer WWW, np.: IIS, LightHTTPd itp. Ciekawą rzeczą jest to, że możemy również mieszać te serwery, a nasze proxy (HAProxy) i tak sobie z takim środowiskiem poradzi. Kolejną interesującą rzeczą jest to, że całe środowisko może obsługiwać aplikacje WWW napisane w różnych technologiach, a odpowiednie ustawienie ACL przekaże ruch w odpowiednie miejsce, ale o tym w kolejnej części artykułu.

Shorewall – proste zarządzanie firewallem w Linuksie

Oprogramowanie ESXi nie posiada możliwości konfiguracji i zarządzania wewnętrzną siecią LAN, a ponieważ zależało mi na zrobieniu czegoś w rodzaju blackbox, zmuszony zostałem do zainstalowania systemu, który będzie pełnił rolę firewalla i routera. Postanowiłem zrobić to na dystrybucji Debian GNU/Linux oraz przy pomocy pakietu shorewall.

1.   Co to jest shorewall?

Shorewall jest to narzędzie, które pozwala w prosty, przejrzysty i łatwy do utrzymania sposób zarządzać zaporą sieciową opartą na wbudowanym w jądro systemu Linuksie Netfilter.

2.   Dlaczego warto stosować shorewalla?

Wybrałem shorewalla, ponieważ przypominają mi się czasy sprzed kilkunastu lat, gdy konfigurowałem swój pierwszy router/firewall oparty na dystrybucji Slackware. Potrzebowałem wtedy prostego firewalla z opcją NAT, niestety nawet tak prosty firewall wymagał napisania skryptu zawierającego kilkadziesiąt lub nawet kilkaset linii kodu. Oczywiście nie mam nic przeciwko takiemu rozwiązaniu, ale pomyślcie sobie, jak będzie wyglądał taki skrypt w przypadku posiadania dużej liczby komputerów/serwerów w sieci, dodatkowo strefy DMZ, przekierowania portów itp. Skrypt bardzo szybko może urosnąć do kilkuset linii kodu… I tutaj zaczynają się kłopoty. Nie zawsze chce nam się skomentować wszystkie części kodu, nie zawsze będziemy pamiętali, co mieliśmy na myśli, pisząc jakąś funkcję, a w najlepszym wypadku wracając po dłuższym czasie do pracy nad skryptem, musimy go „rozgryźć” od początku.

I tu świetnie sprawdza się taki pakiet jak shorewall. Jest to zestaw skryptów z plikami konfiguracyjnymi, który w łatwy sposób pozwala na konfigurację nawet najbardziej skomplikowanej zapory sieciowej.

3. Opis możliwości

Shorewall nie jest demonem działającym w tle, jest zestawem skryptów, które odczytują pliki konfiguracyjne, tłumaczą je na reguły iptables, aktywują w systemie, a następnie kończą swoją pracę. Shorewall posiada swój skrypt w katalogu init.d i może być ładowany podczas startu systemu, dodatkowo posiada funkcję „check”, która sprawdza integralność plików konfiguracyjnych. Polecam uruchomienie shorewalla z tą opcją przed restartem/uruchomieniem firewalla. Pakiet ten świetnie nadaje się do budowy zapory zarówno w małych i prostych sieciach, jak i tych dużych bardziej złożonych.

4. Przykładowa konfiguracja na potrzeby projektu

W swoim projekcie nie potrzebuję skomplikowanej konfiguracji zapory sieciowej. Koncentruję się tylko na strefie DMZ, czyli potrzebny mi jest prosty NAT i przekierowanie portów. Dzięki pakietowi shorewall konfiguracja jest bardzo szybka i prosta.

Po instalacji pakietu shorewall (dystrybucja Debian GNU/Linux) otrzymujemy skrypty oraz katalog z plikami konfiguracyjnymi w lokalizacji: /etc/shorewall. Postanowiłem załączyć konfigurację routera jako archiwum tar.gz. Głównym plikiem, na którym powinniśmy się skoncentrować, jest /etc/shorewall/rules – to tutaj konfigurujemy zasady działania naszej zapory.  Oczywiście nie zalecam używania takiej konfiguracji jako zapory na serwerze produkcyjnym podłączonym do Internetu, konfiguracja pozwala na dostęp z każdej „strony” do SSH, HTTP, HTTPS. Aby włączyć automatyczne ładowania zdefiniowanych przez nas zasad iptables przy starcie systemu należy jeszcze zmienić wartość parametru: startup z „0” na „1” w pliku: /etc/default/shorewall. Po każdej edycji plików shorewalla proponuję uruchomienie polecenia: shorewall check z konsoli w celu weryfikacji integralności plików konfiguracyjnych.

Podsumowanie

Jeżeli ktoś nie używał pakietu shorewall, a zmuszony jest do konfiguracji iptables, polecam wypróbowanie tego pakietu. Jak już wcześniej wspomniałem, jest bardzo prosty w zarządzaniu, nie wymaga pisania długich i skomplikowanych reguł dla iptables. Utrzymywanie konfiguracji, dodawanie nowych reguł, dodawanie nowych stref sieci itd. jest bardzo proste i można to wykonać naprawdę szybko. Chociaż nie posiada ani „ładnego” interfejsu WWW, ani nakładki w postaci GUI, jest naprawdę bardzo prosty do opanowania, a po krótkim czasie wdrożenia praca z nim to prawdziwa przyjemność.

Odsyłam oczywiście do strony internetowej projektu, która znajduje się tutaj. Zaprezentowano tam bardziej zaawansowane możliwości tego pakietu. Są naprawdę imponujące.

 – OiSiS [oisisk<sekurak>gmail.com]