1 Wprowadzenie

System Asix jest systemem czasu rzeczywistego. Dotyczy to zwłaszcza stanowisk, które łączą się bezpośrednio z urządzeniami stanowiącymi źródło danych – sterowniki, liczniki itp.
Warunki, które musi spełniać takie środowisko, różnią się od środowisk realizujących aplikacje biurowe, czy nawet bazodanowe. System Asix ma określony czas liczony co najwyżej w milisekundach na realizację większości operacji, po którym takie operacje kończą się niepowodzeniem.

2 Dostęp do maszyn wirtualnych

Maszyny wirtualne powinny działać na dedykowanym serwerze, do którego użytkownik aplikacji nie powinien mieć bezpośredniego dostępu. Zapewnienie zdalnego dostępu wychodzi poza zakres niniejszego opisu i powinien zostać zapewniony przez służby IT/OT.

3 Połączenie ze sterownikami

Zdecydowaną większość aplikacji Asix można przenieść do środowiska wirtualnego, ale mogą wymagać odpowiedniego dostosowania. Zwykle nie ma problemu z połączeniami sieciowymi, które już działają w sieci Ethernet. Część urządzeń może jednak być podłączonych np. przy pomocy interfejsu szeregowego lub USB. Wtedy należy zastosować odpowiednie konwertery, które umożliwiają wirtualizację takiego portu np. przez sieć Ethernet.

Zdarzają się urządzenia, których protokół wymaga dotrzymania restrykcyjnego reżimu czasowego, nieosiągalnego w środowisku wirtualnym. Zwykle są to bardzo stare urządzenia, które nie uwzględniają nowoczesnych wymagań. Wtedy konieczne jest zastosowanie urządzeń konwertujących taki protokół na inny, który już takich wymagań nie ma.

Jest też grupa urządzeń, które sprawdzają, czy nie mamy do czynienia z maszyną wirtualną i wtedy celowo blokują połączenia. Dla takich nietypowych urządzeń należy upewnić się u producenta, czy nie zablokował wirtualizacji.

4 Parametry maszyny wirtualnej

Należy przewidzieć odpowiednią ilość rdzeni wirtualnych, pamięci RAM i pamięci dyskowej dla działania aplikacji. Oszacowanie tych zasobów dla konkretnej aplikacji jest odrębnym tematem, poza zakresem tego opisu i mocno zależy od charakteru stanowiska i liczby zmiennych aplikacji.

Minimalne i typowe zasoby określamy dla samego Asixa. Inne aplikacje, np. serwer SQL, należy doliczyć osobno.
Asix nigdy nie powinien działać na mniej niż 2 rdzeniach wirtualnych. Zalecane są co najmniej 4 rdzenie wirtualne.

Typowo maszyna wirtualna powinna też dysponować 8 GB RAM, wliczając w to Asixa i system Windows. Małe aplikacje mogą sobie radzić też przy 4 GB RAM.

Zasoby dyskowe zależą głównie od archiwum Asixa na danym stanowisku i nie da się określić typowej potrzebnej wielkości dysku. Zalecamy stosowanie dysków SSD dla zwiększenia wydajności aplikacji.

5 Licencje programowe na maszynach wirtualnych

Do licencjonowania naszych produktów zaleca się stosowanie kluczy sprzętowych USB, które za pomocą konwerterów udostępniane są maszynom wirtualnym przez sieć.

W niektórych przypadkach konieczne jest jednak zastosowanie kluczy programowych. W takiej sytuacji należy zadbać o zachowanie stałych parametrów maszyn wirtualnych, przede wszystkim adresów MAC kart sieciowych, ale też parametrów wirtualnego BIOS’a, parametrów procesora i innych parametrów maszyny wirtualnej. W przeciwnym razie klucz programowy wykryje niezgodność sprzętową i uniemożliwi wystartowanie aplikacji.

Zachowanie parametrów procesora wymaga m.in. aby klaster HA składał się z serwerów z takimi samymi procesorami. Przy różnych procesorach migracja zakończy się powodzeniem, ale licencja przestanie działać.

6 System wirtualizacji

Przy konfiguracji systemu wirtualizacji należy wziąć pod uwagę kilka zasad.

6.1 Stosunek rdzeni wirtualnych do fizycznych

Praktyka pokazuje, że proporcja rdzeni wirtualnych do fizycznych nie powinna przekraczać 3:1. W przeciwnym razie zwykle dochodzi do nadmiernego spadku wydajności, które są poza kontrolą z poziomu maszyny wirtualnej, a tym bardziej systemu SCADA.

6.2 Pamięć operacyjna

Cała pamięć operacyjna maszyny wirtualnej powinna mieć pokrycie w pamięci fizycznej. W przeciwnym razie może dojść do przechowywania części pamięci na dysku, co drastycznie obniża wydajność systemu.

6.3 Backup maszyn

Należy korzystać z profesjonalnych systemów backupu maszyn wirtualnych, które zapewniają wykonanie backupu bez znaczącego zamrożenia maszyny.

