Virtual Cloud Network ve NSX Datacenter (NSX-T)

Bu makalenin amacı sadece ve sadece pratik olarak NSX-T hakkında bilgi vermek, şu ana kadar NSX-T ile uğraşmamış, yeni uğraşacaklar veya NSX-V bilgisi olanlar, NSX-V ile arasındaki farkları bilmek isteyenler için flash hızında ne olup, ne bittiğini neyi nasıl ne şekilde yapılabileceği bununla beraber yine sadece NSX-T hakkında değil ama NSX-T ile beraber kullanacağınız bir takım gereksinimler içinde bilgiler buluyor olacaksınız.

Hemen başlayalım, VMware için “Virtual Cloud Network”  NSX tabanlı sadece NSX-T değil birden fazla bileşen içeren bir yapı ki bu bileşenler NSX Datacenter (NSX-T/NSX-V), SD-WAN, App Defence, NSX Cloud ve Hybrid Connect.

VMware için bu kol oldukça önemli, bunu Saurabh Shah’ın VMworld NET1549BU oturumunda dediği gibi ; 
    -Bu VMware için bir geçiş, ana işi sanallaştırma ve belli başlı networking özelliklerine sahip olan bir firmadan, müşterilerin networking konusunda yaşadığı önemli zorlukları adresleyecek ve dijital dönüşümü destekleyecek bir network çözüm firmasına doğru olan geçiş.

Bu aynı zamanda benim gibi sistemci arkadaşlarım ve networkçü arkadaşlarım içinde benzer geçişlerin olacağını ve bununda hızlanacağının göstergesi. Bizlerde değişeceğiz, sistemcilerin daha çok BGP, VRF bilmemiz gerekecek, networkcü arkadaşların NSX özelinde ilgili bileşenleri bilmek, kendilerini python, ansible, terraform hatta AWS, Azure özellinde geliştirmeleri gerekecek, iki gurup yeri gelecek ileride birleşecek.

Konuya girmeden önce belli başlı terim, yazı içinde kullanacağım kısaltmalar ve bunların açıklamalarına bir göz atalım.

Logical Switch (LS) : Fiziksel switch ile benzer özellikleri olan, sanal makinelerin izolasyonları için yaratılan broadcast domainleri.

Transport Zone (TZ) : Sadece VLAN ile çözüm ürettiğimiz zamanlarda yaptığımız şey şu olurdu, bir VDS yaratırdınız, içersinde her bir VLAN için bir port-group yaratırdınız, network bazında ESX kurulu fiziksel sunucunun bağlı olduğu switch portlarını trunk ayarlar, ilgili tüm VLANların buradan geçmesi için ayar yapardınız ki vMotion yaptığınızda ilgili VM’ler network bağlantılarını kaybetmesin. Network sanallaştırma dünyasında VLAN karşılığı LS/VXLAN olduğundan bunlarında overlay networkde nereye kadar uzanacağını hangi fiziksel ESX sunucular üzerinde koşabileceklerini TZ’u uyguladığınız küme(cluster) ve/veya tekil sunucu bazında limitlemiş veya genişletmiş oluyorsunuz.

Transport Zone Tipleri : Overlay ve VLAN

Transport Node (TN) : Kısaca TZ’u ESX, KVM ve Edge sunuculara atadığınızda ilgili sunucular dönüşüp TN rolüne sahip olmuş oluyorlar.

N-VDS : NSX Managed Virtual Distributed Switch.

N-VDS Name : TZ yaratırken ilgili N-VDS’e vereceğiniz isim.

MTU : Bitmeyen konfigürasyon MTU.  Bence tüm yeni kurulumlarınızda hem vSwitch , Uplink Profile, hemde fiziksel switche bağlı portlarda hiç düşünmeden, tereddüt etmeden varsayılı olarak 9000 ayarlamanızı tavsiye ederim.

pNIC : NSX-T ile konfigürasyon yapmaya başladığınızda ve ESX sunucular üzerindeki fiziksel network kartlarından bahsetmeye başladığımızda bunlara artık vmnic değil pNIC demeye başlayacağız.

Service Router (SR) : NAT, DHCP Server, Metadata Proxy, Edge Firewall ve Load Balancer olmaktan sorumlu.

Distributed Routing (DR) : Her hypervisorda kernel modül olarak kurulu ve routing işleminden sorumlu.

