Cisco ACI Nedir?

1. Cisco ACI Nedir?

Cisco  Application Centric Infrastructure (ACI), ağın tanımlanması için uygulama gereksinimlerini mümkün kılmaktadır. Bu mimari, tüm uygulama dağıtım ömrünü basitleştirir, optimize eder ve hızlandırır.


ACI Denetleyicisi Hakkında

Cisco Application Policy Altyapısı Denetleyicisi (APIC) API, uygulamaların, ağ, hesaplama ve depolama yeteneklerini içeren güvenli, paylaşılan, yüksek performanslı bir kaynak havuzuna doğrudan bağlanmasını sağlar. Aşağıdaki şekil APIC’e genel bir bakış sunmaktadır.

APIC, ölçeklenebilir, çok katmanlı bu ACI altyapısını yönetir. APIC, bu altyapı dizisi için birleştirilmiş bir otomasyon, yönetim, politika programlama, uygulama dağıtımı ve sağlık izleme platformu sunar. Çoğaltılan senkronize edilmiş kümelenmiş kontrolör olarak uygulanan APIC, performansı optimize eder, herhangi bir uygulamayı her yerde destekler ve fiziksel ve sanal altyapının birleşik bir şekilde çalışmasını sağlar. APIC, ağ yöneticilerinin, uygulamalar için en uygun ağı kolayca tanımlamalarını sağlar. Veri merkezi operatörleri, uygulamaların ağ kaynaklarını nasıl tükettiklerini kolayca görebilir, uygulama ve altyapı sorunlarını kolayca izole edip giderebilir ve kaynak kullanım modellerini izleyebilir ve profilleyebilir.

Cisco Uygulama Merkezli Altyapı Sistemine Genel Bakış

Cisco Application Centric Altyapı Fabrikası (ACI) altyapısı, Yaprak (Leaf) / Omurga (Spine) ACI sistemi modunda çalışacak APIC’li Cisco Nexus 9000 Serisi switchleri içerir. Bu anahtarlar her bir LEAF düğümünü bir SPINE düğümüne bağlayarak FAT-TREE ağ oluşturur; Diğer tüm aygıtlar LEAF düğümlerine bağlanır. APIC, ACI altyapısını yönetir. APIC için önerilen minimum yapılandırma, üç adet çoğaltılmış ana bilgisayardan oluşan bir yapıdadır. APIC altyapı yönetimi fonksiyonları sistemin veri yolunda çalışmaz. Aşağıdaki resim LEAF / SPINE ACI altyapısına genel bir bakış sunmaktadır.

Şekil 2: ACI Altyapısına Genel Bakış

ACI yapısı, yüksek bant genişliği bağlantılarında (40 Gbps, ileride 100 Gbps’lik bir kapasite ile) tutarlı ve düşük gecikmeli iletme olanağı sağlar. Kaynak ve varış yeri aynı Leaf switchinde olan trafik yerel olarak yönetilir ve diğer tüm trafik, Leaf girişinden bir omurga anahtarı aracılığıyla çıkış Leaf’a gider. Bu mimari fiziksel açıdan iki atlama oluyormuş gibi görünse de, sistemde tek bir Layer-3 switchi varmış gibi çalıştığı için aslında tek bir Layer-3 atlamasıdır.

ACI altyapısı nesne yönelimli işletim sistemi (OS) her Cisco Nexus 9000 Serisi düğümünde çalışır. Sistemin her yapılandırılabilir öğesi için nesnelerin programlanmasını sağlar. ACI sistemi işletim sistemi, politikaları APIC’ten alarak fiziksel altyapıda çalışan somut bir modele dönüştürür. Somut model, derlenmiş yazılımlara benzemektedir; Switch’in işletim sisteminin uygulayabileceği model biçimidir. Aşağıdaki şekil, mantıksal modelin somut modele ve Switch işletim sistemi arasındaki ilişkiyi göstermektedir.

Şekil 3: Somut Modele Verilen Mantıksal Model

Tüm geçiş düğümleri somut modelin tam bir kopyasını içerir. Bir ağ yöneticisi APIC’de bir yapılandırmayı temsil eden bir kuraloluşturduğunda, APIC mantıksal modeli günceller. APIC daha sonra, somut modelin güncellendiği tamamen hazırlanmış bir politika oluşturma aşamasını tüm geçiş switch’i düğümlerine basarak gerçekleştirir.

Cisco Nexus 9000 Serisi switchler yalnızca somut modeli çalıştırabilir. Her switch’de somut modelin bir kopyası zaten vardır. Böylelikle APIC çevrimdışı olursa bile sistem altyapısı çalışmaya devam eder, ancak politikalarında değişiklikler yapılması mümkün değildir.

