VMware HCX Mobility için İyileştirilmiş Ağ (MON) kılavuzu

Not

VMware HCX Mobility için İyileştirilmiş Ağ, VMware ve HCX sürüm 4.1.0'dan Azure VMware Çözümü tarafından resmi olarak desteklenir.

Önemli

HCX MON'u etkinleştirmeden önce lütfen aşağıdaki sınırlamaları ve desteklenmeyen yapılandırmaları okuyun:

HCX NE için desteklenmeyen kaynak yapılandırmaları

MON dahil tüm HCX dağıtımları için sınırlamalar

VMware HCX Mobility için İyileştirilmiş Ağ (MON) 3. taraf ağ geçidi kullanımıyla desteklenmez. Yalnızca ağ sanal gereci (NVA) olmadan doğrudan T0 ağ geçidine bağlı olan T1 ağ geçidiyle kullanılabilir. Bu yapılandırma işlevini yapabilirsiniz, ancak desteklemiyoruz.

HCX Mobility için İyileştirilmiş Ağ (MON), HCX Ağ Uzantıları (NE) kullanılırken etkinleştirilecek isteğe bağlı bir özelliktir. MON, genişletilmiş ağlardaki şirket içi ve bulut tabanlı kaynaklar arasında ağ bağlamasını önlemek için belirli senaryolar altında en iyi trafik yönlendirmesini sağlar.

MON, NE özelliğinin kurumsal bir özelliği olduğundan, Azure portalı aracılığıyla VMware HCX Enterprise'ı etkinleştirdiğinizden emin olun.

Mon, geçiş döngüsü boyunca uygulama mobilitesini aşağıdakiler için iyileştirir:

• Esnetilmiş ağlar kullanılırken sanal makineden (VM) VM L2'ye iletişimi iyileştirme

• Şirket içi, Azure VMware Çözümü ve Azure arasındaki asimetrik trafik akışlarını iyileştirme ve önleme

Bu makalede MON için Azure VMware Çözümü özel kullanım örnekleri hakkında bilgi edinin.

Özel bulut tarafında standart ve esnetilmiş segmentler arasında trafik akışlarını iyileştirme

Bu senaryoda VM1, VM gecikme süresi için en uygun VM'yi sağlayan NE kullanılarak buluta geçirilir. Sonuç olarak, VM1'in yerel Azure VMware Çözümü segmentindeki VM3 için düşük gecikme süresine ihtiyacı vardır. Trafik için en uygun yolu (mavi çizgi) sağlamak için VM1 ağ geçidini şirket içinden Azure VMware Çözümü (bulut) geçişini yapıyoruz. Ağ geçidi şirket içinde (kırmızı çizgi) kalırsa, bir bağlama etkisi ve daha yüksek gecikme süresi gözlemlenir.

Not

VM ağ geçidini bulut tarafına geçirmeden MON'yi etkinleştirdiğinizde, trafik akışı için en uygun yolu sağlamaz. Ayrıca ilke yollarının değerlendirilmesi için izin vermez.

Asimetrik trafik akışlarını iyileştirme ve önleme

Bu senaryoda, şirket içi bir VM'nin Azure VMware Çözümü geçirilip L2'ye katıldığını ve hizmetlere erişmek için L3 trafiğinin şirket içi akışlara geri döndüğünü varsayarız. Ayrıca Azure'dan bazı VM iletişimlerinin (bağlı Azure VMware Çözümü sanal ağda) Azure VMware Çözümü özel buluta ulaşabileceğini varsayıyoruz.

Önemli

Buradaki ana nokta, asimetrik trafik akışlarını dikkatle planlamak ve önlemektir.

Varsayılan olarak ve MON kullanmadan esnetilmiş bir ağda Azure VMware Çözümü bir VM, ExpressRoute tercih edilen yolunu kullanarak şirket içiyle iletişim kurabilir. Müşteri kullanım durumlarına bağlı olarak, MON ile etkinleştirilmiş Azure VMware Çözümü esnetilmiş segmentteki bir VM'nin Ağ Uzantısı veya ExpressRoute aracılığıyla T0 ağ geçidi üzerinden şirket içi geçiş yaparken trafik akışlarını simetrik tutması gerektiğini değerlendirmeniz gerekir.

Örneğin NE yolunu seçerseniz, MON ilke yollarının şirket içi tarafında alt ağı özellikle ele alınması gerekir; aksi takdirde, 0.0.0.0/0 varsayılan yolu kullanılır. İlke yolları, gelişmiş'i seçerek NE segmentinin altında bulunabilir.

Varsayılan olarak, tüm RFC 1918 IP adresleri MON ilkesi yol tanımına eklenir.

Bu, tüm RFC 1918 çıkış trafiğinin NE yolu üzerinden tünellenmesini ve tüm İnternet ve genel trafiğin T0 ağ geçidine yönlendirilmelerine neden olur.

İlke yolları yalnızca VM ağ geçidi buluta geçirildiğinde değerlendirilir. Bu yapılandırmanın etkisi, hedef için eşleşen alt ağların NE gereci üzerinden tünel oluşturmasıdır. Eşleşmezse, T0 ağ geçidi üzerinden yönlendirilirler.

Not

Azure VMware Çözümü mon'u kullanırken dikkat edilmesi gereken özel nokta, BGP üzerinden tanıtılan /32 yollarının eşlerine verilmesidir; buna ExpressRoute bağlantısı üzerinden şirket içi ve Azure dahildir. Örneğin Azure'daki bir VM, Azure VMware Çözümü MON özellikli bir kesimde Azure VMware Çözümü VM'nin yolunu öğrenir. Dönüş trafiği beklendiği gibi T0 ağ geçidine geri gönderildikten sonra, dönüş alt ağı bir RFC 1918 eşleşmesiyse, trafik T0 yerine NE üzerinden zorlanır. Ardından ExpressRoute üzerinden şirket içi tarafında Azure'a geri döner. Bu durum bilgisi olan güvenlik duvarlarının orta ve asimetrik yönlendirme davranışında karışıklığa neden olabilir. Ayrıca, NE MON segmentlerindeki VM'lerin Azure VMware Çözümü'daki T0 ağ geçidi üzerinden veya yalnızca NE üzerinden şirket içi ortamdan İnternet'e nasıl erişmesi gerektiğini belirlemek de iyi bir fikirdir. Genel olarak, asimetrik trafiği önlemek için varsayılan ilke yollarının tümü kaldırılmalıdır. yalnızca ağ altyapısı asimetrik trafiği hesaba katacak ve önleyecek şekilde yapılandırılmışsa ilke yollarını etkinleştirin.

MON ilkesi yolları tanımlı olmayan bir şekilde silinebilir. Bu, tüm çıkış trafiğinin T0 ağ geçidine yönlendirildiğine neden olur.

MON ilkesi yolları varsayılan bir yol (0.0.0.0/0) ile güncelleştirilebilir. Bu, tüm çıkış trafiğinin NE yolu üzerinden tünellenmesini sağlar.

Yukarıdaki diyagramlarda açıklandığı gibi, bir ilke yolunu gerekli her alt ağ ile eşleştirmek önemlidir. Aksi takdirde trafik T0 üzerinden yönlendirilir ve NE üzerinden tünel oluşturulmaz.

İlke yolları hakkında daha fazla bilgi edinmek için bkz . Mobility için İyileştirilmiş Ağ İlkesi Yolları.