SAN Disk Linux -on


Tagek: SAN, Linux, RedHat,
Írta: toshy
Publikálva: 2013-07-19 14:51:48



SAN disk hozzáadása meglévő Linux rendszerünkhöz.


A storage oldalon el kell készíteni a volume-ot. Ezt nem mutatnám be, mert ahány storage tároló rendszer létezik annyiféle képen lehet. Jelene esetben az IBM Storwize v7000 -el dolgozom, de ez lehet bármilyen más SAN tároló.
Szóval ott áll készen és Online állapotban egy volume, mondjuk így kezdésnek egy 200 GB -os.
Ennek minden esetben lesz egy azonosítója UID -ja amit meg jegyzünk mert a későbiekben szükségünk lesz rá.

Következik a SAN switch-eken a Fabric zona -zása.
Össze kell zonázni a server FC portjait a tároló FC portjaival.
Nem vagyok egy nagy storage -os, de az ajánlás az hogy host páronként külön zónát hozzunk létre.

Szóval ez valahogy így nézz ki.
Először le gyártjuk (ha még nincs meg) a host alias-át. Ehhez tudnunk kell a port WWN -jét.
Ezt megtudhatjuk a dmesg üzenetekből is, de ha fent van a sysfsutils csomag akkor a következő parancs részletes információt ad:

systool -c fc_host -v


Mégis legegyszerűbb ha tudjuk a SAN switch melyik portjába van bedugva, akkor a switchshow paranccsal láthatjuk a portokon észlelt wwn-eket.

Jelen esetben ez legyen: AA:BB:CC:00:DD:EE:FF:00

Ne felejtsük el, hogy nagyobb összetettebb, több switchből, és több körből álló SAN hálózatokon a principal funkcióval bíró switcheken zónázunk.



Tehát a parancs:

alicreate hostname_p1, AA:BB:CC:00:DD:EE:FF:00



Ha nem lenne meg a tároló alias-a akkor azzal is ugyanazt kell tegyük.
Legyen ennek most: AA:BB:CC:11:DD:EE:FF:00



alicreate storage_p1, AA:BB:CC:11:DD:EE:FF:00



Most össze zónázzuk, és hozzá adjuk a portokat. Szerencsére zona létrehozásnál meg adhatjuk az egyik résztvevőt, és így sikerül meg spórolni egy zoneadd parancsot:


zonecreate storage_hostname, storage_p1

zoneadd storage_hostname, hostname_p1

zoneshow -al ellenőrizhetjük, hogy hogy nézz ki.

Ha kész van akkor hozzá kell adni az aktuális konfighoz, ami már éppen van.

cfgadd configname, storage_hostname


Elmentjük.

cfgsave

És aktualizáljuk:

cfgenable configname

Ezt meg kell tenni a második lábbal is ami elvileg fizikailag és logikailag is külön körön van. Ha több kártyánk, vagy több portunk van akkor természetesen többször is meg kell, illetve lehet csinálni. Minden azon múlik, hogy mekkora fokú redundanciát, illetve performanciát akarunk / tudunk kihozni az adott környezetből.

No ha a zónázás elkészült, akkor a tárolón meg kell jelenjen a host mindkét portja a két körröl. Ezt hozzá MAP -eljük a már elkészült 200 GB volume -unkhoz. Ellenőrizzük a tárolón a host státuszát, a port státuszát, és a volume státuszát is.

Ellenőrizzük a lokális disk-ek azonosítóját, hiszen a multipath azt is behúzza.


scsi_id -g -u /dev/sda

az itt kapot azonosítót az /etc/multipath.conf -ban blacklisteljük


blacklist {
	wwid [ide jön a kapot azonosító]
	devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
	devnode "^(hd|sd)[a-z][0-9]*"
}



Ha minden rendben, akkor győződjünk meg arról, hogy multipath service indul automatikusan, és indítsuk újra a host-ot. Újra boot után látnunk kell a felhúzott volume-ot.

multipath -F

multipath -v3

multipath -ll


36005076802808734b000000000000010 dm-2 IBM,2145
size=200G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=0 status=active
| |- 4:0:0:0 sdb 8:16 active undef running
| `- 4:0:1:0 sdc 8:32 active undef running
`-+- policy='round-robin 0' prio=0 status=enabled
  |- 5:0:0:0 sdd 8:48 active undef running
  `- 5:0:1:0 sde 8:64 active undef running


Jelen esetben azért látunk több útvonalat kettőnél, mert 4 útvonalra lett zónázva, igazából ennek nincs korlátja. Első sorban láthatjuk a tarolólóról kiosztott volume azonosítóját, ezt célszerű ellenőrizni, ha több tároló, és/vagy több volume is előfordul a környezetben. Az IBM,2145 a tárolóm azonosítója a multipath kernel modulban.


fdisk -l -el már látnunk kell a disket.


Vigyázat a sok /dev/sdx lehet ugyanaz a disk a különböző útvonalakon. Ezekhez ne nyúljunk, hanem a mapper által létrehozott disk-en dolgozzunk, hiszen ez dolgozik multipath környezetbe nekünk.


ls -alh /dev/mapper/[előző multipath által adott UID]*



Ezt a /dev/mapper/36005076802808734b000000000000010p1 disk -et lehet a továbbiakban kezelni mint meglévő merevlemezt.


Lehet rá LVM -et tenni, vagy csak simán file rendszert létrehozni, és megformázni attól függően, hogy kinek mi a terve vele a továbbiakban. Mivel én csak IO méréseket akarok rajta végezni, ezért én most simán csak file rendszert hoztam rajta létre és megformáztam ext4 -re. Ezt becsatoltam az általam létrehozott /data könyvtárba. Gondoskodtam róla hogy az fstab-ba is be kerüljön.
DD -vel tesztelgettem így első nekifutásra a következő paraméterekkel:


dd if=/dev/zero of=/data/proba.dd bs=100 count=50 ibs=1M obs=1M


Ezt töbször is elindítottam egymás után és nagyjából 270 - 480 MB/s -et kaptam ebből a cirka 5GB -os teszt file írásból. Persze ez nem egy komoly tesz, és messze menő következtetéseket sem lehet belőle le vonni, hacsak azt nem hogy viszonylag jól megy. :)



Következet hát az iozone teszt. ( www.iozone.org )
Én a következő paranccsal teszteltem:



/opt/iozone/bin/iozone -R -l 5 -u 5 -r 4k -s 1G -F /data/f1 /data/f2 /data/f3 /data/f4 /data/f5



A következő eredménnyel zárult:

"Throughput report Y-axis is type of test X-axis is number of processes"
"Record size = 4 Kbytes "
"Output is in Kbytes/sec"

"  Initial write "  432630.23 
"        Rewrite "  427704.72 
"           Read " 5606788.44 
"        Re-read " 5623275.94 
"   Reverse Read " 5692405.38 
"    Stride read " 5460322.50 
"    Random read " 5355024.38 
" Mixed workload " 4103462.09 
"   Random write "  238507.78 
"         Pwrite "  396704.41 
"          Pread " 4328361.38 
"         Fwrite "  570809.95 
"          Fread " 6148487.12 



Ha össze hasonlítom a dd vel végzet mérési eredménnyel akkor látszik , hogy azért köszönő viszonyban vannak itt ~430 MB/s írási sebesség jött ki. Ha a random írási sebességet nézzem akkor meg ~230 MB/s.
Vizualizálom nektek egy szép kis chart-al :)




Most pedig jöjjön az IBM által ajánlott Storewize v7000 -es finomhangolások. Először is azt írják, hogy a device szekcióból a polling_interval -t vegyük ki, és default-ból állítsuk 30-ra.



defaults {
		user_friendly_names yes
		polling_interval  30
}

Ha nincs device szekciónk akkor ugye nincs mit kivenni, de attól még állítsuk be a default-ot.


A következő beállításokat adjuk meg a model-hez a multipath.conf -ban:

device {
		vendor "IBM"
		product "2145"
		path_grouping_policy group_by_prio
		getuid_callout "/lib/udev/scsi_id --whitelisted --device=/dev/%n"
		features "1 queue_if_no_path"
		prio alua
		path_checker tur
		failback immediate
		no_path_retry "5"
		rr_min_io 1
		dev_loss_tmo 120
	}


Valamint udev rule -ok közé is kell egy szabály amivel megnöveli a time out -ot 120 sec -re. Hozzuk létre a következő file-t /etc/udev/rules.d/99-ibm-2145.rules a következő tartalommal.



# Set SCSI command timeout to 120s (default == 30 or 60) for IBM 2145 devices
SUBSYSTEM=="block", ACTION=="add", ENV{ID_VENDOR}=="IBM",ENV{ID_MODEL}=="2145", 
RUN+="/bin/sh -c 'echo 120 >/sys/block/%k/device/timeout'"



Kernel paraméterek közé is tegyük be, hogy a block scheduler noop tipusú legyen. Tehát a következő paraméter elevator=noop a /boot/grub/menu.lst kernel paraméterek közé. Természetesen futási időben is beállíthatjuk ezt:



echo noop > /sys/block/dm-2/queue/scheduler


Érdemes egy újra boot után ellenőrizni, hogy ez van-e kiválasztva.


cat /sys/block/dm-2/queue/scheduler
[noop] anticipatory deadline cfq 



Ha mindezzel megvolnánk akkor újra indítás után újra mérek egyet ugyan azokkal a paraméterekkel.
Eredmény:

"Throughput report Y-axis is type of test X-axis is number of processes"
"Record size = 4 Kbytes "
"Output is in Kbytes/sec"

"  Initial write "  531619.45 
"        Rewrite "  339071.80 
"           Read " 5521059.56 
"        Re-read " 5594080.19 
"   Reverse Read " 5653129.56 
"    Stride read " 5472874.50 
"    Random read " 5412961.75 
" Mixed workload " 4094049.97 
"   Random write "  167474.55 
"         Pwrite "  403579.92 
"          Pread " 4239081.44 
"         Fwrite "  582866.79 
"          Fread " 6171506.38 



Az írás sokkal gyorsabb lett, ellenben a random írás például sokkal lassabb. Az egészet összevéve szerintem nem lett számottevően gyorsabb. Ha a performanciát nézzük akkor nem érte meg vele foglalkozni. Azonban egy ajánlott valamiért ajánlott, és ha nem más egy esetleges szupport esetén nem kell azzal vesződnünk, hogy erre az állapotra hozzuk.



Az ajánlások és hivatalos dokumentációja a terméknek egyébként itt található.



Egyébként igen jónak találom ezeket a mért értékeket. ISCSI-n 1Gb/s -es hálózaton ami egyébként nincs terhelve úgy ~120 - 140 MB/s -et mértem. Persze nem lehet összehasonlítani a kettőt lévén az FC nem 1 Gb/s :-)



Szólj hozzá

Hozzászólások(0)