Déplacez les hôtes iSCSI Linux vers de nouveaux nœuds
Avant de déplacer des volumes SAN iSCSI vers de nouveaux nœuds, vous devez créer de nouvelles connexions iSCSI et renumériser les chemins iSCSI vers les nouveaux nœuds.
Si vous n'avez pas besoin de déplacer des volumes SAN iSCSI lors de la mise à niveau en déplaçant des volumes, vous pouvez ignorer cette procédure et passer à l' "Création d'un agrégat et déplacement des volumes vers les nouveaux nœuds".
-
Les interfaces IPv4 sont créées lors de la configuration des nouvelles connexions iSCSI.
-
Les commandes hôtes et les exemples sont spécifiques aux systèmes d'exploitation Linux.
Étape 1 : configuration de nouvelles connexions iSCSI
Pour déplacer les connexions iSCSI, vous devez configurer de nouvelles connexions iSCSI sur les nouveaux nœuds.
-
Créez des interfaces iSCSI sur les nouveaux nœuds et vérifiez la connectivité ping entre les hôtes iSCSI et les nouvelles interfaces sur les nouveaux nœuds.
Toutes les interfaces iSCSI depuis le SVM doivent être accessibles par l'hôte iSCSI.
-
Sur l'hôte iSCSI, identifiez les connexions iSCSI existantes entre l'hôte et l'ancien nœud :
iscsiadm -m session
[root@scspr1789621001 ~]# iscsiadm -m session tcp: [1] 10.230.68.236:3260,1156 iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6 (non-flash) tcp: [2] 10.230.68.237:3260,1158 iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6 (non-flash)
-
Sur le nouveau nœud, vérifiez les connexions à partir du nouveau nœud :
iscsi session show -vserver <svm-name>
node_A_1-new::*> iscsi session show -vserver vsa_1 Tpgroup Initiator Initiator Vserver Name TSIH Name ISID Alias --------- ------- ---- ------------------------ --------- --------------------- vsa_1 iscsi_lf__n1_p1_ 4 iqn.2020-01.com.netapp.englab.gdl:scspr1789621001 00:02:3d:00:00:01 scspr1789621001.gdl.englab.netapp.com vsa_1 iscsi_lf__n2_p1_ 4 iqn.2020-01.com.netapp.englab.gdl:scspr1789621001 00:02:3d:00:00:02 scspr1789621001.gdl.englab.netapp.com 2 entries were displayed.
-
Sur le nouveau nœud, lister les interfaces iSCSI en ONTAP pour les SVM contenant les interfaces :
iscsi interface show -vserver <svm-name>
sti8200mcchtp001htp_siteA::*> iscsi interface show -vserver vsa_1 Logical Status Curr Curr Vserver Interface TPGT Admin/Oper IP Address Node Port Enabled ------- ---------- ---- ---------- --------------- ----------- ---- ------- vsa_1 iscsi_lf__n1_p1_ 1156 up/up 10.230.68.236 sti8200mcc-htp-001 e0g true vsa_1 iscsi_lf__n1_p2_ 1157 up/up fd20:8b1e:b255:805e::78c9 sti8200mcc-htp-001 e0h true vsa_1 iscsi_lf__n2_p1_ 1158 up/up 10.230.68.237 sti8200mcc-htp-002 e0g true vsa_1 iscsi_lf__n2_p2_ 1159 up/up fd20:8b1e:b255:805e::78ca sti8200mcc-htp-002 e0h true vsa_1 iscsi_lf__n3_p1_ 1183 up/up 10.226.43.134 sti8200mccip-htp-005 e0c true vsa_1 iscsi_lf__n4_p1_ 1188 up/up 10.226.43.142 sti8200mccip-htp-006 e0c true 6 entries were displayed.
-
Sur l'hôte iSCSI, lancer la détection sur l'une des adresses IP iSCSI du SVM pour découvrir les nouvelles cibles :
iscsiadm -m discovery -t sendtargets -p iscsi-ip-address
La détection peut être exécutée sur n'importe quelle adresse IP du SVM, y compris sur des interfaces non iSCSI.
[root@scspr1789621001 ~]# iscsiadm -m discovery -t sendtargets -p 10.230.68.236:3260 10.230.68.236:3260,1156 iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6 10.226.43.142:3260,1188 iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6 10.226.43.134:3260,1183 iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6 10.230.68.237:3260,1158 iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6
-
Sur l'hôte iSCSI, connectez-vous à toutes les adresses découvertes :
iscsiadm -m node -L all -T node-address -p portal-address -l
[root@scspr1789621001 ~]# iscsiadm -m node -L all -T iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6 -p 10.230.68.236:3260 -l Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6, portal: 10.226.43.142,3260] (multiple) Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6, portal: 10.226.43.134,3260] (multiple) Login to [iface: default, target: iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6, portal: 10.226.43.142,3260] successful. Login to [iface: default, target: iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6, portal: 10.226.43.134,3260] successful.
-
Sur l'hôte iSCSI, vérifiez la connexion et les connexions :
iscsiadm -m session
[root@scspr1789621001 ~]# iscsiadm -m session tcp: [1] 10.230.68.236:3260,1156 iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6 (non-flash) tcp: [2] 10.230.68.237:3260,1158 iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6 (non-flash) tcp: [3] 10.226.43.142:3260,1188 iqn.1992-08.com.netapp:sn.58d7f6df2cc611eaa9c500a098a71638:vs.6 (non-flash)
-
Sur le nouveau nœud, vérifiez la connexion et la connexion avec l'hôte :
iscsi initiator show -vserver <svm-name>
sti8200mcchtp001htp_siteA::*> iscsi initiator show -vserver vsa_1 Tpgroup Initiator Vserver Name TSIH Name ISID Igroup Name ------- -------- ---- --------------------- ----------------- ----------------- vsa_1 iscsi_lf__n1_p1_ 4 iqn.2020-01.com.netapp.englab.gdl:scspr1789621001 00:02:3d:00:00:01 igroup_linux vsa_1 iscsi_lf__n2_p1_ 4 iqn.2020-01.com.netapp.englab.gdl:scspr1789621001 00:02:3d:00:00:02 igroup_linux vsa_1 iscsi_lf__n3_p1_ 1 iqn.2020-01.com.netapp.englab.gdl:scspr1789621001 00:02:3d:00:00:04 igroup_linux vsa_1 iscsi_lf__n4_p1_ 1 iqn.2020-01.com.netapp.englab.gdl:scspr1789621001 00:02:3d:00:00:03 igroup_linux 4 entries were displayed.
À la fin de cette tâche, l'hôte peut voir toutes les interfaces iSCSI (sur les anciens et nouveaux nœuds) et est connecté à toutes ces interfaces.
Les LUN et les volumes sont toujours hébergés physiquement sur les anciens nœuds. Les LUN étant signalées uniquement sur les anciennes interfaces de nœud, l'hôte n'affiche que les chemins sur les anciens nœuds. Pour voir ceci, exécutez le sanlun lun show -p
et multipath -ll -d
sur l'hôte et examiner les sorties de la commande.
[root@scspr1789621001 ~]# sanlun lun show -p ONTAP Path: vsa_1:/vol/vsa_1_vol6/lun_linux_12 LUN: 4 LUN Size: 2g Product: cDOT Host Device: 3600a098038304646513f4f674e52774b Multipath Policy: service-time 0 Multipath Provider: Native --------- ---------- ------- ------------ ------------------- host vserver path path /dev/ host vserver state type node adapter LIF --------- ---------- ------- ------------ ------------------- up primary sdk host3 iscsi_lf__n2_p1_ up secondary sdh host2 iscsi_lf__n1_p1_ [root@scspr1789621001 ~]# multipath -ll -d 3600a098038304646513f4f674e52774b dm-5 NETAPP ,LUN C-Mode size=2.0G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw |-+- policy='service-time 0' prio=50 status=active | `- 3:0:0:4 sdk 8:160 active ready running `-+- policy='service-time 0' prio=10 status=enabled `- 2:0:0:4 sdh 8:112 active ready running
Étape 2 : ajoutez les nouveaux nœuds en tant que nœuds de reporting
Après avoir configuré les connexions aux nouveaux nœuds, vous ajoutez les nouveaux nœuds en tant que nœuds de reporting.
-
Sur le nouveau nœud, lister les nœuds reporting pour les LUN sur le SVM :
lun mapping show -vserver <svm-name> -fields reporting-nodes -ostype linux
Les nœuds de reporting suivants sont des nœuds locaux car les LUN sont physiquement sur les anciens nœuds node_A_1-Old et node_A_2-Old.
node_A_1-new::*> lun mapping show -vserver vsa_1 -fields reporting-nodes -ostype linux vserver path igroup reporting-nodes ------- ---------------------------- ------------ --------------------------- vsa_1 /vol/vsa_1_vol1/lun_linux_2 igroup_linux node_A_1-old,node_A_2-old . . . vsa_1 /vol/vsa_1_vol9/lun_linux_19 igroup_linux node_A_1-old,node_A_2-old 12 entries were displayed.
-
Sur le nouveau nœud, ajoutez des nœuds de reporting :
lun mapping add-reporting-nodes -vserver <svm-name> -path /vol/vsa_1_vol*/lun_linux_* -nodes node1,node2 -igroup <igroup_name>
node_A_1-new::*> lun mapping add-reporting-nodes -vserver vsa_1 -path /vol/vsa_1_vol*/lun_linux_* -nodes node_A_1-new,node_A_2-new -igroup igroup_linux 12 entries were acted on.
-
Sur le nouveau nœud, vérifiez que les nouveaux nœuds ajoutés sont présents :
lun mapping show -vserver <svm-name> -fields reporting-nodes -ostype linux vserver path igroup reporting-nodes
node_A_1-new::*> lun mapping show -vserver vsa_1 -fields reporting-nodes -ostype linux vserver path igroup reporting-nodes ------- --------------------------- ------------ ------------------------------------------------------------------------------- vsa_1 /vol/vsa_1_vol1/lun_linux_2 igroup_linux node_A_1-old,node_A_2-old,node_A_1-new,node_A_2-new vsa_1 /vol/vsa_1_vol1/lun_linux_3 igroup_linux node_A_1-old,node_A_2-old,node_A_1-new,node_A_2-new . . . 12 entries were displayed.
-
Le
sg3-utils
Le package doit être installé sur l'hôte Linux. Ceci empêche unrescan-scsi-bus.sh utility not found
Erreur lors de la nouvelle analyse de l'hôte Linux pour les LUN nouvellement mappées à l'aide durescan-scsi-bus
commande.Sur l'hôte, vérifiez que
sg3-utils
le package est installé :-
Pour une distribution Debian :
dpkg -l | grep sg3-utils
-
Pour une distribution basée sur Red Hat :
rpm -qa | grep sg3-utils
Si nécessaire, installer le
sg3-utils
Package sur l'hôte Linux :sudo apt-get install sg3-utils
-
-
Sur l'hôte, lancez une nouvelle analyse du bus SCSI sur l'hôte et découvrez les nouveaux chemins ajoutés :
/usr/bin/rescan-scsi-bus.sh -a
[root@stemgr]# /usr/bin/rescan-scsi-bus.sh -a Scanning SCSI subsystem for new devices Scanning host 0 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 1 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 2 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 2 0 0 0 ... . . . OLD: Host: scsi5 Channel: 00 Id: 00 Lun: 09 Vendor: NETAPP Model: LUN C-Mode Rev: 9800 Type: Direct-Access ANSI SCSI revision: 05 0 new or changed device(s) found. 0 remapped or resized device(s) found. 0 device(s) removed.
-
Sur l'hôte iSCSI, répertoriez les nouveaux chemins ajoutés :
sanlun lun show -p
Quatre chemins sont affichés pour chaque LUN.
[root@stemgr]# sanlun lun show -p ONTAP Path: vsa_1:/vol/vsa_1_vol6/lun_linux_12 LUN: 4 LUN Size: 2g Product: cDOT Host Device: 3600a098038304646513f4f674e52774b Multipath Policy: service-time 0 Multipath Provider: Native ------- ---------- ------- ----------- --------------------- host vserver path path /dev/ host vserver state type node adapter LIF ------ ---------- ------- ----------- --------------------- up primary sdk host3 iscsi_lf__n2_p1_ up secondary sdh host2 iscsi_lf__n1_p1_ up secondary sdag host4 iscsi_lf__n4_p1_ up secondary sdah host5 iscsi_lf__n3_p1_
-
Sur le nouveau nœud, déplacez les volumes contenant des LUN des anciens nœuds vers les nouveaux nœuds.
node_A_1-new::*> vol move start -vserver vsa_1 -volume vsa_1_vol1 -destination-aggregate sti8200mccip_htp_005_aggr1 [Job 1877] Job is queued: Move "vsa_1_vol1" in Vserver "vsa_1" to aggregate "sti8200mccip_htp_005_aggr1". Use the "volume move show -vserver vsa_1 -volume vsa_1_vol1" command to view the status of this operation. node_A_1-new::*> vol move show Vserver Volume State Move Phase Percent-Complete Time-To-Complete -------- ---------- -------- ---------- ---------------- ---------------- ---------------- vsa_1 vsa_1_vol1 healthy initializing - -
-
Une fois le déplacement du volume vers les nouveaux nœuds terminé, vérifier que le volume est en ligne :
volume show -state
-
Les interfaces iSCSI des nouveaux nœuds sur lesquels réside désormais la LUN sont mises à jour en tant que chemins principaux. Si le chemin principal n'est pas mis à jour après le déplacement du volume, exécutez
/usr/bin/rescan-scsi-bus.sh -a
etmultipath -v3
sur l'hôte ou attendez simplement que la nouvelle analyse des chemins d'accès multiples ait lieu.Dans l'exemple suivant, le chemin primaire est une LIF sur le nouveau nœud.
[root@stemgr]# sanlun lun show -p ONTAP Path: vsa_1:/vol/vsa_1_vol6/lun_linux_12 LUN: 4 LUN Size: 2g Product: cDOT Host Device: 3600a098038304646513f4f674e52774b Multipath Policy: service-time 0 Multipath Provider: Native --------- ---------- ------- ------------ ----------------------- host vserver path path /dev/ host vserver state type node adapter LIF --------- ---------- ------- ------------ ------------------------ up primary sdag host4 iscsi_lf__n4_p1_ up secondary sdk host3 iscsi_lf__n2_p1_ up secondary sdh host2 iscsi_lf__n1_p1_ up secondary sdah host5 iscsi_lf__n3_p1_
Étape 3 : supprimer les nœuds de rapport et les chemins de nouvelle analyse
Vous devez supprimer les nœuds de reporting et relancer la détection des chemins.
-
Sur le nouveau nœud, supprimez les nœuds de reporting distants (les nouveaux nœuds) des LUN Linux :
lun mapping remove-reporting-nodes -vserver <svm-name> -path * -igroup <igroup_name> -remote-nodes true
Dans ce cas, les nœuds distants sont d'anciens nœuds.
node_A_1-new::*> lun mapping remove-reporting-nodes -vserver vsa_1 -path * -igroup igroup_linux -remote-nodes true 12 entries were acted on.
-
Sur le nouveau nœud, vérifier les nœuds de reporting des LUN :
lun mapping show -vserver <svm-name> -fields reporting-nodes -ostype linux
node_A_1-new::*> lun mapping show -vserver vsa_1 -fields reporting-nodes -ostype linux vserver path igroup reporting-nodes ------- --------------------------- ------------ ------------------------- vsa_1 /vol/vsa_1_vol1/lun_linux_2 igroup_linux node_A_1-new,node_A_2-new vsa_1 /vol/vsa_1_vol1/lun_linux_3 igroup_linux node_A_1-new,node_A_2-new vsa_1 /vol/vsa_1_vol2/lun_linux_4 group_linux node_A_1-new,node_A_2-new . . . 12 entries were displayed.
-
Le
sg3-utils
Le package doit être installé sur l'hôte Linux. Ceci empêche unrescan-scsi-bus.sh utility not found
Erreur lors de la nouvelle analyse de l'hôte Linux pour les LUN nouvellement mappées à l'aide durescan-scsi-bus
commande.Sur l'hôte, vérifiez que
sg3-utils
le package est installé :-
Pour une distribution Debian :
dpkg -l | grep sg3-utils
-
Pour une distribution basée sur Red Hat :
rpm -qa | grep sg3-utils
Si nécessaire, installer le
sg3-utils
Package sur l'hôte Linux :sudo apt-get install sg3-utils
-
-
Sur l'hôte iSCSI, lancez une nouvelle analyse du bus SCSI :
/usr/bin/rescan-scsi-bus.sh -r
Les chemins qui sont supprimés sont les chemins des anciens nœuds.
[root@scspr1789621001 ~]# /usr/bin/rescan-scsi-bus.sh -r Syncing file systems Scanning SCSI subsystem for new devices and remove devices that have disappeared Scanning host 0 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 1 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 2 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs sg0 changed: LU not available (PQual 1) REM: Host: scsi2 Channel: 00 Id: 00 Lun: 00 DEL: Vendor: NETAPP Model: LUN C-Mode Rev: 9800 Type: Direct-Access ANSI SCSI revision: 05 sg2 changed: LU not available (PQual 1) . . . OLD: Host: scsi5 Channel: 00 Id: 00 Lun: 09 Vendor: NETAPP Model: LUN C-Mode Rev: 9800 Type: Direct-Access ANSI SCSI revision: 05 0 new or changed device(s) found. 0 remapped or resized device(s) found. 24 device(s) removed. [2:0:0:0] [2:0:0:1] . . .
-
Sur l'hôte iSCSI, vérifiez que seuls les chemins des nouveaux nœuds sont visibles :
sanlun lun show -p
multipath -ll -d