Of, hoe een nieuwe server compleet in de prak kan lopen….

Zoals al in de vorige post vermeldt wordt de server waar deze site opdraait vervangen en de sites die erop draaien (zo’n 300 gok ik zo) worden gemigreert naar een nieuwe server. Een leuk klusje voor mij om eens te kijken of ik al weer een beetje productief kan zijn en we hebben ruim de tijd ervoor (de oude server gaat er op 1 juni uit, tijd zat dus). Maar wat kan er een boel mis gaan tijdens zo’n migratie!

Omdat de nieuwe server nogal wat meer capaciteit heeft hebben we (Michel en ik) besloten dat we de oude sites wel in een VPS onder kunnen brengen, dus daarvoor gebruiken we Xen.

Het gedonder begon alleen al snel:

Free swap  = 2097104kB

Total swap = 2097144kB

Free swap:       2097104kB

485150 pages of RAM

298784 pages of HIGHMEM

6023 reserved pages

101248 pages shared

1 pages swap cached

0 pages dirty

31743 pages writeback

1540 pages mapped

9107 pages slab

159 pages pagetables

Out of Memory: Kill process 12924 (sshd) score 2660 and children.

Out of memory: Killed process 12925 (bash).

Uhhh, okay, de OOM-killer begon spontaan processen af te schieten, en het vervelende was: mijn SSH-sessies werden elke keer afgeschoten….

Maar eens even kijken of de Dom0 wel voldoende geheugen had voor de bewerking die ik wilde doen (het met mkfs.ext3 formateren van een 150gb disk) en uiteindelijk, na 4x proberen, lag de server helemaal plat… Okay, maar een APC reboot doen….

Vervolgens kwam de machine niet meer op en een paniek mailtje naar onze hostingprovider later bleek dat het systeem hing in een fsck-check? WTH? Wat is er stuk aan die machine? Een fsck-check later draait de machine weer, maar het backuppen van de data van de LVM-partitie waar alle sites op zouden moeten draaien (dmv een snapshot volume) leverde de volgende meldingen op in dmesg:

EXT3-fs error (device dm-9): ext3_readdir: directory #10354863 contains a hole at offset 2048024576

attempt to access beyond end of device

dm-9: rw=0, want=28341307408, limit=314572800

EXT3-fs error (device dm-9): ext3_readdir: directory #10354863 contains a hole at offset 2048028672

attempt to access beyond end of device

dm-9: rw=0, want=22819790600, limit=314572800

EXT3-fs error (device dm-9): ext3_readdir: directory #10354847 contains a hole at offset 0

EXT3-fs error (device dm-9): ext3_readdir: bad entry in directory #10354847: rec_len % 4 != 0 - offset=0, inode=1025, rec_len=1026, name_len=0

init_special_inode: bogus i_mode (153001)

init_special_inode: bogus i_mode (110025)

init_special_inode: bogus i_mode (151662)

init_special_inode: bogus i_mode (6173)

init_special_inode: bogus i_mode (4620)

init_special_inode: bogus i_mode (4030)

en dat ging zo nog wel even door….

Nu is het zo dat we (door onervarenheid met Xen) een rare situatie hadden gecreeerd met een LVM in een LVM (blijkbaar kan je in een domU van Xen wel een LVM-logicalvolume en Volume Group aanmaken, maar zie je die dan ook in de dom0) en die gaan we nu maar eens opheffen.

Daarnaast zou het zo maar kunnen zijn dat we tegen deze Debian-bug aanlopen, omdat de logicalvolume in de domU weliswaar 150gb is (en de snapshot dus ook) maar de logicalvolume waarin de boel in de dom0 zit  180gb groot is….

Een dezer dagen gaat dan ook de home-partitie in de domU vervangen worden door een virtueel device en niet door een virtuele logicalvolume en dan hopen we dat de machine stabiel is. Zo niet, dan mag onze hoster gaan uitleggen waarom een dedicated server zo brak is….