한 달 전부터 iscsi 오류와 마운트 실패가 발생하기 시작했습니다. 이는 20.04.3 업데이트와 거의 일치합니다. 추격을 시도하면서 다음 명령을 내렸습니다.
root@cor8910:~# iscsiadm -m discovery -t sendtargets -p Readynas2 172.16.7.2:3260,1 iqn.2011-09.nas-8B-3E-60:thunderbird 172.16.7.2:3260,1 iqn.2011-09 .nas-8B-3E-60:vmguests
root@cor8910:~# iscsiadm -m discovery -t sendtargets -p Readynas1 172.16.0.2:3260,1 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5
위 출력은 정확합니다. 그러나 iscsiadm -m node -o show를 실행하면 BEGIN RECORD 2.0-874의 4개 레코드가 표시됩니다.
node.name = iqn.2011-09.nas-8B-3E-60:thunderbird . . . node.conn[0].address = 172.16.7.2 node.conn[0].port = 3260
#end 레코드 #Begin 레코드 2.0-874 node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . node.conn[0].address = ReadyNAS1 #END RECORD 연결 주소가 ReadyNAS2가 1이 아니기 때문에 BAD이며 점으로 구분된 십진수여야 합니다. BEGIN RECORD 2.0-874
node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . . node.conn[0].address = 172.16.7.2< br/> node.conn[0].port = 3260
#END RECORD 이것은 정확하지만 주소가 점으로 구분된 십진수인 이유와 이전 호스트가 동의어인 이유는 무엇입니까? 기록 시작 2.0-874
node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = 172.16.0.2 기록 종료 기록 시작 2.0-874
node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = Readynas1 #end Record 마지막 것도 괜찮습니다. 내가 검색한 잘못된 노드 레코드 문서를 제거할 수 없습니다. 우분투에는 없는 /var/lib/iscsi가 표시됩니다.
root@cor8910:~# ls -al /etc/iscsi/nodes/ 총 20
drw------- 4 루트 루트 4096 10월 9일 15:31 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 drw------ 3 루트 루트 4096 10월 9일 15: 31 iqn.2011-09.nas-8B-3E-60:thunderbird
drw------- 4 루트 루트 4096 10월 9일 15:31 iqn.2011-09.nas-8B-3E-60:vmguests
문제는 더 안전한 곳으로 옮긴 defaults 하위 폴더에 있었던 것 같습니다. 그러나 Thunderbird 폴더는 여전히 fstab을 통해 로그인 및 마운트되지 않습니다. 다른 사람들은 그렇습니다. 부팅되면 iscsiadm을 실행하여 모두 로그인하고 Thunderbird 프로필이 가리키는 Thunderbird LUN을 수동으로 마운트할 수 있습니다.
잘못된 것이 무엇이든 수정할 수 있기를 원하지만 무엇이 잘못되었는지 발견하지 못한 상태에서 open-iscsi를 제거하고 다시 설치하면 문제가 해결됩니까? 'readyNAS2' Netgear의 ultra 4 NAS 장치의 경우 'readyNAS1' Netgear의 214 NAS가 주소에 대한 호스트 파일 동의어를 선택하는 점분리 십진수로 참조하도록 구성에서 어떻게 알 수 있습니까?
장단점을 고려한 후 iscsiadm을 제거하고 다시 설치했습니다. 이것은 실제로 잘 작동했고 정적 대상이 발견되었으며 로그인이 빠르게 진행되었습니다. 그러나 재부팅하고 다시 설치한 후 문제가 다시 발생했으며 시작 시 정적 노드를 잘못 생성하는 무언가가 있음을 발견했습니다. man iscsiadm에 따르면 유일한 검색 유형은 sendtarget, isns입니다. 정적은 없지만 빌드하고 사용하고 실패한 것으로 보입니다.
답변1
분명히 open-iscsi는 어떤 명령이 실행되고 어떤 순서로 실행되는지에 매우 민감합니다. 이를 파악하는 열쇠는 테스트할 '버진' 환경을 확보하는 것입니다. 저는 최신 20.04.3 iso의 VM을 생성하고 계속 진행했습니다. open-iscsi를 구성합니다. /etc/hostsVM에 재정의된 파일이 없었기 때문에 점으로 구분된 십진수 주소에 대한 동의어가 없었습니다. 나는 이것이 문제의 일부일지도 모른다고 생각합니다.
위에 설명된 일련의 명령을 시도했지만 소용이 없었습니다. 그것은 실패하지도 않았고, 시도조차 하지 않았습니다. 그런 다음이 URL에서 일어났습니다. 천천히 주의 깊게 읽고 꼼꼼하게 따라하는 것이 중요합니다.https://www.hiroom2.com/2018/05/05/ubuntu-1804-open-iscsi-en/이것은 18.04용으로 작성되었지만 VM에서는 완벽하게 작동했습니다. 나는 그 결과를 내 '프로덕션' 데스크톱에서 동일한 결과로 재현했습니다.
지시 순서에 특별한 주의를 기울이십시오.
node.startup을 자동으로 변경하기 전에 iSCSI 대상에 연결한 경우, node.startup을 자동으로 변경한 후 다시 iSCSI 대상에 연결해야 합니다.