Linux adatkezelési képességei avagy RAID, LVM és állományrendszerek

Linux adatkezelési képességei avagy RAID, LVM és állományrendszerek

Szalai Ferenc [email protected] Creator:inkscape 0.44.1

http://www.avaxio.hu

Nézz magadba és rendszereidre!

Creator:inkscape 0.44.1


Mi a tipikus konfiguráció?



1 szerverben, 1 vagy maximum néhány merevemez. Nincs redundancia!



Azán, ha megtörténik a baj



Sírás van



vagy mentés

legyen mentés! Creator:inkscape 0.44.1


Előzzük meg a bajt! Használjunk hibatűrő megoldásokat!



Olcsó merevlemezekből építkezzünk (SATA, ATA)



RAID: Redundant Array of Inexpensive Disks (David A. Patterson, Garth A. Gibson and Randy Katz, 1988 junius)



RAID szintek



Elemi egység: BLOKK



RAID 0 - stripe

Nincs redundancia! Creator:inkscape 0.44.1


RAID 0 Sebességre hajtunk!



RAID 1 - mirror



RAID 5 Parittás (pl. Hamming ECC) a te barátod!



Jó nekem a 1TB-os lemez?



Problémák nagy lemezekkel Nagy sebesség eltérések a lemez elején vs végén (20-30%) ● Hosszú RAID szinkronizációs idő ● Egybe vesztünk sokat ● Élettartam problémák (<< 300.000 óra két hiba között) ●



A dupla merevlemez meghibásodások száma arányos a merevlemez számának 3-adik hatványával!



Sok lemeznél a RAID5 nem megoldás! Legalább RAID6 legyen!



RAID6 Parittásbol sosem elég! Legyen rögtön kettő!



Kevert RAID szintek Alap szintek kombinálhatók. ● Pl: RAID 0+1, RAID1+0 ●



Az örök dilemma: Hardver vagy softver RAID?



3ware 9560 PCI-E RAID vezérlő Vs. Linux szoftver RAID







Linux szoftver RAID HOGYAN



Kell egy eszköz!



MDADM a te barátod



mdadm --create --auto=yes \ --level=5 --raid-devices=3 \ –-spare-devices=1 \ /dev/md0 /dev/sdn /dev/sdk \ /dev/sdl /dev/sdm mdadm –-stop /dev/md0



cat /proc/mdstat Personalities : [raid0] [raid6] [raid5] [raid4] md3 : active raid5 sdl[4] sdm[3](S) sdk[1] sdn[0] 976772992 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_] [>....................] recovery = 0.0% (241152/488386496) finish=134.9min speed=60288K/sec unused devices: <none>



mdadm --detail /dev/md3 /dev/md3: Version : 00.90.03 Creation Time : Sat Oct 13 07:03:46 2007 Raid Level : raid5 Array Size : 976772992 (931.52 GiB 1000.22 GB) Device Size : 488386496 (465.76 GiB 500.11 GB) Raid Devices : 3 Total Devices : 4 Preferred Minor : 3 Persistence : Superblock is persistent Update Time : Sat Oct 13 07:03:46 2007

State : clean, degraded,

recovering

Active Devices : 2 Working Devices : 4 Failed Devices : 0 Spare Devices : 2 Layout : left-symmetric Chunk Size : 64K Rebuild Status : 0% complete UUID : f1b7a549:ceee3fb8:8cf68a7e:6edfe29a Events : 0.1 Number Major Minor RaidDevice State 0 8 208 0 active sync /dev/sdn 1 8 160 1 active sync /dev/sdk 4 8 176 2 spare rebuilding /dev/sdl 3

8

192


-

spare /dev/sdm


mdadm –-fail mdadm –-remove mdadm –-add mdadm –-assemble –-scan /dev/md0 mdadm –-monitor –-demonise – scan (/etc/default/mdadm) (/etc/cron.d/mdadm -> checkarray) Creator:inkscape 0.44.1


mdadm --detail –-scan >> /etc/mdadm/mdadm.conf ARRAY /dev/md3 level=raid5 numdevices=3 spares=2 UUID=f1b7a549:ceee3fb8:8cf68a7 e:6edfe29a



Figyeljünk a nevekre! /dev/disk/by-id



Daraboljunk intelligensen! (Linux Volume Management (LVM) azaz PV, VG, LV és egyéb állatfajták)



Emlékeztető: Még mindig blokk az elemi egység





Fizikai kötetek - PV pvcreate /dev/md3 pvcreate /dev/hda1 pvscan PV /dev/md3 lvm2 [931.52 GB] Total: 1 [931.52 GB] / in use: 0 [0 [931.52 GB]

] / in no VG: 1

pvresize pvdisplay pvremove



Az LVM egyik legfontosabb előnye a méretgazdálkodás



Kötet csoportok – VG vgcreate barmi /dev/md3 /dev/hda1 vgs VG #PV #LV #SN Attr VSize VFree barmi 1 0 0 wz--n- 931.52G 931.52G

vgdisplay vgrename vgremove



Logikai kötetek - LV lvcreate -i 2 -n var -L 300M barmi /dev/barmi/var lvs LV VG Attr LSize Origin Snap% Move Log Copy% var barmi -wi-a- 300.00M lvdisplay lvremove lvresize lvreduce Creator:inkscape 0.44.1


Figyelemre méltó apróság: snapshot



lvcreate –-snapshot -L 512M \ -n backup /dev/sda1 a snapshot készítése előtte állítsunk le minden I/O műveletet ● a méret az eredeti kötet 10-20% kell csak legyen ●





Paraméter /sys/block/sda/queue/max_sectors_kb /sys/block/sda/queue/nr_request s blockdev –setra /sys/block/sda/queue/scheduler

Default Opt 128 64 128 512 256 16384 deadline cfq

ionice -c2 -n0



Melyik állományrendszert használjunk?



Az esetek 90%-ban az ext3 tökéletesen megfelelő a maradék 10%-ban használjunk XFS-t



Minden ellenállás hasztalan



Nem lehet végtelen mennyiségű merevlemezt egy szerverbe pakolni!



Adatorientált tervezésre van szükség! Vigyük a merevlemezelet a szerveren kívülre



(legalább) Két megközelítés van:



BLOKK szintű (SAN=Storage Area Network)



Állományrendszer szintű (NAS=Network Attached Storage)



NAS állomány rendszer a adattároló szerver oldalon ● Protokollok: NFS, SMB ● Problémák ●

– – – –

Bonyolult protokoll alacsony szintű biztonság hibatűrés és terhelés kiegyenlítés nehezen megvalósítható gyenge klaszerizációs képességek



SAN állomány rendszer a kliens oldalon ● Protokollok: FC, iSCSI, AoE, SRB over Inifinband ● Problémák: ●

– – –

gyenge biztonság FC: dedikált hálózat kell hozzá gyenge klaszterizációs képességek



Hova tovább, tovatovább?



Klaszterizált megoldások:



Lustre, GlusterFS, StarFish, stb. szokjuk a szavakat



Kalandra fel!



Linux adatkezelési képességei avagy RAID, LVM és állományrendszerek

Recommend Documents