หลายโปรเจกต์ 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 ที่ตั้งใจไว้ สถานะการเพียร์ที่ใช้งานอยู่พิสูจน์ว่าการเพียร์มีอยู่ ไม่ได้พิสูจน์ว่าคำนำหน้าที่แต่ละฝ่ายให้ความสำคัญเคยถูกส่งออก ตรวจสอบช่วงที่ส่งออกทั้งสองด้านของเพียร์ ในการกำหนดค่าที่ทำการส่งออก และเปรียบเทียบกับที่อยู่ที่ภาระงานของคุณใช้จริง ความไม่ตรงกันตรงนั้นคือสาเหตุที่พบบ่อยที่สุดที่การเพียร์ดูแข็งแรงขณะที่คำนำหน้ายังเข้าถึงไม่ได้
เขียนแผนที่อยู่ก่อนสิ่งอื่นใด ช่วงที่ไม่ทับซ้อน เส้นทางไปยังปลายทางที่ตั้งใจไว้แต่ละแห่ง และการประกาศย้อนกลับคือสามสิ่งประดิษฐ์ที่รูปแบบนี้อยู่หรือตาย
ตรวจสอบว่ารูปแบบศูนย์กลางเข้ากับโทโพโลยีหรือไม่
สำหรับการออกแบบที่ใหญ่ขึ้นหรือแบ่งส่วนต่างออกไป ภาพรวมของ 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 หนึ่งตัวสำหรับแต่ละโปรเจกต์ไม่ใช่สิ่งทดแทนการตัดสินใจเรื่องความเป็นเจ้าของนั้น เป็นการตัดสินใจเดียวกัน ที่ทำในภายหลัง โดยผู้ที่สืบทอดใบแจ้งหนี้และตารางเส้นทาง