PowerFlex : L’ajout d’un appareil SDS échoue avec l’erreur « Un appareil portant le même nom existe déjà dans le SDS »

Lors de l’ajout d’un appareil à un SDS via scli, cette erreur s’affichera :

# scli --add_sds_device --sds_name sds-01 --device_path /dev/sdc --storage_pool pool1
Error: MDM failed command. Status: A device with the given name already exists in the SDS

En général, ce problème peut être résolu en utilisant «--update_device_original_path. » Toutefois, la tentative de résolution du problème des chemins d’accès aux périphériques Un périphérique portant le même nom existe déjà dans le SDS se termine désormais par l’erreur suivante :

#  scli --update_device_original_path --sds_id be84190600000001 --device_id cd82454400010008
Error: MDM failed command.  Status: Device has an unhandled error that cannot yet be cleared 

Impact

Impossible d’ajouter de nouveaux périphériques au SDS pour étendre la capacité de stockage dans le cluster.

Comme mentionné précédemment, lorsque cette erreur s’affiche, la première chose à faire est de mettre à jour le chemin d’accès d’origine de l’appareil qui existe actuellement dans le SDS. Si cela échoue, cela est dû au fait que les appareils contrôlés par le SDS sur cet hôte ont déjà rencontré une erreur qui a été effacée, soit dans l’interface utilisateur, soit à partir de la ligne de commande, mais le MDM ne permet pas d’effacer davantage les erreurs d’appareil, car il n’est plus à l’état « errored ». L'« erreur non gérée » est un problème ScaleIO qui est résolu dans une révision ultérieure du code.

Pour contourner ce problème, le moyen le plus rapide consiste à ajouter un périphérique temporaire qui comble le vide dans la liste des périphériques. Par exemple :

# scli --query_sds --sds_id be84190600000001 |grep ID: |awk '{print $4,$5,$6,$7}'
Path: /dev/sdb Original-path: /dev/sdb
Path: /dev/sdc Original-path: /dev/sdc
Path: /dev/sdd Original-path: /dev/sdd
Path: /dev/sde Original-path: /dev/sde
Path: /dev/sdf Original-path: /dev/sdf
Path: /dev/sdg Original-path: /dev/sdh
Path: /dev/sdh Original-path: /dev/sdi
Path: /dev/sdi Original-path: /dev/sdj
 
# lsblk
NAME   MAJ:MIN RM   SIZE RO MOUNTPOINT
sdb      8:16   0 930.4G  0
sdc      8:32   0 930.4G  0
sdd      8:48   0 930.4G  0
sde      8:64   0 930.4G  0
sdf      8:80   0 930.4G  0
sdg      8:96   0 930.4G  0
sda      8:0    0     8G  0
ââsda1   8:1    0  1011M  0 [SWAP]
ââsda2   8:2    0     7G  0 /
sdi      8:128  0 930.4G  0
sdh      8:112  0 930.4G  0
fd0      2:0    1     4K  0
sr0     11:0    1  1024M  0

Notez le chemin actuel que chaque périphérique utilise. Le dernier périphérique est /dev/sdi. Lorsqu’un nouvel appareil est ajouté, il se présente comme suit : /dev/sdj. Il y a déjà un /dev/sdj répertorié sous Original-Path. Lorsqu’un nouvel appareil SDS est ajouté, les chemins d’accès actuel et d’origine doivent correspondre. L’option «--update_device_original_path" est censée éclaircir ce problème et faire correspondre les chemins d’accès actuel et d’origine.

Dans ce cas, l’hôte étant une SVM sur ESXi, nous ajoutons un petit VMDK (8 Go, léger) à la SVM, qui se présentera comme suit : /dev/sdj. Désormais, lorsque le nouvel appareil SDS réel est ajouté, il se présente sous la forme /dev/sdk, qui est gratuit à la fois sur le chemin actuel et sur le chemin d’origine, et réussira.

Versions affectées

V2.0.0.3 et versions ultérieures

Corrigé dans la version

v3.0