APIC, sistem altyapısı aktivasyonundan, anahtar yazılım yönetiminden, ağ politikası konfigürasyonundan ve örnekleme işlemlerinden sorumludur. APIC, sistem altyapısının merkezi politikası ve ağ yönetim motoru olarak hareket ederken, yönlendirme topolojisi de dahil olmak üzere tüm veri yolundan kaldırılır. Bu nedenle, sistem altyapısı, APIC ile iletişim kesildiğinde bile trafiği iletmeye devam eder.

Cisco Nexus 9000 Serisi anahtarlar,  Cisco NX-OS Stand-Alone modunda mevcut Cisco Nexus anahtarları ile uyumluluk ve tutarlılık için veya ACI modunda APIC’in uygulama kuralı odaklı hizmetlerden ve altyapı otomasyon özelliklerinden tam olarak yararlanmak için çalışabilecek modüler ve sabit 1, 10 ve 40 Gigabit Ethernet anahtar yapılandırmalarını sunar.

Sistem Altyapısının Nasıl Davranacağının Belirlenmesi

ACI sistem altyapısı, müşterilerin bulut konuşlandırmaları için ölçeklenebilir, yüksek performanslı ağ, işlemci, bellek ve depolama kaynaklarını otomatikleştirip orkestra etmesine olanak tanır. ACI sistem altyapısının nasıl davrandığını tanımlayan kilit oyuncular şunlardır:

• BT planlayıcıları, ağ mühendisleri ve güvenlik mühendisleri
• Sisteme APIC API’lerinden erişen yazılım geliştiriciler.
• Uygulama ve ağ yöneticileri

Temsili Durum Aktarımı (REST – Representational State Transfer) mimarisi bulut teknolojisini destekleyen önemli bir geliştirme yöntemidir. ACI API, REST tabanlıdır. World Wide Web (WWW), REST mimari stiline uyan sistemin en büyük uygulamasını temsil eder. Bulut bilgi sistemleri, ölçek ve yaklaşım açısından geleneksel bilgi sistemlerinden farklıdır. Bu konvansiyonel ortamlar, önemli beceri setleri ile yazılım ve bakım gereksinimlerini içererek işletme giderlerini tüketen bir yapıya sahiptir. Bulut uygulamaları, hızla azalan maliyet eğrisi boyunca uygulanan çok büyük ölçekli altyapı tarafından desteklenen sistem tasarımlarını kullanır. Bu altyapı türünde sistem yöneticileri, geliştirme ekipleri ve ağ uzmanları çok daha fazla değerli katkı sağlamak için işbirliği yapmaktadır. Geleneksel ayarlarda bilgisayar kaynakları ve sunucular için ağ erişimi, sanal LAN’lar (VLAN) veya trafik yük dengeleyici ve güvenlik duvarları gibi sıkı bir şekilde tanımlanmış ağ hizmetleri üzerinden  Multiprotocol Label Switching (MPLS) gibi katı katmanlarla yönetilir. APIC, programlanabilirlik ve merkezi yönetim için tasarlanmıştır. Ağın soyutlandırılması ile, ACI yapısı operatörleri statik bir şekilde değil, operatörlerin ağdaki kaynakları tahsis edilmesini sağlar. Sonuç, işin yapılma  zamanı (pazarlama süresi) aylar veya haftalar dan dakikalara indirilebilir. Sanal veya fiziksel switchler, bağdaştırıcılar, kurallar ve diğer donanım ve yazılım bileşenleri yapılandırmasında yapılan değişiklikler birkaç dakika içinde API uygulamalarıyla yapılabilir.

Geleneksel uygulamalardan bulut bilgi işlem yöntemlerine geçiş, veri merkezlerinde esnek ve ölçeklenebilir hizmetler talebini artırıyor. Bu değişiklikler, bu dönüşümü sağlamak için oldukça fazla yüksek vasıflı personel havuzu ihtiyacı doğuruyor. APIC programlanabilirlik ve merkezi yönetim için tasarlanmıştır. APIC’in en önemli özelliği, REST adlı web API’sidir. APIC REST API, JavaScript Nesne Gösterimi (JavaScript Object Notation – JSON) veya Genişletilebilir Biçimlendirme Dili (Extensible Markup Language – XML) belgeleri içeren HTTP veya HTTPS iletilerini kabul eder ve işler. Bugün birçok web geliştiricisi RESTful yöntemlerini kullanmaktadır. Web API’lerini ağ üzerinden kabul etme, kurumların kolayca açılıp ve hizmetleri diğer dahili veya harici sağlayıcılarla birleştirmesini sağlar. Bu süreç, ağı karmaşık statik kaynak karışımından, talep üzerine oluşan dinamik bir hizmet dönüşümüne geliştirir.

 

 

