|
Home > Archive > Data Storage > May 2005 > vendor comparison
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Faeandar 2005-05-01, 5:50 pm |
| I'm looking for some input as to vendor choices for a (potentially)
large SAN implementation. The vendors on the table are:
HDS
HP (new EVA line)
3Par
I've got experience with HDS 9900 and 9500 storage, I've had a 3Par
eval (although quite a while ago now, well over a year), and seen the
HP pitch on the new EVA line (which looks pretty good).
So I'm not a newbie on any of these. What I want from the community
is some thoughts, experiences, and problems had with any of the above
in implementation and production.
Details on the SAN are as follows:
3 windows clusters, Active/Passive with MS Cluster
dual fabric, seperate
start at 10TB usable, grow to 200TB over 3 years
Backups need to be non-prod host based. I doubt server free backups
are possible still (they've promising that for years now) but
snapshot/cloning of LUN's and presented to a backup server on the SAN
would be the least requirement.
This is the day-1 config, other hosts will jump on this within a week
and they will be both unix and windows.
Thanks.
~F
| |
| Charles Morrall 2005-05-02, 8:45 pm |
| Faeandar <mr_castalot@yahoo.com> wrote in message news:<r55571lu06roj1d25dfkikbf8ljkjcas2q@4ax.com>...
> I'm looking for some input as to vendor choices for a (potentially)
> large SAN implementation. The vendors on the table are:
>
> HDS
> HP (new EVA line)
> 3Par
>
> I've got experience with HDS 9900 and 9500 storage, I've had a 3Par
> eval (although quite a while ago now, well over a year), and seen the
> HP pitch on the new EVA line (which looks pretty good).
>
> So I'm not a newbie on any of these. What I want from the community
> is some thoughts, experiences, and problems had with any of the above
> in implementation and production.
>
> Details on the SAN are as follows:
> 3 windows clusters, Active/Passive with MS Cluster
> dual fabric, seperate
> start at 10TB usable, grow to 200TB over 3 years
>
> Backups need to be non-prod host based. I doubt server free backups
> are possible still (they've promising that for years now) but
> snapshot/cloning of LUN's and presented to a backup server on the SAN
> would be the least requirement.
>
> This is the day-1 config, other hosts will jump on this within a week
> and they will be both unix and windows.
>
> Thanks.
>
> ~F
Can only really comment on the EVA line.
The EVA can do all this at day 1, no problem. However, although the
EVA is designed for 200TB _usable_ behind a controller pair this isn't
available now. The EVA supports up to 240 physical drives, and that
would mean we would have to use a physical drive in the 1-1,5TB range.
Snapshot/cloning is ok, but there's no delta resync (yet).
It's a really sweet integration if you go for HP Data Protector as
your backup software. It really does work end-to-end with quiese app,
snap, restart app, present snap to backup host, despool to tape. At a
price, of course. The licenses aren't exactly freeware.
If you're looking at stretched clusters, the EVA will do replication
controller to controller. Looks smooth, you can fan in, fan out,
async, sync.
Integration is possible with MSCS with HP calls Cluster Extension. It
plugs into MSCS as a resource type, making integration easy.
There is no Secure Path requirement any more, MPIO for most OSes and
it's free.
The major thing with the EVA is the management. Sure, you can crunch
the numbers comparing IOPS, MB/s, capacity etc. But when it comes to
carving out LUNs, the EVA is the clear winner in my opinion. To create
a LUN, just set the size, raid 1 or 5, which host(s) get the LUN. Done
and done. I suppose those people who make a living out of looking at
performance counters all day and tune a storage system till the cows
come home won't be happy though.
| |
| Faeandar 2005-05-02, 8:45 pm |
| On 2 May 2005 06:14:03 -0700, charles.morrall@martinsson.se (Charles
Morrall) wrote:
>Faeandar <mr_castalot@yahoo.com> wrote in message news:<r55571lu06roj1d25dfkikbf8ljkjcas2q@4ax.com>...
>
>
>Can only really comment on the EVA line.
>The EVA can do all this at day 1, no problem. However, although the
>EVA is designed for 200TB _usable_ behind a controller pair this isn't
>available now. The EVA supports up to 240 physical drives, and that
>would mean we would have to use a physical drive in the 1-1,5TB range.
Is your experience with the new EVA line? I understood it was only
announced recently, like in the last 2 weeks.
Multiple contollers is ok, it just needs to scale well across multiple
controllers.
>
>Snapshot/cloning is ok, but there's no delta resync (yet).
>It's a really sweet integration if you go for HP Data Protector as
>your backup software. It really does work end-to-end with quiese app,
>snap, restart app, present snap to backup host, despool to tape. At a
>price, of course. The licenses aren't exactly freeware.
no delta resync would be a problem unless it's snapshot based. I
guess I need to hit HP up for some info on how that works exactly. If
All I need to do is take a snapshot, present the snapshot to a backup
host, and it can backup all the data needed then no problem. If I
need to sync the entire LUN each time, well that would be bad.
And we are stuck using Veritas NBU.
>
>If you're looking at stretched clusters, the EVA will do replication
>controller to controller. Looks smooth, you can fan in, fan out,
>async, sync.
>Integration is possible with MSCS with HP calls Cluster Extension. It
>plugs into MSCS as a resource type, making integration easy.
>
>There is no Secure Path requirement any more, MPIO for most OSes and
>it's free.
>
>The major thing with the EVA is the management. Sure, you can crunch
>the numbers comparing IOPS, MB/s, capacity etc. But when it comes to
>carving out LUNs, the EVA is the clear winner in my opinion. To create
>a LUN, just set the size, raid 1 or 5, which host(s) get the LUN. Done
>and done. I suppose those people who make a living out of looking at
>performance counters all day and tune a storage system till the cows
>come home won't be happy though.
I've always heard the EVA was at the top in terms of management,
features, functionality, ease of use, etc. It never made my list due
to performance but the new EVA appears to have made vast improvements.
Like anything though, there is still planning to be done. The
virtualization of the LUN creation is very nice (as is Xiotech's) but
you can have major contention if you put the wrong things together on
the same disks. But I understand what you are saying.
Thanks.
~F
| |
| Charles Morrall 2005-05-02, 8:45 pm |
| >>> ~F
>
> Is your experience with the new EVA line? I understood it was only
> announced recently, like in the last 2 weeks.
> Multiple contollers is ok, it just needs to scale well across multiple
> controllers.
>
The new EVA isn't officially announced yet, but I've gotten some info on it.
Scale across multiple controllers, well you can place all systems under one
management GUI, but you can't really see them as one unity. You still manage
each controller pair on it's own. You can't (easily) move LUNs between
controllers, or span a LUN across multiple controllers unless you use some
form of host based volume manager or inband volume controller.
>
> no delta resync would be a problem unless it's snapshot based. I
> guess I need to hit HP up for some info on how that works exactly. If
> All I need to do is take a snapshot, present the snapshot to a backup
> host, and it can backup all the data needed then no problem. If I
> need to sync the entire LUN each time, well that would be bad.
> And we are stuck using Veritas NBU.
>
It's all you need to do if you only want to backup the snapshot. It's not a
full resync if it's only a snapshot you want to make. However, if you want
to keep the snapshot as a way to redirect production to, it's not really
doable. The snapshot will work, but it will always have a connection to it's
mother LUN. Also, you can't do a snapshot of a snapshot, so it's an
emergency solution at best.
With the new EVA, there's a function to "preallocate" space for resync, and
according to HP this makes full resync quite fast.
>
> I've always heard the EVA was at the top in terms of management,
> features, functionality, ease of use, etc. It never made my list due
> to performance but the new EVA appears to have made vast improvements.
> Like anything though, there is still planning to be done. The
> virtualization of the LUN creation is very nice (as is Xiotech's) but
> you can have major contention if you put the wrong things together on
> the same disks. But I understand what you are saying.
>
> Thanks.
>
> ~F
In most cases, it's just a matter of sizing the number of disks you need
total for capacity. I've never heard of performance problems running vanilla
file, sql, oracle, exchange etc. Of course, if you have specific high
performance requirments, planning is a must.
| |
| grshpr 2005-05-18, 10:02 am |
| I can tell you that I have a fully loaded EVA5000 (with 240 disks in 1 disk group) and that we have had 0 performance issues. We have a mix of Windows and AIX attached to the EVA, as well as VMWare ESX.
We have 3 Oracle DB's, 1 DB2 database, 6 32-bit SQL Servers (all clustered) and 2 64-bit Itanium 2 (clustered).
We also have about 10 stand alone application servers, 1 file server, and 12 ESX servers. Inside the ESX servers we have 64 virtual servers running, doing mostly file, print and web, but we do have some application servers.
I just left the HP Storage Americas Conference and can tell you that the EVA8000 is a heck of a box, but I still wish I could get more disk arms. HP at that point will sell you the XP12000 (HDS resell). The new version of the management software will also include some long awaited performace indication software. The basic version is pretty limted, but their are plugins that can be added for a more robust look into the EVA8000 as well as looking into databases such as Oracle and MS SQL. List price on an EVA8000 is not much above a EVA5000, and due to the limitation of the storage capacity I would at this point rule it out, as I have done for a quote that I am working on currently. |
|
|
|
|