[DRBD + Heartbeat] Unmount blijft hangen bij heartbeat stop

[BOOTZ]

Op een aantal servers die ik beheer gebruiken we sinds kort DRBD + Heartbeat zodat we een NFS- FTP- en MySQL-server hebben die altijd beschikbaar is. Dit systeem werkt prima, er raakt geen data kwijt en als er een netwerkverbinding uitvalt neemt de andere server het na een paar seconden zonder problemen over.

Maar... Als je handmatig Heartbeat stopt zodat de andere server het over gaat nemen dan gaat het mis. Ook als je een hb_takeover draait (waarmee dus eigenlijk het zelfde gebeurt) werkt het niet.

Zodra je de boel stopt doet heartbeat het volgende:
• MySQL stoppen
• proftpd stoppen
• NFS stoppen
• IP-adres van de FTP- en NFS-servers vrijgeven
• 3 seconden wachten
• Alle DRBD-filesystems unmounten
• DRBD vertellen dat alle partities in de stand 'secondary' moeten komen te staan

Bij het unmounten van alle DRBD-filesystems gaat het mis. Het systeem kan vaak een of twee filesystems niet unmounten en daardoor blijft alles hangen. Heartbeat kan z'n resources niet helemaal vrijgeven en de andere machine neemt het niet over.

Na wat verder onderzoek blijkt dat bij het unmounten zo'n beetje alle processen die op het systeem draaien ineens bestanden geopend lijken te hebben op de filesystems die ik wil unmounten. 'fuser -m /home' geeft dan een lijst van zo'n beetje alle processen die draaien. 'lsof /home' daarentegen geeft een lege lijst, wat ook de bedoeling is.
Maar omdat er nog files geopend zijn kan het filesystem niet geunmount worden en kan DRBD die disk niet vrijgeven. En dat is best wel een probleem. Ook bij een reboot of shutdown levert dit problemen op, een reboot/shutdown blijft soms ook tot in den eeuwigheid hangen totdat die filesystems geunmount kunnen worden.

Heeft iemand enig idee hoe dit kan komen? Hoe er dus 'spook-filehandles' ontstaan?

[decramy]

