Comments (11)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 simmiy commented Permalink

IS there a way to disable QoS on all the ports of a switch with one command or do I need to run this command for all the ports individually.

2 seb_ commented Permalink

At the moment, I'm not aware of such a possibility. But I'll have a look. So at first I would start with the ISLs, because there it really makes sense. And before you attach additional ISLs, re-configure them as well.

3 seb_ commented Permalink

I checked again, but I found no possibility other than a script or a loop. But as it is disruptive for a short time for all ports that are re-configured, I would either do it in a maint. window or stick with my previous recommendation: do it just for the ISLs and new ISLs in the future.

4 Kareem_in_Toronto commented Permalink

Hi, I raised this point to Brocade and they recommended that we leave QoS Enabled on our ISL's, but that we should not use QoS via zoning prefix. They mentioned that they don't have any customers in Canada who actually use QoS and hinted that either it wouln't work as designed/expected and that it was not appropriate in our environment. They recommended that we add additional ISL's for frame flow instead (with QoS enabled by default). <div>&nbsp;</div> I asked why then is QoS enabled by default and they replied "so that customers who want to use it can, and then it's not disruptive to enable it." I don't follow their logic since they said no customers are using it and it seems to be against their recommendation. <div>&nbsp;</div> Do you know of customers where disabling QoS improved their fabric flow and/or custmers who have implemented QoS to segregate different slow drain devices over different VC's?

5 seb_ commented Permalink

Hi Kareem, <br /> Over the years I saw one European customer actively trying to use it and heard of one other customer by a colleague. (unfortunately both are not reference customer's). I think the reason why it's not used is in most cases that the classification of traffic into the 3 priorities is a complex discussion between all the involved teams (applications, pre-production, development, host infrastructure, SAN, storage) and there is a big psychological as well as a big business part in that discussion. <br /> However I had much more cases where QoS was not used as intended but enabled per default. In some of them it was the reason for their performance problems, specifically in one instance it made the difference between thousands of frame discards in a 3h time frame and - after disabling it - no problem anymore. <br /> Nevertheless I understand Brocade's stance, but I don't share it. I see no point in reducing the buffers of ISLs artificially without any benefit and then adding additional - also reduced - ISLs. ISLs don't come for free. Buying cables and SFPs and having ports being blocked from usage for device connections doesn't sound like a preferable solution for me. Most probably you know that better than I. <br /> So if you don't use it and don't plan to use it, I recommend to disable it and free up the buffers.

6 EndtoEnd commented Permalink

Permalink very good blog, along with this, in my two have 2 sites in each SAN switch (redundant) I want to make the change and following the blog should disable QOS in the ports we are using to ISL in our case is 1 port 8gb and from both ends?. <div>&nbsp;</div> another query, what is the priority you have my areas if they have no prefix current High - Medium - Low?

7 EndtoEnd commented Permalink

PERMALINK we can disable all port QOS not only in the ISL? <br /> so if we buffer priority <div>&nbsp;</div> thanks !!!

8 seb_ commented Permalink

Hi Nelson, Thanks for your feedback! As far as I understood your questions right: 1) To disable QoS on a link it's enough to disable it on one side of it. As soon as not both sides are configured as QoS the link will not do QoS in either direction. If a link does QoS can be seen in islshow - there would be the word "QOS" behind the link then. However to have a clean, consistent setup you might want to disable it on both sides. 2) The priority assigned to any end-device pair not being in a QOSL (low) or QOSH (high) zone is medium. 3) Yes the main concern is with ISLs. There is however the possibility to do QoS on F-Ports, too. This could be done for the link to Access Gateways (never did it myself) or with HBAs supporting that concept (like the Brocade ones) which is called Server Application Optimization (SAO - ). If you have Brocade HBAs, please check them - I'm not aware about any problems in that direction so far...

9 AngeloBernasconiBlog commented Permalink

Seb, talking about SVC Enhanced Stretched Cluster (this is the new name) in configuration with ISL. <br /> We wish, the customer wants, to use XISL to share Private SAN and Public SAN traffic in order to reduce the links number and port on DWDM. <br /> Actually This configuration is not supported, but we are pushing RPQ team in order to be supported and QoS could be a good weapond to win against the RPQ team and against the competition that is proposing its virtualization solution w/o this connectivity limits. <br /> The question is: <br /> Is it possible to use QoS on XISL that will share traffic from two different LSAN ? <br /> Is there any Best Practices or something do not do ? <br /> Thanks in advance

10 seb_ commented Permalink

Hi Angelo! To be honest, I wouldn't do it that way. QoS is pretty much a "100% on or 100% off"-thing. I mean you can't just do "a little" QoS. As soon as you enable it, you should setup a priority for all zoned device pairs that you want to be low or high - the rest stays medium. But if you only have the inter-node-communication on high and the rest on medium, you might run into buffer problems as described above. I'll take some time later to think again about the whole thing but up to now I'm not convinced that it's the best solution.

11 seb_ commented Permalink

I thought through it again and I have to admit, I start to get "comfortable" with the idea. Maybe we should continue this discussion in sametime.