Szanaszét particionált lemezek...

Árulja már el minden saját lemezét szanaszét particionáló/feladatonként külön kötetekbe szervező (pl. külön www-data, külön mysql, külön postgresql, külön whatever) jóember, hogy mégis miert jó?

Főleg, ha utána nincs figyelve, hogy hol mennyi lemezhely van és egyszer csak elfogy valahol, aztán meg mondjuk leáll egy ilyen aprócska lényegtelen szolgáltatás, mint a postgresql.

Bár tény, hogy hatásos ébresztőóra, amikor reggel negyed 8-kor jön a telefon főnöktől, hogy "kritikus hibát ír az oldal". (Az más kérdés, hogy instantforward lesz a rendszergazdáknak ilyen esetben.)

( hadace | 2011. 09. 02., p – 08:11 )

ha a sírásba fektetett időt inkább munkára fordítod, MINDENKI jól járt volna :)

( nevergone v | 2011. 09. 02., p – 08:20 )

Elvileg vannak biztonsági okai, mert az egyes partíciókra könnyen lehet nosuid, noexec, egyéb flag-eket mondani Bár ez inkább régen volt fontos, amikor még nem voltak ennyire elterjedve a különféle, rendszerbe integrált biztonsági megoldások.

Gyakorlatban én is mindig a hátrányát látom, mert akárhogy is tervezik, az egyik partíció mindig kevés lesz, a másik pedig túl nagy, egyiknél levágni kellene az üres helyből, a másikhoz hozzárendelni, és persze lehessen mielőbb újra használni a gépet.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Én ismerem, viszont pár olyant, aki „régen olvastam erről a partíciós dologról és azóta is biztosan úgy kell” elvet követve egyszerűen csak particionál.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

LVM-l is kitorolheti az ember a feneket, ott is ugyanugy elfogy a hely.

Azt meg el is felejtettem megemliteni, hogy annak, hogy a diszken elszorva vannak a dolgok, meg van egy aprobb teljesitmenybeli vonzata is, de ez se erdekeljen senkit.

----------------
Lvl86 Troll

Igen, de jelen esetben csak egy service-t érint (meg azokat amik függnek tőle). Ez a lényege.

Illetve olyan jelentéktelen dolgok, hogy /tmp, /var/tmp külön, és noexec mount, /var/log külön, s ha megtelik nem áll meg minden, stb, stb, stb.

Nyilván ésszel kell csinálni, s egy üres hely figyelő script pár sor bash-ban.

Az élet sajnos 2011-ben nem ilyen egyszerű, amióta ritka az a service, ami nem integrálódik semmivel.

Itt konkrétan a PostgreSQL halt le, ez magával rántotta a webshopot, persze, ugye így a rendelések sem mennek át az ügyviteli rendszerbe, ezen kívül egy másik nagyker rendszer ebből a webshopból húzza át a termékjellemzőket, onnan meg sok kicsi webshop.

Az, hogy egy-két dolog összekutyulódott az megint részletkérdés. (konkrétan most futkosnak még azok a dolgok, amiknek éjjel le kellett volna futniuk, pl., persze, emellett megy élesben az oldal.)

Valóban tök jó, hogy csak egy servicet érint ;)

----------------
Lvl86 Troll

Nem egy rendszer, hanem harom nagyobb es kisebb kulonallo rendszerek osszessege.

Es igen, tudom en minden josagat es hibajat az egesz rendszer rameso reszenek (=kisker webshop) es azt is tudom, hogy milyen toldozasok-foltozasok es varialasok mentek rajta az elmult 3 evben.

Problema: a szep megoldasok vagy idoben vagy penzben (leginkabb a hozott balansz miatt) nem voltak megvalosithatoak.

De varom az otleteket, hogy te hogy csinaltad volna, aztan megmondom, hogy miert nem ugy tortent :)

----------------
Lvl86 Troll

