Cisco ACI Nedir? Veri Merkezlerinde Politika Tabanlı Otomasyonun Gücü

Bugünün veri merkezleri artık sunucuların birbirine kablolarla bağlandığı basit yapılar değil. Sanallaştırma platformları, konteyner tabanlı uygulamalar, hibrit bulut mimarileri ve yapay zekâ iş yükleri bir araya geldiğinde, ağ altyapısından beklenen çeviklik, ölçeklenebilirlik ve otomasyon seviyesi de köklü biçimde değişiyor.

Geleneksel ağ yönetiminde her VLAN, her ACL, her QoS politikası ya da yönlendirme kuralı cihazda elle yapılandırılır. Küçük ölçekli ortamlarda bu iş görür, ama yüzlerce switch ve binlerce uygulamanın koştuğu bir veri merkezinde aynı yaklaşım operasyonel yükü katlar ve hata payını büyütür.

İşte tam bu noktada Cisco Application Centric Infrastructure (ACI) devreye giriyor. Politika tabanlı (policy-based) ve yazılım tanımlı ağ (Software-Defined Networking – SDN) mantığıyla tasarlanan ACI’de ağ yöneticileri cihazları tek tek yapılandırmaz; uygulamanın neye ihtiyaç duyduğunu tanımlar, altyapı gerekeni otomatik olarak devreye sokar.

İlginizi Çekebilir: Red Hat: Açık Kaynak Kurumsal Altyapı Çözümlerinin Lideri

Geleneksel Veri Merkezi Ağlarının Sınırları

Geleneksel mimarilerde yeni bir uygulamayı devreye almak tek bir ekibin işi değildir. Ağ ekibi VLAN’ları ve yönlendirmeyi kurarken güvenlik ekibi firewall ve erişim kurallarını tanımlar, sanallaştırma ekibi ise kendi payına düşen sanal ağ bağlantılarını hazırlar.

Bu parçalı süreç beraberinde birkaç sorunu getirir:

• Manuel konfigürasyon ihtiyacı artar.
• Operasyonel hata riski yükselir.
• Değişiklik yönetimi zorlaşır.
• Yeni servislerin devreye alınma süresi uzar.

Oysa modern veri merkezlerinde beklenti tam tersi yönde: uygulamaların dakikalar içinde ayağa kalkması. Bu beklentiyi karşılayabilmenin yolu da uygulama odaklı otomasyondan geçiyor.

Cisco ACI Nedir?

Cisco ACI, Cisco Nexus 9000 Serisi anahtarlar üzerinde çalışan, merkezi olarak yönetilen bir veri merkezi ağı çözümü. Temel iddiası basit: ağ altyapısını cihaz bazında değil, uygulamanın ihtiyacına göre otomatik şekillendirmek. Ağ yöneticisinin işi artık tek tek cihaz yapılandırmak değil, uygulamaların birbiriyle nasıl konuşacağını tanımlamak.

Örneğin şu iki kural tanımlanabilir:

• Web sunucuları yalnızca uygulama sunucularına HTTPS üzerinden erişebilsin.
• Uygulama sunucuları yalnızca veritabanı sunucularına belirli portlardan erişebilsin.

Bu tanımlar yapıldığı anda ACI, gereken ağ ve güvenlik yapılandırmalarını kendisi devreye alır. Sonuç: hem operasyonel verimlilik artar hem de veri merkezinin tamamında tutarlı bir güvenlik politikası uygulanmış olur.

Cisco ACI Mimarisi

Cisco ACI mimarisi üç temel bileşen üzerine kuruludur:

• APIC,
• Spine-Leaf fabric,
• Politika tabanlı ağ yönetimi modeli.

APIC (Application Policy Infrastructure Controller)

APIC, ACI altyapısının merkezi yönetim platformudur. Ağ politikalarının oluşturulduğu, fabric’in yönetildiği, tenant yapılarının tanımlandığı ve güvenlik kurallarının uygulandığı katman burası; otomasyon sistemleri de REST API üzerinden bu platforma entegre olur. Önemli bir ayrım var: APIC veri trafiğini taşımaz, yalnızca kontrol düzlemini yönetir.

Spine-Leaf Fabric

Cisco ACI’nin fiziksel omurgası tamamen Spine-Leaf mimarisine dayanır. Leaf switch’ler sunuculara ve servis cihazlarına bağlanırken, Spine switch’ler yalnızca Leaf switch’ler arasındaki yüksek hızlı veri iletimini üstlenir. Her Leaf switch tüm Spine switch’lere bağlıdır; Leaf-Leaf ya da Spine-Spine bağlantısı bulunmaz. Bu düzenin getirisi iki yönlü: gecikme süreleri öngörülebilir hale gelir, kapasite artışı da yalnızca yeni bir Leaf ya da Spine anahtarı eklemek kadar basitleşir.

Politika Tabanlı Ağ Yönetimi

ACI’yi rakiplerinden ayıran asıl unsur, uygulama odaklı politika modelidir. Geleneksel yapılarda yeni bir uygulama devreye alınırken VLAN oluşturulur, ACL yazılır, firewall kuralı eklenir, QoS politikası uygulanır, switch portları tek tek yapılandırılır. ACI’de ise yönetici yalnızca uygulamanın nasıl haberleşeceğini tanımlar; gerisini altyapı halleder.

Bu politika modeli şu nesneler üzerinden kurulur: Tenant, VRF, Bridge Domain, Application Profile, Endpoint Group (EPG) ve Contract. Üç katmanlı tipik bir uygulamada Web EPG, Application EPG ve Database EPG tanımlanır; bu gruplar arasındaki iletişim kuralları da Contract yapısıyla belirlenir. Gerekli VXLAN, erişim politikaları ve ağ yapılandırmalarını ACI otomatik olarak oluşturur. Bu da özellikle mikro segmentasyon ve Zero Trust mimarilerinin hayata geçirilmesini kolaylaştırır.

Red Hat OpenShift ile Entegrasyon

Veri merkezleri artık sadece sanal makinelerden ibaret değil; birçok kurum uygulamalarını Kubernetes tabanlı platformlarda çalıştırıyor, bu alanda da en yaygın tercih Red Hat OpenShift oluyor. Cisco ACI, OpenShift ile doğrudan entegre çalışarak konteyner tabanlı uygulamaların da aynı veri merkezi politikaları kapsamında yönetilmesini sağlıyor.

ACI Container Network Interface (ACI CNI) sayesinde mümkün olanlar:

• Kubernetes Pod’ları doğrudan ACI Fabric içinde endpoint olarak görülebilir.
• Ağ politikaları dinamik olarak uygulanabilir.
• Mikro segmentasyon Pod seviyesine kadar genişletilebilir.
• Bare Metal sunucular, sanal makineler ve konteyner uygulamaları aynı güvenlik modeli altında yönetilebilir.

Bu entegrasyonun pratikteki karşılığı, DevOps ekipleriyle ağ ekipleri arasındaki operasyonel sürtünmenin azalması ve uygulamaların daha hızlı devreye alınabilmesi.

OpenShift Virtualization Desteği

Kurumların bir kısmı sanallaştırma platformlarını çeşitlendirmeyi değerlendiriyor; Red Hat OpenShift Virtualization da sanal makinelerin Kubernetes ortamında çalıştırılmasına imkân veren bu yeni yaklaşımlardan biri. Cisco ACI, sanal makineleri, Kubernetes Pod’larını ve Bare Metal sunucuları tek bir politika modeliyle aynı anda yönetebiliyor. Sonuç olarak, hangi platformda çalışırsa çalışsın tüm uygulamalar için tutarlı ağ ve güvenlik politikaları uygulanabiliyor.

Cisco ACI Multi-Site ile Coğrafi Ölçeklenebilirlik

Kurumsal veri merkezleri genelde tek bir lokasyondan ibaret değildir; üretim, felaket kurtarma (Disaster Recovery) ve yedek veri merkezleri farklı şehirlerde, hatta farklı ülkelerde konumlanabilir. Cisco ACI Multi-Site mimarisi tam da bu ihtiyaca cevap veriyor: birbirinden bağımsız ACI Fabric yapılarını merkezi olarak yönetmeyi mümkün kılıyor.

Her veri merkezi kendi APIC kümesine sahip olmaya ve bağımsız çalışmaya devam eder; politikalar yine de merkezi olarak yönetilebilir. Bunun getirdiği avantajlar şöyle sıralanabilir:

• Veri merkezleri birbirinden bağımsız çalışır.
• Bir lokasyondaki sorun diğer lokasyonları etkilemez.
• Tenant ve güvenlik politikaları merkezi olarak yönetilebilir.
• Disaster Recovery senaryoları daha kolay uygulanabilir.

Nexus Dashboard Orchestrator

Multi-Site mimarisinin merkezinde Nexus Dashboard Orchestrator (NDO) yer alır. NDO, farklı veri merkezlerindeki ACI Fabric’lerin tek bir arayüzden yönetilmesini sağlar; yöneticiler Tenant, VRF, Bridge Domain, Endpoint Group ve Contract gibi politika nesnelerini merkezi olarak oluşturup ilgili veri merkezlerine otomatik olarak dağıtabilir. Bu da özellikle çok lokasyonlu kurumlarda operasyonel tutarlılığı belirgin biçimde artırır.

Multi-Pod ve Multi-Site Arasındaki Fark

Cisco ACI’de sıkça birbirine karıştırılan iki kavram var: Multi-Pod ve Multi-Site. Multi-Pod, tek bir ACI Fabric’in farklı fiziksel lokasyonlara genişletilmesidir; tüm Pod’lar aynı APIC kümesi tarafından yönetilir ve tek bir Fabric gibi davranır. Bu yapı, düşük gecikmeli metro mesafelerindeki veri merkezleri için uygundur.

Multi-Site ise farklı bir modele dayanır: her veri merkezi kendi bağımsız Fabric’ine ve APIC kümesine sahiptir, yönetim ise Nexus Dashboard Orchestrator üzerinden merkezi olarak yapılır. Coğrafi olarak uzak lokasyonlar ve felaket kurtarma senaryoları için daha uygun çözüm budur.

VMware’den OpenShift’e Geçiş Sürecinde Cisco ACI

Birçok kurum sanallaştırma stratejisini yeniden gözden geçiriyor; bu süreçte VMware tabanlı iş yükleri Kubernetes ve OpenShift tabanlı uygulamalarla aynı veri merkezinde yan yana çalışabiliyor. Cisco ACI, VMware, Red Hat OpenShift ve Bare Metal sunucular arasında ortak bir politika modeli sunarak bu geçişi kolaylaştırıyor — uygulamanın hangi platformda çalıştığı değil, nasıl haberleşeceği ön plana çıkıyor.

Cisco ACI’nin Sağladığı Avantajlar

Toparlamak gerekirse Cisco ACI, modern veri merkezlerine şu avantajları kazandırıyor:

• Merkezi ve politika tabanlı yönetim
• Ağ otomasyonu ve API desteği
• Mikro segmentasyon ve Zero Trust yaklaşımı
• Red Hat OpenShift ve Kubernetes entegrasyonu
• Çoklu veri merkezi yönetimi (Multi-Site)
• Esnek ve ölçeklenebilir Spine-Leaf mimarisi
• REST API, Terraform ve Ansible ile otomasyon
• Daha hızlı uygulama devreye alma süreçleri
• Tutarlı güvenlik politikaları
• Hibrit bulut ve modern uygulama platformlarına hazır altyapı

Veri merkezlerinin dönüşümü, ağ altyapısının da dönüşmesini zorunlu kılıyor. Cihaz odaklı geleneksel yönetim anlayışı yerini uygulama odaklı, otomasyon destekli yaklaşımlara bırakıyor. Cisco ACI, politika tabanlı yönetim modeliyle ağ operasyonlarını sadeleştirirken; merkezi yönetim, mikro segmentasyon, otomasyon ve çoklu veri merkezi desteğiyle modern veri merkezlerinin ihtiyaçlarını karşılayan güçlü bir platform sunuyor.

Red Hat OpenShift entegrasyonu, OpenShift Virtualization desteği ve Nexus Dashboard Orchestrator ile sağlanan Multi-Site yönetimi bir araya geldiğinde, Cisco ACI artık sadece bir SDN çözümü olmaktan çıkıp hibrit bulut ve cloud-native uygulamalar için stratejik bir veri merkezi platformuna dönüşüyor.

Sekom olarak, veri merkezi ve Cisco teknolojileri alanındaki deneyimimizle Cisco ACI fabric tasarımı, kurulumu ve mevcut altyapıyla entegrasyonu konusunda kurumlara uçtan uca destek sağlıyoruz. Veri merkezi ağınızı politika tabanlı bir mimariye taşımayı değerlendiriyorsanız, uzmanlarımızla iletişime geçebilirsiniz.