As we prepare to roll into 2025, we thought we'd give you information to help create your work-related New Years '25 resolutions..
Proposed Resolution: Explore more reliable, more secure video management systems with IT in mind
Proposed Path to Resolution: watch the video below and ask yourself how much more secure and reliable this solution is for your organization or customers than a standard NVR-based system.
So, Why Bosch BVMS?
Bosch Video Management System, available for large-scale projects with a server or two or as an all-in-one single appliance for smaller applications, has been in the Bosch solution family for nearly a decade, so why haven't you heard about it or considered it for one of your security projects?
So why do most people use something other than BVMS? Frankly, BVMS was introduced as IP video was becoming mainstream. And, due to its IT-centric architecture, many security professionals didn't understand the power of BVMS and were just starting to develop their relationships with IT, and BVMS fell along the wayside in most conversations due to the appearance of being overly complicated.
Fast forward about 10 years, and IT pros are now hearing about BVMS and are excited to take advantage of all of its IT-friendly advantages. For example, BVMS for larger applications records security camera streams directly to iSCSI storage appliances, eliminating the need for more than a server or two in most system designs. This also provides resilience and virtually eliminates server maintenance headaches and vulnerabilities.
What is iSCSI?
Let's check out the details
From the standpoint of live video viewing on a workstation using BVMS Operator Client, when the operator makes a request to see live video, the workstation checks its rights and privileges, permissions, based on the elements file that's transferred from the BVMS management server to the workstation when the operator initially logged on.
Live Video Process
So when this request is made, the workstation goes to the network, across to the appropriate camera, and requests the video, and then the video travels back the other direction and pops up on the workstation so the operator can see the live video. The information never passes through a server. It goes directly from the camera to the network to the workstation.
Playback Process
If a request is made for playback of recorded video, the workstation goes to the network, across the network, it communicates with VRM, which at that point goes back to the network, communicates with the iSCSI storage, the iSCSI storage then sends the information directly to the workstation.
So, the request of the VRM server is just that there is a table of the complete relationship of the video coming from the camera directly to the storage. The request for information is requesting database information in terms of which storage blocks the system needs to put together to send the requested video back to the workstation. So, the video exists in the iSCSI storage. The database of where the video exists is in VRM.
And so when a request is made, VRM says, okay, I’m going to put these blocks of video together from the storage, and it goes from the storage directly to the workstation, and the Operator Client plays it back.
VRM Offline for Playback
If for some reason the workstation cannot access the VRM, it’s offline or there's a network or other problem, the camera also maintains a shorter database of where it has stored video information.
So, if someone wants to play a camera back and for some reason the workstation cannot reach VRM, then the workstation can tell the camera to provide the information and then the workstation makes a request to the camera, the camera then communicates with the storage and says send this video to the workstation, not requiring VRM to be online.
The difference is, VRM gives you a complete database end to end of where all the information is stored. If we use the camera as the reference database, you may only have a couple of days’ worth of database information on the camera because there's not enough memory in the camera for the file to exist in the size that it needs to be for the complete reference, for 30 days for example. So we could play the video back, but we can only have access to maybe 2 or 3 or 4 days of information, depending upon the capability of the camera.
So the data from each camera has a block database from all of the iSCSI storage and in that block database you have free blocks, meaning that when you install BVMS, you tell it how long you want to keep video. Once data is sent to the iSCSI storage, and let's just say for example that we have a 30 day minimum storage time, that block that we're talking about can't be re-accessed to put new information on or override the old information on the iSCSI.
The system knows when that block is going to become free. So, on the 31st day in this example, it unlocks the block, and that is now a free data file where now the system can record new video. It also keeps a reference of the locked or used files that it can't overwrite until it reaches that minimum storage time. That's done by VRM.
When a request for playback is made, it references the database of where the blocks are, and if they're locked or unlocked, and it puts that information together and sends it to the Operator Client workstation for viewing.
You never know exactly where the information is stored from the standpoint of the storage pool.
What does a normal NVR do with the stored video
In most competitive NVR-based systems, a folder is created for each camera. Let's just say for that day. And it fills that folder up and then a new folder is created. This is how a traditional Windows-based NVR works. It fills that folder up and it goes to the next folder, and it continues that creation.
So, you could actually open that folder in those competitive NVR-based systems and then look at the time and date of the file when it was opened and started and the time and date of when that file was closed. It will tell you that that information in that folder is from that camera for that period of time, which is a risk.
Now, surely there's security measures in place that will make it so that these folders cannot be deleted. But in theory, you could access this information and you could do something with it.
How does iSCSI work with Bosch cameras?
In a Bosch VRM with iSCSI video system, all the video data comes directly to the iSCSI pool whioch is broken down into tiny storage blocks.
When VRM is looking at this block database, it knows that this camera is recorded to this little block here, and this little block over here, and this block here, and this block here, and this block here. So, there's no way to go in and see the contents of the blocks.
Common Windows-based NVR systems create folders which are indexed. In Bosch’s VRM, there is no indexing.
So, if you were to look at these blocks using a Windows search mechanism, File Explorer, it will give you what looks to be an empty drive. It says, okay, here's this block of storage and it is X amount of storage, but it has no usable reference to any of this video information associated with these blocks.
The block has lots of little sections which make the VRM be able to know what those blocks are. There's a header, there's a data file, there's some other information associated with it.
And that's the magic of VRM.
So, no one can delete these folders and delete video data because there's no one single place that the information exists, it’s distributed and unidentifiable.
VRM has a database of these blocks and knows when they're free or they're used or they're locked.
Block Lists
VRM sends to the camera what's called a block list. And that block list is generated and sent to the camera based on the downtime data. So, VRM will send a block list to each camera of exactly where it's going to send video data four to seven days ahead of time. And that's why if VRM goes offline, the camera will continue to record. Because VRM knows when these blocks are free and when they're locked up in this storage system and has pre-notified the camera. The list is long enough that the camera knows where it's going to send its information four to seven days ahead of time.
That's again the magic of VRM. You can take VRM offline and the camera will still be able to see that storage information and play back video.
VRM System Limits
Each VRM can manage 4 petabytes of storage. So, if we have one system that has eight petabytes, we would need two VRMs to manage each set of four petabytes. And, when you do that, you assign each camera to a specific VRM and assign the storage pool to the VRM.
You must also consider the amount of data throughput that the controllers on the I skuzzy devices can handle.
So, if we’re using a Bosch all-in-one appliance, a Divar IP 7000 for example, it can handle a given maximum bitrate through the controller in that device. When we talk about having cameras that are 1080p, 5 megapixel, 12 megapixel, or even higher resolutions like the panoramic cameras, and you have a real-time video at 30 images per second, your bit rate will get to be very high and you may have to separate the system out a little bit.
NetApp
If, we use a Bosch Divar IP unit, we're limited to that controller’s specific data throughput capabilities. But, if we use a Bosch NetApp storage appliance, you can get it with a single controller or with a dual controller, and depending upon the level of resilience that you want, you can get more cameras to send data to the iSCSI. Plus, the Bosch NetApp controllers have a higher data throughput capacity than a Divar IP, which makes them a really nice design option.
Bitrate Management
One other consideration, especially in systems that require extreme reliability is to spread the bit rate across multiple NetApp storage appliances. If we did the math and we said that we need to spread the bit rate across these two devices, which VRM will do automatically, let's say the bit rate total is 350 megabits per second and 350 megabits per second that I'm going to assign to these two devices. If this device goes offline and the new demand exceeds the remaining controller’s data throughput limit, something's going to get lost.
So, in a design like this, if it is critical that we don't lose any video recording, best practice is to take the total amount of bit rate throughput coming from the cameras that will be going to the storage, and we would say, okay, 350 plus 350 if one appliance goes offline, that's 700 megabits per second, that's in excess of the 550mbps that a single Divar IP appliance can handle in this example.
So if budget is a critical consideration in the system design, we might specify smaller hard drives to keep the cost down, but use three devices, which means three controllers in this example, in the system design, so that if one device goes offline, the entire video data load can then be balanced across these remaining two units, instead of being balanced across all three, that way you don't lose any video in the event of a failure or a device being offline.
So, if we are working with a limited budget, and we limited the design to two Divar IP units and one storage device goes offline at some point, the system is going to lose video because this device doesn't have enough throughput capacity to ingest all of the video coming from the cameras, if it's in excess of that 550 megabits per second in this example.
Organizations that are evaluating systems that are extremely complex, where video loss is absolutely not an option, need to focus on system reliability and resilience, and build failover into the design and project budget.
Working with IT
In many cases the cameras and storage and servers are owned by the security department, and the network is owned by an IT department. And without a lot of really good communication and understanding between the security team and the network (transport layer team, there could be a lot of problems.
Because if IT starts updating switches and many of the security devices are on one switch, IT could knock everything offline. Or if security is doing something specific to a device connected to a switch, they could cause instability in the system.
Communication between departments is critical.
VRM is constantly monitoring the health and the status of all these devices and it's directing all of the devices. VRM telling the cameras where to send data. It's looking at the storage pool and saying, hey, you've got this block becoming available, or that block is locked up.
It's doing a lot of stuff in the background, and because of that, if something creates data traffic flow problems on the network, it could create waves where VRM is constantly trying to correct the problems, meaning re-routing the data this way or the data through that way.
It will be like a wave that keeps getting bigger and bigger and eventually it'll cause a big problem.
Another challenge for systems is when the network is inconsistent. If the connectivity between the cameras and network is inconsistent. And between the storage devices and VRM is inconsistent.
Remember, VRM is constantly checking the health of the camera and saying, Hey, are you there? Yes, what's your status? I'm recording. Good. Okay. Hey, are you there? What's your status of my recording? It's also doing the same thing to the storage devices. It's constantly looking at the storage devices and saying, Hey, are you there? Are you recording? Hey, are you there? Are you recording? Hey, are you there? Are you healthy?
The camera is also communicating with the I skuzzy storage, so it's sending its information to the I skuzzy across the network and into little blocks where it's been told to send the video. If there's a problem in communication between the camera and the I skuzzy, the camera reports back to the VRM that there's a communication problem between it and where it's supposed to be sending its data in these blocks.
And then VRM quickly goes out and looks at it and says, Hey, I can't get ahold of this device either. Maybe something's wrong with that block and it sends new information to the camera to redirect its video data.
If everything is going on and off line, the system is continually trying to correct itself and it starts over-correcting because it never gets time to heal itself.
The security team using these complex systems has to have an extremely good relationship with the IT groups. Equally important is the transport layer group needs to truly understand how the system works. It's important they understand that when we build this design out, instead of there being one switch, maybe we need to design a network that's made up of several switches. And maybe we need to strategically connect devices to several switches so that if there's a problem with one switch, it doesn't disrupt the entire system.
The minute we tell a camera to start recording, it's like turning a fire hose on. The data flow is massive and it's always there seven days a week, 24 hours a day. It’s staying connected and the data has to be flowing to a recording device.
And then you have the devices that are monitoring the health of the system, and the connectivity and the communication, those devices are also talking on the network at the same time.
So, each camera has a massive amount of data that's coming from it.
Most people don't realize when you're attached to the network and you're working on a Word document, for example, if that document exists on your workstation, you're not really sending much data across the network. You may have some overhead, network monitoring and things like that, but you're working on the document locally on your workstation. When you save it and you're saving it over here to a centralized storage device, now you're sending that document over the network.
In a surveillance system, you're using bandwidth on the network all the time.
We have two primary things to worry about
One is, video data is always going to the storage pool, which is massive amounts of data on the network.
The second thing is, depending upon how the network is set up, every workstation that's looking at one or more cameras on a common network is adding that data to the network.
So, for example, if a workstation is looking at four cameras, the network is now sending four cameras worth of bandwidth to storage, and also four cameras worth of bandwidth going to the workstation for live view. So that doubles the amount of bandwidth required.
And then if another workstation looks at the same four cameras, more bandwidth. Now that's three devices that are getting the video data. That's how a simple unicast network handles it.
In a large system, where you may have lots of users looking at live video and you are also recording these massive amounts of cameras, you might require a multicast network design, which is more complex. It's a little more expensive.
Realistically, if we start with a single camera, it is sending, let's call it five megabits of information across the network to the storage for recording. An operator might be looking at the same stream live, that's five more megabits. And a second person may be looking at it, that's five more megabits.
In a multicast network design, the data from the cameras is presented to the network and then the users get the data from the switches, not from the camera. It’s only one times the data flow on the network from the cameras. It handles data delivery very differently.
And the smart parts of the switches are talking to each other and communicating with each other. The request for video is not going all the way to the camera looking for a connection. The camera is presenting its data to the network switch only once and not going all the way to the camera for each request. So, there's not multiple connections to the camera, just one, and the switch is now the source of the information.
In very large, very complex networks where there's a lot to the video system; multiple VRMs, lots of storage, hundreds or thousands of cameras, it can get to be problematic. Add in lots of system users and you're likely going to be forced to use a multicast network.
Thanks so much for reading this explainer article. If you have any questions or want to get started with your Bosch video surveillance system design, our team is here to help. Contact us at support@midches.com
More about Bosch and NetApp iSCSI
Contact us to explore this technology in more detail