Konsument SSD-diskar i Enterprise servrar

Prestanda är väl en sak, men hur ser det ut med write endurance på diskarna.
Jag har kört 840PRO som cache-devices och de höll ett knappt år innan de rasade utan förvarning.

Om jag inte minns helt fel så var det 840 EVO som hade stora problem, inte PRO. Angående att "bränna ut celler", se svaret från @xxargs

HPE:s Entry level använder SATA, ja - men så finns det lång väg vidare om man vill bli av med mycket pengar

Jag skulle nog kalla det lite marknadsanpassning för att locka in nya användare till Enterprise-segmentet och alla användningar behöver inte börja med diskar med en tio-potens lägre sannolikhet för oläsbara sektorer i jämförelse med SATA-diskar eller att servern fungerar skottsäkert i minst 5 år framöver med ECC-RAM-minne, batteribackuppad HW-SAS-RAID-kontroller, byta diskar, fläktar och kraftmoduler under drift samt kan administreras fjärr inklusive spänningsmässig av och påslag (dvs. för cold-boot) av servern över egen ethernet-port.

det är lite skillnad på en HPE proliant-server-blad för att stackas i stativ mot en noname tower-burk - och det gäller också ljudnivåmässigt, Rack-servrar gillar att drivas välkylda och bryr sig inte om antalet dB i ljudnivå det medför...

Skillnaden är hur gånger en cell kan skrivas till och hur skrivcachen skyddas samt prestandan.

Konsument: Hög prestanda.

Server: Celler tål fler skrivningar, skrivcacheskydd(inte att förväxla med simpla lösningar enbart baserade på tantalkondensatorer som finns på vissa konsument SSD). Skrivcachen är inte att rekommendera att ha påslaget i skarpa miljöer men detta har flertalet tillverkare löst idag med separat NAND där skrivcachen skrivs till vid strömavbrotti flertalet SAS SSD.

Och i många fall är det den batteriuppbackade SAS-RAID-kortet som står för skriv-cachen och vet exakt vilken status diskarna var när strömmen gick och fortsätter vidare från den punkten när strömmen kommer tillbaka.

Detta är ett sätt att komma undan write-hole situationen i en RAID-matris vilket det inte hjälper med skrivcache-skydd på resp. SSD/snurrdisk eftersom diskarna inte har koll på den inbördes skriv-ordningen gentemot varandra precis när strömmen gick - medans en batteribackupad SAS-RAID-kort har koll på det.

En SAS HBA/RAID-kontroller är också framtidsskyddad om man vill 'nedgradera' sig och använda SATA-diskar istället - och dessutom då kan a dubbelt antal av det (typiskt 16 stycken om kortet hanterar 8 dual port SAS-diskar)

@wille61: Det här kan vara intressant att titta på (även om jag inte är jätteförtjust i TweakTown)

Ett alternativ till Intels diskar är Samsung SM863a, har mer eller mindre samma prestanda och endurance som Intel (hade iaf för ca 1 år sedan när jag kollade senast), men till ett bättre pris.

Är det till labburkar är det bara att köra på. Till produktionssystem skulle jag aldrig drömma om att använda något annat än servertillverkarens rekommenderade enterpriseklassade diskar, även om de är dyrare är det säkerligen en fis i rymden jämfört med kostnaden för downtime när diskarna börjar rasa.

Hur tycker Du att det fungerar på lagringsenheter i skarp drift eftersom idén bakom den lösningen är om t.ex. en lagringsenhet dras ut under drift då majoriteten utav maskiner i skarp drift redan har reservkraft så strömavbrott är inte problemet utan det är personer som drar ut lagringsenheter under drift, lagringsenheter som går sönder samt RAID-kort som går sönder.

Överföringar till lagringsenheter sker blockvis och återrapporteringen sker per färdigt block vilket bromsar upp IOPS rätt så rejält om man kör med halvledarenheter och vill t.ex. ha ett ködjup på 32. Då försvinner vitsen med SSD i servermiljöer om man enbart nyttjar skrivcachen på RAID-kortet eftersom dessa fylls rätt så fort om ködjupet till lagringsenheten är 1 men den är 32 från OS till RAID-kort.

Prova stäng av skrivcachen på en ensam hårddisk så känner man direkt av dess IOPS.
Prova stäng av skrivcachen på en ensam halvledarenhet så ser Du samma sak om Du mäter eller skriver mycket till den.

Batterier slutade man använda inom RAID-kort för några år sedan om vi tittar på nya modeller bara 2-3 år tillbaks p.g.a. deras låga hållbarhet och att man ej kan byta dom under drift. Sen håller batterimodellerna inte lika länge RAID-kortets skrivcache som dom nya lösningarna men oftast har det ej varit ett praktiskt problem. Vissa SSD:er för SAS kör just samma teknik för sin egen skrivcache vilket gör att man kan nyttja ködjupen fullt ut och samtidigt få ut höga skriv IOPS och ändå vara helt trygg. Jag har själv batterier till det RAID-kort som sköter hårddiskarna men samtidigt så är den lösningen ifrån år 2011 från LSI. I samma maskin har jag ett annat RAID-kort som sköter SSD:erna så har den inga batterier utan kör helt på kondensatorer som kommer ifrån Areca år 2015 samt alla skrivcachar påslagna då SSD:erna inte sitter i någon vagga och deras samlade skrivcache är dubbelt så stort jämfört med Areca kortets.

Anledningen till att man har en NAND lösning ombord på flera SAS SSD modeller är just för att nyttja skrivcachen och få hög IOPS vid skrivning och stora köer. Skrivcachen skall normalt vara avstängd på hårddiskar i skarpa miljöer men då tappar man värdet som SSD:er ger(som är avsedda för skarpa miljöer) om man tillämpar samma logik på SSD:er som för hårddiskar.

Det stora problemet är att SSD:ernas skrivcache växer i större takt än vad RAID-kortens skrivcache gör och då kommer man ändå att ej nyttja SSD:ernas möjlighet till hög IOPS när RAID-kortet bromsar upp p.g.a. att hans skrivcache är fullt och skrivcachen på SSD:erna är avstängd. Då är man tillbaks till ett ködjup på 1 på varje lagringsenhet i uppsättningen.

Därav nyttjar man SSD:er som har egen reservkraft som skriver från RAM till NAND vid strömavbrott och nyttjar RAID-kortens skrivcache om man känner att man inte har något emot att behöva underhålla en till komponent(batteri/kondensatorer).