Cisco ACI өгөгдлийн төвийн сүлжээний даавуу - администраторт туслах

Cisco ACI өгөгдлийн төвийн сүлжээний даавуу - администраторт туслах
Cisco ACI скриптийн энэхүү ид шидийн тусламжтайгаар та сүлжээгээ хурдан тохируулах боломжтой.

Cisco ACI дата төвийн сүлжээний үйлдвэр таван жилийн турш оршин тогтнож байгаа боловч Хабре энэ талаар юу ч хэлээгүй тул би үүнийг бага зэрэг засахаар шийдсэн. Энэ нь юу болох, ямар хэрэгцээтэй, хаана тармууртай болохыг би өөрийн туршлагаас хэлье.

Энэ юу вэ, хаанаас ирсэн бэ?

2013 онд ACI (Application Centric Infrastructure) зарлах үед өрсөлдөгчид нэгэн зэрэг гурван талаас дата төвийн сүлжээн дэх уламжлалт арга барилаар урагшилж байв.

Нэг талаас, OpenFlow дээр суурилсан "эхний үеийн" SDN шийдлүүд нь сүлжээг илүү уян хатан, нэгэн зэрэг хямд болгоно гэж амласан. Энэхүү санаа нь шийдвэр гаргах ажлыг уламжлалт байдлаар өмчийн шилжүүлэгч програм хангамжаар төв хянагч руу шилжүүлэх явдал байв.

Энэхүү хянагч нь болж буй бүх зүйлийн талаар нэг алсын хараатай байх бөгөөд үүний үндсэн дээр бүх шилжүүлэгчийн техник хангамжийг тодорхой урсгалыг боловсруулах дүрмийн түвшинд програмчлах болно.
Нөгөөтэйгүүр, давхардсан сүлжээний шийдлүүд нь виртуалчлагдсан хостуудын хооронд програм хангамжийн хонгил байгуулах, физик сүлжээнд ямар ч өөрчлөлт оруулахгүйгээр шаардлагатай холболт, аюулгүй байдлын бодлогыг хэрэгжүүлэх боломжийг олгосон. Энэ аргын хамгийн алдартай жишээ бол Ницира байсан бөгөөд тэр үед VMWare 1,26 тэрбум доллараар худалдаж авсан бөгөөд одоогийн VMWare NSX-ийг бий болгосон. Ницирагийн үүсгэн байгуулагчид өмнө нь OpenFlow-ийн гарал үүслийг барьж байсан хүмүүс байсан бөгөөд одоо дата төвийн үйлдвэр барихын тулд гэж хэлж байсан нь нөхцөл байдлын зарим нэг таагүй байдлыг нэмэв. 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 цуврал унтраалгад ашигладаг байсан. Nexus 9000-ийн гэр бүлд ACI-ийг дэмжих зорилгоор тусгайлан гаргасан эрлийз загварыг анх хэрэгжүүлсэн бөгөөд үүнийг Merchant + гэж нэрлэдэг байв. Шилжүүлэгч нь шинэ Broadcom Trident 2 чип болон ACI-ийн бүх ид шидийг хэрэгжүүлдэг Cisco-ийн боловсруулсан нэмэлт чипийг нэгэн зэрэг ашигласан. Энэ нь бүтээгдэхүүний гаралтыг хурдасгаж, шилжүүлэгчийн үнийг Trident 2 дээр суурилсан загвартай ойролцоо түвшинд хүртэл бууруулах боломжийг олгосон бололтой. Энэ арга нь ACI хүргэлтийн эхний хоёр, гурван жилд хангалттай байсан. Энэ хугацаанд Cisco дараагийн үеийн Nexus 9000-ийг илүү гүйцэтгэл, онцлог шинж чанартай, гэхдээ ижил үнийн түвшинд өөрийн чипүүдээр бүтээж, худалдаанд гаргасан. Үйлдвэрийн харилцан үйлчлэлийн хувьд гадаад техникийн үзүүлэлтүүд бүрэн хадгалагдсан байдаг. Үүний зэрэгцээ дотоод дүүргэлт нь бүрэн өөрчлөгдсөн: рефакторинг гэх мэт зүйл, гэхдээ техник хангамжийн хувьд.

Cisco ACI Архитектур хэрхэн ажилладаг

