SDN (Yazılım Tanımlı Ağ) Nedir

Kırk switch'i olan bir ağda yeni bir segment açmak, kırk cihaza tek tek bağlanıp aynı yapılandırmayı elle girmek demektir. Bir tanesini atlarsanız ya da bir harfi yanlış yazarsanız, hatayı ancak aylar sonra tuhaf bir bağlantı sorunu olarak fark edersiniz. SDN, yani yazılım tanımlı ağ, tam olarak bu problemi çözmek için ortaya çıktı: ağ cihazlarının "nereye göndereceğine karar verme" işini cihazlardan alıp merkezî bir yazılıma taşıyor, cihazlara ise yalnızca "gönder" işini bırakıyor.

Bu yazıda SDN'i moda kelimelerden arındırıp ne olduğunu, hangi katmanlardan oluştuğunu, OpenFlow ve Open vSwitch gibi somut bileşenlerin ne işe yaradığını ve bugün sahada en çok karşılaştığınız biçim olan overlay ağların (VXLAN) nasıl çalıştığını anlatacağım. Kendi sunucunuzda deneyebileceğiniz komut örnekleri de vereceğim. En önemlisi, SDN'in nerede gerçekten kazandırdığını ve nerede gereksiz karmaşıklıktan başka bir şey olmadığını dürüstçe konuşacağız.

Klasik Ağın Sorunu: Kontrol ve Veri Aynı Kutuda#

Geleneksel bir switch ya da yönlendirici iki işi birlikte yapar. Birincisi veri düzlemi (data plane): gelen paketi alıp doğru porttan çıkarmak. Bu iş donanımda, çok hızlı yapılır. İkincisi kontrol düzlemi (control plane): hangi paketin nereye gideceğine dair tabloları oluşturmak; yönlendirme protokolleriyle konuşmak, MAC adreslerini öğrenmek, kuralları hesaplamak.

Klasik mimaride bu iki düzlem aynı kutunun içindedir ve her kutu kendi kararını kendi verir. Bu, tek tek cihazlar için sağlam bir tasarımdır ama ölçekte üç sorun doğurur. Cihaz sayısı arttıkça yapılandırma tutarlılığını korumak zorlaşır. Ağın bütününe dair bir karar vermek (örneğin "şu uygulamanın trafiği hep şu yoldan gitsin") tek tek cihazlara çevrilmek zorundadır. Ve her üreticinin komut satırı farklı olduğu için otomasyon kırılgan kalır.

SDN'in temel önerisi basittir: kontrol düzlemini cihazlardan alıp merkezî bir denetleyiciye (controller) taşıyalım. Denetleyici ağın tamamının haritasına sahip olsun, kararları o versin ve cihazlara yalnızca "şu eşleşmeyi gördüğünde şunu yap" biçiminde akış kuralları göndersin. Cihazlar akıllı olmaktan çıkıp hızlı ve programlanabilir birer iletim motoruna dönüşür.

SDN'in Üç Katmanı ve Arayüzler#

SDN mimarisi genellikle üç katmanla anlatılır ve bu katmanlar arasındaki arayüzlerin isimleri sık geçtiği için netleştirmekte fayda var.

Northbound arayüz, denetleyicinin uygulamalara sunduğu yüzdür ve pratikte bir REST API'dir. "Bu iki sunucu birbirini görsün", "şu VLAN'ı oluştur" gibi istekleri buradan gönderirsiniz; denetleyici bunu cihaz kurallarına çevirir.

Southbound arayüz, denetleyicinin cihazlarla konuştuğu protokoldür. En bilinen örneği OpenFlow'dur, ama tek seçenek değildir: OVSDB sanal switch yapılandırması için, NETCONF ve gNMI cihaz yapılandırması ve telemetri için, P4Runtime ise programlanabilir veri düzlemi için kullanılır.

Bu ayrımın en somut faydası şudur: ağ politikanızı kodla ifade edebilir hale gelirsiniz. Sunucu yapılandırmasını Ansible ile sunucu otomasyonu yazısındaki yaklaşımla nasıl kodla yönetiyorsanız, SDN aynı disiplini ağa taşır: ağın istenen durumu bir yerde tanımlıdır ve denetleyici gerçek durumu ona yakınsatır.

OpenFlow ve Akış Tabanlı İletim#

OpenFlow, SDN'i popüler yapan protokoldür ve mantığı öğretici olduğu için anlamaya değer. Klasik bir switch MAC tablosuna bakar; OpenFlow switch'i ise akış tablosuna bakar. Akış tablosundaki her satır üç parçadan oluşur: eşleştirme koşulları (giriş portu, kaynak/hedef MAC, IP, port numarası, VLAN etiketi gibi), eylem (şu porttan çıkar, etiket ekle, düşür, denetleyiciye gönder) ve sayaçlar.

