SD-WAN Üzerine…
SD-WAN, her ne kadar isminin ortaya çıkışı daha eski olsa da son bir yılda herkes tarafından duyulan ve konuşulan bir konu haline geldi. Hem kurumların teknik ve mali sorunlarına verdiği cevaplar hem de dev şirketlerin yaptığı satın almalar SD-WAN üzerindeki ilgiyi artırdı.
SD-WAN’ın özellikle WAN hatlarının aktif kullanımının sağlanması, bağlantı tipi ve alınan hizmetten (MPLS vb.) bağımsız bir şekilde çalışabilmesi gibi yetenekleri tüm kurumların daha az operasyonel maliyetle çalışma hedefiyle örtüştü. Özellikle internetin bir WAN hattı olarak kullanılabilmesi, MPLS hatlarının yedeği ve hatta alternatifi olabilmesi maliyet kalemindeki en ciddi avantaj diyebiliriz. Bu durum sunulan diğer yeniliklerle de birleştiğinde SD-WAN’ın popülerleşmesi kaçınılmaz hale geldi.
Peki SD-WAN’dan neler beklemeliyiz, neler bu çözümün olmazsa olmazlarıdır, ağ yöneticisinin hayatında neleri değiştirmelidir? Ve akla gelebilecek diğer sorular… Bu yazının amacı bu soruların cevaplarını üretici bağımsız şekilde vermeye çalışmaktır. Sistem entegratörü, kurumsal firma ve üretici şapkalarıyla gördüğüm ve yaşadığım sorunlardan yola çıkarak kendi SD-WAN kriterlerimi oluşturdum ve sekiz başlıkta aktarmaya çalıştım. Umarım sizlerin yaşadıklarınız ve düşündüklerinizle de örtüşür ve bu yazı hepimize bir rehber olur.
SD-WAN ve Olmazsa Olmazları…
Tüm SD-WAN çözümleri altyapıdan bağımsız olma ilkesine göre çalışır ve bu bağımsızlığı IPSec VPN tünelleri vasıtasıyla sağlarlar. SD-WAN tüm yeteneklerini bu ilkenin üzerine inşa eder. Bu ilkenin üzerinde ise bize yepyeni bir WAN deneyimi sunar.
Tak Çalıştır: Plug&Play veya Zero Touch Provisioning olarak da bilinen bu konsept bana göre SD-WAN’ın en önemli vaadi. Binden fazla router’a birkaç haftada konfigürasyon ve yazılım atmış, her yeni açılacak banka şubesi bildiriminde elinde bilgisayar ve konsol kablosuyla depoya koşmuş biri olarak bu maddeyi ilk sıraya koyma lüksüm vardır sanırım 🙂
Tak-çalıştır sözünden benim beklediğim, cihazların BT personeli dahi olmayan kişiler tarafından kurulabilmesinin sağlanması. Peki hiç ağ teknolojilerini bilmeyen biri bir lokasyonun WAN ağını nasıl ayağa kaldıracak? Çok basit. SD-WAN çözümünün uç bileşenleri sahada fiziksel olarak kurulduğunda merkezi bir sistemle otomatik olarak irtibata geçebilmeli, hem yazılım güncellemesi hem de kendisine atanmış olan konfigürasyonu çekebilmeli ve akabinde de görevini yerine getirmeye başlamalıdır. Bunun için en doğru yöntem fabrika çıkışı olarak cihazın ilk sorguyu yapacağı yeri bilmesidir. Böylelikle cihaza konfigürasyon anlamında hiç dokunmadan hazır hale gelecektir. Cihazın nasıl ve nereden konfigürasyon ve yazılımını çekeceğinin sonradan öğretildiği bir çözüm benim kriterlerime göre tam bir tak-çalıştır değil, maalesef. Servis sağlayıcı vb. kaynaklı istisnai durumlar tabi ki olabilir. Bu özellikle amaç; ilk kurulum sürelerini kısaltmak, saha personel giderlerini azaltmak ve problem anında cihaz değişim sürelerini düşürmek diyebiliriz.
Otomatik VPN: Bugüne kadar harika VPN teknolojileri kullandık. Her geçen gün yeni yetenekler eklendi ve çok büyük WAN projeleri gerçekleştirildi. Fakat artık bu işin arka planda kendi kendine gerçekleşmesi ve bizim bu kısmı dert etmememiz gerekiyor. Peki bu nasıl olacak? Tüm uç cihazlar merkezi bir beyin ile irtibata geçecekler. Bu merkezi beyin hem hangi cihazın hangi cihazla ne şekilde VPN yapacağını iletecek hem de cihazların kendi arasındaki güven ilişkisini sağlayacak. Biliyorsunuz IPSec VPN’de Faz-1 diye bir aşama vardır ve bu aşamada VPN yapacak cihazlar birbirlerini bir nevi kimlik doğrulamasından geçirirler ve şifreleme anahtarı paylaşım kriterlerinde anlaşma sağlarlar. Merkezi beyin olduğu durumda ise faz-1 dediğimiz kavramı hayatımızdan çıkaracağız. Sonrasındaki faz-2 aşamasında ise cihazlar birbirleri ile paylaştıkları şifreleme anahtarı, şifreleme tipi ve VPN’e girecek ağlar konusunda anlaşma sağlarlar ve aralarındaki VPN tünelini ayağa kaldırırlar. SD-WAN ile faz-2 aşaması yine merkezi beyin idaresinde otomatik olarak gerçekleşecek. Artık; parametreler mi uyuşmadı, trafiği tetikleyemedik mi gibi soruları sormayacağız. Ayrıca karşılıklı anlaşma (negotiation) yükünden kurtulan cihazlar sadece trafik şifrelemesine odaklanacak ve daha az yorulup daha fazla performans verecekler.
Otomatik Yönlendirme: VPN’i kurmakla bitmiyor tabi çilemiz. Bunun bir de yönlendirme boyutu var. Dinamik yönlendirme protokollerinin seçimi, konfigürasyonu, ölçeklenmesi, hepsi ayrı dert. Peki gerek var mı? Madem merkezi bir beyin bizim için VPN’i kuruyor, o zaman yönlendirmeyi de o yapsın diyemez miyiz? İşte bu sebeple SD-WAN ağ yöneticisini yönlendirme protokolleri ile uğraştırmamalı ve tüm rota paylaşımı merkezi beyin üzerinden otomatik olarak yapılmalıdır. Bu konseptte tüm uç cihazlar üzerlerindeki VPN’e dahil olacak ağları merkezi beyin dediğimiz SDN mimarisinde “controller” olarak adlandırılan yapıya iletirler. Bu yapı da rotaların cihazlar arasındaki dağıtımını belirlenmiş politikalara göre gerçekleştirir. Bugüne kadar öğrendiğimiz ve deneyimlediklerimizi geride bırakmak gibi görünse de, aslında amaç ağ mühendisinin protokoller deryasında boğulmasını engelleyip, gerçekten değer yaratmasını sağlayacak politika yönetimine odaklanmasını sağlamaktır. Dolayısıyla bundan sonra “hangi yönlendirme protokolünü kullanıyorsunuz” diye soranlara “kullanmıyorum, bıraktım” cevabını veriyoruz 🙂
Uygulama ve Performans Bazlı Yönlendirme: SD-WAN denildiğinde aslında akla ilk bu madde gelir. Bu maddenin içeriği için, hem bugüne kadar yapamadığımızdan dolayı hem de amacımıza ulaşsak da kırk takla atmak zorunda kaldığımızdan dolayı SD-WAN’ın en cezbedici yeteneği diyebiliriz. SD-WAN ile, bugüne kadar alıştığımız hedef bazlı yönlendirmenin ötesine geçip uygulamaları ve onların performanslarını odak noktasına koyuyoruz. Peki SD-WAN’dan ne beklemeliyiz detaylandıracak olursak; bu çözüm tanıyabildiği uygulamaların ve ağ yöneticisi tarafından tanıtılan uygulamaların kullanacağı hatları seçebilmemize olanak sağlamalıdır. Bir örnek verecek olursak; kritik bir uygulamamızın fiber MPLS hattından, internet ve e-posta trafiğimizin daha az maliyetli DSL internet hattından çift yönlü olarak gitmesini sağlayabilmeliyiz. Burada önemli olan ilgili trafik tipinin çift yönlü olarak, asimetrik trafik oluşturmadan akmasıdır.
“Biz bunu PBR’la yapıyorduk zaten” diyenler vardır ya da “biz NAT’la çözdük diyenler”… Doğru fakat bunlar hem yönetilmesi, hem izlenmesi hem de problem çözümü zor yöntemler.
Ayrıca bu kadar değil. Ya seçtiğimiz hat kötü performans gösteriyorsa ne yapacağız? MPLS hattında paket kaybı varsa, gecikme varsa kullanıcılarım en kritik uygulamamızı kullanırken sorun mu yaşayacaklar? Tabi ki hayır. SD-WAN belirlediğimiz performans kriterlerine göre (paket kaybı, gecikme, jitter gibi) gerektiğinde uygulamaların en performanslı hattan gitmesini sağlayabilmelidir. Biz bunu IP SLA gibi özellikler kullanarak çözüyorduk diyenler varsa işte o zaman ikinci cümledeki kırk taklayı atmış oluyoruz diyebiliriz 🙂
SD-WAN’dan beklentim hem uygulama tabanlı yönlendirmeyi ve hem de performansa dayalı hat değişimlerini basit politikalarla tanımlamamızı sağlaması ve çift yönlü olarak uygulayabilmesidir.
Segmentasyon ve Güvenlik: Konumuz WAN olduğu için bu konunun doğası gereği uzak ve merkeze nazaran genelde küçük lokasyonlardan bahsediyoruz. Ve genelde gözden uzak olan gönülden de uzak oluyor ve oralarda merkezde gerçekleştirdiğimiz güvenlik politikalarını tam anlamıyla uygulayamıyoruz. Bu durum da bu lokasyonları doğal bir hedef haline getirebiliyor. Peki SD-WAN bize nasıl yardımcı olmalı? İlk önce uç lokasyonlarımızdaki farklı kaynakları, ağları birbirinden izole edebilmemizi sağlamalı. Bunu bir güvenlik duvarı tadında kurallarla da yapabilir, uçtan uca izole ederek birbirlerine hiç ulaşmamalarını da sağlayabilir. Buna örnek olarak banka şubelerindeki ATM’lerin şubedeki bilgisayarlardan izole edilmesi ya da parekende sektöründeki kasa, POS cihazı, mağaza ağı segmentasyonlarını verebiliriz.
Buraya kadar bazı önlemleri aldık fakat SD-WAN’ın internet’i bir WAN altyapısı olarak kullanma fikri aynı zamanda uç noktadan doğrudan internete çıkma fikrini de tetikliyor. Çünkü “madem interneti bir WAN aracı olarak kullanıyorum neden kullanıcılarımı internete eriştirmek için merkeze kadar getireyim” sorusu ortaya çıkıyor. Henüz bu fikir Türkiye’de çok karşılık bulamadı ama mutlaka önem kazanacaktır. İşte SD-WAN çözümü bu noktada kullanıcıların internete çıkışı için gerekli önlemler konusunda da yardımcı olabilmelidir. Bunun içinde içerik filtreleme, IPS, zararlı yazılımlardan koruma, DNS güvenliği gibi başlıkların ihtiyaca göre sağlanması gerekebilir.
Kolay Yönetim ve Ölçeklenebilirlik: Şu ana kadar beş başlıkta bir çok yeteneği açıklamaya çalıştım. Akla doğal olarak şu su gelecektir; bunları gerçekleştirmek için bugünkü gibi komut satırı tabanlı bir yönetim mi yapacağız? Tabi ki hayır. Sanırım kimse bunun zorluğunu hayal bile etmek istemez. SD-WAN bize merkezi ve olabildiğince basit bir grafik tabanlı arayüz üzerinden yönetim sağlamalıdır. Şablonlar, sihirbazlar, sorun tespit araçları, uyarılar, kontrol panelleri… Hepsi ya da bazıları… Önemli olan tek tek uç cihazları yönetmek yerine artık sistemi bir bütün olarak yönetmemizi sağlayacak araçlara sahip olmaktır.
Bu yönetim sistemleri aynı zamanda da ölçeklenebilir olmalıdır. Yatayda büyüme dediğimiz yöntemi benimsemeli ve bizim büyüme, yaygınlaşma, genişleme gibi ihtiyaçlarımıza da cevap verebilmelidir. Bir banka, şubeleri için yatırım yaptıktan sonra, şubelerinin birkaç katı fazla olan ATM’lerini de aynı yapıya dahil edebilmelidir. Ya da bir parekende firması yurtiçi mağazalarından sonra yurtdışı mağazalarını da sisteme dahil etmek istediğinde yönetim katmanında limitlere çarpmamalıdır.
Analitik: Analitik herkesin kullandığı ama çerçevesini çizmeden bıraktığı bir sözcük. Özellikle SD-WAN için analitik ne anlama geliyor kısmı biraz daha belirsiz. Ben kendime göre şu şekilde açıklıyorum: Bugün itibariyle çalışma yöntemimiz birinin problem bildirip bizim kaynağını aramamız üzerine kurulu. Fakat doğru olan ağımızda ne olup bittiğini birisi bize sorun bildirmeden biliyor olmamız ve aksiyon alarak çözüme kavuşturmamızdır. İşte SD-WAN’da analitik tam da bunu amaçlar. Analitik; ağ mühendisi syslog, SNMP, flow vb. bilgiler ile samanlıkta iğne aramadan, tüm bu araçları kullanıp yanına kendi araçlarını da ekleyerek ağ yöneticisine samanlıktaki iğnenin yerini gösterip, kimsenin ayağına batmamasını sağlamamız için bizi yönlendirmektir. Analitik ile artık hangi uygulama WAN üzerinden düşük bir performansla çalışıyor, hangi lokasyonda performans sorunları var gibi gibi soruların cevaplarını elde edebiliriz. Tabi ki bunun yanına başka fonksiyonlar da eklenebilir, daha farklı ilişkilendirme raporları sağlanabilir. Fakat benim beklentim ve olmazsa olmazım budur.
Programlanabilirlik (Software Defined): Adının hakkını vermek diyebiliriz belki de bu madde için. Fakat sadece bu özellik de olsun diye değil, bu bir ihtiyaç olduğu için. Yönetim arayüzlerinin bize sunduğu yeteneklerin dışına çıkabilmek, hatta cihazların yeteneklerinin kabuğunu kırmak, olaylara karşı otomatik aksiyonlar alabilmek… Tüm bunlar programlanabilirliğin bize sağlayabilecekleri. Ya da sadece hayal edebildiklerimiz.
SD-WAN çözümü bize sistemimizi izleyebileceğimiz ve kontrol edebileceğimiz bir API sağlamalıdır. Biz ağ mühendisleri de yazdığımız script ve hatta programlarla, uygulamalarla ağımızı bir orkestra şefi gibi yönlendirebilmeliyiz. Çünkü biz sadece ağ mühendisi değil harika birer de yazılımcıyız 🙂 Yok bu biraz iddialı oldu. Hello World falan yazarız ama en azından 🙂 Neyse kaçış yok, hepimiz ucundan kıyısından öğreneceğiz kod yazmayı.
SD-WAN ve Olursa iyi Olurlar…
Sanırım olursa iyi olur diyeceğimiz ilk konu oldukça net; o da WAN optimizasyonu. Neden “olmazsa olmaz” kategorisinde değil diye sorabilirsiniz. Çünkü WAN optimizasyonu bir türlü pazarda hak ettiği karşılığı bulamadı. SD-WAN’a ait, yeni bir yetenek olmadığı için de bu kategoride olmasının daha doğru olacağını düşündüm. Ama TCP optimizasyonu ile hat verimliliği, caching ve sıkıştırma konuları kesinlikle yabana atılacak özellikler değiller.
Bir parantezi de bulut uygulamaları için açmak gerekli. Belki bu konuya performans tabanlı yönlendirme kısmında değinebilirdim fakat daha az karşılaştığım bir ihtiyaç olduğundan bu kategoriye aldım. SD-WAN çözümünün, bilinen yaygın bulut uygulamalarına, kullanıcıların en hızlı ulaşabileceği şekilde internet çıkışı seçimini yapması gerekiyor. Örneğin Office 365 için, merkez üzerinden mi yoksa lokal internet çıkışından mı daha hızlı cevap alıyoruz, hesaplanmalı ve kullanıcılar en hızlı yol üzerinden yönlendirilmeli.
Buluttan sadece uygulama hizmeti almıyor olabiliriz. Altyapı için de bulut kullanılıyorsa bu durumda bulut veri merkezinde bize ait kaynakların da WAN’ın bir parçası haline gelmesi gerekiyor. Örneğin bazı uygulamalarımız AWS’teki sunucular üzerinde çalışıyorsa uç lokasyondaki ya da merkezdeki kullanıcılarımız SD-WAN ağı üzerinden bu uygulamalara erişebilmelidirler. Dolayısıyla bulut hizmet sağlayıcıların sistemlerinde çalışacak uç cihazların sanal versiyonları SD-WAN çözümü tarafından sağlanabilmeli ve bu sanal cihazlar SD-WAN sisteminin doğal bir parçası olarak çalışabilmelidir.
QoS konusuna hiç değinmedin diyenler olacaktır. Ortada bir WAN varsa, QoS da mutlaka parçası olacaktır ve SD-WAN’ın uygulama tanıma ve bununla ilişkili olarak uygulama QoS fonksiyonlarını yerine getirmemesi düşünülemez. Açıkçası bu yüzden QoS konusuna değinmeye gerek bile duymadım.
Özetle…
Kendi adıma önemli gördüğüm noktaları, üretici bağımsız bir şekilde açıklamaya çalıştım. Mutlaka atladığım noktalar vardır ama bu haliyle de okuyanlarda farklı bir bakış açısı sağlayabildiğimi umuyorum. SD-WAN kavramının derinliğinde kaybolmamanız için ufak bir katkım olduysa ne mutlu bana.
Tags:
2 Comments
Gayet güzel olmuş,ağzınıza sağlık…
Çok, akıcı ve anlaşılır olmuş. Elinize sağlık…