A l'estiu, tant l'activitat de compres com la intensitat dels canvis en la infraestructura dels projectes web tradicionalment disminueixen, ens explica el Capità Obvious. Simplement perquè fins i tot els especialistes informàtics de vegades se'n van de vacances. I CTO també. És més difícil per als que es mantenen en el càrrec, però ara no es tracta d'això: potser per això l'estiu és el millor període per pensar a poc a poc el règim de reserves existent i elaborar un pla per millorar-lo. I l'experiència de Yegor Andreev de , de la qual va parlar a la conferència .
Hi ha diversos inconvenients en els quals podeu caure quan creeu llocs de còpia de seguretat. I és absolutament impossible quedar-se atrapat en ells. I el que ens arruïna en tot això, com en moltes altres coses, és el perfeccionisme i... la mandra. Estem intentant fer-ho tot, tot, tot perfectament, però no cal que ho fem perfectament! Només cal fer certes coses, però fer-les correctament, completar-les perquè funcionin correctament.
El failover no és cap tipus de cosa divertida i divertida; això és una cosa que hauria de fer exactament una cosa: reduir el temps d'inactivitat perquè el servei, l'empresa, perdi menys diners. I en tots els mètodes de reserva, suggereixo pensar en el següent context: on són els diners?
Primera trampa: quan construïm sistemes grans i fiables i fem redundància, reduïm el nombre d'accidents. Això és un error terrible. Quan ens dediquem a la redundància, és probable que augmentem el nombre d'accidents. I si ho fem tot bé, col·lectivament reduirem el temps d'inactivitat. Hi haurà més accidents, però es produiran a menors costos. Què és una reserva? - Aquesta és una complicació del sistema. Qualsevol complicació és dolenta: tenim més engranatges, més engranatges, en una paraula, més elements i, per tant, més possibilitats d'avaria. I realment es trencaran. I es trencaran més sovint. Un exemple senzill: suposem que tenim un lloc web amb PHP i MySQL. I urgentment cal reservar-lo.
Shtosh (c) Agafem el segon lloc, construïm un sistema idèntic... La complexitat es fa dues vegades més gran: tenim dues entitats. També implementem una certa lògica per transferir dades d'un lloc a un altre, és a dir, la replicació de dades, la còpia de dades estàtiques, etc. Per tant, la lògica de replicació sol ser molt complexa i, per tant, la complexitat total del sistema no pot ser 2, sinó 3, 5, 10 vegades més gran.
Segon parany: quan construïm sistemes complexos molt grans, fantasiegem amb què volem aconseguir al final. Voila: volem aconseguir un sistema súper fiable que funcioni sense temps d'inactivitat, canviï en mig segon (o millor encara, a l'instant) i comencem a fer realitat els somnis. Però també hi ha un matís aquí: com més curt sigui el temps de commutació desitjat, més complexa serà la lògica del sistema. Com més complex tinguem per fer aquesta lògica, més sovint es trencarà el sistema. I pots acabar en una situació molt desagradable: estem intentant amb totes les nostres forces reduir el temps d'inactivitat, però de fet ho compliquem tot i, quan alguna cosa va malament, el temps d'inactivitat acabarà sent més llarg. Aquí sovint t'atrapes pensant: bé... millor no fer reserva. Seria millor que funcionés sol i amb temps d'inactivitat comprensibles.
Com pots lluitar contra això? Hem de deixar de mentir-nos a nosaltres mateixos, deixar d'afalagar-nos que ara construirem una nau espacial aquí, però entendre adequadament quant de temps pot durar el projecte. I durant aquest temps màxim, triarem quins mètodes utilitzarem realment per augmentar la fiabilitat del nostre sistema.
És hora de les “històries de w”... de la vida, és clar.
Exemple número u
Imagineu-vos un lloc web de targetes de visita per a la planta de laminació de canonades núm. 1 a la ciutat de N. Hi diu amb lletres enormes: PLANTA DE LAMINACIÓ DE TUBERES núm. Just a sota hi ha l'eslògan: "Les nostres canonades són les canonades més rodones de N". I a continuació hi ha el número de telèfon del CEO i el seu nom. Entenem que cal fer una reserva, això és molt important! Comencem a esbrinar en què consisteix. Html-statics: és a dir, un parell d'imatges on el director general, de fet, està discutint algun tipus de proper acord a la taula dels banys amb la seva parella. Comencem a pensar en el temps d'inactivitat. Em ve al cap: cal que estigueu allà cinc minuts, no més. I aleshores sorgeix la pregunta: quantes vendes hi va haver d'aquest lloc nostre en general? Quant-quant? Què vol dir "zero"? I això vol dir: perquè el general va fer les quatre transaccions l'any passat a la mateixa taula, amb les mateixes persones amb qui van als banys i s'asseuen a la taula. I entenem que encara que el lloc s'asseu durant un dia, no passarà res terrible.
A partir de la informació introductòria, hi ha un dia per plantejar aquesta història. Comencem a pensar en un esquema de redundància. I triem l'esquema de redundància més ideal per a aquest exemple: no fem servir la redundància. Tot això pot ser plantejat per qualsevol administrador en mitja hora amb pauses per fumar. Instal·leu un servidor web, afegiu fitxers, això és tot. Funcionarà. No cal vigilar res, no cal prestar especial atenció a res. És a dir, la conclusió de l'exemple número u és força òbvia: no cal reservar serveis que no cal reservar.
Exemple número dos
Bloc de l'empresa: hi escriuen notícies persones especialment formades, vam participar en tal o tal exposició, però vam estrenar un altre producte nou, etc. Diguem que això és PHP estàndard amb WordPress, una base de dades petita i una mica estàtica. Per descomptat, em torna a la ment que en cap cas us hauríeu de estirar: "no més de cinc minuts!" Això és tot. Però pensem més enllà. Què fa aquest blog? La gent hi ve de Yandex, de Google en funció d'algunes consultes, de manera orgànica. Genial. Les vendes hi tenen alguna cosa a veure? Epifania: no realment. El trànsit de publicitat va al lloc principal, que es troba en una màquina diferent. Comencem a pensar en un esquema de reserves. En bona manera, s'ha de criar en un parell d'hores, i estaria bé preparar-se per a això. Seria raonable agafar una màquina d'un altre centre de dades, posar-hi l'entorn, és a dir, un servidor web, PHP, WordPress, MySQL, i deixar-lo allà. En el moment en què entenem que tot està trencat, hem de fer dues coses: desplegar l'abocador de mysql a 50 metres, volarà allà en un minut i desplegarà un cert nombre d'imatges de la còpia de seguretat allà. Això tampoc hi és perquè Déu sap quant de temps. Així, en mitja hora tot puja. No hi ha rèplica, o Déu em perdoni, error automàtic. Conclusió: no cal fer una còpia de seguretat del que podem desplegar ràpidament des d'una còpia de seguretat.
Exemple número tres, més complicat
Botiga online. PhP amb cor obert està una mica ajustat, mysql amb una base sòlida. Molta estàtica (al cap i a la fi, la botiga en línia té imatges en HD i totes aquestes coses), Redis per a la sessió i Elasticsearch per a la cerca. Comencem a pensar en el temps d'inactivitat. I aquí, per descomptat, és obvi que una botiga en línia no pot quedar-se sense dolor durant un dia. Al cap i a la fi, com més temps menteix, més diners perdem. Val la pena accelerar. Quant? Crec que si ens estirem una hora, ningú es tornarà boig. Sí, perdrem alguna cosa, però si comencem a treballar dur, només empitjorarà. Definim un esquema de temps d'inactivitat permès per hora.
Com es pot reservar tot això? Necessites un cotxe en qualsevol cas: una hora de temps és força poca. Mysql: aquí ja necessitem replicació, replicació en directe, perquè d'aquí a una hora 100 GB probablement no s'afegiran a l'abocador. Estàtica, imatges: de nou, en una hora potser 500 GB no tinguin temps d'afegir-se. Per tant, és millor copiar les imatges immediatament. Redis: aquí és on les coses es posen interessants. A Redis, les sessions s'emmagatzemen, no només podem agafar-les i enterrar-les. Perquè això no serà gaire bo: es tancaran la sessió de tots els usuaris, es buidaran les seves cistelles, etc. La gent es veurà obligada a tornar a introduir el seu nom d'usuari i contrasenya, i moltes persones poden separar-se i no completar la compra. De nou, les conversions baixaran. D'altra banda, Redis està directament actualitzat, amb els últims usuaris connectats probablement tampoc no calen. I un bon compromís és agafar Redis i restaurar-lo des d'una còpia de seguretat d'ahir o, si ho feu cada hora, des de fa una hora. Afortunadament, restaurar-lo des d'una còpia de seguretat significa copiar un fitxer. I la història més interessant és Elasticsearch. Qui ha agafat mai la replicació de MySQL? Qui ha agafat mai la replicació d'Elasticsearch? I per a qui va funcionar normalment després? El que vull dir és que veiem una determinada entitat al nostre sistema. Sembla útil, però és complex.
Complex en el sentit que els nostres companys enginyers no tenen experiència treballant-hi. O hi ha una experiència negativa. O entenem que aquesta és encara una tecnologia força nova amb matisos o cruesa. Pensem... Caram, l'elastic també és saludable, també costa molt de temps restaurar-lo des d'una còpia de seguretat, què he de fer? Entenem que l'elastic en el nostre cas s'utilitza per a la recerca. Com ven la nostra botiga en línia? Anem a màrquetings i preguntem d'on ve la gent. Responen: "El 90% de Yandex Market arriba directament a la targeta del producte". I o el compren o no. Per tant, la cerca és necessària per al 10% dels usuaris. I mantenir la replicació elàstica, especialment entre diferents centres de dades en diferents zones, realment té molts matisos. Quina sortida? Agafem elàstic d'un lloc reservat i no hi fem res. Si l'assumpte s'allarga, probablement algun dia el plantejarem, però això no és segur. De fet, la conclusió és la mateixa, més o menys: nosaltres, de nou, no reservem serveis que no afectin diners. Per mantenir el diagrama més senzill.
Exemple número quatre, encara més difícil
Integrador: venent flors, trucant a un taxi, venent mercaderies, en general, qualsevol cosa. Una cosa seriosa que funciona les 24 hores del dia per a un gran nombre d'usuaris. Amb una pila interessant en tota regla, on hi ha bases interessants, solucions, càrrega elevada i, el més important, fa mal estirar-se durant més de 7 minuts. No només i no tant perquè la gent no comprarà, sinó perquè la gent veurà que això no funciona, es molestarà i potser no tornarà gens.
D'ACORD. Cinc minuts. Què farem amb això? En aquest cas, nosaltres, com els adults, utilitzem tots els diners per crear un lloc de còpia de seguretat real, amb replicació de tot, i potser fins i tot automatitzar el canvi a aquest lloc tant com sigui possible. I a més d'això, cal recordar fer una cosa important: en realitat, escriure les normes de canvi. La normativa, encara que ho tinguis tot automatitzat, pot ser molt senzilla. De la sèrie "executa tal i tal script ansible", "fes clic a tal o tal casella de selecció a la ruta 53" i així successivament, però aquesta ha de ser una mena de llista exacta d'accions.
I tot sembla clar. Canviar la rèplica és una tasca trivial, o canviarà per si mateix. Reescriure un nom de domini al DNS és de la mateixa sèrie. El problema és que quan un projecte d'aquest tipus falla, comença el pànic, i fins i tot els administradors més forts i barbuts poden ser-hi susceptibles. Sense instruccions clares "obre el terminal, vine aquí, l'adreça del nostre servidor segueix sent així", és difícil complir amb el límit de 5 minuts assignat per a la reanimació. Bé, a més, quan fem servir aquesta normativa, és fàcil registrar alguns canvis en la infraestructura, per exemple, i canviar la normativa en conseqüència.
Bé, si el sistema de reserves és molt complex i en algun moment ens hem equivocat, podem destruir el nostre lloc de còpia de seguretat i, a més, convertir les dades en una carbassa als dos llocs, això serà completament trist.
Exemple número cinc, hardcore complet
Un servei internacional amb centenars de milions d'usuaris arreu del món. Totes les zones horàries que hi ha, molta càrrega a màxima velocitat, no et pots estirar gens. Un minut, i serà trist. Què fer? Reserveu, de nou, segons el programa complet. Hem fet tot el que he parlat a l'exemple anterior, i una mica més. Un món ideal, i la nostra infraestructura és d'acord amb tots els conceptes de IaaC devops. És a dir, tot està a git i només cal prémer el botó.
Què hi falta? Un - exercicis. És impossible sense ells. Sembla que tot va perfecte amb nosaltres, en general ho tenim tot sota control. Premem el botó, tot passa. Encara que sigui així, i entenem que no passa així, el nostre sistema interactua amb alguns altres sistemes. Per exemple, això és dns de la ruta 53, emmagatzematge s3, integració amb alguna API. No ho podrem preveure tot en aquest experiment especulatiu. I fins que no estirem realment l'interruptor, no sabrem si funcionarà o no.
Això és probablement tot. No siguis mandrós ni exageris. I que el temps d'activitat estigui amb tu!
Font: www.habr.com