Олон 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 худалдаж авах нь тэр өмчлөлийн шийдвэрийг орлохгүй. Энэ нь мөн тэр шийдвэр, дараа нь гаргасан, нэхэмжлэх болон чиглүүлэлтийн хүснэгтийг өвлөн авсан хүн.