Nazca is a system of numerous possibilities, but it has to be implemented in the appropriate way. In this article, we explain what the two virtualization methods are and show you which solution will work better in your client’s specific deployments.
The first way of virtualization takes place in a private network. This requires a suitable IT infrastructure (e.g. servers) – planned and implemented at the client’s premises. Hypervisors capable of supporting Nazca may also be owned by the client.
How to read the diagram?
The Nazca component runs on a virtual machine using the Windows operating system, while the virtual machine itself runs on the hypervisor (physical computer) of the virtual machine. This can be a server or a set of servers that are running software to operate the virtual machine. The virtual machine, on the other hand, is a runtime environment for Nazca that the client does not physically and manually interact with. It can be compared to an operating system that is “invisible” from the user’s perspective.
We recommend that BMS devices (e.g. access control devices) and external systems (marked as “Auxillary” on the drawing; e.g. standalone alarm system or independent CCTV monitoring) should operate on a separate computer network. This means a designated part of the computer network from the building and client’s network infrastructure, which would be used for communication between the Nazca and the BMS infrastructure and external systems.
Will this method of virtualization be adequate? It is certainly better in terms of operations, easier to use, with fewer failures. Unfortunately, its disadvantage is that it requires the organization of space at the client’s premises. It is the client who is responsible for providing and maintaining the infrastructure and hiring specialists to ensure it works properly. Despite these inconveniences, the majority of APA’s clients opt for this solution.
The second option is to implement and run Nazca outside the client’s installation. In this case, the functioning of the system is achieved through a cloud service provider.
In this solution, the physical software is located on the cloud provider’s side, while the client has unrestricted access to it. The virtual machine is therefore not on the network belonging to the client, but outside, in the cloud. This is basically the main difference between this way of virtualization and first-type virtualization.
The advantages of this way of virtualization are zero maintenance and savings on infrastructure. The client does not have to keep the servers on their own, as they are run and maintained by an external entity.
This does not mean that the described variant is lacking shortcomings. Quite the contrary, there may be more of them than in the case of internal network support. Sometimes the continuity of communication between Nazca and private elements in the network is disturbed. Its controllability is reduced, because the network traffic must be “passed” through the entire Internet. When an ISP access failure occurs, the system is cut off from the software that controls it and the user loses the ability to operate it. The cause of the failure itself is much worse to detect than if it occurred on the local network, as the path to diagnosis is more complex.
Unfortunately, virtualization over the cloud is also done at the expense of security. It is much more complicated to implement security outside the internal network.
As you can see, this way of implementation will not be suitable each and every time. Yet, it works well when targeting specific applications, e.g. when the client has dispersed installations in dozens or hundreds of facilities. If those are connected to the Internet anyway, and additionally there is no server room or it is located too far, from the start the risk is included in the price of running the business. The second way to use such virtualization is for demonstrative purposes, as it is easier to provide customers with access to the cloud than to the internal network.
CASE STUDY: NAZCA server virtualization at Tesko Steel facility
Moving the NAZCA server to a virtual machine in Tesko Steel Sp. z o.o., a company which is one of the most modern steel centers in Poland, was an example of implementation within the client’s network. In this case, we relied on automatic backup of the entire server operating system. By the way, it was changed from Windows 7 to Windows 10 IoT.
The benefits have paid off nicely. The virtual server protects against physical hard disk failure or other hardware breakdown. In the event of a server software malfunction, it is possible to remotely reboot the entire server. If necessary, this task can also be automated to ensure the shortest possible downtime for the BMS and parking system.
During such virtualization, the customer benefited as follows, by gaining:
(Brak ocen)
Loading...
