Okay, så vores Nimble CS235 SAN har kørt et års tid uden problemer, og hverken Nimble Infosight eller Veeam ONE har meldt nogle fejl.
Setup er 2 stk. Cisco C2960S switche konfigureret i et flexstack, 2 stk. Dell Poweredge R630 med 6 stk. 1 Gbit/s netkort i hver server, og Nimble san med 4 stk. 1 Gbit/s netkort i hver controller.
Alt trafik til SAN kører iSCSI mpio via 2 netkort fra hver server – så maximalt 2Gbit/s hastighed til disk storage. De resterende netkort i serverne er teamet sammen, og ovenpå har jeg oprettet virtuelle netkort til Cluster trafik, VM´ere, Live migration og Management – så de deles om 4Gbit/s trafik, hvor jeg har defineret QoS regler i powershell – så vi kører altså Hyper V.
Der kører ikke så mange VM´ere, så iscsi trafikken er ganske let og ligger normalt mellem 3 til 10Mbit/s. Men efter jeg installerede Zabbix monitorering software på Ubunbtu, som VM, begyndte jeg at få alarmer fra Veeam ONE, at min latency til de virtuelle maskiners harddisk ofte lå mellem 40 til 180ms.
En fejlsøgning viste ingen fejl. Infosight viste at Nimble boksen kørte upåklageligt med absolut minimal latency fra NVRAM til de fysiske diske (0,2 til 4ms), full duplex på alle netkort med jumbo frames på 9000 bytes hele vejen rundt, netkort drivere opdateret og en Cisco “sh int gigx/x/x” viste umiddelbart heller ikke pakke fejl.
Jeg måtte have fat i Nimble supporten. Jeg åbnede en sag, og vi snakkede lidt frem og tilbage. De kunne heller ikke se nogle problemer på SAN´et, men da jeg nævnte, at jeg kørte iscsi trafik over en c2960s switch, skrev de, at den model er notorisk kendt for at droppe pakker. Så jeg kiggede lige efter endnu engang på et iscsi interface med “sh int gigx/x/x” og ganske rigtigt, “total outout drops” var ekstrem høj på mine iscsi interfaces.
Jeg vil nævne, at ingen form for QoS var aktiveret på switch stacken, så den del var udelukket skulle være årsagen.
Jeg måtte google – og kunne hurtigt konstatere, at c2960s serien har en alt alt for lille pakke buffer, og kan slet ikke klare de bursts, som kommer periodisk, og ikke kan måles via snmp overvågning.
Hvad den faktiske størrelse af bufferen så er på en c2960s findes der (vist) ikke nogen dokumentation på – kun Cisco ved det. Men lille, det er den. Det nærmeste jeg kan komme noget konkret, er ASIC til fysisk port allokering med kommandoen:
sh platform pm if-numbers
Det giver følgende på 2960´eren:
interface gid gpn lpn port slot unit slun port-type lpn-idb gpn-idb
———————————————————————-
Gi1/0/1 1 1 1 0/2 1 1 1 local Yes Yes
Gi1/0/2 2 2 2 0/1 1 2 2 local Yes Yes
Gi1/0/3 3 3 3 0/4 1 3 3 local Yes Yes
Gi1/0/4 4 4 4 0/3 1 4 4 local Yes Yes
Gi1/0/5 5 5 5 0/6 1 5 5 local Yes Yes
Gi1/0/6 6 6 6 0/5 1 6 6 local Yes Yes
Gi1/0/7 7 7 7 0/8 1 7 7 local Yes Yes
Gi1/0/8 8 8 8 0/7 1 8 8 local Yes Yes
Gi1/0/9 9 9 9 0/10 1 9 9 local Yes Yes
Gi1/0/10 10 10 10 0/9 1 10 10 local Yes Yes
Gi1/0/11 11 11 11 0/12 1 11 11 local Yes Yes
Gi1/0/12 12 12 12 0/11 1 12 12 local Yes Yes
Gi1/0/13 13 13 13 0/16 1 13 13 local Yes Yes
Gi1/0/14 14 14 14 0/15 1 14 14 local Yes Yes
Gi1/0/15 15 15 15 0/18 1 15 15 local Yes Yes
Gi1/0/16 16 16 16 0/17 1 16 16 local Yes Yes
Gi1/0/17 17 17 17 0/20 1 17 17 local Yes Yes
Gi1/0/18 18 18 18 0/19 1 18 18 local Yes Yes
Gi1/0/19 19 19 19 0/22 1 19 19 local Yes Yes
Gi1/0/20 20 20 20 0/21 1 20 20 local Yes Yes
Gi1/0/21 21 21 21 0/24 1 21 21 local Yes Yes
Gi1/0/22 22 22 22 0/23 1 22 22 local Yes Yes
Gi1/0/23 23 23 23 0/26 1 23 23 local Yes Yes
Gi1/0/24 24 24 24 0/25 1 24 24 local Yes Yes
Gi1/0/25 25 25 25 1/2 1 25 25 local Yes Yes
Gi1/0/26 26 26 26 1/1 1 26 26 local Yes Yes
Gi1/0/27 27 27 27 1/4 1 27 27 local Yes Yes
Gi1/0/28 28 28 28 1/3 1 28 28 local Yes Yes
Gi1/0/29 29 29 29 1/6 1 29 29 local Yes Yes
Gi1/0/30 30 30 30 1/5 1 30 30 local Yes Yes
Gi1/0/31 31 31 31 1/8 1 31 31 local Yes Yes
Gi1/0/32 32 32 32 1/7 1 32 32 local Yes Yes
Gi1/0/33 33 33 33 1/10 1 33 33 local Yes Yes
Gi1/0/34 34 34 34 1/9 1 34 34 local Yes Yes
Gi1/0/35 35 35 35 1/12 1 35 35 local Yes Yes
Gi1/0/36 36 36 36 1/11 1 36 36 local Yes Yes
Gi1/0/37 37 37 37 1/16 1 37 37 local Yes Yes
Gi1/0/38 38 38 38 1/15 1 38 38 local Yes Yes
Gi1/0/39 39 39 39 1/18 1 39 39 local Yes Yes
Gi1/0/40 40 40 40 1/17 1 40 40 local Yes Yes
Gi1/0/41 41 41 41 1/20 1 41 41 local Yes Yes
Gi1/0/42 42 42 42 1/19 1 42 42 local Yes Yes
Gi1/0/43 43 43 43 1/22 1 43 43 local Yes Yes
Gi1/0/44 44 44 44 1/21 1 44 44 local Yes Yes
Gi1/0/45 45 45 45 1/24 1 45 45 local Yes Yes
Gi1/0/46 46 46 46 1/23 1 46 46 local Yes Yes
Gi1/0/47 47 47 47 1/26 1 47 47 local Yes Yes
Gi1/0/48 48 48 48 1/25 1 48 48 local Yes Yes
Gi1/0/49 49 49 49 0/13 1 49 49 local Yes Yes
Gi1/0/50 50 50 50 1/13 1 50 50 local Yes Yes
Gi1/0/51 51 51 51 1/27 1 51 51 local Yes Yes
Gi1/0/52 52 52 52 0/27 1 52 52 local Yes Yes
Gi2/0/1 57 57 1 0/2 2 1 1 remote No Yes
Gi2/0/2 58 58 2 0/1 2 2 2 remote No Yes
Gi2/0/3 59 59 3 0/4 2 3 3 remote No Yes
Gi2/0/4 60 60 4 0/3 2 4 4 remote No Yes
Gi2/0/5 61 61 5 0/6 2 5 5 remote No Yes
Gi2/0/6 62 62 6 0/5 2 6 6 remote No Yes
Gi2/0/7 63 63 7 0/8 2 7 7 remote No Yes
Gi2/0/8 64 64 8 0/7 2 8 8 remote No Yes
Gi2/0/9 65 65 9 0/10 2 9 9 remote No Yes
Gi2/0/10 66 66 10 0/9 2 10 10 remote No Yes
Gi2/0/11 67 67 11 0/12 2 11 11 remote No Yes
Gi2/0/12 68 68 12 0/11 2 12 12 remote No Yes
Gi2/0/13 69 69 13 0/16 2 13 13 remote No Yes
Gi2/0/14 70 70 14 0/15 2 14 14 remote No Yes
Gi2/0/15 71 71 15 0/18 2 15 15 remote No Yes
Gi2/0/16 72 72 16 0/17 2 16 16 remote No Yes
Gi2/0/17 73 73 17 0/20 2 17 17 remote No Yes
Gi2/0/18 74 74 18 0/19 2 18 18 remote No Yes
Gi2/0/19 75 75 19 0/22 2 19 19 remote No Yes
Gi2/0/20 76 76 20 0/21 2 20 20 remote No Yes
Gi2/0/21 77 77 21 0/24 2 21 21 remote No Yes
Gi2/0/22 78 78 22 0/23 2 22 22 remote No Yes
Gi2/0/23 79 79 23 0/26 2 23 23 remote No Yes
Gi2/0/24 80 80 24 0/25 2 24 24 remote No Yes
Gi2/0/25 81 81 25 1/2 2 25 25 remote No Yes
Gi2/0/26 82 82 26 1/1 2 26 26 remote No Yes
Gi2/0/27 83 83 27 1/4 2 27 27 remote No Yes
Gi2/0/28 84 84 28 1/3 2 28 28 remote No Yes
Gi2/0/29 85 85 29 1/6 2 29 29 remote No Yes
Gi2/0/30 86 86 30 1/5 2 30 30 remote No Yes
Gi2/0/31 87 87 31 1/8 2 31 31 remote No Yes
Gi2/0/32 88 88 32 1/7 2 32 32 remote No Yes
Gi2/0/33 89 89 33 1/10 2 33 33 remote No Yes
Gi2/0/34 90 90 34 1/9 2 34 34 remote No Yes
Gi2/0/35 91 91 35 1/12 2 35 35 remote No Yes
Gi2/0/36 92 92 36 1/11 2 36 36 remote No Yes
Gi2/0/37 93 93 37 1/16 2 37 37 remote No Yes
Gi2/0/38 94 94 38 1/15 2 38 38 remote No Yes
Gi2/0/39 95 95 39 1/18 2 39 39 remote No Yes
Gi2/0/40 96 96 40 1/17 2 40 40 remote No Yes
Gi2/0/41 97 97 41 1/20 2 41 41 remote No Yes
Gi2/0/42 98 98 42 1/19 2 42 42 remote No Yes
Gi2/0/43 99 99 43 1/22 2 43 43 remote No Yes
Gi2/0/44 100 100 44 1/21 2 44 44 remote No Yes
Gi2/0/45 101 101 45 1/24 2 45 45 remote No Yes
Gi2/0/46 102 102 46 1/23 2 46 46 remote No Yes
Gi2/0/47 103 103 47 1/26 2 47 47 remote No Yes
Gi2/0/48 104 104 48 1/25 2 48 48 remote No Yes
Gi2/0/49 105 105 49 0/13 2 49 49 remote No Yes
Gi2/0/50 106 106 50 1/13 2 50 50 remote No Yes
Gi2/0/51 107 107 51 1/27 2 51 51 remote No Yes
Gi2/0/52 108 108 52 0/27 2 52 52 remote No Yes
Po1 232 232 0 0/0 5 1 1 local No No
Po2 240 240 0 0/0 5 2 2 local No No
Po3 248 248 0 1/0 5 3 3 local No No
St1 280 280 0 16/0 1 0 0 internal Yes Yes
St2 281 281 0 16/0 2 0 0 internal No Yes
Formateringen er noget skidt her, men det viser at:
Gi1/0/1 1 1 1 0/2 x x x x x x
Interface gigabit 1/0/1 bruger asic 0 port 2. Nu ved vi, at en c2960s har 2 asic chips. asic 0 er allokeret til interface 1 til 24 og interface 49 og 52. Asic 1 er allokeret til de resterende porte.
Jeg tror dog ikke, at det er asic chippene, der er den egentlige begrænsning her.
Hvad skal man så købe for at iscsi virker fornuftigt. En cisco 3850 blev foreslået, men prisen på sådan én, er temmeligt høj. Hvad jeg dog kan læse er, at 3850/3860 serien har fået meget større buffer, hvilket gør den god til blandt andet iscsci trafik.
Jeg endte med en brugt C3750X – buffer størrelsen på denne model er heller ikke ret stor, men den gør det så meget bedre end sin “lillebror”.
Jeg fik Nimble til at lave et udtræk fra deres Infosight database, der viser latency før og efter skiftet til 3750´eren på netværksiden:
Nimble cs235 Operation latency
Det viser tydeligt, at forskellen er stor omkring kl. 16. Svartiden på RDP sessioner var også ganske mærkbar.
TCP retransmits er også forbedret.
Nimble cs235TCP retransmits
Nimble cs235 Operation size
Hvordan ser ASIC til interface allokeringen så ud på en C3750X:
sh platform pm if-number
interface gid gpn lpn port slot unit slun port-type lpn-idb gpn-idb
———————————————————————-
Gi1/0/1 1 1 1 1/1 1 1 1 local Yes Yes
Gi1/0/2 2 2 2 1/0 1 2 2 local Yes Yes
Gi1/0/3 3 3 3 1/3 1 3 3 local Yes Yes
Gi1/0/4 4 4 4 1/2 1 4 4 local Yes Yes
Gi1/0/5 5 5 5 1/5 1 5 5 local Yes Yes
Gi1/0/6 6 6 6 1/4 1 6 6 local Yes Yes
Gi1/0/7 7 7 7 1/9 1 7 7 local Yes Yes
Gi1/0/8 8 8 8 1/8 1 8 8 local Yes Yes
Gi1/0/9 9 9 9 1/11 1 9 9 local Yes Yes
Gi1/0/10 10 10 10 1/10 1 10 10 local Yes Yes
Gi1/0/11 11 11 11 1/13 1 11 11 local Yes Yes
Gi1/0/12 12 12 12 1/12 1 12 12 local Yes Yes
Gi1/0/13 13 13 13 1/15 1 13 13 local Yes Yes
Gi1/0/14 14 14 14 1/14 1 14 14 local Yes Yes
Gi1/0/15 15 15 15 1/17 1 15 15 local Yes Yes
Gi1/0/16 16 16 16 1/16 1 16 16 local Yes Yes
Gi1/0/17 17 17 17 1/19 1 17 17 local Yes Yes
Gi1/0/18 18 18 18 1/18 1 18 18 local Yes Yes
Gi1/0/19 19 19 19 1/23 1 19 19 local Yes Yes
Gi1/0/20 20 20 20 1/22 1 20 20 local Yes Yes
Gi1/0/21 21 21 21 1/25 1 21 21 local Yes Yes
Gi1/0/22 22 22 22 1/24 1 22 22 local Yes Yes
Gi1/0/23 23 23 23 1/27 1 23 23 local Yes Yes
Gi1/0/24 24 24 24 1/26 1 24 24 local Yes Yes
Gi1/1/1 25 25 25 0/6 1 25 25 local Yes Yes
Gi1/1/2 26 26 26 0/7 1 26 26 local Yes Yes
Gi1/1/3 27 27 27 0/20 1 27 27 local Yes Yes
Gi1/1/4 28 28 28 0/21 1 28 28 local Yes Yes
Te1/1/1 29 29 29 0/0 1 1 29 local Yes Yes
Te1/1/2 30 30 30 0/14 1 2 30 local Yes Yes
St1 896 896 0 16/0 1 0 0 internal Yes Yes
Der er én ASIC chip til de 24 1Gbit/s porte, og én ASIC chip tildelt til de ekstra porte 25,26,27 og 28 – 4x1Gbit/s eller 2x10Gbit/s.
ASIC fordelingen er altså ens, men måske hurtigere på den større serie?
Hvordan med pakke drops på 3750. Jeg ser stadig drops, men antallet er astronomisk meget mindre. Her et eksempel fra interface 1/0/4:
sw50-3#sh int gig1/0/4
GigabitEthernet1/0/4 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 588d.098e.cf84 (bia 588d.098e.cf84)
Description: Nimble cs235 Ctrl.A interface 2
MTU 9198 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 2/255, rxload 2/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
input flow-control is on, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of “show interface” counters 3w2d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 21553
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 8964000 bits/sec, 245 packets/sec
5 minute output rate 11716000 bits/sec, 273 packets/sec
707148558 packets input, 2739859918270 bytes, 0 no buffer
Received 98238 broadcasts (48 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 48 multicast, 0 pause input
0 input packets with dribble condition detected
853760652 packets output, 4887164517731 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
uptime is 16 weeks, 3 days, 20 hours, 17 minutes
Efter noget tid med 3750´eren begyndte jeg at få alarmer fra ONE med disk fejl på mine virtuelle maskiner alla – 8 disk errors the last 15 minuttes is above threashold by 4″. So what to do now?
Vi googler igen, og denne gang faldt jeg over et dokument fra Dell Equallogic, der viser en verificeret konfiguration på C3750X til iscsi trafik med op til 4 Equallogic boske og 8 fysiske servere. Way over my setup, så det må kunne bruges. Det interessante i dette dokument er, at QoS rent faktisk aktiveres og tilpasses – hvilket er lige modsat det, jeg altid troede, var bedst, hvis man bare skulle have blæst noget trafik igennem – standard er jo FIFO – first ind, first out princippet.
“Every packet that is to be transmitted out an interface is placed in one or more egress buffers. The egress buffers allow an interface to store packets when there are more packets to be transmitted than can physically be sent (ie: the interface is experiencing congestion). If the switch drops a packet, the lone reason is that it could not allocate enough buffers to hold the packet. Availability of egress buffers determine if a packet is transmitted or not. When it comes to reducing packet drops, understanding how the switch uses egress buffers is key. The switch does concern itself with packets. Rather it’s the number of buffers that a give packet will require should it be enqueued.”
Kilde: Cisco
Hvordan ser den QoS konfig så ud:
mls qos queue-set output 1 threshold 1 100 100 100 400
mls qos queue-set output 1 threshold 2 3200 100 10 3200
mls qos queue-set output 1 threshold 3 100 100 100 400
mls qos queue-set output 1 threshold 4 100 100 100 400
mls qos queue-set output 1 buffers 4 88 4 4
mls qos
Nu skal jeg ikke gøre mig særlig klog på QoS, da det er en helt videnskab i sig selv, men ovenstående gør, at vi allokere op til 3200% buffere i output 1 threshold 2, hvor der må bruges op til 100%, heraf 10% i reserved buffer area og maximalt 3200% buffere, hvoraf 88% af det totale antal system wide buffere reserveres hertil (tror jeg da).
show mls qos queue-set 1
Queueset: 1
Queue : 1 2 3 4
———————————————-
buffers : 4 88 4 4
threshold1: 100 3200 100 100
threshold2: 100 100 100 100
reserved : 100 10 100 100
maximum : 400 3200 400 400
“IOS ensures at least 16 buffers are reserved for each tx queue no matter how it’s configured. 16* 256 bytes = 4096 Bytes are reserved. This is enough for 2 baby giant frames (1516 bytes). Remember that each buffer is 256 bytes. Even if the configured values for fields “buffers” are “reserved” below 16, IOS will still reserve 16 packets. Basically, IOS won’t let you remove all reserved buffers from a tx queue.”
Default i IOS er, at transmit queue 1 er shaped, og de resterende TX queues 2,3 og 4 er shared og al trafik standard markeres med COS 0 (best effort), som allokeres til output queue 1. Altså en lille reservation af “reserved buffer area” og al resterende buffer allokeres til “common pool area”. Det betyder, at pakker droppes langt tidligere i transmit køen pr. interface på trods af, at der stadig kan være ledige buffere i de andre køer (threshold 2,3,4) – det er jo shaped, så 25% pr. kø i threashold 1.
Så snart QoS aktiveres (mls qos) og alle porte er “untrusted” mht. COS, så bliver alle indgående pakker markeret med COS værdi 1 – som så rammer vores output queue 1 threshold 2 – som har fået allokeret langt flere buffere nu.
At aktivere QoS, som Dell skriver, har hjulpet rigtigt meget igen, men jeg ser stadig periodisk disk alarmer (på trods af at hverken Microsoft logs, Nimbles logs eller andet indikere at der skulle være fejl), men jeg kan konstatere, at det har relation til, hvor mange pakker min Zabbix monitorering software sender ud i sekunded.
I skrivende stund modtager Zabbix 93 nye værdier i sekunded, og så er der ingen problemer, men hvis dette tal kommer op på 7-800 stykker, så begynder jeg at se latency issues. Det er jo ikke fordi, der er tale om store pakker, så mit gæt lige nu er, at det er antallet af pakker og nogle perioder med burst trafik, som påvirker bufferen på cisco switchen i negativ retning. Jeg kommer sikkert aldrig nærmere en fornuftig løsning førend switch udstyret skiftes.
No responses yet