2. ACI Politika Modeli

ACI Politika Modeli Hakkında

ACI politika modeli, uygulama ihtiyaçları kurallarını etkinleştirir. APIC otomatik olarak sistem altyapısında politikalar oluşturur. Bir kullanıcı veya süreç sistemdeki bir nesneye idari bir değişiklik başlattığında, APIC önce bu değişikliği politika modeline uygular. Bu politika modeli değişikliği, daha sonra gerçekte yönetilen son noktaya uygulanır. Bu yaklaşıma, model odaklı bir çerçeve denir.

Politika Modeli Kilit Karakteristikleri

Politika modelinin temel özellikleri şunları içerir:

• Model odaklı bir mimari olarak, yazılım “sistemin (modelin) idari ve operasyonel durumunun eksiksiz bir andaki temsilini” yürütmeye devam eder. Model; sistem altyapısına, hizmetlere, sistem davranışlarına ve ağa bağlı sanal ve fiziksel cihazlara düzgün şekilde uygulanır.

• Mantıksal ve somut alanlar birbirinden ayrılır; Mantıksal konfigürasyonlar, mevcut fiziksel kaynaklarla ilişkili olarak politikaları uygulayarak somut konfigürasyonlara dönüştürülür. Somut varlıklara karşı hiçbir yapılandırma yapılmamaktadır. Somut varlıklar, bitişik olarak APIC politika modelindeki değişikliklerin yan etkisi olarak yapılandırılmıştır. Somut varlıklar fiziksel (sanal makine veya VLAN gibi) olabilir, ancak olmak zorunda değildir.

• İlke modeli yeni aygıtı içerecek şekilde güncellenene kadar sistem yeni bağlanan aygıtlarla olan iletişimi yasaklar.

• Ağ yöneticileri, mantıksal ve fiziksel sistem kaynaklarını doğrudan yapılandıramazlar; sistem davranışının farklı yönlerini kontrol eden mantıksal (donanımdan bağımsız) yapılandırmaları ve APIC ilkelerini tanımlarlar.

Yönetilen modeldeki nesne manipülasyonu, mühendisleri izole edilmiş tek tek bileşen yapılandırmaları görevinden kurtarır. Bu özellikler otomasyonu etkinleştirir ve altyapının herhangi bir yerindeki herhangi bir işyükü bulabilen esnek iş yükü dağılımını sağlar. Ağa bağlı hizmetler kolaylıkla kullanılabilir ve APIC, bu ağa bağlı hizmetlerin yaşam döngüsünü yönetmek için bir otomasyon çerçevesi sağlar.

Mantıksal Yapılar

Politika modeli; altyapı, kimlik doğrulama, güvenlik, servisler, uygulamalar ve teşhisler de dahil olmak üzere tüm sistemi yönetir. Politika modelindeki mantıksal yapılar, sistem altyapısının ve altındaki herhangi bir işlevinin ihtiyaçlarını nasıl karşıladığını tanımlar. Aşağıdaki şekilde ACI ilke modeli mantıksal yapılarına genel bir bakış sunulmaktadır.

Şekil 4: ACI Politika Modeli Mantıksal Yapılarına Genel Bakış

Tüm sistem genelinde veya Tenant yöneticileri, uygulama veya paylaşılan kaynak gereksinimlerini içeren önceden tanımlanmış ilkeler oluşturur. Bu ilkeler, yöneticileri altyapı oluşturma görevleri yerine kaynaklar havuzunu uygulamalarla konfigüre etme pozisyonuna getiren; uygulamaları, ağa bağlı hizmetleri, güvenlik politikalarını ve tenant alt ağlarının sağlanmasını otomatikleştirir. Yani uygulamanın, ağ oluşturma davranışını yönlendirmesi gerekir, tersi değil.

Cisco ACI Politika Yönetim Bilgi Modeli

Tüm sistem, hiyerarşik Yönetim Bilgi Ağacında (Management Information Tree – MIT) temsil edilebilen Yönetim Bilgisi Modeli’nde (Management Information Model  – MIM) kaydedilen fiziksel ve mantıksal bileşenleri içerir. Bilgi modeli APIC üzerinde çalışan süreçler tarafından saklanır ve yönetilir. OSI Ortak Yönetim Bilgisi Protokolü (Common Management Information Protocol – CMIP) ve diğer X.500 değişkenlerine benzer şekilde, APIC, yönetilebilir özelliklerini, hiyerarşik yapı içindeki nesnenin konumuna göre devralınabilen nesne özellikleri olarak sunarak yönetilen kaynakların kontrol edilmesini sağlayan MIT’den oluşmaktadır. Ağacın her düğümü yönetilen bir nesne (Managed Object – MO) veya bir nesne grubunu temsil eder. MO’lar tüm sistem altyapısı kaynaklarının soyutlamış halleridir. Bir MO; uygulama profili, uç nokta grubu veya hata gibi anahtar, bağdaştırıcı veya mantıksal bir nesne olarak somut bir nesneyi temsil edebilir.

Şekil 5: Cisco ACI Politika Yönetim Bilgi Modeli’ne (MIM) Genel Bakış

Hiyerarşik yapı, üstteki (Kök) politika evreniyle başlar ve üst ve alt düğümleri içerir. Ağacın her düğümü bir MO’dur ve tüm sistemdeki her nesne, nesneyi tanımlayan ve ağaçtaki yerini belirleyen benzersiz bir ayırt edici adaya (DN – Distinguished Name) sahiptir.

Aşağıdaki yönetilen nesneler sistemin çalışmasını sağlayan ilkeleri içerir:

• APIC denetleyicileri, multitenat için yönetim, kural programlama, uygulama dağıtımı ve sağlık denetimi sağlayan çoğaltılmış senkronize edilmiş kümelenmiş bir denetleyici içerir.

• Bir tenant, yönetici tarafından alan adı tabanlı erişim kontrolü yapmasını sağlayan politikalar için bir konteynerdir. Sistem aşağıdaki dört çeşit tenantı sunmaktadır:

◦ Kullanıcı tenantları, kullanıcıların ihtiyaçlarına göre yönetici tarafından tanımlanır. Bunlar; uygulamalar, veritabanları, web sunucuları, ağa bağlı depolama, sanal makineler ve benzeri gibi kaynakların çalışmasını yöneten kurallar dizisi içerir.

◦ Ortak tenant sistem tarafından sağlanır, ancak genel sistem; yönetici tarafından yapılandırılabilir. Güvenlik duvarları, yük dengeleyici, Layer 4 ile Layer 7 hizmetleri, saldırı tespit aletleri ve benzeri gibi tüm tenantlar tarafından erişilebilir olan kaynakların çalışmasını yöneten politikaları içerir.

◦ Altyapı tenant sistemi tarafından sağlanır ancak genel sistem yöneticisi tarafından yapılandırılabilir. Genel sistem VXLAN overlay networkü gibi altyapı kaynaklarının işleyişini yöneten politikalar içerir. Aynı zamanda, bir genel sistem sağlayıcısının kaynakları bir veya daha fazla kullanıcı tenantına seçici olarak dağıtmasını sağlar. Altyapı tenant poliçeleri, genel sistem yöneticisi tarafından konfigüre edilebilir.

◦ Yönetim tenantı, sistem tarafından sağlanır ancak Genel Sistem yöneticisi tarafından yapılandırılabilir. Genel Sistem düğümlerinin bant içi ve bant dışı yapılandırması için kullanılan Genel Sistem yönetim işlevlerinin işlemesini yürüten kurallar dizisini içerir. Yönetim tenantı, switchlerin yönetim portundan erişim sağlayan Genel Sistem veri yolunun dışındaki APIC / Genel Sistem iç iletişim için özel sınırlı bir adres alanı içerir. Yönetim tenantı, sanal makine denetleyicileri ile iletişimin otomatik olarak keşfedilmesi ve otomasyonunu mümkün kılmaktadır.

• Erişim ilkeleri depolama, hesaplama, Layer 2 ve Layer 3 (köprülü ve yönlendirilmiş) bağlantılar, sanal makine hypervisor’ları, Layer 4 ile Layer 7 aygıtları vb. kaynaklara bağlantı sağlayan geçiş erişim bağlantı noktalarının çalışmasını yönetir. Bir tenantda, Cisco Discovery Protocol (CDP), Link Layer Discovery Protocol (LLDP), Link Aggregation Control Protocol (LACP) veya Spanning Tree gibi varsayılan bağlantıda sağlananlar dışında bir arayüz yapılandırması gerektiriyorsa, bir yönetici erişim politikalarını etkinleştirmek için Leaf Switchlerin erişim portlarındaki bu gibi konfigürasyonları yapılandırmalıdır.

• Fabrik politikaları, NTP sunucu senkronizasyonu, IS-IS, BGP rota reflektörleri, DNS ve benzeri gibi işlevleri içeren switch’lerin fabrik ile bağlantı noktalarının çalışmasını yönetir. MO malzemesinde güç kaynakları, fanlar, şasiler ve benzerleri gibi nesneler bulunur. MO fabriği güç kaynakları, fanlar, şasiler ve benzeri nesneleri içerir.

• Sanal Makine (VM) etki alanları, benzer ağ ilkesi gereksinimleri olan VM denetleyicileri grubunu gruplar. VM denetleyicileri  VLAN veya VXLAN alanı ve uygulama EPG (Endpoint Groups – Son Nokta grupları) paylaşabilir. APIC daha sonra sanal iş yüklerine uygulanan port grupları gibi ağ yapılandırmalarını yayınlamak için VM denetleyicisiyle iletişim kurar.

Hiyerarşik politika modeli, “REST API arayüzü” ile iyi uyum sağlar. Çağrıldığında “API”, MIT’deki nesnelerden okur veya MIT’teki nesneler üzerine yazar. URL’ler doğrudan MIT’deki nesneleri tanımlayan “ayırt edici isimler” e eşlenir. MIT’deki herhangi bir veri, XML veya JSON’da kodlanmış “bağımsız olarak yapılandırılmış ağaç metin belgesi” olarak tanımlanabilir.

Tenants (kiracılar)

Bir kiracı (fvTenant), bir yöneticinin alan adı tabanlı erişim denetimini uygulayabilmesini sağlayan uygulama ilkeleri için mantıklı bir konteynerdir. Kiracı bir politika perspektifinden ayrı bir birimi temsil eder, ancak özel bir şebekeyi temsil etmez. Kiracılar bir müşteriyi bir hizmet sağlayıcısı ortamında, bir kuruluş ortamında veya bir işletme ortamında veya bir uygun politika gruplandırmasında temsil edebilir. Aşağıdaki resim, yönetim bilgi ağacının (MIT) kiracı kısmına genel bir bakış sunmaktadır.

Şekil 6: Kiracılar

Kiracılar birbirlerinden izole edilebilir veya kaynakları paylaşabilirler. Kiracının içerdiği temel unsurlar; filtreler, sözleşmeler, dış ağlar, köprü alanları, Sanal Yönlendirme ve İletme (VRF) örnekleri ve uç nokta gruplarını (EPG’ler) içeren uygulama profilleridir. Kiracıdaki varlıklar politikalarını devralır. VRF’ler bağlamlar (contexts) olarak da bilinir; Her VRF, birden fazla köprü alanıyla ilişkilendirilebilir.

APIC GUI’de kiracı navigasyon yolunun altında, bir VRF (bağlam) özel ağ olarak adlandırılır.

Kiracılar, uygulama politikaları için mantıksal konteynerlerdir. Kumaş birden çok kiracı içerebilir. Herhangi bir Layer 4 ile Layer 7 hizmetleri dağıtmadan önce bir kiracıyı yapılandırmanız gerekir. ACI dokusu, kiracılar ağı için IPv4, IPv6 ve dual-stack yapılandırmaları destekler.

VRF’ler

Sanal Yönlendirme ve Yönlendirme VRF nesnesi veya contex’i, bir kiracı ağdır (APIC GUI’de özel ağ olarak adlandırılır). Bir kiracı birden fazla VRF’ye sahip olabilir. VRF, benzersiz bir Layer 3 yönlendirme ve uygulama politikası alanıdır. Aşağıdaki resim VRF’lerin yönetim bilgi ağacındaki (MIT) yerini ve kiracıdaki diğer nesnelerle olan ilişkilerini göstermektedir.

Şekil 7: VRF’ler

 

Bir VRF, Layer 3 adres alanı tanımlar. Bir veya daha fazla köprü alanı bir VRF ile ilişkilidir. Layer 3 alanındaki tüm bitiş noktalarının benzersiz IP adresleri olmalıdır, çünkü kurallar izin veriyorsa bu cihazlar arasında doğrudan paket iletmek mümkündür. Bir kiracı birden fazla VRF içerebilir. Bir yönetici mantıksal bir aygıt oluşturduktan sonra, yönetici, bir aygıt kümesi için bir seçim ölçüt ilkesi sağlayan mantıksal aygıt için bir VRF oluşturabilir. Mantıksal bir aygıt, grafik içinde sözleşme adı, grafik adı veya işlev düğümü adı temel alınarak seçilebilir.

 

DEVAM EDECEK…!