Azure VMware Çözümü 2. Nesil Özel Bulutlar için tasarım konuları

Bu makalede, Azure VMware Çözümü 2. Nesil (2. Nesil) özel bulutlar için önemli tasarım konuları özetlenmiştir. Bu neslin VMware tabanlı özel bulut ortamlarına getirdiği özellikleri açıklayarak hem şirket içi altyapıdan hem de Azure tabanlı kaynaklardan uygulamalarınıza erişim sağlar. Azure VMware Çözümü 2. Nesil özel bulutunuzu ayarlamadan önce gözden geçirmeniz gereken birkaç nokta vardır. Bu makalede, özel bulut türünü kullanırken karşılaşabileceğiniz kullanım örnekleri için çözümler sağlanır.

Uyarı

2. nesil, belirli Azure genel bölgelerde kullanılabilir. Kapsamı onaylamak için Microsoft hesabı ekibinize veya Microsoft Desteği başvurun.

Sınırlamalar

Bu süre boyunca aşağıdaki işlevler sınırlıdır. Bu sınırlamalar gelecekte kaldırılacaktır:

• Özel bulutunuzu içeren Kaynak Grubunuzu silemezsiniz. Kaynak grubunu silmeden önce özel bulutu silmeniz gerekir.
• Azure sanal ağ başına yalnızca 1 özel bulutu dağıtabilirsiniz.
• Kaynak Grubu başına yalnızca 1 özel bulut oluşturabilirsiniz. Tek bir Kaynak Grubundaki birden çok özel bulut desteklenmez.
• Özel bulutunuz için özel bulutunuz ve sanal ağınız aynı Kaynak Grubunda olmalıdır.
• Özel bulut oluşturulduktan sonra özel bulutunuzu bir Kaynak Grubundan diğerine taşıyamazsınız .
• Özel bulut oluşturulduktan sonra özel bulutunuzu bir kiracıdan diğerine taşıyamazsınız .
• AVS Özel Bulutunuz için ExpressRoute FastPath veya Global Sanal Ağ Eşleme gerekiyorsa Azure portalı aracılığıyla bir Destek Olayı oluşturun.
• Service Endpoints Azure VMware Çözümü iş yüklerinden doğrudan bağlantı desteklenmez.
• Azure VMware Çözümü’a bağlı bölgeler arasında küresel olarak eşleştirildiğinde Özel Uç Noktalar desteklenmez.
• Özel Uç Noktaları kullanan vCloud Director desteklenir. Ancak Genel Uç Noktaları kullanan vCloud Director desteklenmez.
• vSAN Esnetilmiş Kümeleri desteklenmez.
• İnterneti yapılandırmak için VMware NSX Microsoft Edge üzerinde Genel IP kullanımı desteklenmez. Hangi internet seçeneklerinin desteklendiğine İnternet bağlantı seçenekleri bölümünden ulaşabilirsiniz.
• Yazılım Tanımlı Veri Merkezi’nizdeki (SDDC) ilk dört ana makineden herhangi birinde, ana makine donanımı arızası gibi plansız bakım sırasında bazı iş yüklerinde 30 saniyeye kadar süren geçici bir kuzey-güney ağ bağlantısı kesintisi yaşayabilirsiniz. North-South bağlantı, AVS VMware iş yükleriniz ile Azure hizmetleri veya şirket içi ortamlar gibi NSX-T Katman 0 (T0) Edge dışındaki dış uç noktalar arasındaki trafiği ifade eder. Bu sınırlama belirli Azure bölgelerinde kaldırıldı. Azure Desteği'ne bakarak bölgenizin bu sınırlamadan etkilenip etkilenmediğini onaylayın.  
• Özel bulut ana bilgisayar sanal ağıyla ilişkili Ağ Güvenlik Grupları, özel bulut ve sanal ağıyla aynı kaynak grubunda oluşturulmalıdır.
• Kaynak grupları arası ve abonelikler arası başvurular, müşteri sanal ağlarından Azure VMware Çözümü sanal ağına varsayılan olarak desteklenmez. Buna kullanıcı tanımlı yollar (UDR' ler), DDoS Koruma Planları ve diğer bağlı ağ kaynakları gibi kaynak türleri dahildir. Müşteri sanal ağı, Azure VMware Çözümü sanal ağından farklı bir kaynak grubunda veya abonelikte bulunan bu referanslardan biriyle bağlıysa, ağ programlama (NSX segment yayılımı gibi) başarısız olabilir. Sorunlardan kaçınmak için müşteriler Azure VMware Çözümü sanal ağının başka bir kaynak grubu veya abonelikteki kaynaklara bağlı olmadığından emin olmalıdır. Devam etmeden önce DDoS Koruma Planları gibi bağlantıları sanal ağdan kaldırın.
  • Kaynak grupları arası referansınızı korumak için, kaynak grupları arası kaynak grubunuzdan veya aboneliğinizden bir rol ataması oluşturun ve "AzS VIS Prod App"e "AVS on Fleet VIS Role" rolünü verin. Rol ataması, referansı kullanmanıza ve referansınızın Azure VMware Çözümü özel bulutunuza doğru şekilde uygulanmasına olanak tanır.
• 2. Nesil özel bulut kurulumları, Azure ilkeleri Ağ Güvenlik Grupları veya yönlendirme tabloları (örneğin, belirli adlandırma kuralları) için katı kurallar uyguluyorsa başarısız olabilir. Bu ilke kısıtlamaları, dağıtım sırasında gerekli Azure VMware Çözümü Ağ Güvenlik Grubu ve yönlendirme tablosu oluşturulmasını engelleyebilir. Özel bulutunuzu dağıtmadan önce bu ilkeleri Azure VMware Çözümü sanal ağından kaldırmanız gerekir. Özel bulutunuz dağıtıldıktan sonra bu ilkeler Azure VMware Çözümü özel bulutunuza geri eklenebilir.
• Azure VMware Çözümü 2. Nesil özel bulutunuz için Özel DNS kullanıyorsanız, Custom DNS kullanarak Azure VMware Çözümü 2. Nesil özel bulutunun dağıtıldığı sanal ağda desteklenmez. Özel DNS, ölçeklendirme, yükseltme ve güncelleme yaması ile ilgili yaşam döngüsü işlemlerini bozar.
• Özel bulutunuzu siliyorsanız ve Azure VMware Çözümü tarafından oluşturulan bazı kaynaklar kaldırılmadıysa, Azure CLI’yi kullanarak Azure VMware Çözümü özel bulutunu silmeyi yeniden deneyebilirsiniz.
• Azure VMware Çözümü 2. Nesil, müşteri ve yönetim ağ trafiğini ayırt etmek için bir HTTP Ara Sunucusu kullanır. Bazı VMware bulut hizmeti uç noktaları , genel vCenter tarafından yönetilen trafikle aynı ağ yolunu veya ara sunucu kurallarını izlemeyebilir. Örnekler şunlardır: "scapi.vmware" ve "apigw.vmware." VAMI proxy'si, vCenter Server Appliance'ın (VCSA) genel giden İnternet erişimini yönetir, ancak tüm hizmet uç noktası etkileşimleri bu proxy üzerinden akmıyor. Bazı etkileşimler doğrudan kullanıcının tarayıcısından veya tümleştirme bileşenlerinden kaynaklanır ve bunun yerine iş istasyonunun proxy ayarlarını izler veya bağlantıları bağımsız olarak başlatır. Sonuç olarak, VMware bulut hizmeti uç noktalarına yönelik trafik VCSA proxy'sini tamamen atlayabilir.
• Gen 2 üzerinde HCX RAV ve Toplu geçişler, Base Sync ve Online Sync aşamaları sırasındaki takılmalar nedeniyle daha yavaş performans sergileyebilir. Müşteriler daha uzun geçiş pencereleri planlamalı ve şimdilik buna göre dalgalar zamanlamalıdır. Uygun iş yükleri için, konak ve ağ koşulları izin verildiğinde vMotion daha hızlı ve düşük ek yük seçeneği sunar.
• Sanal HUB (sanal WAN) eşlemesi: 2. Nesil sanal ağı ile sanal hub (sanal WAN) arasında eşleme bağlantısı kurmak için, sanal hub'ın 2. Nesil sanal ağıyla aynı bölgede olması gerekir. Farklı bir bölgedeki bir sanal hub ile eşlemeniz gerekiyorsa, Azure portalı aracılığıyla bir Destek Olayı oluşturmanız gerekir.
• Eşlenik bir Sanal Ağdan (VNET) /32 rota hedefine erişim: NSX'ten /32 rotaları (HCX MON rotaları veya DNS ileticisi rotaları gibi) duyuruyorsanız ve eşlenik bir sanal ağdan bu /32 hedefine erişmeniz gerekiyorsa, Azure portalında bir Destek Talebi açmanız gerekir. /32 hedefine bağlantı, yerel sanal ağın içinden doğru şekilde çalışır.
• VNET Peer Sync Alt Ağ Duyurusu ve Azure Rota Tablosu (UDR) İlişkilendirmesi – Azure VMware Çözümü 2. Nesil iki dahili mimari kullanır. Mevcut mimari, NSX segmenti veya alt ağ rotaları için hem belirli alt ağları hem de daha geniş Azure adres alanını eşlenmiş Azure sanal ağlarıyla eşzamanlar. Sonuç olarak, 2. Nesil'in geçerli mimarisiyle, Azure VMware Çözümü iş yükü segmentleri için genel adres alanı yollarını kullanmak yerine daha belirli NSX segment alt ağ yolları ile Azure yönlendirme tabloları (UDR) yapılandırmanız gerekebilir.

Desteklenmeyen tümleştirmeler

Aşağıdaki 1. taraf ve 3. taraf tümleştirmeleri kullanılamaz:

• Zerto DR

2. Nesil için Temsilci Alt Ağları ve Ağ Güvenlik Grupları

bir Azure VMware Çözümü (AVS) 2. Nesil özel bulut dağıtıldığında, Azure özel bulut ana bilgisayar sanal ağı içinde otomatik olarak birkaç temsilci alt ağı oluşturur. Bu alt ağlar özel bulut yönetim bileşenlerini yalıtmak ve korumak için kullanılır.

Müşteriler, Azure portalında veya Azure CLI/PowerShell aracılığıyla görünen Ağ Güvenlik Gruplarını (NSG) kullanarak bu alt ağlara erişimi yönetebilir. MÜŞTERI tarafından yönetilebilen NSG'lere ek olarak, AVS kritik yönetim arabirimlerine sistem tarafından yönetilen ek NSG'ler uygular. Sistem tarafından yönetilen bu NSG'ler müşteriler tarafından görünür veya düzenlenebilir değildir ve özel bulutların varsayılan olarak güvenli kalmasını sağlamak için mevcuttur.

Varsayılan güvenlik duruşunun bir parçası olarak:

• Müşteri açıkça etkinleştirmediği sürece özel bulut için İnternet erişimi devre dışı bırakılır.
• Yalnızca gerekli yönetim trafiğinin platform hizmetlerine ulaşmasına izin verilir.

Uyarı

Azure portalında belirli bağlantı noktalarının İnternet'e açık gibi göründüğünü belirten bir uyarı görebilirsiniz. Bunun nedeni portalın yalnızca müşteri tarafından görünen Ağ Güvenlik Grubu (NSG) yapılandırmasını değerlendirmesidir. Ancak, Azure VMware Çözümü portalda görünür olmayan ek sistem tarafından yönetilen Ağ Güvenlik Grupları da uygular. Bu sistem tarafından yönetilen Ağ Güvenlik Grupları, erişim Azure VMware Çözümü yapılandırma aracılığıyla açıkça etkinleştirilmediği sürece gelen trafiği engeller.

Bu tasarım, AVS ortamının güvenli ve varsayılan olarak birbirinden ayrılmasını sağlarken, müşterilerin ağ erişimini kendi ihtiyaçlarına göre yönetmesine ve ayarlamasına izin veriyor.

Yönlendirme ve alt ağ ile ilgili dikkat edilmesi gerekenler

Azure VMware Çözümü 2. Nesil özel bulutlar, şirket içi ve Azure tabanlı ortamlardan veya kaynaklardan kullanıcılara ve uygulamalara erişilebilen bir VMware özel bulut ortamı sağlar. Bağlantı standart Azure Ağ üzerinden teslim edilir. Bu hizmetleri etkinleştirmek için belirli ağ adresi aralıkları ve güvenlik duvarı bağlantı noktaları gereklidir. Bu bölüm, ağınızı Azure VMware Çözümü ile çalışacak şekilde yapılandırmanıza yardımcı olur.

Özel bulut, standart Azure ağı kullanarak Azure sanal ağınıza bağlanır. Azure VMware Çözümü 2. Nesil özel bulutlar, alt ağlar için en az /22 CIDR ağ adresi bloğu gerektirir. Bu ağ şirket içi ağlarınızı tamamlar, bu nedenle adres bloğu aboneliğinizdeki diğer sanal ağlarda ve şirket içi ağlarda kullanılan adres bloklarıyla çakışmamalıdır. Yönetim, vMotion ve Çoğaltma ağları bu adres bloğunda otomatik olarak sanal ağınızda alt ağ olarak sağlanır.

Uyarı

Adres bloğunuz için izin verilen aralıklar RFC 1918 özel adres alanlarıdır (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), 172.17.0.0/16 hariç. Çoğaltma ağı AV64 düğümleri için geçerli değildir ve gelecekteki bir tarihte genel kullanımdan kaldırılması planlanmaktadır.

VMware NSX kullanımı için ayrılmış aşağıdaki IP şemasını kullanmaktan kaçının:

• 169.254.0.0/24 - iç aktarım ağı için kullanılır
• 169.254.2.0/23 - VRF arası geçiş ağı için kullanılır
• 100.64.0.0/16 - T1 ve T0 ağ geçitlerini dahili olarak bağlamak için kullanılır
• 100.73.x.x – Microsoft'un yönetim ağı tarafından kullanılır

Uyarı

Tabloda listelenen alt ağların çoğu, Azure sanal ağı içinde alt ağ olarak gösterilir. Bunlar Azure VMware Çözümü kontrol düzlemi tarafından yönetildiğinden ve herhangi bir değişikliğin olumsuz sonuçları olabileceğinden lütfen alt ağ yapılandırmasında el ile değişiklik yapmayınız.

Örnek /22 CIDR ağ adres bloğu 10.31.0.0/22 aşağıdaki alt ağlara ayrılmıştır:

Ağ Kullanımı	Alt ağ	Açıklama	Örnek
VMware NSX Ağı	/27	NSX Yöneticisi ağı.	10.31.0.0/27
vCSA Ağı	/27	vCenter Server ağı.	10.31.0.32/27
avs-mgmt	/27	Yönetim araçları (vCenter Server, NSX Manager ve HCX Cloud Manager), "avs-mgmt" alt ağının arkasında yer alır ve bu alt ağda ikincil IP aralıkları olarak programlanmıştır. Yönetim gereçleriniz için ağ trafiğinizin bir NVA veya güvenlik duvarı üzerinden yönlendirilmesi gerekiyorsa, bu alt ağ ile ilişkili yol tablolarını ayarlamanız gerekebilir	10.31.0.64/27
avs-vnet-sync	/27	Azure VMware Çözümü 2. Nesil tarafından VMware NSX'te oluşturulan yolları sanal ağa programlamak için kullanılır.	10.31.0.96/27
avs-services	/27	Azure VMware Çözümü 2. Nesil sağlayıcı hizmetleri için kullanılır. Özel bulutunuz için özel DNS çözümlemesini yapılandırmak için de kullanılır.	10.31.0.224/27
avs-nsx-gw, avs-nsx-gw-1	/27	İki avs-nsx-gw alt ağı, Azure VMware Çözümü'dan Sanal Ağ ve ötesine giden tüm trafiği işler. Bu nedenle, Azure yönlendirme tabloları (UDR) ve Ağ Güvenlik Grupları (NSG) her senaryoda bu alt ağlara uygulanmalıdır. İlk AVS 2. Nesil özel bulutlarında, bu alt ağlar gelen trafiği de yönetir ve tüm NSX segment alt ağları ikincil IP'ler olarak yapılandırılır. Geçerli AVS 2. Nesil özel bulutlarında, tüm gelen trafiği işlemek için "avs-network-infra-gw" olarak bilinen üçüncü bir alt ağ eklenir. Artık tüm NSX kesimleri avs-nsx-gw alt ağları yerine bu alt ağa atanır.	10.31.0.128/27, 10.31.0.160/27
avs-network-infra-gw	/26	Bu alt ağ mevcut olduğunda, VNET'ten tüm NSX iş yükleri için gelen trafiği işler ve NSX segment alt ağlarını ikincil IP'ler olarak yapılandırmak için Azure VMware Çözümü yönetimi tarafından kullanılır. Herhangi bir Azure yönlendirme tablosunu bu alt ağ ile ilişkilendirmekten kaçının; bunun yerine, Azure Güvenlik Duvarı veya üçüncü taraf Ağ Sanal Gereçleri (NVA) gibi giden AVS trafiğini yönetmek için "avs-nsx-gw" alt ağını kullanın.	10.31.2.128/26
esx-mgmt-vmk1	/25	vmk1, müşterilerin konağa erişmek için kullandığı yönetim arabirimidir. vmk1 arabiriminden IP'ler bu alt ağlardan gelir. Tüm ana bilgisayarlar için vmk1 trafiği, bu alt ağ aralığından gelir.	10.31.1.0/25
esx-vmotion-vmk2	/25	vMotion VMkernel arabirimleri.	10.31.1.128/25
esx-vsan-vmk3	/25	vSAN VMkernel arabirimleri ve düğüm iletişimi.	10.31.2.0/25
Rezerve edildi	/27	Ayrılmış Alan.	10.31.0.128/27
Rezerve edildi	/27	Ayrılmış Alan.	10.31.0.192/27

Uyarı

Azure VMware Çözümü 2. Nesil dağıtımları için müşterilerin artık SDDC dağıtımı sırasında girilen /22'ye ek olarak HCX yönetimi ve yukarı bağlantı için iki ek /24 alt ağı ayırması gerekir. AVS 2. Nesil'de yalnızca HCX mgmt ve HCX yukarı bağlantı alt ağları gereklidir. vMotion ve çoğaltma ağları AVS 2. Nesil için gerekli değildir.

NSX programlamayı Azure Sanal Ağ yönlendirir

Azure VMware Çözümü 2. Nesil NSX yolları, adres alanı kullanılarak ve bunları sistem tarafından oluşturulan "avs-network-infra-gw" alt ağında ikincil IP'ler olarak atayarak Azure ile tümleştirilir ve Azure ile AVS müşteri iş yükleri arasında sorunsuz bağlantı sağlar. NSX Tier-0, kesim oluşturma, statik yollar ekleme veya HCX MON sanal makinelerini kullanma gibi kullanıcı ayarlarına dayalı bir yol tanıttığında, Azure VMware Çözümü denetim düzlemi yol ön ekinin sanal ağ adres alanında bulunup olmadığını denetler. Bunu yapmazsa, adres alanını oluşturur ve yol ön ekini "avs-network-infra-gw" alt ağına ikincil IP'ler olarak ekler. HCX MON rotaları gibi duyurulan Tier-0 /32 rotaları için ikincil IP’ler yapılandırılmaz, ancak veri düzlemi, Azure VMware Çözümü’daki /32 hedeflere bağlantının sağlanması için dahili olarak yapılandırılmıştır.

NSX yönlendirmeleri için adres alanı ve alt ağlara yönelik güncellemeye ek olarak, özellikle daha düşük alt ağ maskeleri kullanıldığında desteklenen ölçek sınırlarıyla ilgili olarak müşterilerin bilmesi gereken bazı iç mekanizmalar da vardır. Ölçeklendirme yönü hakkında daha fazla bilgi için bkz: Azure VMware Çözümü 2. Nesil için Yönlendirme mimarisi

Azure Yönlendirme Tablosu (UDR) İlişkilendirmesinde Dikkat Edilmesi Gerekenler

Azure VMware Çözümü 2. Nesil, hafif varyasyonlu iki iç mimari içerir. İlk 2. Nesil özel bulutlarından bazıları ilk iç mimariyi kullanır. Bunlar, müşteriyle eşgüdümlü olarak zamanlanmış bakım aracılığıyla geçerli mimariye güncelleştirilir. Ancak, aşağıda açıklandığı gibi, ilk mimariye kıyasla geçerli mimariyle ilgili davranışta bazı ağ tasarımı konularını etkileyebilecek bir değişiklik vardır.

İlk 2. Nesil özel bulutlar:

• Azure sanal ağının "avs-nsx-gw" adlı iki temel ağ geçidi alt ağı vardır ve geçerli mimaride olduğu gibi "avs-network-infra-gw" alt ağına sahip değildir.
• Tüm AVS NSX segment alt ağları, Azure NSX iş yüklerine bağlamak için ek IPv4 adresi olarak "avs-nsx-gw" alt ağı altında programlanır.
• AVS'den Azure sanal ağa ve ötesine (şirket içi) giden trafik için yol tablosunun (UDR) veya Azure NSG'sinin "avs-nsx-gw" alt ağına uygulanması gerekir.

Mevcut 2. Nesil özel bulutu:

Bu davranış değişikliğini not almayı unutmayın.

• Azure VNET’te, başlangıç mimarisindeki gibi "avs-nsx-gw" adlı iki temel ağ geçidi alt ağına ek olarak "avs-network-infra-gw" önekine sahip ek bir alt ağ bulunur.
• Tüm AVS NSX segment alt ağları artık bu alt ağ altında Azure NSX iş yüklerine bağlanmak için ikincil IPv4 adresi olarak programlanmıştır. Bu, müşteri ağ bağlantısını değiştirmez.
• VNET eşlemesi, hem adres alanını hem de alt ağları eşlenmiş VNET’e duyurur; bu, yalnızca adres alanının eşitlendiği ilk mimariden veya Azure yerel VNET eşitlemesinden farklıdır.

2. Nesil iç mimarideki değişikliklerden kaynaklanan tasarım konuları

• Müşteriler, sanal ağ eş eşitleme davranışındaki değişiklik nedeniyle eşlenen sanal ağ içindeki AVS alt ağları için ek etkili yollar gözlemler.
• Müşteri güvenlik duvarı veya ağ sanal gereci aracılığıyla şirket içinden AVS'ye trafik göndermek için bir Azure yönlendirme tablosu (UDR) kullanıyorsa, UDR'yi daha önce kullanılan geniş süper ağ adres aralığı yerine belirli NSX alt ağ yollarını kullanacak şekilde güncelleştirmelidir. Bu, Azure yönlendirmesinin en uzun ön ek eşleşmesi davranışı nedeniyle AVS’ye yönelik trafiğin daha spesifik VNET alt ağ yollarını izleyerek amaçlanan güvenlik duvarını atlamasını önlemek için gereklidir. Aksi takdirde, bu durum asimetrik yönlendirmeye neden olabilir ve bağlantı sorunlarına neden olabilir.
• Ancak, AVS'den Azure VNET'e ve ötesine (örneğin şirket içi ortama) giden trafik için yol tablosu (UDR) veya Azure NSG, "avs-network-infra-gw" alt ağlarına değil, "avs-nsx-gw" alt ağlarına uygulanmaya devam edecektir. NSX segment alt ağları ikincil IP olarak yapılandırılmış olsa bile müşterilerin "avs-network-infra-gw" alt ağında yönlendirme tablosunu (UDR) kullanmaması gerekir.

Sonraki adımlar

• önkoşul olarak Azure VMware Çözümü hizmet sorumlunuzu yapılandırmaya başlayın. Nasıl yapılacağını öğrenmek için bkz. Azure VMware Çözümü hizmet sorumlusu ilkesi etkinleştirme hızlı başlangıcı.

• Azure VMware 2. Nesil Özel Bulut Oluşturma öğreticisini izleyin