La web moderna és gairebé impensable sense contingut multimèdia: gairebé totes les àvies tenen un telèfon intel·ligent, tothom està a les xarxes socials i el temps d'inactivitat en el manteniment és costós per a les empreses. Aquí teniu una transcripció de la història de l'empresa sobre com va organitzar el lliurament de fotos mitjançant una solució de maquinari, quins problemes de rendiment va trobar en el procés, què els va causar i com es van resoldre aquests problemes mitjançant una solució de programari basada en Nginx, tot garantint la tolerància a errors a tots els nivells (). Donem les gràcies als autors de la història d'Oleg Efimova i Alexandra Dymova, que van compartir la seva experiència a la conferència .
— Comencem amb una petita introducció sobre com emmagatzemem i emmagatzemem les fotos a la memòria cau. Tenim una capa on les guardem, i una capa on emmagatzemem les fotos a la memòria cau. Al mateix temps, si volem aconseguir un alt percentatge de trucs i reduir la càrrega de l'emmagatzematge, és important per a nosaltres que cada foto d'un usuari individual estigui en un servidor de memòria cau. En cas contrari, hauríem d'instal·lar tantes vegades més discs com més servidors tinguem. El nostre percentatge de trucs ronda el 99%, és a dir, estem reduint 100 vegades la càrrega del nostre emmagatzematge, i per fer-ho, fa 10 anys, quan tot això s'estava construint, teníem 50 servidors. En conseqüència, per poder servir aquestes fotos, necessitàvem essencialment 50 dominis externs que serveixen aquests servidors.
Naturalment, immediatament va sorgir la pregunta: si un dels nostres servidors falla i no està disponible, quina part del trànsit perdem? Vam mirar què hi havia al mercat i vam decidir comprar una peça de maquinari perquè resolgués tots els nostres problemes. L'elecció va recaure en la solució de l'empresa de xarxa F5 (que, per cert, va comprar recentment NGINX, Inc): BIG-IP Local Traffic Manager.
Què fa aquesta peça de maquinari (LTM): és un encaminador de ferro que fa una redundància de ferro dels seus ports externs i permet encaminar el trànsit en funció de la topologia de la xarxa, d'alguns paràmetres i fa comprovacions de salut. Per a nosaltres era important que aquesta peça de maquinari es pogués programar. En conseqüència, podríem descriure la lògica de com es van servir les fotografies d'un usuari concret des d'una memòria cau específica. Quin aspecte té? Hi ha una peça de maquinari que mira Internet en un domini, una IP, descarrega ssl, analitza les sol·licituds http, selecciona un número de memòria cau d'IRule, on anar i deixa que el trànsit hi vagi. Al mateix temps, fa comprovacions de salut i, en cas que alguna màquina no estigui disponible, en aquell moment vam fer que el trànsit anés a un servidor de còpia de seguretat. Des del punt de vista de la configuració, hi ha, és clar, alguns matisos, però en general tot és força senzill: registrem una targeta, correspondència d'un nombre determinat a la nostra IP a la xarxa, diem que escoltarem als ports 80 i 443, diem que si el servidor no està disponible, cal enviar trànsit al de còpia de seguretat, en aquest cas el 35, i descrivim un munt de lògica sobre com s'ha de desmuntar aquesta arquitectura. L'únic problema era que l'idioma en què es programava el maquinari era Tcl. Si algú ho recorda... aquest llenguatge és més d'escriptura que un llenguatge convenient per a la programació:
Què hem aconseguit? Vam rebre un maquinari que garanteix una alta disponibilitat de la nostra infraestructura, encamina tot el nostre trànsit, proporciona beneficis per a la salut i només funciona. A més, funciona durant força temps: durant els últims 10 anys no hi ha hagut queixes al respecte. A principis del 2018, ja estàvem enviant unes 80 fotos per segon. Es tracta d'uns 80 gigabits de trànsit dels nostres dos centres de dades.
Malgrat això…
A principis del 2018 vam veure una imatge lletja als gràfics: el temps que es va trigar a enviar fotos havia augmentat clarament. I ens va deixar de convenir. El problema és que aquest comportament només era visible durant el pic de trànsit: per a la nostra empresa aquesta és la nit de diumenge a dilluns. Però la resta del temps el sistema es va comportar com de costum, sense signes de fracàs.
Tot i això, el problema s'havia de resoldre. Vam identificar possibles colls d'ampolla i vam començar a eliminar-los. En primer lloc, per descomptat, vam ampliar els enllaços ascendents externs, vam realitzar una auditoria completa dels enllaços amunt interns i vam trobar tots els possibles colls d'ampolla. Però tot això no va donar un resultat evident, el problema no va desaparèixer.
Un altre possible coll d'ampolla va ser el rendiment dels propis cachés de fotos. I vam decidir que potser el problema rau en ells. Bé, hem ampliat el rendiment, principalment els ports de xarxa a la memòria cau de fotos. Però de nou no es va veure cap millora evident. Al final, vam prestar molta atenció al rendiment del propi LTM, i aquí vam veure una imatge trista als gràfics: la càrrega de totes les CPU comença a anar sense problemes, però de sobte arriba a un altiplà. Al mateix temps, LTM deixa de respondre adequadament a les comprovacions de salut i als enllaços ascendents i comença a desactivar-los aleatòriament, la qual cosa comporta una greu degradació del rendiment.
És a dir, hem identificat l'origen del problema, identificat el coll d'ampolla. Queda per decidir què farem.
El primer, el més evident que podríem fer és modernitzar d'alguna manera el propi LTM. Però aquí hi ha alguns matisos, perquè aquest maquinari és força únic, no aniràs al supermercat més proper i el compraràs. Aquest és un contracte separat, un contracte de llicència independent i trigarà molt de temps. La segona opció és començar a pensar per tu mateix, trobar la teva pròpia solució utilitzant els teus propis components, preferiblement amb un programa d'accés obert. Només queda decidir què triarem exactament per a això i quant de temps dedicarem a resoldre aquest problema, perquè els usuaris no rebien prou fotos. Per tant, hem de fer tot això molt, molt ràpid, es podria dir ahir.
Com que la tasca sonava com "fer alguna cosa el més ràpid possible i utilitzant el maquinari que tenim", el primer que vam pensar va ser simplement eliminar algunes màquines no molt potents de la part frontal, posar-hi Nginx, amb la qual sabem com fer-ho. treballar i intentar implementar la mateixa lògica que el maquinari solia fer. És a dir, de fet, vam deixar el nostre maquinari, vam instal·lar 4 servidors més que havíem de configurar, els vam crear dominis externs, com era fa 10 anys... Perdíem una mica de disponibilitat si aquestes màquines caiguessin, però encara menys, van resoldre localment el problema dels nostres usuaris.
En conseqüència, la lògica segueix sent la mateixa: instal·lem Nginx, pot fer una descàrrega SSL, podem programar d'alguna manera la lògica d'encaminament, les comprovacions de salut a les configuracions i simplement duplicar la lògica que teníem abans.
Seiem a escriure configuracions. Al principi semblava que tot era molt senzill, però, malauradament, és molt difícil trobar manuals per a cada tasca. Per tant, no us recomanem simplement anar a Google "com configurar Nginx per a fotos": és millor consultar la documentació oficial, que mostrarà quins paràmetres s'han de tocar. Però és millor triar el paràmetre específic. Bé, aleshores tot és senzill: descrivim els servidors que tenim, els certificats... Però el més interessant és, de fet, la pròpia lògica d'encaminament.
Al principi ens va semblar que simplement estàvem descrivint la nostra ubicació, fent coincidir el número de la nostra memòria cau de fotos que hi ha, fent servir les nostres mans o un generador per descriure quants aigües amunt necessitem, a cada aigües amunt indiquem el servidor al qual hauria de fer el trànsit. go, i un servidor de còpia de seguretat, si el servidor principal no està disponible:
Però, probablement, si tot fos tan senzill, simplement tornaríem a casa i no diríem res. Malauradament, amb la configuració predeterminada de Nginx, que, en general, es van fer durant molts anys de desenvolupament i no són del tot adequades per a aquest cas... la configuració es veu així: si algun servidor amunt té un error de sol·licitud o temps d'espera, Nginx sempre canvia el trànsit al següent. A més, després del primer error, en 10 segons, el servidor també s'apagarà, tant per error com per temps d'espera, ni tan sols es pot configurar de cap manera. És a dir, si eliminem o restablim l'opció de temps d'espera a la directiva upstream, aleshores, tot i que Nginx no processarà aquesta sol·licitud i respondrà amb algun error no molt bo, el servidor s'apagarà.
Per evitar-ho hem fet dues coses:
a) van prohibir a Nginx fer-ho manualment i, malauradament, l'única manera de fer-ho és simplement establir la configuració màxima d'errors.
b) hem recordat que en altres projectes utilitzem un mòdul que ens permet fer controls de salut d'antecedents -en conseqüència, vam fer controls de salut bastant freqüents perquè el temps d'inactivitat en cas d'accident fos mínim.
Malauradament, això tampoc és tot, perquè literalment les dues primeres setmanes de funcionament d'aquest esquema van demostrar que la comprovació de salut TCP tampoc és una cosa poc fiable: al servidor amunt pot ser que no sigui Nginx, o Nginx en estat D, i en estat D. en aquest cas, el nucli acceptarà la connexió, la comprovació de salut passarà, però no funcionarà. Per tant, immediatament l'hem substituït per la comprovació de salut http, en vam fer un de específic, que, si retorna 200, tot funciona en aquest script. Podeu fer una lògica addicional; per exemple, en el cas dels servidors de memòria cau, comproveu que el sistema de fitxers estigui muntat correctament:
I això ens convindria, excepte que de moment el circuit repetia completament el que feia el maquinari. Però volíem fer-ho millor. Anteriorment, teníem un servidor de còpia de seguretat, i això probablement no és molt bo, perquè si teniu un centenar de servidors, aleshores, quan fallen diversos alhora, és poc probable que un servidor de còpia de seguretat faci front a la càrrega. Per tant, vam decidir distribuir la reserva entre tots els servidors: simplement vam fer una altra aigües amunt per separat, hi vam escriure tots els servidors amb uns paràmetres determinats d'acord amb la càrrega que poden servir, vam afegir les mateixes comprovacions de salut que teníem abans:
Com que és impossible anar a un altre aigües amunt dins d'un aigües amunt, calia assegurar-se que si el riu amunt principal, en el qual simplement vam gravar la memòria cau de fotos correcta i necessària, no estava disponible, simplement vam passar per la pàgina d'error per a la alternativa, on vam anar a la còpia de seguretat aigües amunt:
I afegint literalment quatre servidors, això és el que vam aconseguir: vam substituir part de la càrrega: la vam eliminar de LTM a aquests servidors, vam implementar la mateixa lògica allà, utilitzant maquinari i programari estàndard i vam rebre immediatament la bonificació que aquests servidors poden escalar, perquè simplement es poden subministrar tant com sigui necessari. Bé, l'únic negatiu és que hem perdut alta disponibilitat per als usuaris externs. Però en aquell moment vam haver de sacrificar això, perquè calia resoldre el problema immediatament. Per tant, vam treure part de la càrrega, era al voltant del 40% en aquell moment, LTM es va sentir bé i, literalment, dues setmanes després que comencés el problema, vam començar a enviar no 45k sol·licituds per segon, sinó 55k. De fet, vam créixer un 20%; aquest és clarament el trànsit que no vam donar a l'usuari. I després d'això, van començar a pensar com resoldre el problema restant: garantir una alta accessibilitat externa.
Vam fer una pausa, durant la qual vam discutir quina solució utilitzaríem per a això. Hi havia propostes per garantir la fiabilitat mitjançant DNS, amb l'ajuda d'alguns scripts escrits a casa, protocols d'encaminament dinàmic... hi havia moltes opcions, però ja es va veure que per a un lliurament de fotos realment fiable, cal introduir una altra capa que vigilarà això. A aquestes màquines els vam anomenar directors de fotos. El programari en què confiàvem era Keepalived:
Per començar, en què consisteix Keepalived? El primer és el protocol VRRP, àmpliament conegut pels usuaris de xarxa, situat en equips de xarxa que proporciona tolerància a errors a l'adreça IP externa a la qual es connecten els clients. La segona part és IPVS, servidor virtual IP, per equilibrar entre encaminadors fotogràfics i garantir la tolerància a errors en aquest nivell. I tercer: controls de salut.
Comencem per la primera part: VRRP: com és? Hi ha una IP virtual determinada, que té una entrada al dns badoocdn.com, on es connecten els clients. En algun moment, tenim una adreça IP en un servidor. Els paquets Keepalived s'executen entre els servidors mitjançant el protocol VRRP i, si el mestre desapareix del radar, el servidor s'ha reiniciat o alguna altra cosa, el servidor de còpia de seguretat recull automàticament aquesta adreça IP, no cal fer cap acció manual. La diferència entre mestre i còpia de seguretat és principalment prioritària: com més alta sigui, més probabilitats que la màquina es converteixi en mestre. Un avantatge molt gran és que no cal que configureu les adreces IP al propi servidor, n'hi ha prou amb descriure-les a la configuració, i si les adreces IP necessiten algunes regles d'encaminament personalitzades, això es descriu directament a la configuració, utilitzant el mateixa sintaxi que es descriu al paquet VRRP. No trobaràs coses desconegudes.
Com es veu això a la pràctica? Què passa si un dels servidors falla? Tan bon punt desapareix el mestre, la nostra còpia de seguretat deixa de rebre anuncis i es converteix automàticament en mestre. Després d'un temps, hem reparat el mestre, hem reiniciat, hem creat Keepalived: els anuncis arriben amb una prioritat més alta que la còpia de seguretat i la còpia de seguretat es torna automàticament enrere, elimina les adreces IP, no cal fer cap acció manual.
Així, hem assegurat la tolerància a errors de l'adreça IP externa. La següent part és equilibrar d'alguna manera el trànsit des de l'adreça IP externa fins als encaminadors fotogràfics que ja l'estan terminant. Tot està clar amb els protocols d'equilibri. Això és un simple round-robin, o coses una mica més complexes, wrr, connexió de llista, etc. Això es descriu bàsicament a la documentació, no hi ha res especial. Però el mètode de lliurament... Aquí veurem més de prop per què n'hem escollit un. Aquests són NAT, Direct Routing i TUN. El fet és que de seguida vam planejar lliurar 100 gigabits de trànsit des dels llocs. Si calculeu, necessiteu targetes de 10 gigabit, oi? Les targetes de 10 gigabits en un servidor ja estan fora de l'abast, almenys, del nostre concepte d'"equip estàndard". I després vam recordar que no només regalem una mica de trànsit, sinó que regalem fotos.
Què té d'especial? — Enorme diferència entre el trànsit entrant i sortint. El trànsit d'entrada és molt petit, el trànsit de sortida és molt gran:
Si mireu aquests gràfics, podeu veure que en aquests moments el director està rebent uns 200 MB per segon, aquest és un dia molt normal. Tornem 4,500 MB per segon, la nostra relació és d'aproximadament 1/22. Ja està clar que per proporcionar totalment el trànsit de sortida a 22 servidors de treball, només en necessitem un que accepti aquesta connexió. Aquí és on l'algoritme d'encaminament directe ens ajuda.
Quin aspecte té? El nostre director fotogràfic, segons la seva taula, transmet connexions als encaminadors fotogràfics. Però els encaminadors fotogràfics envien el trànsit de retorn directament a Internet, l'envien al client, no torna enrere pel director fotogràfic, per tant, amb un nombre mínim de màquines, assegurem una tolerància a errors completa i el bombeig de tot el trànsit. A les configuracions es veu així: especifiquem l'algorisme, en el nostre cas és un simple rr, proporcionem el mètode d'encaminament directe i després comencem a llistar tots els servidors reals, quants d'ells tenim. El que determinarà aquest trànsit. Si tenim un o dos servidors més allà, o diversos servidors, sorgeix aquesta necessitat: només afegim aquesta secció a la configuració i no us preocupeu massa. Des del costat dels servidors reals, des del costat de l'encaminador fotogràfic, aquest mètode requereix la configuració més mínima, està perfectament descrit a la documentació i no hi ha cap inconvenient.
El que és especialment agradable és que aquesta solució no implica un redisseny radical de la xarxa local; això era important per a nosaltres; ho vam haver de resoldre amb uns costos mínims. Si mireu , llavors veurem com és. Aquí tenim un determinat servidor virtual, al port 443, escolta, accepta la connexió, s'enumeren tots els servidors que funcionen, i es pot veure que la connexió és igual. Si mirem les estadístiques del mateix servidor virtual, tenim paquets entrants, connexions entrants, però absolutament cap de sortint. Les connexions de sortida van directament al client. D'acord, vam poder desequilibrar-ho. Ara bé, què passa si un dels nostres encaminadors fotogràfics falla? Després de tot, el ferro és ferro. Pot entrar en pànic del nucli, es pot trencar, la font d'alimentació es pot cremar. Qualsevol cosa. Per això calen controls de salut. Poden ser tan senzills com comprovar com està obert el port, o alguna cosa més complexa, fins a alguns scripts escrits a casa que fins i tot comprovaran la lògica empresarial.
Ens vam aturar en algun lloc al mig: tenim una sol·licitud https a una ubicació concreta, es crida l'script, si respon amb una resposta 200, creiem que tot està bé amb aquest servidor, que està viu i es pot activar bastant. fàcilment.
Com es veu això, de nou, a la pràctica? Apaguem el servidor per fer-ne manteniment, per exemple, flashejar la BIOS. Als registres de seguida tenim un temps d'espera, veiem la primera línia, després de tres intents es marca com a "fallit" i simplement s'elimina de la llista.
També és possible una segona opció de comportament, quan VS simplement es posa a zero, però si es retorna la foto, això no funciona bé. El servidor apareix, Nginx comença allà, Health-Check entén immediatament que la connexió funciona, que tot està bé i el servidor apareix a la nostra llista i la càrrega immediatament comença a aplicar-s'hi. No es requereix cap acció manual de l'administrador de servei. El servidor es va reiniciar a la nit; el departament de supervisió no ens truca per això a la nit. Us informen que això va passar, tot està bé.
Així, d'una manera bastant senzilla, amb l'ajuda d'un nombre reduït de servidors, vam resoldre el problema de la tolerància a errors externs.
Tot el que queda per dir és que tot això, és clar, s'ha de controlar. Per separat, cal tenir en compte que Keepalivede, com el programari escrit fa molt de temps, té un munt de maneres de supervisar-lo, tant utilitzant comprovacions a través de DBus, SMTP, SNMP i Zabbix estàndard. A més, ell mateix sap escriure cartes per gairebé tots els esternuts i, per ser sincers, en algun moment fins i tot vam pensar en desactivar-lo, perquè escriu moltes cartes per a qualsevol canvi de trànsit, encès, per a cada connexió IP, etcètera . Per descomptat, si hi ha molts servidors, podeu desbordar-vos amb aquestes cartes. Supervisem nginx als encaminadors fotogràfics mitjançant mètodes estàndard i el control de maquinari no ha desaparegut. Per descomptat, aconsellem dues coses més: en primer lloc, controls de salut externs i disponibilitat, perquè encara que tot funcioni, de fet, potser els usuaris no reben fotos per problemes amb proveïdors externs o per alguna cosa més complexa. Sempre val la pena mantenir en algun lloc d'una altra xarxa, a Amazon o en un altre lloc, una màquina separada que pugui fer ping als vostres servidors des de l'exterior, i també val la pena utilitzar la detecció d'anomalies, per a aquells que saben com fer un aprenentatge automàtic complicat, o un seguiment senzill. , almenys per tal de fer un seguiment de si les sol·licituds han baixat molt o, per contra, han augmentat. També pot ser útil.
Resumim: nosaltres, de fet, vam substituir la solució de ferro, que en algun moment va deixar de convenir, per un sistema bastant senzill que ho fa tot igual, és a dir, que proporciona la terminació del trànsit HTTPS i un enrutament intel·ligent addicional amb el controls sanitaris necessaris. Hem augmentat l'estabilitat d'aquest sistema, és a dir, encara tenim una alta disponibilitat per a cada capa, a més tenim l'avantatge que és bastant fàcil escalar-ho tot a cada capa, perquè és un maquinari estàndard amb programari estàndard, és a dir. , hem simplificat el diagnòstic de possibles problemes.
Amb què hem acabat? Vam tenir un problema durant les vacances de gener de 2018. Durant els primers sis mesos, mentre vam posar en funcionament aquest esquema, el vam ampliar a tot el trànsit per tal d'eliminar tot el trànsit de LTM, només vam créixer el trànsit en un centre de dades de 40 gigabits a 60 gigabits, i al mateix temps per tot l'any 2018 van poder enviar gairebé tres vegades més fotos per segon.
Font: www.habr.com