Local area network disaster recovery planning is frequently overlooked, although many IT functions depend on the LAN. Jeff Boles, senior analyst with Taneja Group, recently spoke with SearchDisasterRecovery.com Editor Andrew Burton about how to prepare that unsung hero of networks – your LAN – for disaster recovery, as well as whether virtualization can help streamline the process.
Where do you start with local area network disaster recovery?
The physical LAN in a lot of businesses, especially in small- and medium-(size) businesses, tends to be underprepared for disasters. You always expect it to be working. You don’t put a whole lot of thought into how you’re going to recover it or get it back up. Basic, common-sense layout (and) configuration capture is a good place to start. If you look at guys in the trenches, one of the most important tools is to have a connectivity document so you can figure out where stuff goes in your office environment or your network environment and have some idea of physical connectivity.
Don't forget that there is a layer of logical connectivity with this physical LAN at the same time, so you really need to carry out two dimensions of documentation: the physical LAN and the logical LAN. And, you need to make sure you understand how your physical wiring is related to that logical connection. Make sure you have your subnets and your addresses and everything else documented and some idea of what kind of applications are running across your network, especially when you’re trying to plan for recovery of those applications.
And then, as the final ingredient, most devices have the capacity for capturing configuration files. Typically, those configuration files are tagged as XML documents and you can dump that into some kind of spreadsheet so you can reload that onto some other type of device. But, be sure to consider the potential changes in devices in the future. If you’re switching devices at some point in the future, especially after a disaster, you may have to port that configuration to another type of switch or router and you want to know what the key elements are that you’re going to have to reprogram.
There are a whole lot of specialized tools that can help you with your documents and help you capture some of that, like SolarWind’s tools, for instance. So it’s worth looking around at some of those lighter-weight, lower-cost tools because they might help you simplify that process and automate it so you’re keeping that information up to date.
I also want to talk about what trends are going on in this space as well. The big trend is virtualization, and virtualization can change a lot of what’s going on in your network. The way you traditionally approach local area network disaster recovery, you might be touching switches and routers and that type of stuff really frequently, and making changes as clients come and go, and as you deploy things from a development environment into a production environment.
Virtualization can change a lot of that and take a lot of change out of your physical network if you’re using a virtualization solution that has the capability to network inside the hypervisor. You can do some really cool stuff in the virtual infrastructure to make your physical network pretty static. Virtualization may simplify the physical network, and once you have it in a virtual environment, you can capture it much more easily and port it to some other place. So if you need to port it to another place, like a hypervisor up in the cloud, you could do that with your configuration in the virtual environment without having to worry about changes to your physical environment.
Do you think virtualization is making local area network disaster recovery planning more important?
In a virtual environment, you may run many more services over that LAN and your LAN may grow in sophistication because you may want to do things like multipath and have high availability across many connections.
You want to keep it static, and you want to take (out) that chance for mis-configuration and disaster in your physical environment. Local area network disaster recovery becomes more important, but it becomes easier to manage some of the change.
Since so many IT functions rely on the LAN, do you see any trends around virtualization that would make local area network disaster recovery planning easier or more difficult?
I think it could make it easier. If you move into a virtual infrastructure, you can delegate those responsibilities for certain parts of the network and the network team can have responsibility for the other parts. You can choose to delineate that kind of breakout at the hypervisor layer – that is what we commonly see going on in the marketplace today, especially as the server teams take on some of these network responsibilities inside the hypervisor.
The hypervisor has enabled the server admins to manage settings and delegate (services) much more flexibly and without disruption. That keeps the physical network much more static and simple, and lets the network guy do his job better, and let him figure out where his job ends better. At the end of the day, I think it simplifies DR planning and elevates the service level with which IT can deliver these services.
Can you offer any additional local area network disaster recovery best practices?
One of the most important things for the LAN is to take a big-picture view of your LAN infrastructure and plan into the future. At the end of the day, you want to have a roadmap in mind. Maybe you’re moving some of this stuff into the virtual infrastructure if you start to virtualize, or if you are already virtualized.
You want to dictate what kind of services you are going to deploy and where in your LAN. So you want to think with a pretty long-range roadmap in mind and deploy services on your LAN. That helps you define the kind of architecture with which you can deploy things, like multipathing and make sure you have the right number of high availability failover links structured into your network.
So even if you’re not virtualized today, you want to think about that, and think way out into the future as you deploy anything in your LAN. You also need to think about simplicity and where the changes are going to be in this infrastructure. So ‘static and simpler’ is the rule of thumb here: Think about how much of your physical infrastructure can you keep static – because that helps your documentation – and really helps you build a network infrastructure that is going to be around for awhile. Also, think about how you build a core to your infrastructure that is designed for the future and very static.