Bölüm 43: Kontrol Düzlemi ve SDN

Router’lar haritayı kendi çıkardı. Ama o kararın orada verilmesi bir doğa yasası sayılmaz; bir mimari tercihtir.

Kararı bir yerden alıp başka bir yere koymak mümkün. Yer değişince kutunun içinde ne kaldığı da değişiyor. Karar nereye taşınıyor?

Kararı nereye koyarsın?

Kontrol düzlemini kurmanın iki yolu var. Birincisinde her kutu routing algoritmasının bir parçasını kendi içinde koşturur; parçalar birbiriyle konuşarak tabloyu hesaplar. Adı router başına kontrol. 42. bölümde link state ilanları bütün otonom sisteme taşınıyor, aynı topoloji haritası her düğümde ayrı ayrı tutuluyordu. Onlarca kutu, aynı hesabı onlarca kez yapıyordu.

İkinci yolda hesap kutuların dışına çıkar. Uzaktaki sunucularda koşan bir yazılım, denetleyici, tabloyu hesaplayıp cihazlara kurar. Router tabloyu almış olur, üretmiş olmaz. Yaklaşımın tam adı mantıksal olarak merkezîleştirilmiş kontrol. Buradaki mantıksal kelimesi bütün yükü taşıyor: ortada tek bir makine yok, tek bir karar mercii var. Denetleyici başarım, ölçeklenme ve hata toleransı için fiziksel olarak dağıtık kurulur. Arkada birden çok sunucu, paylaşılan bir durum ve biri düştüğünde devralan eşler durur.

Karşı taraftaki klasik router yekpare satılır. Anahtarlama donanımı ve üstünde koşan yazılım aynı satıcıdan gelir. Standart protokolleri konuşur, ama o protokollerin uygulaması da, altındaki işletim sistemi de satıcıya aittir: Cisco’da IOS, Juniper’da Junos.

Ayrımın kendisi yeni sayılmaz. İletme veri düzleminde, routing kontrol düzleminde yaşıyordu; kararı en uzun önek eşleşmesi kesiyordu. Yeni olan, kontrol düzleminin kutudan sökülebilmesi.

Sökmenin fiziksel gerekçesi de 39. bölümde duruyordu: o altı basamaklık hız farkı iki dünyayı aynı gövdede yan yana tutuyor. Kontrol düzlemini yeniden düşünme ilgisi 2005 civarında 4D ve RCP adlı araştırma projeleriyle canlandı; 2007’de Stanford’da Ethane geldi. 2008’de yayımlanan OpenFlow makalesi fikre bir protokol verdi ve yazılım tanımlı ağ (SDN) adı o yıllarda yerleşti.

Kararın kutunun içinde ve dışında durduğu iki düzeni yan yana koyalım:

Neye bakarak karar veriliyor?

Kararı veren tek alanın hedef adres olması gerekmiyor. Genelleştirilmiş iletmede başlıktaki birçok alan kararı birlikte belirler. Eşleşme üç katmandan birden alan okuyabilir: data link, network ve transport layer alanları aynı kuralda yan yana gelir.

Flow kaydının ilk yarısı eşleşme, yani başlıkta aranan desen değerleri. İkinci yarısı eylem: düşür, ilet, değiştir ya da denetleyiciye gönder. Kaydın tamamı yedi bileşen taşır: eşleşme alanları, öncelik, sayaçlar, talimatlar, zaman aşımları, cookie ve bayraklar. Kaydı tekil kılan ikili ise eşleşme alanları ile öncelik.

Üst üste binen desenleri öncelik ayırır. Aynı pakete uyan iki kayıttan önceliği yüksek olan kazanır. Aynı en yüksek öncelikte birden çok kayıt eşleşirse sonuç tanımsız. Sayaçlar da her kayıtta ayrı tutulur: kaç paket ve kaç bayt eşleşti.

Belgeleme adresleriyle kurulmuş bir örnek, s1 switch’inin dört portu için:

198.51.100.7 adresinden 203.0.113.9 adresine giden ve hedef portu 80 olan bir paket iki kayda birden uyar. Kazanan 200 önceliğindeki kayıt ve paket 4 numaralı porttan çıkıyor. Aynı adres çifti arasında hedef portu 22 olan bir paket ise yalnızca 100 önceliğindeki kayda uyar ve 3 numaralı porttan çıkar. Aynı hedefe giden iki paket, iki ayrı porttan çıktı.

Her flow tablosu bir table-miss kaydı taşımak zorunda: bütün alanlar joker, önceliği sıfır. 192.0.2.5 adresinden 192.0.2.9 adresine giden bir paket üç özgül kaydın hiçbirine uymaz; onu bu son satır karşılar. Kayıt hiç yoksa varsayılan davranış paketi düşürmektir.

Eşleşme ile eylemin ikilisi farklı cihazları tek çatı altında topluyor. Router en uzun hedef önekine bakar, switch hedef MAC adresine. Firewall adres ve port ikilisine bakıp izin verir ya da reddeder. Adres çevirisi ise ikisini yeniden yazar. Tek tek tablolar orkestra edildiğinde ağ çapında bir davranış doğuyor, ama hiçbir switch o davranışın tamamını bilmiyor.

Eşleşmenin hangi alanları okuyabildiği de yazılı bir liste. İlk OpenFlow sürümü on iki alan tanımladı ve bu on iki alan, kitabın üç ayrı katmanında tanıdığın başlıklardan geliyor:

Her alanın yanında bir de joker hakkı var: o alanı “umursama” diye işaretlersen kural bütün değerlere uyuyor. Tek bir satır böylece bir paketi değil, bir sınıfı tarif ediyor. Sonraki sürümlerde liste kırkı aştı; IPv6 adresleri, MPLS etiketi ve ARP alanları da eklendi.

Şimdi bunu routing tablosuyla karşılaştır. Orada tek bir alan, hedef IP vardı; eylem de tekti: bir sonraki durağa ilet. Burada on iki alan ve dört eylem ailesi var. Klasik routing, bu tablonun yalnızca hedef IP alanı doldurulmuş, geri kalanı jokerlenmiş özel hâli. Genelleştirilmiş iletme adı da bunu söylüyor: eskisini yok etmiyor, kapsıyor.

Birden çok satırın aynı pakete uyması normal; kazananı öncelik alanı seçiyor. En uzun önek eşleşmesinin buradaki karşılığı bu: orada “daha çok bit sabitleyen” kazanıyordu, burada “yöneticinin daha yüksek numara verdiği”.

Aynı trafiği iki yola nasıl bölersin?

Trafiği ağdaki yollara istenen oranlarda dağıtma işinin adı trafik mühendisliği. Klasik routing’de operatörün elinde tek düğme var: bağlantı ağırlıkları. Gerçek bir denetim için fazlasıyla kaba bir araç. Bir düğümden diğerine akan 10 Gbit/s’lik trafiği %60 ve %40 diye iki yola bölmek istediğini varsay. Birinci yola 6 Gbit/s, ikincisine 4 Gbit/s düşecek. Ağırlıkları oynatarak bu bölüşümü kuramazsın: eşit maliyetli iki yol trafiği yarı yarıya böler, eşit olmayanlarda ucuz olan hepsini alır. Klasik dünyada bu işi 51. bölümde göreceğimiz MPLS trafik mühendisliği ve segment routing yapıyor; ikisi de yolu kaynakta belirliyor.

Asıl istenen şey genelde daha da zor. Aynı iki nokta arasındaki iki trafik türünü ayrı yollardan geçirmek. Karar yalnızca hedef adrese bakıyorsa iki trafik aynı yolu paylaşmak zorunda. Flow kurallarında bu ayrım, kaynak öneki ya da taşıma portu farkıyla iki ayrı kayda yazılır.

Merkezî kontrolün üç gerekçesi var. Birincisi yönetim kolaylığı: yanlış yapılandırmalardan kaçınmak ve flow’lara esnek yollar çizmek. İkincisi merkezden programlamanın kolaylığı. Üçüncüsü açık bir kontrol düzlemi uygulamasının satıcı kilidini kırması.

Dağıtık programlamak zor iştir. 41. bölümde statik yolu elle yazmış, çalışan yapılandırma ile başlangıç yapılandırması arasındaki farkı görmüştün. 500 router’lı bir ağda cihaz başına 2 dakika iyimser bir tahmin. Toplamı yine de 1.000 dakika, yani yaklaşık 16,7 saat; hem de tek bir kural değişikliği için. Otomasyon araçları bu saatleri dakikalara indiriyor ama sorunun kökünü değiştirmiyor: beş yüz kutunun her biri kararı hâlâ kendi başına veriyor.

Bütün bunları toplayan tanım dört maddeli: genelleştirilmiş flow tabanlı iletme, kontrol ile veri düzleminin ayrılması, kontrol işlevlerinin switch’lerin dışında durması ve programlanabilir kontrol uygulamaları. Dördü birden yoksa ortada yazılım tanımlı ağ da yok.

Denetleyici switch’le nasıl konuşuyor?

Denetleyicinin içinde üç bileşen buluyorsun. En altta denetlenen switch’lerle mesajlaşan iletişim katmanı duruyor. Ortada bağlantıların ve switch’lerin durumunu dağıtık bir veritabanında tutan durum yönetimi var. En üstte kontrol uygulamalarına bakan interface katmanı oturuyor.

Yukarıdaki uygulamalarla kuzeye bakan API (northbound) üzerinden, aşağıdaki switch’lerle güneye bakan API (southbound) üzerinden konuşulur. Güneydeki API bir yetenek listesinden çok bir sınır çizgisi: neyin denetlenebilir olduğunu o tanımlıyor.

Kontrol uygulamaları paketten çıkarılmış durumda. Üçüncü bir taraf yazabilir. Veri düzlemi switch’leri ise hızlı, basit ve sıradan olacak şekilde tasarlanıyor. Zekâyı dışarıya verdikleri için ucuzlar.

Güneydeki trafiğin somut hâli OpenFlow. Mesajlar TCP üzerinden taşınır, şifreleme isteğe bağlıdır ve üç sınıf vardır: denetleyiciden switch’e, switch’ten denetleyiciye ve simetrik olanlar. IANA’nın tahsis ettiği varsayılan port TCP 6653; eski 6633 ve 976 portları bırakıldı.

Her mesaj 8 baytlık ortak bir başlıkla başlıyor: 1 bayt sürüm, 1 bayt tür, 2 bayt uzunluk, 4 bayt işlem kimliği. Son alanın adı xid; cevap isteğin xid’ini aynen taşır. Bütün mesajlar big-endian gönderilir. Adlar ile numaralar da sabit:

Bu sayılar OpenFlow 1.5.1 sürümünden; o sürümün sürüm baytı 0x06. Denetleyici switch’e önce ne yapabildiğini sorar; buna features denir. Kural yazma işini modify-state ile yapar. Switch ise tanımadığı bir paketi packet-in ile hem paket hem denetim olarak denetleyiciye devreder.

Bir bağlantı koptuğunda dizi şöyle işliyor. Switch port-status ile denetleyiciyi uyarır. Denetleyici link state (bağlantı durumu) bilgisini günceller. Kayıtlı routing uygulaması çağrılır ve yeni yolları hesaplar. Sonra yalnızca güncellenmesi gereken switch’lere yeni tablolar kurulur.

Bu döngünün bir bedeli var, çünkü denetleyici ayakta olsa bile uzakta. Diyelim ki bir switch’ten tek yön 10 ms uzakta duruyor; uyarının gidişi ve yeni tabloların dönüşü en az 20 ms sürer. Veri düzlemi nanosaniye ölçeğinde çalışıyor, o pencerede çok sayıda paket eski karara göre işlenir. Gerçek kurulumlarda hızlı toparlanma bu yüzden switch’in içinde kalıyor: denetleyici yedek yolu önceden kuruyor, switch bağlantı koptuğu anda yedeğe kendisi geçiyor. OpenFlow’daki adı fast failover grubu.

Operatörler bu mesajları elle üretip göndermez. ONOS’un niyet çerçevesi (intent framework) gibi üst düzey soyutlamalar, ağa nasıl yerine ne istendiğini tarif etmeye yarar.

Zekâ ağın neresinde duruyor?

RFC 7426 yazılım tanımlı ağı bir yetenekle tanımlıyor: yazılım uygulamaları ağ cihazlarını tek tek programlayabilsin ve ağın bütününün davranışı böylece denetlenebilsin. Kilit unsur, iletme düzlemi ile kontrol düzleminin arasına bir soyutlama koymak. Aynı belge ikili değil beşli bir ayrım yapar: iletme, işletim, kontrol, yönetim ve uygulama düzlemleri. Buradaki ikili anlatım onun sadeleştirilmiş hâli.

Yirminci yüzyıl telefon ağında zekâ santrallerdeydi. Uçlar yalnızca rakam ve ses gönderebiliyordu. RFC 1958 internetin ilkesini bunun tersi olarak yazdı: zekâ ağın içine gizlenmez, uçlarda durur. Bugün tablo bir kez daha döndü. Zekâ, ağın içindeki sıradan beyaz kutuların üzerine yazılım katmanı olarak biniyor.

O beyaz kutular artık açık bir API konuşuyor; mimarinin donanım tarafı bu. Aynı kutuların üstünde programlanabilir servisler koşturmayı ise 47. bölümde, yolun üstündeki kutuları açtığımızda ele alacağım. Eşleşme ile eylem fikri de OpenFlow’da durmadı: P4 gibi diller paket işleme hattının kendisini programlanabilir kılıyor. Pazar yine de acımasız: P4’ün en bilinen yongası Intel’in Tofino’suydu ve Intel 2023’te bu ailenin geliştirilmesini durdurdu.

Google kendi ağları için Orion adında bir kontrol düzlemi yazdı. Orada routing ile trafik mühendisliği protokol sayılmaz; Orion’un ortak altyapısının üstünde koşan birer uygulamadır. İç ağda klasik anlamda routing protokolü yok. Google’ın veri merkezlerini bağlayan B4 ağı daha 2013’te hatlarını yüzde yüze yakın doldurabildiğini yayımlamıştı; klasik geniş alan ağlarında bu oran yüzde 30 ile 40 arasında kalıyordu.

Bu mimari bugün veri merkezlerinin içinde ve arasında yaygın kullanılıyor. 5G hücresel ağlarda da taşıyıcı bir bileşen. Aynı ayrımı, 33. bölümde çekirdek ağın denetim ve kullanıcı düzlemlerine bölünmesinde zaten görmüştün.

Merkezîleştirmenin routing’le sınırlı kalması da gerekmiyor: denetleyici, bildirilen tıkanıklık seviyelerine bakıp göndericilerin hızını belirleyebilir. Ağ işlevlerinin bundan sonra protokollerle mi merkezî hesapla mı gerçekleştirileceği açık bir soru.

Bölümün sorusunun cevabı ise tek. Hem hedef tabanlı iletme tablosunu hem genelleştirilmiş flow tablosunu dolduran şey kontrol düzlemidir.

Özet

• Kontrol düzlemi taşınabilir: routing hesabı ya her kutunun içinde koşar ya da uzaktaki bir denetleyicide; bu bir tasarım tercihidir.
• Merkezîlik mantıksaldır: karar mercii tektir, makine tek olmak zorunda değildir; denetleyicinin kendisi fiziksel olarak dağıtık kurulur.
• Kural desen ile eylemden oluşur: eşleşme başlığın birçok alanını birlikte okur, öncelik çakışmayı çözer, sayaçlar da eşleşen paketi ölçer.
• Joker satır zorunludur: hiçbir kuralın tutmadığı paketi table-miss kaydı karşılar, o da yoksa paket düşer.
• Ayrım açık bir protokole dayanır: denetleyici ile switch arasındaki OpenFlow mesajları güneye bakan API’yi somutlaştırır.

Kararı kimin verdiğini artık biliyorsun. Ama verilen kararın işe yarayıp yaramadığı ayrı bir soru: o hattan kaç paket geçti, hangi kural kaç kez tuttu ve bunu kim sayıyor?