ലോഗുകൾ എവിടെ നിന്ന് വരുന്നു? വീം ലോഗ് ഡൈവിംഗ്

ലോഗുകൾ വഴിയുള്ള ട്രബിൾഷൂട്ടിംഗ് ... ഊഹത്തിന്റെ ആകർഷകമായ ലോകത്തിലേക്ക് ഞങ്ങൾ മുഴുകുന്നത് തുടരുന്നു. IN മുമ്പത്തെ ലേഖനം അടിസ്ഥാന നിബന്ധനകളുടെ അർത്ഥം ഞങ്ങൾ അംഗീകരിക്കുകയും വീമിന്റെ മൊത്തത്തിലുള്ള ഘടനയെ ഒരൊറ്റ പ്രയോഗമായി ഒറ്റ കണ്ണുകൊണ്ട് നോക്കുകയും ചെയ്തു. ലോഗ് ഫയലുകൾ എങ്ങനെയാണ് രൂപപ്പെടുന്നത്, ഏത് തരത്തിലുള്ള വിവരങ്ങളാണ് അവയിൽ പ്രദർശിപ്പിച്ചിരിക്കുന്നത്, എന്തുകൊണ്ടാണ് അവ എങ്ങനെ കാണപ്പെടുന്നത് എന്ന് കണ്ടെത്തുക എന്നതാണ് ഇതിനുള്ള ചുമതല.

ഈ "ലോഗുകൾ" എന്താണെന്ന് നിങ്ങൾ കരുതുന്നു? മിക്കവരുടെയും അഭിപ്രായത്തിൽ, ഏതൊരു ആപ്ലിക്കേഷന്റെയും ലോഗുകൾക്ക് ഒരുതരം സർവ്വശക്തമായ അസ്തിത്വത്തിന്റെ പങ്ക് നൽകണം, അത് മിക്കപ്പോഴും വീട്ടുമുറ്റത്ത് എവിടെയെങ്കിലും വളരുന്നു, എന്നാൽ ശരിയായ നിമിഷത്തിൽ തിളങ്ങുന്ന കവചത്തിൽ എവിടെയും നിന്ന് പ്രത്യക്ഷപ്പെടുകയും എല്ലാവരേയും രക്ഷിക്കുകയും ചെയ്യുന്നു. അതായത്, ഓരോ ഘടകത്തിലെയും ചെറിയ പിശകുകൾ മുതൽ വ്യക്തിഗത ഡാറ്റാബേസ് ഇടപാടുകൾ വരെ അവയിൽ എല്ലാം അടങ്ങിയിരിക്കണം. അതിനാൽ പിശകിന് ശേഷം അത് മറ്റെങ്ങനെ പരിഹരിക്കാമെന്ന് ഉടൻ എഴുതി. ഇതെല്ലാം രണ്ട് മെഗാബൈറ്റുകളിൽ ഒതുങ്ങണം, ഇനി വേണ്ട. ഇത് വെറും വാചകം മാത്രമാണ്! ടെക്സ്റ്റ് ഫയലുകൾക്ക് പതിനായിരക്കണക്കിന് ജിഗാബൈറ്റുകൾ എടുക്കാൻ കഴിയില്ല, ഞാൻ അത് എവിടെയോ കേട്ടു!

അങ്ങനെ രേഖകൾ

യഥാർത്ഥ ലോകത്ത്, ലോഗുകൾ ഡയഗ്നോസ്റ്റിക് വിവരങ്ങളുടെ ഒരു ആർക്കൈവ് മാത്രമാണ്. അവിടെ എന്താണ് സംഭരിക്കേണ്ടത്, സംഭരണത്തിനായി വിവരങ്ങൾ എവിടെ നിന്ന് ലഭിക്കും, അത് എത്ര വിശദമായിരിക്കണം, ഡവലപ്പർമാർ സ്വയം തീരുമാനിക്കണം. ഓൺ / ഓഫ് ലെവലിന്റെ രേഖകൾ സൂക്ഷിക്കുന്നതിലൂടെ ആരെങ്കിലും മിനിമലിസത്തിന്റെ പാത പിന്തുടരുന്നു, ആരെങ്കിലും അവർക്ക് എത്തിച്ചേരാനാകുന്നതെല്ലാം ഉത്സാഹത്തോടെ റാക്ക് ചെയ്യുന്നു. ലോഗിംഗ് ലെവൽ എന്ന് വിളിക്കപ്പെടുന്നവ തിരഞ്ഞെടുക്കാനുള്ള കഴിവുള്ള ഒരു ഇന്റർമീഡിയറ്റ് ഓപ്ഷനും ഉണ്ടെങ്കിലും, നിങ്ങൾ എത്ര വിശദമായ വിവരങ്ങൾ സംഭരിക്കാൻ ആഗ്രഹിക്കുന്നുവെന്നും നിങ്ങൾക്ക് എത്ര അധിക ഡിസ്ക് സ്പേസ് ഉണ്ടെന്നും നിങ്ങൾ തന്നെ സൂചിപ്പിക്കുമ്പോൾ =) VBR-ന് അത്തരം ആറ് ലെവലുകൾ ഉണ്ട്. കൂടാതെ, എന്നെ വിശ്വസിക്കൂ, നിങ്ങളുടെ ഡിസ്കിൽ ശൂന്യമായ ഇടമുള്ള ഏറ്റവും വിശദമായ ലോഗിംഗിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നില്ല.

