Last month, we looked at EMC Enterprise Control Center (ECC) Open Edition (see "EMC raises the bar for SAN management")...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
with the intention of comparing its abilities to Veritas SANPoint Control 3.5.1. Although heterogeneous support didn't amount to full control of non-EMC products, the engineering groundwork has been laid and marketing positions taken for ECC to evolve into a useful and nondiscriminatory storage area network (SAN) management offering.
Veritas has engineered and built on another storage management offering in SANPoint Control 3.5.1. SANPoint Control centralizes the management of storage resources into one console by exploring your SAN fabric and discovering its supported hardware and software components. In addition to discovery and zoning, real-time event reporting--along with policy-based end-to-end management and provisioning--ensures that it can be considered next-generation and capable of sparring with EMC's ECC.
|How SANPoint Control works|
A key requirement of business continuity is that there's sufficient distance between data storage locations so that a disaster that wipes out one site is unlikely to wipe out another site.
In fact, the architectural designs of these two product offerings are similar--so similar that one would think these two industry giants are losing software engineers to each other. It's like having the prototype of an NBA center in Shaquille O'Neal: Why would you want to change that basic design? So, each product's value will be determined by its ability to expand on this sound design by developing intuitive interfaces, engineering interoperability across vendor offerings and streamlining administrative efforts across the SAN. But isn't this how it should be?
SANPoint Control is based on a distributed client-server architecture and is represented by three components: the SANPoint control console, server and agent (see "How SANPoint Control works" on this page). These components are supported on the latest versions of Solaris, HP-UX, Windows 2000 and NT platforms. Communication between the console(s) and the SANPoint Control server happen over a TCP/IP socket on port 2802 for the SAN access layer (SAL) or port 5431 for policy management. If there's a conflict with another application, you can redirect this communication traffic to other ports. By default, the simple network management protocol (SNMP) is facilitated by the server listening and polling on ports 162 and 161 respectively. However, the server and configured agents communicate via XML over an HTTP connection on port 2802, which can't be changed.
SANPoint Control's console
The console is a browser-based XML recipient that presents data retrieved from the SANPoint server, or more specifically, the SAL. The data seen in the console is an aggregation of the hardware and software components discovered during exploration. Through this interface, the user is able to engage the API functions of a supported device and thus manage that particular piece of hardware with the same level of control possible with a management application that is native to that piece of hardware. In addition, there are also a few storage, server and database management software solutions that can be discovered and managed. For instance, Veritas Volume Manager and Cluster Server--as well as NetBackup--can all be discovered and launched from the accommodating server. Although the list of applications that can be discovered are mostly Veritas products, the list also includes Oracle and MS Exchange.
Like ECC, the console is divided into three parts that are properly titled the tree view, the display table and the details view. The tree view is on the left side of the interface and contains a directory tree for each SAN resource. From there, you can filter out the presentation of devices by their type or association. Within the tree view frame, the fabric, storage, hosts and group views give the user the ability to display only the devices they're interested for that particular operation.
If you're only interested in fabric networking devices, you can limit the displayed data to only those devices. The storage and hosts views are more comprehensive and detailed than the fabric view in that they display connected and unconnected (no fabric login), zoned and unzoned devices and hosts wired into your SAN. In addition to managing the zones of the devices and hosts in these views, the hosts view also lists the discovered applications currently supported under SANPoint Control. And with group views, users can define views of a specified group of SAN resources associated with a particular department or application. This streamlines operations in a few ways, including letting the user to present accounts payable storage resources to the IT administrative staff responsible for financial applications.
The display table shows the next level of objects under the highlighted parent object. You can customize the table display by selecting the columns of information you've determined to be most important to you and only include those columns in the table.
The details view is composed of a set of panes or tabs. Each pane provides information in a different format, depending on what SAN object or group has been selected in the tree view. The topology, attribute, policy, alert connectivity, OS handles, host bus adapter (HBA), security and collectors panes collectively present topology and tabular data concerning the selected SAN resources' attributes, relationships, policies and statistical counters. Without a doubt, you'll be focusing most of your attention to this frame of SANPoint's console.
The SANPoint Control server is at the heart of this SAN resource management solution. The SANPoint Control Server interacts with the SAL layer to discover SAN resources, provision storage and maintain a real-time data store, as well as provide for access control (e.g., zoning, LUN Security), policy management and reporting.
Discovery is made possible with several explorer modules within the SAL process (sald). Each explorer module is only interested in the SAN components it was coded to discover. There are HBA explorers and array, zoning and tape explorers, as well as a management server explorer. Veritas made the SAN access layer more flexible and extensive by allowing additional modules to be added to the SAL in future releases. This means that with each added module, you need to upgrade the sald process--possibly taking other working modules out of commission should there be a problem with the upgrade. Test each new release of the sald process in an isolated area with the newly added hardware or software that SANPoint Control is managing.
There are two methods of discovery: in-band and out-of-band. In-band discovery takes place over Fibre Channel (FC), using the protocol's common transport (CT) as a communication medium. Out-of-band discovery can take place over TCP or SNMP using IP as the communication medium. Applications requiring the highest levels of availability will want their storage assets being managed and monitored over both transports for redundancy reasons. For direct-attached storage (DAS), the SAL will use a form of SCSI pass-through or other proprietary method for discovering LUNs.
Provisioning, or storage access control, is brought about through zoning and LUN security. Zoning is accomplished by SANPoint Control interacting with the switch vendor's API. Discovered zones can be changed and new zones created either through the zoning wizard or the command line interface. Vendor cooperation isn't equal in this area of management. For example, switch port hard zoning is only available with Brocade switches. All other levels of management functionality appear to be even.
|SANPoint Control's strengths|
LUN security is the collective term used to describe the tasks involved in binding a storage unit to a storage port on an array and masking that storage unit to a particular host. Veritas includes a LUN security wizard to streamline the tasks of provisioning storage into one operation. This feature is a must-have in all SAN resource management applications if they are to plug the leak that's letting money flood out of IT budgets.
The real-time data being collected by the explorers is staged into the SAL data store. From there, the SAN access layer agent translates information in the data store into XML-formatted files that are to be passed on to client consoles for field population. The SAL agent is also responsible for user authentication when commands are passed to the server, and it facilitates communication between the server and other hosts running the agent.
SANPoint Control database server
SANPoint Control also requires a second database structure in the database server. The database server of choice is Sybase's Adaptive Server Anywhere, which is an ODBC-compliant relational database. The database is installed when you install the SANPoint Control server and is used to log alarm data coming from the alarm service in your server. By default, the database stores data over a 30-day period. However, hourly updated data starts to be aged out of the database after 15 days, with less frequent updates aged out after 30 days. Using a compliant relational database gives the administrator the ability to export alarm data to various graphical applications for executive review or to track changes.
Alarm data can be logged on a user-configurable frequency of time, varying the space requirements of the database as the element of time is reduced. Another variable in the database space requirements is the number of device ports that are in your SAN. Device ports are the variable, not simply the entire device because, while an FC-attached tape drive may have only one port, a SAN switch will have more than one port, with each port having its own statistical alarms.
You can perform a hot backup of the database server with the dbbackup utility in Sybase ASA. This utility copies the database file visdb.db and its log file from its installation directory to your specified directory. You can't use OS commands to copy these files while the database server is active--you must use the utility to ensure data integrity is maintained.
However, the restoration of the database server must take place while the SANPoint Control or Sybase ASA server is stopped. Once stopped, the administrator needs to preserve the existing database and log files before copying the backup copy of these files to the production directory. Before restarting the database, synchronization between the backed-up database and the current log file may be desirable. This is accomplished with the dbeng7 utility, whose syntax is documented in the admin guide. After synchronization and copying the files to the installation directory, simply start SANPoint Control as you would normally.
Policy management is implemented through SANPoint Control's policy service. The policy service is responsible for managing the relationships between SAN resources and the statistical thresholds being monitored by the administrator. A policy then is defined by the monitoring of statistical thresholds, the raising of an alarm, and the appropriate action to take when a condition has been met. The supported actions include e-mail, invoking scripts and trap notification to the console or other management framework (e.g., Hewlett-Packard OpenView).
SANPoint Control 3.5.1 comes bundled with user-configurable policies. This helps make the solution usable in a shorter time than expected. The policies shipped are reliant on the monitored device's management information base for access to its management properties.
The alarm service complements the policy service by employing collectors to gather statistical and performance metrics from the SNMP and SAL layers. The alarm service then feeds this information to the policy service that acts upon the received data according to policy. Collected information consists of SAN traffic, error and status changes, as well as environmental data. All of this can be included in defining additional policies for the purpose of tracking service level agreements between your vendors and application support team. You may have a particular switch port with an increasing number of CRC errors over a period of days. If you're administering a SAN at a brokerage firm, wouldn't it be nice to have this alarm raised before the failure and remove a possibly failing GBIC as a controlled event instead of at 9:30 on a Monday morning?
SANPoint Control ships with approximately 40 out-of-the box reports that can be modified and executed against the database server. Reports include data relating to inventory and capacity, as well as performance. By using these reports, I was able to see exactly how much total storage was available in my SAN, how much storage was allocated to each host and even each application, depending on SANPoint Control's ability to support that layered application. For example, with the Oracle Overview feature, you can report on the instance name, version and tablespace characteristics in a glance. The firmware and device driver versions of SAN resources can also be tracked using the reporting feature. This information--along with reports detailing how devices are connected--can be invaluable during certain disaster recovery scenarios.
And like ECC, you can define performance reports that give you some idea of port utilization over some defined period of time, giving you eyes into the data center during overnight processing. Capacity planning is obviously the greatest beneficiary of this feature.
Almost equivalent in functionality to ECC's storage-specific agents, the agent extends the view of the server by exploring SAN objects that may not be available to the server (e.g., SAN islands). The agent is made up of several explorers that are called upon by the server to "walk" the connected SAN to discover and report on its resources. Because SAN islands are so prevalent in today's data centers, agents are necessary to aggregate status and statistical information into the data store. Before SANPoint Control 3.5.1, the server and agent couldn't reside on the same computer, thereby making the overall solution more expensive. Therefore, if you have an older version installed, apply the appropriate patch to gain this and other new features related to the patch.
SPC 3.5.1 pricing starts at $20,000.00 for to manage 32 ports and starts to climb as application-specific agents (e.g., Oracle, MS Exchange) are added.
The solution addresses many of the pain points experienced while managing SAN resources. The provisioning and grouping of SAN resources, monitoring and policy creation, as well as reporting can all be found in SANPoint Control 3.5.1. The scalability can be seen at the agent level, where control agents can be deployed as the number of SAN ports increase. Heterogeneous support of OS platforms, SAN switches and the storage resources that connect them are vast enough to include most IT applications, with the exception of the mainframe.
A support area where SANPoint Control is lacking is in storage resource management (SRM). It mostly addresses the management of SAN resources from the aspect of physical and logical availability to the application. What SANPoint Control is missing is an SRM module that allows the administrator to set policies on who, what, where and why data is stored on these SAN resources. But with the recent purchase of Precise Software Inc., Veritas gains W. Quinn, which is a sound SRM product and stands on its own merit.
Which product is right for you?
If you had the opportunity to read last month's article on EMC ECC, you have now witnessed that these storage resource management solutions are not far apart in terms of design and product offering. Both have central servers that call upon distributed agents to gather protocol data and populate some form of central data store. And from this central data store, reports and policies can be created. Both products take advantage of the volumes of statistical data available via the FC protocol. This adds value to these competing products, but doesn't in and of itself make either product superior.
The features I feel separated these products are ease of management and heterogeneous support. SANPoint Control requires a separate Sybase database to house alarms coming from the alarm service. I didn't find this to be an overtaxing administrative effort; however, it's another point of possible failure or corruption and needs to be protected. As far as heterogeneous support, both products have their respective hurdles to jump in order to gain API access into competing vendor's products. However, I found MVS support in EMC's ECC to be an advantageous point for applications being serviced by mainframes.
Where Veritas' SANPoint Control surpasses ECC is that it can discover and launch Veritas and non-Veritas software products from a single console, streamlining management. This advantage could be significant, considering the number of Volume Manager, NetBackup and Cluster Server installations there are to date and the time you are spending administering these products.
So which one should you buy? Both. The more dependent you are on EMC hardware, the more value you will get out of Enterprise Control Center. If you have EMC arrays and Veritas storage management software sprinkled throughout your enterprise, you have to ask yourself the question: "Is it more costly to manage the EMC or perhaps HP StorageWorks arrays and SAN switches or manage Veritas' Volume Manager, NetBackup and Cluster Server?"
If you don't have any EMC arrays, but have an abundance of Veritas software supporting your storage infrastructure, you may pick SANPoint Control. Whichever you choose, make sure you choose the solution that reduces your greatest financial management burden you're contending with now or will be in the near future.
Are we there yet? No, not yet, but with these product offerings, we're considerably closer to seeing a useful solution that really reduces the management efforts of the organization, thereby making corporations leaner, more flexible and able to sustain growth.