Programme RAID Linux arrête de répondre après avoir retiré le disque du serveur

Je lance la voiture CentOS 7 (Noyau standard:

        3.10.0-327.36.3.el7.x86_64

      

) avec logiciel RAID-10 plus de 16 Bottes d'état solides 1 Tb (Plus précisément, il existe deux matrices RAID sur les disques; L'un des tableaux fournit une section de pagination hôte). La semaine dernière refusée SSD:

13:18:07 kvm7 kernel: sd 1:0:2:0: attempting task abort! scmd(ffff887e57b916c0)

13:18:07 kvm7 kernel: sd 1:0:2:0: [sdk] CDB: Write(10) 2a 08 02 55 20 08 00 00 01 00

13:18:07 kvm7 kernel: scsi target1:0:2: handle(0x000b), sas_address(0x4433221102000000), phy(2)

13:18:07 kvm7 kernel: scsi target1:0:2: enclosure_logical_id(0x500304801c14a001), slot(2)

13:18:10 kvm7 kernel: sd 1:0:2:0: task abort: SUCCESS scmd(ffff887e57b916c0)

13:18:11 kvm7 kernel: sd 1:0:2:0: [sdk] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

13:18:11 kvm7 kernel: sd 1:0:2:0: [sdk] Sense Key : Not Ready [current] 

13:18:11 kvm7 kernel: sd 1:0:2:0: [sdk] Add. Sense: Logical unit not ready, cause not reportable

13:18:11 kvm7 kernel: sd 1:0:2:0: [sdk] CDB: Write(10) 2a 08 02 55 20 08 00 00 01 00

13:18:11 kvm7 kernel: blk_update_request: I/O error, dev sdk, sector 39133192

13:18:11 kvm7 kernel: blk_update_request: I/O error, dev sdk, sector 39133192

13:18:11 kvm7 kernel: md: super_written gets error=-5, uptodate=0

13:18:11 kvm7 kernel: md/raid10:md3: Disk failure on sdk3, disabling device.#012md/raid10:md3: Operation continuing on 15 devices.

13:19:27 kvm7 kernel: sd 1:0:2:0: device_blocked, handle(0x000b)

13:19:29 kvm7 kernel: sd 1:0:2:0: [sdk] Synchronizing SCSI cache

13:19:29 kvm7 kernel: md: md3 still in use.

13:19:29 kvm7 kernel: sd 1:0:2:0: [sdk] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

13:19:29 kvm7 kernel: mpt3sas1: removing handle(0x000b), sas_addr(0x4433221102000000)

13:19:29 kvm7 kernel: md: md2 still in use.

13:19:29 kvm7 kernel: md/raid10:md2: Disk failure on sdk2, disabling device.#012md/raid10:md2: Operation continuing on 15 devices.

13:19:29 kvm7 kernel: md: unbind<sdk3>

13:19:29 kvm7 kernel: md: export_rdev(sdk3)

13:19:29 kvm7 kernel: md: unbind<sdk2>

13:19:29 kvm7 kernel: md: export_rdev(sdk2)

        /proc/mdstat

      

ressemblait à prévu (1 membre défectueux), Et les machines virtuelles ont continué de travailler sans aucun problème.

md3 : active raid10 sdp3[15] sdb3[2] sdg3[12] sde3[8] sdn3[11] sdl3[7] sdm3[9] sdf3[10] sdi3[1] sdk3[5](F) sdc3[4] sdd3[6] sdh3[14] sdo3[13] sda3[0] sdj3[3]

    7844052992 blocks super 1.2 128K chunks 2 near-copies [16/15] [UUUUU_UUUUUUUUUU]

SSD devait remplacer temporairement SSD plus grand parce que SSD sur 1 La tuberculose n'était pas disponible; Nous avons donc fait une restructuration et tout allait bien. Aujourd'hui est arrivé "à droite" SSD, Par conséquent, le spécialiste technique du spécialiste du centre de données a simplement sorti le plateau avec le SSD, Et le système a cessé de répondre dans quelques secondes. Tandis que l'hôte a fonctionné normalement sur un tableau séparé RAID, Les machines virtuelles ne pouvaient pas exécuter des opérations d'E / S. Charge augmentée à> 800. J'ai pu exécuter

        mdadm --detail /dev/md3

      