നന്നായി. എന്താണ് സംരക്ഷിക്കേണ്ടതെന്ന് ഞങ്ങൾ ഏകദേശം മനസ്സിലാക്കി, പക്ഷേ നിയമാനുസൃതമായ ഒരു ചോദ്യം ഉയർന്നുവരുന്നു: ഈ വിവരങ്ങൾ എവിടെ നിന്ന് ലഭിക്കും? തീർച്ചയായും, ഞങ്ങളുടെ ആന്തരിക പ്രക്രിയകൾ വഴി സ്വയം ലോഗിൻ ചെയ്യുന്നതിനുള്ള ഇവന്റുകളുടെ ഭാഗമാണ് ഞങ്ങൾ. എന്നാൽ ബാഹ്യ പരിതസ്ഥിതിയുമായി ഒരു ഇടപെടൽ ഉണ്ടാകുമ്പോൾ എന്തുചെയ്യണം? ഊന്നുവടികളുടെയും സൈക്കിളുകളുടെയും നരകത്തിലേക്ക് വഴുതിവീഴാതിരിക്കാൻ, വീം ഇതിനകം കണ്ടുപിടിച്ച കണ്ടുപിടുത്തങ്ങൾ കണ്ടുപിടിക്കുന്നില്ല. ഒരു റെഡിമെയ്ഡ് API, ബിൽറ്റ്-ഇൻ ഫംഗ്‌ഷൻ, ലൈബ്രറി മുതലായവ ഉള്ളപ്പോഴെല്ലാം, ഞങ്ങളുടെ കോൺട്രാപ്‌ഷനുകൾ വേലിയിറക്കാൻ തുടങ്ങുന്നതിനുമുമ്പ് ഞങ്ങൾ റെഡിമെയ്ഡ് ഓപ്ഷനുകൾക്ക് മുൻഗണന നൽകും. രണ്ടാമത്തേതും മതിയാണെങ്കിലും. അതിനാൽ, ലോഗുകൾ വിശകലനം ചെയ്യുമ്പോൾ, പിശകുകളുടെ സിംഹഭാഗവും മൂന്നാം-കക്ഷി API-കൾ, സിസ്റ്റം കോളുകൾ, മറ്റ് ലൈബ്രറികൾ എന്നിവയിൽ നിന്നുള്ള സന്ദേശങ്ങളിലാണ് വരുന്നതെന്ന് മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ്. ഈ സാഹചര്യത്തിൽ, ഈ പിശകുകൾ ലോഗ് ഫയലുകളിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നതിൽ VBR-ന്റെ പങ്ക് വരുന്നു. ഏത് വരി ആരിൽ നിന്നാണെന്നും ഈ “ആരാണ്” ഇതിന് ഉത്തരവാദികളെന്നും മനസിലാക്കാൻ പഠിക്കുക എന്നതാണ് ഉപയോക്താവിന്റെ പ്രധാന ദൌത്യം. അതിനാൽ VBR ലോഗിൽ നിന്നുള്ള ഒരു പിശക് കോഡ് നിങ്ങളെ ഒരു MSDN പേജിലേക്ക് കൊണ്ടുപോകുകയാണെങ്കിൽ, അത് ശരിയും ശരിയുമാണ്.

ഞങ്ങൾ നേരത്തെ സമ്മതിച്ചതുപോലെ: വീം എന്നത് SQL അടിസ്ഥാനമാക്കിയുള്ള ഒരു ആപ്ലിക്കേഷനാണ്. ഇതിനർത്ഥം എല്ലാ ക്രമീകരണങ്ങളും എല്ലാ വിവരങ്ങളും സാധാരണ പ്രവർത്തനത്തിന് മാത്രം ആവശ്യമായ എല്ലാം - എല്ലാം അതിന്റെ ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്നു എന്നാണ്. അതിനാൽ ലളിതമായ സത്യം: ലോഗുകളിൽ ഇല്ലാത്തത് മിക്കവാറും ഡാറ്റാബേസിൽ ആയിരിക്കും. എന്നാൽ ഇതൊരു സിൽവർ ബുള്ളറ്റല്ല: ചില കാര്യങ്ങൾ വീം ഘടകങ്ങളുടെ പ്രാദേശിക ലോഗുകളിലോ അതിന്റെ ഡാറ്റാബേസിലോ ഇല്ല. അതിനാൽ, ഹോസ്റ്റ് ലോഗുകൾ, ലോക്കൽ മെഷീന്റെ ലോഗുകൾ, ബാക്കപ്പ്, പുനഃസ്ഥാപിക്കൽ പ്രക്രിയയിൽ ഉൾപ്പെട്ടിരിക്കുന്ന എല്ലാറ്റിന്റെയും ലോഗുകൾ എന്നിവ എങ്ങനെ പഠിക്കണമെന്ന് നിങ്ങൾ പഠിക്കേണ്ടതുണ്ട്. ആവശ്യമായ വിവരങ്ങൾ എവിടെയും ലഭ്യമല്ല എന്നതും സംഭവിക്കുന്നു. അതാണ് വഴി. 

അത്തരം API-കളുടെ ചില ഉദാഹരണങ്ങൾ

ഈ ലിസ്റ്റ് അസാധാരണമായി പൂർണ്ണമാകാൻ ലക്ഷ്യമിടുന്നില്ല, അതിനാൽ അതിൽ പരമമായ സത്യം അന്വേഷിക്കേണ്ട ആവശ്യമില്ല. ഞങ്ങളുടെ ഉൽപ്പന്നങ്ങളിൽ ഉപയോഗിക്കുന്ന ഏറ്റവും സാധാരണമായ മൂന്നാം കക്ഷി API-കളും സാങ്കേതികവിദ്യകളും കാണിക്കുക മാത്രമാണ് ഇതിന്റെ ഉദ്ദേശ്യം.

ആരംഭിക്കാം വിഎംവെയർ. 

പട്ടികയിൽ ഒന്നാമതായിരിക്കും vSphere API. പ്രാമാണീകരണം, ശ്രേണി വായിക്കൽ, സ്നാപ്പ്ഷോട്ടുകൾ സൃഷ്‌ടിക്കുന്നതിനും ഇല്ലാതാക്കുന്നതിനും, മെഷീനുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ അഭ്യർത്ഥിക്കുന്നതിനും (വളരെയധികം) കൂടുതൽ കാര്യങ്ങൾക്കും ഉപയോഗിക്കുന്നു. പരിഹാരത്തിന്റെ പ്രവർത്തനം വളരെ വിശാലമാണ്, അതിനാൽ പതിപ്പിനായി എനിക്ക് VMware vSphere API റഫറൻസ് ശുപാർശ ചെയ്യാൻ കഴിയും 5.5 и 6.0. കൂടുതൽ നിലവിലെ പതിപ്പുകൾക്കായി, എല്ലാം ഗൂഗിൾ ചെയ്തതാണ്.

VIX API. ഹൈപ്പർവൈസറിന്റെ ബ്ലാക്ക് മാജിക്, അതിനായി പ്രത്യേകം ഉണ്ട് പിശക് പട്ടിക. നെറ്റ്‌വർക്കിലൂടെ ഫയലുകളിലേക്ക് കണക്‌റ്റ് ചെയ്യാതെ ഹോസ്റ്റിലെ ഫയലുകളുമായി പ്രവർത്തിക്കുന്നതിനുള്ള VMware API. മികച്ച ആശയവിനിമയ ചാനൽ ഇല്ലാത്ത ഒരു മെഷീനിൽ നിങ്ങൾക്ക് ഒരു ഫയൽ ഇടേണ്ടിവരുമ്പോൾ അവസാന ആശ്രയം. ഫയൽ വലുതായിരിക്കുകയും ഹോസ്റ്റ് ലോഡ് ചെയ്യുകയും ചെയ്താൽ അത് വേദനയും കഷ്ടപ്പാടുമാണ്. എന്നാൽ ഇവിടെ നിയമം 56,6 Kb / s പോലും 0 Kb / s എന്നതിനേക്കാൾ മികച്ചതാണ്. ഹൈപ്പർ-വിയിൽ, ഇതിനെ പവർഷെൽ ഡയറക്റ്റ് എന്ന് വിളിക്കുന്നു. എന്നാൽ അത് മുമ്പ് മാത്രമായിരുന്നു

vSpehere വെബ് സേവനങ്ങൾ API vSphere 6.0 മുതൽ ആരംഭിക്കുന്നു (ഏകദേശം, ഈ API ആദ്യമായി പതിപ്പ് 5.5-ൽ അവതരിപ്പിച്ചതിനാൽ) ഇത് അതിഥി മെഷീനുകളിൽ പ്രവർത്തിക്കാൻ ഉപയോഗിക്കുന്നു, കൂടാതെ മിക്കവാറും എല്ലായിടത്തും VIX മാറ്റിസ്ഥാപിച്ചു. വാസ്തവത്തിൽ, ഇത് vSphere കൈകാര്യം ചെയ്യുന്നതിനുള്ള മറ്റൊരു API ആണ്. താൽപ്പര്യമുള്ളവർക്ക്, ഞാൻ പഠിക്കാൻ ശുപാർശ ചെയ്യുന്നു നല്ലത് മാനുവൽ. 

