<\/a><\/noindex>A szolg\u00e1ltat\u00e1s ind\u00edt\u00e1sakor tudtuk, hogy a legfontosabb a hibat\u0171r\u00e9s, megb\u00edzhat\u00f3s\u00e1g \u00e9s a szolg\u00e1ltat\u00e1s folyamatos el\u00e9rhet\u0151s\u00e9ge, mert ha van egy sima weboldalad, p\u00e9ld\u00e1ul egy bolt, \u00e9s az le\u00e1ll egy \u00f3r\u00e1ra \u2013 akkor csak te magad szenvedsz, elvesz\u00edted a rendel\u00e9seket, elvesz\u00edted az \u00fcgyfeleket, de a te \u00fcgyfeled sz\u00e1m\u00e1ra ez nem olyan kritikus. Persze csal\u00f3dott, de elmegy \u00e9s v\u00e1s\u00e1rol egy m\u00e1sik weboldalon. De ha ez egy alkalmaz\u00e1s, amelyre a c\u00e9g munk\u00e1ja, kommunik\u00e1ci\u00f3ja \u00e9s d\u00f6nt\u00e9sei \u00e9p\u00fclnek, akkor a legfontosabb az, hogy megszerezz\u00fck a felhaszn\u00e1l\u00f3k bizalm\u00e1t, teh\u00e1t nem szabad \u0151ket cserben hagyni \u00e9s le\u00e1llni. Mert ha valami bel\u00fcl nem m\u0171k\u00f6dik, az eg\u00e9sz munka megakad.<\/p>\n
Bitrix24 mint SaaS<\/h4>\n \nAz els\u0151 protot\u00edpust egy \u00e9vvel a nyilv\u00e1nos ind\u00edt\u00e1s el\u0151tt, 2011-ben \u00e1ll\u00edtottuk \u00f6ssze. K\u00f6r\u00fclbel\u00fcl egy h\u00e9t alatt megvolt, megn\u00e9zt\u00fck, megforgattuk \u2013 m\u00e9g m\u0171k\u00f6d\u0151k\u00e9pes is volt. Teh\u00e1t be lehetett l\u00e9pni az \u0171rlapba, megadni a port\u00e1l nev\u00e9t, \u00e9s egy \u00faj port\u00e1lhoz jutottunk el, fel\u00e9p\u00fclt a felhaszn\u00e1l\u00f3i adatb\u00e1zis. Megn\u00e9zt\u00fck, \u00e9rt\u00e9kelt\u00fck a term\u00e9ket, majd bez\u00e1rtuk, \u00e9s egy eg\u00e9sz \u00e9vig tov\u00e1bb dolgoztunk rajta. Mert nagy c\u00e9lunk volt: nem akartunk k\u00e9t k\u00fcl\u00f6nb\u00f6z\u0151 k\u00f3dalapot k\u00e9sz\u00edteni, nem akartunk k\u00fcl\u00f6n box term\u00e9ket \u00e9s k\u00fcl\u00f6n felh\u0151megold\u00e1sokat fenntartani - mindezt egy k\u00f3d keretein bel\u00fcl szerett\u00fck volna megval\u00f3s\u00edtani. <\/p>\n
Megfogalmaztuk az ig\u00e9nyeket: az a k\u00e9pess\u00e9g, hogy k\u00fcl\u00f6nb\u00f6z\u0151 helysz\u00edneken helyezkedjen el, t\u00e1mogassa a replik\u00e1ci\u00f3t, ide\u00e1lisan k\u00fcl\u00f6nb\u00f6z\u0151 f\u00f6ldrajzilag elosztott adatk\u00f6zpontokban. El kell v\u00e1lasztani a term\u00e9k logik\u00e1j\u00e1t \u00e9s mag\u00e1t az adatokat. Dinamikusan k\u00e9pesnek kell lennie a terhel\u00e9s sk\u00e1l\u00e1z\u00e1s\u00e1ra, a statikus tartalmat pedig teljesen ki kell emelni. Ezekb\u0151l a szempontokb\u00f3l alakultak ki a term\u00e9k ig\u00e9nyei, amelyet pontosan egy \u00e9ven \u00e1t finom\u00edtottunk. Ebben az id\u0151szakban a platform, amely v\u00e9g\u00fcl egys\u00e9ges lett - a dobozos megold\u00e1sokhoz, a saj\u00e1t szolg\u00e1ltat\u00e1sunkhoz - t\u00e1mogat\u00e1st kapott azokra a dolgokra, amelyekre sz\u00fcks\u00e9g\u00fcnk volt. A mysql replik\u00e1ci\u00f3 t\u00e1mogat\u00e1sa mag\u00e1nak a term\u00e9knek a szintj\u00e9n: teh\u00e1t a fejleszt\u0151, aki a k\u00f3dot \u00edrja - nem kell gondolkodnia, vajon hogyan oszt\u00f3dnak a k\u00e9r\u00e9sei, haszn\u00e1lja a mi api-nkat, \u00e9s mi tudjuk helyesen elosztani a \u00edr\u00e1si \u00e9s olvas\u00e1si k\u00e9r\u00e9seket a mesterek \u00e9s a slave-ek k\u00f6z\u00f6tt. <\/p>\n
T\u00e1mogat\u00e1st ny\u00fajtottunk a term\u00e9k szintj\u00e9n k\u00fcl\u00f6nb\u00f6z\u0151 felh\u0151alap\u00fa objektumt\u00e1rol\u00f3khoz: google storage, amazon s3 - plusz, open stack swift t\u00e1mogat\u00e1sa. Ez\u00e9rt ez k\u00e9nyelmes volt sz\u00e1munkra mint szolg\u00e1ltat\u00e1s, \u00e9s a dobozos megold\u00e1ssal dolgoz\u00f3 fejleszt\u0151knek: ha egyszer\u0171en a mi api-nkat haszn\u00e1lj\u00e1k, nem kell gondolkodniuk, hol fog v\u00e9g\u00fcl a f\u00e1jl t\u00e1rol\u00f3dni, helyben a f\u00e1jlrendszeren vagy egy objektumt\u00e1rol\u00f3ba ker\u00fcl.<\/p>\n
V\u00e9g\u00fcl azonnal eld\u00f6nt\u00f6tt\u00fck, hogy az eg\u00e9sz adatk\u00f6zpontra fogunk tartal\u00e9kolni. 2012-ben teljes m\u00e9rt\u00e9kben az Amazon AWS-en indultunk, mert m\u00e1r volt tapasztalatunk ezzel a platformmal \u2013 a saj\u00e1t weboldalunk ott volt elhelyezve. Az vonzott benn\u00fcnket, hogy az Amazonban minden r\u00e9gi\u00f3ban t\u00f6bb el\u00e9rhet\u0151s\u00e9gi z\u00f3na van \u2013 l\u00e9nyeg\u00e9ben (a terminol\u00f3gi\u00e1juk szerint) t\u00f6bb adatk\u00f6zpont, amelyek t\u00f6bb\u00e9-kev\u00e9sb\u00e9 f\u00fcggetlenek egym\u00e1st\u00f3l, \u00e9s lehet\u0151v\u00e9 teszik a tartal\u00e9kol\u00e1st egy eg\u00e9sz adatk\u00f6zpont szintj\u00e9n: ha az elromlik, az adatb\u00e1zisok master-master m\u00f3don replik\u00e1l\u00f3dnak, a webalkalmaz\u00e1s szerverek tartal\u00e9kolva vannak, a statikus tartalom pedig az s3 objektumt\u00e1rol\u00f3ba ker\u00fclt. A terhel\u00e9s kiegyenl\u00edt\u00e9se \u2013 akkor az Amazon elb-j\u00e9vel, de kicsivel k\u00e9s\u0151bb saj\u00e1t terhel\u00e9smegoszt\u00f3inkhoz jutottunk, mert bonyolultabb logik\u00e1ra volt sz\u00fcks\u00e9g\u00fcnk. <\/p>\n
Amit akartunk \u2013 azt meg is kaptuk...<\/h4>\n \nMinden alapvet\u0151 dolgot, amit biztos\u00edtani akartunk \u2013 a szerverek, webalkalmaz\u00e1sok \u00e9s adatb\u00e1zisok megb\u00edzhat\u00f3s\u00e1g\u00e1t \u2013 mind j\u00f3l m\u0171k\u00f6d\u00f6tt. A legegyszer\u0171bb forgat\u00f3k\u00f6nyv: ha b\u00e1rmelyik webalkalmaz\u00e1sunk elromlik, akkor itt minden egyszer\u0171 \u2013 ki vannak kapcsolva a terhel\u00e9smegoszt\u00e1sb\u00f3l. <\/p>\n
Vil\u00e1gszerte dolgozunk, az \u00fcgyfelek terhel\u00e9si cs\u00facsai teljesen k\u00fcl\u00f6nb\u00f6z\u0151ek, \u00e9s igaz\u00e1b\u00f3l lehet\u0151s\u00e9get kell adnunk arra, hogy a rendszer\u00fcnk b\u00e1rmely komponens\u00e9vel b\u00e1rmikor karbantart\u00e1si munk\u00e1latokat v\u00e9gezhess\u00fcnk \u2013 az \u00fcgyfelek sz\u00e1m\u00e1ra \u00e9szrev\u00e9tlen\u00fcl. Ez\u00e9rt lehet\u0151s\u00e9g\u00fcnk van lekapcsolni az adatb\u00e1zist, a terhel\u00e9st pedig \u00e1thelyezve a m\u00e1sodik adatk\u00f6zpontra. <\/p>\n
Hogyan m\u0171k\u00f6dik ez az eg\u00e9sz? \u2014 A forgalmat a m\u0171k\u00f6d\u0151 adatk\u00f6zpontra ir\u00e1ny\u00edtjuk \u2014 ha ez egy adatk\u00f6zponti hiba, akkor teljesen, ha tervezett karbantart\u00e1s van egy adott adatb\u00e1zison, akkor a forgalom egy r\u00e9sz\u00e9t, amely ezeket az \u00fcgyfeleket szolg\u00e1lja ki, \u00e1tir\u00e1ny\u00edtjuk a m\u00e1sodik adatk\u00f6zpontra, a replik\u00e1ci\u00f3 pedig le\u00e1ll. Ha \u00faj g\u00e9pekre van sz\u00fcks\u00e9g webalkalmaz\u00e1sokhoz, mivel megn\u0151tt a terhel\u00e9s a m\u00e1sodik adatk\u00f6zpontban, akkor automatikusan elindulnak. A munk\u00e1latokat befejezz\u00fck, a replik\u00e1ci\u00f3 helyre\u00e1ll, \u00e9s vissza\u00e1ll\u00edtjuk az \u00f6sszes terhel\u00e9st. Ha t\u00fckr\u00f6zve kell v\u00e9gezni bizonyos munk\u00e1latokat a m\u00e1sodik DC-ben, p\u00e9ld\u00e1ul rendszerny\u0171jt\u00e9sek telep\u00edt\u00e9se vagy be\u00e1ll\u00edt\u00e1sok megv\u00e1ltoztat\u00e1sa a m\u00e1sodik adatb\u00e1zisban, akkor l\u00e9nyeg\u00e9ben ugyanazt ism\u00e9telj\u00fck meg, csak a m\u00e1sik ir\u00e1nyba. Ha viszont hiba t\u00f6rt\u00e9nik, akkor a legegyszer\u0171bben j\u00e1runk el: a monitoring rendszerben esem\u00e9nykezel\u0151 mechanizmust haszn\u00e1lunk. Ha t\u00f6bb ellen\u0151rz\u00e9s aktiv\u00e1l\u00f3dik, \u00e9s a st\u00e1tusz kritikusra v\u00e1lt, akkor elindul ez a kezel\u0151, amit k\u00fcl\u00f6nb\u00f6z\u0151 logik\u00e1k v\u00e9grehajt\u00e1s\u00e1ra terveztek. Minden adatb\u00e1zisunkhoz meg van hat\u00e1rozva, hogy melyik szerver a failover, \u00e9s hov\u00e1 kell \u00e1tir\u00e1ny\u00edtani a forgalmat, ha az nem \u00e9rhet\u0151 el. T\u00f6rt\u00e9nelmileg \u00fagy alakult, hogy valamilyen form\u00e1ban nagios-t vagy annak forkjait haszn\u00e1ljuk. Alapvet\u0151en ilyen mechanizmusok szinte b\u00e1rmilyen monitoring rendszerben el\u00e9rhet\u0151ek, egyel\u0151re nem haszn\u00e1lunk bonyolultabbat, de lehets\u00e9ges, hogy a j\u00f6v\u0151ben majd fogunk. Jelenleg a monitoring az el\u00e9rhetetlens\u00e9gre aktiv\u00e1l\u00f3dik, \u00e9s k\u00e9pes arra, hogy valamit \u00e1tir\u00e1ny\u00edtson.<\/p>\n
Mindent lefoglaltunk?<\/h4>\n \nSok \u00fcgyfel\u00fcnk van az Egyes\u00fclt \u00c1llamokb\u00f3l, sok \u00fcgyfel\u00fcnk van Eur\u00f3p\u00e1b\u00f3l, sok \u00fcgyfel\u00fcnk, aki k\u00f6zelebb van a Kelethez \u2013 Jap\u00e1n, Szingap\u00far \u00e9s \u00edgy tov\u00e1bb. Term\u00e9szetesen egy hatalmas r\u00e9sze az \u00fcgyfeleinknek Oroszorsz\u00e1gb\u00f3l sz\u00e1rmazik. Teh\u00e1t a munka nem korl\u00e1toz\u00f3dik egy r\u00e9gi\u00f3ra. A felhaszn\u00e1l\u00f3k gyors v\u00e1laszid\u0151t szeretn\u00e9nek, vannak k\u00f6vetelm\u00e9nyek, amelyek a k\u00fcl\u00f6nb\u00f6z\u0151 helyi t\u00f6rv\u00e9nyek betart\u00e1s\u00e1ra vonatkoznak, \u00e9s minden r\u00e9gi\u00f3n bel\u00fcl k\u00e9t adatk\u00f6zpontot rezerv\u00e1lunk, plusz vannak olyan kieg\u00e9sz\u00edt\u0151 szolg\u00e1ltat\u00e1sok, amelyeket megint csak k\u00e9nyelmes elhelyezni egy r\u00e9gi\u00f3n bel\u00fcl \u2013 azoknak az \u00fcgyfeleknek, akik ezen a ter\u00fcleten dolgoznak. A REST kezel\u0151k, az autoriz\u00e1l\u00f3 szerverek kev\u00e9sb\u00e9 kritikusak az \u00fcgyf\u00e9l \u00e1ltal\u00e1nos m\u0171k\u00f6d\u00e9se szempontj\u00e1b\u00f3l, ezeken egy kis elfogadhat\u00f3 k\u00e9sleltet\u00e9ssel lehet v\u00e1ltani, de nem akarjuk feltal\u00e1lni a ker\u00e9k \u00fajra, hogy hogyan kell ezeket monitorozni \u00e9s mit kell vel\u00fck csin\u00e1lni. Ez\u00e9rt a maximumot pr\u00f3b\u00e1ljuk kihozni a m\u00e1r megl\u00e9v\u0151 megold\u00e1sokb\u00f3l, \u00e9s nem fejleszt\u00fcnk egy \u00fajabb kompetenci\u00e1t kieg\u00e9sz\u00edt\u0151 term\u00e9kek ter\u00e9n. Valahol egyszer\u0171en dns szinten v\u00e1ltunk, \u00e9s a szolg\u00e1ltat\u00e1s \u00e9l\u00e9t \u00e9ppen a dns hat\u00e1rozza meg. Az Amazonn\u00e1l van a Route 53 szolg\u00e1ltat\u00e1s, de ez nem csak egy dns, amelybe fel tudod vinni a bejegyz\u00e9seket, \u00e9s k\u00e9sz \u2013 sokkal rugalmasabb \u00e9s k\u00e9nyelmesebb. Ezen kereszt\u00fcl geo-elosztott szolg\u00e1ltat\u00e1sokat lehet kialak\u00edtani geolok\u00e1ci\u00f3kkal, amikor ezen kereszt\u00fcl hat\u00e1rozod meg, honnan \u00e9rkezett az \u00fcgyf\u00e9l, \u00e9s adsz neki az egyes bejegyz\u00e9sekb\u0151l \u2013 ezen kereszt\u00fcl failover-architekt\u00far\u00e1kat lehet kialak\u00edtani. Ugyanazokat az health-checks-et a Route 53-ban lehet be\u00e1ll\u00edtani, ahol megadod az endpointokat, amelyeket monitorozni kell, megadod a metrik\u00e1kat, megadod, hogy mely protokollok seg\u00edts\u00e9g\u00e9vel hat\u00e1rozzuk meg a szolg\u00e1ltat\u00e1s \u201e\u00e9l\u0151s\u00e9g\u00e9t\u201d \u2013 tcp, http, https; megadod a vizsg\u00e1latok gyakoris\u00e1g\u00e1t, amely meghat\u00e1rozza, hogy a szolg\u00e1ltat\u00e1s \u00e9l-e vagy sem. A dns-ben pedig megadod, mi lesz az els\u0151dleges, mi lesz a m\u00e1sodlagos, hov\u00e1 kell v\u00e1ltani, ha a health-check a Route 53-ban aktiv\u00e1l\u00f3dik. Mindez m\u00e1s eszk\u00f6z\u00f6kkel is megval\u00f3s\u00edthat\u00f3, de az a k\u00e9nyelmes benne, hogy egyszer be\u00e1ll\u00edtod, \u00e9s ezut\u00e1n egy\u00e1ltal\u00e1n nem kell agg\u00f3dnunk azon, hogy hogyan zajlanak a vizsg\u00e1latok, hogyan t\u00f6rt\u00e9nik a v\u00e1lt\u00e1s: minden automatikusan m\u0171k\u00f6dik.<\/p>\n
Els\u0151 \u201ede\u201d<\/b>: Hogyan \u00e9s mivel k\u00e9sz\u00edts\u00fck el a backupot a Route 53-r\u00f3l? Ki tudja, mi t\u00f6rt\u00e9nhet vele? Szerencs\u00e9re eddig m\u00e9g nem \u00fctk\u00f6zt\u00fcnk hasonl\u00f3 helyzetbe, de h\u00e1t, el\u0151re meg fogom osztani, mi\u00e9rt is gondoltuk, hogy \u00e9rdemes m\u00e9gis biztons\u00e1gi ment\u00e9st k\u00e9sz\u00edteni. Itt el\u0151re h\u00fazunk egy biztos\u00edt\u00e9kot. Naponta t\u00f6bbsz\u00f6r teljes export\u00e1l\u00e1st v\u00e9gz\u00fcnk az \u00f6sszes z\u00f3n\u00e1r\u00f3l, amit a Route 53-ban l\u00e9trehoztunk. Az Amazon API-ja lehet\u0151v\u00e9 teszi, hogy ezeket nyugodtan \u00e1tadjuk JSON form\u00e1tumban, \u00e9s fel\u00e1ll\u00edtottunk n\u00e9h\u00e1ny backup szervert, ahov\u00e1 ezt konvert\u00e1ljuk, export\u00e1ljuk konfigur\u00e1ci\u00f3k\u00e9nt, \u00edgy tulajdonk\u00e9ppen van egy biztons\u00e1gi m\u00e1solatunk. Ha sz\u00fcks\u00e9ges, gyorsan k\u00e9zn\u00e9l van, amit manu\u00e1lisan telep\u00edthet\u00fcnk, \u00edgy nem vesz\u00edt\u00fcnk el semmif\u00e9le dns be\u00e1ll\u00edt\u00e1st.<\/p>\n
A m\u00e1sodik 'de'<\/b>: mi az, ami m\u00e9g nincs biztos\u00edtva? Maga a terhel\u00e9seloszt\u00f3! Az \u00fcgyfelek region\u00e1lis eloszt\u00e1s\u00e1t nagyon egyszer\u0171en megoldottuk. Van bitrix24.ru, bitrix24.com, .de domain\u00fcnk \u2013 most k\u00f6r\u00fclbel\u00fcl 13 k\u00fcl\u00f6nb\u00f6z\u0151, amelyek a legk\u00fcl\u00f6nf\u00e9l\u00e9bb z\u00f3n\u00e1kban m\u0171k\u00f6dnek. Arra a k\u00f6vetkeztet\u00e9sre jutottunk, hogy minden r\u00e9gi\u00f3ban saj\u00e1t terhel\u00e9seloszt\u00f3k legyenek. Ez k\u00e9nyelmesebb a r\u00e9gi\u00f3k k\u00f6z\u00f6tti eloszt\u00e1shoz, att\u00f3l f\u00fcgg\u0151en, hogy hol van a legnagyobb h\u00e1l\u00f3zati terhel\u00e9s. Ha egy adott terhel\u00e9seloszt\u00f3n\u00e1l hiba l\u00e9p fel, akkor azt egyszer\u0171en kivonjuk a forgalomb\u00f3l, \u00e9s elt\u00e1vol\u00edtjuk a DNS-b\u0151l. Ha t\u00f6bb terhel\u00e9seloszt\u00f3 csoportban mer\u00fcl fel probl\u00e9ma, akkor m\u00e1s helyeken biztos\u00edtj\u00e1k \u0151ket, \u00e9s a k\u00f6z\u00f6tt\u00fck val\u00f3 \u00e1tkapcsol\u00e1s ugyanazzal a Route 53-mal t\u00f6rt\u00e9nik, mert a r\u00f6vid TTL miatt a v\u00e1lt\u00e1s maximum 2, 3, 5 percen bel\u00fcl megt\u00f6rt\u00e9nik. <\/p>\n
A harmadik 'de'<\/b>: mi az, ami m\u00e9g nincs biztos\u00edtva? Az S3, igaz. Amikor a felhaszn\u00e1l\u00f3k \u00e1ltal t\u00e1rolt f\u00e1jlokat helyezz\u00fck el az S3-ban, \u0151szint\u00e9n hitt\u00fck, hogy az biztos, \u00e9s nincs sz\u00fcks\u00e9g a biztons\u00e1gi m\u00e1solatra. De a t\u00f6rt\u00e9nelem azt mutatja, hogy a dolgok m\u00e1sk\u00e9pp alakulnak. Az Amazon \u00e1ltal\u00e1ban az S3-at alapvet\u0151 szolg\u00e1ltat\u00e1sk\u00e9nt \u00edrja le, mert maga az Amazon is az S3-at haszn\u00e1lja virtu\u00e1lis g\u00e9pek k\u00e9peinek, konfigur\u00e1ci\u00f3knak, AMI k\u00e9peknek, pillanatk\u00e9pnek a t\u00e1rol\u00e1s\u00e1ra... \u00c9s ha az S3 le\u00e1ll, mint ahogy egyszer megt\u00f6rt\u00e9nt az elm\u00falt 7 \u00e9vben, ami\u00f3ta a Bitrix24-et haszn\u00e1ljuk, akkor rengeteg minden m\u00e1st is mag\u00e1val r\u00e1nt \u2014 a virtu\u00e1lis g\u00e9pek ind\u00edt\u00e1s\u00e1nak el\u00e9rhetetlens\u00e9ge, API m\u0171k\u00f6d\u00e9si hib\u00e1k, \u00e9s \u00edgy tov\u00e1bb. <\/p>\n
S3 is capable of failure \u2014 it happened once. Therefore, we came to the following conclusion: several years ago, there were no serious public object storage options in Russia, and we considered creating something of our own... Fortunately, we didn't start this, as we would have been buried in expertise we lacked and would have inevitably made mistakes. Now, there are S3-compatible storage solutions available from Mail.ru, Yandex, and several other providers. In the end, we realized that we want, firstly, redundancy, and secondly, the ability to work with local copies. For the specific Russian region, we use the Mail.ru Hotbox service, which is API-compatible with S3. We didn't need significant code changes in our application, and we implemented the following mechanism: there are triggers in S3 that activate on the creation\/deletion of objects, and Amazon has a service called Lambda \u2014 this is serverless code execution that occurs when those triggers are activated.<\/p>\n
A k\u00f3d szintj\u00e9n minden egyes \u00fcgyf\u00e9l sz\u00e1m\u00e1ra mindk\u00e9t t\u00e1rol\u00f3 be van \u00e1ll\u00edtva: az egyik f\u0151k\u00e9nt, a m\u00e1sik pedig biztons\u00e1gi m\u00e1solatk\u00e9nt m\u0171k\u00f6dik. Ha minden j\u00f3l megy, azzal a t\u00e1rol\u00f3val dolgozunk, amelyik k\u00f6zelebb van hozz\u00e1nk: p\u00e9ld\u00e1ul a mi \u00fcgyfeleink, akik az Amazonon vannak, az S3 at haszn\u00e1lj\u00e1k, m\u00edg akik Oroszorsz\u00e1gban dolgoznak, \u0151k a Hotbox-t haszn\u00e1lj\u00e1k. Ha aktiv\u00e1l\u00f3dik a kapcsol\u00f3, akkor failover-nek kell bekapcsolnia, \u00e9s \u00e1t\u00e1ll\u00edtjuk az \u00fcgyfeleket egy m\u00e1sik t\u00e1rol\u00f3ra. Ezt a kapcsol\u00f3t region\u00e1lisan f\u00fcggetlen\u00fcl tudjuk \u00e1ll\u00edtani, \u00e9s ide-oda kapcsolgatni. Gyakorlatban m\u00e9g nem haszn\u00e1ltuk, de ezt a mechanizmust el\u0151ir\u00e1nyoztuk, \u00e9s \u00fagy gondoljuk, hogy egyszer m\u00e9g sz\u00fcks\u00e9g\u00fcnk lesz az \u00e1tkapcsol\u00e1sra. Egyszer m\u00e1r megt\u00f6rt\u00e9nt ez. <\/p>\n
\u00d3, az Amazon elment t\u0151letek...<\/h4>\n \nId\u00e9n \u00e1prilisban van a Telegram oroszorsz\u00e1gi blokkol\u00e1sainak \u00e9vfordul\u00f3ja. A legjobban \u00e9rintett szolg\u00e1ltat\u00f3, aki \u00e1ldozatul esett ennek, az Amazon. Sajnos, az orosz c\u00e9gek, akik az eg\u00e9sz vil\u00e1gra dolgoztak, tov\u00e1bbi k\u00e1rokat szenvedtek el. <\/p>\n
Ha a c\u00e9g glob\u00e1lis \u00e9s Oroszorsz\u00e1g egy nagyon kis szegmenst k\u00e9pvisel sz\u00e1m\u00e1ra, 3-5% -ot, akkor \u00edgy vagy \u00fagy, \u00e1ldozatot kell hozni. <\/p>\n
Ha ez egy kifejezetten orosz c\u00e9g \u2014 biztos vagyok benne, hogy helyben kell m\u0171k\u00f6dni\u00fck \u2014 egyszer\u0171en a felhaszn\u00e1l\u00f3knak k\u00e9nyelmes lesz, az kock\u00e1zatok pedig cs\u00f6kkennek. <\/p>\n
De ha ez egy glob\u00e1lisan m\u0171k\u00f6d\u0151 c\u00e9g, amelynek k\u00f6r\u00fclbel\u00fcl egyenl\u0151 sz\u00e1m\u00fa \u00fcgyfele van Oroszorsz\u00e1gb\u00f3l \u00e9s vil\u00e1gszerte, akkor a szegmensek k\u00f6z\u00f6tti kapcsol\u00f3d\u00e1s fontos, \u00e9s ak\u00e1rmilyen m\u00f3don egy\u00fctt kell m\u0171k\u00f6dni\u00fck. <\/p>\n
M\u00e9g 2018 m\u00e1rcius v\u00e9g\u00e9n a Roskomnadzor levelet k\u00fcld\u00f6tt a legnagyobb szolg\u00e1ltat\u00f3knak, hogy tervezik n\u00e9h\u00e1ny milli\u00f3 amazon ip blokkol\u00e1s\u00e1t, hogy blokkolj\u00e1k... a Zello \u00fczenetk\u00fcld\u0151t. K\u00f6sz\u00f6nj\u00fck ezeknek a szolg\u00e1ltat\u00f3knak \u2014 sikeresen kisziv\u00e1rogtatt\u00e1k a levelet, \u00e9s vil\u00e1goss\u00e1 v\u00e1lt, hogy a kapcsol\u00f3d\u00e1s az Amazonhoz megszakadhat. Ez p\u00e9ntek volt, p\u00e1nikban futottunk a servers.ru koll\u00e9g\u00e1ihoz, mondv\u00e1n: \u201eBar\u00e1tok, sz\u00fcks\u00e9g\u00fcnk van n\u00e9h\u00e1ny szerverre, amelyek nem Oroszorsz\u00e1gban, nem az Amazonon, hanem p\u00e9ld\u00e1ul valahol Amszterdamban \u00e1llnak, hogy legal\u00e1bb valamilyen m\u00f3don telep\u00edthess\u00fck ott a saj\u00e1t vpn<\/a> \u00e9s proxy a bizonyos endpoint-okhoz, amelyekre nem tudunk hat\u00e1ssal lenni, p\u00e9ld\u00e1ul az S3 endpoint-ok \u2014 nem lehet \u00faj szolg\u00e1ltat\u00e1st l\u00e9trehozni \u00e9s m\u00e1s ip-t kapni, mindenk\u00e9ppen kapcsolatba kell l\u00e9pn\u00fcnk vel\u00fck. P\u00e1r nap alatt be\u00e1ll\u00edtottuk ezeket a szervereket, fel\u00e1ll\u00edtottuk, \u00e9s l\u00e9nyeg\u00e9ben felk\u00e9sz\u00fclt\u00fcnk a blokkol\u00e1sok kezdet\u00e9re. \u00c9rdekes, hogy a RKN, l\u00e1tva a felhajt\u00e1st \u00e9s a p\u00e1nikot, azt mondta: \u201eNem, most semmit nem fogunk blokkolni\u201d. (De ez pontosan addig tartott, am\u00edg el nem kezdt\u00e9k blokkolni a Telegramot.) Be\u00e1ll\u00edtva a kiker\u00fcl\u00e9si lehet\u0151s\u00e9geket, \u00e9s meg\u00e9rtv\u00e9n, hogy m\u00e9gsem vezett\u00e9k be a blokkol\u00e1st, m\u00e9gsem kezdt\u00fck el sz\u00e9tszedni az eg\u00e9szet. Csak a biztons\u00e1g kedv\u00e9\u00e9rt. <\/p>\n
\u00c9s hogyan lehet biztons\u00e1gi m\u00e1solatot k\u00e9sz\u00edteni\u2026 egy teljes szolg\u00e1ltat\u00f3r\u00f3l?<\/h4>\n \nJelenleg nincs forgat\u00f3k\u00f6nyv\u00fcnk arra az esetre, ha az eg\u00e9sz Amazon le\u00e1llna. Van egy hasonl\u00f3 forgat\u00f3k\u00f6nyv\u00fcnk Oroszorsz\u00e1gra. Oroszorsz\u00e1gban egy szolg\u00e1ltat\u00f3n\u00e1l helyezkedt\u00fcnk el, ahol kiv\u00e1lasztottuk, hogy t\u00f6bb helysz\u00edn\u00fcnk legyen. \u00c9s egy \u00e9ve probl\u00e9m\u00e1val szembes\u00fclt\u00fcnk: m\u00e9g ha k\u00e9t adatk\u00f6zpont is l\u00e9tezik, a szolg\u00e1ltat\u00f3 h\u00e1l\u00f3zati konfigur\u00e1ci\u00f3j\u00e1nak szintj\u00e9n is lehetnek probl\u00e9m\u00e1k, amelyek mindk\u00e9t adatk\u00f6zpontot \u00e9rintik. Ez\u00e1ltal mindk\u00e9t helysz\u00ednen el\u00e9rhetetlens\u00e9get tapasztalhatunk. Term\u00e9szetesen ez val\u00f3ban \u00edgy t\u00f6rt\u00e9nt. V\u00e9g\u00fcl \u00fajra\u00e9rt\u00e9kelt\u00fck a bels\u0151 architekt\u00far\u00e1t. Ez nem v\u00e1ltozott meg jelent\u0151sen, de Oroszorsz\u00e1gban most k\u00e9t helysz\u00edn\u00fcnk van, amelyek nem egy szolg\u00e1ltat\u00f3n\u00e1l, hanem k\u00e9t k\u00fcl\u00f6nb\u00f6z\u0151n\u00e9l tal\u00e1lhat\u00f3k. Ha az egyik meghib\u00e1sodik, \u00e1tv\u00e1lthatunk a m\u00e1sikra.<\/p>\n
Hipotetikusan az Amazon sz\u00e1m\u00e1ra megfontoljuk, hogy egy m\u00e1sik szolg\u00e1ltat\u00f3 szintj\u00e9n biztos\u00edtsunk tartal\u00e9kot; tal\u00e1n a Google-t, tal\u00e1n valaki m\u00e1st... De eddig tapasztalataink szerint, ha az Amazonon bel\u00fcl egy availability z\u00f3n\u00e1ban t\u00f6rt\u00e9nik baleset, a teljes r\u00e9gi\u00f3ra kiterjed\u0151 balesetek meglehet\u0151sen ritka jelens\u00e9gek. Teh\u00e1t elm\u00e9letileg van elk\u00e9pzel\u00e9s\u00fcnk arr\u00f3l, hogy lehet, hogy \u201eAmazon - nem Amazon\u201d tartal\u00e9kot szervez\u00fcnk, de gyakorlatilag ilyesmi eddig nincs. <\/p>\n
N\u00e9h\u00e1ny sz\u00f3 az automatiz\u00e1l\u00e1sr\u00f3l<\/h4>\n \nMindig sz\u00fcks\u00e9g van automatiz\u00e1l\u00e1sra? Itt \u00e9rdemes megeml\u00edteni a Dunning-Kruger hat\u00e1st. Az \u201ex\u201d tengelyen a tud\u00e1sunk \u00e9s tapasztalatunk \u00e1ll, amelyet megszerezt\u00fcnk, m\u00edg az \u201ey\u201d tengelyen a cselekv\u00e9s\u00fcnk ir\u00e1nti bizalmunk. El\u0151sz\u00f6r nem tudunk semmit, \u00e9s teljesen bizonytalanok vagyunk. Ezut\u00e1n tudunk egy kicsit, \u00e9s hiperbiztosak lesz\u00fcnk \u2013 ez a \u201ebutas\u00e1g cs\u00facsa\u201d, amit a \u201eb\u00f6lcsess\u00e9g \u00e9s b\u00e1tors\u00e1g\u201d k\u00e9p illusztr\u00e1l. K\u00e9s\u0151bb m\u00e1r valamennyire tanultunk, \u00e9s k\u00e9szen \u00e1llunk a harcra. Azt\u00e1n ker\u00fcl\u00fcnk valami \u00f3ri\u00e1si csapd\u00e1ba, beleker\u00fcl\u00fcnk a k\u00e9ts\u00e9gbees\u00e9s v\u00f6lgy\u00e9be, amikor \u00fagy t\u0171nik, hogy tudunk valamit, de val\u00f3j\u00e1ban sok mindent nem tudunk. Ezut\u00e1n a tapasztalatokkal egyre magabiztosabb\u00e1 v\u00e1lunk.<\/p>\n
Z\u00e1r\u00e1s<\/h4>\n \nH\u00e9t \u00e9v alatt eljutottunk od\u00e1ig, hogy amikor valami le\u00e1llt, \u2014 p\u00e1nik volt, a meg\u00e9rt\u00e9shez, hogy nincsenek probl\u00e9m\u00e1k, csak feladatok, amelyek megold\u00e1sra v\u00e1rnak \u2014 \u00e9s ez lehets\u00e9ges. Amikor \u00e9p\u00edt\u00fcnk valamilyen szolg\u00e1ltat\u00e1st, r\u00e1n\u00e9z\u00fcnk a dologra fel\u00fclr\u0151l, felm\u00e9rj\u00fck az \u00f6sszes kock\u00e1zatot, ami el\u0151fordulhat. Ha azonnal \u00e9szlelj\u00fck \u0151ket, akkor el\u0151re tervezz\u00fck meg a redundanci\u00e1t \u00e9s a hibat\u0171r\u0151 infrastrukt\u00fara kialak\u00edt\u00e1s\u00e1nak lehet\u0151s\u00e9g\u00e9t, mert b\u00e1rmely olyan elem, amely hib\u00e1san m\u0171k\u00f6dhet \u00e9s a szolg\u00e1ltat\u00e1s megsz\u0171n\u00e9s\u00e9t okozhatja \u2014 az biztosan el fog romlani. \u00c9s m\u00e9g ha \u00fagy t\u0171nik, hogy egyes infrastrukt\u00faraelemek, mint p\u00e9ld\u00e1ul az s3, biztosan nem fognak meghib\u00e1sodni \u2014 az\u00e9rt tartsuk szem el\u0151tt, hogy m\u00e9gis el\u0151fordulhat. Legal\u00e1bb elm\u00e9letben legyen benn\u00fcnket elk\u00e9pzel\u00e9s arr\u00f3l, mit fogunk tenni vel\u00fck, ha valami baj t\u00f6rt\u00e9nik. Legyen v\u00e9szhelyzeti terv\u00fcnknk a kock\u00e1zatok kezel\u00e9s\u00e9re. Amikor arra gondolsz, hogy mindent automatiz\u00e1lj vagy k\u00e9zzel v\u00e9gezz, \u2014 m\u00e9rd fel a kock\u00e1zatokat: mi t\u00f6rt\u00e9nik, ha az automatiz\u00e1l\u00e1s mindent \u00e1tkapcsol \u2014 nem okoz-e ez m\u00e9g rosszabb helyzetet, mint a hiba? Lehet, hogy egy \u00e9sszer\u0171 kompromisszum sz\u00fcks\u00e9ges az automatiz\u00e1l\u00e1s \u00e9s a m\u0171szakban l\u00e9v\u0151 m\u00e9rn\u00f6k reakci\u00f3ja k\u00f6z\u00f6tt, aki \u00e9rt\u00e9keli a val\u00f3s helyzetet \u00e9s meg\u00e9rti, hogy sz\u00fcks\u00e9ges-e azonnal v\u00e1ltani, vagy \u201eigen, de nem most\u201d.<\/p>\n
\u00c9sszer\u0171 kompromisszum a perfekcionizmus \u00e9s a t\u00e9nyleges er\u0151forr\u00e1sok, id\u0151 \u00e9s p\u00e9nz k\u00f6z\u00f6tt, amelyeket a v\u00e9gs\u0151 rendszerre k\u00f6lthet.<\/p>\n
Ez a sz\u00f6veg Alexander Demidov el\u0151ad\u00e1s\u00e1nak kieg\u00e9sz\u00edtett \u00e9s kib\u0151v\u00edtett v\u00e1ltozata a konferenci\u00e1n. Fenn\u00e1ll\u00e1s 4. nap<\/a><\/noindex>.<\/i> 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
![\"\u00abBitrix24\u00bb:](\"\/wp-content\/uploads\/2019\/06\/973fa076fc654237aa869d0ecb0dae9a.jpeg\")