Valahogy történelmileg az IT-ipar bármilyen okból két feltételes táborra oszlik: azokra, akik „mellett” vannak, és azokra, akik „ellen”. Ráadásul a viták tárgya teljesen önkényes lehet. Melyik operációs rendszer jobb: Win vagy Linux? Android vagy iOS okostelefonon? Tároljon mindent a felhőkben, vagy tegye hideg RAID tárolóba, és tegye a csavarokat egy széfbe? Joguk van a PHP-s embereknek programozónak nevezni? Ezek a viták időnként kizárólag egzisztenciális jellegűek, és nincs más alapjuk, mint a sportérdek.
Történt ugyanis, hogy a konténerek megjelenésével és ezzel a sok szeretett konyhával a dockerrel és a feltételes k8-asokkal együtt elkezdődtek a viták az új képességek „mellette” és „ellene” a háttérrendszer különböző területein. (Tegyük meg előre, hogy bár ebben a beszélgetésben a Kubernetes leggyakrabban hangszerelőként szerepel, ennek az eszköznek a megválasztása nem alapvető fontosságú. Ehelyett bármilyen mást helyettesíthet, amely a legkényelmesebbnek és legismertebbnek tűnik. .)
És úgy tűnik, ez egy egyszerű vita ugyanazon érme két oldala között. Olyan értelmetlen és irgalmatlan, mint a Win vs Linux örök konfrontációja, amelyben a megfelelő emberek valahol középen vannak. De a konténerezés esetében nem minden olyan egyszerű. Az ilyen vitákban általában nincs jobb oldal, de az adatbázisok tárolására szolgáló „használ” vagy „nem használ” konténerek esetén minden a feje tetejére áll. Mert bizonyos értelemben ennek a megközelítésnek a támogatóinak és ellenzőinek egyaránt igazuk van.
Napos oldal
A Light Side érvelése röviden leírható egy mondattal: „Helló, 2k19 az ablakon kívül!” Ez persze populizmusnak hangzik, de ha részletesen belemélyedünk a helyzetbe, annak megvannak az előnyei. Most rendezzük őket.
Tegyük fel, hogy van egy nagy internetes projektje. Kezdetben mikroszolgáltatási megközelítés alapján épülhetett fel, vagy valamikor evolúciós úton jutott el hozzá - ez nem túl fontos, sőt. Ön szétszórta projektünket külön mikroszolgáltatásokba, beállította a hangszerelést, a terheléselosztást és a méretezést. Most pedig tiszta lelkiismerettel habraeffektusok közben egy függőágyban szürcsölsz egy mojitót, ahelyett, hogy ledőlt szervereket emelnél fel. De minden cselekedetben következetesnek kell lennie. Nagyon gyakran csak maga az alkalmazás – a kód – van konténerben. Mi másunk van a kódon kívül?
Így van, adatok. Minden projekt szíve az adatokban rejlik: ez lehet egy tipikus DBMS (MySQL, Postgre, MongoDB), vagy egy keresésre használt tároló (ElasticSearch), kulcsérték tároló a gyorsítótárazáshoz – például redis stb. Jelenleg nem ha az adatbázis rosszul megírt lekérdezések miatt összeomlik, akkor ferde háttér-megvalósítási lehetőségekről fogunk beszélni, ehelyett éppen ennek az adatbázisnak a hibatűrésének biztosításáról fogunk beszélni kliens terhelés alatt. Végül is, ha az alkalmazásunkat konténerbe helyezzük, és lehetővé tesszük, hogy tetszőleges számú bejövő kérés feldolgozásához szabadon méretezhessen, ez természetesen növeli az adatbázis terhelését.
Valójában az adatbázis elérésének csatornája és a szerver, amelyen az fut, a tű fokává válik gyönyörű konténeres háttérrendszerünkben. A konténervirtualizáció fő motívuma ugyanakkor a szerkezet mobilitása és rugalmassága, amely lehetővé teszi, hogy a csúcsterhelések elosztását a rendelkezésünkre álló teljes infrastruktúrán a lehető leghatékonyabban szervezzük meg. Vagyis ha nem konténerezzük és nem tesszük ki a rendszer összes létező elemét a klaszteren keresztül, akkor nagyon súlyos hibát követünk el.
Sokkal logikusabb nemcsak magát az alkalmazást, hanem az adatok tárolásáért felelős szolgáltatásokat is klaszterbe gyűjteni. A k8s-ban önállóan működő és a terhelést egymás között elosztó webszerverek klaszterezésével és telepítésével máris megoldjuk az adatszinkronizálás problémáját - ugyanezek a hozzászólások kommentjei, ha valamilyen média- vagy blogplatformot veszünk példának. Mindenesetre az adatbázisnak van egy fürtön belüli, akár virtuális reprezentációja, mint ExternalService. A kérdés az, hogy maga az adatbázis még nem fürtözött - a kockában telepített webszerverek a statikus harci adatbázisunkból vesznek információkat a változásokról, amelyek külön-külön forognak.
Érzel fogást? A k8s-t vagy a Swarm-ot használjuk a terhelés elosztására és a fő webszerver összeomlásának elkerülésére, de ezt nem tesszük meg az adatbázis esetében. De ha az adatbázis összeomlik, akkor a teljes fürtözött infrastruktúránknak nincs értelme – mire jók az üres weboldalak, amelyek adatbázis-hozzáférési hibát adnak vissza?
Éppen ezért nem csak a webszervereket kell klaszterezni, ahogyan általában, hanem az adatbázis-infrastruktúrát is. Csak így biztosítható egy csapatban teljes mértékben működő, de egymástól független struktúra. Sőt, még ha a háttérrendszerünk fele is „összeomlik” terhelés alatt, a többi fennmarad, és a fürtön belüli adatbázisok egymással való szinkronizálásának rendszere, valamint az új fürtök végtelenségig skálázhatósága és telepítése elősegíti a szükséges kapacitás gyors elérését. ha lennének állványok az adatközpontban .
Ezenkívül a fürtökben elosztott adatbázismodell lehetővé teszi, hogy éppen ezt az adatbázist vigye oda, ahol szükség van rá; Ha globális szolgáltatásról beszélünk, akkor meglehetősen logikátlan egy webfürtöt felpörgetni valahol San Francisco környékén, és ezzel egyidejűleg csomagokat küldeni a moszkvai régióban lévő adatbázis elérésekor és vissza.
Ezenkívül az adatbázis konténerezése lehetővé teszi, hogy a rendszer minden elemét azonos absztrakciós szinten építse fel. Ez pedig lehetővé teszi ennek a rendszernek a közvetlen kódból történő kezelését a fejlesztők által, a rendszergazdák aktív közreműködése nélkül. A fejlesztők úgy gondolták, hogy az új alprojekthez külön DBMS-re van szükség – egyszerűen! írt egy yaml fájlt, feltöltötte a fürtbe, és kész.
És természetesen a belső működés jelentősen leegyszerűsödik. Mondd, hányszor hunytad be a szemed, amikor egy új csapattag a harci adatbázisba tette a kezét munkája miatt? Valójában melyik az egyetlen, amelyik megvan, és éppen most forog? Persze itt mindannyian felnőttek vagyunk, és valahol van egy friss tartalékunk, sőt távolabb - a polc mögött a nagymama uborkáival és a régi sílécekkel - egy másik tartalék, talán még hűtőházban is, mert egyszer már lángokban állt az irodája. De mindazonáltal minden új csapattag bemutatkozása, aki hozzáfér a harci infrastruktúrához és természetesen a harci adatbázishoz, egy vödör validol mindenki számára. Nos, ki ismeri őt, újonc, lehet, hogy keresztbe tett? Ez ijesztő, egyet fogsz érteni.
A konténerezés és valójában a projekt adatbázisának elosztott fizikai topológiája segít elkerülni az ilyen érvényesítési pillanatokat. Nem bízol egy újoncban? RENDBEN! Adjuk meg neki a saját fürtjét, amellyel dolgozhat, és válassza le az adatbázist a többi fürtről – a szinkronizálás csak kézi lenyomással és két kulcs szinkron elforgatásával történik (az egyik a csapatvezetőé, a másik az adminisztrátoré). És mindenki boldog.
És most itt az ideje, hogy az adatbázis-fürtözés ellenfeleivé váljunk.
Sötét oldal
Azzal érvelve, hogy miért nem érdemes konténerbe rakni az adatbázist, és továbbra is egyetlen központi szerveren futtatni, nem hajolunk meg az ortodoxiák retorikájához és az olyan kijelentésekhez, mint „a nagypapák hardveren futtatták az adatbázisokat, és mi is!” Ehelyett próbáljunk meg olyan helyzetet találni, amelyben a konténerezés ténylegesen kézzelfogható megtérülést hozna.
Egyetértek, azokat a projekteket, amelyekhez valóban szükség van egy konténerben lévő alapra, egy kéz ujján meg tudja számolni a nem a legjobb marógépkezelő. Többnyire még maga a k8s vagy a Docker Swarm használata is fölösleges - elég gyakran a technológiák általános felhajtása és a „mindenható” hozzáállása miatt folyamodnak ezekhez az eszközökhöz a nemek személyében, hogy mindent belenyomjanak a felhők és konténerek. Hát mert most divat és mindenki ezt csinálja.
Az esetek legalább felében felesleges a Kubernetis vagy csak a Docker használata egy projekten. A probléma az, hogy ezzel nem minden csapat vagy outsourcing cég van tisztában az ügyfél infrastruktúrájának karbantartására. Rosszabb, ha konténereket raknak ki, mert ez bizonyos mennyiségű érmébe kerül az ügyfélnek.
Általánosságban elmondható, hogy az a vélemény, hogy a dokkoló/kocka maffia ostobán zúzza az ügyfeleket, akik kiszervezik ezeket az infrastrukturális problémákat. Hiszen ahhoz, hogy klaszterekkel dolgozhassunk, olyan mérnökökre van szükségünk, akik képesek erre, és általában értik a megvalósított megoldás architektúráját. Egyszer már leírtuk esetünket a Republic-kiadvánnyal – ott betanítottuk az ügyfél csapatát, hogy a Kubernetis valóságában dolgozzanak, és mindenki elégedett volt. És rendes volt. A k8s „megvalósítók” gyakran túszul ejtik a kliens infrastruktúráját – mert most már csak ők értik, hogyan működik ott minden, nincsenek szakemberek az ügyfél oldalán.
Most képzeljük el, hogy így nem csak a webszerver részét, hanem az adatbázis karbantartását is kiszervezzük. Azt mondtuk, hogy a BD a szív, és a szív elvesztése végzetes minden élő szervezet számára. Röviden, a kilátások nem a legjobbak. Tehát a hype Kubernetis helyett sok projektnek egyszerűen nem szabad foglalkoznia az AWS normál tarifájával, amely megoldja a webhelyük/projektjük terhelésével kapcsolatos összes problémát. De az AWS már nem divat, és a show-off többet ér, mint a pénz – sajnos informatikai környezetben is.
RENDBEN. Lehet, hogy a projektnek valóban szüksége van a fürtözésre, de ha az állapot nélküli alkalmazásokkal minden világos, akkor hogyan szervezzünk tisztességes hálózati kapcsolatot egy fürtözött adatbázishoz?
Ha egy zökkenőmentes mérnöki megoldásról beszélünk, ami a k8s-ra való átállás, akkor a fő fejtörést a fürtözött adatbázisban való adatreplikáció okozza. Egyes DBMS-ek kezdetben nagyon lojálisak az adatok egyedi példányai közötti elosztásához. Sokan mások nem annyira barátságosak. És gyakran a fő érv a DBMS kiválasztásánál a projektünkhöz nem a replikálás képessége minimális erőforrás- és tervezési költségekkel. Főleg, ha a projektet eredetileg nem mikroszolgáltatásnak tervezték, hanem egyszerűen ebbe az irányba fejlődött.
Szerintünk nem kell beszélni a hálózati meghajtók sebességéről – lassúak. Azok. Még mindig nincs igazi lehetőségünk, ha valami történik, újraindítani egy DBMS-példányt valahol, ahol több van, például processzorteljesítmény vagy szabad RAM. Nagyon gyorsan belefutunk a virtualizált lemez alrendszer teljesítményébe. Ennek megfelelően a DBMS-t a saját, közvetlen közelben elhelyezkedő gépkészletéhez kell szegezni. Vagy valahogy külön kell lehűteni a kellően gyors adatszinkronizálást a feltételezett tartalékokhoz.
A virtuális fájlrendszerek témakörének folytatása: A Docker kötetek sajnos nem problémamentesek. Általában olyan kérdésben, mint a hosszú távú megbízható adattárolás, a technikailag legegyszerűbb sémákkal szeretnék beérni. És egy új absztrakciós réteg hozzáadása a tároló FS-ből a szülő gazdagép FS-éhez önmagában kockázatot jelent. De amikor a konténerezést támogató rendszer működése is nehézségekbe ütközik az adatok e rétegek közötti továbbításával, akkor az valóban katasztrófa. Jelenleg úgy tűnik, hogy a haladó emberiség által ismert problémák többségét felszámolták. De érti, minél összetettebb a mechanizmus, annál könnyebben eltörik.
Mindezen „kalandok” fényében sokkal kifizetődőbb és egyszerűbb az adatbázist egy helyen tartani, és még ha konténerbe kell is helyezni az alkalmazást, hagyja, hogy az önállóan fusson, és a terjesztési átjárón keresztül egyidejűleg kommunikáljon a adatbázis, amely csak egyszer és egy helyen lesz olvasható és írható. Ez a megközelítés minimálisra csökkenti a hibák és a deszinkronizálás valószínűségét.
Mihez vezetünk? Sőt, az adatbázis-konténerezés ott megfelelő, ahol valóban szükség van rá. Nem tölthet be egy teljes alkalmazású adatbázist, és nem forgathatja úgy, mintha két tucat mikroszolgáltatása lenne – ez nem így működik. És ezt világosan meg kell érteni.
Kimenet helyett
Ha egyértelmű következtetésre vár, „virtualizálja-e az adatbázist vagy sem”, csalódást fog okozni Önnek: nem lesz itt. Mert minden infrastrukturális megoldás megalkotásánál nem a divatnak és a haladásnak kell vezérelnie, hanem mindenekelőtt a józan észnek.
Vannak olyan projektek, amelyekhez a Kubernetishez tartozó alapelvek és eszközök tökéletesen illeszkednek, és az ilyen projektekben legalább a háttérben béke van. És vannak olyan projektek, amelyekhez nem konténerezés kell, hanem normál szerver infrastruktúra, mert alapvetően nem tudják átskálázni a mikroszolgáltatás klaszter modelljére, mert bedőlnek.
Forrás: will.com