Azure VM-ൽ RRAS പിന്തുണയ്ക്കുന്നില്ല: രൂപകൽപ്പനയ്ക്ക് മുമ്പ് പരിശോധിക്കുക

നിങ്ങൾ പോർട്ടൽ തുറക്കുന്നു, Windows Server 2022 ഒരു സബ്നെറ്റിലേക്ക് വിന്യസിക്കുന്നു, Remote Access റോൾ വൃത്തിയായി ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ആ ക്രമം ഇൻസ്റ്റാളർ പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, Microsoft ഈ കോൺഫിഗറേഷനെ പിന്തുണയ്ക്കുന്നു എന്നല്ല. Azure വെർച്വൽ മെഷീനുകൾക്കായി പ്രസിദ്ധീകരിച്ച സെർവർ സോഫ്റ്റ്വെയർ പിന്തുണാ മാർഗ്ഗനിർദ്ദേശം RRAS-നെ Azure VM-ൽ പിന്തുണയ്ക്കാത്ത Windows Server സവിശേഷതകളിൽ ഉൾപ്പെടുത്തുന്നു, ഇത് പ്രശ്നപരിഹാര വിശദാംശമല്ല, വാസ്തുവിദ്യാ തീരുമാനമാണ്. ഉയരുന്ന ടണൽ വിന്യാസത്തെ പിന്തുണാ അതിർത്തിക്കുള്ളിലേക്ക് നീക്കുന്നില്ല.

താഴെയുള്ള മാർഗ്ഗനിർദ്ദേശം പിന്തുണാ പേജിൽ ആരംഭിച്ച് ആവശ്യകതകളിലേക്കും പകരം ഓപ്ഷനുകളിലേക്കും നീങ്ങുന്നു.

ലാബിലല്ല, പിന്തുണാ പേജിൽ നിന്ന് ആരംഭിക്കുക

എന്തെങ്കിലും അളക്കുന്നതിന് മുമ്പ് Azure VM പിന്തുണാ മാർഗ്ഗനിർദ്ദേശം വായിക്കുക. ഇത് Windows Server-നെ ഒരു വിഭജിക്കാത്ത ബ്ലോക്കായി കാണുന്നതിനുപകരം പിന്തുണയുള്ള ഉൽപ്പന്നങ്ങൾ, റോളുകൾ, സവിശേഷതകൾ എന്നിവ വേർതിരിക്കുന്നു. നിങ്ങളുടെ ഉദ്ദേശിച്ച ജോലിഭാരം യഥാർത്ഥത്തിൽ ഏത് വരിയിലാണ് വരുന്നതെന്ന് ശ്രദ്ധിക്കുക, കാരണം കൺസോളിൽ ബന്ധപ്പെട്ടതായി കാണുന്ന രണ്ട് ഘടകങ്ങൾ വ്യത്യസ്ത വരികളിൽ ആകാം.

പേജ് തുറന്നിരിക്കുമ്പോൾ തന്നെ ഡിസൈൻ രേഖയിൽ ഉദ്ധരണി എഴുതുക. പിന്തുണാ നില ഒരു ഉറവിടമുള്ള വസ്തുതയാണ്, അത് ഉദ്ധരിക്കാൻ കഴിയാത്ത ഡിസൈൻ അവലോകനത്തെ ഡെമോയുള്ളയാൾ വാദത്തിൽ തോൽപ്പിക്കും.

OS പിന്തുണയെ റോൾ, സവിശേഷത പിന്തുണയിൽ നിന്ന് വേർതിരിക്കുക

അതേ മാർഗ്ഗനിർദ്ദേശം Network Policy and Access Services-നെ പിന്തുണയുള്ള റോളുകളിൽ പട്ടികപ്പെടുത്തുമ്പോൾ RRAS-നെ പ്രത്യേകമായി പിന്തുണയില്ലാത്തതായി പട്ടികപ്പെടുത്തുന്നു. ആ രണ്ട് എൻട്രികൾ വ്യത്യസ്ത കാര്യങ്ങൾ വിവരിക്കുന്നു, അവയെ “റിമോട്ട് ആക്സസ് പിന്തുണയ്ക്കുന്നു” എന്ന് ഒന്നാക്കുന്നതാണ് തെറ്റായ വായനയുടെ അടിസ്ഥാനത്തിൽ പ്രോജക്ട് അംഗീകരിക്കപ്പെടുന്ന വഴി. ഓപ്പറേറ്റിംഗ് സിസ്റ്റം പിന്തുണയ്ക്കുന്നത് സ്വന്തം വരിയുള്ള ഒരു സവിശേഷതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

പരിമിതി ചിലപ്പോൾ ഉദ്ധരിക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയതാണ്. Azure VM-നുള്ളിൽ പ്രവർത്തിക്കുന്ന ആ സവിശേഷതയെക്കുറിച്ചാണ് ഇത്; സ്വകാര്യ നെറ്റ്വർക്കിന് Azure-ലേക്ക് കണക്റ്റ് ചെയ്യാൻ കഴിയില്ലെന്ന് ഇത് അർത്ഥമാക്കുന്നില്ല, RRAS എല്ലായിടത്തും പിന്തുണയ്ക്കുന്നില്ലെന്നും പറയുന്നില്ല. പാക്കറ്റുകൾ ശരിയായി കൈമാറുന്ന പഴയ ലാബ് പാക്കറ്റുകളെക്കുറിച്ചുള്ള തെളിവാണ്, പിന്തുണാ പ്രസ്താവനയെക്കുറിച്ചല്ല.

പ്രോജക്ടിന്റെ ബാക്കി കാലത്തേക്ക് ഈ രണ്ട് ചോദ്യങ്ങൾ വേർതിരിച്ച് നിർത്തുക: ഇത് പ്രവർത്തിക്കുന്നുണ്ടോ, ഇത് പിന്തുണയ്ക്കപ്പെടുന്നുണ്ടോ. ഓരോന്നിനും വ്യത്യസ്ത ഉത്തരങ്ങളും ചിലപ്പോൾ വ്യത്യസ്ത ഉത്തരവാദികളും വേണ്ടിവരും.

ഡിസൈൻ യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യണമെന്ന് എഴുതുക

പകരം തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് സൈറ്റ് പട്ടികയെ ഒരു ഉൽപ്പന്നത്തെ അളക്കാവുന്ന ആവശ്യകതകളാക്കി മാറ്റുക:

• ബ്രാഞ്ച് ഉപകരണങ്ങൾ ഇപ്പോൾ സംസാരിക്കുന്ന ടണൽ പ്രോട്ടോക്കോളുകൾ, ഏതെങ്കിലും സൈറ്റിന് ഡൈനാമിക് റൂട്ടിംഗ് ആവശ്യമുണ്ടോയെന്നും.
• വിദൂര പ്രിഫിക്സുകൾ, റൂട്ടിംഗിന് പകരം വിവർത്തനം ആവശ്യമുള്ള ഏതെങ്കിലും ഓവർലാപ്പിംഗ് വിലാസ ഇടം ഉൾപ്പെടെ.
• Azure-മായുള്ള റൂട്ട് കൈമാറ്റം, റൂട്ടിംഗ് ടേബിളിലെ ഓരോ എൻട്രിയുടെയും ഉടമ ആരെന്നത്.
• ഏറ്റവും തിരക്കുള്ള മണിക്കൂർ താങ്ങേണ്ട ത്രൂപുട്ടും കണക്ഷനുകളുടെ എണ്ണവും.
• സൈറ്റ് ഉടമകൾ സമ്മതിച്ച ഫെയിൽഓവർ പെരുമാറ്റം, നിങ്ങൾക്ക് നിർമ്മിക്കാൻ കഴിയുന്നത് മാത്രമല്ല.

