Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: wnt 25. 01. 2017, 16:35:41
-
Ahoj,
do firmy stavíme databázový server pro cca 20 uživatelů. Poběží na něm virtualizovaně Win Srv a MS SQL. Aktuálně řeším disky. Určitě tam budou dva SSD disky (Intel S3610) v RAID1. Přemýšlím nad tím, zda je pro tento případ nutné pořizovat i hardwarový raid (Areca 1214) a zda to přinese vůbec nějaké zásadní výhody. Rychlost SSD je sama o sobě více než dostatečná a dva jsou tam hlavně z důvodu redundance.
Pokud bych hw raid nekupoval, tak pak by se zrcadlení řešilo buď v rámci toho, co nabízí základní deska (Supermicro) nebo přímo ve Windows ve správci disku (asi pravděpodobnější).
Díky za názory.
-
RAID na základní desce nedoporučuji, pokud deska umře, tak se k datům už taky nemusíte vůbec dostat. Pro zrcadlení bude SW RAID ve Windows úplně stačit. HW RAID se spíš používá tam, kde je potřeba počítat paritu.
Btw. nezapomeňte na UPS.
-
Hw raid - karta ma vyhodu ve spolehlivosti, nezavyslosti na zakladni desce a je u toho dobry sw na monitoring. Snadne a dobre reseni ktere bych volil.
Pseudo hw raid jedine v pripade lepsi desky jako maji fujitsu siemens servery. Pak mozna ano i kdyz s vyhradama.
Sw raid v os, asi ano, ale je treba s s tim naucit zachazet. Dinammicky disky dokazou udelat boleni hlavy.
-
nezavyslosti Dinammicky
Kristova noho. Nic proti negramotům (moderně-politicky-korektně dyslektikům), ale zapni si českou klávesnici a kontrolu pravopisu v prohlížeči.
-
nezavyslosti Dinammicky
Kristova noho. Nic proti negramotům (moderně-politicky-korektně dyslektikům), ale zapni si českou klávesnici a kontrolu pravopisu v prohlížeči.
Něco k tématu máš a nebo jen trollíš?
-
K tématu snad zkusit strejdu Googla, řeší se to tady furt dokola.
-
Tak se o ty odkazy podělte :-) Já jsem samozřejmě na google hledal a to konkrétně i tady tuto diskuzi a nic relevantního, co by přímo řešilo moji otázku, nenašel.
-
widloswraid je tak leda cesta do pekel. Jakejkoli SW raid je problem v situaci, kdy to zelezo ma bejt pod nejakou zatezi na CPU (databaze). Slusnej HW si monitoruje disky, sleduje chybovost a disk oznaci za vadnej driv, nez skutecne umre. Samo to neni zadarmo. U HW muze nastat potiz, pokud umre radic, ze to nejde pripojit k jinymu. Mimo jiny i proto se pouziva SAS a radice se pouzivaj dva.
A jak bylo receno, hledal si leda prd, protoze na to tema je jen tu nejmin par desitek threadu.
-
widloswraid je tak leda cesta do pekel. Jakejkoli SW raid je problem v situaci, kdy to zelezo ma bejt pod nejakou zatezi na CPU (databaze). Slusnej HW si monitoruje disky, sleduje chybovost a disk oznaci za vadnej driv, nez skutecne umre. Samo to neni zadarmo. U HW muze nastat potiz, pokud umre radic, ze to nejde pripojit k jinymu. Mimo jiny i proto se pouziva SAS a radice se pouzivaj dva.
U dnešních cpu a serveru pro dvacet lidí ceni zátěž CPU softwarovým řadičem žádný problém ... . Aco se týká té potíže hw řadičů tak když se verzme něco třeba od adaptecu tak tam je velká kompatibilita a dopstupnost a nová kompatibilní karta může být do druhého dne.
A jinak si myslim,. že už padla jakákoliv otázka a tak by se mohlo fórum zamknout a napsat velkým písmem "hledej v google"
-
widloswraid je tak leda cesta do pekel. Jakejkoli SW raid je problem v situaci, kdy to zelezo ma bejt pod nejakou zatezi na CPU (databaze).
U RAID 1? Hahaha
Slusnej HW si monitoruje disky, sleduje chybovost a disk oznaci za vadnej driv, nez skutecne umre.
Což nedělá křišťálovou koulí, ale přes SMART a scrub. To samozřejmě může dělat i SW a na serverech by to měla být samozřejmost.
-
Slusnej HW si monitoruje disky, sleduje chybovost a disk oznaci za vadnej driv, nez skutecne umre.
No toto je právě docela zajímavá myšlenka. Opravdu takto řadič funguje i v případě SSD disku? Co je mi tak známo, tak vadnou buňku si řeší SSD disk sám ve své režii. A co jsem četl na některých zahraničních diskuzích a vlastně možná i přímo zde, tak pokud se už na SSD něco podělá, tak prostě umře prakticky bez varování najednou. (samozřejmě ve SMARTu se mohou objevit informace o přemapování, ale asi přímo spolehnout se na to taky nedá)
-
U dnešních cpu a serveru pro dvacet lidí ceni zátěž CPU softwarovým řadičem žádný problém ...
Jo, od tebe bych si nechal navrhovat HW ... 20 lidi = staci 386, co na tom ze treba pocitaj most ... si holt pockaj. M$ SQL dokaze sezrat zcela libovolne dimenzovanej HW, zalezi jen na tom co budou delat. Staci na to klidne jeden trochu vypecenejsi dotaz. A pak bez vysvetlovat, ze ten dotaz misto minuty trva deset, protoze CPU resi raid.
U RAID 1? Hahaha
...
Kdybys nezvanil a vyzkousel si to, tak se tlemit prestanes. Tvuj post vypovida leda o tom, ze si nikdy server nevidel.
No toto je právě docela zajímavá myšlenka. ...
Bavime se o serverovym zeleze ze? A ne o soho kramech za par korun.
-
Ve win nevím, ale na linuxu má SW raid1 minimální režii i na DB. Zásadní nevýhodou je ale pomalý flush/sync, což je u produkční DB dost zásadní, protože tam není zdravé snížit bezpečnost transakcí vypnutím syncu. Tam má HW raid s baterkou a tedy okamžitým syncem velký náskok. A nebo na DB použít kvalitní SSD a rázem je SW raid1 v pohodě. Linux už pár let umí fstrim i přes MD vrstvu.
-
U dnešních cpu a serveru pro dvacet lidí ceni zátěž CPU softwarovým řadičem žádný problém ...
Jo, od tebe bych si nechal navrhovat HW ... 20 lidi = staci 386, co na tom ze treba pocitaj most ... si holt pockaj. M$ SQL dokaze sezrat zcela libovolne dimenzovanej HW, zalezi jen na tom co budou delat. Staci na to klidne jeden trochu vypecenejsi dotaz. A pak bez vysvetlovat, ze ten dotaz misto minuty trva deset, protoze CPU resi raid.
Opět klasické lopatí root výkřiky. Neví co to bude dělat, neví jak se to bude používat, ale určitě ví, že nějaké základní procesory pro servery typu, nevim Xeon E3-1220 určitě nebudou stačit ...
-
A ty vo tom vis lautrhovno a zvanis....
-
Je to server a zas tak na korunu se nehledí. Jestli to bude stát o 10k víc za řadič, tak se nic nestane. Ale nechci jej tam dávat jen proto, protože "každý správný server má mít HW raid". Jde mi o to, jaký to bude nebo nebude mít reálný dopad.
Jinak samotná konfigurace serveru je: Xeon E5-1620v4, 32GB RAM, SSD 480GB v RAID1.
Využití: Provoz ERP systému. Více jak 20 lidí současně s tím dělat nebude. Žádné vypečené analýzy dat se tam běžně dělat nebudou a i kdyby ano, tak by to stejně běželo někdy přes noc.
-
S RAID 1 nad SSD jsem trochu skeptický s ohledem na to, že pokud SSD umře, tak proto, že se často "upřepisuje" a dva stejné modely, stejně staré by mohly umřít teoreticky zroveň. Nemám toto ze své hlavy, ale na pár takových zkušeností jsem narazil, když jsem se zabýval pořízením co nejvýkonnějšího HW pro SQL. Nabízí se kombinované řešení RAID1 z SSD a HDD, ale tenhle paskvil při testech nefungoval (navzdory předpokladům a dokumentaci) přijatelně.
Jako zajímavá varianta je pořídit NVMe SSD do PCIe (cenově to vyjde srovnatelně jako několik SAS/SATA SSD a HW řadič, I/O výkon je o dost vyšší). OS klidně může být na klasických HDD, DB na NVMe a zálohovat každých 24h komplet snapshot na klasické SATA HDD, plus ukládat si transakční logy.
Ano, tohle řešení neposkytuje tolik sucha, bezpečí a jistoty jako ideální RAID1 ze dvou disků. Ale ukažte mi RAID1 s podobnými I/O možnostmi.
Když už stavět RAID1 nad SSD, tak HW řadič s cachí a baterkou a dát do něj dvě různá SSD (s důrazem na různou vnitřní strukturu).
-
Problem HW raidu je tento:
1] vykon HW muze zaostavat za schopnostma pouzitych SSD
2] bod 1] se jeste vice uplatni u nvme disku
3] lepsi HW z hlediska bodu 2] znamena drazsi radice
4] nektere radice akceptuji pouze SSD od vyrobce radice
5] pcie SSD nejdou dat do HW raidu (bez vysokych nakladu)
Jinak jsou tu pak same vyhody - napr. vymena disku je jednodussi nez cachrovat s CLI apod.
-
Když už stavět RAID1 nad SSD, tak HW řadič s cachí a baterkou a dát do něj dvě různá SSD (s důrazem na různou vnitřní strukturu).
Proč pro SSD HW raid s baterkou? Používáme SSD nad SW raidem, samozřejmě monitorujeme smartem jejich status. Všude je Intel DC S3500. Samozřejmě opotřebování pomalu roste, ale nejníže je okolo 90% (tj. opotřebováno 10%). Pro jistotu jsme za partišnou nechali 20% volno, ale asi to nebylo nutné. IMO to raid1 až tak neopotřebuje - jednou zasynchronizuje a pak stejně dostává bloky k trimu od OS, takže to zase pustí.
Samozřejmě PCIe disk je výkonnostně jinde.
Právě výhoda SSD je rychlý flush, tudíž řadič bez baterky nezdržuje transakci.
-
Problem HW raidu je tento:
1] vykon HW muze zaostavat za schopnostma pouzitych SSD
2] bod 1] se jeste vice uplatni u nvme disku
3] lepsi HW z hlediska bodu 2] znamena drazsi radice
4] nektere radice akceptuji pouze SSD od vyrobce radice
5] pcie SSD nejdou dat do HW raidu (bez vysokych nakladu)
Jinak jsou tu pak same vyhody - napr. vymena disku je jednodussi nez cachrovat s CLI apod.
Sorry, napsal jsem to zjednodušeně. Pod pojmem HW raid s baterkou jsem chtěl říct: ne fakeraid a podobné pseudoraidy.
NVMe jsem měl na mysli pouze pro PCIe. Ale jinak souhlasím ....
-
S RAID 1 nad SSD jsem trochu skeptický s ohledem na to, že pokud SSD umře, tak proto, že se často "upřepisuje" a dva stejné modely, stejně staré by mohly umřít teoreticky zroveň.
Dovolím si tvrdit, že většina reklamovaných ssd odešla na jinou závadu než běžné opotřebení ... .
-
Používáme SSD nad SW raidem, samozřejmě monitorujeme smartem jejich status. Všude je Intel DC S3500. Samozřejmě opotřebování pomalu roste, ale nejníže je okolo 90% (tj. opotřebováno 10%). Pro jistotu jsme za partišnou nechali 20% volno, ale asi to nebylo nutné.
No na tom serveru bude vyšší řada těch disků S3610, podle toho co jsem četl srovnání (http://www.anandtech.com/show/8954/intel-launches-ssd-dc-s3610-s3710-enterprise-ssds), tak jsou stavěny ještě na 3x vyšší odolnost na přepisy než řada S3500. S3700 má pak dokonce 10x vyšší odolnost.
Zatím se popravdě spíše kloním k řešení, že RAID1 nechám řešit Windows, protože všechny výhody, které jsou u HW řadičů zmiňovány mi přijdou, že se v případě SSD disku ztrácí. Určitě dobrá připomínka je ale ohledně stejného opotřebení těch disků, takže zřejmě to udělám tak, že v době implementace nového ERP (cca 5 měsíců) to nechám běžet jen na jednom disku a zrcadlo udělám až potom. Částečně bych tak mohl diverzifikovat riziko současného výpadku obou.
Co se týče NVMe disku, tak nad tím jsem původně také uvažoval, ale to jsem zavrhl kvůli zatím špatné podpoře. Supermicro podporuje NVMe snad jen u nových desek na LGA1151 a tam nemám vůbec žádnou rezervu pro případný budoucí výběr výkonnějšího CPU. Nehledě na to, že podporují jen jeden takový disk, takže ani ten RAID1 bych nebyl schopný udělat.
-
Kdybys nezvanil a vyzkousel si to, tak se tlemit prestanes. Tvuj post vypovida leda o tom, ze si nikdy server nevidel.
Rád se nechám poučit, co na RAID 1 počítá CPU.
Mimochodem viděl jsem nejen servery, ale taky nějaká ta čísla ohledně SW vs. HW RAID nad SSD (https://www.reddit.com/r/sysadmin/comments/3m6pma/software_vs_hardware_raid_with_ssd_drives/).
Ve win nevím, ale na linuxu má SW raid1 minimální režii i na DB. Zásadní nevýhodou je ale pomalý flush/sync, což je u produkční DB dost zásadní, protože tam není zdravé snížit bezpečnost transakcí vypnutím syncu. Tam má HW raid s baterkou a tedy okamžitým syncem velký náskok. A nebo na DB použít kvalitní SSD a rázem je SW raid1 v pohodě. Linux už pár let umí fstrim i přes MD vrstvu.
Tohle jsem slyšel několikrát, ale je to opravdu výhoda? Rychlý sync při zátěži je sice super, ale on je rychlý jen do té doby, dokud se data vejdou do cache řadiče. Což při jakékoliv delší zátěži dojde velmi rychle. A u špiček následovaných klidem rychlý sync stejně nemá význam, tak prostě ten jeden dotaz bude trochu pomalejší, další to neovlivní.
-
Detaily jsem nestudoval, ale selským rozumem předpokládám, že máš-li paměť řadiče 256MB+ s půlkou pro write, vejde se tam celá transakce. V našem případě byl rozdíl mezi HW řadičem s pamětí (HP P410 a spol.) a běžnými HDD disky v sw raid10 drastický - zápisy se výrazně zpomalily. Bylo nutné snížit ochranu transakce v mysql (innodb_flush_log_at_trx_commit = 2), poté se rychlost vrátila do normálu. Protože šlo o devel server, nijak zásadně to nevadilo, db se stejně každou noc nalévá znovu. S SSD to potřeba není a lze ponechat defaultní flush po každé transakci, máme to samozřejmě tak i na ostrém serveru. Dnes už jsou tam všude SSD, takže to neřešíme.
-
Co se týče NVMe disku, tak nad tím jsem původně také uvažoval, ale to jsem zavrhl kvůli zatím špatné podpoře. Supermicro podporuje NVMe snad jen u nových desek na LGA1151 a tam nemám vůbec žádnou rezervu pro případný budoucí výběr výkonnějšího CPU. Nehledě na to, že podporují jen jeden takový disk, takže ani ten RAID1 bych nebyl schopný udělat.
Co znamena ta podpora? U NVMe podporuji vicemene vsechny Intely a urcite by tam jely i DC varianty ostatnich vyrobcu. S podporou NVMe z hlediska desky je to jasne, prislo to s generaci X10, pokud se nepletu. My mame ve fazi zprovoznovani jeden z techto serveru a zpusob pripojeni NVMe disku na PCIE s hotswapem rozhodne ocenuji. I kdyz se mi samozrejme trochu styska po nekterych schopnostech HW raidu - netreba resit veci ohledne bootu a CLI v pripade manipulace s vadnym diskem.
-
Co se týče NVMe disku, tak nad tím jsem původně také uvažoval, ale to jsem zavrhl kvůli zatím špatné podpoře. Supermicro podporuje NVMe snad jen u nových desek na LGA1151 a tam nemám vůbec žádnou rezervu pro případný budoucí výběr výkonnějšího CPU. Nehledě na to, že podporují jen jeden takový disk, takže ani ten RAID1 bych nebyl schopný udělat.
Některé servery mají třeba i 4 M.2 sloty (https://www.supermicro.com/products/system/3U/5038/SYS-5038MD-H8TRF.cfm), jinam jde šoupnout rozšiřující kartu se dvěma sloty (https://www.supermicro.com/products/accessories/addon/AOC-SLG3-2M2.cfm).
Detaily jsem nestudoval, ale selským rozumem předpokládám, že máš-li paměť řadiče 256MB+ s půlkou pro write, vejde se tam celá transakce. V našem případě byl rozdíl mezi HW řadičem s pamětí (HP P410 a spol.) a běžnými HDD disky v sw raid10 drastický - zápisy se výrazně zpomalily. Bylo nutné snížit ochranu transakce v mysql (innodb_flush_log_at_trx_commit = 2), poté se rychlost vrátila do normálu. Protože šlo o devel server, nijak zásadně to nevadilo, db se stejně každou noc nalévá znovu. S SSD to potřeba není a lze ponechat defaultní flush po každé transakci, máme to samozřejmě tak i na ostrém serveru. Dnes už jsou tam všude SSD, takže to neřešíme.
Zajímavé. Když to totiž vezmu selským rozumem, tak se sice celá transakce vejde do cache, ale dokud se nezapíše, tak se tam nevejde další. Takže ta první bude flushnutá rychle, ale ty další budou muset stejně čekat a ve výsledku to sice papírově bude mít rychlejší zápisy, ale celková propustnost bude stejná.
-
Detaily jsem nestudoval, ale selským rozumem předpokládám, že máš-li paměť řadiče 256MB+ s půlkou pro write, vejde se tam celá transakce. V našem případě byl rozdíl mezi HW řadičem s pamětí (HP P410 a spol.) a běžnými HDD disky v sw raid10 drastický - zápisy se výrazně zpomalily. Bylo nutné snížit ochranu transakce v mysql (innodb_flush_log_at_trx_commit = 2), poté se rychlost vrátila do normálu. Protože šlo o devel server, nijak zásadně to nevadilo, db se stejně každou noc nalévá znovu. S SSD to potřeba není a lze ponechat defaultní flush po každé transakci, máme to samozřejmě tak i na ostrém serveru. Dnes už jsou tam všude SSD, takže to neřešíme.
Zajímavé. Když to totiž vezmu selským rozumem, tak se sice celá transakce vejde do cache, ale dokud se nezapíše, tak se tam nevejde další. Takže ta první bude flushnutá rychle, ale ty další budou muset stejně čekat a ve výsledku to sice papírově bude mít rychlejší zápisy, ale celková propustnost bude stejná.
Celkova propustnost bude stejna pouze v pripade, ze spicky jsou dlouhodobejsi (resp. to vubec nejsou spicky, ale setrvaly stav) nebo cache prilis mala. V obou pripadech jde o spatny navrh potrebneho HW. Cache pomuze "premostit" vykyvy tim, ze je vnitrne rozprostre do delsi doby, ale samozrejme nenahradi hruby vykon, pokud je diskove pole nebo RAID v serveru na hranici sveho vykonu.
Jinak ano celkova MAXIMALNI propustnost, pokud jsi myslel tu, bude stejna, ale pokud dimenzujes HW tak, aby atakoval maximum dane technologie beznym provozem, vetsinou nedelas dobre.....
-
Slusnej HW si monitoruje disky, sleduje chybovost a disk oznaci za vadnej driv, nez skutecne umre.
No toto je právě docela zajímavá myšlenka. Opravdu takto řadič funguje i v případě SSD disku? Co je mi tak známo, tak vadnou buňku si řeší SSD disk sám ve své režii. A co jsem četl na některých zahraničních diskuzích a vlastně možná i přímo zde, tak pokud se už na SSD něco podělá, tak prostě umře prakticky bez varování najednou. (samozřejmě ve SMARTu se mohou objevit informace o přemapování, ale asi přímo spolehnout se na to taky nedá)
Jedna osobna skusenost s SSD v SW RAID1 - na jednom z diskov odisiel prave ten radic flasiek (v SSDcku) jadro a ani SMART na to neprisiel. Raid fungoval v pohode: Nejaky cas preplieskaval data na fukncnom disku zmrsenymi datami z vadneho disku. Pri neskorsej kontrole mali obe disky rovnaky obsah. Zavada sa prejavila az ked to cele klaklo. Vyrobca diskov - Sandisk.
-
Jedna osobna skusenost s SSD v SW RAID1 - na jednom z diskov odisiel prave ten radic flasiek (v SSDcku) jadro a ani SMART na to neprisiel. Raid fungoval v pohode: Nejaky cas preplieskaval data na fukncnom disku zmrsenymi datami z vadneho disku. Pri neskorsej kontrole mali obe disky rovnaky obsah. Zavada sa prejavila az ked to cele klaklo. Vyrobca diskov - Sandisk.
Silent corruption se mohou stát i na HDD (i když ne tak rozsáhlé) a RAIDy (i ty HW) jsou proti nim bezmocné. Naštěstí už máme btrfs, ZFS a ReFS s checksumy, které to velmi rychle odhalí.
-
tak se sice celá transakce vejde do cache, ale dokud se nezapíše, tak se tam nevejde další.
Proč by se řekněme do 100MB nevešlo více běžných transakcí?
-
Zdravím.
Asi dostanu hrozně vynadáno že je to blbost.
Já bych pořídil nějakou lepší NAS do ní dal 1x SSD a 2x HDD v RAID 1
Připojil bych to pomocí iscsi do serveru a v NAS vytvořil replikaci mezi target na SSD a target na HDD.
Pokud to projde cenově může se i SSD dát RAID 1.
Když odejde NAS dají se data zpřístupnit v Linuxu, propoje mezi NAS a serverem se dají teoreticky vyřešit bez switche.
Dostupnost dat bude vysoká, výkon určitě menší než při použití disků v serveru, ale o řády to nebude.
-
SSD do NASu je podle mého názoru blbost, možná tak pro operační systém (sám to tak používám).
Při rychlostech GbE ti to zvládne vykrýt 7200 rpm disk.
-
Zdravím.
Asi dostanu hrozně vynadáno že je to blbost.
Já bych pořídil nějakou lepší NAS do ní dal 1x SSD a 2x HDD v RAID 1
Připojil bych to pomocí iscsi do serveru a v NAS vytvořil replikaci mezi target na SSD a target na HDD.
Pokud to projde cenově může se i SSD dát RAID 1.
Když odejde NAS dají se data zpřístupnit v Linuxu, propoje mezi NAS a serverem se dají teoreticky vyřešit bez switche.
Dostupnost dat bude vysoká, výkon určitě menší než při použití disků v serveru, ale o řády to nebude.
Pokud to připojíte přes Gen 5+ Fibre Channel, proč ne (na Ethernetu výhody SSD ubije latence, při méně než 5 Gbps nejspíš i propustnost), ale to už bude o řád mimo rozpočet tazatele.
-
Proč pro SSD HW raid s baterkou?...
A dalsi ... to je fakt parada kdyz se pole rozdrbne proto, ze nekdo vypne elektriku ... baterka se na radic nedava proto, ze na nem sou pomaly nebo rychly disky. Baterka se tam dava proto, ze je na nem cache, ktera je minimalne o rad rychlejsi, nez nerychlejsi ssd.
S RAID 1 nad SSD jsem trochu skeptický s ohledem na to, že pokud SSD umře, tak proto, že se často "upřepisuje" a dva stejné modely, stejně staré by mohly umřít teoreticky zroveň.
Dovolím si tvrdit, že většina reklamovaných ssd odešla na jinou závadu než běžné opotřebení ... .
Taky bych chtel videt ssdko, ktery se uprepisovalo k smrti. Na serverovy zelezo je zcela bezne 5let nbd (pokud nekdo neche vynakladat prachy za lepsi). To je taky v normalne fungujici firme zivotnost toho zeleza.
Zatím se popravdě spíše kloním k řešení, že RAID1 nechám řešit Windows,
Dobrej zpusob jak rychle a bezpecne prijit o data. Mozna vubec ten nejlepsi ... widloraid ...
Rád se nechám poučit, co na RAID 1 počítá CPU.
Rad se necham poucit, jak se data z disku A dostanou na disk B bez CPU. Nejspis sublimaci.
Zajímavé. Když to totiž vezmu selským rozumem,...
Zajimavy, tady nekdo vubec netusi, jak funguje cache ... ona prekvapive zcela VZDY naprosto neresi propustnost. Ta je dana vykonem systemu samotnyho (jedno jestli disky nebo ssd), ona resi to, ze (vetsinou) se nezapisuje hromada dat, ale pomer je 90:10 (nebo jeste vic) mezi R a W. Tudiz si disky (nebo ssdcka) muzou s klidem pokracovat ve cteni, a teprve az na to prijde, se i zapise. A proto se tam dava ta baterka, aby radic moh potvrdit systemu zapis, a v pripade vypadku nedoslo ke ztrate tech dat.
-
Co znamena ta podpora? U NVMe podporuji vicemene vsechny Intely a urcite by tam jely i DC varianty ostatnich vyrobcu. S podporou NVMe z hlediska desky je to jasne, prislo to s generaci X10, pokud se nepletu. My mame ve fazi zprovoznovani jeden z techto serveru a zpusob pripojeni NVMe disku na PCIE s hotswapem rozhodne ocenuji. I kdyz se mi samozrejme trochu styska po nekterych schopnostech HW raidu - netreba resit veci ohledne bootu a CLI v pripade manipulace s vadnym diskem.
Pravda :) Jsem vycházel z českého překladu parametrů jednoho prodejce a když jsem se teď nad tím pozastavil tak je to nesmysl. V tom případě ještě zapřemýšlím nad těma NVMe, protože cenově ten rozdíl není nějak zásadní. Pokud se dám touto cestou, tak to i vyřeší můj dotaz a rychlost zas bude někde jinde.
-
Rad se necham poucit, jak se data z disku A dostanou na disk B bez CPU. Nejspis sublimaci.
Pár instrukcemi a jedním I/O příkazem. Stojí to o alespoň o řád méně výkonu než zápis z aplikace vůbec vyvolat (kvůli přepínání kontextů a kopírování dat mezi aplikací a jádrem).
Zajimavy, tady nekdo vubec netusi, jak funguje cache ... ona prekvapive zcela VZDY naprosto neresi propustnost. Ta je dana vykonem systemu samotnyho (jedno jestli disky nebo ssd), ona resi to, ze (vetsinou) se nezapisuje hromada dat, ale pomer je 90:10 (nebo jeste vic) mezi R a W. Tudiz si disky (nebo ssdcka) muzou s klidem pokracovat ve cteni, a teprve az na to prijde, se i zapise. A proto se tam dava ta baterka, aby radic moh potvrdit systemu zapis, a v pripade vypadku nedoslo ke ztrate tech dat.
Nevím, jak máš nastavené servery ty (radši se to ani nebudu pokoušet odhadovat), ale já mám na serverech běžně gigabajty až desítky gigabajtů cache pro čtení. Jmenuje se to RAM. Pár set megabajtů navíc ty servery už nevytrhne, obzvlášť když se tam bude cachovat totéž, co už jednou cachované je.
Co se týče řazení čtení a zápisů tak, aby to vyhovovalo disku, slyšel jsi někdy o NCQ? Uměla to už SCSI. Navíc čtení a zápis ani HW RAID rozumně optimalizovat nemůže, když vůbec netuší, kde jsou hlavičky disků či namapované bloky. Proto taky NCQ vzniklo, jinak by to klidně mohl dělat OS.
-
Ok, je videt, ze vubec netusis jak co funguje, a rozhodne bych nepripustil, abys prave ty cokoli konfiguroval ... mas GB ram kterou obsluhuje ... system, tedy cpu a navic, cokoli zapsany do ram ty tatare vubec zapsany neni. Pri provozu databaze pak ta databaze (zcela kazda spepravna) ceka, az se to realne zapise na disk. Ostatne nektery databaze radsi eliminujou celej system a zapisy na disk si ridej zcela ve vlastni rezii ... neprekvapive kvuli bezpecnosti a vykonu.
A treba prave takovy M$SQL si sebere veskerou dostupnou ram pro sebe, pokud ho v rozletu neomezis, takze ti zadny GB ram nezbudou, protoze budes rad, kdyz ti zbude sotva jeden.
-
Ok, je videt, ze vubec netusis jak co funguje, a rozhodne bych nepripustil, abys prave ty cokoli konfiguroval ... mas GB ram kterou obsluhuje ... system, tedy cpu a navic, cokoli zapsany do ram ty tatare vubec zapsany neni. Pri provozu databaze pak ta databaze (zcela kazda spepravna) ceka, az se to realne zapise na disk. Ostatne nektery databaze radsi eliminujou celej system a zapisy na disk si ridej zcela ve vlastni rezii ... neprekvapive kvuli bezpecnosti a vykonu.
Překvapivě pro jéčko cache pro čtení je pro čtení, ne pro zápis. Nepsal jsi náhodou, že ten hlavní důvod pro cache v HW RAIDu je to, že více než 90% operací je čtení? Tak se už rozhodni, na co tam vlastně je.
Mimochodem by mě zajímalo, proč když to má tak výborně zrychlovat, je HW RAID 10 téměř o polovinu pomalejší (https://www.reddit.com/r/sysadmin/comments/3m6pma/software_vs_hardware_raid_with_ssd_drives/). Asi skvrny na Slunci.
A treba prave takovy M$SQL si sebere veskerou dostupnou ram pro sebe, pokud ho v rozletu neomezis, takze ti zadny GB ram nezbudou, protoze budes rad, kdyz ti zbude sotva jeden.
A ta MSSQL s tou pamětí udělá co? Nápověda: začíná to „c“ a končí „ache“.
-
Protoze to je stejnej tatar jako ty a netusi, ze raid funguje ... jakej zazrak ... po blocich, a pokud se pro ssd necha defaultni velikost bloku urcena pro disk, tak to muze bejt klidne i pomalejsi, nez lecjakej disk. A to ze to netusi je zjevny z toho, ze to tam radsi ani nezminuje.
Nemluve o tom, ze je vazne fajn testovat v raidu soho hracku.
-
Jo, apropos, M$SQL jaksi nema fyzickej pristup k disku, takze ti jaksi nema jak zaridit, ze se neco zapise nebo nezapise, a to ani kdybys ty RAM mel 10TB a databaze mela 1kB. A vic co dela primarne s tou pameti? Neprekvapive se snazi v ni drzet maximum dat, vysledky dotazu ... a cache je az to uplne posledni.
-
Protoze to je stejnej tatar jako ty a netusi, ze raid funguje ... jakej zazrak ... po blocich, a pokud se pro ssd necha defaultni velikost bloku urcena pro disk, tak to muze bejt klidne i pomalejsi, nez lecjakej disk.
Ta velikost bloku byla stejná pro HW i SW RAID.
A to ze to netusi je zjevny z toho, ze to tam radsi ani nezminuje.
Vůbec to nezmiňuje (http://pastebin.com/raw/ZvFVDN3b). Nechtěl by sis to raději napřed přečíst?
Nemluve o tom, ze je vazne fajn testovat v raidu soho hracku.
Když ono to ani tu SOHO hračku nezvládne… Jak si myslíš, že se to bude chovat u ještě výkonnějších SSD?
Jo, apropos, M$SQL jaksi nema fyzickej pristup k disku, takze ti jaksi nema jak zaridit, ze se neco zapise nebo nezapise, a to ani kdybys ty RAM mel 10TB a databaze mela 1kB.
False (https://blogs.msdn.microsoft.com/igorpag/2014/01/07/synchronous-vs-asynchronous-transaction-commit-trading-for-performances-with-delayed-transaction-durability/)
A vic co dela primarne s tou pameti? Neprekvapive se snazi v ni drzet maximum dat, vysledky dotazu ... a cache je az to uplne posledni.
To by mě zajímalo, k čemu podle jčka slouží cache, když ne pro držení dat.
-
Tak jen pro úplnost uvádím, že nakonec jsem stejně musel přistoupit k použití hw raidu. Důvod, který nakonec rozhodl byl zejména ve složité konfigurace Raid1 na Windows včetně zavaděče systému a pak také případná obnova takového pole.
Kdo si chce počíst, může se podívat na popis zde: https://blogs.technet.microsoft.com/tip_of_the_day/2014/10/10/tip-of-the-day-configuring-disk-mirroring-for-windows-server-2012/