Seagate esitteli maailman ensimmäistä NVMe-kiintolevyä

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
22 495
seagate-nvme-hdd-20211112.jpg


Kaotik kirjoitti uutisen/artikkelin:
Tietokoneiden tallennustila on siirtynyt jo useimmissa tapauksissa SSD-aikaan. Kiintolevyillä on kuitenkin edelleen paikkansa eikä se tule ainakaan lähitulevaisuudessa horjumaan, mikäli asia riippuu Seagatesta.

Seagate on esitellyt Open Compute Project Summit -tapahtumassa maailman ensimmäistä NVMe-protokollaa tukevaa kiintolevyä. 2U JBOD -koteloitu prototyyppi sisältää yhtiön mukaan natiivin NVMe-portin, josta löytyy sekä SAS-, SATA- että NVMe-tiloja tukeva Tri-Mode-lähetinvastaanotin. Uusi ohjainpiiri perustuu yhtiön kolmannen sukupolven SSD-asemien ohjainpiiriin ja firmwareen.

NVMe-protokollaa tukeville kiintolevyille povataan kysyntää ainakin palvelinmarkkinoilla, sillä etenkin isoissa datakeskuksissa yhden ja saman protokollan käyttö läpi järjestelmän tallennustilan tyypistä riippumatta yksinkertaistaa toteutusta selvästi. Myös kuluttaja- ja työasemapuolella yhteen protokollaan ja yhtenäisiin liitäntöihin siirtyminen mahdollistaisi yksinkertaisemmat emolevyt ilman SATA- tai SAS-liitäntöjä.

Lisäpontta asialle antaa kiintolevyjenkin kasvavat nopeudet; vaikka SAS- ja jopa SATA-liitännät ovat riittäviä vielä nykypäivän kiintolevyille, on useampia toisistaan riippumatta toimivia lukupäitä hyödyntävät asemat kasvattamassa nopeuksia lähitulevaisuudessa selvästi. Seagate aikookin aloittaa prototyyppien toimitukset asiakkailleen jo vuoden kuluttua, syyskuussa 2022. Varsinaisille markkinoille kiintolevyjä odotellaan kuitenkin vasta vuoden 2024 puolivälin tienoilla.

Lähde: Tom's Hardware

Linkki alkuperäiseen juttuun
 
Viimeksi muokattu:
Tuo on kieltämättä hyvä idea, että tuetaan monia eri tiloja, niin et tartte erikseen palvelimeen ja kuluttajamarkkinoille kehitellä levyjä.
 
NVMe-protokollaa tukeville SSD-asemille povataan kysyntää ainakin palvelinmarkkinoilla
Onkos tämä nyt oikein vai väärin? Ts. muusta uutisesta voisi päätellä, että pitäisi puhua kiintolevystä, eikä SSD-asemasta, vaikka voihan tuokin pitää paikkansa :)
 
Onkos tämä nyt oikein vai väärin? Ts. muusta uutisesta voisi päätellä, että pitäisi puhua kiintolevystä, eikä SSD-asemasta, vaikka voihan tuokin pitää paikkansa :)
Siinä on ajatus näemmä harhaillut, korjataas
 
Olen ihmetellyt, kun SATA-portti ei ole vieläkään saanut seuraajaa kuluttajapuolella.
NVMe lisäkorttien asentelu ei ole kovin käytännöllinen ratkaisu, jos tarvitaan paljon SSD-levytilaa.

Vuosia sitten tuli muutama SATA Express / U.2 tuote markkinoille, mutta ei lähtenyt yleistymään.
 
Menee hetki ja kaikki liitetään myös sisäisesti USB4lla niin riittää vain yksi piuha per lätty.
 
Olen ihmetellyt, kun SATA-portti ei ole vieläkään saanut seuraajaa kuluttajapuolella.
NVMe lisäkorttien asentelu ei ole kovin käytännöllinen ratkaisu, jos tarvitaan paljon SSD-levytilaa.

Vuosia sitten tuli muutama SATA Express / U.2 tuote markkinoille, mutta ei lähtenyt yleistymään.
Ei ole kysyntää kun taviskuluttaja ei käytä ohjelmia missä SATAa nopeampi väylä tuntuisi.
 
Ei ole kysyntää kun taviskuluttaja ei käytä ohjelmia missä SATAa nopeampi väylä tuntuisi.

Kuluttajapuolen lätyissä se SATA väylä ei edes muodostu puollonkaulaksi kovalevy käytössä. Vähän sama kun asentaisi ladaan ralliauton renkaat se olisi vain tuhlausta, koska ei se lada kulje niin kovaa, että tarvittaisiin erikoisvahvisteisia renkaita kestämään sellaiset vauhdit.

Suurimmat syyt muutella väylä ratkaisuja kuluttajapuolella lätty käyttöön on se, että jos niillä saadaan asiat helpommaksi kuluttajille tai valmistajat saavat valmistuskustannuksia alemmas jolloin voitot kasvaa.
 
Serveri / työasemapuolella siirrytään lähitulevaisuudessa käyttämään U.3 -liitäntää. Se tukee yhdellä liittimellä niin SATA, SAS kuin NVMe -levyjäkin, ja käyttää samaa SFF-8639 -liitintä kuin U.2.
Ja se tukee hot swappia myös eri tyyppisten levyjen välillä (firmistuen niin salliessa).
Helppoa, kun emolevylle laitetaan jatkosa vain yhdenlaisia massamuistiliittimiä.
Liitännän soisi yleistyvän kuluttajapuolellakin.
 
Viimeksi muokattu:
MACH.2 Multi-Actuator Hard Drive | Seagate UK

Jos kyseessä tämä himmeli niin ei hyvää päivää.
Kaksi lukupäätä on ihan jees ajatuksena, mutta tuossa se on sössitty kunnolla, ne ovat päälekkäin samalla akselilla eli kumpikaan lukupää ei pääse koko levyalueella toimimaan.
Tällä järjestelyllä ei saavuteta mitään käytännön hyötyä verrattuna simppelisti kahteen eri levyyn verratuna.
Tuossa olis jotain järkeä jos molemmat lukupäät olisivat omilla akseleillaan ja täten olisi pääsy koko levyn alueelle, tällöin voisi levylle natiivisti kirjoittaa ja lukea samanaikaisesti.
 
Tuo selittää vähän tarkemmin Multi Actuator Technology: A New Performance Breakthrough | Seagate Blog kyse on enemmänkin siitä että lukupäitä voidaan ohjata kahtena ryhmänä jolloin satunnaisluku parhaassa tapauksessa nopeutuu. Ei siellä ole mitenkään tuplamäärää lukupäitä.

Niin, siis tämä on lähinnä kaksi erillistä levyä yhdellä moottorilla. Verrattuna kahteen erilliseen levyyn, säästetään moottorin hinta ja laakerien hinta, mutta toisaalta, jos moottori tai laakerit hajoaa, hajoaa kaksi levyä samalla.
 
Niin, siis tämä on lähinnä kaksi erillistä levyä yhdellä moottorilla. Verrattuna kahteen erilliseen levyyn, säästetään moottorin hinta ja laakerien hinta, mutta toisaalta, jos moottori tai laakerit hajoaa, hajoaa kaksi levyä samalla.
Loimitettuna kaikki data menetetään joka tapauksessa jos levyrikko iskee, levyjen määrästä riippumatta.
 
Loimitettuna kaikki data menetetään joka tapauksessa jos levyrikko iskee, levyjen määrästä riippumatta.

Miksi ihmeessä tätä käytettäisiin RAID0ssa?

Verrattuna yhteen isoon levyyn, nähtäisiin ensin hirveästi vaivaa ja duplikoitaisiin komponentteja, että eri levypintojen lukupäät voi käsitellä eri raitoja, ja sitten softalla lukittaisiin ne kuitenkin käytännössä melkein aina käsittelemään samoja raitoja.

Ei juurikaan järkeä.

Toki käsitellessä raid-lohkoa pienempiä tiedostoja hyötyä tulisi rinnakkaisuudesta, mutta jos pikkutiedostojen käsittelyn nopeudella on väliä ja ne on tallennettu pyörivälle levylle eikä SSDlle, jotain on tehty pahasti väärin.
 
Lomituksella saadaan kaistaa, siihen ei tämä vaikuta, vain keskimääräiseen hakuaikaan.
Loimituksella saadaan niitä IOPSeja, mikä on koko homman pointti. Peräkkäisoperaatioihin tuolla ratkaisulla ei ole paljoakaan vaikutusta, eri levyjen peräkkäisnopeudet ovat puolet tavanomaiseen ratkaisuun verrattuna ja loimittamalla ne ovat "normaalilla tasolla".

Miksi ihmeessä tätä käytettäisiin RAID0ssa?

Verrattuna yhteen isoon levyyn, nähtäisiin ensin hirveästi vaivaa ja duplikoitaisiin komponentteja, että eri levypintojen lukupäät voi käsitellä eri raitoja, ja sitten softalla lukittaisiin ne kuitenkin käytännössä melkein aina käsittelemään samoja raitoja.

Ei juurikaan järkeä.

Toki käsitellessä raid-lohkoa pienempiä tiedostoja hyötyä tulisi rinnakkaisuudesta, mutta jos pikkutiedostojen käsittelyn nopeudella on väliä ja ne on tallennettu pyörivälle levylle eikä SSDlle, jotain on tehty pahasti väärin.
Peilauksessa ei luonnollisestikaan ole järkeä, eikä JBODissa saa hyödynnettyä JBODin ainoita plussia loimitukseen verrattuna, osittaista vikasietoisuutta ja eri kapasiteettisten levyjen käyttämistä. Loimitus tarjoaa aina vähintään yhtä hyvän ja parhaimmillaan kaksinkertaisen suorituskyvyn JBODiin verrattuna.

Kiintolevyillä on yhä paikkansa tässä maailmassa, eikä niiden suurimman ongelman, eli satunnaisoperaatioiden hitauden, parantaminen ole huono asia. Siitäkään huolimatta, että on olemassa myös SSD levyjä.
 
Miksi ihmeessä tätä käytettäisiin RAID0ssa?

Verrattuna yhteen isoon levyyn, nähtäisiin ensin hirveästi vaivaa ja duplikoitaisiin komponentteja, että eri levypintojen lukupäät voi käsitellä eri raitoja, ja sitten softalla lukittaisiin ne kuitenkin käytännössä melkein aina käsittelemään samoja raitoja.

Ei juurikaan järkeä.

Toki käsitellessä raid-lohkoa pienempiä tiedostoja hyötyä tulisi rinnakkaisuudesta, mutta jos pikkutiedostojen käsittelyn nopeudella on väliä ja ne on tallennettu pyörivälle levylle eikä SSDlle, jotain on tehty pahasti väärin.
Mitä isompia levyt ovat, sitä vähemmän iops/TB ne tarjoavat. Jos firmani tarjoaa miljoonalle asiakkaalle 1TB cloud-tilaa ja ekan sukupolven storageserverit on täytetty 8TB levyillä ja seuraavan sukupolven levyt ovat 16TB:llä, niin iops/asiakas puolittuu.

Vaikka kuinka olisi isoja tiedostoja, niin joku nollaa isompi keskimääräinen iops-määrä per asiakas on silti pystyttävä lupaamaan.

Kun specsasimme viimeksi 16x 220levyn storage-ratkaisua, niin iops on yksi skaalautumistekijä, eikä levykokoa voi kasvattaa mielivaltaisesti, koska mikään storage ei ole koskaan oikeasti kylmää. Mitä isompi se datamassa on, sitä enemmän niitä hyvin satunnaisia operaatioita siihen levyyn kohdistuu.

Erilaisia caching-layereitä on satojen terojen dram-puskureista + liekö jo petatavujen ssd:eistä, mutta joku osuus luvusta osuu aina myös siihen viimeiseen storagetieriin. Ja jos voimme tuplata sen iopsin per TB, niin cachetuksessa voi sitten säästää jotain.
 
Luulisi tuosta olevan hyötyä hyprifi ssd/hd komboissa, joissa ssd osiosta saataisiin enemmän irti, ja toki sekin että erilaisten liitinten määrä vähenisi.
 

Statistiikka

Viestiketjuista
258 631
Viestejä
4 494 148
Jäsenet
74 265
Uusin jäsen
Oranta

Hinta.fi

Back
Ylös Bottom