En NetApp Tekniske Diary

Jeg kan ikke sige, at jeg nogensinde har prøvet at sætte root-kodeordet som tom, 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 færdigheder 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 være 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, jeg er bange for jeg virkelig ikke få nogen udsættelse 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 ...

optioner autosupport.doit "tekststreng her"

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

Hej Ron,

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

At slukke disken automatisk tildele, skal du gøre følgende ...

optioner disk.auto_assign off

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

Hej Kurt,

Det problem, når du har et komplet aggregat er, at dette påvirker skriver som det første nummer. 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 små mængder ledig plads der er til rådighed. Dette tager skriver længere tid, men endnu vigtigere det har en enorm indflydelse på læser. 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æse 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 dit samlede forbrug (ned til mindre end 80% anbefales) og derefter omfordele de mængder, for at fordele data på tværs af spindler på en mere velordnet måde igen. Dette vil enormt forbedre læse performance fremadrettet, og den ledige plads vil gøre det muligt skrive ydeevne til en igen optræde på optimal hastighed.

Med en 100% fuld samlede man ofte ikke kan se en disk udnyttelse performance problem, men du kan se høje CPU og du kan se "CP Ty" (Sammenhæng punkt Type) tager lang tid at skylle på disken. Du kan se dette fra "sysstat-u 1". Det er meget afhængig af systemets model og den type data, du skriver, men en meget grov tommelfingerregel er, at hvis et CP tager mere end sige 3-4 sekunder, er det arbejder hårdere end det burde gøre. Men som jeg siger, hvis du har en 100% fuld samlet, er der lidt kortere 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, derefter omfordele. Eller slette nogle data / snapshots og frigøre noget plads på harddisken og derefter omfordele.

Det ser ud til du har et stort antal diske mangler eller undladt fra miljøet. Disse skal løses, 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 siddende. 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. Tjek alle de tilslutningsmuligheder først, så skal du måske være i stand til unfail de diske, hvis intet er virkelig 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 stærkt anbefale dig at kontakte NetApp Global Support, da 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 respons, selvom lyder som om du har tingene sorteret nu.

Hvis du ønsker at bruge SnapManager for 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 initiator 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 ved hjælp af enten FCP eller iSCSI.

Den største fordel ved løsningsmodel 1 er granulering kontrol. Exchange admin ikke også behøver at være en VMware admin for at styre og kontrollere hans 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 initiator installeret for alle, og det har både ledelse og CPU overhead.

Fordelen ved mulighed 2 er, at du centralisere storage tilslutningsmuligheder. Uanset hvilken bruger det sker altid på VMware-niveau, kan dette give dig bedre sikkerhed og synlighed om, hvem der bruger hvad opbevaring. Fordelen ved at bruge iSCSI på værten niveau er, at det kun er én forekomst af softwaren initiativtageren. Med FCP denne forsvinder helt. De største negative af valgmulighed 2 er det modsatte af valgmulighed 1, er Exchange-admin ikke få direkte kontrol over sin opbevaring, dog med SnapDrive du stadig få ganske god kontrol, kan du stadig klone, vokse, snapshot og så videre indefra SnapDrive.

Præsentation af storage til et datalager så carving 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 vælges mellem RDM fra ESX og iSCSI initiator inden VM. Min personlige favorit er brug RDMs selv om der kan være yderligere forbehold eller ændringer, hvis du også laver DR. VMware SRM handler godt med RDMs dog, men virker ikke på alle med iSCSI initiativtagere inden VM.

Håber du har alle tingene sorteret i forvejen 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 knude. De logger så sidde på den modsatte systemet igen. Dette hjælper os virkelig til afbalancering af lasten på tværs af en klynge, giver dig flere spindler til at bruge og giver dig et niveau af fysisk adskillelse. Det hjælper dig også med at gøre en vis grad af damage control med systemet skilles ud som dette. Men jeg ville ikke have et system dedikeret til SQL, og den anden til Exchange, du ønsker at balancere ting som logger ud. Det vil give dig flere patroner til en enkelt ansøgning, og du kan stadig anvende en grad af kontrol.

Kig også på Opbevaring IO Control fra VMware side af tingene (rigtig god måde at styre IO hvis du har opfører sig korrekt 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. Dette fungerer på samme måde som VMware aktier, men du lægger dem på lydstyrken og har en vis grad af kontrol over IO og ydeevne, som hver lyden bliver leveret. For eksempel vil du måske ønsker at begrænse IFF brugere til fordel for en SQL-database. Det kan være, at alt bliver på medium (standard), men du lægger Mail DB på meget højt at give det en bedre andel af ressourcerne.

Tak for feedback, det er bare en skam 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 siger min VMware-kunder) begrænser ressourcer på en travl system vil naturligvis påvirke tingene. Det vil gøre en dårlig situation bedre for de mængder, man prioriterer, men det vil gøre det meget værre at alle de andre bind. Et system under hårdt pres allerede nu, at er at have problemer med ydeevnen er ikke den bedste kandidat til ressource aktier eller prioritet grænser. Jeg vil anbefale dig at løse de problemer med ydeevnen første eller begynde at kigge til at begrænse belastningen af ​​anvendelsen side, før du placerer prioritet på tværs af alle mængder.

Husk også, at prioritet kun kommer i spil, når der er ressourcekrævende bliver bedt om. Så hvis du for eksempel ønsker at give flere ressourcer til SQL og Exchange, og den eneste andre ressourcer på, at systemet er let brugt CIFS aktier, vil du sandsynligvis få lidt gavn så lidt IO bliver genereret fra CIFS aktier. 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 høje, at det 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 nogen tid at gennemføre, så du kan have forsøgt at gøre det for hurtigt efter påbegyndt 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 for en eller anden grund.

Undskyldninger for manglende din kommentar!

Kan du give mig et bredere billede af volumen / LUN-konfiguration. Er lydstyrken tvivl om en FlexClone, eller er det at blive FlexCloned? Hvis ikke, har nogen LUN klon operationer blevet gjort på det, enten manuelt eller fra et SnapManager job? Når du viser snapshots for volumen, hvad det viser? Eventuelle særlige øjebliksbillede viser som låst eller optaget? er LUN kortlagt i øjeblikket?

LUN klon gør en klon af LUN inden for samme volumen som den originale. Dette betyder, at hvis de efterfølgende øjebliksbillede 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, at nogle planlægge 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 et enkelt snapshot, påvirker det ikke nogen fremtid øjebliksbillede operationer, og den låsemekanisme kun påvirker den normale rutine opgaver, hvis de FlexClone bevares længere end den normale snapshot lagringsperiode.

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

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

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

Og der er ingen snapshots imod mængden, der indeholder LUN? Er LUN knyttet til nogen initiativtagere? Er lydstyrken værten andre LUN'er? Fra statistik kommandoen eller LUN statistik kommando, kan du se nogen aktivitet, vil dette LUN?