धेरै 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 किन्नु त्यो स्वामित्व निर्णयको विकल्प होइन। यो त्यही निर्णय हो, पछि गरिएको, बिल र राउटिङ तालिका उत्तराधिकारमा पाउने व्यक्तिले।