I dag har Bitrix24-tjenesten ikke hundredvis af gigabits trafik, og den har heller ikke en kæmpe flåde af servere (selvom der selvfølgelig er en del eksisterende). Men for mange kunder er det det vigtigste værktøj til at arbejde i virksomheden; det er en rigtig forretningskritisk applikation. Derfor er der ingen måde at falde på. Hvad hvis styrtet skete, men tjenesten "kom sig" så hurtigt, at ingen bemærkede noget? Og hvordan er det muligt at implementere failover uden at miste kvaliteten af arbejdet og antallet af klienter? Alexander Demidov, direktør for cloud-tjenester hos Bitrix24, talte for vores blog om, hvordan reservationssystemet har udviklet sig i løbet af de 7 år af produktets eksistens.
"Vi lancerede Bitrix24 som en SaaS for 7 år siden. Den største vanskelighed var sandsynligvis følgende: før det blev lanceret offentligt som SaaS, eksisterede dette produkt simpelthen i formatet af en boksløsning. Kunder købte det af os, hostede det på deres servere, oprettede en virksomhedsportal - en generel løsning til medarbejderkommunikation, fillagring, opgavestyring, CRM, det er alt. Og i 2012 besluttede vi, at vi ville lancere det som SaaS, administrere det selv og sikre fejltolerance og pålidelighed. Vi fik erfaring undervejs, for indtil da havde vi det simpelthen ikke – vi var kun softwareproducenter, ikke serviceudbydere.
Ved lanceringen af tjenesten forstod vi, at det vigtigste er at sikre fejltolerance, pålidelighed og konstant tilgængelighed af tjenesten, for hvis du har en simpel almindelig hjemmeside, for eksempel en butik, og den falder på dig og sidder der for en time, kun du lider, du mister ordrer, du mister kunder, men for din klient selv er dette ikke særlig kritisk for ham. Han var selvfølgelig ked af det, men han gik hen og købte den på en anden side. Og hvis dette er en applikation, hvor alt arbejdet i virksomheden, kommunikation, beslutninger er bundet, så er det vigtigste at vinde brugernes tillid, det vil sige ikke at svigte dem og ikke at falde. Fordi alt arbejde kan stoppe, hvis noget indeni ikke virker.
Bitrix.24 som SaaS
Vi samlede den første prototype et år før den offentlige lancering, i 2011. Vi samlede den på omkring en uge, så på den, snurrede den - den virkede endda. Det vil sige, du kunne gå ind i formularen, indtaste navnet på portalen der, en ny portal ville åbne, og en brugerbase ville blive oprettet. Vi kiggede på det, vurderede produktet i princippet, skrottede det og fortsatte med at forfine det i et helt år. Fordi vi havde en stor opgave: vi ville ikke lave to forskellige kodebaser, vi ville ikke understøtte et separat pakket produkt, separate cloud-løsninger - vi ville gøre det hele inden for én kode.
En typisk webapplikation på det tidspunkt var én server, hvorpå noget PHP-kode kører, en mysql-database, filer uploades, dokumenter, billeder lægges i uploadmappen - jamen, det hele virker. Ak, det er umuligt at lancere en kritisk stabil webtjeneste ved hjælp af denne. Der understøttes distribueret cache ikke, databasereplikering understøttes ikke.
Vi formulerede kravene: dette er evnen til at være placeret forskellige steder, understøtte replikering og ideelt set være placeret i forskellige geografisk distribuerede datacentre. Adskil produktlogikken og faktisk datalagring. Kunne dynamisk skalere efter belastningen og helt tolerere statik. Ud fra disse overvejelser opstod faktisk kravene til produktet, som vi har finpudset i løbet af året. I løbet af denne tid, i platformen, som viste sig at være samlet - for boxed-løsninger, til vores egen service - lavede vi support til de ting, vi havde brug for. Understøttelse af mysql-replikering på selve produktets niveau: det vil sige, at udvikleren, der skriver koden, ikke tænker på, hvordan hans anmodninger vil blive distribueret, han bruger vores api, og vi ved, hvordan man korrekt distribuerer skrive- og læseanmodninger mellem mastere og slaver.
Vi har lavet support på produktniveau til forskellige cloud-objektlager: google storage, amazon s3 plus support til open stack swift. Derfor var dette praktisk både for os som en service og for udviklere, der arbejder med en pakket løsning: hvis de bare bruger vores API til arbejdet, tænker de ikke på, hvor filen i sidste ende bliver gemt, lokalt på filsystemet eller i objektfillageret.
Som et resultat besluttede vi straks, at vi ville reservere på niveau med hele datacenteret. I 2012 lancerede vi helt på Amazon AWS, fordi vi allerede havde erfaring med denne platform - vores egen hjemmeside var hostet der. Vi var tiltrukket af det faktum, at Amazon i hver region har flere tilgængelighedszoner - faktisk (i deres terminologi) flere datacentre, der er mere eller mindre uafhængige af hinanden og giver os mulighed for at reservere på niveau med et helt datacenter: hvis det pludselig mislykkes, replikeres databaserne master-master, webapplikationsserverne sikkerhedskopieres, og de statiske data flyttes til s3-objektlageret. Belastningen er balanceret - på det tidspunkt af Amazon elb, men lidt senere kom vi til vores egne load balancers, fordi vi havde brug for mere kompleks logik.
Det, de ville have, er, hvad de fik...
Alle de grundlæggende ting, som vi ville sikre - fejltolerance på selve serverne, webapplikationer, databaser - alt fungerede godt. Det enkleste scenarie: Hvis en af vores webapplikationer fejler, så er alt enkelt - de er slukket for balancering.
Balanceren (dengang var det Amazons elb) markerede maskiner, der var ude af drift, som usunde og slukkede for belastningsfordeling på dem. Amazon autoskalering virkede: når belastningen voksede, blev der tilføjet nye maskiner til autoskaleringsgruppen, belastningen blev fordelt på nye maskiner - alt var i orden. Med vores balancere er logikken omtrent den samme: Hvis der sker noget med applikationsserveren, fjerner vi anmodninger fra den, smider disse maskiner ud, starter nye og fortsætter med at arbejde. Ordningen har ændret sig lidt gennem årene, men fortsætter med at fungere: den er enkel, forståelig, og der er ingen vanskeligheder med den.
Vi arbejder over hele verden, kundebelastningstoppene er helt anderledes, og på en mindelig måde bør vi være i stand til at udføre visse serviceopgaver på alle komponenter i vores system til enhver tid - ubemærket af kunderne. Derfor har vi mulighed for at slukke for databasen fra drift og omfordele belastningen til et andet datacenter.
Hvordan fungerer det hele? — Vi skifter trafik til et fungerende datacenter - hvis der sker en ulykke i datacentret, så fuldstændigt, hvis dette er vores planlagte arbejde med én database, så skifter vi en del af trafikken, der betjener disse klienter til et andet datacenter, og suspenderer det replikation. Hvis der er behov for nye maskiner til webapplikationer, fordi belastningen på det andet datacenter er øget, starter de automatisk. Vi afslutter arbejdet, replikeringen gendannes, og vi returnerer hele belastningen. Hvis vi skal spejle noget arbejde i den anden DC, for eksempel installere systemopdateringer eller ændre indstillinger i den anden database, så gentager vi generelt det samme, bare i den anden retning. Og hvis dette er et uheld, så gør vi alt trivielt: vi bruger hændelseshåndteringsmekanismen i overvågningssystemet. Hvis flere kontroller udløses, og status bliver kritisk, kører vi denne handler, en handler, der kan udføre denne eller hin logik. For hver database angiver vi, hvilken server der er failover for den, og hvor trafikken skal skiftes, hvis den ikke er tilgængelig. Historisk set bruger vi nagios eller nogle af dens gafler i en eller anden form. I princippet findes lignende mekanismer i næsten ethvert overvågningssystem; vi bruger ikke noget mere komplekst endnu, men måske vil vi en dag. Nu udløses overvågning af utilgængelighed og har mulighed for at skifte noget.
Har vi reserveret alt?
Vi har mange kunder fra USA, mange kunder fra Europa, mange kunder, der er tættere på Østen - Japan, Singapore og så videre. Selvfølgelig er en stor del af kunderne i Rusland. Det vil sige, at arbejdet ikke er i én region. Brugere ønsker et hurtigt svar, der er krav om at overholde forskellige lokale love, og inden for hver region reserverer vi to datacentre, plus der er nogle ekstra tjenester, som igen er praktiske at placere inden for én region - for kunder, der er i denne region arbejder. REST-handlere, autorisationsservere, de er mindre kritiske for driften af klienten som helhed, du kan skifte igennem dem med en lille acceptabel forsinkelse, men du vil ikke genopfinde hjulet for, hvordan man overvåger dem, og hvad man skal gøre med dem. Derfor forsøger vi at udnytte eksisterende løsninger maksimalt, frem for at udvikle en form for kompetence inden for yderligere produkter. Og et eller andet sted bruger vi trivielt switching på DNS-niveau, og vi bestemmer tjenestens livlighed ved den samme DNS. Amazon har en Route 53-tjeneste, men det er ikke kun en DNS, som du kan indtaste, og det er det – det er meget mere fleksibelt og bekvemt. Gennem det kan du bygge geo-distribuerede tjenester med geolokationer, når du bruger det til at bestemme, hvor klienten kom fra og give ham visse poster - med dens hjælp kan du bygge failover-arkitekturer. De samme sundhedstjek er konfigureret i selve Route 53, du indstiller de endepunkter, der overvåges, indstiller metrics, indstiller hvilke protokoller, der skal bestemme "liveness" af tjenesten - tcp, http, https; indstille hyppigheden af kontroller, der afgør, om tjenesten er i live eller ej. Og i selve DNS'en angiver du, hvad der skal være primært, hvad der skal være sekundært, hvor du skal skifte, hvis sundhedstjekket udløses inde på rute 53. Alt dette kan gøres med nogle andre værktøjer, men hvorfor er det praktisk - vi indstiller det op en gang og så slet ikke tænke over det, hvordan vi kontrollerer, hvordan vi skifter: alt fungerer af sig selv.
Det første "men": hvordan og med hvad reserverer man selve rute 53? Hvem ved, hvad hvis der sker ham noget? Heldigvis trådte vi aldrig på denne rake, men igen, jeg vil have en historie forud for, hvorfor vi troede, at vi stadig skulle reservere. Her lagde vi sugerør ud til os selv på forhånd. Flere gange om dagen foretager vi en komplet aflæsning af alle de zoner, vi har i rute 53. Amazons API giver dig mulighed for nemt at sende dem i JSON, og vi har flere backup-servere, hvor vi konverterer det, uploader det i form af configs og har groft sagt en backup-konfiguration. Hvis der sker noget, kan vi hurtigt implementere det manuelt uden at miste DNS-indstillingsdataene.
Andet "men": Hvad på dette billede er endnu ikke reserveret? Selve balanceren! Vores fordeling af kunder efter region er gjort meget enkel. Vi har domænerne bitrix24.ru, bitrix24.com, .de - nu er der 13 forskellige, som opererer i en række forskellige zoner. Vi kom frem til følgende: Hver region har sine egne balancere. Dette gør det mere bekvemt at fordele på tværs af regioner, afhængigt af hvor spidsbelastningen på netværket er. Hvis dette er en fejl på niveau med en enkelt balancer, så tages den simpelthen ud af drift og fjernes fra dns. Hvis der er et eller andet problem med en gruppe balancere, så bliver de sikkerhedskopieret på andre sider, og skift mellem dem sker ved hjælp af samme rute53, fordi på grund af den korte TTL, sker skift inden for maksimalt 2, 3, 5 minutter .
Tredje "men": Hvad er endnu ikke reserveret? S3, korrekt. Da vi placerede de filer, som vi gemmer for brugere i s3, troede vi oprigtigt, at det var panserbrydende, og der var ingen grund til at reservere noget der. Men historien viser, at tingene sker anderledes. Generelt beskriver Amazon S3 som en fundamental service, fordi Amazon selv bruger S3 til at gemme maskinbilleder, konfigurationer, AMI-billeder, snapshots... Og hvis s3 går ned, som det skete en gang i løbet af disse 7 år, så længe vi har brugt bitrix24, den følger den som en fan Der er en hel masse ting, der dukker op - manglende evne til at starte virtuelle maskiner, api-fejl og så videre.
Og S3 kan falde - det skete en gang. Derfor kom vi frem til følgende ordning: For nogle år siden var der ingen seriøse offentlige objektopbevaringsfaciliteter i Rusland, og vi overvejede muligheden for at gøre noget af vores eget... Heldigvis begyndte vi ikke at gøre dette, for vi ville har gravet i den ekspertise, som vi ikke har, vi har, og ville sandsynligvis rode. Nu har Mail.ru s3-kompatibel lagerplads, Yandex har det, og en række andre udbydere har det. Til sidst kom vi til den idé, at vi for det første ville have backup, og for det andet evnen til at arbejde med lokale kopier. Specifikt til den russiske region bruger vi Mail.ru Hotbox-tjenesten, som er API-kompatibel med s3. Vi behøvede ingen større ændringer af koden inde i applikationen, og vi lavede følgende mekanisme: i s3 er der triggere, der udløser oprettelse/sletning af objekter, Amazon har en tjeneste kaldet Lambda - dette er en serverløs lancering af kode som vil blive udført, lige når visse triggere udløses.
Vi gjorde det meget enkelt: Hvis vores trigger udløses, udfører vi kode, der kopierer objektet til Mail.ru-lageret. For fuldt ud at starte arbejdet med lokale kopier af data, har vi også brug for omvendt synkronisering, så kunder, der er i det russiske segment, kan arbejde med lager, der er tættere på dem. Mail er ved at fuldføre triggere i sin lagring - det vil være muligt at udføre omvendt synkronisering på infrastrukturniveau, men indtil videre gør vi dette på niveau med vores egen kode. Hvis vi ser, at en klient har postet en fil, placerer vi på kodeniveau hændelsen i en kø, behandler den og laver omvendt replikering. Hvorfor det er dårligt: Hvis vi udfører en eller anden form for arbejde med vores objekter uden for vores produkt, det vil sige på en eller anden måde eksternt, tager vi det ikke i betragtning. Derfor venter vi til slutningen, hvor triggere dukker op på lagerniveauet, så uanset hvor vi eksekverer koden fra, bliver objektet, der kom til os, kopieret i den anden retning.
På kodeniveau registrerer vi begge lagre for hver klient: den ene betragtes som den vigtigste, den anden betragtes som en backup. Hvis alt er i orden, arbejder vi med lageret, der er tættere på os: det vil sige, vores kunder, der er i Amazon, de arbejder med S3, og dem, der arbejder i Rusland, de arbejder med Hotbox. Hvis flaget udløses, skal failover være forbundet, og vi skifter klienter til et andet lager. Vi kan afkrydse dette felt uafhængigt efter region og kan skifte dem frem og tilbage. Vi har ikke brugt dette i praksis endnu, men vi har sørget for denne mekanisme, og vi tror, at vi en dag får brug for netop denne switch og kommer til nytte. Dette er allerede sket en gang.
Åh, og Amazon løb væk...
Denne april markerer årsdagen for begyndelsen af Telegram-blokering i Rusland. Den mest berørte udbyder, der faldt ind under dette, er Amazon. Og desværre led russiske virksomheder, der arbejdede for hele verden, mere.
Hvis virksomheden er global, og Rusland er et meget lille segment for det, 3-5% - ja, på en eller anden måde kan du ofre dem.
Hvis dette er et rent russisk firma - jeg er sikker på, at det skal placeres lokalt - ja, det vil simpelthen være bekvemt for brugerne selv, behageligt, og der vil være færre risici.
Hvad hvis dette er en virksomhed, der opererer globalt og har omtrent lige mange kunder fra Rusland og andre steder i verden? Forbindelsen mellem segmenterne er vigtig, og de skal arbejde sammen på den ene eller anden måde.
I slutningen af marts 2018 sendte Roskomnadzor et brev til de største operatører om, at de planlagde at blokere flere millioner Amazon-IP'er for at blokere... Zello messenger. Takket være de samme udbydere - det lykkedes dem at lække brevet til alle, og der var en forståelse for, at forbindelsen med Amazon kunne falde fra hinanden. Det var fredag, vi løb i panik til vores kolleger fra servers.ru og sagde: "Venner, vi har brug for flere servere, der ikke vil være placeret i Rusland, ikke i Amazon, men for eksempel et sted i Amsterdam," for at for i det mindste på en eller anden måde at kunne installere vores egen VPN og proxy der for nogle endepunkter, som vi ikke kan påvirke på nogen måde, for eksempel endponts af samme s3 - vi kan ikke forsøge at rejse en ny tjeneste og få en anden ip, vi skal du stadig nå dertil. På blot et par dage satte vi disse servere op, fik dem op at køre og forberedte os generelt på det øjeblik, hvor blokeringen begyndte. Det er mærkeligt, at RKN, der kiggede på balladen og panikken, sagde: "Nej, vi vil ikke blokere noget nu." (Men dette er præcis indtil det øjeblik, hvor Telegram begyndte at blive blokeret.) Efter at have sat bypass-funktionerne op og indset, at blokeringen ikke var blevet indført, begyndte vi dog ikke at ordne hele sagen. Ja, for en sikkerheds skyld.
Og i 2019 lever vi stadig under forhold med blokering. Jeg kiggede i går aftes: omkring en million IP'er er fortsat blokeret. Sandt nok var Amazon næsten fuldstændig ophævet, på sit højeste nåede det 20 millioner adresser... Generelt er virkeligheden, at der måske ikke er sammenhæng, god sammenhæng. Pludselig. Det eksisterer måske ikke af tekniske årsager - brande, gravemaskiner, alt det der. Eller, som vi har set, ikke helt teknisk. Derfor kan nogen store og store, med deres egne AS'er, sikkert klare dette på andre måder - direct connect og andre ting er allerede på l2 niveau. Men i en simpel version, som vores eller endnu mindre, kan du, for en sikkerheds skyld, have redundans på niveauet med servere rejst et andet sted, konfigureret på forhånd vpn, proxy, med mulighed for hurtigt at skifte konfigurationen til dem i disse segmenter der er afgørende for din tilslutning. Dette var nyttigt for os mere end én gang, da Amazons blokering begyndte; i værste fald tillod vi kun S3-trafik gennem dem, men efterhånden blev alt dette løst.
Hvordan reserverer man... en hel udbyder?
Lige nu har vi ikke et scenarie, hvis hele Amazonas går ned. Vi har et lignende scenarie for Rusland. I Rusland blev vi hostet af én udbyder, fra hvem vi valgte at have flere websteder. Og for et år siden stod vi over for et problem: Selvom det er to datacentre, kan der være problemer allerede på niveau med udbyderens netværkskonfiguration, som stadig vil påvirke begge datacentre. Og vi kan ende med at være utilgængelige på begge sider. Det er selvfølgelig det, der skete. Vi endte med at genoverveje arkitekturen indeni. Det har ikke ændret sig ret meget, men for Rusland har vi nu to websteder, som ikke er fra samme udbyder, men fra to forskellige. Hvis det ene fejler, kan vi skifte til det andet.
Hypotetisk, for Amazon overvejer vi muligheden for reservation på niveau med en anden udbyder; måske Google, måske en anden... Men indtil videre har vi observeret i praksis, at mens Amazon har ulykker på niveau med én tilgængelighedszone, er ulykker på niveau med en hel region ret sjældne. Derfor har vi teoretisk set den idé, at vi måske foretager en "Amazon is not Amazon" reservation, men i praksis er det endnu ikke tilfældet.
Et par ord om automatisering
Er automatisering altid nødvendigt? Her er det passende at minde om Dunning-Kruger-effekten. På "x"-aksen er vores viden og erfaring, som vi opnår, og på "y"-aksen er tillid til vores handlinger. Først ved vi ingenting og er slet ikke sikre. Så ved vi lidt og bliver mega-sikre - det er den såkaldte "top af dumhed", godt illustreret af billedet "demens og mod". Så har vi lært lidt og er klar til at gå i kamp. Så træder vi på nogle mega-alvorlige fejl og befinder os i en fortvivlelses dal, når vi tilsyneladende ved noget, men faktisk ikke ved meget. Så, efterhånden som vi får erfaring, bliver vi mere selvsikre.
Vores logik omkring forskellige automatiske skift til bestemte ulykker er meget godt beskrevet af denne graf. Vi startede - vi vidste ikke, hvordan vi skulle gøre noget, næsten alt arbejde blev udført i hånden. Så indså vi, at vi kunne knytte automatisering til alting og ligesom sove roligt. Og pludselig træder vi på en mega-rive: en falsk positiv udløses, og vi skifter trafik frem og tilbage, når vi på en god måde ikke skulle have gjort dette. Følgelig bryder replikationen sammen eller noget andet - dette er selve fortvivlelsens dal. Og så kommer vi til den forståelse, at vi skal gribe alt fornuftigt an. Det vil sige, at det giver mening at stole på automatisering, hvilket giver mulighed for falske alarmer. Men! hvis konsekvenserne kan være ødelæggende, så er det bedre at overlade det til vagtskiftet, til de vagthavende ingeniører, som vil sørge for og overvåge, at der virkelig er en ulykke, og vil udføre de nødvendige handlinger manuelt...
Konklusion
I løbet af 7 år gik vi fra, at når noget faldt, var der panik-panik, til forståelsen af, at problemer ikke findes, der er kun opgaver, de skal - og kan - løses. Når du bygger en service, så se på den fra oven, vurder alle de risici, der kan ske. Hvis du ser dem med det samme, så sørg for redundans på forhånd og muligheden for at bygge en fejltolerant infrastruktur, fordi ethvert punkt, der kan fejle og føre til tjenestens ubrugelighed, vil helt sikkert gøre det. Og selvom det ser ud til, at nogle elementer i infrastrukturen absolut ikke vil fejle - som den samme s3, så husk stadig på, at de kan. Og i det mindste i teorien, hav en idé om, hvad du vil gøre med dem, hvis der sker noget. Hav en risikostyringsplan. Når du tænker på at gøre alting automatisk eller manuelt, så vurder risiciene: hvad sker der, hvis automatiseringen begynder at skifte alt - vil det ikke føre til en endnu værre situation sammenlignet med en ulykke? Måske et eller andet sted er det nødvendigt at bruge et rimeligt kompromis mellem brugen af automatisering og reaktionen fra den vagthavende ingeniør, som vil vurdere det reelle billede og forstå, om noget skal skiftes på stedet eller "ja, men ikke nu."
Et rimeligt kompromis mellem perfektionisme og reel indsats, tid, penge, som du kan bruge på den ordning, du i sidste ende vil have.
Denne tekst er en opdateret og udvidet version af Alexander Demidovs rapport på konferencen .
Kilde: www.habr.com