Cisco ACI: Fabric’ten Uygulama Politikasına

Makale

Cisco ACI: Fabric’ten Uygulama Politikasına

Spine–leaf fabric, APIC, EPG ve contract ilişkilerini birlikte okuyun; veri merkezi geçişini uygulama bağımlılıkları ve doğrulanabilir kabul kriterleriyle planlayın.

Cisco ACI
01

Fabric’in fiziksel omurgasını anlayın

Cisco ACI, veri merkezi ağını tek tek anahtar yapılandırmalarının ötesinde ortak bir politika modeliyle ele alır. Fiziksel omurga spine ve leaf düğümlerinden oluşur. Sunucular ve dış bağlantılar leaf katmanında sonlanırken spine’lar fabric içindeki leaf erişimini sağlar. APIC cluster’ı politikayı ve yönetimi üstlenir; uygulama paketlerinin geçmesi gereken inline bir güvenlik cihazı değildir. Bu görev ayrımı, tasarımın ilk kararını belirler: yönetim erişimi, fabric bağlantısı ve uygulama erişimi ayrı ayrı doğrulanmalıdır. Aşağıdaki Cisco referansı, fiziksel bileşenlerin yerleşimini ve çift bağlantıları incelemek için başlangıç noktasıdır.

02

Tenant, VRF ve bridge domain’i doğru ayırın

Tenant, politikaları ve ilgili nesneleri düzenleyen yönetim alanıdır. VRF yönlendirme bağlamını, bridge domain ise ilgili Katman 2 alanını ve ağ davranışını tanımlar. EPG bu alanın içinde ortak politika uygulanan uçları gruplar. Bu nesneleri yalnız eski VLAN numaralarının yeni karşılıkları olarak düşünmek, tasarımı uygulama ihtiyaçlarından uzaklaştırır. Önce hangi ekiplerin ayrı yönetim alanına, hangi iş yüklerinin ayrı yönlendirme bağlamına ihtiyaç duyduğunu belirleyin. Ardından adresleme, gateway yerleşimi ve dış ağ erişimini birlikte değerlendirin. Böylece operasyon ekibi bir erişim sorununun nesne ilişkisi mi, yönlendirme mi, politika mı olduğunu ayırt edebilir.

CISCO · Şekil 1

Cisco ACI: fiziksel fabric

Düğümleri seçerek görevlerini inceleyin; yakınlaştırma veya tam ekranla bağlantıları takip edin.

WAN or CampusSpine 1Fabric leaf düğümlerini birbirine bağlayan spine rolü. Kaynak iki spine gösterir.Spine 2Fabric leaf düğümlerini birbirine bağlayan spine rolü. Kaynak iki spine gösterir.Leaf 1İş yükü, APIC veya dış ağ bağlantısını sağlayan leaf. Kaynakta her leaf iki spine’a bağlanır.Leaf 2İş yükü, APIC veya dış ağ bağlantısını sağlayan leaf. Kaynakta her leaf iki spine’a bağlanır.Leaf 3İş yükü, APIC veya dış ağ bağlantısını sağlayan leaf. Kaynakta her leaf iki spine’a bağlanır.Leaf 4İş yükü, APIC veya dış ağ bağlantısını sağlayan leaf. Kaynakta her leaf iki spine’a bağlanır.Server 1Kaynakta ilk iki leaf’e çift bağlantılı fiziksel sunucu.Server 2Kaynakta ilk iki leaf’e çift bağlantılı fiziksel sunucu.Server 3Kaynakta ilk iki leaf’e çift bağlantılı fiziksel sunucu.Server 4Kaynakta ilk iki leaf’e çift bağlantılı fiziksel sunucu.APIC 1Fabric politika ve yönetim cluster’ının üyesi; kaynakta son iki leaf’e bağlıdır. Kullanıcı trafiğinin inline geçiş noktası değildir.APIC 2Fabric politika ve yönetim cluster’ının üyesi; kaynakta son iki leaf’e bağlıdır. Kullanıcı trafiğinin inline geçiş noktası değildir.APIC 3Fabric politika ve yönetim cluster’ının üyesi; kaynakta son iki leaf’e bağlıdır. Kullanıcı trafiğinin inline geçiş noktası değildir.External router 1Kaynakta border leaf çiftinden WAN/kampüse bağlanan dış yönlendirici.External router 2Kaynakta border leaf çiftinden WAN/kampüse bağlanan dış yönlendirici.VMKaynak sunucu altında gösterilen sanal iş yükü. Bu ikon ayrıca fiziksel bir bağlantı çizmez.VMKaynak sunucu altında gösterilen sanal iş yükü. Bu ikon ayrıca fiziksel bir bağlantı çizmez.VMKaynak sunucu altında gösterilen sanal iş yükü. Bu ikon ayrıca fiziksel bir bağlantı çizmez.VMKaynak sunucu altında gösterilen sanal iş yükü. Bu ikon ayrıca fiziksel bir bağlantı çizmez.VMKaynak sunucu altında gösterilen sanal iş yükü. Bu ikon ayrıca fiziksel bir bağlantı çizmez.VMKaynak sunucu altında gösterilen sanal iş yükü. Bu ikon ayrıca fiziksel bir bağlantı çizmez.VMKaynak sunucu altında gösterilen sanal iş yükü. Bu ikon ayrıca fiziksel bir bağlantı çizmez.VMKaynak sunucu altında gösterilen sanal iş yükü. Bu ikon ayrıca fiziksel bir bağlantı çizmez.Physical fabric · APIC cluster · Virtual workloads
  • Fiziksel bağlantı / Physical connection
