NetApp Tehniskā dienasgrāmatu

Es nevaru teikt, esmu kādreiz mēģinājis noteikt root paroli, kā tukši, un nevar teikt, es ieteiktu vai nu. Ja jūs izmantojat "ndmpcopy" Jūs varat noteikt avota un mērķa pilnvaru ar "-sa username: password" un "-da username: password".

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

Es vienmēr atrast mācās grūti, ja man nav got projektu, censties panākt, lai grāmatu lasīšana un pētot rokasgrāmatas var nebūt labākais veids, kā iemācīties pareizi. Turklāt, tas ir ārkārtīgi garlaicīgi to dara!

Hi Scott, B2net noteikti var sniegt šo pakalpojumu jums, mēs ne tikai 24 / 7 support desk, kuri ir labi apmācīti visās NetApp produktiem, bet arī ļoti prasmīgi un talantīgi inženieri komanda. Ja Jums ir jautā par neatkarīgu konsultantu, es baidos, man tiešām nav get any iedarbību, jo mums ir dažas nozares vadošo iemaņas iekšēji un tikai retos gadījumos jāiesaistās 3. pusēm. Es gribētu būt laimīgs, lai parūpētos par kādu Jums sazināsimies, lai apspriestu iespēju ad-hoc atbalstu tālāk, jo tas, protams, kaut kas, mēs varam piedāvāt.

Tu domā AutoSupport? Jā, jūs to varat izdarīt vai nu no FilerView vai no CLI. No CLI tikai do ...

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

... Un aizvietot "teksta virkni šeit", ar kāda ziņu vēlaties NetApp reaģēt uz, parasti lietas numuru.

Hi Ron,

Vai jums ir (vai bija jums) jebkuru lun klonus agrāk? Iespējams, ka šie ir kļuvuši bloķēta momentuzņēmums, un jums ir tā izdzēsis LUN klons, bet klons joprojām ir lun bloķēta. Pārbaudiet snapshots no apjoma un redzēt, ja tādi ir bloķēti. Ja, dzēšot LUN, ir tur kaut kas cits apjoms? Ja esat bezsaistē apjomu, 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 disku auto piešķirt, rīkojieties šādi ...

iespējas disk.auto_assign off

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

Hi Kurt,

Problēma, ja jums ir pilns kopums ir tas, ka tas ietekmē raksta kā pirmo jautājumu. Parasti WAFL rindas līdz pat raksta svītru pāri visiem diskiem, un tā cenšas to darīt ar tik lielu svītru vien iespējams, jo tas ir optimāls veids, lai gan rakstīt un lasīt vēlāk. , Ar kopējo 100%, ir par maz, lai rakstītu lieliem svītrām, tāpēc ir, lai izjauktu šos raksta mazākos gabalos un rakstīt uz nelielu daudzumu brīvas telpas, kas ir pieejams. Tas ilgst raksta ilgāk, bet vēl svarīgāk tas ir milzīga ietekme uz skan. Lasa Tagad ir nepieciešams darīt vairāk fizisko vārpstas kustību, lai veiktu read-Aheads vai pat tikai vienkāršs kārtas lasīt, kas tagad ir noteikts visā vārpstas, nevis jauka saspringts secību.

Running savu kopumā ar 100% ne tikai ietekmē tūlītējus rakstīt sniegumu, bet tas būs nepārtraukti ietekmēs lasīt sniegumu attiecībā uz jebkuru datu, kas tika rakstīts laikā apjomā, ka kopapjoms ir gandrīz pilna, vai pilna. Jums ir nepieciešams, lai samazinātu jūsu kopējo izmantošanu (līdz mazāk nekā 80% ir ieteicams) un pēc tam pārdalīt apjomus izplatīt datus pa asis, kas ir vairāk sakārtotu veidā vēlreiz. Tas ļoti uzlabo lasīt sniegumu iet uz priekšu, un brīvas telpas ļaus rakstīt veiktspēju uz vienu atkal veikt optimālu ātrumu.

Ar 100% no pilnas kopums, jūs 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 Point Type), ņemot ilgs laiks, lai flush diskā. Jūs varat redzēt šo, no "1 sysstat-u". Tas ir ļoti atkarīga no sistēmas modelis un datu rakstāt tipu, bet ļoti aptuvenu noteikums īkšķis ir tas, ka, ja CP lieto vairāk nekā teikt 3-4 sekundēm, tas strādā grūtāk, nekā tas būtu jādara. Bet kā es saku, ja jums ir 100% no pilnas kopumā, 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 kopumā, tad pārdalīt. Vai dzēst daži dati / momentuzņēmumus un atbrīvotu dažas vietas uz diska un pēc tam pārdalīt.

