VNX: Vad är skillnaden mellan tjocka LUN och tunna LUN?

Tjock LUN :

När ett tjockt LUN skapas reserveras hela det utrymme som ska användas för LUN. Om det inte finns tillräckligt med utrymme i poolen kommer Tjockt LUN inte att skapas. En första allokering på 3 GiB innehåller metadata och användardata, och när användarna sparar ytterligare data i LUN allokeras 1 GiB-segment efter behov. Dessa segment innehåller 1 GiB sammanhängande logiska blockadresser (LBA), så när ett segment skrivs för första gången allokeras det till det tjocka LUN. Eftersom spårningen sker med en kornighet på 1 GiB är mängden metadata relativt låg och de sökningar som krävs för att hitta platsen för segmentet i poolen är snabba. Eftersom sökningar krävs kommer åtkomst till tjocka LUN-enheter att vara långsammare än åtkomst till traditionella LUN.

Tunn LUN :

Tunna LUN allokerar också 1 GiB-sektorer när utrymme behövs, men kornigheten i dessa sektorer är på blocknivå på 8 KiB. Alla 1 GiB-sektorer allokeras till endast 1 tunn LUN, men de 8 KiB-blocken kommer inte nödvändigtvis från sammanhängande LBA:er. Överprenumeration tillåts, så den totala storleken på Tunna LUN i en pool kan överskrida storleken på det tillgängliga fysiska datautrymmet. Övervakning krävs för att säkerställa att förhållanden utanför rymden inte uppstår. Tunna LUN är märkbart mer omkostnader än tjocka LUN och traditionella LUN, vilket leder till att prestandan försämras avsevärt.

Hur beräknar man metadata för pool-LUN?

Metadata associeras med användningen av både tjocka och tunna LUN. Metadata används för att hitta data på de privata LUN som används i poolstrukturen (långsamma prestanda på grund av de sökningar som krävs för att hitta platsen för segmentet i poolen). Mängden metadata beror på LUN-enhetens typ och storlek.

För tjocka LUN-metadata (GB) = 0,001* kapacitet (GB) + 3 GB
För tunna LUN-metadata (GB) = 0,02* kapacitet (GB) + 3 GB

Sammanfattningsvis bör du tänka på följande:

Användning av tunna LUN stöds inte i vissa miljöer, till exempel i VNX-fillagringsgrupper.
Tunna LUN bör aldrig användas där hög prestanda är ett viktigt mål (se artikel 335002 ).
Poolutrymme bör övervakas noggrant (tunna LUN tillåter överprenumeration på poolen medan tjocka LUN inte gör det). Systemet utfärdar en varning när förbrukningen av en pool når en gräns som användaren kan välja.  Som standard är den här gränsen 70 %, vilket ger användaren tid att vidta de korrigerande åtgärder som krävs (se artikel 78223 ).

Tunna LUN bör placeras i blockmiljöer där utrymmesbesparing och lagringseffektivitet väger tyngre än prestanda som huvudmål. Områden där lagringsutrymme traditionellt är överallokerat, och där funktionen för tilldelning av tunna LUN-enheter på begäran skulle vara en fördel, inkluderar användarnas hemkataloger och delat datautrymme.

Om FAST VP är ett krav, och pool-LUN föreslås av den anledningen, är det viktigt att komma ihåg att tjocka LUN ger bättre prestanda än tunna LUN.
Tänk på att tunna LUN inte rekommenderas i vissa miljöer. Bland dessa finns Exchange 2010 och filsystem på VNX.

Utrymme tilldelas till tunna LUN med en kornighet på 8 KiB (inuti en 1 GiB-sektor). Innebörden här är att spårning krävs för varje 8 KiB data som sparas på en tunn LUN, och att spårning innebär kapacitetskostnader i form av metadata. Dessutom, eftersom platsen för 8 KiB-data inte kan förutsägas, kräver varje dataåtkomst till ett tunnt LUN en sökning för att fastställa dataplatsen. Om metadata för närvarande inte är minnesresidenta krävs en diskåtkomst och en förlängd svarstid blir resultatet. Detta gör tunna LUN märkbart långsammare än traditionella LUN och långsammare än tjocka LUN. Eftersom tunna LUN använder dessa ytterligare metadata tar återställning av tunna LUN efter vissa typer av fel (t.ex. fel i cacheminnet) betydligt längre tid än återställning för tjocka LUN eller traditionella LUN. En stark rekommendation är därför att placera verksamhetskritiska program på tjocka LUN eller traditionella LUN.

I vissa miljöer kan de med hög ort för datareferens FAST Cache bidra till att minska prestandapåverkan för metadatasökningen. 

Enheter

* Decimal - alla är potenser av 10

** KB,MB,GB,TB - 10^3 ,10^6,10^9,10^12
** 1,000 , 1,000,000 ,1,000,000,000 ,1,000,000,000

* Binärt -alla är potenser av 2

** KiB,MiB,GiB,TiB - 2^10,2^10,2^20,2^30,2^40
** 1 024 - 1 048 576 - 1 073 741 824 - 1 099 511 627 776

* Disktillverkare använder decimalenheter för att lista kapacitet
* Länkhastigheter mäts i decimalenheter
* I/O-storlekar, cachesidstorlekar, LUN-storlekar är binära enheter

Enheter som används vid design av lagringsmiljöer kan vara förvirrande. I SI-mätsystemet är multiplikatorer decimaler, och mega betyder till exempel 10^6 eller 1 000 000.
Vissa mått som används inom IT baseras dock på de binära ekvivalenterna, som är något större än decimalenheterna. Observera till exempel att på TB/TiB-nivå är den binära enheten nästan 10 % större än decimalenheten.
Disktillverkare anger diskstorlekar i decimalenheter och använder en sektorstorlek på 512 byte när de diskuterar formaterade storlekar. VNX Block-systemen, och deras CLARiiON-föregångare, använder 520 byte-sektorer, och detta måste också tas med i beräkningen. Observera att cachestorlekar, LUN-storlekar och filsystemstorlekar anges i binära enheter.
De binära enheterna är en relativt ny standard som fastställdes av IEC år 2000. Standarden har accepterats av alla större standardiseringsorganisationer, inklusive IEEE.

När du skapar en ny Tjock LUN i överstrålning 32 tilldelas alla segment i förväg. Detta är för att behålla alla segment på samma SP när LUN skapas. "Disksystemets LBA:er tilldelas sekventiellt" för att förhindra att vissa sektorer tilldelas peer-SP (detta kan inträffa under vissa omständigheter).
 

Tjockt LUN i version för 32:

I och med introduktionen av nya EMC VNX Operating Environment (OE) för blockversion 5.32, filversion 7.1 förändras inte beteendet för tunna LUN. men tjocka LUN kommer att allokeras fullt ut när de skapas. Det innebär att alla segment på 1 GB allokeras när LUN först skapas. Skrivningarna kommer fortfarande att organiseras enligt det logiska blockadressintervallet, vilket ursprungligen var fallet. Tjocka LUN och tunna LUN kan dela samma pool. När ett tjockt LUN skapas reserveras all dess kapacitet och allokeras i poolen för användning av det LUN.  Därför kommer en tjock LUN aldrig att få slut på kapacitet. Alla nya skrivningar finns och distribueras i hela det förallokerade området, så den värdrapporterade kapaciteten är ungefär lika med den förbrukade kapaciteten. Tjocka LUN har högre prestanda än tunna LUN på grund av den direkta adresseringen och bör användas för program där prestanda är viktigare än utrymmesbesparingar. Den här förbättringen har positiva konsekvenser för FAST VP, eftersom användarna bättre kan styra vilken nivå sektorerna skrivs till genom att allokera LUN för tjocka pooler fullt ut när de skapas. Eftersom pooler initialt skapas, och det fortfarande finns tillräckligt med utrymme på den högsta nivån, kan användare vara säkra på att när de skapar ett LUN med antingen Högsta tillgängliga nivå eller Starta hög och sedan Automatisk nivå, kommer data att skrivas till den högsta nivån eftersom LUN allokeras omedelbart.

Tjock LUN-förbrukning per nivå för version 31:

När du skapar ett tjockt LUN allokeras inte det poollagringsutrymme som krävs för det tjocka LUN, utan det reserveras. Eftersom dessa reservationer baseras på poolen i stället för nivån återspeglas inte det reserverade lagringsutrymmet i nivåuppdelningen på Tjockt LUN-nivå förrän det tjocka LUN skrivs till och lagringen faktiskt allokeras.
När du anger en nivåindelningsinställning för ett tjockt LUN reserveras lagringen dessutom endast för LUN även om det tjocka LUN verkar vara helt etablerat. Eftersom dessa reservationer inte görs på nivånivå kan det hända att den ursprungligen begärda lagringsnivån inte längre är tillgänglig när data faktiskt allokeras till Tjockt LUN som ett resultat av en skrivning. Om du aktiverar FAST kommer det här problemet att lösas under efterföljande omlokaliseringar.