Home › Forums › OS X Server and Client Discussion › Xsan › Configuring your Qlogic switch for use with Xserve and Xserve RAID
- This topic has 9 replies, 6 voices, and was last updated 19 years, 2 months ago by
cedge.
-
AuthorPosts
-
January 31, 2006 at 11:58 pm #365062
ibgarrett
ParticipantI’ve never seen this posted anywhere, and after going through great pain with getting this configured and setup I figured that it would be good to share the wealth.
When setting up a Qlogic FC switch between a MDC and the Xserve RAID, it’s very important to configure the switches as follows:
RAID attached ports (meaning coming to or from the FC switch and the RAID system) Set the port to use “F” for Fabric and make sure the I/O stream guard is disabled.
XServe attached ports (meaning the cable going to and from the FC switch and the Xserve), Set the port to use “F” for Fabric and make sure the I/O stream guard is enabled.
Without the ports set this way it caused us a great deal of headaches with the system dumping the FC network when the traffic patterns got to high. Once we had this set, with the aid of an Apple engineer, we were able to use the Xsan Tuner to test the I/O connection and it appeared fine.
Good luck!
Brian
February 1, 2006 at 12:58 am #365065maccanada
ParticipantYou’re right, I don’t think this is explicitly posted anywhere, but it is covered as part of the Xsan for Pro Video and Xsan Administration certification courses, as well as in the Peachpit Xsan Reference book.
It’s not only that, but every time a client reboots their machine and drops off the fabric, the switch will rescan to determine the status of each port – this will cause dropped frames in FCP – to prevent this you also need to disable the Device Scan for the same initiator ports (the ones going to hosts).
~Ian
February 1, 2006 at 2:33 am #365066MDhaliwal
ParticipantA lot of people miss this step or forget which port gets what kind of treatment. Pretty much, you have two types of ports, initiators and targets. Initiators are all of your clients, controllers, etc. Targets are your storage devices, such as Xserve RAID units, tape devices, etc.
Think of it this way…
If a client reboots or goes offline, do you care? You have redundant MDCs and a desktop may be running something like software update. You want to know ASAP if your storage goes offline, since you’ve just lost part of your volume. So suppress the messages you don’t care about, i.e. use I/O Stream Guard on the ports connected to the Xserves and PowerMacs.
February 1, 2006 at 6:56 am #365067cedge
ParticipantApple has posted some documentation for this process at http://docs.info.apple.com/article.html?artnum=302135
Charles Edge, ACSA, MCSE, CCNA, Network+
Author :: Mac Tiger Server Little Black Book
Partner :: Three18 Consulting
http://www.three18.com
[email protected]February 1, 2006 at 11:49 pm #365092rhcw
ParticipantDon’t forget that as well as setting the streamguard and device scan correctly on all the switch ports you need to also be careful how you set the XSERVE RAID cache settings etc. This only became an issue with 1.5 FW and Admin. If you get this wrong then you will see RSCN behaviour when you shut down clients and reboot clients.
February 2, 2006 at 5:20 am #365099MDhaliwal
Participant[QUOTE BY= rhcw] Don’t forget that as well as setting the streamguard and device scan correctly on all the switch ports you need to also be careful how you set the XSERVE RAID cache settings etc. This only became an issue with 1.5 FW and Admin. If you get this wrong then you will see RSCN behaviour when you shut down clients and reboot clients. [/QUOTE]
Which setting are you talking about? The only setting I can think of that can degrade performance a bit that was introduced in Xserve RAID firmware 1.5 would be the Host Cache Flushing, which you set per controller and can re-enable itself on hardware reboot.
February 2, 2006 at 9:29 am #365100rhcw
ParticipantI have not actually upgraded any XSRs in an XSAN to 1.5 myself, although I am tucking into one today, but there was a chap in Germany who was suffering terribly with RSCN on an XSAN when clients were shut down or rebooted. He contacted me as I had posted similar issues in the summer (solved by turning off device scan using XSR 1.3 firmware). His problem turned out to be settings on the XSR settings – I think it was the host cache flushing and you are right the settings changed every time the XSR was rebooted.
February 2, 2006 at 3:50 pm #365106ICTFC
Participantre: XSR FW v1.5
Using Steady Streaming Mode will result in a reduction of overall bandwidth.February 5, 2006 at 7:46 pm #365166Anonymous
GuestUnder the Advanced Port Properties on the Sanbox2-64 there is an option for Auto Performance Tuning that by default is turned on. Considering how almost all of the other configurations for Xsan require turning something off or disabling it, it has made me wonder and I can’t seem to find any information about what this option does. The ALFairness option below it is disabled, and I assume doesn’t matter unless there’s an arbitrated loop somewhere in the mix.
Thoughts?
February 11, 2006 at 7:04 am #365268cedge
ParticipantAuto Performance Tuning allows the firmware to set frame sizes (MFS), logging and the fibre channel virtual interface (FC-VI) to maximize performance. I typically leave this setting at its default value, which sets all of these settings based on the switch type. Qlogic also suggests not messing with this one unless you are nasty good at programming these things…
Hope this helps,
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed