Usluga Bitrix24 danas nema stotine gigabita prometa, niti ima veliku flotu servera (iako ih, naravno, ima podosta). Ali za mnoge klijente to je glavni alat za rad u tvrtki; to je stvarna aplikacija kritična za poslovanje. Stoga, nema načina da padne. Što ako se pad dogodio, ali se servis tako brzo "oporavio" da nitko ništa nije primijetio? I kako je moguće implementirati failover bez gubitka kvalitete rada i broja klijenata? Alexander Demidov, direktor cloud usluga u Bitrix24, govorio je za naš blog o tome kako se sustav rezervacija razvijao tijekom 7 godina postojanja proizvoda.
“Pokrenuli smo Bitrix24 kao SaaS prije 7 godina. Glavna poteškoća vjerojatno je bila sljedeća: prije nego što je javno lansiran kao SaaS, ovaj je proizvod jednostavno postojao u formatu rješenja u kutiji. Klijenti su to kupili od nas, smjestili na svoje poslužitelje, postavili korporativni portal - opće rješenje za komunikaciju zaposlenika, pohranu datoteka, upravljanje zadacima, CRM, to je sve. I do 2012. odlučili smo da ga želimo pokrenuti kao SaaS, sami ga administrirajući, osiguravajući toleranciju na greške i pouzdanost. Usput smo stjecali iskustvo jer ga do tada jednostavno nismo imali – bili smo samo proizvođači softvera, a ne pružatelji usluga.
Prilikom pokretanja usluge shvatili smo da je najvažnije osigurati toleranciju na greške, pouzdanost i stalnu dostupnost usluge, jer ako imate jednostavnu običnu web stranicu, trgovinu, na primjer, ona padne na vas i stoji tu sat vremena, samo vi patite, gubite narudžbe, gubite klijente, ali za samog vašeg klijenta to nije kritično za njega. Bio je uzrujan, naravno, ali je otišao i kupio ga na drugom mjestu. A ako je ovo aplikacija na kojoj se veže sav posao unutar tvrtke, komunikacije, odluke, onda je najvažnije steći 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
Prvi prototip sastavili smo godinu dana prije javnog predstavljanja, 2011. godine. Sastavili smo ga za otprilike tjedan dana, pogledali ga, zavrtjeli - čak je i radio. Odnosno, mogli ste ući u obrazac, tamo unijeti naziv portala, otvorio bi se novi portal i stvorila bi se baza korisnika. Pogledali smo ga, načelno procijenili proizvod, bacili ga u otpad i nastavili ga usavršavati cijelu godinu. Zato što smo imali veliki zadatak: nismo htjeli napraviti dvije različite baze koda, nismo htjeli podržati odvojeni pakirani proizvod, odvojena rješenja u oblaku - htjeli smo sve to napraviti unutar jednog koda.
Tipična web aplikacija u to vrijeme bila je jedan server na kojem se vrti neki PHP kod, mysql baza podataka, uploadaju se fajlovi, dokumenti, slike stavljaju u mapu za upload - dobro, sve to radi. Nažalost, pomoću ovoga je nemoguće pokrenuti kritično stabilnu web uslugu. Tamo distribuirana predmemorija nije podržana, replikacija baze podataka nije podržana.
Formulirali smo zahtjeve: to je mogućnost da se nalazite na različitim lokacijama, da podržavate replikaciju i idealno je da budete locirani u različitim geografski raspoređenim podatkovnim centrima. Odvojite logiku proizvoda i, zapravo, pohranu podataka. Budite u mogućnosti dinamički skalirati prema opterećenju i potpuno tolerirati statiku. Iz tih promišljanja proizašli su zapravo zahtjevi za proizvod koje smo dorađivali tijekom godine. Za to vrijeme smo u platformi, koja se pokazala unificiranom - za rješenja u kutiji, za vlastitu uslugu - napravili podršku za one stvari koje su nam trebale. Podrška za mysql replikaciju na razini samog proizvoda: odnosno programer koji piše kod ne razmišlja o tome kako će njegovi zahtjevi biti distribuirani, on koristi naš api, a mi znamo kako pravilno distribuirati zahtjeve za pisanje i čitanje između mastera i robova.
Napravili smo podršku na razini proizvoda za razne pohrane objekata u oblaku: google pohranu, amazon s3, plus podršku za open stack swift. Stoga je ovo bilo zgodno i za nas kao uslugu i za programere koji rade s paketnim rješenjem: ako samo koriste naš API za rad, ne razmišljaju o tome gdje će datoteka na kraju biti spremljena, lokalno na datotečni sustav ili u spremištu objektnih datoteka.
Kao rezultat toga, odmah smo odlučili da ćemo rezervirati na razini cijelog podatkovnog centra. U 2012. pokrenuli smo u potpunosti na Amazon AWS-u jer smo već imali iskustva s tom platformom - naša vlastita web stranica bila je tamo smještena. Privukla nas je činjenica da u svakoj regiji Amazon ima nekoliko zona dostupnosti – zapravo (u njihovoj terminologiji) nekoliko podatkovnih centara koji su više-manje neovisni jedan o drugome i omogućuju nam rezervaciju na razini cijelog podatkovnog centra: ako iznenada zakaže, baze podataka se repliciraju master-master, poslužitelji web aplikacija sigurnosno kopiraju, a statički podaci se premještaju u pohranu objekata s3. Opterećenje je balansirano – u to vrijeme Amazon elb, ali nešto kasnije došli smo do vlastitih balansera opterećenja, jer nam je bila potrebna složenija logika.
Ono što su htjeli to su i dobili...
Sve osnovne stvari koje smo htjeli osigurati - otpornost na pogreške samih poslužitelja, web aplikacija, baza podataka - sve je dobro funkcioniralo. Najjednostavniji scenarij: ako jedna od naših web aplikacija zakaže, onda je sve jednostavno - isključuju se iz balansiranja.
Balanser (tada je to bio Amazonov elb) označavao je strojeve koji nisu radili kao neispravne i isključivao raspodjelu opterećenja na njima. Amazonovo automatsko skaliranje je radilo: kada je opterećenje naraslo, novi su strojevi dodani u grupu za automatsko skaliranje, opterećenje je raspoređeno na nove strojeve - sve je bilo u redu. S našim balanserima logika je otprilike ista: ako se nešto dogodi aplikacijskom poslužitelju, uklanjamo zahtjeve s njega, izbacujemo te strojeve, pokrećemo nove i nastavljamo s radom. Shema se malo promijenila tijekom godina, ali nastavlja raditi: jednostavna je, razumljiva i s njom nema poteškoća.
Radimo po cijelom svijetu, vršna opterećenja korisnika su potpuno drugačija i, na prijateljski način, trebali bismo biti u mogućnosti izvršiti određene servisne radove na bilo kojoj komponenti našeg sustava u bilo kojem trenutku - neprimjećeni od strane kupaca. Stoga imamo priliku isključiti bazu podataka iz rada, redistribuirajući opterećenje na drugi podatkovni centar.
Kako to sve funkcionira? — Prebacujemo promet na radni podatkovni centar - ako dođe do nezgode u podatkovnom centru, onda u potpunosti, ako je to naš planirani rad s jednom bazom podataka, tada dio prometa koji opslužuje te klijente prebacujemo na drugi podatkovni centar, obustavljajući to replikacija. Ako su novi strojevi potrebni za web aplikacije jer se povećalo opterećenje drugog podatkovnog centra, oni će se pokrenuti automatski. Završavamo posao, replikacija se obnavlja i vraćamo cijeli teret natrag. Ako trebamo preslikati neki posao u drugom DC-u, na primjer, instalirati ažuriranja sustava ili promijeniti postavke u drugoj bazi podataka, onda, općenito, ponavljamo istu stvar, samo u drugom smjeru. A ako je to nesreća, onda sve radimo trivijalno: koristimo mehanizam rukovatelja događajima u sustavu praćenja. Ako se pokrene nekoliko provjera i status prijeđe u kritično, tada pokrećemo ovaj rukovatelj, rukovatelj koji može izvršiti ovu ili onu logiku. Za svaku bazu podataka specificiramo koji je poslužitelj failover za nju i gdje promet treba prebaciti ako je nedostupan. Povijesno gledano, koristimo nagios ili neke njegove vilice u ovom ili onom obliku. U principu, slični mehanizmi postoje u gotovo svakom sustavu nadzora; mi još ne koristimo ništa složenije, ali možda jednog dana hoćemo. Sada se nadzor pokreće nedostupnošću i ima mogućnost promjene nečega.
Jesmo li sve rezervirali?
Imamo mnogo klijenata iz SAD-a, mnogo klijenata iz Europe, mnogo klijenata koji su bliže istoku - Japan, Singapur i tako dalje. Naravno, veliki udio klijenata je u Rusiji. To jest, posao nije u jednoj regiji. Korisnici žele brz odgovor, postoje zahtjevi u skladu s raznim lokalnim zakonima, a unutar svake regije rezerviramo dva podatkovna centra, plus postoje neke dodatne usluge koje je, opet, prikladno smjestiti unutar jedne regije - za klijente koji su u ova regija radi. REST rukovatelji, autorizacijski poslužitelji, oni su manje kritični za rad klijenta u cjelini, možete se prebacivati kroz njih s malim prihvatljivim kašnjenjem, ali ne želite ponovno izmišljati kotač kako ih nadzirati i što učiniti sa njima. Stoga nastojimo maksimalno iskoristiti postojeća rješenja, a ne razvijati nekakvu kompetenciju u dodatnim proizvodima. A negdje trivijalno koristimo komutaciju na razini DNS-a, a živost usluge određujemo po tom istom DNS-u. 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 graditi geo-distribuirane usluge s geolokacijama, kada pomoću njega utvrđujete odakle je klijent došao i dajete mu određene zapise – uz njegovu pomoć možete graditi failover arhitekture. Iste provjere zdravlja konfigurirane su u samoj Route 53, postavljate krajnje točke koje se nadziru, postavljate metrike, postavljate koji protokoli za određivanje "živosti" usluge - tcp, http, https; postavite učestalost provjera koje određuju je li usluga živa ili ne. I u samom DNS-u odredite što će biti primarno, što će biti sekundarno, gdje prebaciti ako se provjera zdravlja pokrene unutar rute 53. Sve se to može učiniti s nekim drugim alatima, ali zašto je zgodno - mi smo postavili gore jednom i onda uopće ne razmišljaj o tome kako radimo provjere, kako se prebacujemo: sve radi samo od sebe.
Prvo "ali": kako i čime rezervirati samu rutu 53? Tko zna, što ako mu se nešto dogodi? Srećom, nikada nismo stali na ove grablje, ali opet ću imati priču ispred zašto smo mislili da ipak trebamo rezervirati. Ovdje smo unaprijed postavili slamke za sebe. Nekoliko puta dnevno radimo potpuno rasterećenje svih zona koje imamo na ruti 53. Amazonov API vam omogućuje jednostavno slanje u JSON-u, a mi imamo nekoliko backup poslužitelja gdje to konvertiramo, uploadamo u obliku konfiguracija i imamo, grubo rečeno, backup konfiguraciju. Ako se nešto dogodi, možemo ga brzo ručno implementirati bez gubitka podataka o DNS postavkama.
Drugo "ali": Što na ovoj slici još nije rezervirano? Sam balanser! Naša raspodjela klijenata po regijama je vrlo jednostavna. Imamo domene bitrix24.ru, bitrix24.com, .de - sada ih ima 13 različitih, koje djeluju u različitim zonama. Došli smo do sljedećeg: svaka regija ima svoje balansere. To ga čini praktičnijim za distribuciju po regijama, ovisno o tome gdje je vršno opterećenje mreže. Ako se radi o kvaru na razini jednog balansera, on se jednostavno izbacuje iz službe i uklanja iz dns-a. Ako postoji problem s grupom balansera, oni se backupuju na drugim stranicama, a prebacivanje između njih se vrši istom rutom53, jer zbog kratkog TTL-a, prebacivanje se događa unutar najviše 2, 3, 5 minuta. .
Treće "ali": Što još nije rezervirano? S3, točno. Kada smo datoteke koje pohranjujemo za korisnike smjestili u s3, iskreno smo vjerovali da je oklopna i da tu nema potrebe ništa rezervirati. Ali povijest pokazuje da se stvari događaju drugačije. Općenito, Amazon opisuje S3 kao temeljnu uslugu, jer sam Amazon koristi S3 za pohranu slika strojeva, konfiguracija, AMI slika, snimki... A ako se s3 sruši, kao što se dogodilo jednom u ovih 7 godina, koliko koristimo bitrix24, prati ga kao lepeza Postoji hrpa stvari koje se pojavljuju - nemogućnost pokretanja virtualnih strojeva, kvar api-ja i tako dalje.
I S3 može pasti – dogodilo se jednom. Stoga smo došli do sljedeće sheme: prije nekoliko godina u Rusiji nije bilo ozbiljnih skladišta javnih predmeta i razmatrali smo opciju da napravimo nešto svoje... Srećom, nismo to počeli raditi, jer bismo kopali po stručnosti koju nemamo imamo, i vjerojatno bi zabrljali. Sada Mail.ru ima s3-kompatibilnu pohranu, ima je Yandex i brojni drugi pružatelji usluga. Na kraju smo došli na ideju da želimo imati, prvo, backup, a drugo, mogućnost rada s lokalnim kopijama. Posebno za rusku regiju koristimo uslugu Mail.ru Hotbox, koja je API kompatibilna sa s3. Nismo trebali nikakve veće izmjene koda unutar aplikacije, a napravili smo sljedeći mehanizam: u s3 postoje okidači koji pokreću kreiranje/brisanje objekata, Amazon ima uslugu koja se zove Lambda - ovo je pokretanje koda bez poslužitelja koji će se izvršiti upravo kada se pokreću određeni okidači.
Učinili smo to vrlo jednostavno: ako se aktivira naš okidač, izvršavamo kod koji će kopirati objekt u pohranu Mail.ru. Za potpuno pokretanje rada s lokalnim kopijama podataka potrebna nam je i obrnuta sinkronizacija kako bi klijenti koji su u ruskom segmentu mogli raditi s pohranom koja im je bliža. Mail će uskoro završiti okidače u svojoj pohrani - bit će moguće izvršiti obrnutu sinkronizaciju na razini infrastrukture, ali za sada to radimo na razini vlastitog koda. Ako vidimo da je klijent objavio datoteku, tada na razini koda događaj stavljamo u red čekanja, obrađujemo ga i radimo reverznu replikaciju. Zašto je to loše: ako s našim objektima radimo na neki način izvan našeg proizvoda, to jest nekim vanjskim sredstvima, to nećemo uzeti u obzir. Stoga čekamo do kraja, kada se pojave okidači na razini pohrane, tako da bez obzira odakle izvršavamo kod, objekt koji nam je došao kopira se u drugom smjeru.
Na razini koda registriramo oba skladišta za svakog klijenta: jedan se smatra glavnim, a drugi rezervnim. Ako je sve u redu, radimo s pohranom koja nam je bliža: to jest, naši klijenti koji su u Amazonu, rade s S3, a oni koji rade u Rusiji, rade s Hotboxom. Ako je zastavica pokrenuta, tada bi se trebao povezati failover, a mi prebacimo klijente na drugu pohranu. Ovaj okvir možemo označiti neovisno po regijama i možemo ih mijenjati naprijed i natrag. Ovo još nismo koristili u praksi, ali smo predvidjeli ovaj mehanizam i mislimo da će nam jednom ovaj prekidač trebati i dobro doći. Ovo se već jednom dogodilo.
Oh, i Amazon je pobjegao...
Ovog travnja obilježava se godišnjica početka blokiranja Telegrama u Rusiji. Najviše pogođeni pružatelj koji je pao pod ovo je Amazon. I, nažalost, više su stradale ruske tvrtke koje su radile za cijeli svijet.
Ako je tvrtka globalna i Rusija je za nju vrlo mali segment, 3-5% - pa, na ovaj ili onaj način, možete ih žrtvovati.
Ako je ovo čisto ruska tvrtka - siguran sam da se mora nalaziti lokalno - pa, jednostavno će biti prikladno za same korisnike, udobno i bit će manje rizika.
Što ako se radi o tvrtki 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 ožujka 2018. Roskomnadzor je poslao pismo najvećim operaterima u kojem je naveo da planiraju blokirati nekoliko milijuna Amazonovih IP adresa kako bi blokirali... Messenger Zello. Zahvaljujući tim istim provajderima - uspješno su procurili pismo svima, a došlo se do razumijevanja da bi se veza s Amazonom mogla raspasti. Bio je petak, u panici smo trčali kolegama sa servers.ru, s riječima: "Prijatelji, trebamo nekoliko servera koji se neće nalaziti u Rusiji, ne u Amazonu, već, na primjer, negdje u Amsterdamu," kako bismo mogli barem nekako tamo instalirati vlastiti VPN i proxy za neke krajnje točke na koje ne možemo utjecati ni na koji način, npr. endponte istog s3 - ne možemo pokušati podignuti novu uslugu i dobiti drugačiju ip, još uvijek trebaš stići tamo. U samo nekoliko dana postavili smo te servere, stavili ih u pogon i općenito pripremili za trenutak početka blokade. Zanimljivo je da je RKN, gledajući strku i paniku, rekao: "Ne, nećemo sada ništa blokirati." (Ali to je točno do trenutka kada je Telegram počeo biti blokiran.) Nakon što smo postavili mogućnosti premosnice i uvidjeli da blokada nije uvedena, mi, međutim, nismo krenuli u rješavanje cijele stvari. Da, za svaki slučaj.
I sada u 2019. i dalje živimo u uvjetima blokade. Pogledao sam sinoć: oko milijun IP adresa i dalje je blokirano. Istina, Amazon je bio gotovo potpuno deblokiran, na vrhuncu je dosegao 20 milijuna adresa... Općenito, realnost je takva da možda nema koherentnosti, dobre koherentnosti. Iznenada. Možda ne postoji iz tehničkih razloga - požari, bageri, sve to. Ili, kao što smo vidjeli, ne posve tehnički. Dakle, netko velik i veliki, sa svojim AS-ovima, vjerojatno to može riješiti na druge načine - direktno povezivanje i ostale stvari su već na l2 razini. Ali u jednostavnoj verziji, poput naše ili još manjoj, možete za svaki slučaj imati redundanciju na razini poslužitelja podignutih negdje drugdje, unaprijed konfiguriranih vpn, proxy, s mogućnošću brzog prebacivanja konfiguracije na njih u tim segmentima koji su ključni za vašu povezanost. Ovo nam je više puta dobro došlo, kada je počelo blokiranje Amazona; u najgorem slučaju dopustili smo samo S3 promet preko njih, ali postupno se sve to riješilo.
Kako rezervirati... cijelog pružatelja usluga?
Trenutačno nemamo scenarij u slučaju da cijeli Amazon propadne. Imamo sličan scenarij za Rusiju. U Rusiji nas je ugostio jedan pružatelj, od kojeg smo odabrali nekoliko stranica. A prije godinu dana suočili smo se s problemom: iako se radi o dva podatkovna centra, problemi mogu biti već na razini mrežne konfiguracije pružatelja usluga koji će i dalje utjecati na oba podatkovna centra. I mogli bismo završiti nedostupni na obje stranice. Naravno da se to dogodilo. Na kraju smo preispitali unutrašnju arhitekturu. Nije se puno promijenilo, ali za Rusiju sada imamo dvije stranice, koje nisu od istog pružatelja usluga, već od dva različita. Ako jedno ne uspije, možemo prijeći na drugo.
Hipotetski, za Amazon razmatramo mogućnost rezervacije na razini drugog pružatelja; možda Google, možda netko drugi... Ali do sada smo u praksi primijetili da dok Amazon ima nezgode na razini jedne zone dostupnosti, nezgode na razini cijele regije prilično su rijetke. Stoga teoretski imamo ideju da bismo mogli rezervirati "Amazon nije Amazon", ali u praksi to još nije slučaj.
Nekoliko riječi o automatizaciji
Je li automatizacija uvijek potrebna? Ovdje je prikladno prisjetiti se Dunning-Krugerovog učinka. Na “x” osi je naše znanje i iskustvo koje stječemo, a na “y” osi je povjerenje u naše postupke. U početku ne znamo ništa i nismo nimalo sigurni. Tada znamo malo i postajemo mega samopouzdani - to je takozvani "vrhunac gluposti", dobro ilustriran slikom "demencija i hrabrost". Onda smo malo naučili i spremni smo za bitku. Onda nagazimo na neke mega ozbiljne greške i nađemo se u dolini očaja, kad nam se čini da nešto znamo, a zapravo ne znamo puno. Zatim, kako stječemo iskustvo, postajemo sigurniji.
Našu logiku o raznim automatskim prebacivanjima na određene nesreće vrlo dobro opisuje ovaj grafikon. Počeli smo - nismo znali ništa raditi, gotovo sav posao je rađen ručno. Onda smo shvatili da na sve možemo spojiti automatiku i, onako, mirno spavati. I odjednom nagazimo na mega-rake: pokreće se lažno pozitivno, a mi prebacujemo promet naprijed-natrag kada, u dobrom smislu riječi, to nismo trebali učiniti. Posljedično, replikacija se prekida ili nešto drugo - to je sama dolina očaja. I tada shvaćamo da svemu moramo pristupiti mudro. Odnosno, ima smisla osloniti se na automatizaciju, osiguravajući mogućnost lažnih alarma. Ali! ako posljedice mogu biti razorne, onda je bolje to prepustiti dežurstvu, dežurnim strojarima koji će se uvjeriti i pratiti da doista postoji nesreća, te ručno izvršiti potrebne radnje...
Zaključak
Tijekom 7 godina prošli smo put od toga da kad nešto padne nastane panika-panika, do shvaćanja da problemi ne postoje, postoje samo zadaće, one se moraju – i mogu – rješavati. Kada gradite uslugu, pogledajte je odozgo, procijenite sve rizike koji se mogu dogoditi. Ako ih vidite odmah, onda unaprijed predvidite redundanciju i mogućnost izgradnje fault-tolerant infrastrukture, jer svaka točka koja može zakazati i dovesti do neoperabilnosti servisa će to svakako učiniti. Čak i ako vam se čini da neki infrastrukturni elementi sigurno neće zakazati - poput s3, ipak imajte na umu da mogu. I barem u teoriji, imajte ideju što ćete učiniti s njima ako se nešto dogodi. Imajte plan upravljanja rizikom. Kada razmišljate o tome hoćete li sve raditi automatski ili ručno, procijenite rizike: što će se dogoditi ako automatizacija počne sve mijenjati - neće li to dovesti do još gore situacije u usporedbi s nesrećom? Možda je negdje potrebno koristiti razuman kompromis između upotrebe automatike i reakcije dežurnog inženjera, koji će procijeniti stvarnu sliku i shvatiti treba li nešto promijeniti na licu mjesta ili "da, ali ne sada".
Razuman kompromis između perfekcionizma i stvarnog truda, vremena, novca koji možete potrošiti na shemu koju ćete na kraju imati.
Ovaj tekst je ažurirana i proširena verzija izvješća Aleksandra Demidova na konferenciji .
Izvor: www.habr.com