Nhiều dự án Google Cloud, một VPN lai? Hãy quyết định trước

Khi nhiều dự án Google Cloud cần truy cập lai, bản năng là một VPN cho mỗi dự án, và đó gần như luôn là hình dạng sai. Quyền sở hữu dự án và định tuyến gói tin là những vấn đề liên quan nhưng khác nhau, và kiến trúc hữu ích giữ lại các ranh giới quản trị bạn cần đồng thời cho các tiền tố dự định một con đường có chủ đích đến văn phòng hoặc trung tâm dữ liệu. Những kiểm tra này quyết định mô hình mạng nào bạn thực sự muốn, theo thứ tự tránh làm lại. Mỗi kiểm tra có thể kết thúc cuộc thảo luận sớm, và đó chính là điểm mấu chốt.

Ranh giới dự án không tự động yêu cầu đường hầm riêng.

Kiểm tra xem đối tượng được chia sẻ có phải là mạng không

Bắt đầu bằng câu hỏi về quyền sở hữu, không phải kết nối: quyền sở hữu mạng tập trung có thể hỗ trợ các khối lượng công việc này không? Nếu câu trả lời là có và tổ chức có cấu hình phù hợp, một dự án máy chủ sở hữu VPC, các mạng con và kết nối, trong khi các dự án dịch vụ sở hữu tài nguyên ứng dụng của riêng chúng. Một kết nối Cloud VPN trong mạng chia sẻ đó sau đó có thể phục vụ các tiền tố khối lượng công việc dự định, tuân theo các chính sách định tuyến và bảo mật .

Hãy chính xác về những gì liên kết làm. Việc gắn một dự án dịch vụ không hợp nhất VPC độc lập hiện có của nó vào mạng máy chủ, và không tự động di chuyển mọi tài nguyên. Việc gắn khối lượng công việc, quyền, không gian địa chỉ và DNS đều là một phần của kiến trúc, không phải hệ quả của cài đặt. Hãy đọc liên kết trước hết như một thay đổi quyền và sau đó như một thay đổi định tuyến, vì các nhóm thường phát hiện sự khác biệt trong quá trình chuyển đổi.

Nếu quyền sở hữu tập trung không được các nhóm liên quan chấp nhận, hãy dừng ở đây và coi phần còn lại là thiết kế peering hoặc trung tâm. Việc áp đặt Shared VPC lên một nhóm cần vòng đời mạng độc lập tạo ra một vấn đề chính trị với tên kỹ thuật.

Kiểm tra xem các VPC độc lập có thể vẫn độc lập không

Peering giữ các VPC riêng biệt, và đó chính là lý do nó thu hút các nhóm muốn kế hoạch địa chỉ riêng và kiểm soát thay đổi riêng. Cái bẫy là peering không có tính bắc cầu: peering A-đến-B và B-đến-C tự nó không tạo ra định tuyến A-đến-C qua B. Nếu ba dự án cần đến một đích lai, bạn cần một kế hoạch trao đổi có chủ đích chứ không phải một chuỗi peering.

Việc chia sẻ khả năng tiếp cận lai cũng phụ thuộc vào trao đổi tuyến tùy chỉnh được ghi lại và các quảng cáo Cloud Router dự định. Trạng thái peering hoạt động chứng minh peering tồn tại, không phải rằng các tiền tố mà mỗi bên quan tâm đã từng được xuất. Kiểm tra các dải đã xuất ở cả hai phía của peer, trong cấu hình thực hiện việc xuất, và so sánh chúng với các địa chỉ mà khối lượng công việc của bạn thực sự dùng. Sự không khớp ở đó là lý do phổ biến nhất khiến một peering trông khỏe mạnh trong khi một tiền tố vẫn không thể tiếp cận.

Viết kế hoạch địa chỉ trước mọi thứ khác. Các dải không chồng lấn, các tuyến đến từng đích dự định và các quảng cáo trả về là ba hiện vật mà mô hình này sống hoặc chết dựa vào.

Kiểm tra xem mô hình trung tâm có phù hợp với cấu trúc liên kết không

Đối với thiết kế lớn hơn hoặc phân đoạn khác đi, tổng quan của Google Network Connectivity Center mô tả các mô hình trung tâm và nan hoa. Hãy đọc nó vì những gì bản phát hành hiện tại hỗ trợ, không phải vì những gì sơ đồ ngụ ý: tổ hợp VPC và lai nào, họ tuyến nào và chính sách nào mà mỗi loại nan hoa cho phép.

Kiểm tra họ địa chỉ một cách rõ ràng. Các ví dụ lập kế hoạch trong hầu hết hướng dẫn, kể cả hướng dẫn này, liên quan đến IPv4, và một tính năng tồn tại cho một loại nan hoa không tự động áp dụng nguyên vẹn cho loại khác. Nếu môi trường của bạn là ngăn xếp kép, câu hỏi đó thuộc về lựa chọn mô hình, không phải di chuyển sau này.

Bảng dưới đây là bản tóm tắt ba mô hình và câu hỏi quyết định từng mô hình.

Kiểm tra những gì định tuyến không cấp

Trao đổi tuyến không phải là sự ban tặng tin cậy toàn diện. Phân giải DNS, quyền tường lửa và ủy quyền ứng dụng vẫn là trách nhiệm riêng của chúng, và mỗi thứ được cấu hình bởi một chủ sở hữu khác nhau trong hầu hết tổ chức. Một thiết kế cho rằng khả năng tiếp cận bao hàm ủy quyền sẽ vượt qua bài kiểm tra kết nối và thất bại trong đánh giá bảo mật.

Cũng xác nhận câu chuyện DNS cho từng mô hình, vì cách sắp xếp vùng và chuyển tiếp khác nhau giữa mạng chia sẻ và mạng đã peering. Các tên riêng được phân giải trong một dự án không đi theo tuyến sang dự án khác.

Ghi lại quyết định và chủ sở hữu của nó

Tập trung hóa nơi tổ chức muốn một chủ sở hữu mạng chia sẻ; giữ các VPC riêng biệt nơi vòng đời hoặc chính sách yêu cầu. Sau đó chọn một quan hệ kết nối được hỗ trợ và ghi lại bạn đã chọn cái nào, ai sở hữu mạng chia sẻ và mỗi dự án được phép quảng cáo gì.

Đếm dự án và mua một VPN cho mỗi dự án không thay thế quyết định sở hữu đó. Đó là cùng một quyết định, được đưa ra muộn hơn, bởi người thừa kế hóa đơn và bảng định tuyến.