Kaasaegne veeb on peaaegu mõeldamatu ilma meediasisuta: peaaegu igal vanaemal on nutitelefon, kõik on sotsiaalvõrgustikes ja hoolduse seisakud on ettevõtetele kulukad. Siin on ärakiri ettevõtte loost selle kohta, kuidas ta riistvaralahenduse abil fotode kohaletoimetamist korraldas, milliseid jõudlusprobleeme ta protsessis kokku puutus, mis neid põhjustas ja kuidas need probleemid lahendati Nginxil põhineva tarkvaralahenduse abil, tagades samal ajal tõrketaluvuse kõigil tasanditel (). Täname Olegi loo autoreid Efimova ja Alexandra Dymova, kes jagasid oma kogemust konverentsil .
— Alustame väikese sissejuhatusega selle kohta, kuidas me fotosid talletame ja vahemällu salvestame. Meil on kiht, kuhu me neid salvestame, ja kiht, kuhu me fotod vahemällu salvestame. Samas, kui tahame saavutada kõrget trikkide määra ja vähendada salvestusruumi koormust, on meie jaoks oluline, et iga üksiku kasutaja foto oleks ühes vahemäluserveris. Vastasel juhul peaksime installima sama mitu korda rohkem kettaid, kui meil on rohkem servereid. Meie trikkide määr on umbes 99%, see tähendab, et vähendame oma salvestusruumi koormust 100 korda ja selleks oli meil 10 aastat tagasi, kui seda kõike ehitati, 50 serverit. Seetõttu vajasime nende fotode teenindamiseks sisuliselt 50 välist domeeni, mida need serverid teenindavad.
Loomulikult tekkis kohe küsimus: kui üks meie serveritest kaob ja muutub kättesaamatuks, siis millise osa liiklusest me kaotame? Vaatasime turul pakutavat ja otsustasime osta riistvara, et see lahendaks kõik meie probleemid. Valik langes F5-võrguettevõtte (kes, muide, hiljuti ostis NGINX, Inc) lahenduse: BIG-IP Local Traffic Manager.
Mida see riistvaraosa (LTM) teeb: see on raudruuter, mis muudab oma välised pordid raudse liiasuse ja võimaldab teil suunata liiklust võrgu topoloogia, teatud seadete alusel ja teeb tervisekontrolli. Meie jaoks oli oluline, et seda riistvara saaks programmeerida. Sellest lähtuvalt võiksime kirjeldada loogikat, kuidas konkreetse kasutaja fotosid konkreetsest vahemälust edastati. Kuidas see välja näeb? On riistvara, mis vaatab Internetti ühel domeenil, ühel IP-l, teeb ssl-i mahalaadimist, analüüsib http-päringuid, valib IRule-st vahemälu numbri, kuhu minna ja laseb liiklusel sinna minna. Samas teeb tervisekontrolli ja mõne masina kättesaamatuse korral tegime tookord nii, et liiklus läks ühte varuserverisse. Konfiguratsiooni seisukohalt on muidugi nüansse, kuid üldiselt on kõik üsna lihtne: registreerime kaardi, teatud numbri vastavus meie IP-le võrgus, ütleme, et kuulame pordides 80 ja 443, ütleme, et kui server pole saadaval, siis peate saatma liikluse varuserverile, antud juhul 35., ja kirjeldame hunnikut loogikat selle arhitektuuri lahtivõtmise kohta. Ainus probleem oli see, et keel, milles riistvara programmeeriti, oli Tcl. Kui keegi seda üldse mäletab... see keel on pigem kirjutamiskeel kui programmeerimiseks mugav keel:
Mida me saime? Saime riistvara, mis tagab meie infrastruktuuri kõrge kättesaadavuse, suunab kogu meie liikluse, pakub tervisele kasu ja lihtsalt töötab. Pealegi töötab see üsna pikka aega: viimase 10 aasta jooksul pole selle kohta ühtegi kaebust olnud. 2018. aasta alguseks saatsime juba umbes 80 80 fotot sekundis. See on kuskil XNUMX gigabitist liiklust meie mõlemast andmekeskusest.
Aga…
2018. aasta alguses nägime edetabelites koledat pilti: fotode saatmiseks kulunud aeg oli selgelt pikenenud. Ja see ei sobinud meile enam. Probleem on selles, et selline käitumine oli nähtav ainult liiklustiheduse ajal - meie ettevõtte jaoks on see öö pühapäevast esmaspäevani. Kuid ülejäänud aja käitus süsteem nagu tavaliselt, rikke märke polnud.
Sellest hoolimata tuli probleem lahendada. Tuvastasime võimalikud kitsaskohad ja asusime neid likvideerima. Kõigepealt muidugi laiendasime väliseid üleslinke, tegime sisemiste üleslinkide täieliku auditi ja leidsime kõik võimalikud kitsaskohad. Kuid see kõik ei andnud ilmset tulemust, probleem ei kadunud.
Teine võimalik kitsaskoht oli fotode vahemälude enda jõudlus. Ja me otsustasime, et võib-olla on probleem nendes. Noh, laiendasime jõudlust - peamiselt fotovahemälu võrgupordid. Kuid jällegi ei täheldatud ilmset paranemist. Lõpuks pöörasime suurt tähelepanu LTM-i enda jõudlusele ja siin nägime graafikutel kurba pilti: kõigi CPU-de koormus hakkab sujuvalt minema, kuid jõuab siis järsku platoole. Samal ajal lakkab LTM adekvaatselt reageerimast tervisekontrollidele ja üleslinkidele ning hakkab neid juhuslikult välja lülitama, mis toob kaasa jõudluse tõsise halvenemise.
See tähendab, et oleme tuvastanud probleemi allika, tuvastanud kitsaskoha. Jääb otsustada, mida me teeme.
Esimene, kõige ilmsem asi, mida saaksime teha, on LTM-i ennast kuidagi moderniseerida. Kuid siin on mõned nüansid, kuna see riistvara on üsna ainulaadne, te ei lähe lähimasse supermarketisse ja ostate seda. See on eraldi leping, eraldi litsentsileping ja see võtab palju aega. Teine võimalus on hakata ise mõtlema, ise oma komponente kasutades välja mõelda oma lahendus, eelistatavalt avatud juurdepääsuga programmi abil. Jääb vaid otsustada, mida me selleks täpselt valime ja kui palju aega selle probleemi lahendamisele kulutame, kuna kasutajad ei saanud piisavalt fotosid. Seetõttu peame seda kõike tegema väga-väga kiiresti, võiks öelda eile.
Kuna ülesanne kõlas nagu "tehke midagi nii kiiresti kui võimalik ja kasutades olemasolevat riistvara", siis esimese asjana mõtlesime lihtsalt mõned mitte väga võimsad masinad eest eemaldada, sinna panna Nginx, millega me teame, kuidas töötage ja proovige rakendada kogu sama loogikat, mida riistvara varem tegi. See tähendab, et tegelikult jätsime oma riistvara maha, paigaldasime veel 4 serverit, mida pidime konfigureerima, lõime neile välised domeenid, sarnaselt 10 aasta tagusele... veelgi vähem, nad lahendasid meie kasutajate probleemi kohapeal.
Sellest lähtuvalt jääb loogika samaks: installime Nginxi, see saab teha SSL-i mahalaadimist, saame kuidagi programmeerida marsruutimise loogika, konfiguratsioonides tervisekontrolli ja lihtsalt dubleerida loogikat, mis meil varem oli.
Istume maha, et konfiguratsioone kirjutada. Alguses tundus, et kõik on väga lihtne, kuid kahjuks on iga ülesande jaoks väga raske juhendeid leida. Seetõttu ei soovita me lihtsalt guugeldada "kuidas Nginxi fotode jaoks konfigureerida": parem on vaadata ametlikku dokumentatsiooni, mis näitab, milliseid seadeid tuleks puudutada. Kuid parem on konkreetne parameeter ise valida. Noh, siis on kõik lihtne: kirjeldame servereid, mis meil on, kirjeldame sertifikaate... Aga kõige huvitavam on tegelikult marsruutimisloogika ise.
Alguses tundus meile, et me lihtsalt kirjeldame oma asukohta, sobitasime selles oleva foto vahemälu numbriga, kasutame oma käsi või generaatorit, et kirjeldada, kui palju ülesvoolu vajame, igas ülesvoolus näitame serveri, kuhu liiklus peaks liikuma. go ja varuserver – kui põhiserver pole saadaval:
Aga ilmselt, kui kõik oleks nii lihtne, läheksime lihtsalt koju ega ütleks midagi. Kahjuks Nginxi vaikesätetega, mis on üldiselt tehtud aastatepikkuse arendustööga ja ei ole antud juhul täiesti sobivad... konfig näeb välja selline: kui mõnel ülesvoolu serveril on päringu viga või timeout, siis Nginx alati lülitab liikluse järgmisele. Pealegi lülitatakse pärast esimest tõrget 10 sekundi jooksul välja ka server, nii kogemata kui ka ajalõpu tõttu - seda ei saa isegi mitte kuidagi konfigureerida. See tähendab, et kui eemaldame või lähtestame ülesvoolu direktiivi ajalõpu suvandi, siis kuigi Nginx seda päringut ei töötle ja vastab mõne mitte eriti hea veaga, lülitub server välja.
Selle vältimiseks tegime kaks asja:
a) nad keelasid Nginxil seda käsitsi teha - ja kahjuks on ainus viis seda teha lihtsalt maksimaalsete ebaõnnestumiste seadistustega.
b) meenus, et teistes projektides kasutame moodulit, mis võimaldab teha tausta tervisekontrolli - vastavalt sellele tegime tervisekontrolli üsna sageli, et avarii korral oleks seisakuid minimaalne.
Kahjuks pole see veel kõik, sest sõna otseses mõttes näitasid selle skeemi esimesed kaks nädalat, et ka TCP tervisekontroll on ebausaldusväärne asi: ülesvoolu serveris ei pruugi see olla Nginx või D-olekus Nginx ja sel juhul võtab kernel ühenduse vastu, tervisekontroll läbib, kuid ei tööta. Seetõttu asendasime selle kohe tervisekontrolli http-ga, tegime konkreetse, mis kui tagastab 200, siis selles skriptis kõik töötab. Saate teha täiendavat loogikat - näiteks vahemällu salvestavate serverite puhul kontrollige, kas failisüsteem on õigesti ühendatud:
Ja see sobiks meile, välja arvatud see, et hetkel kordas ahel täielikult seda, mida riistvara tegi. Aga tahtsime paremini teha. Varem oli meil üks varuserver ja see pole ilmselt väga hea, sest kui teil on sada serverit, siis kui mitu korraga ebaõnnestub, ei pea üks varuserver tõenäoliselt koormusega toime. Seetõttu otsustasime jagada broneeringu kõigi serverite vahel: tegime lihtsalt eraldi ülesvoolu, kirjutasime sinna kõik serverid teatud parameetritega vastavalt koormusele, mida nad teenindada saavad, lisasime samad tervisekontrollid, mis meil varem olid:
Kuna ühe ülesvoolu sees ei ole võimalik teisele ülesvoolu minna, siis tuli veenduda, et kui peamine ülesvool, kuhu salvestasime lihtsalt õige, vajaliku foto vahemälu, ei olnud saadaval, läksime lihtsalt error_page kaudu tagasi, alates kus me läksime ülesvoolu tagavarasse:
Ja nelja serveri sõna otseses mõttes lisamisega saime selle: asendasime osa koormusest - eemaldasime selle LTM-ist nendesse serveritesse, rakendasime seal sama loogika, kasutades standardset riist- ja tarkvara ning saime kohe boonuse, mida need serverid suudavad. skaleerida, sest neid saab lihtsalt tarnida nii palju kui vaja. Ainus negatiivne on see, et oleme väliskasutajate jaoks kaotanud kõrge kättesaadavuse. Kuid sel hetkel pidime selle ohverdama, sest probleem oli vaja kohe lahendada. Niisiis, eemaldasime osa koormusest, see oli sel ajal umbes 40%, LTM tundis end hästi ja sõna otseses mõttes kaks nädalat pärast probleemi algust hakkasime saatma mitte 45 55 päringut sekundis, vaid 20 XNUMX. Tegelikult kasvasime XNUMX% – see on selgelt liiklus, mida me kasutajale ei andnud. Ja pärast seda hakati mõtlema, kuidas lahendada allesjäänud probleem - tagada kõrge väline juurdepääsetavus.
Meil oli väike paus, mille jooksul arutasime, millist lahendust me selleks kasutame. Tehti ettepanekuid töökindluse tagamiseks DNS-i abil, mõningate kodus kirjutatud skriptide, dünaamiliste marsruutimisprotokollide kasutamisega... valikuid oli palju, kuid juba sai selgeks, et fotode tõeliselt usaldusväärseks edastamiseks tuleb kasutusele võtta veel üks kiht, mis seda jälgib. . Nimetasime neid masinaid fotorežissöörideks. Tarkvara, millele tuginesime, oli Keepalived:
Alustuseks, millest Keepalived koosneb? Esimene on võrguettevõtjatele laialdaselt tuntud VRRP-protokoll, mis asub võrguseadmetel, mis tagab tõrketaluvuse välisele IP-aadressile, millega kliendid ühenduvad. Teine osa on IPVS, IP virtuaalserver, fotoruuterite vahel tasakaalustamiseks ja tõrketaluvuse tagamiseks sellel tasemel. Ja kolmandaks – tervisekontroll.
Alustame esimese osaga: VRRP – kuidas see välja näeb? Seal on teatud virtuaalne IP, millel on kanne saidil dns badoocdn.com, kus kliendid ühendavad. Mingil ajahetkel on meil ühes serveris IP-aadress. Keepalived paketid jooksevad serverite vahel VRRP protokolli kaudu ja kui master kaob radarilt - server on rebooted või midagi muud, siis varuserver võtab selle IP-aadressi automaatselt üles - käsitsi ei ole vaja midagi teha. Peamise ja varunduse erinevus on peamiselt prioriteetne: mida kõrgem see on, seda suurem on võimalus, et masinast saab master. Väga suureks eeliseks on see, et IP-aadresse ei pea seadistama serveris endas, piisab nende kirjeldamisest konfiguratsioonis ja kui IP-aadressid vajavad kohandatud marsruutimise reegleid, kirjeldatakse seda otse konfiguratsioonis, kasutades sama süntaks, nagu on kirjeldatud VRRP paketis. Sa ei puutu kokku võõraste asjadega.
Kuidas see praktikas välja näeb? Mis juhtub, kui üks serveritest ebaõnnestub? Niipea kui ülem kaob, lõpetab meie varumeeskond reklaamide vastuvõtmise ja muutub automaatselt meistriks. Mõne aja pärast parandasime masteri, taaskäivitasime, tõstsime Keepalived - reklaamid saabuvad kõrgema prioriteediga kui varukoopia ja varukoopia pöördub automaatselt tagasi, eemaldab IP-aadressid, käsitsi toiminguid teha ei pea.
Seega oleme taganud välise IP-aadressi veataluvuse. Järgmine osa on kuidagi tasakaalustada liiklust väliselt IP-aadressilt fotoruuteriteni, mis seda juba lõpetavad. Tasakaalustusprotokollidega on kõik üsna selge. See on kas lihtne round-robin või veidi keerulisemad asjad, wrr, listiühendus ja nii edasi. Põhimõtteliselt on seda dokumentatsioonis kirjeldatud, midagi erilist pole. Aga kohaletoimetamise viis... Siin vaatleme lähemalt, miks me neist ühe valisime. Need on NAT, otsemarsruutimine ja TUN. Fakt on see, et kohe plaanisime saitidelt 100 gigabitist liiklust kohale toimetada. Kui te hindate, on teil vaja 10 gigabitist kaarti, eks? 10 gigabitist kaarti ühes serveris on juba vähemalt meie standardvarustuse kontseptsioonist väljas. Ja siis meenus, et me ei anna lihtsalt ära liiklust, vaid kingime fotosid.
Mis on erilist? — Tohutu erinevus sissetuleva ja väljuva liikluse vahel. Sissetulev liiklus on väga väike, väljaminev liiklus väga suur:
Kui neid graafikuid vaadata, siis on näha, et hetkel saab režissöör umbes 200 MB sekundis, see on väga tavaline päev. Anname tagasi 4,500 MB sekundis, meie suhe on ligikaudu 1/22. Juba praegu on selge, et väljuva liikluse täielikuks pakkumiseks 22 tööserverile on meil vaja ainult ühte, mis selle ühenduse aktsepteerib. Siin tuleb meile appi otsemarsruutimisalgoritm.
Kuidas see välja näeb? Meie fotorežissöör edastab tema tabeli järgi ühendused fotoruuteritele. Aga fotoruuterid saadavad tagasiliikluse otse internetti, saadavad kliendile, see ei lähe tagasi läbi fotorežissööri, seega tagame minimaalse arvu masinatega täieliku veataluvuse ja kogu liikluse pumpamise. Seadistustes näeb see välja järgmine: täpsustame algoritmi, meie puhul on see lihtne rr, anname otsemarsruutimise meetodi ja hakkame siis loetlema kõiki tegelikke servereid, kui palju meil neid on. Mis määrab selle liikluse. Kui meil on seal veel üks või kaks serverit või mitu serverit, tekib selline vajadus - lisame selle jaotise lihtsalt konfiguratsiooni ja ärge muretsege liiga palju. Pärisserverite poolelt, fotoruuteri poolelt, nõuab see meetod kõige minimaalsemat konfiguratsiooni, see on dokumentatsioonis suurepäraselt kirjeldatud ja seal pole lõkse.
Eriti tore on see, et selline lahendus ei tähenda kohaliku võrgu radikaalset ümberkujundamist, see oli meie jaoks oluline, me pidime selle lahendama minimaalsete kuludega. Kui vaatate , siis vaatame, kuidas see välja näeb. Siin on meil kindel virtuaalserver, pordis 443, kuulab, võtab ühendust, kõik töötavad serverid on loetletud ja näete, et ühendus on, anna või võta, sama. Kui vaatame sama virtuaalserveri statistikat, siis meil on sissetulevaid pakette, sissetulevaid ühendusi, aga väljaminevaid absoluutselt mitte. Väljuvad ühendused lähevad otse kliendile. Olgu, me suutsime selle tasakaalust välja viia. Mis juhtub siis, kui üks meie fotoruuteritest ebaõnnestub? Raud on ju raud. See võib sattuda tuumapaanikasse, puruneda, toiteplokk võib läbi põleda. Mida iganes. Seetõttu on vaja tervisekontrolli. Need võivad olla nii lihtsad kui pordi avatuse kontrollimine või midagi keerukamat, kuni mõne kodus kirjutatud skriptini, mis kontrollib isegi äriloogikat.
Peatasime kuskil keskel: meil on https-päring konkreetsele asukohale, skript kutsutakse välja, kui see vastab 200. vastusega, usume, et selle serveriga on kõik korras, see on elus ja saab üsna sisse lülitada lihtsalt.
Kuidas see jälle praktikas välja näeb? Lülitame serveri hoolduseks välja – näiteks BIOS-i vilkumiseks. Logides on meil kohe aeg, näeme esimest rida, seejärel märgitakse pärast kolme katset kui "ebaõnnestunud" ja see eemaldatakse lihtsalt loendist.
Võimalik on ka teine käitumisvariant, kui VS on lihtsalt nulliks, kuid kui foto tagastatakse, ei tööta see hästi. Server ilmub, Nginx käivitub seal, tervisekontroll saab kohe aru, et ühendus töötab, et kõik on korras ja server ilmub meie loendisse ja sellele hakatakse kohe koormust rakendama. Tööülesannete administraatorilt pole vaja mingeid käsitsi toiminguid teha. Server taaskäivitus öösel - seireosakond ei helista meile öösel. Nad teavitavad teid, et see juhtus, kõik on korras.
Seega lahendasime üsna lihtsal viisil väikese hulga serverite abil välise veataluvuse probleemi.
Jääb üle vaid öelda, et seda kõike tuleb loomulikult jälgida. Eraldi tuleb märkida, et Keepalivedel kui kaua aega tagasi kirjutatud tarkvaral on selle jälgimiseks hunnik viise, kasutades nii DBusi, SMTP, SNMP kui ka standardse Zabbixi kaudu tehtud kontrolle. Pluss ta ise oskab peaaegu iga aevastamise jaoks tähti kirjutada ja kui aus olla, siis mingi hetk me isegi mõtlesime selle välja lülitada, sest iga liikluse ümberlülitumise, sisselülitamise, iga IP-ühenduse jaoks kirjutab ta palju tähti, ja nii edasi . Muidugi, kui servereid on palju, siis võid end nende kirjadega üle ujutada. Jälgime nginxi fotoruuteritel tavapäraste meetoditega ja riistvara jälgimine pole kuhugi kadunud. Soovitaksime muidugi veel kahte asja: esiteks väline tervisekontroll ja saadavus, sest isegi kui kõik töötab, siis võib-olla ei saa kasutajad fotosid kätte väliste pakkujatega seotud probleemide või millegi keerukama tõttu. Alati tasub hoida kuskil teises võrgus, Amazonis või kuskil mujal eraldi masin, mis suudab teie servereid väljastpoolt pingida, samuti tasub kasutada kas anomaaliatuvastust, kellel on vaja keerulist masinõpet, või lihtsat jälgimist. , vähemalt selleks, et jälgida, kas taotlused on järsult langenud või, vastupidi, suurenenud. See võib olla ka kasulik.
Teeme kokkuvõtte: tegelikult asendasime raudkindla lahenduse, mis mingil hetkel enam ei sobinud, üsna lihtsa süsteemiga, mis teeb kõike sama, st pakub HTTPS-i liikluse lõpetamist ja edasist nutikat marsruutimist vajalikud tervisekontrollid. Oleme suurendanud selle süsteemi stabiilsust, see tähendab, et meil on endiselt kõrge saadavus iga kihi jaoks, lisaks saime boonuseks, et seda kõike on igal kihil üsna lihtne skaleerida, kuna tegemist on standardse riistvaraga koos standardtarkvaraga, st. , oleme lihtsustanud võimalike probleemide diagnoosimist.
Milleni me lõpuks jõudsime? Meil oli probleem 2018. aasta jaanuari pühade ajal. Esimese kuue kuu jooksul, mil me selle skeemi kasutusele võtsime, laiendasime seda kogu liiklusele, et eemaldada kogu liiklus LTM-ist, kasvasime ainult ühe andmekeskuse liikluse 40 gigabitilt 60 gigabitile ja samal ajal kogu 2018. aasta suutis saata peaaegu kolm korda rohkem fotosid sekundis.
Allikas: www.habr.com