Hands-On Review: Onaro SANscreen 2.5.2

Onaro's SANscreen takes the uncertainty out of making changes to a SAN environment by showing the effects of a change before it's actually implemented.

Manage SAN changes with confidence

Product snapshot
Onaro SANscreen 2.5.2
Storage management
Key Features:
Predictive change management
Easy to learn, excellent navigation, prevalidation of changes
Not SMI-S compliant, requires device passwords
Starts at $64 per port
Do you know what will happen the next time you make a change in your storage area network (SAN)? The impact of a change to a SAN configuration is often an elusive piece of intelligence. Without that insight, changes can go wrong, leaving storage access paths compromised or unavailable to application hosts.

SAN change management largely has been a manual process. Change management is risky enough, and is often compounded by SAN configuration information that's sometimes out of date.

Boston-based Onaro Inc.'s SANscreen v. 2.5.2 is a predictive change management application. It allows different groups to use the same real-time information to collaborate on SAN changes before, during and after the changes are made. SANscreen does not perform changes, but it continuously gleans information from compatible SAN devices and their access paths to predict the effects of changes.

The SANscreen architecture includes a server, local and/or remote acquisition units and clients. SANscreen's server hosts the SAN Intelligence Engine, a repository of identification and event information related to the SAN devices and their access paths. The acquisition unit is responsible for collecting information from its managed data sources, using an out-of-band IP connection to the SAN device or management application. The data that's collected is sent to the server and applied against user-defined policies for the prevalidation of change tasks. A Java-enabled Web browser provides access for the SANscreen client. (See "SANscreen setup")

A data source is associated with an acquisition unit and assigned to a SAN device. This logical component provides the server with end-to-end topology and status information from SAN devices, including access paths used to communicate with other end devices.

The SANscreen server and acquisition units run on Windows 2000 with at least two 2GHz CPUs, 2GB of memory and 5GB of disk space. The client runs on Windows, Unix or Mac OS X Java-enabled machines with at least a 1GHz processor and 512MB of memory. Our test setup consisted of a SANscreen server, a remote acquisition unit and a Mac OS X client.

The installation process is wizard-driven, with familiar prompts for installing the SANscreen server and the acquisition unit.

Remote acquisition units are installed on computers to collect information from SAN devices with IP interfaces on networks behind firewalls, over WAN connections or not otherwise accessible to the local acquisition unit. This communication uses a secured port that's assigned during installation, but can later be changed.

SANscreen setup

