This is part of a series on Enterprise Data Migration Strategies:
In the previous post, I discussed reasons for migration. This post will cover the next step; identifying the owners of storage resources.
It may be hard to believe, but many organisations can’t identify all of their storage users. This happens for many reasons:
- Companies merge — teams and organisations don’t interoperate well
- Teams and departments are continually re-organised
- Key members of staff leave
- Documentation is insufficient, inaccurate or poorly maintained
- Security regimes are over-zealous and restrict IT workers from doing their job effectively
Establishing ownership to all storage resources is essential. After all, migrations may (and almost certainly will) have some impact to service and therefore needs to be agreed and negotiated with the server owner.
Most organisations maintain spreadsheets or simple databases listing server owners, however sometimes even establishing the this small piece of information can be an issue. Remember, SAN storage access is controlled by World Wide Name (WWN) and is not an intuitive method of server identification as the WWN relates only to the HBA and not the server itself. Here are some pointers to help identify servers if your documentation isn’t up to scratch:
- Check your fabric. Is the server even online? It’s pretty easy to work this out. On EMC DMX arrays you can use the Solutions Enabler “list logins” command to determine when a server last logged in.
- Use the fabric login details. For later versions of HBAs with SMI-S drivers, the fabric switch can interrogate the HBA and obtain host details, including the server name.
- Physically trace the cable. When in doubt, sometimes it is necessary to resort to physical cable tracing. Although tedious, sometimes its the only solution to trace a WWN back to an original server.
You’ll find a simple server audit will identify some resources that can be reclaimed.
Unfortunately there’s no easy way to track a server back to an owner. Server management will vary from company to company, however equipped with a list and dogged determination, I’ve always managed to track down someone who will claim responsibility. In addition, local standards will provide some clues; perhaps your organisation uses server naming standards for different teams, or operating systems, for instance.
It may not be completely obvious why having a full list of storage owners is so important when migrations can be executed in some instances without user intervention. For me it comes down to two things — trust and relationships. Storage teams suffer from being at the bottom of the pile when it comes to planning of new applications. So many times, I’ve heard Storage Administrators say how they only get involved as servers are being deployed and if they’d known earlier, then they could have provided storage sooner or offered a more appropriate service. Nothing beats establishing a good relationship with your customer. A good relationship builds trust, which when you’re planning large-scale migrations is essential in order to get customer buy-in — especially if you have aggressive targets to meet.
If you haven’t got a clear understanding of who your server/storage resource owners are then get started making that list now. In addition, review the information you’re keeping on each server — a subject we’ll discuss in the next post.
