What you will learn from this tip: How Onaro SANscreen 2.5.2 can help different groups in your organization predict...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
the effect of changes in the SAN before they're made.
Do you know what will happen the next time you make a change in your (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.
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.
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.
Read the rest of article in Storage magazine.
For more information:
About the author: Darryl Brooks is a Brocade Certified SAN Designer and principle architect at Sanology Inc. He can be reached at firstname.lastname@example.org.