{"id":35092,"date":"2019-10-31T22:02:18","date_gmt":"2019-10-31T19:02:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim\/"},"modified":"2019-10-31T22:02:18","modified_gmt":"2019-10-31T19:02:18","slug":"bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","title":{"rendered":"\u201eBitrix24\u201d: \u201eCe este ridicat rapid nu se consider\u0103 c\u0103zut\u201d","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00cen prezent, serviciul \u201eBitrix24\u201d nu dispune de sute de gigabi\u021bi de trafic \u0219i nu are un parc imens de servere (de\u0219i exist\u0103, bine\u00een\u021beles, \u0219i un num\u0103r considerabil). \u00cens\u0103 pentru mul\u021bi clien\u021bi, el reprezint\u0103 principalul instrument de lucru din companie, fiind o aplica\u021bie cu adev\u0103rat business-critical. Prin urmare, c\u0103derea - nu se poate \u00eent\u00e2mpla. \u0218i ce dac\u0103, totu\u0219i, a avut loc o c\u0103dere, dar serviciul a \u201e\u00eenviat\u201d at\u00e2t de repede \u00eenc\u00e2t nimeni nu a observat? \u0218i cum se reu\u0219e\u0219te implementarea failover-ului f\u0103r\u0103 a afecta calitatea serviciului \u0219i num\u0103rul clien\u021bilor? Alexander Demidov, directorul diviziei de servicii cloud \u201eBitrix24\u201d, a discutat pentru blogul nostru despre cum sistemul de rezervare a evoluat \u00een cei 7 ani de existen\u021b\u0103 a produsului.<\/p>\n

\"\u201eBitrix24\u201d:
\n<\/a><\/noindex>
\n\u201e\u00cen format SaaS am lansat \u201eBitrix24\u201d acum 7 ani. Poate cea mai mare dificultate a fost urm\u0103toarea: \u00eenainte de lansarea public\u0103 \u00een acest format, produsul exista doar ca o solu\u021bie de tip cutie. Clien\u021bii o cump\u0103rau de la noi, o instalau pe serverele lor, creau un portal corporativ - o solu\u021bie comun\u0103 pentru comunicarea angaja\u021bilor, stocarea fi\u0219ierelor, gestionarea sarcinilor, CRM, toate acestea. \u0218i p\u00e2n\u0103 \u00een 2012 am decis c\u0103 vrem s\u0103 lans\u0103m asta ca SaaS, administr\u00e2nd \u00een mod autonom, asigur\u00e2nd redundan\u021ba \u0219i fiabilitatea. Am acumulat experien\u021b\u0103 \u00een proces, pentru c\u0103 p\u00e2n\u0103 atunci nu o aveam - eram doar produc\u0103tori de software, nu furnizori de servicii. <\/p>\n

C\u00e2nd am lansat serviciul, \u00een\u021belegeam c\u0103 cel mai important este s\u0103 asigur\u0103m redundan\u021ba, fiabilitatea \u0219i disponibilitatea constant\u0103 a serviciului, pentru c\u0103 dac\u0103 ai un simplu site obi\u0219nuit, un magazin, de exemplu, \u0219i acesta se blocheaz\u0103 timp de o or\u0103 - suferi doar tu, pierzi comenzi, pierzi clien\u021bi, dar pentru clien\u021bii t\u0103i - pentru ei nu este foarte critic. Desigur, se sup\u0103r\u0103, dar merg \u0219i cump\u0103r\u0103 de pe alt site. Dar dac\u0103 este o aplica\u021bie \u00een care depinde toat\u0103 activitatea din cadrul companiei, comunica\u021biile, solu\u021biile, cel mai important este s\u0103 c\u00e2\u0219tigi \u00eencrederea utilizatorilor, adic\u0103 s\u0103 nu-i dezam\u0103ge\u0219ti \u0219i s\u0103 nu cazi. Pentru c\u0103 \u00eentreaga activitate poate fi oprit\u0103 dac\u0103 ceva din interior nu va func\u021biona.<\/p>\n

Bitrix24 ca SaaS<\/h4>\n

\nPrimul prototip l-am adunat cu un an \u00eenainte de lansarea public\u0103, \u00een 2011. L-am reunit \u00een aproximativ o s\u0103pt\u0103m\u00e2n\u0103, l-am privit, l-am rotit \u2014 era chiar func\u021bional. Adic\u0103 se putea accesa un formular, introduce numele portalului, se desf\u0103\u0219ura un nou portal, se crea o baz\u0103 de utilizatori. Ne-am uitat la el, am evaluat produsul \u00een principiu, l-am \u00eenchis \u0219i am continuat s\u0103 lucr\u0103m la el un \u00eentreg an. Pentru c\u0103 aveam o sarcin\u0103 mare: nu voiam s\u0103 facem dou\u0103 baze de cod diferite, nu voiam s\u0103 suport\u0103m un produs cutie separat, solu\u021bii cloud separate \u2014 voiam s\u0103 facem totul \u00een cadrul unui singur cod. <\/p>\n

\"\u201eBitrix24\u201d:
\n
\nUn aplica\u021bie web tipic\u0103 la acel moment era un server pe care rula un cod php, o baz\u0103 de date mysql, fi\u0219ierele se \u00eenc\u0103rcau, documentele, imaginile erau plasate \u00een folderul upload \u2013 \u0219i asta era tot. Din p\u0103cate, nu era posibil s\u0103 lans\u0103m un serviciu web critic rezistent pe acest lucru. Acolo, cache-ul distribuit nu este suportat, replicarea bazelor de date nu este suportat\u0103. <\/p>\n

Am formulat cerin\u021bele: capacitatea de a fi g\u0103zduit \u00een loca\u021bii diferite, suport pentru replicare, ideal ar fi s\u0103 fie g\u0103zduit \u00een centre de date geografic distribuite. S\u0103 separ\u0103m logica produsului \u0219i, propriu-zis, stocarea datelor. S\u0103 putem scala dinamic \u00een func\u021bie de sarcin\u0103, s\u0103 externaliz\u0103m complet staticul. Din aceste considera\u021bii s-au format, de fapt, cerin\u021bele pentru produsul pe care l-am dezvoltat pe parcursul unui an. \u00cen acest timp, \u00een platforma care a rezultat unitar \u2014 pentru solu\u021bii cutie, pentru propriul nostru serviciu \u2014 am realizat suportul pentru acele lucruri de care aveam nevoie. Suport pentru replicarea mysql la nivelul produsului: adic\u0103 dezvoltatorul care scrie cod \u2014 nu se g\u00e2nde\u0219te la modul \u00een care vor fi distribuite solicit\u0103rile sale, el folose\u0219te api-ul nostru, iar noi \u0219tim s\u0103 distribuim corect solicit\u0103rile de scriere \u0219i citire \u00eentre mastere \u0219i slave. <\/p>\n

Am realizat suportul la nivelul produsului pentru diferite stoc\u0103ri de obiecte cloud: google storage, amazon s3, \u2014 plus, suport pentru open stack swift. De aceea, a fost convenabil at\u00e2t pentru noi ca serviciu, c\u00e2t \u0219i pentru dezvoltatorii care lucreaz\u0103 cu solu\u021bia cutie: dac\u0103 ei folosesc pur \u0219i simplu api-ul nostru pentru a lucra, nu se g\u00e2ndesc la unde se va salva fi\u0219ierul, local pe sistemul de fi\u0219iere sau va ajunge \u00een stocarea de obiecte.<\/p>\n

\u00cen cele din urm\u0103, am decis imediat c\u0103 ne vom rezerva la nivelul \u00eentregului centru de date. \u00cen 2012, am \u00eenceput complet \u00een Amazon AWS, deoarece aveam deja experien\u021b\u0103 cu aceast\u0103 platform\u0103 - propriul nostru site era g\u0103zduit acolo. Ne-a atras faptul c\u0103 \u00een fiecare regiune din Amazon exist\u0103 mai multe zone de disponibilitate - practic, (\u00een terminologia lor) mai multe centre de date care sunt mai mult sau mai pu\u021bin independente unul de cel\u0103lalt \u0219i care ne permit s\u0103 ne rezerv\u0103m la nivelul \u00eentregului centru de date: dac\u0103 acesta se defecteaz\u0103, bazele sunt replicate master-master, serverele aplica\u021biilor web sunt rezervate, iar stocarea static\u0103 este transferat\u0103 \u00een stocarea obiectelor s3. \u00cenc\u0103rc\u0103tura este distribuit\u0103 - la acea vreme cu elb-ul amazonian, dar pu\u021bin mai t\u00e2rziu am ajuns la propriile noastre distribuitoare, deoarece aveam nevoie de o logic\u0103 mai complex\u0103. <\/p>\n

Ce am dorit - am ob\u021binut...<\/h4>\n

\nToate lucrurile de baz\u0103 pe care voiam s\u0103 le asigur\u0103m - toleran\u021ba la erori a serverelor, aplica\u021biilor web, bazelor de date - totul a func\u021bionat bine. Cel mai simplu scenariu: dac\u0103 unul dintre aplica\u021biile noastre web se defecteaz\u0103, atunci aici totul este simplu - ele sunt eliminate din balansare. <\/p>\n

\"\u201eBitrix24\u201d:
\n
\nMa\u0219inile defecte erau marcate automat ca unhealthy de c\u0103tre distribuitor (pe atunci era elb-ul amazonian), iar distribu\u021bia \u00eenc\u0103rc\u0103turii pe acestea era oprit\u0103. Func\u021biona auto-scaling-ul amazonian: c\u00e2nd \u00eenc\u0103rc\u0103tura cre\u0219tea, noi ma\u0219ini erau ad\u0103ugate \u00een grupul de auto-scaling, iar \u00eenc\u0103rc\u0103tura era distribuit\u0103 pe noile ma\u0219ini - totul era \u00een regul\u0103. Cu distribuitoarele noastre, logica este aproximativ aceea\u0219i: dac\u0103 se \u00eent\u00e2mpl\u0103 ceva cu serverul aplica\u021biilor, elimin\u0103m cererile de pe el, scoatem aceste ma\u0219ini, pornim altele noi \u0219i continu\u0103m s\u0103 lucr\u0103m. Schema s-a schimbat pu\u021bin de-a lungul anilor, dar continu\u0103 s\u0103 func\u021bioneze: este simpl\u0103, clar\u0103 \u0219i nu avem nicio dificultate \u00een acest sens. <\/p>\n

Lucr\u0103m la nivel mondial, iar v\u00e2rful de \u00eenc\u0103rcare la clien\u021bi este absolut diferit, iar, pe bun\u0103 dreptate, trebuie s\u0103 avem posibilitatea de a efectua anumite lucr\u0103ri de \u00eentre\u021binere cu orice component\u0103 a sistemului nostru \u00een orice moment - f\u0103r\u0103 ca clien\u021bii s\u0103 observe. De aceea, avem posibilitatea de a dezactiva baza de date, redistribuind \u00eenc\u0103rc\u0103tura pe al doilea centru de date. <\/p>\n

Cum func\u021bioneaz\u0103 totul? \u2014 Direc\u021bion\u0103m traficul c\u0103tre centrul de date func\u021bional \u2014 dac\u0103 este o avarie la centrul de date, \u00eel direc\u021bion\u0103m complet, iar dac\u0103 avem lucr\u0103ri programate pe o anumit\u0103 baz\u0103, redirec\u021bion\u0103m o parte din traficul care deserve\u0219te acei clien\u021bi c\u0103tre cel de-al doilea centru de date, \u00een timp ce repicarea este suspendat\u0103. Dac\u0103 avem nevoie de noi servere pentru aplica\u021bii web din cauza cre\u0219terii \u00eenc\u0103rc\u0103rii pe al doilea centru de date, acestea pornesc automat. Termin\u0103m lucr\u0103rile, repicarea se restabile\u0219te \u0219i redirec\u021bion\u0103m \u00eentreaga \u00eenc\u0103rcare \u00eenapoi. Dac\u0103 trebuie s\u0103 efectu\u0103m lucr\u0103ri simultane \u00een al doilea DC, de exemplu, s\u0103 instal\u0103m actualiz\u0103ri de sistem sau s\u0103 modific\u0103m set\u0103rile \u00een a doua baz\u0103 de date, \u00een general, repet\u0103m exact acelea\u0219i pa\u0219i, doar c\u0103 \u00een cealalt\u0103 direc\u021bie. Iar dac\u0103 este o avarie, proced\u0103m simplu: \u00een sistemul de monitorizare utiliz\u0103m mecanismul event-handlers. Dac\u0103 se activeaz\u0103 mai multe verific\u0103ri \u0219i statutul trece la critic, se activeaz\u0103 acest handler, un proces care poate executa o logic\u0103 specific\u0103. Avem specificat pentru fiecare baz\u0103 care server este pentru ea failover \u0219i unde trebuie redirec\u021bionat traficul \u00een caz de inaccesibilitate. Din motive istorice, utiliz\u0103m \u00eentr-o form\u0103 sau alta nagios sau unele dintre fork-urile sale. \u00cen principiu, astfel de mecanisme exist\u0103 practic \u00een orice sistem de monitorizare, nu folosim \u00eenc\u0103 ceva mai complex, dar este posibil s\u0103 o facem c\u00e2ndva. \u00cen prezent, monitorizarea reac\u021bioneaz\u0103 la inaccesibilitate \u0219i are capacitatea de a redirec\u021biona ceva.<\/p>\n

Am rezervat totul?<\/h4>\n

\nAvem mul\u021bi clien\u021bi din SUA, mul\u021bi clien\u021bi din Europa, mul\u021bi clien\u021bi care sunt mai aproape de Est \u2014 Japonia, Singapore \u0219i a\u0219a mai departe. Desigur, o mare parte din clien\u021bi se afl\u0103 \u00een Rusia. Asta \u00eenseamn\u0103 c\u0103 activitatea nu se desf\u0103\u0219oar\u0103 doar \u00eentr-o singur\u0103 regiune. Utilizatorii doresc timpi de r\u0103spuns rapizi, exist\u0103 cerin\u021be de conformitate cu diverse legi locale, iar \u00een fiecare regiune rezerv\u0103m dou\u0103 centre de date, plus exist\u0103 servicii suplimentare care, din nou, sunt convenabile de plasat \u00een cadrul acelea\u0219i regiuni \u2014 pentru clien\u021bii care opereaz\u0103 \u00een acea regiune. Procesorii REST, serverele de autorizare, sunt mai pu\u021bin critici pentru func\u021bionarea general\u0103 a clientului, prin urmare se poate comuta cu o \u00eent\u00e2rziere acceptabil\u0103, dar nu vrem s\u0103 invent\u0103m roata, cum s\u0103-i monitoriz\u0103m \u0219i ce s\u0103 facem cu ei. De aceea, \u00een m\u0103sura posibilit\u0103\u021bilor, \u00eencerc\u0103m s\u0103 folosim solu\u021biile existente, nu s\u0103 ne dezvolt\u0103m competen\u021be \u00een produse suplimentare. \u0218i uneori folosim pur \u0219i simplu comutarea la nivel DNS, iar disponibilitatea serviciului o determin\u0103m prin acela\u0219i DNS. \u00cen Amazon exist\u0103 serviciul Route 53, dar acesta nu este doar un DNS \u00een care po\u021bi introduce \u00eenregistr\u0103ri \u0219i at\u00e2t \u2014 este mult mai flexibil \u0219i convenabil. Prin intermediul acestuia po\u021bi construi servicii geo-distribuite cu geoloca\u021bii, c\u00e2nd cu ajutorul s\u0103u determini de unde a venit clientul \u0219i \u00eei oferi acele \u00eenregistr\u0103ri \u2014 cu ajutorul acestuia po\u021bi construi arhitecturi de failover. Acelea\u0219i verific\u0103ri de s\u0103n\u0103tate se configureaz\u0103 \u00een Route 53, setezi endpoint-urile care sunt monitorizate, setezi metricile, stabile\u0219ti ce protocoale s\u0103 folose\u0219ti pentru a determina \u201edisponibilitatea\u201d serviciului \u2014 tcp, http, https; setezi frecven\u021ba verific\u0103rilor care determin\u0103 dac\u0103 serviciul este activ sau nu. \u0218i \u00een registrarul DNS specifici ce va fi principal, ce va fi secundar, unde s\u0103 comu\u021bi dac\u0103 se activeaz\u0103 verificarea de s\u0103n\u0103tate \u00een Route 53. Toate acestea pot fi realizate cu alte instrumente, dar avantajul este c\u0103, odat\u0103 configurate, nu mai trebuie s\u0103 ne g\u00e2ndim la cum se fac verific\u0103rile, cum se face comutarea: totul func\u021bioneaz\u0103 de la sine.<\/p>\n

Primul \"dar\"<\/b>: Cum \u0219i cu ce s\u0103 rezerv\u0103m \u00eensu\u0219i route 53? Cine \u0219tie, poate se \u00eent\u00e2mpl\u0103 ceva cu el? Din fericire, nu am avut niciodat\u0103 de-a face cu asta, dar, din nou, urmeaz\u0103 s\u0103 povestesc de ce ne-am g\u00e2ndit c\u0103 trebuie totu\u0219i s\u0103 facem rezervare. Aici ne preg\u0103tim din timp. De c\u00e2teva ori pe zi, facem o exportare complet\u0103 a tuturor zonelor pe care le avem \u00een route 53. API-ul Amazon permite s\u0103 le ob\u021binem \u00een JSON, iar noi avem c\u00e2teva servere de rezerv\u0103 pe care le convertim, le export\u0103m sub form\u0103 de configura\u021bii \u0219i, s\u0103 zicem a\u0219a, avem o configura\u021bie de backup. \u00cen caz de urgen\u021b\u0103, putem s\u0103 o desf\u0103\u0219ur\u0103m rapid manual, f\u0103r\u0103 a pierde datele set\u0103rilor DNS.<\/p>\n

Al doilea \u201edar\u201d<\/b>: ce \u00een aceast\u0103 imagine nu este \u00eenc\u0103 rezervat? \u00cenclinatorul de sarcin\u0103! Distribu\u021bia clien\u021bilor pe regiuni este foarte simpl\u0103. Avem domenii bitrix24.ru, bitrix24.com, .de \u2014 \u00een prezent sunt vreo 13 diferite, care func\u021bioneaz\u0103 pe cele mai variate zone. Am ajuns la urm\u0103toarea concluzie: \u00een fiecare regiune \u2014 propriile \u00eenclinate de sarcin\u0103. Astfel, este mai convenabil s\u0103 distribuim pe regiuni, \u00een func\u021bie de \u00eenc\u0103rc\u0103tura de v\u00e2rf din re\u021bea. Dac\u0103 este o defec\u021biune la nivelul unui singur \u00eenclinator de sarcin\u0103, acesta este pur \u0219i simplu scos din func\u021biune \u0219i eliminat din DNS. Dac\u0103 apare o problem\u0103 cu un grup de \u00eenclinate, acestea sunt rezervate pe alte platforme, iar comutarea \u00eentre ele se face cu ajutorul acelea\u0219i route53, deoarece, datorit\u0103 unui TTL scurt, comutarea se realizeaz\u0103 maxim \u00een 2, 3, 5 minute. <\/p>\n

Al treilea \u201edar\u201d<\/b>: ce altceva nu este rezervat? S3, corect. C\u00e2nd stoc\u0103m fi\u0219ierele pe care le p\u0103str\u0103m pentru utilizatori \u00een S3, am crezut sincer c\u0103 este un sistem infailibil \u0219i c\u0103 nu trebuie s\u0103 facem rezerv\u0103ri. Dar istoria arat\u0103 c\u0103 lucrurile se desf\u0103\u0219oar\u0103 altfel. \u00cen general, Amazon descrie S3 ca un serviciu fundamental, deoarece Amazon \u00eensu\u0219i folose\u0219te S3 pentru stocarea imaginilor ma\u0219inilor, configura\u021biilor, imaginilor AMI, instantaneelor... \u0218i dac\u0103 S3 pic\u0103, a\u0219a cum s-a \u00eent\u00e2mplat odat\u0103 \u00een cei 7 ani \u00een care exploat\u0103m bitrix24, acesta trage dup\u0103 el o mul\u021bime de altele \u2014 indisponibilitatea pornirii ma\u0219inilor virtuale, defec\u021biuni \u00een func\u021bionarea API-ului \u0219i a\u0219a mai departe. <\/p>\n

\u0218i S3 poate s\u0103 cad\u0103 \u2014 a\u0219a s-a \u00eent\u00e2mplat odat\u0103. De aceea am ajuns la urm\u0103toarea schem\u0103: cu c\u00e2\u021biva ani \u00een urm\u0103, nu existau depozite publice de obiecte semnificative \u00een Rusia, \u0219i am considerat op\u021biunea de a face ceva propriu\u2026 Din fericire, nu am \u00eenceput s\u0103 facem acest lucru, pentru c\u0103 ne-am fi \u00eenfundat \u00een expertiza la care nu avem acces \u0219i cu siguran\u021b\u0103 am fi f\u0103cut o mul\u021bime de gre\u0219eli. Acum, depozitele compatibile cu S3 sunt disponibile de la Mail.ru, de la Yandex \u0219i de la un alt num\u0103r de furnizori. \u00cen cele din urm\u0103, am ajuns la concluzia c\u0103 vrem s\u0103 avem, \u00een primul r\u00e2nd, rezervare, iar \u00een al doilea r\u00e2nd, posibilitatea de a lucra cu copii locale. Pentru specificul regiunii ruse\u0219ti, folosim serviciul Mail.ru Hotbox, care este compatibil cu S3 prin API. Nu am avut nevoie de modific\u0103ri semnificative \u00een codul aplica\u021biei \u0219i am realizat urm\u0103torul mecanism: \u00een S3 exist\u0103 trigger-uri care se activeaz\u0103 la crearea\/\u0219tergerea obiectelor, iar Amazon are un astfel de serviciu, numit Lambda \u2014 acesta este un cod serverless care se va executa exact atunci c\u00e2nd sunt activate diverse trigger-uri.<\/p>\n

\"\u201eBitrix24\u201d:
\n
\nAm procedat foarte simplu: dac\u0103 se activeaz\u0103 un trigger, execut\u0103m codul care va copia obiectul \u00een depozitul Mail.ru. Pentru a putea s\u0103 activ\u0103m \u00een \u00eentregime lucrul cu copiile locale de date, avem nevoie \u0219i de sincronizare invers\u0103, astfel \u00eenc\u00e2t clien\u021bii care se afl\u0103 \u00een segmentul rusesc s\u0103 poat\u0103 lucra cu depozitul care le este mai aproape. Mail urmeaz\u0103 s\u0103 finalizeze trigger-urile \u00een depozitul s\u0103u \u2014 va fi posibil s\u0103 execut\u0103m sincronizarea invers\u0103 la nivel de infrastructur\u0103, deocamdat\u0103 facem acest lucru la nivelul propriului nostru cod. Dac\u0103 vedem c\u0103 un client a \u00eenc\u0103rcat un anumit fi\u0219ier, atunci noi, la nivel de cod, plas\u0103m un eveniment \u00een coad\u0103, \u00eel proces\u0103m \u0219i realiz\u0103m replicarea invers\u0103. Problema este c\u0103, dac\u0103 se desf\u0103\u0219oar\u0103 activit\u0103\u021bi cu obiectele noastre din afara produsului nostru, adic\u0103 cu anumite mijloace externe, nu vom lua \u00een considerare acest lucru. Prin urmare, a\u0219tept\u0103m p\u00e2n\u0103 la final, c\u00e2nd vor ap\u0103rea trigger-uri la nivelul depozitului, astfel \u00eenc\u00e2t, indiferent de locul de unde am executat codul, obiectul care ajunge la noi s\u0103 fie copiat \u00een cealalt\u0103 direc\u021bie. <\/p>\n

La nivel de cod, pentru fiecare client configur\u0103m ambele stoc\u0103ri: una este considerat\u0103 principal\u0103, iar cealalt\u0103 ca backup. Dac\u0103 totul merge bine, lucr\u0103m cu stocarea care ne este mai apropiat\u0103: adic\u0103 clien\u021bii no\u0219tri care sunt pe Amazon, ei lucreaz\u0103 cu S3, iar cei care lucreaz\u0103 \u00een Rusia, ei folosesc Hotbox. Dac\u0103 se activeaz\u0103 un semnal, atunci trebuie s\u0103 ne conect\u0103m la failover \u0219i s\u0103 mut\u0103m clien\u021bii pe o alt\u0103 stocare. Putem activa acest semnal independent pe regiuni \u0219i putem transfera \u00eentre ele. Practic, nu am utilizat \u00eenc\u0103 asta, dar am preconizat acest mecanism \u0219i credem c\u0103, la un moment dat, ne va fi necesar s\u0103 efectu\u0103m aceast\u0103 schimbare. A avut deja loc o dat\u0103. <\/p>\n

Oh, dar Amazonul v-a p\u0103r\u0103sit...<\/h4>\n

\n\u00cen aprilie acesta se \u00eemplinesc aniversarea \u00eenceputului bloc\u0103rilor Telegram \u00een Rusia. Cel mai afectat provider de acest lucru este Amazon. \u0218i, din p\u0103cate, companiile ruse\u0219ti care au lucrat la nivel global au avut mult de suferit. <\/p>\n

Dac\u0103 compania este global\u0103 \u0219i Rusia reprezint\u0103 pentru ea un segment foarte mic, 3-5% \u2014 \u00eentr-un fel sau altul, se pot sacrifica. <\/p>\n

Dac\u0103 este o companie pur ruseasc\u0103 \u2014 sunt sigur c\u0103 trebuie s\u0103 opereze local \u2014 pur \u0219i simplu utilizatorilor le va fi mai convenabil, mai confortabil, riscurile vor fi mai mici. <\/p>\n

\u0218i dac\u0103 este o companie care opereaz\u0103 la nivel global, \u0219i are aproximativ la fel de mul\u021bi clien\u021bi din Rusia c\u00e2t \u0219i din alte col\u021buri ale lumii? Conectivitatea segmentelor este important\u0103, \u0219i ele trebuie s\u0103 colaboreze \u00eentr-un fel sau altul. <\/p>\n

De asemenea, la sf\u00e2r\u0219itul lunii martie 2018, Roskomnadzor a trimis celor mai mari operatori o scrisoare, \u00een care anun\u021bau c\u0103 inten\u021bioneaz\u0103 s\u0103 blocheze c\u00e2teva milioane de ip-uri Amazon, pentru a bloca\u2026 aplica\u021bia de mesagerie Zello. Mul\u021bumim acestor provider-i \u2014 ei au distribuit cu succes scrisoarea, \u0219i a ap\u0103rut \u00een\u021belegerea c\u0103 conectivitatea cu Amazon ar putea fi afectat\u0103. A fost o vineri, am alergat \u00een panic\u0103 la colegii de la servers.ru, spun\u00e2nd: \u201ePrieteni, avem nevoie de c\u00e2teva servere care s\u0103 nu fie \u00een Rusia, nu \u00een Amazon, ci, de exemplu, undeva \u00een Amsterdam\u201d, pentru a avea posibilitatea de a pune acolo cel pu\u021bin cumva propriile vpn<\/a> \u0218i proxy pentru anumite endpoint-uri, asupra c\u0103rora nu putem influen\u021ba, de exemplu endpoint-urile aceluia\u0219i s3 \u2014 nu putem \u00eencerca s\u0103 deschidem un nou serviciu \u0219i s\u0103 ob\u021binem o alt\u0103 IP, trebuie s\u0103 ajungem acolo oricum. \u00cen c\u00e2teva zile am configurat ace\u0219ti serveri, i-am activat \u0219i, \u00een general, ne-am preg\u0103tit pentru momentul \u00eenceperii bloc\u0103rilor. Interesant este c\u0103 RKN, v\u0103z\u00e2nd agita\u021bia \u0219i panic\u0103, a spus: \u201eNu, acum nu vom bloca nimic\u201d. (Dar asta tocmai p\u00e2n\u0103 \u00een momentul c\u00e2nd au \u00eenceput s\u0103 blocheze Telegram.) Configur\u00e2nd modalit\u0103\u021bile de ocolire \u0219i \u00een\u021beleg\u00e2nd c\u0103 blocajul nu a fost aplicat, cu toate acestea, nu am \u00eenceput s\u0103 desfacem toate acestea. A\u0219a, pentru orice eventualitate. <\/p>\n

\"\u201eBitrix24\u201d:
\n
\n\u0218i astfel, \u00een 2019, tr\u0103im \u00een condi\u021bii de blocaje. Ieri noapte, am observat: aproape un milion de ip-uri continu\u0103 s\u0103 fie blocate. Adev\u0103rul este c\u0103 Amazon a fost deblocat aproape \u00een \u00eentregime, iar la v\u00e2rf s-au ajuns p\u00e2n\u0103 la 20 de milioane de adrese... \u00cen general, realitatea este c\u0103 conectivitatea, o conectivitate bun\u0103 \u2014 poate s\u0103 nu existe. Dintr-o dat\u0103. Poate s\u0103 nu existe din motive tehnice \u2014 incendii, excavatoare, toate cele. Sau, cum am v\u0103zut, din motive mai pu\u021bin tehnice. De aceea, cineva mare \u0219i puternic, cu propriile AS-uri, probabil, poate s\u0103 gestioneze acest proces prin alte metode, \u2014 direct connect \u0219i alte lucruri deja la nivel de l2. Dar \u00een varianta simpl\u0103, cum suntem noi sau al\u021bii mai mici, este bine s\u0103 avem, de precau\u021bie, rezerv\u0103ri la nivelul serverelor, \u00eenfiin\u021bate undeva altundeva, configurate dinainte cu vpn, proxy, cu posibilitatea de a schimba rapid configura\u021bia \u00een segmentele care sunt critice pentru conectivitate. Acest lucru ne-a fost de ajutor de mai multe ori, c\u00e2nd au \u00eenceput blocajele Amazon, am folosit prin ele exact traficul S3 \u00een cea mai proast\u0103 situa\u021bie, dar treptat totul s-a rezolvat.<\/p>\n

\u0218i cum se poate rezerva\u2026 un \u00eentreg furnizor?<\/h4>\n

\n\u00cen prezent, nu avem un scenariu pentru e\u0219ecul complet al Amazon. Avem un scenariu similar pentru Rusia. Ne-am g\u0103zduit \u00een Rusia la un furnizor care avea mai multe loca\u021bii. Acum un an, ne-am confruntat cu o problem\u0103: chiar dac\u0103 sunt dou\u0103 centre de date, pot exista probleme la nivelul configura\u021biei re\u021belei furnizorului care afecteaz\u0103 totu\u0219i ambele centre. Astfel, putem avea indisponibilitate \u00een ambele loca\u021bii. Desigur, a\u0219a s-a \u00eent\u00e2mplat. \u00cen cele din urm\u0103, am revizuit arhitectura intern\u0103. Nu s-a schimbat foarte mult, dar pentru Rusia avem acum dou\u0103 loca\u021bii, nu la un singur furnizor, ci la doi diferi\u021bi. Dac\u0103 unul dintre ei are o defec\u021biune, putem comuta pe cel\u0103lalt.<\/p>\n

Ipotez\u00e2nd, pentru Amazon, lu\u0103m \u00een considerare posibilitatea de a rezerva la un alt furnizor; poate Google, poate altcineva... Dar, p\u00e2n\u0103 acum, am observat \u00een practic\u0103 c\u0103, dac\u0103 au loc incidente la nivelul unei zone de disponibilitate Amazon, incidentele la nivel de \u00eentreaga regiune sunt destul de rare. Prin urmare, teoretic avem o idee despre ce am putea face cu rezervarea \u201eAmazon - nu Amazon\u201d, dar \u00een practic\u0103, deocamdat\u0103, nu exist\u0103. <\/p>\n

C\u00e2teva cuvinte despre automatizare<\/h4>\n

\nEste \u00eentotdeauna necesar\u0103 automatizarea? Aici este pertinent s\u0103 ne amintim de efectul Dunning-Kruger. Pe axa \u201ex\u201d avem cuno\u0219tin\u021bele \u0219i experien\u021ba pe care le acumul\u0103m, iar pe axa \u201ey\u201d \u2014 \u00eencrederea \u00een ac\u021biunile noastre. La \u00eenceput, nu \u0219tim nimic \u0219i nu suntem deloc \u00eencrez\u0103tori. Apoi, \u0219tim pu\u021bin \u0219i devenim mega-\u00eencrez\u0103tori \u2014 acesta este a\u0219a-zisul \u201ev\u00e2rf al prostiei\u201d, bine ilustrat de imaginea \u201eneputin\u021b\u0103 \u0219i curaj\u201d. Apoi, deja am \u00eenv\u0103\u021bat pu\u021bin \u0219i suntem preg\u0103ti\u021bi s\u0103 lupt\u0103m. Apoi, c\u0103lc\u0103m pe c\u00e2teva capcane serioase, ajungem \u00een valea disper\u0103rii, c\u00e2nd de\u0219i \u0219tim ceva, de fapt nu \u0219tim multe. Apoi, pe m\u0103sur\u0103 ce acumul\u0103m experien\u021b\u0103, devenim mai \u00eencrez\u0103tori.<\/p>\n

\"\u201eBitrix24\u201d:
\n
\nLogica noastr\u0103 cu privire la diversele comut\u0103ri automate \u00een cazul unor incidente este bine descris\u0103 prin acest grafic. Am \u00eenceput f\u0103r\u0103 s\u0103 \u0219tim nimic, aproape toate lucr\u0103rile erau efectuate manual. Apoi, am realizat c\u0103 putem s\u0103 automatiz\u0103m totul \u0219i s\u0103 dormim lini\u0219ti\u021bi. \u0218i apoi d\u0103m peste o mare problem\u0103: se activeaz\u0103 un false positive \u0219i comut\u0103m traficul dintr-o parte \u00een alta, c\u00e2nd, de fapt, nu ar fi trebuit s\u0103 facem asta. Drept urmare, se stric\u0103 replicarea sau altceva \u2014 iat\u0103 acea vale a disper\u0103rii. Apoi ajungem la concluzia c\u0103 trebuie s\u0103 ne raport\u0103m la toate cu \u00een\u021belepciune. Adic\u0103 are sens s\u0103 ne baz\u0103m pe automatizare, prev\u0103z\u00e2nd posibilitatea unui fals alarm\u0103. Dar! dac\u0103 consecin\u021bele pot fi devastatoare, atunci e mai bine s\u0103 l\u0103s\u0103m asta pe seama echipelor de urgen\u021b\u0103, inginerilor de serviciu, care se vor asigura, verific\u00e2nd c\u0103 exist\u0103 \u00eentr-adev\u0103r o avarie, \u0219i vor executa ac\u021biunile necesare manual\u2026<\/p>\n

Concluzie<\/h4>\n

\n\u00cen cei 7 ani, am parcurs drumul de la panic\u0103, atunci c\u00e2nd ceva pica, la \u00een\u021belegerea c\u0103 nu exist\u0103 probleme, ci doar sarcini care trebuie \u2014 \u0219i pot \u2014 fi rezolvate. C\u00e2nd construie\u0219ti un serviciu, prive\u0219te-l dintr-o perspectiv\u0103 de ansamblu, evalueaz\u0103 toate riscurile care pot ap\u0103rea. Dac\u0103 le vezi de la \u00eenceput, preconizeaz\u0103 \u00een avans redundan\u021ba \u0219i posibilitatea de a construi o infrastructur\u0103 rezistent\u0103 la defec\u021biuni, pentru c\u0103 orice punct care poate ie\u0219i din func\u021biune \u0219i poate duce la nefunc\u021bionalitatea serviciului \u2014 cu siguran\u021b\u0103 se va \u00eent\u00e2mpla. Chiar dac\u0103 \u021bi se pare c\u0103 anumite elemente ale infrastructurii nu se vor strica \u2014 precum s3 \u2014 \u021bine minte c\u0103 ele pot face acest lucru. \u0218i, m\u0103car teoretic, s\u0103 ai o idee despre ce vei face cu ele dac\u0103 ceva se va \u00eent\u00e2mpla. F\u0103-\u021bi un plan pentru gestionarea riscurilor. C\u00e2nd te g\u00e2nde\u0219ti s\u0103 automatizezi totul sau s\u0103 faci manual \u2014 evalueaz\u0103 riscurile: ce se va \u00eent\u00e2mpla dac\u0103 automatizarea \u00eencepe s\u0103 comute totul \u2014 va duce la o situa\u021bie \u0219i mai proast\u0103 comparativ cu o avarie? Poate c\u0103 trebuie s\u0103 existe un compromis rezonabil \u00eentre utilizarea automatiz\u0103rii \u0219i reac\u021bia inginerului de serviciu, care va evalua situa\u021bia real\u0103 \u0219i va decide dac\u0103 trebuie s\u0103 comute ceva imediat sau \u201eda, dar nu acum\u201d.<\/p>\n

Un compromis ra\u021bional \u00eentre perfec\u021bionism \u0219i resursele reale, timpul, banii pe care \u00eei pute\u021bi cheltui pentru schema pe care o ve\u021bi avea \u00een final.<\/p>\n

Acest text este o versiune extins\u0103 \u0219i \u00eembun\u0103t\u0103\u021bit\u0103 a raportului lui Alexandr Demidov de la conferin\u021b\u0103. Uptime ziua 4<\/a><\/noindex>.<\/i>
\n
Sursa: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","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\udd47\u201eBitrix24\u201d: \u201eCe este ridicat rapid nu se consider\u0103 c\u0103 a c\u0103zut\u201d | ProHoster","description":"P\u00e2n\u0103 \u00een prezent, serviciul \u201eBitrix24\u201d nu dispune de sute de gigabi\u021bi de trafic, nu are un parc imens de servere (de\u0219i exist\u0103 destule, bine\u00een\u021beles).","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","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\udd47\u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb: \u00ab\u0411\u044b\u0441\u0442\u0440\u043e \u043f\u043e\u0434\u043d\u044f\u0442\u043e\u0435 \u043d\u0435 \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u0443\u043f\u0430\u0432\u0448\u0438\u043c\u00bb | ProHoster","og:description":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e).","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","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:02:18+00:00","article:modified_time":"2019-10-31T19:02:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35092","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-02-04 14:51:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:10:27","updated":"2026-02-04 14:51: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\/35092","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=35092"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/35092\/revisions"}],"predecessor-version":[{"id":156668,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/35092\/revisions\/156668"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/26389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=35092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=35092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=35092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}