Ik vertel hoe het zit en andere zijn het met mijn eens, niet goed genoeg.
Je vertelt niet hoe het zit, je vertelt 'je moet dit doen', dat is niet hetzelfde.
Ik vertel dat ik jaren ervaring heb, niet goed genoeg.
Dan kan je met jouw jaren ervaring misschien meer vertellen dan alleen zeggen dat je ervaring hebt. Het is een drogreden.
Ik vertel je dat alle leveranciers van serieuze storage systemen je zullen vertellen dat je op met soort disken geen raid 5 moet draaien en WAAROM ze dat zeggen, niet goed genoeg.
Het waarom lijkt anders nog steeds te ontbreken in deze discussie. Er zijn blijkbaar mooie cijfers ergens, maar waar zijn die? Ik heb ze nog niet gevonden (en ik interesseer me ook al wel wat langer in storage dan vandaag).
Ik google 5 seconde en vind een stuk wat hetzelfde aangeeft en dat zijn nog maar 8TB disken, de disken waar we het hier over hebben zijn 2x zo groot en zeer zeker niet 2x zo snel want ze draaien hetzelfde toerental, verschillen zijn dan over het algemeen vrij klein.
Ik weet niet wat jij wil zien want harde cijfers zijn afhankelijk van de load op het systeem, de omvang van de disken, de snelheid van de controllers en de prio die je aan de rebuild geeft (welke weer afhankelijk is van de load en maximaal toegestaande latencies en of je dit uberhaupt wel kan instellen).
In de praktijk vertaald dit zich echter naar rebuilds die dagen duren...zoals in dat stuk staat.
Met 8TB is "several" (ik lees dat als mogelijk maar 2-3) nog aan de lage kant maar en is je systeem redelijk rustig verder. Als je gek genoeg bent om echt forse load op dit soort disken te zetten en met hoge read latencies te leven kan je rebuild zomaar 2x zo lang zijn.
Jij lijkt in je calcuaties geen rekening te houden dat het systeem niet stil staat tijdens een rebuild of dat een rebuild met gigantische performance loopt. Beide zijn helaas niet waar, je schrijft maar naar 1 disk en het is een terugrekenactie vanuit parity.
Ik weet ondertussen niet of je mij loopt te trollen, indien dat zo is, gefeliciteerd want ik hapte flink of dat je serieus niet weet hoe dit werkt maar ik ga er nu echt mee stoppen.
Waar ik heen zou willen met discussies als deze is iets als 'Je moet <x> (wel/niet) doen, want er is <y> gebleken uit dataset <z>'. Het blijft nu hangen op 'Om <y> te voorkomen moet je <x> (wel/niet) doen', en dataset <z> is nergens te bekennen. Het wil niet zo op dit onderwerp, en dat reken ik jou uiteraard niet persoonlijk aan. Wel zou ik jou net zo goed kunnen vragen of je mij aan het trollen bent, want volgens mij ben ik vrij consistent om cijfers aan het vragen en komen er van jou consistent verhalen terug zonder.
Onder aan de steep is het niets meer en niets minder dan risk management. Hoe groot is de kans dat het misgaat, en waar stel je de grens. In het ideale geval begin je met het stellen van de grens, kijk je daarna naar de kansen van de verschillende oplossingen en wordt aan de hand daarvan de implementatie gekozen. En de beslissing wordt beter als er meer onderdelen daarvan kwantificeerbaar zijn, en het risico op dataverlies zou wel een mooi cijfer zijn om te hebben bij de keuze voor een opslagsysteem.
Mijn ideale situatie met een rebuild van minder dan een dag is overigens gewoon correct. Je schrijft naar 1 schijf op volle snelheid (in mijn voorbeeld), en bij een raid5-configuratie met n schijven lezen de overige schijven met 1/(n-1) deel van die snelheid om dat aan te leveren (want die zijn striped). Rekenen aan parity is dusdanig eenvoudig dat het geen betekenis heeft, in raid5 is dat een xor van de data van de n schijven en dat kan zelfs een matige CPU sneller dan dat je nodig hebt.
Dan blijft nog de load over. Mijn inschatting is dat als iemand al overweegt om deze schijven in raid5 te gebruiken, dat performance niet de bepalende factor is maar de capaciteit. Daarmee zou de vertraging mee moeten vallen, maar blijft er uiteraard nog steeds een risicofactor over.