Oprogramowanie AVEVA – co warto wiedzieć o projektowaniu i uruchamianiu systemu informatycznego dla przemysłu

Każdy użytkownik komputera zna taką sytuację: mamy nowy program, którego dotąd nie używaliśmy – aby go uruchomić, trzeba go najpierw zainstalować. Albo inny przypadek: pojawia się nowa wersja naszej ulubionej aplikacji – aby jej użyć, trzeba przeprowadzić aktualizację. W komputerze domowym jest to zwykle dość łatwe. Uruchamiamy program „setup.exe”, gładko przechodzimy przez kilka etapów instalatora – i gotowe. W przypadku uruchamiania oprogramowania przemysłowego AVEVA sprawa jest nieco bardziej złożona.

W bardzo zamierzchłych już czasach, kiedy cały system informatyczny zakładu produkcyjnego ograniczał się do pojedynczej stacji wizualizacyjnej InTouch, instalacja oprogramowania wyglądała podobnie, jak w przypadku zwykłych programów. Wystarczyło uruchomić instalator – i za chwilę program był gotowy do pracy. Dzisiejsze systemy wyglądają zupełnie inaczej. Są to z reguły rozbudowane struktury, złożone – oprócz stacji wizualizacyjnych – również z serwerów Platformy Systemowej AVEVA lub Historian. Struktura taka – zanim przystąpimy do prac wdrożeniowych – wymaga dalece bardziej szczegółowego przemyślenia i zaprojektowania.

System może być stosunkowo prosty…

Na potrzeby tego artykułu zilustrujemy temat, posługując się dwoma dość typowymi przykładami systemów informatycznych w przemyśle. Pierwszy z nich to system „mniejszy”, w którym łączna liczba obsługiwanych sygnałów I/O nie przekracza 5 000. Z reguły w tego typu systemach aplikacje wizualizacyjne nie są bardzo skomplikowane, a tym samym wymagania stawiane serwerom i stacjom klienckim są mniejsze.

W tej aplikacji jeden komputer pełni jednocześnie funkcję Application Servera Platformy Systemowej AVEVA i serwera Historian. Jest na nim umieszczone również Galaxy Repository, a nierzadko też środowisko deweloperskie System Plarform IDE. System obejmuje także kilka stacji wizualizacyjnych AVEVA InTouch. Całość połączona jest siecią Ethernet.

Dlaczego tak? W przypadku tego rodzaju systemów wymagania w zakresie wydajności są mniejsze, natomiast jednocześnie większe są ograniczenia budżetowe, które sprawiają, że choćby tylko z powodów finansowych, nie mamy możliwości instalacji oddzielnych serwerów dla każdej usługi. Trzeba tu jednak podkreślić dwie rzeczy. Po pierwsze – taka architektura nie daje nam żadnych zabezpieczeń na wypadek awarii serwera. Żadna jego funkcja nie jest dublowana na innej maszynie, więc jeżeli serwer przestaje działać – cały system zatrzymuje się. Podobnie ma się sytuacja z planowymi pracami serwisowymi – również one powodują konieczność zatrzymania wszystkich usług.

Po drugie – jest prawdą, że mniejsze systemy mają mniejsze wymagania, więc często tego rodzaju prostsza architektura będzie wystarczająca. Czy jednak możemy zawsze mieć taką gwarancję? Oczywiście nie. Skąd zatem można mieć pewność? Do tego tematu wrócimy w dalszej części tekstu.

… ale może być też bardzo rozbudowany

W przypadku systemów większych, w których liczba obsługiwanych zmiennych I/O często znacznie przekracza 5 000, architektura powinna oczywiście wyglądać zupełnie inaczej. Na przykład tak, jak na poniższym schemacie.

W tym przypadku każdy serwer, zarówno Application Server, jak i Historian, powinien być osobnym komputerem. Również Galaxy Repository uruchomione jest na oddzielnej stacji, podobnie środowisko deweloperskie System Platform IDE. Stacje wizualizacyjne natomiast podłączone są za pośrednictwem serwera terminalowego. Wszystkie komponenty spina oczywiście sieć Ethernet.

