Эхний хоёр нийтлэлд би автоматжуулалтын асуудлыг хөндөж, түүний хүрээг тоймлон харуулсан бол хоёрдугаарт би үйлчилгээний тохиргоог автоматжуулах эхний арга болох сүлжээний виртуалчлал руу ухарсан.
Одоо физик сүлжээний диаграммыг зурах цаг болжээ.

Хэрэв та өгөгдлийн төвийн сүлжээг тохируулах талаар сайн мэдэхгүй байгаа бол би үүнийг эхлүүлэхийг зөвлөж байна тэдний тухай нийтлэлүүд.

Бүх асуудал:

• 0. ADSM. Тэг хэсэг. Төлөвлөлт
• 1. ADSM. Нэгдүгээр хэсэг (тэгээс хойшхи). Сүлжээний виртуалчлал
• 2. ADSM. Хоёрдугаар хэсэг. Сүлжээний дизайн

Энэ цувралд тайлбарласан дадлага нь ямар ч төрлийн сүлжээ, ямар ч хэмжээтэй, ямар ч төрлийн борлуулагчтай (үгүй) хамааралтай байх ёстой. Гэсэн хэдий ч эдгээр аргуудыг ашиглах бүх нийтийн жишээг тайлбарлах боломжгүй юм. Тиймээс би DC сүлжээний орчин үеийн архитектурт анхаарлаа хандуулах болно. Клозын үйлдвэр.
Бид MPLS L3VPN дээр DCI хийх болно.

Overlay сүлжээ нь хостоос физик сүлжээн дээр ажилладаг (энэ нь OpenStack-ийн VXLAN эсвэл гянт болдын даавуу эсвэл сүлжээнээс зөвхөн үндсэн IP холболт шаарддаг бусад зүйл байж болно).

Энэ тохиолдолд бид автоматжуулалтын харьцангуй энгийн хувилбарыг олж авдаг, учир нь бид ижил аргаар тохируулагдсан олон тоног төхөөрөмжтэй байдаг.

Бид вакуум дахь бөмбөрцөг DC-г сонгоно.

• Хаа сайгүй дизайны нэг хувилбар.
• Хоёр үйлдвэрлэгч хоёр сүлжээний онгоцыг бүрдүүлдэг.
• Нэг DC нь хоёр вандуйтай ижил төстэй.

Агуулга

• Физик топологи
• Чиглүүлэлт
• IP төлөвлөгөө
• Лаба
• дүгнэлт
• Ашигтай холбоосууд

Жишээлбэл, манай Үйлчилгээ үзүүлэгч LAN_DC-д гацсан лифтэнд амьд үлдэх талаар сургалтын видео бичлэг хийцгээе.

Мега хотуудад энэ нь маш их алдартай тул танд маш олон физик машин хэрэгтэй.

Эхлээд би сүлжээг өөрийн хүссэнээр ойролцоогоор тайлбарлах болно. Дараа нь би үүнийг лабораторид хялбарчлах болно.

Физик топологи

Байршил

LAN_DC нь 6 DC-тэй байх болно:

• Орос (RU):
  • Москва (msk)
  • Казань (kzn)

• Испани (SP):
  • Барселона (bcn)
  • Малага (млг)

• Хятад (CN):
  • Шанхай (ша)
  • Сиань (аль аль нь)

Дотор DC (Intra-DC)

Бүх DC нь Clos топологи дээр суурилсан ижил төрлийн дотоод холболтын сүлжээтэй байдаг.
Тэд ямар төрлийн Clos сүлжээнүүд вэ, яагаад тусдаа байдаг вэ? нийтлэл.

DC бүр машинтай 10 тавиуртай бөгөөд тэдгээрийг дугаарлана A, B, C Тиймээ.

Тавиур бүр 30 машинтай. Тэд биднийг сонирхохгүй.

Мөн тавиур бүрт бүх машин холбогдсон унтраалга байдаг - энэ бол Rack-ийн дээд шилжүүлэгч - ToR эсвэл өөрөөр хэлбэл Clos үйлдвэрийн хувьд бид үүнийг нэрлэх болно навч.

Үйлдвэрийн ерөнхий диаграмм.

Бид тэднийг дуудах болно XXX- навчYхаана XXX - DC гурван үсгийн товчлол, ба Y - серийн дугаар. Жишээлбэл, kzn-навч11.

