V nedávné době padlo ve firmě rozhodnutí virtualizovat naše servery. K tomu bylo potřeba vyřešit nějaké centrální úložiště dat. Původně jsme chtěli použít nějakou hotovou platformu, vyhlídnuté jsme měli Intel "Snow Hill" nebo Intel "Grosse Point" , ale nakonec jsme se rozhodli pro více diskových pozic a montovaný server. Protože základní deska Intel Grosse Point se prodává i samostatně, původně jsme ji chtěli použít. Nedokázali jsme však u dodavatelel zjistit, jaký má vlastně použitý raid-řadič, tak jsme se nakonec rozhodli pro čistě SW-raid a levnější řešení se základní deskou GigaByte 890XA-UD3, která má celkem tři řadiče SATA a 10 SATA portů, z toho 6 jich dokonce podporuje 6Gb/s SATA. Jako procesor jsme použili obyčejný Sempron 140 (uvidíme, zda bude výkonově stačit - upgradovat můžeme kdykoliv dle potřeby). A paměti zatím jen 4GB. Ovšem pro hlavní centrální úložiště jsme si představovali case s HotSwap pozicemi pro pevné disky. Nakonec jsme si vybrali case, který má celkem 8 HotSwap pozic s označením RC-265D8. A k tomu i patřičný 500W zdroj RP-250. Na záložní úložiště již nebyly požadavky na HotSwap, ani zde není uvažováno nasazení RAIDu, proto jsme použili velice cenově zajímavý case Acutake Industry Just 2U, do kterého se dá umístit až 6 disků (jeden v redukci do 5,25" pozice).
Záložní centrální úložiště:
Začnu tím jednodušším - až na použité HW komponenty je řešení v podstatě stejné, jako u domacího NASu. Pouze zde není počítáno se Sambou, ale sdílení bude zatím řešeno přes NFS a GlusterFS. V použitém case je počítáno s vodorovným umístěním přídavných karet (VGA), proto je i zapotřebí "stromeček". Bohužel dnes jsou všechny VGA již v provedení PCI-E a takový stromeček není moc běžný, naštěstí jsem ho sehnal. Osazeno je celkem 6 disků, vybírali jsme z nabídky disků se sníženou spotřebou a tepelným vyzařováním - nakonec zvítězil Samsung; hlavně proto, že u disků WD jsme narazili na nižší kompatibilitu s některými řadiči a s hardwarovými RAID-poli XtendLan, které též používáme.
Použité komponenty:
Základní deska GigaByte 890XA-UD3 3023,-
Procesor AMD Sempron 140 661,-
Paměť 4GB Transcend 2618,-
VGA nVidia 652,-
Stromeček PCI-E 126,-
Case Acutake Industry Just 2U 1404,-
Zdroj 350W 275,-
Disky Samsung F3 1TB (celkem 6ks) 8568,-
Celkem (uvedené ceny jsou bez DPH) 17327,-
Použitý systém je opět má oblíbená Fedora 12, konfigurace je až na Sambu shodná jako u domácího NASu. Montování disků je opět řešeno pomocí e2label a položky LABEL v /etc/fstab. Bezpečnost zde není řešena, protože úložiště budou připojena přes separátní kartu v serverech a k vnější síti nebude existovat fyzické spojení. Administrace bude prováděna vždy přes některý ze serverů.
Hlavní centrální úložiště:
Zde byl kladen hlavní důraz na spolehlivost dat, proto bylo jednoznačně počítáno s RAIDem. Ze začátku jsme zvažovali HW-raid, ale po zjištění, že v případě poruchy řadiče mohou být data s jiným řadičem nedostupná, a dostupnost stejného řadiče po x-letech může být sporná, jsem se rozhodl i za cenu nižší rychlosti pro softwarový raid. Použitý case má celkem 8 diskových pozic a na základní desce je dokonce 10 SATA portů, rozhodli jsme se osadit disky do všech pozic. Zde jsme se sice opět rozhodli pro disky Samsung, tentokrát ovšem pro "RAID EDITION".
Z dodaných disků jsem nejprve sestavil první diskové pole typu RAID1 (mirror). U druhého pole je počítáno s RAID5 na pěti discích + jeden disk jako hot-spare.
Použité komponenty:
Základní deska GigaByte 890XA-UD3 3023,-
Procesor AMD Sempron 140 661,-
Paměť 4GB Transcend 2618,-
VGA nVidia 652,-
Stromeček PCI-E 126,-
Case RC-265D8 9360,-
Zdroj 500W RP-250 2951,-
Disky Samsung F1 1TB RAID-Edition (8 ks) 12800,-
Celkem (uvedené ceny jsou bez DPH) 32191,-
V tomto case je počítáno se svislým umístěním low-profile karet, proto zde není komplikace s chybějícím stromečkem PCI-E. Zato se nám nepodařilo sehnat low-profile VGA kartu, proto jsme použili kartu "Point Of View nVidia GeForce 8400GS" , která má sice nízký profil plošného spoje, ale "zadní plech" je na plnou výšku. Konektor pro VGA je však k desce připojen plochým kabelem a jde odmontovat. Tento konektor se potom umístí do vedlejší pozice na záslepku (nutno vyvrtat a vypilovat patřičný otvor) a původní plech je již možné kladivem, pilkou a vrtačkou přesvědčit, aby se nechal umístit do 2U pozice..... Při pečlivé práci ani není poznat, že to výrobce takto původně neplánoval...
Jako OS jsem opět zvolil Fedoru, i když jsem nejprve instaloval CentOS. Protože však jsem si zvykl na určitý "komfort", který má Fedora navíc, jsem nakonec ten CentOS vzdal a přeinstaloval na Fedoru. Nevím, zda to v tomto případě nebylo špatné rozhodnutí, ale nakonec RAID je věcí kernelu a snad je na distribuci nezávislý....
Navíc Fedora umožňuje vytvoření RAID1 hned při instalaci a není potřeba dodatečně pole sestavovat (na dodatečném sestavní jsem u toho CentOSu pohořel - druhý disk se mi nepodařilo nakonfigurovat jako bootovací...).
Zatím však mám stále nedořešený jeden problém. A to s HotSwapem. Pokud totiž simuluji závadu jednoho disku (vyjmu jej), systém si stále "drží" jeho označení a při opětovném vložení disku mu přiřadí první následující volné označení. S tím však není počítáno v konfiguraci raidu a tak nezačne automatický rebuild. Je zapotřebí buď restart (to ale strácí smysl hotswap), nebo ruční přiřazení disku do pole pomocí příkazu mdadm. Jenomže tohle zase nezvládne každý ve firmě.... Na druhou stranu u toho RAID5 pole bude trvale osazen hot-spare disk, takže případná výměna vadného disku snad nebude zapotřebí řešit okamžitě. Dokonce jsem zjistil, že jeden hot-spare disk může být společný pro dvě raid-pole.
Konfigurace NASu s RAID1:
Jak jsem se již zmínil, nejjednodušší konfigurace bootabilního pole RAID1 je hned při instalaci. Já při instalaci vytvořil oddíly md0 až md3 (boot - 300M, system - 40GB, swap - 4GB a oblast pro data - zbytek). Na toto rozdělení by sice někdo mohl namítnout, že stačí samostatná oblast pro /boot a zbytek řešit nasazením LVM a místo jednotlivých oddílů použít LV, ale já nějak LVM na systémovém disku stále nemůžu přijít na chuť... Takže LVM mám nasazeno až nad datovou oblastí, v tomto případě nad md3 a to se konfiguruje už na hotovém systému. Instalační procedura sama nastaví typ diskové oblasti na "fd" (Linux RAID samorozpoznatelný) a správně vytvoří i konfigurační soubor /etc/mdadm.conf, takže se v podstatě po instalaci nijak nemusí RAID1 konfigurovat. Je to elegantnější a hlavně rychlejší řešení, než zakládat RAID1 dodatečně a potom ještě čekat, než se druhý disk replikuje. Stav RAIDu je možno zkontrolovat v /proc/mdstat, musí zde být něco jako
Personalities : [raid1]
md3 : active raid1 sdb5[0] sdc5[1]
4095936 blocks [2/2] [UU]
md2 : active raid1 sdb3[0] sdc3[1]
931388352 blocks [2/2] [UU]
md1 : active raid1 sdb2[0] sdc2[1]
40959936 blocks [2/2] [UU]
md0 : active raid1 sdb1[0] sdc1[1]
307136 blocks [2/2] [UU]
unused devices: <none>
kde je vždy popsáno, ze kterých oblastí je RAID sestaven (např. oblast RAIDu md3 je zde sestavena z diskových oddílů sdb5 a sdc5) a znaky UU znamenají, že jsou obě části RAIDu funkční. Pokud zde místo jednoho písmena U bude jen znak "_", znamená to, že pole je v degradovaném stavu (skládá se pouze z jedné oblasti). To je samozřejmě není provozní stav, je to buď závada disku, ruční odpojení jednoho disku (mdadm -f, mdadm -r) , nebo může probíhat rebuild - ten vypadá nějak takto
Personalities : [raid1]
md3 : active raid1 sdb5[0] sdc5[1]
4095936 blocks [2/2] [UU]
md2 : active raid1 sdb3[2] sdc3[1]
931388352 blocks [2/1] [_U]
resync=DELAYED
md1 : active raid1 sdb2[2] sdc2[1]
40959936 blocks [2/1] [_U]
[=>.............] recovery = 5.3% (2184960/40959936) finish=8.2min speed=78034K/sec
md0 : active raid1 sdb1[0] sdc1[1]
307136 blocks [2/2] [UU]
unused devices: <none>
Konfigurace NASu s RAID5:
Zatímco u předchozího odstavce (RAID1) vzniklo diskové pole přímo při instalační proceduře a v podstatě není v tuto chvíli potřeba pracovat s programem mdadm (v podstatě jen při poruše disku), u pole typu RAID5 je potřeba je vytvářet ručně právě pomocí mdadm.
Nejprve je potřeba pomocí programu fdisk připravit všechny disky pro RAID5 (stejné oblasti). Jako typ oddílu je zapotřebí zvolit "fd" - "Linux RAID samorozpoznatelný".
Vlastní pole se potom vytvoří pomocí řádku
mdadm --create /dev/md4 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
stav RAIDu je možné zjišťovat opět v /proc/mdstat, nebo pomocí mdadm
mdadm --detail /dev/md4
by mělo vrátit něco takového:
[root@storage1 proc]# mdadm -D /dev/md4
/dev/md4:
Version : 0.90
Creation Time : Mon May 31 11:44:43 2010
Raid Level : raid5
Array Size : 209808384 (200.09 GiB 214.84 GB)
Used Dev Size : 52452096 (50.02 GiB 53.71 GB)
Raid Devices : 5
Total Devices : 6
Preferred Minor : 4
Persistence : Superblock is persistent
Update Time : Mon Jun 7 16:17:52 2010
State : clean
Active Devices : 5
Working Devices : 6
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
UUID : 8c9a8034:9c9bf20b:ac6cd07f:121627b0
Events : 0.5564
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 8 33 2 active sync /dev/sdc1
3 8 49 3 active sync /dev/sdd1
4 8 65 4 active sync /dev/sde1
5 8 81 - spare /dev/sdf1
Zde je na výpisu vidět i přidaný spare-disk (/dev/sdf1). Ten se k hotovému RAIDu přidá příkazem
mdadm /dev/md4 -a /dev/sdf1
Zatímco u RAID1 vytvořeného přímo instalační procedurou se automaticky vytvoří konfigurační soubor /etc/mdadm.conf, v tomto případě se musí vytvořit pomocí
mdadm --detail --scan >> /etc/mdadm.conf
a případně ještě ručně "doladit"
# mdadm.conf written out by anaconda
MAILADDR
admin@mojedomena.cz
AUTO +imsm +1.x -all
ARRAY /dev/md0 level=raid1 num-devices=2 devices=/dev/sdg1,dev/sdh1 UUID=4d94b248:bfab8707:bfe78010:bc810f04 spares=1
ARRAY /dev/md1 level=raid1 num-devices=2 devices=/dev/sdg2,dev/sdh2 UUID=2d9feb7a:4be48c21:bfe78010:bc810f04 spares=1
ARRAY /dev/md2 level=raid1 num-devices=2 devices=/dev/sdg3,dev/sdh3 UUID=9a7381d8:a597a22a:7a224a58:fc9befbb spares=1
ARRAY /dev/md4 level=raid5 num-devices=5 UUID=8c9a8034:9c9bf20b:ac6cd07f:121627b0
ARRAY /dev/md5 level=raid5 num-devices=5 UUID=c32fd718:6f3cc29c:ac6cd07f:121627b0
Dle dostupných informací lze jeden spare disk použít i pro více RAID-polí. K tomu by mělo stačit do tohoto konfiguračního souboru přidat volbu spare-group=jmeno, bohužel se mi to však nepodařilo nakonfigurovat tak, aby byl společný jak pro md0/md1/md2, tak i pro md4/md5 (a to jsem zkoušel i disky přerozdělil tak, aby všech 8 disků mělo naprosto stejné partišny).....
V případě, že je zapotřebí diskové pole nově sesadit (například po reinstalaci systému), je zapotřebí nejprve zjistit, ze kterých disků/oblastí byl RAID sesazen.
mdadm --examine /dev/sda1
Tento údaj (metadata) je zapsán na každém z disků pole, proto je možné místo /dev/sda1 zadat jakoukoliv oblast z libovolného disku. Ve výsledku je pak vidět, z jakých oblastí a disků byl původní RAID sesazen. Z těchto oblastí je pak možné nově vytvořit konfigurační soubor /etc/mdadm.conf. Dokonce je možné v jednom kroku přidat i spare-disk (zde /dev/sdf1).
mdadm --examine --scan /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 >>/etc/mdadm.conf
Nyní je možné RAID znovu sesadit (nesmí se ale už použít volba --create, ale --assemble).
mdadm --assemble -s
poznámka: jak u RAIDu, tak i u jednotlivých disků se používá UUID. Podle UUID lze i jednotlivé oblasti montovat (v souboru /etc/fstab). Na zjištění UUID disků se používá příkaz blkid - bez parametru vypíše UUID všech oblastí
[root@storage1 ~]# blkid
/dev/sdf1: UUID="8c9a8034-9c9b-f20b-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sdf3: UUID="c32fd718-6f3c-c29c-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sdb1: UUID="8c9a8034-9c9b-f20b-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sdb3: UUID="c32fd718-6f3c-c29c-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sdc1: UUID="8c9a8034-9c9b-f20b-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sdc3: UUID="c32fd718-6f3c-c29c-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sde1: UUID="8c9a8034-9c9b-f20b-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sde3: UUID="c32fd718-6f3c-c29c-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sdd1: UUID="8c9a8034-9c9b-f20b-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sdd3: UUID="c32fd718-6f3c-c29c-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sda1: UUID="8c9a8034-9c9b-f20b-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sda3: UUID="c32fd718-6f3c-c29c-ac6c-d07f121627b0" TYPE="linux_raid_member"
/dev/sdg1: UUID="4d94b248-bfab-8707-bfe7-8010bc810f04" TYPE="linux_raid_member"
/dev/sdg2: UUID="2d9feb7a-4be4-8c21-bfe7-8010bc810f04" TYPE="linux_raid_member"
/dev/sdg3:
UUID="9a7381d8-a597-a22a-7a22-4a58fc9befbb"
UUID_SUB="9f82bc78-bdbb-4901-4dc6-b7effdec076a"
LABEL="localhost.localdomain:2" TYPE="linux_raid_member"
/dev/sdh1: UUID="4d94b248-bfab-8707-bfe7-8010bc810f04" TYPE="linux_raid_member"
/dev/sdh2: UUID="2d9feb7a-4be4-8c21-bfe7-8010bc810f04" TYPE="linux_raid_member"
/dev/sdh3:
UUID="9a7381d8-a597-a22a-7a22-4a58fc9befbb"
UUID_SUB="ea1cc571-f83b-2556-e209-26469f148e6c"
LABEL="localhost.localdomain:2" TYPE="linux_raid_member"
/dev/md0: LABEL="system" UUID="9309c8d4-a21c-4cf2-8df2-15b046bdd50f" TYPE="ext4"
/dev/md1: UUID="5b04f646-70d4-4982-b211-62d8dd3f623e" TYPE="swap"
/dev/md2: LABEL="raid1" UUID="fdbaadcd-0178-4b2c-878e-e74310891f77" TYPE="ext4"
/dev/md4: LABEL="raid51" UUID="f5c20069-1c66-44cb-b2c6-de5a413c2d54" TYPE="ext4"
/dev/md5: LABEL="raid52" UUID="d4261541-5fab-4a65-889f-6cd4bb3806cc" TYPE="ext4"
Další možnosti programu mdadm:
Zastavení pole
mdadm --stop /dev/md4
Označení disku jako vadného (okamžitě začne rebuild pole na spare-disk)
mdadm --manage /dev/md4 --fail /dev/sdd1
Vyjmutí disku (uvolní se označení disku - zde sdd1 - pro opětovné použití s novým diskem)
mdadm --manage /dev/md4 --remove /dev/sdd1
Při vyjmutí disku musí být označeny (--fail) a odpojeny (--remove) všechny oddíly na vyjímaném disku
Síťový file-systém
Pro nedůležitá data (instalační obrazy pro XENServer apod.) je nejjednodušší použít NFS. Ale pro plánované použití dvou úložišť se shodnými daty je potřeba použít nějaký fs, který umí on-line data replikovat zároveň na dvě úložiště. V této oblasti zatím nemám moc zkušeností, proto jsem hledal potřebné informace po netu a nakonec mi jako nejlepší řešení připadl GlusterFS.
Nejprve je potřeba si stáhnout potřebné soubory:
wget http://ftp.gluster.com/pub/gluster/glusterfs/fuse/fuse-2.7.4glfs11.tar.gz
wget http://ftp.gluster.com/pub/gluster/glusterfs/2.0/LATEST/glusterfs-2.0.9.tar.gz
a doinstalovat knihovnu libibverbs
yum install libibverbs-devel
Nejprve jsem soubory rozbalil pro standardní postup při kompilaci, ale pak jsem si povšiml, že oba balíčky obsahují .spec soubory - tak jsem je zkusil přeložit pomocí rpmbuild - nejprve "fuse".
rpmbuild -ta fuse-2.7.4glfs11.tar.gz
a po úpěšném překladu jsem vytvořená rpm-ka z adresáře /root/rpmbuild/RPMS/x86_64 nainstaloval (jsou zapotřebí fuse, fuse-devel a fuse-libs). Nejprve jsem však odinstaloval původní fuse
yum remove fuse
V dalším kroku jsem vytvořil rpm-ka glusters
rpmbuild -ta glusterfs-2.0.9.tar.gz
a potom všechny vzniklé balíčky nainstaloval.
Při konfiguraci jsem ze začátku tápal, ale potom jsem někde vygooglil informaci o existenci programu glusterfs-volgen. Takže nakonec to bylo strašně jednoduché:
glusterfs-volgen --name teststore --raid 1 192.168.1.100:/mnt/storage 192.168.1.200:/mnt/storage
kde volba "--raid 1" říká, že se vytvoří mirror z diskových oblastí /mnt/storage na serverech 192.168.1.100 a 192.168.1.200. Vzniknou celkem tři konfigurační soubory - soubor "store-tcp.vol" se přejmenuje na "glusterfs.vol" a zkopiruje do /etc/glusterfs/ na klientském počítači, soubory 192.168.1.100-store-export.vol a 192.168.1.200-store-export.vol se zkopírují na odpovídající servery taktéž do adresáře /etc/glusterfs/, ale pod jmenem glusterfsd.vol. Na obou serverech se potom spustí export pomocí příkazu
service glusterfsd start
a samozřejmě pro zajištění automatického startu po bootu i
chkconfig --level 2345 glusterfsd on
Když servery běží, je možné již namontovat exportovaný adresář na klientský počítač
mount -t glusterfs /etc/glusterfs/glusterfs.vol /mnt/netmirror
od tohoto okamžiku by vše, co se na klientském počítači zkopíruje do adresáře /mnt/netmirror, se objeví na obou serverech v adresářích /mnt/storage (samozřejmě, že jména adresářů nejsou závazná, jsou uvedeny jen jako příklad). Při testování je však třeba si uvědomit, že synchronizace obsahu adresářů neprobíhá přímo mezi servery, ale vždy přes klientský počítač. Proto je potřeba všechny změny provádět z klientského počítače a na serverech jen simulovat výpadky pomocí "service glusterfsd stop" a "service glusterfsd start".
Pro automatické namountování po bootu je možné upravit /etc/fstab, já ještě používám mezi všemi servery sdílený adresář, namountovaný pomocí NFS:
192.168.1.100:/mnt/Disk1/servery /mnt/share nfs defaults 0 0
/etc/glusterfs/glusterfs.vol /mnt/storage glusterfs defaults 0 0
Fedora 13
V této verzi se již GlusterFS nemusí kompilovat, je plně funkční i při instalaci z balíčků.
yum install fuse fuse-libs fuse-devel glusterfs-*
Konfigurace je stejná jako v předchozí části.
V současné době již provozujeme několik VM serverů, které sdílejí data přes zmíněný GlusterFS celkem bez problémů (snad s jedinou vyjímkou - Cacti, u kterého jsem cca 4500 .rrd souborů neprozřetelně umístil do jednoho adresáře bez stromové struktury, při 5-minutovém cyklu nějak nestíhá.... ). Ale narazil jsem na jiný problém. Jako platformu pro VM jsem zvolil Citrix XenServer, a ten GlusterFS nepodporuje. Takže obrazy VM musím mít připojené přes NFS, a to zase nepodporuje síťový mirroring, takže vše je závislé na jednom datovém úložišti....
Rozhodl jsem se toto řešit přes DRBD, dokonce se mi základ již i podařil zprovoznit, ale v tomto případě nemám moc prostoru pro nějaké pokusničení (potřebuji mít spolehlivé řešení hned od začátku), takže zatím mi nezbývá, než tuto část odložit na později a zatím se spokojit s tím původním NFS řešením z jednoho úložiště.
Update 14.9.2010
Dnes jsem se rozhodl že si zkusím DRBD nechat zprovoznit dodavatelsky. Oslovil jsem několik firem, uvidíme, zda uspěji.
Tak opět změna. Po konzultaci s firmou OldanyGroup, která mi za rozumnou cenu drbd nakonfigurovala, jsem kompletně přeorganizoval strukturu disků. Obě úložiště nyní mají disky v RAID5 na pěti discích (na hlavním úložišti je navíc jeden hot-spare disk). Na obou polích je nasazen LVM, kde je vytvořeno několik LV. Nad jedním LV je nasazen GlusterFS, nad dvěmi LV na každém poli je potom drbd. Ty drbd-svazky jsou potom přes iscsi exportovány a pomocí multipath namapovány do dvou XenServerů v poolu.
Obyčejné mirrory (RAID1) na bootovacích discích jsem zrušil, místo toho je datová část těchto bootovacích disků (pro boot systému mám jen cca 20GB velkou partition) mirrorována síťově opět přes drbd a využívána pro systémové účely (zálohy VM apod.). Tím pádem jsem nemusel řešit bootováni z RAIDu, které se mi nepodařilo u CentOSu zprovoznit, a protože se mi podařilo navíc i najít potřebné programové balíčky na přídavných repozitářích pro CentOS, došlo k návratu k původní myšlence a obě úložiště nyní "jedou" na CentOS 5.5 (viz sekce CentOS.
Poslední, osmý disk na hlavním úložišti je využit samostatně pro méně důležitá data (provozní údaje dle zákona 485/2005Sb, remote syslog, apod.).
Konfigurace drbd a iscsi-target zde nebude popsána, jelikož toto není moje tvorba a byla zprovozněna dodavatelsky.