Şemayı keşfedin

Düğüme tıklayarak rolünü inceleyin. Şemayı sürükleyebilir veya düğmelerle yakınlaştırabilirsiniz.

Cisco’nun fiziksel fabric çizimi: iki spine, dört leaf, çift bağlantılı sunucular ve üç APIC. WAN/kampüs bağlantısı border leaf çiftindedir. EPG ve contract’lar bu fiziksel çizime ek kablo olarak eklenmez.

03

EPG ve contract ile erişimi tarif edin

Bir EPG, uygulamanın web, servis veya veri katmanındaki uçları ortak bir politika grubunda toplamak için kullanılabilir. Contract ise provider ve consumer arasındaki iletişim koşullarını tarif eder; filtreler izin verilen trafiğin kapsamını sınırlar. Ancak EPG adının “veritabanı” olması, erişimin kendiliğinden doğru sınırlandığını göstermez. Uygulama sahibiyle gerçek kaynak, hedef, protokol ve port gereksinimlerini çıkarın. Yönetim araçları, yedekleme ve sağlık kontrolleri gibi yardımcı akışları da değerlendirin. Olumlu testlerde gerekli iletişim çalışmalı; olumsuz testlerde gereksiz iletişim engellenmelidir. Böylece politika, yalnız yapılandırılmış değil, uygulamanın gereksinimleriyle doğrulanmış olur.

04

L3Out ve dış bağımlılıkları birlikte planlayın

Fabric dışındaki ağlara Katman 3 erişim, ACI’de L3Out yapısıyla ele alınır. Bu bağlantı yalnız bir uplink açmak değildir: dış yönlendirme, route öğrenimi ve ilgili dış EPG politikaları birlikte değerlendirilir. DNS, kimlik servisleri, internet çıkışı ve diğer veri merkezleri gibi bağımlılıkları bir akış envanterinde toplayın. Mevcut ortamla geçiş döneminde eş zamanlı çalışılacaksa geri dönüş yolu ve asimetrik trafik olasılığı ayrıca incelenmelidir. Topolojideki dış router ikonları bir internet servisi garantisi vermez; gerçek erişim, kurumun taşıyıcı bağlantıları ve uyguladığı politika ile belirlenir. Tasarım kararı bu ayrımı açıkça belgelemelidir.

05

Fiziksel ve sanal iş yüklerini aynı envanterde görün

ACI hem fiziksel hem sanal iş yüklerinin bağlantı ve politika ihtiyaçlarına göre tasarlanabilir. Sanallaştırma entegrasyonu için kullanılan VMM seçeneği ve yazılım sürümleri ayrıca uyumluluk kontrolü gerektirir. Kaynak çizimde sunucu altında yer alan VM ikonları, APIC’e doğrudan bağlanan yeni cihazlar olarak okunmamalıdır. Tasarımda her iş yükünün host bağlantısı, port veya domain eşlemesi, gateway’i ve politika grubu bilinmelidir. Bir sanal makinenin yeni host’a taşınması, onu kullanan uygulamanın erişim davranışını da etkileyebilir. Bu nedenle pilot kapsamına yalnız fiziksel port testleri değil, kurumun kullandığı hareketlilik ve yeniden başlatma senaryoları da alınmalıdır.

06

Geçişi uygulama grupları üzerinden yönetin

Geçiş planına bütün ağı tek seferde taşımakla başlamak yerine, bağımlılıkları bilinen bir uygulama grubunu aday olarak seçin. Önce mevcut akışları ve kritik çalışma saatlerini kaydedin; sonra hedef politika, bağlantı sırası, sorumlu ekip ve geri dönüş adımlarını tanımlayın. Başarı ölçütü yalnız endpoint’in öğrenilmesi olmamalıdır. Kullanıcı işlemi, servisler arası çağrı, kayıt ve raporlama gibi gerçek iş akışları denenmelidir. Eski ve yeni ortamın birlikte çalıştığı süre için geçici kuralların sahibi ve kaldırılma koşulu belirlenmelidir. Bu yaklaşım, geçişin teknik adımlarını kurumun uygulama sorumluluğuyla aynı plana taşır.

07

Kabul ve operasyon devrini ölçülebilir hale getirin

Kabul kaydı; hedef uygulama akışlarını, engellenmesi gereken erişimleri, yönetim erişimini ve yedekli bağlantı davranışını kapsamalıdır. Her bulguya kullanılan test, beklenen sonuç ve elde edilen kanıt ekleyin. Operasyon devrinde tenant ve EPG isimlendirmesi, contract sahipliği, konfigürasyon yedekleri ve değişiklik yöntemi aktarılmalıdır. Yeni bir uygulama eklendiğinde hangi nesnenin değişeceği ve bunu kimin onaylayacağı bilinmelidir. Trustnet’in katalogdaki analiz, tasarım, planlama, uygulama ve destek yaklaşımı bu çalışmaya bir çerçeve sunar; proje kapsamı ve kabul eşikleri kurumun gerçek gereksinimleriyle netleştirilir. Referans mimari başlangıçtır; üretim tasarımı bu kararların belgelenmiş bütünüdür.

Teknik kaynaklar

İLGİLİ İÇERİKLER

Tümünü Gör