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

Yönlendiriciler 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 yönlendirme algoritmasının bir parçasını kendi içinde koşturur; parçalar birbiriyle konuşarak tabloyu hesaplar. Adı yönlendirici başına kontrol. Bağlantı durumu ilanları bütün otonom sisteme taşı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. Yönlendirici 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 yönlendirici 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. O işletim sisteminin genel adı ROS, yani yönlendirici işletim sistemi.

Ayrımın kendisi yeni sayılmaz. İletme veri düzleminde, yönlendirme 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 orada duruyordu: o altı basamaklık fark iki dünyayı aynı gövdede yan yana tutuyor. Kontrol düzlemini yeniden düşünme ilgisi 2005 civarında canlandı. İnternet tarihi 2008’i yazılım tanımlı ağın yılı olarak yazdı.

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: bağ, ağ ve taşıma katmanı alanları aynı kuralda yan yana gelir.

Akış 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 anahtarının 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. Aynı adres çifti arasında hedef portu 22 olan bir paket ise yalnızca alttaki kayda uyar. Aynı hedefe giden iki paket, iki ayrı porttan çıktı.

Her akış 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. Yönlendirici en uzun hedef önekine bakar, anahtar hedef MAC adresine. Güvenlik duvarı 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 anahtar 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.

Şimdi bunu yönlendirme tablosuyla karşılaştır. Orada tek bir alan vardı — hedef IP — ve tek bir eylem: bir sonraki durağa ilet. Burada on iki alan ve dört eylem ailesi var. Klasik yönlendirme, bu tablonun yalnızca hedef IP alanı doldurulmuş, geri kalanı jokerlenmiş özel hâli. Genelleştirilmiş iletme adı da tam olarak 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 yönlendirmede 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.

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. Akış 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 akışları esnek yönlendirmek. İ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. Statik yolu elle yazmış, çalışan yapılandırma ile başlangıç yapılandırması arasındaki farkı görmüştün. 500 yönlendiricili bir ağda cihaz başına 2 dakika iyimser bir tahmin. Toplamı yine de 1.000 dakika, yani yaklaşık 16,7 saat — tek bir kural değişikliği için.

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

Denetleyici anahtarla nasıl konuşuyor?

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

Yukarıdaki uygulamalarla kuzeye bakan API üzerinden, aşağıdaki anahtarlarla güneye bakan API ü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 anahtarları 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 anahtara, anahtardan 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 anahtara önce ne yapabildiğini sorar; buna features denir. Kural yazma işini modify-state ile yapar. Anahtar ise tanımadığı bir paketi packet-in ile hem paket hem denetim olarak denetleyiciye devreder.

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

Bu döngünün bir bedeli var, çünkü denetleyici ayakta olsa bile uzakta. Diyelim ki bir anahtardan 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.

Operatörler bu mesajları elle üretip göndermez. ONOS’un niyet çerçevesi gibi üst düzey soyutlamalar nasıl yerine ne diye 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. Anahtar 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 yolun üstündeki kutuları açtığımız durakta 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.

Google kendi ağları için ORION adında bir kontrol düzlemi yazdı. Orada yönlendirme ile trafik mühendisliği protokol sayılmaz; çekirdeğin üstünde koşan birer uygulamadır. İç ağda klasik anlamda yönlendirme protokolü yok.

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ı, çekirdek ağın denetim ve kullanıcı düzlemlerine bölünmesinde zaten görmüştün.

Merkezîleştirmenin yönlendirmeyle 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ş akış tablosunu dolduran şey kontrol düzlemidir.

Özet

Peki, ne öğrendik?

• Kontrol düzlemi taşınabilir: yönlendirme hesabı ya her kutunun içinde koşar ya da uzaktaki bir denetleyicide, ve 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 anahtar 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?