Manuelles binden von iSCSI an zusätzliche IP-Adresse

Hallo zusammen,

ich habe an meiner TS-453Be 3 Netzwerkschnittstellen, 2x die verbauten 1GBe und 1x 10GBe über eine zusätzliche QNAP-Karte. Alle Karten haben eine virtuelle Switch. Auf die virtuelle Switch der 10GBe Karte habe ich mittels ifconfig qvs0:2 192.168.4.100 netmask 255.255.255.0 up eine zusätzliche IP-Adresse gebunden. Leider ist auf dieser IP der iSCSI-Dienst der QNAP nicht aktiv, ich werde diesem also manuell die IP-Adresse zuweisen müssen. Wie kann ich das machen? (Grundsätzlich funktioniert die Zuweisung der IP erst einmal, die IP lässt sich vom ESXi aus anpingen).

Hintergrund:

Ich habe derzeit meinen ESXi-Server mittels iSCSI auf die 2 1GBe Karten gebunden, das funktioniert soweit auch erst einmal gut. Da der ESXi aber noch einen Netzwerkanschluss frei hat, würde ich gerne diesen (über eine zusätzliche IP und NICHT über das Standardnetz) auf die 3te Netzwerkkarte der QNAP binden. Und bevor jemand fragt: Der ESXi hat insg. 10 Netzwerkanschlüsse, 2 OnBoard und 2x 4x1GBe Steckkarten. Jeder "aktive" Anschluss hat also jeweils noch 1 Fallback - was für den aktuellen Fall aber grundsätzlich erst einmal nicht relevant ist, da dies den ESXi und nicht die QNAP betrifft.

Lieben Gruß,

Lauri

Hy,

das Problem ist, dass die manuell hinzugefügten IP-Adressen in der Oberfläche garnicht auftauchen, sondern nur die "primären" der Hardwareschnittstellen. Rein theoretisch könnte ich natürlich die primäre Adresse nehmen, aber das möchte ich halt nicht - der iSCSI-Traffic soll komplett über eigene Subnetze laufen. (Man sieht also auch in den virtuellen Switches nicht die hinzugefügten IP-Adressen sondern nur die "Haupt-IP" die direkt auf der Hardwareschnittstelle liegt).

Lieben Gruß,

Lauri

Kein Ding - das was ich da vorhabe ist ja auch sicherlich nicht alltäglich und dass ich da auf der CLI (und vermutlich auch in Configfiles) rumbasteln muss, ist mir völlig klar. Da ich mich aber mit Linux (und vor allem mit dem abgespeckten in der QNAP) nicht ausreichend auskenne, bin ich mal gespannt, was die Linux-Gurus hier dazu beitragen können. Wäre ja gelacht, wenn man das nicht zum laufen bekommt...

Gruß,

Lauri

Also,

LAG ist bei den beiden GBit-Links nicht notwendig, das macht VMWare selbst. Sprich, selbst wenn man testweise "nur" die 2 GBit Links der QNAP direkt mit dem ESXi verbindet und entsprechend auf dem ESXi das korrekte Protokoll einrichtet (in meinem Fall VMW_PSP_RR in der default pathing policy für QNAP-iSCSI Storage Array Type VMW_SATP_ALUA) , hab ich auf den Guest-Maschinen mit CrystalDiskMark6 ~200MB/sec auf die Storage - das funktioniert also prima. Die Idee war jetzt, eine zusätzliche IP auf den 10GBe-Link zu legen und seitens des ESXi eine weiteres vmk einzurichten das sich dann auf diese IP verbindet - um auf ~280MB/sec zu kommen. Wie gesagt, das Thema dabei ist, dass sich zwar weitere IPs problemlos auf den Port legen lassen, aber der iSCSI-Deamon sich per default nur auf die jeweils 1te IP der Netzwerkkarten bindet. Das liegt evtl. auch daran, dass die weitere IP erst nach dem Start des iSCSI-Deamon aktiv wird - ich hab das in der autorun.sh drin. Allerdings bringt auch ein Neustart des iSCSI-Deamon genau garnichts. Testweise habe ich mal eine Verbindung auf die primäre IP der 10GBe hinzugefügt und komme, wie von mir gewünscht, auch auf die ~280MB/sec in den Guest-Systemen - meine grundsätzliche Idee funktioniert also. Ich möchte das aber, aus diversen Gründen, nicht auf der primären, sondern einer weiteren IP laufen lassen und genau dort liegt dann der Hase im Pfeffer. VLan etc. wird alles eingerichtet, sobald die grundlegende Einrichtung fertig ist - dafür fehlt mir im Moment schlicht noch der funktionierende Link auf die 2te IP der 10GBe Netzwerkkarte auf der QNAP.

