|
Home > Archive > Data Storage > March 2005 > Netapp FC-SAN experiences anyone??
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]
| Author |
Netapp FC-SAN experiences anyone??
|
|
| Rob Turk 2005-02-14, 5:45 pm |
| I'm trying to evaluate NetApp's SAN functionality, not the iSCSI way but
Fibre Channel.
Network Appliance offers FC-SAN connectivity for real fibre SAN's. Inside
the box the LUN's they offer exist as files on top of their WAFL filesystem.
So the LUN's are pure virtual. To me that sounds like it could be beneficial
as this allows NetApp to do all the clustering, cache, snapshot and remote
replication over Ethernet stuff they do on any of the files stored on their
box.
Has anyone tried their FC-SAN setup at all? How does the performance compare
to, say, an IBM DS4300 or an HDS 9570 for streaming and transactional loads?
What experiences have you had, good or bad?
Rob
| |
| Faeandar 2005-02-15, 2:45 am |
| On Mon, 14 Feb 2005 22:55:01 +0100, "Rob Turk"
<_wipe_me_r.turk@chello.nl> wrote:
>I'm trying to evaluate NetApp's SAN functionality, not the iSCSI way but
>Fibre Channel.
>
>Network Appliance offers FC-SAN connectivity for real fibre SAN's. Inside
>the box the LUN's they offer exist as files on top of their WAFL filesystem.
>So the LUN's are pure virtual. To me that sounds like it could be beneficial
>as this allows NetApp to do all the clustering, cache, snapshot and remote
>replication over Ethernet stuff they do on any of the files stored on their
>box.
>
>Has anyone tried their FC-SAN setup at all? How does the performance compare
>to, say, an IBM DS4300 or an HDS 9570 for streaming and transactional loads?
>What experiences have you had, good or bad?
>
>Rob
>
No personal experience for reasons I'm about to mention; but alot of
homework on it.
Fiber channel is considered an interrupt to the primary functions of
the filer, namely NFS and Snap*. It takes precendence over CIFS but
just about everything does already. Traffic out of FC on a filer is
secondary to Ethernet, so there's one thing to consider. Of course,
if this will only be SAN then no issue.
Second, clustering good. Cache good. Snapshot and remote replication
problematic.
If you're using an application that NetApp officially supports (like
Exchange or SQL Server) then they have nice tools that tie snapshots
and IO quiesence together. If not, then you need to manually (or
scripted, but your dime) halt IO to the LUN in order to get a good
snapshot. Under Ethernet circumstances this is not an issue, Ontap
takes care of the traffic.
The same problem holds for remote replication, mainly Snap*.
The you have to factor in OS upgrades and such against your apps.
Over NFS, or even CIFS to a limited degree, apps will handle the
reboot time of an upgrade without barfing. Not all apps will if they
are making direct access calls (or what they think are direct). The
OS shields the app from the NFS timeouts in almost all cases. And
CIFS is stateful so it will reconnect on next use (unless you were
actually transferring data, then you gotta start over).
Since no personal experience I can't speak to performance. I hear
it's good, but given my first point I would tend to classify it at
best around 9570 performance. At best.
Don't get me wrong, I love NetApp. But SAN is not their thing. They
have the best NAS on the market, bar none. But SAN? Not in my
opinion.
~F
| |
|
| On Tue, 15 Feb 2005 02:52:50 GMT, Faeandar wrote:
[excellent appraisal snipped]
>Since no personal experience I can't speak to performance. I hear
>it's good, but given my first point I would tend to classify it at
>best around 9570 performance. At best.
I don't think it's that good... :-/
>Don't get me wrong, I love NetApp. But SAN is not their thing. They
>have the best NAS on the market, bar none. But SAN? Not in my
>opinion.
I agree with you completely, but I wanted to point out that just
because it might not be the best SAN in the world doesn't mean that
it's not suitable for the OP.
The OP didn't specify what he wants the storage for. I wouldn't
necessarily want to run a huge OLTP system off the FC ports on a
Filer, but if I had lower performance requirements it might just suit
fine.
I think the NetApp approach works exceptionally well from a unified
storage pool perspective. If I wanted one reasonably priced device
that would do pretty much everything well, NetApp would be a good
choice.
HVB.
| |
| Faeandar 2005-02-16, 5:45 pm |
| On Tue, 15 Feb 2005 11:30:48 +0000, HVB <devnull@127.0.0.1> wrote:
>
>I agree with you completely, but I wanted to point out that just
>because it might not be the best SAN in the world doesn't mean that
>it's not suitable for the OP.
>
>The OP didn't specify what he wants the storage for. I wouldn't
>necessarily want to run a huge OLTP system off the FC ports on a
>Filer, but if I had lower performance requirements it might just suit
>fine.
>
>I think the NetApp approach works exceptionally well from a unified
>storage pool perspective. If I wanted one reasonably priced device
>that would do pretty much everything well, NetApp would be a good
>choice.
>
>HVB.
The OP was talking about FC specifically, and in that case I would say
it's not acceptable. Primarily because of unpredictable application
behavior during a reboot/upgrade/failover as well as the performance
interrupt. Even if the the latter is not not important the former
still applies.
Now, if the actual intent is simply block level storage then by all
means try it. But use iSCSI instead of FC. iSCSI has configurable
timeouts very similar to NFS, and application behavior is much more
predictable. And ethernet is what the filer was designed for...
~F
| |
| Faeandar 2005-02-17, 5:46 pm |
| On Tue, 15 Feb 2005 02:52:50 GMT, Faeandar <mr_castalot@yahoo.com>
wrote:
>On Mon, 14 Feb 2005 22:55:01 +0100, "Rob Turk"
><_wipe_me_r.turk@chello.nl> wrote:
>
>
>No personal experience for reasons I'm about to mention; but alot of
>homework on it.
>
>Fiber channel is considered an interrupt to the primary functions of
>the filer, namely NFS and Snap*. It takes precendence over CIFS but
>just about everything does already. Traffic out of FC on a filer is
>secondary to Ethernet, so there's one thing to consider. Of course,
>if this will only be SAN then no issue.
>
>Second, clustering good. Cache good. Snapshot and remote replication
>problematic.
>If you're using an application that NetApp officially supports (like
>Exchange or SQL Server) then they have nice tools that tie snapshots
>and IO quiesence together. If not, then you need to manually (or
>scripted, but your dime) halt IO to the LUN in order to get a good
>snapshot. Under Ethernet circumstances this is not an issue, Ontap
>takes care of the traffic.
>The same problem holds for remote replication, mainly Snap*.
>
>The you have to factor in OS upgrades and such against your apps.
>Over NFS, or even CIFS to a limited degree, apps will handle the
>reboot time of an upgrade without barfing. Not all apps will if they
>are making direct access calls (or what they think are direct). The
>OS shields the app from the NFS timeouts in almost all cases. And
>CIFS is stateful so it will reconnect on next use (unless you were
>actually transferring data, then you gotta start over).
>
>Since no personal experience I can't speak to performance. I hear
>it's good, but given my first point I would tend to classify it at
>best around 9570 performance. At best.
>
>Don't get me wrong, I love NetApp. But SAN is not their thing. They
>have the best NAS on the market, bar none. But SAN? Not in my
>opinion.
>
>~F
Update to my original post. I did some checking on the FC priority
thing. Turns out only *backup* FC traffic is low priority, not data
transfer traffic like SAN or (duh) disk access. I thought OT new the
difference between it's disk FC controllers and any other FC
controllers. That is not the case, it only knows the difference
between dump and not-dump, not FC or non-FC. So even backup traffic
over ethernet is low priority.
So one of my arguments against NetApp SAN is not valid. However, my
gut still says bad idea. But your gut may say differently.
~F
| |
| Rob Turk 2005-02-17, 5:46 pm |
| "Faeandar" <mr_castalot@yahoo.com> wrote in message
news:per911lg0v1f049l252t3d6se1294f9vke@
4ax.com...
>
> Update to my original post. I did some checking on the FC priority
> thing. Turns out only *backup* FC traffic is low priority, not data
> transfer traffic like SAN or (duh) disk access. I thought OT new the
> difference between it's disk FC controllers and any other FC
> controllers. That is not the case, it only knows the difference
> between dump and not-dump, not FC or non-FC. So even backup traffic
> over ethernet is low priority.
>
> So one of my arguments against NetApp SAN is not valid. However, my
> gut still says bad idea. But your gut may say differently.
>
> ~F
Thank you for your in-dept analysis. My gut feeling is exactly like yours,
that's why I asked in the first place. The customer's intent is to hook up a
2-node AIX HACMP cluster to the FC-SAN side of the filer, then use async
replication to replicate to a secondary Filer on a fairly low-bandwidth
(10Mbit) link. The AIX machines are used for database stuff, mostly read.
I've been able to find next to nothing on real production iSCSI experiences
for AIX, and customer wants SAN, not NFS..
They also have a couple of Windows machines that they'd like to use CIFS on
the Filer too, and replicate that as well.
Rob
| |
| Faeandar 2005-02-17, 5:46 pm |
| On Thu, 17 Feb 2005 21:48:27 +0100, "Rob Turk"
<_wipe_me_r.turk@chello.nl> wrote:
>"Faeandar" <mr_castalot@yahoo.com> wrote in message
> news:per911lg0v1f049l252t3d6se1294f9vke@
4ax.com...
>
>Thank you for your in-dept analysis. My gut feeling is exactly like yours,
>that's why I asked in the first place. The customer's intent is to hook up a
>2-node AIX HACMP cluster to the FC-SAN side of the filer, then use async
>replication to replicate to a secondary Filer on a fairly low-bandwidth
>(10Mbit) link. The AIX machines are used for database stuff, mostly read.
>I've been able to find next to nothing on real production iSCSI experiences
>for AIX, and customer wants SAN, not NFS..
>
>They also have a couple of Windows machines that they'd like to use CIFS on
>the Filer too, and replicate that as well.
>
>Rob
>
The "SAN not NFS" aspect is very old world. We tested Oracle 10g RAC
over NFS on a pair of filers and it rocked. Absolutely kicked XXX.
But the initial investment was more than the DB group wanted to spend,
so they ended up on an existing SAN. They are already regretting it
because the 20 line scripts I provided as examples for backup,
replication, and test environment refreshes are in the process of
becoming 7 different scripts and a proprietary binary from the storage
vendor. All that *after* a 3 day on-site consultancy and 2 weeks of
prep.
No idea how well it works for non-Oracle db's but Oracle over NFS is
fantastic. Especially RAC. They actually recommended NFS until they
got a GA release of OCFS. But OCFS blows goats so NFS is still the
best solution in that case.
On a side note, someone (I believe it was CITI but I could be
mistaken) showed that NFS as a protocol is just as fast as Fiber
Channel (scsi). It's all in the implementation...
Just food for thought.
We also have production iSCSI in place for SQL Server but no AIX
involved anywhere. That is just a matter of testing the client
though.
~F
| |
| victor.engle@gmail.com 2005-02-18, 5:45 pm |
|
Faeandar wrote:
> On Thu, 17 Feb 2005 21:48:27 +0100, "Rob Turk"
> <_wipe_me_r.turk@chello.nl> wrote:
>
priority[vbcol=seagreen]
data[vbcol=seagreen]
the[vbcol=seagreen]
traffic[vbcol=seagreen]
my[vbcol=seagreen]
yours,[vbcol=seagreen]
hook up a[vbcol=seagreen]
async[vbcol=seagreen]
low-bandwidth[vbcol=seagreen]
read.[vbcol=seagreen]
experiences[vbcol=seagreen]
CIFS on[vbcol=seagreen]
>
> The "SAN not NFS" aspect is very old world. We tested Oracle 10g RAC
> over NFS on a pair of filers and it rocked. Absolutely kicked XXX.
>
> But the initial investment was more than the DB group wanted to
spend,
> so they ended up on an existing SAN. They are already regretting it
> because the 20 line scripts I provided as examples for backup,
> replication, and test environment refreshes are in the process of
> becoming 7 different scripts and a proprietary binary from the
storage
> vendor. All that *after* a 3 day on-site consultancy and 2 weeks of
> prep.
>
> No idea how well it works for non-Oracle db's but Oracle over NFS is
> fantastic. Especially RAC. They actually recommended NFS until they
> got a GA release of OCFS. But OCFS blows goats so NFS is still the
> best solution in that case.
>
> On a side note, someone (I believe it was CITI but I could be
> mistaken) showed that NFS as a protocol is just as fast as Fiber
> Channel (scsi). It's all in the implementation...
> Just food for thought.
>
>
> We also have production iSCSI in place for SQL Server but no AIX
> involved anywhere. That is just a matter of testing the client
> though.
>
> ~F
| |
| victor.engle@gmail.com 2005-02-18, 5:45 pm |
| I would be cautious of NetApp endorsements for block level
requirements, especially in the absence of any benchmarks,
configuration info or any meaningful comparisons or stats. SAN
technology is not "old world" at all. There are situations where SAN
makes much more sense than NAS and visa-versa. For file services like
nfs and cifs NAS is the obvious choice. For block level requirements
like database or other disk intensive applications SAN is the obvious
choice.
As far as FC SAN with a NetApp I think this only makes sense if you
also need nfs and cifs although I still think that Netapp makes
absolutely the most expensive "file server" on the planet.
An alternative approach for consolidating the storage pool would be a
Hitachi array with a netapp gateway if you really need the netapp.
Otherwise possibly a SAN of some type with a hefty HP/Compaq or Dell
server running samba and nfs may work for a lot less money.
Regards,
Vic
| |
| Yura Pismerov 2005-02-18, 5:45 pm |
|
SAN is not an obvious choice for Oracle.
Read, for example, this:
http://www.google.ca/url?sa=U&start...3322.pdf&e=7629
victor.engle@gmail.com wrote:
> I would be cautious of NetApp endorsements for block level
> requirements, especially in the absence of any benchmarks,
> configuration info or any meaningful comparisons or stats. SAN
> technology is not "old world" at all. There are situations where SAN
> makes much more sense than NAS and visa-versa. For file services like
> nfs and cifs NAS is the obvious choice. For block level requirements
> like database or other disk intensive applications SAN is the obvious
> choice.
>
> As far as FC SAN with a NetApp I think this only makes sense if you
> also need nfs and cifs although I still think that Netapp makes
> absolutely the most expensive "file server" on the planet.
>
> An alternative approach for consolidating the storage pool would be a
> Hitachi array with a netapp gateway if you really need the netapp.
> Otherwise possibly a SAN of some type with a hefty HP/Compaq or Dell
> server running samba and nfs may work for a lot less money.
>
> Regards,
> Vic
>
| |
| Faeandar 2005-02-20, 5:47 pm |
| On 18 Feb 2005 06:04:02 -0800, "victor.engle@gmail.com"
<victor.engle@gmail.com> wrote:
>I would be cautious of NetApp endorsements for block level
>requirements, especially in the absence of any benchmarks,
>configuration info or any meaningful comparisons or stats. SAN
>technology is not "old world" at all. There are situations where SAN
>makes much more sense than NAS and visa-versa. For file services like
>nfs and cifs NAS is the obvious choice. For block level requirements
>like database or other disk intensive applications SAN is the obvious
>choice.
>
>As far as FC SAN with a NetApp I think this only makes sense if you
>also need nfs and cifs although I still think that Netapp makes
>absolutely the most expensive "file server" on the planet.
>
>An alternative approach for consolidating the storage pool would be a
>Hitachi array with a netapp gateway if you really need the netapp.
>Otherwise possibly a SAN of some type with a hefty HP/Compaq or Dell
>server running samba and nfs may work for a lot less money.
>
>Regards,
>Vic
As Yuri points out, block level is no longer the "obvious choice" for
databases. Hence my comment about old world. If you noticed in my
previous post I mentioned:
"They (Oracle) actually recommended NFS until they
got a GA release of OCFS. But OCFS blows goats so NFS is still the
best solution in that case."
The only time block level access was a requirement was when databases
used raw partitions. Once they started supporting file systems people
started using NFS immediately. Nasa JPL has been using Oracle on
NetApp for nigh 7 years now.
Not to say SAN doesn't have a place, but imo it's a niche really. I
know alot of people will say "look at market share" and "NAS can't
perform like SAN". To them I say, Windows has OS market share. And
NFS has been shown to be as fast as FC with the right implementation.
If people built an ethernet storage network with as much attention to
detail and stringent requirements as FC (although it doesn't *need*
the same stringent requirements) I say it will outperform today's FC.
And maybe tomorrow's.
Point is, Ethernet has been the surviving protocol for about 30 years
now. A myriad of protocols have come and gone, even supposed
ethernet-replacements. FC is on that list I believe.
Of course all this is a rant on FC v. ethernet but the original idea
still stands. There's ZERO reason not to run Oracle (or most other
db's) over NFS. And if you're looking to do clustered db environments
(like Oracle RAC), NFS is the BEST option. Ask Oracle, after you get
them past OCFS that is... it really does blow.
~F
| |
| victor.engle@gmail.com 2005-02-21, 5:46 pm |
| This paper was co-authored by a NetApp employee. This is only slightly
more informative than a NetApp filer brochure. I'm sure I could find
plenty of EMC and Hitachi white papers that would say exactly the
opposite. To me a disk intensive application makes more sense with 64k
fibre channel packets over a 2gb or 4gb storage network than with 1.5k
packets over a 1gb network. If I were to recommend something to my
employer I would want to base my decision on technical facts instead of
marketing propaganda.
Vic
| |
| Yura Pismerov 2005-02-22, 5:45 pm |
|
victor.engle@gmail.com wrote:
> This paper was co-authored by a NetApp employee. This is only slightly
> more informative than a NetApp filer brochure. I'm sure I could find
> plenty of EMC and Hitachi white papers that would say exactly the
I wonder why Hitachi uses NetApp in their Gfilers and recommends using it for certain applications to offload I/O operations from
the host to the filer...
> opposite. To me a disk intensive application makes more sense with 64k
> fibre channel packets over a 2gb or 4gb storage network than with 1.5k
> packets over a 1gb network. If I were to recommend something to my
What speed of the link has to do with it ?
Like you can't install multiple GBICs and use trunking with netapp ?
> employer I would want to base my decision on technical facts instead of
> marketing propaganda.
LOL ! What your employer has to do with it ? Job security issues ? 
Besides, what do you call "technical facts" ? There is always sources you have to rely on.
Or you say you always rely on your own experience and you have all the hardware to prove that you are right ?
You are a very lucky person...
>
> Vic
>
| |
| Yura Pismerov 2005-02-22, 5:45 pm |
|
Faeandar wrote:
>
> Of course all this is a rant on FC v. ethernet but the original idea
> still stands. There's ZERO reason not to run Oracle (or most other
> db's) over NFS. And if you're looking to do clustered db environments
Just to be fair. I had negative experience of running PostgreSQL off a NetApp.
Switching to DAS gave significant performance improvement.
But again, nobody did anything in Postgres to optimize it for NFS, unlike Oracle...
> (like Oracle RAC), NFS is the BEST option. Ask Oracle, after you get
> them past OCFS that is... it really does blow.
>
> ~F
>
>
| |
| Faeandar 2005-02-23, 2:45 am |
| On 21 Feb 2005 11:59:51 -0800, "victor.engle@gmail.com"
<victor.engle@gmail.com> wrote:
>This paper was co-authored by a NetApp employee. This is only slightly
>more informative than a NetApp filer brochure. I'm sure I could find
>plenty of EMC and Hitachi white papers that would say exactly the
>opposite. To me a disk intensive application makes more sense with 64k
>fibre channel packets over a 2gb or 4gb storage network than with 1.5k
>packets over a 1gb network. If I were to recommend something to my
>employer I would want to base my decision on technical facts instead of
>marketing propaganda.
>
>Vic
It's not propoganda. Well it is, I mean everyone wants to make money
so marketing plays a key role. But who was the other author on this
paper?
I can tell you that Oracle uses NetApp internally. Alot of it too.
In fact, Oracle became NetApps second largest customer in the last 2
years. That's not a coincidence. Part of the reason I'm sure is to
stick it to Veritas but you can't do that unless you have a viable
alternative.
And the filer is not just viable but awesome. Performance for all but
the most IO intensive applications rocks, the snapshot funtionality of
a filer is unsurpassed, and the DR or test environment scenario with
Snap* is the easiest bar none.
I've dealt with HDS in this arena and it is much more difficult to
make it all work. And performance was no better, in this case.
You mention packet size and pipe. Well alot of DB apps don't ask for
more than 1-4k per request. Meaning all that extra payload in FC is
wasted. So the pipe is not really an issue, but even supposing it is
you can still trunk as mentioned previously.
~F
| |
| StorProfi 2005-02-25, 5:45 pm |
| Hi All!
We speak about Oracle. Perhaps you can help me with your experience
in another environment with a NetApp 270C and AIX / DB2 in SAN and
mixed with Windows in NAS.
Is right that NetApp is very good in NAS but not so good in pure SAN
FC environment ?
what about the Snapshots ? they are always 20% ? In all the
environments ?
How looks your experience in a heterogenous environment when the
NetApp shares access between NAS and SAN. If I good understand, is
SAN Block I/O emulated on top of WAFL and not native ?
I need to use a NetApp in an AIX / DB2 environment and I'm not sure if
this is the best solution.
There are anywehre troughput values for the NetApp in SAN environment
compared with a DS4300, or Clarion, or.... ( native FC solutions ) ???
Thanks a lot for all comments !!
Alfredo.
| |
| Yura Pismerov 2005-02-25, 5:45 pm |
|
StorProfi wrote:
>
> what about the Snapshots ? they are always 20% ? In all the
> environments ?
Size of the snapshots really depends on how often your data are being changed.
The more changes between the snapshots, the more space is being taken.
>
> How looks your experience in a heterogenous environment when the
> NetApp shares access between NAS and SAN. If I good understand, is
> SAN Block I/O emulated on top of WAFL and not native ?
I believe WAFL is only for NAS.
I might be wrong, but in mixed environments NetApp head unit is connected to SAN and uses a pool of disks
from it to export the disk space to NFS clients. So you still can connect SAN disks directly without NetApp, or you can use NAS.
Obviously whatever disks are currently assigned to NetApp can not be attached to the SAN clients directly.
>
> I need to use a NetApp in an AIX / DB2 environment and I'm not sure if
> this is the best solution.
>
> There are anywehre troughput values for the NetApp in SAN environment
> compared with a DS4300, or Clarion, or.... ( native FC solutions ) ???
>
I'd say you will have a better option with HDS solutions that uses rebadged NetApp in their systems (that provide mixed SAN/NAS access).
In this case you will get advantage of the best NAS solution and you will have SAN capable storage under the same management "umbrella".
> Thanks a lot for all comments !!
>
> Alfredo.
| |
| Rob Turk 2005-02-25, 5:45 pm |
| "Yura Pismerov" <ypismerov@tucows.com> wrote in message
news:cvnt0r$8dh$1@bfos.tucows.com...
>
> I believe WAFL is only for NAS.
> I might be wrong, but in mixed environments NetApp head unit is connected
> to SAN and uses a pool of disks
> from it to export the disk space to NFS clients. So you still can connect
> SAN disks directly without NetApp, or you can use NAS.
> Obviously whatever disks are currently assigned to NetApp can not be
> attached to the SAN clients directly.
>
As far as I know WAFL is being used throughout the Filer and on all attached
disks. iSCSI LUN's and FC-SAN LUN's are just files on top of the WAFL file
system, which allows NetApp to do all the fancy snapshot/cache/replication
stuff with SAN.
Rob
| |
| Faeandar 2005-02-26, 2:45 am |
| On 25 Feb 2005 10:12:11 -0800, iscsi2005@yahoo.com (StorProfi) wrote:
>Hi All!
>We speak about Oracle. Perhaps you can help me with your experience
>in another environment with a NetApp 270C and AIX / DB2 in SAN and
>mixed with Windows in NAS.
>
>Is right that NetApp is very good in NAS but not so good in pure SAN
>FC environment ?
That's my opinion, but not necessarily accurate for all workloads or
environments. It probably is but ....
>
>what about the Snapshots ? they are always 20% ? In all the
>environments ?
Configurable. All depends on rate of change. May only need 5% or may
need 30%. Time will tell.
>
>How looks your experience in a heterogenous environment when the
>NetApp shares access between NAS and SAN. If I good understand, is
>SAN Block I/O emulated on top of WAFL and not native ?
That is correct. It's native as far as the app/host is concerned but
it really is a file on WAFL being server out by the filer. There is
no direct block access to a filer, only WAFL can do that.
>
>I need to use a NetApp in an AIX / DB2 environment and I'm not sure if
>this is the best solution.
I'm not either. If you were to use it over NFS I would say likely,
but haven't tested the AIX NFS client to say for sure. For Redhat and
Solaris it works fine.
In a SAN config I would be concerned whether or not IBM supports it.
~F
| |
| boatgeek 2005-02-28, 5:46 pm |
| We have tons of NetApp storage (15 filer filers, 5 locations, 150 TBs)
and we use NFS connections for oracle financials, peoplesoft,
documentum. It better be supported by Oracle, because Oracle
themselves are the largest users of NetApp storage. NFS works
wonderfully, great performance and extremely flexible. Oracle dba's
launch and rsh script to put the database in hotbackup mode, take a
snapshot and then take it out of hotbackup mode. They love it because
it takes 5 seconds. They've recover oracle databases a lot using
this.
Regarding the filers as SAN storage, we use it for SQL and exchange.
Functionality is the key as the snapshots are controlled by the local
clients
the snapshot are consistent and recoverable (vs a traditional SAN
snapshot). The clients can have up to 254 of them, so they have a lot
of flexibility as to how often they take snapshots.
We also have equal amounts of storage on SANs. Mainly, SANs are very
good for a database which can never go down. NetApp isn't N+1
architecture and realistically you should tell your users that they
should plan on maybe 2 to 3 15 minute outages per year for maintenance.
Also if someone came to me with performance numbers which had 100s of
MBs per sec of throughput needed, then I would put them on a SAN. But
realistically, the only devices that can do that are large UNIX servers
which have high loads. Few people really have that, though most think
they do until they actually look at the numbers.
Let me know if I can be of any further help.
Doug Vibbert
| |
| boatgeek 2005-03-01, 5:45 pm |
| One quick note. NEVER on a netapp pick NTFS as the volume type upon
which you create a LUN. NEVER. Usually people have CIFS shares off
the netapp filers and eventually someone will want to do auditing on a
particular directory for security purposes. If you enable auditing,
it will then "audit" the NTFS volume with the LUN, and it will
absolutely kill the performance. It has to be UNIX permissions (even
if it has an volume such as sql for a windows server). We did that
once and everyone called up and asked why it was such a dog on
performance. When we switched the permission style to UNIX, it was 4
times the speed of the servers local disks.
| |
| Maxim S. Shatskih 2005-03-02, 5:49 pm |
| > absolutely kill the performance. It has to be UNIX permissions (even
> if it has an volume such as sql for a windows server).
UNIX-style permissions are absolutely fine for SQL. For any SQL - MSSQLServer,
Oracle, mysql etc.
Just disable all access to the files except for the admin and for the user
account under which the database engine runs (must be very low-privilege
account with only the rights for the database files and for backup device).
UNIX permissions start to be too primitive for a _file server_, but for a
database they are enough.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
|
|
|
|
|