{"id":36393,"date":"2019-10-31T22:11:24","date_gmt":"2019-10-31T19:11:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/failover-nas-gubit-perfektsionizm-i-len\/"},"modified":"2019-10-31T22:11:24","modified_gmt":"2019-10-31T19:11:24","slug":"failover-nas-gubit-perfektsionizm-i-len","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: ne distruge perfec\u021bionismul \u0219i\u2026 lenea","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00cen timpul verii, tradi\u021bional, at\u00e2t activitatea de cump\u0103rare, c\u00e2t \u0219i intensitatea schimb\u0103rii infrastructurii proiectelor web scad, ne spune C\u0103pitanul Evident. Pur \u0219i simplu pentru c\u0103 chiar \u0219i IT-i\u0219tii, se \u00eent\u00e2mpl\u0103, merg \u00een vacan\u021b\u0103. \u0218i CTO-ul de asemenea. Mai greu le este celor care r\u0103m\u00e2n la post, dar acum nu despre asta este vorba: poate tocmai de aceea vara este cea mai bun\u0103 perioad\u0103 pentru a r\u00e9fl\u00e9chii cu calm la schema existent\u0103 de rezervare \u0219i a elabora un plan pentru \u00eembun\u0103t\u0103\u021birea acesteia. Iar \u00een acest sens, experien\u021ba lui Egor Andreev de la AdminDivision<\/a><\/noindex>, despre care a vorbit la conferin\u021b\u0103 Uptime day<\/a><\/noindex>.<\/i><\/p>\n

Atunci c\u00e2nd construim site-uri de rezerv\u0103, exist\u0103 c\u00e2teva capcane \u00een care putem c\u0103dea. Iar c\u0103derea \u00een ele este complet inacceptabil\u0103. \u0218i ne distruge \u00een tot acest proces, ca, de altfel, \u00een multe alte situa\u021bii, perfec\u021bionismul \u0219i\u2026 lenea. \u00cencerc\u0103m s\u0103 facem totul perfect, dar nu este necesar s\u0103 facem totul perfect! Trebuie s\u0103 facem doar anumite lucruri, dar s\u0103 le facem corect, s\u0103 le ducem p\u00e2n\u0103 la cap\u0103t, astfel \u00eenc\u00e2t s\u0103 func\u021bioneze bine. <\/p>\n

Failover \u2014 nu este un lucru amuzant de genul \u201es\u0103 fie acolo\u201d; este un lucru care trebuie s\u0103 fac\u0103 exact un singur lucru \u2014 s\u0103 reduc\u0103 timpul de nefunc\u021bionare, astfel \u00eenc\u00e2t serviciul, compania, s\u0103 piard\u0103 mai pu\u021bini bani. \u0218i \u00een toate metodele de rezervare propun s\u0103 g\u00e2ndim \u00een urm\u0103torul context: unde sunt banii?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nPrima capcan\u0103<\/b>: atunci c\u00e2nd construim sisteme mari \u0219i fiabile \u0219i ne ocup\u0103m de rezervare \u2014 reducem num\u0103rul de avarii. Aceasta este o \u00een\u021belegere gre\u0219it\u0103 teribil\u0103. C\u00e2nd ne ocup\u0103m de rezervare, num\u0103rul de avarii, probabil, cre\u0219te. \u0218i dac\u0103 facem totul bine, atunci \u00een total vom reduce timpul de nefunc\u021bionare. Vor fi mai multe avarii, dar acestea se vor produce cu costuri mai mici. Ce este rezervarea? \u2014 este complicarea sistemului. Orice complicare este un lucru r\u0103u: ne apar mai multe \u0219uruburi, mai multe ro\u021bi din\u021bate, pe scurt, mai multe elemente \u2014 \u0219i, prin urmare, \u0219ansa de defectare cre\u0219te. \u0218i ele se vor defecta cu adev\u0103rat. \u0218i se vor defecta mai des. Un exemplu simplu: s\u0103 spunem c\u0103 avem un anumit site, cu PHP, MySQL. \u0218i trebuie s\u0103 fie rezervat urgent. <\/p>\n

Ei bine (c) Lu\u0103m a doua platform\u0103, construim un sistem identic... Complexitatea devine de dou\u0103 ori mai mare - avem dou\u0103 entit\u0103\u021bi. \u0218i deasupra aplic\u0103m o anumit\u0103 logic\u0103 de transfer de date de pe o platform\u0103 pe alta - adic\u0103 replicarea datelor, copierea staticei \u0219i a\u0219a mai departe. A\u0219adar, logica replic\u0103rii - de obicei, este foarte complicat\u0103, \u0219i, prin urmare, complexitatea cumulat\u0103 a sistemului poate fi nu de 2, ci de 3, 5, 10 ori mai mare. <\/p>\n

A doua capcan\u0103<\/b>: c\u00e2nd construim sisteme cu adev\u0103rat mari \u0219i complexe, ne imagin\u0103m ce vrem s\u0103 ob\u021binem la final. Voil\u00e0: vrem s\u0103 ob\u021binem un sistem superfiabil, care func\u021bioneaz\u0103 complet f\u0103r\u0103 \u00eentreruperi, se comut\u0103 \u00een jum\u0103tate de secund\u0103 (sau, mai bine, instantaneu), \u0219i \u00eencepem s\u0103 transform\u0103m visele \u00een realitate. Dar aici exist\u0103 \u0219i un detaliu: cu c\u00e2t timpul de comutare dorit este mai mic, cu at\u00e2t logica sistemului devine mai complicat\u0103. Cu c\u00e2t trebuie s\u0103 facem aceast\u0103 logic\u0103 mai complex\u0103, cu at\u00e2t mai des se va strica sistemul. \u0218i putem ajunge \u00eentr-o situa\u021bie foarte nepl\u0103cut\u0103: ne str\u0103duim din toate puterile s\u0103 reducem timpul de nefunc\u021bionare, iar \u00een realitate complic\u0103m totul, iar c\u00e2nd ceva nu merge bine, timpul de nefunc\u021bionare va fi, \u00een cele din urm\u0103, mai mare. Adesea, \u00ee\u021bi dai seama: mai bine nu am fi rezervat. Mai bine s\u0103 func\u021bioneze unul singur \u0219i cu un timp de nefunc\u021bionare clar. <\/p>\n

Cum ne putem lupta cu asta? Trebuie s\u0103 \u00eencet\u0103m s\u0103 ne min\u021bim, s\u0103 \u00eencet\u0103m s\u0103 ne flatt\u0103m, c\u0103 acum vom construi o nav\u0103 spa\u021bial\u0103, dar s\u0103 \u00een\u021belegem ra\u021bional c\u00e2t de mult va putea r\u0103m\u00e2ne proiectul. \u0218i pentru acest timp maxim vom alege ce metode vom folosi pentru a spori fiabilitatea sistemului nostru. <\/p>\n

\"Failover:
\n
\nEste momentul pentru \u201epove\u0219ti din via\u021b\u0103\u201d... bine\u00een\u021beles, din via\u021b\u0103. <\/p>\n

Exemplul num\u0103rul unu<\/h4>\n

\nImagina\u021bi-v\u0103 un site de prezentare pentru fabrica de \u021bevi num\u0103rul 1 din ora\u0219ul N. Pe el este scris cu litere mari \u2014 FABRICA DE \u021aEVI NR. 1. Pu\u021bin mai jos \u2014 sloganul: \u201e\u021aevile noastre sunt cele mai rotunde din N\u201d. Iar mai jos este num\u0103rul de telefon al directorului general \u0219i numele s\u0103u. \u00cen\u021belegem c\u0103 trebuie s\u0103 rezerv\u0103m \u2014 este o chestiune foarte important\u0103! \u00cencepem s\u0103 analiz\u0103m din ce este compus. Html-static \u2014 adic\u0103 o pereche de poze, unde directorul, de fapt, st\u0103 la mas\u0103 \u00een saun\u0103 cu partenerul s\u0103u discut\u00e2nd despre o afacere recent\u0103. \u00cencepem s\u0103 ne g\u00e2ndim la timpul de nefunc\u021bionare. \u00cemi vine \u00een minte: trebuie s\u0103 r\u0103m\u00e2n\u0103 acolo cinci minute, nu mai mult. \u0218i acum \u00eentrebarea: c\u00e2te v\u00e2nz\u0103ri au fost de pe acest site? C\u00e2te? Ce \u00eenseamn\u0103 \u201ezero\u201d? Adic\u0103: pentru c\u0103 toate cele patru tranzac\u021bii de anul trecut le-a realizat la aceea\u0219i mas\u0103, cu aceia\u0219i oameni, cu care merg la saun\u0103 \u0219i stau la mas\u0103. \u0218i \u00een\u021belegem c\u0103, chiar dac\u0103 site-ul st\u0103 o zi, nu va fi nimic grav. <\/p>\n