Usability and interface
The administration portal is the first point of user contact with SANscreen; it's accessed by typing the server's name and port number (i.e., https://santa-anita:80) into a Web browser. (The port is the Web server port number, not the port used for communication between the server and acquisition unit.)

The interface provides a portal to the SANscreen client GUI, user management, import, mail and simple network management protocol (SNMP) configurations. It's also the access point for applying license strings, accessing log files and backing up and restoring configuration files.

You'll spend most of your time with the SANscreen client GUI. Each of the five main interfaces has shortcut and navigation panes on the left, with icons that launch screens that display a main table, topology and detail pane on the right. A menu pane lets you quickly view device properties and change the details of a screen layout.

Through the main table, individual Nx_Ports and their access paths can be selected to obtain more information. The topology pane reflects the relationships between the end points and their paths, including zone membership, the number of paths between end points and the health of those paths. The topology pane tends to get cluttered, but you can customize it to only display particular zones and fabrics.

SANscreen's interface is easy to navigate. The screens, menus and simple mouse-click operations make it easy to get up to speed quickly. In addition, the topology pane and automatic refresh feature makes SANscreen a good monitoring tool.

The user management portal lets administrators define users, assign roles and the rights to view or change configuration data. SANscreen is highly customizable; you can, for example, define individual views with groups of SAN devices that are of interest to a particular business unit. E-mail notifications alert users to changes and policy violations in the SAN on a daily, weekly or monthly basis.

E-mail notifications are enabled by providing the server the IP address of your SMTP server and a valid e-mail account user name and password. SANscreen uses the account to send out notifications.

Onaro uses SNMP to send change and violation traps to trap hosts in an enterprise network management infrastructure, thereby providing visibility into events that occur in the SAN. SANscreen isn't currently Storage Management Initiative Specification (SMI-S) compliant, but Assaf Levy, Onaro's vice president of product development, says SANscreen will support SMI-S next year.

Unless you install an open-file backup agent on the SANscreen server, you'll have to backup and restore its configuration manually using the administration portal. You only have to provide the backup destination and source for the restore file.

SANscreen pinpoints configuration problems

SANscreen pinpoints configuration problems: SANscreen shows where proposed changes will violate operational policies and possibly cause a disruption in storage area network service. In this example, the policy on the authorized access path between Host A and Storage 2 has been violated, perhaps due to a failed HBA or Switch 2 reboot.

Data sources are the processes that send information to the SANscreen server. They're associated with acquisition units and tied to individual SAN devices. To add a data source, you must have the IP address, and the administrative user name and password of the related SAN device or management station.

With a single storage group managing an entire SAN, providing SANscreen with SAN device user names and passwords wouldn't be considered a security threat if the management network is hardened against outside access. However, in larger organizations, turf wars may erupt because business unit administrators may not want to share passwords with a separate enterprise storage group.

A better solution might be to provide the business unit administrators with an interface to change user names and passwords for the devices they manage. The enterprise storage group would still be able to get a telnet or Web session with the SAN device, but only through SANscreen where accounting takes place. Outside of SANscreen, only business unit administrators with the correct passwords would be able to gain direct access, thus enhancing security.

SANscreen violations result when a policy is broken on an authorized access path. Violations signal that an unauthorized change has occurred or indicate that an impending change will violate a policy. An authorization wizard is used to associate policies to access paths; policies provide the basis by which SANscreen determines if the path is healthy or not--shown as green or red on the topology display.

During the authorization process, a previously defined path is chosen from a list and assigned a policy. Policies include a redundancy level for the path, minimum number of host ports having access to a particular LUN and maximum switch hops between end points, for example.

After a path has been authorized, SANscreen will apply events received from data sources to the access path's policy to determine if a violation has occurred.

Violations can include unauthorized or missing paths, or a reduction in redundancy due to a failed inter-switch link (ISL) or HBA. Clicking on the violations icon launches a screen with a list of violations in the main table; when a specific violation is selected, the access path with the violation is highlighted on the topology pane (see "SANscreen pinpoints configuration problems"). Selecting the device involved in the violation displays the details pane that shows the port connectivity of the device and a list of recent changes for the device.

There are two reasons for violations to occur. An unexpected change event in the SAN will trigger a violation. A violation will also occur if there was a planned change in the SAN, but the authorized path list wasn't updated. Unexpected changes are easy to track to determine the root cause. The second instance is more of an "oops, I forgot" thing and is remedied by updating the authorized path list.

A historical list of changes can be viewed by clicking the changes icon in the shortcut pane. The time-stamped list shows all the changes on a managed data source since a given time. During our evaluation, zoning, LUN masking and device addition and removal changes were all tested successfully. Administrators can also simulate rolling a SAN configuration back to specific changes and points in time to see exactly what change broke a specific policy or caused an error.

The vulnerabilities screen displays data sources that are at risk of being in violation if included in an authorized path. Some examples of vulnerability types are blocked hosts, blocked ports, high LUN utilization per storage device and unconnected zone ports.

Although the list of vulnerability types is fairly comprehensive, I'd like to see SANscreen predict hardware vulnerabilities as well. For example, the link error status block is part of the Fibre Channel Physical (FC-PH) standard. It maintains counters such as "loss of signal" and "bad CRC." When these counters increment quickly, it usually means that a gigabit interface converter or other physical component between ports is about to fail. These counters offer insight into the physical health of a SAN, so it seems natural to include them in SANscreen's analysis.

SAN changes are planned, prevalidated and stored in the tasks screen using a MySQL database. You can create tasks with unique reference numbers and associate them with actions necessary to complete the task. You can perform a prevalidation of a change by logically stepping through action keywords (create, add, connect, authorize) to flag potential errors.

SANscreen has two pricing models, perpetual and subscription based. The perpetual license starts at $125 per port and the subscription model is priced at $64 a year per port with volume discounts available.

Considering the ROI related to maintaining SAN stability during the change process, SANscreen's cost is nominal when compared to application downtime and the man hours required for manual changes.

SANscreen 2.5.2 is must-have software for large, complex SANs that undergo frequent configuration changes. SANscreen steers change management away from Murphy's law and puts the SAN administrator back in control.

Dig Deeper on SAN technology and arrays