വി.ഡി.ഡി.കെ (വെർച്വൽ ഡിസ്ക് ഡെവലപ്മെന്റ് കിറ്റ്). ഇതിൽ ഭാഗികമായി ചർച്ച ചെയ്യപ്പെട്ട ഗ്രന്ഥശാല ലേഖനം. വെർച്വൽ ഡിസ്കുകൾ വായിക്കാൻ ഉപയോഗിക്കുന്നു. ഒരു കാലത്ത് ഇത് VIX ന്റെ ഭാഗമായിരുന്നു, എന്നാൽ കാലക്രമേണ അത് ഒരു പ്രത്യേക ഉൽപ്പന്നത്തിലേക്ക് മാറ്റി. എന്നാൽ ഒരു അവകാശി എന്ന നിലയിൽ, ഇത് VIX-ന്റെ അതേ പിശക് കോഡുകൾ ഉപയോഗിക്കുന്നു. എന്നാൽ ചില കാരണങ്ങളാൽ, SDK-യിൽ തന്നെ ഈ പിശകുകളുടെ വിവരണമില്ല. അതിനാൽ, മറ്റ് കോഡുകളുമായുള്ള VDDK പിശകുകൾ ബൈനറിയിൽ നിന്ന് ദശാംശ കോഡിലേക്കുള്ള വിവർത്തനം മാത്രമാണെന്ന് അനുഭവപരമായി കണ്ടെത്തി. ഇതിൽ രണ്ട് ഭാഗങ്ങളുണ്ട് - ആദ്യ പകുതി സന്ദർഭത്തെക്കുറിച്ചുള്ള രേഖകളില്ലാത്ത വിവരങ്ങളാണ്, രണ്ടാം ഭാഗം പരമ്പരാഗത VIX / VDDK പിശകുകളാണ്. ഉദാഹരണത്തിന്, നമ്മൾ കാണുകയാണെങ്കിൽ:

VDDK error: 21036749815809.Unknown error

തുടർന്ന് ഞങ്ങൾ ഇത് ധൈര്യത്തോടെ ഹെക്‌സിലേക്ക് പരിവർത്തനം ചെയ്യുകയും 132200000001 നേടുകയും ചെയ്യുന്നു. 132200-ന്റെ വിവരമില്ലാത്ത തുടക്കം ഞങ്ങൾ നിരസിക്കുക, ബാക്കിയുള്ളത് ഞങ്ങളുടെ പിശക് കോഡ് ആയിരിക്കും (VDDK 1: അജ്ഞാത പിശക്). ഏറ്റവും സാധാരണമായ VDDK പിശകുകളെക്കുറിച്ച്, അടുത്തിടെ ഒരു പ്രത്യേക പിശക് ഉണ്ടായിരുന്നു ഒരു ലേഖനം.

ഇനി നമുക്ക് നോക്കാം വിൻ‌ഡോസ്.

ഇവിടെ, ഞങ്ങൾക്ക് ഏറ്റവും ആവശ്യമുള്ളതും പ്രധാനപ്പെട്ടതുമായ എല്ലാം സ്റ്റാൻഡേർഡിൽ കണ്ടെത്താനാകും ഇവന്റ് വ്യൂവർ. എന്നാൽ ഒരു ക്യാച്ച് ഉണ്ട്: ഒരു നീണ്ട പാരമ്പര്യമനുസരിച്ച്, വിൻഡോസ് പിശകിന്റെ മുഴുവൻ വാചകവും ലോഗ് ചെയ്യുന്നില്ല, പക്ഷേ അതിന്റെ നമ്പർ മാത്രം. ഉദാഹരണത്തിന്, പിശക് 5 "ആക്സസ് നിരസിച്ചു", 1722 "ആർപിസി സെർവർ ലഭ്യമല്ല", 10060 എന്നത് "കണക്ഷൻ സമയം കഴിഞ്ഞു". തീർച്ചയായും, നിങ്ങൾ ഏറ്റവും പ്രശസ്തരായവരെ ഓർക്കുന്നുവെങ്കിൽ അത് വളരെ മികച്ചതാണ്, പക്ഷേ ഇതുവരെ കാണാത്തവയുടെ കാര്യമോ? 

ജീവിതം തേൻ പോലെ തോന്നാതിരിക്കാൻ, പിശകുകൾ ഹെക്സാഡെസിമൽ രൂപത്തിൽ 0x8007 എന്ന പ്രിഫിക്‌സിനൊപ്പം സൂക്ഷിക്കുന്നു. ഉദാഹരണത്തിന്, 0x8007000e യഥാർത്ഥത്തിൽ 14 ആണ്, ഓർമ്മയില്ല. ഇത് എന്തിന്, ആർക്ക് വേണ്ടി ചെയ്തു എന്നത് ഇരുട്ടിൽ മൂടിക്കിടക്കുന്ന ഒരു രഹസ്യമാണ്. എന്നിരുന്നാലും, പിശകുകളുടെ ഒരു പൂർണ്ണമായ ലിസ്റ്റ് സൗജന്യമായും SMS ഇല്ലാതെയും ഡൗൺലോഡ് ചെയ്യാവുന്നതാണ് devcenter.

