A little while ago I was imbibing in a quality craft beer or two (or seven, but who’s counting?) with a friend. This particular friend also happens to be a talented network engineer, and we began discussing some of the new technologies he’s seeing among his customer base. As is wont to happen when one mixes booze, nachos, and IT geeks the conversation drifted towards Software Defined Networking (I did mention we were IT Geeks, right?). That got me to thinking. Since we’re a network and systems management software vendor, what would our role be in this brave new world where controller devices auto-magically configure LAN, WAN, and wireless gear such that applications continue to function without any hiccups? Can SDN and management co-exist? The answer is an emphatic “yes.” To paraphrase Merlin the Magician from the story of King Arthur “… [SDN] and … [Management], there …[can] never …[be] one without the other.”
For the uninitiated, Software Defined Networking (SDN), according to Wikipedia, is an umbrella term encompassing several kinds of network technology aimed at making the network as agile and flexible as the virtualized server and storage infrastructure of the modern data center. Based on this definition, it should be obvious why one cannot exist without the other. Software Defined Networking and Network management solve different problems. You should no sooner use a Philips head screwdriver to attach a couple 2×4 boards together, than rely on SDN technologies to handle all of your systems management and monitoring tasks.
As regular readers of this blog know the topic of particular interest to us are the best practices surrounding systems and network management tools and processes. To that end, what considerations should be taken into account when evaluating whether or not your management system and SDN platform will play nicely together?
A common refrain we hear from customers is, “Sure you’re watching my systems and networking gear, but who’s watching you?” The same can be said of SDN technologies. Just because engineers have policies to dictate how a network is supposed to work doesn’t mean it’s working that way. Your Network Management System (NMS) should act as an independent arbiter to discover your network and ensure the architecture is working optimally.
One of the beautiful things about SDN, especially in very large and complicated networks, is that that there isn’t a need (or necessity) to manage the individual configuration on every device. However, who’s watching the watcher? Although policy definitions usually define what’s configured on a given device, how do we audit to make sure everything is configured correctly and hasn’t been tweaked or tampered with?
And, of course, the most important consideration in an SDN environment (and the bread and butter of all NMS tools) is the acronym FCAPS (Fault, Configuration, Accounting, Performance, Security) management of the SDN controller itself. The controller device(s) are the linchpin of your entire network architecture, upon which your applications depend. Therefore, it should go without saying that it needs to be tightly controlled and strictly monitored.
This blog doesn’t necessarily recommend or condone making major system architecture decisions while under the influence of copious amounts of craft beer and nachos. However, if you must, limit yourself to a couple beers and make sure your nachos have real cheese and not that liquid ballpark stuff. And keep in mind that SDN is slowly becoming more common. As server, storage, and network virtualization continue to gain traction in the business technology arena, that pervasiveness will only grow. You want to make sure your NMS tools can keep pace.
Netreo has the IT Monitoring tools you need.
