Mert ha több egymással kommunikáló rendszered van, akkor az összességében nem egy komplex megoldás csak mert több komponensből van.
erzek egy picinyke kulonbseget a tobb, adott celra kihegyezett eszkozok okoszisztemaja es egy mindent csinalni akaro blob kozott. Meg mielott nagyon elszallnal a brekingnyuzodtol, talan valaszolhatnal arra is, amit olyan elegansan elsumakoltal, hogy megis mit tud tenni a systemd, ha meghal a gep (pl. kernel panic, hw-hiba, stb. miatt)? Csak azert, mert a valaszbol te is megerted, hogy a systemd monitorozasra finoman szolva nem megfelelo.
Masfelol ha a systemd-nel nem 1 db bin file van, hanem tobb utility, demon, whatever (bar ez pusztan tervezesi dilemma, keveset valtoztat a kepen), akkor is ott vagyunk, hogy egyik oldalon a meglehetosen komplex systemd van, ami sosem lesz olyan jo egy adott feladatban, mint a masik oldalon levo monitorozo cucc, ami erre a feladatra van kihegyezve. De karpotlaskent a systemd-vel 5 sec-cel hamarabb kapsz login promptot.
Nem is azt mondtam, hogy minden itt van, de te kértél példát. Most akkor ne sírjon a szád miatta.
ja, hogy nem minden ott van? Akkor maris ugrott a jaj, de nehezen indul el 50 service a gepen siram. Igen, peldat kertem, _eletszagu_ peldat, de vegul csak kibujt a szog a zsakbol, LOL.
Szóval mi is lenne az ideális felosztás szerinted?
az idealis felosztas sokban fugg az adott helytol, de az emlitett 8-16 cpu-s gepen, amire hivatkoztal, de en (hacsak valami nem indokol) az alabbit csinalnam.
- dns, ntp: a szolgaltato rezolvereit (+auth dns-eit) es ntp szerveret hasznalnam (-2 vagy 3 demon, -2 biztonsagi res a pajzson)
- syslog, cron, ssh: nincs mese, ezek kellenek minden gepen, cserebe pikk-pakk elindulnak
- sql szerver*: egyelore maradjon a gepen, par sec. ennek is kellhet, amig elindul
- apache**, fcgi: ha mar webszerverrol van szo, legyen rajta ez is. Valoszinuleg nem (annyira) kritikus, ha a webszerver mar fut, es az sql szerver csak par sec mulva all fel, de csinaljuk szepen, es varja csak szepen ki az apache, amig elindul az sql szerver
- rsyncd: nem inditanam el, hanem az ssh-t hasznalnam transzportkent (-1 demon)
- sphinx***: ha nagy sp* file-ok vannak, akkor valoban ido amig beolvassa, ami kell neki. Csinaljuk szepen, es varja meg ezt is az apache, de a sphinx meg varja meg a sql szervert, biztos kell neki
- openvpn: ne fusson a gepen, hanem oldjuk meg a funkciot halozati eszkozzel, tipikusan egy tuzfallal (-1 demon, -1 erosen takoltnak mondott dolog)
- levelezes: kulon gepre (ugye, ugye?) Ja hogy webmail, az mas, akkor nyilvan az az esszeru, ha a production / dev webszerverre kerul :-)
- samba: ja, hogy ez sincs, akkor ennek az allitolagos lassu indulasaert sem kell panaszkodni
*: van az az elethelyzet, amikor plusz overhead miatt is megeri kulon tenni az sql szervert (esetleg klasztert)
**: megneznem, elmegy-e a cucc nginx alatt is. Ha igen, akkor dobnam az apache-ot, ami kb. olyan a webszerverek vilagaban, mint a spamassassin a spamszuroknel.
***: ha az sql szerver is kulon lenne, akkor el lehetne gondolkodni, hogy feltetlen a webszerveren van-e ennek jo helye?
Nyilvan egy idealis kialakitashoz azt is tudni kell, hogy mit is szeretnenk, hogy egy nagy latogatottsagu site-unk van, ami szenne kell optimalizalni, vagy egy az alagsorba tett es lezart dev szerverrol, amin ki nem **ja le (imho ennel sem kellene), hogy karacsonyfat jatszik. De a lenyeg az, hogy (imho) nem eletszeru a jaj, alig birom kivarni, mire minden elindul siram.