Jotenkin historiallisesti IT-ala on jaettu kahteen ehdolliseen leiriin mistä tahansa syystä: niihin, jotka ovat "puolta" ja niihin, jotka ovat "vastaan". Lisäksi riitojen aihe voi olla täysin mielivaltainen. Kumpi käyttöjärjestelmä on parempi: Win vai Linux? Android- tai iOS-älypuhelimella? Pitäisikö sinun säilyttää kaikki pilvissä vai laittaa kylmään RAID-säilöön ja laittaa ruuvit kassakaappiin? Onko PHP-ihmisillä oikeus tulla kutsutuksi ohjelmoijaksi? Nämä kiistat ovat toisinaan luonteeltaan yksinomaan eksistentiaalisia eikä niillä ole muuta perustetta kuin urheilullinen etu.
Sattui vain niin, että konttien ja kaiken tämän rakastetun keittiön, jossa on telakka ja ehdollinen k8s, ilmaantumisen myötä alkoivat keskustelut "puolesta" ja "vastaan" uusien ominaisuuksien käyttöön taustalla eri alueilla. (Tehdään varaus etukäteen, että vaikka Kubernetes mainitaan useimmiten tässä keskustelussa järjestäjänä, tämän työkalun valinnalla ei ole perustavanlaatuista merkitystä. Sen sijaan voit korvata sen jollain toisella, joka näyttää sinulle sopivimmalta ja tutummalta. .)
Ja näyttää siltä, että tämä olisi yksinkertainen kiista saman kolikon kahden puolen välillä. Yhtä järjetön ja armoton kuin Win vs Linuxin ikuinen vastakkainasettelu, jossa riittävät ihmiset ovat jossain välissä. Mutta konttien tapauksessa kaikki ei ole niin yksinkertaista. Yleensä tällaisissa riita-asioissa ei ole oikeaa puolta, mutta "käytä" tai "älä käytä" -kontteja tietokantojen tallentamiseen, kaikki kääntyy ylösalaisin. Koska tietyssä mielessä sekä tämän lähestymistavan kannattajat että vastustajat ovat oikeassa.
Valoisa puoli
Light Siden argumenttia voidaan kuvata lyhyesti yhdellä lauseella: "Hei, 2k19 on ikkunan ulkopuolella!" Se kuulostaa tietysti populismista, mutta jos asiaan perehtyy yksityiskohtaisesti, siinä on puolensa. Selvitetään ne nyt.
Oletetaan, että sinulla on suuri verkkoprojekti. Se olisi voitu alun perin rakentaa mikropalvelulähestymistavan pohjalta tai jossain vaiheessa se tuli siihen evoluution polkua pitkin - tämä ei itse asiassa ole kovin tärkeää. Hajotit projektimme erillisiin mikropalveluihin, määritit orkestroinnin, kuormituksen tasapainotuksen ja skaalauksen. Ja nyt, puhtaalla omallatunnolla, siemailet mojitoa riippumatossa habra-efektien aikana sen sijaan, että nostaisit kaatuneita palvelimia. Mutta kaikissa toimissa sinun on oltava johdonmukainen. Hyvin usein vain itse sovellus - koodi - on säilötty. Mitä muuta meillä on koodin lisäksi?
Aivan oikein, dataa. Minkä tahansa projektin ydin on sen data: tämä voi olla joko tyypillinen tietokantajärjestelmä - MySQL, Postgre, MongoDB tai tallennustila, jota käytetään hakuun (ElasticSearch), avainarvojen tallennus välimuistiin - esimerkiksi redis jne. Tällä hetkellä emme ole puhumme vääristä taustajärjestelmän toteutusvaihtoehdoista, kun tietokanta kaatuu huonosti kirjoitettujen kyselyjen takia, ja sen sijaan puhumme juuri tämän tietokannan vikasietoisuuden varmistamisesta asiakaskuormituksen aikana. Loppujen lopuksi, kun kontiloimme sovelluksemme ja annamme sen skaalata vapaasti käsitelläkseen minkä tahansa määrän saapuvia pyyntöjä, tämä luonnollisesti lisää tietokannan kuormitusta.
Itse asiassa tietokannan käyttökanavasta ja palvelimesta, jolla se toimii, tulee neulansilmä kauniissa konttipohjaisessa taustajärjestelmässämme. Samanaikaisesti konttivirtualisoinnin päämotiivina on rakenteen liikkuvuus ja joustavuus, jonka avulla pystymme järjestämään huippukuormituksen jakautumisen koko käytettävissämme olevaan infrastruktuuriin mahdollisimman tehokkaasti. Toisin sanoen, jos emme kokoa ja levitä kaikkia olemassa olevia järjestelmän elementtejä klusterin poikki, teemme erittäin vakavan virheen.
On paljon loogisempaa klusteroida paitsi itse sovellus, myös tiedon tallentamisesta vastaavat palvelut. Klusteroimalla ja ottamalla käyttöön itsenäisesti toimivia ja kuorman keskenään jakavia web-palvelimia k8s:ssa ratkaisemme jo datan synkronoinnin ongelman - samat kommentit postauksiin, jos otamme esimerkkinä jonkin media- tai blogialustan. Joka tapauksessa meillä on klusterin sisäinen, jopa virtuaalinen, esitys tietokannasta ulkoisena palveluna. Kysymys on siitä, että itse tietokanta ei ole vielä klusteroitu - kuutioon asennetut web-palvelimet ottavat tiedot muutoksista staattisesta taistelutietokannastamme, joka pyörii erikseen.
Tunnetko saaliin? Käytämme k8s:a tai Swarmia kuorman jakamiseen ja pääverkkopalvelimen kaatumisen välttämiseen, mutta emme tee tätä tietokannan osalta. Mutta jos tietokanta kaatuu, koko klusteroidussa infrastruktuurissamme ei ole mitään järkeä - mitä hyötyä on tyhjistä verkkosivuista, jotka palauttavat tietokannan käyttövirheen?
Siksi on välttämätöntä klusteroida verkkopalvelimien lisäksi myös tietokantainfrastruktuuri, kuten yleensä tehdään. Vain näin voimme varmistaa rakenteen, joka toimii täysin yhdessä tiimissä, mutta samalla toisistaan riippumattomana. Lisäksi, vaikka puolet taustajärjestelmästämme "romoituisi" kuormituksen alaisena, loput säilyvät hengissä, ja tietokantojen synkronointijärjestelmä klusterin sisällä ja kyky loputtomasti skaalata ja ottaa käyttöön uusia klustereita auttavat saavuttamaan nopeasti vaaditun kapasiteetin. jos vain palvelinkeskuksessa olisi telineitä.
Lisäksi klustereissa jaettu tietokantamalli mahdollistaa juuri tämän tietokannan viemisen sinne, missä sitä tarvitaan; Jos puhumme globaalista palvelusta, niin on melko epäloogista muodostaa verkkoklusteri jonnekin San Franciscon alueelle ja samalla lähettää paketteja Moskovan alueen tietokannan yhteydessä ja takaisin.
Lisäksi tietokannan kontissaus mahdollistaa kaikkien järjestelmän elementtien rakentamisen samalla abstraktiotasolla. Mikä puolestaan mahdollistaa tämän järjestelmän hallinnan suoraan koodista, kehittäjien toimesta ilman järjestelmänvalvojien aktiivista osallistumista. Kehittäjät ajattelivat, että uutta aliprojektia varten tarvitaan erillinen DBMS - helppoa! kirjoitti yaml-tiedoston, latasi sen klusteriin ja olet valmis.
Ja tietysti sisäinen toiminta yksinkertaistuu huomattavasti. Kerro minulle, kuinka monta kertaa olet sulkenut silmäsi, kun uusi tiimin jäsen laittoi kätensä taistelutietokantaan työn takia? Mikä itse asiassa on ainoa, joka sinulla on ja joka pyörii juuri nyt? Tietysti olemme täällä kaikki aikuisia, ja jossain meillä on tuore varmuuskopio, ja vielä kauempana - hyllyn takana mummon kurkkujen ja vanhojen suksien kanssa - toinen varmuuskopio, ehkä jopa kylmävarastossa, koska toimistosi oli jo kerran tulessa. Mutta joka tapauksessa, jokainen uuden tiimin jäsenen esittely, jolla on pääsy taisteluinfrastruktuuriin ja tietysti taistelutietokantaan, on ämpäri validolia kaikille ympärillä oleville. No, kuka tuntee hänet, aloittelija, ehkä hän on ristissä? Se on pelottavaa, olet samaa mieltä.
Säiliöinti ja itse asiassa projektisi tietokannan hajautettu fyysinen topologia auttavat välttämään tällaiset validointihetket. Etkö luota aloittelijaan? OK! Annetaan hänelle oma klusteri työskennelläkseen ja katkaistaan tietokanta muista klustereista - synkronointi vain manuaalisella painalluksella ja kahden avaimen (toinen tiimin johtajalle, toinen järjestelmänvalvojalle) synkronisella pyörityksellä. Ja kaikki ovat onnellisia.
Ja nyt on aika muuttua tietokantaklusteroinnin vastustajiksi.
Pimeä puoli
Keskustelemalla siitä, miksi tietokannan konttiaminen ja sen käyttäminen yhdellä keskuspalvelimella ei kannata jatkaa, emme alistu ortodoksian retoriikkaan ja väitteisiin, kuten "isoisät pitivät tietokantoja laitteistolla, ja niin teemme mekin!" Sen sijaan yritetään keksiä tilanne, jossa konttikuljetus todella tuottaisi konkreettisia osinkoja.
Samaa mieltä, projektit, jotka todella tarvitsevat alustan konttiin, voidaan laskea yhden käden sormilla ei paras jyrsinkoneen kuljettaja. Suurimmaksi osaksi jopa k8s:n tai Docker Swarmin käyttö itsessään on turhaa - melko usein näihin työkaluihin turvaudutaan teknologioiden yleisen hypetyksen ja "kaikkivaltiaan" asenteiden vuoksi sukupuolten persoonassa työntää kaikkea pilvet ja kontit. No, koska se on nyt muotia ja kaikki tekevät niin.
Ainakin puolessa tapauksista Kubernetiksen tai vain Dockerin käyttö projektissa on tarpeetonta. Ongelmana on, että kaikki asiakkaan infrastruktuurin ylläpitoon palkatut tiimit tai ulkoistamisyritykset eivät ole tietoisia tästä. Se on pahempaa, kun kontit asetetaan, koska se maksaa asiakkaalle tietyn määrän kolikoita.
Yleisesti ottaen ollaan sitä mieltä, että telakka-/kuutiomafia murskaa tyhmästi asiakkaita, jotka ulkoistavat nämä infrastruktuuriongelmat. Klusterien kanssa työskentelyyn tarvitsemme kuitenkin insinöörejä, jotka pystyvät tähän ja ymmärtävät yleisesti toteutetun ratkaisun arkkitehtuurin. Kerran jo kuvailimme tapaustamme Republic-julkaisun kanssa - siellä koulutimme asiakkaan tiimin työskentelemään Kubernetiksen realiteeteissa, ja kaikki olivat tyytyväisiä. Ja se oli kunnollista. Usein k8s:n "toteuttajat" ottavat asiakkaan infrastruktuurin panttivangiksi - koska nyt vain he ymmärtävät, kuinka kaikki siellä toimii; asiakkaan puolella ei ole asiantuntijoita.
Kuvittele nyt, että tällä tavalla ulkoistamme verkkopalvelinosan lisäksi myös tietokannan ylläpidon. Sanoimme, että BD on sydän, ja sydämen menetys on kohtalokasta kaikille elävälle organismille. Lyhyesti sanottuna näkymät eivät ole parhaat. Joten hype Kubernetiksen sijaan monien projektien ei yksinkertaisesti pitäisi vaivautua normaaliin AWS-tariffiin, joka ratkaisee kaikki heidän sivustonsa/projektinsa kuormitukseen liittyvät ongelmat. Mutta AWS ei ole enää muodissa, ja esittelyt ovat arvokkaampia kuin rahaa - valitettavasti myös IT-ympäristössä.
OK. Ehkä projekti todella tarvitsee klusterointia, mutta jos tilattomien sovellusten kanssa kaikki on selvää, niin kuinka voimme järjestää kunnollisen verkkoyhteyden klusteroituun tietokantaan?
Jos puhumme saumattomasta suunnitteluratkaisusta, jota k8s:iin siirtyminen tarkoittaa, suurin päänsärkymme on tietojen replikointi klusteroidussa tietokannassa. Jotkut DBMS-järjestelmät ovat aluksi melko uskollisia tietojen jakelulle yksittäisten esiintymistensä välillä. Monet muut eivät ole niin tervetulleita. Ja melko usein tärkein argumentti DBMS:n valinnassa projektiimme ei ole kyky replikoida minimaalisilla resurssi- ja suunnittelukustannuksilla. Varsinkin jos projektia ei alun perin suunniteltu mikropalveluksi, vaan se yksinkertaisesti kehittyi tähän suuntaan.
Mielestämme verkkoasemien nopeudesta ei tarvitse puhua - ne ovat hitaita. Nuo. Meillä ei edelleenkään ole todellista mahdollisuutta, jos jotain tapahtuu, käynnistää DBMS-esiintymä uudelleen jostain, jossa on enemmän, esimerkiksi prosessoritehoa tai vapaata RAM-muistia. Törmäämme erittäin nopeasti virtualisoidun levyn alijärjestelmän suorituskykyyn. Näin ollen DBMS on naulattava sen omaan henkilökohtaiseen konesarjaan, jotka sijaitsevat lähellä. Tai joudutaan jotenkin erikseen jäähdyttämään riittävän nopeaa datasynkronointia oletetuille varauksille.
Jatkaen virtuaalisten tiedostojärjestelmien aihetta: Docker Volumes ei valitettavasti ole ongelmattomia. Yleisesti ottaen sellaisessa asiassa kuin pitkäaikaisessa luotettavassa tiedontallennuksessa haluaisin tyytyä teknisesti yksinkertaisimmilla kaavoilla. Ja uuden abstraktiokerroksen lisääminen säilön FS:stä isäntäpalvelimen FS:ään on riski sinänsä. Mutta kun konttien tukijärjestelmän toiminnassa on myös vaikeuksia tiedonsiirrossa näiden kerrosten välillä, se on todella katastrofi. Tällä hetkellä useimmat edistyksellisen ihmiskunnan tuntemista ongelmista näyttävät olevan hävitetty. Mutta ymmärräthän, mitä monimutkaisempi mekanismi, sitä helpommin se rikkoutuu.
Kaikkien näiden "seikkailujen" valossa on paljon kannattavampaa ja helpompaa pitää tietokanta yhdessä paikassa, ja vaikka sovellus tarvitsisi säilöä, anna sen toimia itsenäisesti ja vastaanottaa samanaikaista viestintää jakeluyhdyskäytävän kautta tietokanta, joka luetaan ja kirjoitetaan vain kerran ja yhdessä paikassa. Tämä lähestymistapa vähentää virheiden ja epäsynkronoinnin todennäköisyyttä minimiin.
Mihin me johdamme? Lisäksi tietokantakontti on tarkoituksenmukaista silloin, kun sille on todellinen tarve. Et voi täyttää koko sovellustietokantaa ja pyörittää sitä ikään kuin sinulla olisi kaksi tusinaa mikropalvelua - se ei toimi niin. Ja tämä on ymmärrettävä selvästi.
Tulostuksen sijaan
Jos odotat selkeää johtopäätöstä "virtualisoidaanko tietokanta vai ei", tuotamme sinulle pettymyksen: se ei tule olemaan täällä. Koska mitä tahansa infrastruktuuriratkaisua luotaessa ei saa ohjata muotia ja edistystä, vaan ennen kaikkea tervettä järkeä.
On projekteja, joihin Kubernetiksen mukana tulevat periaatteet ja työkalut sopivat täydellisesti, ja sellaisissa projekteissa on rauhaa ainakin tausta-alueella. Ja on projekteja, jotka eivät vaadi konttia, vaan normaalia palvelininfrastruktuuria, koska ne eivät periaatteessa voi skaalata mikropalveluklusterimalliin, koska ne putoavat.
Lähde: will.com