Sie sind hier

August 2008

M68k Porters Meeting 2008 in Kiel is over

Yesterday a server at work needed some care - which was the reason why I had to leave the m68k porters meeting early. It was intented to migrate the filesystem to a RAID1 setup instead of using just a single disk.

Of course I tested everything in advance and it worked. Sadly Murphy did hit the scene as well and the previously tested upgrade path failed: somehow the RAID couldn't be started and the boot progress stopped.

Actually, the error was this one:

Failure: failed to load Module 1 no such module

Useless to say that the initrd was uptodate and included all necessary modules!

Luckily someone else happened to stumble upon the same problem last year and it was well documented on debian-user mailing list in a thread between Andrew Sackville-West and Martin F. Krafft , properly archieved by some mirrors.

So, the problem was in some mdadm script that was executed during boot process and which parsed the ARRAY definition in that way that the kernel modules couldn't get loaded.
If you follow the thread on that mailing list you'll come to the following hint:

Try the following patch agaist
/usr/share/initramfs-tools/hooks/mdadm. It ensures that RAID levels
include the word 'raid'. I think your mdadm.conf may say stuff like
level=5, when it should say level=raid5 or not specify level= at
all.

And yes, my ARRAY definition in mdadm.conf just stated level=1 as well. So after setting it to level=raid1 everything worked again.

Thanks, Andrew and Martin for solving that problem a year ago! :-)

Kategorie: 
 

re: Killing Servers with Virtualisation and Swap

As previously announced the m68k porters met this weekend in Kiel this year.
It was really great to meet the persons in reality with whom you're working for several years now!

You can find a short summary of the results here.

Kategorie: 
 

Adding a RAID under a LVM

Russel Coker blogs about a problem, which concerned me as well: Killing Servers with Virtualisation and Swap, i.e.: what happens when one domU is happily swapping the whole day?

Luckily this didn't happen to me yet, but as Russel do I tend as well to give a small sized swap area to domUs. If they're doing extensive swapping, something is wrong and most probably a task has a memory leaking problem or the virtual machine is undersized with its RAM.

Anyway, Russel had some thoughts and ideas how to deal with the problem, such as giving dedicated swap areas on single disks to some domUs to seperate disk I/O for the filesystem and the I/O for swap. He proceeds with:

Now if you have a server with 8 or 12 disks (both of which seem to be reasonably common capacities of modern 2RU servers) and if you decide that RAID is not required for the swap space of DomUs then it would be possible to assign single disks for swap spaces for groups of virtual machines. So if one client had several virtual machines they could have them share the same single disk for the swap, so a thrashing server would only affect the performance of other VMs from the same client. One possible configuration would be a 12 disk server that has a four disk RAID-5 array for main storage and 8 single disks for swap. 8 CPU cores is common for a modern 2RU server, so it would be possible to lock 8 groups of DomUs so that they share CPUs and swap spaces. Another possibility would be to have four groups of DomUs where each group had a RAID-1 array for swap and two CPU cores.

I would myself consider a different approach:

  • make your RAID as usual across your 8 or 12 disks, but don't use the whole disks, but just a partition on it, leave 10 GB or so free on each disk for later swap purposes.
  • with 10 GB on each disk you'll have 80 GB swap with 8 disks or 120 GB with 12 disks in your 2 RU server.
  • you can setup your swap areas as needed. Maybe some domUs would benefit from more heads when swapping, some need more space or another one should survive when one disk fails. So you can setup each swap differently, be it as a single partition on a single disk or a RAID1 or JBOD for multiple heads.

Of course you can mix up both approaches or even use swap over NFS or NBD/DRBD. There are many ways and possible solutions, but the best way to deal with swapping is to take care that it doesn't happen, of course... ;)

Kategorie: 
 

Hotline: Wenn Profis unter sich sind...

Just as a personal reminder for the next time I need that:

If there's a machine, for example a Xen host, with just one harddisk and you want to be somewhat safe in case of a disk failure, you can add a second disk and setup a RAID1 (mirroring). It's most simple to shutdown the machine and setup the RAID1 for the dom0. Afterwards you can start the domU VMs again when you're using LVM for their virtual disks. Following these steps will add RAID1 underneath your LVM setup:

0. /dev/sda5 is your current physical volume for your LVM, on the second (equally partitioned) disk /dev/sdb5 will be your starting point for your RAID1 (/dev/md3)
1. create a degraded RAID1 on /dev/sdb5:

# mdadm --create /dev/md3 --level=1 -f --raid-devices=1 /dev/sdb5
mdadm: array /dev/md3 started.
# cat /proc/mdstat
md3 : active raid1 sdb5[0]
135540288 blocks [1/1] [U]

2. prepare it for LVM and add it to your virtual group:

# pvcreate /dev/md3
# vgextend /dev/vg /dev/md3
Volume group "vg" successfully extended

3. move the extends from one disk to the other and be verbose to watch the progress:

# pvmove -v /dev/sda5
Finding volume group "vg"
Archiving volume group "vg" metadata (seqno 22).
Creating logical volume pvmove0
Moving 192 extents of logical volume vg/ts2-swap
Moving 1536 extents of logical volume vg/ts2-disk
[....]
Found volume group "vg"
Removing temporary pvmove LV
Writing out final volume group after pvmove
Creating volume group backup "/etc/lvm/backup/vg" (seqno 31)

4. remove the old partition from the virtual group:

# vgreduce /dev/vg /dev/sda5
Removed "/dev/sda5" from volume group "vg"

5. add the old partition to your raid and set it active:

# mdadm --add /dev/md3 /dev/sda5
mdadm: added /dev/sda5
# cat /proc/mdstat
md3 : active raid1 sda5[1](S) sdb5[0]
135540288 blocks [1/1] [U]
# mdadm --grow /dev/md3 --raid-devices=2
# cat /proc/mdstat
md3 : active raid1 sda5[2] sdb5[0]
135540288 blocks [2/1] [U_]
[>....................] recovery = 0.2% (284480/135540288) finish=39.6min speed=56896K/sec

6. let the RAID1 doing its sync and you're done.

Just as a small side note:
I don't know why the kernel don't want to boot when it get passed root=/dev/md2 as a kernel parameter. It works with root=/dev/sda3, though...

Kategorie: 
 

2008 M68k Porter Meeting

Bei Isotopp fragt man sich, wie man es vermeiden kann, daß zwei "Profis" an der Hotline aneinander vorbeireden bzw. sinnlos Zeit vergeuden:

Ich beobachte trotz langer Zusammenarbeit an vielen Stellen einen ganzen oder teilweisen Zusammenbruch der Kommunikation. Es geht sehr viel Zeit verloren, weil der verstandene Fehler häufig ein ganz anderer ist, als der der gemeldet werden sollte. Fehlermeldungen verlieren sich in Details, während das darüberliegende Szenario unklar bleibt. Der Helpdesk glaubt das Problem schon erfasst zu haben, und verpasst die wichtigen Teile der Fehlermeldung.

Im Kommentar schreibt z.B. deltatango u.a.:

Erste Regel: "Nimm nichts als gegeben an, hinterfrage alles." Zu Anfang kommt man sich bissle doof vor, weil man elementarste Dinge erfragt, aber es hilft.

Zweite Regel: "Nur weil am anderen Ende ein vermeintlicher IT-ler sitzt, bedeutet das noch lange nicht, daß der Probleme, Fehler, Symptome konkret und mit korrekten Termini beschreiben kann." Siehe Regel eins.

Dritte Regel: "Wiederhole das Gehörte dem Fragesteller mit eigenen Worten und laß' ihn bestätigen, daß du sein Problem richtig verstanden hast." In der Luftfahrt macht man das auch und weiß warum: es vermeidet teure Mißverständnisse.

Alle drei Regeln sollte man beherzigen, insbesondere die dritte, weil dadurch Missverständnisse vermieden werden. Hinzufügen sollte man aber auch, daß man sich gegenseitig ausreden läßt. Mir ist es bei diversen Hotlines auch schon passiert, daß mich das Gegenüber nicht hat ausreden lassen und dann Dinge hinterfragte, die ich alleine gesagt hätte.
Ansonsten hat TPOSANA (The Practice of System and Network Administration - Limoncelli, Hogan, Challup) auch ein eigenes Kapitel zum Thema Hotline.

Das ganze kann man sicherlich noch verfeinern, wenn es sich nicht um eine allgemeine Hotline handelt. Wenn es sich z.B. wie beim Fragesteller Martin um eine Firmenbeziehung Kunde und Hersteller handelt, könnte folgende Verbesserungen in Absprache zwischen den beiden Parteien eingeführt werden:

  1. Feste Ansprechpartner: Beim Hersteller wird ein fester Ansprechpartner benannt, an den man sich mit Problemen wenden kann. Idealerweise sollte vom Kunden dann auch nicht jeder dort anrufen, sondern auch nur eine begrenzte Anzahl von Personen.
  2. Checkliste/Ablaufplan: Normalerweise gehen Hotliner aus gutem Grund nach Schema F bzw. ihrem Ablaufplan vor. So ist es durchaus berechtigt zu fragen, ob das Netzwerkkabel steckt und die LEDs an Karte und Switch/Router leuchten, wenn der Kunde nicht ins Internet kommt. Man sollte meinen, dass das Unsinn ist und man "selbstverständlich" das Kabel im richtigen Port stecken hat, aber leider ist dem eben nicht immer so.
    Hat der Kunde nun die gleiche bzw. eine ähnliche Checkliste bzw. einen entsprechenden Ablaufplan, kann er sowas selber checken und dem Ansprechpartner dann mitteilen, bis zu welchem Punkt der Checkliste er gekommen ist und ab wann dann ein Fehler auftritt.
  3. gemeinsame Sprache: auch wenn es offensichtlich sein sollte, hilft es, die gleiche Sprache bzw. die gleichen Begriffe zu verwenden. Wenn der Kunde von einem Icon in der Taskbar spricht, tatsächlich aber das Systray meint, mag der Hotliner sich wundern, wo der Kunde da ein Icon sieht. Insofern sollte man sich also auf gemeinsame Begriffe einigen, damit man sich auch gegenseitig versteht und nicht aneinander vorbei redet.

Natürlich gibt es noch mehr Möglichkeiten, die Kommunikation zwischen Kunde und Hotline zu verbessern. Letztendlich profitieren beide davon, wenn die Kommunikation gut funktioniert. Und nicht immer gibt es ehrliche Kunden, die löblicherweise zugeben, daß sie keine Ahnung haben. Solche Kunden sind mir jedenfalls lieber als solche, die vorgeben, daß sie Ahnung haben. ;-)

Kategorie: 
 

PostgreSQL on SMP machines

Joey mailed lately just another announcement for the m68k port ermeeting. This year in Kiel from August 29th - 31st:

Executive summary:

2008 M68k Linux Porter Meeting
August 29th - 31st
University of Kiel, Germany

This summer we are organising a Linux porter meeting especially
targetting the m68k architecture. During the meeting current problems
of the m68k architecture, its integration in Debian, releases
etc. will be discussed.

The meeting will take place at the last weekend in August (29-31) at
the University of Kiel, Germany. Details and participants are
collected here:

This meeting is evolved from the Oldenburg porter meeting that has
started with the m68k architecture but had to stop two years ago.

Interested developers and supporters are invited to join the meeting
and help develop the m68k port of Linux.

If you are interested to attend this meeting, please drop Christian
(cts) or me a note or add yourself to the Wiki page.

Regards,

Joey

Despite all the problems the m68k faced in the last years, we're still alive and performing fine. Part of the meeting will be discussion about the current changes of the m68k port like Aranym buildds and other stuff.

So, if you're interested in the m68k port or the experience of the m68k porters for your embedded architecture, come to Kiel and visit us! :-)

Kategorie: 
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer