अनेक 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 खरेदी करणे हे त्या मालकी निर्णयाचा पर्याय नाही. तोच निर्णय, नंतर घेतलेला, बिल आणि राउटिंग तक्ता वारसाहक्काने मिळणाऱ्या व्यक्तीकडून.