कई 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 खरीदना उस स्वामित्व निर्णय का विकल्प नहीं है। यह वही निर्णय है, बाद में लिया गया, उस व्यक्ति द्वारा जो बिल और रूटिंग तालिका विरासत में पाता है।