Izskatās, ka jums ir liels skaits disku pazudis vai nav no vides. Šie nepieciešams noteikt pirms varat dot kopējo atpakaļ tiešsaistē vēlreiz. Jums nepieciešams pārbaudīt, vai disks ir pareizi. Labākais veids, kā to panākt, ir iespējams izslēdzās sistēmas un nodrošina visu kabeļu ir pilnībā savienota un droši, un ka visi diski ir pareizi sēž. Cerams, ka kaut kā brīvs kabelis ir radījis filer neizdoties šos diskus nevis faktiskie dati vai mehānisks bojājums visu šo disku. Pārbaudiet visas savienojumu pirmo, tad jūs varētu būt iespēja unfail šo disku, ja nekas faktiski ir nepareizi ar tiem.

Tomēr, ja disks ir pilnībā izdevies, 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ārbaudes šos diskus un, ja iespējams remonts kopsummā. Tas var būt zināma bug un viegli noteikt, bet tie ir labākā situācijā, lai diagnosticētu šo.

Hi Kurt,

Es jums ātri reaģēt, lai gan izklausās kā jūs ir lietas sakārtoti tagad.

Ja vēlaties izmantot SnapManager for Exchange, tad jums patiešām ir 2 dažādi veidi, kā iesniegt uzglabāšanas Exchange VM.

1) Pievienojiet, lai tās, izmantojot iSCSI programmatūru iniciators laikā VM
2) Savienojiet tām, izmantojot RDMs par ESX, un jāprezentē izejvielas lun uz VM. To var izdarīt, izmantojot vai nu FCP vai iSCSI.

Galvenā priekšrocība 1 variants ir detalizācijas kontrole. Apmaiņas 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 though. Negatīvie 1 iespēja ir, ka, ja jums ir daudz VM nepieciešama uzglabāšana šādā veidā, tas būs neatkarīgas programmatūras ierosinātājs ierīko visiem, un tas ir gan vadības, gan CPU pieskaitāmās izmaksas.

2 variants priekšrocība ir tā, ka jums ir centralizēt uzglabāšanas savienojumu. Neatkarīgi no tā lietošanas tas vienmēr darīts pēc VMware līmenī, tas var sniegt jums labāku drošību un pārredzamību, kas izmanto to, ko glabāšanai. Izmantojot iSCSI pie uzņēmēja līmenī priekšrocība ir tā, ka tikai vienā gadījumā no programmatūras iniciators. Ar FCP tas pazūd pavisam. Galvenie negatīvie 2 variants ir pretēja 1 variants, Birža admin nesaņem tiešu kontroli pār savām uzglabāšanas, tomēr ar SnapDrive jūs joprojām saņemt diezgan labu kontroli, joprojām varat klons, augt, momentuzņēmums un tā tālāk no iekšienes SnapDrive.

Iepazīstinot uzglabāšanas datastore tad griešanai VMDK, iespējams, sliktākajā gadījumā, kā jums nav get any SnapDrive vai SnapManager integrācija no Exchange, bet jūs vēl joprojām ir pieskaitāmās savienojot no VMware. Es domāju, ka tā var tikai būt typo savu jautājumu, kā tas izskatās kā 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 brīdinājumus 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 Kurt,

Ja jums ir klastera, es gribētu skatīties likt SQL DB ir uz viena mezglā, un Mail DB ir uz citu mezglu. Logs pēc tam sēdēt uz pretējo sistēma vēlreiz. Tas tiešām palīdz līdzsvarot slodzi pāri kopu, dod jums vairāk vārpstiņas izmantot, un sniedz jums līmeni fizisku nodalīšanu. Tas arī palīdz jums darīt dažas līmeni bojājumu kontroli ar sistēmu nodalīti, kā šis. Tomēr es nebūtu sistēmu, kas veltīta SQL, un otru, lai Exchange, jūs vēlaties, lai līdzsvarotu lietas, piemēram, baļķi out. Tas būs jums vairāk asis, kas paredzēti vienreizējai piemērošanai, un jūs joprojām varat pieteikties kontroles līmeni.

Arī apskatīt Storage IO Control, no VMware pusē lietām (lielisks veids, kā kontrolēt IO, ja Jums ir misbehaving iekārtas), kā arī apskatīt liekot dažādas prioritātes, uz NetApp apjomiem. Jūs varat uzstādīt tos no ļoti zema, zema, vidēja, augsta un ļoti augsta. Tas darbojas līdzīgi kā VMware akcijas, bet jūs viņus pie skaļuma līmeni un ir dažas kontroles līmeni 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ājiem par labu SQL datu bāzi. Tā var būt, ka viss paliek uz vidi (pēc noklusējuma), bet jūs varat ievietot Mail DB ir ļoti augsta, lai varētu tai labāk daļu resursu.

Paldies par atsauksmēm, tas ir tikai kauns man nav get vairāk laika, lai izdarītu vairākas tēmas!

Iespējojot prioritāte, tā nosaka default (vidējs) politiku visās apjomiem, tādēļ jums nav nepieciešams to darīt atsevišķi. Jums būs nepieciešams atsevišķi noteikt atšķirības, uz šo, kā prasīts tomēr.

Prioritātes var palīdzēt sistēmu, kas cīnās, lai konkurētu ar lietām, piemēram, SnapMirror, jo tā dod priekšroku pār sistēmas uzdevumi. Tāpat kā jebkura veida resursu sadali instruments (tāpat kā es pateikt manu VMware klienti) ierobežot resursu aizņemts sistēma, protams, ietekmēs lietas. Tas būs padarīt sliktā stāvoklī labāka apjomiem jums dot priekšroku, bet tas būs padarīt to daudz sliktāk visām pārējām apjomus. Ar lielu slodzi sistēma jau ka ir, kam darbības problēmas nav labākais kandidāts resurss akcijām vai prioritāte ierobežojumus. Es gribētu ieteikt jums risināt veiktspējas jautājumiem, pirmajā vai sākt meklēt, lai ierobežotu kravas no pieteikuma pusē, pirms laist prioritāte visos sējumos.

Atcerieties arī, ka galvenā prioritāte ir tikai stājas spēlēt, kad ir resursa lūdza. Tātad, ja, piemēram, vēlaties piešķirt vairāk resursu SQL un Exchange, un tikai citus resursus, šī sistēma ir viegli izmantot CIFS akcijas, jūs, iespējams gūt nelielu labumu, jo maz IO tiek ģenerēti no CIFS akcijām. Sniedzot visiem prioritāti SQL un Exchange joprojām dēļ tās ierobežojums ar eachother.

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 jauna bāzes. Turklāt, ja VSM nevarat dzēst mērķa snap, tad iespējams, ka flex klons joprojām ir šādi bloķēta kaut kā. Atdalīšana ir process var aizņemt kādu laiku, lai pabeigtu, tāpēc jums, iespējams, ir mēģina to darīt pārāk ātri pēc uzsākšanas split.

Diemžēl, kad SnapMirror iesprūst vai sajaukt, vienīgā reālā iespēja ir pamata, ja vien daži līdzīgi momentuzņēmumus joprojām pastāv. Esmu bijis daudzās neērtām situācijām, kad man bija atkārtoti bāzes galamērķis, jo snapshots tiek dzēsti vienu iemeslu vai citu.

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

Vai jūs varētu man plašāku priekšstatu par apjoma / lun konfigurācija. Tilpums attiecīgā FlexClone, vai tas tiek FlexCloned? Ja nē, nekādas LUN klons operācijas darīts, vai nu manuāli, vai no SnapManager darbu? Kad jūs izrādāt snapshots par apjomu, ko tas liecina? Jebkura īpaši momentuzņēmums parādās kā slēgts vai aizņemts? ir LUN plānots šobrīd?

LUN klons padara klons LUN ietvaros tādu pašu tilpumu kā sākotnējā. Tas nozīmē, ka ja turpmāko momentuzņēmums darbības notiks pēc klons ir izveidots, tas patiesībā slēdzenes LUN klons, kas pēc tam atsauce laikā momentuzņēmums, lai nevar izdzēst. Tas var izraisīt dažas grafiku un administratīvās problēmas.

FlexClone ir daudz elastīgāka šajos noteikumos, jo tā rada klons īpaši momentuzņēmumu visu apjomu. Lai gan tas varētu lock individuāla momentuzņēmums, tas neietekmē turpmāku momentuzņēmums darbību, un bloķēšanas mehānisms tikai ietekmē ikdienas uzdevumus, ja FlexClone tiek saglabāta ilgāk nekā parastais momentuzņēmums saglabāšanas periods.

FlexClone ir daudz dinamiskāks un admin draudzīgas tehnoloģijas un noteikti ir ieteicamā pieeja. Tas aizņem daudz problēmu, ka LUN klons bieži var izraisīt.

Tur nav pārāk daudz Kranz ir ap Es tev varu pateikt Tom nākamreiz es viņu redzēt!

Izskatās, ka jūs esat hit zināma kļūda VSC. Tikai reālus risinājumus, ir scenāriju pieeja, lai noteiktu nosaukumu (kas, šķiet, darbojas, lai daži cilvēki), vai gaida NetApp noteikt kodu, VSC, lai to novērstu!

Un nav, salīdzinot ar apjomu, kas satur LUN snapshots? Vai LUN plānots jebkuru iniciatoriem? Vai apjomu uzņēmējā jebkuras citas Luns? No stats komandu vai lun stats komandu, jūs redzat jebkuru darbību, dodoties uz šo lun?