Çok Şubeli Bir Ağı Hat Çeşitliliğiyle Tasarlamak

Çok şubeli ağ tasarımında en pahalı hata teknoloji seçiminde yapılmaz. Genellikle ilk cümlede yapılır: “her şubeye iki hat çekelim”. İki hat iyi bir başlangıç, ama iki hattın ikisi de aynı sokaktaki aynı kutuya, aynı santrale ya da aynı omurgaya bağlıysa elinizde iki hat yok. Bir hat ve bir fatura daha var.

Bu rehber sırayla şunu kuruyor. Şubeleri neye göre ayıracaksınız, çeşitliliği nasıl gerçek kılacaksınız, merkez tarafını nasıl tekil olmaktan çıkaracaksınız, yol seçimini neye bağlayacaksınız ve kurulumu hangi sırayla yapacaksınız.

Önce Sınıflandırma, Sonra Tasarım

Bütün şubelere aynı tasarımı uygulamak iki yönde de hata üretir. Küçük şubelere gereğinden fazla para harcarsınız, kritik olanlara ise yetmeyen bir şey kurarsınız.

Sınıflandırmayı kesinti tahammülüne göre yapın, çalışan sayısına göre değil. Sorulacak soru şu: bu şube bir saat boyunca merkeze erişemezse ne durur ve bunun bedeli nedir? Kasiyerin çevrimdışı çalışabildiği bir mağaza ile stok hareketi merkezden onay bekleyen bir depo, aynı çalışan sayısıyla bambaşka iki sınıftır.

Pratikte üç sınıf çoğu kuruma yeter. Kesintiye hiç tahammülü olmayan az sayıda nokta: iki bağımsız hat, ikisi de aktif, otomatik geçiş, yerinde yedek donanım. Orta grup. İki hat ama biri daha ucuz ve yalnız devreye giren bir yedek, donanım yedeği merkezde. En geniş grup. Tek hat, hızlı kargo anlaşması ve mobil bir yedek çıkış.

Bu ayrımı yazılı yapın ve iş birimlerine onaylatın. Onaylatmazsanız kesinti günü herkes kendi şubesinin birinci sınıf olduğunu hatırlar.

##

“İki Hat” Ne Zaman Gerçekten İki Hattır

Hat çeşitliliğinin ölçüsü faturadaki iki farklı isim değil. Ölçü şu: bir kesinti iki hattı birden düşürebilir mi?

Şunları sorun. İki hat binaya farklı fiziksel yollardan mı giriyor, yoksa aynı kanaldan mı? Aynı saha dolabından mı besleniyor? İki taşıyıcının omurgası bir noktada aynı altyapıyı mı kullanıyor? Toptan hat satın alan bir sağlayıcıyla çalışıyorsanız, alt taşıyıcının kim olduğunu biliyor musunuz?

Son madde en sık gözden kaçan. İki farklı şirketten alınan iki hattın ikisi de aynı altyapı sahibinden kiralanmış olabilir ve bu, sözleşmede yazmaz. Sormak zorundasınız, cevabı da yazılı isteyin.

Gerçek çeşitlilik için erişim teknolojisini değiştirmek en sağlam yol. Karasal bir hattın yanına hücresel bir bağlantı koymak, iki karasal hat almaktan çoğu zaman daha iyi bir yedeklilik verir — çünkü kazma kepçesi ikisini birden kesemez. Hücresel hattın kendi sınırları var: hacim, gecikme, kapalı alanda sinyal. Bunları yedek olarak kabul edip ana hat gibi kullanmamak gerekir. Antenin nereye konacağını kurulum günü değil, keşif gününde kararlaştırın.

Son bir ayrıntı: elektrik. İki hattı olan ama tek prizle beslenen bir şubede yedeklilik yoktur. Kesintisiz güç kaynağının kapsamına modem ve anten de girmeli.

Merkez Tekilse Tasarım Tekildir

Şubelerin hepsine ikinci hat çekip merkezde tek bir uçta toplayan tasarımlar yaygın. Bu tasarımda şube arızası çözülmüştür, kurum arızası çözülmemiştir.

Merkez tarafında en az iki şey ayrışmalı. Tünellerin sonlandığı cihaz ve o cihazın bağlı olduğu internet çıkışı. İkinci bir veri merkezi mümkün değilse, en azından merkezde iki bağımsız çıkış ve tünelleri iki uca da kurabilen bir yapılandırma olsun. Şube bir uca ulaşamadığında diğerine gitsin.

Burada sık yapılan hata, ikinci ucu yapılandırıp hiç test etmemek. Yılda bir kez birinci ucu planlı olarak kapatın ve şubelerin gerçekten ikinciye geçtiğini görün. Test edilmemiş bir yedeklilik, mimari olmaktan çok muhasebe kaydıdır.

Bulut hizmetlerinin ağırlıkta olduğu kurumlarda ayrı bir soru var. Bütün şube trafiğini merkeze taşıyıp oradan internete çıkarmak hâlâ doğru mu? Merkezden çıkış denetimi ve kaydı kolaylaştırır, ama her şubenin trafiğine merkeze kadar bir gidiş dönüş ekler ve merkezi darboğaz yapar. Yerel çıkış hızlıdır ama denetim ve kayıt sorumluluğunu şubeye dağıtır. Karar, uygulama karışımınıza ve kayıt yükümlülüğünüze bağlı; ikisini birden düşünmeden verilirse yanlış çıkar.

Yol Seçimini Neye Bağlayacaksınız

SD-WAN’ın satış vaadi burada. Trafiği o an daha iyi olan hattan geçirmek. Vaadin gerçek karşılığı, “iyi”yi neye göre tanımladığınıza bağlı.

Hattın ayakta olup olmadığına bakan bir ölçüm en basit ve en yanıltıcı olanı. Hatlar nadiren tamamen ölür; daha sık olan şey, ayakta kalıp bozulmasıdır. Paket kaybı yüzde birkaça çıkmış bir hat, ping’e cevap vermeye devam eder ve dosya transferini yavaşlatmaz bile — ama sesli görüşmeyi kullanılamaz hâle getirir.

Bu yüzden ölçütü uygulamanın hissettiği şeye bağlayın. Gecikme, gecikme değişkenliği ve paket kaybı birlikte ölçülmeli, ölçüm de trafiğin gerçekten gittiği hedefe doğru yapılmalı. Kendi merkezinize doğru sağlıklı görünen bir hat, bulut sağlayıcınıza doğru kötü olabilir.

Eşikleri belirlerken bir tuzak var. Çok hassas eşik, trafiği hatlar arasında sürekli gidip gelmeye zorlar. Her geçiş oturumları etkiler; sürekli geçiş yapan bir yapı, kötü hattan daha kötüdür. Geçiş için bir eşik, geri dönüş için biraz daha iyi bir eşik tanımlayın ve arada bir bekleme süresi bırakın.

Bir de kuralın kapsamı meselesi. “Ses trafiği iyi hattan gitsin” cümlesinin cihazdaki karşılığı, ses trafiğini nasıl tanıdığınıza bağlı. Port ve adrese göre tanıyorsanız bulut tabanlı bir görüşme servisi bunu boşa çıkarır. Uygulama tanımaya dayanıyorsanız, tanımanın şifreli trafikte ne kadar çalıştığını bilerek kurun.

Adresleme ve İsimlendirme

Bu bölümün sıkıcı görünmesi aldatıcı. Çok şubeli ağlarda en çok zaman kaybettiren şey burada başlar.

Şube adres planını en baştan sistemli kurun. Şube numarasından adres bloğunun türetilebildiği bir şema, üçüncü yılda arıza ararken bir mühendisin hafızasından tasarruf ettirir. Yeni şubeler için baştan yer ayırın. Blokları sıkı verirseniz büyüyen bir şube tüm planı bozar.

Çakışma kontrolünü kurulum öncesine alın. Devralınan şubeler, satın alınan şirketler ve yıllar içinde kendi kendine adres seçmiş noktalar, birleştirme gününde birbiriyle çakışır. Çeviriyle örtmek mümkün ama her ek katman sonraki arıza aramasını zorlaştırır.

İsimlendirme de aynı hikâye. Tünellere, hatlara ve politikalara verilen adlar bir kalıba uysun. Cihaz üzerinde tunel1, tunel2 gören biri hangisinin hangi şube olduğunu bilemez, gece yarısı da bilmesi gerekecek.

Kurulum Sırası ve Şubeye Giden Kutu

Şubelere donanım göndermeden önce merkez tarafını bitirin ve tek bir pilot şubeyle uçtan uca çalıştırın. Pilot şubeyi kolay olanlardan değil, orta zorlukta bir yerden seçin; en kolay şubede karşılaşmadığınız her şey, elli şubeye dağıldıktan sonra karşınıza çıkar.

Kutuyu şubeye giderken tam yapılandırılmış göndermek en sorunsuz yöntem. Şubede teknik personel olmadığı varsayımıyla çalışın. Kabloların hangi porta takılacağı resimli olsun, açılışta bir gösterge kullanıcının okuyabileceği bir şey söylesin ve cihaz merkeze ulaşamadığında ne yapacağı önceden tanımlı olsun.

Uzaktan yönetimin kendisi için ayrı bir yol düşünün. Ana bağlantı üzerinden yönetilen bir cihaz, ana bağlantı bozulduğunda tam da müdahale etmeniz gereken anda erişilemez olur. Hücresel yedek hattın üstünden çalışan bir yönetim erişimi, ya da konsola ulaşmanın başka bir yolu, elli şubelik bir kurulumda kendini ilk ayda amorti eder.

Toplu yayılırken tempoyu bölün. Haftada birkaç şube, her dalgadan sonra bir gözlem. Elli şubeyi iki haftada açan ekip, üçüncü haftada aynı hatanın elli kopyasıyla uğraşır.

Kesinti Tatbikatı

Tasarımın doğru olduğunu kesinti günü öğrenmek istemezsiniz.

Yılda bir kez, planlı olarak, birkaç şubede ana hattı fiziksel olarak çekin. Ölçün. Geçiş ne kadar sürdü, hangi oturumlar koptu, kullanıcı ne hissetti, uyarı sistemine bildirim düştü mü, kim gördü. Sesli görüşme ve masaüstü oturumları bu testte en hassas göstergelerdir; dosya kopyalama geçişi neredeyse hiç hissetmez ve sizi yanıltır.

Aynı tatbikatta merkez tarafını da sınayın. Birinci uç kapandığında şubeler ikinciye geçiyor mu, geçtiklerinde politikalar aynı mı, kayıtlar akmaya devam ediyor mu?

Bu Tasarıma Ne Zaman Girişilmemeli

Uygulamalar zaten bulutta ve şubeler merkeze bağımlı değilse. Merkeze giden ağır bir tünel mimarisi kurmanın karşılığı yoksa kurmayın. Böyle bir kurumda doğru yatırım, şubenin internet çıkışını sağlamlaştırmak ve kimlik ile erişim denetimini uygulama tarafına taşımak olabilir. Ağ katmanında çözülmesi gereken bir sorun olmadan ağ projesi başlatmayın.

Hat çeşitliliği fiziksel olarak mümkün değilse. Tek altyapının bulunduğu bir yerleşimde ikinci karasal hat almak, aynı riski iki kez satın almaktır. Orada doğru hamle farklı bir erişim teknolojisi eklemek ya da o şubenin çevrimdışı çalışabilmesini sağlamak. Yazılım katmanı, olmayan fiziksel çeşitliliği üretemez.

Ekip sayı olarak yetmiyorsa. Merkezden yönetilen bir yapı, merkezde birinin yönetmesini gerektirir. Elli şubelik bir ağı tek kişiyle ayakta tutmayı planlıyorsanız, tasarımı o kişinin izne çıktığı haftaya göre yapın: standart yapılandırma, az sayıda istisna, yazılı yordam. İstisnası bol bir tasarım, kadro büyümeden kurulmaz.