Ik zit ook in zo`n situatie... Ik lees even mee

* decramy zwaait naar BOOTZ

[Verwijderd]

dus als je de heartbeat service stopt op de ene blijft hij hangen ??? post je ha.conf eens.

[Verwijderd]

wild guess: de user waarmee je bent ingelogd staat die home dir op /home ?
Zou dit misschien het probleem kunnen veroorzaken?

[Verwijderd]

de dbrd volume is meestal wel keihard te unmouten ook al zijn er bestanden in gebruik. heb tijdens testen dat wel eens geprobeerd.. maar als je bij 1 server de stekker er uit trekt dan pakt hij wel goed over ??

[BOOTZ]

Als je ergens een stekker uittrekt (heb dat voor de test nagebootst door de netwerk-interface down te gooien) neemt de andere server het meteen zonder problemen over. Het is het unmounten waar het echt mis gaat. Op dat moment is /home trouwens niet in gebruik, voordat ik het probeer doe ik netjes "cd /".

Voordat je "/etc/init.d/heartbeat stop" hebt gegeven:

xxx:/# fuser -m /home
xxx:/# fuser -m /var/data
/var/data: 8272c 8317c
xxx:/# fuser -m /var/www
xxx:/# fuser -m /usr/local
xxx:/# fuser -m /var/lib/mysql/
/var/lib/mysql/: 8671c

En nadat je dat commando hebt gegeven komen er bij /var/www ineens allemaal spook-processen bij die er voor het unmounten niet waren:

xxx:/# fuser -m /home
xxx:/# fuser -m /var/www
/var/www: 356 465c 485 692c 695c 986 1060 1061 1062 1063 1064 5691rc 5782 7899 14225rc
xxx:/# fuser -m /var/data
xxx:/# fuser -m /var/lib/mysql/
xxx:/# fuser -m /usr/local

Als je dan nog even wacht om te kijken of het zichzelf kan herstellen komen er overal 'spookprocessen' bij te staan:

xxx:/# fuser -m /var/www
/var/www: 356 465c 485 692c 695c 986 1060 1061 1062 1063 1064 5691rc 7899 14225rc
xxx:/# fuser -m /var/data
/var/data: 356 465c 485 692c 695c 986 1060 1061 1062 1063 1064 5691rc 7899 14225rc
xxx:/# fuser -m /home
/home: 1rce 2rc 3rc 4rc 5rc 6rc 7rc 8rc 9rc 10rc 11rc 12rc 13rc 14rc 15rc 16rc 17rc 18rc 19rc 20rc 152rc 153rc 154rc 286rce 356rce 359rce 370rcm 465rm 472rcm 478rcm 485rcm 553rc 561rc 692rm 695rm 986rcm 1000rce 1001rce 1002rce 1003rce 1004rce 1060rcm 1061rcm 1062rcm 1063rcm 1064rcm 5691m 7491rc 7637rc 7784rc 7899rcm 8213rc 9143rc 9147rc 9149rc 9239rc 9240rc 9246rc 9247rc 9303rc 9304rc 9376rc 9377rc 9412rc 9413rc 11487rc 12212rce 14225m 18602rcm 18604rcm 18605rce 18608rce 18918rce 18919rcm 18921rcm 18922rce 18923rce 18977rce 18978rce 18979rce 18982rce 19285rce 19332re
xxx:/# fuser -m /var/lib/mysql/
/var/lib/mysql/: 356 465c 485 692c 695c 986 1060 1061 1062 1063 1064 5691rc 7899 14225rc
xxx:/# fuser -m /usr/local
/usr/local: 370e 465e 472e 478e 485e 692e 695e 986e 1060e 1061e 1062e 1063e 1064e 5691e 7899e 14225e 18602e 18604e 18919e 18921e

En dit vind ik heel vreemd, hoe kan het dat alle processen ineens open filehandles krijgen op die partities terwijl ik ze aan het unmnounten ben?

Verwijderd schreef op woensdag 05 april 2006 @ 19:20:
de dbrd volume is meestal wel keihard te unmouten ook al zijn er bestanden in gebruik. heb tijdens testen dat wel eens geprobeerd..

Hoe krijg je die hard geunmount dan? "umount" en "unmount -f" doen in ieder geval niks behalve niet meer reageren (ook niet op "kill -9" enzo).

[Verwijderd]

kreeg hem meestal wel geunmounten door drdbadmin --secondary --do what i say weet commando zo niet uit mn hoofd.

welke dbrd versie en kernel gebruik je ? bij fc5 zijn er problemen bekend zie hun mail lijst

[BOOTZ]

--do-what-I-say is dat, mooie optie wel
Het enige probleem daarmee is dat het altijd een risico is of je filesystem niet beschadigd raakt. Als je het netjes kan unmounten gaat dat in ieder geval altijd goed

Gebruik op dit moment drbd-0.7.10 (die zit bij debian-sarge) met kernel 2.6.15-1. Wat bedoel je met "fc5"?

[Surfer]

BOOTZ schreef op woensdag 05 april 2006 @ 22:04:
Wat bedoel je met "fc5"?

Als ik een gok mag doen: Fedora Core 5 (het testbed distro van Red Hat)

[Verwijderd]

zo uit het hoofd is er met die versie van de kernel wel een probleem met de dbrd module. als ik thuis ben kijk ik ff mn archief door.

[decramy]

Uit bijzonder betrouwbare bronnen weet ik dat de hardware hetzelfde is als hier wordt aangegeven:
http://www.gossamer-threads.com/lists/drbd/users/9814
en
http://archives.free.net....7.211152.7a7054a2.en.html

hoewel in onze .config 'CONFIG_4KSTACKS' niet wordt geset, en hij lijkt dan default op N te staan...

Zou het opgelost zijn met een nieuwe kernel...?

Gevonden door: Google: drbd 0.7 kernel 2.6.15

[ Voor 80% gewijzigd door decramy op 07-04-2006 00:31 ]

[BOOTZ]

Dan misschien maar eens proberen met de nieuwe kernel