SSD o HDD per server

Problema

Ho letto molte discussioni sull'archiviazione e se SSD o HDD classici sono migliori. Sono abbastanza confuso. Gli HDD sono ancora piuttosto preferiti, ma perché?

Quale è meglio per l'archiviazione attiva? Ad esempio per i database, dove il disco è sempre attivo?

A proposito di SSD.

Professionisti.

• Sono tranquilli.
• Non meccanico.
• Più veloce.

Cons.

• Più costoso.

Domanda.

• Quando viene utilizzato il ciclo di vita di una cella di un SSD, cosa succede allora? Il disco è ridotto solo da questa cella e funziona normalmente?
• Qual è il miglior filesystem da scrivere? Ext4 è buono perché salva consecutivamente nelle celle?

Informazioni sull'HDD.

Professionisti.

• Più economico.

Cons.

• In caso di guasto meccanico, credo che di solito non ci sia modo di ripararlo. (Conferma.)
• Più lento, anche se penso che la velocità dell'HDD sia di solito sufficiente per i server.

Si tratta solo di prezzo? Perché sono preferiti gli HDD? E gli SSD sono davvero utili per i server?

Un aspetto del mio lavoro è la progettazione e la costruzione di sistemi di archiviazione su larga scala (spesso noti come "SAN" o "Storage Area Networks"). In genere, utilizziamo un approccio a più livelli con SSD e HDD combinati.

Detto questo, ognuno ha vantaggi specifici.

1. Gli SSD hanno quasi sempre un costo per byte più elevato. Posso ottenere 10k SAS 4kn HDD con un costo per gigabyte di $ 0,068 / GB USD. Ciò significa che per circa $ 280 posso ottenere un disco da 4 TB. D'altra parte, gli SSD hanno in genere un costo per gigabyte negli anni 10 e 20 centesimi, anche alto come dollari per gigabyte.

2. Quando si ha a che fare con RAID, la velocità diventa meno importante e invece le dimensioni e l'affidabilità contano molto di più. Posso costruire un sistema RAID N + 2 da 12 TB con l'HDD molto più economico di quello dell'SSD. Ciò è dovuto principalmente al punto 1.

3. Se trattati correttamente, gli HDD sono estremamente economici da sostituire e mantenere. Poiché il costo per byte è inferiore, sostituire un HDD con un altro a causa di un guasto è più economico. Inoltre, poiché i guasti dell'HDD sono in genere correlati al tempo rispetto alla scrittura dei dati, la sua sostituzione non inizia automaticamente a utilizzare TBW quando ricostruisce l'array RAID. (Concesso, la percentuale di TBW utilizzata per una ricostruzione è complessivamente minuscola, ma il punto è valido.)

4. Il mercato degli SSD è relativamente complesso. Esistono quattro principali tipi di SSD (attualmente in corso di stesura), classificati dal numero più alto di scritture totali supportate al più basso: SLC, MLC, TLC, QLC. L'SLC in genere supporta il maggior numero di scritture totali (il principale fattore limitante delle vite SSD), mentre il QLC in genere supporta il numero più basso di scritture totali.

Detto questo, i sistemi di archiviazione di maggior successo che ho visto sono suddivisi in livelli con entrambe le unità in uso. Personalmente, tutti i sistemi di archiviazione che consiglio ai clienti generalmente seguono i seguenti livelli:

1. Il livello 1 è in genere un (o più) solo livello SSD RAID 10. I dati vengono sempre scritti nel livello 1.
2. Il livello 2 è in genere un (o più) livelli solo per SSD RAID 50 o 5. I dati sono scaduti dal livello 1 al livello 2.
3. Il livello 3 è in genere un (o più) livello solo per HDD RAID 10. I dati sono scaduti dal livello 2 al livello 3.
4. Il livello 4 è in genere diversi gruppi di livelli solo per HDD RAID 6. I dati sono passati dal livello 3 al livello 4. Riduciamo i gruppi RAID 6 il più piccolo possibile, in modo che vi sia un supporto massimo in caso di guasto dell'unità.

Le prestazioni di lettura / scrittura diminuiscono quando si aumentano i livelli, i dati si propagheranno fino a un livello in cui la maggior parte dei dati condivide la stessa frequenza di accesso / modifica. (Cioè, più frequentemente i dati vengono letti / scritti, maggiore è il livello su cui risiede.)

Cospargi un po 'di canale in fibra ben progettato e puoi effettivamente costruire una SAN che abbia un throughput più elevato rispetto alle unità integrate .

Ora, per alcuni elementi specifici che menzioni:

Le tue domande su SSD

Come funziona esattamente SSD, quando il ciclo di vita di una cella è fuori uso, che cosa succede? Il disco è ridotto solo da questa cella e funziona normalmente? O cosa è successo allora?

• Entrambi i tipi di unità sono in genere progettati con un numero di celle "di riserva". Cioè, hanno uno spazio "extra" su cui non puoi accedere che supporta il fallimento se una cellula muore. (IIRC è del 7-10%). Ciò significa che se una singola "cellula" (settore su HDD) muore, viene utilizzato un "ricambio". È possibile verificarne lo stato tramite l'utilità di diagnostica SMART su entrambe le unità.

Qual è la migliore soluzione (filesystem) da scrivere? Penso che ext4 sia buono, perché salva consecutivamente nelle celle?

• Per gli SSD questo è del tutto irrilevante. Il posizionamento delle celle non ha importanza, poiché il tempo di accesso è in genere lineare.

Le tue domande sull'HDD

In caso di guasto meccanico, non c'è modo di ripararlo (è giusto)?

• Parzialmente errato Gli HDD sono in realtà più facili da recuperare i dati nella maggior parte delle situazioni di guasto. (Nota: ho detto più facile , non facile .) Sono necessarie attrezzature specializzate, ma i tassi di successo qui sembrano piuttosto alti. I piatti possono spesso essere letti fuori il disco fisso stesso mediante apparecchiature speciali, che permette di recupero dati se l'unità è morto.

Più lento, ma penso che la velocità non sia così importante, perché la velocità dell'HDD è assolutamente sufficiente per l'utilizzo del server?

• In genere, quando si utilizza RAID, la velocità a unità singola diventa un fattore minore in quanto è possibile utilizzare le impostazioni RAID di associazione della velocità che consentono di aumentare la velocità complessiva. (RAID 0, 5, 6 sono usati frequentemente, spesso in tandem.) Per un database con IO elevati, gli HDD non sono in genere sufficienti se non progettati in modo molto deliberato. Vorresti SSD di grado SLC ad alta intensità di scrittura per IO di livello database.

L'HDD è ancora piuttosto preferito

È? Non sono sicuro che sia sincero.

L'HDD è disponibile in grandi dimensioni a un prezzo decente in questo momento, è innegabile e penso che le persone si fidino di loro per una conservazione dei dati più lunga rispetto agli SSD. Inoltre, quando gli SSD muoiono tendono a morire completamente, tutto in una volta, mentre gli HDD tendono a morire in un modo più prevedibile che forse consente più tempo per ottenere i dati prima se necessario.

Ma per il resto SSD è la strada da percorrere per la maggior parte degli usi: vuoi una coppia di avvio, un paio di SATA da 500 GB in R1 non costeranno nulla, per l'uso di DB non puoi davvero battere SSD (finché i tuoi log sono attivi modelli di alta resistenza comunque). Per i backup sì, potresti usare grandi HDD da 7,2k, lo stesso per set di dati molto grandi (in effetti ho acquistato oltre 4.000 HDD da 10 TB all'inizio dello scorso anno solo per questo requisito), ma per il resto SSD è la strada da percorrere.

Stato solido per tutto ciò che è caldo: uso interattivo, database, tutto online. Mandrini come memoria calda economica, solo per archivi non abbastanza freddi o dati a cui si accede raramente. In particolare, gli HDD in un'area di gestione temporanea prima dei backup vengono archiviati su nastro.

Diversi tipi di media per caldo contro freddo aiutano anche con una certa diversità. Un difetto di perdita di dati in un marchio di controller SSD sarebbe molto peggio se eliminasse sia i dati online che quelli di backup. È improbabile, ma i mandrini e il nastro sono comunque economici, quindi perché rischiare.

La modalità di errore di un determinato dispositivo non è importante, a condizione che gli array rimangano ridondanti e sottoposti a backup. Di solito la procedura è sostituire un'unità con qualsiasi sintomo di guasto. Prova a ripararli nei tuoi sistemi di test, dove qualsiasi guasto catastrofico non influisce sui servizi di produzione.

Il file system è una questione di preferenze personali. Mentre ci sono file system ottimizzati SSD, qualcosa che conosci e che puoi riparare potrebbe essere più importante.

Il grande vantaggio di un SSD è la velocità e l'affidabilità, tuttavia uno dei piccoli segreti sporchi è il numero limitato di cicli di scrittura di un SSD. Se stai costruendo un server che ha molte attività di scrittura sul disco rigido come un database o un server di posta elettronica, avrai bisogno di un SSD più costoso con una resistenza maggiore.

NAND Flash ha 3 tipi

• TLC
• MLC
• SLC

TLC è progettato principalmente per server Web o server di archivio che hanno piccoli cicli di scrittura. MLC è per server che hanno una combinazione di cicli di lettura e scrittura come un server di database a basso volume. SLC è progettato per server che hanno molti cicli di lettura / scrittura come un server di database ad alto volume.

Il principale fattore trainante tra SSD e HDD è l'applicazione e il budget. In un mondo perfetto, i dischi rigidi SLC SSD renderebbero obsoleto un HDD standard, ma non ci siamo ancora.

L'HDD è ancora piuttosto preferito, ma perché?

Dipende da chi parli, dal loro background (gestione, IT, vendite, ecc.) E dal tipo di server a cui fa riferimento la discussione. Gli HDD sono generalmente di un ordine di grandezza meno costoso per byte, ma consumano più energia e sono quasi sempre più lenti, a seconda del carico di lavoro.

Quasi sempre si riduce ai costi e alla quantità di spazio di archiviazione che può essere inserita in un determinato numero di server. Se riesci a ottenere le prestazioni di un array raid a 5 dischi con un singolo SSD, l'SSD è probabilmente molto meno costoso e utilizza una frazione della potenza, ma otterrai anche 1/10 di spazio di archiviazione.

Quale è meglio per l'archiviazione attiva?

Qui è dove diventa complicato e perché molte persone salteranno la complicazione e andranno semplicemente con gli HDD che conoscono.

Gli SSD sono disponibili in diversi gradi con limiti sulla quantità di dati che possono essere scritti nelle celle, che NON è uguale alla quantità di dati scritti dall'host. Scrivere piccole quantità di dati finisce per scrivere grandi quantità nelle celle, questo si chiama amplificazione della scrittura e può uccidere rapidamente le unità con bassi livelli di resistenza.

Le celle SSD sono nominate per la quantità di bit che possono memorizzare, per memorizzare n-bit, hanno bisogno di 2 ^ n livelli di tensione per cella. Un TLC (triplo bit) richiede 8 livelli di tensione per indirizzare quei bit. In genere, ogni volta che si aumenta il livello di bit per cella, si ottiene un calo di 3-10 volte la durata della cella. Ad esempio , un'unità SLC può scrivere tutte le celle 100000 volte prima che le celle muoiano, eMLC aziendale 30000 volte, MLC 10000, TLC 5000, QLC 1000.

Ci sono anche miglioramenti generazionali nella tecnologia delle celle SSD, una migliore litografia e una NAND 3D migliorano la densità e le prestazioni rispetto alla vecchia NAND 2D, "La MLC di oggi è migliore della SLC di ieri", come citato dall'analista Jim Handy .

Gli SSD in realtà non scrivono direttamente nelle celle indirizzate, ma scrivono su blocchi di celle. In questo modo il blocco ha una quantità più consistente di scritture di celle e quando le celle non rientrano nella tolleranza l'intero blocco viene contrassegnato come non valido e i dati vengono spostati in un nuovo blocco. La resistenza SSD si basa sul tipo di cella, sul numero di blocchi di riserva disponibili, sull'overhead per la correzione degli errori e su come l'unità utilizza la cache e gli algoritmi per ridurre l'amplificazione della scrittura. Entra in gioco anche la tolleranza che il produttore sceglie di contrassegnare come non valido, un'unità aziendale contrassegnerà i blocchi come non validi rispetto a un'unità consumer, anche se una delle due è ancora perfettamente funzionante.

Gli SSD "high-write" di livello enterprise si basano su celle SLC o eMLC e dispongono di grandi quantità di blocchi di riserva e di solito dispongono di una cache di grandi dimensioni con condensatori per assicurarsi che la cache possa scaricarsi sul disco in caso di interruzione dell'alimentazione.

Esistono anche unità con resistenza molto inferiore per applicazioni "high-read" come file server che richiedono tempi di accesso rapidi, costano meno per byte al prezzo di resistenza ridotta, con diversi tipi di celle, meno area di riserva e così via, esse può avere solo il 5% della resistenza di un'unità "high-write", ma non è necessaria se utilizzata correttamente.

Ad esempio per il database, dove il disco è sempre attivo?

Il mio database è piccolo, con letture intermittenti pari al 95% di accesso e la maggior parte è memorizzata nella cache nella RAM, è quasi altrettanto veloce su un HDD che su un SSD. Se fosse più grande, non ci sarebbe abbastanza RAM sul sistema e l'SSD inizia a fare una grande differenza nei tempi di accesso.

Gli SSD rendono inoltre più rapidi i backup e gli ordini di ripristino di grandezza. Il mio DB è stato ripristinato dal backup in circa 10 minuti su un SSD lento, o circa 11 secondi su un disco veramente veloce, il backup su un HDD sarebbe stato di circa 25 minuti. Sono almeno 2 ordini di grandezza e ciò può fare una differenza enorme a seconda del carico di lavoro. Può letteralmente pagare da solo il primo giorno.

Database con enormi quantità di piccole scritture possono uccidere un'unità TLC di livello consumer nel giro di poche ore.

E gli SSD sono davvero utili per il server?

Assolutamente, se il tipo di unità e il grado corretti sono selezionati per l'applicazione, se lo fai in modo sbagliato può essere un disastro.

Il mio server esegue diversi database, oltre all'archiviazione di rete ad alta lettura, oltre all'archiviazione di filmati di sicurezza ad alta scrittura, oltre all'archiviazione di file di scrittura a lettura mista e al backup del client. Il server ha un array RAID-6 di HDD per l'archiviazione di rete di massa e NVR, un singolo SSD MLC ad alte prestazioni per MySQL e 3 unità TLC consumer in RAID-5 per backup di client e database e archiviazione di rete ad accesso rapido.

La velocità di scrittura sul RAID SSD è circa la stessa velocità del RAID HDD, ma la velocità di lettura ad accesso casuale è più di 10 volte più veloce sul RAID SSD. Ancora una volta si tratta di un SSD TLC consumer, ma poiché la velocità di scrittura sequenziale è circa 3 volte più veloce della LAN gigabit, non viene mai sovraccaricata e c'è un sacco di sovraccarico se il sistema esegue backup locali quando si accede da remoto.

La maggior parte degli SSD offre anche la cancellazione sicura istantanea (ISE) , che può cancellare i dati in pochi secondi, rispetto a molte ore o giorni per gli HDD che non dispongono di tale funzione, solo alcuni HDD di livello aziendale tendono ad offrire ISE, ma stanno diventando più comune. Questo è molto utile se si sta ritirando o ri-proponendo un'unità.

Qual è la migliore soluzione (filesystem) da scrivere?

Dipende dal tipo di dati e dai tipi di funzionalità del filesystem che desideri. Sto usando solo EXT4 e BTRFS (ho bisogno di istantanee e checksum). L'overhead del filesystem ridurrà lo spazio utilizzabile e può ridurre leggermente la durata degli SSD, BTRFS ha un overhead elevato per checksum e altre funzionalità e le snapshot useranno molto spazio.

In caso di guasto meccanico, non c'è modo di ripararlo (è giusto)?

Indipendentemente dal tipo di unità, hai mai dovuto eseguire il ripristino dei dati su un'unità non funzionante? Può essere molto costoso , è meglio avere un backup su più livelli, RAID sulla memoria principale, backup con versione locale su un dispositivo o macchina diverso, quindi sincronizzare con offsite o cloud. 1 TB di spazio di archiviazione cloud è di $ 5 al mese, il recupero dei dati su un HDD può costare 2 mila dollari e un SSD morto potrebbe essere impossibile da recuperare ... basta fare i backup e dimenticare la riparazione.

ENTRAMBI.

Devo ancora vedere un SSD morire a causa del carico di scrittura (in questo caso dovrebbero diventare di sola lettura). Non che non muoiano per altri motivi, incluso, ma non limitato a surriscaldamento e bug del firmware.

E ho visto un HDD morto. Molti di più, in realtà.

Tanto sull'affidabilità.

In alcuni casi ha senso creare un RAID1 misto (HDD + SSD). In questo modo è possibile coprire le modalità di errore correlate a entrambi e mantenere prestazioni di lettura SSD.

In altri casi ha senso usare un SSD solo per il journal del filesystem: otterrai il doppio delle prestazioni di scrittura dell'HDD (perché risparmi metà delle scritture e metà delle ricerche) e generalmente nessun rischio anche se il tuo SSD maltrattato muore. Ext4 perde il suo diario piuttosto elegantemente.

I due principali fattori da considerare sono:

• Prestazioni (in tempo di accesso e velocità effettiva)
• Costo per gigabyte

Gli SSD espellono gli HDD in termini di prestazioni. Se hai bisogno di throughput elevato e tempi di accesso bassi, niente è meglio di SSD .

Ma il costo per gigabyte di SSD è molto più alto di quello degli HDD. Se hai bisogno di un sacco di spazio di archiviazione e velocità effettiva o i tempi di accesso sono meno importanti, niente è meglio degli HDD.

I dati relativi alla velocità effettiva (larghezza di banda) possono essere aiutati dal livello RAID appropriato (non così tanti tempi di accesso, a meno che le unità non siano abbastanza arretrate che l'accodamento sia un problema).

I valori dei tempi di accesso in lettura per piccoli set di dati possono essere aiutati da una cache adeguata (ovvero inserire più RAM nel server). Tuttavia, non aiuta per le scritture (ad eccezione delle cache RAM con batteria tampone nei controller o nei dischi).

Quindi tutto dipende davvero dal tuo caso d'uso. Un server di backup / archivio che richiede molta capacità ma non si preoccupa molto dei tempi di accesso o della larghezza di banda sarà meglio usando gli HDD. Un server di database ad alto traffico preferirà gli SSD. Nel mezzo ... dipende.

Qualunque sia la situazione:

• Hai bisogno di backup. Non importa se un'unità (SSD o HDD) non funzionerà, dipende da quando .

• Se il server ha qualche tipo di importanza, si desidera che un qualche tipo di RAID mantenga il tempo di attività e protegga i dati. Il RAID di solito aiuta anche con le prestazioni. Ciò dipende molto dalle vostre esigenze (di nuovo, un compromesso prestazioni / costi).

Come già accennato, la grande differenza è il prezzo per GB rispetto alle prestazioni di I / O casuali.

Prendiamo, ad esempio, un Seagate Exos 16 TB: a ~ 550 $, comanda 0,034 $ / GB. Ora confrontalo con un Micron 5200 ECO 7.68 TB entry-level (in termini di velocità) al prezzo di ~ 1300 $, con un conseguente rapporto 0,14 $ / GB: l'HDD è 5 volte più economico, pur essendo anche 2 volte più grande. Dall'altro lato, le prestazioni di I / O casuali degli SSD sono decisamente migliori, con un problema : gli SSD di consumo, privi di cache di writeback protetta da perdita di potenza , sono piuttosto lenti (a volte lenti come gli HDD) per carichi di lavoro ricchi di IO casuali sincronizzati (ad esempio: database, macchine virtuali ). Questo è un punto molto importante, raramente analizzato dalle recensioni online. Gli SSD aziendali, con condensatori quasi universalmente utilizzati come protezione della perdita di potenza, non soffrono di questa debolezza, avendo un I / O casuale di lettura e scrittura molto elevato.

Da quanto sopra, puoi capire perché SSD ha ucciso i dischi SAS di fascia alta da 15K e 10K: offrono prestazioni molto migliori a un costo comparabile (i dischi da 15K erano particolarmente costosi). D'altro canto, l'HDD da 7,2 K ha un punto d'appoggio molto forte nei sistemi di archiviazione ad alta capacità.

Intel Optane (che si basa su Xpoint anziché su NAND) è in una classe a sé stante sia in termini di velocità che di durata, con un prezzo / GB molto elevato: un Optane P4801x da 100 GB costa oltre 260 $, con un costo al GB di > 2,6 $, 80 volte di più rispetto agli HDD. Per questo motivo, viene spesso utilizzato come "acceleratore di applicazione" o come dispositivo di registro / giornale.

Per questi motivi, le SAN e i server moderni hanno spesso utilizzato un sottosistema di archiviazione a più livelli o memorizzato nella cache :

• i sistemi a livelli inseriscono i dati caldi nel livello rapido (SSD) e i dati freddi nel livello lento (HDD). In tali sistemi, lo spazio di archiviazione totale è la somma del livello veloce e lento; tuttavia, sono staticamente tutti partizionati - se un dato freddo diventa improvvisamente caldo, devi aspettare che venga spostato al livello veloce. Inoltre, il livello veloce deve essere durevole quanto quello lento;

• il sistema basato su cache ha tutti i dati su HDD lento, aumentato con una cache dinamica su SSD in cui i dati caldi vengono copiati (anziché spostati); ciò significa che tali sistemi hanno uno spazio di archiviazione totale pari a quello offerto dal livello lento, ma con la flessibilità aggiuntiva di una cache dinamica. Con i sistemi basati su cache, il livello rapido può essere formato da SSD economici ed economici.

Qual è il miglior filesystem per un SSD basato su flash? Una risposta ingenua può essere "quella che scrive di meno", ma la realtà è che qualsiasi tecnologia avanzata di filesystem si basa su un approccio CoW che, basato sull'implementazione specifica, può portare a un'amplificazione della scrittura abbastanza sostanziale (es .: ZFS e WALF scriverò più di, diciamo, EXT4 o XFS). Per un puro punto di vista "senza scrittura", penso che sia difficile battere EXT4 e XFS (specialmente se supportato da lvmthin , che consente istantanee veloci anche su questi file system classici); tuttavia, mi piace molto la garanzia di protezione dei dati aggiunta e la compressione lz4 grattata da ZFS.

Quindi, hai davvero bisogno di una memoria SSD per le tue funzioni del server? Dipende:

• se è necessario archiviare a buon mercato più TB di dati, gli HDD (o al massimo SSD consumer economici) è la strada da percorrere;

• se hai un carico di lavoro prevalentemente sequenziale (es: fileserver), non hai bisogno di SSD;

• se il tuo carico di lavoro è ricco di I / O casuali, trarrai grandi benefici dagli SSD;

• se si dispone di un modello di scrittura fsync pesante, gli SSD aziendali (o un controller RAID robusto con cache di writeback protetta da perdita di potenza) sono la soluzione migliore, con il rovescio della medaglia a costi elevati.

Risposta semplice qui: utilizzare gli SSD per dati di prestazioni veloci, ad esempio quando si costruisce un server per eseguire operazioni di dati grandi e veloci (come l'editing video)

Utilizzare HHD per l'archiviazione lenta.

Generalmente gli HDD sono meno affidabili degli SSD anche se hanno un costo per concerto inferiore rispetto agli SSD.

se vengono archiviati dati sensibili, considerare l'utilizzo di un SSD e anche un HDD per il backup.

La quiete non è sempre buona. Come se le auto elettriche sulla strada fossero troppo silenziose. I rumori di accesso all'HDD possono fornire sicurezza (il modo in cui ho rilevato un'interruzione in un server di lavoro durante la visione di un film. (Aggiunta: le stampanti di alimentazione di linea collegate a / var / log / messaggi sono più difficili da cancellare una singola voce)

Lo guardo così,

A cosa serve il servizio che sto costruendo server?

Se si tratta di un servizio di infrastruttura come LDAP / AUTH / Stampa ecc. Per cui stai offrendo un servizio, è principalmente un problema di memoria che consente di risparmiare denaro e utilizzare l'HDD (7.2k o 10k forse un dispositivo di avvio SSD raid 1) e lanciare un sacco di memoria su di esso .

Assicurati di utilizzare un controller di raid flash con batteria di backup per file server, puoi quindi utilizzare l'HDD in modo efficiente dalla scrittura impegnata dal controller e non dai dischi.

Se si tratta di un DB di servizi dati, ecc., Utilizzare il raid SSD per un throughput elevato ma controllare i costi utilizzando anche l'HDD, ad esempio alcuni DB non richiedono un'alta velocità di scrittura o non eseguono semplicemente l'IOP per garantire l'uso di storage a costi elevati.

Alla fine della giornata è finita con i soldi e il tuo direttore finanziario / direttore finanziario / vicepresidente finanziario.

Gli SSD sono chiaramente i migliori, miglioreranno e continueranno ad essere più economici, ma oggi sono più costosi.

Gli HDD vanno bene per le attività di archiviazione sequenziale:

• File di registro del database
• Archiviazione video
• Volumi di backup (in blocco)
• Istantanee della macchina virtuale

Gli HDD vanno bene anche per compiti insensibili alla latenza:

• Archiviazione dei file (singolarmente)
• Piccoli database abbastanza piccoli da essere comunque in esecuzione in memoria
• File software non OS (se l'SSD si sta riempiendo)

Quindi, per un server, se si dispone del budget, è possibile riempirlo con SSD. Oltre a ciò, utilizzando l'elenco incompleto sopra, puoi risparmiare denaro mescolando con gli HDD.

RAID, e Tiering va oltre lo scopo di questa domanda, sono sicuro che ci sono molte altre domande a riguardo.

Per quanto riguarda il ciclo di vita degli SSD, (ricordo che leggere Samsung Evo Pro (prodotto di consumo) è durato molto più a lungo di quanto promesso). Le singole celle possono certamente rompersi nel tempo, ma ciò non rompe l'intero disco. La durata della cella è collegata alla quantità di scritture. su quella cella. Il controller SSD diffonde le scritture su più celle nel tempo. Se l'SSD è pieno al 99% e lo spazio rimanente viene utilizzato con molte scritture, lo spazio rimanente verrà consumato più rapidamente.

Se ce n'è bisogno

1. Scambio basato su file montato per memoria aggiuntiva
2. Chat video o streaming video o elaborazione video
3. Elaborazione che porta alla grande un singolo file

allora l'HDD è più affidabile
La sovrascrittura sembra essere più lenta nell'SSD

L'SSD è fantastico però!
ha fatto la rivoluzione della memoria fisica di exabyte / yotabytes in un piccolo armadio / rack

È possibile installare un grande dispositivo di raffreddamento dell'azoto e un piccolo spazio può servire un rack di stoccaggio puro

La cache SSD è un'altra straordinaria tecnologia di lettura più veloce che consente la memorizzazione nella cache a un altro livello