Subscribing is a smart move!
You can subscribe to this board after you log in or create your free account.
Invite a Co-worker
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
Link copied. Please paste this link to share this article on your social media post.
SAN
A storage-area network (SAN) is a dedicated high-speed network (or subnetwork) that interconnects and presents shared pools of storage devices to multiple servers. Geo SCADA can be deployed with a SAN, often in conjunction with a virtual environment, with one or more virtual servers running on the same physical hardware and sharing other peripheral devices.
The SAN can be used to add resilience and provide a higher performance at lower cost to a broader range of servers. When using SANs, there are several considerations you need to make relating to hardware and performance.
Storage and Database Locking
The Geo SCADA database, as any other, will need to lock parts of the database while it is performing different operations affecting the same area. This is to protect the integrity of the database and keep it self-consistent. Some of these locking operations will occur around the read and write of data from the storage system. Geo SCADA keeps these to a minimum through the use of double-buffering (using memory as an intermediate store), but there will be some operations for which the database activity (or part of it) requires to wait for a disk to complete a read or write operation.
The Geo SCADA Data and Configuration sections of the database are accessed most often and do not require waiting for read or write of storage, but the larger historian storage sections (events, point data, alarms, configuration changes) require database locking during disk operations. Therefore, the disk operations associated with the read and write of historic data are important for the performance of Geo SCADA, and adverse disk performance can affect data scanning from drivers and data requests and updates to clients.
Dedicated vs SAN Storage
With conventional storage, only the server connects to the storage devices (which are usually RAID for redundancy and performance). There is little sharing of the resource and usually the highest performance is possible. Further gains are possible by separating the different database areas such as events, historic and logging onto different sets of media, and by improving the media itself with SSD or faster means of connection.
With SAN storage, other applications are sharing the resource. If these other applications are as demanding as Geo SCADA , then there is the possibility of performance impact.
In our experience we have found that adding further high demand applications to a SAN shared with Geo SCADA can be successful, but the loading should be inspected carefully. There is a non-linear relationship between system load and the performance impact, and at higher loads a small load increase causes a disproportionately higher impact on applications.
Geo SCADA requires all disk operations to be carried out efficiently, as a single delayed operation will affect important transactions such as the round-trip scan of a device or the request for a display of real-time or historic data.
Case Study
In the following graph, the blue line is the disk write latency reported by the server using a shared SAN, and the red line is the same for a locally connected RAID array: 
In this test the Geo SCADA server loading is a 650,000-point database reading 12,000 devices and storing 5000 historic samples per minute and 1000 events per minute. There were the equivalent of six such Geo SCADA servers presenting this load to the SAN, plus a user operation, engineering and configuration loading appropriate to a SCADA database of this size. This is a considerable loading. The symptoms of this high loading included slower scanning, for which only 75% of the desired scan rate was achieved, and slow response to users, with display times averaging 4 seconds.
By removing two of the Geo SCADA databases from the SAN (which were also a separate and more lightly loaded database), the performance of the remaining four servers returned to the expected level, with the desired scan rate being achieved and with display times averaging 1 second.
In the revised situation, the average write latency for the SAN was still higher than the physical disks, but had a smaller effect on Geo SCADA operation. Thus the relationships between variables are non-linear.
Of the many measurements available for disk performance, as with networking the most significant measure is the latency for read and write operations, and we recommend that system design and assessment use these carefully.
Further Recommendations
We recommend the following Geo SCADA Resource Center sections for additional guidance:
Network: Network Configuration and Performance
CPU and Memory: CPU and Memory Performance
Storage: Hard Disk Configuration and Performance
Go: Home Back
Author
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.