David Brent is a technical information engineer for IT systems at Bosch Security Systems, Inc.
Traditional video designs used centralized storage, says Brent, but modern network capability lend themselves better to edge-based and decentralized storage of video surveillance data.
Photo credit: Image courtesy stock.xchng/digital_a
"I cannot imagine any condition which would cause a ship to founder. I cannot conceive of any vital disaster happening to this vessel. Modern ship building has gone beyond that."
- Captain Smith, Commander of the Titanic
This quotation is a foreshadowing that not only applies to ships at sea, but also to networks of any size. The iceberg that may lurk in your future is CCTV video, if it is treated like regular data. Video is a unique creature with nuances of its own, and those can be very mercurial based on the implementation and specific deployment.
In the mid-1990s, the CCTV industry slowly started its digital convergence with the IT industry, and the merger has now reached staggering speed -- outpacing the knowledge base of most CCTV integrators, installers and contractors. Most integrators will not pay IT industry salaries to their field technicians, preventing qualified IT techs from entering the security industry. That, coupled with the fact that IT now has the biggest say about the products being deployed on their networks, results in more IT departments taking ownership of their CCTV security systems.
About a decade ago, when I found my way into the security industry, I was an anomaly -- the computer "geek" in the analog CCTV world. Moving from my role as a network administrator in the Marine Corps to a CCTV technical instructor was truly a culture shock. My previous world was about data flow (speed), data security, and long-term storage. The CCTV world is based on the same data principles, but the two types of data were and still are very different in terms of sheer size and volume.
The industry then, as well as some vendors' perspectives now, is to treat video data like any other type of data and store it in a centralized fashion. ("Captain Smith, I think we should turn SOUTH just a bit!")
In most of my seminars and presentations, I usually equate video and data to ice. Data is like a cup of ice cubes, while video on a large system is the iceberg that sank the Titanic. Let's do a simple comparison to show you what I mean.
For a point-of-sale transaction database with 100 million records, you would need roughly 80GB of space, depending on the vendor application and the type of database used. Since a transaction is a change to the database (add, change, delete), theoretically, we could run trillions of transactions against that same 80GB database. So, the first set of numbers for our comparison exercise is:
POS 80GB = 100 million records with 1 trillion transactions
For the second portion of our comparison, let's look at data that most of us are more familiar with. We have an Exchange Server with 2,000 users, and each user has a 150MB mailbox. That would give us roughly 292GB of needed storage. So, our next set of numbers is:
292GB Exchange Space = 2,000 users
To get the third number, we are going to look at only one IP camera. We will use some numbers from a very common specification for video: 30 FPS at 4CIF (H.264) with an average bit rate of 2,000kb/s with no quiet time. We want to record this camera and retain the video for 30 days. This number is:
679.8GB = 1 camera for 30 days
So, from a storage perspective, we have three very different numbers that help us see the basic difference between video and data -- 80GB, 292GB and 679GB.
Now, consider the numbers involved in a surveillance system at a medium-sized international airport that has been installed for a few years now. Here are the specifications:
300 cameras, 15 FPS @ 4CIF (H.263/MPEG4), max and target bit rates of 1500 kb/s and 1200 kb/s, with 30 days retention time
This installation requires:
135 TB + failover devices (20 TB in back up storage) for a total of 155 TB
So, just imagine the storage required for a truly large installation with more than 2,000 cameras and retention time close to one year!
How Does this Affect the Network?
When you implement IP video, you are paying for three things: inputs, storage, and bandwidth. The three are inseparable, and storage is tied to bandwidth's hip. In the example above, we have a peak network load of 439Mb/s. Most network administrators today have at least a 1 gig production network, so even with the true value of production bandwidth between 70% and 80% (700 to 800 Mb/s); the peak load identified above leaves plenty of room for every day activities, correct? Wait, not so fast!
This peak forecast is for the recorded stream only, and does not include live streams going to PCs, monitor wall applications, or virtual matrix stations. If the airport referenced above has 10 workstations (all in 10 to 15 cameo viewing mode), and three monitor wall applications (each with two flat panels in 5x5 mode), that translates into an additional 366 Mb/s of network consumption. This brings the network usage to 805Mb/s - crippling the 1 gig production network.
So what is the alternative? Decentralize video with iSCSI-based storage. This approach leaves video at the point of its origin - reducing the network load and safeguarding the video against catastrophic loss.
But beware; living on the edge also has its pitfalls.
The Edge and Beyond
The evolution of CCTV encoding over the last decade has been a fast-paced race to the edge. The mindset of most companies in the industry has been to leave the DVR by the wayside, and do the conversion from analog to digital via what is known as the common "edge" encoder.
The encoder is basically the digital signal processor from a DVR grabber card placed in a box with an analog input and an Ethernet jack. This eliminates the multiple layers of failure that typically exist within a big box DVR. Still, most companies rely on the network video recorder (NVR) to do the laborious job of recording. With this old-school mentality, 9 out of 10 companies still place NVRs in the central location where the old DVRs used to reside. While the encoder-plus-NVR combination decentralizes the single point of failure of the DVR, it is the first step in converting from an analog system to digital, and places the burden back on the network when deployed in a centralized fashion.
A better approach pushes encoding to the edge. The emergence of intelligent encoders and IP cameras has enabled these devices to perform motion detection, alarm task scripting, video analytics, e-mail and SMS messaging, and to feature built-in iSCSI initiators. By handling these features at the encoder, you can eliminate the need for a separate PC and its associated acquisition, management and maintenance costs - creating a positive effect on your return on investment.
The last feature in the list above - iSCSI -- is the primary solution for decentralized storage. With true CCTV iSCSI integration, there is little or no operating system intervention, and the encoders or IP cameras can record directly to a target LUN located nearby at the edge or directly connected.
Many vendors tout that they record via iSCSI, but in most cases, it is iSCSI with a catch. Some of the "pseudo iSCSI" solutions on the market are:
- Recording to an NVR-based system on a Windows Server, and the storage is an iSCSI appliance. This is usually still a centralized approach with iSCSI storage connected to the NVR instead of the typical DAS SCSI storage.
- iSCSI appliances running a Unix kernel, with the Unix kernel running either ZEN or VMWare with Windows Server installed, and also running an NVR software. This is usually deployed in a centralized fashion and has multiple possible failure points.
The common thread among these pseudo iSCSI solutions is the NVR application. To be truly decentralized, you need to avoid being tied to an NVR anchor. NVR applications are very processor and memory intensive, as they can receive and record video streams from 64 - 128 video sources simultaneously, depending on the vendor implementation.
True iSCSI implementation allows the encoder(s) or IP camera(s) to be assigned to iSCSI target(s). The encoder(s) or IP camera(s) and storage devices do the work - there is no intervening NVR application.
Selecting iSCSI Hardware
There are well over 100 iSCSI vendors in the market today, and each one operates differently. One of the major mistakes I see IT administrators make with CCTV projects is that they insist on using their existing storage appliances. Instead, it is best to ask the CCTV vendor what storage is recommended and why, or what storage devices have been tested with the surveillance equipment.
Most iSCSI vendors, as well as some hard drive and tape drive vendors, run when they hear the word video, due to the 24/7 nature of surveillance. Video is a constant bombardment against the device, not the occasional full, incremental, or differential backup common in data storage. As a result, many vendors will not guarantee their products beyond one year, if they do at all.
Other vendors get snagged on the number of actual iSCSI server sessions they can support. If an iSCSI can only accept 6 to 30 sessions at one time, it is not well suited for a video installation, which typically requires 60 - 256 simultaneous iSCSI server sessions.
The last hurdle vendors fail at is the actual read/write throughput across the backplane of the iSCSI device. The appliance must support more than 200 Mb/s during rebuilds for a video surveillance application.
Overall, be aware that iSCSI is an open standard with mandatory and optional features. Most storage vendors pick a flavor of iSCSI to implement in their devices and test them against the full implementation of a MS, Linux, Open-E, or other initiator. A camera vendor may use all of the mandatory features of the MS initiator but none of the optional features. If the storage appliance wants to see the entire MS iSCSI implementation and does not, communication is impeded or does not take place at all.
I have been to customer sites where the user purchased a lower-end iSCSI model than what was originally recommended in an attempt to reduce costs. The lower-end model either failed at one of the previously mentioned hurdles or used a slightly different implementation of the RFC iSCSI initiator stack, and the customers were unable to record video. Do not assume a different model from the same vendor will work for your system, as it may use a different firmware version or platform than you need.
In summary, it is important to do your homework before making decisions on which video system and which architecture to deploy. Ask questions about the system and how it will affect your network. It is much easier to install the correct system that fits your needs and your network's capabilities, than to rip out the wrong one and start over.
About the author: David Brent is a technical information engineer for IT systems at Bosch Security Systems, Inc. He has extensive knowledge of networks and holds a number of IT and networking certifications. He can be reached at firstname.lastname@example.org.