Gyda chymorth y darn hudolus hwn o sgript Cisco ACI, gallwch chi sefydlu rhwydwaith yn gyflym.
Mae'r ffatri rhwydwaith ar gyfer canolfan ddata Cisco ACI wedi bodoli ers pum mlynedd, ond ni ddywedodd Habré unrhyw beth amdani mewn gwirionedd, felly penderfynais ei drwsio ychydig. Byddaf yn dweud wrthych o fy mhrofiad fy hun beth ydyw, beth yw'r defnydd ohono a lle mae rhaca.
Beth ydyw ac o ble y daeth?
Erbyn i ACI (Isadeiledd Sy'n Canolbwyntio ar y Cais) gael ei gyhoeddi yn 2013, roedd cystadleuwyr yn symud ymlaen ar ddulliau traddodiadol o ddefnyddio rhwydweithiau canolfannau data o dair ochr ar unwaith.
Ar y naill law, addawodd atebion SDN "cenhedlaeth gyntaf" yn seiliedig ar OpenFlow wneud rhwydweithiau'n fwy hyblyg ac yn rhatach ar yr un pryd. Y syniad oedd symud y penderfyniadau a wneir yn draddodiadol gan feddalwedd switsh perchnogol i reolwr canolog.
Byddai gan y rheolydd hwn un weledigaeth o bopeth sy'n digwydd ac, yn seiliedig ar hyn, byddai'n rhaglennu caledwedd pob switsh ar lefel y rheolau ar gyfer prosesu llifau penodol.
Ar y llaw arall, roedd atebion rhwydwaith troshaenu yn ei gwneud hi'n bosibl gweithredu'r polisïau cysylltedd a diogelwch angenrheidiol heb unrhyw newidiadau yn y rhwydwaith ffisegol o gwbl, gan adeiladu twneli meddalwedd rhwng gwesteiwyr rhithwir. Yr enghraifft fwyaf adnabyddus o'r dull hwn oedd Nicira, a oedd erbyn hynny eisoes wedi'i chaffael gan VMWare am $1,26 biliwn ac a arweiniodd at y VMWare NSX presennol. Ychwanegwyd rhywfaint o hynodrwydd y sefyllfa gan y ffaith mai cyd-sylfaenwyr Nicira oedd yr un bobl ag a safai o'r blaen ar wreiddiau OpenFlow, sydd bellach yn dweud hynny er mwyn adeiladu ffatri canolfan ddata. .
Ac yn olaf, mae newid sglodion sydd ar gael ar y farchnad agored (yr hyn a elwir yn silicon masnachwr) wedi cyrraedd cyfnod aeddfedrwydd lle maent wedi dod yn fygythiad gwirioneddol i weithgynhyrchwyr switsh traddodiadol. Os yn gynharach y datblygodd pob gwerthwr sglodion yn annibynnol ar gyfer ei switshis, yna dros amser, dechreuodd sglodion gan weithgynhyrchwyr trydydd parti, yn bennaf o Broadcom, leihau'r pellter gyda sglodion gwerthwr o ran swyddogaethau, a'u rhagori o ran cymhareb pris / perfformiad. Felly, roedd llawer yn credu bod dyddiau switshis ar sglodion o'u dyluniad eu hunain wedi'u rhifo.
Mae ACI wedi dod yn "ymateb anghymesur" Cisco (yn fwy manwl gywir, ei gwmni Insieme, a sefydlwyd gan ei gyn-weithwyr) i bob un o'r uchod.
Beth yw'r gwahaniaeth gydag OpenFlow?
O ran dosbarthiad swyddogaethau, mae ACI mewn gwirionedd i'r gwrthwyneb i OpenFlow.
Ym mhensaernïaeth OpenFlow, mae'r rheolwr yn gyfrifol am ysgrifennu rheolau manwl (llifoedd)
yng nghaledwedd pob switshis, hynny yw, mewn rhwydwaith mawr, gall fod yn gyfrifol am gynnal ac, yn bwysicaf oll, am newid degau o filiynau o gofnodion ar gannoedd o bwyntiau yn y rhwydwaith, felly mae ei berfformiad a'i ddibynadwyedd yn dod yn dagfa mewn a gweithrediad mawr.
Mae ACI yn defnyddio'r dull gwrthdroi: wrth gwrs, mae yna reolwr hefyd, ond mae'r switshis yn derbyn polisïau datganiadol lefel uchel ohono, ac mae'r switsh ei hun yn perfformio eu rendro i fanylion gosodiadau penodol yn y caledwedd. Gellir ailgychwyn neu ddiffodd y rheolydd yn gyfan gwbl, ac ni fydd unrhyw beth drwg yn digwydd i'r rhwydwaith, ac eithrio, wrth gwrs, y diffyg rheolaeth ar hyn o bryd. Yn ddiddorol, mae yna sefyllfaoedd yn ACI lle mae OpenFlow yn dal i gael ei ddefnyddio, ond yn lleol o fewn y gwesteiwr ar gyfer rhaglennu Open vSwitch.
Mae ACI wedi'i adeiladu'n gyfan gwbl ar gludiant troshaen sy'n seiliedig ar VXLAN, ond mae'n cynnwys y cludiant IP sylfaenol fel rhan o un datrysiad. Galwodd Cisco hwn yn derm “troshaen integredig”. Fel pwynt terfynu ar gyfer troshaenau yn ACI, yn y rhan fwyaf o achosion, defnyddir switshis ffatri (maen nhw'n gwneud hyn ar gyflymder cyswllt). Nid yw'n ofynnol i westeion wybod unrhyw beth am y ffatri, amgáu, ac ati, fodd bynnag, mewn rhai achosion (er enghraifft, i gysylltu gwesteiwyr OpenStack), gellir dod â thraffig VXLAN atynt.
Defnyddir troshaenau yn ACI nid yn unig i ddarparu cysylltedd hyblyg trwy'r rhwydwaith trafnidiaeth, ond hefyd i drosglwyddo metainformation (fe'i defnyddir, er enghraifft, i gymhwyso polisïau diogelwch).
Defnyddiwyd sglodion o Broadcom yn flaenorol gan Cisco yn y switshis cyfres Nexus 3000. Yn y teulu Nexus 9000, a ryddhawyd yn arbennig i gefnogi ACI, gweithredwyd model hybrid yn wreiddiol, a elwir yn Merchant +. Ar yr un pryd, defnyddiodd y switsh y sglodyn Broadcom Trident 2 newydd a sglodyn cyflenwol a ddatblygwyd gan Cisco, sy'n gweithredu holl hud ACI. Yn ôl pob tebyg, roedd hyn yn ei gwneud hi'n bosibl cyflymu'r broses o ryddhau'r cynnyrch a lleihau tag pris y switsh i lefel sy'n agos at fodelau sy'n seiliedig yn syml ar Trident 2. Roedd y dull hwn yn ddigon ar gyfer dwy neu dair blynedd gyntaf danfoniadau ACI. Yn ystod y cyfnod hwn, mae Cisco wedi datblygu a lansio'r genhedlaeth nesaf Nexus 9000 ar ei sglodion ei hun gyda mwy o berfformiad a set nodwedd, ond ar yr un lefel pris. Mae manylebau allanol o ran rhyngweithio yn y ffatri yn cael eu cadw'n llwyr. Ar yr un pryd, mae'r llenwad mewnol wedi newid yn llwyr: rhywbeth fel ailffactorio, ond ar gyfer haearn.
Sut mae Pensaernïaeth Cisco ACI yn Gweithio
Yn yr achos symlaf, mae ACI wedi'i adeiladu ar dopoleg rhwydwaith Klose, neu, fel y maent yn ei ddweud yn aml, Spine-Leaf. Gall switshis lefel asgwrn cefn fod o ddau (neu un, os nad ydym yn poeni am oddefgarwch bai) i chwech. Yn unol â hynny, po fwyaf ohonynt, yr uchaf yw'r goddefgarwch bai (po isaf yw'r lled band a gostyngiad dibynadwyedd rhag ofn damwain neu gynnal a chadw un asgwrn cefn) a'r perfformiad cyffredinol. Mae pob cysylltiad allanol yn mynd i switshis lefel dail: mae'r rhain yn weinyddion, ac yn tocio â rhwydweithiau allanol trwy L2 neu L3, ac yn cysylltu rheolwyr APIC. Yn gyffredinol, gydag ACI, nid yn unig cyfluniad, ond hefyd casglu ystadegau, monitro methiant, ac yn y blaen - mae popeth yn cael ei wneud trwy ryngwyneb rheolwyr, y mae tri ohonynt mewn gweithrediadau maint safonol.
Nid oes raid i chi byth gysylltu â'r switshis gyda'r consol, hyd yn oed i gychwyn y rhwydwaith: mae'r rheolydd ei hun yn canfod y switshis ac yn cydosod ffatri oddi wrthynt, gan gynnwys gosodiadau'r holl brotocolau gwasanaeth, felly, gyda llaw, mae'n bwysig iawn i ysgrifennwch rifau cyfresol yr offer sy'n cael eu gosod yn ystod y gosodiad, fel na fydd yn rhaid i chi yn ddiweddarach ddyfalu pa switsh sydd ym mha rac sydd wedi'i leoli. Ar gyfer datrys problemau, os oes angen, gallwch gysylltu â'r switshis trwy SSH: maent yn atgynhyrchu'r gorchmynion sioe Cisco arferol yn eithaf gofalus.
Yn fewnol, mae'r ffatri'n defnyddio cludiant IP, felly nid oes Spanning Tree ac erchyllterau eraill y gorffennol ynddo: mae pob cysylltiad yn gysylltiedig, ac mae cydgyfeirio rhag ofn methiannau yn gyflym iawn. Mae'r traffig yn y ffabrig yn cael ei drosglwyddo trwy dwneli yn seiliedig ar VXLAN. Yn fwy manwl gywir, mae Cisco ei hun yn galw amgapsiwleiddio iVXLAN, ac mae'n wahanol i VXLAN arferol gan fod y meysydd neilltuedig ym mhennyn y rhwydwaith yn cael eu defnyddio i drosglwyddo gwybodaeth gwasanaeth, yn bennaf am berthynas traffig â'r grŵp EPG. Mae hyn yn caniatáu ichi weithredu rheolau rhyngweithio rhwng grwpiau yn yr offer, gan ddefnyddio eu rhifau yn yr un modd ag y defnyddir cyfeiriadau mewn rhestrau mynediad arferol.
Mae twneli yn caniatáu ymestyn segmentau L2 a segmentau L3 (h.y. VRF) trwy'r cludiant IP mewnol. Yn yr achos hwn, dosberthir y porth rhagosodedig. Mae hyn yn golygu bod pob switsh yn gyfrifol am lwybro'r traffig sy'n mynd i mewn i'r ffabrig. O ran rhesymeg llif traffig, mae ACI yn debyg i ffabrig VXLAN/EVPN.
Os felly, beth yw'r gwahaniaethau? Popeth arall!
Y prif wahaniaeth rydych chi'n dod ar ei draws ag ACI yw sut mae gweinyddwyr wedi'u cysylltu â'r rhwydwaith. Mewn rhwydweithiau traddodiadol, mae cynnwys gweinyddwyr corfforol a pheiriannau rhithwir yn mynd i VLANs, ac mae popeth arall yn dawnsio oddi wrthynt: cysylltedd, diogelwch, ac ati. Yn ACI, defnyddir dyluniad y mae Cisco yn ei alw'n EPG (End-point Group), ac o hynny nid oes unman i ffwrdd. A yw'n bosibl ei gyfateb i VLAN? Oes, ond yn yr achos hwn mae cyfle i golli'r rhan fwyaf o'r hyn y mae ACI yn ei roi.
O ran EPG, mae'r holl reolau mynediad yn cael eu llunio, ac yn ACI, defnyddir yr egwyddor “rhestr wen” yn ddiofyn, hynny yw, dim ond traffig a ganiateir, y caniateir ei basio yn benodol. Hynny yw, gallwn greu'r grwpiau EPG "We" a "MySQL" a diffinio rheol sy'n caniatáu cyfathrebu rhyngddynt yn unig ar borthladd 3306. Bydd hyn yn gweithio heb gael ei glymu i gyfeiriadau rhwydwaith a hyd yn oed o fewn yr un isrwyd!
Mae gennym gwsmeriaid sydd wedi dewis ACI yn union oherwydd y nodwedd hon, gan ei fod yn caniatáu ichi gyfyngu mynediad rhwng gweinyddwyr (rhithwir neu gorfforol - nid oes ots) heb eu llusgo rhwng is-rwydweithiau, sy'n golygu heb gyffwrdd â'r cyfeiriad. Ydym, ie, rydym yn gwybod nad oes neb yn rhagnodi cyfeiriadau IP mewn ffurfweddiadau cais â llaw, dde?
Gelwir rheolau traffig yn ACI yn gontractau. Mewn contract o'r fath, mae un neu fwy o grwpiau neu lefelau mewn cymhwysiad aml-haen yn dod yn ddarparwr gwasanaeth (dyweder, gwasanaeth cronfa ddata), mae eraill yn dod yn ddefnyddiwr. Yn syml, gall y contract basio traffig, neu gall wneud rhywbeth mwy anodd, er enghraifft, ei gyfeirio at wal dân neu gydbwysedd, a hefyd newid y gwerth QoS.
Sut mae gweinyddwyr yn ymuno â'r grwpiau hyn? Os yw'r rhain yn weinyddion ffisegol neu'n rhywbeth sydd wedi'i gynnwys mewn rhwydwaith sy'n bodoli eisoes y gwnaethom greu boncyff VLAN ynddo, yna er mwyn eu gosod yn yr EPG, bydd angen i chi bwyntio at y porthladd switsh a'r VLAN a ddefnyddir arno. Fel y gallwch weld, mae VLANs yn ymddangos lle na allwch wneud hebddynt.
Os yw'r gweinyddwyr yn beiriannau rhithwir, yna mae'n ddigon cyfeirio at yr amgylchedd rhithwiroli cysylltiedig, ac yna bydd popeth yn digwydd ar ei ben ei hun: bydd grŵp porthladd yn cael ei greu (o ran VMWare) i gysylltu'r VM, bydd y VLANs neu VXLANs angenrheidiol yn cael eu neilltuo, byddant yn cael eu cofrestru ar y porthladdoedd switsh angenrheidiol, ac ati Felly, er bod ACI wedi'i adeiladu o amgylch rhwydwaith ffisegol, mae cysylltiadau ar gyfer gweinyddwyr rhithwir yn edrych yn llawer symlach nag ar gyfer rhai ffisegol. Mae gan ACI gysylltedd adeiledig eisoes â VMWare ac MS Hyper-V, yn ogystal â chefnogaeth ar gyfer Rhithwiroli OpenStack a RedHat. O ryw bwynt ymlaen, mae cefnogaeth adeiledig ar gyfer llwyfannau cynwysyddion hefyd wedi ymddangos: Kubernetes, OpenShift, Cloud Foundry, er ei fod yn ymwneud â chymhwyso polisïau a monitro, hynny yw, gall gweinyddwr y rhwydwaith weld ar unwaith pa westeion pa godennau sy'n gweithio arnynt a pa grwpiau y maent yn perthyn iddynt.
Yn ogystal â chael eu cynnwys mewn grŵp porthladd penodol, mae gan weinyddion rhithwir briodweddau ychwanegol: enw, priodoleddau, ac ati, y gellir eu defnyddio fel meini prawf ar gyfer eu trosglwyddo i grŵp arall, dyweder, pan fydd VM yn cael ei ailenwi neu pan fydd tag ychwanegol yn ymddangos yn mae'n. Mae Cisco yn galw hyn yn grwpiau micro-segmentu, er, ar y cyfan, mae'r dyluniad ei hun gyda'r gallu i greu llawer o segmentau diogelwch ar ffurf EPGs ar yr un isrwyd hefyd yn eithaf micro-segmentiad. Wel, mae'r gwerthwr yn gwybod yn well.
Mae EPGs eu hunain yn luniadau cwbl resymegol, heb eu cysylltu â switshis penodol, gweinyddwyr, ac ati, felly gallwch chi wneud pethau gyda nhw a lluniadau yn seiliedig arnynt (ceisiadau a thenantiaid) sy'n anodd eu gwneud mewn rhwydweithiau cyffredin, megis clonio. O ganlyniad, gadewch i ni ddweud ei bod hi'n hawdd iawn clonio amgylchedd cynhyrchu er mwyn cael amgylchedd prawf sy'n sicr o fod yn union yr un fath â'r amgylchedd cynhyrchu. Gallwch chi ei wneud â llaw, ond mae'n well (ac yn haws) trwy'r API.
Yn gyffredinol, nid yw'r rhesymeg reoli yn ACI yn debyg o gwbl i'r hyn rydych chi'n ei gyfarfod fel arfer
mewn rhwydweithiau traddodiadol o'r un Cisco: mae'r rhyngwyneb meddalwedd yn gynradd, ac mae'r GUI neu'r CLI yn eilaidd, gan eu bod yn gweithio trwy'r un API. Felly, mae bron pawb sy'n ymwneud ag ACI, ar ôl ychydig, yn dechrau llywio'r model gwrthrych a ddefnyddir ar gyfer rheoli ac awtomeiddio rhywbeth i gyd-fynd â'u hanghenion. Y ffordd hawsaf o wneud hyn yw Python: mae yna offer parod cyfleus ar ei gyfer.
Addewid rhaca
Y brif broblem yw bod llawer o bethau yn ACI yn cael eu gwneud yn wahanol. I ddechrau gweithio gydag ef fel arfer, mae angen i chi ailhyfforddi. Mae hyn yn arbennig o wir ar gyfer timau gweithrediadau rhwydwaith mewn cwsmeriaid mawr, lle mae peirianwyr wedi bod yn “rhagnodi VLANs” ers blynyddoedd ar gais. Mae'r ffaith nad yw VLANs bellach yn VLANs, ac nid oes angen i chi greu VLANs â llaw i osod rhwydweithiau newydd yn westeion rhithwir, yn chwythu'r to oddi ar rwydwaithwyr traddodiadol yn llwyr ac yn gwneud iddynt lynu wrth ddulliau cyfarwydd. Dylid nodi bod Cisco wedi ceisio melysu'r bilsen ychydig ac ychwanegu CLI “tebyg i NXOS” at y rheolydd, sy'n eich galluogi i wneud cyfluniad o ryngwyneb tebyg i switshis traddodiadol. Ond o hyd, er mwyn dechrau defnyddio ACI fel arfer, mae'n rhaid i chi ddeall sut mae'n gweithio.
O ran pris, ar raddfeydd mawr a chanolig, nid yw rhwydweithiau ACI mewn gwirionedd yn wahanol i rwydweithiau traddodiadol ar offer Cisco, gan fod yr un switshis yn cael eu defnyddio i'w hadeiladu (gall Nexus 9000 weithio yn ACI ac yn y modd traddodiadol ac maent bellach yn brif un. "workhorse" ar gyfer prosiectau canolfan ddata newydd). Ond ar gyfer canolfannau data dau switshis, mae presenoldeb rheolwyr a phensaernïaeth Spine-Leaf, wrth gwrs, yn gwneud eu hunain yn teimlo. Yn ddiweddar, mae ffatri Mini ACI wedi ymddangos, lle mae peiriannau rhithwir yn disodli dau o'r tri rheolydd. Mae hyn yn lleihau'r gwahaniaeth mewn cost, ond mae'n parhau i fod. Felly ar gyfer y cwsmer, mae'r dewis yn dibynnu ar faint y mae ganddo ddiddordeb mewn nodweddion diogelwch, integreiddio â rhithwiroli, un pwynt rheoli, ac ati.
Ffynhonnell: hab.com