QoS: prioritize one VSAN over another

[Roman Rodichev]

Hi,

I understand that QoS configuration is per VSAN, but the actual QoS prioritarization happens globally, all VSANs share the High, Medium and Low queue.

So if I want to prioritize traffic in VSAN 10, over VSAN 20, over VSAN 30. Can I do this?

qos class-map MED

match any

qos class-map HIGH

match any

qos policy-map VSAN20

class MEDIUM

priority medium

qos policy-map VSAN10

class HIGH

priority high

qos service policy VSAN10 vsan 10

qos service policy VSAN20 vsan 20

Or do I have to identify specific source and destination FCID/pWWN?

[tblancha]

No, this does not prioritize one vsan over another. The current hardware does not allow for such a thing. The QoS is on a per vsan basis and within that vsan. Also, it is applied on ingress only so it needs to be configured appropriately by relative position in the fabric if there is more than 1 switch.

[Roman Rodichev]

I understand that I need at least two switches for QoS to work properly.

Let's say I have Switch A and Switch B.

Host10 connects to Switch A (VSAN10)

Host20 connects to Switch A (VSAN20)

Storage10 connects to Switch B (VSAN10)

Storage20 connects to Switch B (VSAN20)

Host10 talks to Storage10

Host20 talks to Storage20

I've read somewhere that when you have multiple egress ports, FCC won't help, but QoS should still help. Right?

When QoS is enabled, each ingress interface has three queueus: High, Med, Low. Do these queues know anything about VSANs?

If I put traffic from Host10 in VSAN10 in High queue, and traffic from Host20 in VSAN20 in Medium queue, wouldn't it prioritize traffic in VSAN10 over traffic in VSAN20 on ingress EISL port on Switch B?

[j.sargent]

Yes and no. If you put traffic from Host10 in the High queue, and traffic from Host20 in the Medium queue, the ingress port would prioritize the traffic from Host10 over the traffic from Host20. It would NOT, however, prioritize ALL traffic in VSAN10 over ALL VSAN20 traffic. You're getting confused on your class-maps:

qos class-map MED

match any

qos class-map HIGH

match any

^^^^These are not valid class-maps. You must have a "match" statement for it to match on anything. You can match on source-wwn, dest-wwn, SID, DID, source interface, or dest device alias. So a proper class-map might look like this:

qos class-map HIGH match-any

match input-interface fc 1/3

match input-interface fc 2/3

The "match-any" and "match-all" operators specify the criteria for a qualified match on your "match" statements, but you must have at least one "match" statement. You can't just "match-any" and expect it to apply to all traffic in the VSAN that you apply it to.

Does that make sense? See the configuration guide for syntax details and examples.

Hope that helps....

Josh

[j.sargent · Accepted solution]

Frames are marked per VSAN (or, service policies are assigned per VSAN), but there is not a scheduler for each VSAN as I understand it. The scheduler doesn't know about VSANs - it only knows about its 4 queues.

Therefore, a frame marked High in VSAN 10 will have priority over a frame marked Low in VSAN 20.

[j.sargent]

You must specify something to match - source wwn, dest wwn, SID, DID, input-interface, or destination device alias.

Or, you could give attributes to the zones to implement zone-based QOS.

[Roman Rodichev]

So what does "match any" do under "qos class-map"? Does that command do anything at all? If I have a lot of sources and destinations in my VSAN, do I have to specify each one?

[dmcloon]

There are two places you can specify "match any" and that is where the confusion comes from.

If you append a "match-any" (note the hyphen) on the class-map then the linecard forwarding ASICs will inspect each ingress frame and that frame will be classified on the first (if any) matching criteria. If there is no match the frame will be checked against any other class maps and if ultimately there is no match the frame will be put into the default "low" priority virtual output queue.

qos class-map truecopy-prefer match-any

match source-wwn 50:06:0e:80:00:42:83:53

match destination-wwn 50:06:0e:80:00:42:83:63

match input-interface fc1/1

The other place is "match any" (no hyphen) entered as the only criteria under the class map. This is like a wildcard and will catch all frames in the vsan it is applied to.

qos class-map test match-any

match any

[j.sargent]

Excellent - I didn't know you could do the wildcard thing...

Thanks!

[Roman Rodichev]

ok, so this means this config would prioritize one VSAN over another?

qos class-map MED

match any

qos class-map HIGH

match any

qos policy-map VSAN20

class MEDIUM

priority medium

qos policy-map VSAN10

class HIGH

priority high

qos service policy VSAN10 vsan 10

qos service policy VSAN20 vsan 20

[dmcloon · Accepted solution]

Correct.

But this would only kick in where there are competing flows hitting the same set of Virtual Output Queues (VoQ). In other words, you need traffic from both vsans 10 and 20 entering the same Queuing Engine ingress port and also destined to the same physical output port.

For example vsan 10 host on fc1/1 and vsan 20 host on fc1/2 both have disk I/O that need to traverse the same EISL link (which could be any interface). The TE port is a common output port for both hosts. The flows will be prioritized within the switch before they hit the forwarding engine for egress. If the EISL gets congested, frames will queue up in the VoQ buffers and the scheduler will service traffic from vsan 10 host more often than traffic from vsan 20 host.