FC Target (SAN) unter Debian 8 / Jessie

Probleme mit Samba, NFS, FTP und Co.
Antworten
ranni26
Beiträge: 33
Registriert: 01.03.2011 18:42:31

FC Target (SAN) unter Debian 8 / Jessie

Beitrag von ranni26 » 27.01.2016 10:30:29

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]

ranni26
Beiträge: 33
Registriert: 01.03.2011 18:42:31

Gelöst: FC Target (SAN) unter Debian 8 / Jessie

Beitrag von ranni26 » 31.01.2016 12:03:18

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

Code: Alles auswählen

wget http://ldriver.qlogic.com/firmware/ql2400_fw.bin
cp ql2400_fw.bin /lib/firmware/
oder aus den "non-free" Debian Repo´s

Code: Alles auswählen

apt-get install firmware-qlogic
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.

Code: Alles auswählen

rmmod qla2xxx
echo blacklist qla2xxx >/etc/modprobe.d/blacklist-qla2xxx.conf
update-initramfs -u
reboot
Nach dem Reboot prüfen, ob das Modul noch geladen wird, wenn nicht ist alles ok.

Code: Alles auswählen

lsmod | grep ql*
3. Benötigte Pakete für Abhängigkeiten + Kernel Sources holen
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
Kernel Sourcen ablegen in /tmp lt. Beispiel oder anderen Ordner nach Wahl

Code: Alles auswählen

mkdir /tmp/KernelSource
cd /tmp/KernelSource
apt-get source linux-source-3.x
ln -s linux-3.x.xx ../Linux
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

Code: Alles auswählen

cd /tmp/
svn co https://svn.code.sf.net/p/scst/svn/trunk scst
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

Code: Alles auswählen

cd Linux
patch -p1 < {your_scst_source_directory}/scst/kernel/in-tree/Makefile.drivers.Linux-x.x.patch
"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:

Code: Alles auswählen

patch -p1 < {your_scst_source_directory}/scst/iscsi-scst/kernel/patches/put_page_callback-3.xx.patch
6. qla2x00t Treiber in den Quellen austauschen
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
7. Kernel anpassen

Code: Alles auswählen

make menuconfig
Wie im geposteten Tutorial beschrieben sollte man folgende Kernelsettings prüfen und ggfg. einstellen:
- 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)
8. Kernel bauen

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
9. SCST Software bauen

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
"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.
scst
qla2xxx_scst
qla2x00tgt
scst_vdisk
scst_user
scst_disk
11. SCSTadmin bauen

Code: Alles auswählen

cd {your_scst_source}/scstadmin
make
make install
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

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	
			
		}
	}
 
Als Target und Initiator Adresse muss der Port Name des jeweiligen Adapters eingetragen werden.

Nach dem Anlegen der Config reicht es folgenden Befehl abzusetzen:

Code: Alles auswählen

scstadmin -conf /etc/scst.conf

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: FC Target (SAN) unter Debian 8 / Jessie

Beitrag von r4pt0r » 09.03.2016 14:09:38

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 :wink: ):

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
    }
}
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:

Code: Alles auswählen

TARGET_DRIVER qla2x00t {
    TARGET <WWN> {
        enabled 1
        LUN 0 myzvol
    }
}
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:

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>
        }

    }
}
"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:

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]
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:

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 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:

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
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 :wink:


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 :wink: ). 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 :)

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: FC Target (SAN) unter Debian 8 / Jessie

Beitrag von r4pt0r » 15.03.2016 21:19:52

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:

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)
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 :mrgreen:
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

ranni26
Beiträge: 33
Registriert: 01.03.2011 18:42:31

Re: FC Target (SAN) unter Debian 8 / Jessie

Beitrag von ranni26 » 18.06.2016 13:17:25

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 :D

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:
Um die konfiguration zu aktivieren NICHT den scst-dienst neu starten, sondern per "scstadmin -config /etc/scst.conf".
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.

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 ;)

Knogle
Beiträge: 269
Registriert: 06.05.2016 19:29:00
Lizenz eigener Beiträge: GNU General Public License

Re: FC Target (SAN) unter Debian 8 / Jessie

Beitrag von Knogle » 19.08.2017 21:26:26

Gibt es hier bereits Updates? :D
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!

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: FC Target (SAN) unter Debian 8 / Jessie

Beitrag von r4pt0r » 21.08.2017 16:08:04

Knogle hat geschrieben: ↑ zum Beitrag ↑
19.08.2017 21:26:26
Ist sowas wie Samba oder FTP denn auch ueber FC moeglich?
Nein, weil diese (gammligen) Protokolle auf TCP/IP aufbauen - FC arbeitet einzig und allein mit blockdevices.
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...
Ich bewege oft hunderte GB an Daten auf meinen 12 Festplatten Raid 5 NAS, und bei 95MB/s dauert das ewig.
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!).
Bei einem RAID5 (vermutl. mit SATA-HDDs) wirst du aber sowieso schon ziemlich am Limit sein - der Flaschenhals ist hier einfach die Plattenkonfiguration.
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
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.
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.

Knogle
Beiträge: 269
Registriert: 06.05.2016 19:29:00
Lizenz eigener Beiträge: GNU General Public License

Re: FC Target (SAN) unter Debian 8 / Jessie

Beitrag von Knogle » 21.08.2017 18:11:23

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? :D
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.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: FC Target (SAN) unter Debian 8 / Jessie

Beitrag von r4pt0r » 21.08.2017 18:58:14

Knogle hat geschrieben: ↑ zum Beitrag ↑
21.08.2017 18:11:23
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?
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)
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?
ja, z.B.
Ich kenne die aktuelle treibersituation unter debian nicht, aber mit Mellanox oder Intel ist man i.d.r. am besten beraten.
Das Tutorial habe ich durch, den Kernel habe ich mir gebaut, Verbindung steht, nur wie kriege ich nun was rueber? :D
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
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.
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.
Mein RAID laeuft mit SAS 2TB Festplatten von Seagate welche an einem LSI SAS Controller mit Expander haengen.
Der Flaschenhals ist trotzdem das RAID5 über 12 Platten - der overhead ist hierbei gigantisch. Meine übliche Empfehlung: ZFS

Knogle
Beiträge: 269
Registriert: 06.05.2016 19:29:00
Lizenz eigener Beiträge: GNU General Public License

Re: FC Target (SAN) unter Debian 8 / Jessie

Beitrag von Knogle » 23.08.2017 16:59:03

Danke dir, von der Konfiguration her ist das mit den Ethernet SFP eine ganz andere Ebene, da war die Konfiguration in 10 Minuten erledigt 8O
Wie von dir vorrausgesehen ist das RAID 5 der Flaschenhals ja :D Das macht bei 330 MB/s dicht, manchmal sogar bei 100MB/s wenn er Controller heiss wird..

Antworten