NSX-T Data Center Nedir? Genel Mimari

Merhaba, NSX-T Data Center Nedir? Genel mimari nasıldır? Başlangıç yazısına hoş geldiniz. Bu yazıda öncelikle NSX-T Data Center hakkında genel dizayn ve mimari üzerine konuşacağım sonrasında parça parça gelecek olan dökümanlar bütünü tüm mimariyi içerecek şekilde köşe noktaları da içererek bir rehber niteliği taşıyacaktır.

Öncelikle NSX-V ve NSX-T için bir çok projede yer almış birisi olarak söylemeliyim ki kişisel olarak bu yayına çok geç kalmış olmak biraz canımı sıkmakta. Ancak zamanın yetersizliği en temel sebeplerden birisi bunu da bilmenizi isterim 🙂 

Genel olarak mimariden bahsetmeden önce şu yazımı okuyarak konsept hakkında bilgi sahibi olmanızı öneririm; VMware NSX Nedir?  

Rehber İçeriğinde Neler Var?

• NSX-T Deployment – İlk Kurulum
• NSX-T Manager Cluster Kurulum ve İncelemesi
• NSX-T Manager Node ve Cluster Sertifika Değişimi
• NSX-T Host Uplink Profilleri
• NSX-T Edge Uplink Profilleri
• Named Teaming Policy
• NSX-T Transport Zone ( VLAN – Overlay)
• N-VDS Yapısı ve Özellikleri
• NSX-T Host Transport Node – Transport Node Profile
• NSX-T Edge Transport Node – Edge Cluster Profile
• ESXi Transport Node – NSX-T installation
• KVM Transport Node – NSX-T installation
• Edge Transport Node 
• NSX-T Logical Switching
• NSX-T Logical Routing
• NSX-T Static Routing
• NSX-T BGP 
• NSX-T T0 ve T1 router
• NSX-T Bridge Profiles – Bridging
• NSX-T Gateway Firewall
• Microsegmentation – NSX-T Distributed Firewall
• NSX-T Distributed Context Firewall
• NSX-T Identity Firewall
• Bare Metal Networking ve Security
• NSX-T Load Balancer
• One-Arm vs. In-Line Load Balancing
• NSX-T Segment Profiles
• NSX-T DHCP
• NSX-T DNS ve IPAM
• NSX-T SNAT – DNAT – Reflexive NAT – NoSNAT – NoDNAT
• NSX-T Service Insertion – TrendMicro Deep Security
• NSX-T Service Insertion – FortiGate VMX
• NSX-T Service Insertion – CheckPoint
• NSX-T Container Networking – Load Balancing
• NSX-T Kubernetes Networking ve PKS
• vRealize Automation ve NSX-T
• NSX-T ve NSX Intelligence
• NSX Advanced Load Balancer by Avi Networks

NSX-T Ögeleri Nelerden oluşur?

NSX Manager Appliance

NSX Manager içerisinde NSX controller’ı da barındıran, grafiksel ve REST API yoluyla sistem geneli konfigürasyonları yapabilmemizi sağlayan, management plane’de bulunan yönetim modülüdür. NSX Manager Management Plane Agent (MPA) yardımı ile kendi domaininde olan tüm hypervisor’ları desired state’de tutma işini yapar.  

ESXi veya KVM üzerine deploy edilebilir. Temel olarak tek node yeterli olsada production için kullanılacaksa kesinlikle Large sized ve 3 Node içeren cluster olmalıdır. 

NSX Controller

NSX Controller aynı zamanda Central Control Plane (CCP) olarak adlandırılan, Sanal networkleri ve overlay’de bulunan transport tunnelleri kontrol eden dağıtık bir durum yönetim sistemidir. 

Türkçesi şudur ki bu arkadaşın işi bizlerin yapmış olduğu konfigürasyon değişikleri (yeni switch yaratma, yeni transport zone, static route değişimi gibi vs.) ve dahi sistemde oluşan forwarding durum değişikliklerinin hostlar üzerinde bulunan Local Control Plane’lere dağıtılmasıdır. Her biri bir NSX Manager node içerisinde olmakla birlikte NSX-T 2.4’den itibaren dağıtık üç parçadan oluşmaktadır. Üst tarafta bahsettiğim üzere Control Plane’de yer almaktadır. NSX-T managerin ve controller’ın fail olması trafiğin aksamasına sebep olmaz. Yaptıkları en önemli işlerden birisi sharding’dir ki bu da Transport Node’ları paylaşarak iş yükü dağıtımı yapmaktır. Bu durumda 3 node içeren controller cluster altında çalışan 9 ESXi host varsa her bir controller 3 host’un sahipliğini edinecek gerekli güncellemeleri kendi ESXi hostlarının Local Control Plane’lerine geçecektir.