Ponadto łatwo zauważyć, że oba kluczowe serwery (Application Server i Historian) zostały zdublowane w układzie redundancji, dzięki czemu awaria jednego komputera nie będzie miała wpływu na nieprzerwaną, prawidłową pracę całego systemu. Uszkodzony element możemy łatwo wymienić lub zmodernizować. To jeden z ważniejszych powodów, dla których architekturę systemu warto projektować właśnie w ten sposób.

Jednak są jeszcze inne powody. Takie rozproszenie funkcjonalności sprawia, że łatwiej jest zarządzać wydajnością – każda usługa ma swoje zasoby i jest niezależna od pozostałych. Podobnie w przypadku konieczności wykonania działań serwisowych możemy pracować na jednym fragmencie całego systemu, który jako całość nadal pracuje. Rozproszenie i zdublowanie usług pozwalają także przeprowadzać proces migracji z wersji na wersję oprogramowania, gdyż zastosowanie rozproszenia wraz z procedurą opisaną w dokumentacji, pozwala zminimalizować czas potencjalnego przestoju. W przypadku opisanej wcześniej „małej” architektury prozaiczna konieczność zrestartowania serwera całkowicie zatrzymuje działanie systemu.

W przypadku używania usług terminalowych, warto zastosować farmę takich serwerów. Gdy wykorzystujemy fizyczne komputery jako stacje wizualizacyjne i awarii ulegnie jedna z nich, to zwykle proces można prowadzić awaryjnie na innej stacji. W przypadku awarii serwera terminalowego wszystkie sesje terminalowe przestaną działać – i nie będzie skąd prowadzić procesu. Gdy zastosujemy farmę serwerów terminalowych, liczba potrzebnych stacji klienckich jest łatwa do skalowania. Możemy w razie potrzeby zwiększać zasoby serwerów lub ich liczbę, zapewniając podwyższenie dostępności oraz równoważenie obciążenia pomiędzy serwerami.

Ważne słowo: wirtualizacja

Częstą praktyką jest obecnie projektowanie i wdrażanie przemysłowych systemów informatycznych w środowisku zwirtualizowanym. Wszystkie komponenty takiego systemu, nawet najbardziej wymagające serwery, mogą być uruchomione na maszynach wirtualnych. Oprogramowanie AVEVA wspiera rozwiązania od dwóch największych dostawców technologii wirtualizacji: Microsoft Hyper-V oraz VMWare vSphere. W przypadku tego drugiego mamy do dyspozycji narzędzie vCenter, dzięki któremu możemy centralnie zarządzać wieloma hostami wirtualizacji, wykonywać kopie bezpieczeństwa, a także łatwo przenosić maszyny wirtualne pomiędzy serwerami, zapewniając ciągłość pracy instalacji w przypadku konieczności serwisowych samych serwerów do wirtualizacji.

Naturalne jednak wydaje się pytanie: dlaczego w ogóle warto stosować wirtualizację. Rozwiązanie takie ma kilka ważnych zalet:

1. Maszyny wirtualne nie są uzależnione od sprzętu, na którym są uruchomione. Każda maszyna może być w razie potrzeby szybko przeniesiona na zupełnie inny serwer. Pozwala to na dużo szybsze reagowanie na awarie oraz znacznie ułatwia wszelkie prace serwisowe.

2. Na jednym serwerze może być uruchomionych wiele maszyn wirtualnych, które w rzeczywistości współdzielą ze sobą zasoby tego serwera. To daje nam elastyczność w zarządzaniu przydzielaniem zasobów dla poszczególnych maszyn i pozwala skutecznie regulować wydajność ich pracy.

3. Wirtualizacja pozwala nam na wykonywanie tzw. snapshotów, czyli zapisywanie kompletnego stanu maszyny (w tym zawartości dysku i pamięci), który później może zostać odtworzony. Dzięki temu możemy „zatrzasnąć” dany stan maszyny wirtualnej np. gdy potrzebujemy wykonać jakieś testy. Gdyby w trakcie testów coś poszło nie tak, łatwo możemy powrócić do wcześniej zapisanego stanu maszyny, tym samym wycofując wszystkie wprowadzone zmiany.

4. Wirtualizacja ułatwia zarządzanie poszczególnymi komponentami systemu, ponieważ maszynami wirtualnymi możemy zarządzać centralnie, z jednego miejsca. Co więcej, również mechanizm wykonywania kopii bezpieczeństwa może być scentralizowany i skonfigurowany w taki sposób, aby kopie wszystkich maszyn wirtualnych były wykonywane automatycznie oraz zapisywane w jednym, przeznaczonym do tego miejscu.

5. Wirtualizacja bardzo ułatwia skalowanie systemu. Dużo łatwiej dodać do systemu nową maszynę wirtualną niż fizyczny komputer.

Jakie wymagania mają aplikacje?

Niezależnie od tego, czy jest uruchamiana na fizycznym komputerze, czy na maszynie wirtualnej, każda aplikacja AVEVA ma określone wymagania sprzętowe. Ich określenie jest łatwiejsze w przypadku środowiska zwirtualizowanego, w którym operujemy trzema parametrami: liczbą rdzeni wirtualnych procesora (vCPU) oraz ilością pamięci RAM i pojemnością dysku (storage), przydzielonymi pojedynczej maszynie. Dla poszczególnych aplikacji możemy określić zalecane/typowe wymagania, ale należy pamiętać, że zawsze będzie to jedynie punkt odniesienia, a rzeczywiste wartości mogą być uzależnione od specyfiki konkretnej aplikacji.

Zapotrzebowanie na zasoby serwera aplikacji Platformy Systemowej zależy od liczby wykorzystywanych silników aplikacyjnych. Przy skalowaniu zasobów można przyjąć, że każdy silnik wymaga 1 vCPU (jeżeli lepiej chcemy wykorzystać zasoby zakupionego sprzętu i wykorzystywać przetwarzanie równoległe, warto stosować wiele silników aplikacyjnych, gdyż te nie są już podzielne pomiędzy rdzeniami procesora). Dobrym punktem startowym będzie przydział 4 wirtualnych rdzeni – oraz 1 GB RAM (w przypadku skomplikowanych skryptów może to być 1,2 GB), zachowując rezerwy na obsługę sytuacji nieprzewidzianych oraz oczywiście na sam system operacyjny (wg specyfikacji i rekomendacji dla danej wersji systemu operacyjnego). Zapotrzebowanie na przestrzeń dyskową ma mniejsze znaczenie, 120 – 150 GB SSD będzie wystarczające.

AVEVA Historian wymaga zawsze od 4 do 6 rdzeni vCPU oraz minimum 16 GB RAM (sam serwer SQL wymaga 10 GB). Jeżeli będziemy wykorzystywać SQL Server Reporting Services lub własne bazy SQL, konieczne będzie 24 GB RAM. Jeżeli chodzi o storage, to powinniśmy wykorzystać dwa osobne, wirtualne dyski: jeden na pliki systemu operacyjnego oraz pliki bazy danych SQL (120-150 GB SSD), drugi na same bloki danych Historiana (nawet 1 TB – w zależności od wymaganego czasu przechowywania danych).

Galaxy Repository wymaga 4 rdzeni vCPU, 8-12 GB RAM i 120-150 GB SSD. Natomiast środowisko deweloperskie Aveva System Platform IDE potrzebuje 4 rdzeni vCPU, 8 GB RAM i 120-150 GB przestrzeni dyskowej SSD.

W przypadku stacji wizualizacyjnych uruchamianych na serwerze usług terminalowych sprawa jest nieco bardziej skomplikowana. Po pierwsze, AVEVA InTouch WindowViewer jest aplikacją jednowątkową, dlatego ważne jest, aby procesory używane w serwerach hostujących sesje terminalowe były jak najwydajniejsze – minimum 2,6-2,8 GHz. Użycie procesorów wolniejszych (2,2 – 2,4 GHz) będzie powodować wolne działanie i gorszy komfort pracy operatorów.

Jeżeli chodzi o serwer terminalowy (Remote Desktop Server), należy przewidzieć jeden rdzeń vCPU na każde 2-3 sesje teminalowe. Jest to wartość szacunkowa, gdyż zapotrzebowanie mocno zależy od tego, jak przygotowane są aplikacje wizualizacyjne i jak bardzo obciążają procesor. Na każdą sesję terminalową powinniśmy też przewidzieć 1–1,5 GB pamięci RAM (choć należy pamiętać, że zapotrzebowanie na RAM rośnie w miarę czasu pracy aplikacji i otwierania kolejnych okien). Realnie rzecz biorąc, pojedynczy serwer usług terminalowych powinien być wyposażony w 26-32 GB pamięci RAM.

Dla serwerów terminalowych jako nośniki danych należy bezwzględnie zastosować dyski SSD (dla zapewnienia odpowiedniej wydajności). Trzeba przewidzieć odpowiednią ilość przestrzeni dyskowej dla samego systemu operacyjnego (120 – 150 GB), a także niezbędną przestrzeń dla kopii aplikacji wizualizacyjnej dla każdej z sesji.

Jak dobrze zaprojektować system? Kilka przydatnych wskazówek

Warto tu jeszcze przytoczyć kilka ogólnych wskazówek, przydatnych przy projektowaniu rozbudowanych, przemysłowych systemów IT, opartych na oprogramowaniu AVEVA:

1. W przypadku, gdy system ma posiadać więcej niż 5 stacji (komputerów fizycznych lub wirtualnych), wskazane jest skonfigurowanie środowiska domenowego. To znacznie ułatwia zarządzanie wszystkimi maszynami, użytkownikami i regułami – np. firewall poprzez polisy grupowe. Dodatkową zaletą jest dostępność pojedynczego logowania (single sign-on, SSO) w takiej konfiguracji – użytkownik loguje się raz, uzyskując dostęp do wszystkich zasobów i aplikacji w całym systemie.

2. Oprogramowanie AVEVA InTouch wykorzystuje tylko jeden rdzeń procesora, zatem dla jego wydajnej pracy (niezależnie, czy jest uruchamiane na fizycznym komputerze, czy na maszynie wirtualnej) znacznie ważniejsze jest taktowanie procesora niż liczba rdzeni.

3. W przypadku wykorzystywania serwerów terminalowych obowiązuje prosta zasada – im więcej równoległych połączeń klienckich, tym więcej potrzebnych rdzeni procesora.

4. Jeżeli w aplikacji wizualizacyjnej planujemy wykorzystać elementy 3D, warto zastosować dedykowaną kartę graficzną z odpowiednio mocnym GPU. Podobnie jest przypadku wyświetlania obrazu z wielu kamer.

5. Niezwykle ważne jest skonfigurowanie wiarygodnego źródła czasu (NTP) dla systemu. Można skorzystać z publicznego serwera lub wykorzystać lokalny moduł GPS.

6. Z każdym instalatorem aplikacji dostarczany jest dokument ze szczegółowymi wymaganiami sprzętowymi. Należy jednak pamiętać, że są to wymagania produktowe, a nie aplikacyjne. Oznacza to, że w zależności od tego, jak bardzo rozbudowaną aplikację będziemy tworzyć, mogą one okazać się niewystarczające.

Wsparcie ekspertów ułatwia zaprojektowanie każdego systemu

Nawet biorąc pod uwagę wszystkie powyższe wskazówki, poprawne zaprojektowanie architektury oraz wdrożenie przemysłowego systemu informatycznego jest skomplikowanym i odpowiedzialnym procesem. Pojawia się wiele pytań. Jakie produkty wybrać? Jak je połączyć? Na jakim sprzęcie je zainstalować? Czy to będzie niezawodnie działać? Czy to będzie działać wydajnie? I czy na pewno?

Są to bardzo stresujące pytania, szczególnie jeżeli nie mamy zbyt dużego doświadczenia w takich wdrożeniach. Wymagana jest też oczywiście rzetelna wiedza techniczna o poszczególnych produktach.

Warto zatem pamiętać, że jeżeli stoimy przed takim wyzwaniem, możemy zwrócić się do firmy ASTOR. Nasi eksperci skutecznie pomogą na każdym etapie projektowania i wdrożenia systemu:

• pomożemy zaprojektować architekturę systemu,
• wskażemy zalecaną konfigurację aplikacji,
• doradzimy w zakresie konfiguracji sprzętu i/lub środowiska wirtualnego,
• pomożemy określić, jakie zasoby będą niezbędne dla poszczególnych komponentów,
• doradzimy, jak zaprojektować zabezpieczenia takie jak redundancja czy system kopii bezpieczeństwa.

W ramach naszych usług doradczych klient może otrzymać od nas projekt kompletnego środowiska IT z konfiguracją dedykowaną do oprogramowania AVEVA, wraz z dokumentacją tego środowiska, tak aby mógł je przejąć i samodzielnie nim zarządzać. 

Autorzy tekstu:

Artur Połeć

Marcin Woźniczka

Dział Pomocy Technicznej ASTOR