Kun la helpo de ĉi tiu magia peco de Cisco ACI-skripto, vi povas rapide agordi reton.
La reto-fabriko por la datumcentro de Cisco ACI ekzistas de kvin jaroj, sed Habré vere nenion diris pri ĝi, do mi decidis iomete ripari ĝin. Mi diros al vi laŭ mia propra sperto, kio ĝi estas, kia ĝi utilas kaj kie ĝi havas rastilon.
Kio ĝi estas kaj de kie ĝi venis?
Antaŭ la tempo ACI (Application Centric Infrastructure) estis sciigita en 2013, konkurantoj avancis sur tradiciaj aliroj al datencentraj retoj de tri flankoj samtempe.
Unuflanke, "unua generacio" SDN-solvoj bazitaj sur OpenFlow promesis fari retojn pli flekseblaj kaj pli malmultekostaj samtempe. La ideo estis movi la decidiĝon tradicie faritan per proprieta ŝaltilsoftvaro al centra regilo.
Ĉi tiu regilo havus ununuran vizion de ĉio, kio okazas kaj, surbaze de tio, programus la aparataron de ĉiuj ŝaltiloj je la nivelo de reguloj por prilaborado de specifaj fluoj.
Aliflanke, supermetitaj retosolvoj ebligis efektivigi la necesajn konekteblec- kaj sekurecpolitikojn tute sen ajnaj ŝanĝoj en la fizika reto, konstruante programajn tunelojn inter virtualigitaj gastigantoj. La plej konata ekzemplo de ĉi tiu aliro estis Nicira, kiu tiam jam estis akirita de VMWare por $ 1,26 miliardoj kaj kaŭzis la nunan VMWare NSX. Iom da pikado de la situacio aldoniĝis pro la fakto, ke la kunfondintoj de Nicira estis la samaj homoj, kiuj antaŭe staris ĉe la originoj de OpenFlow, nun dirante, ke por konstrui datumcentran fabrikon. .
Kaj finfine, ŝanĝado de blatoj disponeblaj sur la malferma merkato (kio nomiĝas komerca silicio) atingis stadion de matureco, kie ili fariĝis vera minaco por tradiciaj ŝaltiloj. Se pli frue ĉiu vendisto sendepende disvolvis blatojn por siaj ŝaltiloj, tiam kun la tempo, blatoj de triaj fabrikistoj, ĉefe de Broadcom, komencis redukti la distancon kun vendistaj blatoj laŭ funkcioj, kaj superis ilin laŭ prezo/efikeco. Tial multaj kredis, ke la tagoj de ŝaltiloj sur blatoj de sia propra dezajno estis nombritaj.
ACI fariĝis la "nesimetria respondo" de Cisco (pli precize ĝia kompanio Insieme, fondita de ĝiaj iamaj dungitoj) al ĉio ĉi-supra.
Kio estas la diferenco kun OpenFlow?
Koncerne distribuadon de funkcioj, ACI estas fakte la malo de OpenFlow.
En la OpenFlow-arkitekturo, la regilo respondecas pri skribado de detalaj reguloj (fluoj)
en la aparataro de ĉiuj ŝaltiloj, tio estas, en granda reto, ĝi povas esti respondeca pri konservado kaj, plej grave, ŝanĝado de dekoj da milionoj da rekordoj ĉe centoj da punktoj en la reto, do ĝia rendimento kaj fidindeco fariĝas botelkolo en granda efektivigo.
ACI uzas la inversan aliron: kompreneble ekzistas ankaŭ regilo, sed la ŝaltiloj ricevas altnivelajn deklarajn politikojn de ĝi, kaj la ŝaltilo mem elfaras sian bildigon en detalojn de specifaj agordoj en la aparataro. La regilo povas esti rekomencita aŭ malŝaltita entute, kaj nenio malbona okazos al la reto, krom, kompreneble, la manko de kontrolo ĉi-momente. Interese, estas situacioj en ACI, en kiuj OpenFlow ankoraŭ estas uzata, sed loke ene de la gastiganto por programado de Open vSwitch.
ACI estas konstruita tute sur VXLAN-bazita superkovra transporto, sed inkluzivas la suban IP-transporton kiel parton de ununura solvo. Cisco nomis tion la "integra superkovro-" esprimo. Kiel finpunkto por supermetaĵoj en ACI, en la plej multaj kazoj, fabrikŝaltiloj estas uzitaj (ili faras tion ĉe ligrapideco). Gastigantoj ne bezonas scii ion pri la fabriko, enkapsuligo, ktp., tamen, en iuj kazoj (ekzemple, por konekti OpenStack-gastigantojn), VXLAN-trafiko povas esti alportita al ili.
Supermetaĵoj estas uzataj en ACI ne nur por disponigi flekseblan konekteblecon tra la transportreto, sed ankaŭ por transdoni metainformojn (ĝi estas uzata, ekzemple, por apliki sekurecpolitikojn).
Blatoj de Broadcom antaŭe estis uzitaj fare de Cisco en la Nexus 3000-serioŝaltiloj. En la Nexus 9000-familio, speciale liberigita por subteni ACI, hibrida modelo estis origine efektivigita, kiu estis nomita Merchant +. La ŝaltilo samtempe uzis kaj la novan blaton Broadcom Trident 2 kaj komplementan blaton evoluigitan de Cisco, kiu efektivigas la tutan magion de ACI. Ŝajne, ĉi tio ebligis akceli la liberigon de la produkto kaj redukti la prezon de la ŝaltilo al nivelo proksima al modeloj simple bazitaj sur Trident 2. Ĉi tiu aliro sufiĉis por la unuaj du aŭ tri jaroj de ACI-liveraĵoj. Dum ĉi tiu tempo, Cisco evoluigis kaj lanĉis la venontan generacion Nexus 9000 sur siaj propraj blatoj kun pli da efikeco kaj funkcioj, sed je la sama preznivelo. Eksteraj specifoj rilate al interago en la fabriko estas tute konservitaj. Samtempe, la interna plenigo tute ŝanĝiĝis: io kiel refaktorado, sed por aparataro.
Kiel Funkcias la Arkitekturo de Cisco ACI
En la plej simpla kazo, ACI estas konstruita sur la topologio de la Klose-reto, aŭ, kiel ili ofte diras, Spine-Leaf. Spin-nivelaj ŝaltiloj povas esti de du (aŭ unu, se ni ne zorgas pri misfunkciado) ĝis ses. Sekve, ju pli da ili, des pli alta estas la toleremo al misfunkciadoj (des pli malalta la bendolarĝo kaj fidindeco redukto en kazo de akcidento aŭ bontenado de unu Spino) kaj la ĝenerala agado. Ĉiuj eksteraj konektoj iras al folio-nivelaj ŝaltiloj: ĉi tiuj estas serviloj, kaj aldokiĝo kun eksteraj retoj per L2 aŭ L3, kaj konektanta APIC-regilojn. Ĝenerale, kun ACI, ne nur agordo, sed ankaŭ statistika kolekto, malsukcesa monitorado ktp - ĉio estas farita per la interfaco de regiloj, el kiuj estas tri en normgrandaj efektivigoj.
Vi neniam devas konekti al la ŝaltiloj per la konzolo, eĉ por komenci la reton: la regilo mem detektas la ŝaltilojn kaj arigas fabrikon de ili, inkluzive de la agordoj de ĉiuj servaj protokoloj, tial, cetere, estas tre grave. notu la seriajn numerojn de la ekipaĵo instalita dum instalado, por ke poste vi ne devu diveni, kiu ŝaltilo estas en kiu rako troviĝas. Por solvi problemojn, se necese, vi povas konektiĝi al la ŝaltiloj per SSH: ili reproduktas la kutimajn Cisco-show-komandojn sufiĉe zorge.
Interne, la fabriko uzas IP-transporton, do ne estas Spanning Tree kaj aliaj hororoj de la pasinteco en ĝi: ĉiuj ligiloj estas implikitaj, kaj konverĝo en kazo de fiaskoj estas tre rapida. La trafiko en la ŝtofo estas elsendita tra tuneloj bazitaj sur VXLAN. Pli precize, Cisco mem nomas iVXLAN-enkapsuligon, kaj ĝi diferencas de regula VXLAN en tio, ke la rezervitaj kampoj en la retkapo estas uzataj por transdoni servajn informojn, ĉefe pri la rilato de trafiko al la EPG-grupo. Ĉi tio ebligas al vi efektivigi la regulojn de interagado inter grupoj en la ekipaĵo, uzante iliajn numerojn same kiel adresoj estas uzataj en ordinaraj alirlistoj.
Tuneloj permesas kaj L2-segmentojn kaj L3-segmentojn (t.e. VRF) esti streĉitaj tra la interna IP-transporto. En ĉi tiu kazo, la defaŭlta enirejo estas distribuita. Ĉi tio signifas, ke ĉiu ŝaltilo respondecas pri direktado de la trafiko eniranta la ŝtofon. Laŭ trafikflua logiko, ACI similas al ŝtofo VXLAN/EVPN.
Se jes, kio estas la diferencoj? Ĉio alia!
La numero unu diferenco, kiun vi renkontas kun ACI, estas kiel serviloj estas konektitaj al la reto. En tradiciaj retoj, la inkludo de kaj fizikaj serviloj kaj virtualaj maŝinoj iras al VLAN-oj, kaj ĉio alia dancas de ili: konektebleco, sekureco, ktp. En ACI, estas uzata dezajno, kiun Cisco nomas EPG (End-point Group), de kiu estas nenie foriri. Ĉu eblas egaligi ĝin al VLAN? Jes, sed ĉi-kaze estas ŝanco perdi la plej grandan parton de tio, kion donas ACI.
Koncerne EPG, ĉiuj alirreguloj estas formulitaj, kaj en ACI, la principo "blanka listo" estas uzata defaŭlte, tio estas, nur trafiko estas permesita, kies trairejo estas eksplicite permesita. Tio estas, ni povas krei la EPG-grupojn "TTT" kaj "MySQL" kaj difini regulon, kiu ebligas komunikadon inter ili nur sur la haveno 3306. Ĉi tio funkcios sen esti ligita al retadresoj kaj eĉ ene de la sama subreto!
Ni havas klientojn, kiuj elektis ACI ĝuste pro ĉi tiu funkcio, ĉar ĝi permesas vin limigi aliron inter serviloj (virtuala aŭ fizika - ne gravas) sen treni ilin inter subretojn, kio signifas sen tuŝi la adresadon. Jes, jes, ni scias, ke neniu preskribas IP-adresojn en aplikaj agordoj mane, ĉu ne?
Trafikreguloj en ACI estas nomitaj kontraktoj. En tia kontrakto, unu aŭ pluraj grupoj aŭ niveloj en plurnivela aplikaĵo fariĝas servoprovizanto (ekzemple, datumbaza servo), aliaj fariĝas konsumanto. La kontrakto povas simple trapasi trafikon, aŭ ĝi povas fari ion pli malfacilan, ekzemple direkti ĝin al fajroŝirmilo aŭ ekvilibristo, kaj ankaŭ ŝanĝi la QoS-valoron.
Kiel serviloj eniras ĉi tiujn grupojn? Se ĉi tiuj estas fizikaj serviloj aŭ io inkluzivita en ekzistanta reto en kiu ni kreis VLAN-trunkon, tiam por meti ilin en la EPG, vi devos indiki la ŝaltilhavenon kaj la VLAN uzatan sur ĝi. Kiel vi povas vidi, VLANoj aperas kie vi ne povas malhavi ilin.
Se la serviloj estas virtualaj maŝinoj, tiam sufiĉas referenci al la ligita virtualiga medio, kaj tiam ĉio okazos per si mem: havengrupo estos kreita (laŭ VMWare) por konekti la VM, la necesaj VLAN-oj aŭ VXLAN-oj estos kreitaj. esti asignitaj, ili estos registritaj sur la necesaj ŝaltilpordoj, ktp. Do, kvankam ACI estas konstruita ĉirkaŭ fizika reto, konektoj por virtualaj serviloj aspektas multe pli simplaj ol por fizikaj. ACI jam havas enkonstruitan konekteblecon kun VMWare kaj MS Hyper-V, kaj ankaŭ subtenon por OpenStack kaj RedHat Virtualization. De iu momento aperis ankaŭ enkonstruita subteno por ujplatformoj: Kubernetes, OpenShift, Cloud Foundry, dum ĝi koncernas kaj la aplikon de politikoj kaj monitorado, tio estas, la administranto de la reto tuj povas vidi sur kiuj gastigantoj, kiuj podoj funkcias kaj kiujn grupojn ili falas.
Krom esti inkluditaj en aparta havengrupo, virtualaj serviloj havas kromajn trajtojn: nomo, atributoj, ktp., kiuj povas esti uzataj kiel kriterioj por transdoni ilin al alia grupo, ekzemple, kiam VM estas renomita aŭ plia etikedo aperas en ĝi. Cisco nomas ĉi tion mikro-segmentaj grupoj, kvankam, ĝenerale, la dezajno mem kun la kapablo krei multajn sekurecsegmentojn en la formo de EPGoj sur la sama subreto ankaŭ estas sufiĉe mikro-segmentado. Nu, la vendisto scias pli bone.
EPG-oj mem estas pure logikaj konstrukcioj, ne ligitaj al specifaj ŝaltiloj, serviloj, ktp., do vi povas fari aferojn per ili kaj konstrukciojn bazitajn sur ili (aplikaĵoj kaj luantoj) malfacile fareblaj en ordinaraj retoj, kiel klonado. Kiel rezulto, ni diru, ke estas tre facile kloni produktadmedion por akiri testan medion, kiu garantias esti identa al la produktadmedio. Vi povas fari ĝin permane, sed ĝi estas pli bona (kaj pli facila) per la API.
Ĝenerale, la kontrollogiko en ACI tute ne similas al tio, kion vi kutime renkontas
en tradiciaj retoj de la sama Cisco: la programara interfaco estas primara, kaj la GUI aŭ CLI estas sekundaraj, ĉar ili funkcias per la sama API. Tial, preskaŭ ĉiuj implikitaj en ACI, post iom da tempo, komencas navigi la objektomodelon uzatan por administrado kaj aŭtomatigi ion por konveni siajn bezonojn. La plej facila maniero fari tion estas de Python: estas oportunaj pretaj iloj por ĝi.
Promesita rastilo
La ĉefa problemo estas, ke multaj aferoj en ACI estas faritaj malsame. Por komenci labori kun ĝi normale, vi devas retrejni. Ĉi tio validas precipe por retaj operaciaj teamoj en grandaj klientoj, kie inĝenieroj "preskribas VLANojn" dum jaroj laŭ peto. La fakto, ke nun VLAN-oj ne plu estas VLAN-oj, kaj vi ne bezonas krei VLAN-ojn mane por meti novajn retojn en virtualigitaj gastigantoj, tute blovas la tegmenton de tradiciaj retumantoj kaj igas ilin alkroĉiĝi al konataj aliroj. Oni devas rimarki, ke Cisco provis dolĉigi la pilolon iomete kaj aldonis "NXOS-similan" CLI al la regilo, kiu ebligas al vi fari agordon de interfaco simila al tradiciaj ŝaltiloj. Sed tamen, por komenci uzi ACI normale, vi devas kompreni kiel ĝi funkcias.
Laŭ prezo, je grandaj kaj mezaj skaloj, ACI-retoj fakte ne diferencas de tradiciaj retoj sur Cisco-ekipaĵoj, ĉar la samaj ŝaltiloj estas uzataj por konstrui ilin (Nexus 9000 povas funkcii en ACI kaj en tradicia reĝimo kaj fariĝis nun la ĉefa. "laborĉevalo" por novaj datencentraj projektoj). Sed por datumcentroj de du ŝaltiloj, la ĉeesto de regiloj kaj Spine-Leaf-arkitekturo, kompreneble, sentas sin. Lastatempe aperis Mini ACI-fabriko, en kiu du el la tri regiloj estas anstataŭigitaj per virtualaj maŝinoj. Ĉi tio reduktas la diferencon en kosto, sed ĝi ankoraŭ restas. Do por la kliento, la elekto estas diktita de kiom li interesiĝas pri sekurecaj funkcioj, integriĝo kun virtualigo, ununura punkto de kontrolo, ktp.
fonto: www.habr.com