വഴിയിൽ, ചിലപ്പോൾ 0x8007 മാത്രമല്ല, മറ്റ് പ്രിഫിക്സുകളും ഉണ്ട്. അത്തരമൊരു സങ്കടകരമായ സാഹചര്യത്തിൽ, HRESULT (“ഫല ഹാൻഡിൽ”) മനസിലാക്കാൻ, നിങ്ങൾ കൂടുതൽ ആഴത്തിൽ പരിശോധിക്കേണ്ടതുണ്ട് പ്രമാണീകരണം ഡെവലപ്പർമാർക്കായി. സാധാരണ ജീവിതത്തിൽ, ഇത് ചെയ്യാൻ ഞാൻ നിങ്ങളെ ഉപദേശിക്കുന്നില്ല, എന്നാൽ നിങ്ങൾ പെട്ടെന്ന് ഭിത്തിയിൽ അമർത്തുകയോ ജിജ്ഞാസയോ ആണെങ്കിൽ, എന്തുചെയ്യണമെന്ന് ഇപ്പോൾ നിങ്ങൾക്കറിയാം.

എന്നാൽ മൈക്രോസോഫ്റ്റിലെ സഖാക്കൾ ഞങ്ങളോട് അൽപ്പം കരുണ കാണിക്കുകയും ലോകത്തിന് ഒരു പ്രയോജനം കാണിച്ചുകൊടുക്കുകയും ചെയ്തു ERR. ഗൂഗിൾ ഉപയോഗിക്കാതെ തന്നെ പിശക് കോഡുകൾ മനുഷ്യനിലേക്ക് വിവർത്തനം ചെയ്യാൻ കഴിയുന്ന കൺസോൾ സന്തോഷത്തിന്റെ ഒരു ചെറിയ ഭാഗമാണിത്. ഇത് ഇതുപോലെ പ്രവർത്തിക്കുന്നു.

C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"

നിയമാനുസൃതമായ ഒരു ചോദ്യം ഉയർന്നുവരുന്നു: എന്തുകൊണ്ടാണ് ഞങ്ങൾ ലോഗുകളിലേക്ക് ഡീക്രിപ്ഷൻ ഉടൻ എഴുതാത്തത്, പക്ഷേ ഈ നിഗൂഢ കോഡുകൾ ഉപേക്ഷിക്കുന്നത് എന്തുകൊണ്ട്? ഉത്തരം മൂന്നാം കക്ഷി ആപ്ലിക്കേഷനുകളിലാണ്. നിങ്ങൾ സ്വയം ചില WinAPI കോൾ വലിക്കുമ്പോൾ, അതിന്റെ പ്രതികരണം മനസ്സിലാക്കുന്നത് ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല, കാരണം ഇതിനായി ഒരു പ്രത്യേക WinAPI കോൾ പോലും ഉണ്ട്. എന്നാൽ ഇതിനകം സൂചിപ്പിച്ചതുപോലെ, പ്രതികരണങ്ങളിൽ മാത്രം ഞങ്ങൾക്ക് വരുന്നതെല്ലാം ഞങ്ങളുടെ ലോഗുകളിൽ പ്രവേശിക്കുന്നു. ഇവിടെ, ഇത് ഡീക്രിപ്റ്റ് ചെയ്യുന്നതിന്, ഒരാൾ ഈ ബോധ സ്ട്രീം നിരന്തരം നിരീക്ഷിക്കുകയും അതിൽ നിന്ന് വിൻഡോസ് പിശകുകളുള്ള ഭാഗങ്ങൾ പുറത്തെടുക്കുകയും അവയെ ഡീക്രിപ്റ്റ് ചെയ്യുകയും തിരികെ ഒട്ടിക്കുകയും വേണം. നമുക്ക് സത്യസന്ധത പുലർത്താം, ഏറ്റവും ആവേശകരമായ പ്രവർത്തനമല്ല.

വിൻഡോസ് ഫയൽ മാനേജ്മെന്റ് API ഫയലുകളിൽ പ്രവർത്തിക്കുമ്പോൾ സാധ്യമായ എല്ലാ വഴികളിലും ഉപയോഗിക്കുന്നു. ഫയലുകൾ സൃഷ്ടിക്കുക, ഇല്ലാതാക്കുക, എഴുതാൻ തുറക്കുക, ആട്രിബ്യൂട്ടുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുക, അങ്ങനെ അങ്ങനെ പലതും.

മുകളിൽ സൂചിപ്പിച്ച പവർഷെൽ ഡയറക്റ്റ് ഹൈപ്പർ-വി ലോകത്തിലെ VIX API യുടെ അനലോഗ് ആയി. നിർഭാഗ്യവശാൽ, അത്ര അയവുള്ളതല്ല: പ്രവർത്തനത്തിൽ ധാരാളം നിയന്ത്രണങ്ങൾ, ഹോസ്റ്റിന്റെ എല്ലാ പതിപ്പുകളിലും ഇത് പ്രവർത്തിക്കില്ല, എല്ലാ അതിഥികൾക്കും അല്ല.

ആർ‌പി‌സി (റിമോട്ട് പ്രൊസീജർ കോൾ) RPC-യുമായി ബന്ധപ്പെട്ട പിശകുകൾ കാണാത്ത ഒരു വ്യക്തി പോലും വിൻഡോസിൽ പ്രവർത്തിച്ചിട്ടുണ്ടെന്ന് ഞാൻ കരുതുന്നില്ല. ജനപ്രിയമായ തെറ്റിദ്ധാരണ ഉണ്ടായിരുന്നിട്ടും, ഇത് ഒരൊറ്റ പ്രോട്ടോക്കോൾ അല്ല, മറിച്ച് നിരവധി പാരാമീറ്ററുകൾ തൃപ്തിപ്പെടുത്തുന്ന ഏതെങ്കിലും ക്ലയന്റ്-സെർവർ പ്രോട്ടോക്കോൾ ആണ്. എന്നിരുന്നാലും, ഞങ്ങളുടെ ലോഗുകളിൽ ഒരു RPC പിശക് ഉണ്ടെങ്കിൽ, 90% സമയവും അത് DCOM (ഡിസ്ട്രിബ്യൂട്ടഡ് കോംപോണന്റ് ഒബ്ജക്റ്റ് മോഡൽ) ന്റെ ഭാഗമായ Microsoft RPC-യിൽ നിന്നുള്ള പിശകായിരിക്കും. നെറ്റിൽ ഈ വിഷയത്തെക്കുറിച്ചുള്ള ഒരു വലിയ ഡോക്യുമെന്റേഷൻ നിങ്ങൾക്ക് കണ്ടെത്താൻ കഴിയും, എന്നാൽ അതിന്റെ സിംഹഭാഗവും കാലഹരണപ്പെട്ടതാണ്. എന്നാൽ വിഷയം പഠിക്കാൻ തീവ്രമായ ആഗ്രഹമുണ്ടെങ്കിൽ, എനിക്ക് ലേഖനങ്ങൾ ശുപാർശ ചെയ്യാൻ കഴിയും എന്താണ് RPC?, എങ്ങനെ ആർപിസി വർക്ക്സ് നീണ്ട പട്ടികയും RPC പിശകുകൾ.

ഞങ്ങളുടെ ലോഗുകളിലെ RPC പിശകുകളുടെ പ്രധാന കാരണങ്ങൾ VBR ഘടകങ്ങൾ (സെർവർ > പ്രോക്സി, ഉദാഹരണത്തിന്) തമ്മിൽ ആശയവിനിമയം നടത്താനുള്ള പരാജയപ്പെട്ട ശ്രമങ്ങളും മിക്കപ്പോഴും ആശയവിനിമയ പ്രശ്നങ്ങൾ മൂലവുമാണ്.

എല്ലാ ടോപ്പുകളിലും ടോപ്പ് ടോപ്പ് പിശകാണ് RPC സെർവർ ലഭ്യമല്ല (1722). ലളിതമായി പറഞ്ഞാൽ, ക്ലയന്റിന് സെർവറുമായി ഒരു കണക്ഷൻ സ്ഥാപിക്കാൻ കഴിഞ്ഞില്ല. എങ്ങനെ, എന്തുകൊണ്ട് - ഒരൊറ്റ ഉത്തരമില്ല, പക്ഷേ സാധാരണയായി ഇത് പ്രാമാണീകരണത്തിലോ പോർട്ട് 135-ലേക്കുള്ള നെറ്റ്‌വർക്ക് ആക്‌സസിലോ ഉള്ള ഒരു പ്രശ്‌നമാണ്. രണ്ടാമത്തേത് ഡൈനാമിക് പോർട്ട് അസൈൻമെന്റുള്ള ഇൻഫ്രാസ്ട്രക്ചറുകൾക്ക് സാധാരണമാണ്. ഈ വിഷയത്തിൽ, പോലും ഉണ്ട് പ്രത്യേക HF. മൈക്രോസോഫ്റ്റിനും ഉണ്ട് വലിയ ഗൈഡ് പരാജയത്തിന്റെ കാരണം കണ്ടെത്താൻ.

