SDSM bitti ama kontrol edilemeyen yazma arzusu devam ediyor.

Kardeşimiz uzun yıllar boyunca rutin işler yapmaktan, işe başlamadan önce parmaklarını çaprazlamaktan ve gece geri dönüşlerden dolayı uykusuz kalmaktan acı çekti.
Ancak karanlık zamanlar sona eriyor.

Bu makaleyle nasıl yapılacağına dair bir diziye başlayacağım. bana otomasyon görülmektedir.
Yol boyunca otomasyon, değişkenlerin saklanması, tasarımın formalleştirilmesi, RestAPI, NETCONF, YANG, YDK aşamalarını anlayacağız ve birçok programlama yapacağız.
Beni şu anlama gelir: a) nesnel bir gerçek değildir, b) kayıtsız şartsız en iyi yaklaşım değildir, c) fikrim, ilk makaleden son makaleye geçiş sırasında bile - dürüst olmak gerekirse, taslak aşamasından diğerine - değişebilir. yayın, her şeyi tamamen iki kez yeniden yazdım.

Içerik

1. Amacı
   1. Ağ tek bir organizma gibidir
   2. Yapılandırma testi
   3. Sürüm oluşturma
   4. Hizmetlerin izlenmesi ve kendi kendini iyileştirmesi

2. Para
   1. Envanter sistemi
   2. IP alanı yönetim sistemi
   3. Ağ hizmeti açıklama sistemi
   4. Cihaz başlatma mekanizması
   5. Satıcıdan bağımsız yapılandırma modeli
   6. Satıcıya özel sürücü arayüzü
   7. Yapılandırmayı cihaza iletme mekanizması
   8. CI / CD
   9. Yedekleme ve sapmaları arama mekanizması
   10. İzleme sistemi

3. Sonuç

ADSM'yi SDSM'den biraz farklı bir formatta yürütmeye çalışacağım. Büyük, ayrıntılı, numaralı makaleler yayınlanmaya devam edecek ve bunların arasında günlük deneyimlerden küçük notlar yayınlayacağım. Burada mükemmeliyetçilikle mücadele etmeye çalışacağım ve her birini yalamayacağım.

Aynı yoldan ikinci kez geçmek zorunda kalman ne kadar komik.

İlk başta RuNet'te olmadıkları için ağlar hakkında kendim makaleler yazmak zorunda kaldım.

Artık otomasyona yönelik yaklaşımları sistematik hale getirecek ve yukarıdaki teknolojileri basit pratik örneklerle analiz edecek kapsamlı bir belge bulamadım.

Yanılıyor olabilirim, bu yüzden lütfen yararlı kaynaklara bağlantılar sağlayın. Ancak bu yazma kararlılığımı değiştirmeyecek, çünkü asıl amaç kendim bir şeyler öğrenmek ve başkalarının hayatını kolaylaştırmak, deneyim paylaşma genini okşayan hoş bir bonus.

Orta büyüklükte bir LAN DC veri merkezini alıp tüm otomasyon şemasını çözmeye çalışacağız.
Bazı şeyleri neredeyse ilk defa seninle yapacağım.

Burada açıklanan fikir ve araçlarda orijinal olmayacağım. Dmitry Figol'un mükemmel bir yeteneği var bu konuyla ilgili yayınların olduğu kanal.
Yazılar pek çok açıdan onlarla örtüşecek.

LAN DC'de 4 DC, yaklaşık 250 anahtar, yarım düzine yönlendirici ve birkaç güvenlik duvarı bulunur.
Facebook değil ama otomasyon hakkında derinlemesine düşünmenizi sağlayacak kadar.
Ancak 1'den fazla cihazınız varsa otomasyonun zaten gerekli olduğu yönünde bir görüş var.
Aslında artık herhangi birinin en azından bir dizi diz senaryosu olmadan yaşayabileceğini hayal etmek zor.
Gerçi IP adreslerinin Excel'de tutulduğu ofislerin olduğunu ve binlerce ağ cihazının her birinin manuel olarak yapılandırıldığını ve kendine özgü konfigürasyona sahip olduğunu duydum. Bu elbette modern sanat olarak geçiştirilebilir, ancak mühendisin duyguları kesinlikle kırılacaktır.

