Myślenie enterprise'owe, czyli jak to wszystko działa..

Gdy byłem początkującym administratorem sieci i moje doświadczenia zamykały się w serwerach hostingowo-shellowych, oraz routerach sieci osiedlowych, wszystko było proste. Wychowany na żłobku dla administratorów (swego czasu świetna kopalnia wiedzy), serwer był dla mnie takim sobie komputerem PC, z zainstalowanym linuxem, w ambitniejszej wersji wpiętym do UPSa..


..w korporacjach tak niestety nie ma, dlatego sam musiałem nauczyć się myśleć trochę inaczej.. redundantnie :) I tak właśnie redundancja - czyli nadmiarowość musiała stać się moim ulubionym słowem.

Nadmiarowość, powinna występować na wszystkich poziomach: sprzętu, systemu operacyjnego i usługi. W sytuacjach gdy chwilowy przestój aplikacji może kosztować tysiące, setki tysięcy, czy miliony, już na samym etapie projektowania należy dokładnie przemyśleć co zrobić by mieć jak najbezpieczniejsze i redundantne środowisko. Postaram się tu wypunktować i opisać podstawowe panujące zwyczaje.

Rozkładamy na czynniki pierwsze: Mamy więc dwie oddzielne lokalizacje, a w każdej z nich minimum dwa źródła zasilania, dwie drogi dojścia tego zasilania do serwerów, to samo tyczy się też sieci, czyli switchy i kabli sieciowych dochodzących do serwerów. Dokładając serwer (lub tworząc wirtualną maszynę) dokładamy ją oczywiście podwójnie, w każdej z lokalizacji. Tu pojawia się problem klastrowania. Mamy dwa rodzaje klastrów:

a) active-passive - usługa uruchomiona jest na jednym z nodów, drugi pozostaje nieaktywny. Przykładem takiego klastra może być usługa klastrowa RedHata RHCS. Nod (serwer) aktywny przypisuje sobie  adres ip usługi i zasób (jeśli jest konieczny). Gdy następuje awaria serwera, usługa jest przełączana na drugi Nod.

b) active-active - usługa jest uruchomiona na obu Nodach. Rozdzielaniem ruchu pomiędzy Nodami zajmuje się sprzętowy, bądz programowy load balancer, czyli urządzenie przed nodami, odpowiednio rozkładające ruch na oba nody (on także powinnien być redundatny)

W obu przypadkach klastry w celu synchronizacji danych mogą być wpięte do wspólnego zasobu dyskowego (macierzy), lub bazy danych. Tradycyjnie z zasada redundancji ta baza danych / zasób powinien być mirrorowany w zależności od wybranego rozwiązania w jednym z dwóch omawianych wyżej trybów, czyli np. tak:

lub tak:

(na wszystkich rysunkach gdzie wykorzystywany jest loadbalancer oczywiście też powinien on mieć swojego odpowiednika, na którego ruch też przełączy się w czasie awarii)

W mojej pracy, najczęściej dążymy do rozwiązań active-active, podstawową ich zaletą jest fakt, że nie marnujemy zasobów, a w razie większego obciążenia, zawsze możemy dołożyć kolejny serwer. Nie zawsze jednak jest to możliwe lub zalecane, wtedy zazwyczaj stosujemy rozwiązania active-passive.

Kiedy już pojmiemy, że nadmiarowość jest dobra. Wtedy czas na kolejne pojęcia czyli bezpieczeństwo i złożoność. W dobie wirtualizacji, złożoność nie jest problemem, a dołożenie kolejnego serwera to zwykle kilka kliknięć, zwłaszcza gdy mamy już predefiniowane środowiska. Jesli chodzi o bezpieczeństwo - to zawsze jest to priorytet, dlatego jeśli możemy zrobić coś dla jego poprawy - zwykle to robimy.

Prześledźmy więc jak może wyglądać nasza hipotetyczna aplikacja w pełnej okazałości - ilość nodów, w ramach przykładu ograniczymy do dwóch, w praktyce takie środowiska mogą się też nieźle rozrastać:

I tak patrząc od lewej strony, naszej hipotetycznej aplikacji mamy:

1. Dwa Load Balancery, jeden główny drugi zapasowy, na wypadek awarii pierwszego
2. Dwa serwery web - serwujące statyczny kontent naszej aplikacji, typu obrazki, statyczne treści http itp.
3. Dwa serwery aplikacji - generujące elementy dynamiczne będą to np. serwery java: tomcat, lub jboss.
(To zwykle poza bazami danych najmocniej obciążony element systemu, nic nie stoi w takim układzie na przeszkodzie aby dołożyć więcej nodów gdy dwa będą za malo wydajne)
4. Serwer bazodanowy - baza danych na potrzeby aplikacji, powinna być w zupełnie osobnym środowisku niż baza danych użytkowników (autoryzacji), wynika to z faktu, że baza autoryzacji jest zwykle kluczowym elementem każdego systemu. Często też wykorzystuje się wspólne serwery autoryzacji SSO, na potrzeby wielu różnych systemów.
5. Kolejne środowiska, zwykle stanowią je serwery autoryzacji (wyżej wymienione SSO), oraz serwery integracji, pozwalające się komunikować aplikacji z innymi aplikacjami po odpowiednich szynach danych.

Jak widać na rysunku, każda warstwa to zwykle osobna sieć, a przepuszczane pakiety między tymi sieciami ograniczają się jedynie do portów komunikacyjnych usługi i często są dodatkowo filtrowane.

Przykładowo właśnie takie środowisko może być potrzebne, aby wyświetlić wam jakąś
średnio zaawansowaną aplikację webową..

W gwoli podsumowania: wszystkich wtajemniczonych przepraszam za banalność opisanych tutaj przypadków, które w gruncie rzeczy są oczywiście tylko przykładowe i mają za zadanie jedynie pokazać jak to wszystko może działać w firmach gdzie serwer to nie jeden wiekszy pecet polozony gdzieś pod biurkiem :) Tym którzy są obecnie na tym etapie mam nadzieje, że pomogłem wyobrazić sobie jak może to wyglądać w wiekszych firmach.. Pamiętam, że gdy zaczynałem do takich aplikować, często pytano mnie, jak wyobrażam sobie ich środowiska, warto więc uświadomić sobie, ze firmowe środowiska są zwykle dość rozbudowane i mogą (choć nie muszą) przypominać opisane wyżej przykłady.

W razie jakichkolwiek pytań czy sugestii zapraszam do komentowania, na wszystkie pytania które ogarnę, postaram się odpowiedzieć.