RAID Atomicity
Som du gør, jeg læste op på RAID-niveauer, mens i badet. Emnet for atomicity kom op, og det er noget jeg gerne ville dele.
Ikke normalt den mest pålidelige kilde til tekniske data, men jeg vil citere Wikipedia til at hjælpe med at forklare atomicity at sætte scenen. Taget fra http://en.wikipedia.org/wiki/RAID under afsnittet "Problemer med RAID" ...
Dette er en lille forstået og sjældent nævnes svigt for redundante storage-systemer, der ikke udnytter transaktionelle funktioner. Database forsker Jim Gray skrev "Update in Place er en Poison Apple" [28] i de tidlige dage af relationel database kommercialisering. Men denne advarsel stort set gik upåagtet hen og faldt af i svinget på fremkomsten af RAID, som mange softwareingeniører forvekslede som løse alle datalagring integritet og pålidelighed problemer. Mange programmer opdatere et lager objekt "in-place", det er, de skriver en ny version af objektet på den samme disk-adresser som den gamle version af objektet. Mens softwaren kan også logge nogle delta informationer andetsteds, forventer opbevaring at præsentere "Atomic skrive semantik", hvilket betyder, at skrivning af data indtraf enten i sin helhed eller slet ikke forekomme overhovedet.
Dette er kommet tilbage til lys for nylig, men under en anden forklædning med SSD skrive svigt problemer. Mange SSD producenter og enterprise storage leverandører tager fat på dette med nye firmware, der skriver alle data sekventielt, aldrig over-skrive en datablok, indtil hele disken er skrevet derefter starte forfra-skrive blokke fra starten (der er naturligvis blevet frigjort først).
Men dette er et overset problem med de traditionelle roterende medier og bliver ofte overset, og afskediget uden en klar forklaring eller forståelse. Ideen er, at mange systemer vil over-skrive data på plads, er det skrive bekræftet, at det med succes blev skrevet, men ikke nødvendigvis, at de data, der matchede, hvad værten sendt. Overhead af denne kontrol ville sætte en betydelig ekstra belastning, som hver nedskrivning ville forudsætte en yderligere læsning og checksum før skriver er bekræftet, og write cache kan skylles.
Dette kan blive forværret af den såkaldte "Kopier Skriv" snapshot-teknologier. Snarere end at bevare de data, der allerede er skrevet til en bestemt sektor på disken, bliver de oprindelige data kopieres til en snapshot område i en anden del af lageret, inden de oprindelige data sektoren overskrives. Så en stor transaktion program, der overskriver sine data regelmæssigt (siger en temp DB eller replay logs der bliver skyllet jævnligt, ligesom Oracle logs før arkivering) kan være ganske modtagelige for denne form for fejl. Det største problem her er, at når data skrives og bekræftet, er der ingen mulighed for at korrigere det som lagersystem vil bekræfte det som intakt. Dette kan have en massiv afsmittende virkning til data de-duplikering. Hvis den første blok er skrevet til en korrupt sektor, uden at blive identificeret, kan dette derefter kan knyttes til hundrede af andre datablokke som en del af de-duplikering proces, massive data korruption.
Dette kan ikke altid fastsættes ved RAID paritet som RAID beregnes efter en stribe er skrevet. Det kan ikke altid opgøres i hukommelsen enten som en hel stribe ikke altid skrevet, kunne det være en delvis stribe i hvilket tilfælde paritet skal beregnes ud fra eksisterende data på disken, samt data endnu ikke er skrevet til disk. Hvis data skrives til disk og derefter læse for at beregne paritet, er det ikke nødvendigvis er bekræftet mod kilden. Der er flere måder at løse dette, og for det meste det skal ske i hukommelsen, er generelt en checksum betragtes som acceptabel fremgangsmåde. Læsning af data senere efter en bekræftet skrive ikke kan garanteres, da du ikke har noget at sammenligne det mod, integritet skal kontrolleres, mens data er stadig aktiv i hukommelsen for at sammenligne med.
Der er flere måder at storage leverandører tackle dette, og som du ville forvente, jeg vil dække, hvad NetApp gør. Det WAFL filsystemet skriver til alle gratis datablok og aldrig aktivt over-skriver en datablok. At skabe en fri datablokke der er en scrub proces, der kører i baggrunden, løber det hele lagersystemet blok efter blok, og forhører om et øjebliksbillede eller aktivt filsystem peger på netop dette datablok. Hvis det ikke er, så rydder data i blokken og markerer det som gratis (eller unmarks det som i brug ville sandsynligvis være mere korrekt). Dette tillader filsystemet for at bekræfte, at ikke blot er datablokkommando ikke er i brug, men faktisk som en bivirkning spreder dataene skriver over hele overfladearealet af en skive og negerer eller minimerer virkningerne af atomicity. Derudover WAFL krat processen tester datablokke for at kontrollere, om disken integritet, det er sådan diske kan på forhånd ikke på grundlag af disken overflade integritet snarere end fysisk fiasko, efter at en tærskelværdi defineret mislykkede disk sektorer disken er mislykkedes, og en opsving er forsøgt, og en hot spare aktiveret. Så i en NetApp system er de samme datablokke sjældent skrevet til gentagne gange, selv (eller især) i et højt gentagelse transaktionssystem.
Tag alt det ovenstående, og du også begynde at indse, at en fuld filsystem er dårligt for dit lager på forskellige måder. Hvis du har et komplet lagersystem, så er der færre frie blokke til at skrive til, og så en mindre del af datablokke skrives til løbende. Dette forbindelser chancerne for atomicity og i almindelighed vil forøge disken slid. Så en god grund til at kigge på data arkivering, de-duplikering og generelt holde dine filsystemer rene og ikke misbruger de storage-systemer!
Så spørg din storageproducenten hvordan de beskytter dine data mod disse spørgsmål.
Meget cool.