Amacı

Şimdi en soyut hedefleri belirleyeceğiz:

• Ağ tek bir organizma gibidir
• Yapılandırma testi
• Ağ durumu versiyonlaması
• Hizmetlerin izlenmesi ve kendi kendini iyileştirmesi

Bu yazının ilerleyen kısımlarında hangi araçları kullanacağımıza bakacağız ve aşağıda da hedeflere ve araçlara detaylı olarak bakacağız.

Ağ tek bir organizma gibidir

İlk bakışta çok önemli görünmese de serinin tanımlayıcı cümlesi: bireysel cihazları değil ağı yapılandıracağız.
Son yıllarda, ağın tek bir varlık olarak ele alınmasına yönelik vurgunun değiştiğini gördük. Yazılım Tanımlı Ağ, Amaca Dayalı Ağlar и Otonom Ağlar.
Sonuçta, uygulamaların küresel olarak ağdan neye ihtiyacı var: A ve B noktaları arasındaki bağlantı (bazen +B-Z) ve diğer uygulamalardan ve kullanıcılardan izolasyon.

Ve bu serideki görevimiz bir sistem kurmak, mevcut konfigürasyonun korunması tüm ağ, rolüne ve konumuna göre her cihazdaki gerçek konfigürasyona zaten ayrıştırılmıştır.
Sistem ağ yönetimi, değişiklik yapmak için onunla iletişime geçmemiz anlamına gelir ve o da her cihaz için istenen durumu hesaplar ve yapılandırır.
Bu şekilde, CLI'ye manuel erişimi neredeyse sıfıra indiriyoruz - cihaz ayarlarında veya ağ tasarımında yapılan herhangi bir değişiklik resmileştirilmeli ve belgelenmelidir - ve ancak bundan sonra gerekli ağ öğelerine aktarılmalıdır.

Yani, örneğin, şu andan itibaren Kazan'daki raf anahtarlarının bir yerine iki ağı duyurması gerektiğine karar verirsek,

1. Öncelikle sistemlerdeki değişiklikleri belgeliyoruz
2. Tüm ağ cihazlarının hedef konfigürasyonunun oluşturulması
3. Her bir düğümde nelerin kaldırılması gerektiğini, nelerin eklenmesi gerektiğini hesaplayan ve düğümleri istenilen duruma getiren ağ yapılandırma güncelleme programını başlatıyoruz.

Aynı zamanda değişiklikleri yalnızca ilk adımda manuel olarak yapıyoruz.

Yapılandırma testi

Bu bilinensorunların %80'inin konfigürasyon değişiklikleri sırasında ortaya çıktığı - bunun dolaylı kanıtı, Yeni Yıl tatillerinde her şeyin genellikle sakin olmasıdır.
İnsan hatası nedeniyle düzinelerce küresel kesintiye şahsen tanık oldum: yanlış komut, yanlış dalda yapılandırma yürütüldü, topluluk unutuldu, MPLS yönlendiricide küresel olarak yıkıldı, beş donanım parçası yapılandırıldı, ancak hata düzeltilmedi altıncısında fark edildi, başka bir kişi tarafından yapılan eski değişiklikler yapıldı. Bir ton senaryo var.

Otomasyon daha az hata yapmamıza olanak tanıyacak, ancak daha büyük ölçekte. Bu şekilde yalnızca bir cihazı değil tüm ağı aynı anda tuğlalayabilirsiniz.

Çok eski zamanlardan beri dedelerimiz, yapılan değişikliklerin doğruluğunu, çelik bilyeleri ve ağın işlevselliğini, kullanıma sunulduktan sonra kontrol ettiler.
Çalışmaları kesintilere ve yıkıcı kayıplara yol açan büyükbabalar daha az yavru bıraktılar ve zamanla yok olmaları gerekiyor, ancak evrim yavaş bir süreç ve bu nedenle herkes hâlâ değişiklikleri önce laboratuvarda test etmiyor.
Bununla birlikte, ilerlemenin ön saflarında, yapılandırmayı test etme sürecini ve bunun ağa daha fazla uygulanmasını otomatikleştirenler yer almaktadır. Başka bir deyişle CI/CD prosedürünü ödünç aldım (Sürekli Entegrasyon, Sürekli Dağıtım) geliştiricilerden.
Bölümlerden birinde bunun bir sürüm kontrol sistemi (muhtemelen Github) kullanılarak nasıl uygulanacağına bakacağız.