NSX Edge

NSX Edge, görevi network servisleri sunmak ve fiziksel dünya ile iletişim kurmamızı sağlamak olan ve bu işi docker container imajları ile yapan boş bir container hosttur. Data Plane’de yer alır ve fail olması durumunda kesintiye sebep olabilir. İki farklı şekilde kullanılabilir ki bunlardan birincisi Sanal Makine formundadır ve ESXi üzerinde çalıştırılabilir. İkinci seçenek ise NIC ve CPU isterlerini karşılamanız durumunda Bare Metal’dir ki bu şekli ile boş bir fiziksel sunucuyu hem router hem load balancer hem firewall yapmanız mümkündür. NSX Edge üzerinde yapabileceğimiz tüm işler içerisinde oluşturacağımız T1 ve T0 router’lara bağlı olacaktır ki bunlarda söylediğim gibi aslında docker process’leridir. Aşağıya ilgili bir çıktı paylaşıyorum. NSX Edge’e root account ile login olduğunuzda aşağıdaki gibi ilgili imajları ve ps’leri görmeniz mümkündür. 

NSX Intelligence

NSX intelligence, NSX-T’den ayrı olarak paketlenen ve mikro-segmentasyon için derin flow analizi yapan bir ek appliance’dır. Şuanda 1.1 sürümündedir. Yaptığı iş genel olarak microsegmentasyon focus olsa da çok önemli bir sorunu adreslediğinden şimdilik inanılmaz kullanışlı bir tool olduğunu söyleyebilirim. Sonrasında ürün hakkında detay vereceğim. Şuan için yeni sürümü beklemekteyim..

NSX-T Konseptleri Nelerdir?

Dizayn ve Kurulum tarafını konuşmadan önce NSX-T’de var olan konseptleri konuşmak önem arzetmekte. Overlay dediğimizde ne anlamalıyız underlay dendiğinde kim ne anlamalı yok efendim segment, T0, T1 dendiğinde kim neyi işaret eder. Gelin birlikte inceleyelim.

• Compute Manager
  Compute manager kaynak yönetimi gerçekleştiren uygulamalardır. Örneğin vCenter Server.
• Management Plane
  Kullanıcı konfigürasyonu için tek bir yönetim noktası sağlayan modüldür. Temel amacı API veya arayüzden yapılan değişiklikleri control plane aracılığıyla tüm network’e yaymaktır. SDN mimarisinin merkezcil network yönetim noktasıdır.
• Control Plane
  Management Plane’den alınan konfigürasyonu ve data plane’den toplanan durumu forward engine’a yaymakla mükellef olan boyut. Örnek olarak NSX controller.
• Data Plane
  Paketlerin iletilmesi veya transform edilmesi işi ile ilgilenir burada control plane’den alınan forwarding kararlarına göre hareket eder. Bununla birlikte control plane’e mevcut topoloji bilgisini verir ve paket seviyesinde istatistik tutar. (şu kadar paket geçti bu kadar paket drop oldu)
• External Network
  NSX-T tarafından yönetilmeyen network’ü temsil eder. Örnek olarak aynı DC içerisinde olsa bile Fiziksel ortamda veya NSX dışında bulunan AD serverlarınız external networkdür.
• Logical Port Egress
  Çıkış yönlü trafiğe verilen isimdir. Çıkış VM’den veya logical networkden olabilir. Yani NSX domainini terk eden trafiktir.
• Logical Port Ingress
  Giriş yönlü trafiğe verilen isimdir. Giriş VM’e doğrudur.
• Logical Router
  Routing yapabilme kapasitesine sahip router instancedır. Örnek olarak T1 veya T0 router.
• Logical Router Port
  T1 veya T0 router üzerinde oluşturalan, logical switch’e veya external network’e bağlanmak için kullanılan port.
• Logical Switch
  Fiziksel networking’de layer 2’ye denk gelen NSX instance’dır. Burada forwarding yazılım katmanında yapılır ve oluşan segmentler birbirinden izoledir. Bir hypervisor üzerinde birden fazla logical switch oluşturulabilir.
• Logical Switch Port
  Logical router veya VM’e bağlantı noktasıdır.
• NSX Edge Cluster
  NSX Edge nodelardan oluşan cluster yapısı. Aynı işi yapan veya yapabilecek iş gücü bütünü olarak düşünebilirsiniz. 
• NSX Edge Node
  IP routing veya IP bazlı servislerin sağlanmasında kullanılan iş gücüdür. VM veya Bare metal sunucu olabilir. Ubuntu bazlıdır ve içerisinde docker çalışır. Her bir servis için docker process’leri oluşur.
• NSX N-VDS veya Open vSwitch
  vCenter Server’dan bildiğimiz VDS’in enhanced datapath destekleyen versiyonudur. NSX-T’de bir iş yapacaksanız N-VDS kullanmama şansı yoktur. Standart ve Enhanced DataPath modları vardır ki bunları sonrasında açıklayacağım. 
• NSX Manager Cluster
  Toplamda üç node’dan oluşan NSX Manager bütünüdür.
• Open vSwitch (OVS)
  Linux Based hypervisor’ler için virtual switch fonksiyonu sağlayan open source bir yazılımdır. N-VDS’in KVM, Xen gibi hypervisorler için karşılığı denilebilir.
• Overlay Logical Network
  Fiziksel network’den ayrıştırılmış, layer-2 trafiği layer-3 üzerinde döndürebilmemizi sağlayan ve tunneling mekanizması kullanan network tipidir. Sanal makine network’ün overlay veya fiziksel olduğunun farkında değildir. Basit olarak akışta standart ethernet frame yeniden framelenerek tunelin karşı noktasına teslim edilir.
• Physical Interface (pNIC)
  Fiziksel server üzerindeki Network Interface Card’ı işaret eder.
• Virtual Interface (vNIC)
  Sanal Makine üzerindeki Network Interface Card’ı işaret eder. N-VDS, VDS, OVS, VSS bağlantı noktasıdır.
• Segment
  NSX-T ile oluşturulabilen Layer 2 switching mekanizmasına sahip ve birden fazla VM barındırabilen broadcast domaindir. Fiziksel server bağımlılığı yoktur ve dağıtık bir yapıda local instance’larla çalışır. Yani NSX üzerinde koşan üç hostunuz varsa bunların hepsinde aynı state’de olan segment vardır. Logical switch ile aynı şeydir.

Biraz Daha Konsept 🙂

• Tier-0 Gateway veya T0 Logical Router
• Tier-1 Gateway veya T1 Logical Router
• Service Router (SR)
• Distributed Router (DR)
  Stateless bir yapıda packet forwarding yapan ve tüm node’ların üzerinde bulunan Router’dır. Örnek olarak 3 ESXi hostunuz var gittiniz bir T1 oluşturdunuz, 3 kopyaya sahip 1 Adet DR elde edeceksiniz. Her ESXi üzerindeki DR aslında aynıdır. 
• Transport Zone (TZ)
  Datanın akacağı domaindir. Bu domainde olmayan ilgili networkler ile ilişkilendirilemez.
  
• Transport Node (TN)
  ESXi, KVM, Edge, Baremetal nodeları temsil eder. Datapath’de duran herkes.
• Uplink Profile
• Virtual Tunnel Endpoint (VTEP)
• Overlay
• Underlay

Genel Routing Mimarisi Nasıldır?

Yukarıdaki yapıda görüldüğü üzere genel routing mimarisi T0, T1 router ve segment instance’lardan oluşmaktadır. Burada DR distributed router anlamına gelmektedir ve T1-T0 DR tüm transport nodelarda bulunabilmektedir. Bu durumda DR oluşturmak için Edge Cluster gerekmemektedir. Ancak merkezcil ve stateful servis çalıştırmak  istiyorsanız Service Router’a (SR) ihtiyaç vardır. SR’a ihtiyaç olan durumda ise merkezcil kaynak gücünü sağlayacak bir Edge Cluster gereklidir. Şu durumlar için SR gerekmektedir diyebiliriz;

• Gateway Firewall
• VPN
• Bridging
• Service Interface
• Physical network connectivity
• NAT
• DHCP
• Metadata Proxy

DHCP server yapmak istiyorsanız, NAT yapmak istiyorsanız veya NSX’in VPN servisinden yararlanmak istiyorsanız ya da en basiti fiziksel network’e NSX networkünü bağlamak istiyorsanız Edge VM veya Baremetal deploy ederek Cluster oluşturmanız gerekmektedir. SR ve DR instance’ları arayüzden aşağıdaki gibi görebilmemiz mümkündür. 

Burada SR sayısı iki DR sayısı bir olarak görünmekte ancak aslında bu mantıksal bakıştır. Yani SR sayısı active ve passive olmak üzere gerçekten iki tanedir ama DR TransportZone : GeneveOverlay’e dahil olan her yerde 1 tane olmak üzere toplam Transport Node sayısı kadardır. Bu da Distributed routing’in oyuna girdiği noktadır ki routing aşağıdaki görselde görüldüğü üzere; 

Packet Walk Nasıl Olur?

Aslında bize tek olarak görünen ancak farklı TN’ler üzerinde olan DR’lar arasında gerçekleşir. Yukarıdaki görsele göre ESXi1’de bulunan Web1 VM’i ESXi2’de bulunan App2 VM’ine erişmek istediğinde aslında routing nasıl gerçekleşiyor?

Bu görseli kullanmamın en temel amacı aslında NSX’de routing’in her zaman source’da yapıldığını da söylemek. Dikkat edilirse sağ ve soldaki iki router birebir aynı herşeyiyle. Web1 App2’ye gitmek istediğinde kendi TN’inde bulunan gateway’e paketi gönderiyor. Paket burada networkler arası switch edilerek, hala ESXi1 üzerinde iken app segmentine geçiyor ve yoluna devam ediyor. Verilen cevapta ise paket yine source’da route ediliyor ve gideceği segmente geçiyor (app segmentten – web segmentine) ve hardware’i daha sonra terk ediyor. Biraz daha detaya inersek;

1. Paket Web1’den DR’ın LIF1 interface’ine geldi.
2. Source MAC: MAC1 dest MAC: vMAC, Source IP:172.16.10.11 Dest IP: 172.17.20.12 . Routing table’a bakıldı ve 172.16.20.12 adresinin LIF2’de olduğu ve remote KVM’den MAC2 ile öğrenildiği tespit edildi. Paket LIF2 interface’inden çıkarıldı.
3. Paket ESXi’ı terk etmeden önce Geneve ile enkapsüle edildi ve source MAC ESXi’ın kendisi dest MAC kvm’in vmnic’i oldu. Artık Yeni  SMAC: ESXi DMAC : KVM SIP: 10.10.10.10 DIP: 20.20.20.20 
4. Paket KVM’e ulaştığında geneve dekapsüle edildi ve dış header temizlendi.
5. Routing zaten source’da yapılmıştı ve paket KVM DR LIF2’de olan MAC2 adresine sahip 172.16.20.12 (App2) ulaştı.

Yukarıda gördüğümüz üzere paket yürüyüşü birden fazla adımdan oluşmakta ve Outer header yardımı ile yapılmakta. Yani paket networkde noktadan noktaya geçerken mevcut source destination iç tarafa gömülüp dışına yeni source destination içeren bir ekstra paketleme yapılıyor. Bunu basitçe anlatmak gerekirse istanbul’dan new york’a zarf göndereceğim. Paketin üzerine gönderen  tolgahan alıcı Maria yazıyorum. Daha sonra Ptt alıyor bu zarfı tekrar paketleyerek gönderen istanbul alıcı new york şube yazıyor. New york şubede açılıyor ve daha sonra Maria’nın adresine teslim ediliyor. 

Service Router varsa?

Yukarıda konuştuğumuz senaryo DR to DR senaryosuydu. Peki olayın içerisinde fiziksel network çıkışı veya SR gerektiren bir servis kullanımı varsa neler oluyor?

Burada mantık yine temel olarak aynı Geneve tunnel yardımı ile data TN’ler arası geçiş sağlıyor ancak bir farklılık var ki bu da trafiğin SR’ın bulunduğu yere gelme şartı. Yani ESXi1 üzerindeki VM dış dünyaya çıkmak isterse TEP yardımı ile ESXi2 üzerindeki Edge Node’a gidecek oradan dışarıya çıkacaktır. Geri dönüşte de yine benzer bir yol izlenecektir.

Aşağıdaki görselde bir VM dış dünyaya erişmeye çalışıyor;

Yine burada adım adım olayı incelediğimizde;

1. paket VM’den çıkıyor.
2. Local DR’a geliyor ve burada routing kararı verilip gidilmek istenen subnet’e sadece SR üzerinden ulaşılabileceği görülüyor.
3. Enkapsüle edilip remote edge node’a gönderiliyor.
4. Edge node tarafından alınıp dekapsüle ediliyor.
5. Paket SR’a geçiyor.
6. SR external interface’i yardımıyla paketi fiziksel router veya firewall’a teslim ediyor.

Gördüğünüz üzere burada klasik yapıda olmayan kuzey güneyde datapath’e birde Edge giriyor ve cost artıyor. Bu durum özellikle gateway’ler ToR’da yapılandırılmadıysa ciddi derecede sorunlu bir durum olabilir. Çünkü Edge ve ESXi TEP subnetlerinin farklı olduğu durumlarda birde araya fiziksel gateway girecek, trafik ESXi ile Edge arasında gitmeden önce fiziksel gateway’e gidip oradan geri dönecektir. Bu durum günümüz ASIC çipleri, network kapasitesi ve düşük latency cihazlarla çok önemli görünmese de paketin normalde 2 adımlık yolunu 10 adıma çıkarmamak kaynakların uygun kullanımı açısından önemlidir.

Diğer yandan stateful servislerin bize kazandırdıkları yanında uygun bir dizayn ile bu dezavantaj ciddi bir avantaj olarak kullanılabilir.

Sıkça karşılaştığım sorulardan birisi madem T0, T1’in yaptığı işi yapabiliyor neden o halde segmentleri direkt T0’a bağlamıyoruz?

Açıkcası bu durum uygulanabilir bir durumdur. Ancak güvenlik ve izolasyon sağlamak istediğimizde kaynak isterleri çok fazla olacaktır. Multi tenant bir yapı arzulanıyorsa two-tier yani T1 ve T0’dan oluşan yapı kullanılmalıdır. Bununla beraber Load Balancer kullanımı için T1 gereklidir.

Geneve Nasıl Çalışır?

Bu konuda açıkcası çok fazla detaya girmek istemiyorum. Ancak görselde gördüğümüz üzere 2 frame mevcut. 1.frame original ethernet frame olarak geçen geleneksel mimaride çalışan frame. ikincisi geneve encapsulated frame. Bu da birinci frame’in payload olarak başka bir frame içine sokulmasından ve protokol olarak UDP kullanılmasından başka bir şey değil. Basitçe bilgileri manipüle et şifrele yolla şifreyi bilen karşıdaki açabilsin gibi bir şey. Bir frame’ı başka bir frame içerisine sokmak ek olarak yaklaşık 50 byte kadar fazlalık getirmektedir. Bu yüzden Geneve kullanılacaksa MTU size minimum 1550 olmalıdır veya daha üstü. VMware VXLAN için 1600 Geneve için 1700 önermektedir.

Daha fazla bilgi için durumu kaynağında incelemek iyidir : https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/?include_text=1

Dizayn Neleri Adreslemelidir?

1. Network’ün programlanabilirliği adreslenmelidir.
2. Backup/Disaster Recovery ve hata yönetimi adreslenmelidir.
3. Yazılım tabanlı packet processing ve forwarding yapılabildiği adreslenmelidir.
4. Yapının amacı ve mimari şekli açık olarak adreslenmelidir.
5. Kullanıcı gereklilikleri, varsayımlar, riskler ve kısıtlayıcı öğeler adreslenmelidir.
6. Underlay olarak kullanılacak network yapılandırması ve NSX ile ilgisi bulunacak olan network topolojisi adreslenmelidir.
7. Scalability ve High availability adreslenmelidir.
8. Alternatif dizayn kararları ile potansiyel risk savunması adreslenmelidir.
9. Yönetecek ekipler için içerik anlaşılır olmalıdır.
10. Sanal Network Servisleri (varsa) adreslenmelidir.

Kurulum İçin Gereksinimler Nelerdir?

Öncelikle uyumluluk listesini kontrol ederek uygun hypervisor sürümlerine sahip olunması gerekmektedir. ESXi için şuradan ulaşabilirsiniz. 
2.5 Sürümü için Bare Metal Supported işletim sistemleri de şurada : https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.5/installation/GUID-26D8A6AE-FC16-428D-8A11-6A581091F2CF.html

Support matrix’den emin olunduktan sonra açıkcası geriye kalan iki nokta var ki ikisi de network altyapısına dayanan noktalar. 

Birincisi etkili bir dizayn için sizlere 4 adet VLAN gerekecektir. Bu 4 adet VLAN için her biri şu şekildedir. 

1. Management VLAN : 
   NSX Manager, Cluster VIP ve Edge Node’ların yönetimsel adresi için gereklidir. vCenter ve ESXi hostların olduğu subnette atama yaparsanız sizi genellikle onlarca firewall rule yazmaktan kurtarır.
2. ESXi-EDGE TEP VLAN : 
   Transport VLAN’da diyebiliriz. Geneve Tunnel için gereklidir ve overlay’de olan biten host’tan host’a veya host’tan Edge’e çift yönlü oluşan trafik bu VLAN vasıtasıyla taşınır. 
   Edge ve ESXi için tek bir VLAN kullanabilmenin şartı EDGE’i Bare Metal yapmak veya üzerinde NSX kurulu olmayan bir hypervisor üzerinde barındırmaktır. 
   Eğer ki Edge VM’leri NSX’in kurulu olduğu cluster içerisinde collapsed bir yapıda barındırmak gerekiyorsa ESXi ve EDGE TEP için kullanılan VLAN’lar farklı olmalıdır.
3. EDGE Uplink-1 
   External Network için birinci çıkış noktasıdır. Kuzey-Güney akışı bu VLAN’dan sağlanacaktır.
4. EDGE Uplink-2
   External Network için ikinci çıkış noktasıdır. Kuzey-Güney akışı bu VLAN’dan sağlanacaktır. Genel olarak Active/Active T0 yapılandırmasında kullanılır. BGP ve ECMP ile birlikte throughput yükseltmek ve fault tolerance sağlamak adına ikincil bir uplink önemlidir.

MTU

Şimdi burada MTU konusunda sayfalarca yazmak isterim ama yine anlaşılmam diye korkuyorum 🙂 basitçe NSX Tunneling için GENEVE kullandığından +~100 byte bir ek header gerekmektedir. Bunun sonucu olarak MTU değeri underlay’de en az 1600 değilse NSX-T düzgün çalışmaz. Önerilen değer ise 1700.

Yine de siz çağın gereklerine ayak uydurarak bu değeri switchlerde 9216, ESXi host vmnic’lerde 9000, NSX profillerinde 9000, vmk interfacelerde 9000 ve Guest VM’lerde 8900 yapmaya gayret gösterin. Basit matematik şudur ki 9000/1500 = 6 yani packet per second 6 kat daha az olacaktır. Bu daha fazla throughput demektir. Ortamınız sadece ses kaydı yapan, küçük UDP paketlerin cirit attığı bir network ortamı değil ve en az 10Gib NIC’lere sahipseniz MTU 9K kaçınılmaz ve en akıllıca olandır. Bunun testlerini sizlere daha sonra paylaşacağım.

Sonuç ve Yorumlar;

Sonuç olarak NSX-T günümüzün ve geleceğin ciddi aktörlerinden birisidir ve üzerinde durulması, takip edilmesi, öğrenilip uygulanması gereken bir teknolojidir. Data Center içerisinde bize kazandırdığı değer ciddi anlamda kıyaslanamaz bir değerdir.

Bu dökümanı zamanla güncelleyeceğim. Kısa yazdığım veya hiç yazmadığım bazı noktalar var onlarda zamanla güncellenecektir.

İşte Görsel;

HONDA NSX CURVA RED