Beruflich Dokumente
Kultur Dokumente
Education
Justifying Symmetrix 3000:
Using The “Why EMC” Comparison Chart
W e’ve found that when we give briefings or present to customers, they love the
message: the vision is great, the strategy is right on, they like the value
messages. But when they walk away from a briefing, the next thing they say is,
"Now, why do I have to pay $1.50 more a megabyte for EMC storage than
someone else’s storage?".
The goal of the Why EMC comparison chart for Symmetrix 3000 is to help you
establish a dollar value with your customer that gives them the reason and the
justification to spend the additional money for EMC Open Storage.
During a presentation, use it as an overhead to talk about soft values for all
categories and to “raise the issue of value” and get them thinking about it.
During a working session, sit down with your customer and put in hard dollar
values for each of these items.
There are a lot of items on the sheet, so it’s unlikely that your customer will buy-
off on all of them. The goal here is not to establish buy-off on every category, but
to establish enough value that the customer leaves convinced that spending the
additional money on Symmetrix 3000 is worth it.
Let’s go through each item on the chart to give you a point/counter point on each
issue and how you can present them to your customer.
Architecture
OUR MOSAIC:2000 architecture forms the foundation of all the concepts and
capabilities on the W hy EMC chart we’re discussing. MOSAIC:2000 is more than
a marketing term. It is a legitimate architecture that enables us to change the
front- end and the back-end, and not worry about whether it’s 3GB drives, 9GB
drives, next generation technology, block mux or wide-SCSI today. W hatever the
next technology is, MOSAIC:2000 will support it. So, we have a multi-platform
architecture.
Most people approach buying disks as tactical. They want to make a short term
problem go away. Buying a Symmetrix, however, is a strategic investment for
needs now and into the future. Because Symmetrix 3000 is designed to provide
mainframe-class capabilities, it offers a useful life of four to five years, like you
would see in the mainframe world. On the other hand, in the open systems
world, we are finding people are depreciating technology to zero within 12, 18 or
24 months. One of the driving factors behind this is the rapid pace of new
technology. W hen a new disk drive or new technology comes out, customers are
typically forced to walk away from their investments. Vendors drop support on
disk drives very quickly as soon as new items come out. Have you seen any of
th a t?
Look at PCs. The example of 386 to 486 to Pentium to P6. Or look at multiple
generations of HP architecture. If the system is no longer supported after 2
years, you need to get your customer to acknowledge that. “Look, Mr. Customer,
with Symmetrix, you can support it four to five to six years, and with your storage
its 1 or 2 or 3 years.” All you need to do is get them to support that. Then you
establish a price that they are spending for storage. Let’s say they are spending
a half a million dollars for storage. If you can amortize half a million dollars of
storage for over five years, that’s $100,000 a year versus $250,000 for just two
years. So that’s a huge savings you can justify right there in tangible goods. All
you have to do is ask your customer and get an agreement with him and get a
number down in the column on the right hand side.
Increased Performance
The next point on the chart, Increased Performance, plays a lot of different
ways. Root fact is that a Symmetrix, in most applications, will dramatically
increase performance. And that has a different spin on values. You can do more
work in a shorter amount of time; you can save money on upgrades. So we’re
going to examine each of these as we go through it. So, how much of a
performance increase will you see? It varies. W orst case, we’ve seen 50%
improvements. These climb all the up to two times, three times four times... up
to eight times the performance measured at the application level. You have to
Think of some of the examples used in the Business Impact Profiles; the key
here is to establish the value. One of our retailing customers was able to stay in
business two days longer at the end of their quarter and process more of their
work. That has tangible, bottom line dollar relief for that customer. They felt that
was worth over $20 million to the bottom line at the end of the year. Now, all you
have to do is get your customer to say, “No, it’s not worth $20 million; it’s only
worth $2 million,” and you’ve got them nailed. So the issue here is to establish a
value. You have to dig and find out what their application is and what you can do
to add value by increasing performance.
If they can’t look at the value of the business process, maybe they can get by
with a smaller system or, conversely put, “You may be looking at a CPU
upgrade, Mr. Customer. Since I’m dramatically improving your performance, you
can either think in terms of a smaller Sequent, a smaller Sun, something other
than a T-500 from HP and probably get better performance from that small box
simply because you now have better I/O.” So you have to ask the question, ”Are
you looking at upgrading your CPUs any time soon?” That money needs to go to
us because now you don’t have to do it. “Are you looking at anything in the area
of downsizing existing servers? Could you potentially consolidate onto one
server instead of having multiples?” Keep in mind that savings cascade. If I get
into smaller boxes or fewer boxes, not only do I save on hardware, maintenance
comes down. Software licenses come down. Management overhead comes
down. So you can take that one smaller box concept and spin off three or four
different savings streams for the customer.
A customer doesn’t necessarily know the size of the system they need. W hat’s
the traditional answer from a system vendor when they say “I need more
performance”? They say, “You need more memory and you need more CPU.” If
you take a look at an HP T-500, a system at $90,000 per CPU, that’s a lot of
money. Take a look at one of the benchmarks we just ran. W e took a T-500 with
four CPUs and ran the same application using Symmetrix on a single-processor
I-70 HP. W e went from 345 rows per second to 7500 rows per second. W hat we
found out is that you don’t necessarily need the size of the system you thought
you needed. Now, if you think about being able to defer an upgrade for
processors, think of it from a financial perspective. Three CPUs at $90,000
apiece is $270,000. If you can defer those three CPUs for a period of one or two
years, you have the use of that money and, at the end of two years, those CPUs
don’t cost $90,000 apiece. They cost 30% less per year. So at the end of two
It’s not just the hardware. Don’t forget everything else that comes with it: it’s the
software, it’s the maintenance, it’s the labor. But there’s another way to look at
this, too. Very often as people get into larger and larger systems they find
themselves getting squeezed on slots. W hy is that? They can plug in four to six
drives on a single SCSI controller. If you want more storage, you need more
controllers. You need more slots. W ell, if you look at Sequent’s product line,
what they sell you is slots. The little one, the medium one and the big one all
have different numbers of slots. Same with HP, IBM and everybody else. So if
the customer has a decision support application, you’ve got a handful of people
that want to access a large amount of storage. Do you really need a maximal
system or do you want to be able to plug lots and lots of storage onto a much
smaller system? So look at the value of a system slot. W e ran into a lot of
customers that are either, a) looking at an upgrade just to plug in storage or, b)
just can’t plug it all in and are facing very expensive alternatives. You always
have to ask the question, “Are you mirroring?” because, remember, when you
mirror on a normal UNIX you’re using twice as many slots. That’s a real problem.
So, we’ve been able to go to a number of customers and say “W ell, with this
architecture, how big a system do you need now?”
W e have an example. W e had a customer in a few weeks ago with a large SP2
with 104 nodes. The customer said, “I have two problems. One of them is I have
all these channels I have to connect and all the cabling which is a nightmare to
connect up all the nodes. The other problem is that IBM said if I want more
performance what I have to add another 256MB of memory to all 104 nodes.” I
asked the question, “W ell, what’s the price tag on that?” and they said $3 million.
They still had to buy the storage as well. So I asked the obvious question: “If you
could do that for $3 million of storage and not have to put the additional memory
in and perhaps even reduce the number of CPUs that were in that system and
reduce the number of slots you need, what’s that worth? On an IBM SP2 you
can put 15 nodes in a rack before you have to go to the next rack. W ell, what’s it
worth if I save a rack, save all those nodes. There’s tremendous value there.
And that brings us to our next point. In addition to saving system slots, you can
also save on system memory. Again, conventional UNIX wisdom is, “If it’s
running slow, throw more memory at it.” W ell, there are a couple of problems
with that. First of all, UNIX is volatile. UNIX cache can’t be used for writes, at
least not safely; and UNIX cache tends to be very, very limited and not used too
intelligently. Also, if you max out one of these UNIX boxes with two gigs of RAM,
that memory is not available to all the other systems on your floor. So we’ve
been able to make the point that, because we have such a large, shareable,
non-volatile cache in the Symmetrix, you can get by with considerably less
memory on all of your UNIX boxes. In a high performance environment, you may
take half of your system memory or more and turn it over to buffers and cache.
In the Symmetrix environment, you may be able to get away with only 15% to
20% of your memory used for UNIX buffers and cache. On a large system,
you’re saving 256MB of memory, maybe as much as 512MB of memory. And
again, over multiple systems, this can really add up.
But let’s just draw the line on making smaller boxes and making them run faster.
Let’s step back and take a look at this whole concept of re-useable storage. This
is where we really tend to shine because, although a lot of people may be able
to make performance claims, we’ve found that we’re just about the only ones in
the business who can enable this concept of vendor-independent, shareable
storage. So let’s take the first point: the ability to re-use storage. In other words,
if I have a platform on my floor today, what can I do with the storage tomorrow?
So I typically ask the question, “W hat was the fastest UNIX processor last year
at this time?” I think you’ll get some answers. “W ell, what’s the fastest UNIX
processor today? How about twelve months from now?” All you have to do is get
them to agree that it might be a different platform and you get the point across.
Nobody wants to walk away from a storage investment.
But there are some real examples behind this, too. Take a look at UNIX in
general. Aside from the fact that servers come and go every 18 to 24 months or
every 36 months, there are other things too. In the UNIX business, most
customers start pilot applications. And they’ll start with development, for
example, on a small Sun because they don’t want to spend a tremendous
amount of money on that but they still have to pay for that system. They may
go to production on an SP2 or a T-500 or on a Sequent or any other machine.
By having re-usable storage they can save their investment in that storage and
continue into production and continue further development. W ithout being able
to reuse storage their investment is lost and, therefore, they lose all the value in
time and money and effort that’s been put into utilizing that storage in the first
place. So we’re seeing a real value in being able to reuse storage. I find this
point to be exceptionally interesting.
2
EM C
T h e E M C O pen S torage S olu tion
BEFORE AFTER
SUN HP IB M OTHER SUN HP IB M OTHER
P ro p rie ta ry O pen
D is p o s a b le R e -u s a b le
C o m p le x S im p le
L im ite d S c a le a b le
U n p ro te c te d P ro te c te d
O p e n S to ra g e fo r O p e n S y s te m s
O p e n S to ra g e S o lu tio n s
The “Before” piece says each server has its own storage. The EMC model
shows multiple servers connected to the same storage system.
I talked to Oracle sometime ago and I asked Oracle the question, “How much
storage do you need to reorganize your files twice, three times a year or even
monthly?” Oracle said, “Thirty percent of the storage is devoted to
reorganization.” So if you imagine now having four separate servers each
100GB and each with 30GB devoted to reorganization. That’s 120GB spread
among those four servers. The moment I put those four servers on a
consolidated storage solution, I no longer need all 120GB, I only need 30GB and
I can reorganize each server, one at a time, one after the other and have a hard,
tangible savings of 90GB of storage in that example. And that’s because the
storage is re-useable and I can reconfigure and reallocate the storage as I
choose.
That’s kind of a double benefit between the reusable concept, in other words,
every platform on your floor, and this concept of storage sharing. Now, I want to
caution you today that, the manageability aspect of Symmetrix makes this
reallocation of storage a little difficult unless you put some forethought into it.
The current issue we face today is that if someone wants to change their whole
Symmetrix configuration, we basically have to have the customer engineer come
out and do it. That will be changing soon, so I’m going to stick to the message.
There are peak demands and dips in all of this: database reorg, end of the
month closing, a project that doesn’t work out and you want to allocate the
W e had a customer that had four HP servers. Each one of these HP servers had
the same data base on it. The customer would download the same data to all
four of the servers; it took 72 hours to get all the data down. W ith the strategy
we put in place, instead of having the servers duplicate their data four times, we
put all four servers onto the same system, downloaded the data once in only
seven hours. In this decision support environment, all four servers could read
the same data and that’s exactly what they wanted to do. So they had the ability
to share storage. They had the ability to consolidate it and they had significant
performance improvement by going from 72 hours to 7 hours of downloading.
And that was done every week.
You reduce the amount of time it takes significantly to download the data and
you increase the reliability in terms of having to maintain four separate systems
and maintain the data and handle all four of those at the same time.
You can look at actually shrinking the total storage needed because you can
share it. You can look at the risk factor saying that, if something doesn’t work
out, I don’t walk away from the storage or you can look at it in some cases as
time and labor savings because you’ve compressed the business process that
had to use a network or tape that now can use shared disk in new and creative
ways.
I had a similar experience also with someone who was in the UNIX side of the
house and had come from the mainframe side. They challenged me a little bit
Some people are very concerned about having problems. Other people, for
whatever reason, haven’t seen any issues. But just today in the EBC when I was
giving a customer briefing, this guy said, “You know, it was just a holiday
weekend for everybody else but me. I was in the shop, I was restoring tapes, I
was fixing broken disks. I hate my storage.” Timing may have something to do
with this. Sometimes you’re successful at creating fear, uncertainty and doubt
about the storage outage that hasn’t happened but if they’ve been in this for a
while, they’ve experienced this pain and will do anything to avoid it. And there’s
a hard cost in terms of business process interruption. There’s also a soft cost
which I’ll call hassle factor: the unscheduled, unplanned emergency which no
one likes.
There’s another twist to this, too. It goes hand in hand with the sharing storage.
Say a customer has a homogenous environment and multiple servers all
connected to the same storage system. In the event a server actually goes
down, they can move that application over to another server because all the
data, all the resources, are sitting on that same storage system as opposed to
having storage separated server by server. They can actually get back up and
running much faster than they could if they had individual servers with storage.
Remote Mirroring
Remote Mirroring can be a difficult and complex topic. The idea in the
mainframe world is of business continuance. If your mainframe goes down we
have an easy way for you to get back up again at a remote site. The problem in
the UNIX world is that very, very few UNIX sites that we’ve met have any
provision for disaster recovery and those that do typically don’t manage this
themselves. They’re going with a Comdisco or other third party disaster recovery
outfit. So what we usually have to do is draw a picture of OK, it’s two years out,
this is mission critical and now you do have a business continuance issue. If
they’re already a Symmetrix customer they’re probably already looking at SRDF
to handle their mainframe requirements. Being able to say, “I can do it for open
systems, too,” has a value associated with it. The other thing I wanted to spin
around was that, if you had to do real time, synchronized business continuance
things with, for example, Sybase Replicator or Oracle Replication, those things
just don’t work. Nobody can make them work right and there’s always these big
windows of exposure. So our problem, is that we have to draw a picture out in
the future when the customer is going to have to do this because they’re not
doing it today.
In the past few weeks this next concept has raised a few eyebrows. It turns out,
in the dynamics of dealing with vendors, like the HPs and the Suns and the
IBMs, when you take storage out of the equation they have to compete on the
value of the system and the operating system they’re selling. Again, you’re
forcing them to unbundle their offerings. And, we’re finding that if a customer is
smart about that they can drive a better deal with their system vendor.
W arranty is a very important point. Every Symmetrix goes out the door with a
standard two year, 24 by 7 warranty. Do you know what the value of that is?
Many system vendors don’t even offer 24 by 7 and if they do they can’t offer the
same guaranteed response times we do. Not only that, the story is, you call the
guy, he comes out, he takes a look at it and then he has to go off and get parts.
W e’ve got remote support; we don’t have a problem. W e dial in, figure out what
the problem is and we show up with the right parts. So even if you could get this
service from your other system vendors it wouldn’t be of the same high quality
and responsiveness of what you get bundled in with your EMC Symmetrix as
part of your purchase price.
You’ll find, if you look at standard offerings, they don’t come 24 by 7, they come
with an option to go to 24 by 7 and there’s a significant value savings in that.
You just need to look, on a case by case basis, which vendor you’re dealing with
and you can establish a pretty significant value. All you have to do is say to your
customer “How much are you spending a year on maintenance?” The first two
years of maintenance are already taken care of with EMC.
This is also useful as a positioning tool. W e’re serious about this storage. W e’re
serious about your application. W hy would anybody want anything but 24 by 7
from a mainframe class organization?
Everyone’s impressed by the fact that we use much less floor space because,
again, these HPs and Sun Arrays just seem to expand all over the floor but
unless somebody’s up against the wall, literally and figuratively speaking, it’s
hard to get the importance of that point across.
Let me give you two examples. I talked to a customer and because of the good
job Symmetrix did, they had so much room in their data center it just didn’t
matter. But I’ve run into many more customers where they have a room is a
problem. They have room that’s dedicated to open systems and I’ve said
“W here are you putting this additional storage and servers that are coming in?”
and the answer is that they’re having to build another building. So I ask them “If
we could delay or defer your expansion into a new building, not just the
floorspace you save at $15 a square foot, what’s that worth?”
You have to ask the question. And you may not have all the answers but the
value is in asking the question and getting the customer to agree to the value.
And if the problem isn’t there today there’s a good chance it’ll be there in the
future: growth, capacity problems, performance challenges.
So, we’ve made it through our chart. W e hope we’ve spawned some interesting
thinking about how you can establish value with your customers.