Fórum Root.cz
Hlavní témata => Software => Téma založeno: Jakub 26. 02. 2018, 08:48:53
-
Zdravím,
je možné znovu vytvořit SW raid (1) v Ubuntu 16.04, ale bez synchronizace? Tj. bez ztráty dat na discích?
-
A jak by ten raid pak fungoval, kdyby na obou discích byla jiná data?
Čistě teoreticky by mělo jít, že vyberete jeden disk jako hlavní a ten přinutíte zmirrorovat na ten druhý. Stejně mi to nepřijde jako dobrý nápad.
Určitě se nepouštějte do jakékoliv operace na živých datech, toto se vždy a bez výjimky musí dělat na zálohovaných datech.
-
Jde to lehce - vytvoris novy RAID-1 hlavne na novem/prazdnem disku s "missing" diskem (viz manualy). Naformatujes a presunes na tohle degradovane pole data. Pak na starem disku zmenis typ partisny na mdraid a pridas ho do toho pole. A po tomto ukonu pak nastane konecne vytvoreni kopie / synchronizace.
Jestli si nespletes disky, tak to je zcela bezpecny postup.
-
"RAID" a "zcela bezpecny postup pri zmenach konfigurace" jsou slova, ktera nepatri dohromady :)))))
vojak zalohuje, vojak ma....
-
Zálohy je samozřejmost, s raidem nijak nesouvisí. Nicméně přechod na raid1 postupem, který popisuje RDa, je mnohokrát vyzkoušený a spolehlivý. Ještě je pak potřeba zaktualizovat /etc/mdadm/mdadm.conf, initramfs a konfiguraci grubu před restartem do raidu, pokud jde o root partition.
-
Jestli si nespletes disky, tak to je zcela bezpecny postup.
Do chvíle, než se po spuštění synchronizace zjistí, že ten nový disk je vadný (vlastní zkušenost) :)
-
Špatně jsem popsal problém. Asi občas neplatí ráno moudřejší večera. :)
Nejde o root partition, pouze o datové úložiště.
Disky již byli společně v SW raidu, ale po kleknutí NASu se mi již nepodařilo rozchodit Ubuntu (blbá shoda náhod)
Takže jsem přišel o konfiguraci raidu. Jde mi o to, že když jsem konfiguroval raid tak to vyžadovalo synchronizaci disků, ale co si pamatuji, tak to smazalo data na obou discích, což já teď zrovna moc nechci. :)
Zálohu mám, ale je cca 1,5 měsíce stará, takže bych chtěl zachránit co se dá. :)
Otestuji postup od RDa. Vůbec mě to nenepadlo, ale teď si vzpomínám, že když jsem pročítal tutoriály na raid tak tam bylo i obnovení raidu z jednoho disku. Každopádně díky. :)
Dost i přemýšlím o HW Raid řešení, kde bych nebyl limitovaný spolehnutím na systém. Je možnost nějakého RAID HW řešení do 2 000kč? Co jsem našel, tak raid řadič od axago, ale má jen sata1...
-
Teď mě ještě napadlo, kdybych ze systémového disku zachránil složku s konfigurací raidu a vložil do "nového", jak by se systém zachoval? (Disky by byly pořád zapojeny stejně, takže by se sda/sdb/sdc nezměnilo.
-
Disky již byli společně v SW raidu, ale po kleknutí NASu se mi již nepodařilo rozchodit Ubuntu (blbá shoda náhod)
Takže jsem přišel o konfiguraci raidu. Jde mi o to, že když jsem konfiguroval raid tak to vyžadovalo synchronizaci disků, ale co si pamatuji, tak to smazalo data na obou discích, což já teď zrovna moc nechci. :)
mdadm --create --assume-clean
-
Naposledy ked som presuval disky tak novy system rozpoznal ich rozdelenie, dokonca viacere RAID-y.
-
Disky již byli společně v SW raidu, ale po kleknutí NASu se mi již nepodařilo rozchodit Ubuntu (blbá shoda náhod)
Takže jsem přišel o konfiguraci raidu. Jde mi o to, že když jsem konfiguroval raid tak to vyžadovalo synchronizaci disků, ale co si pamatuji, tak to smazalo data na obou discích, což já teď zrovna moc nechci. :)
mdadm --create --assume-clean
Jak tak pročítám dokumentaci k mdadm s --assume-clean, tak to vypadá jako věc šitá na míru, ale raději se zeptám ještě jednou, abych potom nebyl za vola: Mohu toto použít, při vytváření raidu > to preskočí sync, nepřijdu o data a raid bude zase šlapat jak má?
-
Jak tak pročítám dokumentaci k mdadm s --assume-clean, tak to vypadá jako věc šitá na míru, ale raději se zeptám ještě jednou, abych potom nebyl za vola: Mohu toto použít, při vytváření raidu > to preskočí sync, nepřijdu o data a raid bude zase šlapat jak má?
Pokud použijete přesně stejnou konfiguraci pro --create, tak ano.
-
Měl jsem napsaný celkem dlouhý příspěvek, který by moc neřekl... Proto píšu znovu a jinak.
Nebylo by v tomhle případě správné použít
mdadm --assemble
s tím, že se použije jen jeden disk a druhý bude "missing"?
Pokud jsem pochopil, tak je jen rozpadlý RAID, takže se musí pole jen složit s jedním z disků a druhý pak přidat a nechat "ozrcadlit"...? Pokud se použije --create, tak se vytvoří nové info o RAIDu a může se to celé podělat. Jestli mi tedy slouží paměť dobře... dělal jsem to už před lety, ale zase opakovaně :)
-
Ano HW konfigurace bude stejná, pouze nahraji znovu OS a sestavím RAID pole.
-
PROBOHA NEDĚLEJ --CREATE!!!
Takže jsem přišel o konfiguraci raidu.
Ne. MD-RAID má metadata přímo na tom zařízení v hlavičce (formát 1.2) nebo patičce (formát 0.9).
Zálohu mám, ale je cca 1,5 měsíce stará, takže bych chtěl zachránit co se dá. :)
mdadm --examine --scan
mdadm --assemble --scan
cat /proc/mdstat
Otestuji postup od RDa. Vůbec mě to nenepadlo, ale teď si vzpomínám, že když jsem pročítal tutoriály na raid tak tam bylo i obnovení raidu z jednoho disku.
Ne proboha! Ten RAID stačí prostě jenom složit, velmi pravděpodobně to dokonce mdadm udělá automaticky (jenom ho nastaví na readonly dokud to nepotvrdíš).
Dost i přemýšlím o HW Raid řešení, kde bych nebyl limitovaný spolehnutím na systém. Je možnost nějakého RAID HW řešení do 2 000kč?
Ne, obzvláště levné HW RAIDy jsou neuvěřitelně strašné.
mdadm --create --assume-clean
Ne, tohle vytvoří nové pole a bude při čtení vracet data náhodně z jednoho a druhého disku. On nechce pole vytvořit, on chce sestavit existující.
-
Btw. --assume-clean znamená jenom že se to nebude synchronizovat hned při vytvoření. Neříká to nic o tom, že se to nesyncne časem - většina distribucí má v cronu job, který každý měsíc kontroluje, že jsou disková pole v pořádku. V lepším případě to vyhodí chybu že v pořádku nejsou, v horším to rovnou spustí sync.
-
Zdravím,
je možné znovu vytvořit SW raid (1) v Ubuntu 16.04, ale bez synchronizace? Tj. bez ztráty dat na discích?
Ak tie dva disky predtým boli v RAID1, je na nich presne to isté. Ak sa náhodou spustí SYNC, tak len rovnaké dáta z jedného disku prepíše identickými dátami z druhého disku. Cez víkend som zväčšoval RAID oddiel s metadata=0.90 a keďže pri tejto verzii metadáta sú na konci oddielu, podarilo sa mi tým úplne zrušiť informáciu o RAID-e na tých oddieloch (lebo koniec oddielu bol odrazu na inom mieste). mdadm --assemble sa nemal čoho chytiť, takže mi ostalo len mdadm --create. Keďže začiatok oddielu sa neposúval, filesystém ostal nedotknutý a SYNC sa síce spustil, ale žiadne dáta nezmenil, nakoľko na oboch diskoch už boli dáta rovnaké (do rozsahu kam siahal ten pôvodný filesystém). Takže SYNC prebehol, potom som dal e2resize a pripojil, a všetko bolo OK.
-
...
Dost i přemýšlím o HW Raid řešení, kde bych nebyl limitovaný spolehnutím na systém. Je možnost nějakého RAID HW řešení do 2 000kč? Co jsem našel, tak raid řadič od axago, ale má jen sata1...
Do 2000 dostanes s prominutim s*ackoidni radic ktery s HW raidem ma spolecneho asi tolik jako tvoje babicka a pristani na mesici. HW raid ma sve vyhody u vetsiho mnozstvi disku, nebo kdyz mas specificke pozadavky, ve tvem pripade je nejsnazsi reseni mdraid nebo pokud rad riskujes treba btrfs raid. Zalohovat linuxovou konfiguraci raidu je snazsi nez resit interkompatibilitu mezi radicem do 2000 a novym radicem do 2000.
-
Použitý HP P420 s 512MB keše a novou baterkou vyjde tak na 150 dolarů, formát smartarray na disku je stejný již spoustu let. Ale md raid udělá lepší službu, pokud mu nejde o hrubý výkon.
-
Ale md raid udělá lepší službu, pokud mu nejde o hrubý výkon.
Pochybuji, daní bude zátěž CPU.
-
md raid1 ani raid10 žádnou větší CPU daň nemá, pár procent. Stačí si to vyzkoušet, v topu jsou kernelí vlákna raidu vidět. raid5/6 nepoužívám, takže neznám, ale ani tam nepředpokládám nic zásadního.
Něco jiného je ZFSoL, tam mi kopírování souborů na ZVOL s blocksize 4kB sežralo 12 xeoních jader ze 16. Na druhou stranu funkce ZFS nelze s md raid1/10 vůbec srovnávat...
-
Pro upřesnění toho ZFS - šlo o kopírování (dd) celého XFS filesystému se stovkami miliónů hardlinků, proto tak malý blocksize na ZVOL. 4kB blocksize se ukázala nepoužitelnou - čtení pak 30 MB/s na poolu se 14 disky v zfs mirroru a load opět několik jader.
-
raid5/6 nepoužívám, takže neznám, ale ani tam nepředpokládám nic zásadního.
Pro představu pět let starý Xeon E5-2420 0 @ 1.90GHz upočítá MD RAID6 (tj. výpočetně nejnáročnější typ RAIDu) 8.5 GB/s.
-
Pro představu pět let starý Xeon E5-2420 0 @ 1.90GHz upočítá MD RAID6 (tj. výpočetně nejnáročnější typ RAIDu) 8.5 GB/s.
je na to nejaky benchmark?
-
Pro představu pět let starý Xeon E5-2420 0 @ 1.90GHz upočítá MD RAID6 (tj. výpočetně nejnáročnější typ RAIDu) 8.5 GB/s.
je na to nejaky benchmark?
Pise to u bootu:
[ 0.143135] raid6: sse2x1 gen() 9722 MB/s
[ 0.160148] raid6: sse2x1 xor() 7582 MB/s
[ 0.177159] raid6: sse2x2 gen() 12199 MB/s
[ 0.194169] raid6: sse2x2 xor() 8359 MB/s
[ 0.211180] raid6: sse2x4 gen() 14261 MB/s
[ 0.228194] raid6: sse2x4 xor() 10056 MB/s
[ 0.228260] raid6: using algorithm sse2x4 gen() 14261 MB/s
[ 0.228328] raid6: .... xor() 10056 MB/s, rmw enabled
[ 0.229130] raid6: using ssse3x2 recovery algorithm@ dvojjadrovy Intel(R) Pentium(R) CPU G3220 @ 3.00GHz
Takze ty famy ze SW raid je narocny na CPU jsou z dob i586. Stejne to byla blbost, protoze XOR z raid-u je velice jednoducha instrukce - jakekoliv zpracovani dat (parsovani) bude trvat nasobne dele. Maly vliv to bude mit jen na fileserveru s 10GE, kde se presouvaji opravdu kvanta dat, ale pochybuji ze to nekdo z vas provozuje.
-
Takze ty famy ze SW raid je narocny na CPU jsou z dob i586. Stejne to byla blbost, protoze XOR z raid-u je velice jednoducha instrukce - jakekoliv zpracovani dat (parsovani) bude trvat nasobne dele. Maly vliv to bude mit jen na fileserveru s 10GE, kde se presouvaji opravdu kvanta dat, ale pochybuji ze to nekdo z vas provozuje.
To samozřejmě fámy nejsou. Na hw raid funguje cpu offloading, podobně, jako se to řeší u serverových síťových karet. Hlavním cílem je udržet nízkou latenci, ne jen hrubý průtok.
Na fileserveru či NAS samozřejmě rozdíl asi nepoznáte, ale u databázového serveru už sakra jo.
-
Tu latenci přece snižuje baterií zálohovaná write keš, díky které HW řadič okamžitě potvrzuje dokončení zápisu. To není o vyšší zátěži CPU.
-
Díky, zůstanu u md raidu.
O žraní výkonu zase tolik nejde, mám dostatečnou rezervu.
Vše běží na CPU (síťovka, gpu, raid), cpu podtaktováno z původních 4x1400 na 4x800MHz, stále se cpu nedostalo přes 67% zatížení při souběžném zapisování/vypsování dat z db, otevírání webu z apache a zapisování/čtení z disků od 2 uživatelů. :)
Bohužel se na "opravu" raidu vrhnu později, sesipalo se mi na hlavu najednou více věcí a oprava RAIDU v nasu není teď prioritou. Každopádně díky. :)
-
Pro představu pět let starý Xeon E5-2420 0 @ 1.90GHz upočítá MD RAID6 (tj. výpočetně nejnáročnější typ RAIDu) 8.5 GB/s.
je na to nejaky benchmark?
Pise to u bootu:
[ 0.143135] raid6: sse2x1 gen() 9722 MB/s
[ 0.160148] raid6: sse2x1 xor() 7582 MB/s
[ 0.177159] raid6: sse2x2 gen() 12199 MB/s
[ 0.194169] raid6: sse2x2 xor() 8359 MB/s
[ 0.211180] raid6: sse2x4 gen() 14261 MB/s
[ 0.228194] raid6: sse2x4 xor() 10056 MB/s
[ 0.228260] raid6: using algorithm sse2x4 gen() 14261 MB/s
[ 0.228328] raid6: .... xor() 10056 MB/s, rmw enabled
[ 0.229130] raid6: using ssse3x2 recovery algorithm@ dvojjadrovy Intel(R) Pentium(R) CPU G3220 @ 3.00GHz
Takze ty famy ze SW raid je narocny na CPU jsou z dob i586. Stejne to byla blbost, protoze XOR z raid-u je velice jednoducha instrukce - jakekoliv zpracovani dat (parsovani) bude trvat nasobne dele. Maly vliv to bude mit jen na fileserveru s 10GE, kde se presouvaji opravdu kvanta dat, ale pochybuji ze to nekdo z vas provozuje.
Maly vliv to bude mit taky u stroju kde je tech raid6 nekolik. Treba takovy storage s 90x hdd.
-
To samozřejmě fámy nejsou. Na hw raid funguje cpu offloading, podobně, jako se to řeší u serverových síťových karet. Hlavním cílem je udržet nízkou latenci, ne jen hrubý průtok.
Na fileserveru či NAS samozřejmě rozdíl asi nepoznáte, ale u databázového serveru už sakra jo.
Offloading ma jedine smysl pokud mate uzke hrdlo v I/O k radici a provozujete RAID1 / RAID10 nebo 4 diskovy RAID6 - kde je mnozstvi dat pro disky jiz 2x vetsi nez puvodni data. Stejne si toho vsimnete az na SSD nebo s vetsim poctem poli.
Prave ze podil CPU vypoctu zacne byt znatelny, az kdyz se bude jednat o opravdovy objem dat. Coz databaze rozhodne neudela vetsi, nez FS/NAS. A i kdybych tlacil pres 2x 10GE tech imaginarnich 2000MB/s, tak to vytizi tu G3220 teoreticky z 14%, coz neni zadna zatez.
Kdyz vam databaze pri zapisu bude delat RMW a nemate uzke hrdlo k HBA, tak je uplne jedno, zda prepocet udela radic nebo procesor, protoze vam to cele budou stejne brzdit disky.
Jestli porad pocitujete rozdil, tak je to kvuli tomu jak psal dustin prede mnou - zapisy potvrdi radic drive nez je provede (at uz do SSD fronty, nebo zalohovane ram). Ale to same muze nabidnout i stroj se sw raidem a NVDIMM.
-
Testoval jsem dva starší 16portové JBOD řadiče SAS 9201-16e, všech 32 SATA disků (rotačních) současně dávalo čtení na svou max. rychlost (150MB/s). Karty mají ještě staré PCI-e v2 (samozřejmě každá ve slotu s vlastní sadou x8 linek) a sběrnice to nezahltilo, karty za pár desítek dolarů to dávaly zcela na pohodu. Komplet SSD místo HDD by to samozřejmě neutáhlo.
md raid (několik raid10) na tom není na CPU nijak znát. Samozřejmě HW raid s baterkou (i starý HP P800 v jiném serveru) má latenci v zápisu úplně jinde, ale zdaleka mi nedovoluje takové věci, co dělám na sw raidu (přesuny raidů, přidávání nových disků, změny velikostí, zálohování mirrorem raidu na externí disky atd.). Pro nízkou latenci (DB) jsou tam SSDčka, proti kterým si HW raid s HDD disky při čtení stejně neškrtne.