Cisco Meraki: Bulut Yönetimi, Catalyst ve Auto VPN

Meraki Dashboard ağ bileşenlerinin yapılandırma, görünürlük ve yönetim ihtiyaçlarını buluttan ele alır. Bu, kullanıcı trafiğinin bütününün Dashboard üzerinden geçtiği anlamına gelmez. Dağıtık ofis veya perakende şubesi için tasarım yapılırken yönetim bağlantısı, yerel erişim ve siteler arası veri yolu ayrı incelenmelidir. Kurum hangi ekibin hangi network’ü yönetebileceğini, hangi ayarın merkezden uygulanacağını ve yerel destek ekibinin sorumluluğunu belirlemelidir. Şema bu nedenle Dashboard’ı yeni bir inline data-plane cihazı olarak eklemez. Kullanışlı bir bulut yönetim modeli, yalnız ortak panel sağlamakla kalmaz; değişiklik sahipliğini ve gözlem yöntemini de anlaşılır hale getirir.

Auto VPN, aynı Dashboard organizasyonu içindeki uygun WAN appliance’ları arasında VPN bağlantılarını yönetir. Hub’lar diğer hub’larla ve kendilerini seçen spoke’larla bağlantı kurar; spoke’lar ise tanımlanan hub’lara bağlanır. Bu roller, her cihazın bütün diğer cihazlara doğrudan tünel açtığı anlamına gelmez. Aşağıdaki resmî Standard Hub & Spoke örneği veri merkezini, MPLS ve internet taşıyıcılarını, RS-A ve RS-B’yi gösterir. Kesikli yollar overlay ilişkilerini, düz çizgiler fiziksel bağlantıları ayırır. Spoke’lar arasında kaynakta bulunmayan doğrudan bir tünel eklenmemiştir. Topoloji kararı, uygulamaların hangi merkez veya bulut kaynağına erişeceği bilindikten sonra verilmelidir.

VPN’e hangi yerel ağların katılacağı açıkça seçilmelidir. Split tunnel yaklaşımında ilgili VPN subnet’lerine giden trafik overlay üzerinden, diğer trafik uygun yerel yönlendirme kararıyla taşınır. Full tunnel ise ilgili trafiğin bir hub üzerinden çıkmasını sağlayan ayrı bir tercih oluşturur. Bu seçimi yalnız “daha güvenli” etiketiyle yapmak yerine internet erişimi, merkez kapasitesi ve uygulama bağımlılıkları birlikte değerlendirilmelidir. Yönetim trafiği ile istemci trafiği aynı kurala tabi kabul edilmemelidir. Kabul testlerinde şube–merkez erişimi, internet çıkışı ve izin verilmeyen subnet iletişimi ayrı gözlenir. Böylece routing tercihinin kullanıcı deneyimi ve güvenlik kapsamına etkisi görünür olur.

Meraki MS switching ve MR/CW kablosuz seçenekleri ortak yönetim deneyiminde yer alabilir; ancak kablolu erişim ve kablosuz kapsama aynı tasarım problemi değildir. VLAN ve uplink düzeni, PoE ihtiyacı, RF koşulları, istemci yoğunluğu ve kimlik doğrulama birlikte incelenmelidir. Şube şablonları operasyonu sadeleştirebilir, fakat her sahanın fiziksel koşullarını ortadan kaldırmaz. Bir mağazada çalışan tasarımın farklı bina yapısı veya kullanıcı yoğunluğu olan diğer sahada aynı sonucu vereceği varsayılmamalıdır. Saha keşfi ve pilot ölçümleri bu nedenle önemlidir. Ortak panelden elde edilen görünürlük, gerçek uygulama işlemleriyle doğrulandığında daha anlamlı bir operasyon kaydı sağlar.

Katalogda Meraki MV kamera ve MT sensör bileşenleri de portföyün parçası olarak yer alır. Bu bileşenleri yalnız yeni bir ağ cihazı sayısı olarak ele almak yerine, hangi alanın hangi amaçla izleneceğini belirlemek gerekir. Kamera veya sensör verisinin sahibi, erişim yetkisi ve saklama ihtiyacı kurumun ilgili operasyon kararlarına bağlanmalıdır. Teknik tasarımda bağlantı, besleme ve cihaz yönetimi koşulları kontrol edilir. Bunların tamamını MX Auto VPN topolojisine eklemek doğru olmaz; kaynak şema bu bileşenleri göstermez. Ayrı bir saha gereksinimi oluştuğunda desteklenen cihaz ve yerleşim seçenekleri o kapsam için değerlendirilir ve kabul ölçütü tanımlanır.

Desteklenen Catalyst switching platformları için Cloud Management with IOS XE seçenekleri bulunur. Ancak her Catalyst cihazının veya bütün mevcut CLI özelliklerinin aynı şekilde bulut yönetimine taşınacağı varsayılmamalıdır. Donanım modeli, çalışan yazılım, lisans ve hedef yönetim modu resmi uyumluluk ve geçiş dokümanlarıyla karşılaştırılır. Mevcut yönetim IP’si, SVI ve uplink düzeninin hedef modda nasıl işleyeceği özellikle incelenmelidir. Bir firmware değişikliği, geri dönüşte ek koşullar doğurabilir. Bu nedenle dönüşüm planında konfigürasyon kaydı, yönetim erişimini doğrulama ve kurtarma adımları bulunmalıdır. “Catalyst + Meraki” ortak deneyimi, bu teknik sınırlar görülerek değerlendirildiğinde doğru bir beklenti oluşturur.

Bir şubede iki uplink veya birden fazla hub bulunması, bütün arıza senaryolarının aynı şekilde çözüldüğünü göstermez. Hub sırası, ilan edilen subnet’ler, uplink davranışı ve dönüş yolu birlikte değerlendirilmelidir. Sadece şubeden merkeze tek yönlü erişim testi yeterli değildir; uygulamanın yanıtları ve gerektiğinde merkezden başlayan iletişim de incelenir. Test kapsamına taşıyıcı kesilmesi, cihaz yeniden başlatması ve yönetim bağlantısının kaybı gibi gerçek işletim durumları eklenebilir. Sabit bir geçiş süresi ilan etmek yerine kurumun seçtiği mimarinin davranışı ölçülmelidir. Ölçüm, kullanılan konfigürasyon ve yük koşullarıyla birlikte kayıt altına alındığında tekrar değerlendirilebilir.

Dağıtık sahalarda cihazın hazır olması kadar kurulum sırası ve yerel ekip koordinasyonu önemlidir. Saha envanteri, cihaz ataması, uplink bilgisi, hedef şablon ve kabul senaryoları tek plan içinde tutulmalıdır. Pilot sahadan alınan bulgular diğer sahalara aktarılırken fiziksel farklılıklar yeniden kontrol edilir. Operasyon devrinde Dashboard yetkileri, değişiklik yöntemi, alarm sahipliği ve destek eskalasyonu açıklanmalıdır. Trustnet’in katalogdaki analiz, tasarım, geçiş ve operasyon yaklaşımı bu hazırlığı bir proje kapsamında ele alır. Başarılı sonuç, bütün cihazların panelde görünmesinden öte; kullanıcıların gerekli uygulamalara erişebilmesi ve destek ekibinin sorunu kanıtla takip edebilmesidir.