کئی 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 خریدنا اس ملکیت کے فیصلے کا متبادل نہیں ہے۔ یہ وہی فیصلہ ہے، بعد میں لیا گیا، اس شخص کی طرف سے جو بل اور روٹنگ جدول کا وارث ہوتا ہے۔