Cisco ACI скриптинин бул сыйкырдуу бөлүгүнүн жардамы менен сиз тармакты тез орното аласыз.
Cisco ACI маалымат борбору үчүн тармактык кездеме беш жылдан бери бар, бирок Habréде бул жөнүндө эч нерсе айтылган эмес, ошондуктан мен аны бир аз оңдоону чечтим. Мен өз тажрыйбамдан айтып берем, бул эмне, анын кандай пайдасы бар жана тырмоо кайда.
Бул эмне жана ал кайдан пайда болгон?
2013-жылы ACI (Application Centric Infrastructure) жарыяланган учурда, маалымат борборлоруна болгон салттуу ыкмаларга бир эле учурда үч тараптан атаандаштар кол салышкан.
Бир жагынан алганда, OpenFlow негизиндеги "биринчи муун" SDN чечимдери тармактарды ийкемдүү жана ошол эле учурда арзандатууну убада кылган. Идея, адатта, проприетардык коммутатор программалык камсыздоосу тарабынан башкарылуучу чечимдерди кабыл алууну борбордук контроллерге алып келүү болгон.
Бул контролер болуп жаткан нерселердин бардыгына бирдиктүү көз карашка ээ болмок жана анын негизинде бардык өчүргүчтөрдүн жабдууларын белгилүү агымдарды иштетүү эрежелеринин деңгээлинде программалайт.
Башка жагынан алганда, капталган тармак чечимдери виртуалдаштырылган хосттордун ортосунда программалык туннелдерди куруп, физикалык тармакка эч кандай өзгөртүүлөрдү киргизбестен керектүү байланышты жана коопсуздук саясатын ишке ашырууга мүмкүндүк берди. Бул ыкманын эң белгилүү мисалы болуп Nicira компаниясынын чечими болгон, ал ошол убакта VMWare тарабынан 1,26 миллиард долларга сатылып алынган жана учурдагы VMWare NSX пайда болгон. Кырдаалды бир аз ачууланткан нерсе, Nicira компаниясынын тең негиздөөчүлөрү OpenFlowдун башында турган адамдар болгон, алар азыр маалымат борбору фабрикасын курууну айтышкан. .
Акыр-аягы, ачык рынокто жеткиликтүү коммутатор чиптери (эмне соода кремний деп аталат) салттуу коммутатор өндүрүүчүлөр үчүн реалдуу коркунуч болуп калган жетилүү деңгээлине жетти. Эгерде мурда ар бир сатуучу өзү өчүргүчтөрү үчүн чиптерди иштеп чыкса, анда убакыттын өтүшү менен үчүнчү тараптын өндүрүүчүлөрүнүн, биринчи кезекте Broadcom компаниясынын чиптери функциялары боюнча сатуучу чиптери менен аралыкты жакындай башташты жана алардан баа/өндүрүш катышы боюнча ашып кетти. Ошондуктан, көптөр проприетардык чиптерди өчүрүү күндөрү саналган деп эсептешкен.
ACI жогоруда айтылгандардын баарына Ciscoнун (тагыраак айтканда, анын курамына кирген Insieme компаниясынын мурдагы кызматкерлери тарабынан негизделген) "ассиметриялык жообу" болуп калды.
OpenFlow менен кандай айырма бар?
Функцияларды бөлүштүрүү жагынан ACI чындыгында OpenFlowга карама-каршы келет.
OpenFlow архитектурасында контроллер деталдуу эрежелерди (агымдарды) жазуу үчүн жооптуу.
бардык өчүргүчтөрдүн аппараттык жабдыктарында, башкача айтканда, чоң тармакта, ал тармактын жүздөгөн пункттарында он миллиондогон жазууларды сактоо жана эң негизгиси өзгөртүү үчүн жооптуу болушу мүмкүн, ошондуктан чоң жайылтууда анын иштеши жана ишенимдүүлүгү чоңоёт. тоскоолдук.
ACI карама-каршы ыкманы колдонот: албетте, контроллер бар, бирок которгучтар андан жогорку деңгээлдеги декларативдик саясаттарды алышат жана коммутатор өзү аларды аппараттык жабдыктагы конкреттүү орнотуулардын деталдарына келтирет. Контроллерди кайра жүктөсө же толугу менен өчүрсө болот жана тармакка жаман эч нерсе болбойт, албетте, азыркы учурда көзөмөлдүн жоктугу. Кызыктуусу, ACIде OpenFlow дагы эле колдонулуп жаткан, бирок Open vSwitch программалоо үчүн хосттун ичинде локалдуу түрдө колдонулган жагдайлар бар.
ACI толугу менен VXLAN негизиндеги кабатташуу транспортуна курулган, бирок ошондой эле бирдиктүү чечимдин бөлүгү катары негизги IP транспортун камтыйт. Cisco бул терминди "интегралдык катмар" деп атады. Көпчүлүк учурларда, кездемеден өчүргүчтөр ACIдеги катмарлар үчүн аяктоочу чекит катары колдонулат (алар муну шилтеме ылдамдыгы менен жасашат). Хосттардан кездеме, инкапсуляция ж.б.у.с. жөнүндө эч нерсе билиши талап кылынбайт, бирок кээ бир учурларда (айталы, OpenStack хостторун туташтыруу үчүн) аларга VXLAN трафиги жеткирилиши мүмкүн.
Катташуулар ACIде транспорт тармагы боюнча ийкемдүү байланышты камсыз кылуу үчүн гана эмес, мета-маалыматтарды берүү үчүн да колдонулат (мисалы, коопсуздук саясатын ишке ашыруу үчүн колдонулат).
Broadcom чиптери мурун Cisco тарабынан Nexus 3000 сериясындагы өчүргүчтөрүндө колдонулган. Которуу бир эле учурда жаңы Broadcom Trident 9000 чипти жана ACIдин бардык сыйкырын ишке ашырган Cisco тарабынан иштелип чыккан кошумча чипти колдонду. Кыязы, бул продуктунун чыгарылышын тездетүүгө жана алмаштыргычтын баасын Trident 2ге негизделген моделдерге жакын деңгээлге чейин төмөндөтүүгө мүмкүндүк берди. Бул ыкма ACI жеткирүүнүн алгачкы эки-үч жылы үчүн жетиштүү болду. Бул убакыттын ичинде, Cisco кийинки муундагы Nexus 2ди өзүнүн микросхемаларында жакшыраак аткаруу жана функциялар топтому менен, бирок ошол эле баа деңгээлинде иштеп чыгып, ишке киргизди. Заводдо ез ара аракеттенуу жагынан тышкы спецификациялар толук сакталган. Ошол эле учурда, ички толтуруу толугу менен өзгөрдү: рефакторинг сыяктуу бир нерсе, бирок аппараттык үчүн.
Cisco ACI архитектурасы кантип иштейт
Эң жөнөкөй учурда, ACI Clos тармагынын топологиясына ылайык курулган, же алар көп айткандай, Spine-Leaf. Омуртканын деңгээлиндеги өчүргүчтөр экиден (же бир, эгерде биз катага чыдамкайлыкка маани бербесек) алтыга чейин болушу мүмкүн. Ошого жараша, алар канчалык көп болсо, катага толеранттуулук ошончолук жогору болот (кырсык болгондо же бир Омуртканын тейлөөсүндө өткөрүү жөндөмдүүлүгү жана ишенимдүүлүгү азыраак төмөндөйт) жана жалпы көрсөткүч. Бардык тышкы туташуулар Жалбырак деңгээлиндеги которгучтарга өтөт: бул серверлер, L2 же L3 аркылуу тышкы тармактарга туташуу жана APIC контроллерлорунун туташуусу. Жалпысынан алганда, ACI менен конфигурация гана эмес, статистиканы чогултуу, каталарды көзөмөлдөө ж.б.у.с. - бардыгы контроллердин интерфейси аркылуу ишке ашырылат, алардын үчөө кадимки өлчөмдөгү ишке ашырууда бар.
Сиз эч качан консол менен өчүргүчтөргө туташтыруунун кереги жок, атүгүл тармакты баштоо үчүн: контроллер өзү өчүргүчтөрдү аныктайт жана алардан заводду, анын ичинде бардык тейлөө протоколдорунун орнотууларын чогултат Орнотуу учурунда орнотулган жабдуулардын сериялык номерлерин төмөндөтүңүз, кийинчерээк кайсы коммутатор кайсы стеллажда жайгашканын билбеш үчүн? Мүчүлүштүктөрдү жоюу үчүн, зарыл болсо, сиз SSH аркылуу которгучтарга туташа аласыз: кадимки Cisco шоу буйруктары аларда кылдаттык менен чыгарылат.
Ичинде завод IP транспортун колдонот, андыктан анда Spanning Tree же өткөндүн башка коркунучтары жок: бардык шилтемелер колдонулат жана бузулган учурда конвергенция абдан тез. Кездемедеги трафик VXLAN негизиндеги туннелдер аркылуу жүргүзүлөт. Тагыраак айтканда, Cisco өзү инкапсуляцияны iVXLAN деп атайт жана ал кадимки VXLANдан айырмаланып турат, бул тармактын аталышындагы резервдик талаалар кызматтык маалыматты, биринчи кезекте, трафиктин EPG тобуна болгон мамилеси жөнүндө өткөрүү үчүн колдонулат. Бул жабдууларда топтордун өз ара аракеттенүүсүнүн эрежелерин ишке ашырууга мүмкүндүк берет, алардын номерлерин кадимки кирүү тизмелеринде даректер колдонулгандай эле колдонуу.
Туннелдер L2 жана L3 сегменттерин (башкача айтканда, VRF) ички IP транспорту аркылуу узартууга мүмкүндүк берет. Бул учурда, демейки шлюз бөлүштүрүлөт. Бул ар бир коммутатор кездемеге кирген трафиктин маршруту үчүн жооптуу экенин билдирет. Трафик берүү логикасы боюнча, ACI VXLAN/EVPN негизиндеги кездемеге окшош.
Эгер ошондой болсо, анда кандай айырмачылыктар бар? Бардык башка!
ACIде сиз жолуккан биринчи айырма - бул серверлер тармакка кантип туташкандыгы. Салттуу тармактарда физикалык серверлердин да, виртуалдык машиналардын да кошулуусу VLANга кирет, калганынын баары алардан бийлейт: туташуу, коопсуздук ж.б. ACI Cisco EPG (End-point Group) деп атаган дизайнды колдонот. кетүү. Аны VLANга теңесе болобу? Ооба, бирок бул учурда ACI берген нерселердин көбүн жоготуп алуу мүмкүнчүлүгү бар.
Бардык кирүү эрежелери EPGге карата формулировкаланган жана ACIде демейки боюнча “ак тизме” принциби колдонулат, башкача айтканда трафикке гана уруксат берилет, анын өтүшүнө ачык уруксат берилет. Башкача айтканда, биз “Web” жана “MySQL” EPG топторун түзө алабыз жана алардын ортосундагы өз ара аракеттенүүгө 3306 портунда гана уруксат берген эрежени аныктай алабыз. Бул тармак даректерине байланбастан, жада калса ошол эле ички тармактын ичинде да иштейт!
Бизде ACIди дал ушул өзгөчөлүктөн улам тандап алган кардарлар бар, анткени ал серверлердин ортосундагы кирүүнү чектөөгө мүмкүндүк берет (виртуалдык же физикалык, бул маанилүү эмес), аларды субсеттердин ортосунда сүйрөп кетпестен, демек, дарекке таасир этпестен. Ооба, ооба, биз билебиз, эч ким IP даректерин колдонмо конфигурацияларында кол менен жазбайт, туурабы?
ACIде трафик агымынын эрежелери келишимдер деп аталат. Мындай келишимде көп баскычтуу тиркемедеги бир же бир нече топтор же катмарлар кызмат көрсөтүүчү (мисалы, маалымат базасы кызматы), ал эми калгандары керектөөчү болуп калышат. Келишим жөн гана трафиктин өтүшүнө уруксат бере алат же ал татаалыраак нерсени жасай алат, мисалы, аны брандмауэрге же жүк балансына багыттай алат же QoS маанисин өзгөртөт.
Бул топторго серверлер кантип кирет? Эгерде бул физикалык серверлер же биз VLAN магистралын түзгөн учурдагы тармакка кирген нерсе болсо, анда аларды EPGге жайгаштыруу үчүн биз коммутатор портун жана анда колдонулган VLANды көрсөтүшүбүз керек. Көрүнүп тургандай, VLANлар аларсыз иштей албаган жерлерде пайда болот.
Эгерде серверлер виртуалдык машиналар болсо, анда туташкан виртуалдаштыруу чөйрөсүнө кайрылуу жетиштүү, анан баары өзүнөн-өзү болот: VMлерди туташтыруу үчүн порт тобу түзүлөт (VMWare терминдеринде), керектүү VLAN же VXLAN түзүлөт. дайындалган, керектүү коммутатор портторунда катталган, ж.б.у.с. Ошентип, ACI физикалык тармактын айланасында курулганына карабастан, виртуалдык серверлердин туташуулары физикалык серверлерге караганда алда канча жөнөкөй көрүнөт. ACI мурунтан эле VMWare жана MS Hyper-V менен орнотулган байланышы бар, ошондой эле OpenStack жана RedHat Virtualization үчүн колдоо. Кайсы бир убакта контейнердик платформалар үчүн орнотулган колдоо пайда болду: Kubernetes, OpenShift, Cloud Foundry жана бул саясаттарды колдонууга да, мониторингге да тиешелүү, башкача айтканда, тармак администратору кайсы хосттордо кайсы поддержкалар иштеп жатканын дароо көрө алат. алар кайсы топторго кирет.
Белгилүү бир порт тобуна киргенден тышкары, виртуалдык серверлер кошумча касиеттерге ээ: аты, атрибуттары ж. . Cisco бул микро-сегментация топтору деп атайт, бирок жалпысынан алганда, дизайндын өзү эле бир эле подтармакта EPG түрүндөгү көптөгөн коопсуздук сегменттерин түзө алат. Ооба, сатуучу жакшы билет.
EPGs өзүлөрү так логикалык конструкциялар, алар конкреттүү өчүргүчтөр, серверлер ж. Натыйжада, айталы, өндүрүштүк чөйрөнүн клонун түзүү абдан оңой, ал өндүрүштүк чөйрөгө окшош экендигине кепилдик берилген сыноо чөйрөсүн алуу үчүн. Сиз аны кол менен кыла аласыз, бирок API аркылуу жакшыраак (жана жеңилирээк).
Жалпысынан алганда, ACI башкаруу логикасы сиз адаттагыдай эле окшош эмес
ошол эле Cisco компаниясынын салттуу тармактарында: программалык интерфейс негизги, ал эми GUI же CLI экинчилик, анткени алар бир эле API аркылуу иштешет. Ошондуктан, ACI менен иштеген дээрлик ар бир адам, бир аз убакыт өткөндөн кийин, башкаруу үчүн колдонулган объект моделин багыттоо жана алардын муктаждыктарына ылайык бир нерсени автоматташтыруу башталат. Муну жасоонун эң оңой жолу Python'дон: ал үчүн ыңгайлуу даяр куралдар бар.
Убадаланган тырмоо
Негизги маселе - ACIде көп нерселер башкача жасалат. Аны менен кадимкидей иштей баштоо үчүн, кайра үйрөнүшүңүз керек. Бул, айрыкча, инженерлер көп жылдар бою суроо-талаптарга ылайык "VLAN жазып" келген ири кардарлардын тармактык операциялар топторуна тиешелүү. Азыр VLAN VLAN болбой калгандыгы жана виртуалдаштырылган хостторго жаңы тармактарды орнотуу үчүн VLANларды кол менен түзүүнүн кереги жок экендиги салттуу сетевиктердин аң-сезимин толугу менен талкалап, аларды кадимки ыкмаларга жабышууга мажбурлайт. Белгилей кетсек, Cisco таблетканы бир аз таттууга аракет кылып, контроллерге "NXOS сыяктуу" CLI кошту, бул салттуу которгучтарга окшош интерфейстен конфигурациялоого мүмкүндүк берет. Ошентсе да, ACIди кадимкидей колдонуп баштоо үчүн, анын кантип иштээрин түшүнүшүңүз керек.
Чоң жана орто масштабдагы баасы боюнча ACI тармактары Cisco жабдыктарындагы салттуу тармактардан дээрлик эч айырмаланбайт, анткени аларды куруу үчүн ошол эле өчүргүчтөр колдонулат (Nexus 9000 ACI да, салттуу режимде да иштей алат жана негизги "жумушчу" болуп калды. ” жаңы маалымат борборунун долбоорлору үчүн). Бирок эки өчүргүчтөн турган маалымат борборлору үчүн контроллерлордун жана Spine-Leaf архитектурасынын болушу, албетте, өзүн сезет. Жакында Mini ACI фабрикасы пайда болду, анда үч контроллердин экөө виртуалдык машиналар менен алмаштырылды. Бул наркынын айырмасын азайтат, бирок ал дагы эле бойдон калууда. Ошентип, кардар үчүн тандоо анын коопсуздук функцияларына, виртуалдаштыруу менен интеграцияга, башкаруунун бирдиктүү чекитине жана башкаларга канчалык кызыкдар экендигине байланыштуу.
Source: www.habr.com