Who should be charged with managing your SAN hardware?

Why not network engineers?
Can the network engineering group perform the same duties on a SAN?

Up to a point, yes. Capacity planning methods for Fibre Channel (FC) networks are similar to those for IP networks if the focus is on the traffic flow. But beyond that, the similarity fades. In order to provide secure access to the SAN, the engineer will need to be more than just familiar with the Fibre Channel protocol (FCP) and there lies the difference with standard IP networks.

Providing secure access to your SAN entails knowing where the entry points are, and what vulnerabilities lie at each entry point. In order to be proactive in your defense you have to know the FCP's weaknesses. And before you can identify them, you must first get your mind around the protocol itself. You can't determine what is going wrong unless you know how the network is supposed to behave in the first place.

Also, a bad router, a DNS typographical error or other IP problems can all be determined without logging into the server experiencing problems. This isn't necessarily so on an FC network where it's often necessary to gather the server's host bus adapter (HBA) configuration as well. That requires collaboration with your system support group on some level - either complete access to the administrative account or some derivative thereof. This often leads to some kind of territorial standoff between your network and system administrators.

Network engineers aren't likely to be familiar with connecting an enterprise storage array or tape library or other ongoing hardware integration tasks.

The interaction between connecting devices on a SAN is more than just being able to ping the connecting NIC to ensure proper functionality. Instead, we're looking at device drivers and firmware revisions, HBA and SCSI bridge configuration parameters - tasks that have been traditionally assigned to system administrators.

The case for sysadmins
Having come up through the ranks of system administration, I am probably a little biased towards this group. This bias is also a result of my field experience interacting with the two groups. In general, sysadmins have had more experience troubleshooting network problems or outages than network administrators have had troubleshooting system problems or outages. Network administrator may not have as many similar experiences troubleshooting storage management applications and the devices they manage.

With direct-attached storage (DAS), system administrators have always taken the lead role in providing capacity planning and provisioning for server storage. Unless your data center is comprised of many large DAS arrays requiring a separate group for management, your system administrators have more than likely put storage management under their support umbrella.

In that case, it will be tough to wrestle this responsibility away from your system support group. Not only are territorial considerations (e.g., job security) a concern, but because the system support group has been providing storage-related services to their applications up until this point, they probably possess most of the real knowledge associated with the currently direct-attached storage array.

Like their network counterparts, sysadmins are likely to have a learning curve with FCP. However, having experience with the SCSI protocol definitely gives the sysadmin an edge. Additionally, I've yet to meet an IP network engineer at a customer's site who has any interest in the connection methods of an enterprise storage device.

In terms of IP networking, a system administrator's responsibility would typically stop at the NIC card, with network engineering providing secure access to the destination endpoint (typically another NIC card).

Storage admins
Storage administration was originally born in mainframe computing. That was a natural phenomenon since everyone was forced to deposit their data in one location. This location -- eventually vast and complex -- had to be managed by a separate entity. Let's face it, 25 years ago it would have taken a building full of DASD to provide the same capacity of today's enterprise storage arrays. Therefore, having a separate group to manage this hardware wasn't so much ingenious, it was necessary.

We've all heard it said that "necessity is the mother of all invention," so here we are again being propelled into different ways of thinking. And yes, it appears as if we have come full circle on this administrative practice for some of the same reasons as before. Due to the sheer number of users or data types of a particular application server, data growth is off the charts, requiring hardware purchases and manpower to manage it.

However, there are new reasons for administrative changes as well. These new reasons are the switching architecture itself and the addition of FCP to transport mostly SCSI information over the wire.

A revitalized group of storage administrators ensures the desirable ability to conceptualize and understand network, system and storage semantics. You may have employees that have the experience and initiative in one or two of these areas, but not as many that are familiar with all three. So to start, this group of storage administrators should be an assembly of your brightest people in each one of these disciplines that have an interest in SAN management.

I say "that have an interest" because forcing this responsibility on a network engineer, who is highly respected for what they know in the IP world, could have adverse affects on their morale when placing them in an environment where they aren't necessarily the go-to person in the group.

If your budget allows for a new storage group to manage your SAN, try to ensure responsibility from the installation of the HBA in the server, to the connecting storage resource and everything in between. This gives your group the ability to manage the entire data path without the aforementioned impediments. Another hidden benefit of forming a new storage group from in-house experts is that they are likely to grow their knowledge base horizontally instead of vertically. For example, your Hitachi storage expert will gain knowledge of traffic pattern analysis from your Cisco expert and apply this to the internal switching architecture of your Hitachi storage array, possibly leading to increased performance. And likewise, the Cisco expert will be in a position to gain insight on how the physical layout of an Oracle database might affect a network engineering management application.

Ahh, the sharing of information ... isn't work great?