VDS : Virtual Distributed Switch

VC : vCenter

Bileşenleride tanımladıktan sonra en temel soru ile başlayalım ;

NSX-T Nedir ve NSX-V ‘den farkı nedir ?
 
Bu sorunun en yüzeysel ve önemli cevabı, NSX-T  ile beraber VMware’in vizyonu sadece ESX ortamında değil artık KVM üzerindede, AWS’de veya Azure üzerinde NSX koşabilecek olması.

Bir iki örnek ile anlatacak olursak ; 

  • Kendi lokasyonunuzda hem ESX hemde KVM sunucularınızın olduğunu var sayalım, kurmuş olduğunuz veya kuracağınız overlay network bu birbirinden farklı olan iki hypervisor üzerine yayılmasını, yaratacağınız veya var olan sanal iş yüklerinizin birbirleri ile farklı hypervisor üzerinde olmasına rağmen aynı L2 networkünde koşabileceğini, tek bir merkezden bunları yönetebileceğinizi ve network bazında görünürlüğü aynı şekilde sağlayabileceğinizi düşünün.
  • Veya kendi lokasyonunuza ek olarak AWS üzerinde VPC’leriniz var ve merkezi bir noktadan firewall kuralları uyarlamak, vpc’deki ortamınızı görünürlüğü artırmak, sizden izinsiz herhangi bir güvenlik kuralı uygulanmamış bir instance’ı karantinaya alabileceksiniz gibi aksiyonlar almak istiyorsunuz gibi. (Bakınız NSX Cloud)

Sadece bu kadar mı ?

Sanırısam en önemli nedenlerden bir diğeri ise konteyner ve konteyner orkestrasyon çözümleri hakkında. Genel clouda geçiş ve cloud hakkında yapılan istatistiklerde güvenlik genelde ilk üç’de olur, konteyner dünyasındada en önemli konulardan biri orkestrasyon (ki artık her yerde K8S’in bu konuda tartışmasız lider olduğu) ve güvenlik. Burada NSX-T ile beraber sanal iş yüklerinize uyguladığınız güvenlik mekanizmalarını ve diğer servisleri (NAT, FW, LB gibi) aynısını konteynerler için uygulayabiliyorsunuz, bu kanımca büyük bir rahatlık.

Farkları biraz daha artıralım ;

Yeni bir virtual switch var artık, adı N-VDS, açılımı şöyle ;  NSX Managed Virtual Distributed Switch.

NSX-V için VDS üzerine kurulan ek vib’ler ile NSX-V özelliklerini desteklemeye başlıyordu VDS fakat NSX-T ile bu değişmiş durumda. Benim aklımda daha çok overlay networkleri üzerinden taşıyacak diye sabitledim fakat N-VDS bunu dışında tüm geri kalan yönetim, vMotion gibi diğer trafik tiplerinide taşıyabiliyor.

Özellikle dizayn dökümanlarında göreceksiniz, mesela dört fiziksel kartlı ESX sunucular mevcut bunun iki tanesi N-VDS ile overlay networke, diğer iki tanesi ise VSS/VDS olup diğer networklerin trafiklerini yönetmesi için tasarlanacak ama VMware tarafında gerekli geçişlerde hazır nasıl VSS’den VDS’e kernel portlarını taşıyordunuz aynısını yönetim ve diğer trafikler içi N-VDS geçiş için kullanabiliyorsunuz.

N-VDS’in hayatımıza katacağı diğer bir yenilik ise Enhanced Datapath yani DPDK desteği ;

Özellikle 5G alt yapısında SDN ve NFV kullanımının olmaz ise olmaz olacağından artık servisler sanallaştırılacak ve trafikte bu sanal ortamlardan geçecek 🙂 haliyle sanal ortamlardaki networklerinde performanslarının artırılması gerekiyordu (1-10Gbit endpoint bağlantıları), aynı zamanda düşük gecikme ihtiyacı olan diğer servisler (self driving car) içinde birşey olması gerekiyordu, işte bunu DPDK ile N-VDS Enhanced Datapath mode ile desteklemeye çalışacak.

Yeni overlay protokolü GENEVE !

Güle güle VXLAN hoş geldin GENEVE 🙂 Evet, no vxlan. GENEVE aslında IETF bilgilerine göre overlay network taşımaları ile ilgili olarak protokol savaşlarına son verip, geliştirilebilir, farklı sağlayıcıların arasında kullanıcak generic bir protokol olacak.

Artık NVGRE,VXLAN,STT gibi encapsulation protokollerini bırakıp yerine GENEVE gelecek. Keza NSX-T ile beraber GENEVE protokolü kullanılmaya başladı. Haliyle bu işlemleri offload edebilmek için switch chip ve network kartlarıda mevcut.

Örnek olarak Intel 700 serisi network kartları , Broadcom Trident 3 chip’li switch’ler bunlardan sadece bir kaç tanesi. Diğer tüm GENEVE-Offload ve GENEVE-RxFilter uyumluluk listesi için buraya bakabilirsiniz.

Ripe tarafından hazırlanmış güzel bir döküman, bunuda kontrol edebilirsiniz.

Peki NSX-T, NSX-V yerini mi alacak ?

Evet, version 2.4 ile beraber otomatik göç (migration) gelmeye başladı, tamamı olmasada belli bir oranda NSX-V ‘den NSX-T geçiş mevcut.

Bunlarında dışında en önemli nokta şu, ayrıklaştırma. Ayrıştırma hızlanarak devam ediyor (decoupling);

Ayrıştırma Örnek 1 ;

Mesela artık VC ile NSX-T Manager ile aranızda zorunlu bir bağ yok, NSX Managerınızı kurun ve daha sonra yönetmek istediğiniz ESX veya KVM sunucuları, VC veya VCleri sadece buraya ekleyin yeter. Bırakın VC “Compute” iş yükünüzü yönetsin, NSX ‘de networking ve diğer servisleri yönetsin.

Ayrıştırma Örnek 2 ;

Bunla beraber NSX-T ile beraber göreceksiniz çok fazla profile mevcut, bu profiller ile hızlı ve basit bir şekilde bileşenleri yöneteceksiniz.

Uplink Profile (UP):  NSX-T ile beraber hayatımıza pNIC diye bir kavram giriyor, elimizdeki network kartları ve sunucunun bağlantı şeklinde göre LACP veya Non-LACP, MTU, VLAN bilgilerinden bir profile oluşturuyoruz ve bunuda TZ yaratırken veya TZ’a node eklerken ilgili sunuculara veya Edge TN ekliyoruz hepsi bu.

Aşağıdaki gördüğünü ekran çıktısı benim test için yarattığım bir UP. Bunu vSwitch NIC Teaming ayarlarına benzetebilirsiniz. Tek yapmanız gereken yukarda belirttiğim gibi ESX veya KVM sunucunuzu yaratırken bu UP’i atamak.

Ayrıştırma Örnek 3 ;

Switching Profile (SP) : SP’de keza aynı , logical switch yarattıkça yarattığınız ilgili profile’ı buraya uyguluyorsunuz.


Peki T0 ile T1 nedir ?

Geleneksel yapıda bizim fiziksel veya sanal netscaller, f5, nginx gibi load balancerlarımız olur, firewall olarak Fortinet,Checkpoint gibi ürünler kullanır, atadığımız networklerin varsayılı gw’leri ya bu LB yada FW cihazlar olur, kurallar burada uygulanır, dış dünyadan ilgili (ki buna kuzey güney trafiği diyoruz) networklerdeki servislere ulaşmak içinde FW veya LB üzerinde ya statik yada dinamik routing protokolleri ile networkcü arkadaşlarımızın router’ları ile aramızda OSPF, BGP veya statik route konfigürasyonları yapardık.

NSX-V ile bu yapıyı konuştuğumuzda ESG (Edge Service Gateway) ve dinamik routing koşacak isek Control VM ‘in varlığından bahsetmeliyiz. ESG tüm kuzey ve güney dediğimiz trafik’e yukarıda geleneksel yapıda verdiğimiz servisleri üzerinde barındırıyordu.

NSX-T ile beraber Tier0 (T0) ve Tier1 (T1) adı verilen iki router var, bana göre rol/obje gibi farklı şeyler içersinde bulunduruyor. İlla her ikisinin kullanılması gerekir gibi bir şart yok. Bu daha çok kullanım şekliniz ile alakalı olacak. T0 arkasında LS bağlayabilirisiniz ve yolunuza devam edebilirsiniz ki buna single tier diyorlar veya T1 arkasına LS bağlayıp, T1’ide T0 bağlayarak two-tier adı verilen bir yapıya sahip olabilirsiniz.

Neden two-tier dizayn var, çünkü “Multitenancy” gereksiniminden ötürü. Türkiye’de departmanları örnek verebilirmiyiz bilmiyorum ama bir servis sağlayıcının müşterileri için örnek verebiliriz.

Bir servis sağlayıcı her bir müşterisine routing ve networking servisleri için bir T1 verdiğini düşünün. Müşteriler firewall, NAT ,LB gereksinimlerini T1 üzerinde halledecekler fakat dış dünyadan kendi yarattıkları servislere erişim verilmesi için sahip oldukları public ip adreslerininde dünyaya anons etmeliler, bunun için networkçü arkadaşlarımıza gitmeden bir ayrıştırma daha yapıp T0 katmanını yaratıyoruz, bu katman provider router denilen yani ISP’inin sahip olduğu Juniper, Cisco, Arista gibi routing yapan cihazlarla T0 router arasında BGP (dikkat, sadece ve sadece BGP) komşuluğu kurduğunu düşünün. Bundan sonra tek yapılması gereken şey T0 ile T1 router’larının birbirlerine bağlanması ve T1 üzerinde anons edilmesi gereken public ip adreslerinin provider router’lara geçirilmesi.

Bu dizaynın bir benzeride VMware’in production ready K8S çözümü olan PKS içinde benzer şekilde kullanılmakta, aşağıda bununla ilgili bir göresel bulabilirsiniz.

PKS bazında her bir T1 K8S namespace’e eş değer, ISP için ise müşteri.
T0 ISP’deki fiziksel router’larla arkasında T1’ler için geçirgenliği sağlamakta.
Her bir T1’de networking servislerini konteyner ve sanal makineler için sağlamakta.

Edge Node ve Edge Node Cluster Nedir ?

Edge nodelar NSX-T ile beraber yapı olarak ESG’lerden farklı bir hale bürünmüş durumda. Her bir edge node aslında mantıksal boş bir obje, edge node cluster ise bu objelerin guruplanmış hali. Birşey uygulamak istediğimizde edge node’a değil, edge node clustera uyguluyorsunuz.

ESG gibi üzerinde tüm servisleri (NAT,VPN,LB gibi) bulundurmuyor sadece ve sadece üzerinde koşması gereken servisler ne ise onu koşturuyor üzerinde. Haliyle Edge Node’un yüksek erişilebilir olması değil edge node clusterda koşan servislerin yüksek erişilebilirliği olması sağlanıyor.

Ek olarak iki farklı tipi mevcut yine ESG’e göre farklı olan, sadece VM bazlı değil aynı zamanda Bare Metal dediğimiz fiziksel bir sunucu üzerindede ilgili servisleri çalıştırabilir durumda olunabilecek NSX-T ile beraber. Bunun tek bir nedeni var o da performans.
Örneğin cpu ağırlıklı olan BGP Fast Convergence BM’de, 10Gbit üzeri network bant genişliği için yine BM öneriliyor.

Bunla beraber edge node’larda varsayılı olarak DPDK Fast Path geliyor.

SR ve DR Nedir ?

Buraya kadar herkes benimle birlikte ise T0,T1 Router ile Edge ve Edge Node Cluster konusu birbiri ile çakıştığını fark edeceklerdir.

T0 veya T1’i mantıksal iki bileşenden oluşan bir konteyner veya bir yapı olarak düşünmeliyiz. Bu iki bileşenlerden biri SR (Service Router) ve diğeri DR (Distributed Router). Başka bir deyişle hypervisor üzerinde dağıtık çalışabilecek servisler DR’ı , merkezi bir yerde çalışması gereken servislerde SR’ı oluşturuyor veya doğu-batı trafiği DR’ı , kuzey-güney trafiği ise SR’ı.

SR ki, içerdiği tüm servisler ( dış dünyaya olan fiziksel bağlantı, NAT, DHCP, MetaData Proxy, LB, Edge Firewall ) işte bu edge node cluster yüklenicisindeki edge node’lar üzerinde çalışmakta.

Yani edge node cluster içersindeki edge node’larda bir sürü T0 ve T1 SR instance’ları çalışıyor demek olacak.

Şimdilik bu kadar…
VM

Advertisements

Posted on 15/04/2019, in NSX-T and tagged , , , , , , , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: