Kater software uporabljate za avtomatizacijo skaliranja?

V resnici nimam pojma, pa bom vseeno kaj dodal. :-)
Moj "homelab" laufa proxmox in ne vedim kaj od tega ne bi šlo. Load balancing najbrž kar skozi reverse proxy in potem najbrž ni potrebe po različnih public IP.

če boš imel en entry point rabiš samo en javni ip, bo že potem proxy razmetal promet po strežnikih. Več entry pointov bi imel recimo zaradi geografske razpršenosti, da zmanjšaš latenco do uporabnika.

Dobro jutro.

Evo, sem malo iskal sestavne dele po internetu, ter našel tri linke, na katerih so seznami.

https://www.openstack.org/software/proj...

https://openinfra.dev/projects/

https://www.cncf.io/projects/

Na koncu je v eni taki celoti lahko 10, 20, 30 komponent. Poimenovane pa so pravličnih bitjih, kar prehod iz LAMP na Cloud malo oteži.

Tako je. Če razmišljaš v stilu "imam en lamp app, dodal bom magic ingredient in zadeva bo autoskalabilna", si zavozil že v štartu. To ne deluje tako in prva stvar, ki jo moraš doseči je, da nehaš razmišljati na ta način.

Next ... openstack je bil "in" pred 12imi leti, danes je samo ekspresna pot v "štrik vs zvonik" debate. Resno, meni je 2x povzročil zdravstvene težave. Probaj, če ne verjameš.

Danes se zadeve delajo z mikroservices in k8s. Najprej nariši diagram svoje lamp aplikacije na papir, nato pa raztrgaj ta papir na drobne koščke. Vsak košček ti predstavlja eno malo funkcijo, atom aplikacije, ki ga implementiraš kot samostojno storitev in vse skupaj zvežeš z APIji, ki čepijo za load balancerji. Najmanjše zadeve lahko furaš "serverless", večje z nekaj logike pa v bolj ali manj oskubljenih kontejnerjih.

Dobiš že neke komponente, ki ti znajo na vsakem mikroservisu meriti load in po potrebi dodajati ali odvzemati instance. Zadnja leta nisem toliko v teh vodah, da bi jih znal našteti poimensko, a ti bo 5min guglanja vrglo vsaj tri aktualne ponudbe.

V končni fazi se moraš odločiti, kakšen del te autoscaling logike boš prepustil platformi in kakšen del hočeš nadzirati sam. Glede na to odločitev si potem izbereš primerno rešitev in okolje. Začneš lahko z eno piksno, nekim container runtimeom in eno fancy bash skripto v cronu ...

Realnost pa je taka, da so danes piksne že tako velike, da za slovenske potrebe zadošča vsaka 10 let stara (ali mlajša) in je vsako mutenje z mikroservisi samo to, mutenje. Razen če to počneš iz lastne zabave ...

pegasus je 10. jan 2023 ob 22:04 izjavil:

Tako je. Če razmišljaš v stilu "imam en lamp app, dodal bom magic ingredient in zadeva bo autoskalabilna", si zavozil že v štartu. To ne deluje tako in prva stvar, ki jo moraš doseči je, da nehaš razmišljati na ta način.

Next ... openstack je bil "in" pred 12imi leti, danes je samo ekspresna pot v "štrik vs zvonik" debate. Resno, meni je 2x povzročil zdravstvene težave. Probaj, če ne verjameš.

Očitno nisem edini
Jaz sem na srečo bil samo zunanji opazovalec propadlega experimenta.

V osnovi me zanima bolj struktura, ter kako so posamezne komponente povezane. Ker je teh "tool-ov" ko malo morje.

Npr. Harbor (Container registry), ki se potem navezuje naprej na druge tool-e (seznam spodaj):

https://goharbor.io/docs/2.7.0/install-...


Ali pa naprimer OpenStack DESIGNATE (DNS service):

https://docs.openstack.org/designate/la...

Se pravi gre za software, ki (med drugim) skalira administracijo npr. BIND9 serverja, zraven pa uporablja še RabbitMQ.

secops je 9. jan 2023 ob 18:43 izjavil:

Ko neko komponento začne zabijati, povečaš število instanc poda v katerem prebiva komponenta. Ko pa promet upade, recimo ko je konec praznikov, pa samo scalaš nazaj na prvotno število podov. Pri tem paziš samo na to, ali je potrebno dodati nov worker node, da bo dovolj resourcov za dodatne pode. Vse je pa seveda odvisno o kakšnem scalanju govorimo.

Za to uporabiš autoscaling, da ne rabiš ročno gledat grafov ob božični večerji. V cloudu je to enostavno.

pegasus je 10. jan 2023 ob 22:04 izjavil:

Tako je. Če razmišljaš v stilu "imam en lamp app, dodal bom magic ingredient in zadeva bo autoskalabilna", si zavozil že v štartu. To ne deluje tako in prva stvar, ki jo moraš doseči je, da nehaš razmišljati na ta način.

Next ... openstack je bil "in" pred 12imi leti, danes je samo ekspresna pot v "štrik vs zvonik" debate. Resno, meni je 2x povzročil zdravstvene težave. Probaj, če ne verjameš.

Sem ga nekoč celo testno postavil in se strinjam.

Na tem linku sem že bil, in pogledal seznam.

Sedaj nekaj drugega gledam. Npr. ta Harbor (software) ima pod "Harbor Users" in "Harbor Partners" ne ravno majhne firme, recimo China Mobile in BingoCloud (slednji ima spet seznam ne ravno majhnih firm/strank).

Skratka, LAMP na eni strani in OpenStack/CNCF/HashiCorp na drugi strani so praktično dve skrajnosti po veličini.

Vprašanje, ki je mogoče zanimivo, je, kakšne opcije se nahajajo vmes med tema dvema skrajnostima?

Ker to, da imaš danes en BIND9 server na 2-3-5 tisoč evrov vrednem strežniku, jutri pa kar naenkrat rabiš 200 serverjev, ker se je load toliko dvignal... well, ni ravno pogosto. Vprašanje je tudi, koliko so oz. bi se dale aplikacije zoptimizirat, da bi pokurile manj cpu/ram/net resursov. Glede na to, koliko js/css balasta je danes prisotnega na spletu, je tu (verjetno) ogromno prostora. Mogoče pretehta hitrost izvedbe (in zaslužka), da se to ne splača.

Verjamem pa, da obstajajo primeri, kjer niha (u)poraba in da tukaj pride "cloud" prav, ker ga lahko raztegneš po potrebi (kot harmoniko). Ampak to raztegovanje je smiselno, če imaš software na strežnikih od nekoga drugega. Sicer moraš itak sam imet hardware za max load vedno na voljo.

Zanima me, katere so manj poznane opcije za avtomatizacijo, ki bi jih umestil nekje "vmes". Recimo, da število serverjev raste x2 (1,2,4,8,16 itn.); verjetno ni optimalno, da 2 strežnika furaš z 20 tool-i (sploh če je odločitev za to "trendovsko cool trenutni hip" software/pristop/whatever). Je verjetno lažje in hitreje na roko + kaka skripta.

Enkrat sem delal seznam takšnega software-a/tool-ov. Primer spodaj:

Easy-RSA: https://easy-rsa.readthedocs.io
dogtag: https://www.dogtagpki.org
freeipa: https://www.freeipa.org

PXEBootInstall: https://wiki.debian.org/PXEBootInstall
PXEBootDisklessSystem: https://wiki.debian.org/PXEBootDiskless...

collectd: https://collectd.org
Cacti: https://www.cacti.net

Pacemaker: https://clusterlabs.org/pacemaker/
Corosync: https://clusterlabs.org/corosync/

cdist: https://www.cdi.st
skonfig https://skonfig.li


Druga stvar, ki me zanima, pa je prehod iz LAMP monolit-a, vse do nekega L7 nivoja, kjer vse "lebdi" na teh visokih "serverless" rešitvah.

HotBurek je 14. jan 2023 ob 18:11 izjavil:

Ker to, da imaš danes en BIND9 server na 2-3-5 tisoč evrov vrednem strežniku, jutri pa kar naenkrat rabiš 200 serverjev, ker se je load toliko dvignal... well, ni ravno pogosto.

Bind je hkrati slab in dober primer v tej zgodbi. Slab, ker je na današnjem hardveru prepočasen v zgolj najbolj bizarnih situacijah, dober pa zato, ker je DNS caching by design in se lahko po tem dizajnu zgleduješ tudi v web aplikacijah in caching vtakneš na čisto vsako mogoče mesto. Zgolj izjemoma potrebuješ real-time sveže rezultate kakega apija, vedno si lahko privoščiš več sekund ali minut cachinga. Tako da ti razni squidi in varnishi rešujejo rit.
Zanimivosti sem opazil v času Ruby-on-Rails mode. Zadeva je bila out of the box tako fakin počasna, da brez cachinga nisi preživel niti z najbolj enostavnim sajtom. Zato so se ti dečki zelo dobro naučili varnisha in sedaj znajo furati največje web aplikacije. Tako da glej najprej v to smer.

Povzetek bi lahko bil; če gradiš startup, uporabi "boring technology", infrastruktura/software pa naj bo "monolith".