Av\u00e2nd \u00een vedere informa\u021biile, avem o zi \u00eentreg\u0103 pentru a ridica aceast\u0103 poveste. \u00cencepem s\u0103 ne g\u00e2ndim la schema de rezervare. \u0218i alegem cea mai ideal\u0103 schem\u0103 de rezervare pentru acest exemplu: nu folosin rezervarea. Toat\u0103 aceast\u0103 activitate poate fi ini\u021biat\u0103 de oricine administrator \u00een treizeci de minute, cu pauze. S\u0103 instalezi un server web, s\u0103 a\u0219ezi fi\u0219ierele \u2014 gata. Totul va func\u021biona. Nu trebuie s\u0103 monitoriz\u0103m nimic, nu trebuie s\u0103 acord\u0103m o aten\u021bie deosebit\u0103. A\u0219adar, concluzia din exemplul num\u0103rul unu este destul de evident\u0103: serviciile care nu necesit\u0103 rezervare \u2014 nu trebuie rezervate.<\/p>\n

\"Failover:
\n<\/p>\n

Exemplul num\u0103rul doi<\/h4>\n

\nBlogul companiei: speciali\u0219tii scriu acolo \u0219tiri, cum am participat la o expozi\u021bie sau cum am lansat un nou produs \u0219i a\u0219a mai departe. S\u0103 presupunem c\u0103 este un PHP standard cu WordPress, o baz\u0103 de date mic\u0103 \u0219i pu\u021bin\u0103 static\u0103. \u00cen minte, desigur, \u00eemi vine din nou g\u00e2ndul c\u0103 nu ar trebui s\u0103 st\u0103m deloc - \u201enu mai mult de cinci minute!\u201d, tot acest gen de lucru. Dar haide\u021bi s\u0103 ne g\u00e2ndim mai departe. Ce face acest blog? Atrag vizitatori din Yandex, din Google prin diferite c\u0103ut\u0103ri organice. Minunat. \u0218i v\u00e2nz\u0103rile sunt cumva legate de acesta? O revela\u021bie: nu prea. Traficul publicitar merge pe site-ul principal, care este pe alt server. \u00cencepem s\u0103 ne g\u00e2ndim la schema de rezervare a blogului. Ideal ar fi s\u0103 putem s\u0103-l ridic\u0103m \u00een c\u00e2teva ore, \u0219i ar fi bine s\u0103 ne preg\u0103tim pentru asta. O idee rezonabil\u0103 ar fi s\u0103 lu\u0103m un server din alt centru de date, s\u0103 configur\u0103m mediu, adic\u0103 server web, PHP, WordPress, MySQL \u0219i s\u0103 \u00eel l\u0103s\u0103m inactiv. Atunci c\u00e2nd realiz\u0103m c\u0103 totul s-a stricat, trebuie s\u0103 facem dou\u0103 lucruri - s\u0103 restaur\u0103m un dump MySQL de 50 de metri, care se va face \u00een mai pu\u021bin de un minut, \u0219i s\u0103 restaur\u0103m un anumit num\u0103r de imagini din backup. De asemenea, nu este nimic complicat acolo. Astfel, \u00een jum\u0103tate de or\u0103 totul este repus \u00een func\u021biune. F\u0103r\u0103 replic\u0103ri sau, Doamne fere\u0219te, failover automat. Concluzia: ceea ce putem restaura rapid din backup nu trebuie rezervat. <\/p>\n

\"Failover:
\n<\/p>\n

Exemplul num\u0103rul trei, mai complicat<\/h4>\n

\nMagazin online. PHP cu open heart pu\u021bin modificat, MySQL cu o baz\u0103 de date solid\u0103. Destul de mult con\u021binut static (deoarece \u00eentr-un magazin online sunt imagini HD frumoase \u0219i tot felul de alte lucruri), Redis pentru sesiuni \u0219i Elasticsearch pentru c\u0103utare. \u00cencepem s\u0103 ne g\u00e2ndim la timpul de nefunc\u021bionare. Aici, desigur, e clar c\u0103 un magazin online nu poate s\u0103 fie offline o zi f\u0103r\u0103 consecin\u021be. Cu c\u00e2t st\u0103 mai mult offline, cu at\u00e2t pierdem mai mult. Trebuie s\u0103 ne gr\u0103bim. \u0218i c\u00e2t de mult? Cred c\u0103 dac\u0103 st\u0103m o or\u0103 offline, nimeni nu va \u00eennebuni. Da, vom pierde ceva, dar dac\u0103 ne aglomer\u0103m, va fi doar mai r\u0103u. Stabilim un plan pentru timpul de nefunc\u021bionare tolerabil \u00eentr-o or\u0103.<\/p>\n

Cum putem rezerva totul? O ma\u015fin\u0103 este absolut necesar\u0103: o or\u0103 de timp este destul de pu\u0163in. Mysql: aici deja avem nevoie de replicare, replicare live, deoarece \u00eentr-o or\u0103 100 GB \u00een dump, cel mai probabil, nu se va \u00eenc\u0103rca. Statica, pozele: din nou, \u00eentr-o or\u0103 500 GB poate s\u0103 nu reu\u015feasc\u0103 s\u0103 fie preluat\u0103. A\u015fadar, ar fi mai bine s\u0103 copiem imediat imaginile. Redis: aici devine mai interesant. \u00cen Redis se afl\u0103 sesiunile \u2014 nu putem pur \u0219i simplu s\u0103-l ignor\u0103m. Pentru c\u0103 nu ar fi foarte bine: to\u0163i utilizatorii s-ar deconecta, co\u015furile ar fi goale \u015fi a\u015fa mai departe. Oamenii ar fi nevoi\u0163i s\u0103 introduc\u0103 din nou login-ul \u015fi parola, iar mul\u0163i ar putea p\u0103r\u0103si procesul f\u0103r\u0103 a finaliza achizi\u0163ia. Din nou, conversia ar sc\u0103dea. Pe de alt\u0103 parte, Redis este exact la zi, cu ultimii utilizatori conecta\u0163i, probabil c\u0103 nu este necesar. \u015ei un bun compromis ar fi s\u0103 lu\u0103m Redis \u015fi s\u0103-l restaur\u0103m din backup, cel de ieri, sau, dac\u0103 \u00eel ave\u0163i creat \u00een fiecare or\u0103, din backup-ul de acum o or\u0103. Din fericire, restaurarea lui din backup este doar copierea unui fi\u015fier. Iar cea mai interesant\u0103 poveste este Elasticsearch. Cine a ridicat vreodat\u0103 replicarea MySQL? Cine a ridicat vreodat\u0103 replicarea Elasticsearch? \u015ei la cine a func\u0163ionat bine dup\u0103 aceea? La ce m\u0103 refer: vedem \u00een sistemul nostru o anumit\u0103 entitate. Ea pare a fi util\u0103 \u2014 dar este complex\u0103.
\nEste complex \u00een sensul c\u0103 colegii no\u0219tri ingineri nu au experien\u021b\u0103 de lucru cu ea. Fie c\u0103 au avut o experien\u021b\u0103 negativ\u0103, fie c\u0103 \u00een\u021belegem c\u0103, deocamdat\u0103, aceasta este o tehnologie relativ nou\u0103 cu nuan\u021be sau neclarit\u0103\u021bi. Ne g\u00e2ndim... Doamne, elasticul e, de asemenea, foarte mare, nu-i a\u0219a? Recupereaz\u0103-l din backup dureaz\u0103 mult, ce s\u0103 facem? \u00cen\u021belegem c\u0103 elastic este folosit pentru c\u0103utare \u00een cazul nostru. \u0218i cum \u00ee\u0219i vinde magazinul nostru online produsele? Mergem la marketeri, \u00eentreb\u0103m, de unde vin oamenii? Ei r\u0103spund: \u201e90% vin din Yandex.Market direct pe pagina produsului\u201d. \u0218i fie cump\u0103r\u0103, fie nu. Prin urmare, c\u0103utarea este necesar\u0103 pentru 10% dintre utilizatori. \u0218i a men\u021bine replicarea elasticului, \u00een special \u00eentre diferite centre de date din diferite zone, vine cu multe nuan\u021be. Care este solu\u021bia? Lu\u0103m elastic pe o platform\u0103 rezervat\u0103 \u0219i nu facem nimic cu el. Dac\u0103 lucrurile se vor prelungi, \u00eel vom ridica la un moment dat, poate, dar nu este sigur. \u00cen esen\u021b\u0103, concluzia r\u0103m\u00e2ne aceea\u0219i: serviciile care nu influen\u021beaz\u0103 banii, din nou, nu le rezerv\u0103m. Ca schema s\u0103 r\u0103m\u00e2n\u0103 mai simpl\u0103.<\/p>\n

\"Failover:
\n<\/p>\n

Exemplul num\u0103rul patru, chiar mai complicat<\/h4>\n

\nIntegrator: v\u00e2nz\u0103ri de flori, chemarea de taxiuri, v\u00e2nzarea de bunuri, \u00een general, orice. O afacere serioas\u0103 care func\u021bioneaz\u0103 24\/7 pentru un num\u0103r mare de utilizatori. Cu un stiv\u0103 interesant\u0103, unde exist\u0103 baze interesante, solu\u021bii, o sarcin\u0103 mare \u0219i, cel mai important, dac\u0103 r\u0103m\u00e2ne nefunc\u021bional\u0103 mai mult de 5 minute, este o problem\u0103. Nu doar din cauza c\u0103 oamenii nu vor cump\u0103ra, ci pentru c\u0103 vor observa c\u0103 acest lucru nu func\u021bioneaz\u0103, se vor dezam\u0103gi \u0219i s-ar putea s\u0103 nu mai revin\u0103 deloc. <\/p>\n

Bine. Cinci minute. Ce facem cu asta? \u00cen acest caz, ne comport\u0103m ca ni\u0219te adul\u021bi, investim bani pentru a construi o platform\u0103 de rezerv\u0103 adev\u0103rat\u0103, cu replicarea tuturor \u0219i a tuturor, \u0219i poate chiar automatiz\u0103m la maxim comutarea pe aceast\u0103 platform\u0103. \u0218i, pe l\u00e2ng\u0103 aceasta, nu trebuie s\u0103 uit\u0103m s\u0103 facem un lucru important: s\u0103 redact\u0103m un regulament de comutare. Regulamentul, chiar dac\u0103 ave\u021bi totul automatizat, poate fi foarte simplu. De tipul \u201elansa\u021bi acest scenariu ansible\u201d, \u201ebifa\u021bi aceast\u0103 op\u021biune \u00een Route 53\u201d \u0219i a\u0219a mai departe - dar trebuie s\u0103 existe o list\u0103 exact\u0103 de ac\u021biuni. <\/p>\n

\u0218i totul pare clar. Comutarea replic\u0103rii este o sarcin\u0103 trivial\u0103, fie se va comuta singur\u0103. Rescrierea numelui de domeniu \u00een DNS face parte din aceea\u0219i categorie. Problema este c\u0103, atunci c\u00e2nd un astfel de proiect e\u0219ueaz\u0103, panic\u0103 \u00eencepe s\u0103 domneasc\u0103, \u0219i chiar cei mai experimenta\u021bi administratori pot fi afecta\u021bi. F\u0103r\u0103 o instruc\u021biune clar\u0103 \u201edeschide terminalul, intr\u0103 aici, adresa serverului nostru este \u00een continuare aceasta\u201d, este greu de respectat termenul de 5 minute alocat pentru recuperare. Mai mult, atunci c\u00e2nd folosim acest regulament, este u\u0219or s\u0103 \u00eenregistr\u0103m anumite modific\u0103ri \u00een infrastructur\u0103, de exemplu, \u0219i s\u0103 ajust\u0103m regulamentul corespunz\u0103tor.
\nDar, dac\u0103 sistemul de rezervare este foarte complex \u0219i, la un moment dat, am f\u0103cut o gre\u0219eal\u0103, putem afecta \u0219i platforma noastr\u0103 de rezerv\u0103, iar datele se pot transforma \u00eentr-o dovleac\u0103 pe ambele platforme \u2014 aceasta ar fi o situa\u021bie cu adev\u0103rat trist\u0103. <\/p>\n

