Sa tulong nitong mahiwagang piraso ng Cisco ACI script, mabilis kang makakapag-set up ng network.
Ang pabrika ng network para sa Cisco ACI data center ay umiral sa loob ng limang taon, ngunit wala talagang sinabi si HabrΓ© tungkol dito, kaya nagpasya akong ayusin ito nang kaunti. Sasabihin ko sa iyo mula sa aking sariling karanasan kung ano ito, kung ano ang silbi nito at kung saan ito may kalaykay.
Ano ito at saan ito nanggaling?
Sa oras na ang ACI (Application Centric Infrastructure) ay inihayag noong 2013, ang mga kakumpitensya ay sumusulong sa mga tradisyonal na diskarte sa mga network ng data center mula sa tatlong panig nang sabay-sabay.
Sa isang banda, ang mga "unang henerasyon" na solusyon sa SDN batay sa OpenFlow ay nangako na gagawing mas flexible at mas mura ang mga network sa parehong oras. Ang ideya ay ilipat ang paggawa ng desisyon na tradisyonal na ginagawa ng proprietary switch software sa isang sentral na controller.
Ang controller na ito ay magkakaroon ng isang solong pananaw sa lahat ng nangyayari at, batay dito, ipo-program ang hardware ng lahat ng switch sa antas ng mga panuntunan para sa pagproseso ng mga partikular na daloy.
Sa kabilang banda, ginawang posible ng mga overlay na solusyon sa network na ipatupad ang kinakailangang mga patakaran sa koneksyon at seguridad nang walang anumang pagbabago sa pisikal na network, na gumagawa ng mga software tunnel sa pagitan ng mga virtualized na host. Ang pinakakilalang halimbawa ng diskarteng ito ay ang Nicira, na noon ay nakuha na ng VMWare sa halagang $1,26 bilyon at nagbunga ng kasalukuyang VMWare NSX. Idinagdag ang ilang katuwaan ng sitwasyon sa katotohanan na ang mga co-founder ng Nicira ay ang parehong mga tao na dating nakatayo sa pinagmulan ng OpenFlow, ngayon ay nagsasabi na upang makabuo ng isang pabrika ng data center .
At sa wakas, ang paglipat ng mga chip na magagamit sa bukas na merkado (kung ano ang tinatawag na merchant silicon) ay umabot sa isang yugto ng kapanahunan kung saan sila ay naging isang tunay na banta sa mga tradisyunal na tagagawa ng switch. Kung mas maaga ang bawat vendor ay nakapag-iisa na bumuo ng mga chip para sa mga switch nito, pagkatapos ay sa paglipas ng panahon, ang mga chips mula sa mga tagagawa ng third-party, pangunahin mula sa Broadcom, ay nagsimulang bawasan ang distansya sa mga chips ng vendor sa mga tuntunin ng mga pag-andar, at nalampasan ang mga ito sa mga tuntunin ng ratio ng presyo / pagganap. Samakatuwid, marami ang naniniwala na ang mga araw ng mga switch sa mga chips ng kanilang sariling disenyo ay binilang.
Ang ACI ay naging "asymmetric response" ng Cisco (mas tiyak, ang kumpanyang Insieme nito, na itinatag ng mga dating empleyado nito) sa lahat ng nasa itaas.
Ano ang pagkakaiba sa OpenFlow?
Sa mga tuntunin ng pamamahagi ng mga function, ang ACI ay talagang kabaligtaran ng OpenFlow.
Sa arkitektura ng OpenFlow, ang controller ay responsable para sa pagsusulat ng mga detalyadong panuntunan (mga daloy)
sa hardware ng lahat ng switch, iyon ay, sa isang malaking network, maaaring may pananagutan ito sa pagpapanatili at, higit sa lahat, pagbabago ng sampu-sampung milyong record sa daan-daang puntos sa network, upang ang pagganap at pagiging maaasahan nito ay maging isang bottleneck sa isang malaking pagpapatupad.
Ginagamit ng ACI ang reverse approach: siyempre, mayroon ding controller, ngunit ang mga switch ay tumatanggap ng mataas na antas ng mga patakarang deklaratibo mula dito, at ang switch mismo ay nagsasagawa ng kanilang pag-render sa mga detalye ng mga partikular na setting sa hardware. Ang controller ay maaaring i-reboot o i-off nang buo, at walang masamang mangyayari sa network, maliban, siyempre, ang kawalan ng kontrol sa sandaling ito. Kapansin-pansin, may mga sitwasyon sa ACI kung saan ginagamit pa rin ang OpenFlow, ngunit lokal sa loob ng host para sa Open vSwitch programming.
Ang ACI ay ganap na binuo sa VXLAN-based na overlay na transportasyon, ngunit kasama ang pinagbabatayan na IP transport bilang bahagi ng isang solong solusyon. Tinawag ito ng Cisco na terminong "integrated overlay". Bilang termination point para sa mga overlay sa ACI, sa karamihan ng mga kaso, ginagamit ang mga factory switch (ginagawa nila ito sa bilis ng link). Ang mga host ay hindi kinakailangang malaman ang anumang bagay tungkol sa pabrika, encapsulation, atbp., gayunpaman, sa ilang mga kaso (halimbawa, upang ikonekta ang mga OpenStack host), ang trapiko ng VXLAN ay maaaring dalhin sa kanila.
Ang mga overlay ay ginagamit sa ACI hindi lamang upang magbigay ng nababaluktot na koneksyon sa pamamagitan ng network ng transportasyon, kundi pati na rin upang maglipat ng metainformation (ginagamit ito, halimbawa, upang ilapat ang mga patakaran sa seguridad).
Ang mga chip mula sa Broadcom ay dating ginamit ng Cisco sa mga switch ng serye ng Nexus 3000. Sa pamilyang Nexus 9000, na espesyal na inilabas upang suportahan ang ACI, isang hybrid na modelo ang orihinal na ipinatupad, na tinawag na Merchant +. Sabay-sabay na ginamit ng switch ang bagong Broadcom Trident 2 chip at isang complementary chip na binuo ng Cisco, na nagpapatupad ng lahat ng magic ng ACI. Tila, ginawa nitong posible na mapabilis ang paglabas ng produkto at bawasan ang tag ng presyo ng switch sa isang antas na malapit sa mga modelo na nakabatay lamang sa Trident 2. Ang diskarte na ito ay sapat para sa unang dalawa o tatlong taon ng paghahatid ng ACI. Sa panahong ito, binuo at inilunsad ng Cisco ang susunod na henerasyong Nexus 9000 sa sarili nitong mga chip na may higit na performance at feature set, ngunit sa parehong antas ng presyo. Ang mga panlabas na pagtutukoy sa mga tuntunin ng pakikipag-ugnayan sa pabrika ay ganap na napanatili. Kasabay nito, ang panloob na pagpuno ay ganap na nagbago: isang bagay tulad ng refactoring, ngunit para sa hardware.
Paano Gumagana ang Cisco ACI Architecture
Sa pinakasimpleng kaso, ang ACI ay binuo sa topology ng Klose network, o, gaya ng madalas nilang sinasabi, Spine-Leaf. Ang mga switch sa antas ng gulugod ay maaaring mula sa dalawa (o isa, kung wala tayong pakialam sa fault tolerance) hanggang anim. Alinsunod dito, mas marami sa kanila, mas mataas ang fault tolerance (mas mababa ang bandwidth at pagbabawas ng pagiging maaasahan sa kaso ng isang aksidente o pagpapanatili ng isang Spine) at ang pangkalahatang pagganap. Ang lahat ng panlabas na koneksyon ay pumupunta sa mga switch sa antas ng dahon: ito ay mga server, at docking sa mga panlabas na network sa pamamagitan ng L2 o L3, at pagkonekta sa mga APIC controller. Sa pangkalahatan, sa ACI, hindi lamang pagsasaayos, kundi pati na rin ang koleksyon ng mga istatistika, pagsubaybay sa kabiguan, at iba pa - lahat ay ginagawa sa pamamagitan ng interface ng mga controllers, kung saan mayroong tatlo sa mga standard-sized na pagpapatupad.
Hindi mo na kailangang kumonekta sa mga switch gamit ang console, kahit na upang simulan ang network: ang controller mismo ay nakakakita ng mga switch at nag-iipon ng isang pabrika mula sa kanila, kasama ang mga setting ng lahat ng mga protocol ng serbisyo, samakatuwid, sa pamamagitan ng paraan, napakahalaga na isulat ang mga serial number ng kagamitan na ini-install sa panahon ng pag-install, upang sa paglaon ay hindi mo na kailangang hulaan kung aling switch kung saan matatagpuan ang rack. Para sa pag-troubleshoot, kung kinakailangan, maaari kang kumonekta sa mga switch sa pamamagitan ng SSH: maingat nilang i-reproduce ang karaniwang Cisco show command.
Sa panloob, ang pabrika ay gumagamit ng IP transport, kaya walang Spanning Tree at iba pang mga kakila-kilabot sa nakaraan sa loob nito: lahat ng mga link ay kasangkot, at ang convergence sa kaso ng mga pagkabigo ay napakabilis. Ang trapiko sa tela ay ipinapadala sa pamamagitan ng mga tunnel batay sa VXLAN. Mas tiyak, ang Cisco mismo ang tumatawag sa iVXLAN encapsulation, at ito ay naiiba sa regular na VXLAN dahil ang mga nakalaan na field sa header ng network ay ginagamit upang magpadala ng impormasyon ng serbisyo, pangunahin ang tungkol sa kaugnayan ng trapiko sa pangkat ng EPG. Nagbibigay-daan ito sa iyo na ipatupad ang mga panuntunan ng pakikipag-ugnayan sa pagitan ng mga grupo sa kagamitan, gamit ang kanilang mga numero sa parehong paraan tulad ng paggamit ng mga address sa mga ordinaryong listahan ng pag-access.
Ang mga tunnel ay nagbibigay-daan sa parehong L2 segment at L3 segment (i.e. VRF) na ma-stretch sa pamamagitan ng internal na IP transport. Sa kasong ito, ang default na gateway ay ipinamamahagi. Nangangahulugan ito na ang bawat switch ay may pananagutan sa pagruruta ng trapiko na pumapasok sa tela. Sa mga tuntunin ng lohika ng daloy ng trapiko, ang ACI ay katulad ng isang tela ng VXLAN/EVPN.
Kung gayon, ano ang mga pagkakaiba? Lahat ng iba pa!
Ang numero unong pagkakaiba na nakatagpo mo sa ACI ay kung paano nakakonekta ang mga server sa network. Sa mga tradisyunal na network, ang pagsasama ng parehong mga pisikal na server at virtual machine ay napupunta sa mga VLAN, at lahat ng iba ay sumasayaw mula sa kanila: koneksyon, seguridad, atbp. Sa ACI, isang disenyo ang ginagamit na tinatawag ng Cisco na EPG (End-point Group), kung saan walang makaalis. Posible bang i-equate ito sa VLAN? Oo, ngunit sa kasong ito ay may pagkakataong mawala ang karamihan sa ibinibigay ng ACI.
Tungkol sa EPG, ang lahat ng mga panuntunan sa pag-access ay nabuo, at sa ACI, ang prinsipyo ng "puting listahan" ay ginagamit bilang default, iyon ay, ang trapiko lamang ang pinapayagan, ang pagpasa kung saan ay tahasang pinapayagan. Iyon ay, maaari tayong lumikha ng mga grupong "Web" at "MySQL" na EPG at tukuyin ang isang panuntunan na nagpapahintulot sa komunikasyon sa pagitan nila sa port 3306 lamang. Gagana ito nang hindi nakatali sa mga address ng network at maging sa loob ng parehong subnet!
Mayroon kaming mga customer na eksaktong pumili ng ACI dahil sa tampok na ito, dahil pinapayagan ka nitong paghigpitan ang pag-access sa pagitan ng mga server (virtual o pisikal - hindi mahalaga) nang hindi dina-drag ang mga ito sa pagitan ng mga subnet, na nangangahulugang hindi hinahawakan ang addressing. Oo, oo, alam namin na walang nagrereseta ng mga IP address sa mga pagsasaayos ng application sa pamamagitan ng kamay, tama ba?
Ang mga tuntunin sa trapiko sa ACI ay tinatawag na mga kontrata. Sa naturang kontrata, ang isa o higit pang mga grupo o antas sa isang multi-tier na application ay naging isang service provider (sabihin, isang serbisyo sa database), ang iba ay nagiging isang consumer. Ang kontrata ay maaaring pumasa lamang sa trapiko, o maaari itong gumawa ng isang bagay na mas nakakalito, halimbawa, idirekta ito sa isang firewall o balancer, at baguhin din ang halaga ng QoS.
Paano napupunta ang mga server sa mga pangkat na ito? Kung ito ay mga pisikal na server o isang bagay na kasama sa isang umiiral na network kung saan gumawa kami ng VLAN trunk, pagkatapos ay upang mailagay ang mga ito sa EPG, kakailanganin mong ituro ang switch port at ang VLAN na ginamit dito. Tulad ng nakikita mo, lumilitaw ang mga VLAN kung saan hindi mo magagawa nang wala ang mga ito.
Kung ang mga server ay mga virtual machine, kung gayon ito ay sapat na upang sumangguni sa konektadong kapaligiran ng virtualization, at pagkatapos ay ang lahat ay mangyayari sa kanyang sarili: isang port group ay malilikha (sa mga tuntunin ng VMWare) upang ikonekta ang VM, ang mga kinakailangang VLAN o VXLAN ay gagawa. itatalaga, sila ay irerehistro sa mga kinakailangang switch port, atbp. Kaya, kahit na ang ACI ay binuo sa paligid ng isang pisikal na network, ang mga koneksyon para sa mga virtual na server ay mukhang mas simple kaysa sa mga pisikal. Ang ACI ay mayroon nang built-in na koneksyon sa VMWare at MS Hyper-V, pati na rin ang suporta para sa OpenStack at RedHat Virtualization. Mula sa ilang sandali, lumitaw din ang built-in na suporta para sa mga container platform: Kubernetes, OpenShift, Cloud Foundry, habang ito ay may kinalaman sa parehong aplikasyon ng mga patakaran at pagsubaybay, iyon ay, makikita kaagad ng administrator ng network kung aling mga host ang gumagana at kung saang grupo sila nabibilang.
Bilang karagdagan sa pagiging kasama sa isang partikular na pangkat ng port, ang mga virtual server ay may mga karagdagang katangian: pangalan, mga katangian, atbp., na maaaring magamit bilang pamantayan para sa paglilipat sa kanila sa isa pang grupo, halimbawa, kapag ang isang VM ay pinalitan ng pangalan o isang karagdagang tag ay lilitaw sa ito. Tinatawag ng Cisco ang mga grupong ito ng micro-segmentation, bagaman, sa pangkalahatan, ang disenyo mismo na may kakayahang lumikha ng maraming mga segment ng seguridad sa anyo ng mga EPG sa parehong subnet ay medyo isang micro-segmentation. Well, mas alam ng vendor.
Ang mga EPG mismo ay mga lohikal na konstruksyon lamang, hindi nakatali sa mga partikular na switch, server, atbp., kaya maaari mong gawin ang mga bagay sa kanila at mga konstruksyon batay sa kanila (mga aplikasyon at nangungupahan) na mahirap gawin sa mga ordinaryong network, tulad ng pag-clone. Bilang resulta, sabihin nating napakadaling i-clone ang isang kapaligiran ng produksyon upang makakuha ng isang kapaligiran sa pagsubok na garantisadong magkapareho sa kapaligiran ng produksyon. Magagawa mo ito nang manu-mano, ngunit ito ay mas mahusay (at mas madali) sa pamamagitan ng API.
Sa pangkalahatan, ang control logic sa ACI ay hindi katulad ng karaniwan mong natutugunan
sa mga tradisyunal na network mula sa parehong Cisco: ang interface ng software ay pangunahin, at ang GUI o CLI ay pangalawa, dahil gumagana ang mga ito sa parehong API. Samakatuwid, halos lahat ng kasangkot sa ACI, pagkaraan ng ilang sandali, ay nagsisimulang mag-navigate sa object model na ginagamit para sa pamamahala at i-automate ang isang bagay upang umangkop sa kanilang mga pangangailangan. Ang pinakamadaling paraan upang gawin ito ay mula sa Python: may mga maginhawang handa na mga tool para dito.
Nangako kalaykay
Ang pangunahing problema ay ang maraming bagay sa ACI ay ginagawa nang iba. Upang magsimulang magtrabaho kasama nito nang normal, kailangan mong magsanay muli. Ito ay totoo lalo na para sa mga network operations team sa malalaking customer, kung saan ang mga inhinyero ay "nagrereseta ng mga VLAN" sa loob ng maraming taon kapag hiniling. Ang katotohanan na ngayon ang mga VLAN ay hindi na mga VLAN, at hindi mo na kailangang lumikha ng mga VLAN sa pamamagitan ng kamay upang maglagay ng mga bagong network sa mga virtualized na host, ganap na pumutok sa bubong ng mga tradisyunal na networker at ginagawa silang kumapit sa mga pamilyar na diskarte. Dapat tandaan na sinubukan ng Cisco na patamisin ng kaunti ang tableta at nagdagdag ng "tulad ng NXOS" na CLI sa controller, na nagpapahintulot sa iyo na gawin ang pagsasaayos mula sa isang interface na katulad ng mga tradisyonal na switch. Ngunit gayon pa man, upang simulan ang paggamit ng ACI nang normal, kailangan mong maunawaan kung paano ito gumagana.
Sa mga tuntunin ng presyo, sa malaki at katamtamang mga antas, ang mga network ng ACI ay hindi aktwal na naiiba mula sa mga tradisyonal na network sa mga kagamitan sa Cisco, dahil ang parehong mga switch ay ginagamit upang itayo ang mga ito (Ang Nexus 9000 ay maaaring gumana sa ACI at sa tradisyonal na mode at ngayon ay naging pangunahing "workhorse" para sa mga bagong proyekto ng data center). Ngunit para sa mga sentro ng data ng dalawang switch, ang pagkakaroon ng mga controller at arkitektura ng Spine-Leaf, siyempre, ay nagpaparamdam sa kanilang sarili. Kamakailan, lumitaw ang isang pabrika ng Mini ACI, kung saan ang dalawa sa tatlong controller ay pinalitan ng mga virtual machine. Binabawasan nito ang pagkakaiba sa gastos, ngunit nananatili pa rin ito. Kaya para sa customer, ang pagpili ay idinidikta ng kung gaano siya interesado sa mga tampok ng seguridad, pagsasama sa virtualization, isang solong punto ng kontrol, at iba pa.
Pinagmulan: www.habr.com