Toshiba kondigt met helium gevulde 14TB-hdd met 9 platters aan

Toshiba heeft de MG07ACA-serie van hdd's aangekondigd. Deze bestaan uit modellen met 12TB en acht platters en 14TB-schijven met negen platters. In beide gevallen gaat het om 3,5"-hdd's met dikte van 26,1mm die gevuld zijn met helium.

Bij het model met 14TB-capaciteit hebben de pmr-platters een opslagdichtheid van ongeveer 1,56TB, bij de 12TB-modellen is dat een meer reguliere 1,5TB. De fabrikant gebruikt achttien koppen voor de versie met negen platters en zestien voor de 8-platter-hdd. Toshiba richt zich met de schijven op gebruik voor clouddiensten en enterprise-opslag.

De MG07ACA-schijven volgen de MG06ACA-modellen op. De maximale opslagcapaciteit van die serie bedraagt 10TB. De nieuwe schijven zijn met helium gevuld en Toshiba maakt gebruik van laserlassen om te garanderen dat de behuizingen volledig afgesloten zijn.

De harde schijven hebben een rotatiesnelheid van 7200rpm en zijn van een sata600-interface voorzien. Verder hebben ze beide 256MB cache. Toshiba begint per direct met het versturen van samples naar zijn klanten. Op een later moment moeten ze breed beschikbaar komen voor een nog onbekende prijs.

Het zijn niet de eerste 14TB-hdd's: WD kondigde in oktober al zakelijke 14TB-schijven aan. Western Digital en Seagate bieden al enkele jaren met helium gevulde hdd's aan. Helium heeft een lagere dichtheid dan lucht en zorgt zo voor minder wrijving, waardoor fabrikanten meer platters in de schijven kunnen stoppen.

Reacties (131)

[mark-k]

Kan iemand mij vertellen waar je dit soort schijven voor gebruikt? Het lijkt mij enorm veel data om in 1x kwijt te raken en de rebuild time van 14TB zal ook wel enorm zijn in raid. Is dit niet teveel risico?

[sdk1985]

Kan iemand mij vertellen waar je dit soort schijven voor gebruikt? Het lijkt mij enorm veel data om in 1x kwijt te raken en de rebuild time van 14TB zal ook wel enorm zijn in raid. Is dit niet teveel risico?

Ik vind dat altijd een rare manier van naar data kijken. Of je nu een 1 TB hard disk of een 14TB hard disk pakt, in beide gevallen is het vervelend als je vakantie foto's ineens weg zijn. De oplossing is niet het aantal disks verhogen (want je weet van te voren niet welke stuk gaat), maar een andere backup strategie toepassen.

Overigens zijn er tegenwoordig wat slimmere manieren om met redundancy om te gaan zoals SHR en Snapraid. Een 8 TB disk kun je in theorie in een uur of 8 weer vullen, een archive schijf gaat langer duren (100 MB/s via netwerk, anders zakt hij in).

[Akemi]

Dit zijn ook niet schijven die je even in een traditionele raid5 oplossing gebruikt. Hoogstens in een raid 0/1 oplossing.

[TD-er]

Nee dit soort schijven gebruik je in een oplossing met bijv. erasure code opslag, zoals Ceph filesystemen, of DDP van Dell of andere vergelijkbare technieken zoals ActiveScale van HGST (al gebruiken die hun eigen schijven )

In bijvoorbeeld een MD3460 kastje van Dell zou je dan met 4U 60 schijven kwijt kunnen. Netto blijft daar dan 575 TB per kastje over aan opslag als je DDP gebruikt.
Dat is toch wel een leuk aantal Petabytes per rack

RAID is niet echt meer van deze tijd.
Met Erasure code verdeel je de datablokken in een vast aantal kleine blokjes en schrijf je die pseudo-random over de hele pool van schijven weg.
Dus stel je hebt 100 schijven in de pool en je verdeelt je data in 8 blokken + 2 parity blokken (meestal vrij in te stellen), dan heb je 10 datablokken (in de praktijk meer, maar even als voorbeeld).
Die datablokken schrijf je dan naar "random" gekozen schijven. Dus maar een fractie van je schijven is bezig met een query.
Bij rebuilds komt het grote voordeel dan ook naar boven.
De nieuwe schijf zal namelijk met de maximale schrijfsnelheid beschreven worden en bij uitval van 2 schijven ga je dan binnen minuten van "critical" naar "degraded" en in een paar uren van "degraded" naar "normal". Tijdens zo'n rebuild is telkens maar een fractie van de schijven bezig met lees-operaties om die rebuild-schijven van data te voorzien.
Dus de impact is minimaal en de rebuild-tijden zijn erg kort. Bij RAID is de impact van een rebuild enorm en de rebuildtijden kunnen oplopen tot wel een maand op een druk systeem.

Je gebruikt dit soort opslag dingen voor hele grote archieven en/of object stores (bestanden opslaan per bestand, niet als een filesysteem), zoals cloud opslagdiensten doen. Denk aan Dropbox, Google Drive, Microsoft OneDrive.
Op die manier kun je data access heel erg goed schalen in de breedte. Voeg extra schijven toe en je hebt en meer capaciteit en meer bandbreedte erbij.

[borft]

Ik zie eigenlijk niet het verschil tussen een raid oplossing en jouw voorbeeld. Je beschrijft hier het gebruik van striping en parity om performance respectievelijk resilience te verkrijgen

[TD-er]

Ik zie eigenlijk niet het verschil tussen een raid oplossing en jouw voorbeeld. Je beschrijft hier het gebruik van striping en parity om performance respectievelijk resilience te verkrijgen

RAID schaalt niet boven enkele tientallen schijven.
Je zit altijd met "geklooi" van hot spare schijven per RAIDset en rebuildtijden die echt idioot lang kunnen zijn. Die rebuild kan zo lang duren dat je een volgende schijf defect hebt en dus echt data kwijt raakt.
Daarnaast is de performance impact op RAID echt goed merkbaar tijdens rebuilds.
Met Erasure code systemen reserveer je gewoon de capaciteit van N schijven die je als "hotspare" zou willen hebben. Wanneer een schijf uitvalt, ga je zo snel mogelijk de data die kritiek is geworden (dus zonder voldoende redundantie) migreren naar de gereserveerde ruimte en zodoende heb je heel snel weer de gewenste mate van redundantie.
Bij het rebuilden van een schijf, pak je dan eerst de blokjes die het meest kritiek zijn en ben je in minuten klaar met het kritieke deel en ga je daarna de nieuwe schijf dus volschrijven (en de gereserveerde vrije ruimte weer voldoende verdeeld is over genoeg schijven).

Voordelen:

• Weinig impact op performance tijdens rebuilds
• Zeer korte tijd dat data-redundantie "kritiek" is.
• Schaalt zeer ver door
• Performance schaalt mee met aantal schijven
• Veel meer flexibel in toekennen "hot spares", doordat dat per schijven pool gaat
• Mate van redundatie bij sommige implementaties vrij te kiezen

Nadelen:

• Meer rekenkracht nodig. Bij voorkeur 1 CPU core/thread per schijf (geen hoge eisen aan CPU-kracht per core).
• Performance kan meer fluctueren dan bij RAID, doordat opeenvolgende requests een aantal schijven overlap kan hebben.
• Implementaties zijn soms vendor afhankelijk (dus data overzetten en niet hdd's overzetten in ander systeem), maar dat is ook niet altijd even transparant bij RAID.

[dmantione]

Ik ben mninder positief dan jij over software-defined storage als Ceph. Ik heb er mee geëxperimenteerd om te kijken of het de RAID-kaarten kan vervangen, maar Ceph is om te beginnen retetraag vergeleken met een batterij servers met RAID-controllers, maar anderzijds is het erg onvolwassen. Als je bijvoorbeeld erasure-coding gebruikt, dan kan je geen block devices meer aanmaken, wat de praktsiche toepasbaarheid enorm inperkt. Ceph is bijzonder inefficiënt geschreven wat betreft geheugenallocatie, wat tot gevolg heeft dat je er processoren tegenaan moet gooien met veel megahertzen. Het is geschreven om efficiënt te zijn met 1 kern per schijf, maar dat faalt als je doorschaalt, omdat het Linux-geheugenbeheer niet goed schaalt als alle kernen tegeliijk geheugen bij de kernel willen alloceren.

De hersteltijd bij een defecte schijf is daarom vooral een theoretisch voordeel. Op dit moment is het veel zinniger om de hersteltijd van een RAID-array binnen de perken te houden door het storagesysteem zo te ontwerpen dat er geen flessehals ontstaat anders dan de schijf zelf. Je hebt daar controle over met de keuze van het aantal schijven per array, de hoeveelheid schijven die op een kabel zit en de RAID-rekenkracht van de RAID-controller. Moderne schijven halen snelheden tot 250MB/s, als je zorgt dat dat tijdens rebuilds behaald wordt, dan blijven de rebuildtijden binnen de perken.

Het snelheidsnadeel als je een zelfde systeem met Ceph zou bouwen is zo groot, dat er amper een zinnige casus voor te maken is.

[TD-er]

Met Ceph heb ik geen praktijkervaring. Wel met DDP van Dell en ActiveArchive van HGST.
Dat ActiveArchive systeem is een beetje lastig te benchmarken, aangezien er toch al snel zo'n 600 GByte aan RAM in zit, dus je zit nogal snel tegen cache-resultaten aan te kijken.
Met die Active Archive systemen heb je een CPU-core per hdd en per netwerkinterface en een flinke sloot geheugen. Dat zijn S3 object stores, dus in principe alleen via http benaderbaar, maar wel heel schaalbaar.
Met DDP van Dell heb je een aparte controller in de disk-enclosure die de dingen voor je regelt en die interface heeft naar de host via SAS. (tot 64 TB blockdevices via multipath en dan op de host aan elkaar knopen tot 1 volume als je zou willen)

Maar met beide oplossingen kun je vrij makkelijk opslagsystemen maken die een 40G netwerk verbinding voltrekken, is mijn ervaring. (met meerdere devices)
De lees-snelheid van RAID6 in die Dell systemen is wel hoger dan die van DDP, maar de schaalbaarheid is dan wel een dingetje. Schrijfsnelheid is vergelijkbaar.

Met Ceph moet je bij gebruik van Erasure code een cache aanhouden. Nadeel van zo'n cache is dat het de latency verhoogt.
Je moet dan namelijk eerst de data van de schijven naar die cache brengen om de blokjes samen te voegen en dan kan je de data pas van de cache lezen.
Voor zover ik weet had Ceph wel een mogelijkheid om blockdevices aan te maken. Alleen heb ik daar dus geen praktijkervaring mee.

[DLGandalf]

Je noemt Ceph onvolwassen omdat het geen block storage ondersteunt met erasure coded pools? Is het wel of niet ondersteunen van functionaliteit een kenmerk voor volwassenheid?
Overigens ondersteunt Ceph weldegelijk blockstorage op erasure coded pools since de laatste stabiele versie.

Ceph zien als een vervanging voor RAID kaarten is sowieso een verkeerde use-case. Kennelijk vind je lokale performance belangrijker dan node-failure redundant te zijn.

[dmantione]

Het kenmerk voor volwassenheid is dat het ingezet kan worden voor productie en de conclusie is daarbij dat een Ceph-installatie zowel kwa prestaties als op functionaliteit tekortkomingen vertoonde t.o.v. een traditionele opstelling met een parallel bestandssysteem gebaseerd op opslag met traditionele RAID. Hogere RAID-nveau's zijn vaak een commerciële eis en un die zin is het dus onvolwassen.

Redundantie tegen uitval van een node is ook met traditionele oplossingen te realiseren. Ook daar tegen bepaalde kosten, wat Ceph een kans zou bieden, maar die benut het niet: De traditionele oplossing blijft vooralsnog beter.

Het gaat om de totale prestaties van het systeem, maar omdat een beetje parallel bestandsysteem amper netwerkoverhead heeft, komt het uiteindelijk neer op lokale prestaties. In veel Ceph-opstellingen zie ik velen prutsen met netwerkjes van 10 gigabps of minder. Dat is de ruwe snelheid van ongeveer 10 schijven en daarom erg inefficiënt. In dat geval is het netwerk wel de flessehals.

Een beetje server met RAID-kaart kan tegenwoordig makkelijk 6 gigabyte per seconde het netwerk oppompen, als je dat moet vergelijken met een Ceph-installatie die moeite heeft om de 1 te halen, dan is de conclusie snel getrokken.

[Reactie gewijzigd door dmantione op 23 juli 2024 03:21]

[Terrestrial]

Ook ik blijf gewoon van mening dat dit nog steeds geoptimaliseerde RAID technologie is. (Redundant Arrey of Disks) Of je het nu software matig doet of de parity op een andere manier organiseert.het blijft RAID technology.

[TD-er]

Het heeft er zeker wat van weg. Sterker nog, in de basis is de DDP die Dell gebruikt niet heel erg verschillend van 8 + 2 RAID6.
Echter het grote verschil zit 'm erin dat je met RAID alle schijven uit een RAID-set gebruikt voor lees- en schrijfoperaties (N.B. bij lezen zou je de parity drives kunnen overslaan)
Hierdoor zit je met het grote probleem van performance bij rebuilds en ook bij veel concurrent read/writes.
Met Erasure-code heb je die problemen niet, of in elk geval veel minder dramatisch.
Maar daarbij komt ook nog dat je met RAID beperkt blijft tot wat je op 1 host kunt aansluiten. Met erasure code kun je veel verder doorschalen. Kijk naar Ceph, of ActiveArchive van HGST. Daarbij kun je de redundantie zo instellen dat je bijv. met 8+3 werkt. In dat geval kun je tot 3 willekeurige units (van totaal 11 units) verliezen zonder dataloss te krijgen. Een unit kan dan zijn een schijf, een node, een rack of zelfs een datacenter.
Zie dat maar eens met RAID te doen.

Dus ja, in de basis is er zeker overeenkomst met RAID en Erasure Code. Echter als het aankomt op schaalvergroting is er weinig reden meer om voor RAID te gaan.

[dmantione]

Nou beetje overdreven... Technologiën als Ceph en ActiveArchive zijn een combinatie van een parallel bestandssysteem en RAID, in dit geval dan erasurecoding genoemd, ineen.

Het staat je natuurlijk vrij om een parallel bestandssysteem als BeeGFS of GPFS te draaien en in je servers RAID-kaarten te gebruiken. Daarmee is schaalvergroting geen argument om geen RAID te gebruiken.

Omdat ik tot nog toe weinig gezien heb i software-defined storage wat redelijkerwijs tegen traditionele RAID-kaarten kan concureren, zie ik voorlopig nog wel toekomst in RAID-kaarten.

[bbob]

Conclusie is gewoon deze schijven gebruik je als je veel data hebt, dat kan in raid zijn of in andere vorm als je cluster met 100-200 of meer schijven hebt.

Voor de kleinere gebruiker met een nas zal het gewoon raid worden.

[tijgetje57]

oftewel gewoon software defined storage, blockbased. Zoals o.a. 3par heeft.

[servicedb]

Het verschil tussen RAID en SDS (Software Defined Storage zoals Ceph) is dat bij een RAID array alle data op één fysieke machine staat en bij een SDS oplossing alles op verschillende fysieke machines staat.

Een voorbeeld: Je hebt een RAID array van 10 harde schijven en je raakt één kwijt. Je moet bij het vervangen van die ene harde schijf een hele RAID array gaan rebuilden: dit duurt enorm lang en je storage wordt ontzettend traag.

Bij een SDS kan je makkelijk 100 schijven in een pool gooien. Van elke harde schijf hoeft maar een klein beetje gelezen te worden om één schijf te rebuilden. Het gevolg is dat er tijdens het rebuilden de storage snel is voor het normale server gebruik en dat het rebuilden ontzettend snel kan gebeuren omdat het op maximale snelheid weggeschreven kan worden.

Stel de schrijfsnelheid is 175 MB/s. Dat betekend dat je slechts 1.77 MB/s (175 / 99 schijven) nodig hebt van elke harde schijf om de nieuwe harde schijf in te werken. Bij een RAID array van 10 schijven heb je per harde schijf 19.4 MB/s (175 / 9) nodig en als je iets wilt openen, dan is dat ontzettend traag. Daarnaast is een deel in gebruik voor het normale storage gebruik en zal je in de praktijk niet altijd de hoogste snelheid behalen.

Dus kort gezegd: met een SDS heb je een snellere recovery time en hogere performance tijdens recovery dan in vergelijking met een RAID array. Verder minimaliseer je ook eventuele risico's met een kortere recovery time doordat je array sneller gezond is.

[Reactie gewijzigd door servicedb op 23 juli 2024 03:21]

[borft]

Ik snap je punt, maar bij raid met striping (bv raid50) lees je ook van meerdere disks bij een rebuild, waardoor je met de maximale schrijfsnelheid op je nieuwe disk kunt schrijven, terwijl je met 1/n-1 leest van de overige schijven

Overigens, als het op verschillende machines staat, heb je dan niet een veel hogere latency? Bij lokale storage is je latency <1ms, maar als er een extra laag tussenkomt, wordt het al snel veel hoger lijkt me

[Navi]

Een goed 10G (of hoger) netwerk over glasvezel heeft ook ontzettend lage latency hoor, zul je weinig van merken. Gaat echt over nanoseconden per hop.

[Joenino]

Klopt hier een Purestorage M10 richting ons HP C7000 chassis met 4x 10 Gbit bundel en de gemiddelde latency op een vm is sub 1 ms. Gemiddelde op de Purestorage is 0.34 ms op het moment. (er draaien zo'n 55 servers op)

[servicedb]

Zoals aangegeven zit de kracht bij een SDS oplossing juist in de bulk (100 harde schijven). Dit ga je niet éénvoudig krijgen met een doorsnee RAID oplossing. En als wel, dan heb je een grote SPOF.

Bij deze harde schijven wil je sowieso niet kijken naar de latency. Bij een SDS oplossing over het netwerk krijg je inderdaad een latency verhoging, maar dat zal bij deze harde schijven verwaarloosbaar zijn. Het doel is voornamelijk dienen als trage grote storage (denk aan Onedrive, foto's, backup, etc.).

Bij SSDs heeft dit natuurlijk meer impact, maar daar kunnen we een ander topic over beginnen. Mocht je de hoogste IOPS en laagste latencies echt nodig hebben dan kan je beter gaan voor lokale SSDs. In de praktijk voldoet SSDs over het netwerk vaak wel (vermits de juiste connecties gebruikt wordt ivm latencies) als je het combineert met voldoende RAM.

[isama]

Dat klopt, maar het verschil dat ik zie is dat dit op een hogere laag gebeurt waar het systeem bewust is van welke blokken er gebruikt worden en welke niet, daardoor kan het dan alleen de blokken kopieren die nodig zijn en dat scheelt natuurlijk in de rebuildtijd.

Natuurlijk gaat dit langer duren als je disk pool helemaal vol zit, maar daar staat dan weer tegenover dat als ik het me goed herinner de meeste raidcontrollers behoorlijk traag zijn met rebuilden om zo bandbreedte/iops te bewaren voor als het systeem het nodig heeft. Dit soort systemen kunnen op 100% blazen en heel even een pauze nemen als het systeem iets van de schrijvende disk nodig heeft.

[borft]

Hmm, die ervaring deel ik niet Bij goeie raidcontrollers is het configureerbaar is mijn ervaring.

Echter het argument dat je storagelaag bewust is van zowel de blocklaag als de fslaag is wel een goeie. Dat klinkt een beetje vergelijkbaar met iets als ZFS, of begrijp ik het verkeerd?

[MSalters]

Yup. Het is natuurlijk geen toeval. Iedereen die serieus met storage bezig is, snapt de limieten van RAID5/6. en zelfs RAID1 - je replacement disk is kritisch afhankelijk van een klein aantal andere schijven, en daardoor explodeert de rebuild time en de failure kansen. Fundamenteel blijft ook RAID6 een Error Correcting Code uit 1970.

[masterant]

Even wat kort door de bocht maar wellicht makkelijker uitgelegd dan alle goeie informatie die al gegeven is:

Raid voorbeeld bij rebuild= many-to-one (1 disk moet dus al het schrijfwerk doen en kan dus erg lang duren)
Dit soort oplossingen (GRID-achtig)= many-to-many = rebuilds zijn dus sneller

[Stijn98765]

dus stel een situatie met 100 schijven aan 50% gevuld. Eentje val er uit. De andere schijven vullen zich dan tot 50,5%, totdat de nieuwe schijf zich helemaal heeft ingewerkt.

[Reactie gewijzigd door Stijn98765 op 23 juli 2024 03:21]

[Snow_King]

Ik ben Ceph fan en kenner, dat voorop, maar, ZFS met RAID-Z3 zou hier ook nog kunnen.

Kleine vdev's houden van maximaal 11 disks. Dan heb je 8x14TB netto per vdev van 11 disks.

Dan blijft je recovery-tijd ook nog acceptabel.

[fastedje]

Raid is voor zulke grote schijven niet praktisch inderdaad, echter een ceph storage node zal toch op een server moeten draaien waar een.OS op staat. Hier heb je voor de betrouwbaarheid toch wel een raid disk voor nodig.

[n4m3l355]

Ik ben niet zo thuis in dit geheel aangezien ik enkel wat rommel met mijn Synology maar is hetgeen wat je hier omschrijft niet geheel gericht op de grote enterprise solutions? Terwijl Raid hoewel je het niet van deze tijd meer vindt, meer geschikt is voor de hobbyist thuis of de SME's? Of geeft het voor de ietwat serieuzere hobbist out of the box solutions die dergelijke technieken ondersteund? Mij klinkt het allemaal wel indrukwekkend echter zou het mij wel aanspreken om 5 a 10 van dit soort schijven thuis te hebben omdat het kan maar omdat ik niet beter weet gebruik ik maar een Synology.

[TD-er]

Voor opstellingen met minder dan pak 'm beet 10 drives zijn dit soort Erasure code oplossingen niet geschikt.
Het hele voordeel van Erasure code zit 'm namelijk in het idee dat de set schijven die actief zijn voor 1 opdracht kleiner is dan de hele pool aan schijven.

Ik zie alleen nog wel gebeuren dat afgeleiden van dit soort technieken in de nabije toekomst naar de NAS'jes komen. En dan bedoel ik meer dat je dan softwarematig 1 netwerkstation ziet, maar dat er op de achtergrond meerdere NAS'jes actief zijn en dat die onderling de data uitwisselen en zodoende de redundantie automatisch op peil houden.
Zeg maar een hybride oplossing van Cloudsync/Dropbox achtig gedrag, met daarbij ook de mogelijkheid om NAS'jes op verschillende locatie te hebben staan, of gewoon een erbij zetten en je hebt meer capaciteit en/of snelheid.
Oftewel dat je een management laag krijgt tussen de schijven en de applicaties, die zorg draagt voor de redundantie en eventueel mirroring van populaire data, maar ook synchronisatie tussen verschillende locaties en gebruikers en taken op zich neemt zoals backup en versiebeheer.
Allemaal zaken die stuk voor stuk nu ook wel door NAS'jes gedaan kunnen worden, maar eigenlijk totaal niet met elkaar integreren en eigenlijk al bijna een Master in de informatica vereisen om te configureren.

[DukeBox]

In veel gevallen moet je nu de afweging maken of je überhaupt raid wilt gebruiken.

RAID Arrays met dit soort schijven hebben vaak een hogere rebuild tijd dan restore tijd met gerelateerd dus ook een hogere performance impact.
Als je de redundancy op een lager niveau legt (bijv. het file system) kan de beschikbaarheid en rebuild (lees: her-distributie) aanzienlijk beter zijn.
Ook ben je dan veel flexibeler met performance, veel gebruikte data kan je op meerdere plekken zetten zodat deze sneller toegankelijk is en/of hogere beschikbaarheid heeft.

[The Chosen One]

Tja dat geld voor alle schijven op bepaalde punten in geschiedenis.

Eerst is de grootte nodig voor dataservers, dan voor "enthousiasts", dan voor de gewone persoon omdat games/progr's etc gewoon groter worden. Schuift gewoon door.
En de techniek en dus soms hogere prijs die er soms inzit zoals met de meeste dingen bedrijfsleven -> consumenten.

[Reactie gewijzigd door The Chosen One op 23 juli 2024 03:21]

[Kraz]

Niet helemaal waar in dit geval.
Als je deze schijven voor RAID 5 gebruikt en er valt er 1 uit, dan kan het zomaar zijn dat het een aantal dagen duurt voordat de data op de vervangen schijf weer terug staat. Al die tijd loop je een risico (als er nog een schijf uitvalt) dat je je gegevens kwijt raakt.

Ik zou in een zakelijke omgeving deze schijven meer als een WORM schijf gebruiken denk ik.

[mae-t.net]

RAID is geen backup, dus je bent sowieso je gegevens niet kwijt als je RAID offline gaat. Wel is het risico op onbeschikbaarheid van het systeem groter als hij nog staat te rebuilden en er een tweede schijf uitvalt.

[Ronnerd]

Niets staat je in de weg om een andere RAID variant dan RAID 5 te gebruiken waardoor dat risico veel beperkter gaat zijn.

[fastedje]

Dit document van Dell geeft een overzicht van de voor en nadelen van diverse RAID varianten http://en.community.dell....2D00_CD_2D00_DS_2900_.pdf.

Zo is er ook RAID10 Dual mirroring waarbij alle data op 3 schijven staat. Bij alle RAID configuraties is er nog het nadeel dat je de controller in write-through mode gaat als je je geen redundancy meer hebt.

Bij grote RAID5 arrays is er nog het risico dat er diskerrors zijn waar je pas te laat achterkomt. Dell heeft wel zoiets als patrol reads om dit weer voor een deel op te vangen.

[Ronnerd]

Waarom reageer je op mij? Ik heb het idee dat kraz meer aan deze info heeft dan ik.

[fastedje]

Het is ook meer een aanvulling op je suggestie om een andere RAID configuratie te gebruiken.

[Wannial]

Ik heb op mijn 10*4TB radi array ook al een rebuild time van meer dan een dag. Onderandere om die reden een RAID6 opstelling gekozen

[boolean]

Ik heb EXACT dezelfde config, maar de rebuild tijd bedraagt 6-9 uur. Jij hebt geen WD Red Pro's of Gold's gebruikt?

[Wannial]

Wellicht dat mijn synology langzamer is, is natuurlijk ook een kwestie van CPU power die je hebt he.
Ik gebruik HGST en hitachi schijven, enterprise class.

[boolean]

Dan is die Synology wel schandalig veel langzamer. Ik heb in het verleden (2011) een QNAP TS-879 Pro gehad en die deed er ongeveer net zo lang over als mijn huidige setup met een HW RAID controller in de DC/FS.

Als je tijdens het rebuilden het filesystem met rust laat is hij binnen 6 uur klaar. Wanneer je tijdens de herstel veelvuldig naar het filesystem schrijft, neemt het ruim 9 uur in beslag.

De 7200rpm schijven van WD/HGST/Hitachi zijn zo goed als gelijk aan elkaar (op firmware na), dus ik verwacht niet dat het daar aan zal liggen.

[Arokh]

Ik denk dat raid 5 zijn langste tijd echt wel heeft gehad. Al een poosje trouwens. Voor dit soort opslag.

[the_shadow]

Ik denk dat raid 5 zijn langste tijd echt wel heeft gehad.

De meesten raden RAID 5 af voor schijven groter dan 1TB. Daar zijn we inderdaad al een tijdje voorbij.

[killerdemon]

Dan maak je een RAID 6 toch?

[jabwd]

Ik gok hier maar een beetje; op dit moment zijn er best veel archieven gemaakt van magnetic tapes. Ik weet niet precies wat de levensduur van z'n 14TB HDD is en hoe lang de data ook onbeschadigd er op zou kunnen blijven staan maar het lijkt mij 1 van de meer voor de hand liggende manieren.

Hier IBM over hun eigen tapes:

IBM® TS1155™ Tape Drive gives organizations an easy way to deliver fast access to data, improve security and provide long-term data retention--and at a lower cost than disk-based solutions. TS1155 is designed to support JD and JZ media formats, but is equipped with an advanced read/write subsystem that enables the use (or re-use) of JD media at a 50 percent higher capacity than previous-generation drives. TS1155 also offers high-performance, flexible data storage with support for data encryption.

https://www.ibm.com/us-en/marketplace/ts1155

Ik denk niet dat HDDs nog heel lang voor actieve storage gebruikt zullen worden, ik denk ook dat Toshiba/WD daarom zich misschien meer op dit segment willen richten. Al zitten de tape drives van IBM nu richting de 15TB

[Reactie gewijzigd door jabwd op 23 juli 2024 03:21]

[Arokh]

Dat ze die tapes als 'fast' aanduiden. :-) ten ozichte van een HDD zijn ze gruwelijk langzaam, tov SSD zijn ze nog gruwelijker langzaam, alleen ten opzichte van pen en papier zijn ze 'fast'...

[DukeBox]

Hoezo ? De bandbreedte van tape is over het algemeen aanzienlijk hoger dan van een HDD.
LTO 7 doet met compressie al snel 500MB/s. Ik heb nog geen HDD gezien die dat (sustained) doet.

[MSalters]

HDD's komen "met compressie" redelijk in die richting hoor. En dan negeer ik nog deduplication, wat op tape feitelijk niet kan (geen random access) maar wel de meest efficiente vorm van compressie is.

[DukeBox]

Zover ik weet doen HDD's geen hardware compressie. De-duplicatie gebeurd met tape en degelijke backup software ook echter alleen op basis van file hashing maar qua houskeeping wordt het er niet minder ingewikkeld op. Met dedup backups moet je ook overwegen of je het wel wil gebruiken aangezien het een flinke impact kan hebben op je restore tijd (zowel positief als negatief).

[Reactie gewijzigd door DukeBox op 23 juli 2024 03:21]

[MSalters]

Ik zet "met compressie" niet voor niets tussen aanhalingstekens. Het gebeurt inderdaad niet in hardware, en wel om de simpele reden dat het al lang niet meer kosteneffectief is. Met alle cores op een moderne Xeon is er geen winst te behalen om dat te offloaden naar dure, in klein volume gemaakte hardware.

Het is nog wel een feature op dure IBM mainframes om de simpele reden dat 1% van je mainframe capaciteit gebruiken voor software compressie nog steeds enorm duur is. Mainframes zijn nog steeds niet kostenefficient op dat gebied.

[Arokh]

Maar kan die tape ook willekeurige bestanden vinden net zo snel? Dat geloof ik nooit. En die tape die je aanhaalt heeft toch een max capaciteit van 6TB? Ook niet echt vergelijkbaar.

[DukeBox]

Uiteraard is seek niet snel, maar in dit geval mag het duidelijk zijn dat 'fast' duid op de doorvoersnelheid.

En de vergelijking van 6TB t.o.v. 14TB is opzich ook niet oneerlijk, er zit ook bijna 2 jaar tussen de release van beiden maar dan zou je ook kunnen vergelijken met LTO8 (12TB, 360MB/s uncompressed, 530MB/s compressed)

[Arokh]

Die tapes zijn inderdaad sneller dan ik dacht. Wij zijn al een tijdje van de tapes af omdat ze zo ontzettend vaak lees en schrijfproblemen gaven (5 op de 7 backups mislukten), dus ben er helemaal uit :-)

[DukeBox]

Dat moet dan wel lang geleden zijn. Sinds onstream waar er variabele koppenstand gebruikt werdt speelt dat niet echt meer.

[svennd]

Ik denk dat je dit soort disks als tussenstap tussen tapes en disk/flash moet zien. Storage servers zullen flash gebruiken om super snel te zijn, iets minder actieve storage zoals het OS kan perfect op cheap disks, archiveren kan super snel en goedkoop naar deze type disks, om vervolgens op tape te worden gezet.

Tape is nog steeds best goedkoop en een pak betrouwbaarder dan disks. Maar access time is zeer lang

[psdata]

Laatste generatie LTO tape's + device is Versie LTO8. Deze kan tot op heden 30Tb opslaan (met compressie), Ibm levert dit al reeds een tijdje: https://www.ibm.com/us-en/marketplace/ts2280pe's
Op basis van een meerdere drive's en een tapelibrary kun je heel veel opslaan
zie : https://www.ibm.com/us-en/marketplace/ts4500 (Store up to 8.76 PB of data in a single 10 square-foot library using LTO 8 cartridges). Maar z'n library kun je ook met verschillende drive uitrusten.

Op deze Wikipedia staat nog wel twee leuke plaatjes van tape een "Tape library
" https://en.wikipedia.org/wiki/Tape_library
Rechts boven een moderne, en Rechts beneden de oude handmatige


Ik ben geen IBM sales maar hun site zoekt wel gemakkelijk

[Reactie gewijzigd door psdata op 23 juli 2024 03:21]

[dmantione]

Om je een idee te geven: Bouw een opslagsysteem van 10 petabyte aan capaciteit en doe dat tegen de laagste kosten en energieverbruik. Je zult merken dat grotere schijven behoorlijk opbrengen om de doelen te halen. Snelheid ten minste 20 gigabyte/s.

Dergelijke systemen komen heel veel voor in rekencentra: Mensen willen van alles opslaan. Snelheids is soms een grote factor, soms ook niet en dient het vooral als archiefopslag.

[Reactie gewijzigd door dmantione op 23 juli 2024 03:21]

[Verwijderd]

Precies, de SSD's vreten ook veel meer stroom dan vergelijkbare opslag op HD.

[dmantione]

Ja, maar de energiekosten zitten niet in de SSD's zelf: Omdat je er veel meer van nodig hebt om dezelfde capaciteit te halen, heb je meer servers nodig. In servers zitten processoren. En processoren, dat zijn de echte kachels in computers. Processoren kan je in opslagsystemen missen als kiespijn: Ze zijn een noodzakelijk kwaad, maar ze zijn duur en verbruiken veel energie.

Ook bij harde schijven tikt het al zwaar aan, en vaak kom je uit op constructies waar één processor meer dan 100 schijven aanstuurt. Dat moet prestatietechnsich kloppen uiteraard, maar over het algemeen is dat goed te doen: Een moderne processor kan best wat trekken als je de software een beetje goed regelt.

[Reactie gewijzigd door dmantione op 23 juli 2024 03:21]

[TD-er]

Je bent ook nogal wat kwijt aan "vaste kosten", zoals een kast, rackspace, controllers, etc.
Als je die vaste kosten kunt uitsmeren over meer opslagcapaciteit, is dat natuurlijk voordeliger.
Zelfs als de grote schijven dan duurder zijn per GB, kan het onder de streep nog steeds voordeliger zijn om dergelijk dure schijven te kopen.

[dmantione]

Precies en daarom is het goed een heel opslagsysteem uit te gaan werken, omdat je dan ook moet kijken naar factoren als de kosten van servers, controllers, de huur van ruimte in een rekencentrum e.d. Pas als je het uitwerkt, dan zie je de waarde van een schijf waar veel meer op kan, het scheelt gewoon fors in de totale kosten.

[Niet Henk]

Zover ik weet m.n. cold storage, opslag van grote bestanden waar zeer weinig van gelezen wordt, als alternatief voor tapes. Je kan bijvoorbeeld denken aan lange-termijn opslag van camerabeelden. Maar er zijn veel toepassingen waarbij cold storage handig kan zijn.

Omdat de schijf erg weinig gebruikt wordt, is de kans op falen, en de impact van lang wachten op een rebuild beperkt. Het is wel spijtig als dit voorkomt tijdens het schrijven.

[Malantur]

Zoals @DukeBox voorstelt denk ik ook dat ze zonder RAID kunnen draaien in services zoals Dropbox en Facebook. Deze kunnen het zich niet veroorloven dat er plots een deel van de data verwijnt, er zou nogal moord en brand geroepen worden denk ik.
En er zijn veel redenen te bedenken waarom er niet 1 maar ineens meerdere schijven uit een RAID set tegelijk kapot gaan of niet beschikbaar zijn: voeding die zich opblaast, airco kapot dus oververhitting, stroomuitval, bliksem, brand, slechte manipulatie van personeel (“oei de verkeerde stekker uitgetrokken”), ...

Dus wat veel logischer is, is om de data te parkeren in 2 of meer server parken in verschillende landen.

Neem bv de 2GB gratis opslag van Dropbox. 14TB per schijf betekend dat je 7000 users per schijf kan parkeren.
Neem dan een redundantie van 3 schijven a 650 dollar per stuk, komt op net geen 2000 dollar. Zo kost een 2GB stukje gratis dropbox ruimte in aanschaf dus ongeveer 28 dollar cent.

[jeffer]

Die berekening klopt helaas niet helemaal....Je vergeet namelijk nog even de servers mee te rekenen,en de bijkomende netwerkapparatuur, de bijkomende datacenter kosten, personeel om die servers en het netwerk te beheren, een development team om de software te schrijven en onderhouden, een sales, marketing, administratie en support team. Een pand welke gehuurd moet worden om dat personeel in te laten werken, apparatuur waar op gewerkt moet worden en een behoorlijk budget voor marketing....inmiddels zit je dus wel op 28 dollar per 2gb gratis.

[Reactie gewijzigd door jeffer op 23 juli 2024 03:21]

[Arokh]

Ik weet nog dat men exact datzelfde zei tegen mij toen ik een PC kocht met 850MB opslag erin. De meeste mensen hadden toen ook geen idee wat ik met zo idioot veel ruimte moest doen.

[mark-k]

Oh nee ik snap best dat je 14TB makkelijk vol kunt krijgen, maar om dan alles op 1 schijf te gooien leek mij nogal gewaagd.

[Arokh]

Ik snap je wel, maar dat is dus eigenlijk altijd het geval. In mijn voorbeeld gebruikten mensen nog enorme stapels diskettes om dingen op te slaan. Ik had spelletjes die op 30 diskettes stonden (1 foutje op een van de diskettes en je hele programma deed het niet). Dat was eigenlijk een soort raid 0.

Maar ik maak ook verschillende backups. Ik heb 1TB met belangrijke data op One Drive staan, heb een 4TB schijf met heel veel spullen bij mijn ouders liggen en thuis een soort Raid 1 van al mijn bestanden.

Zoiets lijkt me beter dan vertrouwen op 1 raid 5 systeem.

[CH4OS]

Met zoveel storage wil je ook geen RAID gebruiken. Dan gebruik je eerder oplossingen zoals ZFS.

[terror538]

feitelijk is de onderliggende architectuur van ZFS gelijk aan raid. En de rebuildtijd is dramatisch, die kan zelfs slechter zijn dan RAID omdat er 'ongesorteerd' gerebuild wordt. Dat wil zeggen dat alle superblocks in volgorde van wegschrijven worden ingelezen en gerebuild, met een oude pool waar veel data gewijzigd is is dat dus hopeloos inefficient.

Daar komen gelukkig wél veranderingen in, op de laatste OpenZFS conferentie zijn een aantal verschillende technieken gepresenteerd die de rebuild tijd dramatisch kunnen verlagen.

[LordSinclair]

Dat is een uitspraak van aller tijden ;-)

Wat nu nog veel lijkt is over een paar jaar normaal en een paar jaar later weinig.

[totaalgeenhard]

Backup server.
Archief.

Opslag etc..

Bij RAID 5 kunnen er 2 schijven tegerlijkertijd stuk zijn.

Rebuild doet er niet, je kunt bij data tijdens rebuilden.

De vraag die je kunt stellen of particulieren/bedrijven straks nog lokaal opslag zullen/willen hebben.


Stel op een dag hebben we allemaal
> 1Gb/s internet up&down met latency van < 10ms.

Dan is het de vraag of je liever een dienst van 10 euro per maand afneemt voor 10TB opslag hebt en er niet naar hoeft om te kijken. Of dat je zelf hardware gaat inkopen, onderhouden etc..

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 03:21]

[Burn_and_Fire]

Als er minder weerstand gewenst is, is het dan niet veel makkelijker om vacuüm toe te passen? Dan heb je helemaal geen "lucht"weerstand. Zou dat zo veel moeilijker zijn dan met helium vullen?

[Mijzelf]

Gaat niet met de gebruikte technieken. De kop heeft het gas nodig om op de juiste afstand tot de platter te blijven.

[thof]

Zie het als een soort luchtkussentje, die moet voorkomen dat de koppen over de platters heen slepen (krassen).

[hood]

http://en.wikipedia.org/wiki/Flying_height

Vacuüm werkt niet omdat dan de kop over de platter schraapt.....

[DisasterMaster]

Ja. Het op grote schaal produceren van met helium gevulde, hermetisch afgesloten harde schijven bleek een enorme uitdaging te zijn waar vele jaren research voor nodig was. Een vacuüm creëren en in stand houden is voor zover ik weet productietechnisch nog een stuk lastiger dan een harde schijf vullen met een gas en deze hermetisch te sluiten. Verder 'zweeft' de head van een moderne harde schijf (voor zover ik weet, correct me if i'm wrong) nog steeds op een zeer dun laagje gas. Bij een (perfect) vacuüm kun je deze techniek niet meer toepassen, er is immers geen gas meer. En er zijn nog meer praktische problemen zoals minder warmteoverdracht, etc. In theorie zou je inderdaad nog grotere winsten uit kunnen halen dan het gebruik van een zeer gas als helium, maar dit zal niet opwegen tegen de praktische problemen waar je tegenaan zal lopen.

[isama]

Dat klopt, maar blijkbaar is het veel makkelijker om een behuizing goed genoeg te sealen om de helium erin te houden (voor een lang genoege tijd) dan een behuizing daadwerkelijk vacuum te trekken

[Alkjoa]

Een aspect dat ik hier nog niet heb zien langs komen is dat helium een zeer goede warmtegeleider is, ten minste wat gassen betreft. En de afvoer van warmte is nou juist een van de belangrijkste factoren die de levensduur van een HDD bepalen.

[Becquerel]

Wat versta jij onder vacuüm? Een perfect vacuüm kan niet, dus er blijft altijd wel wat over. En wanneer de druk laag genoeg wordt, zit je straks onder de damp druk van de metalen / andere onderdelen in de schijf, en dan gaan die dampen, dat lijkt me niet helemaal de bedoeling.

Gewoon vullen met Helium lijkt mij het beste, ik kan het mis hebben, maar dan loop je toch minder problemen aan.

[mae-t.net]

Tegen losgeslagen atomen heb je getters, dus het onderhouden van een hoogvacuum is niet zo'n probleem. Dit was gewoonte vanaf de eerste buizenradio t/m de laatste televisie met beeldbuis. Wel zitten er zoals elders genoemd andere uitdagingen aan het laten werken van een harddisk in vacuum.

[Roelof]

En waarop moet de kop dan zweven

[netmeester]

Heb ik me ook eens afgevraagd en dit opgezocht, maar kan de bron nu ff niet vinden...

Dat is inderdaad moeilijker. Er moet een soort van gas tussen de kop en de platter zitten als 'kussen'.
Als dat er niet is heb je kans dat de kop op de platter knalt.

edit: had eerder een andere uitleg staan waar ik achteraf m'n twijfels over had...

[Reactie gewijzigd door netmeester op 23 juli 2024 03:21]

[Durandal]

Ik weet dat waterstofmoleculen klein genoeg zijn om uit je waterstoftank van je auto te ontsnappen. Dat betekent dat je vacuum harddisks na een tijdje niet meer vacuum zijn maar vol zitten met H2 uit de atmosfeer. Ik denk dat dat een probleem is.

[mae-t.net]

Electronenbuizen en sommige gasgevulde lampen hebben daarvoor een zogeheten getter. Dit is een reactief materiaal dat met alle vreemde moleculen reageert. Tot het op is, maar dat kan afhankelijk van de seal tientallen tot honderden of zelfs duizenden jaren duren.

[Durandal]

Oh wist ik niet. Goede oplossing.

[ragcage]

Waarom gaat de rotatiesnelheid van HDDs nooit omhoog? Ik herinner me in het verleden een paar schijven met 9400 RPM en 12000 RPM gezien te hebben voor enorme prijzen.
Alles gaat tegenwoordig sneller maar dit is zoiets dat dan blijft hangen op 7600.

[S0epkip]

Dat waren de raptors, die zijn nu obsolete door SSDs. De rotatiesnelheid is beperkt om de warmteproductie en het stroomverbruik laag te houden. De snelheid is 'voldoende hoog' en bovendien is er met een lagere rotatiesnelheid minder kans op mechanisch falen.

[Mijzelf]

Waarom zou je? In theorie kan je dat een paar msec toegangstijd opleveren. Dat was de moeite waard toen er geen alternatieven waren. Vandaar dat er 10kRPM disks werden gemaakt tegen enorme prijzen.
Maar tegen een SSD legt hij het compleet af. Waar je de toegangstijd van een harddisk in milliseconden uitdrukt (ongeveer 10) doet een SSD het in microseconden.
Dus de niche van dure, hoge RPM disks is verdwenen.

[hood]

Hoger verbruik en daardoor warmer en daardoor kortere levensduur? Denk ik.

[Navi]

10K en 15K schijven bestaan nog steeds en worden in servers vaak gebruikt. (zijn overigens zeer betrouwbaar!)

Nadeel voor een consument is o.a de enorme herrie die er vanaf komt, en dan de prijs. Een SSD is dan gewoon een beter keuze.

[Reactie gewijzigd door Navi op 23 juli 2024 03:21]

[ManIkWeet]

Waarom worden deze schijven gevuld met helium? Ze zouden ook vacuum gemaakt kunnen worden toch?

[Becquerel]

https://en.wikipedia.org/wiki/Flying_height

[ManIkWeet]

Je zou niet verwachten dat deze link het antwoord geeft, maar dat doet ie wel. Zeer interessant!

[FastRDust]

mij vermoeden is dat vacuum zwaarder is dan lucht en helium lichter dus minder zwaar.
dit denk ik en ik zeg niet dat het zo is

[Jape]

Vacuum is het lichtste. Er zijn dan geen moleculen, dus ook geen gewicht. Helium is lichter per volume dan lucht, en vacuüm is dus weer lichter dan helium.

[FastRDust]

kan de druk dan niet meer invloed hebben op het reageren van de platters?
dan lijken mij deze veel gevoeliger voor het niet waterpas liggen.

[Jape]

Je vraag is me niet helemaal duidelijk.

Er moet in ieder ieder geval een gas aanwezig zijn om een bel te vormen onder de leeskop, andere schraapt die over de platter en is je schijf stuk.

Het gaat overigens bij een ander gas over de dichtheid en niet over de druk. Je kunt de dichtheid uiteraard ook beïnvloeden door de druk te variëren, maar dan moet de behuizing extreem goed gesloten zijn.

[tijgetje57]

vacuum heeft geen lucht of gas maar de naald heeft het gas nodig om te kunnen functioneren.

Anders krijg je te veel wrijving.

[ManIkWeet]

De naald zou helemaal geen wrijving hebben in een vacuum

[mjansen2016]

Degene die zich nog de Quantum Bigfoot 5,25 HDD's die 2 bays in beslag namen vanwege meerdere platters, pinken nu een traantje weg...

[Blokker_1999]

Die bigfoot van mij nam toch echt maar 1 bay in beslag. Ze gebruikten wel net een 5,25" bay ipv de huidige 3,5" bay. Als ik me niet vergis kon je die zelfs met 2 in 1 bay steken.

[tweazer]

Precies, die bigfoots waren een geweldige stap vooruit in prijs/Mb, ten koste van snelheid. Ik had eerder associaties met dit soort zware jongens.. Daar krijg ik geen tranen van, eerder old stuff, blij dat het weg is .....

[SMSfreakie]

van de week nog net een 2GB bigfoot uit een oude Compaq gesloopt puur voor de nostalgie..
Verder wou ik de mediaGX cpu ook nog wel bewaren voor de fun.. alleen die zit gewoon op het bord gebakken dus dat werd hem even niet.. _{iets met te koud buiten}

nou m'n USB2 SATA/IDE converter nog even terug vinden...

[PPie]

De opslagdichtheid (bits/oppervlak) lijkt toch eindig te zijn, gezien ze weer terug gaan naar grote aantallen platters.
Daar Samsung al een 16 TB 2.5" SSD heeft, lijkt dat 16 TB een beetje de grens zal worden van HDD naar SSD?

[dmantione]

Die 16TB-SSD is een stuntproduct, om aandacht te trekken. Er zijn mensen die er naar vragen, maar Samsung geeft nul op het rekest, ze willen 'm niet leveren.

De opslagdichtheid van platters nam een tijdje lang niet toe, omdat de grenzen van de PMR-opnametechniek bereikt waren. Om toch grotere capaciteiten te kunnen leveren, zijn hardeschijffabrikanten helium gaan gebruiken om meer platters te kunnen plaatsen.

Dat heeft de fabrikanten de tijd gegeven om te werken aan de echte oplossing: Een nieuwe opnametechniek. Binnenkort komen schrijven die van HAMR- en MAMR-opnametechniek gebruik maken op de markt en vanaf dan zal de dichtheid weer toenemen. Er wortd gezegd dat de weg tot 40TB per schijf open ligt. Daarmee lijkt de toekomst van de harde schijf voor de komende 10 jaar verzekerd.

[himlims_]

helium gevuld - is dat wat ze noemen cloud-opslag

[hood]

De wolken op aarde zijn van waterdamp. Maar misschien heb ik wel honger en begrijp ik de grap niet.

[RobinF]

Helium gaat omhoog in lucht (richting de wolken)

[MrMonkE]

sterker nog.. helium gaat de ruimte in. zo licht is het.

[StefanDingenout]

Ja dat zijn regenwolken, maar wolk is ook een algemene term als in stofwolk, gifwolk, en ... gaswolk. Zou me verbazen als er zich ook een wolkje vormt in de HDD, daar niet van.

[tweazer]

en wanneer het fout gaat heet het a-zure

[Navi]

In de AmazonE?

[tweazer]

of in New York als de politie opgeschakeld wordt

[Reactie gewijzigd door tweazer op 23 juli 2024 03:21]

[BroederM]

Is ook niet geschikt voor opslag van muziek bestanden, alles krijgt een hoog stemmetje

[itlee]

mooie praat allemaal dat je geen raid moet gebruiken, maar een beetje NAS ondersteunt alleen maar raid. Dus alle fancy "praat" heb je niet veel aan in mijn optiek...of jullie moeten zeggen ik heb een goeie tip.

[tijgetje57]

Openzfs, 3par of andere keuze voor software defined storage. Dan heb je geen raid meer.

[Reactie gewijzigd door tijgetje57 op 23 juli 2024 03:21]

[the_shadow]

Behalve dan dat je dan hetzelfde geintje doet in software, in plaats van op de controller. Verder is het zo dat er niets mis is met RAID 10, je moet met schijven van dit formaat gewoon geen RAID 5 of zelfs 6 gebruiken, daar is de rebuild tijd gewoon te hoog voor.

[tijgetje57]

Nee, je doet niet hetzelfde.

Laat het los, raid en 3par is niet hetzelfde. Blockbased storage, dus om het even kort uit te leggen je hebt een spare of 2. Alle bestanden zijn geknipt in blokjes, die blokjes zijn verdeeld over bijvoorbeeld de 20 SSD schijven die je erin hebt zitten. Zodoende als je wat vraagt gaan er 20 SSD schijven voor je aan de gang.

Gaat er eentje stuk of hij wordt slecht kopieert hij de blokjes over naar de spare SSD. Daarna markeert hij de SSD disk. En met de service van HP heb jij al sneller een SSD in huis dan dat jij het ziet dat hij stuk is.

Als hij geplaatst is knipper je met je ogen en het deel dat rood was in de pie chart, van de stukke disk, is weg. Dus hoezo rebuild tijd?

[stresstak]

mooie praat allemaal dat je geen raid moet gebruiken, maar een beetje NAS ondersteunt alleen maar raid.

Dan moet je niet een 'beetje NAS' kopen, maar een behoorlijke.
Een behoorlijke ondersteunt ook zfs of btrfs

https://www.synology.com/en-global/dsm/Btrfs

En niet alleen maar raid, maar ook 'single' is vaak mogelijk. Het blijven keuzes.

[ASS-Ware]

Dan moet je niet een 'beetje NAS' kopen, maar een behoorlijke.
Een behoorlijke ondersteunt ook zfs of btrfs

https://www.synology.com/en-global/dsm/Btrfs

Bij Synology nassen is het dan BTRFS op RAID he.

[jimbo123]

Dit gaat over enterprise storage oplossingen, niet over een simpele NAS.
Denk aan Ceph etc.

[Becquerel]

Ik koop dan ook geen NAS om mijn NAS van te maken, ik gebruik gewoon een standaard motherboard die een beetje laag in energie verbruik is.

[Verwijderd]

Is dikte van 26,1mm de standaard?

[satoer]

Ik heb nog steeds geen lang termijn opslag vertrouwen in die helium schijven. over 10 jaar wil ik nog steeds m'n backup schijven kunnen lezen. Is dan ondertussen de helium niet vervlogen? Latex ballonnen zijn binnen 5 dagen al hun zweefvermogen kwijt. Die metallic ballonnen zijn een stuk beter, maar ook daar vervliegt langzaam maar zeker de helium.