Hat en a termeklistat egy cron-nal kigeneraltatnam, es azt adnam oda a partnereknek, statikus fajl, es nem erdekli, hogy nincs mogotte db. Nyilvan nem lesz mindig up-to-date de szerintem egy bolthoz az 1-3 perces frissesseg mar eleg.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"egy másik nagyker rendszer ebből a webshopból húzza át a termékjellemzőket, onnan meg sok kicsi webshop."

En erre reagaltam. Mivel gondolom a rendelesek tudnak kesobb is jonni (a rendeles queue-zasa legyen a partner gondja), viszont a termekjellemzokhoz felesleges megjaratni a komplett ugyviteli rendszert, mert ha doglott akkor ugysincs uj termek, ha meg megy, akkor meg legalabb ez se a rendszert terheli. Sima CSV/XML/JSON/YAML tok eleg ra.

Aztan tovabb lehet gondolni, hogy a megrendelesek direktben jonnek valami webservice-nak, ami ha nem eri el a db-t, akkor lerakja valami xml/yaml/json-ba valahova, es ha van db, akkor betolja. Ebbe az a szep, hogy ha kell valamit processzalni, ami megy db nelkul is (pl. penz atvaltas, afa processzalas, barmi), azt mar itt el lehet vegezni. Igy legfeljebb a partner nem tudja lekerdezni a rendeles allapotat, de bekuldeni be tudja.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Bocs felreerthetoen irtam. Az "egy nagyker rendszer" az a nagyker webshopja lett volna. Nyilvan meg lehetett volna irni maskepp is, de nem en irtam.

Megrendelesek meg sehova nem mennek, ha nincs DB, ugyanis a megrendelesek a kisker webshopbol a kisker ugyviteli rendszerebe mennek (mert olyan is van).

----------------
Lvl86 Troll

A kerdes az, hogy a termekjellemzok mindig online vannak lekerve? Vagyis, ha beballag az uf a webshopba, es rakattint egy termekre, akkor az mindig toletek keri le az infot? Mert ha nem, akkor offline-osithato a dolog, xml-be kigeneralod a jellemzoket, es ha jonnek erte, egy webszervizzel kiszolgalod.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Oke, de a kabel egyik vegen azert csak latod a forgalmat, jol meg lehet tippelni, hogy online vagy offline kerik le, illetve te ismered a rendszer mukodeset is. Ha nagy a forgalom a webservice korul, naponta parszazszor meghivjak, akkor mindig online olvassa ki toletek a termekjellemzoket, db-ben nem tarolja, ekkor szopo lehet. Ha csak napi egyszer erinti a termekjellemzoket, akkor cacheli. Ezt egy apache log megmondja neked jol.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

De ertsd mar meg, hogy _NINCS_ webservice a kisker webshopnal. A nagyker webshop automatizaltan racsatlakozik naponta 1x a kisker webshop adatbazisara, megfelelo tarolt eljarasokkal kiolvassa es elmenti maganak. (Kozos a kisker-nagyker gepparkja).

Masik webshop fejlesztoje szerette az egyszeru megoldasokat. Erteem? :)

----------------
Lvl86 Troll

Na most ha ezt hétfőn reggel írod, akkor azt mondanám, hogy persze, csak nem az én felelősségem. Ma meg át kellett vennem az egészet... :D

Egyébként megjegyzem, nem a termékjellemzők a legnagyobb problémák, hanem a rendelések átvitele, amit nem, nem tudsz teljesen atom-stabilra megoldani, már csak a nyomorék UPC miatt sem.

----------------
Lvl86 Troll

Elfogy, de ha van még benne tartalék (azaz csak a kiosztott méretből fogyott ki), akkor egy egyszerű:

lvextend -L +1G /dev/vg0/akarmicsatolas
xfs_growfs [mountpoint]

s akadás nélkül megy tovább. Nyilván nem 100%-nál kell észbe kapni.

Ha meg fizikailag is elfogy a hely, akkor tök 8, mennyi felé van particionálva. LVM esetén meg ha elfogy, teszel be disket, vg extendál, örül.
Ha nálatok ez gond volt, akkor a rendszergazdáitok voltak a figyelmetlenek. Ennyi.

