Czas łączyć serwery w klastry

-- wtorek, 01 marzec 2005 15:18

Systemy produkcyjne były kiedyś oparte na pojedynczych komputerach, takich jak: PDP-11, VAX, AS-400 oraz Data General. Były to „małe-żelazne” systemy, mali bracia „wielkich-żelaznych” systemów pochodzących od IBM, Burroughs oraz Univac. Obecnie większość głównych aplikacji produkcyjnych jest wykonywana na pojedynczym procesorze Intela czy AMD i posługuje się systemem operacyjnym Microsoft Windows 2000; pomimo krótkiej infiltracji środowiska przez UNIX, jaka miała miejsce na początku lat 90-tych. Równocześnie z momentem, w którym aplikacje produkcyjne zaczęły się opierać na architekturach jednoserwerowych, nastąpiła wielka zmiana w aplikacjach firmowych. „Wielkie-żelazne” systemy zostały zastąpione klastrami serwerowymi (clustered servers – serwery „połączone w nadmiarowe zbitki”), pochodzącymi od dostawców, takich jak: IBM, Sun oraz HP. Termin „clustering” jest definiowany dosyć szeroko, zależnie od tego jak konfiguracja sprzętu różni się odpowiednio do zastosowanej sieci i celu systemu, ale większość działa ta tej samej zasadzie. Architektura klastrowych serwerów to kilka serwerów pracujących w jednej sieci, z których wszystkie obsługują te same aplikacje, współużytkują bazę danych i działają jako jeden, zjednoczony system obliczeniowy. Systemy klastrowe tworzą drugą i trzecią warstwę w  w trójwarstwowym modelu systemu.

Skalowalność odpowiednio do potrzeb

Pierwszą warstwę (w takim trójwarstwowym modelu) stanowi interfejs użytkownika aplikacji. Interfejs użytkownika zgłasza zapotrzebowanie na wykonanie usługi do dyspozytora usług. Dyspozytor, którym zazwyczaj jest serwer bądź router, przekierowuje następnie to zapotrzebowanie do jednego z fizycznych serwerów pracujących w klastrze (grupie/zbitce). Jeśli obciążenie, tj. wykorzystanie aplikacji, zwiększa się lub zmniejsza, można łatwo dodać lub  zwolnić serwery z klastra, odpowiednio do zmian obciążenia systemu. Architektury klastrowych serwerów zapewniają wystarczający poziom skalowalności, a inteligentni dyspozytorzy pozwalają na modernizacje poprzez wysyłanie zapotrzebowań na wykonanie pracy do serwerów, wykonujących odpowiednią wersję aplikacji. Architektury klastrów serwerów są stosowane w większości aplikacji firmowych, łącznie z ERP, zarządzaniem współpracą z klientem (CRM), łańcuchem zaopatrzenia (SCM), pocztą elektroniczną (e-mailem) oraz bazami danych. Jednakże architektury klastrów serwerów wymagają, by aplikacja była zaprojektowania odpowiednio do takiego sposobu jej uruchamiania i wykorzystywania.

Podczas gdy aplikacje biurowe przeszły na clustering, dostawcy oprogramowania do obsługi procesów produkcyjnych – nie. Niewiele aplikacji „produkcyjnych” projektuje się do clusteringu. Większość aplikacji produkcyjnych w dalszym ciągu stosuje podejście „małe– żelazne”*, a jeśli system pracuje zbyt wolno, użytkownik musi kupić większy i szybszy sprzęt. Większość aplikacji produkcyjnych to systemy dwuwarstwowe, których z natury uruchomić na klastrze serwerów po prostu się nie da. Systemy dwuwarstwowe, nazywane czasami systemami „thick client – gruby klient”, zazwyczaj mają wewnętrzną bazę danych na serwerze oraz aplikację czołową interfejsu użytkownika, która musi być zainstalowana na komputerze każdego użytkownika systemu.

„Cienki” nie oznacza „pracujący w klastrze”

Nowsze systemy są skonstruowane według architektury trójwarstwowej i czasami nazywa się je systemami „thin client” – „cienki klient”. Wiele systemów trójwarstwowych posługuje się przeglądarkami internetowymi, które stanowią interfejs użytkownika w pierwszej warstwie, aplikacją wykonywaną na osobnym serwerze będącą drugą warstwą oraz bazą danych na kolejnym serwerze, która stanowi warstwę trzecią. Systemy trójwarstwowe są łatwiejsze do instalowania, utrzymania i rozbudowywania niż systemy dwuwarstwowe, ale to że są one trójwarstwowe, nie oznacza, iż aplikacja jest w stanie pracować na klastrze serwerów. Nowe aplikacje biurowe przeszły od poziomu trzech warstw do „n-warstw” grup aplikacji. W aplikacjach n-warstwowych jedna aplikacja może wykorzystywać usługi wielu innych aplikacji, a interfejsy użytkownika mogą łączyć elementy pochodzące z wielu aplikacji. W nowych systemach biurowych liczba aplikacji pracujących dla jednego użytkownika może być bardzo duża, a źródła danych i ujścia danych mogą znajdować się  w odrębnych, bardzo zróżnicowanych, systemach.

Ponieważ przeniesienie i wdrożenie (zastosowanie) głównych technologii biznesowych na poziomie produkcji zabiera zazwyczaj około pięciu lat, powinniśmy zacząć widzieć zastosowanie architektury klastrów serwerów (clustered server) oraz n-warstwowych aplikacji produkcyjnych na przestrzeni kilku najbliższych lat. Jednak te aplikacje są potrzebne teraz. Bez architektury klastrowego systemu (clustered system) musi być jeden duży system dla całego zakładu czy partycji fizycznej, takiej jak jednego systemu SCADA czy MES na komórkę procesu, czy linii produkcyjnej. Żadne inne rozwiązanie (prócz łącznia serwerów w klastry) nie  zapewnia realnych możliwości rozbudowywania i modernizacji systemów potrzebnych w nowoczesnych zakładach produkcyjnych.

^{Dennis Brandl (dbrandl@brlconsulting.com) jest prezesem BR&L Consulting, firmy zajmującej się rozwiązaniami IT dla produkcji.}

* Pojęcie „żelazny” określa sztywność systemu i brak możliwości tolerancji błędów sprzętowych. Redundancja kilku serwerów połączonych w klaster powoduje, że w razie sprzętowej awarii jednego z serwerów inny serwer z klastra przejmuje jego funkcje i aplikacja jest wykonywana dalej, zaś awaria, poza niewielkim czasem zwłoki, może pozostać niewidoczna dla samego procesu produkcyjnego, jak i dla użytkowników – przyp. red.

Linki sponsorowane

	Almanach Produkcji w Polsce Kompleksowy katalog w wersji on-online oraz drukowanej majacy na celu dostarczenie użytecznych informacji o dostawcach dla przemysłu jak i oferowanych przez nich produktach
	Produkcja od A do Z w samym sercu polskiego przemysłu Zapraszamy Państwa do udziału w Kongresie Produkcji i Technologii PROTECH.