Portworx by Everpure: Kontejner je standardizovao transport, ali nije izgradio luku
Zašto orkestracija aplikacija ne rešava automatski pitanje podataka i šta Portworx by Everpure dodaje Kubernetes arhitekturi
Pedeset osam sanduka na palubi
Kada je preuređeni tanker „Ideal X“ 1956. godine isplovio iz Njuarka s pedeset osam metalnih sanduka na palubi, niko u luci nije imao utisak da prisustvuje prekretnici. Brod nije bio brži od ostalih, motor nije bio jači, ruta nije bila nova; promenila se samo jedna, naizgled banalna stvar: teret više nije bio pakovan u vreće, burad i sanduke različitih dimenzija, nego u jedinicu čije su mere, nosivost i način prihvatanja bili unapred dogovoreni.
Efekat te dosadne odluke bio je nesrazmeran njenoj složenosti. Isti sanduk mogao je da pređe s broda na vagon, pa s vagona na kamion, bez ijednog otvaranja i bez ijednog ručnog pretovara sadržaja. Vreme koje je brod provodio vezan uz obalu smanjilo se s nedelja na sate, a cena transporta jedne tone pala je do nivoa na kojem je globalna proizvodnja postala izvodljiva kao poslovni model.
Ono što se u toj priči često preskoči jeste da standardizacija transportne jedinice nije završila posao – tek ga je premestila, pa su lukama bili potrebni portalni kranovi drugačije konstrukcije, betonski platoi za slaganje kontejnera u više redova, sistemi za dodelu prostora, manifesti koji opisuju šta je u kojoj jedinici, pravila prioriteta, rezervne rute kada čvorište stane i deponovane kopije dokumentacije kada originalna pošiljka nestane. Standardizovani kontejner rešio je jedan sloj problema i time razotkrio sve ostale.
U prethodna tri teksta ovog serijala pratili smo kako se enterprise infrastruktura kretala od skladišta ka platformi i kako Everpure arhitektura izbegava zastoje. Ovaj tekst se bavi slojem koji nastaje kada se ista logika prenese u Kubernetes.
Kubernetes je rešio raspored, ali podaci imaju masu
Kubernetes je za aplikativni deo infrastrukture uradio ono što je kontejnerizacija uradila za teret – definisao je standardnu jedinicu izvršavanja i preuzeo odgovornost za njeno raspoređivanje: gde će se pokrenuti, koliko instanci treba da postoji, šta se dešava kada čvor otkaže i kako se saobraćaj preusmerava tokom nadogradnje. Za stateless radna opterećenja – ona koja ne čuvaju sopstveno stanje između dva pokretanja – taj model je gotovo savršen. Instanca koja nestane ne nosi sa sobom ništa nezamenljivo; scheduler je jednostavno pokrene na drugom mestu i sistem nastavlja da radi.
Problem počinje onog trenutka kada aplikacija ima stanje. Baza podataka, message queue, sistem za obradu transakcija ili vektorska baza koja opslužuje AI upite jesu tehnički kontejnerizovani na isti način kao i bilo koji veb servis, ali njihova vrednost ne leži u procesu koji se izvršava, nego u podacima koji stoje iza njega. Pod (najmanja jedinica koju Kubernetes pokreće i raspoređuje, sastavljena od jednog ili više kontejnera koji dele životni ciklus) može biti efemeran, ali poslovni podatak to nije. Kada Kubernetes odluči da radno opterećenje premesti na drugi nod, u drugu availability zonu ili u drugi klaster, postavlja se pitanje koje control plane sam po sebi ne rešava: Da li podaci putuju s aplikacijom, kojom brzinom, s kakvim garancijama konzistentnosti i po kojoj politici zaštite?
To pitanje je u fazi eksperimenta praktično nevidljivo. Klaster ima deset radnih opterećenja, jedan storidž sistem i jednog inženjera koji zna kako je sve povezano. U produkciji s nekoliko stotina aplikacija, više klastera i kombinacijom on-prem i cloud infrastrukture, isto pitanje postaje operativni teret koji raste brže od tima koji ga nosi.
CSI: standardni prihvat nije kompletna logistika
Container Storage Interface (CSI) upravo predstavlja ono što luci znači standardizovani prihvatni mehanizam na kranu. To je „ugovor“ između Kubernetes-a i storidž sistema koji odvaja životni ciklus drajvera od životnog ciklusa same platforme, pa proizvođači mogu da razvijaju i objavljuju drajvere nezavisno od Kubernetes izdanja. Standardni deo tog ugovora pokriva osnovni provisioning volumena i upravljanje njihovim životnim ciklusom, a sve preko toga svaki proizvođač dodaje kroz sopstveni plugin.
Bez CSI-ja ne bi bilo ozbiljnog persistent storidža na Kubernetes-u i to treba jasno reći. Ali kran koji ume da prihvati kontejner nije isto što i logistički sistem koji zna gde ta jedinica treba da stoji, koliko joj prostora pripada, kakav prioritet ima u odnosu na susedne pošiljke, gde postoji njena kopija i šta se dešava kada terminal ispadne iz rada.
Ograničenja se, kako i sam proizvođač otvoreno navodi u poređenju sopstvene platforme sa standardnim CSI pristupom, gotovo nikada ne vide u malim testnim okruženjima – ona izlaze na videlo tokom Day 2 operacija na skali. Svaki drajver donosi sopstvenu krivu učenja i sopstveni skup mogućnosti, pa standardizacija razvojnih i platformskih workflow-a postaje teška. CSI je, po svojoj prirodi, produžetak tradicionalnih storidž arhitektura i nije projektovan za nivo dinamičkog, distribuiranog raspoređivanja koji Kubernetes podrazumeva. U okruženjima s više klastera i više storidž sistema javlja se ono što se naziva CSI sprawl, gde nadogradnje, zakrpe i migracije podataka produžavaju vremenske prozore za održavanje i akumuliraju tehnički dug. Na kraju, kada podaci žive na više različitih storidž sistema, istu bezbednosnu politiku i jedinstven revizioni trag teško je sprovesti nad svima. Osnovni CSI uz to ne zna kako je okruženje fizički raspoređeno, pa ne može da garantuje da dve kopije istog volumena neće završiti tamo gde ih isti kvar odnosi zajedno. Ovde ne govorimo o lošoj tehnologiji, nego o pogrešnom očekivanju – interfejs za povezivanje nije sloj za upravljanje podacima.
Portworx: sloj podataka koji putuje s aplikacijom
Portworx by Everpure pozicioniran je upravo na toj granici. Nije reč o još jednom storidž sistemu, nego o čistom Kubernetes sloju za upravljanje podacima koji agregira postojeću infrastrukturu (bilo čiji blok storidž, cloud diskove ili FlashArray sisteme) u zajednički pool, a zatim njime upravlja kroz iste deklarativne mehanizme kojima Kubernetes upravlja aplikacijama. Politika zaštite, nivo replikacije, pravila smeštanja i prava pristupa opisuju se kao objekti u klasteru, a ne kao konfiguracija na uređaju ispod njega.
Posledica te odluke ogleda se u tome što se sloj podataka ponaša kao deo aplikacije, a ne kao njeno okruženje. Kada se radno opterećenje pomeri, njegova politika ide s njim i to je razlika između pošiljke koja ima manifest i pošiljke koja ima samo nalepnicu sa adresom.
Automate: terminal koji ne čeka dispečera za svaki sanduk
Moderan kontejnerski terminal ne funkcioniše tako što operater za svaku jedinicu ručno određuje poziciju. Sistem zna koliko je prostora slobodno, koje pošiljke odlaze prve i kako da rasporedi teret tako da kasnije ne mora sve da premešta. Portworx Enterprise radi po istom principu. Volumeni se dinamički balansiraju, skaliraju i proširuju kroz ugrađeni rules engine, thin provisioning omogućuje da se troši samo ono što je zaista zauzeto, a inteligentno smeštanje volumena kroz granularna affinity i anti-affinity pravila određuje na kojim nodovima i u kojim domenima otkaza replike žive. Volumeni se dodeljuju i pripajaju u milisekundima, a aplikacije i njihovi podaci mogu da se migriraju između klastera, rekova i cloud okruženja bez prekida u radu.
Ono što iz te automatizacije proizlazi važnije je od bilo koje pojedinačne funkcije. Ako developer za svaki novi volumen mora da otvori tiket i čeka storidž administratora, platform tim je prestao da bude platforma i postao je red čekanja. Kada isti taj developer može sam da uzme storidž koji mu treba, direktno iz svog CI/CD lanca, infrastruktura se pretvara u servis; broj aplikacija raste, a količina administrativnog rada ne prati ga u istom ritmu. Da samousluga ne bi značila i gubitak kontrole, tu su granularna prava pristupa, enkripcija volumena povezana s eksternim key management serverima i usklađenost sa SOC 2 i ISO 27001 standardima.
Protect: sanduk bez manifesta nije pošiljka
Klasični bekap model nastao je u svetu virtualnih mašina, gde je jedna VM praktično bila jedna aplikacija. Kopija diska bila je dovoljna, budući da je sve što aplikacija jeste živelo unutar te granice. Kubernetes tu granicu eliminiše, pa je jedna aplikacija sastavljena od više distribuiranih komponenti, njeni persistent podaci žive izvan kontejnera, a njeno stvarno stanje uključuje i Kubernetes objekte – deployment-e, secrets, konfiguracione mape, definicije servisa. Bekap koji obuhvata samo diskove vraća sadržaj bez manifesta: podaci postoje, ali logička celina ne može automatski da se rekonstruiše.
Portworx Backup je zato projektovan kao application-aware i container-granularan: štiti podatke, konfiguracije i objekte aplikacije kao jednu celinu, uz mogućnost da se ciljano vrati samo određena aplikacija, a ne ceo nod ili ceo klaster. Upravljanje je centralizovano kroz hibridna i multi-cloud okruženja, s istim mehanizmom i za kontejnere i za virtualne mašine koje se izvršavaju na Kubernetes-u. Zaštita od brisanja i immutability kopija predstavljaju konkretan odgovor na ransomware scenario, podrška za 3-2-1 pravilo drži tri kopije na dva različita medija s najmanje jednom van lokacije, a rad u air-gapped okruženjima pokriva slučajeve u kojima izolacija nije opcija nego zahtev. Prva korist od takvog pristupa nije bezbednosna nego operativna – kada se vraća tačno jedna aplikacija sa svime što joj pripada, unapred se zna šta će se vratiti i koliko će to trajati, ali kada se vraća komad infrastrukture, to se otkriva tek u toku oporavka.
Disaster Recovery: rezervni terminal, a ne samo arhiva dokumenata
Bekap i disaster recovery (DR) u praksi se često izjednačavaju, ali razlika je, zapravo, suštinska. Arhivirana kopija manifesta govori šta je bilo u pošiljci; rezervni terminal omogućuje da roba stigne i kada primarno čvorište stane. To su dva različita problema i rešavaju se različitim mehanizmima.
Portworx Disaster Recovery oslanja se na replikaciju na nivou storidža i nudi dva profila:
1) sinhroni model, namenjen klasterima unutar iste metro regije uz latenciju ispod deset milisekundi, obezbeđuje nulti RPO – svaka promena na produkcionom klasteru automatski postoji i na DR klasteru, pa u slučaju ispada nema gubitka podataka;
2) asinhroni model pokriva klastere bilo gde u svetu, s RPO vrednostima od petnaest minuta i više, definisanim kroz raspored replikacije. Izbor između ta dva modela arhitektonska je i finansijska odluka: sinhrona zaštita za svaku aplikaciju u portfoliju retko je opravdana, a nivo zaštite treba da prati poslovni značaj radnog opterećenja, a ne uniformno pravilo.
Unify: ista pravila bez obzira na to čiji se put koristi
Vrednost intermodalnog sistema ne leži u tome što svaki prevoznik koristi istu opremu, nego u tome što se ista pošiljka kreće kroz različite mreže (vidove transporta) po istim pravilima. Nijedna ozbiljna kompanija danas ne prevozi robu isključivo jednim modalitetom, kao što ni ozbiljan IT nema samo jednu Kubernetes distribuciju ni samo jednu infrastrukturu.
Portworx je agnostičan i prema infrastrukturi i prema distribuciji, pa isti model upravljanja podacima važi na Red Hat OpenShift-u, SUSE Rancher-u, Amazon EKS-u, Azure AKS-u, Google Kubernetes Engine-u ili IBM Cloud okruženju, kao i na bare metal instalacijama i na integraciji s FlashArray sistemima. Poenta nije u dužini spiska podržanih platformi, nego u tome da se politika zaštite, replikacije i pristupa ne piše iznova za svako okruženje. Fragmentacija upravljanja predstavlja trošak koji se ne vidi u nabavci, ali se svakodnevno plaća u vremenu inženjera i u nedoslednosti bezbednosnih politika.
Tri toka koja se slivaju na isti control plane
Tri velike infrastrukturne inicijative danas kreću se ka istoj tački:
1) modernizacija aplikacija donosi kontejnerizovane, stateful servise;
2) modernizacija virtuelizacije, ubrzana promenama u licencnom modelu nakon Broadcom akvizicije VMware-a, dovodi virtualne mašine na Kubernetes kroz KubeVirt (Portworx je u tom segmentu 2026. godine proglašen za Red Hat partnera godine u oblasti virtuelizacije);
3) AI radna opterećenja, sa svojim zahtevima za pristupom velikim skupovima podataka, sve češće se izvršavaju na istom control plane-u. Kada se tri tako različita profila opterećenja nađu na jednoj platformi, konzistentan sloj podataka prestaje da bude optimizacija i postaje uslov upravljivosti.
Kraj priče koji je zapravo bio početak
Standardizovani kontejner nije učinio luke suvišnim – učinio ih je važnijim. Kada je jedinica transporta prestala da bude problem, sve što se dešava oko nje postalo je merilo kvaliteta celog sistema. Kubernetes je za aplikativnu infrastrukturu odradio isti posao i odradio ga je dobro, ali čim radno opterećenje dobije stanje i poslovnu težinu, pitanje koje se postavlja više ne glasi: Gde ćemo pokrenuti ovaj kontejner? Umesto toga imamo mnogo važniju dilemu: Šta se dešava s podacima kada se kontejner premesti, kada se klaster nadograđuje, kada regija ispadne iz rada ili kada neko pokuša da ih šifruje?
Infrastruktura koja na to pitanje nema unapred pripremljen odgovor nije nesigurna zato što joj nedostaje neka funkcionalnost, nego zato što je odgovor prepustila ljudima da ga improvizuju u trenutku kada za improvizaciju nema vremena.
Tekst pripremio: Miodrag Nikolić, Pre-Sales Engineer, ASBIS Srbija
ASBIS je ovlašćeni Everpure distributer za Republiku Srbiju.
Za ponude i sve dodatne informacije, kontaktirajte nas:
Da postanete ASBIS Partner, popunite formular na sledećem linku: