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.
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 ACI: fiziksel fabric
Düğümleri seçerek görevlerini inceleyin; yakınlaştırma veya tam ekranla bağlantıları takip edin.
- Fiziksel bağlantı / Physical connection
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.
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.
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.
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.
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.
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.



