Comment puis-je simuler un disque défectueux pendant le test?

Question

Dans une machine virtuelle Linux (poste de travail Vmware ou similaire), comment puis-je simuler une panne sur un disque fonctionnant précédemment?

J'ai une situation en production où un disque tombe en panne (probablement un problème de contrôleur, de câble ou de microprogramme). Évidemment, ce n'est pas prévisible ou reproductible, je veux tester mon monitoring pour m'assurer qu'il alerte correctement. Je voudrais idéalement être capable de simuler une situation où elle échoue écrit mais réussit à lire, ainsi qu'un échec complet, c'est-à-dire que l'interface scsi rapporte des erreurs au noyau.

Answer 1

Il existe plusieurs couches pour lesquelles une erreur de disque peut être simulée. Si vous testez un seul programme d'espace utilisateur, l'approche la plus simple consiste probablement à interposer les appels appropriés (par exemple, write()) et à leur renvoyer parfois une erreur. La bibliothèque libfiu d'injection de faute can do this en utilisant son outil fiu-run.

Une autre approche consiste à utiliser un pilote de noyau qui peut transmettre des données vers/depuis un autre périphérique, tout en injectant des erreurs en cours de route. Vous pouvez ensuite monter l'appareil et l'utiliser depuis n'importe quelle application comme s'il s'agissait d'un disque défectueux. Le pilote fsdisk en est un exemple.

Il existe également une infrastructure d'injection de fautes qui a été intégrée au noyau Linux, bien que vous ayez probablement besoin de reconfigurer votre noyau pour l'activer. Il est documenté dans Documentation/fault-injection/fault-injection.txt. Ceci est utile pour tester le code du noyau.

Il est également possible d'utiliser SystemTap pour injecter des défauts au niveau du noyau. Voir The SCSI fault injection test et Kernel Fault injection using SystemTap.

Answer 2

Un moyen simple de réaliser un disque SCSI disparaître avec un noyau 2.6 est la suivante:

echo 1 > /sys/bus/scsi/devices/H:B:T:L/delete 

(H: B: T: L est l'hôte, bus, cible, LUN). Pour simuler le cas en lecture seule, vous devrez utiliser les méthodes d'injection de faute mentionnées par mark4o.

Answer 3

Pour ajouter à la réponse de mark4o, vous pouvez également utiliser Device Mapper de Linux pour générer des périphériques défaillants.

Device Mapper's delay device peut être utilisé pour envoyer des E/S de lecture et d'écriture du même bloc à différents périphériques sous-jacents (il peut également retarder les E/S comme son nom l'indique). Le périphérique d'erreur Device Mapper peut être utilisé pour générer des erreurs permanentes lorsqu'un bloc particulier est accédé. En combinant les deux, vous pouvez créer un périphérique où les écritures échouent toujours mais les lectures réussissent toujours pour une zone donnée. Ce qui précède est un exemple plus compliqué de ce qui est décrit dans la question Simulate a faulty block device with read errors? (voir https://stackoverflow.com/a/1871029 pour un exemple de Device Mapper simple). Il existe également un list of Linux disk fault injection mechanisms sur la question Linux Special File that causes I/O error Unix &.

Answer 4

Vous pouvez utiliser le module noyau scsi_debug pour simuler un disque RAM et il prend en charge toutes les erreurs SCSI avec les options opts et every_nth.

S'il vous plaît vérifier http://sg.danny.cz/sg/sdebug26.html

Exemple d'erreur moyenne sur le secteur 4656:

[fge@Gris-Laptop ~]$ sudo modprobe scsi_debug opts=2 every_nth=1 
[fge@Gris-Laptop ~]$ sudo dd if=/dev/sdb of=/dev/null 
dd: error reading ‘/dev/sdb’: Input/output error 
4656+0 records in 
4656+0 records out 
2383872 bytes (2.4 MB) copied, 0.021299 s, 112 MB/s 
[fge@Gris-Laptop ~]$ dmesg|tail 
[11201.454332] blk_update_request: critical medium error, dev sdb, sector 4656 
[11201.456292] sd 5:0:0:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE 
[11201.456299] sd 5:0:0:0: [sdb] Sense Key : Medium Error [current] 
[11201.456303] sd 5:0:0:0: [sdb] Add. Sense: Unrecovered read error 
[11201.456308] sd 5:0:0:0: [sdb] CDB: Read(10) 28 00 00 00 12 30 00 00 08 00 
[11201.456312] blk_update_request: critical medium error, dev sdb, sector 4656 

Vous pouvez modifier les opts et every_nth options dans l'exécution via sysfs:

echo 2 | sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts 
echo 1 | sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts 

Answer 5

noyau Linux fournit une fonctionnalité intéressante appelée "injection de faute"

echo 1 > /sys/block/vdd/vdd2/make-it-fail 

Pour configurer certaines options:

mkdir /debug 
mount debugfs /debug -t debugfs 
cd /debug/fail_make_request 
echo 10 > interval # interval 
echo 100 > probability # 100% probability 
echo -1 > times # how many times: -1 means no limit 

https://lxadm.com/Using_fault_injection

Answer 6

On peut aussi utiliser des méthodes qui sont fournis par les disques pour faire des tests d'erreur de médias. SCSI a une commande WRITE LONG qui peut être utilisée pour corrompre un bloc en écrivant des données avec ECC invalide. SATA et NVMe ont également des commandes similaires. Pour le cas le plus courant (SATA), vous pouvez utiliser hdparm avec --make-bad-sector pour utiliser cette commande, vous pouvez utiliser sg_write_long pour SCSI et pour NVMe vous pouvez utiliser le nvme-cli avec le write-uncor option. Le gros avantage de ces commandes par rapport aux autres méthodes d'injection est qu'elles se comportent également comme un disque, avec des impacts de latence complets et la récupération après écriture sur ce secteur par réallocation. Cela inclut également les compteurs d'erreurs remontant dans le lecteur. L'inconvénient est que si vous faites cela trop pour le même lecteur, ses compteurs d'erreur vont augmenter et SMART peut marquer le disque comme mauvais ou vous pouvez épuiser ses tables de réallocation. Alors, utilisez-le pour les tests manuels, mais si vous l'utilisez sur des tests automatisés, ne le faites pas trop souvent.