Bir paket geldiğinde switch tabloyu tarar, eşleşen ilk kuralın eylemini uygular. Hiçbir kural eşleşmezse paket denetleyiciye gönderilir; denetleyici karar verir ve genellikle switch'e yeni bir kural yükler, böylece sonraki paketler hızlı yoldan gider.

# Open vSwitch üzerinde mevcut akış kurallarını listele
ovs-ofctl dump-flows br0

# 80 numaralı porta giden trafiği belirli bir çıkışa yönlendir
ovs-ofctl add-flow br0 "priority=200,tcp,tp_dst=80,actions=output:3"

# Belirli bir kaynak IP'den geleni düşür
ovs-ofctl add-flow br0 "priority=300,ip,nw_src=185.12.34.56,actions=drop"

# Varsayılan davranış: normal switch gibi öğren ve ilet
ovs-ofctl add-flow br0 "priority=0,actions=normal"

Buradaki priority alanı kritik: kurallar öncelik sırasına göre değerlendirilir ve ilk eşleşen kazanır. Düşük öncelikli bir "normal" kuralı en altta tutmak, kural setinde bir boşluk kaldığında trafiğin tamamen durmasını engeller. Üretimde bu güvenlik ağını her zaman bırakın.

VXLAN ve Overlay Ağlar#

Bugün "SDN kullanıyoruz" diyen çoğu ortamda gördüğünüz şey, saf OpenFlow değil overlay ağ mimarisidir. Fikir şu: fiziksel ağ (underlay) yalnızca IP paketlerini taşısın, mantıksal ağlar ise bu fiziksel ağın üzerinde tünellerle kurulsun.

En yaygın kapsülleme protokolü VXLAN'dır. Bir sanal makinenin ürettiği Ethernet çerçevesi olduğu gibi bir UDP paketinin içine konur ve fiziksel ağ üzerinden hedef sunucuya taşınır; orada açılıp hedef sanal makineye teslim edilir. VXLAN kimliği (VNI) 24 bittir, yani yaklaşık 16 milyon ayrı segment tanımlayabilirsiniz. Bunu VLAN'ın 4094'lük sınırıyla karşılaştırdığınızda, çok kiracılı bulut ortamlarında neden VXLAN'a geçildiği anlaşılır.

Linux'ta bir VXLAN tüneli kurmak sandığınızdan basittir:

# İki sunucu arasında VNI 10 için VXLAN arayüzü (185.12.34.56 uzak uç)
ip link add vxlan10 type vxlan id 10 dstport 4789 \
  local 185.12.34.10 remote 185.12.34.56 dev eth0

ip link set vxlan10 up

# Bu arayüzü bir köprüye bağlayarak sanal makineleri aynı segmente al
ip link add name br-tenant type bridge
ip link set vxlan10 master br-tenant
ip link set br-tenant up

Burada dikkat edilecek en kritik nokta MTU'dur. VXLAN başlıkları yaklaşık 50 bayt ek yük getirir; underlay MTU'su 1500 ise overlay içindeki arayüzlerin MTU'sunu 1450 civarına çekmeniz gerekir. Bunu yapmazsanız küçük paketler geçer, büyükler sessizce düşer ve "SSH çalışıyor ama dosya kopyalamıyor" gibi teşhisi zor bir tabloyla karşılaşırsınız. Underlay'de jumbo frame (9000 MTU) kullanabiliyorsanız bu sorunu baştan ortadan kaldırırsınız.

Open vSwitch ile Küçük Bir Deneme#

SDN'i anlamanın en hızlı yolu, bir sunucuda Open vSwitch kurup elle akış kuralı yazmaktır. OVS, Linux üzerinde çalışan programlanabilir bir sanal switch'tir ve neredeyse tüm bulut platformlarının altında bir biçimde bulunur.

# Kurulum
apt install -y openvswitch-switch

# Köprü oluştur ve fiziksel arayüzü ekle
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0

# Yapıyı gör
ovs-vsctl show

# Bir portu belirli bir VLAN'a access olarak ata
ovs-vsctl set port vnet0 tag=20

# Trunk port tanımla
ovs-vsctl set port eth0 trunks=10,20,30

Denetleyici bağlamak isterseniz OVS'a denetleyicinin adresini gösterirsiniz; bundan sonra akış kurallarını denetleyici yazar:

# Denetleyiciye bağlan (OpenFlow, 6653 standart port)
ovs-vsctl set-controller br0 tcp:10.10.99.5:6653

# Denetleyici erişilemezse bağımsız çalışmaya devam et
ovs-vsctl set bridge br0 fail-mode=standalone

Bu son satır önemli: fail-mode=secure seçilirse denetleyici düştüğünde switch yeni akış kabul etmez ve trafik durur. standalone ise klasik öğrenen switch gibi davranmaya devam eder. Hangi davranışı istediğinizi bilinçli seçin; üretimde denetleyici tek arıza noktasıysa standalone çoğu zaman daha güvenlidir.

SDN Nerede Kazandırır, Nerede Gereksizdir#

Dürüst olalım: on sunucusu ve iki switch'i olan bir ortamda SDN kurmak, çözdüğünden fazla problem üretir. SDN'in gerçekten kazandırdığı yerler bellidir.

Kazandırdığı yerler: Çok kiracılı ortamlar, yani her müşterinin kendi yalıtılmış ağını istediği bulut platformları. Sık değişen ağ topolojileri; konteyner platformlarında saniyeler içinde doğup ölen iş yükleri klasik yöntemle yönetilemez. Lokasyonlar arası uzatılmış ağlar. Ve ağ politikasının kodla yönetilmesinin gerçekten değer ürettiği, denetim ve tekrarlanabilirlik gereksinimi olan ortamlar.

Gereksiz olduğu yerler: Tek kabinet, sabit topoloji, birkaç VLAN'la çözülebilen ihtiyaçlar. Böyle bir ortamda iyi planlanmış bir VLAN yapısı, denetleyici bakımı gerektirmediği için daha dayanıklıdır. Bir de şu var: SDN yeni bir bileşen ekler ve o bileşen düşerse ağınızın kontrol düzlemi düşer; küçük ekipler için bu ciddi bir işletme yüküdür.

Bugün en çok karşılaşacağınız pratik SDN biçimi, muhtemelen konteyner platformlarının ağ eklentileridir. Kubernetes'te kullanılan ağ eklentileri kontrol düzlemini merkezîleştirip her düğüme kural dağıtır; siz "bu servis şu servisi görebilir" diye politika yazarsınız, alt katmanı hiç düşünmezsiniz. Bu, SDN felsefesinin en yaygın uygulaması ve çoğu ekibin SDN'e ilk temas noktasıdır. Kendi platformunuzu kuracağınız esnek bir zemin için bulut sunucu paketlerimiz uygun; hipervizör seviyesinde tam kontrol gerekiyorsa dedicated sunucu tarafına bakabilirsiniz. Sanal ve fiziksel arasındaki seçimi netleştirmek isterseniz bulut sunucu mu VDS mi yazısı karşılaştırmayı yapıyor.

Sık Yapılan Hatalar ve Tuzaklar#

MTU hesabını atlamak. Overlay kurulumlarında en sık ve en sinsi hata budur. Kapsülleme ek yükünü hesaba katmazsanız küçük paketler geçer, büyükler düşer. Ping başarılı olur ama gerçek trafik takılır. Overlay arayüzlerinde MTU'yu 1450 civarına çekin ya da underlay'de jumbo frame kullanın.

Denetleyiciyi tek noktada çalıştırmak. Kontrol düzlemini merkezîleştirmek onu tek arıza noktası haline getirir. Denetleyiciyi kümeli çalıştırın ve switch'lerin denetleyicisiz kaldıklarında ne yapacağını (fail-mode) bilinçli seçin.

Underlay'i ihmal etmek. Overlay ne kadar zarif olursa olsun altındaki fiziksel ağın üzerinde çalışır. Underlay'de kayıp, jitter ya da yanlış yönlendirme varsa overlay bunu gizlemez, sadece teşhisi zorlaştırır. Önce underlay'i sağlam ve basit kurun.

Sorun giderme araçlarını hazırlamamak. Kapsüllenmiş trafikte klasik paket yakalama tek başına yetmez; hangi tünelde, hangi VNI'da olduğunuzu bilmeniz gerekir. tcpdump -i eth0 udp port 4789 ile dış zarfı, tcpdump -i vxlan10 ile iç trafiği ayrı ayrı izlemeyi alışkanlık edinin.

SDN'i güvenlik duvarı sanmak. SDN akışları yönetir, uygulama katmanındaki saldırıları anlamaz. SQL enjeksiyonu ya da bot trafiği için WAF gibi bir katman gerekir; hacimsel saldırılar için de ayrı bir çözüm.

Karmaşıklığı gereksiz yere satın almak. İhtiyacınız üç segmentse üç VLAN yeter. SDN'i bir çözüm arayan problem haline getirmeyin.

Sıkça Sorulan Sorular#

SDN ile VLAN arasındaki fark nedir#

VLAN, switch üzerinde tanımlanan ve yayın alanını bölen bir mekanizmadır; kararı her switch kendi yapılandırmasına göre verir. SDN ise kararın nerede alındığını değiştirir: kontrol düzlemini cihazlardan alıp merkezî bir denetleyiciye taşır. Yani VLAN bir özellik, SDN bir mimari yaklaşımdır. Pratikte ikisi birlikte kullanılır; SDN denetleyicisi arka planda VLAN ya da VXLAN segmentleri oluşturabilir.

SDN kurmak için özel donanım gerekir mi#

Hayır. Open vSwitch gibi yazılım tabanlı sanal switch'ler sıradan sunucularda çalışır ve OpenFlow'u destekler; bir dizüstü bilgisayarda bile deneyebilirsiniz. Özel donanım, yüksek hızda donanımsal akış işleme gerektiğinde devreye girer. Sanallaştırma ve konteyner ortamlarında SDN zaten büyük ölçüde yazılımla, sunucuların içinde uygulanır.

VXLAN performansı düşürür mü#

Bir miktar ek yük getirir: yaklaşık 50 baytlık başlık ve kapsülleme işleminin işlemci maliyeti. Modern ağ kartlarının çoğu VXLAN kapsüllemesini donanımda yapabilir ve bu durumda fark ihmal edilebilir seviyeye iner. Asıl performans sorunu genellikle kapsüllemenin kendisinden değil, yanlış MTU ayarından kaynaklanan parçalanma ve yeniden iletimlerden doğar.

SDN denetleyicisi çökerse ağ durur mu#

Yapılandırmanıza bağlıdır. Switch'ler daha önce yüklenmiş akış kurallarıyla çalışmaya devam eder; duran şey yeni kural yazılmasıdır. Cihaz fail-mode=secure ayarındaysa eşleşmeyen trafik düşer ve etkiler hızla görünür hale gelir; standalone ayarındaysa cihaz klasik öğrenen switch gibi davranmaya devam eder. Üretimde denetleyiciyi kümeli çalıştırmak ve fail-mode'u bilinçli seçmek temel disiplindir.

Küçük bir işletme için SDN gerekli mi#

Çoğu durumda hayır. Tek kabinet, sabit topoloji ve birkaç segment ihtiyacı olan bir ortamda iyi planlanmış VLAN yapısı hem daha basit hem daha dayanıklıdır; bakım gerektiren ek bir bileşen eklemezsiniz. SDN, ağ topolojisi sık değişiyorsa, çok kiracılı bir hizmet sunuyorsanız ya da konteyner platformu işletiyorsanız anlam kazanır.

SDN öğrenmeye nereden başlamalıyım#

En verimli yol elinizi kirletmektir. Bir sanal sunucuya Open vSwitch kurun, bir köprü oluşturun, ovs-ofctl ile akış kuralları yazıp trafiğin nasıl değiştiğini tcpdump ile izleyin. Ardından iki sunucu arasında bir VXLAN tüneli kurup MTU sorununu bizzat yaşayın; bu bir saatlik deneme, onlarca sayfa dokümandan daha öğreticidir. Sonrasında konteyner platformlarının ağ eklentilerine bakmak, aynı fikirlerin üretimdeki halini görmenizi sağlar.

Kapanış#

SDN'in özü tek cümlede toplanır: ağın nereye göndereceğine karar verme işini cihazlardan alıp merkezî ve programlanabilir bir yere taşımak. Bunun günlük karşılığı birkaç pratik alışkanlık: overlay kurarken MTU hesabını en baştan yapın; denetleyiciyi tek arıza noktası bırakmayın ve cihazların denetleyicisiz davranışını bilinçli seçin; underlay'i sade ve sağlam tutun, çünkü overlay onun sorunlarını gizlemez, sadece görünmez kılar; ve ihtiyacınız VLAN'la çözülüyorsa SDN'e geçmek için acele etmeyin.

Kendi ağ mimarinizi kurabileceğiniz esnek bir zemin arıyorsanız bulut sunucu paketlerimizle overlay denemelerine başlayabilir, hipervizör ve switch portu seviyesinde tam kontrol istiyorsanız dedicated sunucu veya colocation tarafına geçebilirsiniz. Ağ tasarımını, tünel yapılandırmasını ve MTU planını sizin yerinize kurgulamamızı isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir.