عدة مشاريع في Google Cloud وشبكة VPN هجينة واحدة؟ قرّر أولًا
تجيب شبكة VPC المشتركة والاقتران ومركز الاتصال عن أسئلة ملكية مختلفة. اختر حدود الشبكة قبل أن تنشر شبكة VPN واحدة لكل مشروع.
عندما تحتاج عدة مشاريع في Google Cloud إلى وصول هجين، تكون الغريزة هي شبكة VPN واحدة لكل مشروع، وهي في الغالب الشكل الخاطئ. ترتبط ملكية المشروع وتوجيه الحزم ببعضهما لكنهما مسألتان مختلفتان، ويحافظ التصميم المفيد على الحدود الإدارية التي تحتاجها مع منح البادئات المقصودة مسارًا واحدًا مدروسًا إلى المكتب أو مركز البيانات. تحسم هذه الفحوصات أي نموذج شبكة تريده فعليًا، بالترتيب الذي يتجنب إعادة العمل. ويمكن لكل فحص أن ينهي النقاش مبكرًا، وهذا هو المقصود.
حدود المشروع لا تفرض تلقائيًا نفقًا خاصًا بها.
تحقّق مما إذا كان العنصر المشترك هو الشبكة
ابدأ بسؤال عن الملكية لا عن الاتصال: هل يمكن لملكية الشبكة المركزية أن تدعم أحمال العمل هذه؟ إذا كان الجواب نعم وكان لدى المؤسسة إعداد مؤهل، فإن مشروعًا مضيفًا يملك شبكة VPC والشبكات الفرعية والاتصال، بينما تملك مشاريع الخدمة موارد تطبيقاتها. ويمكن لاتصال Cloud VPN واحد في تلك الشبكة المشتركة أن يخدم بادئات أحمال العمل المقصودة، رهنًا بسياسات التوجيه والأمان .
كن دقيقًا بشأن ما يفعله الربط. إن إرفاق مشروع خدمة لا يدمج شبكة VPC المستقلة القائمة فيه في الشبكة المضيفة، ولا ينقل كل مورد تلقائيًا. إن ربط أحمال العمل والأذونات ومساحة العناوين ونظام DNS كلها جزء من التصميم، وليست نتائج للإعداد. اقرأ الربط كتغيير في الأذونات أولًا وتغيير في التوجيه ثانيًا، لأن الفرق يكتشفه الفريق عادة أثناء التحويل.
إذا لم تكن الملكية المركزية مقبولة للفرق المعنية، فتوقف هنا وتعامل مع الباقي كتصميم اقتران أو مركز. إن فرض Shared VPC على مجموعة تحتاج دورات حياة شبكية مستقلة ينتج مشكلة سياسية باسم تقني.
تحقّق مما إذا كانت شبكات VPC المستقلة قادرة على البقاء مستقلة
يحافظ الاقتران على شبكات VPC منفصلة، ولهذا بالضبط يجذب الفرق التي تريد خطط عناوين خاصة بها وتحكمًا خاصًا في التغيير. المفارقة أن الاقتران غير متعدٍ: اقتران A بـ B وB بـ C لا ينشئ بحد ذاته توجيهًا من A إلى C عبر B. وإذا احتاج ثلاثة مشاريع إلى الوصول إلى وجهة هجينة واحدة، فأنت تحتاج خطة تبادل مدروسة لا سلسلة من الاقترانات.
يعتمد تقاسم قابلية الوصول الهجين أيضًا على تبادل المسارات المخصص الموثق وعلى إعلانات Cloud Router المقصودة. إن حالة الاقتران النشطة تثبت وجود الاقتران، لا أن البادئات التي يهتم بها كل طرف قد صُدّرت فعلًا. افحص النطاقات المصدّرة على جانبي الاقتران، في الإعداد الذي ينفذ التصدير، وقارنها بالعناوين التي تستخدمها أحمال عملك فعليًا. وعدم التطابق هناك هو السبب الأكثر شيوعًا لظهور الاقتران سليمًا بينما تبقى بادئة غير قابلة للوصول.
اكتب خطة العناوين قبل أي شيء آخر. النطاقات غير المتداخلة والمسارات نحو كل وجهة مقصودة وإعلانات العودة هي القطع الثلاث التي يعيش عليها هذا النموذج أو يموت.
تحقّق مما إذا كان نموذج المركز يناسب الطوبولوجيا
للتصميم الأكبر أو الأكثر تقسيمًا، تصف نظرة عامة على Network Connectivity Center من Google نماذج المركز والفرع. اقرأها لما يدعمه الإصدار الحالي لا لما يوحي به المخطط: أي مجموعات 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 لكل منها ليس بديلًا عن قرار الملكية ذلك. إنه القرار نفسه، يُتخذ لاحقًا، من قبل من يرث الفاتورة وجدول التوجيه.