பல 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 தொடர்பானவை, மேலும் ஒரு பின்னல் வகைக்கு இருக்கும் அம்சம் மாற்றமின்றி தானாக மற்றொன்றுக்குப் பொருந்தாது. உங்கள் சூழல் இரட்டை அடுக்கு என்றால், அந்தக் கேள்வி மாதிரி தேர்வுக்கு உரியது, பிந்தைய இடம்பெயர்வுக்கு அல்ல.

கீழே உள்ள அட்டவணை மூன்று மாதிரிகளின் சுருக்கம் மற்றும் ஒவ்வொன்றையும் தீர்மானிக்கும் கேள்வி.

ModelNetwork relationshipPlanning question
Shared VPCService projects use subnets of a host project's VPCCan central network ownership support these workloads?
VPC Network PeeringIndependent VPCs exchange supported routes through explicit peersAre direct peer and hybrid route exchanges sufficient?
Network Connectivity CenterSupported VPC and hybrid spokes join a managed hubDoes the required topology fit current routing and policy?

வழிசெலுத்தல் எதை வழங்காது என்பதைச் சரிபார்க்கவும்

வழிப் பரிமாற்றம் நம்பிக்கையின் எல்லையற்ற வழங்கல் அல்ல. DNS தீர்வு, ஃபயர்வால் அனுமதி மற்றும் பயன்பாட்டு அங்கீகாரம் ஆகியவை அவற்றின் சொந்தப் பொறுப்புகளாகவே இருக்கும், பெரும்பாலான அமைப்புகளில் ஒவ்வொன்றையும் வெவ்வேறு உரிமையாளர் கட்டமைக்கிறார். அணுகல்தன்மை என்பது அங்கீகாரம் என்று கருதும் வடிவமைப்பு அதன் இணைப்புச் சோதனையில் தேர்ச்சி பெற்று பாதுகாப்பு மதிப்பாய்வில் தோல்வியடையும்.

ஒவ்வொரு மாதிரிக்கும் DNS கதையை உறுதிப்படுத்துங்கள், ஏனெனில் மண்டலம் மற்றும் அனுப்புதல் ஏற்பாடுகள் பகிரப்பட்ட நெட்வொர்க் மற்றும் பியர் செய்யப்பட்ட நெட்வொர்க்குகளுக்கு இடையே வேறுபடுகின்றன. ஒரு திட்டத்தில் தீர்க்கப்படும் தனிப்பட்ட பெயர்கள் மற்றொன்றுக்கு வழியைப் பின்பற்றுவதில்லை.

முடிவையும் அதன் உரிமையாளரையும் பதிவு செய்யுங்கள்

அமைப்பு பகிரப்பட்ட நெட்வொர்க் உரிமையாளரை விரும்பும் இடத்தில் மையப்படுத்துங்கள்; வாழ்க்கைச் சுழற்சி அல்லது கொள்கை தேவைப்படும் இடத்தில் தனித்தனி VPC-களை வைத்திருங்கள். பின்னர் ஆதரிக்கப்படும் இணைப்பு உறவைத் தேர்ந்தெடுத்து நீங்கள் எதைத் தேர்ந்தெடுத்தீர்கள், பகிரப்பட்ட நெட்வொர்க் யாருக்குச் சொந்தம், ஒவ்வொரு திட்டமும் எதை அறிவிக்கலாம் என்பதை எழுதுங்கள்.

திட்டங்களை எண்ணி ஒவ்வொன்றுக்கும் ஒரு VPN வாங்குவது அந்த உரிமை முடிவுக்கு மாற்றல்ல. அது அதே முடிவு, பின்னர் எடுக்கப்பட்டது, பில் மற்றும் வழிசெலுத்தல் அட்டவணையை வாரிசாகப் பெறுபவரால்.

தொடர்புடைய கட்டுரைகள்