NAS upgrade RAID1 array duurt wel erg lang

[Marcel-J]

Beste mensen,

We zijn in bezit van een QNAP Turbo TS-459 Pro II NAS (4 GB intern geheugen, Intel Atom D525 1.8 Ghz dual-core processor).

Deze NAS is al best een paar jaartjes oud, maar functioneert nog prima. Daarom besloten we in juli jongstleden om de RAID1-array die we in deze NAS gebruiken te upgraden van 2x 8TB naar 2x 14TB.

Nu hadden we jaren terug al een keer geupgrade van 2x 2TB naar 2x 8TB. Daarvan kan ik me herinneren dat het hele proces best lang duurde.

Maar wat ons dit keer overkomt is volgens mij niet normaal meer. We hebben netjes alle aanwijzingen opgevolgd. Volgens de specs moet deze NAS harde schijven van maximaal 16TB aan kunnen. Dus we menen dat de twee aangekochte schrijven van 14TB zou moeten werken (Western Digital Red Plus WD140EFGX).

Uit het systeemlog heb ik hier een paar relevante momenten overgenomen:
- 11 juli 2023 19:16 uur eerste oude RAID 1 schijf verwijderd (8TB)
- 11 juli 2023 19:19 uur eerste nieuwe RAID 1 schijf geplaatst (14TB)
- 13 juli 2023 06:15 uur Rebuiling completed
- 13 juli 2023 08:10 uur tweede oude RAID 1 schijf verwijderd (8TB)
- 13 juli 2023 08:13 uur tweede nieuwe RAID 1 schijf geplaatst (14TB)
- 14 juli 2023 17:10 uur Rebuilding completed
- 14 juli 2023 17:10 uur Do RAID size expension

En met dat laatste is de NAS sinds 14 juli dus al mee bezig.
Het is nu 23 september, dus meer dan twee maanden verder ! ....

De NAS herkent de nieuwe harde schijven wel met het juiste formaat. Echter kan ik de RAID 1 array nu nog steeds "slechts" gebruiken op de oude omvang van 8TB, omdat de NAS aangeeft dat hij aan het uitbreiden is.

Op de NAS zie ik de rode LED die de harddisk-activiteit aanduidt wel knipperen, dus het is net alsof de NAS nog iets aan het doen is. Op de systeempagina van de NAS staat de aanduiding van de uitbreiding al lange tijd op 50%. Zie bijgevoegde screenprint:



Ik meen me ter herinneren dat dit percentage een paar dagen na het plaatsen van de tweede harddisk een poosje op meer dan 50% heeft gestaan, maar dat weet ik eerlijk gezegd niet zeker meer. Feit is echter dat ik nog steeds de oude capaciteit van 8 TB heb....

Wat is hier aan de hand ?

Marcel-J.

[leonbong]

Ik kan op de hcl van deze nas geen schijven vinden dan 6TB dus misschien ondersteund hij toch geen schijven groter dan 6TB.

Ik kan wel vinden dat array’s 12TB mogen zijn.

[Mijzelf]

Heb je shell toegang?

[Marcel-J]

leonbong schreef op zaterdag 23 september 2023 @ 08:39:
Ik kan op de hcl van deze nas geen schijven vinden dan 6TB dus misschien ondersteund hij toch geen schijven groter dan 6TB.

Ik kan wel vinden dat array’s 12TB mogen zijn.

Volgens de handleiding maximaal 16TB.
En de huidige 8TB schijven deden het er ook in, die waren ook al groter dan 6TB.

[Marcel-J]

Mijzelf schreef op zaterdag 23 september 2023 @ 09:04:
Heb je shell toegang?

Dit vergt voor mij een nadere toelichting. Ik ben geen automatiseringsdeskundige, dus ik weet eerlijk gezegd niet wat je bedoelt.

[reinier68]

Ik ken de QNAP's niet heel goed, maar kan het zijn dat je storage manager is vastgelopen?
Misschien een reboot nodig om de zaak weer in het gareel te krijgen.

[Mijzelf]

Marcel-J schreef op zaterdag 23 september 2023 @ 09:53:
[...]


Dit vergt voor mij een nadere toelichting. Ik ben geen automatiseringsdeskundige, dus ik weet eerlijk gezegd niet wat je bedoelt.

Kun je inloggen via ssh of telnet? Het vergroten van de raid array zou hoogstens iets van 10 minuten moeten kosten, maar bestaat wel uit 3 stappen. (partities vergroten, raid array vergroten, filesysteem vergroten) Ik neem aan dat 1 van de stappen is mislukt, en dat de firmware dat niet doorheeft. Vanuit een shell kun je zien waar hij is gebleven, en eventueel manueel die stap voltooien.

[leonbong]

Misschien maar eens gewoon het apparaat herstarten.
Je hebt de oude schijven toch nog dus geen dataverlies.

De rebuild zou naar herstart gewoon door moeten gaan.

[ Voor 52% gewijzigd door leonbong op 23-09-2023 11:44 ]

[Marcel-J]

@Mijzelf: misschien kom ik een beetje dom over, maar ik weet eigenlijk nog steeds niet wat je bedoelt met ssh of telnet. Ik heb er op gegoogeld en zag vervolgens op de website van QNAP hoe ik dat aan of uit kan zetten. In mijn settings staat ssh aan en telnet uit. Maar ik weet dus niet hoe ik dat moet gebruiken. Ik benader de NAS gewoon via het webadres 192.168.2.100:8080.

@allen: dank voor jullie reacties. Zojuist heb ik de NAS opnieuw opgestart, vervolgens opnieuw opdracht gegeven voor uitbreiding van de RAID1 en zo'n 20 minuten later wat het gepiept ! Ik heb nu de volledige capaciteit.

[The Eagle]

Zou er voor de zekerheid even een data integrity check overheen gooien. Verwacht geen issues maar better safe then sorry.

En vwb de ondersteuning van grote schijven: dat de handleiding zegt dat het ondersteund wordt kan ook een nuance in zitten dat je daar software versie X voor moet hebben. Dus zou even dubbelchecken hoe dat zit.

16 TB is een hoop data om kwijt te raken

[peter-rm]

@Marcel-J de ts459 is een 4-bay nas. was het niet handiger geweest om een derde(en vierde) disk erbij te plaatsen en te migreren naar een raid-5 ? Met3x8T heb je dan 16T effectief, en met 4x8T kom je op 24T bruikbaar.

[Mijzelf]

Marcel-J schreef op zondag 24 september 2023 @ 10:16:
@Mijzelf: misschien kom ik een beetje dom over, maar ik weet eigenlijk nog steeds niet wat je bedoelt met ssh of telnet. Ik heb er op gegoogeld en zag vervolgens op de website van QNAP hoe ik dat aan of uit kan zetten. In mijn settings staat ssh aan en telnet uit. Maar ik weet dus niet hoe ik dat moet gebruiken. Ik benader de NAS gewoon via het webadres 192.168.2.100:8080.

Beetje mosterd na de maaltijd, maar als ssh aanstaat, dan kun je shell toegang krijgen door op de commandprompt (cmd) van je computer 'ssh 192.168.2.100' in te typen.

[The Eagle]

peter-rm schreef op zondag 24 september 2023 @ 10:54:
@Marcel-J de ts459 is een 4-bay nas. was het niet handiger geweest om een derde(en vierde) disk erbij te plaatsen en te migreren naar een raid-5 ? Met3x8T heb je dan 16T effectief, en met 4x8T kom je op 24T bruikbaar.

Das achteraf, en das mooi wonen
Bovendien vraag ik me sterk af wel voordeel je haalt van raid 5. Ja, stukje extra redundantie, maar raid is sowieso geen backup, dus die extra redundantie heb je als het goed is ook al van een offsite sync of backup.

En zo niet moet @Marcel-J daar maar eens over nadenken

[eltweako]

Ik denk dat een proces vastgelopen is, want 2 maanden is geen normale termijn meer.

Als het goed is kun je de Qnap gewoon rebooten via de interface, de raid expansion zou verder moeten gaan na de reboot.

Dat gezegd hebbende, altijd zorgen voor een back-up van de data.

[_JGC_]

The Eagle schreef op zondag 24 september 2023 @ 13:20:
[...]

Das achteraf, en das mooi wonen
Bovendien vraag ik me sterk af wel voordeel je haalt van raid 5. Ja, stukje extra redundantie, maar raid is sowieso geen backup, dus die extra redundantie heb je als het goed is ook al van een offsite sync of backup.

En zo niet moet @Marcel-J daar maar eens over nadenken

RAID5 geeft geen extra redundantie tov RAID1. Er mag nog steeds maar 1 disk uitvallen, en met 3 of 4 disks in het systeem is die kans groter dan met 2 disks.

RAID5 geeft wel veel lagere schrijfprestaties omdat bij elke write de hele stripe uitgelezen en herschreven moet worden.

[_Dune_]

_JGC_ schreef op zondag 24 september 2023 @ 13:30:
[...]

RAID5 geeft geen extra redundantie tov RAID1. Er mag nog steeds maar 1 disk uitvallen, en met 3 of 4 disks in het systeem is die kans groter dan met 2 disks.

RAID5 geeft wel veel lagere schrijfprestaties omdat bij elke write de hele stripe uitgelezen en herschreven moet worden.

Bij RAID levels moet je altijd goed kijken wat in jouw situatie het best past. Een voordeel bij RAID 5 zijn de read snelheden, zeker als je meerdere schijven gaat gebruiken, meer dan de minimale 3. De mindere schrijf prestaties kunnen ook verminderd worden met een goede controller en cache.

[Mijzelf]

_Dune_ schreef op zondag 24 september 2023 @ 13:40:
[...]


Een voordeel bij RAID 5 zijn de read snelheden

Ik denk niet dat je daar iets van kunt merken/meten bij een NAS met een gigabit aansluiting.

[White Feather]

peter-rm schreef op zondag 24 september 2023 @ 10:54:
@Marcel-J de ts459 is een 4-bay nas. was het niet handiger geweest om een derde(en vierde) disk erbij te plaatsen en te migreren naar een raid-5 ? Met3x8T heb je dan 16T effectief, en met 4x8T kom je op 24T bruikbaar.

Er zijn natuurlijk zat redenen om een Raid 1 aan te houden, lichter voor de cpu, minder schijven, dus minder stroom, warmte en geluid.

Bovendien zullen de 8 TB schijven er ook al enige tijd inzitten, dus vervangen kan een verstandige keuze zijn.

@Marcel-J Bij mijn Synology uit 2012 duurde het vergroten van mijn Raid 5 volume enkele minuten.

Mijn 462 deed er wel 60 uur over om van 2x16 TB in Raid - naar 3x16TB in Raid 5 te gaan, maar dat is data lezen en schrijven, het volume vergroten zou echt zo gebeurd moeten zijn.

Zou het een probleem kunnen zijn met de 16 TB limiet?

https://forum.qnap.com/vi...20is%20less%20than%2016TB.

Ik zou zeggen van niet, want 16 TB schijven levert een duidelijk kleiner volume op dan 16 TB.

Ik zou kijken of je kunt stoppen, de boel verifiëren op fouten en dan nogmaals proberen. Of dat kan en hoe precies zou ik niet weten, daarvoor zit ik nog niet lang genoeg op een Qnap.

[Ben(V)]

Raid 5 heeft als voordeel dat bij corrupt geraakte data die herstelt kan worden met behulp van de parity
Bij een Raid 1 kan alleen geconstateerd worden dat er iets corrupt is maar kan niet vastgesteld worden welke van de disken correct is en welke gecorrumpeerd, dus herstel is niet mogelijk.

En dat raid 5 trager zou zijn dan raid 1 is onzin.
Er moet weliswaar van meerdere disken gelezen worden maar dat gebeurd parallel en omdat van elke disk minder data gelezen wordt is het zelfs sneller dan een Raid 1.

[_JGC_]

@Ben(V) In de praktijk wordt bij RAID5 gewoon de parity herberekend en weggeschreven, data kan dan corrupt zijn. Wil je data integriteit, moet je naar RAID6 met dubbele parity of naar een filesystem dat gebouwd is op integriteit, zoals ZFS.

Wat performance betreft, QNAP is MDADM met daarbovenop EXT4. Heb even zitten zoeken naar benchmarks, de prestaties daarvan zijn heel afhankelijk van de workload. Benchmark gevonden bij Phoronix waar ze met 4 SSDs testen. RAID1 (en zelfs single disk) is daar sneller dan RAID5, alleen Postgres weet het voordeel van meer disks te benutten.

[Mijzelf]

@Ben(V) en @_JGC_ : Bij een RAID5 is het niet alleen in praktijk niet mogelijk om data te herstellen, maar ook in theorie niet. De paritiebit P = A XOR B XOR C ... . Je kunt waarnemen dat een bit corrupt is doordat de som niet klopt, maar niet welke bit (P, A. B, of C).
Overigens wordt bij normaal gebruik de parity alleen gezet bij het schrijven, maar niet gecontroleerd bij het lezen.

[Ben(V)]

@_JGC_ en @Mijzelf
Hoe komen jullie erbij dat een raid 5 geen herstel mogelijkheden heeft?

Een datablock die verdeelt is over de disken waarvan er een corrupt geraakt is kan met behulp van de parity gewoon de volledige data reconstrueren.
Als je data gewoon beschikbaar blijft als een hele disk uitvalt moge het toch duidelijk zijn dat je ook corrupte data kunt recoveren.

En omdat de parity niet bij lezen gecontroleerd wordt en er ook zoiets als bitrot kan optreden is het belangrijk om bij een raid 5 set (en hoger) regelmatig een scrubbing (=parity controle) uit te laten voeren

En met benchmarks kun je bijna alles aantonen als je maar de juiste benchmark gebruikt.
Er zijn te veel factoren die op dat nivo invloed hebben.

[_JGC_]

Ben(V) schreef op maandag 25 september 2023 @ 12:44:
@_JGC_ en @Mijzelf
Hoe komen jullie erbij dat een raid 5 geen herstel mogelijkheden heeft?

Een datablock die verdeelt is over de disken waarvan er een corrupt geraakt is kan met behulp van de parity gewoon de volledige data reconstrueren.
Als je data gewoon beschikbaar blijft als een hele disk uitvalt moge het toch duidelijk zijn dat je ook corrupte data kunt recoveren.

En omdat de parity niet bij lezen gecontroleerd wordt en er ook zoiets als bitrot kan optreden is het belangrijk om bij een raid 5 set (en hoger) regelmatig een scrubbing (=parity controle) uit te laten voeren

En met benchmarks kun je bijna alles aantonen als je maar de juiste benchmark gebruikt.
Er zijn te veel factoren die op dat nivo invloed hebben.

Lees hierboven. Je kunt detecteren dat er IETS fout is, maar je weet niet WAT er fout is. Dat is hetzelfde als bij een mirror waarbij 1 van beide disks een foute bit teruggeeft.

Als je een hele disk mist weet je welke rotte data je moet herstellen, dat weet je bij datacorruptie niet. Je claim dat RAID5 daarmee betrouwbaarder is dan RAID1 is onzin.

[Renault]

Aangezien TS het in zijn harddisk-overwegingen óók heeft over de verbruikte energie, lijkt mij het benutten van bay 3 en 4 geen goede optie.
En herstel van data bij datacorruptie is meestal wel mogelijk, maar daar zitten grote nadelen aan:
- een datacorruptie wordt pas gemeld bij de eerste benaderde sector die problemen geeft
- op dat moment worden hele disks gecontroleerd die meerdere corrupte sectoren kunnen aantonen, als die corupte sectoren daarvoor niet werden benaderd
- als een datacorruptie wordt geconstateerd, kán dat dus het begin zijn van een compleet recoverytraject, wat op zijn minst een periode van performanceproblemen/onbeschikbaarheid van de NAS betekent, en op zijn slechtst het afkeuren van beide disks, waarna je geen data meer hebt. Dat laatste toont het belang aan van een volledige en redelijk recente offline backup (wat TS in zijn openingspost ook zegt te hebben).
En je werkt nu met nieuwe disks in een oude NAS.

Nieuwe stelling:
- waarom niet de oude 4-bay NAS nu voorlopig verder laten draaien met de huidige disks
- sparen voor een nieuwe 2-bay NAS die 16 TB disks in de HCL heeft staan, en zodra je die NAS hebt aangeschaft, de huidige nieuwe harddisks daarin doen?
Voordeel van deze oplossing is dat je dan alles nieuw hebt en dat alles (na het doorlopen van het eerste deel van de betrouwbaarheids-badkuipvorminge curve) weer maximaal betrouwbaar is.
- de oude NAS kan je dan met de oude disk(s) er in periodiek aanzetten om de data daar naartoe te synchroniseren (als snelle vorm van offline backup).