\"Failover:
\n<\/p>\n

Exemplul num\u0103rul cinci, hardcore complet.<\/h4>\n

\nUn serviciu interna\u021bional cu sute de milioane de utilizatori din \u00eentreaga lume. Toate fusurile orare, de care exist\u0103, highload la maximum, nu se poate permite s\u0103 fie indisponibil. O minut\u0103 \u2014 \u0219i va fi trist. Ce s\u0103 facem? S\u0103 rezerv\u0103m, din nou, la maximum. Am realizat tot ce am spus \u00een exemplul anterior \u0219i chiar mai mult. O lume ideal\u0103, iar infrastructura noastr\u0103 \u2014 este conform tuturor conceptelor de DevOps IaaC. Adic\u0103 totul este \u00een git, iar tu doar apesi butonul. <\/p>\n

Ce lipse\u0219te? Un lucru \u2014 exerci\u021biile. F\u0103r\u0103 ele, nu se poate. Pare c\u0103 totul este perfect, totul este sub control. Apas\u0103 butonul \u0219i totul se \u00eent\u00e2mpl\u0103. Chiar dac\u0103 ar fi a\u0219a \u2014 \u0219i \u0219tim c\u0103 a\u0219a nu se \u00eent\u00e2mpl\u0103 \u2014 sistemul nostru interac\u021bioneaz\u0103 cu anumite alte sisteme. De exemplu, este DNS-ul de la Route 53, S3 storage, integrarea cu anumite API-uri. Nu putem prevedea totul \u00een acest experiment teoretic. \u0218i p\u00e2n\u0103 nu tragem efectiv \u00eentrerup\u0103torul \u2014 nu vom \u0219ti dac\u0103 va func\u021biona sau nu. <\/p>\n

\"Failover:
\n
\nCam at\u00e2t. Nu fi\u021bi lene\u0219i \u0219i nu exagera\u021bi. \u0218i s\u0103 fie cu voi uptime-ul!
\n
Sursa: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a. \u0418 C\u0422\u041e \u0442\u043e\u0436\u0435. \u0422\u0435\u043c \u0442\u044f\u0436\u0435\u043b\u0435\u0435 \u0442\u0435\u043c, \u043a\u0442\u043e \u043e\u0441\u0442\u0430\u0451\u0442\u0441\u044f \u043d\u0430 \u043f\u043e\u0441\u0442\u0443, \u043d\u043e \u0441\u0435\u0439\u0447\u0430\u0441 \u043d\u0435 \u043e\u0431 \u044d\u0442\u043e\u043c: \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043b\u0435\u0442\u043e \u2014 \u043b\u0443\u0447\u0448\u0438\u0439 \u043f\u0435\u0440\u0438\u043e\u0434 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u0442\u043e\u0440\u043e\u043f\u044f\u0441\u044c \u043e\u0431\u0434\u0443\u043c\u0430\u0442\u044c \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0443\u044e \u0441\u0445\u0435\u043c\u0443 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27235,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36393","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Failover: ne distruge perfec\u021bionismul \u0219i\u2026 lene | ProHoster","description":"Vara, tradi\u021bional, scade at\u00e2t activitatea de cump\u0103rare, c\u00e2t \u0219i intensitatea modific\u0103rii infrastructurii proiectelor web, ne spune C\u0103pitanul Evident. Pur \u0219i simplu, pentru c\u0103 chiar \u0219i IT-i\u0219tii, se \u00eent\u00e2mpl\u0103, merg \u00een vacan\u021b\u0103.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Failover: \u043d\u0430\u0441 \u0433\u0443\u0431\u0438\u0442 \u043f\u0435\u0440\u0444\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0437\u043c \u0438\u2026 \u043b\u0435\u043d\u044c | ProHoster","og:description":"\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:11:24+00:00","article:modified_time":"2019-10-31T19:11:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36393","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 03:07:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:45:36","updated":"2026-01-22 03:07:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}