Би нийтлэлдээ Навч ба ТоР гэсэн нэр томъёог синоним болгон ашиглахыг зөвшөөрнө. Гэсэн хэдий ч энэ нь тийм биш гэдгийг бид санаж байх ёстой.
ToR нь машинууд холбогдсон тавиур дээр суурилуулсан унтраалга юм.
Навч нь физик сүлжээн дэх төхөөрөмжийн үүрэг эсвэл Cloes топологийн хувьд нэгдүгээр түвшний шилжүүлэгч юм.
Энэ нь Навч != ToR.
Жишээлбэл, Leaf нь EndofRaw шилжүүлэгч байж болно.
Гэсэн хэдий ч энэ нийтлэлийн хүрээнд бид тэдгээрийг ижил утгатай гэж үзэх болно.

ToR шилжүүлэгч бүр нь дээд түвшний дөрвөн нэгтгэх унтраалгатай холбогдсон байна - Сээр нуруу. DC-д нэг өлгүүр нь Spines-д зориулагдсан. Бид үүнийг ижил төстэй нэрлэх болно: XXX- нурууY.

Ижил тавиур дээр MPLS бүхий DC - 2 чиглүүлэгчийн хооронд холболт хийх сүлжээний тоног төхөөрөмж байх болно. Гэхдээ ерөнхийдөө эдгээр нь ижил ТоР юм. Өөрөөр хэлбэл, нурууны шилжүүлэгчийн үүднээс авч үзвэл холбогдсон машинууд эсвэл DCI чиглүүлэгчтэй ердийн ToR нь огт хамаагүй - зүгээр л дамжуулдаг.

Ийм тусгай ТоР гэж нэрлэдэг Ирмэг навч. Бид тэднийг дуудах болно XXX- ирмэгY.

Энэ нь иймэрхүү харагдах болно.

Дээрх диаграммд би үнэндээ ирмэг ба навчийг ижил түвшинд байрлуулсан. Сонгодог гурван давхаргат сүлжээ Тэд бидэнд uplinking (тиймээс энэ нэр томъёо) нь uplinks гэж үзэхийг заасан. Эндээс харахад DCI "дээд холбоос" буцаж доошилдог бөгөөд энэ нь зарим хүмүүсийн хувьд ердийн логикийг бага зэрэг эвддэг. Том сүлжээнүүдийн хувьд дата төвийг бүр жижиг хэсгүүдэд хуваах үед - Pod‘s (Point Of Delivery), хувь хүнийг онцлон тэмдэглэ Ирмэг-POD‘s DCI болон гадаад сүлжээнд нэвтрэх.

Ирээдүйд ойлголтыг хөнгөвчлөхийн тулд би нурууны дээгүүр ирмэгийг зурсан хэвээр байх болно, гэхдээ бид нуруунд ямар ч оюун ухаан байхгүй, ердийн навч, ирмэгийн навчтай ажиллахад ямар ч ялгаа байхгүй гэдгийг санах болно (хэдийгээр энд нюансууд байж болно) , гэхдээ ерөнхийдөө энэ нь үнэн).

Ирмэг навчтай үйлдвэрийн схем.

Навч, Нуруу, Ирмэг гурвал нь Дотор сүлжээ буюу үйлдвэрийг бүрдүүлдэг.

Сүлжээний үйлдвэрийн даалгавар (Underlay-г уншина уу), бид аль хэдийн тодорхойлсон сүүлийн дугаар, маш, маш энгийн - нэг DC доторх машинуудын хооронд болон тэдгээрийн хооронд IP холболтыг хангах.
Ийм учраас сүлжээг үйлдвэр гэж нэрлэдэг бөгөөд жишээ нь модульчлагдсан сүлжээний хайрцаг доторх сэлгэн залгах үйлдвэртэй адил бөгөөд та энэ талаар дэлгэрэнгүй унших боломжтой. SDSM14.

Ерөнхийдөө ийм топологийг үйлдвэр гэж нэрлэдэг, учир нь орчуулгад даавуу нь даавуу гэсэн үг юм. Мөн санал нийлэхгүй байх хэцүү:

Үйлдвэр нь бүрэн L3 юм. VLAN байхгүй, өргөн нэвтрүүлэг байхгүй - бидэнд LAN_DC дээр ийм гайхалтай програмистууд байдаг, тэд L3 парадигмд амьдардаг програмуудыг хэрхэн бичихийг мэддэг бөгөөд виртуал машинууд IP хаягийг хадгалах замаар Live Migration шаарддаггүй.

Дахин нэг удаа: яагаад үйлдвэр, яагаад L3 тусдаа байдаг гэсэн асуултын хариулт нийтлэл.

DCI - Дата төвийн харилцан холболт (DC хоорондын)

DCI нь Edge-Leaf ашиглан зохион байгуулагдах болно, өөрөөр хэлбэл тэдгээр нь бидний хурдны зам руу гарах цэг юм.
Энгийн байхын тулд бид DC-үүд хоорондоо шууд холбоосоор холбогдсон гэж үздэг.
Гадаад холболтыг авч үзэхээс хасъя.

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

Edge-Leafs дээр доод давхаргыг VPN-д байрлуулж, MPLS-ийн үндсэн шугамаар дамжуулдаг (ижил шууд холбоос).

Энэ бол бидний олж авсан дээд түвшний диаграм юм.

Чиглүүлэлт

DC дотор чиглүүлэлтийн хувьд бид BGP ашиглана.
MPLS их бие дээр OSPF+LDP.
DCI-ийн хувьд, өөрөөр хэлбэл газар доорх холболтыг зохион байгуулах - MPLS-ээр BGP L3VPN.

Чиглүүлэлтийн ерөнхий схем

Үйлдвэрт OSPF эсвэл ISIS (ОХУ-д хориглосон чиглүүлэлтийн протокол) байдаггүй.

Энэ нь автоматаар илрүүлэх эсвэл хамгийн богино замыг тооцоолох боломжгүй гэсэн үг - зөвхөн гараар (үнэндээ автоматаар - бид энд автоматжуулалтын тухай ярьж байна) протокол, хөрш, бодлогыг тохируулах.

DC доторх BGP чиглүүлэлтийн схем

Яагаад BGP гэж?

Энэ сэдвээр байна бүхэлд нь RFC Фэйсбүүк болон Аристагийн нэрээр нэрлэсэн бөгөөд энэ нь хэрхэн барихыг хэлдэг маш том BGP ашиглан мэдээллийн төвийн сүлжээ. Энэ нь бараг л уран зохиол шиг уншдаг, би үүнийг тайван оройн цагаар хийхийг зөвлөж байна.

Мөн миний нийтлэлд үүнд зориулагдсан бүхэл бүтэн хэсэг бий. Би чамайг хаашаа авч явах вэ Би явуулж байна.

Гэсэн хэдий ч, товчхондоо, сүлжээний төхөөрөмжийн тоо хэдэн мянгад хүрдэг томоохон мэдээллийн төвийн сүлжээнд тохирох IGP байхгүй.

Нэмж дурдахад BGP-ийг хаа сайгүй ашиглах нь хэд хэдэн өөр өөр протоколуудыг дэмжих, тэдгээрийн хооронд синхрончлоход цаг алдахгүй байх боломжийг танд олгоно.

Маш хурдан өсөх магадлал өндөргүй манай үйлдвэрт OSPF нь нүдэнд хангалттай байх болно. Эдгээр нь үнэндээ мегаscalers болон үүл титануудын асуудал юм. Гэхдээ Петр Лапуховын гэрээслэн үлдээсэнчлэн бид BGP-г ашиглах болно гэдгийг хэдхэн хувилбараар төсөөлөөд үз дээ.

Чиглүүлэлтийн бодлого

Навч шилжүүлэгч дээр бид Underlay сүлжээний интерфейсээс угтваруудыг BGP руу импортолдог.
Бид хооронд BGP сесс хийх болно тус бүр Навч-нугасны хос, үүнд эдгээр Underlay угтваруудыг сүлжээгээр нааш цааш зарлах болно.

Нэг дата төвд бид ToRe-д импортолсон техникийн үзүүлэлтүүдийг түгээх болно. Edge-Leafs дээр бид тэдгээрийг нэгтгэж, алслагдсан DC-д зарлаж, TOR-д илгээх болно. Өөрөөр хэлбэл, ToR бүр нэг DC-д өөр ToR руу хэрхэн хүрэх, өөр DC-д орох цэг нь хаана байгааг яг таг мэдэх болно.

DCI-д маршрутуудыг VPNv4 хэлбэрээр дамжуулах болно. Үүнийг хийхийн тулд Edge-Leaf дээр үйлдвэр рүү чиглэсэн интерфэйсийг VRF-д байрлуулж, үүнийг UNDERLAY гэж нэрлэе, мөн Edge-Leaf дээрх Spine-тай хөрш VRF дотор, Edge-Leafs хооронд VPNv4-т байрлана. гэр бүл.

