This article can also be found in the Premium Editorial Download "Storage magazine: What are the real benefits of data storage management software?."
Download it now to read this article plus other related content.
With hardware zoning, nodes are identified by their domain/port number pair, and access to the SAN is based only on location. In order to circumvent hardware zoning, the undesirable needs physical access to the port. This implies a certain amount of inherent security. However, with this increase in security comes more management overhead because changes to the nameserver database are necessary to mark the change in the port and possibly domain numbers. Yet this process is so simple, there isn't any real reason not to strive toward hardware zoning for its inherent security benefits, especially because port relocations in a SAN are less likely to occur than in a LAN environment where moves are more likely practiced.
Although the domain/port pair can identify the incoming node, the WWN is still a referenced characteristic of the end node. Surely an API developer can use this information to update the record in the nameserver database to reflect the location change of the end node, and notify the administrative community through a raised dialogue box in their network monitoring application.
Zoning is essential to ensuring that only authorized, predetermined nodes gain access to the management realm that makes up its community. Nodes are authorized by being entered into a DNS-like array using its WWN or domain/port pair to identify itself to the nameserver for acceptance into the fabric. Once accepted, the node becomes part of the larger community and communication
In terms of location in the security layers, zoning fits above physical access and between any access lists situated at the port level and/or at the service layer of your fabric. Zoning isn't an all-encompassing security measure, however, the residual affect of partitioning nodes on your SAN is one of heightened security and protection from unauthorized nodes.
Zones should be as small as possible, only including the hosts and storage that are related by an instance of an application. For example, if you're running three Oracle instances on an enterprise class server, you should configure three zones that identify the initiator(s) and targets associated with each Oracle instance. In this way, SAN events occurring in one zone and ultimately one Oracle instance won't propagate to the other Oracle instances. State change notifications (SCNs) are sent to each member of a zone that has registered to receive such notifications. And depending on the node's configuration and error recovery mechanics, the node will respond to the SCN in a manner consistent with these variables, possibly resetting the end device and causing alarm to the upper layer application.
In this same configuration, each Oracle instance will need to be protected by backup during the course of the day. However, each instance may have different availability requirements, requiring sliding schedules in your backup routine. If you changed zoning configurations on the fly to accommodate backup strategies, each zone member must process the SCN and log into the nameserver to find out what changed. Therefore, to ensure that non-related SAN devices aren't affected by the management of the other segregate zone members based on their application relations and your administrative processes.
Application correlation in your network management applications is another beneficiary of good zone planning. Wouldn't it be nice to have an association between an intermittent, an application write error and a pop-up dialogue box in your management application? If you plan your zones with an eye towards the management processes (well-known processes) of your SAN as well as your organization, it's possible.
This was first published in April 2003