Storitev Bitrix24 danes nima več sto gigabitov prometa, niti ne ogromne flote strežnikov (čeprav jih je seveda kar nekaj). Toda za mnoge stranke je glavno orodje za delo v podjetju, je resnično poslovno kritična aplikacija. Zato ni možnosti za padec. Kaj pa, če se je zrušitev res zgodila, vendar se je storitev tako hitro "okrenila", da nihče ni ničesar opazil? In kako je možno implementirati failover brez izgube kakovosti dela in števila strank? Alexander Demidov, direktor storitev v oblaku pri Bitrix24, je za naš blog spregovoril o tem, kako se je rezervacijski sistem razvijal v 7 letih obstoja produkta.
»Bitrix24 kot SaaS smo lansirali pred 7 leti. Glavna težava je bila verjetno naslednja: preden je bil javno predstavljen kot SaaS, je ta izdelek preprosto obstajal v formatu škatlaste rešitve. Naročniki so ga kupili pri nas, ga gostili na svojih strežnikih, postavili korporativni portal – splošna rešitev za komunikacijo zaposlenih, shranjevanje datotek, upravljanje nalog, CRM, to je vse. Do leta 2012 smo se odločili, da ga želimo lansirati kot SaaS, ga upravljati sami, zagotavljati odpornost na napake in zanesljivost. Na poti smo pridobivali izkušnje, saj jih do takrat preprosto nismo imeli – bili smo samo proizvajalci programske opreme, ne pa ponudniki storitev.
Pri uvedbi storitve smo razumeli, da je najpomembnejše zagotoviti toleranco na napake, zanesljivost in stalno razpoložljivost storitve, kajti če imaš preprosto navadno spletno stran, na primer trgovino, pade nate in tam stoji uro, samo vi trpite, izgubljate naročila, izgubljate stranke, vendar za vašo stranko samega to ni zelo kritično. Seveda je bil razburjen, vendar je šel in ga kupil na drugem mestu. In če je to aplikacija, na kateri je vezano vse delo znotraj podjetja, komunikacija, odločitve, potem je najbolj pomembno pridobiti zaupanje uporabnikov, torej, da jih ne pustimo na cedilu in ne pademo. Kajti vse delo se lahko ustavi, če nekaj znotraj ne deluje.
Bitrix.24 kot SaaS
Prvi prototip smo sestavili leto pred javno predstavitvijo, leta 2011. Sestavili smo ga v približno enem tednu, ga pogledali, zavrteli - celo delal je. To pomeni, da bi lahko šli v obrazec, tam vpisali ime portala, odprl bi se nov portal in ustvarila bi se baza uporabnikov. Pogledali smo ga, načeloma ocenili izdelek, ga zavrgli in še celo leto izpopolnjevali. Ker smo imeli veliko nalogo: nismo želeli izdelati dveh različnih kodnih osnov, nismo želeli podpirati ločenega pakiranega izdelka, ločenih rešitev v oblaku – želeli smo narediti vse v eni kodi.
Tipična spletna aplikacija takrat je bila en strežnik, na katerem teče neka PHP koda, mysql baza, nalagajo se datoteke, dokumenti, slike se dajo v mapo za nalaganje - no, vse deluje. Žal, s tem je nemogoče zagnati kritično stabilno spletno storitev. Tam porazdeljeni predpomnilnik ni podprt, podvajanje baze podatkov ni podprto.
Oblikovali smo zahteve: to je zmožnost lociranja na različnih lokacijah, podpore za replikacijo in idealno lociranje v različnih geografsko porazdeljenih podatkovnih centrih. Ločite logiko izdelka in pravzaprav shranjevanje podatkov. Sposobnost dinamičnega prilagajanja glede na obremenitev in popolno prenašanje statike. Iz teh premislekov so pravzaprav nastale zahteve za izdelek, ki smo jih tekom leta izpopolnjevali. V tem času smo v platformi, ki se je izkazala za enotno – za škatlaste rešitve, za lastne storitve – naredili podporo za tiste stvari, ki smo jih potrebovali. Podpora za replikacijo mysql na ravni samega produkta: torej razvijalec, ki piše kodo, ne razmišlja o tem, kako bodo njegove zahteve porazdeljene, uporablja naš api, mi pa znamo pravilno porazdeliti zahteve za pisanje in branje med mojstri in sužnji.
Izdelali smo podporo na ravni izdelka za različne shrambe objektov v oblaku: google storage, amazon s3 in podporo za open stack swift. Zato je bilo to priročno tako za nas kot storitev kot za razvijalce, ki delajo s paketno rešitvijo: če le uporabljajo naš API za delo, ne razmišljajo o tem, kam bo datoteka na koncu shranjena, lokalno v datotečnem sistemu oz. v shrambi objektnih datotek.
Posledično smo se takoj odločili, da bomo rezervirali na nivoju celotnega podatkovnega centra. Leta 2012 smo v celoti lansirali na Amazon AWS, ker smo že imeli izkušnje s to platformo – tam je gostovalo naše lastno spletno mesto. Pritegnilo nas je dejstvo, da ima Amazon v vsaki regiji več con razpoložljivosti – pravzaprav (v njihovi terminologiji) več podatkovnih centrov, ki so bolj ali manj neodvisni drug od drugega in nam omogočajo rezervacijo na ravni celotnega podatkovnega centra: če nenadoma odpove, se baze podatkov replicirajo master-master, strežniki spletnih aplikacij se varnostno kopirajo in statični podatki se premaknejo v objektno shrambo s3. Obremenitev je uravnotežena - takrat Amazon elb, malo kasneje pa smo prišli do lastnih load balancerjev, ker smo potrebovali bolj zapleteno logiko.
Kar so hoteli, to so dobili...
Vse osnovne stvari, ki smo jih želeli zagotoviti - toleranca napak samih strežnikov, spletne aplikacije, baze podatkov - vse je delovalo dobro. Najenostavnejši scenarij: če ena od naših spletnih aplikacij odpove, potem je vse preprosto - izklopijo se iz uravnoteženja.
Balanser (takrat je bil to Amazonov elb) je okvarjene stroje označil za nezdrave in na njih izklopil porazdelitev obremenitve. Amazonovo samodejno skaliranje je delovalo: ko se je obremenitev povečala, so bili v skupino za samodejno skaliranje dodani novi stroji, obremenitev je bila porazdeljena na nove stroje - vse je bilo v redu. Pri naših balanserjih je logika približno enaka: če se nekaj zgodi aplikacijskemu strežniku, z njega odstranimo zahteve, zavržemo te stroje, zaženemo nove in nadaljujemo z delom. Shema se je z leti nekoliko spremenila, vendar še naprej deluje: je preprosta, razumljiva in z njo ni težav.
Delamo povsod po svetu, konice obremenitev strank so popolnoma drugačne in na sporazumen način bi morali kadarkoli opraviti določena servisna dela na katerikoli komponenti našega sistema - neopazno za stranke. Zato imamo možnost izklopiti bazo podatkov iz delovanja in prerazporediti obremenitev v drugi podatkovni center.
Kako vse to deluje? — Promet preklopimo na delujoč podatkovni center - če pride do nesreče v podatkovnem centru, potem v celoti, če je to naše načrtovano delo z eno bazo podatkov, potem del prometa, ki služi tem strankam, preklopimo na drugi podatkovni center in prekinemo to podvajanje. Če so za spletne aplikacije potrebni novi stroji, ker se je povečala obremenitev drugega podatkovnega centra, se bodo samodejno zagnali. Delo zaključimo, replikacija se obnovi in vrnemo celotno obremenitev nazaj. Če moramo nekaj dela zrcaliti v drugem DC-ju, na primer namestiti sistemske posodobitve ali spremeniti nastavitve v drugi bazi podatkov, potem na splošno ponovimo isto stvar, samo v drugo smer. In če je to nesreča, potem naredimo vse trivialno: uporabimo mehanizem obdelovalcev dogodkov v sistemu za spremljanje. Če se sproži več preverjanj in stanje preide v kritično, potem zaženemo ta obdelovalnik, obdelovalnik, ki lahko izvede to ali ono logiko. Za vsako zbirko podatkov določimo, kateri strežnik je preklopni zanjo in kam je treba preusmeriti promet, če ta ni na voljo. Zgodovinsko gledano uporabljamo nagios ali nekatere njegove vilice v takšni ali drugačni obliki. Načeloma podobni mehanizmi obstajajo v skoraj vsakem nadzornem sistemu, nič bolj zapletenega še ne uporabljamo, a morda nekoč bomo. Zdaj se nadzor sproži zaradi nedosegljivosti in ima možnost nekaj preklopiti.
Smo rezervirali vse?
Imamo veliko strank iz ZDA, veliko strank iz Evrope, veliko strank, ki so bližje vzhodu - Japonska, Singapur in tako naprej. Seveda je ogromen delež strank v Rusiji. To pomeni, da delo ni v eni regiji. Uporabniki želijo hiter odziv, obstajajo zahteve glede skladnosti z različnimi lokalnimi zakoni, znotraj vsake regije pa rezerviramo dva podatkovna centra, poleg tega pa je na voljo nekaj dodatnih storitev, ki jih je spet priročno postaviti znotraj ene regije – za stranke, ki so v ta regija deluje. Obdelovalci REST, avtorizacijski strežniki, so manj kritični za delovanje odjemalca kot celote, med njimi lahko preklapljate z majhno sprejemljivo zamudo, vendar ne želite na novo izumljati kolesa, kako jih nadzirati in kaj narediti z njimi. Zato poskušamo maksimalno izkoristiti obstoječe rešitve, ne pa razvijati neke kompetence v dodatnih produktih. In nekje trivialno uporabljamo preklapljanje na nivoju DNS in po tem istem DNS določamo živahnost storitve. Amazon ima storitev Route 53, vendar to ni le DNS, v katerega lahko vnašate in to je to - je veliko bolj prilagodljiv in priročen. Prek njega lahko gradite geo-distribuirane storitve z geolokacijami, ko z njim ugotavljate, od kod prihaja stranka in mu dajete določene zapise – z njegovo pomočjo lahko gradite failover arhitekture. Isti zdravstveni pregledi so konfigurirani v sami Route 53, nastavite končne točke, ki se spremljajo, nastavite metrike, nastavite, kateri protokoli za določanje »živosti« storitve - tcp, http, https; nastavite pogostost preverjanj, ki ugotavljajo, ali storitev deluje ali ne. In v samem DNS določite, kaj bo primarno, kaj bo sekundarno, kam preklopiti, če se sproži pregled zdravja znotraj poti 53. Vse to je mogoče storiti z nekaterimi drugimi orodji, ampak zakaj je priročno - nastavimo enkrat gor in potem sploh ne razmišljaj o tem, kako delamo preglede, kako menjamo: vse deluje samo od sebe.
Prvi "ampak": kako in s čim rezervirati samo pot 53? Kdo ve, kaj če se mu kaj zgodi? Na srečo nismo nikoli stopili na te grablje, a spet bom imel pred seboj zgodbo, zakaj smo mislili, da moramo vseeno rezervirati. Tukaj smo si vnaprej postavili slamice. Večkrat na dan opravimo popolno razbremenitev vseh con, ki jih imamo na poti 53. Amazonov API vam omogoča, da jih preprosto pošljete v JSON, in imamo več rezervnih strežnikov, kjer jih pretvorimo, naložimo v obliki konfiguracij in imamo, grobo rečeno, rezervno konfiguracijo. Če se kaj zgodi, ga lahko hitro uvedemo ročno, ne da bi izgubili podatke o nastavitvah DNS.
Drugi "ampak": Kaj na tej sliki še ni rezervirano? Ravnotežje sam! Naša razdelitev strank po regijah je zelo preprosta. Imamo domene bitrix24.ru, bitrix24.com, .de - zdaj jih je 13 različnih, ki delujejo v različnih conah. Prišli smo do naslednjega: vsaka regija ima svoje uravnilovke. Zaradi tega je bolj priročno porazdeliti po regijah, odvisno od tega, kje je največja obremenitev omrežja. Če je to okvara na ravni enega samega balanserja, se le-ta preprosto izključi iz uporabe in odstrani iz dns. Če pride do težave s skupino balanserjev, se le-ti varnostno kopirajo na drugih mestih, preklapljanje med njimi pa poteka po isti poti53, saj zaradi kratkega TTL pride do preklopa v največ 2, 3, 5 minutah. .
Tretji "ampak": Kaj še ni rezervirano? S3, pravilno. Ko smo datoteke, ki jih hranimo za uporabnike, postavili v s3, smo iskreno verjeli, da je oklepna in da tam ni treba ničesar rezervirati. Toda zgodovina kaže, da se stvari dogajajo drugače. Na splošno Amazon opisuje S3 kot temeljno storitev, saj Amazon sam uporablja S3 za shranjevanje strojnih slik, konfiguracij, AMI slik, posnetkov ... In če se s3 zruši, kot se je zgodilo enkrat v teh 7 letih, kolikor uporabljamo bitrix24, spremlja ga kot ventilator. Pojavi se cel kup stvari - nezmožnost zagona virtualnih strojev, okvara api-ja itd.
In S3 lahko pade - zgodilo se je enkrat. Zato smo prišli do naslednje sheme: pred nekaj leti v Rusiji ni bilo resnih skladišč javnih predmetov in razmišljali smo o možnosti, da naredimo nekaj svojega ... Na srečo tega nismo začeli, ker bi se zakopali v strokovno znanje, ki ga nimamo, in bi verjetno zamočili. Zdaj ima Mail.ru shrambo, združljivo s S3, ima jo Yandex in številni drugi ponudniki. Sčasoma smo prišli do ideje, da želimo imeti, prvič, varnostno kopiranje, in drugič, možnost dela z lokalnimi kopijami. Posebej za rusko regijo uporabljamo storitev Mail.ru Hotbox, ki je API združljiva s s3. Nismo potrebovali večjih sprememb kode znotraj aplikacije in naredili smo naslednji mehanizem: v s3 so sprožilci, ki sprožijo ustvarjanje/brisanje objektov, Amazon ima storitev imenovano Lambda - to je brezstrežniški zagon kode ki se bo izvršil ravno takrat, ko se bodo sprožili določeni sprožilci.
To smo storili zelo preprosto: če se naš sprožilec sproži, izvedemo kodo, ki bo objekt kopirala v shrambo Mail.ru. Za popoln zagon dela z lokalnimi kopijami podatkov potrebujemo tudi povratno sinhronizacijo, tako da lahko stranke, ki so v ruskem segmentu, delajo s shrambo, ki jim je bližje. Pošta je tik pred dokončanjem sprožilcev v svoji shrambi – povratno sinhronizacijo bo mogoče izvajati na infrastrukturni ravni, a zaenkrat to počnemo na ravni lastne kode. Če vidimo, da je odjemalec objavil datoteko, potem na ravni kode dogodek postavimo v čakalno vrsto, ga obdelamo in izvedemo povratno replikacijo. Zakaj je slabo: če delamo z našimi predmeti zunaj našega izdelka, torej z zunanjimi sredstvi, tega ne bomo upoštevali. Zato počakamo do konca, ko se sprožilci pojavijo na nivoju pomnilnika, tako da se ne glede na to, od kod izvajamo kodo, objekt, ki je prišel do nas, kopira v drugo smer.
Na nivoju kode registriramo obe shrambi za vsakega odjemalca: ena velja za glavno, druga za rezervno. Če je vse v redu, delamo s shrambo, ki nam je bližje: torej naše stranke, ki so v Amazonu, delajo s S3, tiste, ki delajo v Rusiji, pa s Hotboxom. Če se zastavica sproži, je treba vzpostaviti samodejni preklop in odjemalce preklopimo na drugo shrambo. To polje lahko označimo neodvisno glede na regijo in jih lahko preklapljamo naprej in nazaj. Tega v praksi še nismo uporabljali, smo pa predvideli ta mehanizem in mislimo, da bomo nekoč potrebovali prav to stikalo in nam bo prišlo prav. Enkrat se je to že zgodilo.
Aja, pa Amazonka je pobegnila...
Aprila letos mineva obletnica začetka blokiranja Telegrama v Rusiji. Najbolj prizadeti ponudnik, ki je spadal pod to, je Amazon. In na žalost so bolj trpela ruska podjetja, ki so delala za ves svet.
Če je podjetje globalno in je Rusija zanj zelo majhen segment, 3-5% - no, tako ali drugače, jih lahko žrtvujete.
Če je to čisto rusko podjetje - prepričan sem, da mora biti lokalno - no, preprosto bo priročno za same uporabnike, udobno in manj bo tveganj.
Kaj pa, če je to podjetje, ki deluje globalno in ima približno enako število strank iz Rusije in nekje po svetu? Pomembna je povezljivost segmentov, ki morajo med seboj tako ali drugače delovati.
Konec marca 2018 je Roskomnadzor največjim operaterjem poslal pismo, v katerem je izjavil, da nameravajo blokirati več milijonov Amazonovih IP-jev, da bi blokirali ... messenger Zello. Zahvaljujoč tem istim ponudnikom - pismo so uspešno razkrili vsem in prišlo je do razumevanja, da lahko povezava z Amazonom razpade. Bil je petek, v paniki smo tekli do kolegov iz servers.ru z besedami: "Prijatelji, potrebujemo več strežnikov, ki ne bodo v Rusiji, ne v Amazonu, ampak na primer nekje v Amsterdamu," da bi lahko tam vsaj nekako namestili svoj VPN in proxy za nekatere končne točke, na katere nikakor ne moremo vplivati, na primer končne točke istega s3 - ne moremo poskušati dvigniti nove storitve in dobiti drugačne ip, še vedno moraš priti tja. V samo nekaj dneh smo te strežnike postavili, spravili v pogon in se nasploh pripravili na trenutek, ko se je začela blokada. Zanimivo je, da je RKN ob pogledu na hrup in paniko rekel: "Ne, zdaj ne bomo ničesar blokirali." (A to točno do trenutka, ko se je Telegram začel blokirati.) Ko smo vzpostavili obvodne zmogljivosti in ugotovili, da blokada ni bila uvedena, pa se nismo lotili reševanja celotne zadeve. Ja, za vsak slučaj.
In leta 2019 še vedno živimo v pogojih blokade. Sinoči sem pogledal: približno milijon IP-jev je še naprej blokiranih. Res je, Amazon je bil skoraj popolnoma odblokiran, na vrhuncu je dosegel 20 milijonov naslovov ... Na splošno je realnost taka, da morda ni koherence, dobre koherence. Nenadoma. Morda ne obstaja zaradi tehničnih razlogov - požari, bagri, vse to. Ali, kot smo videli, ne povsem tehnično. Zato lahko nekdo velik in velik, s svojimi AS-i, verjetno to uredi na druge načine - direktna povezava in ostalo je že na nivoju l2. Ampak v enostavni različici, kot je naša ali še manjša, lahko imaš za vsak slučaj redundanco na nivoju strežnikov, dvignjenih nekje drugje, vnaprej konfiguriran vpn, proxy, z možnostjo hitrega preklopa konfiguracije na njih v tistih segmentih. ki so ključnega pomena za vašo povezljivost. To nam je večkrat prišlo prav, ko se je začela blokada Amazona, v najslabšem primeru smo dovolili samo S3 promet preko njih, a postopoma se je vse to rešilo.
Kako rezervirati ... celotnega ponudnika?
Trenutno nimamo scenarija v primeru, da celoten Amazon propade. Podoben scenarij imamo za Rusijo. V Rusiji nas je gostil en ponudnik, med katerim smo se odločili za več lokacij. In pred enim letom smo se soočili s težavo: čeprav gre za dva podatkovna centra, lahko pride do težav že na nivoju konfiguracije omrežja ponudnika, ki bodo vseeno vplivale na oba podatkovna centra. In morda bomo na koncu nedosegljivi na obeh straneh. Seveda se je to zgodilo. Na koncu smo ponovno razmislili o notranji arhitekturi. Ni se veliko spremenilo, vendar imamo za Rusijo zdaj dve strani, ki nista od istega ponudnika, ampak od dveh različnih. Če ena odpove, lahko preidemo na drugo.
Hipotetično za Amazon razmišljamo o možnosti rezervacije na nivoju drugega ponudnika; morda Google, morda kdo drug ... Toda doslej smo v praksi opazili, da medtem ko ima Amazon nesreče na ravni enega območja razpoložljivosti, so nesreče na ravni celotne regije precej redke. Zato imamo teoretično idejo, da bi lahko naredili pridržek »Amazon ni Amazon«, vendar v praksi še ni tako.
Nekaj besed o avtomatizaciji
Je avtomatizacija vedno potrebna? Tukaj je primerno spomniti se na Dunning-Krugerjev učinek. Na osi “x” je naše znanje in izkušnje, ki jih pridobimo, na osi “y” pa zaupanje v naša dejanja. Sprva ne vemo ničesar in sploh nismo prepričani. Potem malo vemo in postanemo mega samozavestni - to je tako imenovani "vrhunec neumnosti", ki ga dobro ponazarja slika "demenca in pogum". Potem smo se malo naučili in smo pripravljeni na boj. Potem pa stopimo na megahude napake in se znajdemo v dolini obupa, ko se nam zdi, da nekaj vemo, v resnici pa ne vemo veliko. Potem, ko pridobivamo izkušnje, postajamo bolj samozavestni.
Našo logiko o različnih samodejnih preklopih na določene nesreče zelo dobro opisuje ta graf. Začeli smo - nismo vedeli, kako narediti ničesar, skoraj vse delo je bilo opravljeno ročno. Potem smo ugotovili, da lahko na vse priklopimo avtomatizacijo in tako mirno spimo. In nenadoma stopimo na mega-rake: sproži se lažno pozitiven signal in preklapljamo promet naprej in nazaj, ko tega v dobrem smislu ne bi smeli storiti. Posledično se replikacija pokvari ali kaj drugega - to je prava dolina obupa. In potem pridemo do razumevanja, da se moramo vsega lotiti pametno. To pomeni, da se je smiselno zanašati na avtomatizacijo, ki zagotavlja možnost lažnih alarmov. Ampak! če so posledice lahko uničujoče, potem je bolje, da to prepustimo dežurnemu, dežurnim inženirjem, ki bodo poskrbeli in spremljali, da res pride do nesreče, in bodo ročno izvedli potrebna dejanja ...
Zaključek
V 7 letih smo šli od dejstva, da ko nekaj pade, je nastala panika-panika, do razumevanja, da problemi ne obstajajo, so samo naloge, ki jih je treba – in mogoče – rešiti. Ko gradite storitev, jo poglejte od zgoraj, ocenite vsa tveganja, ki se lahko zgodijo. Če jih opazite takoj, potem vnaprej poskrbite za redundanco in možnost izgradnje infrastrukture, odporne na napake, kajti vsaka točka, ki lahko odpove in povzroči nedelovanje storitve, bo to zagotovo storila. In tudi če se vam zdi, da nekateri elementi infrastrukture zagotovo ne bodo odpovedali - na primer isti s3, še vedno ne pozabite, da lahko. In vsaj v teoriji imejte idejo, kaj boste storili z njimi, če se kaj zgodi. Imejte načrt za obvladovanje tveganja. Ko razmišljate o tem, da bi vse naredili samodejno ali ročno, ocenite tveganja: kaj se bo zgodilo, če bo avtomatika začela vse preklapljati – ali ne bo to povzročilo še hujše situacije v primerjavi z nesrečo? Morda je nekje treba uporabiti razumen kompromis med uporabo avtomatizacije in reakcijo dežurnega inženirja, ki bo ocenil realno sliko in razumel, ali je treba nekaj preklopiti na kraju samem ali "da, vendar ne zdaj."
Razumen kompromis med perfekcionizmom in resničnim trudom, časom, denarjem, ki ga lahko porabite za shemo, ki jo boste na koncu imeli.
To besedilo je posodobljena in razširjena različica poročila Aleksandra Demidova na konferenci .
Vir: www.habr.com