Бид мөн нуруунаас хүлээн авсан маршрутыг дахин зарлахыг хориглоно.

Навч ба нуруун дээр бид Loopback-ийг импортлохгүй. Бидэнд зөвхөн чиглүүлэгчийн ID-г тодорхойлоход л хэрэгтэй.

Гэхдээ Edge-Leafs дээр бид үүнийг Global BGP руу оруулж ирдэг. Loopback хаягуудын хооронд Edge-Leafs нь хоорондоо IPv4 VPN-гэр бүлд BGP сессийг үүсгэнэ.

Бид EDGE төхөөрөмжүүдийн хооронд OSPF+LDP тулгууртай болно. Бүх зүйл нэг бүсэд байна. Маш энгийн тохиргоо.

Энэ бол чиглүүлэлттэй зураг юм.

BGP ASN

Ирмэг навч ASN

Edge-Leafs нь бүх DC-д нэг ASN-тэй байх болно. Edge-Leafs хооронд iBGP байх нь чухал бөгөөд бид eBGP-ийн нарийн ширийн зүйлд баригдахгүй. 65535. Бодит байдал дээр энэ нь нийтийн АС-ийн тоо байж болох юм.

Нурууны ASN

Spine дээр бид DC тутамд нэг ASN байх болно. Хувийн AS - 64512, 64513 гэх мэт хамгийн эхний дугаараас эхэлцгээе.

Яагаад DC дээр ASN?

Энэ асуултыг хоёр хэсэгт хувааж үзье:

• Яагаад нэг DC-ийн бүх нуруун дээр ASN-ууд ижил байдаг вэ?
• Тэд яагаад өөр өөр DC-д ялгаатай байдаг вэ?

Яагаад нэг DC-ийн бүх нуруун дээр ижил ASN байдаг вэ?

Edge-Leaf дээрх Underlay маршрутын AS-Path нь иймэрхүү харагдах болно.
[leafX_ASN, spine_ASN, edge_ASN]
Та үүнийг нуруу руу буцааж сурталчлах гэж оролдох үед AS (Spine_AS) нь аль хэдийн жагсаалтад орсон байгаа тул үүнийг хаях болно.

Гэсэн хэдий ч DC дотор бид Edge хүртэл өгсөх Underlay маршрутууд доошоо бууж чадахгүй гэдэгт бүрэн сэтгэл хангалуун байна. DC доторх хостуудын хоорондох бүх холбоо нь нурууны түвшинд явагдах ёстой.

Үүний зэрэгцээ, бусад DC-ийн нэгтгэсэн маршрутууд нь ямар ч тохиолдолд ToR-д хялбархан хүрэх болно - тэдний AS-Path нь зөвхөн ASN 65535 - AS Edge-Leafs-ийн тоотой байх болно, учир нь тэдгээр нь энд бий болсон.

Тэд яагаад өөр өөр DC-д ялгаатай байдаг вэ?

Онолын хувьд бид DC-ийн хооронд Loopback болон зарим үйлчилгээний виртуал машинуудыг чирэх хэрэгтэй болж магадгүй юм.

Жишээлбэл, хост дээр бид Route Reflector эсвэл ажиллуулах болно ижил VNGW (Virtual Network Gateway) нь BGP-ээр дамжуулан TopR-ээр түгжиж, бүх DC-ээс хандах боломжтой байх ёстой.

Тиймээс түүний AS-Path нь иймэрхүү харагдах болно:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Мөн хаана ч давхардсан ASN байх ёсгүй.

Өөрөөр хэлбэл, Spine_DC1 болон Spine_DC2 нь яг л навчX_DC1, leafY_DC2 шиг ялгаатай байх ёстой бөгөөд энэ нь яг бидний ойртож буй зүйл юм.

Давхардсан ASN-тэй маршрутуудыг давтахаас урьдчилан сэргийлэх механизм (Cisco дээр зөвшөөрөгдсөн) ч хүлээн зөвшөөрөх боломжийг олгодог хакерууд байдгийг та мэдэж байгаа байх. Мөн энэ нь бүр хууль ёсны хэрэглээтэй байдаг. Гэхдээ энэ нь сүлжээний тогтвортой байдалд учирч болзошгүй цоорхой юм. Тэгээд би хувьдаа хэд хэдэн удаа унасан.

Тэгээд аюултай зүйл хэрэглэхгүй байх боломж байгаа бол бид үүнийг ашиглах болно.

Навч ASN

Бид сүлжээн дэх Навч шилжүүлэгч бүр дээр тусдаа ASN-тэй байх болно.
Бид дээр дурдсан шалтгааны улмаас үүнийг хийдэг: гогцоогүй AS-зам, хавчуургагүй BGP тохиргоо.

Навч хоорондын замууд саадгүй өнгөрөхийн тулд AS-зам дараах байдалтай байх ёстой.
[leafX_ASN, spine_ASN, leafY_ASN]
хаана leafX_ASN болон leafY_ASN ялгаатай байвал сайхан байх болно.

Энэ нь DC-ийн хооронд VNF давталтыг зарлахтай холбоотой нөхцөл байдалд бас шаардлагатай:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Бид 4 байт ASN ашиглаж, нурууны ASN болон Навч шилжүүлэгчийн дугаар дээр үндэслэн үүсгэнэ, тухайлбал: Нурууны_ASN.0000X.

Энэ бол ASN-ийн зураг юм.

IP төлөвлөгөө

Үндсэндээ бид дараах холболтуудын хаягийг хуваарилах хэрэгтэй.

1. ToR болон машин хоорондын сүлжээний хаягууд. Эдгээр нь бүхэл бүтэн сүлжээнд өвөрмөц байх ёстой бөгөөд ингэснээр ямар ч машин бусадтай харилцах боломжтой. Маш тохиромжтой 10/8. Тавиур бүрт /26 нөөцтэй. Бид DC-д /19, бүс бүрт /17-г хуваарилна.
2. Навч/Тор болон нурууны хоорондох хаягуудыг холбоно.

   Би тэдгээрийг алгоритмын дагуу хуваарилахыг хүсч байна, өөрөөр хэлбэл тэдгээрийг холбох шаардлагатай төхөөрөмжүүдийн нэрээр тооцоолохыг хүсч байна.

   Байгаа... 169.254.0.0/16.
   Тэр тусмаа 169.254.00X.Y/31хаана X - Нурууны дугаар, Y — P2P сүлжээ /31.
   Энэ нь DC-д 128 хүртэлх тавиур, 10 хүртэлх Spine ажиллуулах боломжийг танд олгоно. Холбоосын хаягууд нь DC-ээс DC хүртэл давтагдах боломжтой (мөн байх болно).

3. Бид дэд сүлжээн дээр нуруу-ирмэг-навчны уулзварыг зохион байгуулдаг 169.254.10X.Y/31, хаана яг адилхан X - Нурууны дугаар, Y — P2P сүлжээ /31.
4. Edge-Leaf-аас MPLS-ийн үндсэн холбоос руу хаягуудыг холбоно. Энд нөхцөл байдал арай өөр байна - бүх хэсгүүдийг нэг бялуу болгон холбосон газар тул ижил хаягуудыг дахин ашиглах нь ажиллахгүй болно - та дараагийн үнэгүй дэд сүлжээг сонгох хэрэгтэй. Тиймээс, үндэс болгон авч үзье 192.168.0.0/16 мөн бид түүнээс чөлөөтэйг нь гаргана.
5. Давталтын хаягууд. Бид тэдэнд зориулж бүх хүрээг өгөх болно 172.16.0.0/12.
   • Навч - / DC тутамд 25 - ижил 128 тавиур. Бид бүс болгонд /23-ыг хуваарилна.
   • Нуруу - / DC-д 28 - 16 хүртэл Нуруу. Бүс болгонд /26-г хуваарилъя.
   • Edge-Leaf - / DC тутамд 29 - 8 хайрцаг хүртэл. Бүс болгонд /27-г хуваарилъя.

Хэрэв бид DC-д хангалттай хуваарилагдсан муж байхгүй бол (мөн байхгүй болно - бид өөрсдийгөө хэт масштабтай гэж мэдэгддэг) бид зүгээр л дараагийн блокыг сонгоно.

Энэ бол IP хаягтай зураг юм.

Буцах давталт:

Угтвар
Төхөөрөмжийн үүрэг
Бүс нутаг
DC

172.16.0.0/23
зах
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
msk

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
bcn

172.16.0.40/29
млг

172.16.0.64/27
cn
 

172.16.0.64/29
ша

