Simultagnosia is a word I overheard while implementing a multiterabyte storage area network (SAN) for the radiology department of one of the nation's largest healthcare systems. It's a disorder where a person lacks the ability to integrate information across their visual fields. Instead, the affected person can only pay attention to one small area at a time, absorb information in that area and then move on to the next area.
As soon as I heard the definition, I immediately thought of managing resources on a SAN--administrators are expected to manage an enterprise tape library one minute, and then walk over to an enterprise disk array and utilize its inherent tools to manage it. And you also have to be more than familiar with the switches, routers and host bus adapters (HBAs) that connect tape libraries and disk arrays.
Doing more with less
From having salaried employees work additional hours without compensation to asking users to suffer through the pains of subpar response times, the lack of capital available for hardware upgrades is affecting productivity throughout corporations.
For example, backup administrators who oversee SAN-based backup environments are being asked to make-do with what they have--even when they need additional fiber-attached tape drives to meet their backup windows. Sure, high-speed, low-load time fiber-attached tape drives are costly, and that's part of the problem. And to some extent, I agree with the make-do approach because I've seen installations where a storage vendor's sales force was particularly successful in convincing the IT organization that they needed more hardware than they actually did. This misrepresentation of need usually takes place in the assessment phase of the engagement where the speed and feed numbers are fudged to benefit the hardware vendor. Ignored in the process is the fact that the IT organization's backup environment may be capable of accommodating more servers than previously thought. And with some added ingenuity, it may be possible to postpone the procurement of additional hardware altogether.
Incoming data won't subside simply because hardware purchasing has done so. If you're charged with maintaining a balance between resource management and your budget, keep an insightful eye on the point of diminishing returns. For example, when you assign client backups to a tape library that's already overprovisioned, other more important client backups may start to fail because of timeouts while waiting for resources.
As for the user with what appears to be a permanent hour glass on their screen, that loss of productivity will be multiplied across the office--and perhaps across departments--if the application in question was deployed in a consolidated storage environment where access to application data takes place over a shared fiber optic cable, a phenomenon that wasn't evident in direct-attached storage (DAS).
That leaves you with no choice but to seek other ways to improve the response times of applications, whether it's the defragmentation of file systems, improved locality of reference (fewer hops) between your application hosts and storage or simply revisiting your application server's kernel parameters as they relate to data access. Whatever your approach, document your efforts in case you have to pay a second visit to the person holding the purse strings.
Simultagnosia occurs when the administrator charged with managing disparate devices on the SAN makes changes in one management realm without having a visual understanding of the affect those changes will have on another realm. This change will undoubtedly cause a ripple effect throughout your backup window and possibly cause backups to fail, leaving applications vulnerable to data loss.
Continuing down this trail, LUN masking and SAN zoning are sometimes used interchangeably. Depending on the security practices of a particular organization, they may both be used to serve up and organize storage resources on the SAN. In this example, if there isn't someone in the organization that's familiar with the management interfaces of the disk array, SAN switches and possibly server HBAs, you may very well need three people to carve up your storage. This is certainly not what you intended when you sold senior management on this whole idea of moving to a SAN.
Aggregating management interfaces into a single storage management console is obviously the goal here. But with a significant number of the vendors in this space being stingy and not sharing the intelligence of their hardware with each other in an effort to gain market share, significant SAN management software offerings have been hard to come by. I'm not referring to software offerings that provide discovery and basic zoning. By significant, I mean an offering that provides portals into the management interfaces of hardware from leading vendors in the storage space within a click of a mouse.
How nice it would be to sit down at a single console and launch an application that not only discovers the resources on your SAN, but also provides you with the same kind of hardware control that you'd enjoy if you were using the software that was packaged with the hardware at the factory. In order for this to happen with any speed, we must put pressure on vendors to share their hardware intelligence with the software management vendor of our choosing.
Pressure doesn't mean being satisfied when the hardware vendor answers your interoperability questions by saying that they're corporate partners with your software vendor. I've implemented enough solutions to know that in the field, being corporate partners means nothing when problems arise and fingers start pointing. Pressure means insisting that your perspective hardware vendor swaps APIs with your software vendor before signing your deal.
Of course, this suggests that their legal departments would have to come to some sort of agreement--a feat within itself. But we as users can't continue to allow the egos of lawyers and CEOs limit our abilities to manage our storage infrastructures in the most cost-effective manner. On one hand, vendors want your budget dollars, yet on the other hand they hold the reins of your ability cut cost within your organization.
In these lean times, vendors should be more sympathetic to your bottom line. When times were better and capital budgets overflowed with cash, the vendors reaped the benefits. And although the vendors have cash flow and stock price problems, cooperation within the entire industry is necessary if the industry is to rebound at all. Perhaps they should let the benefits and features of the products that they develop dictate their market share, and not the proprietary practices that they engage in.
The user community's preference for standards has forced big shots in the industry to conform to these standards. That opens up their products for mere mortals to manage, thus cutting back on their professional services revenue. However, when vendors don't share the intelligence of their hardware in the form of an API, it amounts to a reinvention of their proprietary ways of the past. And although performance and scalability are inherent benefits of moving to a SAN solution, a reduction in management costs could be seen as the greatest monetary benefit of a SAN deployment. This benefit won't be possible until vendors take the covers off of their products for us all to see.
Superior SAN resource management is the key to the amount and rate of investment that corporations will invest in this technology. It's one of the main selling points of the investment and it's the only way that IT organizations will be able to manage the data that abounds from their data centers. But it will require vendors to develop and share APIs with the heavyweights in our field. Then perhaps there can be benefits for all of us.