Kā salabot kļūdainu VMFS datu krātuvi
VMFS datu krātuves kļūme VMware vidē ir viena no nepatīkamākajām situācijām, jo tā skar ne tikai vienu failu vai vienu virtuālo mašīnu, bet visu glabātuves slāni, uz kura balstās vairāki servisi vienlaikus. Praktiski tas var izskatīties dažādi: datastore pēkšņi kļūst nepieejama, VM faili pazūd no pārlūka, parādās I/O kļūdas, hostam vairs neizdodas piemontēt krātuvi, vai arī virtuālās mašīnas iestrēgst ar kļūdām par lock, snapshot vai inaccessible statusu. Šādā brīdī vissvarīgākais ir nerīkoties impulsīvi. Visbiežāk tieši steiga — formatēšana, resignature bez analīzes, nekontrolēta failu kopēšana vai haotiska rescan veikšana vairākos hostos — padara situāciju sliktāku.
Labs atkopšanas process sākas ar disciplīnu: vispirms jānosaka, vai problēma ir VMFS metadatos, pašā LUN, RAID kontrolierī, multipath slānī, iSCSI vai FC savienojumā, vai tikai konkrētā hosta skatījumā. Tikai pēc tam drīkst pieņemt lēmumu, vai datastore jāmēģina remountēt, jāveic rescan, jāanalizē konkrētas VM failu ķēdes, vai arī jāatjauno dati no rezerves kopijas. Ja jūsu virtualizācijas vide hostē svarīgus pakalpojumus, paralēli ir vērts domāt par elastīgu infrastruktūru un rezerves scenārijiem: pārejas vidēm labi noder virtuālie serveri, lielākām slodzēm — serveru īre, bet drošai rezerves kopiju glabāšanai bieži palīdz arī mākoņu datu glabāšana.
VMFS problēmas reti rodas pilnīgi nejauši. Parasti cēlonis ir kāds no šiem slāņiem: storage kontroliera vai disku degradācija, nekorekts hosta restarts, LUN ID maiņa, nekārtīgi snapshot, nepareizi veikta migrācija, path flapping, APD vai PDL notikumi, vai kļūda pašos failos. Tāpēc šīs pamācības mērķis nav tikai dot vienu komandu, bet parādīt pareizo secību, lai jūs nesabojātu atjaunošanas iespējas.
1) Pirmais noteikums: neko nerakstiet uz bojātās datu krātuves
Ja datastore izskatās bojāta vai nepieejama, neizveidojiet uz tās jaunus failus, nemēģiniet tur veidot testa VM un neveiciet formatēšanu. Pat ja vSphere interfeiss piedāvā izveidot jaunu datastore uz tā paša diska, šādu soli šajā brīdī nedrīkst spert. Prioritāte ir saglabāt esošo metadatu un failu struktūru pēc iespējas neskartu, lai nepieciešamības gadījumā būtu iespējama korekta analīze vai atjaunošana.
Ja uz bojātās datu krātuves joprojām darbojas virtuālās mašīnas, neveiciet paniskas restartēšanas. Vispirms pārbaudiet, vai tās iespējams korekti izslēgt vai migrēt uz citu datastore. Ja Storage vMotion vide ir stabila un pa ceļiem nav aktīvu I/O kļūdu, tā var būt laba izeja. Taču, ja storage turpina mest kļūdas, pārmērīga datu pārvietošana var situāciju pasliktināt.
2) Pārbaudiet, vai problēma ir hostā, ceļos vai pašā LUN
Pirmais praktiskais solis ir noskaidrot, vai datastore neredz viens host, vairāki hosti vai visa VMware vide. Ja problēma ir tikai vienā hostā, pastāv laba iespēja, ka VMFS pati nav bojāta un vaina ir hosta adapterī, multipath konfigurācijā vai rescan stāvoklī. Ja datastore pazudusi visos hostos vienlaikus, daudz ticamāks ir storage vai LUN līmeņa incidents.
ESXi pusē pārbaudiet ierīču sarakstu, ceļus un failu sistēmas statusu. Praktiski sāk ar komandu kopu, kas parāda device, path un filesystem informāciju. Ja pati ierīce ir redzama, bet VMFS netiek piemontēta, problēma bieži ir VMFS parakstā, mount statusā vai metadatos. Ja ierīces nav vispār, jāskatās zemāk: iSCSI sesijas, FC fabric, HBA, RAID kontrolieris vai storage masīvs.
Pie iSCSI īpaši svarīgi ir pārbaudīt sessions un target pieejamību. Pie FC jāskatās zoning un fabric kļūdas. Pie lokāliem RAID jāvērtē kontroliera event log, cache vai battery statuss un disku veselība. Tas ir svarīgi, jo datastore kļūme bieži vien ir tikai simptoms, nevis galvenais bojājums.
3) Rescan, remount un resignature — tikai ar skaidru mērķi
Ja storage puse ir sakārtota un LUN atgriezusies, nākamais solis ir kontrolēta rescan veikšana. Rescan tikai liek hostam no jauna nolasīt storage topoloģiju; tas pats par sevi neko nelabo. Ja pēc rescan datastore joprojām neparādās, jānoskaidro, vai sistēma redz VMFS kā snapshot copy, nezināmu parakstu vai neaktīvu mount.
Šeit ļoti svarīgi saprast atšķirību starp remount un resignature. Remount mēģina atkal piemontēt esošo datastore ar to pašu identitāti. Resignature izveido jaunu VMFS identitāti. Tas ir noderīgi klonu vai kopētu LUN scenārijā, bet bojājuma situācijā resignature bez vajadzības var sarežģīt turpmāko atjaunošanu, jo mainās datastore UUID un identitāte.
Tāpēc labs princips ir vienkāršs: ja neesat pilnīgi pārliecināts, ka skatāties uz kopiju, nevis oriģinālo datastore, nesteidzieties ar resignature. Daudzos gadījumos drošāks solis ir remount, hosta ceļu stabilizēšana vai atjaunošana no storage snapshot, nevis jauna paraksta piešķiršana.
4) Pārbaudiet VM direktorijas, descriptor failus un snapshot ķēdes
Ja datastore ir redzams, bet konkrētas VM ir inaccessible, problēma var būt failu līmenī. Pārbaudiet, vai redzami .vmx faili, .vmdk descriptor faili un vai nav situācija, kur palikuši tikai -flat.vmdk vai -delta.vmdk faili. Tas nenozīmē, ka dati ir zuduši, bet nozīmē, ka jāstrādā ļoti uzmanīgi.
Descriptor faili ir īpaši svarīgi, jo tie sasaista virtuālo disku ķēdes. Ja descriptor ir bojāts vai pazudis, iespējams atjaunot piekļuvi, bet tikai tad, ja pareizi saprotat diska izmēru, adaptera tipu un snapshot struktūru. Nepareiza descriptor atjaunošana var padarīt atkopšanu grūtāku nekā sākotnēji.
Ja datastore bija gandrīz pilna, ļoti ticams, ka problēma saistīta ar snapshot pieaugumu vai nekorektu consolidate procesu. Pēc piekļuves atjaunošanas nevajag uzreiz dzēst vecos delta failus. Vispirms nosakiet, kurš disks ir aktīvs, vai nav lock no cita hosta, un tikai pēc tam plānojiet consolidate vai failu sakārtošanu.
5) Logi un komandas, kas dod visvairāk informācijas
Praktiskā analīzē lielu vērtību dod vmkernel logi, vobd ieraksti un storage kļūdu ziņojumi, kuros redzami APD, PDL, SCSI sense kodi un VMFS metadatu pazīmes. Ja redzat atkārtotus APD vai PDL notikumus, fokuss ir uz storage ceļiem un pieejamību, nevis failu sistēmas remontu. Ja logi norāda uz korupcijas pazīmēm, jārīkojas vēl piesardzīgāk.
Komandas, kas parāda extent, filesystem un scsi device informāciju, palīdz saprast, pie kuras ierīces datastore ir piesaistīta un kāds ir tās statuss. Tās ir labas diagnostikas komandas, jo neko nepārraksta. Bieži vien problēma sākas tikai tajā brīdī, kad administrators no analīzes pārāk ātri pāriet uz destruktīvu darbību.
Kad labot, kad atjaunot no backup un kad apstāties
Ja problēma ir ceļu, HBA, iSCSI, FC vai īslaicīgas storage pieejamības zuduma līmenī, bieži pietiek ar pareizu remount un vidi var atgriezt darbībā bez datu zaudējuma. Ja problēma ir konkrētu VM failos vai snapshot ķēdēs, iespējama failu līmeņa atkopšana. Taču, ja ir aizdomas par īstu VMFS metadatu bojājumu vai fiziska diska degradāciju, drošākais ceļš daudzos gadījumos ir apstāties un atjaunot no backup, nevis eksperimentēt uz oriģinālajiem datiem.
Profilakses ziņā ļoti palīdz konsekventa backup politika, datastore brīvās vietas uzraudzība un storage notikumu monitorings. VMFS datu krātuves nevajag uzturēt gandrīz pilnas, jo snapshot un consolidations šādos apstākļos kļūst bīstamāki. Tāpat ir vērtīgi dokumentēt LUN piesaistes, datastore UUID un hostu path politikas, lai incidenta brīdī nevajadzētu minēt, kā vide bija salikta.
Ja izmantojat shared storage vairākiem hostiem, regulāri pārskatiet multipath statusu un pārbaudiet, vai visi hosti redz to pašu ierīču komplektu vienādi. Netīras atšķirības starp hostiem bieži rada problēmas tieši pēc restarta vai maintenance darbiem. Jo labāk dokumentēta un novērota ir storage vide, jo mazāka iespēja, ka VMFS kļūme pārvērtīsies par ilgstošu dīkstāvi.
Labs administrators necenšas uzvarēt jebkuru storage bojājumu ar vienu komandu. Labs administrators zina, kad jāapstājas. Ja jums ir svaigas rezerves kopijas vai storage snapshot, to izmantošana bieži ir drošāka nekā agresīvi remonta mēģinājumi uz dzīvas datu krātuves. Tāpēc pareizā secība ir vienkārša: neko nerakstīt, noskaidrot cēloni, savākt diagnostiku un tikai tad izvēlēties vismazāk riskanto atkopšanas ceļu.