( nanto | 2011. 09. 02., p – 09:46 )

kicsit off, de en apamnak nem tudom evek ota elmagyarazni, hogy nem eppen elegans es nem is praktikus megoldas MOVIE, GAMES, es INSTALL particiot csinalni az egyterasan, ez a 3 bekesen megferne egymas mellett egy particion is, es nem is lenne para, hogy az egyik tele lett.

Nalam az egesz /root egyben van, van azon kivul egy /media-ba felcsatolt meghajto van meg, hogy ujratelepites (eleg kicsi az esely hogy ilyenre szukseg lesz, ugyanis chroot, package dowmngrade, config file torolgetes, uj user, stb. megold mindent) elott legyen hova kimenteni midnent, meg ujratelepites zeneket filmeket ne erintsen. /home-ot se valasztottam kulon, de annak talan van ertelme (pl. ha a buta user tele rakja, nem a /root-ban nem fog tudni beirodni valami fontos fajl, vagy ujratelepites utan /home-ban levo user configok (pl. bongeszoelozmenyek) megmaradnak)

Hat en most raszaladtam egy ilyenre. Grub2, RAID, Ubuntu. Kedvenc Ubuntunk nem particionkent csinalt raidet, hanem a komplett diszket rakta abba (miert? passz). Mindegy, segond, ez is egy mukodokepes allapot, elel addig ameddig el kell neki elnie. Valami eltort a grub2-be, mert a rendszer be se jon, semmit ki nem ir, csak rebootol bootolas helyett. Oke, mondom sysrescd, engedelyezzuk a grub-ba a menuzest, hogy at tudjak terni a masik kernelre, megnezni, mi a nyug. Raid osszetol, mindent felmountoltam, chroot, vim /etc/default/grub, :wq, grub-mkconfig. Aszondta nincs ilyen particio. Eleg sok kort futottam vele, utana felkerult a grub (es le a grub2). Nem hiszed el, azota mindket kernel tok szepen bootol.

Na, ez jol peldazza a velemenyemet a grub2-rol.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( LGee | 2011. 09. 02., p – 10:18 )

> Főleg, ha utána kurvára nincs figyelve

Ennyi a lenyeg, Tapasztalattal es monitorozassal meg lehet csinalni ertelmesen. Amugy csak az a lenyeg, hogy a statikus filerendszerek kulon legyenek valasztva a valtozo meretuektol (pl. user home, rendszer logjai, alkalmazas logjai, adatbazis).

( hrgy84 | 2011. 09. 02., p – 12:17 )

A kulon particio felesleges, de a kulon LVM jo otlet lehet. Egyreszt az LVM dinamikusan novelheto, masreszt pedig az lvm kotetnek maganak mindegy, hogy egy raid node-val, egy nyers diskkel, vagy egy iscsi LUN-nal novelted meg a teruletet, mindent egysegesen lat.

Nyilvan az ilyen kulonparticionalasok egyenes kovetelmenye a monitorozottsag. Es itt nem csak arrol beszelunk, hogy a rendszer 75%-nal warningol egyet, akkor leokezzuk, hogy oke baratom, meg van helyed, hanem akkor mar meg kell rendelni a winyokat, es mielott criticalba fordulna a dolog, tervezni egy leallast - ha szukseges, es nem hotswap -, es betenni a winyokat. Ez az uzemeltetes feladata, ezert kapjak a penzuket. Ha ez nincs, akkor a komplett gardat elso korben el lehet hordani mindennek, a kovetkezo esetnel pedig fel lehet ajanlani, hogy ok hordjak el magukat.

Ja, es ha a fejlesztonek szolnak ilyenert, akkor szolni kell, hogy az uzemeltetes pont erre van tartva - aztan aludni tovabb.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( HalfDemon v | 2011. 09. 03., szo – 16:13 )

"lehetett volna akar kulon szerveren is..."

( asd | 2011. 09. 08., cs – 11:07 )

