Building the Navisphere architecture from scratch was driven by some of the use cases and requirements listed in my last post, including: the ability to manage a "family" of CLARiiONs, the ability to scale in both trays of disks and LUN counts, and the ability to manage fiber channel SAN configurations for the very first time. Customers also wanted "ease-of" capabilities as well.
We proposed a layered architecture upon which all future Navisphere tools would be based. The architecture, proposed in 1995, still exists (albeit in modified form) today. The 2008 version of Navisphere has added new layers, which I'd like to cover in future posts.
The architecture consisted of four layered building blocks: a portability layer, a connection layer, a factory layer, and a schema layer.
The Portability Layer
The need for a portability layer stemmed from the fact that the Navisphere architecture would need to run on a variety of platforms. Keep in mind that the CLARiiON internal software (FLARE) of the 1990s was NOT embedded Windows XP; it was a proprietary operating system. There was no "FLARE management server" listening to a network port. The management server would need to run on the platforms connected to CLARiiON. A portability layer was required that would run on several platforms, e.g. Windows, IBM's AIX, SGI's IRIX, Sun Solaris, etc. The architecture required a layer that isolated the software from details such as endian-ness and word size. Navisphere has a portability library that serves that purpose.
Another important capability of the portability layer was to support the ability to gather server-specific information, such as operating system type and name, as well as hardware information about the server (such as host bus adapter type and name). Obtaining this information, and then pushing it down to the CLARiiON, was a customer requirement that promoted ease-of-use when managing a SAN.
The Connect Layer
Each platform in a SAN had its own nuances when it came to passing SCSI management commands (e.g. mode sense/select) to a CLARiiON. The details of how to send SCSI commands through a Solaris pipe, or a Microsoft pipe, were of no particular significance to the upper layers of the architecture. Therefore the Navisphere architectural component known as the connection "pipe" had a strong API contract with the upper layers of the architecture, but the implementation was fully encapsulated and varied from platform to platform.
The Schema Layer
The Navisphere architecture has an object model to represent the logical and physical components of CLARiiON systems. This object schema pre-dates the common information model (CIM) and SMI-S, but the internal Navi model mapped quite well to the standards (EMC's Solution Enabler prodect integrates with and supports CIM).
The physical schema modeled subsystems, cabinets, and physical devices (disks, memory, etc). The logical schema modeled items like LUNs and cache within the context of the subsystem. This part of the architecture was originally implemented as a library; storage management applications would build their business logic on top of these objects.
The Factory Layer
The factory layer existed in between the schema layer and the connection layer. The "factories" produced the "objects" in the schema (e.g. LUNs and disks). The details of the the object construction were hidden by the factory layer. For example, the factory might build objects by directly interfacing with a CLARiiON, or it might fetch these objects from a server process on another machine. The application didn't have to worry about these details because the factory layer did.
Putting It All Together
The architecture as described above passed the "customer requirements and use cases" test. In other words, we could map the desires of the customers (ease-of-use, reliable, fast) onto the architecture. The next step was validating that any complexity was bounded and testable. Each layer supported a fairly exhaustive set of automated test to validate correctness of the architecture.
This architecture has lasted. All four levels still exist, albeit INSIDE the CLARiiON. When CLARiiON moved to a Windows Embedded XP architecture, it enabled these layers to run directly on the box. New layers were added that were "browser-friendly" (e.g. HTTP XML protocols, Java applet technology).
Many of the components of the Navisphere architecture are being re-used within the company in other products; Invista is one example of a product that has re-used the Navisphere architecture, and Solutions Enabler is another.
The Navisphere architecture continues to address scale moving forward, in terms of number of CLARiiONs being managed (currently supports hundreds) as well as higher LUN and disk counts. It's an excellent example of a modular, testable, quality architecture that continues to stand the test of time.
Steve
Working on Navisphere during those years is probably my fondest professional memory. I came right out of college and almost directly into analysis and design meetings about these layers that Steve's described. It was a very collaborative environment, with lots of peer review and discussion.
Out of all the projects I've worked on, it was definitely the most "playground"-like, and I'm glad to see that the decisions we made back then haven't completely failed in the intervening years.
Posted by: David | July 15, 2008 at 06:45 AM