Üzemeltetési napló

2008. szeptember 17.

A portaudit szépen szólt, hogy a python25 csomag több hibát is tartalmaz, célszerű lenne frissíteni, de mivel ez a template része, ezért ez "közös" csomag, minden jail örökölte. Ennek ellenére az összes jail-on belül futtathatjuk a portupgrade parancsot, hogy frissítsük, az elhasznált hely kevésbé fontos, mint a biztonsági kockázat.

A jail technológia egyetlen hátránya a jail frissítésének nehézsége – de csak akkor, ha a megszokott módon műveljük. ZFS esetén a template tartalmát átmásolhatjuk egy újabb alkönyvtárban, amelyet verziózhatunk. Én eddig a /jails/system_v1.0.3/ verziónál tartok, ez nagyjából azt jelenti, hogy alaprendszert nem változtattam, az első csomagkészlethez képest nem került újabb csomag a template-be, de már három frissítés történt a jail mintában. Mivel sok helyen előfordult a java szükségessége, ezért úgy döntöttem, hogy a template része lesz a Sun JDK6.0 is, így az elkövetkező verziószám a v1.1.0 lesz.

A jail frissítését célszerű script-re bízni, így nem lesz túl sok munkánk a frissítéssel:

2008. szeptember 2.

Kissé nagy ugrás történt a naplóban, ugyanis minden eddigi szolgáltatás migrálása megtörtént, több lépéssel tovább is haladtam, mint ami jelenleg le van dokumentálva, de majd utólag csak sikerül ledokumentálni. A wiki jópár oldalán vannak ilyen töredékek, illetve félig kész leírások... amint időm engedi, ezeket rendbeszedem...

Az üzemeltetés során szükséges idővel újabb és újabb ZFS alapokat készíteni, amelyekből klónozni lehet a rendszer szolgáltatásait. Egy kör már lement ezügyben, és rájöttem a ZFS egyik apró problémájára: akkor lehet átnevezni egy ZFS fájlrendszert, ha alatta az összes fájlrendszer lecsatolható – tehát az átnevezendő fájlrendszer alatt nem lehet foglalt fájl.

Azon célkitűzés felé haladok, hogy a szerver magas rendelkezésreállással működjön, értve ez alatt a frissítésekből adódó leállásoktól való mentességet, mint a hardver hibáját – amely ellen jelenleg nem tudok védekezni. A jelenlegi struktúrát ezért kissé meg kell bontani, és elő kell készíteni a cluster technológiák használatára. Jail-ek esetén lehetőség van egy gépen is cluster jellegű használatra, hiszen különálló IP címek és fájlrendszerek között kiválóan lehet cluster-t építeni.

Egy hibásan frissített syslog-ng képes volt megölni a gépet, egyszerűen azzal, hogy a logot teleírta az alábbival (~4G méretig, a tömörített fájlrendszeren csak ~20MBájtot foglalt), és ez még nem volt elég a ZFS számára, hanem amikor olvasni akartam belőle tail-el, miközben másodpercenként több ezer sor került bele a fájlba, akkor a load elszállt az egekig... és ez már megölte a ZFS alrendszert. Nos, a ZFS még nem stabil, valóban... Kértem újraindítást, meg is tették röpke fél óra alatt, utána viszont azt vettem észre, hogy az LDAP adatbázis megsérülhetett (pedig tudtommal nem írtam bele az utóbbi pár órában). A sérülés alapján egy darabig működött, majd eldobta az adatbázisát. Ja jó időben csináltam egy ldapsearch kérést, akkor visszakaptam a teljes tartalmat, majd az adatbázis törlése után visszatöltöttem ezt és minden megjavult. A probléma az volt, hogy minden szépen elindult – ami LDAP alapú, aztán megállt (DNS, levelezés). Hm... ez nem hangzik túl jól:

2008. augusztus 26.

A gépben lévő RAID vezérlővel akadt némi probléma, a FreeBSD nem szerette igazán, ezért kis kutakodás után kiderült, hogy a hardver beállításait használja, a hardverben pedig alapból le van tiltva a write cache. Ez felülbírálható:

