Cisco ACI məlumat mərkəzi üçün şəbəkə quruluşu - administratora kömək etmək üçün

Cisco ACI məlumat mərkəzi üçün şəbəkə quruluşu - administratora kömək etmək üçün
Cisco ACI skriptinin bu sehrli parçasının köməyi ilə siz tez bir zamanda şəbəkə qura bilərsiniz.

Cisco ACI məlumat mərkəzi üçün şəbəkə fabriki beş ildir mövcuddur, lakin Habré bu barədə heç nə demədi, ona görə də onu bir az düzəltməyə qərar verdim. Mən sizə öz təcrübəmdən bunun nə olduğunu, nə üçün lazım olduğunu və harada dırmıq olduğunu söyləyəcəyəm.

Bu nədir və haradan gəldi?

2013-cü ildə ACI (Tətbiq Mərkəzli İnfrastruktur) elan edilən zaman rəqiblər eyni anda üç tərəfdən məlumat mərkəzi şəbəkələrinə ənənəvi yanaşmalar üzərində irəliləyirdilər.

Bir tərəfdən, OpenFlow-a əsaslanan "birinci nəsil" SDN həlləri şəbəkələri eyni zamanda daha çevik və daha ucuz etməyə söz verdi. İdeya, ənənəvi olaraq xüsusi keçid proqramı tərəfindən həyata keçirilən qərar qəbulunu mərkəzi nəzarətçiyə köçürmək idi.

Bu nəzarətçi baş verən hər şey haqqında vahid bir baxışa sahib olacaq və buna əsaslanaraq, bütün açarların aparatını xüsusi axınların işlənməsi qaydaları səviyyəsində proqramlaşdıracaq.
Digər tərəfdən, overlay şəbəkə həlləri virtuallaşdırılmış hostlar arasında proqram tunelləri quraraq, ümumiyyətlə fiziki şəbəkədə heç bir dəyişiklik etmədən lazımi əlaqə və təhlükəsizlik siyasətlərini həyata keçirməyə imkan verdi. Bu yanaşmanın ən məşhur nümunəsi o vaxta qədər VMWare tərəfindən 1,26 milyard dollara alınmış və indiki VMWare NSX-in yaranmasına səbəb olan Nicira idi. Vəziyyətin bəzi acınacaqlılığı, Nicira-nın həmtəsisçilərinin əvvəllər OpenFlow-un mənşəyində dayanan eyni adamlar olması ilə əlavə edildi, indi məlumat mərkəzi fabriki qurmaq üçün OpenFlow uyğun deyil.

Və nəhayət, açıq bazarda mövcud olan kommutasiya çipləri (tacir silikonu adlanır) ənənəvi keçid istehsalçıları üçün real təhlükəyə çevrildiyi yetkinlik mərhələsinə çatdı. Əgər əvvəllər hər bir satıcı öz açarları üçün müstəqil olaraq çiplər hazırlayırdısa, zaman keçdikcə üçüncü tərəf istehsalçılarının, ilk növbədə Broadcom-un çipləri funksiyalarına görə satıcı çipləri ilə məsafəni azaltmağa başladı və qiymət / performans nisbətinə görə onları ötdü. Buna görə də, bir çoxları öz dizaynlarının çiplərindəki açarların günlərinin sayıldığına inanırdılar.

ACI yuxarıda qeyd olunanların hamısına Cisco-nun “asimmetrik cavabı” oldu (daha doğrusu, onun keçmiş işçiləri tərəfindən yaradılmış Insieme şirkəti).

OpenFlow ilə fərq nədir?

Funksiyaların paylanması baxımından ACI əslində OpenFlow-un əksidir.
OpenFlow arxitekturasında nəzarətçi ətraflı qaydaların (axınların) yazılmasına cavabdehdir.
bütün açarların aparatında, yəni böyük bir şəbəkədə o, şəbəkənin yüzlərlə nöqtəsində on milyonlarla qeydin saxlanmasına və ən əsası dəyişdirilməsinə cavabdeh ola bilər, buna görə də onun performansı və etibarlılığı bir darboğaza çevrilir. böyük icra.

ACI tərs yanaşmadan istifadə edir: əlbəttə ki, nəzarətçi də var, lakin açarlar ondan yüksək səviyyəli deklarativ siyasətlər alır və açarın özü onların renderini aparatdakı xüsusi parametrlərin təfərrüatlarına çevirir. Nəzarətçi yenidən işə salına və ya tamamilə söndürülə bilər və əlbəttə ki, bu anda nəzarətin olmaması istisna olmaqla, şəbəkədə pis bir şey olmayacaq. Maraqlıdır ki, ACI-də OpenFlow-un hələ də istifadə edildiyi hallar var, lakin Open vSwitch proqramlaşdırması üçün host daxilində yerli olaraq.

