Storage Area Network: Lecture Notes
Storage Area Network: Lecture Notes
SANs, NT and UNIX servers can now share storage resources of a single disk array,
and management of the array's resources may exist independently.
Lower layers move status and event information up through the hierarchy.
Upper layers issue commands and queries down to the appropriate agents.
The management structure is built on a foundation of managed devices that create the
SAN interconnection (host adapters, switches, and bridges).
The vendor of a managed network device supplies a console or graphical interface that, at
minimum, allows port configuration (insert/bypass) and reports basic enclosure
environmental status (power, temperature, etc ).
The feature set of a managed HBA, hub, or fabric switch is vendor-dependent. Some
products offer only basic enclosure and port status, whereas others include performance and
diagnostic utilities.
The application provided by the vendor to manage its product is a device manager.
A management utility for a host adapter card, for example, will give status, configuration,
and port statistics for the adapter, but it may not provide visibility to fabric switches or
other nodes with which it communicates.
The management of multiple storage network products implies the need for multiple
device managers, and consequently multiple management workstations or consoles to
support applications from different vendors.
A management agent on-board the device must then translate the bypass command into a
hardware instruction, and the hardware, in turn, must raise or lower the appropriate leads to
physically bypass the port.
Communication between a device and its management workstation may occur through
the storage transport media, this is referred to as in-band management.
Alternatively, management data may be segregated from storage data traffic via an
external Ethernet, RS-232, or other interface, this is referred to as out-of-band
management.
Out-of-band management through Ethernet normally uses the SNMP protocol, although
Telnet and Web browser HTTP (Hypertext Transfer Protocol)-based implementations are
also available.
In-band and out-of-band solutions have their respective advantages and disadvantages,
and some products offer both to provide complementary functions.
In a Fibre Channel SAN, you might use the common HBA API to report host bus adapter
status and use proprietary switch and storage APIs to report status and configuration
information for the fabric and targets.
In the case of an IP SAN, SNMP or API queries could be sent along the same
infrastructure as the SAN interconnection, directed at the IP addresses of management
entities within host, switch, or target devices.
In-band management simplifies SAN deployment, provided that all the devices that
require management support in-band methods.
Unfortunately, in Fibre Channel SANs some devices still require out-of-band access, so
you need an additional Ethernet network to handle SNMP traffic.
Because all management data must move across the storage network, loss of the
transport means loss of management visibility to the managed devices, and that negates
the ability to detect, isolate, and recover from network problems.
Thus, although in-band management fulfills a useful function under stable network
conditions, it is ill equipped to deal with catastrophic physical-layer or transport-level
events.
In large, meshed SANs, you can somewhat obviate this vulnerability by providing:
Redundant links.
Providing alternative paths for storage data and management data.
Adds cost, consumes additional ports.
out-of-band techniques typically use Ethernet for the management data path and wrap
management queries or commands in SNMP, Telnet, or Web browser HTTP protocols.
Most switches and storage targets also provide a serial RS-232 console port as an
alternative (but rarely used) access method.
Because out-of-band implementations do not rely on the SAN transport, you can still
manage host adapters, switches, and storage arrays if the fabric links are down.
The use of IP to carry management instructions and responses lets you manage storage
network devices from anywhere in a routed IP network.
Storage network management can thus be co-located with the SAN or can be
centralized with other IP-based network management applications in an enterprise
network operating center (NOC).
SNMP provides a command set for soliciting status (SNMP Gets) or setting operational
parameters (SNMP Sets) of target devices.
The management platform contains the SNMP manager; the managed router, hub, or
switch contains an SNMP agent.
Device status information may include a variety of data points: serial number, vendor ID,
enclosure status, port type, port operational state, traffic volumes, error conditions, and so
on.
If a vendor wishes to include additional device information that is not specified in a
standard MIB, vendor-specific parameters or status can be compiled in a proprietary
enterprise MIB or MIB extension.
Device information, status, and control variables within an MIB are organized in a
hierarchical data structure called structure of management information (SMI).
SMI defines an information tree whose branches lead to various management information
bases and whose leaves are discrete data about a device's functionality and status.
If a preconfigured error condition or threshold is reached, the managed device will
initiate an SNMP message to the management workstation as an alert.
On the management platform, the icon representing the managed device typically turns
yellow or red, and the application may send a page or e-mail to the network operator.
Because SNMP is a protocol shared by the vendor's device management application and
third-party management platforms, SNMP traps can be directed to either one.
SNMP allow a trap to be addressed to the Open View management workstation, which
could then automatically launch the vendor's device manager for further status or diagnosis
of the problem.
Although polling for all status information from multiple SNMP agents may generate
noticeable overhead, SNMP management applications can reduce IP traffic by relying on
traps for notification of events or by polling only for changes from an original status
check.
ME - CSE [SAN- Unit VI] 17
HTTP
Use of HTTP (Hypertext Transfer Protocol) is a management tool that leverages the
proliferation of Web browsers for managing network products.
Web-based management of network resources is being extended through the Web Based
Enterprise Management (WBEM) initiative, which makes browsers the common interface
for managing diverse network components.
An HTTP management implementation has two components: an HTTP server that
resides in firmware at the managed device, and a Web browser (such as Netscape or
Explorer) that acts as a management graphical interface.
By pointing the browser to the IP address of the managed device, the user can navigate a
series of screens to monitor device status or change device parameters.
Embedded HTTP capability is an entry-level management scheme and does not integrate
into broader management applications as easily as SNMP or SES.
Because a browser can be addressed only to one IP target at a time, the administrator
would have to open multiple instances of a browser application to manage multiple HTTP-
based devices
ME - CSE [SAN- Unit VI] 18
Embedded HTTP management does not facilitate a comprehensive view of all managed
products.
Recognizing that HTTP-based management has an appeal for the low end of the market,
vendors of SAN products may provide both HTTP and SNMP management options.
Even with password protection at the managed device, HTTP presents a higher security
risk than other methods.
At minimum, password protection should be provided for both read-only and read/write
access, complemented by a firewall to prohibit external penetration of the customer
network.
This arrangement allows multiple remote managers to view the storage network via
browsers and overcomes the single-device limitation of embedded HTTP management.
By assigning read-only and read/write permissions, the administrator can provide
management operations for monitoring and modification controls.
The user sends a Telnet command across the IP network to the managed device (for
example, Telnet 192.168.1.1) and establishes a session.
The vendor, hopefully, has provided one or two layers of password protection, beyond
which a menu of commands is available.
Telnet is usually used only to set the device's default IP address to one that can be used
for SNMP access, but a command line interface alone is sometimes the tool of choice for
UNIX environments.
The command set available and status information that can be queried via Telnet are
vendor-dependent.
Some offer only basic configuration commands, whereas others provide commands and
queries for all functions that are available through the vendor's SNMP graphical interface.
Open systems exert pressure on all vendors to seek common methods cooperatively
while competing for market share with unique functionality.
This contradiction slowly and sometimes painfully works its way through standards
bodies and industry groups, with both technical and political consequences.
The primary value offered by these programs is the ability to make all distributed disk
assets visible to a single management console.
Therefore, SRM applications are not unique to SANs but may also encompass internal
workstation-attached, SCSI-attached, and NAS storage.
The SAN-specific features of a storage resource application surface when, via the SAN
interconnection, multiple servers have access to the same storage arrays and when the
SRM workstation itself is SAN-attached.
ME - CSE [SAN- Unit VI] 24
Storage resource management addresses these shortcomings by automating the process of
disk information retrieval and presenting a single view of all disk resources.
SRM client software on each server periodically updates information on its assigned
volumes and directories and forwards this data to the SRM manager.
The SRM management platform, in turn, consolidates the status information from
multiple clients in a relational database and may, depending on the vendor's
implementation, provide storage policies that issue.
As with trending tools in local and wide area networks, SRM applications may also offer
enhanced capacity planning utilities that facilitate redistribution of storage resources and
provide data for accurate budget forecasts of impending storage needs.
JBODs and RAIDs on a storage network, for example, offer more flexibility in
redistribution of disk space between SAN-attached servers and more easily accommodate
increases in the pool of storage without system down time.
As with SRM applications, storage management is facilitated by, but not dependent on,
storage area network topologies.
The more tightly integrated these activities are within a single application, the simpler
storage administration becomes for day-to-day operations.
ME - CSE [SAN- Unit VI] 26
Storage management functions may monitor access to shared resources such as tape
libraries or optical archives, schedule non-disruptive disk de-fragmentation routines,
manage the growth and integrity of file systems, and oversee cross-platform access to
storage.
As more storage, tape, and archive systems appear on the SAN, integration is further
enhanced, because the storage management platform itself can access resources directly
without having to pass through servers.