Kissé vissza van fojtva a ZFS, mert a gépben csak 1G memória van egyelőre. De így már más a helyzet.

2008. augusztus 25.

Vágjunk kissé rendet a fájlrendszerek között:

Azok a snapshot-ok, amelyeket a teleptésnél hoztunk létre – már nem kellenek, helyettük célszerű egy @stable létrehozása, amely a rendszerünk jelenlegi stabil állapotát jelenti. Egyedül a /usr/src fájlrendszeren célszerű meghagyni a snapshot-ot, de nevezzük át @install névre, hiszen ebből tudunk olyan kernelt és alaprendszert fordítani, amely megegyezik a rendszerünk jelenlegi állapotával – ugyanakkor lehetővé válik a források folyamatos frissítése is.

A ports fát érdemes naponta frissíteni, ezért erre állítsunk be egy megfelelő crontab bejegyzést, erről levelet fogunk kapni (a `cron` paraméter azt jelenti, hogy a portsnap program maximum egy órát vár véletlenszerűen választott ideig, mielőtt indulna, ezzel tehermentesíti a snap szervert, mivel szép egész órákra szoktak a rendszergazdák programokat időzíteni – ahogy mi is):

Az eredményt levélben kapjuk (valamikor dél és egy óra között):

Ezen túl az alaprendszer forrását hetente egyszer frissítsük, hátha olyan részt javítanak, amely fontos lehet:

Az eredmény itt is levélben jön:

Ami esetleg még fontos lehet, hogy a jail-ek ports fáját is frissítsük, ez némi ZFS karbantartást is igényel, ezért erre írjunk egy script-et (egyelőre belekódoljuk a jail-ek elérési útját, ezen majd változtatunk a későbbiekben):

Ezt is tegyük bele a crontab-ba:

2008. augusztus 24.

Sajnos megdöglött a gép a második nap, az okát egyelőre nem tudom, mert nem tudtam neki távoli konzolt kérni (jövő héten kap IP-t a management portra), egyelőre kértem most egy újraindítást, megnézem írt-e valamit logba – nem írt semmi fontosat. Ahogy nézem, a `find` futott, amely jelenthet I/O terhelést, ami jelenthet ZFS halált, de ahogy olvastam, ilyenkor zfs státuszban maradna. Hm... itt az utolsó `top`, amit SSH-n át tudott küldeni. Ami érdekes, hogy a gép `ping`-re válaszol, a portokat nyitottnak mondja, de minden olyan process, ami hallgatna ezeken a portokon `wait` állapotban van.

2008. augusztus 23.

A wiki-n leírt összes tartalom felment a szerverre, így most up-to-date az írás és a valóság.

2008. augusztus 22.

Kisebb-nagyobb nehézségek árán ugyan – de sikerült feltelepíteni kettő FreeBSD-t a szerverre. Érdekességképpen, a telepítés során iszonyú lassan reagált a gép, ami eléggé riasztó volt (200-300kBájt/s írás!), de újraindítás után már megfelelő sebességgel működött. Az új alaprendszert és kernelt már otthon fordítottam és single-user mód helyett multi-user módban kapta az installworld és az installkernel parancsokat, majd ezek után újraindítottam. Egyelőre nincs nyoma annak, hogy ez hátránnyal járt volna.

A RAID vezérlő nem győzött meg igazán:

root@freebsd:~$ dd if=/dev/zero of=/root/testfile ibs=65536 count=16384
16384+0 records in
2097152+0 records out
1073741824 bytes transferred in 161.619783 secs (6643629 bytes/sec)
root@freebsd:~$ dd if=/root/testfile of=/dev/null ibs=1024
1048576+0 records in
2097152+0 records out
1073741824 bytes transferred in 16.862023 secs (63678115 bytes/sec)

6MBájt/s írás és 60MBájt/s olvasás nem tűnik jónak, legalábbis a 6MBájt/s kevés... nemde?