Ağ CI/CD fikrine alıştığınızda, bir yapılandırmayı bir üretim ağına uygulayarak bir gecede kontrol etme yöntemi, erken ortaçağ cehaleti gibi görünecektir. Bir savaş başlığına çekiçle vurmak gibi bir şey bu.

Hakkında fikirlerin organik bir devamı sistem ağ yönetimi ve CI/CD, yapılandırmanın tam sürümü haline gelir.

Sürüm oluşturma

Ne kadar küçük olursa olsun, fark edilmeyen bir cihazda bile herhangi bir değişiklikle tüm ağın bir durumdan diğerine geçtiğini varsayacağız.
Ve her zaman cihazda bir komut çalıştırmıyoruz, ağın durumunu değiştiriyoruz.
Peki bu durumlara versiyonlar mı diyelim?

Diyelim ki mevcut sürüm 1.0.0.
Şartnamelerden birindeki Loopback arayüzünün IP adresi değişti mi? Bu küçük bir versiyondur ve 1.0.1 olarak numaralandırılacaktır.
Rotaları BGP'ye aktarma politikalarını - biraz daha ciddi olarak - zaten 1.1.0'da revize ettik.
IGP'den kurtulup yalnızca BGP'ye geçmeye karar verdik - bu zaten radikal bir tasarım değişikliği - 2.0.0.

Aynı zamanda, farklı DC'lerin farklı versiyonları olabilir - ağ gelişiyor, yeni ekipman kuruluyor, bir yere yeni omurga seviyeleri ekleniyor, başkalarına değil vb.

Hakkında anlamsal versiyonlama ayrı bir yazıda konuşacağız.

Tekrar ediyorum - herhangi bir değişiklik (hata ayıklama komutları hariç) bir sürüm güncellemesidir. Yöneticiler mevcut sürümden herhangi bir sapma konusunda bilgilendirilmelidir.

Aynısı, değişiklikleri geri almak için de geçerlidir - bu, son komutların iptal edilmesi değildir, bu, cihazın işletim sistemini kullanan bir geri alma değildir - bu, tüm ağın yeni (eski) bir sürüme getirilmesidir.

Hizmetlerin izlenmesi ve kendi kendini iyileştirmesi

Bu apaçık görev, modern ağlarda yeni bir düzeye ulaştı.
Çoğu zaman büyük hizmet sağlayıcılar, ne olduğunu çözmek yerine, başarısız bir hizmetin çok hızlı bir şekilde düzeltilmesi ve yeni bir hizmetin başlatılması gerektiği yaklaşımını benimser.
"Çok", normdan en ufak sapmaları saniyeler içinde tespit edecek olan izleme sistemiyle her tarafınızın cömertçe kaplanması gerektiği anlamına gelir.
Ve burada arayüz yüklemesi veya düğüm kullanılabilirliği gibi olağan ölçümler artık yeterli değil. Bunların görevli memur tarafından manuel olarak izlenmesi de yeterli değildir.
Birçok şey için olması gereken Kendi Kendini İyileştirme - izleme ışıkları kırmızıya döndü ve biz gidip ağrıyan yere kendimiz muz sürdük.

Ve burada sadece bireysel cihazları değil, aynı zamanda tüm ağın sağlığını da izliyoruz; hem nispeten anlaşılır olan beyaz kutuyu hem de daha karmaşık olan kara kutuyu.

Bu kadar iddialı planları uygulamak için neye ihtiyacımız olacak?

• Ağdaki tüm cihazların, konumlarının, rollerinin, modellerinin, yazılım sürümlerinin bir listesine sahip olun.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• Ağ hizmetlerini tanımlamak için bir sisteme sahip olun.
  IGP, BGP, L2/3VPN, Politika, ACL, NTP, SSH.
• Cihazı başlatabilme.
  Ana Bilgisayar Adı, Yönetim IP'si, Yönetim Rotası, Kullanıcılar, RSA Anahtarları, LLDP, NETCONF
• Cihazı yapılandırın ve konfigürasyonu istediğiniz (eski dahil) sürüme getirin.
• Test yapılandırması
• Tüm cihazların durumunu mevcut olanlardan sapmalar açısından periyodik olarak kontrol edin ve kime olması gerektiğini bildirin.
  Bir gecede birisi sessizce ACL'ye bir kural ekledi.
• Ekran performansı.

Para

Projeyi bileşenlere ayırmaya başlayacak kadar karmaşık geliyor.

Ve onlardan on tane olacak:

1. Envanter sistemi
2. IP alanı yönetim sistemi
3. Ağ hizmeti açıklama sistemi
4. Cihaz başlatma mekanizması
5. Satıcıdan bağımsız yapılandırma modeli
6. Satıcıya özel sürücü arayüzü
7. Yapılandırmayı cihaza iletme mekanizması
8. CI / CD
9. Yedekleme ve sapmaları arama mekanizması
10. İzleme sistemi

Bu arada bu, döngünün hedeflerine ilişkin görüşün nasıl değiştiğine bir örnektir - taslakta 4 bileşen vardı.

Çizimde tüm bileşenleri ve cihazın kendisini gösterdim.
Kesişen bileşenler birbirleriyle etkileşime girer.
Blok büyüdükçe bu bileşene daha fazla dikkat edilmesi gerekir.

Bileşen 1: Envanter Sistemi

Açıkçası hangi ekipmanın nerede bulunduğunu, neye bağlı olduğunu bilmek istiyoruz.
Envanter sistemi herhangi bir işletmenin ayrılmaz bir parçasıdır.
Çoğu zaman, bir işletmenin ağ cihazları için daha spesifik sorunları çözen ayrı bir envanter sistemi vardır.
Bu yazı dizisi kapsamında buna DCIM - Veri Merkezi Altyapı Yönetimi adını vereceğiz. Her ne kadar DCIM teriminin kendisi aslında çok daha fazlasını içeriyor olsa da.

Amaçlarımız doğrultusunda, cihazla ilgili aşağıdaki bilgileri bu cihazda saklayacağız:

• Envanter numarası
• Başlık Açıklaması
• modeli (Huawei CE12800, Ardıç QFX5120, vb.)
• Karakteristik parametreler (panolar, arayüzler vb.)
• Rol (Yaprak, Omurga, Kenar Yönlendirici vb.)
• Konum (bölge, şehir, veri merkezi, raf, birim)
• Cihazlar arasındaki ara bağlantılar
• Ağ topolojisi

Bütün bunları bizim de bilmek istediğimiz çok açık.
Ancak bu otomasyon amaçlarına yardımcı olacak mı?
Kesinlikle.
Örneğin, Leaf anahtarlarındaki belirli bir veri merkezinde, Huawei ise, belirli trafiği filtrelemek için ACL'lerin VLAN'a ve Juniper ise fiziksel arayüzün 0 birimine uygulanması gerektiğini biliyoruz.
Veya bölgedeki tüm sınırlara yeni bir Syslog sunucusu dağıtmanız gerekir.

İçinde sanal yönlendiriciler veya kök reflektörler gibi sanal ağ cihazlarını saklayacağız. DNS sunucularını, NTP'yi, Syslog'u ve genel olarak şu veya bu şekilde ağla ilgili olan her şeyi ekleyebiliriz.

Bileşen 2: IP alanı yönetim sistemi

Evet ve günümüzde bir Excel dosyasındaki önekleri ve IP adreslerini takip eden ekipler var. Ancak modern yaklaşım hala nginx/apache üzerinde bir ön uç, API ve VRF'lere bölünmüş IP adreslerini ve ağları kaydetmek için kapsamlı işlevlere sahip bir veritabanıdır.
IPAM - IP Adresi Yönetimi.

Amaçlarımız doğrultusunda aşağıdaki bilgileri burada saklayacağız:

• VLAN
• VRF uzantısı
• Ağlar/Alt Ağlar
• IP adresleri
• Adresleri cihazlara, ağları konumlara ve VLAN numaralarına bağlama

Yine, ToR geridöngüsü için yeni bir IP adresi tahsis ettiğimizde, bu adresin zaten birine atanmış olduğu gerçeğiyle karşılaşmayacağımızdan emin olmak istediğimiz açıktır. Veya aynı öneki ağın farklı uçlarında iki kez kullandığımızı.
Peki bu otomasyona nasıl yardımcı oluyor?
Kolayca.
Sistemde tahsise uygun IP adreslerini içeren Loopbacks rolüne sahip bir önek talep ediyoruz - bulunursa adresi tahsis ediyoruz, yoksa yeni bir önek oluşturulmasını talep ediyoruz.
Veya cihaz konfigürasyonu oluştururken arayüzün hangi VRF'de bulunması gerektiğini aynı sistemden öğrenebiliriz.
Ve yeni bir sunucu başlatıldığında, komut dosyası sistemde oturum açar, sunucunun hangi anahtarda olduğunu, arayüze hangi bağlantı noktasının ve hangi alt ağın atandığını bulur ve sunucu adresini buradan tahsis eder.

Bu, işlevleri çoğaltmamak ve iki benzer varlığa hizmet etmemek için DCIM ve IPAM'yi tek bir sistemde birleştirme arzusunu ortaya koymaktadır.
Biz de bunu yapacağız.

Bileşen 3. Ağ hizmetlerini açıklayan sistem

İlk iki sistem hala bir şekilde kullanılması gereken değişkenleri saklıyorsa, üçüncüsü her cihaz rolü için nasıl yapılandırılması gerektiğini açıklar.
İki farklı ağ hizmeti türünü ayırt etmeye değer:

• Altyapı
• Müşteri.

İlki, temel bağlantı ve cihaz kontrolünü sağlamak için tasarlanmıştır. Bunlar arasında VTY, SNMP, NTP, Syslog, AAA, yönlendirme protokolleri, CoPP vb. bulunur.
İkincisi istemci için hizmeti düzenler: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, vb.
Elbette sınırda durumlar da var; MPLS LDP, BGP nereye dahil edilmeli? Evet ve istemciler için yönlendirme protokolleri kullanılabilir. Ancak bu önemli değil.

Her iki hizmet türü de yapılandırma temellerine ayrıştırılmıştır:

• fiziksel ve mantıksal arayüzler (etiket/anteg, mtu)
• IP adresleri ve VRF'ler (IP, IPv6, VRF)
• ACL'ler ve trafik işleme politikaları
• Protokoller (IGP, BGP, MPLS)
• Yönlendirme politikaları (önek listeleri, topluluklar, ASN filtreleri).
• Yardımcı hizmetler (SSH, NTP, LLDP, Syslog...)
• Vb.

Bunu tam olarak nasıl yapacağız, henüz hiçbir fikrim yok. Bunu ayrı bir makalede inceleyeceğiz.

Hayata biraz daha yakın olsa bunu anlatabiliriz
Yaprak anahtarının tüm bağlı Spine anahtarlarıyla BGP oturumları olması, bağlı ağları sürece aktarması ve Spine anahtarlarından yalnızca belirli bir önekten gelen ağları kabul etmesi gerekir. CoPP IPv6 ND'yi 10 pps vb. ile sınırlayın.
Buna karşılık, dikenler, kök yansıtıcı görevi gören tüm bağlı uçlarla oturumlar düzenler ve onlardan yalnızca belirli bir uzunlukta ve belirli bir topluluğa sahip rotaları kabul eder.

Bileşen 4: Cihaz Başlatma Mekanizması

Bir cihazın radarda görünmesi ve uzaktan erişilebilmesi için yapılması gereken birçok eylemi bu başlık altında topluyorum.

1. Cihazı envanter sistemine girin.
2. Bir yönetim IP adresi seçin.
3. Temel erişimi ayarlayın:
   Ana bilgisayar adı, yönetim IP adresi, yönetim ağına rota, kullanıcılar, SSH anahtarları, protokoller - telnet/SSH/NETCONF

Üç yaklaşım vardır:

• Her şey tamamen manueldir. Cihaz, sıradan bir organik kişinin onu sistemlere gireceği, konsola bağlanacağı ve yapılandıracağı standa getiriliyor. Küçük statik ağlarda çalışabilir.
• ZTP - Sıfır Dokunuş Sağlama. Donanım geldi, ayağa kalktı, DHCP üzerinden adres aldı, özel bir sunucuya gitti ve kendini yapılandırdı.
• İlk yapılandırmanın konsol bağlantı noktası üzerinden otomatik modda gerçekleştiği konsol sunucularının altyapısı.

Üçünden de ayrı bir yazıda bahsedeceğiz.

Bileşen 5: Satıcıdan bağımsız yapılandırma modeli

Şimdiye kadar tüm sistemler, ağda görmek istediklerimizin değişkenlerini ve bildirimsel açıklamalarını sağlayan farklı yamalardan oluşuyordu. Ancak er ya da geç ayrıntılarla uğraşmak zorunda kalacaksınız.
Bu aşamada, her bir spesifik cihaz için temel öğeler, hizmetler ve değişkenler, yalnızca satıcıdan bağımsız bir şekilde, spesifik bir cihazın tam konfigürasyonunu gerçekten açıklayan bir konfigürasyon modelinde birleştirilir.
Bu adım ne işe yarar? Neden hemen kolayca yükleyebileceğiniz bir cihaz konfigürasyonu oluşturmuyorsunuz?
Aslında bu üç sorunu çözer:

1. Cihazla etkileşim için belirli bir arayüze uyum sağlamayın. CLI, NETCONF, RESTCONF, SNMP olsun, model aynı olacaktır.
2. Şablon/script sayısını ağdaki satıcı sayısına göre tutmayın, tasarım değişirse aynı şeyi birkaç yerde değiştirin.
3. Yapılandırmayı cihazdan yükleyin (yedekleyin), tam olarak aynı modele yerleştirin ve deltayı hesaplamak için hedef yapılandırmayı doğrudan mevcut olanla karşılaştırın ve yalnızca gerekli olan parçaları değiştirecek veya sapmaları tanımlayacak bir yapılandırma yaması hazırlayın.

Bu aşamanın sonucunda satıcıdan bağımsız bir konfigürasyon elde ediyoruz.

Bileşen 6. Satıcıya özel sürücü arayüzü

Bir gün bir ciska'yı Juniper ile tamamen aynı şekilde yapılandırmanın mümkün olacağı umuduyla kendinizi övmemelisiniz, sadece onlara tamamen aynı çağrıları göndererek. Beyaz kutuların artan popülaritesine ve NETCONF, RESTCONF, OpenConfig desteğinin ortaya çıkmasına rağmen, bu protokollerin sunduğu spesifik içerik satıcıdan satıcıya farklılık gösterir ve bu, onların bu kadar kolay vazgeçmeyecekleri rekabet farklılıklarından biridir.
Bu, NorthBound arayüzü olarak RestAPI'ye sahip olan OpenContrail ve OpenStack'in tamamen farklı çağrılar beklemesiyle kabaca aynıdır.

Yani beşinci adımda satıcıdan bağımsız modelin donanıma geçeceği formu alması gerekiyor.
Ve burada tüm araçlar iyidir (değil): CLI, NETCONF, RESTCONF, SNMP.

Bu nedenle, önceki adımın sonucunu belirli bir satıcının gerekli formatına aktaracak bir sürücüye ihtiyacımız olacak: bir dizi CLI komutu, bir XML yapısı.

Bileşen 7. Yapılandırmayı cihaza iletme mekanizması

Konfigürasyonu oluşturduk, ancak yine de cihazlara teslim edilmesi gerekiyor ve elbette elle değil.
Ilk olarakHangi ulaşım aracını kullanacağız sorusuyla karşı karşıyayız? Ve bugün seçim artık küçük değil:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (bu bir aykırı değer olmasına rağmen, ayarları değil, FIB'yi sunmanın bir yolu olduğundan)

T'yi buraya noktalayalım. CLI eskidir. SNMP... öksürük öksürük.
RESTCONF hala bilinmeyen bir hayvan; REST API neredeyse hiç kimse tarafından desteklenmiyor. Bu nedenle seride NETCONF'a odaklanacağız.

Aslında, okuyucunun zaten anlayacağı gibi, bu noktada arayüze zaten karar verdik - önceki adımın sonucu zaten seçilen arayüzün formatında sunuluyor.

Ikinci olarakve bunu hangi araçlarla yapacağız?
Burada da geniş bir seçenek var:

• Kendi kendine yazılan komut dosyası veya platform. Kendimizi ncclient ve asyncIO ile donatalım ve her şeyi kendimiz yapalım. Sıfırdan bir dağıtım sistemi oluşturmanın bize maliyeti nedir?
• Zengin ağ modülleri kütüphanesine sahip Ansible.
• Ağ ile yetersiz çalışması ve Napalm ile bağlantısı ile tuz.
• Aslında birkaç satıcıyı tanıyan Napalm, hepsi bu, elveda.
• Nornir de gelecekte inceleyeceğimiz bir diğer hayvan.

Burada favori henüz seçilmedi - arayacağız.

Burada başka ne önemli? Yapılandırmayı uygulamanın sonuçları.
Başarılı ya da değil. Donanıma hâlâ erişim var mı, yok mu?
Görünüşe göre taahhüt, cihaza indirilenlerin onaylanması ve doğrulanması konusunda burada yardımcı olacaktır.
Bu, NETCONF'un doğru uygulanmasıyla birleştiğinde uygun cihaz yelpazesini önemli ölçüde daraltır; pek çok üretici normal taahhütleri desteklemez. Ancak bu, önkoşullardan sadece bir tanesidir. RFP. Sonuçta hiç kimse tek bir Rus satıcının bile 32*100GE arayüz koşuluna uymamasından endişe duymuyor. Yoksa endişeli mi?

Bileşen 8. CI/CD

Bu noktada zaten tüm ağ cihazları için konfigürasyonumuz hazır.
Ağ durumunun versiyonlandırılmasından bahsettiğimiz için “her şey için” yazıyorum. Üstelik yalnızca bir anahtarın ayarlarını değiştirmeniz gerekse bile değişiklikler tüm ağ için hesaplanır. Açıkçası çoğu düğüm için sıfır olabilirler.

Ancak yukarıda da söylediğimiz gibi, her şeyi doğrudan üretime geçirmek isteyen barbarlar değiliz.
Oluşturulan konfigürasyonun öncelikle Pipeline CI/CD'den geçmesi gerekir.

CI/CD, Sürekli Entegrasyon, Sürekli Dağıtım anlamına gelir. Bu, ekibin yalnızca her altı ayda bir yeni bir büyük sürüm yayınlaması, eskisinin tamamen yerini alması değil, aynı zamanda her biri uyumluluk, güvenlik ve güvenlik açısından kapsamlı bir şekilde test edilen yeni işlevleri küçük porsiyonlarda düzenli olarak artımlı olarak (Dağıtım) uyguladığı bir yaklaşımdır. performans (Entegrasyon).

Bunu yapmak için, konfigürasyon değişikliklerini izleyen bir sürüm kontrol sistemimiz, istemci hizmetinin bozuk olup olmadığını kontrol eden bir laboratuvarımız, bu durumu kontrol eden bir izleme sistemimiz var ve son adım, değişiklikleri üretim ağına yaymak.

Hata ayıklama komutları dışında, ağdaki tüm değişikliklerin kesinlikle CI/CD Pipeline'dan geçmesi gerekir; bu bizim sessiz bir yaşamın ve uzun, mutlu bir kariyerin garantisidir.

Bileşen 9. Yedekleme ve anormallik tespit sistemi

Yedeklemelerden tekrar bahsetmeye gerek yok.
Bunları, taca göre veya konfigürasyon değişikliği gerçeğine göre git'e koyacağız.

Ancak ikinci kısım daha ilginç; birisinin bu yedeklere göz kulak olması gerekiyor. Ve bazı durumlarda, bu kişinin gidip her şeyi olduğu gibi değiştirmesi gerekir, diğerlerinde ise birine bir şeylerin ters gittiğini miyavlaması gerekir.
Örneğin, değişkenlere kayıtlı olmayan yeni bir kullanıcı ortaya çıkarsa, onu hack'ten çıkarmanız gerekir. Ve yeni bir güvenlik duvarı kuralına dokunmamak daha iyiyse, belki birisi hata ayıklamayı yeni açmıştır veya belki yeni hizmet, bir beceriksiz, düzenlemelere göre kaydedilmemiştir, ancak insanlar ona zaten katılmıştır.

Otomasyon sistemlerine ve yönetimin çelik gibi ellerine rağmen, tüm ağ ölçeğinde küçük bir deltadan hâlâ kaçamayacağız. Sorunları ayıklamak için zaten hiç kimse sistemlere yapılandırma eklemeyecektir. Üstelik konfigürasyon modeline bile dahil edilmeyebilirler.

Örneğin, bir sorunu yerelleştirmek için belirli bir IP başına paket sayısını saymaya yönelik bir güvenlik duvarı kuralı, tamamen sıradan bir geçici yapılandırmadır.

Bileşen 10. İzleme sistemi

İlk başta izleme konusunu ele almayacaktım; bu hâlâ çok geniş, tartışmalı ve karmaşık bir konu. Ancak işler ilerledikçe bunun otomasyonun ayrılmaz bir parçası olduğu ortaya çıktı. Ve pratik yapmadan bile onu atlamak imkansızdır.

Gelişen Düşünce CI/CD sürecinin organik bir parçasıdır. Yapılandırmayı ağa dağıttıktan sonra, şimdi her şeyin yolunda olup olmadığını belirleyebilmemiz gerekiyor.
Ve sadece arayüz kullanım programları veya düğüm kullanılabilirliği hakkında değil, aynı zamanda daha incelikli şeyler hakkında da konuşuyoruz - gerekli rotaların varlığı, bunlardaki nitelikler, BGP oturumlarının sayısı, OSPF komşuları, Uçtan Uca performans. üst düzey hizmetlerden.
Harici sunucuya giden sistem günlüklerinin toplanması durdu mu, SFlow aracısı bozuldu mu, kuyruklardaki düşüşler büyümeye mi başladı ya da bazı önek çiftleri arasındaki bağlantı mı bozuldu?

Bu konuyu ayrı bir makalede ele alacağız.

Sonuç

Temel olarak modern veri merkezi ağ tasarımlarından birini, yönlendirme protokolü olarak BGP'li L3 Clos Fabric'i seçtim.
Bu sefer ağı Juniper üzerinde kuracağız çünkü artık JunO'nun arayüzü bir vanlove.

Yalnızca Açık Kaynak araçlarını ve çok sağlayıcılı bir ağı kullanarak hayatımızı daha da zorlaştıralım - bu yüzden yol boyunca Juniper'a ek olarak bir şanslı kişiyi daha seçeceğim.

Gelecek yayınlar için plan şuna benzer:
Öncelikle sanal ağlardan bahsedeceğim. Öncelikle istediğim için, ikincisi de bu olmadan altyapı ağının tasarımı pek net olmayacak.
Sonra ağ tasarımının kendisi hakkında: topoloji, yönlendirme, politikalar.
Bir laboratuvar standı oluşturalım.
Bunu düşünelim ve belki de cihazı ağda başlatmayı deneyelim.
Ve sonra her bir bileşen hakkında ayrıntılı olarak bilgi vereceğiz.

Ve evet, bu döngüyü hazır bir çözümle zarif bir şekilde sonlandıracağıma söz vermiyorum. 🙂

Faydalı linkler

• Diziye geçmeden önce Natasha Samoilenko'nun kitabını okumaya değer. Ağ Mühendisleri için Python. Ve belki geçer seyir.
• Ayrıca okumanız da faydalı olacaktır. RFC Peter Lapukhov'un Facebook'tan veri merkezi fabrikalarının tasarımı hakkında.
• Mimari dokümantasyonu size Overlay SDN'nin nasıl çalıştığına dair bir fikir verecektir. Tungsten Kumaş (eski adıyla Open Contrail).

Teşekkür ederim

Roma Geçidi. Yorumlar ve düzenlemeler için.
Artyom Çernobay. KDPV'ye yönelik.

Kaynak: habr.com