Consultant Informatique Réseau et Internet

4 novembre 2009

OVH: Retour d’expérience Proxmox + LVM + RAID soft

Officiellement, Proxmox ne supporte pas les serveurs raid soft. J’ai quand même tenté.  Voici mon retour d’expérience:

Compte tenu de l’offre OVH actuelle (nov 2009) privilégiant largement le raid soft (premier prix en raid soft 50€/mois, contre 135€/mois en raid hard) j’ai décidé de tester la configuration suivante:

  • Serveur OVH SP-09 BestOf (raid 1 soft)
  • Proxmox 1.3
  • VMs OpenVZ centos et debian et KVM Windows Server 2003

Afin de pouvoir effectuer des sauvegardes de type snapshot (c’est à dire sans arrêter les VMs) je remplace la partition de données de linstallation OVH Promox par une partition LVM2. J’installe mes machines virtuelles. A première vue, tout va bien, les machines virtuelles tournent sans problèmes visibles.

Mais, quelques jours plus tard, les problèmes commencent…

Toutes les machines virtuelles ne repondent plus du tout, même pas au ping. Par contre le host fonctionne et je peux m’y connecter en SSH. Je comprends rapidement que la partition LVM est complètement bloquée. C’est à dire que tout accès à un LV de la partition LVM freeze. Un simple “ls -l” ne retourne rien et je dois tuer la session SSH. Reboot soft ne fonctione pas. La situation se présente d’autant plus mal que je ne trouve aucun message d’erreur dans les différents logs (log lvm level=7 lvm2).

Bref, je passe les détails qui me permettent de mieux comprendre le problème et d’arriver enfin à reproduire le symptôme:

En fait, la partition LVM se bloque systématiquement si je lance une sauvegarde de type snapshot alors que l’array raid soft (”md0″ sur mon serveur) est en cours de “check” ou “recover”.
(”checkarray” est lancé tous les premiers dimaches de chaque mois à 0h57 par “/etc/cron.d/mdadm”)

Donc, si je lance un checkarray:

# /usr/share/mdadm/checkarray –cron –all –quiet

et une sauvegarde snapshot :

# vzdump –snapshot –dumpdir /backups/ 201

après quelques secondes la partition LVM se bloque systématiquement.

Lorsque la partition LVM ne répond plus, j’execute la procédure ci-dessous pour la récupérer :

marquer “faulty” un des hdd du array raid soft:
# mdadm –manage /dev/md0 –fail /dev/sdb3

Reboot via la manager OVH (le reboot soft ne reboot pas)

supprimer le LV snapshot (utiliser “lvscan” pour voir les snapshot actif)
# lvremove /dev/data/vzsnap

re-attacher le hdd au md:
# mdadm –manage /dev/md0 –re-add /dev/sdb3

A ce stade, la partition LVM doit de nouveau être accessible. Cette procédure a toujours fonctionné pour moi.

Malheureusement, les équipes Proxmox et Debian ne souhaitent pas étudier ce symptôme. Proxmox car le problème est lié au raid soft, et Debian car il s’agit d’un kernel non 100% debian.

Voila où j’en suis de ma conpréhension du problème. Pour aller plus loin, il faudrait essayer de reproduire le symptôme sur un serveur pur Debian 64 bits, et, en cas de réussite, le soumettre à l’équipe Debian.

En attendant mieux, j’ai modifié le script “vzdump” pour qu’il n’execute pas de sauvegarde si le raid soft n’est pas optimal et je m’arrange pour ne pas avoir de sauvegarde en cours les dimanches à 0h57.

———————————————————————-

Mise à jour 2009/11/13:

Alors … est-ce Proxmox fonctionne avec du raid soft ?

A ce jour et en attendant mieux, voici ma réponse :

Je n’ai pas constaté d’autre problème que celui décrit ci-dessus, donc, je considère qu’il est possible d’utiliser proxmox avec du raid soft, sous reserve de :

1) Ne pas utiliser de partition LVM

2) Avec une partition LVM, ne pas utiliser de sauvegarde snapshot. Malheureusement les sauvagardes suspend/resume semble aussi poser des problèmes (cf update du 2010/3/1 ci-dessous)

3) Avec une partition LVM et des sauvegardes snapshot:
Il faut absolument ne pas démarrer une sauvegarde lorsque la partition raid est en état “check” ou “recover”. Cela impose de de modifier vzdump pour vérifier l’état de la partition raid. Malheureusement, il reste un cas non géré suceptible de geler la partition lvm: si un “recover” démarre  pendant une sauvegarde snapshot.

Pour finir, je précise que je n’ai jamais perdu mes machines virtuelles. La procédure de récupération décrite ci-dessus à toujours fonctionner pour moi.

————————————————————————

Mise à jour 2009/12/7

Je n’ai pas réussi à reproduire le symptome sur un debian 5/OVH:

#uname -a
Linux ns353018.ovh.net 2.6.31.5-grsec-xxxx-grs-ipv4-64 #3 SMP Tue Nov 24 16:51:16 UTC 2009 x86_64 GNU/Linux

Plus précisement, la commande de vzdump ci-dessous est passée sans problème (plante systématiquement avec un kernel proxmox 1.3):

Avec la partition RAID 1 en cours de resync, depuis un snapshot lvm vers une partition ext3:

#cd /mnt/vzsnap
#find . ‘(’ -type ’s’ -prune ‘)’ -o -print0|tar cpf - –totals –sparse –numeric-owner –no-recursion –ignore-failed-read –null -T -|cstream -t 10485760 >/home/test2.dat

A suivre …

————————————————————————–

Mise à jour 2010/01/25

Enfin du nouveau: http://forum.ovh.com/showthread.php?t=55870, Merci madameirma12955 !

Il semble donc que le probleme soit lié au bug connu évoqué ici :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/212684

En résumé, le bug dépend du matériel et se produit sur les serveurs exploitant un controlleur HDD Intel 82801 SATA AHCI.

De fait, sur mon serveur OVH, j’obtiens:

# lspci -vvnn
00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller [8086:2922] (rev 02) (prog-if 01 [AHCI 1.0])
        Subsystem: Intel Corporation Device [8086:5044]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 2298
        Region 0: I/O ports at 2428 [size=8]
        Region 1: I/O ports at 243c [size=4]
        Region 2: I/O ports at 2420 [size=8]
        Region 3: I/O ports at 2438 [size=4]
        Region 4: I/O ports at 2020 [size=32]
        Region 5: Memory at e83a1000 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4 Enable+
                Address: fee0300c  Data: 4199
        Capabilities: [70] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a8] SATA HBA <?>
        Capabilities: [b0] Vendor Specific Information <?>
        Kernel driver in use: ahci
        Kernel modules: ahci

Le probleme serait corrigé dans le kernel 2.6.27-11.26, malheureusement pas encore utilisé avec Proxmox.

Patience …

————————————————————————–

Mise à jour 2010/03/01

J’ai rencontré, à quatre reprises, un autre problème qui semble se produire uniquement sur les serveurs avec Raid soft. Il s’agit d’un Oops kernel qui se produit lors du “resume” de la VM en fin de vzdump. Le symptôme visible après le kernel Oops est une VM complètement figée, impossible à redémarrer. Il y a des threads en état State = D, pour les voir taper la commande “ps axl | grep D”.
A ma connaissance, comme il est impossible de tuer les threads avec State = D, le seul moyen de sortir de cette situation est un reboot hard.
Mes tentatives de reboot avec la commande “reboot” n’ont pas fonctionnées, il m’a fallut à chaque fois faire un reboot hard par coupure de l’alimentation.
Je n’ai trouvé aucune solution à ce jour. Je conseille donc les sauvegardes snapshot avec les précautions du premier dimanche de chaque mois.
Voici les détails du symptome:
Log de vzdump:

2010-02-24T02:09:00+0100 vzctl : CT 103 : Checkpointing completed succesfully
2010-02-24T02:11:09+0100 vzctl : CT 103 : Resuming…
2010-02-24T08:13:05+0100 vzctl : CT 103 : Removing stale lock file /var/lib/vz/lock/103.lck
2010-02-24T08:13:05+0100 vzctl : CT 103 : Restarting container
2010-02-24T08:13:05+0100 vzctl : CT 103 : Stopping container …
2010-02-24T08:16:05+0100 vzctl : CT 103 : Unable to stop container: operation timed out

Pas de failcnt dans vzctl exec 103 cat /proc/user_beancouters
Feb 22 02:11:21 ns300364 kernel: Unable to handle kernel NULL pointer dereference at 0000000000000808 RIP:
Feb 22 02:11:21 ns300364 kernel: [<ffffffff804c9708>] _spin_lock_irqsave+0×28/0xb0
Feb 22 02:11:21 ns300364 kernel: PGD 1131dc067 PUD 10e4c9067 PMD 0
Feb 22 02:11:21 ns300364 kernel: Oops: 0002 [1] PREEMPT SMP
Feb 22 02:11:21 ns300364 kernel: CPU: 1
Feb 22 02:11:21 ns300364 kernel: Modules linked in: kvm_intel kvm vzethdev vznetdev simfs vzrst vzcpt tun vzdquota vzmon vzdev xt_length ipt_ttl xt_tcpmss xt_TCPMSS xt_multiport xt_limit ipt_tos ipt_REJECT xt_tcpudp xt_state iptable_filter iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_raw ip_tables x_tables dummy bridge ipv6 ata_generic pata_acpi ehci_hcd ohci1394 i2c_i801 uhci_hcd ieee1394 pata_marvell pcspkr evdev i2c_core usbcore e1000e button heci intel_agp dm_snapshot thermal processor fan sata_nv via686a ahci mptctl mptsas scsi_transport_sas mptspi mptscsih mptbase dm_crypt raid456 async_xor async_memcpy async_tx xor raid0 raid1 md_mod dm_mirror dm_mod sata_via ata_piix sata_sis pata_sis libata sym53c8xx megaraid aic7xxx scsi_transport_spi sd_mod 3w_xxxx scsi_mod atl1 sky2 skge r8169 e1000 via_rhine sis900 8139too e100 mii
Feb 22 02:11:21 ns300364 kernel: Pid: 7511, comm: vzctl Not tainted 2.6.24-7-pve #1 ovz005
Feb 22 02:11:21 ns300364 kernel: RIP: 0010:[<ffffffff804c9708>] [<ffffffff804c9708>] _spin_lock_irqsave+0×28/0xb0
Feb 22 02:11:21 ns300364 kernel: RSP: 0000:ffff810102d67df8 EFLAGS: 00010002
Feb 22 02:11:21 ns300364 kernel: RAX: 0000000000000000 RBX: 0000000000000808 RCX: 00000000c0000100
Feb 22 02:11:21 ns300364 kernel: RDX: 0000000000000202 RSI: ffff8100831348e0 RDI: 0000000000000808
Feb 22 02:11:21 ns300364 kernel: RBP: 0000000000000000 R08: ffff810102d66000 R09: 0000000000000000
Feb 22 02:11:21 ns300364 kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100d7965f80
Feb 22 02:11:21 ns300364 kernel: R13: ffff81003d5b9000 R14: ffff81003d5b9198 R15: 0000000000001000
Feb 22 02:11:21 ns300364 kernel: FS: 00007f8f0ad876e0(0000) GS:ffff810117402880(0000) knlGS:0000000000000000
Feb 22 02:11:21 ns300364 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Feb 22 02:11:21 ns300364 kernel: CR2: 0000000000000808 CR3: 0000000108089000 CR4: 00000000000026e0
Feb 22 02:11:21 ns300364 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Feb 22 02:11:21 ns300364 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Feb 22 02:11:21 ns300364 kernel: Process vzctl (pid: 7511, veid=0, threadinfo ffff810102d66000, task ffff810046634000)
Feb 22 02:11:21 ns300364 kernel: Stack: ffff8100831348e0 ffff81001b1bd1c0 ffff81003d5b9020 ffffffff884c8796
Feb 22 02:11:21 ns300364 kernel: 0000000000000000 0000000000002d08 ffff81003d5b9020 ffff8100d7be5200
Feb 22 02:11:21 ns300364 kernel: 0000000000000000 ffff81003d5b9000 0000000000000000 ffffffff884c4fed
Feb 22 02:11:21 ns300364 kernel: Call Trace:
Feb 22 02:11:21 ns300364 kernel: [<ffffffff884c8796>] :vzcpt:cpt_resume+0xe6/0×210
Feb 22 02:11:21 ns300364 kernel: [<ffffffff884c4fed>] :vzcpt:cpt_ioctl+0xa3d/0xeb0
Feb 22 02:11:21 ns300364 kernel: [<ffffffff804cba66>] do_page_fault+0×176/0×890
Feb 22 02:11:21 ns300364 kernel: [<ffffffff884c45b0>] :vzcpt:cpt_ioctl+0×0/0xeb0
Feb 22 02:11:21 ns300364 kernel: [<ffffffff8031c43e>] proc_reg_unlocked_ioctl+0xee/0×110
Feb 22 02:11:21 ns300364 kernel: [<ffffffff802e18af>] do_ioctl+0×2f/0xb0
Feb 22 02:11:21 ns300364 kernel: [<ffffffff802e1bbb>] vfs_ioctl+0×28b/0×300
Feb 22 02:11:21 ns300364 kernel: [<ffffffff802d2a3c>] vfs_write+0×12c/0×190
Feb 22 02:11:21 ns300364 kernel: [<ffffffff802e1c79>] sys_ioctl+0×49/0×80
Feb 22 02:11:21 ns300364 kernel: [<ffffffff8020c69e>] system_call+0×7e/0×83
Feb 22 02:11:21 ns300364 kernel:
Feb 22 02:11:21 ns300364 kernel:
Feb 22 02:11:21 ns300364 kernel: Code: 87 03 85 c0 7e 19 c7 43 04 00 00 00 00 48 89 d0 48 8b 5c 24
Feb 22 02:11:21 ns300364 kernel: RIP [<ffffffff804c9708>] _spin_lock_irqsave+0×28/0xb0
Feb 22 02:11:21 ns300364 kernel: RSP <ffff810102d67df8>
Feb 22 02:11:21 ns300364 kernel: CR2: 0000000000000808
Feb 22 02:11:21 ns300364 kernel: —[ end trace 71ce71d54ca466b6 ]—
Feb 22 02:11:21 ns300364 kernel: note: vzctl[7511] exited with preempt_count 1
***** Liste des threads avec State en état D :
# ps axl | grep D
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 1000 5984 4362 20 0 63332 34724 futex_ Sl ? 4:04 /usr/bin/mono /var/www/dekiwiki/bin/mindtouch.host.exe apikey jPcYGyFZ86f48kmu5Dq04POIiSBMcpGt script /etc/dekiwiki/mindtouch.deki.startup.xml path-prefix @api http-port 8081 ip localhost connect-limit -5 notty
1 0 10723 4255 20 0 1656 384 wait Ss ? 0:00 /opt/zimbra/libexec/zmmailboxdmgr start -server -Djava.awt.headless=true -XX:+UseConcMarkSweepGC -XX:NewRatio=2 -XX:PermSize=128m -XX:MaxPermSize=128m -XX:SoftRefLRUPolicyMSPerMB=1 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -Xss256k -Xms1512m -Xmx1512m -Xmn378m
4 500 10724 10723 20 0 1908692 673780 futex_ Sl ? 51:22 /opt/zimbra/java/bin/java -server -Djava.awt.headless=true -XX:+UseConcMarkSweepGC -XX:NewRatio=2 -XX:PermSize=128m -XX:MaxPermSize=128m -XX:SoftRefLRUPolicyMSPerMB=1 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -Xss256k -Xms1512m -Xmx1512m -Xmn378m -Djava.io.tmpdir=/opt/zimbra/mailboxd/work -Djava.library.path=/opt/zimbra/lib -Djava.endorsed.dirs=/opt/zimbra/mailboxd/common/endorsed -Dzimbra.config=/opt/zimbra/conf/localconfig.xml -Djetty.home=/opt/zimbra/mailboxd -DSTART=/opt/zimbra/mailboxd/etc/start.config -jar /opt/zimbra/mailboxd/start.jar /opt/zimbra/mailboxd/etc/jetty.properties /opt/zimbra/mailboxd/etc/jetty-setuid.xml /opt/zimbra/mailboxd/etc/jetty.xml
0 500 12452 4255 20 0 6420 4652 refrig D ? 0:12 /usr/bin/perl -w? /opt/zimbra/libexec/zmstat-io
0 500 12454 4255 20 0 6420 4580 refrig D ? 0:14 /usr/bin/perl -w? /opt/zimbra/libexec/zmstat-fd
0 500 12458 4255 20 0 6552 4736 refrig D ? 10:12 /usr/bin/perl -w? /opt/zimbra/libexec/zmstat-mysql
0 500 12488 4255 20 0 6420 4592 refrig D ? 1:34 /usr/bin/perl -w? /opt/zimbra/libexec/zmstat-mtaqueue
0 500 12813 4255 20 0 6732 4880 refrig D ? 0:00 /usr/bin/perl /opt/zimbra/libexec/logswatch –config-file=/opt/zimbra/conf/logswatchrc –use-cpan-file-tail –pid-file=/opt/zimbra/log/logswatch.pid –script-dir=/opt/zimbra/data/tmp -t /var/log/zimbra-stats.log
0 500 12815 12813 20 0 8764 6780 refrig D ? 0:01 /usr/bin/perl /opt/zimbra/data/tmp/.swatch_script.4935
0 500 12817 12815 20 0 16168 5364 refrig D ? 0:01 /usr/bin/perl /opt/zimbra/libexec/zmlogger
0 500 12873 12452 20 0 1692 600 refrig D ? 0:06 /usr/bin/iostat -d -k 30
0 500 12962 4255 20 0 6732 4896 refrig D ? 0:00 /usr/bin/perl /opt/zimbra/libexec/swatch –config-file=/opt/zimbra/conf/swatchrc –use-cpan-file-tail –script-dir=/opt/zimbra/data/tmp -t /var/log/zimbra.log
0 500 13006 12962 20 0 8768 6772 refrig D ? 0:01 /usr/bin/perl /opt/zimbra/data/tmp/.swatch_script.5080
1 500 13061 4255 20 0 9912 7460 refrig D ? 0:00 /usr/bin/perl /opt/zimbra/libexec/zmmtaconfig
0 500 13930 13755 20 0 430408 28196 futex_ Sl ? 0:02 /opt/zimbra/java/bin/java -XX:ErrorFile=/opt/zimbra/log -client -Xmx256m -Dzimbra.home=/opt/zimbra -Djava.library.path=/opt/zimbra/lib -Djava.ext.dirs=/opt/zimbra/java/jre/lib/ext:/opt/zimbra/lib/jars:/opt/zimbra/lib/ext-common:/opt/zimbra/lib/ext/clamscanner com.zimbra.common.util.ConsoleRunner com.zimbra.cs.account.ProvUtil gas mta
0 0 19763 3574 20 0 8888 792 pipe_w S+ pts/0 0:00 grep D
root@ns300364:~#

Un commentaire

  1. Pour rebooter tu peux faire un
    J’ai aussi le problème mais uniquement avec une VE particuliere ????
    par contre j’arrive a faire un reboot soft avec : reboot -f
    en ayant pris soint d’arreter les autres ve avant, le système est de nouveau up dans la minute (avec les ve lancer); le temps de redemarrage est fonction de la place disque occuper par la ve défaillante : le système ayant besoin de refaire un vzquota avant de relancer la vm

    Commentaire par lorksoft — 9 avril 2010 @ 4:30

Flux RSS des commentaires de cet article.

Désolé, les commentaires sont fermés pour le moment.

Propulsé par WordPress