Хамгийн энгийн тохиолдолд ACI нь Klose сүлжээний топологи дээр суурилдаг, эсвэл тэдний хэлснээр Spine-Leaf. Нурууны түвшний унтраалга нь хоёроос (эсвэл алдааг тэсвэрлэх чадваргүй бол нэгээс) зургаа хүртэл байж болно. Үүний дагуу тэдгээр нь олон байх тусам эвдрэлийг тэсвэрлэх чадвар өндөр байх болно (нэг нурууны ослын үед эсвэл нэг нурууны засвар үйлчилгээ хийх тохиолдолд зурвасын өргөн, найдвартай байдал багасах тусам) болон нийт гүйцэтгэл өндөр байна. Бүх гадаад холболтууд нь навчны түвшний унтраалга руу ордог: эдгээр нь серверүүд бөгөөд L2 эсвэл L3-ээр дамжуулан гадаад сүлжээнд залгах, APIC хянагчдыг холбох явдал юм. Ерөнхийдөө ACI-ийн тусламжтайгаар зөвхөн тохиргоо төдийгүй статистик цуглуулах, алдааны хяналт гэх мэт бүх зүйлийг хянагчийн интерфэйсээр хийдэг бөгөөд үүнээс гурван стандарт хэмжээтэй хэрэгжүүлэлт байдаг.

Сүлжээг эхлүүлэхийн тулд та консолтой унтраалгатай хэзээ ч холбогдох шаардлагагүй: хянагч өөрөө унтраалгауудыг илрүүлж, тэдгээрээс үйлдвэрийг угсардаг, үүнд үйлчилгээний бүх протоколуудын тохиргоог оруулдаг тул дашрамд хэлэхэд, энэ нь маш чухал юм. Суулгах явцад суулгаж буй тоног төхөөрөмжийн серийн дугаарыг бичээрэй, ингэснээр дараа нь аль унтраалга аль тавиур дээр байгааг тааварлах шаардлагагүй болно. Асуудлыг олж засварлахын тулд шаардлагатай бол SSH-ээр дамжуулан унтраалгатай холбогдож болно: тэд Cisco шоуны ердийн командуудыг маш болгоомжтой хуулбарладаг.

Дотооддоо үйлдвэр нь IP тээвэрлэлтийг ашигладаг тул ямар ч Spanning Tree болон өнгөрсөн үеийн бусад аймшигт зүйл байхгүй: бүх холбоосууд оролцдог бөгөөд эвдэрсэн тохиолдолд нэгдэх нь маш хурдан байдаг. Даавууны урсгалыг VXLAN дээр суурилсан хонгилоор дамжуулдаг. Илүү нарийн яривал, Cisco өөрөө iVXLAN-ийн капсулжуулалт гэж нэрлэдэг бөгөөд энэ нь сүлжээний толгой хэсэгт нөөцлөгдсөн талбарууд нь үйлчилгээний мэдээллийг дамжуулахад, ялангуяа EPG бүлэгт чиглэсэн урсгалын харилцааны талаар ашиглагддагаараа ердийн VXLAN-аас ялгаатай. Энэ нь энгийн хандалтын жагсаалтад хаягийг ашигладагтай адил дугаарыг ашиглан тоног төхөөрөмж дэх бүлгүүдийн хоорондын харилцан үйлчлэлийн дүрмийг хэрэгжүүлэх боломжийг танд олгоно.

Хонгилууд нь L2 сегмент ба L3 сегментийг (жишээ нь VRF) дотоод IP дамжуулалтаар сунгах боломжийг олгодог. Энэ тохиолдолд анхдагч гарцыг тараана. Энэ нь шилжүүлэгч бүр даавуунд орж буй урсгалыг чиглүүлэх үүрэгтэй гэсэн үг юм. Замын хөдөлгөөний логикийн хувьд ACI нь VXLAN/EVPN даавуутай төстэй.

Хэрэв тийм бол ялгаа нь юу вэ? Бусад бүх зүйл!

Таны ACI-д тулгардаг нэг номерын ялгаа нь серверүүд сүлжээнд хэрхэн холбогдож байгаа явдал юм. Уламжлалт сүлжээнд физик серверүүд болон виртуал машинуудын аль алиныг нь оруулах нь VLAN-д ордог бөгөөд холболт, аюулгүй байдал гэх мэт бусад бүх зүйл тэдгээрээс бүрддэг. ACI-д Cisco EPG (Төгсгөлийн цэгийн бүлэг) гэж нэрлэдэг загварыг ашигладаг. холдох газар байхгүй. Үүнийг VLAN-тай адилтгах боломжтой юу? Тийм ээ, гэхдээ энэ тохиолдолд ACI-ийн ихэнхийг алдах боломж бий.

EPG-ийн хувьд бүх хандалтын дүрмийг боловсруулсан бөгөөд ACI-д "цагаан жагсаалт" зарчмыг анхдагч байдлаар ашигладаг, өөрөөр хэлбэл зөвхөн замын хөдөлгөөнийг зөвшөөрдөг бөгөөд үүнийг нэвтрүүлэхийг тодорхой зөвшөөрдөг. Өөрөөр хэлбэл, бид "Вэб" болон "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, гэхдээ энэ нь бодлого, мониторингийн аль алинд нь хамаатай бөгөөд өөрөөр хэлбэл сүлжээний администратор аль хостууд дээр ажиллаж байгааг шууд харах боломжтой. тэд ямар бүлэгт багтдаг.

