అనేక 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 కొనడం ఆ యాజమాన్య నిర్ణయానికి ప్రత్యామ్నాయం కాదు. అది అదే నిర్ణయం, తర్వాత తీసుకున్నది, బిల్లు మరియు రూటింగ్ పట్టికను వారసత్వంగా పొందే వ్యక్తి.