Op ien of oare manier, histoarysk, is de IT-sektor ferdield yn twa betingsten foar elke reden: dyjingen dy't "foar" binne en dyjingen dy't "tsjin" binne. Boppedat kin it ûnderwerp fan skeel folslein willekeurich wêze. Hokker OS is better: Win of Linux? Op in Android- of iOS-smartphone? Moatte jo alles opslaan yn 'e wolken of set it op kâlde RAID-opslach en sette de skroeven yn in feilich? Hawwe PHP-minsken it rjocht om programmeurs neamd te wurden? Dizze skelen binne, soms, eksklusyf eksistinsjele fan aard en hawwe gjin oare basis as sportyf belang.
It barde sa dat mei de komst fan konteners en al dizze leafste keuken mei docker en betingsten k8's, de debatten "foar" en "tsjin" it gebrûk fan nije mooglikheden yn ferskate gebieten fan 'e backend begon. (Litte wy it foarbehâld meitsje dat alhoewol't Kubernetes yn dizze diskusje meastentiids as orkestrator oanjûn wurde, de kar fan dit bysûndere ark net fan fûnemintele belang is. Ynstee kinne jo in oare ferfange dy't jo it meast handich en fertroud liket .)
En, it soe lykje, dit soe in ienfâldich skeel wêze tusken twa kanten fan deselde munt. Sa sinleas en genedeleas as de ivige konfrontaasje tusken Win vs Linux, wêryn adekwate minsken bestean earne yn 'e midden. Mar yn it gefal fan kontenerisaasje is net alles sa ienfâldich. Meastentiids is yn sokke skeel gjin rjochterkant, mar yn it gefal fan "gebrûk" of "net brûke" konteners foar it bewarjen fan databases, draait alles op 'e kop. Want yn in bepaalde sin hawwe sawol foar- as tsjinstanners fan dizze oanpak gelyk.
Sinnige kant
It argumint fan 'e Light Side kin koart beskreaun wurde yn ien sin: "Hallo, 2k19 is bûten it finster!" It klinkt fansels as populisme, mar as jo de situaasje yn detail ferdjipje, hat it syn foardielen. Litte wy se no sortearje.
Litte wy sizze dat jo in grut webprojekt hawwe. It koe yn earste ynstânsje boud wurde op basis fan in mikroservice-oanpak, of op in stuit kaam it troch in evolúsjonêr paad - dat is trouwens net sa wichtich. Jo hawwe ús projekt ferspraat yn aparte mikrotsjinsten, orkestraasje ynsteld, load balancing, en skaalfergrutting. En no, mei in skjin gewisse, nipje jo in mojito yn in hangmat tidens habra-effekten ynstee fan fallen servers op te heljen. Mar yn alle aksjes moatte jo konsekwint wêze. Hiel faak is allinich de applikaasje sels - de koade - yn kontener. Wat oars hawwe wy neist koade?
Dat is rjocht, gegevens. It hert fan elk projekt is syn gegevens: dit kin of in typyske DBMS wêze - MySQL, Postgre, MongoDB, of opslach brûkt foar sykjen (ElasticSearch), kaai-wearde opslach foar caching - bygelyks redis, ensfh. Op it stuit binne wy net wy sille prate oer krom backend ymplemintaasje opsjes as de databank crashes fanwege min skreaun queries, en ynstee sille wy prate oer it garandearjen fan de fout tolerânsje fan dizze tige databank ûnder client load. Ommers, as wy ús applikaasje containerisearje en it frij skaalje litte om elk oantal ynkommende oanfragen te ferwurkjen, fergruttet dit fansels de lading op 'e database.
Yn feite, it kanaal foar tagong ta de databank en de tsjinner dêr't it rint wurdt it each fan 'e needel yn ús prachtige containerized backend. Tagelyk is it haadmotyf fan kontenervirtualisaasje de mobiliteit en fleksibiliteit fan 'e struktuer, wêrtroch't wy de ferdieling fan peaklasten oer de hiele ynfrastruktuer dy't foar ús beskikber binne sa effisjint mooglik organisearje. Dat is, as wy alle besteande eleminten fan it systeem net oer it kluster kontenerisearje en útrolje, meitsje wy in heul serieuze flater.
It is folle logysker om net allinich de applikaasje sels te klusterjen, mar ek de tsjinsten dy't ferantwurdlik binne foar it opslaan fan gegevens. Troch it klusterjen en ynsetten fan webservers dy't selsstannich wurkje en de lading ûnder harsels yn k8's fersprieden, binne wy al oplost it probleem fan gegevenssyngronisaasje - deselde opmerkingen op berjochten, as wy wat media- of blogplatfoarm as foarbyld nimme. Yn alle gefallen hawwe wy in intra-cluster, sels firtuele, fertsjintwurdiging fan 'e databank as in ExternalService. De fraach is dat de databank sels noch net klustere is - de webservers ynset yn 'e kubus nimme ynformaasje oer feroarings fan ús statyske bestridingsdatabase, dy't apart rotearret.
Fielsto in fangen? Wy brûke k8s of Swarm te fersprieden de lading en foar te kommen crashe de wichtichste web tsjinner, mar wy dogge dit net foar de databank. Mar as de databank crasht, dan hat ús hiele klustere ynfrastruktuer gjin sin - wat is it nut fan lege websiden dy't in databank tagongsflater weromjaan?
Dêrom is it needsaaklik om net allinich webservers te klusterjen, lykas gewoanlik dien wurdt, mar ek de databankynfrastruktuer. Allinnich op dizze manier kinne wy soargje foar in struktuer dy't folslein yn ien team wurket, mar tagelyk ûnôfhinklik fan elkoar. Boppedat, sels as de helte fan ús backend "ynstoart" ûnder lading, de rest sil oerlibje, en it systeem fan syngronisaasje fan de databases mei elkoar binnen it kluster en de mooglikheid om einleaze skaalfergrutting en ynsette nije klusters sil helpe om fluch berikke de fereaske kapasiteit - as d'r mar rekken wiene yn it datasintrum.
Derneist, it databank model ferdield yn klusters kinne jo nimme dizze hiel databank nei wêr't it is nedich; As wy it hawwe oer in wrâldwide tsjinst, dan is it frij ûnlogysk om in webkluster earne yn it San Francisco-gebiet te spinnen en tagelyk pakketten te stjoeren by tagong ta in databank yn 'e Moskou-regio en werom.
Ek, containerization fan de databank kinne jo bouwe alle eleminten fan it systeem op itselde nivo fan abstraksje. Wat, op syn beurt, it mooglik makket om dit systeem direkt te behearjen fan koade, troch ûntwikkelders, sûnder de aktive belutsenens fan behearders. De ûntwikkelders tochten dat in aparte DBMS nedich wie foar it nije subprojekt - maklik! skreau in yaml-bestân, upload it nei it kluster en jo binne klear.
En fansels, ynterne operaasje is sterk ferienfâldige. Fertel my, hoefolle kearen hawwe jo de eagen sluten doe't in nij teamlid syn hannen yn 'e gefjochtsdatabase sette foar wurk? Hokker is trouwens de iennichste dy't jo hawwe en no draait? Fansels binne wy hjir allegear folwoeksenen, en earne hawwe wy in frisse reservekopy, en noch fierder fuort - efter de planke mei komkommers fan beppe en âlde ski's - noch in reservekopy, miskien sels yn kâlde opslach, om't jo kantoar al ien kear yn 'e brân stie. Mar lykwols, elke yntroduksje fan in nij teamlid mei tagong ta de gefjochtsinfrastruktuer en, fansels, ta de gefjochtsdatabank is in emmer fan validol foar elkenien om. No, wa ken him, in newbie, miskien is er dwers? It is skriklik, jo sille it iens wêze.
Containerisaasje en, yn feite, de ferdielde fysike topology fan 'e databank fan jo projekt helpt om sokke validearjende mominten te foarkommen. Fertrouwe jo gjin newbie? OK! Litte wy him syn eigen kluster jaan om mei te wurkjen en de databank los te meitsjen fan 'e oare klusters - syngronisaasje allinich troch manuele druk en syngroane rotaasje fan twa kaaien (ien foar de teamlieding, de oare foar de admin). En elkenien is bliid.
En no is it tiid om te feroarjen yn tsjinstanners fan databankklustering.
Donkere kant
Argumintearjen wêrom't it net wurdich is om de database te kontenerearjen en troch te gean mei it útfieren op ien sintrale tsjinner, sille wy net bûge foar de retoryk fan ortodoksen en útspraken lykas "pakesizzers rûnen databases op hardware, en dat sille wy ek!" Litte wy ynstee besykje te kommen mei in situaasje wêryn kontenerisaasje wirklik tastbare dividenden soe betelje.
Iens, de projekten dy't wirklik in basis yn in kontener nedich binne, kinne op 'e fingers fan ien hân teld wurde troch net de bêste freesmasine-operator. Foar it meastepart is sels it gebrûk fan k8's as Docker Swarm sels oerstallich - faak wurde dizze ark brûkt troch de algemiene hype fan technologyen en de hâlding fan 'e "almachtige" yn 'e persoan fan' e geslachten om alles yn 'e wolken en konteners. No, want no is it moade en elkenien docht it.
Yn op syn minst de helte fan 'e gefallen is it brûken fan Kubernetis of gewoan Docker op in projekt oerstallich. It probleem is dat net alle teams of outsourcingbedriuwen dy't ynhierd binne om de ynfrastruktuer fan 'e kliïnt te behâlden, dit bewust binne. It is slimmer as konteners wurde oplein, omdat it kostet in beskaat bedrach fan munten oan de klant.
Yn 't algemien is d'r in miening dat de docker / kubusmafia dom kliïnten ferpletteret dy't dizze ynfrastruktuerproblemen útbesteegje. Ommers, om mei klusters te wurkjen, hawwe wy yngenieurs nedich dy't dit yn steat binne en de arsjitektuer fan 'e ymplementearre oplossing algemien begripe. Wy hawwe ús saak ienris al beskreaun mei de publikaasje fan 'e Republyk - dêr hawwe wy it team fan' e kliïnt oplaat om te wurkjen yn 'e realiteit fan Kubernetis, en elkenien wie tefreden. En it wie fatsoenlik. Faak nimme k8s "útfierders" de ynfrastruktuer fan 'e kliïnt yn gizeling - om't se no allinich begripe hoe't alles dêr wurket; d'r binne gjin spesjalisten oan 'e kant fan 'e kliïnt.
Stel jo no foar dat wy op dizze manier net allinich it webserverdiel útbesteegje, mar ek it databaseûnderhâld. Wy seine dat BD it hert is, en it ferlies fan it hert is fataal foar alle libbene organismen. Koartsein, de perspektiven binne net de bêste. Dus, ynstee fan hype Kubernetis, moatte in protte projekten gewoan net lestich falle mei it normale taryf foar AWS, dy't alle problemen mei de lading op har side / projekt oplosse. Mar AWS is net mear modieus, en show-offs binne mear wurdich dan jild - spitigernôch ek yn 'e IT-omjouwing.
OK. Miskien hat it projekt echt klustering nedich, mar as alles dúdlik is mei steatleaze applikaasjes, hoe kinne wy dan fatsoenlike netwurkferbining organisearje foar in klustere database?
As wy it hawwe oer in seamless engineering-oplossing, wat is de oergong nei k8s, dan is ús wichtichste hoofdpijn gegevensreplikaasje yn in klustere database. Guon DBMS's binne yn earste ynstânsje frij loyaal oan de ferdieling fan gegevens tusken har yndividuele eksimplaren. In protte oaren binne net sa gastfrij. En faaks is it wichtichste argumint by it kiezen fan in DBMS foar ús projekt net de mooglikheid om te replikearjen mei minimale boarne- en technykkosten. Benammen as it projekt yn earste ynstânsje net pland wie as in mikrotsjinst, mar gewoan yn dizze rjochting evoluearre.
Wy tinke dat it net nedich is om te praten oer de snelheid fan netwurkskiven - se binne stadich. Dy. Wy hawwe noch gjin echte kâns, as der wat bart, om in DBMS-eksimplaar earne te begjinnen wêr't mear is, bygelyks prosessorkrêft of frije RAM. Wy sille hiel fluch rinne yn 'e prestaasjes fan it virtualisearre skiifsubsysteem. Dêrtroch moat de DBMS wurde nagele oan syn eigen persoanlike set fan masines dy't yn 'e buert leit. Of it is nedich om ien of oare manier apart ôf te koelen genôch flugge gegevens syngronisaasje foar de sabeare reserves.
Trochgean mei it ûnderwerp fan firtuele bestânsystemen: Docker Volumes, spitigernôch, binne net probleemfrij. Yn 't algemien, yn sa'n saak as betroubere gegevensopslach op lange termyn, soe ik my graach dwaan wolle mei de meast technysk ienfâldige regelingen. En it tafoegjen fan in nije abstraksjelaach fan 'e FS fan' e kontener oan 'e FS fan 'e âlderhost is in risiko op himsels. Mar as de wurking fan it kontenerisaasje-stipesysteem ek swierrichheden tsjinkomt mei it ferstjoeren fan gegevens tusken dizze lagen, dan is it echt in ramp. Op it stuit lykje de measte problemen dy't de progressive minskdom bekend binne, útroege te wêzen. Mar jo begripe, hoe komplekser it meganisme, hoe makliker it brekt.
Yn it ljocht fan al dizze "aventoeren" is it folle rendabeler en makliker om de databank op ien plak te hâlden, en sels as jo de applikaasje moatte kontenerisearje, lit it dan op harsels rinne en fia de distribúsjegateway tagelyk kommunikaasje krije mei de databank, dy't mar ien kear lêzen en skreaun wurde sil en op ien plak. Dizze oanpak ferleget de kâns op flaters en desyngronisaasje ta in minimum.
Wat liede wy ta? Boppedat is databankkontenerisaasje passend wêr't it wirklik ferlet is. Jo kinne in folsleine-app-database net ynfolje en spinje as jo twa tsientallen mikrotsjinsten hawwe - it wurket net sa. En dit moat dúdlik begrepen wurde.
Yn plak fan útfier
As jo wachtsje op in dúdlike konklúzje "om de databank te virtualisearjen of net," dan sille wy jo teloarstelle: it sil hjir net wêze. Want by it meitsjen fan in ynfrastruktueroplossing moat men net liede troch moade en foarútgong, mar earst fan alle sûn ferstân.
Der binne projekten dêr't de prinsipes en ark dy't komme mei Kubernetis perfekt passe, en yn sokke projekten is der op syn minst frede yn it backend gebiet. En d'r binne projekten dy't gjin kontenerisaasje nedich binne, mar in normale serverynfrastruktuer, om't se yn prinsipe net kinne rescale nei it mikroserviceklustermodel, om't se falle.
Boarne: www.habr.com