Platforma HIT4B3 - Architektura
Oferta
W tradycyjnej (dotychczasowej) architekturze systemów serwerowych, serwer aplikacji składał się z jednego procesu i wielu wątków. Pojedynczy proces mógł być plikiem wykonywalnym lub procesem roboczym ISAPI, Apache czy ewentualnie usługą systemu Windows. We wszystkich tych przypadkach, wszystkie sesje znajdowały się w jednym procesie, a kilka wątków tego samego procesu było używanych do obsługi przychodzących żądań.
Architektura HyperServer zmienia powyższy model i wprowadza go w model wieloprocesowy, wielowątkowy. W tym nowym modelu uruchamianych jest kilka procesów roboczych, obsługujących tę samą aplikację internetową. Sesje są podzielone pomiędzy procesy robocze i w zależności od konfiguracji, może powstać / istnieć wiele procesów roboczych dla tej samej weblikacji. Procesy robocze są zarządzane i koordynowane przez inny proces, którym w rzeczywistości jest sam HyperServer.
HyperServer będzie głównym punktem wejścia dla wszystkich przychodzących żądań. HyperServer przyjmuje wszystkie żądania i rozdziela je pomiędzy procesami roboczymi. HyperServer jest również odpowiedzialny za tworzenie nowych procesów roboczych, gdy jest to potrzebne, i ponowne ich przetwarzanie, gdy tylko zostaną usunięte. Ponieważ sesje HIT4B3 są stanowe, kolejnym ważnym obowiązkiem HyperServera jest kierowanie przychodzących żądań sesji do właściwego procesu roboczego, który utworzył tę konkretną sesję. W terminologii HyperServer każdy proces roboczy nazywany jest węzłem (Node). Poniższy rys. przedstawia graficzną reprezentację powyższego opisu.
Zastosowana architektura HyperServer ma na celu drastyczną poprawę stabilności. HyperServer osiąga ten cel poprzez wdrożenie różnych mechanizmów: jest wewnętrzne równoważenie obciążenia i recykling węzłów. Równoważenie obciążenia rozdziela całkowite obciążenie serwera pomiędzy węzłami. Recykling węzłów skraca cykl życia węzłów poprzez ich recykling w oparciu o wcześniej zdefiniowane zasady. Recykling zapewnia, że węzły będą znajdować się w przestrzeni pamięci procesu tylko przez określony czas. W przeciwieństwie do klasycznego modelu, który utrzymuje proces serwera aplikacji w pamięci przez czas nieokreślony – rys. poniżej:
Głównym zadaniem HyperServera jest upewnienie się, że cały serwer aplikacji nie ulegnie awarii w wyniku defektu pamięci lub innego problemu w węźle (Node).
Architektura HyperServer jest podzielona na dwie zasadnicze części.
Pierwsza część to plik wykonywalny HyperServer, który jest punktem wejścia dla aplikacji internetowej (weblikacji). Będzie obsługiwać wszystkie żądania przychodzące od klientów.
Drugą częścią aplikacji HyperServer jest klaster węzłów, czyli weblikacji składowych HIT4B3 (np. EKAIZEN).
Kolejną ekscytującą, nową funkcją, którą HyperServer dodaje do HIT4B3, jest możliwość zdalnego wdrażania nowych wersji weblikacji bez konieczności zatrzymywania serwera. Chodzi o ciągłość pracy i dostępność serwera aplikacji w modelu 24/7/365.
W klasycznej, jednoprocesowej weblikacji, jej aktualizacja jest stosunkowo trudna. Po pierwsze, trzeba wyśledzić odpowiedni czas, w którym ruch jest mały i jest niewiele aktywnych sesji. Następnie trzeba wyłączyć serwer, co oznacza, że wszystkie aktywne sesje zostaną odrzucone i utracone. Prawdopodobnie wiąże się to z koniecznością wcześniejszego ostrzeżenia użytkowników weblikacji, aby się wylogowali i poczekali, aż aktualizacja się zakończy.
W przypadku HyperServera powyższy scenariusz staje się dużo prostszy i skuteczniejszy. Można zdalnie załadować (upload) nową wersję weblikacji, a resztą pracy zajmie się HyperServer. HyperServer będzie stopniowo, automatycznie aktualizował węzły (Nodes), a wszystkie nowe sesje użytkowników będą przekierowywane do węzłów (Nodes), na których działa nowa wersja weblikacji. Węzły z jej starszymi wersjami zostaną odrzucone i usunięte, gdy tylko wszystkie ich sesje zostaną wylogowane.
Dodając do tego warstwę dostępu do danych, realizowaną za pomocą serwera bazy danych w standardzie SQL (w naszej implementacji jest to Firebird Database Server), uzyskujemy pełny obraz architektury całego systemu HIT4B3, zainstalowanego w niniejszej lokalizacji. Pokazuje to w uproszczeniu rys. poniżej.