Qui a montré dégradé (Mais actif / faire le ménage) Un tableau, donc de ce point de vue, le système était absolument en ordre. J'ai essayé de supprimer les défectueux / disque manquant de la matrice, qui, bien sûr, a échoué ("Il n'y a pas de tel dispositif"), Et soudain même

        mdadm --detail /dev/md3

      

n'a plus généré aucune conclusion, il a juste pendu, et je devais tuer une session SSH, S'en sortir. Après cela, j'ai décidé de redémarrer avec force l'ordinateur, car je ne savais même pas comment supprimer ce disque défectueux de la matrice. - Et tout s'est avéré correctement. Bien sûr, RAID Il était toujours dégradé et nécessaire pour synchroniser, mais en plus de cela:

aucun problème.

Je suis presque sûr que je

doit

Disque supprimé à travers mdadm après

        --set-faulty

      

Avant de tirer le plateau du rack,

Bien que je ne puisse pas expliquer ce comportement mdraid.

À mon avis, nous avons "modélisé" la déconnexion habituelle du disque, de sorte que quelqu'un a une idée de ce qui a causé ce problème et comment puis-je vous assurer que la prochaine déconnexion du disque ordinaire provoquera le même problème?

Le noyau a enregistré plusieurs messages, et qu'il me semblait intéressant, c'est ce que le nouvel appareil est apparu comme

SDQ

Tandis que le dispositif tiré était connu comme

        sdk

      

. Alors je suppose que

        sdk

      

Pas Pinali

correctement

De la matrice. Quand la semaine dernière, il y avait un premier échec SSD, Je n'ai pas remarqué ce comportement; Donc, le lecteur remplaçable s'est également approché comme

        sdk

      

.

Le magazine montre aussi 7 minutes entre l'échec de l'ancien et d'insertion SSD, Par conséquent, je ne pense pas que le problème similaire à celui décrit dans la section
https://superuser.com/question ... nding
a eu lieu. De plus, des machines virtuelles désactivées immédiatement, pas à travers 7 minutes. alors - Des pensées à ce sujet? Je serai très reconnaissant :)

11:45:36 kvm7 kernel: sd 1:0:8:0: device_blocked, handle(0x000b)

11:45:37 kvm7 kernel: blk_update_request: I/O error, dev sdk, sector 0

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069640

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069648

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069656

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069664

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069672

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069680

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069688

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069696

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069704

11:45:37 kvm7 kernel: md/raid10:md3: sdk3: rescheduling sector 4072069712

11:45:37 kvm7 kernel: sd 1:0:8:0: [sdk] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

11:45:37 kvm7 kernel: sd 1:0:8:0: [sdk] CDB: Read(10) 28 00 20 af f7 08 00 00 08 00

11:45:37 kvm7 kernel: blk_update_request: I/O error, dev sdk, sector 548402952

11:45:37 kvm7 kernel: blk_update_request: I/O error, dev sdk, sector 0

11:45:37 kvm7 kernel: blk_update_request: I/O error, dev sdk, sector 39133192

11:45:37 kvm7 kernel: md: super_written gets error=-5, uptodate=0

11:45:37 kvm7 kernel: md/raid10:md3: Disk failure on sdk3, disabling device.#012md/raid10:md3: Operation continuing on 15 devices.

11:45:37 kvm7 kernel: md: md2 still in use.

11:45:37 kvm7 kernel: md/raid10:md2: Disk failure on sdk2, disabling device.#012md/raid10:md2: Operation continuing on 15 devices.

11:45:37 kvm7 kernel: blk_update_request: I/O error, dev sdk, sector 39133264

11:45:37 kvm7 kernel: md: super_written gets error=-5, uptodate=0

11:45:37 kvm7 kernel: sd 1:0:8:0: [sdk] Synchronizing SCSI cache

11:45:37 kvm7 kernel: sd 1:0:8:0: [sdk] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

11:45:37 kvm7 kernel: mpt3sas1: removing handle(0x000b), sas_addr(0x4433221102000000)

11:45:37 kvm7 kernel: md: unbind<sdk2>

11:45:37 kvm7 kernel: md: export_rdev(sdk2)

