Historicky je IT průmysl z nějakého důvodu rozdělen na dva podmíněné tábory: na ty, kteří jsou „pro“ a na ty, kteří jsou „proti“. Navíc předmět sporů může být zcela libovolný. Který OS je lepší: Win nebo Linux? Na smartphonu se systémem Android nebo iOS? Měli byste vše uložit do mraků nebo to dát na studené úložiště RAID a šrouby uložit do trezoru? Mají PHP lidé právo být nazýváni programátory? Tyto spory jsou někdy výhradně existenční povahy a nemají žádný jiný základ než sportovní zájem.
Náhodou se stalo, že s příchodem kontejnerů a celé této milované kuchyně s dockerem a podmíněnými k8 začaly debaty „pro“ a „proti“ o využití nových schopností v různých oblastech backendu. (Předem si udělejme výhradu, že ačkoliv Kubernetes bude v této diskusi nejčastěji uváděn jako orchestrátor, výběr tohoto konkrétního nástroje nemá zásadní význam. Místo toho můžete nahradit jakýkoli jiný, který se vám bude zdát nejpohodlnější a známý .)
A zdá se, že by to byl jednoduchý spor mezi dvěma stranami téže mince. Stejně nesmyslné a nemilosrdné jako věčná konfrontace Win vs Linux, v níž někde uprostřed existují adekvátní lidé. Ale v případě kontejnerizace není vše tak jednoduché. Obvykle v takových sporech neexistuje správná strana, ale v případě kontejnerů „použít“ nebo „nepoužít“ pro ukládání databází se vše obrátí vzhůru nohama. Protože v určitém smyslu mají pravdu jak zastánci, tak odpůrci tohoto přístupu.
Světlá stránka
Argument Světlé strany lze stručně popsat jednou větou: „Ahoj, 2k19 je za oknem!“ Zní to samozřejmě jako populismus, ale pokud se do situace detailně ponoříte, má to své výhody. Pojďme je nyní roztřídit.
Řekněme, že máte velký webový projekt. Mohla být původně postavena na základě přístupu mikroslužeb, nebo k ní v určitém okamžiku přišla evoluční cestou – to ve skutečnosti není příliš důležité. Náš projekt jste rozptýlili do samostatných mikroslužeb, nastavili orchestraci, vyvažování zátěže a škálování. A teď s čistým svědomím upíjíte mojito v houpací síti během habra efektů, místo abyste zvedali padlé servery. Ale ve všech činnostech musíte být důslední. Velmi často je kontejnerizována pouze samotná aplikace – kód. Co dalšího kromě kódu máme?
Přesně tak, data. Srdcem každého projektu jsou jeho data: mohou to být buď typické DBMS – MySQL, Postgre, MongoDB, nebo úložiště používané pro vyhledávání (ElasticSearch), úložiště klíč-hodnota pro ukládání do mezipaměti – například redis atd. V současné době nejsme budeme hovořit o křivých možnostech implementace backendu, když databáze spadne kvůli špatně napsaným dotazům, a místo toho se budeme bavit o zajištění odolnosti proti chybám právě této databáze při zatížení klienta. Když totiž naši aplikaci kontejnerizujeme a necháme ji volně škálovat pro zpracování libovolného počtu příchozích požadavků, přirozeně to zvyšuje zátěž databáze.
Kanál pro přístup k databázi a serveru, na kterém běží, se ve skutečnosti stávají okem jehly v našem krásném kontejnerovém backendu. Hlavním motivem virtualizace kontejnerů je přitom mobilita a flexibilita struktury, která nám umožňuje co nejefektivněji organizovat rozložení špičkového zatížení napříč celou nám dostupnou infrastrukturou. To znamená, že pokud nebudeme kontejnerizovat a nezavést všechny existující prvky systému napříč clusterem, děláme velmi vážnou chybu.
Mnohem logičtější je klastrovat nejen samotnou aplikaci, ale i služby odpovědné za ukládání dat. Klastrováním a nasazením samostatně fungujících webových serverů, které si v k8s rozdělují zátěž mezi sebe, už řešíme problém synchronizace dat – stejné komentáře u příspěvků, vezmeme-li za příklad nějaké médium nebo blogovou platformu. V každém případě máme vnitroklastrovou, dokonce virtuální, reprezentaci databáze jako ExternalService. Otázkou je, že samotná databáze ještě není clusterovaná – webové servery nasazené v kostce berou informace o změnách z naší statické bojové databáze, která rotuje samostatně.
Cítíte úlovek? Používáme k8s nebo Swarm k rozložení zátěže a zabránění zhroucení hlavního webového serveru, ale neděláme to pro databázi. Pokud se ale databáze zhroutí, pak celá naše klastrovaná infrastruktura postrádá smysl – k čemu jsou prázdné webové stránky, které vrací chybu přístupu k databázi?
Proto je nutné klastrovat nejen webové servery, jak se to běžně dělá, ale i databázovou infrastrukturu. Jen tak můžeme zajistit strukturu, která plně funguje v jednom týmu, ale zároveň je na sobě nezávislá. Navíc, i když se nám polovina backendu při zátěži „zhroutí“, zbytek přežije a systém synchronizace databází mezi sebou v rámci clusteru a možnost nekonečného škálování a nasazování nových clusterů pomůže rychle dosáhnout požadované kapacity. - jen kdyby v datovém centru byly stojany .
Databázový model distribuovaný v klastrech vám navíc umožňuje přenést právě tuto databázi tam, kde je potřeba; Pokud se bavíme o globální službě, tak je celkem nelogické roztáčet webový cluster někde v oblasti San Francisca a zároveň posílat pakety při přístupu do databáze v moskevské oblasti a zpět.
Kontejnerizace databáze také umožňuje sestavit všechny prvky systému na stejné úrovni abstrakce. Což zase umožňuje řídit právě tento systém přímo z kódu, vývojáři, bez aktivního zapojení administrátorů. Vývojáři se domnívali, že pro nový podprojekt je potřeba samostatný DBMS – snadné! napsal soubor yaml, nahrál jej do clusteru a máte hotovo.
A samozřejmě se výrazně zjednoduší vnitřní ovládání. Řekněte mi, kolikrát jste zavřel oči, když nový člen týmu vložil ruce do bojové databáze kvůli práci? Který vlastně jediný máte a právě teď točí? Samozřejmě jsme tu všichni dospělí a někde máme čerstvou zálohu a ještě dál - za regálem s babiččinými okurkami a starými lyžemi - další zálohu, třeba i v chladírně, protože vám už jednou hořela kancelář. Ale stejně každé představení nového člena týmu s přístupem k bojové infrastruktuře a samozřejmě k bojové databázi je pro všechny kolem kýbl validolu. No, kdo ho zná, nováček, možná je zkřížený? Je to děsivé, budete souhlasit.
Kontejnerizace a ve skutečnosti distribuovaná fyzická topologie databáze vašeho projektu pomáhá vyhnout se takovým momentům ověřování. Nevěříte nováčkovi? OK! Dejme mu jeho vlastní cluster, se kterým bude pracovat a odpojíme databázi od ostatních clusterů - synchronizace pouze ručním stiskem a synchronním otáčením dvou klíčů (jeden pro vedoucího týmu, druhý pro admina). A všichni jsou šťastní.
A nyní je čas změnit se v odpůrce shlukování databází.
Temná strana
Argumentovat tím, proč se nevyplatí kontejnerizovat databázi a nadále ji provozovat na jednom centrálním serveru, se nesnížíme k ortodoxní rétorice a prohlášením typu „dědové provozovali databáze na hardwaru a my také!“ Místo toho se pokusme vymyslet situaci, ve které by kontejnerizace skutečně přinesla hmatatelné dividendy.
Souhlas, projekty, které opravdu potřebují základ v nádobě, by ne nejlepší frézař spočítal na prstech jedné ruky. Z velké části je nadbytečné i samotné použití k8s nebo Docker Swarm - poměrně často se k těmto nástrojům uchyluje kvůli všeobecnému humbuku technologií a postojům „všemocných“ v osobě pohlaví tlačit vše do mraky a kontejnery. No protože teď je to v módě a dělá to každý.
Minimálně v polovině případů je použití Kubernetis nebo jen Docker na projektu nadbytečné. Problém je v tom, že ne všechny týmy nebo outsourcingové společnosti najaté na údržbu infrastruktury klienta si to uvědomují. Horší je to, když jsou kontejnery uloženy, protože to klienta stojí určité množství mincí.
Obecně panuje názor, že mafie docker/cube hloupě drtí klienty, kteří tyto problémy s infrastrukturou outsourcují. Abychom totiž mohli pracovat s clustery, potřebujeme inženýry, kteří jsou toho schopni a obecně rozumí architektuře implementovaného řešení. Náš případ jsme již jednou popsali v publikaci Republic - tam jsme zaškolili klientský tým pro práci v realitách Kubernetis a všichni byli spokojeni. A bylo to slušné. Často si „implementátoři“ k8 berou klientskou infrastrukturu jako rukojmí – protože nyní jen oni chápou, jak tam vše funguje, na straně klienta nejsou žádní specialisté.
Nyní si představte, že tímto způsobem outsourcujeme nejen část webového serveru, ale i údržbu databáze. Řekli jsme, že BD je srdce a ztráta srdce je smrtelná pro jakýkoli živý organismus. Vyhlídky zkrátka nejsou nejlepší. Takže místo humbuku Kubernetis by se mnoho projektů prostě nemělo trápit s normálním tarifem pro AWS, který vyřeší všechny problémy se zátěží na jejich webu/projektu. Ale AWS už není v módě a předvádění stojí víc než peníze – bohužel i v IT prostředí.
OK. Možná, že projekt skutečně potřebuje clustering, ale pokud je vše jasné s bezstavovými aplikacemi, jak pak můžeme zorganizovat slušnou síťovou konektivitu pro clusterovou databázi?
Pokud mluvíme o bezproblémovém inženýrském řešení, což je přechod na k8s, pak je naší hlavní bolestí replikace dat v klastrované databázi. Některé DBMS jsou zpočátku poměrně loajální k distribuci dat mezi svými jednotlivými instancemi. Mnozí další nejsou tak přívětiví. A dost často hlavním argumentem při výběru DBMS pro náš projekt není schopnost replikace s minimálními náklady na zdroje a inženýrství. Zvláště pokud projekt nebyl původně plánován jako mikroslužba, ale jednoduše se vyvíjel tímto směrem.
Myslíme si, že o rychlosti síťových disků není třeba mluvit – jsou pomalé. Tito. Stále nemáme skutečnou příležitost, pokud se něco stane, restartovat instanci DBMS někde, kde je více, například výkon procesoru nebo volná RAM. Velmi rychle narazíme na výkon virtualizovaného diskového subsystému. V souladu s tím musí být DBMS přibit k vlastní osobní sadě strojů umístěných v těsné blízkosti. Nebo je třeba nějak zvlášť uchladit dostatečně rychlou synchronizaci dat pro domnělé rezervy.
Pokračujeme v tématu virtuálních souborových systémů: Docker Volumes bohužel nejsou bezproblémové. Obecně bych si v takové věci, jako je dlouhodobé spolehlivé ukládání dat, rád vystačil s technicky nejjednoduššími schématy. A přidání nové abstrakční vrstvy z FS kontejneru do FS nadřazeného hostitele je riziko samo o sobě. Ale když provoz systému podpory kontejnerizace narazí také na potíže s přenosem dat mezi těmito vrstvami, pak je to opravdu katastrofa. V tuto chvíli se zdá, že většina problémů známých progresivnímu lidstvu byla vymýcena. Ale chápete, čím složitější je mechanismus, tím snáze se rozbije.
Ve světle všech těchto „dobrodružství“ je mnohem výnosnější a snazší udržet databázi na jednom místě, a i když potřebujete aplikaci kontejnerizovat, nechte ji běžet samotnou a prostřednictvím distribuční brány přijímat současnou komunikaci s databáze, která se bude číst a zapisovat pouze jednou a na jednom místě. Tento přístup snižuje pravděpodobnost chyb a desynchronizace na minimum.
K čemu směřujeme? Kontejnerizace databáze je navíc vhodná tam, kde je to skutečně potřeba. Nemůžete nacpat databázi plné aplikace a roztočit ji, jako byste měli dva tucty mikroslužeb – takhle to nefunguje. A to musí být jasně pochopeno.
Místo výstupu
Pokud čekáte jednoznačný závěr „virtualizovat databázi nebo ne“, pak vás zklameme: tady to nebude. Protože při vytváření jakéhokoli infrastrukturního řešení se člověk musí řídit nikoli módou a pokrokem, ale především zdravým rozumem.
Jsou projekty, kterým principy a nástroje, které Kubernetis přináší, perfektně sedí a v takových projektech je klid alespoň v backendové oblasti. A jsou projekty, které nepotřebují kontejnerizaci, ale běžnou serverovou infrastrukturu, protože se zásadně nemohou přeškálovat na model clusteru mikroslužeb, protože padnou.
Zdroj: www.habr.com