ACI bütünlüklə VXLAN əsaslı üst-üstə düşmə nəqliyyatı üzərində qurulub, lakin vahid həllin bir hissəsi kimi əsas İP nəqliyyatını ehtiva edir. Cisco bunu "inteqrasiya edilmiş örtük" termini adlandırdı. ACI-də üst-üstə düşmələr üçün son nöqtə kimi, əksər hallarda zavod açarları istifadə olunur (bunu keçid sürətində edirlər). Hostlardan zavod, inkapsulyasiya və s. haqqında heç nə bilmələri tələb olunmur, lakin bəzi hallarda (məsələn, OpenStack hostlarını birləşdirmək üçün) onlara VXLAN trafiki gətirilə bilər.

Bindirmələr ACI-də yalnız nəqliyyat şəbəkəsi vasitəsilə çevik əlaqə təmin etmək üçün deyil, həm də metainformasiyanın ötürülməsi üçün istifadə olunur (məsələn, təhlükəsizlik siyasətini tətbiq etmək üçün istifadə olunur).

Broadcom-dan olan çiplər əvvəllər Nexus 3000 seriyalı açarlarda Cisco tərəfindən istifadə olunurdu.ACI-ı dəstəkləmək üçün xüsusi olaraq buraxılan Nexus 9000 ailəsində əvvəlcə Merchant+ adlanan hibrid model tətbiq olundu. Keçid eyni vaxtda həm yeni Broadcom Trident 2 çipindən, həm də ACI-nin bütün sehrini həyata keçirən Cisco tərəfindən hazırlanmış tamamlayıcı çipdən istifadə etdi. Görünür, bu, məhsulun buraxılışını sürətləndirməyə və keçidin qiymət etiketini sadəcə Trident 2-yə əsaslanan modellərə yaxın səviyyəyə endirməyə imkan verdi. Bu yanaşma ACI-nin çatdırılmasının ilk iki və ya üç ili üçün kifayət idi. Bu müddət ərzində Cisco yeni nəsil Nexus 9000-ni daha çox performans və xüsusiyyət dəsti ilə, lakin eyni qiymət səviyyəsində öz çiplərində hazırlayıb təqdim etdi. Zavodda qarşılıqlı əlaqə baxımından xarici spesifikasiyalar tamamilə qorunur. Eyni zamanda, daxili doldurma tamamilə dəyişdi: refaktorinq kimi bir şey, ancaq dəmir üçün.

Cisco ACI Architecture necə işləyir

Ən sadə halda, ACI Klose şəbəkəsinin topologiyası və ya tez-tez deyildiyi kimi, Spine-Leaf üzərində qurulur. Onurğa səviyyəli açarlar ikidən (və ya səhvlərə dözümlülüyünü nəzərə almasaq, birdən) altıya qədər ola bilər. Müvafiq olaraq, onların sayı nə qədər çox olarsa, nasazlığa dözümlülük bir o qədər yüksəkdir (qəza zamanı və ya bir Onurğanın saxlanması halında bant genişliyi və etibarlılığın azalması) və ümumi performans. Bütün xarici əlaqələr yarpaq səviyyəli açarlara keçir: bunlar serverlərdir və L2 və ya L3 vasitəsilə xarici şəbəkələrə qoşulma və APIC kontrollerlərini birləşdirən serverlərdir. Ümumiyyətlə, ACI ilə yalnız konfiqurasiya deyil, həm də statistik məlumatların toplanması, nasazlığın monitorinqi və s. - hər şey standart ölçülü tətbiqlərdə üçü olan nəzarətçilərin interfeysi vasitəsilə həyata keçirilir.

Heç vaxt konsolla açarlara qoşulmaq məcburiyyətində deyilsiniz, hətta şəbəkəni işə salmaq üçün: nəzarətçi özü açarları aşkarlayır və onlardan bir zavod yığır, o cümlədən bütün xidmət protokollarının parametrləri, buna görə də yeri gəlmişkən, çox vacibdir. quraşdırma zamanı quraşdırılan avadanlığın seriya nömrələrini yazın ki, sonradan hansı açarın hansı rəfdə yerləşdiyini təxmin etməyə ehtiyac qalmasın. Problemləri həll etmək üçün, lazım gələrsə, SSH vasitəsilə açarlara qoşula bilərsiniz: onlar adi Cisco şou əmrlərini olduqca diqqətlə təkrarlayırlar.

Daxili olaraq, fabrik IP nəqliyyatından istifadə edir, buna görə də orada heç bir Spanning Tree və keçmişin digər dəhşətləri yoxdur: bütün bağlantılar iştirak edir və uğursuzluqlar halında yaxınlaşma çox sürətlidir. Parçadakı trafik VXLAN əsasında tunellər vasitəsilə ötürülür. Daha dəqiq desək, Cisco özü iVXLAN inkapsulyasiyasını adlandırır və o, adi VXLAN-dan onunla fərqlənir ki, şəbəkə başlığında qorunan sahələr xidmət məlumatlarını ötürmək üçün istifadə olunur, ilk növbədə trafikin EPG qrupu ilə əlaqəsi haqqında. Bu, adi giriş siyahılarında ünvanlar istifadə edildiyi kimi onların nömrələrindən istifadə edərək, avadanlıqdakı qruplar arasında qarşılıqlı əlaqə qaydalarını həyata keçirməyə imkan verir.

Tunellər həm L2 seqmentlərini, həm də L3 seqmentlərini (yəni VRF) daxili IP nəqliyyatı vasitəsilə uzatmağa imkan verir. Bu halda, standart şlüz paylanır. Bu o deməkdir ki, hər bir keçid parçaya daxil olan trafikin yönləndirilməsinə cavabdehdir. Trafik axını məntiqi baxımından ACI VXLAN/EVPN quruluşuna bənzəyir.

Əgər belədirsə, fərqlər nələrdir? Qalan hər şey!

ACI ilə qarşılaşdığınız bir nömrəli fərq, serverlərin şəbəkəyə necə qoşulmasıdır. Ənənəvi şəbəkələrdə həm fiziki serverlərin, həm də virtual maşınların daxil edilməsi VLAN-lara gedir və hər şey onlardan gedir: əlaqə, təhlükəsizlik və s. ACI-də Cisco-nun EPG (End-point Group) adlandırdığı dizayndan istifadə olunur. uzaqlaşan yer yoxdur. Onu VLAN-a bərabərləşdirmək mümkündürmü? Bəli, amma bu vəziyyətdə ACI-nin verdiyi şeylərin çoxunu itirmək şansı var.

EPG-yə gəldikdə, bütün giriş qaydaları tərtib edilmişdir və ACI-də "ağ siyahı" prinsipi standart olaraq istifadə olunur, yəni yalnız keçidə açıq şəkildə icazə verilən trafikə icazə verilir. Yəni, biz "Web" və "MySQL" EPG qruplarını yarada və onlar arasında yalnız 3306 portunda əlaqə yaratmağa imkan verən qayda müəyyən edə bilərik. Bu, şəbəkə ünvanlarına bağlanmadan və hətta eyni alt şəbəkə daxilində işləyəcək!

Bu xüsusiyyətə görə ACI-ni seçmiş müştərilərimiz var, çünki o, serverlər arasında girişi məhdudlaşdırmağa imkan verir (virtual və ya fiziki - fərqi yoxdur) onları alt şəbəkələr arasında sürükləmədən, yəni ünvana toxunmadan. Bəli, bəli, bilirik ki, heç kim tətbiq konfiqurasiyalarında IP ünvanlarını əl ilə təyin etmir, elə deyilmi?

ACI-də yol hərəkəti qaydaları müqavilələr adlanır. Belə bir müqavilədə çox səviyyəli proqramda bir və ya bir neçə qrup və ya səviyyə xidmət təminatçısına (məsələn, verilənlər bazası xidməti), digərləri isə istehlakçıya çevrilir. Müqavilə sadəcə olaraq trafiki ötürə bilər və ya daha çətin bir şey edə bilər, məsələn, onu firewall və ya balanslaşdırıcıya yönləndirə, həmçinin QoS dəyərini dəyişdirə bilər.

Serverlər bu qruplara necə daxil olurlar? Əgər bunlar fiziki serverlər və ya VLAN magistralını yaratdığımız mövcud şəbəkəyə daxil olan bir şeydirsə, onları EPG-də yerləşdirmək üçün keçid portunu və orada istifadə olunan VLAN-ı göstərməlisiniz. Gördüyünüz kimi, VLAN-lar onsuz edə bilməyəcəyiniz yerlərdə görünür.

Əgər serverlər virtual maşınlardırsa, o zaman qoşulmuş virtuallaşdırma mühitinə müraciət etmək kifayətdir və sonra hər şey öz-özünə baş verəcək: VM-ni birləşdirmək üçün port qrupu yaradılacaq (VMWare baxımından), lazımi VLAN və ya VXLAN-lar təyin olunarsa, onlar lazımi keçid portlarında qeydiyyatdan keçəcəklər və s. Beləliklə, ACI fiziki şəbəkə ətrafında qurulsa da, virtual serverlər üçün bağlantılar fiziki olanlara nisbətən daha sadə görünür. ACI artıq VMWare və MS Hyper-V ilə daxili bağlantıya, həmçinin OpenStack və RedHat Virtualization dəstəyinə malikdir. Bir nöqtədən, konteyner platformaları üçün daxili dəstək də ortaya çıxdı: Kubernetes, OpenShift, Cloud Foundry, həm siyasətlərin tətbiqinə, həm də monitorinqə aiddir, yəni şəbəkə administratoru hansı podların işlədiyini və hansı hostların işlədiyini dərhal görə bilər. hansı qruplara düşürlər.

Müəyyən bir port qrupuna daxil olmaqla yanaşı, virtual serverlər əlavə xüsusiyyətlərə malikdir: ad, atributlar və s., bunlar başqa qrupa ötürülməsi üçün meyar kimi istifadə edilə bilər, məsələn, VM-nin adı dəyişdirildikdə və ya əlavə etiket göründükdə. o. Cisco bunu mikro-seqmentasiya qrupları adlandırır, baxmayaraq ki, eyni alt şəbəkədə EPG şəklində bir çox təhlükəsizlik seqmentləri yaratmaq imkanı ilə dizaynın özü də kifayət qədər mikro seqmentasiyadır. Yaxşı, satıcı daha yaxşı bilir.

EPG-lərin özləri sırf məntiqi konstruksiyalardır, xüsusi açarlara, serverlərə və s.-yə bağlı deyillər, ona görə də siz onlarla işlər görə bilərsiniz və onlara əsaslanan konstruksiyalar (tətbiqlər və kirayəçilər) adi şəbəkələrdə, məsələn, klonlamada etmək çətindir. Nəticə olaraq deyək ki, istehsal mühiti ilə eyni olmasına zəmanət verilən sınaq mühiti əldə etmək üçün istehsal mühitini klonlaşdırmaq çox asandır. Bunu əl ilə edə bilərsiniz, lakin API vasitəsilə daha yaxşıdır (və daha asandır).

Ümumiyyətlə, ACI-də idarəetmə məntiqi ümumiyyətlə rastlaşdığınıza bənzəmir
eyni Cisco-dan olan ənənəvi şəbəkələrdə: proqram interfeysi əsasdır, GUI və ya CLI isə ikinci dərəcəlidir, çünki onlar eyni API vasitəsilə işləyirlər. Buna görə də, ACI-də iştirak edən demək olar ki, hər kəs bir müddət sonra idarəetmə üçün istifadə olunan obyekt modelində naviqasiya etməyə və ehtiyaclarına uyğun bir şeyi avtomatlaşdırmağa başlayır. Bunu etməyin ən asan yolu Python-dandır: bunun üçün rahat hazır alətlər var.

Söz verilmiş tırmık

Əsas problem ACI-də bir çox şeyin fərqli şəkildə edilməsidir. Onunla normal işləməyə başlamaq üçün yenidən məşq etməlisiniz. Bu, xüsusilə mühəndislərin istək əsasında illərdir “VLAN-lar təyin etdiyi” böyük müştərilərin şəbəkə əməliyyatları qrupları üçün doğrudur. İndi VLAN-ların artıq VLAN olmadığı və virtuallaşdırılmış hostlarda yeni şəbəkələr yaratmaq üçün əl ilə VLAN yaratmağınıza ehtiyac olmadığı faktı ənənəvi şəbəkəçilərin damını tamamilə məhv edir və onları tanış yanaşmalardan yapışmağa məcbur edir. Qeyd etmək lazımdır ki, Cisco həbi bir az şirinləşdirməyə çalışdı və nəzarətçiyə ənənəvi açarlara bənzər interfeysdən konfiqurasiya etməyə imkan verən “NXOS-a bənzər” CLI əlavə etdi. Ancaq yenə də ACI-dən normal istifadə etməyə başlamaq üçün onun necə işlədiyini başa düşməlisiniz.

Qiymət baxımından böyük və orta miqyasda ACI şəbəkələri əslində Cisco avadanlığında ənənəvi şəbəkələrdən fərqlənmir, çünki onları qurmaq üçün eyni açarlardan istifadə olunur (Nexus 9000 ACI və ənənəvi rejimdə işləyə bilər və indi əsas şəbəkəyə çevrilib. yeni məlumat mərkəzi layihələri üçün "işgücü"). Ancaq iki açarın məlumat mərkəzləri üçün nəzarətçilərin və Spine-Leaf arxitekturasının mövcudluğu, əlbəttə ki, özlərini hiss etdirir. Bu yaxınlarda üç nəzarətçidən ikisinin virtual maşınlarla əvəz olunduğu Mini ACI fabriki meydana çıxdı. Bu, xərc fərqini azaldır, lakin yenə də qalır. Beləliklə, müştəri üçün seçim onun təhlükəsizlik xüsusiyyətləri, virtualizasiya ilə inteqrasiya, vahid idarəetmə nöqtəsi və s.

Mənbə: www.habr.com

Добавить комментарий