Seit etwa einem Monat treten bei mir iscsi-Fehler und Mount-Fehler auf. Dies geschah ungefähr zeitgleich mit dem Update 20.04.3. Um es kurz zu machen, habe ich die folgenden Befehle eingegeben:
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
Die obige Ausgabe ist korrekt. Wenn ich jedoch iscsiadm -m node -o show abgebe, erhalte ich 4 Datensätze BEGIN RECORD 2.0-874
Knoten.Name = iqn.2011-09.nas-8B-3E-60:Thunderbird . . . Knoten.conn[0].Adresse = 172.16.7.2 Knoten.conn[0].Port = 3260
#Datensatzende #Datensatzbeginn 2.0-874 node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . node.conn[0].address = readyNAS1 #Datensatzende Das ist FEHLER, da die Verbindungsadresse readyNAS2 und nicht 1 ist und in Dezimalzahlen mit Punkten angegeben werden sollte. Datensatzbeginn 2.0-874
node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . . node.conn[0].adresse = 172.16.7.2< br/> node.conn[0].port = 3260
#END RECORD Das ist richtig, aber warum ist die Adresse mit Punkten versehen und warum war der vorherige Host gleichbedeutend? BEGIN RECORD 2.0-874
node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = 172.16.0.2 ENDE DES DATENSATZES BEGINNT DES DATENSATZES 2.0-874
node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = readynas1 #end record Das letzte ist auch in Ordnung. Ich werde diesen fehlerhaften Node-Record nicht los. Das Dokument, das ich gegoogelt habe, weist auf ein /var/lib/iscsi hin, das Ubuntu nicht hat.
root@cor8910:~# ls -al /etc/iscsi/nodes/ insgesamt 20
drw------- 4 root root 4096 9. Okt. 15:31 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 drw------- 3 root root 4096 9. Okt. 15:31 iqn.2011-09.nas-8B-3E-60:thunderbird
drw------- 4 root root 4096 9. Okt. 15:31 iqn.2011-09.nas-8B-3E-60:vmguests
Ich denke, das Problem könnte im Unterordner „Defaults“ liegen, den ich an einen sichereren Ort verschoben habe. Der Thunderbird-Ordner wird jedoch immer noch nicht über fstab angemeldet und gemountet. Die anderen schon. Nach dem Booten kann ich ein iscsiadm ausführen, um mich bei allen anzumelden und den Thunderbird-LUN manuell dort zu mounten, wo das Thunderbird-Profil darauf verweist.
Ich würde gerne in der Lage sein, alle Fehler zu korrigieren, aber wenn ich nicht herausfinde, was falsch ist, würde das Problem gelöst, wenn ich open-iSCSI lösche und neu installiere? Woher weiß die Konfiguration, dass im Fall von „readyNAS2“ Netgears Ultra 4 NAS-Einheit mit Dezimalpunkten darauf verwiesen werden muss, während „readyNAS1“ Netgears 214 NAS das Host-Dateisynonym für seine Adresse aufnimmt?
Nachdem ich die Vor- und Nachteile abgewogen hatte, habe ich iscsiadm gelöscht und neu installiert. Das hat tatsächlich gut funktioniert, statische Ziele wurden gefunden und die Anmeldung ging schnell vonstatten. Nach dem Neustart nach der Neuinstallation trat das Problem jedoch erneut auf und ich stellte fest, dass beim Start etwas die statischen Knoten falsch erstellt. Laut man iscsiadm ist die einzige Erkennungsart sendtarget, isns. KEIN STATISCH, aber es scheint zu erstellen und zu verwenden und zu scheitern.
Antwort1
Offenbar reagiert open-iscsi sehr empfindlich auf die Befehle und deren Reihenfolge. Der Schlüssel zur Lösung dieses Problems ist eine „jungfräuliche“ Testumgebung. Ich habe eine VM mit dem neuesten ISO 20.04.3 erstellt und mit der Konfiguration von open-iscsi begonnen. Da ich /etc/hostsin der VM keine neu definierte Datei hatte, gab es keine Synonyme für Adressen mit Dezimalpunkten. Ich denke, das könnte ein Teil des Problems gewesen sein.
Ich habe die oben dargestellte Befehlsfolge vergeblich ausprobiert. Es ist nicht fehlgeschlagen, es hat nicht einmal versucht. Dann bin ich zufällig auf diese URL gestoßen. Es ist wichtig, sie langsam und sorgfältig zu lesen und ihr genau zu folgen.https://www.hiroom2.com/2018/05/05/ubuntu-1804-open-iscsi-en/Obwohl dies für 18.04 geschrieben wurde, funktionierte es in der VM perfekt. Ich habe diese Ergebnisse auf meinem „Produktions“-Desktop mit identischen Ergebnissen reproduziert.
Achten Sie bei der Anweisungsfolge besonders darauf,
Wenn Sie vor der Änderung von node.startup auf automatisch eine Verbindung zum iSCSI-Ziel hergestellt haben, müssen Sie nach der Änderung von node.startup auf automatisch erneut eine Verbindung zum iSCSI-Ziel herstellen.