FC Target (SAN) unter Debian 8 / Jessie
FC Target (SAN) unter Debian 8 / Jessie
Hallo zusammen,
ich habe bereits eine Custom-NAS unter Jessie per Samba laufen im Netzwerk. Zwei neue Festplatten Arrays möchte ich aber aus Performancegründen wegen 1 Gbit/Ethernet Flaschenhals direkt über Fibre Channel laufen lassen.
Es handelt sich hierbei um eine Point-to-Point Verbindung mit 2x Qlogic 2460 4Gbit Karten, Hardware ist an beiden Endpunkten schon in Betrieb. Der Windowsrechner, der als Initiator dient, ist bereits fertig eingerichtet.
Welche Möglichkeiten gibt es derzeit bei Debian 8, FC Targets zu generieren, ist das mittlerweile schon "out of the box" möglich? Ich möchte direkt das Fibre Channel Protokoll benutzen, kein iSCSI. LIO/targetcli ist wohl bei Jessie aufgrund von Problemen rausgefallen, war bei Wheezy noch dabei. Mit SCST habe ich auch schon probiert, bekomme das aber nicht zum laufen.
[EDIT]
Mittlerweile ist es mir gelungen, die SCST Software unter Debian 8 zum Laufen zu bekommen. Die vordefinierten deb Packages die dort angeboten werden, sind nicht akutell und ließen sich nicht korrekt installieren. Kommen wahrscheinlich nicht mit dem neuen SystemD zurecht.
Habe daher kurzerhand selbst aus den Sourcen kompiliert, Version 3.1.0:
scst
scstadmin-tool
Am Kernel habe ich bisher nichts herumgepatcht, scheint auch so zu laufen, da die Qlogic FC-Karte erkannt wird und im Debian 8 bereits Treiber integriert sind. Das einzige was jetzt noch fehlt ist eine passende config File ( /etc/scst.conf ), die man sich mit dem scstadmin Tool generieren lassen kann.
[/EDIT]
ich habe bereits eine Custom-NAS unter Jessie per Samba laufen im Netzwerk. Zwei neue Festplatten Arrays möchte ich aber aus Performancegründen wegen 1 Gbit/Ethernet Flaschenhals direkt über Fibre Channel laufen lassen.
Es handelt sich hierbei um eine Point-to-Point Verbindung mit 2x Qlogic 2460 4Gbit Karten, Hardware ist an beiden Endpunkten schon in Betrieb. Der Windowsrechner, der als Initiator dient, ist bereits fertig eingerichtet.
Welche Möglichkeiten gibt es derzeit bei Debian 8, FC Targets zu generieren, ist das mittlerweile schon "out of the box" möglich? Ich möchte direkt das Fibre Channel Protokoll benutzen, kein iSCSI. LIO/targetcli ist wohl bei Jessie aufgrund von Problemen rausgefallen, war bei Wheezy noch dabei. Mit SCST habe ich auch schon probiert, bekomme das aber nicht zum laufen.
[EDIT]
Mittlerweile ist es mir gelungen, die SCST Software unter Debian 8 zum Laufen zu bekommen. Die vordefinierten deb Packages die dort angeboten werden, sind nicht akutell und ließen sich nicht korrekt installieren. Kommen wahrscheinlich nicht mit dem neuen SystemD zurecht.
Habe daher kurzerhand selbst aus den Sourcen kompiliert, Version 3.1.0:
scst
scstadmin-tool
Am Kernel habe ich bisher nichts herumgepatcht, scheint auch so zu laufen, da die Qlogic FC-Karte erkannt wird und im Debian 8 bereits Treiber integriert sind. Das einzige was jetzt noch fehlt ist eine passende config File ( /etc/scst.conf ), die man sich mit dem scstadmin Tool generieren lassen kann.
[/EDIT]
Gelöst: FC Target (SAN) unter Debian 8 / Jessie
Gute Nachricht, ich konnte das mittlwerweile bei mir zum Laufen bringen. Jeder der ein Custom-NAS hat, sollte sich das eventuell mal überlegen. Die 4Gbit HBA´s gibts schon teilweise für unter 10 Euro + LWL Kabel für paar Euro.
Bin die Sache nochmal von vorne angegangen und habe mich anhand folgendem Tutorial orientiert, welches ich hier in angepasster Form nochmal wiedergeben möchte. Vorneweg sei gesagt, dass es obligatorisch ist, einen gepatchten Kernel zu erstellen.
http://thejimmahknows.com/linux-fibre-c ... sing-scst/
1. Firmware für Qlogic HBA 24xx besorgen
oder aus den "non-free" Debian Repo´s
2.Kerneleigenes Treibermodul qla2xxx auf die Blacklist
Da das im Kernel enthaltene Modul qla2xxx nur für den Initiatorbetrieb gedacht ist, muss es entfernt bzw. auf die Blacklist gesetzt werden.
Nach dem Reboot prüfen, ob das Modul noch geladen wird, wenn nicht ist alles ok.
3. Benötigte Pakete für Abhängigkeiten + Kernel Sources holen
Folgende Pakete nachinstallieren, falls noch nicht vorhanden
Kernel Sourcen ablegen in /tmp lt. Beispiel oder anderen Ordner nach Wahl
Bei meinem Jessie mit Kernel 3.16 hatte ich beim ersten Versuch Probleme, später die scst Software zu kompilieren. Habe daher akutell auf einen Kernel 4.4 aus den offziellen Kernel Archiven zurückgegriffen.
4. SCST Software über subversion laden
Anmerkung: Für die SCST Software besser einen anderen Ordner als tmp verwenden, sofern man die Leerung des tmp beim Boot aktiv hat.
5. Kernel patchen
Hier ist das verlinkte Tutorial leider schon etwas veraltet daher die aktuelle Vorgehensweise die ich ausgeführt habe
"Linux-x.x." stellvertretend ersetzen mit der jeweilig eingesetzten Kernelversion.
Bei Kerneln bis 3.19 kommt eventuell noch der folgende Patch zum Tragen, bei meinem 4.4 lief es ohne:
6. qla2x00t Treiber in den Quellen austauschen
Im neuen Kernel soll natürlich schon von Haus aus der korrekte Target Treiber integriert sein.
7. Kernel anpassen
Wie im geposteten Tutorial beschrieben sollte man folgende Kernelsettings prüfen und ggfg. einstellen:
9. SCST Software bauen
"2release" ist zu verwenden, da standardmäßig nur im Debugmodus kompiliert wird.
10. SCST Module
Die folgenden Module müssten sich dann erfolgreich per modprobe starten lassen. Bei Bedarf in den Systemstart einbinden.
12. SCST Config
Jetzt fehlt nur noch die Config Datei unter /etc/scst.conf
Entweder per scstadmin über diverse Kommandos zusammenbauen lassen
http://scst.sourceforge.net/qla2x00t-howto.html
oder selbst Hand anlegen
Hier als Beispiel meine Config für eine einzelne Partition auf meiner 2 TB Samsung Platte, man kann natürlich auch das gesamte Device
Als Target und Initiator Adresse muss der Port Name des jeweiligen Adapters eingetragen werden.
Nach dem Anlegen der Config reicht es folgenden Befehl abzusetzen:
Bin die Sache nochmal von vorne angegangen und habe mich anhand folgendem Tutorial orientiert, welches ich hier in angepasster Form nochmal wiedergeben möchte. Vorneweg sei gesagt, dass es obligatorisch ist, einen gepatchten Kernel zu erstellen.
http://thejimmahknows.com/linux-fibre-c ... sing-scst/
1. Firmware für Qlogic HBA 24xx besorgen
Code: Alles auswählen
wget http://ldriver.qlogic.com/firmware/ql2400_fw.bin
cp ql2400_fw.bin /lib/firmware/
Code: Alles auswählen
apt-get install firmware-qlogic
Da das im Kernel enthaltene Modul qla2xxx nur für den Initiatorbetrieb gedacht ist, muss es entfernt bzw. auf die Blacklist gesetzt werden.
Code: Alles auswählen
rmmod qla2xxx
echo blacklist qla2xxx >/etc/modprobe.d/blacklist-qla2xxx.conf
update-initramfs -u
reboot
Code: Alles auswählen
lsmod | grep ql*
Folgende Pakete nachinstallieren, falls noch nicht vorhanden
Code: Alles auswählen
apt-get install fakeroot kernel-wedge build-essential makedumpfile kernel-package libncurses5 libncurses5-dev gcc libncurses5-dev linux-headers-$(uname -r) lsscsi patch subversion
Code: Alles auswählen
mkdir /tmp/KernelSource
cd /tmp/KernelSource
apt-get source linux-source-3.x
ln -s linux-3.x.xx ../Linux
4. SCST Software über subversion laden
Code: Alles auswählen
cd /tmp/
svn co https://svn.code.sf.net/p/scst/svn/trunk scst
5. Kernel patchen
Hier ist das verlinkte Tutorial leider schon etwas veraltet daher die aktuelle Vorgehensweise die ich ausgeführt habe
Code: Alles auswählen
cd Linux
patch -p1 < {your_scst_source_directory}/scst/kernel/in-tree/Makefile.drivers.Linux-x.x.patch
Bei Kerneln bis 3.19 kommt eventuell noch der folgende Patch zum Tragen, bei meinem 4.4 lief es ohne:
Code: Alles auswählen
patch -p1 < {your_scst_source_directory}/scst/iscsi-scst/kernel/patches/put_page_callback-3.xx.patch
Im neuen Kernel soll natürlich schon von Haus aus der korrekte Target Treiber integriert sein.
Code: Alles auswählen
mv {your_kernel_source}/drivers/scsi/qla2xxx {your_kernel_source}/drivers/scsi/qla2xxx_orig
ln -s {your_scst_source}/scst/qla2x00t {your_kernel_source}/drivers/scsi/qla2xxx
Code: Alles auswählen
make menuconfig
8. Kernel bauen- Enable the block layer” –> “IO Schedulers” –> Default I/O scheduler -> CFQ
- Processor type and features” –> Preemption Model –> No Forced Preemption (Server)
- Device Drivers” –> “SCSI device support” –> “SCSI low level drivers” –> “Qlogic 2xxx target mode support” (Da sollte dann ein "NEW" dahinterstehen)
Code: Alles auswählen
export CONCURRENCY_LEVEL=5 //Quadcore Optimierung)
make-kpkg clean //Hier kann eine Fehlermeldung auftreten wegen dem Austausch des qla2xxx Treibers
fakeroot make-kpkg --initrd --append-to-version=-scst-enabled kernel-image kernel-headers //Nach eigenen Bedürfnissen anpassen
Code: Alles auswählen
cd {scst_source_directory}
make 2release
make all
BUILD_2X_MODULE=y CONFIG_SCSI_QLA_FC=y CONFIG_SCSI_QLA2XXX_TARGET=y make all install
10. SCST Module
Die folgenden Module müssten sich dann erfolgreich per modprobe starten lassen. Bei Bedarf in den Systemstart einbinden.
11. SCSTadmin bauenscst
qla2xxx_scst
qla2x00tgt
scst_vdisk
scst_user
scst_disk
Code: Alles auswählen
cd {your_scst_source}/scstadmin
make
make install
Jetzt fehlt nur noch die Config Datei unter /etc/scst.conf
Entweder per scstadmin über diverse Kommandos zusammenbauen lassen
http://scst.sourceforge.net/qla2x00t-howto.html
oder selbst Hand anlegen
Hier als Beispiel meine Config für eine einzelne Partition auf meiner 2 TB Samsung Platte, man kann natürlich auch das gesamte Device
Code: Alles auswählen
HANDLER vdisk_fileio {
DEVICE sm2000 {
filename /dev/sdc1
}
}
TARGET_DRIVER qla2x00t {
TARGET 50:01:00:00:00:00:00:00 {
HW_TARGET
enabled 1
rel_tgt_id 1
GROUP test {
LUN 0 sm2000
INIITATOR 52:98:00:00:00:00:00:00
}
}
Nach dem Anlegen der Config reicht es folgenden Befehl abzusetzen:
Code: Alles auswählen
scstadmin -conf /etc/scst.conf
Re: FC Target (SAN) unter Debian 8 / Jessie
Habe den Thread gerade erst entdeckt. Ich habe seit kurzem ein Ähnliches setup mit Qlogic HBAs am laufen.
Der Kernelpatch ist wohl nur nötig, wenn SCSI-passthrough benötigt wird (also device "raw" durchreichen) oder man Targets per iSCSI verfügbar macht. iSCSI über FC ist aber IMHO eher sinnfrei, da man den Overhead deutlich erhöht - das schöne an FC ist ja, dass die Hardware alles erledigt und die Targets direkt als SCSI-Geräte am Initiator genutzt werden können.
Am Target muss man das Kernelmodul qla2xxx aus dem firmware-qlogic Paket blacklisten - geladen werden sollen qla2x00tgt und qla2xxx_scst. Das Paket firmware-qlogic ist aber für die firmware (/lib/firmware/ql2400_fw.bin) nötig, ausser man kopiert die firmware manuell dort hin (und kümmert sich um aktualisierungen...).
Am Initiator reicht es das paket firmware-qlogic zu installieren und das qla2xxx Modul zu laden.
Die scst.conf ist relativ gut dokumentiert - sofern man den Grundaufbau/Grundkonfiguration begriffen hat, die ist nämlich nicht wirklich erklärt...
In einem ubuntu-tutorial zu SCST/FC wird eine config automatisch generiert - diese ist aber falsch und funktioniert nur fehlerhaft, da TARGET_DRIVER mehrfach definiert wird (hat mich 2 Nächte gekostet...), auch die manuelle Konfiguration per scstadmin und anschließendes dumpen der config ist IMHO etwas umständlich und zudem in besagtem Tutorial nicht wirklich erklärt - eben ubuntu-like "tippe 'sudo irgendwas' aber frag nicht was das macht..."
Hatte mich deshalb ein paar Stunden mit den Dokumentationen von RH befasst um erstmal den grundsätzlichen Aufbau der scst.conf rauszufiltern.
Ich versuche hier mal die Grundkonfiguration zu erklären (soweit ich sie begriffen habe ):
Für jeden SCST Device-Handler wird eine definition mit devices angelegt - also z.B. für disk, vdisk und fileio. Mit einem ZFS zvol schaut das dann so aus:
Nun wird für jeden TARGET_DRIVER ein Konfigurationsblock erstellt, in dem die Targets (=ports des HBA) konfiguriert und die zuvor in den Handlern definierten Devices an den Targets "freigegeben" werden. Der einfachste Fall für einen Port sieht dann so aus:
Die TARGET <WWN> definitionen werden für jeden Port wiederholt und können auch unterschiedliche Devices enthalten.
Will man LUNs nur an bestimmte Initiatoren freigeben oder z.b. über je einen Link ein anderes device verbinden, kann man das über GROUPS definieren:
"WWN1" ist hier die WWN des ersten Ports am Target-HBA, WWNA/B sind die WWNs der Ports an den Initiatoren. Für jeden weiteren Port/Initiator also entsprechend wiederholen/erweitern.
Um die konfiguration zu aktivieren NICHT den scst-dienst neu starten, sondern per "scstadmin -config /etc/scst.conf". Am initiator reicht dann ein rescan der/des scsi-host: "for i in /sys/class/scsi_host/host* ; do echo "- - -" > $i/scan ; done"
Danach sollten die LUNs sichtbar sein (lsblk).
So habe ich einen HBA mit 4 Ports am Target für 2 Initiatoren mit jeweils 2 Ports konfiguriert. Jeder Initiator kann an einen beliebigen Port angeschlossen werden, sieht aber nur "seine" targets. Einer der beiden soll später auch direkt per FC booten, so kann ich dem Testsystem (=Server im Rack) vorab eine Installation auf ein zvol bügeln und ihn dann mit nem vorbereiteten System booten und muss mich nicht mit Bildschirm, Tastatur und USB-Stick ans Rack stellen...
Nun noch zu multipath (das imho ziemlich unschön gelöst ist...)
Wenn man mehrere links zwischen Target und initiator hat, muss/sollte man multi-path nutzen, da der Initiator das Target über jeden Pfad einmal sieht - wird also ein device vom Target zur verfügung gestellt, sieht der Initiator dieses zwei mal - ein mal für jeden Link. Hängt ein FC-Switch dazwischen sind es sogar 4. Damit man diese als multipath-gerät nutzen kann muss man multipath-tools am initiator installieren und einrichten.
Mit den multipath-tools habe ich die letzten beiden Abende gekämpft - so wirklich zuversichtlich bin ich noch nicht, aber es funktioniert aktuell. Werde heute abend damit noch etwas testen ob das ganze setup auch wirklich mit dem ausfall eines links klarkommt...
Die einzelnen Pfade zu einer LUN werden vom Initiator als einzelne blockdevices "gesehen", z.B. sda und sdb
multipath verknüpft diese beiden und legt ZUSÄTZLICH noch mp-devices in /dev/mapper/ bzw als /dev/mpathN an. Man muss also vorsichtig sein, dass nicht irgendwo die pfade (/dev/sd[ab]) angesprochen werden, sondern nur noch das mp-device. Ansonsten verhält sich das aber ähnlich wie devices eines dm-raid, auch was die darstellung mit lsblk angeht:
Aus unerfindlichen Gründen wollte multipath bei mir immer nur meine beiden (völlig unterschiedlichen!) lokalen Platten konfigurieren - die FC LUNs haben ihn nicht interessiert. Die funktionierende Konfiguration sieht jetzt so aus:
Damit multipath sich nicht auch an Wechseldatenträgern, USB-Sticks usw vergreift wird pauschal alles auf die blacklist gesetzt und nur die wwid der FC-LUNs aus der blacklist ausgenommen.
Damit die dm-devices nicht mit ellenlanger wwid als namen angelegt werden, wird user_friendly_names gesetzt, so werden die MP-devices als /dev/mapper/<alias> im Dateisystem angelegt und können dort direkt als blockdevice angesprochen werden.
"vendor" und "product" für den abschnitt "devices" bekommt man per "cat /sys/block/sdX/device/vendor" bzw ".../device/model".
Device "test" sieht damit dann bei mir so aus:
Warum für die HW-Pfade nur #.#.#.# angegeben wird ist mir noch schleierhaft - immerhin stimmen die MAJ:MIN SCSI-Kennungen...
Performance ist mit mehreren Links auch etwas höher - hdparm -t gibt mir ca 360MB/s für das MP-device an, für ein einzelnes Target ca 240MB/s. Target ist wie schon gesagt ein zvol. Geht sicher auch noch schneller, habe aber noch nicht geschaut wo da noch der Flaschenhals ist, aber schneller als ne einzelne lokale Platte ist es sowieso schon
Schön dass sich hier noch jemand mit FC beschäftigt. Ich habe vor meine Notitzen und Schmierzettel zu dem ganzen Thema demnächst zusammenzutragen (blog, "tutorial", Wikiseite, Leidensbericht - KA was draus wird ). Wäre schön wenn man hier vll auch etwas mehr zusammentragen könnte, die Informationen zu dem Thema sind leider relativ knapp und oft veraltet und obsolet.
Update:
Zu dm-multipath hat redhat sehr gute Dokumentationen:
https://access.redhat.com/documentation ... index.html
Auch wenn sich vieles auf das RHEL-Tool "mpathconf" bezieht bekommt man so ziemlich alles mit was man für die manuelle konfiguration benötigt.
Mein Setup läuft mittlerweile stabil (=überlebt Neustarts), man muss allerdings peinlichst darauf aufpassen, dass die Dateisysteme auf den MP-Geräten erst NACH der initialisierung durch dm-multipath verwendet werden. Hatte auf einer LUN einen ZFS-pool eingerichtet und nach jedem neustart war multipath scheinbar wieder defekt - weil ZFS früher initialisiert und multipath kein Gerät anrührt das bereits aktiv ist. Die Fehlerausgabe von multipath ist dabei völlig wertlos - mehr als ein "map ignored" bekommt man auch mit -v3 nicht als Fehler.
Ich kann nun problemlos im laufenden Betrieb einen LWL ausstecken, der Transfer läuft über den verbleibenden link weiter und nach wiedereinstecken werden sofort wieder beide Pfade genutzt.
Jetzt muss ich "nur" noch das wackelige verhalten von SCST bei/nach pm-suspend in den griff bekommen (initialisiert nur einen Pfad oder teilweise überhaupt keine LUN) und den import des ZFS-pools verzögern, dann ist das ganze wirklich alltagstauglich
Der Kernelpatch ist wohl nur nötig, wenn SCSI-passthrough benötigt wird (also device "raw" durchreichen) oder man Targets per iSCSI verfügbar macht. iSCSI über FC ist aber IMHO eher sinnfrei, da man den Overhead deutlich erhöht - das schöne an FC ist ja, dass die Hardware alles erledigt und die Targets direkt als SCSI-Geräte am Initiator genutzt werden können.
Am Target muss man das Kernelmodul qla2xxx aus dem firmware-qlogic Paket blacklisten - geladen werden sollen qla2x00tgt und qla2xxx_scst. Das Paket firmware-qlogic ist aber für die firmware (/lib/firmware/ql2400_fw.bin) nötig, ausser man kopiert die firmware manuell dort hin (und kümmert sich um aktualisierungen...).
Am Initiator reicht es das paket firmware-qlogic zu installieren und das qla2xxx Modul zu laden.
Die scst.conf ist relativ gut dokumentiert - sofern man den Grundaufbau/Grundkonfiguration begriffen hat, die ist nämlich nicht wirklich erklärt...
In einem ubuntu-tutorial zu SCST/FC wird eine config automatisch generiert - diese ist aber falsch und funktioniert nur fehlerhaft, da TARGET_DRIVER mehrfach definiert wird (hat mich 2 Nächte gekostet...), auch die manuelle Konfiguration per scstadmin und anschließendes dumpen der config ist IMHO etwas umständlich und zudem in besagtem Tutorial nicht wirklich erklärt - eben ubuntu-like "tippe 'sudo irgendwas' aber frag nicht was das macht..."
Hatte mich deshalb ein paar Stunden mit den Dokumentationen von RH befasst um erstmal den grundsätzlichen Aufbau der scst.conf rauszufiltern.
Ich versuche hier mal die Grundkonfiguration zu erklären (soweit ich sie begriffen habe ):
Für jeden SCST Device-Handler wird eine definition mit devices angelegt - also z.B. für disk, vdisk und fileio. Mit einem ZFS zvol schaut das dann so aus:
Code: Alles auswählen
HANDLER vdisk_blockio {
DEVICE myzvol {
filename /dev/zvol/tank/fctgt/myzvol
}
}
Code: Alles auswählen
TARGET_DRIVER qla2x00t {
TARGET <WWN> {
enabled 1
LUN 0 myzvol
}
}
Will man LUNs nur an bestimmte Initiatoren freigeben oder z.b. über je einen Link ein anderes device verbinden, kann man das über GROUPS definieren:
Code: Alles auswählen
TARGET_DRIVER qla2x00t {
TARGET <WWN1> {
enabled 1
GROUP clientA {
LUN 0 myzvol
INITIATOR <WWNA>
}
GROUP clientB {
LUN 1 myothervol
INITIATOR <WWNB>
}
}
}
Um die konfiguration zu aktivieren NICHT den scst-dienst neu starten, sondern per "scstadmin -config /etc/scst.conf". Am initiator reicht dann ein rescan der/des scsi-host: "for i in /sys/class/scsi_host/host* ; do echo "- - -" > $i/scan ; done"
Danach sollten die LUNs sichtbar sein (lsblk).
So habe ich einen HBA mit 4 Ports am Target für 2 Initiatoren mit jeweils 2 Ports konfiguriert. Jeder Initiator kann an einen beliebigen Port angeschlossen werden, sieht aber nur "seine" targets. Einer der beiden soll später auch direkt per FC booten, so kann ich dem Testsystem (=Server im Rack) vorab eine Installation auf ein zvol bügeln und ihn dann mit nem vorbereiteten System booten und muss mich nicht mit Bildschirm, Tastatur und USB-Stick ans Rack stellen...
Nun noch zu multipath (das imho ziemlich unschön gelöst ist...)
Wenn man mehrere links zwischen Target und initiator hat, muss/sollte man multi-path nutzen, da der Initiator das Target über jeden Pfad einmal sieht - wird also ein device vom Target zur verfügung gestellt, sieht der Initiator dieses zwei mal - ein mal für jeden Link. Hängt ein FC-Switch dazwischen sind es sogar 4. Damit man diese als multipath-gerät nutzen kann muss man multipath-tools am initiator installieren und einrichten.
Mit den multipath-tools habe ich die letzten beiden Abende gekämpft - so wirklich zuversichtlich bin ich noch nicht, aber es funktioniert aktuell. Werde heute abend damit noch etwas testen ob das ganze setup auch wirklich mit dem ausfall eines links klarkommt...
Die einzelnen Pfade zu einer LUN werden vom Initiator als einzelne blockdevices "gesehen", z.B. sda und sdb
multipath verknüpft diese beiden und legt ZUSÄTZLICH noch mp-devices in /dev/mapper/ bzw als /dev/mpathN an. Man muss also vorsichtig sein, dass nicht irgendwo die pfade (/dev/sd[ab]) angesprochen werden, sondern nur noch das mp-device. Ansonsten verhält sich das aber ähnlich wie devices eines dm-raid, auch was die darstellung mit lsblk angeht:
Code: Alles auswählen
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 100G 0 part
└─test 250:3 0 100G 0 mpath
└─test-part1 250:4 0 100G 0 part
sdb 8:16 0 100G 0 disk
├─sdb1 8:17 0 100G 0 part
└─test 250:3 0 100G 0 mpath
└─test-part1 250:4 0 100G 0 part
sdc 8:32 0 931,5G 0 disk
└─sdc1 8:33 0 931,5G 0 part
└─vg0-home 250:1 0 465,7G 0 lvm /home
sdd 8:48 0 931,5G 0 disk
└─sdd1 8:49 0 931,5G 0 part
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 119,2G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
├─nvme0n1p2 259:2 0 93,1G 0 part
│ ├─vg0-root 250:0 0 46,6G 0 lvm /
│ └─vg0-steam 250:2 0 46,6G 0 lvm /home/r4pt0r/.steam
└─nvme0n1p3 259:3 0 25,6G 0 part [SWAP]
Code: Alles auswählen
blacklist {
".*"
}
blacklist_exceptions {
wwid 23235666139303939
}
defaults {
user_friendly_names yes
path_grouping_policy multibus
}
multipaths {
multipath {
wwid 23235666139303939
alias test
}
}
devices {
device {
vendor "SCST_BIO"
product "test"
}
}
Damit die dm-devices nicht mit ellenlanger wwid als namen angelegt werden, wird user_friendly_names gesetzt, so werden die MP-devices als /dev/mapper/<alias> im Dateisystem angelegt und können dort direkt als blockdevice angesprochen werden.
"vendor" und "product" für den abschnitt "devices" bekommt man per "cat /sys/block/sdX/device/vendor" bzw ".../device/model".
Device "test" sieht damit dann bei mir so aus:
Code: Alles auswählen
# multipath -ll
test (23235666139303939) dm-3 ,
size=100G features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=0 status=active
|- #:#:#:# sda 8:0 active undef running
`- #:#:#:# sdb 8:16 active undef running
Performance ist mit mehreren Links auch etwas höher - hdparm -t gibt mir ca 360MB/s für das MP-device an, für ein einzelnes Target ca 240MB/s. Target ist wie schon gesagt ein zvol. Geht sicher auch noch schneller, habe aber noch nicht geschaut wo da noch der Flaschenhals ist, aber schneller als ne einzelne lokale Platte ist es sowieso schon
Schön dass sich hier noch jemand mit FC beschäftigt. Ich habe vor meine Notitzen und Schmierzettel zu dem ganzen Thema demnächst zusammenzutragen (blog, "tutorial", Wikiseite, Leidensbericht - KA was draus wird ). Wäre schön wenn man hier vll auch etwas mehr zusammentragen könnte, die Informationen zu dem Thema sind leider relativ knapp und oft veraltet und obsolet.
Update:
Zu dm-multipath hat redhat sehr gute Dokumentationen:
https://access.redhat.com/documentation ... index.html
Auch wenn sich vieles auf das RHEL-Tool "mpathconf" bezieht bekommt man so ziemlich alles mit was man für die manuelle konfiguration benötigt.
Mein Setup läuft mittlerweile stabil (=überlebt Neustarts), man muss allerdings peinlichst darauf aufpassen, dass die Dateisysteme auf den MP-Geräten erst NACH der initialisierung durch dm-multipath verwendet werden. Hatte auf einer LUN einen ZFS-pool eingerichtet und nach jedem neustart war multipath scheinbar wieder defekt - weil ZFS früher initialisiert und multipath kein Gerät anrührt das bereits aktiv ist. Die Fehlerausgabe von multipath ist dabei völlig wertlos - mehr als ein "map ignored" bekommt man auch mit -v3 nicht als Fehler.
Ich kann nun problemlos im laufenden Betrieb einen LWL ausstecken, der Transfer läuft über den verbleibenden link weiter und nach wiedereinstecken werden sofort wieder beide Pfade genutzt.
Jetzt muss ich "nur" noch das wackelige verhalten von SCST bei/nach pm-suspend in den griff bekommen (initialisiert nur einen Pfad oder teilweise überhaupt keine LUN) und den import des ZFS-pools verzögern, dann ist das ganze wirklich alltagstauglich
Re: FC Target (SAN) unter Debian 8 / Jessie
Kleines Update:
Ich habe mir mittlerweile in /usr/lib/pm-utils/sleep.d/ ein Skript gebaut, das zuerst ggf alle Dateisysteme auf FC/MP-devices aushängt und zfs-pools exportiert, dann multipathd beendet und das qla2xxx Kernelmodul entfernt. Letzteres war nötig, da der HBA beim aufwachen nicht immer beide Ports neu initialisierte - in 2 von 3 Fällen war einer "offline" (alle LEDs leuchten - HBA scant den Port also nicht). Das ganze dauert ca 5sek extra beim Aufruf von "pm-suspend" - 4sek davon fallen auf das Entladen des Kernelmoduls. Ich vermute hierbei werden dann noch Caches geleert und die Session am Target sauber geschlossen.
Nach dem aufwecken das ganze in umgekehrter Reihenfolge geht bedeutend schneller - nach ca 1-2sec sind alle LUNs verfügbar.
Für optimale Performance muss man die Blockgrößen an den Einsatzzweck anpassen - ich bekomme bei 4k Blöcken die beste IOPS-Leistung, maximale Bandbreite aber bei 65k Blöcken:
Da IOPS und Bandbreite über >65k drastisch einbrechen, dürfte 16k der sinnvollste "sweet spot" sein. Kleiner nur wenn wirklich IO-Leistung benötigt wird (Datenbank), größer nur wenns auf jedes MB/s Bandbreite ankommt.
Die IOPS sind in diesem Setup _extrem_ vom Caching im ZFS-Pool abhängig auf dem die zvols liegen. Ich hatte die ersten tests noch mit 2 billigen 30GB transcend SSD370 gemacht (die gabs mal dreckbillig und es lagen noch 2 rum...), seit gestern sind 2x 120 GB kingston V300 drin - das brachte über 30% mehr IOPs und 0.8 GBit/s besseren Durchsatz (5.8-5.9GBit/s war zuvor maximum...). Müsste man ja fast mal mit NVMe- oder PCIe-SSDs testen
Mehr RAM schadet natürlich auch nicht - wenn alles vom cache im RAM abgefangen wird sind die HBAs der Flaschenhals. Die werden jetzt aber schon _extrem_ heiß bei längerer Belastung, weshalb ich denen in den nächsten Tagen erstmal Kühlkörper auf den CPUs spendieren werde...
Hier noch der link zu dem Tool das ich für die Messungen verwende:
https://benjamin-schweizer.de/measuring ... mance.html
Ich habe mir mittlerweile in /usr/lib/pm-utils/sleep.d/ ein Skript gebaut, das zuerst ggf alle Dateisysteme auf FC/MP-devices aushängt und zfs-pools exportiert, dann multipathd beendet und das qla2xxx Kernelmodul entfernt. Letzteres war nötig, da der HBA beim aufwachen nicht immer beide Ports neu initialisierte - in 2 von 3 Fällen war einer "offline" (alle LEDs leuchten - HBA scant den Port also nicht). Das ganze dauert ca 5sek extra beim Aufruf von "pm-suspend" - 4sek davon fallen auf das Entladen des Kernelmoduls. Ich vermute hierbei werden dann noch Caches geleert und die Session am Target sauber geschlossen.
Nach dem aufwecken das ganze in umgekehrter Reihenfolge geht bedeutend schneller - nach ca 1-2sec sind alle LUNs verfügbar.
Für optimale Performance muss man die Blockgrößen an den Einsatzzweck anpassen - ich bekomme bei 4k Blöcken die beste IOPS-Leistung, maximale Bandbreite aber bei 65k Blöcken:
Code: Alles auswählen
# ./iops /dev/mapper/mpathc
/dev/mapper/mpathc, 21.47 GB, 32 threads, random:
512 B blocks: 138146.1 IO/s, 70.7 MB/s (565.8 Mbit/s)
1 kB blocks: 139215.5 IO/s, 142.6 MB/s ( 1.1 Gbit/s)
2 kB blocks: 137167.2 IO/s, 280.9 MB/s ( 2.2 Gbit/s)
4 kB blocks: 140778.5 IO/s, 576.6 MB/s ( 4.6 Gbit/s)
8 kB blocks: 89767.0 IO/s, 735.4 MB/s ( 5.9 Gbit/s)
16 kB blocks: 49945.3 IO/s, 818.3 MB/s ( 6.5 Gbit/s)
32 kB blocks: 25116.8 IO/s, 823.0 MB/s ( 6.6 Gbit/s)
65 kB blocks: 12702.6 IO/s, 832.4 MB/s ( 6.7 Gbit/s)
131 kB blocks: 6203.5 IO/s, 813.1 MB/s ( 6.5 Gbit/s)
262 kB blocks: 2008.3 IO/s, 526.5 MB/s ( 4.2 Gbit/s)
524 kB blocks: 1193.9 IO/s, 625.9 MB/s ( 5.0 Gbit/s)
1 MB blocks: 418.8 IO/s, 439.1 MB/s ( 3.5 Gbit/s)
2 MB blocks: 161.9 IO/s, 339.6 MB/s ( 2.7 Gbit/s)
4 MB blocks: 90.3 IO/s, 378.9 MB/s ( 3.0 Gbit/s)
8 MB blocks: 46.8 IO/s, 392.5 MB/s ( 3.1 Gbit/s)
16 MB blocks: 23.2 IO/s, 389.4 MB/s ( 3.1 Gbit/s)
Die IOPS sind in diesem Setup _extrem_ vom Caching im ZFS-Pool abhängig auf dem die zvols liegen. Ich hatte die ersten tests noch mit 2 billigen 30GB transcend SSD370 gemacht (die gabs mal dreckbillig und es lagen noch 2 rum...), seit gestern sind 2x 120 GB kingston V300 drin - das brachte über 30% mehr IOPs und 0.8 GBit/s besseren Durchsatz (5.8-5.9GBit/s war zuvor maximum...). Müsste man ja fast mal mit NVMe- oder PCIe-SSDs testen
Mehr RAM schadet natürlich auch nicht - wenn alles vom cache im RAM abgefangen wird sind die HBAs der Flaschenhals. Die werden jetzt aber schon _extrem_ heiß bei längerer Belastung, weshalb ich denen in den nächsten Tagen erstmal Kühlkörper auf den CPUs spendieren werde...
Hier noch der link zu dem Tool das ich für die Messungen verwende:
https://benjamin-schweizer.de/measuring ... mance.html
Re: FC Target (SAN) unter Debian 8 / Jessie
Habe meinen gestarteten Thread gerade wieder als Nachschlagewerk herausgesucht, wegen Konfigurationsänderung, da mir meine handschriftliche Dokumentation abhanden gekommen ist
Schön, dass ich nicht der Einzige bin, der sich mit dem Thema schon gerne mal ein halbe Nacht um die Ohren geschlagen hat
Wenn man die SCST Config begriffen hat, geht es relativ einfach von der Hand, man muss sich da aber wiklich ein wenig damit beschäftigen. Mittels "quick&dirty" Methode herumprobieren und schauen ob´s funktioniert, läuft da nicht. Anfangs habe ich auch den Fehler gemacht und einfach den SCST Dienst nach Konfigurationsänderung durchgestartet, was man tunlichst vermeiden sollte. Daher, wie von r4pt0r beschrieben:
Als Fazit nach mittlerweile über 1/4 Jahr in produktivem Einsatz hat sich der Aufwand für eine Storageanbindung per FC echt gelohnt. Gerade beim bewegen größerer Datenmengen von Disk-Arrays geht das gut und gerne mal mit 250-300MB/s von statten, anstatt über Kupfer-Gbit mit 100MB herumzudümpeln. Den beschriebenen Extremfall von SSD zu SSD hatte ich aber auch schon, das kratzt bei den 4Gbit HBA´s dann am Maximum von knapp 400 MB/s. Lässt hoffen, dass die 8G Karten auch irgendwann mal für ein Taschengeld zu bekommen sind
Schön, dass ich nicht der Einzige bin, der sich mit dem Thema schon gerne mal ein halbe Nacht um die Ohren geschlagen hat
Wenn man die SCST Config begriffen hat, geht es relativ einfach von der Hand, man muss sich da aber wiklich ein wenig damit beschäftigen. Mittels "quick&dirty" Methode herumprobieren und schauen ob´s funktioniert, läuft da nicht. Anfangs habe ich auch den Fehler gemacht und einfach den SCST Dienst nach Konfigurationsänderung durchgestartet, was man tunlichst vermeiden sollte. Daher, wie von r4pt0r beschrieben:
Von Multipath auf LUN´s hatte ich bisher die Finger gelassen, aber zwecks eventuellem Ausbau einer Dual-Port HBA in meier SAN werde ich mir deine gesammelte Erfahrung zu Nutzen machen.Um die konfiguration zu aktivieren NICHT den scst-dienst neu starten, sondern per "scstadmin -config /etc/scst.conf".
Als Fazit nach mittlerweile über 1/4 Jahr in produktivem Einsatz hat sich der Aufwand für eine Storageanbindung per FC echt gelohnt. Gerade beim bewegen größerer Datenmengen von Disk-Arrays geht das gut und gerne mal mit 250-300MB/s von statten, anstatt über Kupfer-Gbit mit 100MB herumzudümpeln. Den beschriebenen Extremfall von SSD zu SSD hatte ich aber auch schon, das kratzt bei den 4Gbit HBA´s dann am Maximum von knapp 400 MB/s. Lässt hoffen, dass die 8G Karten auch irgendwann mal für ein Taschengeld zu bekommen sind
Re: FC Target (SAN) unter Debian 8 / Jessie
Gibt es hier bereits Updates?
Ist sowas wie Samba oder FTP denn auch ueber FC moeglich? 8GBit/s Karten nun auch fuer wenig Geld verfuegbar?
Ich bewege oft hunderte GB an Daten auf meinen 12 Festplatten Raid 5 NAS, und bei 95MB/s dauert das ewig.
Habe daher nun Glasfaser LC Kabel verlegt, und mir solce QL 2460 Karten geholt! Ich probiere mal die Vorgehensweise hier
Kann es sein dass die LC Kabel nur bei den 4GBIt Karten verwendet werden koennen? Die anderen haben alle SFP so was ich sehe
Leider scheint sich ja einiges geaendert zu haben seitdem, komme daher mit dem Tutorial unter Debian 9.1.0 nicht sehr weit, maximal bis Schritt 2!
Ist sowas wie Samba oder FTP denn auch ueber FC moeglich? 8GBit/s Karten nun auch fuer wenig Geld verfuegbar?
Ich bewege oft hunderte GB an Daten auf meinen 12 Festplatten Raid 5 NAS, und bei 95MB/s dauert das ewig.
Habe daher nun Glasfaser LC Kabel verlegt, und mir solce QL 2460 Karten geholt! Ich probiere mal die Vorgehensweise hier
Kann es sein dass die LC Kabel nur bei den 4GBIt Karten verwendet werden koennen? Die anderen haben alle SFP so was ich sehe
Leider scheint sich ja einiges geaendert zu haben seitdem, komme daher mit dem Tutorial unter Debian 9.1.0 nicht sehr weit, maximal bis Schritt 2!
Re: FC Target (SAN) unter Debian 8 / Jessie
Nein, weil diese (gammligen) Protokolle auf TCP/IP aufbauen - FC arbeitet einzig und allein mit blockdevices.Knogle hat geschrieben:19.08.2017 21:26:26Ist sowas wie Samba oder FTP denn auch ueber FC moeglich?
Wenn du unbedingt lokal mit diesen Protokollen arbeiten musst, schau dich nach 10Gbit Ethernet NICs um - die sind mittlerweile auch dreckbillig. Brauchbare switches (=die wirklich line-speed packen) sind aber preislich für den privatgebrauch noch eher uninteressant...
Für lokale mounts ist NFS auf jeden Fall die schnellere Variante als SMB oder FTP (die beide noch etliche andere Probleme mit sich bringen!).Ich bewege oft hunderte GB an Daten auf meinen 12 Festplatten Raid 5 NAS, und bei 95MB/s dauert das ewig.
Bei einem RAID5 (vermutl. mit SATA-HDDs) wirst du aber sowieso schon ziemlich am Limit sein - der Flaschenhals ist hier einfach die Plattenkonfiguration.
Praktisch alles was man an FC-HBAs bekommt hat entweder fest verbaute Transceiver mit LC-Buchse oder nimmt SFP+ module mit eben solchen Buchsen auf.Habe daher nun Glasfaser LC Kabel verlegt, und mir solce QL 2460 Karten geholt! Ich probiere mal die Vorgehensweise hier
Kann es sein dass die LC Kabel nur bei den 4GBIt Karten verwendet werden koennen? Die anderen haben alle SFP so was ich sehe
Für kurze Distanzen (<1m) kann man ggf auch SFP-DAC/Twinax Kabel verwenden. Für 4Gbit tuns evtl auch die billigen noname-DACs, ansonsten sind brauchbare/hochwertige DACs meist teurer als Transceiver + LWL-Patchkabel.
Re: FC Target (SAN) unter Debian 8 / Jessie
Vielen Dank schonmal fuer die Antwort.
Meinste jetzt mit den 10GBit NICs welche spotbillig sein sollen, welche fuer RJ45, oder kann ich da auch bedenkenlos zu solchen 10GBit "Ethernet" SFP Karten suchen?
Wenn ich das richtig verstehe kann ich mir sowas reinstecken http://www.ebay.de/itm/HP-Mellanox-Conn ... 0005.m1851 und dann einen entsprechenden FC Transceiver und fertig, oder sehe ich das falsch?
Das Tutorial habe ich durch, den Kernel habe ich mir gebaut, Verbindung steht, nur wie kriege ich nun was rueber?
War viel anpasserei in Debian Stretch noetig, werde wohl nachher mal meine Vorgehensweise posten
Auf die Protokolle bin ich jedoch nicht zwingend angewiesen, mir kommt es nur irgendwie drauf an dass ich die Daten von A --> B kriege
Mein RAID laeuft mit SAS 2TB Festplatten von Seagate welche an einem LSI SAS Controller mit Expander haengen.
Meinste jetzt mit den 10GBit NICs welche spotbillig sein sollen, welche fuer RJ45, oder kann ich da auch bedenkenlos zu solchen 10GBit "Ethernet" SFP Karten suchen?
Wenn ich das richtig verstehe kann ich mir sowas reinstecken http://www.ebay.de/itm/HP-Mellanox-Conn ... 0005.m1851 und dann einen entsprechenden FC Transceiver und fertig, oder sehe ich das falsch?
Das Tutorial habe ich durch, den Kernel habe ich mir gebaut, Verbindung steht, nur wie kriege ich nun was rueber?
War viel anpasserei in Debian Stretch noetig, werde wohl nachher mal meine Vorgehensweise posten
Auf die Protokolle bin ich jedoch nicht zwingend angewiesen, mir kommt es nur irgendwie drauf an dass ich die Daten von A --> B kriege
Mein RAID laeuft mit SAS 2TB Festplatten von Seagate welche an einem LSI SAS Controller mit Expander haengen.
Re: FC Target (SAN) unter Debian 8 / Jessie
Ich habe die letzten ~2 Jahre für alles >Gbit nur noch LWL verbaut - solange du nicht zwingend ein vorhandenes Kupfernetz nutzen musst, verwende Transceiver für LWL (SR / 850nm Transceiver mit multimode-Fasern ist m.E. am unkompliziertesten)Knogle hat geschrieben:21.08.2017 18:11:23Vielen Dank schonmal fuer die Antwort.
Meinste jetzt mit den 10GBit NICs welche spotbillig sein sollen, welche fuer RJ45, oder kann ich da auch bedenkenlos zu solchen 10GBit "Ethernet" SFP Karten suchen?
ja, z.B.Wenn ich das richtig verstehe kann ich mir sowas reinstecken http://www.ebay.de/itm/HP-Mellanox-Conn ... 0005.m1851 und dann einen entsprechenden FC Transceiver und fertig, oder sehe ich das falsch?
Ich kenne die aktuelle treibersituation unter debian nicht, aber mit Mellanox oder Intel ist man i.d.r. am besten beraten.
FC reicht wie gesagt blockdevices durch - du musst also serverseitig images/zvols/platten zur verfügung stellen, welche die clients dann wie normale blockdevices nutzen können - sprich partitionen und dateisysteme darauf erstellen.Das Tutorial habe ich durch, den Kernel habe ich mir gebaut, Verbindung steht, nur wie kriege ich nun was rueber?
War viel anpasserei in Debian Stretch noetig, werde wohl nachher mal meine Vorgehensweise posten
Auf die Protokolle bin ich jedoch nicht zwingend angewiesen, mir kommt es nur irgendwie drauf an dass ich die Daten von A --> B kriege
Alles was darauf liegt kann (DARF) immer nur von EINEM System gleichzeitig gemountet sein! Willst du die daten von mehreren systemen aus nutzen ist FC der falsche ansatz bzw nur im hintergrund z.b. für einen fileserver ohne eigene platten relevant.
Der Flaschenhals ist trotzdem das RAID5 über 12 Platten - der overhead ist hierbei gigantisch. Meine übliche Empfehlung: ZFSMein RAID laeuft mit SAS 2TB Festplatten von Seagate welche an einem LSI SAS Controller mit Expander haengen.
Re: FC Target (SAN) unter Debian 8 / Jessie
Danke dir, von der Konfiguration her ist das mit den Ethernet SFP eine ganz andere Ebene, da war die Konfiguration in 10 Minuten erledigt
Wie von dir vorrausgesehen ist das RAID 5 der Flaschenhals ja Das macht bei 330 MB/s dicht, manchmal sogar bei 100MB/s wenn er Controller heiss wird..
Wie von dir vorrausgesehen ist das RAID 5 der Flaschenhals ja Das macht bei 330 MB/s dicht, manchmal sogar bei 100MB/s wenn er Controller heiss wird..