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
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.
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.
Ja se tukee hot swappia myös eri tyyppisten levyjen välillä (firmistuen niin salliessa).
Helppoa, kun emolevylle laitetaan jatkosaa vain yhdenlaisia massamuistiliittimiä.
Liitännän soisi yleistyvän kuluttajapuolellakin.
data-unfurl="true" data-result-id="249500" data-url="https://en.wikipedia.org/wiki/NVM_Express#U.3_(SFF-8639)" data-host="en.wikipedia.org" data-pending="false">
class="link link--external fauxBlockLink-blockLink"
target="_blank"
rel="nofollow noopener"
data-proxy-href="">
NVM Express – Wikipedia
en.wikipedia.org
https://www.seagate.com/gb/en/innovation/multi-actuator-hard-drives/
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 https://blog.seagate.com/craftsman-ship/multi-actuator-technology-a-new-performance-breakthrough/ 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. 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.
Lomituksella saadaan kaistaa, siihen ei tämä vaikuta, vain keskimääräiseen hakuaikaan.
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.
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".
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ä.
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".
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ä.
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.
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.
Kommentoi uutista tai artikkelia foorumilla (Kommentointi sivuston puolella toistakseksi pois käytöstä)
Lähetä palautetta / raportoi kirjoitusvirheestä