To understand the implications of data protection and disaster recovery in a “software defined data center”, I need to first make sure we are on the same page as to what that term even means.
Defining SDDC (software defined data center)
Essentially, what the industry is trying to do is separate the control and data paths from the various stacks that make up a data center, such as networking, storage, and compute. The control path is the “how” data moves and the data path is the physical movement (or storage) of the data. We don’t want both of these pieces of logic to be in the same stack, let alone tied to a particular firmware/hardware.
Why do we want to do this? Well, when the data and control paths are bound to a physical piece of hardware, the data center and IT staff is less agile. To make any kind of changes in the infrastructure, it always involves physical changes, such as cabling changes, hard programming of the network switches or changing policies in each of the storage arrays. The IT staff has to log into the hardware and manually change the policies and settings, often differently for each networking and storage and compute equipment they have.
In an ideal world, the data center is fully automated and adaptive to ever changing business workflow needs… dynamically reconfiguring the flow of information in the switches, dynamically deciding which storage array the data is destined for and how it is to be protected.
The underlying hardware should not pose a factor into how these decisions are made and most importantly, humans (IT) should not be pulled into making these changes on an on going basis.
History of how the industry started moving towards SDDC
So the first steps in the industry started out with dynamically changing network profiles. While not getting into too many details, this concept is known as software defined networking or SDN. It was predominantly driven by openflow. Here, the switches maintain the data path, but it’s control information (such as which port a certain packet needs to go out of, or if it should be dropped) is determined by a separate control path running typically on a server. There you have it, now the IT staff - if they have an all openflow switch infrastructure – can determine how to route all the data center traffic just from one centralized server console.
With storage, software defined storage mostly implies taking the software features such as virtual volumes, quotas, replication requirements, etc out of the arrays and into a central server while treating the disks, as just a bunch of disks.
Storage complicates the issue further by the lack of any good clustered file system that can sit on top of dumb commodity storage arrays. In a nutshell, SDS is still a lot of good thought but less action.
How can data protection be part of the SDDC
Well, what does all this mean to data protection? The first thing I realize is that there is no unified “SDDC stack” yet. The concept exists and is being evolved, but there is no concrete standard (such as openflow) as to what SDDC needs to look like, and specifically what SDS needs to look like (SMI-S did not get very far).
The first thing data protection products need to do is be able to handle the SDN and SDS software stacks as a specific application to be snapped, backed up and replicated. Just like we treat databases as special software stacks. That is, we need to snap the control stack (SDN or SDS) and its data stacks together to assure the equivalence of “application consistency” that we offer today. Let me dig into that a little bit more… today, there is a difference between crash consistent and application consistent backups. Crash consistency implies the data is intact, but the application may not act exactly like it was behaving when the disaster happened. So we now implement various strategies within the applications to enforce application consistent snapshots. In a software defined data center world, we need to extend this to reach into the control stacks of the arrays and the network controllers to make sure that the entire data center can be brought backup online exactly how it was before it went down.
Secondly, we need to integrate the data protection logic, such as AppAssure into the SDN and SDS stacks directly. We can’t be a separate stack or implemented in a separate layer. The whole orchestration of the data center needs to be orchestrated in one console, by one set of policies and perhaps by one congealed software stack. Let me give you an example here… As an IT administrator I want to be able to set a policy in my SDDC console that says “At 2AM add 10GB extra bandwidth to XYZ Oracle application just after snapshotting the entire stack. Replicate the stack to datacenter B and run data center B in standby mode with 5GB bandwidth”
One day we are going to get there, and pieces are falling into place. We just need to be in sync and at pace with the rest of the industry.
How do you see data protection fitting into a SDDC? Let’s discuss in the comments.
Image may be NSFW.Clik here to view.