Netapp FC-SAN experiences anyone??

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

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

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

On 21 Feb 2005 11:59:51 -0800, "
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

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.

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.

"Yura Pismerov" wrote in message
...
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.


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

On 25 Feb 2005 10:12:11 -0800, (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

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

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.