A Mother's Day SAN
By Jon Toigo

For this Mother's Day, my 83-year-young mom has decided that she needs a computer. As her favorite son, she has honored me with a request to buy her a PC and to set her up with an Internet connection at her retirement condo. (Why she can't be like my father and content herself with an all-expenses-paid trip to Las Vegas is beyond me.)

To be honest, a tear welled up in my eye as she quoted me disk capacity requirements, CPU speed requirements, connectivity requirements (USB and Firewire), and peripheral support requirements (CD-RW, DVD ROM, a scanner, etc.) Clearly, she was trying to talk the talk that some propeller head had given her during a recent fact finding visit she had made to a local computer store. She had taken the source at face value and written down his laundry list of components comprising a "state-of-the-art" system.

She confused Megahertz with Megabytes a couple of times, and referred to disk storage as memory. All in all, however, it was really cute to hear her try to sound technical.

Gently, I asked her what she needed a system for and she responded that she wanted to surf the Web, exchange e-mail with friends and family, write her memoirs, and create a recipe database to preserve her unique legacy in the culinary field: Techniques for delivering nutritious meals for a husband and 12 children three times per day for nearly 50 years -- often times on a meager or non-existent budget. All

    Requires Free Membership to View

worthy applications from my point of view.

She asked me why I had asked about what she planned to do with the system. She seemed worried that I was going to get her something less than "state of the art" or "leading edge." She even got a bit offended: Was I patronizing her as an octogenarian seeking her first PC?

I told her that applications should determine system platform components: You need to know what you plan to do with a system before you configure the necessary ingredients for the system itself. She didn't understand. The computer kid at the store told her about a state-of-the-art system: Wouldn't that do the job? I acknowledged that it would, most likely, support everything she wanted to do, but emphasized that it might be more machine than she needed. I found myself trying to explain the concepts of economy and waste to someone who had economized and wasted nothing for the past five decades of child rearing.

She sounded disappointed when I told her that she could support her applications well with a much less pricey machine. She asked if I was having money problems. I told her that 100 GB of storage was probably more than she would ever need for what she intended to do. She asked me if it was enough for me? I responded that my application requirements were different than hers. I have seven servers and a NAS platform in my home office, but that I do some programming, testing, application and Web site development, a little writing, accounting, digital video (in my spare time), and digital photography. Bottom line: I needed a bit more capacity than she needed.

She still seemed disappointed. A magazine article she had read had mentioned something called a SAN. Could she at least have one of those?

I thought about my poor ol' grey haired mother, who had raised me up from a seedling to the mighty oak I am today, trying to configure and manage a SAN, struggling with half-baked virtualization engines, using blunted software tools for provisioning and security, spending all of her remaining golden years trying to create a stable platform that she really didn't need, based on her applications. I shuddered.

Then, bizarrely, I thought about a grizzled IT manager at a health insurance company who cornered me at a recent conference and begged for information about the number of disk spindles in a SAN that could be actuated effectively by a 2-way or 4-way Intel server running "state-of-the-art" virtualization software. He needed to have an answer before committing major dollars in a project to "virtualize" more than 180 Terabytes in a SAN.

Wouldn't there be an enormous queue if a bunch of servers hammered storage I/O requests at a back-end SAN comprised of hundreds or thousands of individual disk drives? Was virtualization the only way to make the SAN present different types of storage to meet different application requirements? At what point would you max out the CPU or saturate the bus of an aggrandized PC pretending to be a storage virtualization server?

Moreover, was it cost effective to use SANs merely as a block storage platform? Could files also be served cost-effectively from such a platform?

His questions were good ones, especially since most virtualization products hadn't been tested with SANs having more than 300 GB or so of disk storage behind them. He was losing his hair over the quest for the answers.

Bottom line: I told my mother and the IT manager that they didn't need a SAN just yet. Based on the applications they were using, SAN technology simply wasn't justified.

Both exclaimed that they were being driven to the SAN by a combination of fear and uncertainty about future data growth and expert advice from integrators or retailers. To address the former, I said that they needed to have faith in common sense management techniques that will allow them to optimize whatever storage they deployed over time. To address the latter concern, they need to ignore the experts and become experts themselves by practical, hands-on testing. The only way to ensure that a new technology will perform as well or better than current technology given the application load is to monitor current performance and evaluate alternatives on a comparative side-by-side basis over time.

For my mother, this was a bitter pill. At her age, she asked, how many more years would she have for making such comparisons? For my friend at the insurance company, the concern was about his longevity at the company if he made an incorrect decision.

I am buying my mother the machine she needs rather than the one she thinks she wants, rest assured that if she outgrows the PC I give her, I will upgrade her with a new one. I am advising my client to go with his gut and to avoid a virtualized SAN environment until his questions can be answered and the answers can be thoroughly tested -- even if the politically correct move is to engage in an exciting new project involving a bleeding edge technology.

To integrators and resellers, many of whom seem to have forgotten that they are in business to solve problems and not just to sell products, I challenge you to reflect on a question this Mother's Day: Would you really sell the SAN to your mom that you are recommending to your clients?


About the author: Jon William Toigo has authored hundreds of articles on storage and technology and authors the monthly SearchStorage "Toigo's Take on Storage" expert column. He is also a frequent site contributor on the subjects of storage management, disaster recovery and enterprise storage. Toigo has authored a number of storage books, including, The holy grail of data storage management.


This was first published in April 2002

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.