നിരവധി Google Cloud പ്രോജക്ടുകൾ, ഒരു ഹൈബ്രിഡ് VPN? ആദ്യം തീരുമാനിക്കുക
പങ്കിട്ട VPC, പിയറിംഗ്, ഒരു കണക്റ്റിവിറ്റി ഹബ് എന്നിവ വ്യത്യസ്ത ഉടമസ്ഥതാ ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. ഓരോ പ്രോജക്ടിനും ഒരു VPN വിന്യസിക്കുന്നതിന് മുമ്പ് നെറ്റ്വർക്ക് അതിർത്തി തിരഞ്ഞെടുക്കുക.
നിരവധി Google Cloud പ്രോജക്ടുകൾക്ക് ഹൈബ്രിഡ് ആക്സസ് ആവശ്യമുള്ളപ്പോൾ, ഓരോ പ്രോജക്ടിനും ഒരു VPN എന്നതാണ് സഹജവാസന, അത് ഏതാണ്ട് എപ്പോഴും തെറ്റായ രൂപമാണ്. പ്രോജക്ട് ഉടമസ്ഥതയും പാക്കറ്റ് റൂട്ടിംഗും ബന്ധപ്പെട്ടതും എന്നാൽ വ്യത്യസ്തവുമായ വിഷയങ്ങളാണ്, ഉപയോഗപ്രദമായ ആർക്കിടെക്ചർ ആവശ്യമായ ഭരണപരമായ അതിർത്തികൾ നിലനിർത്തിക്കൊണ്ട് ഉദ്ദേശിച്ച പ്രിഫിക്സുകൾക്ക് ഓഫീസിലേക്കോ ഡാറ്റാ സെന്ററിലേക്കോ ഒരു ഉദ്ദേശപൂർവമായ വഴി നൽകുന്നു. ഈ പരിശോധനകൾ നിങ്ങൾ യഥാർത്ഥത്തിൽ ഏത് നെറ്റ്വർക്ക് മോഡലാണ് ആഗ്രഹിക്കുന്നതെന്ന്, വീണ്ടും ജോലി ഒഴിവാക്കുന്ന ക്രമത്തിൽ തീരുമാനിക്കുന്നു. ഓരോന്നിനും ചർച്ച നേരത്തെ അവസാനിപ്പിക്കാം, അതാണ് പ്രധാന കാര്യം.
പ്രോജക്ട് അതിർത്തിക്ക് സ്വയമേവ അതിന്റേതായ ടണൽ ആവശ്യമില്ല.
പങ്കിട്ട വസ്തു നെറ്റ്വർക്ക് ആണോ എന്ന് പരിശോധിക്കുക
ഉടമസ്ഥതയെക്കുറിച്ചുള്ള ചോദ്യത്തിൽ തുടങ്ങുക, കണക്റ്റിവിറ്റിയല്ല: കേന്ദ്ര നെറ്റ്വർക്ക് ഉടമസ്ഥതയ്ക്ക് ഈ വർക്ക്ലോഡുകൾ പിന്തുണയ്ക്കാനാകുമോ? ഉത്തരം അതെ എന്നും സംഘടനയ്ക്ക് അനുയോജ്യമായ കോൺഫിഗറേഷൻ ഉണ്ടെന്നും ആണെങ്കിൽ, ഒരു ഹോസ്റ്റ് പ്രോജക്ട് VPC, സബ്നെറ്റുകൾ, കണക്റ്റിവിറ്റി എന്നിവ സ്വന്തമാക്കുന്നു, സേവന പ്രോജക്ടുകൾ അവയുടെ അപ്ലിക്കേഷൻ റിസോഴ്സുകൾ സ്വന്തമാക്കുന്നു. ആ പങ്കിട്ട നെറ്റ്വർക്കിലെ ഒരു Cloud VPN കണക്ഷന് പിന്നീട് ഉദ്ദേശിച്ച വർക്ക്ലോഡ് പ്രിഫിക്സുകൾക്ക് സേവനം നൽകാം, റൂട്ടിംഗ്, സുരക്ഷാ നയങ്ങൾക്ക് വിധേയമായി .
അസോസിയേഷൻ എന്ത് ചെയ്യുന്നു എന്നതിൽ കൃത്യത പാലിക്കുക. സേവന പ്രോജക്ട് ഘടിപ്പിക്കുന്നത് അതിന്റെ നിലവിലുള്ള സ്വതന്ത്ര VPC ഹോസ്റ്റ് നെറ്റ്വർക്കിലേക്ക് ലയിപ്പിക്കുന്നില്ല, ഓരോ റിസോഴ്സും സ്വയമേവ നീക്കുന്നുമില്ല. വർക്ക്ലോഡ് അറ്റാച്ച്മെന്റ്, അനുമതികൾ, വിലാസ സ്ഥലം, DNS എന്നിവയെല്ലാം ആർക്കിടെക്ചറിന്റെ ഭാഗമാണ്, ക്രമീകരണത്തിന്റെ ഫലമല്ല. അസോസിയേഷൻ ആദ്യം അനുമതി മാറ്റമായും പിന്നീട് റൂട്ടിംഗ് മാറ്റമായും വായിക്കുക, കാരണം ടീമുകൾ സാധാരണയായി കട്ട്ഓവറിനിടയിൽ വ്യത്യാസം കണ്ടെത്തുന്നു.
കേന്ദ്ര ഉടമസ്ഥത ബന്ധപ്പെട്ട ടീമുകൾക്ക് സ്വീകാര്യമല്ലെങ്കിൽ, ഇവിടെ നിർത്തുക, ബാക്കിയുള്ളത് പിയറിംഗ് അല്ലെങ്കിൽ ഹബ് ഡിസൈനായി കണക്കാക്കുക. സ്വതന്ത്ര നെറ്റ്വർക്ക് ജീവിതചക്രങ്ങൾ ആവശ്യമുള്ള ഒരു ഗ്രൂപ്പിന് മേൽ Shared VPC അടിച്ചേൽപ്പിക്കുന്നത് സാങ്കേതിക പേരുള്ള രാഷ്ട്രീയ പ്രശ്നം സൃഷ്ടിക്കുന്നു.
സ്വതന്ത്ര VPC-കൾക്ക് സ്വതന്ത്രമായി തുടരാനാകുമോ എന്ന് പരിശോധിക്കുക
പിയറിംഗ് വെവ്വേറെ VPC-കൾ നിലനിർത്തുന്നു, അതുകൊണ്ടുതന്നെ സ്വന്തം വിലാസ പ്ലാനുകളും സ്വന്തം മാറ്റ നിയന്ത്രണവും ആഗ്രഹിക്കുന്ന ടീമുകളെ അത് ആകർഷിക്കുന്നു. കെണി എന്തെന്നാൽ പിയറിംഗ് ട്രാൻസിറ്റീവ് അല്ല: A-ൽ നിന്ന് B-ലേക്കും B-ൽ നിന്ന് C-ലേക്കുമുള്ള പിയറിംഗ് സ്വയം B വഴി A-ൽ നിന്ന് C-ലേക്ക് റൂട്ടിംഗ് സൃഷ്ടിക്കുന്നില്ല. മൂന്ന് പ്രോജക്ടുകൾക്ക് ഒരു ഹൈബ്രിഡ് ലക്ഷ്യസ്ഥാനത്ത് എത്തണമെങ്കിൽ, പിയറിംഗ് ശൃംഖലയല്ല, ഉദ്ദേശപൂർവമായ കൈമാറ്റ പ്ലാൻ ആവശ്യമാണ്.
ഹൈബ്രിഡ് എത്തിച്ചേരാനുള്ള കഴിവ് പങ്കിടുന്നത് രേഖപ്പെടുത്തിയ ഇഷ്ടാനുസൃത റൂട്ട് കൈമാറ്റത്തെയും ഉദ്ദേശിച്ച Cloud Router പ്രഖ്യാപനങ്ങളെയും ആശ്രയിച്ചിരിക്കുന്നു. സജീവ പിയറിംഗ് നില പിയറിംഗ് നിലനിൽക്കുന്നു എന്ന് തെളിയിക്കുന്നു, ഓരോ വശത്തിനും പ്രധാനമായ പ്രിഫിക്സുകൾ എപ്പോഴെങ്കിലും കയറ്റുമതി ചെയ്തു എന്നല്ല. പിയറിന്റെ ഇരുവശത്തുമുള്ള കയറ്റുമതി ചെയ്ത ശ്രേണികൾ, കയറ്റുമതി നടത്തുന്ന കോൺഫിഗറേഷനിൽ പരിശോധിച്ച്, നിങ്ങളുടെ വർക്ക്ലോഡുകൾ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന വിലാസങ്ങളുമായി താരതമ്യം ചെയ്യുക. അവിടെയുള്ള പൊരുത്തക്കേടാണ് പിയറിംഗ് ആരോഗ്യകരമായി തോന്നുമ്പോഴും ഒരു പ്രിഫിക്സ് എത്തിച്ചേരാനാകാതെ തുടരുന്നതിന്റെ ഏറ്റവും സാധാരണ കാരണം.
എല്ലാറ്റിനും മുമ്പ് വിലാസ പ്ലാൻ എഴുതുക. ഒന്നുമേൽ ഒന്ന് വരാത്ത ശ്രേണികൾ, ഓരോ ഉദ്ദേശിച്ച ലക്ഷ്യസ്ഥാനത്തേക്കുള്ള റൂട്ടുകൾ, തിരികെയുള്ള പ്രഖ്യാപനങ്ങൾ എന്നിവയാണ് ഈ മോഡൽ ജീവിക്കുന്നതോ മരിക്കുന്നതോ ആയ മൂന്ന് കലാസൃഷ്ടികൾ.
ഹബ് മോഡൽ ടോപ്പോളജിയുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക
വലിയതോ വ്യത്യസ്തമായി വിഭജിച്ചതോ ആയ ഡിസൈനിന്, Google-ന്റെ Network Connectivity Center അവലോകനം ഹബ്, സ്പോക്ക് മോഡലുകൾ വിവരിക്കുന്നു. നിലവിലെ റിലീസ് എന്തിനെ പിന്തുണയ്ക്കുന്നു എന്നതിനായി ഇത് വായിക്കുക, ഡയഗ്രം സൂചിപ്പിക്കുന്നതിനായല്ല: ഏത് VPC, ഹൈബ്രിഡ് സംയോജനങ്ങൾ, ഏത് റൂട്ട് കുടുംബങ്ങൾ, ഓരോ സ്പോക്ക് തരവും ഏത് നയങ്ങൾ അനുവദിക്കുന്നു എന്നിവ.
വിലാസ കുടുംബം വ്യക്തമായി പരിശോധിക്കുക. മിക്ക ഗൈഡുകളിലെയും, ഇതും ഉൾപ്പെടെ, പ്ലാനിംഗ് ഉദാഹരണങ്ങൾ IPv4-നെക്കുറിച്ചാണ്, ഒരു സ്പോക്ക് തരത്തിന് നിലവിലുള്ള ഒരു സവിശേഷത മാറ്റമില്ലാതെ സ്വയമേവ മറ്റൊന്നിന് ബാധകമാകുന്നില്ല. നിങ്ങളുടെ പരിതസ്ഥിതി ഇരട്ട സ്റ്റാക്ക് ആണെങ്കിൽ, ആ ചോദ്യം മോഡൽ തിരഞ്ഞെടുപ്പിൽ ഉൾപ്പെടുന്നു, പിന്നീടുള്ള മൈഗ്രേഷനിൽ അല്ല.
ചുവടെയുള്ള പട്ടിക മൂന്ന് മോഡലുകളുടെ സംഗ്രഹവും ഓരോന്നിനെയും തീരുമാനിക്കുന്ന ചോദ്യവുമാണ്.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
റൂട്ടിംഗ് എന്ത് നൽകുന്നില്ല എന്ന് പരിശോധിക്കുക
റൂട്ട് കൈമാറ്റം സർവവ്യാപിയായ വിശ്വാസ ദാനമല്ല. DNS റെസല്യൂഷൻ, ഫയർവാൾ അനുമതി, അപ്ലിക്കേഷൻ അംഗീകാരം എന്നിവ അവരവരുടെ ഉത്തരവാദിത്വങ്ങളായി തുടരുന്നു, മിക്ക സംഘടനകളിലും ഓരോന്നും വ്യത്യസ്ത ഉടമകൾ കോൺഫിഗർ ചെയ്യുന്നു. എത്തിച്ചേരാനുള്ള കഴിവ് അംഗീകാരം എന്നർത്ഥമാക്കുന്നു എന്ന് അനുമാനിക്കുന്ന ഡിസൈൻ അതിന്റെ കണക്റ്റിവിറ്റി പരിശോധനയിൽ വിജയിക്കുകയും സുരക്ഷാ അവലോകനത്തിൽ പരാജയപ്പെടുകയും ചെയ്യും.
ഓരോ മോഡലിനും DNS കഥ സ്ഥിരീകരിക്കുക, കാരണം സോൺ, ഫോർവേഡിംഗ് ക്രമീകരണങ്ങൾ പങ്കിട്ട നെറ്റ്വർക്കും പിയർ ചെയ്ത നെറ്റ്വർക്കുകളും തമ്മിൽ വ്യത്യാസപ്പെടുന്നു. ഒരു പ്രോജക്ടിൽ പരിഹരിക്കുന്ന സ്വകാര്യ പേരുകൾ മറ്റൊന്നിലേക്ക് റൂട്ട് പിന്തുടരുന്നില്ല.
തീരുമാനവും അതിന്റെ ഉടമയും രേഖപ്പെടുത്തുക
സംഘടന പങ്കിട്ട നെറ്റ്വർക്ക് ഉടമയെ ആഗ്രഹിക്കുന്നിടത്ത് കേന്ദ്രീകരിക്കുക; ജീവിതചക്രമോ നയമോ ആവശ്യപ്പെടുന്നിടത്ത് വെവ്വേറെ VPC-കൾ നിലനിർത്തുക. തുടർന്ന് പിന്തുണയ്ക്കുന്ന ഒരു കണക്റ്റിവിറ്റി ബന്ധം തിരഞ്ഞെടുത്ത്, ഏതാണ് തിരഞ്ഞെടുത്തത്, പങ്കിട്ട നെറ്റ്വർക്ക് ആർക്കുള്ളത്, ഓരോ പ്രോജക്ടിനും എന്ത് പ്രഖ്യാപിക്കാം എന്നിവ എഴുതുക.
പ്രോജക്ടുകൾ എണ്ണി ഓരോന്നിനും ഒരു VPN വാങ്ങുന്നത് ആ ഉടമസ്ഥതാ തീരുമാനത്തിന് പകരമല്ല. അതേ തീരുമാനം തന്നെ, പിന്നീട് എടുക്കുന്നത്, ബിൽ, റൂട്ടിംഗ് പട്ടിക എന്നിവ പാരമ്പര്യമായി ലഭിക്കുന്നയാൾ.