여러 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을 하나씩 사는 것은 그 소유권 결정을 대신하지 못합니다. 그것은 같은 결정을, 청구서와 라우팅 테이블을 물려받는 사람이 나중에 내리는 것입니다.