Software-Defined Networking (SDN) Teknolojisi

Software-Defined Networking (SDN) Teknolojisi
Adem YETİM tarafından 2 sene önce eklendi. 4,024 kez okundu.

Networking dünyasındaki teknolojik gelişmelere baktığımızda, son 15-20 sene içerisinde cihazların kapasiteleri ve kademeli bazı gelişmelere ilave olarak (MPLS, Data-Voice-Video Convergence, Control Plane/ Data Plane İzolasyonu, Kablosuz Teknolojiler  gibi..), son zamanlarda herkesin konuştuğu, giderek çok daha fazla konuşulur hale gelen, tüm üreticilerin pazar payı almak için aynı alana odaklandığı Cloud Networking , Software Defined Data Center/ Software Defined Networking gibi kavramların tartışıldığı ve başarılı şekilde uygulanmaya başladığı zamana tanıklık ediyoruz.

1990-2000 yılları arasındaki tartışmaları ve akıllardaki Networking ile ilgili soruları incelediğimizde kafamızda net olmayan bir çok konu vardı:

Hangi Teknolojiyi kullanmalıyım? Token Ring, SNA, ATM, Frame-Relay ya da Ethernet mi? Tüm Network’ üm aynı Layer-2 Domain de mi olmalı? Segmentasyon için Layer-3 Routing mi yapmalıyım? HUB mı, Bridge mi, Switch mi, Router mı kullanmalıyım?

Networkteki her cihazı yöneten çok büyük bir merkezi yönetim Network’ üm mü olmalı? Yoksa ihtiyaca gore farklı domainler için farklı yönetim konsolları mı kullanmalıyım? Gibi…

Teknolojik gelişmeler, toplam sahip olma maliyeti, operasyonel kolaylıkları, artan iş yüklerinin ihtiyaçlarını karşılama esnekliklerine göre ilk aşamalarda kurumların farklı farklı yaklaşımlarının-tercihlerinin sonunda, günümüzde bu teknolojilerden hepimizin bildiği opsiyonlar standard hale gelmiş durumda. Sanırım WAN bağlantısında artık hemen hemen kimsenin aklına bir tercih olarak ATM/ Frame-Relay gelmiyor artık. (Her ne kadar xDSL teknolojilerinde son kullanıcıya bakan tarafta arka planda ATM kullanısa dahi, biz Ethernet over ATM Encapsulation’ ı kullandığımızdan esasında bizim açımızdan temel olarak Ethernet uçtan uca hakim Teknoloji olmaktadır.)

Benzer kavram kargaşaları, farklı yaklaşımlar günümüzde popüler olan SDN- Software Defined Networking tanımı için de geçerli. Bu konuda Hardware üreticisinden üreticisine değişen bir ya da birden fazla yaklaşım söz konusu. Konu aslında Network ile birlikte, Yazılım-Software olduğundan dolayı aynı donanım üreticisinin dahi birden fazla yaklaşımının olmasını da normal karşılamak gerekir. Zira Software temelli bir yaklaşım olduğunda çözüm tarafının çok çeşitlenmesi normal olsa gerek.

Her kurumun ihtiyacı farklı olabileceğinden ve SDN konusunda da yaygın bir standard oluşmamış olmasından dolayı, belirli bir çözümü mutlak doğru ya da yanlış olduğunu söylemek doğru olmaz. Bize düşen bu farklı yaklaşımları bilip, kurumun-müşterinin ihtiyacına gore uygun olan çözümü önermek olmalıdır.

Farklı üreticilerin her söylediği tam olarak doğru olmayabileceği gibi, bazı şeylerin bugün için yapılabiliyor olması da o şeyi sorgusuz yapmamız gerektiği anlamına gelmemeli.

Doğru ve gerçek olan şu ki; eğer kendimize yatırım yapmaz ve bu değişimin gerisinde kalırsak, SDN ile ilgili bu gelişmeler sonucunda malesef biz Network mühendislerinin konfor alanı da aslında kısa sürede daralacak.

Bu yazıda ilk olarak amacım, SDN teknolojileri içerisinde farklı yaklaşımları genel hatları ile tanıtmak, sonrasında ise takip eden yazılarla teknoloji bazında detay açıklamalara bilgim dahilinde yer vermek. Bazı terimlerin ilk aşamada detay açıklamasına girmeyeceğim (NFV vb. gibi), elimden geldiğince yazı içerisinde her birini mümkün mertebede açıklamaya çalışacağım.

Neden SDN?

SDN’ e gerek duyulmasını gerektiren temel iş gereksinimlerinden bazıları;

  • Son zamanlarda bir klişe olarak her yerde kullanılan Hız-Çeviklik diyebileceğimiz “Agility” kavramı. Beklemeye kimsenin tahammülünün olmadığı, vakit-nakittir gibi kapitalist gerçekliklerin geçerli olduğu bir zamanda, istemcilerin ihtiyacını onları memnun edecek hızda sunmak önem arz etmektedir.
  •  Networking Kaynaklarının Uygulama gruplarınca ilelebet rezerve olarak değil de, yapılmış olan Networking donanım yatırımının Multi-Tenancy desteği ve NFV ile birlikte ortaklaşa kullanımı sayesinde daha fazla faydalanılır hale getirilmesi,
  • Multi-Tenancy ile birlikte gündeme gelebilecek olan Network Güvenliği ve Tenant-Isolation sorununun adreslenmesi,
  •  Popüler diğer bir kavram olan  “Hybrid Cloud” uygulamaları sonrasında meydana gelen Veri Merkezleri arası esnek arabağlantı ve merkezi tanım-control ihtiyacı,

Genel olarak merkezi bir Controller üzerinden ilgili API’ lar ile birlikte Programlanabilirlik ve Otomasyon desteği olarak sıralanabilir. Günümüzde bildiğiniz üzere Sunucu ve Storage bileşenleri sanallaştırılmış durumda, bir kaç dakika içerisinde Sanal bir sunucu ilgili Storage kombinasyonu ile birlikte oluşturulabiliyor. Ancak kurumun büyüklüğüne, prosedürlerin miktarına ve dokunulacak olan Network cihazlarının kritikliğine ve adedine gore bu oluşturulan Sanal Sunucuya erişim için Network tarafında yapılması gereken değişiklikler (VLAN/ Subnet oluşturma, Routing/Switching tanımları, Firewall/Load Balancer tanımları, varsa yeni kablolama ihtiyacı gibi) bir kaç gün ya da en iyi ihtimalle saatleri bulabilmekte. Artan kapasite ihtiyacının farklı lokasyonlardaki donanımlar ile karşılanabiliyor olması gerekliliğinin zaman zaman ortaya çıkardığı Layer-2 Network Extension gibi gereksinimler de konuya eklenir ise, bu süreç daha da karmaşık hale gelebilmektedir.

SDN ile birlikte hedef, Network’ ü de tam olarak Sanallaştırılmış ve Programlanabilir bir duruma getirerek, kapasite kullanım ihtiyaçlarındaki artışa hızlı cevap verecek, belirli minimum gereksinimleri sağlamak şartı ile fiziksel lokasyon ve donanım bağımlılığı gibi konuları ortadan kaldırıp, Sunucu ve Storage tarafındaki bu hıza ulaşmak. Böylece işbirimlerinden gelen isteklere karşı Sunucu ve Storage tarafında olduğu gibi aynı hızda cevap verip, hitap ettiğimiz pazarı memnun etmek.sdn14Eğer klasik yöntemlerle Network tarafındaki bu değişiklikler için harcanan süre kurum için çok da sorun değil ise ve bu tür değişiklikler ayda yılda bir yapılıyor ise SDN’ in avantajı olarak, otomasyon ile birlikte tüm işlemlerin merkezi Controller üzerinden yapılıyor olduğundan Admin kaynaklı hataların minimuma indirilmesi, sunucu yönetiminde olduğu gibi tüm Network seviyesinde de Roll-back yeteneklerinin mümkün olması ve sonrasında değineceğimiz güvenlik ile ilgili avantajlar sayılabilir.

Bütün bu argümanlar şu an için kabul görmez ise de, müşteriyi vakti geldiğinde geçişin daha sancısız ve masrafsız olması açısından “SDN Ready” bir altyapıya yönlendirmek (Yeni bir Data Center Network kurulacak two-tier bir mimari ile birlikte SDN Teknoliji bağımsız ürünlerin konumlandırılması gibi) en uygunu olur sanırım.

SDN Tanımı aşağıdaki özet başlıklar altında ifade edilebilir,

Management ve Data Plane’ in ayrıştırılması:

Merkezi Controller sayesinde, Management Plane tüm Network’ e hakim olacak şekilde merkezileştirilir. SDN Controllerdaki bu Management Plane sayesinde MAC-IP tabloları, Overlay Tuneller gibi bileşenler yönetilir. Data Plane ise her bir Compute Node’ da dağıtık olarak (Virtual Switch) uygulanır.

Programlanabilir Network Oluşturmak: API lar sayesinde Orkestrasyon ve Otomasyon desteği sağlanır.

Network Sanallaştırma: Farklı Overlay teknikleri ile birlikte IP Networklerin Sanallaştırılması (VXLAN, MPLS over GRE kullanılarak) sağlanır. Böylece Multy-Tenancy ve Security gereksinimleri adreslenir.

Network Function Virtualization (NFV): Sanal Firewallar, Sanal Load Balancerlar, Sanal IPS gibi opsiyonlar kullanılarak daha hızlı servis tanımları gerçekleştirilir.

SDN teknolojileri genel olarak iki kategoride sıralanabilir:

1-) Network Virtualization (NV): Merkezi Control Plane sayesinde, lojik olarak altyapıda kullanılan donanımdan bağımsız olarak sanal Networkler’ in oluşturulması olarak tanımlanır. Bunu yaparken de iki yaklaşım var genel olarak; Overlay ve Fabric temelli.

Overlay Metodunda Network sanallaştırması Hypervisor katmanında, fiziksel Network’ te değişikliğe gerek kalmaksızın (idealde minimum ilk değişiklik ile) yapılır. Fiziksel Network’ te yapılacak güncellemeler ve değişiklikler Sanal Network’ ü değiştirmez. Genel olarak VXLAN kullanılması durumunda, teknik olarak 16 Milyon sanal Network oluşturulabilir (Mevcut VLAN segmentasyonunda ise bu rakam bilindiği üzere 4096). VXLAN’ da basit  olarak GRE’ de olduğu gibi original IP paketininin üzerine yeni bir Source-Destination IP ile birlikte VXLAN Header’ ının yerleştirilmesi temeline dayanır. Dolayısıyla bu yeni header’ in Source ve Destination IP’ leri Underlay Network içerisinde Route edilebilir olması durumunda, Layer-2 segmentleri, L-3 Networkler üzerinden haberleştirilebilir.

Fabric Temelli Metodda ise Fiziksel Switchlerin geleneksel yöntemlere nazaran daha efektif olmak üzere, Openflow gibi bir SDN protokolü ile birlikte programlanmasını  içerir.

http://archive.openflow.org/wp/learnmore/

2-) Network Functions Virtualization (NFV)

Geleneksel Network Donanımlarının, standart sunucu platformları üzerinde açılmasını ifade eder (Örneğin: Sanal Load Balancer, Sanal Firewall gibi).


sdn02
SDN Fonksiyonel Diyagramı

SDN Teknoloji Opsiyonları:

 Bu kısımda genel olarak popular olan üç farklı alternative hakkında bilgi vermeye çalışacağım.

1-) VMWare NSX-V Genel Bakış:

 VMWare NSX, VMWare’ in SDDC (Software Defined Data Center) mimarisinde, herhangi bir IP Network üzerinden gelişmiş microsegmentation güvenlik özellikleri ile birlikte dağıtık NFV desteği de sağlayan Overlay temelli Sanal Networkler oluşturmaktan sorumlu olan bileşenidir.

VMWare NSX, mevcut herhangi bir Network mimarisi (3-Tier:Access, Aggregation, Core ; 2-Tier:Leaf-Spine ya da Flat) üzerinden çalışabilmekte ve herhangi özel bir Network üreticisini adreslememektedir. Network altyapısında olması gereken temel gereksinim, VXLAN encapsulationundan kaynaklanan 50 Byte ekstra Header’ ı iletebilecek 1550 Bytes IP MTU değerini sağlıyor olmasıdır. L2 Encapsulation eklemeleri (.1Q, QinQ gibi) ile birlikte kabaca bu değerin 1600 Bytes olması gerektiği söylenebilir.

Bununla birlikte ideal dizaynda, 2-Tier bir Network (Spine/Leaf) Mimarisi kullanılması önerilir. Özellikle Network Switchleri seviyesinde Visibility-Troubleshooting, VTEP gibi entegrasyonlar açısından bir kaç Network donanımı üreticisi firma ön plana çıkmaktadır (Juniper, Arista Networks, Brocade gibi)

VMWare NSX ile birlikte bahsettiğim gibi NFV özellikleri kendi içerisinde gelse de, bu konuda geniş yelpazede bir çok üretici ile de güçlü entegrasyonları da bulunmaktadır.

https://www.vmware.com/products/nsx/technology-partners

NSX ile Hypervisor seviyesinde ve her bir sanal sunucu bazında uygulanan dağıtık Firewall ile birlikte farklı subnetler arasındaki Sanal Sunucular arasında olduğu gibi, aynı Subnet içerisinde bulunan Sanal Sunucular arasında da merkezi güvenlik politikaları uygulamasına imkan salanmaktadır (Micro-Segmentation). Bu dağıtık Firewall Layer4 seviyesine kadar Stateful çalışmakta ve harici bir Sanal sunucu gibi değil, VMKernel seviyesinde çalıştığı için hemen hemen Line-Rate L4 Firewall kapasitesi sağlayabilmektedir. Sanal Sunucular ESX Hostlar içerisinde VMotion’ a tabi olduğu durumlarda yine aynı Firewall, aynı State Tabloları ile birlikte yeni Host üzerinde kaldığı yerden sanal sunucu ile birlikte ayağa  kalkmaktadır.

Konfigürasyon ve otomasyon desteği doğrudan NSX Manager ya da NSX Manager, VMWare vRealize ya da OpenStack API üzerinden de yapılabilir.

Fiziksel cihazlar ya da Sanallaştırılmış Veri merkezi dışındaki Networkler ile görüşmek, Load Balancer, SSL VPN gibi tümleşik gelen özellikleri kullanmak için “NSX Edge Services Gateway” ler kullanılır. Bu cihazlar yine VMWare ortamındaki sanal sunucular olduğu gibi, yukarıda bahsedilen İş Ortakları  entegrasyonu ile birlikte bü dönüşüm Hardware seviyesinde de yapılmakdadır. Fiziksel dünya ile bağlantının sağlandığı, overlay temelli sanal Network’ ün fiziksel VLAN dönüşümünün yapıldığı fonksiyon VTEP- Virtual Terminal Endpoint olarak adlandırılmaktadır.

sdn06VMWare NSX Fonksiyonel Diyagramı

VMWare NSX Bileşenleri:

NSX Management Bileşenleri : NSX Manager ve NSX Controllerlar.

DVS- Distributed Virtual Switch: ESX Hypervisor’ de, VXLAN Overlay Encapsulation kullanarak Network Sanallaştırmasını ve Data Plane’ i oluşturur. NFV özelliğini ise NSX ile birlikte gelen özellikler ile ya da diğer üretici işbirlikleri ile entegre olarak sağlar.

Edge Services Gateway-ESGWler: ESGW’ ler NSX Sanal Networkler ile Non-NSX Networkler arasında entegrasyonu, Release 6.2.1 ile birlikte Dağıtık L2-L4 Load-Balancer, NAT, Dağıtık Routing (BGP, OSPF) desteği sağlar. Dağıtık Routing, Firewall gibi özellikler sayesinde, aynı fiziksel ESX Host üzerinde ancak farklı Subnetlerdeki iki farklı VM arasındaki trafik Network Switch’ e çıkmadan, ESX Host içerisinde ilgili Security/ Routing Politikaları vs. kontrol edilerek gerçekleşir. Dolayısıyla oluşacak fazladan gecikmeler ve Network’ ün gereksiz yüklenmesi engellenmiş olur.

sdn07Mimari Bakış: VMWare NSX-V SDN Bileşenleri

 

2-) Cisco ACI (Application Centric Infrastructure) Genel Bakış:

Cisco ACI çözümünde, merkezi Cisco APIC Controller aracılığıyla uygulamaların gereksinim duyduğu Network ve Network Servisleri gereksinimlerinin otomatik olarak ilgili Network Servis Politikaları (Security, Load Balancing, QoS gibi) ile birlikte Cisco Nexus 9000 Serisi cihazlar üzerinden programlanması sağlanır. Cisco ACI çözümüne entegre olan iş ortaklarını sağladığı API’ ler üzerinden Hypervisor, Storage ve Sunucu yönetimi desteği de sağlayabilmektedir.

http://www.cisco.com/c/en/us/solutions/data-center-virtualization/unified-fabric/aci_ecosystem.html

Cisco ACI, geleneksel yöntemlerde gerçekleştirdiğimiz (L2/L3 konfigürasyonları, Switchler arası Trunklar vs.) adımların manuel olarak yapılmasına gerek kalmasızın, Leaf Switchler (Leaf Switch: Two-Tier Data Center Network Mimarisinde Sunucu, Firewall, Load Balancer gibi cihazların sonlandırıldığı genel olarak Top of Rack switch olarak ifade edilebilecek Veri merkezi Switchleridir. Tüm Leaf Swithler birden çok Spine-Omurga Switch’ e bir ya da birden fazla Uplink ile bağlanır. Böylece Veri Merkezi Network’ ü genişlerken Leaf’ ler arası Networking deneyimi-Latency, Kapasite gibi- aynı olması sağlanır.) üzerinde programlanmasını sağlar. Data Center’ daki genişlemeye parallel olarak ilave edilen Leaf Swithchler otomatik olarak ACI Fabric içerisine dahil olur.

ACI uygulama merkezli çalışan bir Policy temelli Network mimarisi demiştik, bununla birlikte alışageldiğimiz bir çok eski kavram aksine, ACI Mimarisi ile birlikte yeni kavramlar gelmektedir. Örneğin Sanal ya da Fiziksel olsun, ACI Fabric’ e bağlanan cihazlara “Endpoint”, aynı Security grubunda olması, aynı Network servislerine ihtiyaç duyması, aynı QoS ihtiyacı gibi benzer niteliklere sahip olan “Endpointler”’ in kümesine ise “Endpoing Grouups-EPGs” denmektedir. EPG’ ler arasındaki bağlantı-connectivity Politikaları ise “Contracts” ile tanımlanmaktadır. Detay mimari için aşağıdaki Link’ Ii inceleyebilirsiniz.

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals.html

ACI mimarisinde Cisco Nexus 9000 Serisi cihazlar ve full-ACI mode destekli Line Card/Switchler kullanılması zorunludur. Cisco yeni duyurduğu ürünler ile önceki nesil Nexus 9000 Serisi Switchlerde olan “Sadece ACI Mode” ya da “Sadece traditional NX-OS” destekli cihazlara ilave olarak her iki modu da destekleyen ve daha gelişmiş Cisco ASIC ler ile daha büyük Bufferlar’ a, daha düşük güç tüketimine, daha yüksek performansa ve Network Telemetry gibi özelliklere sahip olacaktır. Bu cihazlar standard NX-OS destekli donanımlara göre her ne kadar daha maliyetli olsa da, sahip oldukları Bufferlar’ ın büyüklükleri ve sanal ortamlar için sağladığı Görünürlük-Visibility ile de ön plana çıkmaktadır.

Cisco APIC Controller; Nexus 9000 Leaf Switchler, F5 Citrix, Red Hat gibi iş ortakları cihazlarına ilgili uygulama politikalarının aktarımı için XML ya da JSON temelli çalışan OpFlex protokolünü kullanmaktadır. OpFlex protokolünün standartlaşması ve SDN teknolojilerinin başlangıcı sayılabilecek Openflow’ a bir alternative olması için IETF ve Opensource Toplulukları ile de görüşülmektedir.

Cisco ACI, Orchestration katmanında ilgili Plug-in ile birlikte Openstack Heat ve Neutron entegrasyonunu desteklemektedir.

https://wiki.openstack.org/wiki/Heat

https://wiki.openstack.org/wiki/Neutron

sdn08Mimari Bakış: Cisco ACI SDN Bileşenleri

3-) Juniper Contrail Genel Bakış:

Juniper Contrail SDN çözümünde, altyapıda kullanılan Network donanım cihazlarının üreticisinden bağımsız olarak, herhangi bir IP Network üzerinden, kullanılan sanallaştırma Hypervisorü seviyesinde MPLS ya da VXLAN Overlay temelli Forwarding Plane’ i oluşturan vRouter kullanılır. vRouter ve Contrail Controller mimarinin en önemli bileşenleridir. NFV tarafında ise yine Juniper çözümleri kullanılabildiği gibi, Citrix, Checkpoint gibi iş ortakları ile de entegrasyonları bulunmaktadır. Detay bilgi için aşağıdaki Link incelenebilir.

http://www.juniper.net/uk/en/partners/technology-alliances/data-center/

Diğer alternatiflerinden farklı olarak üretici tercihi açısından daha açık bir mimari sunmaktadır.

sdn09Juniper Contrail Fonksiyonel Diyagramı

Juniper Contrail SDN bileşenlerinden “External Gateway” aracılığıyla  (Ör: Juniper MX Router ya da MP-BGP, MPLS destekli herhangi bir Router); Birbirinden farklı Sanal Network Domainlerinin haberleştirilmesi (Ör: Opnestack, VMWare etc.), Farklı lokasyonlarda bulunan Sanal Networklerin haberleştirilmesi, Sanal Networkler ile Fiziksel Networkler arasında erişimin sağlanması, Sanal ve Fiziksel Servis bileşenlerinin birleştirilmesi (Service-Chaining) gibi fonksiyonları gerçekleştirilir.

sdn10Mimari Bakış: Juniper Contrail SDN Bileşenleri

Son olarak aşağıdaki tabloda bahsettiğimiz üç farklı teknolojinin kıyaslamasını bulabilirsiniz.

sdn11

  • Burhan Abdiler: Elinize sağlık Fatih Bey , detaylı incelemeniz konuyu tamamen açıklayıcı nitelikte ....
  • Tufan ULU: Adem kardeşim, tebrik ediyorum ve başarılarının devamını diliyorum,...
  • Rafet Arslanyı lmaz: Adem Hocam, Tebrikler.. Umarım devamıda gelir :)...
  • Serkan ERSAN: Çok başarılı ve güzel bir anlatım olmuş. Emeğinize sağlık, teşekkürler....
  • Adrenalin .: Teşekkürler Adem Bey....

Bu içerik için henüz hiç kimse görüş bildirmemiş. İlk olarak siz yorum yazamaya ne dersiniz ?

Yorum ekleyin

Doğrulama Kodunuz : 17378434

ÖNEMLİ:
Yorumlarınızı eklerken lütfen girmiş olduğunuz bilgilerin size ait olduğundan emin olunuz. Geçersiz posta adresleri iel yapılan yorumlara yanıt vermek istenildiğinde size ulaşamayacağımız için, geçerli / aktif olarak kullandığınız posta adresiniz ile yorum eklemeniz daha sağlıklı olacaktır. Her yorum yazarı tarafından sorumlu tutulur.

Sayfa başı

Güncellemeler, yeni eklenen içeriklerden anında haberdar olmak için mail listemize adınızı soyadınızı ve posta adresinizi yazarak abone olabilirsiniz.

Adınız Soyadınız
E posta adresiniz
Kaydol