Dotaz: HW RAID5 a LVM

[zigi]

Zdravim,

mam LVM (1 PV, 1 VG, x LV) na hardwarovem RAID5 a mel bych dve otazky, kde ta druha jak si vyplyva z te prvni:

1. Je lepsi umistit PV primo na cely disk nebo vytvorit partition tabluku PT (GPT) a jednu partisnu pro cele LVM?

2. Jak se zvetsi partisna pro LVM?  (v mem pripade po rozsireni RAID5 o novy disk)

  - pomoci parted a jeho resize to nejde - skonci to chybou Error: Could not detect file system.
  - zatim me napadly tri moznosti jak docilit rozsireni:
    a) zrusit soucasnou partisnu a hned vytvorit novou pres cely nove dostupny diskovy prostor a pak pouzit pvresize (ale nevim jak moc je to bezpecne pro data)
    b) vytvorit novou partisnu a PV s kazdym nove pridanym diskovym prostorem a tyto nove PV pridavat do VG (ale to je takove reseni, ktere se mi moc nelibi)
    c) vykaslat se na PT (viz. prvni otazka) a pak tedy rovnou pouzit pvresize

Diky za vase nazory a preji pekny den

Odpovědi

[Heron]

V fdisku lze smazat původní partition a vytvořit větší. Je ovšem nutné zachovat počátek. Fdisk nic nedělá s daty ani FS, tato operace je bezpečná. Pak se zvětší PV.

PV přímo na poli lze použít též. Pak odpadne šachování s partition tabulkou. Jinak je to celkem jedno.

[zigi]

fdisk nemuzu pouzit kvuli GPT a velikosti pole nad 2TB.

[Heron]

Jasně, to byl jen příklad. Stačí použít cokoliv co zachová počátek a nesahá na obsah partition.

[zigi]

Par nazoru ohledne LVM - jedna partisna vs. cely disk: http://serverfault.com/questions/101215/linux-lvm-single-or-multiple-harddisk-partitions.

Ale poznamky jako jsou tyto:

- Good Idea to at least have a single disk-encompassing partition so that various tools or people know there's something there.
- Many tools will detect the disk as being unpartitioned and you can happily blow it away without realizing it.

ztraci vyznam pri pouziti HW RAID5.

[MMichal]

Vytvoreni partition tabulky ma tu vyhodu, ze kazdy vidi, ze na tom disku (LUNu) neco je (a taky co to je) a neni prazdny. Pak je ale dobre umistit pocatek partition podle velikosti stripu.

Michal

[zigi]

Vytvoreni partition tabulky ma tu vyhodu, ze kazdy vidi, ze na tom disku (LUNu) neco je (a taky co to je) a neni prazdny.

To je mi jasne a beru to jako vyhodu, ale ja to hlavne resim z pohledu budouciho rozsirovani diskoveho prostoru a pak PV/VG ...

Pak je ale dobre umistit pocatek partition podle velikosti stripu.

Mohl byste to trochu rozvest. Co je mineno stripem? V PV se pouzivaji jako zakladni kameny PE...

[MMichal]

Tim je mysleno, aby partition zacinala na zacatku stripu na tom HW RAID5 a ne nekde uprostred.

[zigi]

Jeste se objevila dalsi otazka:

3. Jak je to s velikosti metadat VG?

  a) Kolik LV ci PV muze pri vychozim nastaveni obsahovat?
  b) Kolik mista (bytu) zabiraji metadata pro jeden LV/PV?
  c) Da se prostor pro metadata dodatecne zvetsit?
  d) Nebo je lepsi je ukladat mimo VG (PV) nekde na jinem disku a filesystemu?

  z dokumentace RHEL - LVM

You can specify the size of metadata area with the --metadatasize. option of the pvcreate command. The default size is too small for volume groups with many logical volumes or physical volumes.

Kolik je "many"?

[zigi]

Příloha:

• LVM_Limits_White_Paper_V4.pdf (122514 bytů)

V prilozenem dokumentu jsou uvedene urcite limity pro LVM na HP-UX (pocet LV a PV, zavislost velikosti PE a VG) - jak je to s limity na Linuxu?

[zigi]

Tyto dva zdroje se napriklad neshoduji v tom, zda je limitovana maximalni velikost LV a zda je zavisla na velikosti PE:
http://wiki.novell.com/index.php/Linux_Data_Management#LVM2_Limits
http://www.walkernews.net/2007/07/02/maximum-size-of-a-logical-volume-in-lvm/

[zigi]

z http://tldp.org/HOWTO/LVM-HOWTO/lvm2faq.html:

4.1.13. What is the maximum size of a single LV?

The answer to this question depends upon the CPU architecture of your computer and the kernel you are a running:

