Sokan hallották már, hogy a Cloud4Y vállalati felhőszolgáltató. Ezért nem magunkról fogunk beszélni, hanem megosztunk egy rövid történetet arról, hogy egyes oldalak elérése során milyen problémák merültek fel, és mi okozta ezt.
Egy szép napon a marketing osztály panaszkodott a mérnököknek, hogy amikor a terminálon keresztül dolgoztak a böngészőkben, egyes oldalak betöltése sokáig tartott. Különösen a vk.com létfontosságú számukra. Megkaptuk a jelet, és elkezdtük kitalálni, mi a probléma.
Tehát a helyzet: Megafon internetszolgáltató, Windows szerver operációs rendszer, Firefox böngésző. Ha normál Windows 10 rendszerrel nyitja meg a VKontakte alkalmazást, a webhely 10-100 ms alatt töltődik be. Ha Windows Server 2012/16/19 operációs rendszerrel próbálunk megnyitni, a késés akár 15 másodperc is lehet, de akár több is.
Elvitte , és rajta keresztül elkezdték kidolgozni a történések lehetséges verzióit.
1. hipotézis tesztelése – probléma a terminálkiszolgálóval.
Nem megerősített. Amikor az oldalt ugyanazon a hálózaton egy másik szerveren keresztül próbálta megnyitni, a probléma továbbra is fennáll.
A 2. hipotézis tesztelése – a probléma az átjáróban van.
Nem megerősített. Megjegyezték, hogy a helyi laptopokon minden könnyen és gyorsan megnyílik. Ugyanakkor a probléma továbbra is fennáll a termináloknál (és a belső szervereknél). Játszottunk az ICMP beállításaival a külső és belső interfészeken – nem segített.
Valahogy furcsa.
Helyi laptopról a webhely nem lassul le.
A belső lapolvasó gépről (beolvasási terminál) - nem lassul.
De a marketing lassú. Rendellenesség!
Menjünk tovább.
3. hipotézis tesztelése – DNS probléma.
Nem megerősített. A pixelt a nyilvános DNS-en (8.8.8.8) keresztül indítottuk el – ugyanez a történet. A probléma jól látható például, amikor először inkognitó módban húzza ki ezt a pixelt.
Fennáll a gyanú, hogy a probléma nagymértékben a böngészőtől függ. FF-ben mindig lefagy a pixel, krómban az első bejelentkezéskor. A marketing minden böngészőben állandóan elakad.
4. hipotézis tesztelése – Valami az operációs rendszer sablonjával.
Nem megerősített. Tiszta Windows Server 2016-ot telepítettünk, és a tesztet a .0 hálózatról futtattuk. Problémánk van. Áttértünk a .200-as hálózatra, a probléma továbbra is fennáll. Vagyis a hálózati kapu .0. nincs köze hozzá. Az ebből a hálózatból származó laptopoknál azonban nincs ilyen probléma. Vagyis a hálózati kapu .200. semmi köze hozzá.
Vagyis ez nem az operációs rendszer sablonja. A virtuális gép lelassul a pixel betöltése közben. De ha VPN-t (külön hálózati kártyát) telepítünk rá és forgalmat küldünk rajta, akkor minden nagyon gyorsan működik (ahogyan lennie kell). Úgy látjuk, hogy két lehetőség okozhat problémát: egy átjáró az irodában vagy egy internetszolgáltató az irodában.
De a Megafon kifejezetten megszakíthatja a hozzáférést a VKontakte pixelhez? Nem, ez valami hülyeség. Próbáljunk még egy kicsit ásni.
5. hipotézis tesztelése – Mindenért a VMware Tools a felelős.
Nem megerősített. Káros hatás nem figyelhető meg. Megpróbáltuk megváltoztatni a kártya beállításait, de az sem ment. A TTL megváltozott – nincs hatása. Nos, általában nem világos, hogy mi a különbség a Windows 10 és a Windows Server között. De van különbség. Mint a sztori a gopherrel.
Már egy ideje foglalkozunk a problémával. Természetesen kerestünk a google-ban hasonló helyzeteket, de nem találtunk semmit. Így felszólítás nélkül cselekedtünk, minden lehetséges verziót kidolgoztunk. Tesztelést végeztünk egy Windows 2016 laptopon, hogy megbizonyosodjunk arról, hogy a virtualizáció és így tovább nem okolható a pixel betöltésekor tapasztalható lassulásért. Megváltoztattuk a hálózati kártya és az IP-verem összes lehetséges beállítását. Egy csomó dolgot kipróbáltunk. A probléma azonban megmaradt, és a marketing beindult, és követelte, hogy mindent javítsanak ki.
Egy idő után végre megtaláltuk, hol van elásva a kutya. Minden a lehetőségekről szólt
netsh interfész tcp setglobal ecncapability=disabled
Ez az opció alapértelmezés szerint le van tiltva az asztali Windows operációs rendszereken, és alapértelmezés szerint engedélyezve van a szerver operációs rendszereken. Amint letiltjuk a szerverszobában, minden azonnal megnyílik, akárcsak az asztalon. Ezt a problémát meg tudtuk erősíteni az irodai internetet biztosító szolgáltatótól (Megafon), a Megafon mobilinternetén keresztül (ha telefonról osztja meg és Windows Serveren keresztül csatlakozik), a Yotán keresztül, bizonyos területeken kipróbáltuk. és ez a probléma mindenhol jelen volt. Amikor más üzemeltetőkön dolgozott, azonnali hozzáférés volt az oldalhoz.
Ez egy olyan kancsalság, ahogy egy prominens politikai személyiség fogalmazott. Elvileg mára megoldódott a probléma, de nagyon érdekel minket: csak nálunk fordult elő, vagy egy nagyszabású katasztrófa, amely más városok cégeit is sújtja? Ha ez az eset nem elszigetelt, akkor a Megafonnak el kell gondolkodnia a probléma megoldásán. Végül is az ECN (ecncapability) opció alapértelmezés szerint engedélyezve van a szervereken, és sok időbe telik, mire rájön, miről is van szó.
Hogyan kell ellenőrizni? Igen, akárcsak mi. A Firefox böngészővel megpróbáljuk megnyitni a vk.com bármely oldalát, majd ismét a ctrl+f5 használatával. Ha probléma van, akkor állandó késés lesz, ha nincs probléma, azonnal megnyílik az oldal.
Mit olvashatsz még a blogon?
→
→
→
→
→
Iratkozzon fel a -csatorna, hogy ne maradj le a következő cikkről! Hetente legfeljebb kétszer írunk, és csak üzleti ügyben.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Késéseket tapasztal a Windows Server betöltésénél?
-
4,8%Igen, sokáig tart a betöltése2
-
50,0%Nem, minden repül21
-
45,2%A probléma nem a beállításokban van, hanem a marketingesekben19
42 felhasználó szavazott. 35 felhasználó tartózkodott.
Forrás: will.com