The third in the series on SDN monitoring (Monitoring a Software Defined Network, Part 3) talks about the management system architecture. What factors drive the placement of monitoring system components? What drives the overall architecture? Are there any really important factors that determine how an SDN monitoring system should be designed?
I’m starting to see some interest in the concept of monitoring an SDN, with blogs by Cengiz Alaettinoglu, SDN Management: Risks and Challenges and Tom Hollingsworth, Focus on SDN Tools Obscures SDN Benefits.
I’m sure that there are vendors who suggest that their controller is all that’s needed to monitor an SDN. They may be right, if they’ve done a lot of work to add the necessary functionality. But I’ll bet that most vendors (and probably all) will have cut corners to get their controller released and that it doesn’t include all the functionality that is really required to adequately monitor an SDN.
When talking with vendors about SDN, make sure to ask how their system will facilitate troubleshooting when things go wrong. Learn what you’ll need to do to diagnose a bad link that’s preventing the controller from talking with a portion of the network. How will the SDN report that a controller died or rebooted? Will the system enable the network team to quickly detect and correct problems with links to critical application servers? In other words, don’t jump into SDN without understanding how to integrate it into your current IT operations.
-Terry