11:48:00 kvm7 kernel: INFO: task md3_raid10:1293 blocked for more than 120 seconds.

11:48:00 kvm7 kernel: "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.

11:48:00 kvm7 kernel: md3_raid10      D ffff883f26e55c00     0  1293      2 0x00000000

11:48:00 kvm7 kernel: ffff887f24bd7c58 0000000000000046 ffff887f212eb980 ffff887f24bd7fd8

11:48:00 kvm7 kernel: ffff887f24bd7fd8 ffff887f24bd7fd8 ffff887f212eb980 ffff887f23514400

11:48:00 kvm7 kernel: ffff887f235144dc 0000000000000001 ffff887f23514500 ffff8807fa4c4300

11:48:00 kvm7 kernel: Call Trace:

11:48:00 kvm7 kernel: [<ffffffff8163bb39>] schedule+0x29/0x70

11:48:00 kvm7 kernel: [<ffffffffa0104ef7>] freeze_array+0xb7/0x180 [raid10]

11:48:00 kvm7 kernel: [<ffffffff810a6b80>] ? wake_up_atomic_t+0x30/0x30

11:48:00 kvm7 kernel: [<ffffffffa010880d>] handle_read_error+0x2bd/0x360 [raid10]

11:48:00 kvm7 kernel: [<ffffffff812c7412>] ? generic_make_request+0xe2/0x130

11:48:00 kvm7 kernel: [<ffffffffa0108a1d>] raid10d+0x16d/0x1440 [raid10]

11:48:00 kvm7 kernel: [<ffffffff814bb785>] md_thread+0x155/0x1a0

11:48:00 kvm7 kernel: [<ffffffff810a6b80>] ? wake_up_atomic_t+0x30/0x30

11:48:00 kvm7 kernel: [<ffffffff814bb630>] ? md_safemode_timeout+0x50/0x50

11:48:00 kvm7 kernel: [<ffffffff810a5b8f>] kthread+0xcf/0xe0

11:48:00 kvm7 kernel: [<ffffffff810a5ac0>] ? kthread_create_on_node+0x140/0x140

11:48:00 kvm7 kernel: [<ffffffff81646a98>] ret_from_fork+0x58/0x90

11:48:00 kvm7 kernel: [<ffffffff810a5ac0>] ? kthread_create_on_node+0x140/0x140

11:48:00 kvm7 kernel: INFO: task qemu-kvm:26929 blocked for more than 120 seconds.



[serveral messages for stuck qemu-kvm processes]



11:52:42 kvm7 kernel: scsi 1:0:9:0: Direct-Access     ATA      KINGSTON SKC400S 001A PQ: 0 ANSI: 6

11:52:42 kvm7 kernel: scsi 1:0:9:0: SATA: handle(0x000b), sas_addr(0x4433221102000000), phy(2), device_name(0x4d6b497569a68ba2)

11:52:42 kvm7 kernel: scsi 1:0:9:0: SATA: enclosure_logical_id(0x500304801c14a001), slot(2)

11:52:42 kvm7 kernel: scsi 1:0:9:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)

11:52:42 kvm7 kernel: scsi 1:0:9:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)

11:52:42 kvm7 kernel: sd 1:0:9:0: Attached scsi generic sg10 type 0

11:52:42 kvm7 kernel: sd 1:0:9:0: [sdq] 2000409264 512-byte logical blocks: (1.02 TB/953 GiB)

11:52:42 kvm7 kernel: sd 1:0:9:0: [sdq] Write Protect is off

11:52:42 kvm7 kernel: sd 1:0:9:0: [sdq] Write cache: enabled, read cache: enabled, supports DPO and FUA

11:52:42 kvm7 kernel: sdq: unknown partition table

11:52:42 kvm7 kernel: sd 1:0:9:0: [sdq] Attached SCSI disk

</ffffffff810a5ac0></ffffffff81646a98></ffffffff810a5ac0></ffffffff810a5b8f></ffffffff814bb630></ffffffff810a6b80></ffffffff814bb785></ffffffffa0108a1d></ffffffff812c7412></ffffffffa010880d></ffffffff810a6b80></ffffffffa0104ef7></ffffffff8163bb39></sdk2></sdk2></sdk3>