Hot Spindlar
Ursäkta frånvaron i både närvaro och inlägg. Det har varit en berg-och dalbana senaste året med personskada och platta ut arbetsscheman, så jag har haft lite tid eller motivation att blogg eller visa mitt ansikte hela samhällen. Jag ber om ursäkt, och jag är fast besluten att bryta den vanan och komma tillbaka in i saker igen! Men nog om prat, gå vidare med skrifter ...
Detta är inte något jag ser väldigt ofta, men när jag gör så är det intressant att se statistik talar för sig själva. Jag är med en kund som hade ett manus utplaceringen av sina NetApp gården för några år sedan, och det var inte utformad eller levereras med för mycket och behandling (något jag vill diskutera en annan dag). De har en VMware egendom med SQL, Exchange och andra saker. Det löper över hela totalt över 100 15k FC spindlar. Det är inte en stor egendom i jämförelse med andra sajter, så jag är nyfiken på varför de har sådana prestandaproblem.
Nu när du kör igenom "sysstat-u" kan du se att Uppgiftslämnaren i sig gör mycket lite, glatt gå vidare med vad den borde göra. Men skivan är att slå 100% ganska ofta. Omedelbart detta visar en disk problem. De behöver fler spindlar, självklart?
För det första finns en obalans i spindlar. De har ett andra aggregat på den partner styrenhet som bara har testa volymer. Jag får tillåtelse att ta bort denna och varmt, jag omfördela dessa till andra controller och expandera befintliga aggregat. Detta fördubblar spindeln räkna, men jag vet att det inte kommer att göra något för befintliga prestanda (i att uppgifterna inte automatiskt kommer att omfördela sig själv!).
Om jag går igenom "statistik visar disk: *: disk_busy" Jag kan se något ganska uppenbart. Det finns en enda skiva i hela systemet som drabbar 100%, resten är det inte. Det finns en massa andra diskar (ca 10), som körs 50-60%, och sedan de återstående diskarna tickar på omkring 20-30%. Så vad har hänt här? NetApp teknik ska förhindra alla former av hot spindel i systemet.
Min teori är denna. Uppgiftslämnaren plågades och staplade ur lådan, men den sammanlagda var inte vuxit (3 disk sammanlagt 1 data, 2 paritet). Vissa lagring var reserveringar och data migreras. De sprang ut ur rummet, så blev den sammanlagda (lite) och sedan kopierade en massa mer data på diskar. Efter allt detta, tillade de sedan resten av diskarna. Nu, eftersom data inte automatiskt omfördela i farten, alla data som förblir oförändrat (som kommer att hända med VM-systemet diskar, gammal e-post Exchange och gamla data Data Warehousing), då de fortfarande satt på den ursprungliga spindlar eller ens spindel som när de först installerades.
Så jag nu ser fram emot helgen. Vi kommer att uppgradera dem till Data ONTAP 7.3.2 och jag kan sedan köra några omfördelning skannar hela systemet utan att påverka användningen ögonblicksbild utrymme (enorm bonus, tack NetApp!). Jag hoppas att detta kommer att ta bort den varma spindeln frågan. Jag har en del tidigare statistik, och jag ska dra ut en del efter att statistik nästa vecka. Jag kommer uppdatera detta inlägg om detta.
Lärdom från historien? Konfigurera ditt lagringssystem helt och ordentligt innan du börjar kasta uppgifter på det. Bli inte upphetsad om hur du använder din nya lagring leksak och kasta data på den omedelbart. Jag har sett ovanstående scenario vid flera tillfällen nu, och innan ONTAP 7,3, var det en smärta att fixa.
Snabb ögonblicksbild av statistik utgång. Tänk på att inom ett kluster här kommer att visa alla diskar, så alla disk statistik är helt relevanta. Den livliga diskar här bara lägger inte upp till det faktiska antalet diskar i systemet, och man kan tydligt se en upptagen disken.
based on 1 rating> Sysstat-U 1
CPU totala kB / s Disk kB / s Tape kB / s Cache Cache CP CP Disk
ops / si läste skriva läsa skriva ålder drabbades tid Ty util
11% 3220 6942 3270 4232 0 0 0 12 95% 0% - 60%
11% 2898 7385 4030 4892 0 0 0 11 94% 0% - 69%
9% 3547 1820 3496 3920 24 0 0 11 93% 0% - 89%
7% 2329 1160 3048 3892 0 0 0 11 93% 0% - 81%
10% 3173 2055 4851 4644 8 0 0 11 93% 0% - 67%
9% 2491 1860 4547 4568 24 0 0 11 91% 0% - 98%
9% 2523 2960 4404 5372 0 0 0 11 90% 0% - 89%
14% 5136 8173 4465 3352 0 0 0 11 95% 0% - 81%> Statistik visar disk: *: disk_busy
... Snip ...
... Snip ...
En annan viktig punkt är att du inte bör lägga en enda skiva när du ändrar storlek på aggregat om det är nästan full, de flesta av de nya data skrivs till den extra hårddisken. Således är resultatet riktigt illa!
Min rekommendation: skapa några stora aggregat istället för många små. Lägg hårddiskar för att den sammanlagda när användningen är över 80%. Och ja, användning Performance Advisor och trösklar för att övervaka din prestation!
Tack Chris - några riktigt bra tips där! Kul att du skriver igen
Skål för feedbacken, känns bra att faktiskt få chansen att skriva något ner igen!
Och ja, lägga till enstaka diskar är en fruktansvärd sak att göra. Jag vet någon som köper en skiva en månad eftersom det är hur deras budget fungerar. Jag hatar detta och försöka få dem att förvara dem och lägga dem i bulk åtminstone. Hjälper inte med deras account manager uppmuntra dem att göra detta kan kalla det för lagring på efterfrågan!
Chockerande!
Du nämner att "köra några omfördelning skannar hela systemet utan att påverka ögonblicksbild utrymme" som en ny funktion med 7.3.2. Kanske en idé för en annan bloggpost är att förklara detta lite mer, och varför det är viktigt. Jag förstår (tidigare) som omfördelning skulle dumpa allt arbete i ögonblicksbilder, men jag är inte medveten om förändringen i 7.3.2 du nämner som fixar / förändringar här.
Förhoppningsvis kommer jag att köra igenom detta i helgen, så jag kommer att kunna ge några verkliga exempel på hur detta fungerar.
Naturligtvis kan du alltid plats för nya singleton kör in en hylla varje månad, men lämna dem tomgång som reservdelar tills du får en hel ny RAID-koncernens värt ... bara inte berätta för dem att
@ Rick rhodes
Den nya omfördelning i 7.3.x är fysisk omfördelning (omfördela-P, se man-sidan). Och även om du expanderar ett aggregat med en hel hylla eller mer, kanske du ändå vill göra en fysisk omfördela av alla volymer i den sammanlagda, även om du inte har varma diskar. På så sätt kan du rand data över ännu fler spindlar, så det kommer att ge högre (läs) prestanda för befintliga data också.
Egentligen manualen säger att "omfördela-p" inte bör användas för att sprida data över diskarna. Den rekommenderar att göra omfördela mot varje volym inom det utvidgade aggregat.
Inte säker på vad den faktiska effekten av detta är, har jag inte haft ett system för att prova det här som skulle se stora förbättringar.
Hej,
Detta är ett underbart inlägg
Bara en liten fråga
disk: 88922F61: C2026AF9: E5D68A17: B49415B1: 00000000:00000000:00000000:00000000
Hur kan jag ta reda på vilka aggregerade denna disk tillhör?
Jag försökte med disk show och lagring visa disken, aggr status-r
Men hittade ingen
Hälsningar,
Tyvärr är jag inte 100% säker. Det är på min "att-göra-lista" och jag har ännu inte lista ut hur man översätter den långa adressen utrymme "stats"-kommandot ger dig in i något som kan användas i termer av faktiska diskutrymmet adress eller plats. Tyvärr detta inte hjälpa dig mycket
KB ID: 1010747
https://kb.netapp.com/support/index?page=content&id=1010747
Det är utmärkt! Tack!
Jag är nyfiken på vad är tecken på nödvändighet för att köra "omfördela", förutom att ha en skiva med hektisk 99%?
Tack
Vad exakt letar efter i Perf.monitor? Latens, ops / sek?
Hej Vladimir,
Running "omfördela" anses nu vara ganska god praxis på olika LUN. Allt som kommer att få en förmån från stora sekventiell läsning är en bra kandidat för ett reguljära omfördela, men också många olika vanliga typer av LUN kommer att dra nytta ändå.
Även om NetApp disksystem gör ett mycket bra jobb för att placera data i stora bitar och ränder över diskarna, det kan bara göra så mycket heller, eftersom ett system är mycket upptagen eller för att diskarna är väldigt full. Köra en omfördela efteråt är post-processen så att det kan ta är det dags att se till att uppgifterna läggs ut helt jämnt.
Jag får vara försiktig med att köra omfördela om diskarna har redan 99% upptagen, kommer att omfördela lägga större belastning på dem för en tid när data omfördelas. Jag skulle rekommendera att göra detta under en underhåll fönster, eller out-of-timmar.