Published: 15 Jun 2003
My previous article, "Simpler SAN management--please," uncovered the burdens and associated costs of administering independent management points for the devices in your storage area network (SAN) without a comprehensive storage resource management package. Inflated staffs, data lost through failed backups and lackluster application performance are just some of the inefficiencies in today's data centers.
These well-documented inefficiencies existed before the emergence of SANs. But the emergence of SANs gave us the functionality and intelligence in hardware and protocols to effectively manage, provision and report on our application storage and its pathways. Now, we're finally gaining complete control over the storage infrastructure and the business processes that rely on it.
|ECC's tiered architecture|
This month and next, I'll put two products under the proverbial microscope that seek to enable that new level of control. This month, I'll take a look at EMC ControlCenter (ECC) 5.1 and next month I'll size up Veritas SANPoint Control 3.5.1 and compare the two products.
I chose these products not only because the vendors have huge footprints in our data centers, but also because they represent competitive offerings from two different perspectives. Although EMC is making its presence known in the storage management software market, its reputation in the field still largely rests on its hardware. And with Veritas software tightly integrated into our volume management, clustering and backup/recovery solutions, I thought it would interesting to test its product abilities and corporate partnerships to see if we are at the point where we can completely rely on a single software vendor to provide management solutions for the various types of hardware we have to support. It begs the question that all of us have probably asked in our childhood travels at one time or another: "Are we there yet?"
In comparing them, we'll look at the soundness of their architectural designs. Do they permit scalability and redundancy; the discovery of heterogeneous SAN resources and their connection points; the automatic provisioning and management of these SAN resources; policy management, including application association and service level agreements and reporting? That's a tall order to fill--short order cooks need not apply because basic discovery and zoning is no longer acceptable as the main features of solutions in this management space.
ECC 5.1 Open Edition has a three-tier client server design that integrates both current EMC product offerings, as well as newly released offerings in one console. ECC/Open Edition is composed of services called open integration components (OIC), and includes the console, server, repository, store(s), master agent and storage specific-agents (see "ECC's tiered architecture"). These common services provide a means for administration and access control, device mapping, relationship views, alert management and enterprise framework integration. And although ECC's support matrix lists non-EMC hardware, EMC's Symmetrix and Clariion product line is the greatest beneficiary in terms of available functionality to date.
The console is a launch pad for access to each management point of your SAN resource. It's browser-based, can be launched from any Windows or Solaris desktop and supports multiple instances of the ECC GUI by launching multiple browsers from any number of hosts. Essentially, this means that in an organization where each business unit has its own support team, the storage administrator can provide condensed views that pertain only to that business unit. This implies enhanced security and more streamlined functionality, which also improves efficiency.
Object-oriented programming is evident in the user interface, as the menus and tabs remain consistent while moving between the various application plug-ins under ECC's control. This brought familiarity and lowered the learning curve while moving between management applications. The console is made up of three parts--the menu/task bar, navigation tree and target area--with each part allowing the user to delve deeper into the storage management realm until you reach a single device, whose status is dynamically updated as events take place on the SAN. The ECC console is organized by functionality, which is good because it more closely resembles how we might approach the tasks of SAN resource management. These tasks are administration, monitoring, provisioning, performance management and data protection.
The console communicates with the server over TCP/IP. The server provides login authentication, management and communication between distributed agents. You can also use the console to create reports and manage policies. The console distributes data collection and alert policies to storage specific agents managing SAN resources.
The ECC server runs on a Windows 2000 server and in order to gain access, the storage administrator needs to have a login account on this server. For those concerned about Windows security, remember that best practice is to locate such a server on its own management LAN with its own security policies. Subsequently, the ECC administrator can provide some subset of functionality to departmental storage administrators on a user name or group basis. The distribution of user management doesn't affect change management, however. Each change initiated at the user level is logged in the repository and is displayed from the Command History menu. At a lowest level, subsets can only be defined at the storage element level (i.e., disk array, switch, database). The exception to that rule is the Symmetrix, which can have its resources managed at the volume level.
EMC's ControlCenter server runs a master agent that manages and communicates with storage-specific agents over TCP/IP and can run on a Unix, Windows or a mainframe system MVS host. These client agents are responsible for managing the storage elements that are assigned to them for control and management by the master agent. Management tasks consist of data collection, status monitoring and command execution on the storage element. A nice management feature of ECC is that you can install and upgrade client agents from the server, which reduces the overall management effort of the solution.
Client agents receive their policies via the server, after which they are stored locally to reduce the dependency on the server. Secondary agents that run on a separate host can be configured to support the primary agents should the hosting server fail. While most of us would be happy to get a single pair of eyes into our storage infrastructures, having redundancy at this level is a bonus because it comes with no additional cost.
Policies control the polling frequency of the storage element by the client agent raising threshold alerts and status events to the operator. Once a violation has been detected, you have the option of autocorrecting the violation or simply raising the event to an operator's attention and possible action. ECC's autocorrection feature is available with the Automated Resource Manager (ARM) add-on and implemented with scripting, which gives the user more flexibility in their approach to policy management.
Also included with ARM is ECC's reporting feature. This gives the user the ability to create and run reports against the repository either manually or on a predefined schedule. Additionally, the Workload Analyzer has the ability to collect, archive and report on historical performance from the host or Symmetrix point of view.
That delivers the immediate benefit of having the ability to see how network utilization is rising over time. If, for example, you are administering an application with predictable inter-switch link (ISL) usage, and then add an additional application (initiator) to feed traffic over the same ISL, you can determine at which point the network traffic of the initial application(s) starts to degrade. Without this historic feature, ISL congestion that occurs in the middle of the night wouldn't be noticeable, especially if the workload is completed in a timely fashion. This is a classic example of ISL oversubscription, which saves budget capital in the initial design of the SAN. However, the oversubscription ratio is at best an educated guess and shouldn't be considered reality. With Workload Analyzer, you can determine the exact point at which an E_Port is throttled.
The repository is a relational database that's modeled after RAB1 (.dbm flat file) data structures and was reportedly chosen to eliminate the need for staff with DBA skills. The repository contains configuration data, status, utilization and capacity data for storage elements in the SAN. This data represents both current and historical data provides the raw functionality for point-in-time report generation. In addition to the GUI, the user can access data elements in the repository using SQL or XML.
ECC's repository is populated by store(s) that convert incoming data from the storage-specific agents. Conversions are performed by specific plug-ins that process the different types of data coming from the managed agents. While processing the data, the store(s) can also notify the consoles of the changing events in the SAN, updating and correcting visual links between resources. There can be more than one store available for allocation to an agent sending data to the repository. Allocation occurs dynamically and is based on load and availability of the store(s) in the environment. Again, adding scalability and availability to the solution.
Storage-specific agents run on hosts (i.e., Unix, Windows, MVS) that have access to the storage elements that they're managing. And although these agents support non-EMC hardware and software, the functionality of these agents depends on the particular vendor's willingness to share its product's intelligence. As for disk arrays, with the exception of Hewlett-Packard's StorageWorks line of products, don't look for the same functional abilities for non-EMC hardware as you would for EMC hardware. To ensure that you actually get the functionality you need, check with EMC for interoperability, and put pressure on your other vendors to share the intelligence of their products. Of course, this is contradictory to patent holdings and market share, but how else are we to manage heterogeneous storage environments with any hope of reducing the reported 7:1 expense regarding management to hardware ratio?
A few of the storage-specific agents that can be integrated into ECC/Open Edition are Array Management, Storage Network Management and Host Management. Through these integrated components, EMC touts its ability to bring heterogeneous support of various products under ECC's management. A complete list of these supported products can be found in ECC product documentation on EMC's Web site.
Array management--to a greater or lesser degree depending on product--can be achieved by accessing the management point of the hardware via a shared API. However, without the shared API, only basic statistical information can be gleaned from the array--no management of storage ports, no LUN creation or other volume management tasks. Simple read-only access to performance data is what you can expect from hardware intelligence that's being supported, but not shared.
That doesn't mean you shouldn't consider EMC's ControlCenter if you're managing a heterogeneous storage network. However, I'll say that the more EMC and perhaps HP StorageWorks equipment you have, the more likely this solution will be of benefit to your management budget.
Heterogeneous SAN management is accomplished using EMC SAN Manager, which recently replaced Enterprise Storage Network Manager. SAN Manager aggregates the administrative functions of multivendor SAN gear into a single interface, thereby reducing the need for a separate management application for each brand of device. That, in turn, can reduce administrative man hours and save expenses on items such as licenses and servers to host each management application. I say reduce--and not eliminate--because all of the devices functionality may not be available to SAN Manager. Depending on the relationship with the vendor, you are likely only to have discovery, zoning, performance and health monitoring available at this level.
In fact, much of this functionality can be obtained by interfacing with the Fibre Channel (FC) protocol alone, without any sharing of information by vendors. Therefore, the potential procurer of such a solution should at least hold the vendor/product accountable for providing that amount of functionality. If the product can't deliver that functionality, it's doubtful that the software engineers at the organization are going to be able to bring a more useful and competitive product to market.
This somewhat limited ability to completely manage a SAN switching device for example, is obviously due to vendor competition. Almost all SAN hardware that can be discovered by SAN Manager has its own native management application developed and being sold by the manufacturer. That reduces the likelihood that any real management functionality can be had by an application developed elsewhere.
What EMC has done with SAN Manager is give you the ability to summon those native applications through its interface. That's the way to go as long as the support staff of the vendor who you purchased the solution from is up on interworkings of the summoned application. What you don't want is to have to interface with a second vendor to get resolution, thereby increasing the chance of finger pointing.
SAN Manager does have the ability to backup and recover heterogeneous switch configurations, simultaneously configure zones and LUN masking and provide your SAN with end-to-end path management. Having the ability to backup and recover heterogeneous switch configurations is a big win for the largest of sites with the most diverse compilations of hardware. The autopath wizard simplifies the process of switch zoning and LUN masking by completing both tasks in one operation. That reduces human error and streamlines the operations associated with SAN security. End-to-end path management is a dream come true for the troubleshooter engaged in an exercise with several hops between the initiator and target.
EMC has brought host management to ECC by way of ARM. ARM provides for the provisioning, monitoring, real-time reporting and alert notification of such data structures as databases, logical volumes and file systems on Unix, Windows and MVS operating systems. Accomplished by alert notification, administrators can develop autofix scripts to launch upon the receipt of an event from a managed data structure to enhance lights out operations. ControlCenter 5.1 is free with the purchase of one of its application plug-ins. With the plug-ins priced as follows:
- Automatic Resource Manager (ARM): $5,800
- StorageScope: $3,300
- Common Array Manager: $1,000
- SAN Manager: $16,000
- Workload Analyzer: $6,600
In conclusion, EMC's ControlCenter product is definitely a next-generation package. It provides intelligence over and above basic discovery and zoning with its own engineering efforts directed towards backup and recovery, streamlining operational tasks by encapsulating long tedious procedures into single operations, and heterogeneous support. And although management functionality is limited in some of ECC's advertised supported hardware, an effort has been made to forge relationships with other vendors by integrating their native management applications into ECC.