A modern web szinte elképzelhetetlen médiatartalom nélkül: szinte minden nagymamának van okostelefonja, mindenki a közösségi oldalakon van, a karbantartási leállások pedig költségesek a cégeknek. Íme a cég történetének átirata arról, hogyan szervezte meg hardveres megoldással a fotók kézbesítését, milyen teljesítményproblémákkal találkozott a folyamat során, mi okozta ezeket, és hogyan oldották meg ezeket a problémákat egy Nginx alapú szoftveres megoldással, miközben minden szinten biztosította a hibatűrést (). Köszönetet mondunk Oleg történetének szerzőinek Efimova és Alexandra Dymova, akik megosztották tapasztalataikat a konferencián .
— Kezdjük egy kis bevezetővel arról, hogyan tároljuk és gyorsítótárazzuk a fényképeket. Van egy rétegünk, ahol tároljuk őket, és egy réteg, ahol gyorsítótárazzuk a fényképeket. Ugyanakkor, ha nagy trükkarányt szeretnénk elérni, és csökkenteni szeretnénk a tárhely terhelését, fontos számunkra, hogy egy-egy felhasználó minden egyes fotója egy gyorsítótárazó szerveren legyen. Ellenkező esetben annyi lemezt kellene telepítenünk, ahány szerverünk van. A trükkarányunk 99% körül mozog, vagyis 100-szorosára csökkentjük a tárhelyünk terhelését, és ennek érdekében 10 évvel ezelőtt, amikor mindez épült, 50 szerverünk volt. Ennek megfelelően a képek kiszolgálásához lényegében 50 külső domainre volt szükségünk, amelyeket ezek a szerverek kiszolgálnak.
Természetesen azonnal felmerült a kérdés: ha valamelyik szerverünk leáll és elérhetetlenné válik, a forgalom mekkora részét veszítjük el? Megnéztük, mi van a piacon, és úgy döntöttünk, veszünk egy hardvert, hogy az minden problémánkat megoldja. A választás az F5-hálózatos cég (amely egyébként nemrég vásárolta meg az NGINX, Inc-t): BIG-IP Local Traffic Manager megoldására esett.
Amit ez a hardver (LTM) csinál: egy vas útválasztó, amely vasredundanciát tesz külső portjaira, és lehetővé teszi a forgalom irányítását a hálózati topológia, bizonyos beállítások alapján, és állapotellenőrzéseket végez. Fontos volt számunkra, hogy ez a hardver programozható legyen. Ennek megfelelően leírhatnánk azt a logikát, hogy egy adott felhasználó fényképeit miként szolgálják ki egy adott gyorsítótárból. Hogy néz ki? Van egy hardver, amely egy tartományon, egy IP-n nézi az internetet, végrehajtja az ssl-letöltést, elemzi a http kéréseket, kiválasztja a gyorsítótár számát az IRule-ból, hova kell mennie, és oda engedi a forgalmat. Ugyanakkor állapotellenőrzést is végez, és ha valamelyik gép nem elérhető, akkor úgy csináltuk, hogy egy tartalék szerverre menjen a forgalom. Konfigurációs szempontból természetesen vannak árnyalatok, de általában minden nagyon egyszerű: regisztrálunk egy kártyát, egy bizonyos szám megfelel az IP-címünknek a hálózaton, azt mondjuk, hogy a 80-as portokon fogunk figyelni. és 443-ban azt mondjuk, hogy ha a szerver nem elérhető, akkor a forgalmat a tartalék szerverre kell küldeni, jelen esetben a 35.-re, és leírunk egy csomó logikát, hogyan kell ezt az architektúrát szétszedni. Az egyetlen probléma az volt, hogy a hardver programozási nyelve a Tcl volt. Ha valaki egyáltalán emlékszik erre... ez a nyelv inkább csak írható, mint egy programozáshoz kényelmes nyelv:
Mit kaptunk? Kaptunk egy hardvert, amely biztosítja infrastruktúránk magas rendelkezésre állását, irányítja az összes forgalmunkat, egészségügyi előnyökkel jár és egyszerűen működik. Ráadásul elég sokáig működik: az elmúlt 10 évben nem volt rá panasz. 2018 elején már körülbelül 80 ezer fotót küldtünk másodpercenként. Ez valahol 80 gigabites forgalom mindkét adatközpontunkból.
Azonban…
2018 elején csúnya képet láttunk a slágerlistákon: egyértelműen megnőtt a fotók küldésének ideje. És már nem illett hozzánk. A probléma az, hogy ez a viselkedés csak a forgalmi csúcs idején volt látható - cégünknél ez a vasárnapról hétfőre tartó éjszaka. De az idő hátralévő részében a rendszer a szokásos módon viselkedett, semmi jele nem volt meghibásodásnak.
Ennek ellenére a problémát meg kellett oldani. Azonosítottuk a lehetséges szűk keresztmetszeteket, és megkezdtük azok megszüntetését. Mindenekelőtt természetesen kiterjesztettük a külső uplinkeket, elvégeztük a belső uplinkek teljes auditját, és megtaláltuk az összes lehetséges szűk keresztmetszetet. De mindez nem adott nyilvánvaló eredményt, a probléma nem szűnt meg.
Egy másik lehetséges szűk keresztmetszet maguknak a fotógyorsítótárak teljesítménye volt. És úgy döntöttünk, hogy a probléma talán rajtuk van. Nos, bővítettük a teljesítményt – főleg a hálózati portokat a fotógyorsítótáron. De ismét nem volt látható javulás. A végén nagyon odafigyeltünk magának az LTM-nek a teljesítményére, és itt egy szomorú képet láttunk a grafikonokon: az összes CPU terhelése zökkenőmentesen indul, de aztán hirtelen egy platóra jön. Ugyanakkor az LTM nem reagál megfelelően az állapotellenőrzésekre és a felfelé irányuló kapcsolatokra, és elkezdi véletlenszerűen kikapcsolni őket, ami komoly teljesítményromláshoz vezet.
Vagyis azonosítottuk a probléma forrását, azonosítottuk a szűk keresztmetszetet. Azt kell eldönteni, hogy mit tegyünk.
Az első, legnyilvánvalóbb dolog, amit tehetünk, hogy magát az LTM-et modernizáljuk. De van itt néhány árnyalat, mert ez a hardver meglehetősen egyedi, nem megy el a legközelebbi szupermarketbe és vásárolja meg. Ez egy külön szerződés, egy külön licencszerződés, és ez sok időt vesz igénybe. A második lehetőség, hogy elkezdesz önállóan gondolkodni, saját komponensekkel, lehetőleg nyílt hozzáférésű programmal, saját megoldást találsz ki. Már csak azt kell eldönteni, hogy pontosan mit választunk erre, és mennyi időt fordítunk a probléma megoldására, mivel a felhasználók nem kaptak elég fotót. Ezért mindezt nagyon-nagyon gyorsan meg kell tennünk, mondhatnánk tegnap.
Mivel a feladat úgy hangzott, hogy „csináljunk valamit, amilyen gyorsan csak lehet, és használjuk a rendelkezésünkre álló hardvert”, az első dolog, amit arra gondoltunk, egyszerűen távolítunk el néhány nem túl erős gépet az előlapról, és helyezzük oda az Nginx-et, amivel tudjuk, hogyan kell dolgozzon, és próbálja megvalósítani ugyanazt a logikát, mint a hardver. Vagyis tulajdonképpen otthagytuk a hardverünket, telepítettünk még 4 szervert, amit be kellett állítani, külső tartományokat hoztunk létre hozzájuk, hasonlóan, mint 10 éve... Kicsit veszítettünk az elérhetőségből, ha ezek a gépek leestek, de még kevésbé, helyben oldották meg felhasználóink problémáját.
Ennek megfelelően a logika változatlan: telepítjük az Nginx-et, képes SSL-offload-ot csinálni, valahogy programozhatjuk az útválasztási logikát, állapotellenőrzéseket a konfigurációkban, és egyszerűen lemásoljuk a korábban létező logikát.
Üljünk le konfigurációkat írni. Eleinte úgy tűnt, hogy minden nagyon egyszerű, de sajnos nagyon nehéz kézikönyveket találni az egyes feladatokhoz. Ezért nem javasoljuk, hogy egyszerűen guglizzon „hogyan állítsuk be az Nginxet a fényképekhez”: jobb, ha a hivatalos dokumentációra hivatkozik, amely megmutatja, hogy mely beállításokat kell megérinteni. De jobb, ha saját maga választja ki az adott paramétert. Nos, akkor minden egyszerű: leírjuk a szervereinket, amik vannak, leírjuk a tanúsítványokat... De a legérdekesebb valójában maga az útválasztási logika.
Eleinte úgy tűnt, hogy egyszerűen leírjuk a helyünket, összeegyeztetjük a benne lévő fénykép-gyorsítótárunk számát, a kezünkkel vagy egy generátorral leírjuk, hogy hány upstreamre van szükségünk, minden felfelé mutatóban megjelöljük azt a szervert, amelyre a forgalomnak kell irányulnia. go, és egy tartalék szerver – ha a fő szerver nem elérhető:
De valószínűleg, ha minden ilyen egyszerű lenne, egyszerűen hazamennénk, és nem mondanánk semmit. Sajnos az alapértelmezett Nginx beállításokkal, amelyek általában sok éves fejlesztés alatt készültek, és nem teljesen alkalmasak erre az esetre... a konfiguráció így néz ki: ha valamelyik upstream szerveren kérési hiba vagy időtúllépés van, az Nginx mindig átkapcsolja a forgalmat a következőre. Sőt, az első meghibásodás után 10 másodpercen belül a szerver is kikapcsolódik, tévedésből és időtúllépés miatt is - ezt nem is lehet konfigurálni semmilyen módon. Vagyis ha eltávolítjuk vagy alaphelyzetbe állítjuk az időkorlát opciót az upstream direktívában, akkor bár az Nginx nem dolgozza fel ezt a kérést, és valami nem túl jó hibával válaszol, a szerver leáll.
Ennek elkerülése érdekében két dolgot tettünk:
a) megtiltották az Nginx-nek, hogy ezt manuálisan csinálja – és sajnos ennek egyetlen módja a max fails beállítások megadása.
b) emlékeztünk arra, hogy más projektekben olyan modult használunk, amely lehetővé teszi a háttér-egészségügyi vizsgálatok elvégzését - ennek megfelelően elég sűrűn végeztünk állapotfelmérést, hogy baleset esetén minimális legyen az állásidő.
Sajnos ez még nem minden, mert szó szerint ennek a sémának az első két hete megmutatta, hogy a TCP állapotellenőrzés is megbízhatatlan dolog: a upstream szerveren nem biztos, hogy Nginx, vagy Nginx D-állapotban, és ebben az esetben a kernel elfogadja a kapcsolatot, az állapotellenőrzés sikeres, de nem működik. Ezért ezt azonnal lecseréltük állapotellenőrző http-re, csináltunk egy konkrétat, ami ha 200-at ad vissza, akkor ebben a szkriptben minden működik. További logikát is végezhet - például gyorsítótárazott szerverek esetén ellenőrizze, hogy a fájlrendszer megfelelően van-e csatlakoztatva:
És ez megfelelne nekünk, kivéve, hogy pillanatnyilag az áramkör teljesen megismételte azt, amit a hardver. De mi jobbat akartunk csinálni. Korábban egy tartalék szerverünk volt, és ez valószínűleg nem túl jó, mert ha száz szerverünk van, akkor ha egyszerre több meghibásodik, egy tartalék szerver nem valószínű, hogy megbirkózik a terheléssel. Ezért úgy döntöttünk, hogy elosztjuk a foglalást az összes szerver között: egyszerűen létrehoztunk egy másik külön upstreamet, odaírtuk az összes szervert bizonyos paraméterekkel az általuk kiszolgálható terhelésnek megfelelően, hozzáadtuk ugyanazokat az állapotellenőrzéseket, mint korábban:
Mivel egy upstreamen belül nem lehet másik upstreamre menni, meg kellett győződni arról, hogy ha a fő upstream, amelyben egyszerűen rögzítettük a megfelelő, szükséges fotógyorsítótárat, nem volt elérhető, akkor egyszerűen átmentünk a error_page-n a tartalékhoz, ahol a tartalék upstreamhez mentünk:
És szó szerint négy szerver hozzáadásával ezt kaptuk: kicseréltük a terhelés egy részét - eltávolítottuk az LTM-ről ezekre a szerverekre, ugyanazt a logikát implementáltuk ott is, szabványos hardverrel és szoftverrel, és azonnal megkaptuk azt a bónuszt, amit ezek a szerverek képesek. méretezhető, mert egyszerűen annyit szállíthatunk belőlük, amennyire szükség van. Nos, az egyetlen negatívum az, hogy elveszítettük a magas rendelkezésre állást a külső felhasználók számára. De abban a pillanatban ezt fel kellett áldoznunk, mert azonnal meg kellett oldani a problémát. Tehát eltávolítottuk a terhelés egy részét, ez akkoriban körülbelül 40% volt, az LTM jól érezte magát, és szó szerint két héttel a probléma kezdete után nem 45 ezer kérést kezdtünk el küldeni másodpercenként, hanem 55 ezer kérést. Valójában 20%-kal nőttünk – ez egyértelműen az a forgalom, amit nem adtunk át a felhasználónak. És ezt követően elkezdtek gondolkodni, hogyan lehet megoldani a fennmaradó problémát - a magas szintű külső hozzáférhetőség biztosítása érdekében.
Volt egy kis szünetünk, közben megbeszéltük, hogy milyen megoldást alkalmazunk erre. Voltak javaslatok a megbízhatóság biztosítására DNS használatával, néhány házilag írt szkript használatával, dinamikus útválasztási protokollokkal... sok lehetőség volt, de az már világossá vált, hogy a fotók valóban megbízható kézbesítéséhez be kell vezetni egy másik réteget, amely ezt figyeli. . Ezeket a gépeket fotórendezőknek hívtuk. A szoftver, amelyre támaszkodtunk, a Keepalived volt:
Először is, miből áll a Keepalived? Az első a hálózatépítők által széles körben ismert VRRP protokoll, amely a hálózati berendezéseken található, és hibatűrést biztosít a külső IP-címhez, amelyhez az ügyfelek csatlakoznak. A második rész az IPVS, az IP virtuális szerver a fotórouterek közötti egyensúlyozásra és a hibatűrés biztosítására ezen a szinten. És a harmadik - egészségügyi ellenőrzések.
Kezdjük az első résszel: VRRP – hogy néz ki? Van egy bizonyos virtuális IP-cím, amelynek van egy bejegyzése a dns badoocdn.com-ban, ahol az ügyfelek csatlakoznak. Egy adott időpontban van egy IP-címünk az egyik szerveren. A fenntartott csomagok VRRP protokollt használva futnak a szerverek között, és ha a master eltűnik a radarról - a szerver újraindult vagy valami más, akkor a tartalék szerver automatikusan felveszi ezt az IP-címet - nincs szükség kézi beavatkozásra. A fő és a biztonsági mentés közötti különbség főként prioritás: minél magasabb, annál nagyobb az esély arra, hogy a gép mesterré válik. Nagyon nagy előnye, hogy nem magán a szerveren kell IP-címeket konfigurálni, elég leírni a konfigurációban, és ha az IP-címekhez valamilyen egyedi útválasztási szabály kell, akkor ez közvetlenül a konfigurációban van leírva, a ugyanaz a szintaxis, mint a VRRP csomagban leírtak. Nem fogsz találkozni ismeretlen dolgokkal.
Hogy néz ez ki a gyakorlatban? Mi történik, ha az egyik szerver meghibásodik? Amint a mester eltűnik, a biztonsági másolatunk leállítja a hirdetések fogadását, és automatikusan mesterré válik. Egy idő után megjavítottuk a mestert, újraindítottuk, felemeltük a Keepalivedet - a hirdetések magasabb prioritással érkeznek, mint a mentés, és a mentés automatikusan visszafordul, eltávolítja az IP-címeket, nem kell manuálisan tenni.
Így biztosítottuk a külső IP-cím hibatűrését. A következő rész az, hogy valahogy egyensúlyba hozza a forgalmat a külső IP-címről az azt már lezáró fotórouterek felé. A kiegyenlítési protokollokkal minden teljesen világos. Ez vagy egy egyszerű körmérkőzés, vagy kicsit bonyolultabb dolgok, wrr, listakapcsolat és így tovább. Ez alapvetően le van írva a dokumentációban, nincs semmi különös. De a szállítási mód... Itt közelebbről megvizsgáljuk, miért választottuk valamelyiket. Ezek a NAT, a közvetlen útválasztás és a TUN. Az tény, hogy rögtön 100 gigabites forgalmat terveztünk a telephelyekről. Ha úgy becsüli, 10 gigabites kártyára van szüksége, igaz? 10 gigabites kártya egy szerveren már túlmutat legalábbis a mi „standard felszerelés” koncepciónkon. És akkor eszébe jutott, hogy nem csak forgalmat adunk, hanem fotókat is.
Mi a különleges? — Óriási különbség a bejövő és a kimenő forgalom között. A bejövő forgalom nagyon kicsi, a kimenő forgalom nagyon nagy:
Ha megnézi ezeket a grafikonokat, láthatja, hogy jelenleg a rendező körülbelül 200 MB-ot kap másodpercenként, ez egy nagyon hétköznapi nap. 4,500 MB-ot adunk vissza másodpercenként, az arányunk hozzávetőlegesen 1/22. Az már világos, hogy a kimenő forgalom teljes körű biztosításához 22 dolgozó szerver számára csak egy olyanra van szükségünk, amely elfogadja ezt a kapcsolatot. Itt jön a segítségünkre a közvetlen útválasztási algoritmus.
Hogy néz ki? A fotórendezőnk a táblázata szerint továbbítja a kapcsolatokat a fotórouterekhez. De a fotórouterek a visszatérő forgalmat közvetlenül az Internetre küldik, elküldik a kliensnek, az nem megy vissza a fotórendezőn keresztül, így minimális számú géppel biztosítjuk a teljes hibatűrést és a teljes forgalom pumpálását. A konfigurációkban ez így néz ki: megadjuk az algoritmust, esetünkben ez egy egyszerű rr, megadjuk a közvetlen útválasztási metódust, majd elkezdjük listázni az összes valódi szervert, hány van belőlük. Ami meghatározza ezt a forgalmat. Ha van ott még egy-két szerverünk, vagy több szerverünk, akkor felmerül az igény – csak adjuk hozzá ezt a részt a konfigurációhoz, és ne aggódjunk túl sokat. A valódi szerverek oldaláról, a fotórouter oldaláról ez a módszer a legminimálisabb konfigurációt igényli, a dokumentációban tökéletesen le van írva, és ott nincsenek buktatók.
Ami különösen jó, hogy egy ilyen megoldás nem jelenti a helyi hálózat radikális átalakítását, ez fontos volt számunkra, ezt minimális költségekkel kellett megoldanunk. Ha megnézed , majd meglátjuk, hogy néz ki. Itt van egy virtuális szerverünk a 443-as porton, figyel, elfogadja a kapcsolatot, az összes működő szerver fel van sorolva, és láthatod, hogy a kapcsolat, adj vagy veszel, ugyanaz. Ha ugyanazon a virtuális szerveren nézzük a statisztikát, akkor vannak bejövő csomagjaink, bejövő kapcsolataink, de kimenőink egyáltalán nincsenek. A kimenő kapcsolatok közvetlenül az ügyfélhez mennek. Oké, sikerült kiegyensúlyoznunk. Most mi történik, ha az egyik fotóútválasztónk meghibásodik? Hiszen a vas az vas. Kernelpánikba kerülhet, eltörhet, kiéghet a táp. Bármi. Ezért van szükség egészségügyi ellenőrzésekre. Ezek lehetnek olyan egyszerűek, mint a port megnyitásának ellenőrzése, vagy valami bonyolultabb dolog, akár néhány otthon írt szkript is, amely még az üzleti logikát is ellenőrzi.
Valahol a közepén megálltunk: van egy https kérésünk egy adott helyre, a script meghívódik, ha 200-as választ ad, akkor úgy gondoljuk, hogy minden rendben van ezzel a szerverrel, él és eléggé bekapcsolható. könnyen.
Hogy is néz ki ez a gyakorlatban? Kapcsoljuk ki a szervert karbantartás miatt – például a BIOS felvillantásával. A naplókban azonnal időtúllépést kapunk, látjuk az első sort, majd három próbálkozás után „sikertelennek” jelölik, és egyszerűen kikerül a listából.
Egy második viselkedési lehetőség is lehetséges, amikor a VS egyszerűen nullára van állítva, de ha a fényképet visszaküldik, ez nem működik jól. A szerver megjelenik, az Nginx ott indul, az állapotellenőrzés azonnal megérti, hogy a kapcsolat működik, minden rendben van, és a szerver megjelenik a listánkban, és azonnal elkezdődik a terhelés. Az ügyeleti adminisztrátortól nincs szükség kézi műveletekre. A szerver éjszaka újraindult – a felügyeleti részleg nem hív minket éjszaka. Tájékoztatják, hogy ez történt, minden rendben van.
Így meglehetősen egyszerű módon, kis számú szerver segítségével megoldottuk a külső hibatűrés problémáját.
Csak annyit kell elmondani, hogy mindezt természetesen figyelemmel kell kísérni. Külön meg kell jegyezni, hogy a Keepalivede, mint régen megírt szoftver, számos módszerrel rendelkezik a figyelésére, mindkettő DBus-on, SMTP-n, SNMP-n és szabványos Zabbix-on keresztüli ellenőrzésekkel. Ráadásul ő maga is tud szinte minden tüsszentésre betűt írni, és hogy őszinte legyek, valamikor még arra is gondoltunk, hogy kikapcsoljuk, mert minden forgalomváltásra, bekapcsolásra, minden IP-kapcsolatra rengeteg betűt ír, stb . Persze, ha sok a szerver, akkor ezekkel a levelekkel elboríthatod magad. Szabványos módszerekkel figyeljük az nginx-et fotóroutereken, és a hardveres megfigyelés nem szűnt meg. Természetesen még két dolgot tanácsolnánk: először is a külső állapotellenőrzést és a rendelkezésre állást, mert még ha minden működik is, előfordulhat, hogy a felhasználók külső szolgáltatókkal kapcsolatos problémák vagy valami bonyolultabb dolog miatt nem kapnak fényképeket. Mindig érdemes valahol egy másik hálózaton, az Amazonon vagy máshol egy külön gépet tartani, ami kívülről pingelni tudja a szervereinket, és érdemes akár anomália-észlelést is használni, aki trükkös gépi tanulást tud, vagy egyszerű monitorozást. , legalábbis annak nyomon követése érdekében, hogy a kérések meredeken csökkentek-e, vagy éppen ellenkezőleg, növekedtek-e. Hasznos is lehet.
Összegezzük: a vaskalapos megoldást, ami valamikor már nem felelt meg nekünk, tulajdonképpen egy meglehetősen egyszerű rendszerre cseréltük, amely mindent ugyanúgy csinál, azaz HTTPS forgalom leállítását és további intelligens útválasztást biztosít a szükséges egészségügyi vizsgálatokat. Növeltük ennek a rendszernek a stabilitását, vagyis továbbra is magas rendelkezésre állást biztosítunk minden réteghez, plusz az a bónuszunk van, hogy elég könnyű az egészet minden rétegre skálázni, mert ez egy standard hardver szabványos szoftverrel, azaz , egyszerűsítettük a lehetséges problémák diagnosztizálását.
Mire jutottunk? Problémánk volt a 2018. januári ünnepek alatt. Az első hat hónapban, amíg ezt a sémát üzembe helyeztük, az összes forgalomra kiterjesztettük, hogy az LTM-ből az összes forgalmat eltávolítsuk, csak egy adatközpont forgalma nőtt 40 gigabitről 60 gigabitre, és ezzel egyidejűleg az egész 2018-as évben csaknem háromszor több fotót tudtak küldeni másodpercenként.
Forrás: will.com