Škoda, da se podjetje ne odloči prvo postavit software in ga laufat kake pol leta, leto, šele potem pa se odloči, ali bo software sploh kupilo in za katero ceno.

Možno, da drirektorčine padajo na bonbone, ki jih v zameno za nakup dobijo: razni pointles (alko) eventi, invite na jaderanje, filing da si član neke elitne skupine, ipd. Ali pa, da ko bodo odslužili v trenutni firmi, jim vendor ponudi job pri njih, in potem iz tiste pozicije prodajajo njihovo robo.

Nisme mislil, da se testira pol leta. Ampak, da daš v produkcijo, s to razliko, da plačaš šele po pol leta.

Tam, kjer ni vendor lock-in-a, so ziher opcije.

Moj komentar se nanaša na zgoraj omenjeni primer, kjer se podjetje prvo odloči za software (recimo SAP), kupi licence, potem pa ga začne uvajat in šele tu spozna, kakšen kluster-fuck-bloatware v resnici je.

Če bi se z SAP-om zmenili, da so načeloma committed, a da bi prvo radi probali in pol leta delali na migraciji/integraciji, bi kasneje pri ceni lahko zbijali, ker bi za sabo imeli 1/2 letno izkušnjo ter vse felerje, nekompatibilnosti,...

Ne vem no, jaz nisem govoril o tem, da bi se za ceno pogajal s tem, kar ti razlagaš (da jim "groziš", da ne boš vzel).

Ampak da, če software že uporabljaš in veš za njegove pomankljivosti tudi v praksi, lahko izpostaviš slabosti/težave pri pogajanju za ceno.

Anyway, lets move one.

Dejansko dostikrat pomeni tudi spremembo sami poslovnih procesov, ker se lažje proces prilagodi SAPu kot obratno.

Sploh pa, ko enkrat nekaj uvedeš in s tem nisi zadovoljen - kam boš pa šel? Nazaj na prejšnji sistem, ki tudi ni bil ok (ker zakaj bi drugače nekaj novega uvajal)? V vsakem primeru rabiš novo migracijo, pa če tudi nazaj na prejšnji sistem.

Evo, sedaj sem našel eno večjo shemo. Izgleda, kot bi gledal programsko shemo 5000 kanalov na eni strani.

https://landscape.cncf.io/?fullscreen=y...

Je toliko opcij, da se kar zgubiš...

Pač raziskujem opcije in primerjam.

Sedajle sem našel software, ki sliši na ime NATS.

https://nats.io/

In sem bral, ter iskal, kam se to umešča v primerjavi s klasiko.

NATS vs RabbitMQ vs Kafka

Tule je pdf, kjer so primerjali te tri sisteme, a v zelo poenostavljenem setup-u.

https://www.diva-portal.org/smash/get/d...

V osnovi naj bi Kafka bil "najboljši" od treh, sicer pa nič dramatičnega.

In v vseh treh primerih gre za 10 let star software. Zakaj sta RabbitMQ in Kafka videna bolj kot klasika (vsaj jaz jih tako vidim), NATS pa kot wow-cloud-buzzword, če so si pa v resnici zelo podobni?

Moje izkušnje z dvema event busoma (Microsoft BizTalk ter Neuron ESB) so taka, da kljub temu da obstajajo vnaprej narejeni adapterji in podpora za razne sisteme se še vedno bistveno hitreje integrira custom .NET kodo s temi sistemi kot pa preko event buss. Da ne omenjam da .NET developerja dobim kadarkoli, za te integracijske sisteme pa se zgublja mesece dni uvajanja pa še slaba volja je med developerji ker vsak ko začne z njimi delat izgubi motivacijo do dela :)

Kar se pa tiče pregleda nad integracijami ki jih te fensi event busi ponujajo, pa se to lahko reši lepo na network nivoju s service mesh precej precej bolj elegantno. Ti event busi kot končni produkti radi marketinško prepričajo kupce v "lej kak lep pregled nad integracijami bomo imeli ko vse integracije migriramo na ta produkt", kar je hud catch ko mal bolj trezno razmišliš o tem.

Za prvo možnost uporabljamo Redis.io.

Burek, če si še kaj stare šole, se marsikaj koristnega in lepo organiziranega najde v obliki mrtvih dreves: https://www.manning.com/bundles/applied...

c3p0 je 25. jan 2023 ob 09:04 izjavil:

Redis že dolga leta rešuje slabo kodo in neoptimalne queryje.

Neoptimalnih queryjev in slabe kode ne resi nic, Redis samo zmanjsa pain ob vsakem naslednjem requestu.