NetApp Tehniskā dienasgrāmatu

Es nevaru teikt, es esmu mēģinājis, lai uzstādītu root paroli, tukšs, un nevar teikt, es gribētu ieteikt arī tos. Ja jūs izmantojat "ndmpcopy" Jūs varat noteikt avota un saņēmēja akreditācijas datus ar "-sa lietotājvārds: parole" un "-da lietotājvārds: parole".

Labākais bet ir jāsāk no šajā nozarē. Lielākā daļa manu prasmju nāk no tā self māca un strādā B2net. Varbūt atrast kādu uzglabāšanas pārdevējs vai izplatītāju savā jomā un redzēt par iegūt dažas darba pieredzi.

Es vienmēr atrast studēt grūti, ja man nav got projektu vēlmi sadarboties, tāpēc lasot grāmatas un studējot rokasgrāmatas varētu nebūt labākais veids, kā iemācīties pareizi. Turklāt tas ir ārkārtīgi garlaicīgi darām!

Hi Scott, B2net noteikti var sniegt šo pakalpojumu jums, mēs ne tikai ir 24/7 atbalsts dienestu, kas ir labi apmācīts visos NetApp produktiem, bet arī ļoti prasmīgu un talantīgu inženieru komanda. Ja tu jautā par neatkarīgu konsultantu, es baidos, es tiešām nesaņem jebkādu iedarbību uz tiem, jo ​​mums ir dažas nozares vadošo iemaņas iekšēji un reti jāiesaistās 3rd puses. Es labprāt organizēt kāds Jums sazināties, lai pārrunātu iespēju ad-hoc atbalstu tālāk kā tas noteikti ir kaut kas, mēs varam piedāvāt.

Tu domā AutoSupport? Yeah, jūs varat darīt, vai nu no FilerView vai no CLI. No CLI tikai darīt ...

iespējas autosupport.doit "teksta virkni šeit"

... Un aizstāt "teksta virkni šeit" ar jebkāda ziņa jūs vēlaties NetApp reaģēt, parasti gadījumu skaitu.

Hi Rons

Vai Jums ir (vai jums bija) visas lun klonus agrāk? Varbūt tie ir kļuvuši bloķēta momentuzņēmums, un jūs esat tā izdzēsis lun klons, bet klons joprojām ir lun bloķēta. Pārbaudiet snapshots no apjoma un redzēt, ja kāds ir bloķēta. Ja jums ir dzēšanu LUN, ir tur kaut kas cits apjoma? Ja jūs offline skaļumu, jūs noteikti noņemt visas saites uz LUN. Tad jūs varētu vienkārši izdzēst apjomu un to atkārtot.

Lai izslēgtu diska auto piešķirt, veiciet šādas ...

iespējas disk.auto_assign off

un pēc tam ANO pieder šīs diski vēlreiz. Jums vajadzētu būt labi iet tad!

Hi Kurts,

Problēma, kad jūs strādājat pilnu apdrošināšanas kopsumma ir, ka tas ietekmē raksta kā pirmo jautājumu. Parasti WAFL rindas līdz raksta svītru pāri visiem diskiem un tā mēģina to darīt ar tik lielu kā joslu, kā iespējams, jo tas ir optimālais veids, gan rakstīt, un lasīt vēlāk. Ar kopējo 100%, tur ir maz vietas, lai rakstīt lielus svītras, tāpēc ir, lai izjauktu tiem raksta mazākos gabalos un rakstīt uz mazo daudzumu brīvas telpas, kas ir pieejams. Tas aizņem raksta ilgāk, taču vēl svarīgāk tas ir milzīgs iespaids uz lasījuši. Jànolasa tagad jādara vairāk fizisko vārpstas kustību, lai veiktu nolasīšanas Aheads vai pat tikai vienkāršs kārtas lasīt kas tagad noteikts visā vārpstas, nevis jauku saspringts secībā.

Rādīt jūsu agregāts ar 100% ne tikai ietekmē tūlītējus rakstīt sniegumu, taču tas nepārtraukti ietekmē lasīt sniegumu par visiem datiem, kas tika rakstīti tajā laika grafikā, kopējais bija gandrīz pilns, vai pilns. Jums vajadzēs samazināt kopējo patēriņu (samazinājies līdz mazāk nekā 80% ir ieteicams) un pēc tam pārdalīt apjomu, izplatīt datus visā vārpstas, kas ir vairāk sakārtotu veidā vēlreiz. Tas būs ļoti uzlabos lasīt sniegums iet uz priekšu, un brīvas telpas ļaus rakstīt sniegumu vienam atkal uzstāsies optimālo ātrumu.

Ar 100% pilnas kopsummu, tu bieži neredzat diska izmantošanas efektivitātes jautājums, bet jūs varat redzēt augsta CPU, un jūs varat redzēt "CP ty" (Saskanība punkts tips), ņemot ilgs laiks, lai flush diskā. Jūs varat redzēt šo no "1 sysstat-u". Tas ir ļoti atkarīga no sistēmas modeļa un datu rakstāt veidu, bet ļoti aptuvenu noteikums īkšķis ir, ja CP lieto vairāk nekā pateikt 3-4 sekundes, tas strādā grūtāk, nekā tas būtu jādara. Bet kā es saku, ja jums ir 100% pilnu kopumu, tur ir maz īstermiņa programmatūras darbu jūs varat darīt, lai mazinātu šo problēmu, noteikt ir vienkārša, vairāk diska vai mazāk datu. Tātad nopirkt dažas vairāk vārpstiņas un pievienot tos uz kopsummu, tad pārdalīt. Vai izdzēst dažus datus / momentuzņēmumus un bezmaksas dažas vietas uz diska un pēc tam pārdalīt.

Izskatās, ka jums ir daudz disku trūkstošo vai nav no vides. Tie ir ar ko, pirms jūs varat dot kopumu atpakaļ tiešsaistē vēlreiz. Jums nepieciešams pārbaudīt, ka diski ir pieslēgti pareizi. Labākais veids, kā to panākt, ir iespējams, lai izslēdzās sistēmu un nodrošināt visu kabeļu ir pilnībā savienota un droši, un ka visi diski ir pareizi sēž. Cerams kaut kā brīvs kabeļa izraisījis filtrē neizdoties šos diskus nevis faktisko datu vai mehāniska defekta visu šo disku. Pārbaudīt visu savienojumu 1., tad jūs varētu būt iespēja unfail šos diskus ja nekas faktiski nepareizs ar to.

Tomēr, ja disks ir pilnībā neizdevās, tad es baidos, ka jūs varētu būt diezgan situācijā.

Es ļoti iesakām jums sazināties ar NetApp Global Support, jo viņi varēs staigāt jums caur process pārbaudīt šos diskus un, ja iespējams, remonts kopumu. Tas var būt zināma kļūda, un viegli noteikt, bet tie ir labākā situācijā, lai diagnosticētu šo.

Hi Kurts,

Es došu jums ātru atbildi, lai gan izklausās jums ir viss sakārtots tagad.

Ja jūs vēlaties izmantot SnapManager for Exchange, tad jums tiešām ir 2 dažādi veidi, kā pasniegt uzglabāšanu uz Exchange VM.

1) Savienojums ar tām, izmantojot iSCSI programmatūras ierosinātājam ietvaros VM
2) Pievienojiet, lai tās, izmantojot RDMs par ESX līmenī un iesniegt izejvielas LUN uz VM. To var izdarīt, izmantojot vai nu FCP vai iSCSI.

Galvenā priekšrocība 1 variants ir detalizācijas kontrole. Birža admin nav arī jābūt VMware admin, lai pārvaldītu un kontrolētu viņa uzglabāšanu. Varbūt ikvienam būtu daži VMware zināšanas gan. Negatīvie 1 variants ir, ka, ja jums ir daudz VMS vajadzīga glabāšanai šādā veidā, tas būs neatkarīga programmatūras ierosinātājs uzstādīta ikvienam, un tas ir gan vadības, gan CPU pieskaitāmās.

2 iespējas priekšrocība ir tā, ka jums ir centralizēt uzglabāšanas savienojumu. Neatkarīgi no izmantošanas tas tiek vienmēr darīts pēc VMware līmenī, tas var sniegt jums labāku drošību un redzamību, kas izmanto kāda uzglabāšanu. Tad izmantojot iSCSI tajā uzņēmējā līmenī priekšrocība ir tā, ka tas ir tikai viens gadījums programmatūras iniciators. Ar FCP izzūd pavisam. Galvenais mīnuss 2 variants ir pretēja 1 variantu, Birža admin nesaņem tiešu kontroli pār viņa glabāšanā, tomēr ar SnapDrive jūs joprojām saņemt diezgan labu kontroli, jūs varat klons, augt, momentuzņēmums un tā tālāk no iekšienes SnapDrive.

Pasniedzot uzglabāšanu līdz DataStore tad griešanai VMDK ir iespējams sliktākais gadījums, kā jums nav get any SnapDrive vai SnapManager integrāciju no Exchange, bet jūs vēl joprojām ir virs galvas, kas savieno no VMware. Es domāju, ka tā var tikai būt typo jūsu jautājumu, jo izskatās, ka jums bija izšķirties starp RDM no ESX un iSCSI iniciators ietvaros VM. Mans personīgais favorīts ir, izmantojot RDMs gan var būt papildu iebildumi vai izmaiņas, ja jūs arī darāt DR. VMware SRM nodarbojas arī ar RDMs tomēr, bet nedarbojas vispār ar iSCSI iniciatoriem ietvaros VM.

Ceru, ka jums ir viss sakārtots jau tomēr!

Hi Kurts,

Ja jums ir klastera, es gribētu skatīties likt SQL DB 's uz vienu mezglu, un pasta DB ir uz citu mezglu. Apaļkokus tad sēdēt uz pretējā sistēmā vēlreiz. Tas tiešām palīdz līdzsvarot slodzi pāri klastera, dod jums vairāk vārpstiņas izmantot un sniedz jums līmeni nodalīšanu. Tas arī palīdz jums darīt zināmu līmeni bojājumu novēršanai ar sistēmu atdalītas no kā šis. Tomēr es nebūtu sistēmu veltīta SQL, un otrs ar Exchange, jūs vēlaties, lai līdzsvarotu lietas, piemēram, žurnāliem ārā. Tai došu jums vairāk vārpstiņas par vienu pieteikumu, un jūs joprojām varat lietot kontroles līmeni.

Arī apskatīt Storage IO kontroles no VMware pusē lietām panta lielisks veids, kā kontrolēt IO ja esat misbehaving mašīnas), un arī apskatīt liekot dažādas prioritātes uz NetApp apjomiem. Jūs varat iestatīt šos no ļoti zema, zema, vidēja, augsta un ļoti augsta. Tas darbojas līdzīgi kā VMware akciju, bet jūs viņus pie skaļuma līmenī un ir zināmā mērā kontroles pār IO un darbību, kas katru apjoms izpaužas piegādāts. Piemēram, jūs varētu vēlēties ierobežot CIFS lietotājus par labu SQL datubāzē. Tā var būt, ka viss paliek vidē (noklusējums), bet jūs nodot Pasta DB uz ļoti augsta, lai varētu tai labāk daļu resursu.

Paldies par atsauksmi, tas ir tikai kauns man nav iegūt vairāk laika, lai izdarītu vairāk tematus!

Iespējojot prioritāte, tā nosaka noklusējuma (Medium) politika visās apjomiem, tāpēc jums nav nepieciešams to darīt atsevišķi. Jums būs nepieciešams atsevišķi noteikt atšķirības, tas kā to prasa tomēr.

Prioritāti var palīdzēt sistēmu, kas cīnās, lai konkurētu ar tādām lietām kā SnapMirror jo tā dod priekšroku pār sistēmas uzdevumiem. Kā ar jebkuru no resursu sadales instruments (tāpat kā es pateikt manu VMware klientiem) Kārtot ierobežojot resursus aizņemts sistēmu, protams, ietekmēs lietas. Tas būs padarīt sliktā stāvoklī labāks par apjomiem jums dod priekšroku, taču tas būs padara daudz sliktāk visiem pārējiem apjomiem. Ar lielu slodzi sistēma jau ka ir, kam problēmas ar pienākumu veikšanu nav labākais kandidāts resursu akcijām vai prioritāro ierobežojumiem. Es gribētu ieteikt jums risināt veiktspējas problēmas 1. vai sākt meklēt, lai ierobežotu kravas no pieteikuma pusē pirms laišanas prioritāti visos sējumos.

Atcerieties arī, ka prioritāte tikai sāk spēlēt, ir resurss, ko lūdza. Tātad, ja, piemēram, jūs vēlaties, lai dotu vairāk resursu SQL un Exchange, un tikai citi resursi šai sistēmai ir viegli izmantot CIFS akcijas, jūs, iespējams gūt nelielu labumu, jo maz IO tiek ģenerēts no CIFS akcijām. Piešķirtu visiem prioritāti SQL un Exchange joprojām rezultātā tās piespiedu ar tuvināšanās.

Hi Michael, atvainojos par kavēšanos saņemt atpakaļ uz jums. Jūs varētu mēģināt veikt SnapMirror resync, tomēr izredzes ir lielas, ka tas tagad var būt vajadzīgs jauns bāzlīniju. Turklāt, ja VSM nevarat dzēst mērķa snap, tad izredzes ir, ka flex klons joprojām ir tas bloķēta kaut kā. Sadalīšanas process var aizņemt kādu laiku, lai pabeigtu, lai jūs varētu ir mēģinājuši to darīt pārāk ātri pēc uzsākšanas sadalījumu.

Diemžēl, kad SnapMirror iesprūst vai sajaukt, vienīgā reālā iespēja ir pamata, ja vien daži līdzīgi snapshots joprojām pastāv. Esmu bijis daudzās neveiklās situācijās, kad man bija, lai atkārtotu izejas galamērķi, jo snapshots tiek svītrots viens iemesls vai citu.

Atvainojos par trūkstošo savu komentāru!

Vai jūs varētu man plašāku priekšstatu par tilpuma / lun konfigurācija. Ir tilpums attiecīgā FlexClone, vai tas tiek FlexCloned? Ja nē, ir kādi lun klons operācijas darīts, vai nu manuāli, vai no SnapManager darbu? Ja jums parādīt momentuzņēmumus par apjomu, ko tas liecina? Kādam konkrētam momentuzņēmums parādot kā aizslēgtas vai aizņemts? Vai lun plānots šobrīd?

Lun klons padara klons LUN tajā pašā apjomā kā oriģinālam. Tas nozīmē, ka, ja vēlākie momentuzņēmums darbības notiek pēc klons ir izveidots, tas faktiski bloķē lun klons, ko tad atsauce laikā momentuzņēmums tā nevar izdzēst. Tas var izraisīt grafiku un administratīvās problēmas.

FlexClone ir daudz elastīgāka, šajos noteikumos jo tas rada klons konkrētā momentuzņēmums visu apjomu. Kaut gan tas bloķētu individuāla momentuzņēmums, tas neietekmē jebkādus turpmākus momentuzņēmumus operācijas, un bloķēšanas mehānisms skar tikai parastās ikdienas uzdevumus, ja FlexClone tiek saglabāts ilgāk nekā parastā momentuzņēmums nemainīšanas periodā.

FlexClone ir daudz dinamiskāka un admin draudzīgu tehnoloģiju un noteikti ir ieteicamā pieeja. Tas aizņem daudz ērtāku šo lun klons bieži var izraisīt.

Tur nav pārāk daudz Kranz ir ap Es jums saku: Tom nākamreiz es redzu viņu!

Izskatās, ka jūs esat hit zināma kļūda VSC. Vienīgais reālais risinājums ir scenāriju pieeja, lai noteiktu vārda piešķiršanu (kas, šķiet, darbojas, lai daži cilvēki), vai gaida NetApp noteikt kodu VSC, lai to novērstu!

Un nav pret tilpuma satur LUN momentuzņēmumi? Vai lun plānots nekādi ierosinātāji? Vai tilpums uzņemt jebkuru citu Luns? No stats komandu vai Lun stats komandu, Jūsuprāt jebkura darbība, dodoties uz šo LUN?