APAGROUP
APA LAB alt

2 sposoby wirtualizacji systemu NAZCA

2 sposoby wirtualizacji systemu NAZCA

alt
  1. NAZCA to system wielu możliwości, który jednak trzeba w odpowiedni sposób zaimplementować. W tym wpisie wyjaśniamy, jakie są dwie metody wirtualizacji oraz pokazujemy, które rozwiązanie sprawdzi się lepiej w konkretnych wdrożeniach u klienta.

    Wirtualizacja wewnątrz sieci klienta
    Pierwszy sposób wirtualizacji odbywa się w sieci prywatnej. Wymagana jest do tego odpowiednia infrastruktura informatyczna (np. serwery) – zaplanowana i wdrożona w siedzibie klienta. Hypervisory zdolne obsługiwać NAZCĘ również mogą być jego własnością.

    1. Komponent NAZCA pracuje na maszynie wirtualnej z systemem operacyjnym Windows, natomiast sama maszyna wirtualna jest uruchomiona na hypervisorze (fizycznym komputerze) wirtualnej maszyny. Może to być serwer lub zespół serwerów, które mają uruchomione oprogramowanie do obsługiwania maszyny wirtualnej. Wirtualna maszyna to natomiast środowisko uruchomieniowe dla NAZCA, z którym klient nie ma do czynienia fizycznie, manualnie. Można to porównać do “niewidocznego” z perspektywy użytkownika systemu operacyjnego.

      Zalecamy, by urządzenia BMS (np. urządzenia kontroli dostępu) oraz systemy zewnętrzne (oznaczone na rysunku jako “Auxillary”; np. system alarmowy niezależny albo niezależny monitoring CCTV) pracowały na osobnej sieci komputerowej. Chodzi zatem o wydzielony fragment sieci komputerowej z infrastruktury sieciowej budynku i klienta, który miałby służyć do komunikacji między NAZCĄ a infrastrukturą BMS oraz systemami zewnętrznymi.

      Czy taka metoda wirtualizacji będzie odpowiednia? Z pewnością jest lepsza pod względem operacyjnym, łatwiejsza w obsłudze, mniej awaryjna. Niestety jej wadą jest to, że wymaga zorganizowania przestrzeni u klienta. To na nim ciąży odpowiedzialność za dostarczenie i utrzymanie infrastruktury oraz zatrudnienie specjalistów, którzy będą czuwać nad prawidłowością jej działania. Mimo tych niedogodności większość klientów APA decyduje się właśnie na ten wariant.

      Wirtualizacja w usługach typu chmurowego
      Druga opcja to implementacja i uruchomienie NAZCA poza instalacją klienta. W takim przypadku funkcjonowanie systemu jest możliwe dzięki dostawcy usług chmurowych.

W tym rozwiązaniu fizyczne oprogramowanie znajduje się po stronie dostawcy usług chmurowych, natomiast klient może z niego swobodnie korzystać. Wirtualna maszyna znajduje się zatem nie w sieci należącej do klienta, ale na zewnątrz, w chmurze. To w zasadzie główna różnica między tym sposobem wirtualizacji a wirtualizacją pierwszego typu.

Zaletami takiego sposobu wirtualizacji są bezobsługowość i oszczędności na infrastrukturze. Klient nie musi bowiem utrzymywać serwerów we własnym zakresie. O ich prawidłowe działanie i utrzymanie troszczy się podmiot zewnętrzny.

Nie oznacza to, że opisywany wariant jest pozbawiony wad. Wręcz przeciwnie, może być ich więcej niż w przypadku obsługi wewnętrznej sieciowej. Czasem zaburzona jest ciągłość komunikacji między NAZCĄ a elementami prywatnymi w sieci. Zmniejsza się jej kontrolowalność, bo ruch sieci musi być “przepuszczony” przez cały Internet. W momencie wystąpienia awarii dostępu ISP system jest odcięty od oprogramowania sterującego nim i użytkownik traci zdolność obsługi. Samą przyczynę usterki wykrywa się dużo gorzej, niż gdyby miało to miejsce w sieci lokalnej, bo droga zdiagnozowania jest bardziej skomplikowana.

Wirtualizacja przez chmurę niestety odbywa się także z niekorzyścią dla bezpieczeństwa. Dużo trudniej wdraża się zabezpieczenia poza wewnętrzną siecią.

Jak widać, taki sposób wdrożenia nie będzie odpowiedni zawsze i wszędzie. Sprawdza się jednak w przypadku specyficznych zastosowań, na przykład gdy klient dysponuje rozproszonymi instalacjami w kilkudziesięciu lub kilkuset obiektach. Jeśli te i tak są połączone Internetem, a dodatkowo serwerowni nie ma lub jest ulokowana zbyt daleko, to ryzyko od początku jest wliczone w cenę prowadzenia działalności. Drugim sposobem wykorzystania takiej wirtualizacji są cele pokazowe, bo łatwiej zapewnić dostęp klientom do chmury niż do sieci wewnętrznej.

 


CASE STUDY: Wirtualizacja serwera NAZCA na obiekcie Tesko Steel

Przykładem realizacji w ramach infrastruktury klienta było przeniesienie serwera NAZCA na maszynę wirtualną w Tesko Steel Sp. z o.o., czyli w firmie będącej jednym z najnowocześniejszych centrów stalowych w Polsce. W tym przypadku postawiliśmy na automatyczne wykonywanie kopii bezpieczeństwa całego systemu operacyjnego serwera. Zmieniono go zresztą z Windows 7 na Windows 10 IoT. 

Korzyści okazały się spore. Serwer wirtualny zabezpiecza przed awarią fizycznego dysku twardego czy też inną awarią sprzętową. W przypadku awarii oprogramowania serwera możliwy jest natomiast zdalny restart całego serwera. W razie potrzeby, zadanie to może być także zautomatyzowane, po to, by zapewnić jak najkrótsze okresy przerw w pracy systemu BMS oraz systemu parkingowego. 

Podczas takiej wirtualizacji klient zyskał zatem:

  • Łatwość zarządzania serwerem.
  • Bezpieczeństwo danych.
  • Krótsze czasy odzyskania sprawności po awarii.
  • Odporność na awarie sprzętu.
  • Zwiększenie poziomu cyber-bezpieczeństwa serwera.

 

 

 

 

Zobacz więcej

Integracja czujnika parkingowego z systemem NAZCA

Czytaj więcej