ഏറ്റവും ജനപ്രിയമായ രണ്ടാമത്തെ പിശക്: എൻഡ്‌പോയിന്റ് മാപ്പറിൽ നിന്ന് കൂടുതൽ എൻഡ്‌പോയിന്റുകൾ ലഭ്യമല്ല (1753). RPC ക്ലയന്റ് അല്ലെങ്കിൽ സെർവർ സ്വയം ഒരു പോർട്ട് നൽകുന്നതിൽ പരാജയപ്പെട്ടു. അവസാനിച്ച ഇടുങ്ങിയ ശ്രേണിയിൽ നിന്നുള്ള പോർട്ടുകൾ ഡൈനാമിക് ആയി അനുവദിക്കുന്നതിനായി സെർവർ (ഞങ്ങളുടെ കാര്യത്തിൽ, ഗസ്റ്റ് മെഷീൻ) കോൺഫിഗർ ചെയ്തിരിക്കുമ്പോൾ സാധാരണയായി സംഭവിക്കുന്നു. നിങ്ങൾ ക്ലയന്റ് ഭാഗത്ത് നിന്ന് ലോഗിൻ ചെയ്യുകയാണെങ്കിൽ (ഞങ്ങളുടെ കാര്യത്തിൽ, VBR സെർവർ), ഇതിനർത്ഥം ഞങ്ങളുടെ VeeamVssAgent ഒന്നുകിൽ ആരംഭിച്ചിട്ടില്ല അല്ലെങ്കിൽ ഒരു RPC ഇന്റർഫേസായി രജിസ്റ്റർ ചെയ്തിട്ടില്ല എന്നാണ്. ഈ വിഷയത്തിലും ഉണ്ട് പ്രത്യേക HF.

ശരി, മികച്ച 3 RPC പിശകുകൾ പൂർത്തിയാക്കാൻ, RPC ഫംഗ്‌ഷൻ കോൾ പരാജയപ്പെട്ടു (1726) എന്ന് ഓർക്കുക. കണക്ഷൻ സ്ഥാപിച്ചിട്ടുണ്ടെങ്കിൽ ദൃശ്യമാകും, എന്നാൽ RPC അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നില്ല. ഉദാഹരണത്തിന്, VSS-ന്റെ നിലയെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഞങ്ങൾ അഭ്യർത്ഥിക്കുന്നു (പെട്ടെന്ന് ഇപ്പോൾ അവിടെ ഒരു നിഴൽ ഖനി നിർമ്മിക്കപ്പെടുന്നു, ഞങ്ങൾ കയറാൻ ശ്രമിക്കുന്നു), ഞങ്ങൾക്ക് മറുപടിയായി, നിശബ്ദത പാലിക്കുക, അവഗണിക്കുക.

വിൻഡോസ് ടേപ്പ് ബാക്കപ്പ് API ടേപ്പ് ലൈബ്രറികളിലോ ഡ്രൈവുകളിലോ പ്രവർത്തിക്കേണ്ടത് ആവശ്യമാണ്. ഞാൻ തുടക്കത്തിൽ സൂചിപ്പിച്ചതുപോലെ: ഞങ്ങളുടെ സ്വന്തം ഡ്രൈവറുകൾ എഴുതുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമില്ല, തുടർന്ന് ഓരോ ഉപകരണത്തിന്റെയും പിന്തുണയോടെ കഷ്ടപ്പെടുന്നു. അതിനാൽ, വിമ്മിന് സ്വന്തമായി ഡ്രൈവർമാരില്ല. എല്ലാം ഒരു സ്റ്റാൻഡേർഡ് API വഴി, അതിന്റെ പിന്തുണ ഹാർഡ്‌വെയർ വെണ്ടർമാർ തന്നെ നടപ്പിലാക്കുന്നു. വളരെ കൂടുതൽ യുക്തിസഹമാണ്, അല്ലേ?

SMB / CIFS CIFS (കോമൺ ഇന്റർനെറ്റ് ഫയൽ സിസ്റ്റം) എന്നത് SMB-യുടെ (സെർവർ മെസേജ് ബ്ലോക്ക്) വെറുമൊരു സ്വകാര്യ പതിപ്പാണെന്ന് എല്ലാവരും ഓർക്കുന്നില്ലെങ്കിലും, ശീലമില്ലാതെ, എല്ലാവരും അവ ഓരോന്നായി എഴുതുന്നു. അതുകൊണ്ട് ഈ ആശയങ്ങളെ സാമാന്യവത്കരിക്കുന്നതിൽ തെറ്റില്ല. സാംബ ഇതിനകം ഒരു LinuxUnix നടപ്പിലാക്കലാണ്, അതിന് അതിന്റേതായ പ്രത്യേകതകൾ ഉണ്ട്, പക്ഷേ ഞാൻ പിന്മാറുന്നു. ഇവിടെ എന്താണ് പ്രധാനം: UNC പാതയിലേക്ക് (സെർവർഡയറക്‌ടറി) എന്തെങ്കിലും എഴുതാൻ Veeam ആവശ്യപ്പെടുമ്പോൾ, പന്തിൽ എഴുതാൻ സെർവർ mup, mrxsmb എന്നിവയുൾപ്പെടെയുള്ള ഫയൽ സിസ്റ്റം ഡ്രൈവറുകളുടെ ശ്രേണി ഉപയോഗിക്കുന്നു. അതനുസരിച്ച്, ഈ ഡ്രൈവറുകളും പിശകുകൾ സൃഷ്ടിക്കും.

