SSD v RAID1, hw/sw?

[wnt]

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.

[Reklama]

[Frantisek Koudelka]

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).

[MP]

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.

[dustin]

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.

[Frantisek Koudelka]

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 ....

[Reklama]

[serverovyinženýr]

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í ... .

[wnt]

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.

[Sten]

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.

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í.

[dustin]

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.

[MP]

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.

[Sten]

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, jinam jde šoupnout rozšiřující kartu se dvěma sloty.

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á.

[Cek]

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.....

[AlyoSHA]

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.

[Sten]

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í.

[dustin]

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í?