Виртуал серверүүд нь тодорхой порт бүлэгт багтахаас гадна нэмэлт шинж чанартай байдаг: нэр, шинж чанарууд гэх мэт, тэдгээрийг өөр бүлэгт шилжүүлэх шалгуур болгон ашиглаж болно, жишээ нь VM-ийн нэрийг өөрчлөх эсвэл нэмэлт шошго гарч ирэх үед. тэр. Cisco үүнийг микро сегментчилсэн бүлгүүд гэж нэрлэдэг боловч ерөнхийдөө нэг дэд сүлжээнд EPG хэлбэрээр олон хамгаалалтын сегментийг үүсгэх чадвартай загвар нь өөрөө бас нэлээд микро сегментчилэл юм. За, худалдагч нь илүү сайн мэддэг.

EPG нь өөрөө цэвэр логик бүтэц бөгөөд тодорхой унтраалга, сервер гэх мэтээр холбогддоггүй тул та тэдгээрт тулгуурлан клон хийх гэх мэт энгийн сүлжээнд хийхэд хэцүү (програмууд болон түрээслэгчид) ямар нэгэн зүйл хийж болно. Үүний үр дүнд үйлдвэрлэлийн орчинтой ижил байх баталгаатай туршилтын орчинг авахын тулд үйлдвэрлэлийн орчныг хувилах нь маш хялбар гэж бодъё. Та үүнийг гараар хийж болно, гэхдээ энэ нь API-ээр дамжуулан илүү сайн (мөн хялбар) юм.

Ерөнхийдөө ACI дахь хяналтын логик нь таны ихэвчлэн тааралддагтай огтхон ч төстэй биш юм
ижил Cisco-ийн уламжлалт сүлжээнд: програм хангамжийн интерфейс нь үндсэн, GUI эсвэл CLI нь нэг API-ээр ажилладаг тул хоёрдогч байдаг. Тиймээс, ACI-д хамрагдсан бараг бүх хүмүүс хэсэг хугацааны дараа менежментэд ашигладаг объектын загварт шилжиж, өөрсдийн хэрэгцээнд нийцүүлэн ямар нэг зүйлийг автоматжуулж эхэлдэг. Үүнийг хийх хамгийн хялбар арга бол Python юм: үүнд тохиромжтой бэлэн хэрэгслүүд байдаг.

Амласан тармуур

Хамгийн гол асуудал бол ACI-д олон зүйл өөрөөр хийгдсэн байдаг. Түүнтэй хэвийн ажиллаж эхлэхийн тулд та дахин сургах хэрэгтэй. Энэ нь ялангуяа инженерүүд хүсэлтийн дагуу олон жилийн турш "VLAN-г зааж өгсөн" томоохон хэрэглэгчдийн сүлжээний үйл ажиллагааны багуудад үнэн юм. Одоо VLAN-ууд VLAN байхаа больж, виртуалчлагдсан хостууд руу шинэ сүлжээ байрлуулахын тулд гараар VLAN үүсгэх шаардлагагүй болсон нь уламжлалт сүлжээчдийн дээврийг бүрмөсөн устгаж, тэднийг танил арга барилтай зууралдахад хүргэдэг. Cisco нь эмийг бага зэрэг чихэрлэг болгохыг оролдсон бөгөөд хянагчдаа уламжлалт унтраалгатай төстэй интерфейсээс тохиргоо хийх боломжийг олгодог "NXOS-тэй төстэй" CLI-г нэмсэн гэдгийг тэмдэглэх нь зүйтэй. Гэсэн хэдий ч ACI-г хэвийн ашиглаж эхлэхийн тулд энэ нь хэрхэн ажилладагийг ойлгох хэрэгтэй.

Үнийн хувьд том ба дунд хэмжээний хувьд ACI сүлжээнүүд нь Cisco төхөөрөмж дээрх уламжлалт сүлжээнүүдээс ялгаатай биш, учир нь тэдгээрийг бүтээхэд ижил унтраалга ашигладаг (Nexus 9000 нь ACI болон уламжлалт горимд ажиллах боломжтой бөгөөд одоо үндсэн сүлжээ болжээ. дата төвийн шинэ төслүүдэд зориулсан "ажлын морь"). Гэхдээ хоёр шилжүүлэгчийн мэдээллийн төвүүдийн хувьд хянагч, нурууны навчны архитектур байгаа нь мэдээжийн хэрэг өөрсдийгөө мэдэрдэг. Саяхан Mini ACI үйлдвэр гарч ирсэн бөгөөд гурван хянагчийн хоёрыг виртуал машинаар сольсон. Энэ нь зардлын зөрүүг багасгадаг ч энэ нь хэвээр байна. Тиймээс хэрэглэгчийн хувьд сонголт нь хамгаалалтын функц, виртуалчлалтай нэгтгэх, нэг хяналтын цэг гэх мэтийг хэр их сонирхож байгаагаас шалтгаална.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх