I think it depends on your environment. AFAIK the one thing Fibre still has going for it is that it's *very* deterministic - you know what your latency will be and the level of jitter is very small. That does not mean it's "faster" than IP based connectivity but for some applications I can see *knowing* you are inside a very narrow set of parameters as being worth the extra hassle of maintaining a FC infrastructure. That should be very small percentage of the IT population though. I am quite happy with Oracle's performance over NFS.


On 12/20/2013 08:50 AM, Adam Levin wrote:
This may be a silly question, and is certainly a religious debate, but, ah, any reason you must put those Oracle databases on LUNs?  Why not just use NFS?

-Adam


On Thu, Dec 19, 2013 at 6:31 PM, Mark <mkopenski@gmail.com> wrote:

Lun moves work fine on cluster mode. It also works on 7-mode for aggregates on the same filer. 

Cluster mode is managed differently , allow for time for training and lots of testing in your environment. 

A drawback is that luns cannot be migrated without a third party appliance and a lengthy maintenance window. 




On Dec 19, 2013, at 5:57 PM, Michael Garrison <mcgarr@umich.edu> wrote:

There are limits to the maximum number of nodes in a cluster, which varies depending on the model. If I recall correctly, FAS6200 series with NO iSCSI or FCP can go up to 24 nodes. FAS6200 with iSCSI or FC can go up to 8 nodes. Mixing FAS3200 with FAS6200 means max of 8 nodes. 

We're in the process of transitioning some of our NFS customers over to a CMode system. We'll wait a bit for CIFS to be more baked, since only with the RC does it support offboard virus scanning and some other features 7mode has had for ages.
Pun 
--
Mike Garrison


On Thu, Dec 19, 2013 at 5:14 PM, John Stoffel <john@stoffel.org> wrote:

Guys,

We're looking to spec out a big Netapp cluster, and since 7-mode is
end of life in terms of new features, and it looks like 8.2.1RC1 is
now out, what do people think of it?

One question I have is whether I should get a bunch of 3250s in
cluster pairs, on the order of four or six heads all clustered
together, or whether it makes more sense to get a 6250 pair (or
pairs?) instead.

We're looking at roughtly 1 Petabyte of storage.  Probably 50% can be
SATA, the rest SAS, but possibly <20% would need to be FC LUNs for
Oracle DBs doing some ERP stuff.  Lots of IOPs will happen there.
Another thought is to get SSDs and setup FlexPools.  Which is nice
since you can prioritze volumes to get that speedup.  But which costs
like crazy from what I hear.

I'm hesitant of putting all my eggs into one big basket.

After talking with a FE, it looks like there are all sorts of goodies
in 8.2.1 and up, such that we can setup multiple Virtual Filers (now
known as SVMs I think) on the cluster and do transparent volume moves
across heads/aggregates, etc.  And moving a SVM from one cluster head
to another or to another set of nodes in the cluster.

My question of course, is how well dows this work in practise?  Esp
for FCP luns.  Being able to live move volumes between aggregates
looks to be a real help, since now I won't be stuck withe large, but
not endless aggregates.

Basically, I'm looking for what people think of how well this all
works in real life and what the gotchas are.  And of course, what
about tape backups over direct attached SAN FC tape drives from an
SVM?  How is that performance as well?

Thanks,
John
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters




_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters


Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.