For 2.4 based kernels, the maximum LV size is 2TB. For some older kernels, however, the limit was 1TB due to signedness problems in the block layer. Red Hat Enterprise Linux 3 Update 5 has fixes to allow the full 2TB LVs. Consult your distribution for more information in this regard.

For 32-bit CPUs on 2.6 kernels, the maximum LV size is 16TB.

For 64-bit CPUs on 2.6 kernels, the maximum LV size is 8EB. (Yes, that is a very large number.)

[zigi]

Příloha:

• LINUX_lvm_whitepaper_SuSE.pdf (380862 bytů)

Z appendixu C, viz. priloha:

Currently up to 99 volume groups with a grand total of 256 logical volumes can be created. The limit for the logical volumes is not caused by the LVM but by Linux 8 bit device minor numbers. This means that you can have 99 volume groups with 1−3 logical volumes each or on the other hand 1 volume group with up to 256 logical volumes or anything in between these extreme examples.

Z toho vyplyva ze pro 1 VG, 1 PV muzu mit az 255 LV -> staci vychozi velikost metadat pro vsech 255 LV?

[Lol Phirae]

Nebylo by jednodussi to vyzkouset?

[zigi]

No nic jineho mi nezbyde. Ale chtel jsem znat dopredu teoreticke hranice a zkusit rozjet akademickou diskuzi

[zigi]

No tak jsem na 2,73TB poli vytvoril 270 10GB LV oddilu. Metadata pro VG v /etc/lvm/backup zabiraji 86kB.

brw-rw---- 1 root disk 253, 272 bře 13 14:52 vg_hw_raid5-lv_270

Podle vyse uvedeneho vypisu to vypada, ze 8bit limit pro cisla zarizeni uz neplati (nemel by nekdo blizsi info ohledne cisel zarizeni, diky) a neznamou tedy zustava velikost metadat pro VG.

[zigi]

Jen mensi doplneni, uvedene limity se tykaji LVM1 (napr. max. pocet PE = 64k). U LVM2 neni zadne omezeni/vazba mezi velikosti volumu a velikosti/poctem PE.

[zigi]

Ahoj, dovolil bych si znovu otevrit tento muj stary dotaz, nebot behem uplynuleho roku se objevily dalsi otazky, ve kterych jak si nemam jasno.

1) Jakou konfiguraci (pocet disku) doporucujete pro RAID 5?

  - co jsem se docetl ruzne po internetu, tak z hlediska optimalniho zarovnani dat se jevi jako nejvyhodnejsi kombinace ze tri (dva datovy) a peti (ctyri datovy) disku

  - pak se veskere vypocty ohledne zarovnani dat toci kolem mocniny dvou

2) Ma cenu se vubec zabyvat velikosti stripu(chunku), sirkou stripes a zarovnanim dat z pohledu LVM ci filesystemu?

  - pokud provedu optimalizaci pri vytvoreni pole je to OK, ale jakmile do RAID5 pridam disk, puvodni nastaveni/snaha o optimalizaci zarovnani dat muze jit k sipku, protoze:

    - u LVM to vyzaduje nekolik akci typu lvresize,pvresize,pvmove

    - u partisny to znamena posunout jeji zacatek, ale problemem je kam pred tim odsypat data

    - filesystemy typu ext? by se meli dat prizpusobit pomoci tune2fs, ale podle to take bude zaviset na predchozich dvouch bodech

3) Kontretni pripad, ktery tedka resim a zadam vas o radu a vase nazory:

  - HW RAID5 na radici LSI 9260i4 s 512MB pameti s BBU

  - 4x 1TB SATA disk (3x data, 1x parita)

  - hlavni parametry nastaveni: WriteBack cache, Direct I/O, vypnuta disk cache, read policy - adaptive read ahead

  - RAID se v budoucnu nebude rozsirovat pridanim disku, ale pouze pomoci vymeny 1TB disku za vetsi (>2TB)

  - nad timto RAIDem (virtualnim diskem VD) bude LVM, ktere bude pouzito pro virtualizovane stroje (vlastni volume per VM, ci jako spolecne uloziste obrazu pro jednotlive VM)

  a) Jak velky strip/chunk nastavit pro uvedeny RAID?

    - osobne se rozhoduji mezi 128kB a 256kB (radic zvlada rozsah 8kB az 1MB)

  b) Sirka stripes?

    - zavisi na odpovedi na predchozi otazku, tedy napr. 384kB / 768kB

  c) Zarovnani LVM a velikost PE, neboli jak eliminovat overhead pri zapisu?

    - opet zavisi na odpovedi na otazku a)

    - zacatek VG nastavit na nasobek velikosti/sirky stripe

    - velikost PE nastavit na nasobek velikosti/sirky stripe, tedy napr. 4224kB / 4608 kB, ale tyto cisla nejsou mocninou 2, jak to vyzaduje manualova stranka

Dekuji za vase nazory a rady