Vielleicht noch als Zusatzinfo:

Testweise hab ich einfach mal einem Rechner eine IP aus dem Subnetz der 2ten IP auf der Karte gegeben und versucht, mich per iSCSI auf die 2te IP zu verbinden - das schlägt fehl, weil er das iSCSI-Target nicht findet. Es liegt also tatsächlich an der Bindung des iSCSI-Deamons (oder an etwas ganz anderem was mir grade so absolut nicht einfallen will).

Gruß,

Lauri

Neue Erkenntnisse: Es wird absurd!

Ich habe, egal was ich auch mache, noch keine Möglichkeit gefunden, der QNAP beim booten beizubringen, iSCSI auf die virtuellen Schnittstellen zu binden. Ich habe aber eine Möglichkeit gefunden, wie sie es nachträglich macht:

Sobald ich einen virtuellen Switch hinzufüge oder entferne (eine Änderung reicht nicht aus), wird der iSCSI-Deamon auch auf die virtuellen Schnittstellen gebunden! Das bedeutet, sobald sich die Liste der virtuellen Switches ändert, ändert sich scheinbar die Art, wie das Netzwerk neu gestartet wird.

Nach dem booten:

[~] # netstat -tulpn | grep :3260
tcp        0      0 192.168.3.100:3260      0.0.0.0:*               LISTEN      -
tcp        0      0 192.168.2.100:3260      0.0.0.0:*               LISTEN      -
tcp        0      0 192.168.0.100:3260      0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:3260          0.0.0.0:*               LISTEN      -
[~] #

Nachdem ich einen virtuellen Switch (ohne Netzwerkarte) hinzugefügt habe:

[~] # netstat -tulpn | grep :3260
tcp        0      0 192.168.4.100:3260      0.0.0.0:*               LISTEN      -
tcp        0      0 192.168.1.100:3260      0.0.0.0:*               LISTEN      -
tcp        0      0 192.168.3.100:3260      0.0.0.0:*               LISTEN      -
tcp        0      0 192.168.2.100:3260      0.0.0.0:*               LISTEN      -
tcp        0      0 192.168.0.100:3260      0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:3260          0.0.0.0:*               LISTEN      -
[~] #

Man beachte dabei, nach hinzufügen des virtuellen Switches, wird sowohl die IP des virtuellen Switches (192.168.1.100) als auch die IP des virtuellen Interfaces qvs0:2 (192.168.4.100) an iSCSI gebunden. Also exakt DAS was ich haben will. Ich würde mich sehr freuen, wenn sich die QNAP-Profis ( dr_mike zuzwinker ) das mal anschauen könnten - denn wenn ich diesen Neustart des Netzwerks per Befehl hinbekomme, dann könnte ich das auch in der autorun.sh machen und wäre exakt da, wo ich hin will. Übrigens, wenn ich den virtuellen Switch wieder entferne, dann fehlt lediglich die 192.168.1.100, die Bindung ans Interface 192.168.4.100 bleibt bestehen. Von "das geht nicht" bin ich jetzt bei "es geht, aber auf komische Art und Weise" angekommen - glorreich wäre jetzt echt das Ergebnis "es geht auch ohne manuellen Eingriff über die Oberfläche".

Und ja, das ganze funktioniert natürlich auch:

pasted-from-clipboard.png

Danke und Gruß,

Lauri

RedDiabolo hat die Lösung gefunden: ein einfaches /etc/rcS.d/S45network restart am Ende der autorun.sh hat das gewünschte Ergebnis gebracht - der iSCSI-Deamon ist jetzt bootsicher an die virtuellen Schnittstellen gebunden!