NAT എന്നത് ഒഴിവാക്കപ്പെടുന്ന, തുടർന്ന് മുഴുവൻ ഡിസൈനും നിർണ്ണയിക്കുന്ന ഇനമാണ്. IPsec സ്ഥാപിക്കാൻ കഴിയുന്ന ഉപകരണം പകരം വയ്ക്കുന്ന RRAS വിന്യാസത്തിൽ നിന്ന് വ്യത്യസ്തമായി വിലാസങ്ങൾ വിവർത്തനം ചെയ്തേക്കാം, അത് ബ്രാഞ്ച് ഏത് വിലാസങ്ങളെ ഉറവിടമായി കാണുന്നു, നിങ്ങളുടെ ലോഗുകൾ എന്ത് രേഖപ്പെടുത്തുന്നു എന്നതിനെ മാറ്റുന്നു.

പട്ടിക നെറ്റ്വർക്ക് ഉടമകളുടെ അടുത്ത് കൊണ്ടുപോയി ഏതെങ്കിലും ഉൽപ്പന്ന ചർച്ചയ്ക്ക് മുമ്പ് സ്ഥിരീകരിക്കുക. അവ്യക്തമായ ആവശ്യകതകൾ ഓരോ വിൽപ്പനക്കാരൻ താരതമ്യത്തെയും മുൻഗണനാ തർക്കമാക്കി മാറ്റുന്നു.

ആ ആവശ്യകതകൾക്കെതിരെ പകരമുള്ളവ വിലയിരുത്തുക

Azure-ന്റെ മാനേജ്ഡ് കണക്റ്റിവിറ്റി സേവനങ്ങളും വിൽപ്പനക്കാർ പിന്തുണയ്ക്കുന്ന നെറ്റ്വർക്ക് വെർച്വൽ ഉപകരണങ്ങളും ഒരേ പട്ടികയ്ക്കെതിരെ സ്കോർ ചെയ്യണം. IPsec അവസാനിപ്പിക്കാൻ കഴിയുന്നു എന്ന കാരണത്താൽ മാത്രം അവയിലൊന്നും RRAS VM-ന്റെ നേരിട്ടുള്ള തുല്യമാണെന്ന് കരുതരുത്: NAT മാതൃകയും റൂട്ട് ഉടമസ്ഥതയും ഉയർന്ന ലഭ്യതയുടെ രൂപകൽപ്പനയും നിലവിലുള്ള സൈറ്റുകൾ എങ്ങനെ ബന്ധിപ്പിക്കുന്നു, അവയുടെ മറുപടികൾ എവിടേക്ക് മടങ്ങുന്നു എന്നത് നിർണ്ണയിക്കുന്നു. ഓരോ സ്ഥാനാർത്ഥിയെയും പേപ്പറിൽ പട്ടികയ്ക്കെതിരെ സ്കോർ ചെയ്ത് ഏത് ആവശ്യകതകൾ അത് പരാജയപ്പെടുത്തുന്നു എന്ന് എഴുതുക, കാരണം ആ കുറിപ്പാണ് തിരഞ്ഞെടുപ്പിനെ പിന്നീട് അവലോകനം ചെയ്യാവുന്നതാക്കുന്നത്.

രണ്ട് ഉപകരണ VM-കൾക്ക് മുന്നിലുള്ള ലോഡ് ബാലൻസർ അതിൽത്തന്നെ ഉയർന്ന ലഭ്യതയല്ല. അത് ഒരു ഫ്രണ്ട് എൻഡ് നൽകുന്നു, സമന്വയിപ്പിച്ച ടണൽ നിലയല്ല, ഓരോ സെഷനും വീഴ്ത്തുന്ന ഫെയിൽഓവർ ആരെങ്കിലും ബോധപൂർവം എടുക്കേണ്ട ഡിസൈൻ തിരഞ്ഞെടുപ്പാണ്. ഉപകരണ വിൽപ്പനക്കാരനോട് പിന്തുണയുള്ള HA പാറ്റേൺ എന്തെന്നും അത് സൈറ്റുകൾക്ക് വാഗ്ദാനം ചെയ്ത ലഭ്യതയുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്നും ചോദിക്കുക. ആ സൈറ്റുകൾ അതിനെ ആശ്രയിക്കുന്നതിന് മുമ്പ് ഫെയിൽഓവർ പരിശോധിക്കുക, നഷ്ടപ്പെട്ട ഓരോ സെഷനെയും അത്ഭുതമല്ല, കണ്ടെത്തലായി കാണുക.

