rssLink RSS dla wszystkich kategorii
 
icon_orange
icon_red
icon_red
icon_blue
icon_blue
icon_blue
icon_green
icon_red
icon_blue
icon_blue
icon_blue
icon_blue
icon_blue
icon_blue
icon_blue
icon_blue
icon_red
icon_blue
icon_orange
icon_red
icon_blue
icon_blue
icon_blue
icon_blue
icon_green
icon_blue
icon_blue
 

FS#27230 — P19 - Hosting

Przydzielony do projektu— Serwery wirtualne
Nagła usterka
P19
ZAMKNIĘTE
100%
5.12.2016 16:33

Występują duże spowolnienia w dostępie do filerów i do baz danych, co powoduje niedostępność usług. Szukamy przyczyny tego problemu.
Data:  wtorek, 06 grudzień 2016, 12:12
Powód zamknięcia:  Done
Komentarz od OVH - wtorek, 06 grudzień 2016, 08:45

05.12.2016, 17:09PM

Wystąpiły przeciążenia na jednej z par N6K (P19-90/91), co spowodowało spowolnienia między serwerami www i filerami. Serwery NFS odłączyły się od serwerów www, następnie powróciły.

Sprawdzamy, dlaczego 600 łączy na tej parze przeszło z 2-3Gbps na 10Gbps i wygenerowało ponad 300Gbps ruchu wewnętrznego.


05.12.2016, 18:08PM

Od godziny 14:00 mamy 4 razy więcej ruchu w sieci, co przeciąża niektóre łącza między szafami. Nie znamy jeszcze przyczyny problemu. Dodamy łącza, w celu uniknięcia przeciążenia.


05.12.2016, 18:31PM

Zwiększyliśmy przepustowość do pary N6. To rozwiązało część problemu. Nadal mamy dużo ruchu.

Możliwe, że jest to związane z wyłączeniem lokalnej pamięci cache serwerów www, co jest związane z nieprawidłowym rozdzielaniem obciążenia. System powinien przekierowywać zapytania strony www na serwer www i korzystać z lokalnej pamięci cache. Jeśli rozdzielanie obciążenia nie jest wykonywane prawidłowo, a system przekierowuje zapytania na wszystkie serwery www, może to wyjaśniać, dlaczego mamy dużo ruchu do filerów.


05.12.2016, 18:32PM

Wymusiliśmy restart wszystkich stron www. Wymusiliśmy rozdzielanie ruchu na jeden serwer www.


05.12.2016, 18:45PM

Strony działają prawidłowo. Kontynuujemy szukanie przyczyny problemu.


05.12.2016, 22:01PM

Kontynuujemy poszukiwania przyczyny problemu. Myślimy, że ją odnaleźliśmy. Sprawdzimy, czy patch rozwiąże problem i przedstawimy wyjaśnienie.


05.12.2016, 22:09PM

Patch rozwiązał problem. Przyczyna problemu została odnaleziona. Kończymy wdrażanie patcha, aby zmniejszyć wykorzystanie sieci i powrócić do standardowych poziomów.

p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 350.95 Mbps, 44.27 Kpps; output rate 82.87 Mbps, 28.78 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 348.19 Mbps, 43.96 Kpps; output rate 81.15 Mbps, 28.56 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 348.19 Mbps, 43.96 Kpps; output rate 81.15 Mbps, 28.56 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 265.41 Mbps, 35.56 Kpps; output rate 57.98 Mbps, 24.28 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 265.41 Mbps, 35.56 Kpps; output rate 57.98 Mbps, 24.28 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 254.96 Mbps, 34.32 Kpps; output rate 51.54 Mbps, 23.34 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 254.96 Mbps, 34.32 Kpps; output rate 51.54 Mbps, 23.34 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 228.52 Mbps, 31.10 Kpps; output rate 39.44 Mbps, 21.24 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 226.64 Mbps, 30.85 Kpps; output rate 37.90 Mbps, 21.05 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 208.08 Mbps, 29.10 Kpps; output rate 36.65 Mbps, 20.58 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 206.52 Mbps, 28.96 Kpps; output rate 36.72 Mbps, 20.55 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 197.82 Mbps, 27.83 Kpps; output rate 36.49 Mbps, 19.90 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 187.65 Mbps, 26.49 Kpps; output rate 35.02 Mbps, 19.16 Kpps
p19-90-n6# sh inter Eth104/1/38 | i " input rate"
input rate 155.02 Mbps, 22.82 Kpps; output rate 32.48 Mbps, 17.50 Kpps
p19-90-n6#


W trakcie wdrażania patcha na 10000 serwerów www widać, że ruch do filera stopniowo się zmniejsza. Mamy ponad 2000 filerów.


05.12.2016, 23:01PM

input rate 67.19 Mbps, 11.67 Kpps; output rate 20.54 Mbps, 9.29 Kpps

Mamy normalny poziom ruchu na przestrzeniach dyskowych.


Komentarz od OVH - wtorek, 06 grudzień 2016, 12:11

05.12.2016, 23:32PM

Dobry wieczór,

Przyczyna problemu:

Do przesyłania zapytań www stron internetowych na dany serwer www używamy systemu opartego na Cookies. W zależności od strony www określamy, jaki serwer www odpowie na zapytania www. Upewniamy się, że wszystkie zapytania tej samej strony docierają zawsze na ten sam serwer www. Pozwala to na zagwarantowanie zasobów wykorzystanych przez stronę www, na wykorzystanie pamięci cache przestrzeni dyskowej i na przyspieszenie działania stron. W przypadku awarii serwera www, system przelicza Cookie tak, aby zapytania www tej samej strony dotarły na na inny działający serwer www w klastrze. W ten sposób zapewniamy wysoką dostępność.

Każdy serwer www ma swój numer cookie, który opiera się na algorytmie Cisco wykorzystywanym przez ACE. Znamy formułę, która przekierowuje pierwsze zapytanie na dobry serwera www. Następnie zapytania www mają dobry numer Cookie i to ACE zapewnia load balancing i przekierowanie zapytania na dobry serwer www.

Dziś około godziny 14:00 formuła obliczająca Cookie zmieniła zachowanie na skutek modyfikacji funkcji, która podaje listę serwerów www dostępnych na klastrze. Był to skutek uboczny jednego z patchy. Obliczone Cookies nie odpowiadały żadnemu Cookie rozpoznawanemu przez ACE i w tym przypadku ACE rozdzielało ruch na wszystkie serwery www jednocześnie. Takie zachowanie klastra pojawiło się 5 lat temu: wszystkie serwery www pracowały dla wszystkich stron www. W tym przypadku każdy serwer www szukał informacji na wszystkich filerach dla wszystkich stron. I to spowodowało zwiększenie ruchu wewnętrznego 6-krotnie, ponieważ serwery www nie zapisywały informacji w lokalnej pamięci cache. Wzrost ruchu spowodował przeciążenie niektórych łączy i spowolnienia w sieci. To z kolei spowodowało całkowitą przerwę lub częściowe przerwy w dostępnie do stron www :( Jeśli sieć nie byłaby przeciążona, nie byłoby wpływu na działanie load balancingu na wszystkich serwerach www.

Przyczyna problemu była trudna do zidentyfikowania. Widzieliśmy, że serwery www nie przechowywały informacji w pamięci cache, ale nie wiedzieliśmy dlaczego. Podjęliśmy decyzję o szybkim zwiększeniu łącza w sieci dodając kilka łączy 10G między switchami. Pozwoliło to na ustabilizowanie sytuacji i dało nam czas na odnalezienie przyczyny problemu.

Odnaleźliśmy przyczynę problemu i odinstalowaliśmy patch. Następnie wprowadziliśmy prawidłowy kod na wszystkich serwerach www. Ruch zmniejszył się do standardowego poziomu.

Jak uniknąć ponownego pojawienia się problemu?

1) W ciągu kilku tygodni wprowadzimy load balancing dla hostingu oparty na ACE. Będziemy umieli wygenerować system Cookie w inny sposób i będziemy mniej zależni od precyzyjnych obliczeń Cookie. Przygotowaliśmy nasz własny system LB, który stopniowo wdrażamy zastępując ACE Cisco.

2) Zaplanowaliśmy zmianę konfiguracji sieci w P19 przechodząc z 10G na 40G/100G, oraz przechodząc na tę samą technologię, z której korzysta vRack, ze znacznie większą wydajnością między sprzętem sieciowym. Dzięki ECMP na L3 będziemy mogli lepiej rozdzialać wydajność w sieci.

3) Pomimo wielu narzędzi do monitoringu, należy wszystko zweryfikować i przygotować narzędzia pokazujące prawdziwy stan działania infrastruktury. Nie potrafiliśmy szybko stwierdzić, dlaczego load balancing nie działał.

Bardzo nam przykro z powodu awarii. W żadnym wypadku nie powinna ona trwać tak długo i nie powinna mieć tak dużego zakresu. W najbliższych dniach otrzymają Państwo e-mail z infomacją dotyczącą rekompensaty.

Pozdrawiam
Octave