Bir nechta Google Cloud loyihasi, bitta gibrid VPN? Avval qaror qiling
Umumiy VPC, peering va ulanish markazi turli egalik savollariga javob beradi. Har bir loyiha uchun bitta VPN joylashtirishdan oldin tarmoq chegarasini tanlang.
Bir nechta Google Cloud loyihasiga gibrid kirish kerak bo'lganda, instinkt har bir loyiha uchun bitta VPN bo'ladi va bu deyarli har doim noto'g'ri shakl. Loyiha egaligi va paketlarni marshrutlash bog'liq, ammo turlicha masalalar, va foydali arxitektura kerakli ma'muriy chegaralarni saqlab, mo'ljallangan prefikslarga ofis yoki ma'lumot markaziga bitta o'ylangan yo'l beradi. Bu tekshiruvlar qaysi tarmoq modelini chindan xohlayotganingizni, qayta ishlashdan qochadigan tartibda hal qiladi. Ularning har biri muhokamani erta tugatishi mumkin, va ma'no shunda.
Loyiha chegarasi avtomatik ravishda o'z tunnelini talab qilmaydi.
Umumiy ob'ekt tarmoqmi yoki yo'qmi tekshiring
Egalik haqidagi savol bilan boshlang, ulanish haqida emas: markaziy tarmoq egaligi bu ish yuklamalarini qo'llab-quvvatlay oladimi? Javob ha bo'lsa va tashkilotda mos konfiguratsiya bo'lsa, xost loyiha VPC, quyi tarmoqlar va ulanishga ega, xizmat loyihalari esa o'z ilova resurslariga ega. O'sha umumiy tarmoqdagi bitta Cloud VPN ulanishi keyin mo'ljallangan ish yuklamasi prefikslariga xizmat qilishi mumkin, marshrutlash va xavfsizlik siyosatlariga rioya qilgan holda .
Birlashma nima qilishida aniq bo'ling. Xizmat loyihasini ulash uning mavjud mustaqil VPC'sini xost tarmog'iga birlashtirmaydi va har bir resursni avtomatik ko'chirmaydi. Ish yuklamasini ulash, ruxsatlar, manzil maydoni va DNS arxitekturaning qismi, sozlamaning natijasi emas. Birlashmani avval ruxsat o'zgarishi, keyin marshrutlash o'zgarishi sifatida o'qing, chunki jamoalar farqni odatda o'tish paytida aniqlaydi.
Agar markaziy egalik jalb qilingan jamoalar uchun maqbul bo'lmasa, shu yerda to'xtang va qolganini peering yoki markaz dizayni deb biling. Mustaqil tarmoq hayot tsikllariga muhtoj guruhga Shared VPC'ni majburlash texnik nomli siyosiy muammo tug'diradi.
Mustaqil VPC'lar mustaqil qola oladimi tekshiring
Peering alohida VPC'larni saqlaydi va shuning uchun o'z manzil rejalari va o'z o'zgarish nazoratini istaydigan jamoalarni jalb qiladi. Tuzoq shundaki, peering tranzitiv emas: A-dan-B ga va B-dan-C ga peering o'z-o'zidan B orqali A-dan-C ga marshrutlash yaratmaydi. Agar uchta loyiha bitta gibrid manzilga yetishi kerak bo'lsa, sizga peering zanjiri emas, o'ylangan almashinuv rejasi kerak.
Gibrid yetib borish imkoniyatini bo'lishish hujjatlashtirilgan maxsus marshrut almashinuviga va mo'ljallangan Cloud Router e'lonlariga ham bog'liq. Faol peering holati peering mavjudligini isbotlaydi, har bir tomon uchun muhim prefikslar qachonlardir eksport qilinganini emas. Peerning ikkala tomonidagi eksport qilingan diapazonlarni eksportni bajaradigan konfiguratsiyada tekshiring va ularni ish yuklamalaringiz haqiqatda ishlatadigan manzillar bilan solishtiring. U yerdagi nomuvofiqlik peering sog'lom ko'rinib, prefiks yetib bo'lmaydigan bo'lib qolishining eng keng tarqalgan sababidir.
Manzil rejasini hamma narsadan oldin yozing. Bir-biriga tushmaydigan diapazonlar, har bir mo'ljallangan manzilga yo'llar va qaytish e'lonlari bu model yashaydigan yoki o'ladigan uchta artefaktdir.
Markaz modeli topologiyaga mos keladimi tekshiring
Kattaroq yoki boshqacha segmentlangan dizayn uchun Google'ning Network Connectivity Center sharhi markaz va nur modellarini tavsiflaydi. Uni joriy nashr nimani qo'llab-quvvatlashi uchun o'qing, diagramma nimani nazarda tutishi uchun emas: qaysi VPC va gibrid kombinatsiyalar, qaysi marshrut oilalari va har bir nur turi qanday siyosatlarga ruxsat beradi.
Manzil oilasini aniq tekshiring. Ko'pgina qo'llanmalardagi, shu jumladan bu, rejalash misollari IPv4 ga tegishli, va bitta nur turi uchun mavjud xususiyat o'zgarishsiz avtomatik ravishda boshqasiga qo'llanilmaydi. Agar muhitingiz ikki qavatli stek bo'lsa, bu savol model tanlashiga tegishli, keyingi migratsiyaga emas.
Quyidagi jadval uch modelning xulosasi va har birini hal qiladigan savoldir.
| 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? |
Marshrutlash nima bermasligini tekshiring
Marshrut almashinuvi ishonchni umumiy berish emas. DNS hal qilish, tarmoq to'sig'i ruxsati va ilova avtorizatsiyasi o'z mas'uliyatlari bo'lib qoladi va ko'p tashkilotlarda har birini boshqa egasi sozlaydi. Yetib borish avtorizatsiyani anglatadi deb hisoblaydigan dizayn ulanish testidan o'tadi va xavfsizlik ko'rigida yiqiladi.
Har bir model uchun DNS hikoyasini ham tasdiqlang, chunki zona va uzatish sozlamalari umumiy tarmoq va peer qilingan tarmoqlar o'rtasida farq qiladi. Bir loyihada hal bo'ladigan shaxsiy nomlar boshqasiga marshrut bo'ylab bormaydi.
Qarorni va uning egasini yozib qo'ying
Tashkilot umumiy tarmoq egasini xohlagan joyda markazlashtiring; hayot tsikli yoki siyosat talab qiladigan joyda alohida VPC'larni saqlang. Keyin qo'llab-quvvatlanadigan ulanish munosabatini tanlang va qaysi birini tanlaganingizni, umumiy tarmoq kimga tegishli ekanini va har bir loyiha nima e'lon qilishi mumkinligini yozing.
Loyihalarni sanash va har biriga bitta VPN sotib olish o'sha egalik qarorining o'rnini bosmaydi. Bu o'sha qaror, keyinroq qabul qilingan, hisob-faktura va marshrutlash jadvalini meros olgan kishi tomonidan.