Say I have SAN and VoIP traffic going over the same link.
The text books say to put VoIP in LLQ, then SAN traffic comes along and appears to want much less than 20mS round-trip time for something like EMC SRDF/Synchronous (SRDF/S).
So is it best to,
1) Create 2 LLQ queues so SAN and VoIP can be configured with separate policing. Problem is now both lots of traffic are being FIFO'ed with respect to each other, within the LLQ.
or
2) Give SAN traffic PHB EF and VoIP AF41 or CS4. Trouble is this starts breaking down Cisco's "QoS Baseline Marking Recommendation". See,
it is down to what is most important and the design
voice doesnt work unless you have low latency and reasonably low jitter - but "low" in this context usually means over a slow serial link, and 50 mSec round trip.
if you are doing sync replication between disc systems then you need some serious bandwidth - i suspect 100 Mbps is a realistic bare minimum.
Gigabit is probably a lot better unless you want disc performance where you can count the bits going past by hand...
whether you can afford the bandwidth you need for the performance you want is a separate Q - but if you are buying EMC for this then you are already spending a lot
formatting link
1st thing to do if you dont understand the scale of a problem is a worked example
so assumptions on...... given you have a big enough link to handle the SAN, i would expect voip to be only a small fraction of total traffic. San will use big frames, voip packets are small.
say you have a 100 Mbps link, and up to 100 voice calls at the same time.
even if you dont compress the voice - a voice call takes around 100 Kbps.
100 calls is 10 Mbps, or 10% of your link. voip will evenly space packets, so SAN traffic will be able to use the "gaps" between voip packets - i.e. only wait for at most 1 voip packet.
so - very roughly (ignoring statistics, modelling and stuff) if EMC traffic is (almost) saturating the link, and voice gets priority then maybe 1 in a few EMC packets gets Qed behind a voip packet. G.711 voice packets are approx 200 bytes, or 1600 bits. Added delay = 1600 / 100M = 16 uSec.......(i think that is around the same delay as ~3 Km of fibre)
the other way of looking at this is that storage only gets 90% of the link. But if you didnt add a fair amount of headroom to the bandwidth the storage guys have calculated they need, then the SAN traffic is going to Q, and that will add more delay.
(the really big assumption here is that someone worked out how much bandwidth you need for the EMC traffic - often the "number" is just a guess - i suggest you test this, preferably with your app before you commit to the design)
of course on a slower link, or with a big %age of voice the added delay goes up quickly. But a 2M link probably breaks the storage link anyway.
The SRDF traffic will be orders of magnitude greater that the VoIP traffic and 20ms is a lifetime in LAN environment. I would not put the SRDF traffic in a LLQ, just put it in you highest priority category. If you are running this across a WAN connection (not point-to-point dark fiber), than you need to have a very serious conversation with you SAN group. With Synchronous SRDF, any interruption in the link will cause SRDF to cease all writes to the SAN on BOTH sides because a write is not committed until it is written to both sides. The remote side is offline, the local side is offline as well. On a WAN link, even a brief link loss such as neighbor reset will cause major headaches. On WAN connections, Asynchronous SRDF is the way to go.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.