Najlepiej przewidzieć harmonogram wykonywania kopii zapasowych taki, aby nie dochodziło równocześnie do backupu więcej niż jednej maszyny. Należy zapewnić, aby w razie niepowodzenia można było zareagować bez upadku całego systemu. Np. w razie stosowania redundancji Asixa, wykonać backup redundantnych maszyn w różnych dniach.

Konieczne jest systematyczne nadzorowanie system backupu, aby np. w razie niepowodzenia nie pozostawiać migawek maszyn, które zwykle są tworzone przez system backupu.

6.4 Nie stosować migawek maszyn wirtualnych

Systemy wirtualizacji umożliwiają stosowanie migawek (snapshot) maszyn wirtualnych. Jest to wygodne przy zarządzaniu systemem wirtualizacji, ale pozostawienie kilku takich migawek powoduje znaczne spowolnienie wszystkich maszyn w systemie wirtualizacji. Migawki, wbrew swojej nazwie, nie są statycznymi obrazami maszyn, a wymagają stałej aktualizacji różnic, która może zabierać więcej czasu niż sama maszyna.

Należy unikać stosowania migawek maszyn wirtualnych, a jeżeli są konieczne, to zadbać o ich jak najszybsze usunięcie.

W systemie Asix milisekundy mogą decydować o niepowodzeniu niektórych operacji, więc zwielokrotnienie obciążenia systemu wirtualizacji może mieć katastrofalne skutki.

6.5 Aktualizacja oprogramowania

Należy zadbać o to, aby aktualizacja oprogramowania narzędzi systemu wirtualizacji na maszynach wirtualnych nie powodowała ich automatycznego restartu. Niestety, np. aktualizacja VMware Tools najczęściej restartuje maszynę. Takie aktualizacje należy więc wykonywać w porozumieniu ze służbami utrzymania ruchu.

Podobne zasady należy stosować przy aktualizacji systemu Windows. Niektóre oczekujące aktualizacje powodują niestabilne działanie systemu i wymagają restartu. Należy więc zadbać o ich wykonywanie w akceptowalnych porach.

Aktualizacje maszyn z redundantnymi stanowiskami należy planować w różnych dniach, aby umożliwić reakcję na ewentualne niepowodzenia, bez upadku całego systemu SCADA.

6.6 Synchronizacja czasu

Należy zapewnić pojedyncze źródło synchronizacji czasu w systemach Asix.

Nieraz można spotkać np. synchronizację zarówno z czasem hosta systemu wirtualizacji, jak i z serwerem NTP. To błąd. Kilka źródeł może powodować niewielkie skoki czasu w obydwie strony, co skutkuje dziurami w archiwum i zaburzeniem sekwencji zdarzeń.

Częste skoki czasu są w stanie całkowicie zdestabilizować system SCADA.

Poza tym synchronizacja NTP może zostać rozpoznana przez system wirtualizacji jako wadliwe ustawienie przeliczników czasu maszyny i skutkować niewłaściwą korektą tych przeliczników, co spowoduje, że czas maszyny będzie sztucznie spowolniony lub przyśpieszony. Dlatego przy stosowaniu synchronizacji czasu należy wyłączyć taką automatyczną korekcję.

Istotne jest, aby synchronizacja czasu działała w czasie uniwersalnym, a nie lokalnym. Inaczej drobne zmiany czasu mogą skutkować skokami o godzinę, jeżeli dojdzie do nich w chwili zmiany czasu z zimowego na letni i na odwrót. Takie skoki, nawet jeżeli trwają tylko przez kilka sekund, powodują poważne problemy w archiwach Asixa, gdzie mogą się rejestrować zapętlenia danych w czasie o całą godzinę.

Należy zapewnić synchronizację czasu zarówno dla wirtualnych maszyn jak i dla serwerów, które są odpowiedzialne za wirtualizację.

6.7 Rozdzielczość ekranu

Należy zarezerwować odpowiednią pamięć dla wirtualnej karty graficznej. Często typowo dostosowuje się pamięć do rozdzielczości ekranu stosowanych w firmie laptopów. Maszyny wirtualne systemu SCADA są zwykle podłączone do terminali operatorów z ekranami 4K, a czasem do systemów wielomonitorowych. Wtedy pamięć typowo przypisywana do maszyn do zastosowań biurowych będzie niewystarczająca.

6.8 Konfiguracja sieci

Należy zapewnić redundantne połączenia do każdego z serwerów odpowiedzialnego za wirtualizację. Dobrze jest też zapewnić odpowiednią detekcję awarii połączeń sieciowych po stronie przełączników wirtualnych. W środowisku VMware zalecamy ustawić opcję „Beacon probing”, a nie „Link status only”.

6.9 Diagnostyka systemu

W systemach produkcyjnych ważne jest szybkie usuwanie awarii. Dlatego od początku należy zadbać o odpowiednią diagnostykę systemu, aby szybko zlokalizować źródło potencjalnej awarii.