Serwis korporacyjny
 APA Group  

Artykuły

2 sposoby wirtualizacji systemu Nazca – ich mocne i słabe strony

Z artykułu dowiesz się:

  • Jakie są dwa sposoby wirtualizacji systemu Nazca i czym się one charakteryzują. 
  • Które rozwiązanie lokalne czy chmurowe przynosi więcej korzyści. 
  • W jakich zastosowaniach obsługa zewnętrzna sprawdzi się lepiej od wewnętrznej. 

Nazca to system wielu możliwości, który jednak trzeba w odpowiedni sposób zaimplementować. W tym artykule 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ą. 

Jak odczytywać schemat?

  • Na zielono zalety
  • Na czerwono wady
  • Na żółto i biało treści informacyjne 

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:

1 Gwiazda2 Gwiazdki3 Gwiazdki4 Gwiazdki5 Gwiazdek (oddanych głosów: 1 średnia: 5,00 z 5)
Loading...


Zobacz również