En NetApp Tekniske Diary

Jeg kan ikke sige, at jeg nogensinde har prøvet at sætte root-kodeordet som tomme, og kan ikke sige, at jeg vil anbefale det heller. Hvis du bruger "ndmpcopy" kan du definere kilde og destination legitimationsoplysninger med "-sa brugernavn: password" og "-da brugernavn: password".

Bedste chance er at starte ud i branchen. De fleste af mine evner kommer fra at være selvlært og arbejder på B2net. Måske finde et lager sælger eller forhandler i dit område og se om at få noget erhvervserfaring.

Jeg har altid finde studere svært, hvis jeg ikke har fået et projekt at arbejde hen imod, så at læse bøger og studere manualer måske ikke den bedste måde at lære ordentligt. Desuden er det usædvanligt kedeligt at gøre det!

Hej Scott, B2net kan helt sikkert yde denne service for dig, at vi ikke kun har en 24/7 support desk, der er veluddannede i alle NetApp produkter, men også et team af meget dygtige og talentfulde ingeniører. Hvis du spørger om uafhængige konsulenter, er jeg bange for jeg ikke får nogen eksponering for dem, som vi har nogle branchens førende kompetencer internt og sjældent har brug for at engagere sig i 3. parter. Jeg vil være glad for at sørge for nogen til at kontakte dig for at drøfte muligheden af ​​ad-hoc-støtte yderligere, da det er helt sikkert noget, vi kan tilbyde.

Du mener AutoSupport? Ja, kan du gøre dette enten fra FilerView eller fra CLI. Fra CLI bare gøre ...

muligheder autosupport.doit "tekststreng her"

... Og erstatte "tekststrengen her" med hvad besked, du ønsker NetApp til at reagere på, som regel et sagsnummer.

Hej Ron,

Har du (eller har du har) alle LUN kloner i fortiden? Måske disse er blevet låst inde i et øjebliksbillede, og du har siden slettet LUN klon, men den klon, der stadig har LUN låst. Kontroller snapshots af volumen og se, om nogen er låst. Hvis du sletter LUN, er der noget andet i mængden? Hvis du offline lydstyrken, vil du helt sikkert fjerne alle links til LUN. Så kan du bare slette diskenheden og genskabe det.

For at slukke disken automatisk tildeler, skal du gøre følgende ...

optioner disk.auto_assign off

og derefter un-egne disse diske igen. Du skal være god til at gå da!

Hej Kurt,

Problemet, når man har en fuld aggregat er, at dette påvirker skriver som det første spørgsmål. Normalt WAFL køer op skriver til stribe på tværs af alle de diske, og den forsøger at gøre dette med så stor en stribe som muligt, da det er den optimale måde at både skrive og at læse senere. Med en samlet ved 100%, er der ikke meget plads til at skrive store striber, så det er nødt til at bryde disse skriver i mindre bidder og skrive ind i de små mængder fri plads der er tilgængelig. Dette tager skriver længere tid, men endnu vigtigere det har en enorm indflydelse på hits. Læser nu nødt til at gøre mere fysisk spindel bevægelse til at udføre læse-aheads eller bare en simpel sekventiel læsning, som nu er lagt over spindlen i stedet for i en dejlig stram sekvens.

Kører din samlede til 100% ikke kun påvirker umiddelbart skrive præstation, men det vil løbende påvirke læse ydeevne for alle data, der blev skrevet inden for den tidsramme, at den samlede var næsten fuld, eller fuld. Du er nødt til at reducere dine samlede forbrug (ned til mindre end 80% anbefales) og derefter omfordele de mængder, til at distribuere data på tværs af spindler i en mere velordnet måde igen. Dette vil enormt forbedre læse ydeevne går fremad, og den ledige plads vil tillade ydelsen ved skrivning til en igen optræde på optimale hastigheder.

Med en 100% komplet aggregat, man ofte ikke kan se en disk udnyttelse præstation problem, men du kan se høj CPU og du kan se "CP Ty" (Sammenhæng punkt Type) tager lang tid at skylle til disk. Du kan se dette fra "sysstat-u 1". Det er meget afhængig af systemet model og type data, du skriver, men en meget grov tommelfingerregel er, at hvis en CP tager mere end at sige 3-4 sekunder, er det arbejder hårdere end det burde gøre. Men som jeg siger, hvis du har en 100% komplet aggregat, der er lidt kort sigt software arbejde, du kan gøre for at afhjælpe problemet, rettelsen er enkel, mere disk eller færre data. Så købe nogle flere spindler og tilføje dem til den samlede, og derefter omfordele. Eller slette nogle data / snapshots og frigøre noget plads på disken og derefter omfordele.

Det ser ud til du har et stort antal af diske manglende eller ikke fra miljøet. Disse skal rettes, før du kan bringe den samlede online igen igen. Du skal kontrollere, at diskene er tilsluttet korrekt. Den bedste måde at opnå dette er nok til at slukke for systemet og sikre, at alle kabler er fuldt tilsluttet og sikker, og at alle diske korrekt placeret. Forhåbentlig noget i retning af et løst kabel, har forårsaget filer til at mislykkes disse diske i stedet for en egentlig data eller mekaniske fejl af alle disse diske. Se alle de tilslutningsmuligheder, først, så er du måske være i stand til unfail disse diske hvis intet er rent faktisk galt med dem.

Men hvis diskene er fuldstændigt mislykkedes, så er jeg bange for, du kunne være i en ganske situation.

Jeg vil kraftigt anbefale du kontakter NetApp Global Support, som de vil være i stand til at gå dig gennem processen med at tjekke disse diske, og hvis det er muligt at reparere den samlede. Det kan være en kendt fejl, og en let løsning, men de er i den bedste position til at diagnosticere dette.

Hej Kurt,

Jeg vil give dig en hurtig reaktion, men lyder som om du har tingene sorteres nu.

Hvis du ønsker at bruge SnapManager til Exchange, så du virkelig har 2 forskellige måder at præsentere opbevaring til Exchange VM.

1) Tilslut til dem ved hjælp af iSCSI software igangsætter inden VM
2) Tilslut til dem ved hjælp RDMs på ESX niveau og præsentere en rå LUN til VM. Dette kan gøres enten ved hjælp af FCP eller iSCSI.

Den største fordel ved alternativ 1 er granularitet af kontrol. Exchange admin ikke også behøver at være en VMware admin for at styre og kontrollere sin opbevaring. Formentlig alle bør have en vis VMware viden selv. Ulempen til løsning 1 er, at hvis du har en masse af VM'er, der kræver opbevaring på denne måde, vil det være en uafhængig software igangsætter installeret for alle, og det har både ledelse og CPU overhead.

Fordelen ved løsning 2 er, at du centralisere lagring tilslutningsmuligheder. Uanset brug det sker altid på VMware-niveau, kan dette give dig en bedre sikkerhed og synlighed af hvem der bruger hvad opbevaring. Fordelen ved at anvende iSCSI på værten plan er, at det kun er en instans af softwaren initiator. Med FCP denne forsvinder helt. Den største ulempe ved option 2 er bagsiden af ​​valgmulighed 1, betyder Exchange admin ikke få direkte kontrol over sin opbevaring, dog med SnapDrive du stadig få ganske god kontrol, kan du stadig klone, vokser, snapshot og så videre indefra SnapDrive.

Præsentation af lagring til et datalager og derefter skære en VMDK er formentlig værste fald, som du ikke får nogen SnapDrive eller SnapManager integration fra Exchange, men du stadig har den overhead af tilslutning fra VMware. Jeg tror, ​​det kan bare være en slåfejl i dit spørgsmål, da det ser ud som om du var beslutter mellem RDM fra ESX og iSCSI-initiatoren i VM. Min personlige favorit bruger RDMs selv om der kan være yderligere forbehold eller ændringer, hvis du også laver DR. VMware SRM beskæftiger godt med RDMs dog, men virker ikke på alle med iSCSI initiativtagere inden VM.

Håber du har alle ting sorteres allerede dog!

Hej Kurt,

Hvis du har en klynge, ville jeg se at sætte SQL DB på en node, og Mail DB er på den anden node. Logfilerne derefter sidder på den modsatte systemet igen. Dette hjælper os virkelig til afbalancering af lasten på tværs af en klynge, giver dig mere spindler at bruge og giver dig et niveau af fysisk adskillelse. Det hjælper dig også gøre nogle omfanget af den skade kontrol med systemet skilles ud som denne. Men jeg ville ikke have et system dedikeret til SQL, og den anden til Exchange, du ønsker at balancere ting som træstammer ud. Det vil give dig mere patroner til en enkelt ansøgning, og du kan stadig anvende en grad af kontrol.

Også se på opbevaring IO Control fra VMware side af tingene (rigtig god måde at kontrollere IO, hvis du har vild maskiner), og også se på at sætte forskellige prioriteter på NetApp mængder. Du kan indstille disse fra meget lav, lav, middel, høj og meget høj. Det fungerer på samme måde til VMware aktier, men du lægger dem på lydstyrke og har en vis grad af kontrol over IO og ydeevne, som hver volumen bliver leveret. For eksempel vil du måske ønsker at begrænse CIFS brugere til fordel for en SQL-database. Det kan være, at alt forbliver på medium (standard), men du lægger Mail DB på meget højt for at give det en bedre andel af ressourcerne.

Tak for feedback, det er bare en skam, at jeg ikke får mere tid til at begå flere emner!

Når du aktiverer prioritet, det sætter en standard (medium) politik på tværs af alle mængder, så du behøver ikke at gøre det individuelt. Du skal indstilles individuelt forskelle i forhold til det som kræves dog.

Prioritet kan hjælpe med et system, der kæmper for at konkurrere med ting som SnapMirror, da det giver højere prioritet end systemets opgaver. Som med enhver form for ressourcedeling værktøj (samme som jeg fortæller mine VMware kunder) at begrænse ressourcer på en travl system vil naturligvis påvirke tingene. Det vil gøre en dårlig situation bedre for de mængder, du prioriterer, men det vil gøre det meget værre at alle de andre mængder. Et system under kraftig belastning i forvejen, der har problemer med ydeevnen er ikke den bedste kandidat til ressource aktier eller prioriterede begrænsninger. Jeg vil anbefale dig tage fat på de problemer med ydeevnen første eller begynde at kigge til at begrænse belastningen af ​​anvendelsen siden før placere prioritere på tværs af alle mængder.

Husk også, at prioritet kun kommer i spil, når der er ressource bedt om. Så hvis du for eksempel ønsker at give flere ressourcer til SQL og Exchange, og de eneste andre ressourcer på, at systemet er let brugt CIFS aktier, vil du sandsynligvis få lidt gavn så lidt IO bliver genereret fra Instituttets aktier. At give alle prioritet til SQL og Exchange vil stadig resultere i deres begrænsning med hinanden.

Hej Michael, undskyld for forsinkelsen med at få tilbage til dig. Du kan prøve at udføre en SnapMirror resync, men chancerne er store, at dette nu kan kræve en ny baseline. Derudover hvis VSM kan ikke slette destinationen snap, så chancerne er, at flex klon stadig har denne låst eller anden måde. Opdelingen proces kan tage noget tid at gennemføre, så du kan har forsøgt at gøre det for hurtigt efter start opdelingen.

Desværre når SnapMirror sidder fast eller forvirret, den eneste reelle mulighed er en baseline, medmindre nogle lignende snapshots stadig eksisterer. Jeg har været i mange vanskelige situationer, hvor jeg har haft til at re-baseline en destination på grund af snapshots blive slettet af en eller anden grund.

Undskyldninger for manglende din kommentar!

Kan du give mig et bredere billede af volumen / LUN-konfiguration. Er volumen i spørgsmål en FlexClone, eller bliver det FlexCloned? Hvis ikke, har nogen LUN klon operationer blevet gjort på det, enten manuelt eller fra en SnapManager job? Når du viser snapshots for lydstyrken, hvad det viser? En bestemt snapshot viser som låst eller optaget? er LUN kortlagt i øjeblikket?

LUN klon gør en klon af LUN inden for samme volumen som det oprindelige. Det betyder, at hvis de efterfølgende snapshot operationer ske efter klon er skabt, dette faktisk låser LUN klon, som derefter refereres til i et øjebliksbillede, så kan ikke slettes. Dette kan medføre en vis tidsplan og administrative udfordringer.

FlexClone er langt mere fleksible i disse vilkår, da det skaber en klon af en bestemt øjebliksbillede af hele mængden. Selv om dette ville låse en enkelt snapshot, betyder det ikke påvirke fremtidige snapshot operationer, og låsemekanismen påvirker kun de normale rutineopgaver, hvis FlexClone bevares længere end den normale øjebliksbillede opbevaringsperioden.

FlexClone er en langt mere dynamisk og admin venlig teknologi og er afgjort den anbefalede metode. Det tager en masse af besværet, at LUN klon kan ofte medføre.

Der er ikke for mange Kranz har omkring Jeg vil fortælle Tom næste gang jeg ser ham!

Ser ud til du har ramt en kendt fejl i VSC. Kun reelle løsninger er scripted tilgang at fastsætte navngivning (som synes at arbejde for nogle mennesker), eller venter til NetApp at fastsætte koden i VSC at forhindre at dette sker!

Og der er ingen snapshots mod volumen indeholdende LUN? Er LUN kortlagt nogen initiativtagerne? Er lydstyrken vært nogen anden LUN'er? Fra visningen kommando eller LUN statistikken kommando, vil du se nogen aktivitet, vil dette LUN?