Birden çok Google Cloud projesi, tek hibrit VPN? Önce karar verin
Paylaşılan VPC, eşleme ve bir bağlantı merkezi farklı sahiplik sorularını yanıtlar. Her proje için bir VPN dağıtmadan önce ağ sınırını seçin.
Birden çok Google Cloud projesinin hibrit erişime ihtiyacı olduğunda içgüdü her proje için bir VPN'dir ve bu neredeyse her zaman yanlış biçimdir. Proje sahipliği ve paket yönlendirme ilişkili ancak farklı konulardır ve kullanışlı mimari, ihtiyaç duyduğunuz yönetim sınırlarını korurken amaçlanan öneklere ofise veya veri merkezine tek bir bilinçli yol verir. Bu kontroller hangi ağ modelini gerçekten istediğinizi, yeniden çalışmayı önleyen sırayla belirler. Her biri tartışmayı erken bitirebilir ve amaç da budur.
Bir proje sınırı otomatik olarak kendi tünelini gerektirmez.
Paylaşılan nesnenin ağ olup olmadığını kontrol edin
Sahiplikle ilgili bir soruyla başlayın, bağlantıyla değil: merkezi ağ sahipliği bu iş yüklerini destekleyebilir mi? Yanıt evetse ve kuruluşun uygun bir yapılandırması varsa, bir ana proje VPC'yi, alt ağları ve bağlantıyı sahiplenirken hizmet projeleri kendi uygulama kaynaklarını sahiplenir. O paylaşılan ağdaki tek bir Cloud VPN bağlantısı daha sonra amaçlanan iş yükü öneklerine hizmet edebilir, yönlendirme ve güvenlik politikalarına tabi olarak .
İlişkilendirmenin ne yaptığı konusunda kesin olun. Bir hizmet projesini eklemek, mevcut bağımsız VPC'sini ana ağla birleştirmez ve her kaynağı otomatik olarak taşımaz. İş yükü ekleme, izinler, adres alanı ve DNS mimarinin parçasıdır, ayarın sonucu değildir. İlişkilendirmeyi önce izin değişikliği, sonra yönlendirme değişikliği olarak okuyun, çünkü ekipler farkı genellikle geçiş sırasında keşfeder.
Merkezi sahiplik ilgili ekipler için kabul edilebilir değilse burada durun ve geri kalanı eşleme veya merkez tasarımı olarak ele alın. Bağımsız ağ yaşam döngülerine ihtiyaç duyan bir gruba Shared VPC'yi zorlamak teknik adı olan bir siyasi sorun yaratır.
Bağımsız VPC'lerin bağımsız kalıp kalamayacağını kontrol edin
Eşleme ayrı VPC'leri korur ve tam da bu yüzden kendi adres planlarını ve kendi değişiklik kontrollerini isteyen ekipleri çeker. Tuzak, eşlemenin geçişli olmamasıdır: A-dan-B'ye ve B'den-C'ye eşleme kendi başına B üzerinden A'dan-C'ye yönlendirme oluşturmaz. Üç projenin tek bir hibrit hedefe ulaşması gerekiyorsa, eşleme zinciri değil, bilinçli bir değişim planı gerekir.
Hibrit erişilebilirliğin paylaşılması ayrıca belgelenmiş özel rota değişimine ve amaçlanan Cloud Router duyurularına bağlıdır. Etkin eşleme durumu, eşlemenin var olduğunu kanıtlar, her tarafın önemsediği öneklerin bir zamanlar dışa aktarıldığını değil. Eşin her iki tarafındaki dışa aktarılan aralıkları, dışa aktarmayı yapan yapılandırmada kontrol edin ve bunları iş yüklerinizin gerçekte kullandığı adreslerle karşılaştırın. Oradaki uyumsuzluk, bir önek erişilemez kalırken eşlemenin sağlıklı görünmesinin en yaygın nedenidir.
Adres planını her şeyden önce yazın. Çakışmayan aralıklar, amaçlanan her hedefe giden rotalar ve dönüş duyuruları bu modelin yaşadığı veya öldüğü üç eserdir.
Merkez modelinin topolojiye uyup uymadığını kontrol edin
Daha büyük veya farklı segmentlenmiş bir tasarım için Google'ın Network Connectivity Center genel bakışı merkez ve ispit modellerini açıklar. Güncel sürümün neyi desteklediği için okuyun, diyagramın ima ettiği için değil: hangi VPC ve hibrit kombinasyonları, hangi rota aileleri ve her ispit türünün hangi politikaları kabul ettiği.
Adres ailesini açıkça kontrol edin. Çoğu kılavuzdaki planlama örnekleri, bu da dahil, IPv4 ile ilgilidir ve bir ispit türü için var olan bir özellik değişiklik olmadan otomatik olarak diğerine uygulanmaz. Ortamınız çift yığınsa, o soru model seçimine aittir, sonraki bir geçişe değil.
Aşağıdaki tablo üç modelin özeti ve her birini belirleyen sorudur.
| 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? |
Yönlendirmenin neyi vermediğini kontrol edin
Rota değişimi kapsamlı bir güven verme değildir. DNS çözümlemesi, güvenlik duvarı izni ve uygulama yetkilendirmesi kendi sorumlulukları olarak kalır ve her biri çoğu kuruluşta farklı bir sahip tarafından yapılandırılır. Erişilebilirliğin yetkilendirme anlamına geldiğini varsayan bir tasarım bağlantı testini geçer ve güvenlik incelemesinde kalır.
Her model için DNS hikâyesini de doğrulayın, çünkü bölge ve yönlendirme düzenlemeleri paylaşılan ağ ile eşlenmiş ağlar arasında farklıdır. Bir projede çözülen özel adlar diğerine rota izlemez.
Kararı ve sahibini kaydedin
Kuruluşun paylaşılan ağ sahibi istediği yerde merkezileştirin; yaşam döngüsü veya politikanın gerektirdiği yerde ayrı VPC'leri koruyun. Ardından desteklenen bir bağlantı ilişkisi seçin ve hangisini seçtiğinizi, paylaşılan ağın kime ait olduğunu ve her projenin ne duyurabileceğini yazın.
Projeleri saymak ve her biri için bir VPN satın almak o sahiplik kararının yerine geçmez. Aynı karardır, daha sonra faturayı ve yönlendirme tablosunu devralan kişi tarafından verilir.