ഇല്ലാതെ പറ്റില്ല വിൻസോക്ക് API. നെറ്റ്‌വർക്കിലൂടെ എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, വിബിആർ വിൻസോക്ക് എന്നറിയപ്പെടുന്ന വിൻഡോസ് സോക്കറ്റ് എപിഐ വഴിയാണ് പ്രവർത്തിക്കുന്നത്. ലോഗിൽ ഒരു കൂട്ടം IP:Port കാണുകയാണെങ്കിൽ, ഇതാണ്. ഔദ്യോഗിക ഡോക്യുമെന്റേഷനിൽ സാധ്യമായ ഒരു നല്ല ലിസ്റ്റ് ഉണ്ട് തെറ്റുകൾ.

മുകളിൽ സൂചിപ്പിച്ച WMI (Windows Management Instrumentation) എന്നത് Windows ലോകത്തിലെ എല്ലാവരെയും എല്ലാവരെയും നിയന്ത്രിക്കുന്നതിനുള്ള ഒരുതരം സർവശക്തമായ API ആണ്. ഉദാഹരണത്തിന്, ഹൈപ്പർ-വിയിൽ പ്രവർത്തിക്കുമ്പോൾ, ഹോസ്റ്റിനുള്ള മിക്കവാറും എല്ലാ അഭ്യർത്ഥനകളും അതിലൂടെ കടന്നുപോകുന്നു. ഒറ്റവാക്കിൽ പറഞ്ഞാൽ, ഈ കാര്യം തികച്ചും മാറ്റാനാകാത്തതും അതിന്റെ കഴിവുകളിൽ വളരെ ശക്തവുമാണ്. എവിടെ, എന്താണ് തകർന്നതെന്ന് കണ്ടെത്താൻ സഹായിക്കുന്നതിനുള്ള ശ്രമത്തിൽ, അന്തർനിർമ്മിത WBEMtest.exe ടൂൾ വളരെയധികം സഹായിക്കുന്നു.

ലിസ്റ്റിൽ അവസാനത്തേത്, പക്ഷേ ഒരു തരത്തിലും പ്രാധാന്യമില്ല - വി.എസ്.എസ് (വോളിയം ഷാഡോ സ്റ്റോറേജ്). എത്രയോ ഡോക്യുമെന്റേഷനുകൾ എഴുതിയിരിക്കുന്നതുപോലെ ഈ വിഷയം വിവരണാതീതവും നിഗൂഢവുമാണ്. നിഴൽ പകർപ്പ് ഒരു പ്രത്യേക തരം സ്നാപ്പ്ഷോട്ട് ആയിട്ടാണ് ഏറ്റവും ലളിതമായി മനസ്സിലാക്കുന്നത്, സാരാംശത്തിൽ അത്. അദ്ദേഹത്തിന് നന്ദി, നിങ്ങൾക്ക് VMware-ലും ഹൈപ്പർ-V-യിലെ മിക്കവാറും എല്ലാ കാര്യങ്ങളും ആപ്ലിക്കേഷൻ-സ്ഥിരതയുള്ള ബാക്കപ്പുകൾ ഉണ്ടാക്കാം. വിഎസ്‌എസിൽ കുറച്ച് ഞെക്കിപ്പിടിച്ച് ഒരു പ്രത്യേക ലേഖനം തയ്യാറാക്കാൻ എനിക്ക് പദ്ധതിയുണ്ട്, എന്നാൽ ഇപ്പോൾ നിങ്ങൾക്ക് വായിക്കാൻ ശ്രമിക്കാം ഈ വിവരണം. ശ്രദ്ധിക്കുക, കാരണം. ഒരു ഫ്ലാഷിൽ VSS മനസ്സിലാക്കാൻ ശ്രമിക്കുന്നത് മസ്തിഷ്ക ക്ഷതത്തിലേക്ക് നയിച്ചേക്കാം.

ഇതിൽ, ഒരുപക്ഷേ, നമുക്ക് നിർത്താം. പൂർത്തിയാക്കിയ ഏറ്റവും അടിസ്ഥാനപരമായ കാര്യങ്ങൾ വിശദീകരിക്കാനുള്ള ചുമതല ഞാൻ പരിഗണിക്കുന്നു, അതിനാൽ അടുത്ത അധ്യായത്തിൽ ഞങ്ങൾ ഇതിനകം ലോഗുകൾ നോക്കും. എന്നാൽ നിങ്ങൾക്ക് എന്തെങ്കിലും ചോദ്യങ്ങളുണ്ടെങ്കിൽ, അഭിപ്രായങ്ങളിൽ അവരോട് ചോദിക്കാൻ മടിക്കേണ്ടതില്ല.

അവലംബം: www.habr.com