Danas servis Bitrix24 nema stotine gigabita saobraćaja, niti ima ogromnu flotu servera (iako, naravno, postoji dosta postojećih). Ali za mnoge klijente to je glavni alat za rad u kompaniji, prava je poslovno kritična aplikacija. Dakle, nema načina da padne. Šta ako se pad ipak dogodi, ali se servis „oporavi“ tako brzo da niko ništa nije primijetio? A kako je moguće implementirati failover bez gubitka kvaliteta rada i broja klijenata? Aleksandar Demidov, direktor cloud servisa u Bitrix24, govorio je za naš blog o tome kako je evoluirao sistem rezervacija tokom 7 godina postojanja proizvoda.
“Pokrenuli smo Bitrix24 kao SaaS prije 7 godina. Glavna poteškoća je vjerovatno bila sljedeća: prije nego što je javno lansiran kao SaaS, ovaj proizvod je jednostavno postojao u formatu rješenja u kutiji. Klijenti su ga kupili od nas, hostirali na svojim serverima, postavili korporativni portal - opće rješenje za komunikaciju zaposlenika, skladištenje datoteka, upravljanje zadacima, CRM, to je sve. I do 2012. odlučili smo da ga želimo pokrenuti kao SaaS, da ga sami administriramo, osiguravajući toleranciju grešaka i pouzdanost. Iskustvo smo sticali usput, jer ga do tada jednostavno nismo imali – bili smo samo proizvođači softvera, a ne pružaoci usluga.
Prilikom pokretanja servisa shvatili smo da je najvažnije osigurati toleranciju grešaka, pouzdanost i stalnu dostupnost servisa, jer ako imate običnu običnu web stranicu, prodavnicu, na primjer, i ona pada na vas i sjedi tamo za sat vremena, samo vi patite, gubite narudžbe, gubite klijente, ali za samog vašeg klijenta to nije kritično za njega. Bio je uznemiren, naravno, ali je otišao i kupio ga na drugom sajtu. A ako je ovo aplikacija na kojoj je vezan sav rad unutar kompanije, komunikacije, odluke, onda je najvažnije pridobiti povjerenje korisnika, odnosno ne iznevjeriti ih i ne pasti. Jer sav posao može stati ako nešto unutra ne radi.
Bitrix.24 kao SaaS
Sastavili smo prvi prototip godinu dana prije javnog predstavljanja, 2011. Sastavili smo ga za otprilike nedelju dana, pogledali, zavrtili - čak je i radio. Odnosno, mogli biste ući u formu, tamo unijeti naziv portala, otvorio bi se novi portal i kreirala bi se korisnička baza. Pogledali smo ga, načelno procijenili proizvod, izbacili ga i nastavili usavršavati cijelu godinu. Zato što smo imali veliki zadatak: nismo željeli napraviti dvije različite baze koda, nismo htjeli podržati odvojeni upakovani proizvod, odvojena rješenja u oblaku – htjeli smo sve to učiniti unutar jednog koda.
Tipična web aplikacija u to vrijeme bila je jedan server na kojem radi neki PHP kod, mysql baza podataka, uploaduju se fajlovi, dokumenti, slike stavljaju u upload folder - pa, sve radi. Nažalost, nemoguće je pokrenuti kritično stabilan web servis koristeći ovo. Tamo, distribuirana predmemorija nije podržana, replikacija baze podataka nije podržana.
Formulirali smo zahtjeve: ovo je mogućnost da se nalazite na različitim lokacijama, podržavate replikaciju i idealno se nalazite u različitim geografski raspoređenim centrima podataka. Odvojite logiku proizvoda i, zapravo, skladištenje podataka. Biti u stanju dinamički skalirati prema opterećenju i tolerirati statiku u potpunosti. Iz ovih razmatranja, zapravo, proizašli su zahtjevi za proizvod, koje smo usavršavali tokom godine. Za to vrijeme, u platformi, koja je ispala objedinjena – za kutijska rješenja, za vlastitu uslugu – napravili smo podršku za one stvari koje su nam bile potrebne. Podrška za mysql replikaciju na nivou samog proizvoda: to jest, programer koji piše kod ne razmišlja o tome kako će se njegovi zahtjevi distribuirati, on koristi naš API, a mi znamo kako pravilno distribuirati zahtjeve za pisanje i čitanje između mastera i robove.
Napravili smo podršku na nivou proizvoda za različite pohrane objekata u oblaku: google storage, amazon s3, plus podršku za open stack swift. Stoga je ovo bilo zgodno i za nas kao uslugu i za programere koji rade sa upakovanim rješenjem: ako samo koriste naš API za rad, ne razmišljaju o tome gdje će datoteka na kraju biti sačuvana, lokalno na sistemu datoteka ili u skladištu objektne datoteke.
Kao rezultat toga, odmah smo odlučili da rezervišemo na nivou čitavog data centra. 2012. godine smo u potpunosti pokrenuli Amazon AWS jer smo već imali iskustva s ovom platformom – tu je bila hostirana naša vlastita web stranica. Privukla nas je činjenica da u svakoj regiji Amazon ima nekoliko zona dostupnosti – zapravo (u njihovoj terminologiji) nekoliko centara podataka koji su manje-više neovisni jedan od drugog i koji nam omogućavaju rezervaciju na razini cijelog podatkovnog centra: ako iznenada ne uspije, baze podataka se repliciraju master-master, serveri web aplikacija se prave sigurnosne kopije, a statički podaci se premještaju u skladište s3 objekata. Opterećenje je izbalansirano - u to vrijeme Amazon elb-om, ali malo kasnije došli smo do vlastitih balansera opterećenja, jer nam je bila potrebna složenija logika.
Šta su hteli to su i dobili...
Sve osnovne stvari koje smo željeli osigurati - tolerancija grešaka samih servera, web aplikacija, baza podataka - sve je funkcionisalo dobro. Najjednostavniji scenario: ako jedna od naših web aplikacija ne uspije, onda je sve jednostavno - one se isključuju iz balansiranja.
Balanser (u to vrijeme to je bio Amazonov elb) označio je mašine koje nisu u funkciji kao nezdrave i isključio raspodjelu opterećenja na njima. Amazonovo automatsko skaliranje je radilo: kada je opterećenje poraslo, nove mašine su dodane u grupu za automatsko skaliranje, opterećenje je raspoređeno na nove mašine - sve je bilo u redu. Kod naših balansera logika je otprilike ista: ako se nešto dogodi aplikacijskom serveru, uklanjamo zahtjeve s njega, izbacimo ove mašine, pokrećemo nove i nastavljamo sa radom. Shema se malo promijenila tijekom godina, ali nastavlja raditi: jednostavna je, razumljiva i s njom nema poteškoća.
Radimo u cijelom svijetu, vršna opterećenja kupaca su potpuno različita, i, na prijateljski način, trebali bismo biti u mogućnosti da izvršimo određene servisne radove na bilo kojoj komponenti našeg sistema u bilo koje vrijeme - neprimijećeno od strane kupaca. Stoga imamo priliku da isključimo bazu podataka iz rada, preraspodijelivši opterećenje na drugi podatkovni centar.
Kako sve to funkcionira? — Prebacujemo promet na radni podatkovni centar - ako dođe do nesreće u podatkovnom centru, onda u potpunosti, ako je ovo naš planirani rad s jednom bazom podataka, onda dio prometa koji opslužuje ove klijente prebacujemo na drugi podatkovni centar, obustavljajući to replikacija. Ako su za web aplikacije potrebne nove mašine zbog povećanja opterećenja drugog data centra, one će se automatski pokrenuti. Završavamo posao, replikacija se obnavlja i vraćamo cijelo opterećenje. Ako trebamo preslikati neki posao u drugom DC-u, na primjer, instalirati ažuriranja sistema ili promijeniti postavke u drugoj bazi podataka, onda, općenito, ponavljamo istu stvar, samo u drugom smjeru. A ako je ovo nesreća, onda sve radimo trivijalno: koristimo mehanizam za obradu događaja u sistemu za praćenje. Ako se pokrene nekoliko provjera i status postane kritičan, tada pokrećemo ovaj rukovalac, rukovalac koji može izvesti ovu ili onu logiku. Za svaku bazu podataka navodimo koji server je za nju prelazak na grešku i na koji se promet treba prebaciti ako je nedostupan. Istorijski gledano, koristimo nagios ili neke od njegovih viljuški u ovom ili onom obliku. U principu, slični mehanizmi postoje u gotovo svakom sistemu praćenja, ništa složenije još ne koristimo, ali možda ćemo jednog dana. Sada je praćenje pokrenuto nedostupnošću i ima mogućnost promjene nečega.
Jesmo li sve rezervirali?
Imamo mnogo klijenata iz SAD-a, mnogo klijenata iz Evrope, mnogo klijenata koji su bliži Istoku - Japanu, Singapuru i tako dalje. Naravno, veliki udio klijenata je u Rusiji. Odnosno, posao nije u jednom regionu. Korisnici žele brzu reakciju, postoje zahtjevi da se poštuju različiti lokalni zakoni, a unutar svake regije rezervišemo dva data centra, plus postoje i neke dodatne usluge, koje je, opet, zgodno postaviti unutar jednog regiona - za klijente koji su u ovaj region rade. REST rukovaoci, autorizacijski serveri, oni su manje kritični za rad klijenta u cjelini, možete se prebacivati kroz njih s malim prihvatljivim kašnjenjem, ali ne želite ponovo izmišljati točak kako ih nadgledati i šta učiniti sa njima. Stoga nastojimo maksimalno iskoristiti postojeća rješenja, umjesto da razvijamo neku vrstu kompetencije u dodatnim proizvodima. I negdje trivijalno koristimo prebacivanje na DNS nivou, a živost usluge određujemo istim DNS-om. Amazon ima uslugu Route 53, ali to nije samo DNS u koji možete unositi i to je to – mnogo je fleksibilniji i praktičniji. Preko njega možete izgraditi geo-distribuirane servise sa geolokacijama, kada pomoću njega odredite odakle je klijent došao i date mu određene zapise - uz njegovu pomoć možete izgraditi arhitekturu napuštanja greške. Iste zdravstvene provjere su konfigurisane u samom Route 53, vi postavljate krajnje tačke koje se nadgledaju, postavljate metriku, postavljate protokole za određivanje “živosti” usluge - tcp, http, https; postavite učestalost provjera koje određuju da li je usluga živa ili ne. I u samom DNS-u navedete šta će biti primarno, a šta sekundarno, gdje se prebaciti ako se provjera stanja aktivira unutar rute 53. Sve ovo se može uraditi sa nekim drugim alatima, ali zašto je to zgodno - mi to postavljamo jednom i onda nemoj uopće razmišljati o tome kako radimo provjere, kako se mijenjamo: sve radi samo od sebe.
prvo "ali": kako i čime rezervisati samu rutu 53? Ko zna šta ako mu se nešto desi? Na sreću, nikada nismo nagazili na ove grablje, ali opet ću imati priču o tome zašto smo mislili da ipak moramo da rezervišemo. Ovdje smo unaprijed izložili slamke. Nekoliko puta dnevno vršimo potpuni istovar svih zona koje imamo na ruti 53. Amazonov API vam omogućava da ih lako pošaljete u JSON-u, a mi imamo nekoliko backup servera na koje ih konvertujemo, otpremamo u obliku konfiguracija i imamo, grubo rečeno, backup konfiguraciju. Ako se nešto dogodi, možemo to brzo implementirati ručno bez gubitka podataka o postavkama DNS-a.
drugo "ali": Šta na ovoj slici još nije rezervirano? Sam balanser! Naša distribucija klijenata po regionima je vrlo jednostavna. Imamo domene bitrix24.ru, bitrix24.com, .de - sada postoji 13 različitih, koji rade u različitim zonama. Došli smo do sljedećeg: svaka regija ima svoje balansere. To ga čini pogodnijim za distribuciju po regijama, ovisno o tome gdje je vršno opterećenje mreže. Ako je ovo kvar na nivou jednog balansera, onda se jednostavno povlači iz upotrebe i uklanja iz dns-a. Ako postoji neki problem sa grupom balansera, onda se oni bekapuju na drugim sajtovima, a prebacivanje između njih se vrši istom rutom53, jer zbog kratkog TTL-a, prebacivanje se dešava u roku od maksimalno 2, 3, 5 minuta .
Treće "ali": Šta još nije rezervisano? S3, tačno. Kada smo fajlove koje pohranjujemo za korisnike smjestili u s3, iskreno smo vjerovali da je on oklopnoprobojan i da tu nije potrebno ništa rezervirati. Ali istorija pokazuje da se stvari dešavaju drugačije. Generalno, Amazon opisuje S3 kao fundamentalnu uslugu, jer sam Amazon koristi S3 za pohranjivanje slika mašine, konfiguracija, AMI slika, snimaka... A ako se s3 sruši, kao što se desilo jednom tokom ovih 7 godina, koliko koristimo bitrix24, prati ga kao obožavatelj. Postoji čitava gomila stvari koje se pojavljuju – nemogućnost pokretanja virtuelnih mašina, neuspjeh API-ja itd.
I S3 može pasti - desilo se jednom. Dakle, došli smo do sljedeće šeme: prije nekoliko godina u Rusiji nije bilo ozbiljnih skladišta javnih objekata i razmišljali smo o mogućnosti da uradimo nešto svoje... Na sreću, nismo počeli s tim, jer bismo iskopali smo u stručnost koju nemamo imamo, i vjerovatno bi zabrljali. Sada Mail.ru ima skladište kompatibilno sa s3, Yandex ga ima, a imaju ga i brojni drugi provajderi. Na kraju smo došli do ideje da želimo imati, prvo, backup, a drugo, mogućnost rada sa lokalnim kopijama. Posebno za rusku regiju koristimo uslugu Mail.ru Hotbox, koja je API kompatibilna sa s3. Nisu nam bile potrebne nikakve veće modifikacije koda unutar aplikacije, a napravili smo sljedeći mehanizam: u s3 postoje okidači koji pokreću kreiranje/brisanje objekata, Amazon ima uslugu pod nazivom Lambda - ovo je pokretanje koda bez servera koji će se izvršiti upravo kada se aktiviraju određeni okidači.
Uradili smo to vrlo jednostavno: ako se naš okidač aktivira, izvršavamo kod koji će kopirati objekat u Mail.ru skladište. Da bismo u potpunosti pokrenuli rad sa lokalnim kopijama podataka, potrebna nam je i obrnuta sinhronizacija kako bi klijenti koji su u ruskom segmentu mogli da rade sa skladištima koja su im bliža. Mail će dovršiti trigere u svom skladištu - biće moguće izvršiti obrnutu sinhronizaciju na infrastrukturnom nivou, ali za sada to radimo na nivou vlastitog koda. Ako vidimo da je klijent objavio datoteku, tada na nivou koda stavljamo događaj u red čekanja, obrađujemo ga i vršimo obrnutu replikaciju. Zašto je to loše: ako radimo neku vrstu posla sa svojim objektima izvan našeg proizvoda, odnosno nekim eksternim sredstvima, nećemo to uzeti u obzir. Stoga čekamo do kraja, kada se na nivou pohrane pojave okidači, tako da bez obzira odakle izvršavamo kod, objekt koji je došao do nas se kopira u drugom smjeru.
Na nivou koda registrujemo oba skladišta za svakog klijenta: jedno se smatra glavnim, a drugo rezervnim. Ako je sve u redu, radimo sa skladištem koji nam je bliži: to jest, naši klijenti koji su u Amazonu, rade sa S3, a oni koji rade u Rusiji, rade sa Hotboxom. Ako se zastavica aktivira, tada bi trebalo povezati prelazak na grešku i prebaciti klijente na drugu pohranu. Možemo označiti ovaj okvir nezavisno po regijama i možemo ih prebacivati naprijed-nazad. Ovo još nismo koristili u praksi, ali smo predvidjeli ovaj mehanizam i mislimo da će nam jednog dana zatrebati upravo ovaj prekidač i dobro će nam doći. Ovo se već jednom dogodilo.
Oh, i Amazon je pobjegao...
Ovog aprila obilježava se godišnjica početka blokiranja Telegrama u Rusiji. Najpogođeniji provajder koji je potpao pod ovo je Amazon. I, nažalost, više su stradale ruske kompanije koje su radile za cijeli svijet.
Ako je kompanija globalna i Rusija je vrlo mali segment za nju, 3-5% - pa, na ovaj ili onaj način, možete ih žrtvovati.
Ako je ovo čisto ruska kompanija - siguran sam da se mora nalaziti lokalno - pa, jednostavno će biti zgodno za same korisnike, udobno i bit će manje rizika.
Šta ako je ovo kompanija koja posluje globalno i ima približno jednak broj klijenata iz Rusije i negdje u svijetu? Povezanost segmenata je važna i oni moraju raditi jedan s drugim na ovaj ili onaj način.
Krajem marta 2018. Roskomnadzor je najvećim operaterima poslao pismo u kojem se navodi da planiraju blokirati nekoliko miliona Amazon IP-ova kako bi blokirali... Zello messenger. Zahvaljujući tim istim provajderima - uspješno su procurili pismo svima i došlo je do razumijevanja da bi se veza s Amazonom mogla raspasti. Bio je petak, panično smo potrčali kolegama sa servers.ru, rekavši: „Prijatelji, treba nam nekoliko servera koji će biti locirani ne u Rusiji, ne u Amazonu, već, na primjer, negdje u Amsterdamu“, kako bi da bismo mogli barem nekako tamo instalirati svoj VPN i proxy za neke krajnje tačke na koje ne možemo utjecati ni na koji način, na primjer endponte istog s3 - ne možemo pokušati podići novi servis i dobiti drugi IP, još uvek morate da stignete tamo. Za samo nekoliko dana postavili smo ove servere, pokrenuli ih i, općenito, pripremili se za trenutak kada je blokiranje počelo. Zanimljivo je da je RKN, gledajući galamu i paniku, rekao: „Ne, nećemo sada ništa blokirati“. (Ali to je tačno do trenutka kada je Telegram počeo da se blokira.) Pošto smo postavili mogućnosti zaobilaženja i shvatili da blokiranje nije uvedeno, nismo, međutim, počeli da rešavamo celu stvar. Da, za svaki slučaj.
I 2019. godine i dalje živimo u uslovima blokade. Pogledao sam sinoć: oko milion IP adresa je i dalje blokirano. Istina, Amazon je bio skoro potpuno deblokiran, na svom vrhuncu dostigao je 20 miliona adresa... Generalno, realnost je da možda nema koherentnosti, dobre koherentnosti. Odjednom. Možda ne postoji iz tehničkih razloga - požari, bageri, sve to. Ili, kao što smo vidjeli, ne sasvim tehnički. Dakle, neko veliki i veliki, sa sopstvenim AS-ovima, verovatno može ovo da upravlja na druge načine - direktno povezivanje i druge stvari su već na l2 nivou. Ali u jednostavnoj verziji, poput naše ili još manjoj, možete, za svaki slučaj, imati redundantnost na nivou servera podignutih negdje drugdje, unaprijed konfigurisan vpn, proxy, sa mogućnošću brzog prebacivanja konfiguracije na njih u tim segmentima koji su kritični za vašu povezanost. To nam je više puta dobro došlo, kada je počelo blokiranje Amazona; u najgorem slučaju, dozvolili smo samo S3 promet preko njih, ali se postepeno sve to riješilo.
Kako rezervirati... cijelog provajdera?
Trenutno nemamo scenario u slučaju da ceo Amazon propadne. Imamo sličan scenario za Rusiju. U Rusiji nas je ugostio jedan provajder, od kojeg smo odabrali da imamo nekoliko sajtova. I prije godinu dana suočili smo se s problemom: iako se radi o dva podatkovna centra, možda već na razini mrežne konfiguracije provajdera postoje problemi koji će i dalje utjecati na oba podatkovna centra. I možda ćemo završiti nedostupni na obje stranice. Naravno da se to desilo. Na kraju smo ponovo razmotrili arhitekturu unutra. Nije se mnogo promijenilo, ali za Rusiju sada imamo dvije stranice, koje nisu od istog provajdera, već od dva različita. Ako jedno ne uspije, možemo se prebaciti na drugo.
Hipotetički, za Amazon razmatramo mogućnost rezervacije na nivou drugog provajdera; možda Google, možda neko drugi... Ali do sada smo u praksi uočili da dok Amazon ima nezgode na nivou jedne zone dostupnosti, nezgode na nivou čitavog regiona su prilično rijetke. Stoga teoretski imamo ideju da bismo mogli napraviti rezervaciju „Amazon nije Amazon“, ali u praksi to još nije slučaj.
Nekoliko riječi o automatizaciji
Da li je automatizacija uvijek neophodna? Ovdje je prikladno podsjetiti se na Dunning-Krugerov efekat. Na osi “x” je naše znanje i iskustvo koje steknemo, a na osi “y” je povjerenje u naše postupke. U početku ne znamo ništa i nismo nimalo sigurni. Tada znamo malo i postajemo megapouzdani - ovo je takozvani "vrhunac gluposti", dobro ilustrovan slikom "demencija i hrabrost". Onda smo malo naučili i spremni smo za borbu. Onda nagazimo na neke mega-ozbiljne greške i nađemo se u dolini očaja, kada nam se čini da nešto znamo, a zapravo ne znamo mnogo. Zatim, kako stječemo iskustvo, postajemo sigurniji.
Našu logiku o raznim automatskim prebacivanjima na određene nezgode vrlo dobro opisuje ovaj grafikon. Počeli smo - nismo znali ništa da uradimo, skoro sav posao je rađen ručno. Tada smo shvatili da na sve možemo priložiti automatizaciju i, kao, mirno spavati. I odjednom nagazimo na mega-grabulje: aktivira se lažni pozitivan rezultat, i mi prebacujemo saobraćaj tamo-amo kada, na dobar način, to nismo trebali učiniti. Posljedično, replikacija se kvari ili nešto drugo - ovo je sama dolina očaja. I tada dolazimo do shvatanja da svemu moramo pristupiti mudro. Odnosno, ima smisla osloniti se na automatizaciju, predviđajući mogućnost lažnih alarma. Ali! ako posljedice mogu biti razorne, onda je bolje to prepustiti dežurstvu, dežurnim inženjerima koji će se pobrinuti i nadgledati da zaista dođe do nesreće, te će ručno izvršiti potrebne radnje...
zaključak
Tokom 7 godina išli smo od činjenice da kada je nešto palo, nastala je panika-panika, do shvatanja da problemi ne postoje, postoje samo zadaci, oni se moraju – i mogu – rešavati. Kada gradite uslugu, pogledajte je odozgo, procijenite sve rizike koji se mogu dogoditi. Ako ih odmah vidite, tada unaprijed predvidite redundantnost i mogućnost izgradnje infrastrukture otporne na greške, jer svaka točka koja može pokvariti i dovesti do neoperabilnosti servisa će to sigurno učiniti. Čak i ako vam se čini da neki elementi infrastrukture sigurno neće otkazati - poput istog s3, ipak imajte na umu da mogu. I barem u teoriji, imajte ideju šta ćete učiniti s njima ako se nešto dogodi. Imajte plan upravljanja rizikom. Kada razmišljate o tome da sve radite automatski ili ručno, procijenite rizike: šta će se dogoditi ako automatizacija počne sve prebacivati - neće li to dovesti do još gore situacije u odnosu na nesreću? Možda je negdje potrebno iskoristiti razuman kompromis između upotrebe automatike i reakcije dežurnog inženjera, koji će procijeniti stvarnu sliku i shvatiti da li treba nešto mijenjati na licu mjesta ili „da, ali ne sada“.
Razuman kompromis između perfekcionizma i stvarnog truda, vremena, novca koji možete potrošiti na šemu koju ćete na kraju imati.
Ovaj tekst je ažurirana i proširena verzija izvještaja Aleksandra Demidova na konferenciji .
izvor: www.habr.com