172.16.0.72/29
аль аль нь

172.16.2.0/23
нуруу
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
msk

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
bcn

172.16.2.80/28
млг

172.16.2.128/26
cn
 

172.16.2.128/28
ша

172.16.2.144/28
аль аль нь

172.16.8.0/21
навч
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
msk

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
bcn

172.16.10.128/25
млг

172.16.12.0/23
cn
 

172.16.12.0/25
ша

172.16.12.128/25
аль аль нь

Доод давхарга:

Угтвар
Бүс нутаг
DC

10.0.0.0/17
ru
 

10.0.0.0/19
msk

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
bcn

10.0.160.0/19
млг

10.1.0.0/17
cn
 

10.1.0.0/19
ша

10.1.32.0/19
аль аль нь

Лаба

Хоёр худалдагч. Нэг сүлжээ. ADSM.

Арц + Ариста. Ubuntu. Сайн хөгшин Ева.

Мирана дахь манай виртуал сервер дээрх нөөцийн хэмжээ хязгаарлагдмал хэвээр байгаа тул дадлага хийхийн тулд бид хязгаар хүртэл хялбаршуулсан сүлжээг ашиглах болно.

Хоёр дата төв: Казань, Барселона.

• Тус бүр хоёр нуруу: Арц, Ариста.
• Тус бүрдээ нэг торус (Навч) - Арц ба Ариста, нэг холбогдсон хосттой (үүнд зориулж хөнгөн жинтэй Cisco IOL авцгаая).
• Нэг ирмэг-навчны зангилаа (одоохондоо зөвхөн арц).
• Бүгдийг удирдах нэг Cisco шилжүүлэгч.
• Сүлжээний хайрцагуудаас гадна виртуал хяналтын машин ажиллаж байна. Ubuntu ажиллуулж байна.
  Энэ нь бүх төхөөрөмжид хандах эрхтэй, IPAM/DCIM систем, Python скриптүүд, Ansible болон бидэнд хэрэгтэй байж болох бусад бүх зүйлийг ажиллуулах болно.

Бүрэн тохиргоо Бид автоматжуулалтыг ашиглан хуулбарлахыг хичээх бүх сүлжээний төхөөрөмжүүдийн .

дүгнэлт

Үүнийг бас хүлээн зөвшөөрсөн үү? Би нийтлэл бүрийн доор товч дүгнэлт бичих ёстой юу?

Тиймээс бид сонгосон гурван түвшний DC доторх Kloz сүлжээ, учир нь бид зүүнээс баруун тийш маш их урсгалыг хүлээж, ECMP-ийг хүсч байна.

Сүлжээг физик (давуулаа) ба виртуал (давхардсан) гэж хуваасан. Үүний зэрэгцээ, давхарга нь хостоос эхэлдэг - ингэснээр доод давхаргад тавигдах шаардлагыг хялбаршуулдаг.

Бид BGP-ийг сүлжээний сүлжээний чиглүүлэлтийн протокол болгон сонгосон бөгөөд түүний цар хүрээ, бодлогын уян хатан байдлыг харгалзан үзсэн.

Бид DCI - Edge-leaf-ийг зохион байгуулах тусдаа зангилаатай болно.
Суурь нь OSPF+LDP байх болно.
DCI нь MPLS L3VPN дээр тулгуурлан хэрэгжинэ.
P2P холбоосуудын хувьд бид төхөөрөмжийн нэр дээр үндэслэн IP хаягийг алгоритмаар тооцоолох болно.
Бид төхөөрөмжүүдийн үүрэг, байршлын дагуу давталтыг хуваарилах болно.
Доод давхаргын угтварууд - зөвхөн Навч свич дээр байршлаас нь хамааран дарааллаар.

Одоогоор бидэнд тоног төхөөрөмж суурилуулаагүй байна гэж бодъё.
Тиймээс бидний дараагийн алхмууд нь тэдгээрийг системд (IPAM, бараа материал) нэмэх, хандалтыг зохион байгуулах, тохиргоог үүсгэх, байрлуулах явдал юм.

Дараагийн өгүүллээр бид Netbox - DC дахь IP зайны тооллого, удирдлагын системийг авч үзэх болно.

Баярлалаа

• Андрей Глазков ака @ glazgoo засвар, засвар
• Засвар унших, засварлах ажилд Александр Клименко ака @v00lk
• KDPV-д зориулсан Артём Чернобай

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