I have a number of P Series frames using FCoE with VIOS to share with AIX LPARs. So this is isn't exactly the same, but here's my experience:
The major thing that I found with FCoE wasn't necessarily the connection speeds (which were fairly functionally comparable to dedicated 8gb HBAs and 10Gb NICs), but the memory requirements of the card. There's a bit of tweaking that has to happen with FCoE wherein it will easily oversaturate the memory buffers using the default settings, especially if you're experiencing a high network load. It takes some trial and error to get it to all play nicely together. The other issue that I came across -- this one might be extremely specific to my environment, but if there's a flapping port situation in your SAN, the SAN connection part of the FCoE card seems to just give up after a while, and the only way I (or the vendor) could get it to cooperate again was to re-initialize the card by doing a cold boot of the VIO Server. I hope this helps. On Tue, Apr 1, 2014 at 9:38 AM, Christina Plummer <[email protected]> wrote: > My company is in the process of planning a new data center, and is looking > to avoid the cost associated with traditional fibre channel storage. The > original plan was use 10Gb NFS for everything (mostly ESXi hosts, plus some > big Oracle RAC servers on RHEL6). But after doing some more research, the > database guys are balking at NFS and want to stick with block devices. So, > that is leading us back to FCoE for the Oracle databases (they'll stick with > NFS for the ESXi hosts). > > They apparently attempted FCoE about 4 years ago when the converged network > adapters were new, and ran into a number of issues (I don't know what they > were). I've personally worked a lot with traditional FC on RHEL, but > haven't ever done anything with FCoE. Our network gear is Cisco, the > storage is NetApp. > > Does anyone have any comments, experiences or things to watch out for? > > Thanks, > Christina > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ > -- ---------------------------- Regards, Michael Shulman [email protected] Never attribute to malice that which can be adequately explained by stupidity. _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
