Varios proxectos de Google Cloud, unha VPN híbrida? Decida primeiro
A VPC compartida, o emparellamento e un centro de conectividade responden a preguntas de propiedade distintas. Escolla o límite da rede antes de despregar unha VPN por proxecto.
Cando varios proxectos de Google Cloud necesitan acceso híbrido, o instinto é unha VPN por proxecto, e case sempre é a forma equivocada. A propiedade do proxecto e o encamiñamento de paquetes son cuestións relacionadas pero distintas, e a arquitectura útil conserva os límites administrativos que precisa mentres dá aos prefixos previstos un único camiño deliberado cara á oficina ou ao centro de datos. Estas comprobacións deciden que modelo de rede quere realmente, na orde que evita retraballo. Cada unha pode rematar a discusión cedo, e desa trata.
Un límite de proxecto non require automaticamente o seu propio túnel.
Comprobe se o obxecto compartido é a rede
Comece cunha pregunta sobre a propiedade, non sobre a conectividade: pode a propiedade central da rede soportar estas cargas de traballo? Se a resposta é si e a organización ten unha configuración elixible, un proxecto anfitrión posúe a VPC, as subredes e a conectividade, mentres que os proxectos de servizo posúen os seus recursos de aplicación. Unha conexión de Cloud VPN nesa rede compartida pode entón servir os prefixos de carga de traballo previstos, suxeita ás políticas de encamiñamento e seguridade .
Sexa preciso sobre o que fai a asociación. Engadir un proxecto de servizo non fusiona a súa VPC independente existente coa rede anfitrioa, nin move cada recurso automaticamente. A adhesión de cargas de traballo, os permisos, o espazo de enderezos e o DNS forman parte da arquitectura, non son consecuencias da configuración. Lea a asociación primeiro como un cambio de permisos e despois como un cambio de encamiñamento, porque os equipos adoitan descubrir a diferenza durante a migración.
Se a propiedade central non é aceptable para os equipos implicados, detéñase aquí e trate o resto como un deseño de emparellamento ou de centro. Forzar Shared VPC sobre un grupo que necesita ciclos de vida de rede independentes produce un problema político cun nome técnico.
Comprobe se as VPC independentes poden seguir sendo independentes
O emparellamento conserva VPC separadas, e por iso atrae equipos que queren os seus propios plans de enderezos e o seu propio control de cambios. A trampa é que o emparellamento non é transitivo: o emparellamento A-con-B e B-con-C non crea por si mesmo encamiñamento A-con-C a través de B. Se tres proxectos deben alcanzar un destino híbrido, necesita un plan de intercambio deliberado e non unha cadea de emparellamentos.
Compartir a alcanzabilidade híbrida tamén depende do intercambio documentado de rutas personalizadas e dos anuncios previstos de Cloud Router. Un estado de emparellamento activo demostra que o emparellamento existe, non que os prefixos que importan a cada lado se exportasen algunha vez. Comprobe os rangos exportados en ambos os dous lados do par, na configuración que realiza a exportación, e compáreos cos enderezos que as súas cargas de traballo usan realmente. Unha discrepancia aí é a razón máis común de que un emparellamento pareza san mentres un prefixo segue inalcanzable.
Escriba o plan de enderezos antes que nada. Os rangos que non se solapan, as rutas cara a cada destino previsto e os anuncios de retorno son os tres artefactos dos que este modelo vive ou morre.
Comprobe se un modelo de centro encaixa coa topoloxía
Para un deseño máis grande ou segmentado doutro xeito, a descrición xeral de Google Network Connectivity Center describe os modelos de centro e de raio. Léaa polo que admite a versión actual e non polo que implica o diagrama: que combinacións de VPC e híbridas, que familias de rutas e que políticas permite cada tipo de raio.
Comprobe a familia de enderezos de forma explícita. Os exemplos de planificación da maioría das guías, incluída esta, tratan de IPv4, e unha función que existe para un tipo de raio non se aplica automaticamente sen cambios a outro. Se o seu contorno é de dobre pila, esa pregunta pertence á elección do modelo, non a unha migración posterior.
A táboa seguinte é o resumo dos tres modelos e a pregunta que decide cada un.
| 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? |
Comprobe que non concede o encamiñamento
O intercambio de rutas non é unha concesión global de confianza. A resolución de DNS, o permiso da devasa e a autorización de aplicacións seguen sendo responsabilidades propias, e cada unha configúraa un propietario distinto na maioría das organizacións. Un deseño que asume que a alcanzabilidade implica autorización pasará a súa proba de conectividade e suspenderá a súa revisión de seguridade.
Confirme tamén a historia de DNS para cada modelo, porque os arranxos de zona e reenvío difiren entre unha rede compartida e redes emparelladas. Os nomes privados que se resolven nun proxecto non seguen unha ruta cara a outro.
Rexistre a decisión e o seu propietario
Centralice onde a organización quere un propietario de rede compartido; manteña VPC separadas onde o esixa o ciclo de vida ou a política. Logo escolla unha relación de conectividade admitida e anote cal escolleu, quen posúe a rede compartida e que pode anunciar cada proxecto.
Contar proxectos e mercar unha VPN para cada un non substitúe esa decisión de propiedade. É a mesma decisión, tomada máis tarde, por quen herda a factura e a táboa de encamiñamento.