Készülődnék egy állásinterjúra...
Előfordulhat (még nem kaptam megerősítést, csak ígéretet), hogy jövő év elején lesz egy állás interjúm, linuxos rendszergazdaként.
Erre próbálok valamennyire felkészülni, de elég zűrös a dolog. Korábban is rendszergazda voltam, csakhogy linuxokkal elsősorban hobbiból foglalkoztam, a VMS ismereteimmel meg nem megyek sokra ezen a területen, amit meg HPUX-ból tanultam, azt kb. el is felejtettem mostanra.
Szóval ezügyben szeretnék időnként kérdezősködni, ha a törzsközönségnek nem okozok vele gondot (mivel totál offtopik a téma)
Most két dologgal vagyok elakadva:
1. Ha linuxon tükrözni (RAID-1) akarok diszkeket, miért jó, hogy nem a fizikai diszket tükrözöm, hanem a partíciókat? OK, valamivel rugalmasabban kezelhető, ugyanakkor van egy olyan érzésem, hogy ezzel jelentősen ront(hat)om a performanciát.
Azt úgy nagyjából sejtem, hogy LVM-et csak végszükség esetén szabad bevetni e célra, mert iszonyatosan lassú (ex kollégák tapasztalata valami HP-s diszk rendszeren, RedHat linuxokkal - ők maradtak a hardveres RAID mellett)
2. Clusteres témában mi az, aminek érdemes utánanézni? Úgy öt éve, HPUX-on még csak olyan megoldásunk volt, hogy failover módban működtek a szolgáltatások. Ha kidőlt a cluster egy tagja, akkor a rajta futó service-ek egyszerűen elindultak valamelyik másik node-on. VMS-en meg már húsz éve is párhuzamosan működhetett minden, az összes node-on, közösen használt diszkekkel. Itt igazából az érdekelne, hogy milyen kulcsszavakra érdemes keresni, a neten mi az, amit valóban érdemes átlapozni? Elég sokféle HA megoldást találtam a múltkor (jól látom? Az sem mindegy, hogy RedHat c. Debian alapú a rendszerem?) és nem vagyok biztos benne, hogy egyformán elterjedtek, használhatóak. (a megcélzott helyről sajnos csak annyit tudok, hogy a jelenlegi webszerverük CentOS-t futtat, de azt nem, hogy ahová embert keresnek, ott mi van - nem biztos, hogy saját szerveren fut a weblapjuk)
Természetesen szó sincs arról, hogy pár hét alatt profivá akarnék válni a témákban, csak jó lenne, ha legalább felszínes ismereteim lennének ezekről a dolgokról.
■ Erre próbálok valamennyire felkészülni, de elég zűrös a dolog. Korábban is rendszergazda voltam, csakhogy linuxokkal elsősorban hobbiból foglalkoztam, a VMS ismereteimmel meg nem megyek sokra ezen a területen, amit meg HPUX-ból tanultam, azt kb. el is felejtettem mostanra.
Szóval ezügyben szeretnék időnként kérdezősködni, ha a törzsközönségnek nem okozok vele gondot (mivel totál offtopik a téma)
Most két dologgal vagyok elakadva:
1. Ha linuxon tükrözni (RAID-1) akarok diszkeket, miért jó, hogy nem a fizikai diszket tükrözöm, hanem a partíciókat? OK, valamivel rugalmasabban kezelhető, ugyanakkor van egy olyan érzésem, hogy ezzel jelentősen ront(hat)om a performanciát.
Azt úgy nagyjából sejtem, hogy LVM-et csak végszükség esetén szabad bevetni e célra, mert iszonyatosan lassú (ex kollégák tapasztalata valami HP-s diszk rendszeren, RedHat linuxokkal - ők maradtak a hardveres RAID mellett)
2. Clusteres témában mi az, aminek érdemes utánanézni? Úgy öt éve, HPUX-on még csak olyan megoldásunk volt, hogy failover módban működtek a szolgáltatások. Ha kidőlt a cluster egy tagja, akkor a rajta futó service-ek egyszerűen elindultak valamelyik másik node-on. VMS-en meg már húsz éve is párhuzamosan működhetett minden, az összes node-on, közösen használt diszkekkel. Itt igazából az érdekelne, hogy milyen kulcsszavakra érdemes keresni, a neten mi az, amit valóban érdemes átlapozni? Elég sokféle HA megoldást találtam a múltkor (jól látom? Az sem mindegy, hogy RedHat c. Debian alapú a rendszerem?) és nem vagyok biztos benne, hogy egyformán elterjedtek, használhatóak. (a megcélzott helyről sajnos csak annyit tudok, hogy a jelenlegi webszerverük CentOS-t futtat, de azt nem, hogy ahová embert keresnek, ott mi van - nem biztos, hogy saját szerveren fut a weblapjuk)
Természetesen szó sincs arról, hogy pár hét alatt profivá akarnék válni a témákban, csak jó lenne, ha legalább felszínes ismereteim lennének ezekről a dolgokról.
Valasz
1. Tukrozheted az egesz disket is, de akkor abba egy ujabb particios tablat kell csinalnod, amirok a klasszikus BIOS es az UEFI sem tud bootolni. Plusz mivel nem szabvanyos megoldas, jo esellyel sajat initrd-t/initramfs-t is kell epitened hozza. Az LVM is jo, csak eppen a boot particiot kell kihagyni belole. Az, hogy iszonyatosan lassu, eros tulzas, a 2.6.32-tol kezdve egesz hasznalhato es manapsag kvazi szabvanyos megoldassa notte ki magad.
Ami a exkollegaidat illeti, ne keverjuk a szezont a fazonnal, az LVM nem RAID. Ha szoftveres RAID-rol beszelunk, az CPU-bol dolgozik, ergo a rendszeredet lassitja. Ha viszont IO intenziv folyamatokat futtatsz, csinalhatsz olyat, hogy hardveres RAID controllerbol csinalsz egy RAID 0-t, majd ra egy szoftveres RAID 1-et, igy kb. 30%-kal gyorsabb lesz, mint a "sima" megoldas.
2. A clusterezesben leginkabb az alapelveket erdemes ismerni, pl. hogy 2 gepbol nem epitunk clustert, erdemes utananezni a Quorum, STONITH, stb. fogalmaknak. Megoldasok tekinteteben a Pacemaker stack a meno mostanaban. DRBD szinte kotelezo.
Köszi!
Félórán át ültem felette, hogy elküldjem-ne küldjem, végül úgy emlékeztem, hogy eldobtam.
1. Ezen csak azért értetlenkedtem, mert kipróbáltam, hogy eleve egy tükrözött diszkre gyártottam rendszert és a Virtualbox minden gond nélkül bebootolta. A régi, nem x86-os emlékeim alapján, ez a "normális" megoldás. Persze az is hozzátartozik, hogy azokon a rendszereken nem nagyon létezett olyasmi, hogy particionálás.
LVM - persze, maga az LVM másról(is?) szól, de pl. a HPUX-os egész szépen megvalósította a RAID funkciók nagy részét és immár a linuxos is hajlandó legalább tükrözni (más RAID funkciókat nem néztem benne). Pontosabban RAID1 és RAID6(???)-ot össze lehet vele rakni. Kollégák meg a szoftveres tükrözést hasonlították valami spéci, nagysebességű kontrollernek a hardveres megoldásával. Nekik elhiszem, hogy a korábbi tapasztalataik mellett lassú volt :-)
update: RAID/tükrözés témához egy kis adalék... Nálam még ott indult a tükrözés, amit a VMS tudott: két fizikai diszket egymás mellé tenni. Később, mikor jöttek az első HPUX-ok, akkor valahogy ezt próbáltuk arra is átvinni, ott meg egyedüli eszköz erre az LVM-be épített tükrözési lehetőség volt, illetve lehetett a HSx kontrollereken is tükrözgetni, de - mivel az egyik a hardveres, a másik a szoftveres csoporthoz tartozott - elég macerás volt, ha matatni kellett ezeken a diszkeken és nem szoftveres tükröket csináltunk. Persze a későbbiekben a sebesség miatt maradt a hardveres, viszont így kiesett az a VMS-en bevált opció, hogy backup címszóval egy-egy patch/upgrade előtt szétszedni a tükröt és a leválasztott részt megtartani mentésként.
--------------------------
2. Cluster... na itt kezdődnek a gázos dolgok. Én még elég sok két gépes clustert építettem. Ilyenkor egy közös, min. dual path-os diszk adta a quorumot. :-)
De most, hogy mondod, tényleg, ez már teljesen kiment a fejemből :( : a HPUX-nak is kellett plusz egy gép (sok clusterhez is elég volt egy), aki a quorum miatt volt szükséges. STONITH, DBRD így első olvasásra számomra ismeretlen fogalmak, ezeknek mindenképp utánanézek.
Tegnap felraktam egy Debian squeeze-t, abban nézegettem a csomagokat, de már ott is legalább két- (ha nem három)féle megoldást találtam, de mind ismeretlen volt.
-----------
Időközben megkerestem a google-n a STONITH és DBRD jelentését. Első tképp ismerős, csak a rövidítés nem volt az. :-) A másik... hát hogy is mondjam... azért ez elég más világ, mint amiben én "szocializálódtam".
Hát lenne mit tanulnom, hogy finoman fogalmazzak...
ui: Tanenbaumot nem felejtettem el...
Valaszok
2. Itt lesznek problemaid. A Linuxban a multipath a driver layer folott van, szoval SCSI3-PR-t csak akkor tudsz csinalni, ha ossze van kelloen csiszolva. Ez jellemozen FC-nel nem szokott osszejonni. Egyebkent a HP/Sun/stb mar regen eljutott oda, amire a Linuxis HA most kezd eljutni, hogy kulturaltan mukodjenek ezek a cuccok, de hat a koltseghatekonysag azert elegge kozrejatszik abban, hogy inkabb ezt hasznaljak, na.
1. Én csak elismételtem, amit
2. Igen, azt látom már most is, hogy lesznek gondjaim, ha beleásom magam. :-)
(FC... már megint egy olyan, amin órák óta törtem a fejem és nem ugrott be)
FC
:-) Az FC rövidítés sem
Az FC rövidítés sem ugrott be... HSC, HSD, HSJ (DEC-es kontrollerek voltak, CI-t, illetve a HSD DSSI-t használt - de már ennek is utána kellett néznem) ...
Majd jött a HSG, ami már FC-n ment, de hiába törtem a fejem, egyszerűen nem jutott eszembe.
Hajrá
CentOS
Mivel a cég, ahol próbálkoznék, talán CentOS-t használ, én meg kb, tizenöt éve kizárólag debian alapokon linuxozok, gondoltam, kicsit belenézek. Háááát...
Vagy nagyon nem nekem való ez a játék már, vagy valamit nagyon elkeféltek a fejlesztők: ha jól értem, a 6.3-as a legfrissebb stabil verziója (az 5.5 mellett). Szép. De nincs doksija. 5-öshöz még van komplett dokumentáció, a 6-oshoz már csak release notes.
És egyelőre semmit sem találtam arról, hogy miért hanyagolják.
(megérteném, ha "marketing" lenne a 6-os és ez valójában egy 5.x verzió, de ilyen utalással sem találkoztam mindeddig)
Ethernet vs Wlan
De csak nem hagyott nyugodni a dolog.
A történet röviden annyi, hogy egy laptopon futtatok virtualbox-ot, abban linuxokat. Ezen linuxok egyike routerként funkcionálna a többi virtuális gép felé. Ugyanez a felállás csodásan működött, míg a host (ami a virtualboxot futtatta) egy desktopra telepített linux volt.
Ugyanaz a konfiguráció a windowsomra pakolt virtuális gépekkel nem működött. Pontosabban: a virtuális hálón igen, de kívülről elérhetetlen volt.
Az imént kiderült, egyetlen jelentős eltérés van a két rendszer között: a windows-on wifit használok ethernet helyett. Ugyanis az előbb rádugtam a laptopot a router egyik portjára, lekapcsoltam a wifit és... láss csodát, minden működik úgy, ahogy kell. Pedig már kezdtem azt hinni, hogy ennyire hülye vagyok a témához, hogy valamit rosszul állítok be...
Úgyhogy ezzel kapcsolatban felmerült bennem egy nagy kérdés: mi működhet másképp egy wifi adapter esetében? Hiszen elvileg ez véget ér valahol az 1. OSI rétegnél, így szerintem az IP-nek már semmi köze hozzá, hogy milyen hardveren működnek.
(janoszen: azt a microsoftos doksit még nem olvastam végig, szóval ha csak az én ismereteim hiányosak, az ezért is lehet! :-) )
update: virtualbox fórumán kaptam egy tippet... promiscuous módban másképp viselkedik a wlan, mint az ethernet, ez is okozhatja...
Tartok tőle, nem lesz tisztességes megoldás a problémára, csak a korábbi workaround: hostonly-if a bridged helyett.
update2: azért ezt nem teljesen értem. Lehet, hogy az angollal gyűlt meg a bajom? Esküdni mernék, hogy a virtualbox fórumán azt állították, a promisc. módnak köze van a route-oláshoz. Az előbb direkt olyan beállításokkal próbáltam ki, hogy a promisc. mode le volt tiltva az összes kártyákon. Belül mégis működött a routing. Egyre kevésbé értem. :-(
update:3: nem az angollal volt gond, hanem az odafigyeléssel. Bridge-ről írták azt, amit, bennem meg egyre az volt, hogy a route-olásról beszélt. Szóval szokás szerint figyelmetlen voltam...
update4: csak a dokumentáció kedvéért (tuti el fogom felejteni, de mindegy :-) )
Van linuxon egy ú.n. ebtables csomag. Ez valami hasonló eszköz, mint az iptables, de ez az ethernet bridge-eken végez különböző műveleteket.
Kellett az eth0 helyett egy br0 bridge, melynek egyetlen interface tagja van, az eth0.
Ha ez megvan, akkor kell egy ilyen parancs:
Egyelőre úgy fest, működik... Még nem tökéletes, mert a további routing nem megy, de már ez is valami. Ettől kezdve sejtem, hol keresgéljek. :-)
update sok... :D
Persze... 172.31.1.2-t pingelek szorgalmasan, miközben a felrakott dhcp szervernek köszönhetően 172.31.1.160 a címe a megcélzott gépnek. Én meg csodálkozom, hogy nem érem el. :D
Na ennyit erről, rólam, meg arról, hogy hajnali fél kettő van. :-)