látom valakinek nem erőssége a monitorozás...
és ha nem az, akkor tök mindegy, hogy 1 vagy 10 volume-ot nem monitoroz...
csak a baj lesz nagyobb ha elfogy az _összes_ hely.

LVM nelkul szoba se jon a szeparalas, illetve a kiskazalnyi particio letrehozasa. LVM nelkul kell 3 particio, es slusszpassz: /boot, swap, /. Minden mas LVM-en ertendo, mert csak ott van ertelme (meg esetleg majd ZFS-en).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

En mindenkeppen terveznek egy minimalis swapet. A mai merevlemez arak mellett akar 1G sem tul sok, cserebe megvan az az elonye, hogy nem hal meg a gep, ha betelik teljesen a memoria. Tudom, hogy ez a mostani memoriameretek mellett gyakorlatilag minimalis, megis-megis, en jobb szeretek nyugodtan aludni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

en meg pont azert nem tervezek swapet (1G-t a sok G RAM melle meg plane nem), mert tul sok remhirt hallottam mar arrol, hogy lelassult a rendszer, mert a Linux 1G foglalt 3G szabad memoria mellett megiscsak a swapbe akart pakolni par dolgot (sot, nem csak remhirt, desktopon sokszor lassultam is be emiatt, miota nincs swapem, nem lassul be a desktopom konkretan). Egyszeruen nem vagyok hajlando tobbet swappel szenvedni, ha nem muszaj.

Mellesleg ha a memoria betelik, akkor a swap is, esetleg ha egy program a vegtelensegig folyamatosan probalna lefoglalni, akkor talan picit lassabban (de olyan meg eleve miert futna?) :)

A remhir igaz, csak az okokat szereti elfelejteni mindenki elmondani. A memoriakezeles ugyanis ugy mukodik, hogy a kevesbe aktiv processzek memorialapjai kerulnek swapre. Namarmost, desktop eseteben ilyet el tudok kepzelni, egy szerver azonban teljesen mas teszta, ott nincsenek ugymond felesleges szolgaltatasok (ha vannak, az nem production szerver). Vagyis, ha valahol, egy eles es aktivan hasznalt szerveren nagyon kicsi az eselye, hogy pl. az Apache vagy a Postfix swapre keruljon, annyi forgalom mindig lesz.

A memoria beteleshez: kulonbseg van akozott, hogy swap mellett telik be a fizikai memoria es akozott, hogy swap mellett. Azt kell megerteni, hogy a Linux memoriakezeleset alapvetoen ugy irtak meg, hogy az tamaszkodik a swapre, mint szolgaltatasra. Amennyiben a fizikai memoria betelik, es nincs swap, az egesz szerver ugy megall, mint a szog. Ha van swap, akkor a szervernek van lehetosege sulyozni, pl. az inaktiv shelleket ki tudja pakolaszni swapre, vagy a monitorozo szolgaltatasokat, a lenyeg, hogy van a rendszernek valamennyi mozgasterulete addig is, amig pl. az oom-killer ki tudja loni a tulfoglalo processzeket. Ha nincs swap, akkor csak a kardjaba tud dolni a rendszer, es ennyi.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( hnsz2002 v | 2011. 09. 10., szo – 01:59 )

Ha tele, nem hal le minden, mert még egy pid fájlt sem tud írni.
Ha borul vagy sérül akármilyen ok miatt (szabálytalan leállás, softraid, fs), akkor max. az adott service adatait bukod (tudom, backup...)
Nagyjából ennyi, persze monitorozni kell...
Attól függ milyen szolgáltatások futnak a szerveren, aszerint szoktam particionálni. Egy átlagos lamp+mail szervernél pl: /boot, /, /tmp, /var/lib/mysql, /val/spool/mail, /var/log, /srv/www, és /backup külön partíciók.
[szerk] Még az lehet esetleg, hogy más az optimális fs. tmp-re bőven jó egy XFS (vagy sok ram esetén akár ramdisk), mailre ext4 (maildir), mysqlhez ext3 (fontos adatok...).
--
Discover It - Have a lot of fun!