ആവശ്യകത ശരിക്കും ലളിതമാകുമ്പോൾ — ഒരു സൈറ്റ്, ഒരു പ്രിഫിക്സ്, ഓവർലാപ്പ് ഇല്ല — മാനേജ്ഡ് സേവനം സാധാരണയായി പ്രവർത്തന ചെലവിൽ ജയിക്കുന്നു. വിവർത്തനവും ഡൈനാമിക് റൂട്ടിംഗും രണ്ടും കളിയിലുള്ളപ്പോൾ, ഉപകരണ പാത മാത്രം അനുയോജ്യമായിരിക്കാം, അത് പിന്തുണയില്ലാത്ത VM നിലനിർത്തുന്നതിനുപകരം നീണ്ട കുടിയേറ്റം ആസൂത്രണം ചെയ്യാനുള്ള കാരണമാണ്.

RRAS VM ഇപ്പോൾ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ

കണ്ടെത്തൽ അത് ഇല്ലാതാക്കാനുള്ള കാരണമല്ല. ആ VM സമാഹരിച്ച ആശ്രിതത്വങ്ങൾക്ക് ചുറ്റും മാറ്റം ആസൂത്രണം ചെയ്യുക: മറ്റ് സബ്നെറ്റുകൾ ആശ്രയിക്കുന്ന റൂട്ടുകൾ, ഉറവിട വിലാസങ്ങൾ മറയ്ക്കുന്ന NAT നിയമങ്ങൾ, മോണിറ്ററിംഗ് അതിന്റെ വിലാസത്തിൽ നിന്ന് പ്രതീക്ഷിക്കാൻ പഠിച്ചതെല്ലാം. പിന്തുണയുള്ള ലക്ഷ്യം അരികിൽ രൂപകൽപ്പന ചെയ്ത് സാധൂകരിക്കുമ്പോൾ ആവശ്യമായ റൂട്ടുകളും പരിശോധിച്ച വീണ്ടെടുക്കൽ പാതയും സംരക്ഷിക്കുക.

പിന്തുണയ്ക്കാനുള്ള കഴിവും സാങ്കേതിക രോഗനിർണ്ണയവും എപ്പോഴും വേറിട്ട കണ്ടെത്തലുകളായി നിർത്തുക. പിന്തുണയില്ലാത്ത ക്രമീകരണത്തിന് സാധാരണ റൂട്ടിംഗ് പിശകും ഉണ്ടാകാം, ആ പിശക് തിരുത്തുന്നത് അതിന്റെ പിന്തുണാ നില മാറ്റുന്നില്ല. രണ്ട് പ്രസ്താവനകളും റിപ്പോർട്ടിൽ ഉള്ളതാണ്, ഒന്നും മറ്റൊന്നിനെ റദ്ദാക്കുന്നില്ല.

പിന്തുണാ ഉദ്ധരണി, ആവശ്യകതാ പട്ടിക, തിരഞ്ഞെടുത്ത പകരം, കട്ട്ഓവർ ക്രമം എന്നിവ രേഖപ്പെടുത്തി മാർഗ്ഗനിർദ്ദേശം അവസാനിപ്പിക്കുക. ഓഡിറ്റർക്കോ പുതിയ ടീം അംഗത്തിനോ ആദ്യം ചോദിക്കേണ്ടത് ഈ നാല് കാര്യങ്ങളാണ്.