Fórum Root.cz
Hlavní témata => Server => Téma založeno: racchek 02. 09. 2019, 11:54:28
-
Pole mám rozdělený viz. niže.
Potřeboval bych z md125 uříznout kus místa a to vyhradit třeba na vytvoření nové mdX a to bez ztráty dat.
je to vůbec technicky možné, nebo nějaky hint?
Filesystem Type Size Used Avail Use% Mounted on
/dev/md125 ext4 17T 1.8G 16T 1% /
devtmpfs devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs tmpfs 1.9G 8.8M 1.9G 1% /run
tmpfs tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/md126 ext4 991M 148M 777M 16% /boot
tmpfs tmpfs 379M 0 379M 0% /run/user/0
Personalities : [raid1] [raid6] [raid5] [raid4]
md125 : active raid5 sdd4[4] sda4[0] sdc4[2] sdb4[1]
17565419520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/44 pages [0KB], 65536KB chunk
md126 : active raid1 sdc3[2] sdd3[3] sda3[0] sdb3[1]
1047552 blocks super 1.2 [4/4] [UUUU]
bitmap: 0/1 pages [0KB], 65536KB chunk
md127 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0]
4193280 blocks super 1.2 [4/4] [UUUU]
-
pole mám rozdělený viz. niže.
Potřeboval bych z md125 uříznout kus místa a to vyhradit třeba na vytvoření nové mdX a to bez ztráty dat.
je to vůbec technicky možné, nebo nějaky hint?
Ano je to možné. Nejdříve je nutné zmenšit souborový systém na tom md125 device, např. pokud máte ext2/3/4, tak přes e2resize (raději menší než má být výsledný). Potom je třeba shrinknout RAID na požadovanou velikost přes mdadm --grow /dev/md125 --size=NOVA_VELIKOST_V_KB. Pak zvětšit FS na RAIDU na maximální dostupnou velikost. Pak zmenšit oddíly na kterých je RAID. Pak už nebrání nic tomu, aby se volné místo na discích využilo pro nové oddíly a vytvoření dalšího md RAIDu.
Vzhledem k tomu, že se stačí kdekoli překlepnout a problém je na světě, je vhodné před touto operací zazálohovat.
-
Vzhledem k tomu, že se stačí kdekoli překlepnout a problém je na světě, je vhodné před touto operací zazálohovat.
Obzvláště zmenšení partišen je docela o hubu. Pokud je tazatel začátečník (což asi je), pak bych doporučoval to nechat někomu zkušenějšímu.
-
Vzhledem k tomu, že se stačí kdekoli překlepnout a problém je na světě, je vhodné před touto operací zazálohovat.
Obzvláště zmenšení partišen je docela o hubu. Pokud je tazatel začátečník (což asi je), pak bych doporučoval to nechat někomu zkušenějšímu.
S tím se nedá než souhlasit.
Každopádně riziko zmenšení oddílů je vhodné řešit podobně jako u zmenšování FS. Raději zmenšit md RAID více s rezervou, pak zmenšit oddíly na požadovanou velikost, pak zvětšit RAID na maximální dostupné misto pres --size=max, nakonec zvětšit FS na maximum možného a je hotovo.
-
Obzvláště zmenšení partišen je docela o hubu. Pokud je tazatel začátečník (což asi je), pak bych doporučoval to nechat někomu zkušenějšímu.
S tím se nedá než souhlasit.
Každopádně riziko zmenšení oddílů je vhodné řešit podobně jako u zmenšování FS. Raději zmenšit md RAID více s rezervou, pak zmenšit oddíly na požadovanou velikost, pak zvětšit RAID na maximální dostupné misto pres --size=max, nakonec zvětšit FS na maximum možného a je hotovo.
Chtel jste rict nejprve zmensit FS na mensi nez je treba, pak zmensit md na pozadovanou velikost a nasledne zvetsit FS do autodetekovaneho volneho prostoru :-)
-
Obzvláště zmenšení partišen je docela o hubu. Pokud je tazatel začátečník (což asi je), pak bych doporučoval to nechat někomu zkušenějšímu.
S tím se nedá než souhlasit.
Každopádně riziko zmenšení oddílů je vhodné řešit podobně jako u zmenšování FS. Raději zmenšit md RAID více s rezervou, pak zmenšit oddíly na požadovanou velikost, pak zvětšit RAID na maximální dostupné misto pres --size=max, nakonec zvětšit FS na maximum možného a je hotovo.
Chtel jste rict nejprve zmensit FS na mensi nez je treba, pak zmensit md na pozadovanou velikost a nasledne zvetsit FS do autodetekovaneho volneho prostoru :-)
Chtěl jsem říct zmenšit FS na menší než je třeba, pak zmenšit RAID na menší než je třeba (ale větší než je FS), pak zmenšit oddíly jak je potřeba, pak natáhnout RAID na novou maximální dostupnou velikost, pak natáhnout FS na novou maximální dostupnou velikost. Pak vytvářet nové oddíly a nový RAID.
-
se vykašli na nějaký takový harakiri.
to udělej celé od začátku. A zahoď md raid a udělej si tam zfs raid :-)
-
to udělej celé od začátku. A zahoď md raid a udělej si tam zfs raid :-)
Naprostý souhlas. 16TB na MD RAID5 bych nedával. Jenom resync po výměně disku bude nekonečný... ZFS je v pohodě, resyncuje jen bloky s daty, při nezaplněném filesystému (což dle df tak vypadá) je resync nesrovnatelně rychlejší.
-
[...] 16TB na MD RAID5 bych nedával. Jenom resync po výměně disku bude nekonečný [...]
resync (s RAID6) mdadm cca 1den, to neni zrovna nekonecne ;-)
-
mám stejně velké pole doma a vždy když s nim něco dělám tak trnu zda to doběhne :-D
Nicméně to zfs je rychlejší a daleko modernější než md raid. Kdybych dokázal sehnat disky, kam bych odlil 16tb dat tak bych to doma taky předělal na zfs :-)
-
resync (s RAID6) mdadm cca 1den, to neni zrovna nekonecne ;-)
Konkrétní systém:
zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 24.5T 1.85T 22.6T - 19% 7% 1.00x ONLINE -
zpool status
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1031176 ONLINE 0 0 0
ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0J25NCZ ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
ata-TOSHIBA_HDWD130_78FVP49AS ONLINE 0 0 0
ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1315714 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1327418 ONLINE 0 0 0
ata-TOSHIBA_DT01ACA300_55C60GEGS ONLINE 0 0 0
mirror-3 ONLINE 0 0 0
ata-WDC_WD60EFRX-68L0BN1_WD-WX11D77K745H ONLINE 0 0 0
ata-ST6000VN0041-2EL11C_ZA1994N9 ONLINE 0 0 0
mirror-4 ONLINE 0 0 0
ata-TOSHIBA_HDWE160_17ARK09JF56D ONLINE 0 0 0
ata-WDC_WD60EFRX-68L0BN1_WD-WX51D77EYZCS ONLINE 0 0 0
mirror-5 ONLINE 0 0 0
ata-TOSHIBA_HDWN160_57GGK0CWFPAE ONLINE 0 0 0
ata-ST6000VN0041-2EL11C_ZA199FF1 ONLINE 0 0 0
Pole je téměř prázdné (jako má tazatel), resilvering po výměně vadného disku zabere do 10 minut.
Ve stejném serveru i MD RAID10 z 8 disků:
Filesystem Size Used Avail Use% Mounted on
/dev/md6 17T 11T 6.1T 64% /mnt/raid
Resync vadného disku skoro celý den, samozřejmě obojí za provozu. Taková doba bez redundance je dost nekonečná :-) A je to RAID10 (ne 5 či 6), takže resync podstatně rychlejší než RAID5/6.
-
se vykašli na nějaký takový harakiri.
to udělej celé od začátku. A zahoď md raid a udělej si tam zfs raid :-)
Tazatel přišel s tím, že pole potřebuje zmenšit. Už umí ZFS pool zmenšit?
-
mno a odpověď na jeho otázku byla že se na to má vykašlat a udělat to znovu od začátku.
navíc za zfs by si udělal nový pool a ten si přimountoval kam by chtěl
ale jeslti ti přijde lepší se patlal se zmenšováním raidu, na kterym je ještě ke všemu root partition tak mu odpověz lépe
-
navíc za zfs by si udělal nový pool a ten si přimountoval kam by chtěl
My nevíme proč to chtěl, třeba opravdu potřeboval surový přístup na disk a ne ZFS pool. (například u databází/rainbow tabulek které si místo spravují samy overhead inteligentního FS jako je ZFS brzdí a nejlepší je mít to přímo na disku)
ale jeslti ti přijde lepší se patlal se zmenšováním raidu, na kterym je ještě ke všemu root partition tak mu odpověz lépe
Již bylo odpovězeno, zmenšit FS, zmenšit RAID, zmenšit partition.
-
[...] Resync vadného disku skoro celý den, samozřejmě obojí za provozu. Taková doba bez redundance je dost nekonečná :-)[...]
nezpochybnoval sem ze je zfs rychlejsi, ale ze u mdadm raid6 doba 1den na sync po vymene neni nekonecna a behem sync neni bez redundance, ale je na tom jako nedegradovanej "jako raid5"...
-
Ano, ale tazatel má RAID5 a jeho resync 17TB při 4 discích bude také minimálně 1 den.
-
nezpochybnoval sem ze je zfs rychlejsi
Přesněji řečeno nezaplněné ZFS je rychlejší (protože syncuje jenom skutečná data, ne i zbytečně volné místo). Pokud bude mít ten RAID přiměřeně zaplněný (asi si nekupoval 16TB storage proto aby tam měl 15 TB nepoužitého volného místa :), tak se ta data musí zkopírovat tak jako tak a vyjde to nastejno.
-
nezpochybnoval sem ze je zfs rychlejsi
Přesněji řečeno nezaplněné ZFS je rychlejší (protože syncuje jenom skutečná data, ne i zbytečně volné místo). Pokud bude mít ten RAID přiměřeně zaplněný (asi si nekupoval 16TB storage proto aby tam měl 15 TB nepoužitého volného místa :), tak se ta data musí zkopírovat tak jako tak a vyjde to nastejno.
Přesně to jsem chtěl napsat po tom, co redustin posílal porovnání resync ZFS poolu zaplněného ze 7% oproti md RAID zaplněného ze 64%:
Konkrétní systém:
zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 24.5T 1.85T 22.6T - 19% 7% 1.00x ONLINE -
...
Ve stejném serveru i MD RAID10 z 8 disků:
Filesystem Size Used Avail Use% Mounted on
/dev/md6 17T 11T 6.1T 64% /mnt/raid
Resync vadného disku skoro celý den, samozřejmě obojí za provozu.
Až to provede na podobně zaplněném ZFS, bude to mít větší relevanci. Disková pole o kapacitě větších TB nebo desítek TB se určitě nepořizují proto, aby zely prázdnotou a aby se na nic pak zkoušely simulace syncnutí disku po výpadku.
-
Ano, to pole je zaplněné jen z 10%. Jde o reálné použití, ZFS pole bylo od začátku připravené pro přesun toho MD raidu. Protože přesun vyžaduje přejít z hardlinkovaného backuppc3 na metadatové backuppc4, zatím němu stále nedošlo. Mezitím v ZFS postupně odešly dva disky (na začátku již měly něco naběháno). Point je v tom, že rebuild trval řádově kratší dobu, než by trval rebuild celého disku v MD raidu. Rychlost zápisu při synchronizaci ZFS i MD byla srovnatelná. Čekal jsem hit na ZFS kvůli kopírování na úrovni filesystému, zatímco MD jede sekvenčně (RAID10), ale zřejmě je to na disku dobře uložené. Jelo to v klidu 100-150MB/s pro SATA, což je standardní limit disku.
Samozřejmě až bude ZFS plné, rozdíl nebude žádný. jenže stejně jako málokdo (dlouhodobě) provozuje pole zaplněné z 10%, málokdo buduje pole, které je hned na začátku plné...
-
Samozřejmě až bude ZFS plné, rozdíl nebude žádný. jenže stejně jako málokdo (dlouhodobě) provozuje pole zaplněné z 10%, málokdo buduje pole, které je hned na začátku plné...
...a málokdo buduje pole ze starých disků, které odcházejí chvíli po vybudování pole, dříve než je kapacita pole využita.
Prostě vaše srovnání od počátku smrdělo na sto honů ;)
-
Ta chvíle už je nějaké dva roky :-)
-
Ta chvíle už je nějaké dva roky :-)
Jo a po dvou letech je to pole na 7% zaplnění své kapacity. Prostě úplně typické dvouleté pole, se staršíma diskama už v době prvního sestavená, v podstatě prázdné, za tu dobu už 2 disky měněné, elektriku zbytečně spotřebovávající 12 disků, když by na žitou kapacitu stačil jediný. Jak říkám, úplně typický příklad, na kterém se ukazuje resync disku po havárii, ale očividně k ničemu jinému praktickému to neslouží ;D
-
Představ si, že reálný život není jak z učebnice správců.
1) konsolidace dvou serverů na jeden do lxc kontejnerů. Disky dvou původních MD raid polí (pole A, pole B) přesunuté do 24-bay bedny
2) Přesun hodně dat z pole A do velkého pole B, protože A bylo plné.
3) Pole A překlopené do ZFS. Použito pár nových disků, aby šel přechod udělat.
4) Zbylé disky z pole A přidány do ZFS, aby bylo ZFS dost velké pro data z B.
5) Testování přechodu z backuppc3 na backuppc4 pomocí toho velkého pole. Ukazuje se, že konverze je velice pomalá (pole má stovky miliónů hardlinků) a zálohování by muselo být shozené příliš dlouho.
6) Testování zvol pro přesun celého XFS bez potřeby likvidace hardlinků - běží však příliš pomalu. Při tom muselo být ZFS samozřejmě dostatečně velké, aby se to tam celé pole B vešlo.
7) Odstranění 17TB zvol - tedy ZFS zůstalo plné jen z 10%.
8 ) Mezitím nárůst jiných priorit, stávající řešení běží OK, ponecháno jak je.
ZFS pole je je pro data devel serveru (testy, CI, různé verze), běží na něm několik klonů anonymizované produkční DB pro devel. Výkonově klíčové DB mají data samozřejmě na SSD.
Celé to trvalo dlouho a od té doby také uplynulo dost času. Je spoustu jiné práce, než řešit pár nadbytečně běžících disků. Jednak je nelze ze ZFS odstranit, jednak se budou hodit, protože k přesunu z pole B dojde, až backuppc4 nabere trochu historie a bude možné pool z backuppc3 nechat jen jako soubor s obrazem přes loopback.
Samozřejmě z 10 disků jich časem pár umřelo, to je úplně normální. Nahrazují se rovnou dvojnásobnými, na nyní skoro prázdném ZFS jsou syncnuté za chvíli (narozdíl od MD raidu).
Takže odlož svou věšteckou kouli, máš ji rozbitou.
-
Představ si, že reálný život není jak z učebnice správců.
...
Takže odlož svou věšteckou kouli, máš ji rozbitou.
Já se nebavil o redustinovi, ale o tom, že redustin tvrdí, že dvouleté pole je typicky zaplněné na 7%, do dvou let se v něm běžně mění 2 disky, je složené od startu ze starých použitých disků a že je lepší aby na něm bylo ZFS než md RAID, protože resync ZFS je oproti md bleskový. Ne není, protože typicky taková pole neuvidíte.