 |
One product set being featured at Cisco Live this week is EMC's Service Assurance Suite. The evolution of the SMARTS technology acquired by EMC last decade is part of this suite. Given the heritage of SMARTS, it makes sense for its functionality to be featured at Cisco Live. The sweet spot of the SMARTS technology has always been to help customers diagnose the myriad failures that can occur in complex network topologies. So this week at Cisco Live, the SMARTS team is continuing to showcase exactly how their product has evolved alongside recent developments in networking. In particular, the team continues to monitor software-defined network and network virtualization trends and enhance their algorithms accordingly (e.g. how their technology will interact with products like NSX and Cisco’s ACI). From my perspective inside EMC, however, one aspect of SMARTS that doesn’t get a lot of airplay is that it has extended its capabilities far beyond network endpoints and started diagnosing failures at both the application and the storage levels. Think about this in the context of the diagram below. The SMARTS correlation engine originally had fairly hard boundaries regarding what it monitored and diagnosed. It concerned itself only with the physical path that the data (“1”, “2”, “3”, “4”) travelled over network devices. Indeed, the ability to diagnose the network became highly valued as the distance between application and disk continually expanded during the last decade of the second platform (client/server) data center era. The diagram below emphasizes this phenomenon. There are several networks in this picture (e.g. carrier/cloud, SAN) and SMARTS can perform root cause analysis on the network devices and switches in all configurations. What most people don’t know is that SMARTS technology has continually expanded up and down the stack and enhanced its diagnostic capabilities beyond the network; it can now diagnose up into the application space as well as down into the storage level. At the application level, for example, SMARTS has done WMI integration with Microsoft technologies and can now monitor the processes that run on servers (e.g. exchange.exe). In the context of VMware, SMARTS is working on targeted discovery for vCenter and the processes that run within. At the storage level, SMARTS has become aware of LUN configurations and switch zoning settings, for example. All of this data allows SMARTS to infer complex wiring diagrams between applications and storage, monitor each of them, and pinpoint failures accurately in complex software-defined data centers. Why is this important? Well, software-defined data centers imply automation. The complexity and underlying infrastructure of 2nd platform client-server topologies make it impossible for any one person to diagnose. One last diagram below will make this point crystal clear. As next-generation applications get deployed on top of software defined servers, networks, and storage, failures in any one of the layers is a needle-in-the-haystack scenario. The intellectual property within the SMARTS correlation engine, however, can filter through any cascading noise resulting from a failure and inform the operator “what went wrong” (or eventually feed the failure to an automated recovery service). The beauty of SMARTS is that it is written in a portable, high-level language that can be applied within any cloud management and orchestration framework, be it VMware, Microsoft, OpenStack, CloudStack, etc. SMARTS' persistent mission is to discover and monitor the physical and virtual infrastructure seamlessly. As I mentioned earlier, this applies to both the NSX approach as well as Cisco’s ACI’s approach in providing SDN to a software-defined data center. Steve Twitter: @SteveTodd EMC Fellow |
