ໃນສອງບົດຄວາມທໍາອິດ, ຂ້າພະເຈົ້າໄດ້ຍົກບັນຫາຂອງອັດຕະໂນມັດແລະແຕ້ມກອບຂອງຕົນ, ໃນຄັ້ງທີສອງຂ້າພະເຈົ້າໄດ້ກັບຄືນສູ່ virtualization ເຄືອຂ່າຍ, ເປັນວິທີການທໍາອິດທີ່ຈະອັດຕະໂນມັດການຕັ້ງຄ່າການບໍລິການ.
ໃນປັດຈຸບັນມັນເຖິງເວລາທີ່ຈະແຕ້ມແຜນວາດຂອງເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍ.

ຖ້າທ່ານບໍ່ຄຸ້ນເຄີຍກັບການຕັ້ງຄ່າເຄືອຂ່າຍສູນຂໍ້ມູນ, ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ເລີ່ມຕົ້ນດ້ວຍ ບົດຄວາມກ່ຽວກັບພວກເຂົາ.

ບັນຫາທັງໝົດ:

• 0. ADSM. ສ່ວນສູນ. ການວາງແຜນ
• 1. ADSM. ສ່ວນຫນຶ່ງ (ເຊິ່ງຫຼັງຈາກສູນ). ເຄືອຂ່າຍ virtualization
• 2. ADSM. ສ່ວນສອງ. ການອອກແບບເຄືອຂ່າຍ

ການປະຕິບັດທີ່ອະທິບາຍໄວ້ໃນຊຸດນີ້ຄວນໃຊ້ໄດ້ກັບເຄືອຂ່າຍປະເພດໃດກໍ່ຕາມ, ຂະຫນາດໃດກໍ່ຕາມ, ກັບຜູ້ຂາຍຕ່າງໆ (ບໍ່). ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະອະທິບາຍຕົວຢ່າງທົ່ວໄປຂອງການນໍາໃຊ້ວິທີການເຫຼົ່ານີ້. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າຈະສຸມໃສ່ສະຖາປັດຕະຍະກໍາທີ່ທັນສະໄຫມຂອງເຄືອຂ່າຍ DC: ໂຮງງານ Kloz.
ພວກເຮົາຈະເຮັດ DCI ໃນ MPLS L3VPN.

ເຄືອຂ່າຍ Overlay ດໍາເນີນການຢູ່ເທິງສຸດຂອງເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍຈາກໂຮດ (ນີ້ອາດຈະເປັນ VXLAN ຂອງ OpenStack ຫຼືຜ້າ Tungsten ຫຼືສິ່ງອື່ນທີ່ຮຽກຮ້ອງໃຫ້ມີພຽງແຕ່ການເຊື່ອມຕໍ່ IP ພື້ນຖານຈາກເຄືອຂ່າຍ).

ໃນກໍລະນີນີ້, ພວກເຮົາໄດ້ຮັບສະຖານະການທີ່ຂ້ອນຂ້າງງ່າຍດາຍສໍາລັບການອັດຕະໂນມັດ, ເພາະວ່າພວກເຮົາມີອຸປະກອນຈໍານວນຫລາຍທີ່ຖືກກໍານົດໄວ້ໃນລັກສະນະດຽວກັນ.

ພວກເຮົາຈະເລືອກ DC spherical ໃນສູນຍາກາດ:

• ສະບັບການອອກແບບຫນຶ່ງຢູ່ທົ່ວທຸກແຫ່ງ.
• ຜູ້ຂາຍສອງຄົນປະກອບເປັນຍົນເຄືອຂ່າຍສອງອັນ.
• ຫນຶ່ງ DC ແມ່ນຄ້າຍຄືອີກອັນຫນຶ່ງຄືກັບຖົ່ວສອງເມັດໃນຝັກ.

ເນື້ອໃນ

• topology ທາງກາຍຍະພາບ
• ກຳນົດເສັ້ນທາງ
• ແຜນການ IP
• ລາບາ
• ສະຫລຸບ
• ການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດ

ຕົວຢ່າງໃຫ້ຜູ້ໃຫ້ບໍລິການ LAN_DC ຂອງພວກເຮົາເປັນເຈົ້າພາບວິດີໂອການຝຶກອົບຮົມກ່ຽວກັບການລອດຊີວິດໃນລິຟທີ່ຕິດຢູ່.

ໃນ megacities ນີ້ແມ່ນເປັນທີ່ນິຍົມ wildly, ສະນັ້ນທ່ານຕ້ອງການເຄື່ອງທາງດ້ານຮ່າງກາຍຫຼາຍ.

ຫນ້າທໍາອິດ, ຂ້າພະເຈົ້າຈະອະທິບາຍເຄືອຂ່າຍປະມານທີ່ຂ້າພະເຈົ້າຢາກໃຫ້ມັນເປັນ. ແລະຫຼັງຈາກນັ້ນຂ້ອຍຈະເຮັດໃຫ້ມັນງ່າຍດາຍສໍາລັບຫ້ອງທົດລອງ.

topology ທາງກາຍຍະພາບ

ສະຖານທີ່

LAN_DC ຈະມີ 6 DCs:

• ລັດເຊຍ (RU):
  • ມອດໂກ (msk)
  • ຄາຊານ (kzn)

• ສະເປນ (SP):
  • ບາເຊໂລນາ (bcn)
  • ມາລາກາ (MLG)

• ຈີນ (CN):
  • ຊຽງໄຮ (sha)
  • Xi'an (sia)

ພາຍໃນ DC (Intra-DC)

DCs ທັງໝົດມີເຄືອຂ່າຍເຊື່ອມຕໍ່ພາຍໃນທີ່ຄືກັນໂດຍອ້າງອີງຈາກ Clos topology.
ເຂົາເຈົ້າເປັນເຄືອຂ່າຍ Clos ປະເພດໃດ ແລະເປັນຫຍັງພວກມັນຈຶ່ງຢູ່ໃນແຍກຕ່າງຫາກ ບົດຄວາມ.

ແຕ່ລະ DC ມີ 10 racks ທີ່ມີເຄື່ອງຈັກ, ພວກເຂົາເຈົ້າຈະຖືກນັບເປັນ A, B, C ແລະອື່ນໆ.

ແຕ່ລະ rack ມີ 30 ເຄື່ອງ. ເຂົາເຈົ້າຈະບໍ່ສົນໃຈພວກເຮົາ.

ນອກຈາກນີ້ໃນແຕ່ລະ rack ມີສະຫຼັບທີ່ເຄື່ອງທັງຫມົດແມ່ນເຊື່ອມຕໍ່ - ນີ້ແມ່ນ ດ້ານເທິງຂອງສະວິດ Rack - ToR ຫຼືຖ້າບໍ່ດັ່ງນັ້ນ, ໃນເງື່ອນໄຂຂອງໂຮງງານ Clos, ພວກເຮົາຈະໂທຫາມັນ ໃບ.

ແຜນວາດທົ່ວໄປຂອງໂຮງງານ.

ພວກເຮົາຈະໂທຫາພວກເຂົາ XXX- ໃບYບ່ອນທີ່ XXX - ຕົວຫຍໍ້ສາມຕົວອັກສອນ DC, ແລະ Y - ເລກລໍາດັບ. ຍົກ​ຕົວ​ຢ່າງ, kzn-leaf11.

ໃນບົດຄວາມຂອງຂ້ອຍຂ້ອຍຈະອະນຸຍາດໃຫ້ຕົວເອງໃຊ້ ຄຳ ສັບ Leaf ແລະ ToR ແທນທີ່ຈະເປັນ ຄຳ ສັບຄ້າຍຄືກັນ. ຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາຕ້ອງຈື່ໄວ້ວ່ານີ້ບໍ່ແມ່ນກໍລະນີ.
ToR ແມ່ນສະວິດທີ່ຕິດຕັ້ງຢູ່ໃນ rack ທີ່ເຄື່ອງໄດ້ຖືກເຊື່ອມຕໍ່.
Leaf ແມ່ນບົດບາດຂອງອຸປະກອນໃນເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍຫຼືການປ່ຽນລະດັບທໍາອິດໃນແງ່ຂອງ Cloes topology.
ນັ້ນແມ່ນ, ໃບ != ToR.
ດັ່ງນັ້ນ Leaf ສາມາດເປັນຕົວປ່ຽນ EndofRaw, ສໍາລັບການຍົກຕົວຢ່າງ.
ຢ່າງໃດກໍຕາມ, ຢູ່ໃນຂອບຂອງບົດຄວາມນີ້ພວກເຮົາຍັງຈະປະຕິບັດໃຫ້ເຂົາເຈົ້າເປັນຄໍາສັບຄ້າຍຄື.

ແຕ່ລະສະວິດ ToR ແມ່ນເຊື່ອມຕໍ່ກັນກັບສີ່ສະຫຼັບການລວບລວມລະດັບສູງກວ່າ - ກະດູກສັນຫຼັງ. ຫນຶ່ງ rack ໃນ DC ແມ່ນຈັດສັນສໍາລັບ Spines. ພວກເຮົາຈະຕັ້ງຊື່ມັນຄ້າຍຄືກັນ: XXX- ກະດູກສັນຫຼັງY.

rack ດຽວກັນຈະປະກອບດ້ວຍອຸປະກອນເຄືອຂ່າຍສໍາລັບການເຊື່ອມຕໍ່ລະຫວ່າງ routers DC - 2 ກັບ MPLS ໃນຄະນະ. ແຕ່ໂດຍແລະຂະຫນາດໃຫຍ່, ເຫຼົ່ານີ້ແມ່ນ ToRs ດຽວກັນ. ນັ້ນແມ່ນ, ຈາກມຸມເບິ່ງຂອງສະຫຼັບ Spine, ToR ປົກກະຕິກັບເຄື່ອງເຊື່ອມຕໍ່ຫຼື router ສໍາລັບ DCI ບໍ່ສໍາຄັນເລີຍ - ພຽງແຕ່ສົ່ງຕໍ່.

ToRs ພິເສດດັ່ງກ່າວຖືກເອີ້ນວ່າ ຂອບໃບ. ພວກເຮົາຈະໂທຫາພວກເຂົາ XXX- ສັນຍາY.

ມັນຈະມີລັກສະນະນີ້.

ໃນແຜນວາດຂ້າງເທິງ, ຕົວຈິງແລ້ວຂ້າພະເຈົ້າວາງຂອບແລະໃບຢູ່ໃນລະດັບດຽວກັນ. ເຄືອຂ່າຍສາມຊັ້ນຄລາສສິກ ພວກເຂົາເຈົ້າໄດ້ສອນພວກເຮົາໃຫ້ພິຈາລະນາ uplinking (ເພາະສະນັ້ນຄໍາສັບ) ເປັນ uplinks. ແລະໃນທີ່ນີ້ມັນປາກົດວ່າ DCI "uplink" ກັບຄືນໄປບ່ອນລົງ, ເຊິ່ງສໍາລັບບາງສ່ວນເລັກນ້ອຍ breaks ຕາມເຫດຜົນປົກກະຕິ. ໃນກໍລະນີຂອງເຄືອຂ່າຍຂະຫນາດໃຫຍ່, ເມື່ອສູນຂໍ້ມູນຖືກແບ່ງອອກເປັນຫນ່ວຍງານຂະຫນາດນ້ອຍກວ່າ - POD's (Point Of Delivery), ເນັ້ນໃສ່ບຸກຄົນ ຂອບ-POD's ສໍາລັບ DCI ແລະການເຂົ້າເຖິງເຄືອຂ່າຍພາຍນອກ.

ເພື່ອຄວາມງ່າຍຂອງການຮັບຮູ້ໃນອະນາຄົດ, ຂ້ອຍຈະຍັງແຕ້ມ Edge ຢູ່ເທິງກະດູກສັນຫຼັງ, ໃນຂະນະທີ່ພວກເຮົາຈະຈື່ໄວ້ວ່າບໍ່ມີຄວາມສະຫລາດກ່ຽວກັບກະດູກສັນຫຼັງແລະບໍ່ມີຄວາມແຕກຕ່າງກັນໃນເວລາທີ່ເຮັດວຽກກັບ Leaf ແລະ Edge-leaf ປົກກະຕິ (ເຖິງແມ່ນວ່າອາດຈະມີຄວາມແຕກຕ່າງຢູ່ທີ່ນີ້. , ແຕ່ໂດຍທົ່ວໄປນີ້ແມ່ນຄວາມຈິງ).

ຮູບແບບຂອງໂຮງງານທີ່ມີໃບແຂບ.

Trinity ຂອງ Leaf, Spine ແລະ Edge ປະກອບເປັນເຄືອຂ່າຍ Underlay ຫຼືໂຮງງານ.

ວຽກງານຂອງໂຮງງານເຄືອຂ່າຍ (ອ່ານ Underlay), ດັ່ງທີ່ພວກເຮົາໄດ້ກໍານົດໄວ້ແລ້ວໃນ ສະບັບສຸດທ້າຍ, ຫຼາຍ, ງ່າຍດາຍຫຼາຍ - ເພື່ອສະຫນອງການເຊື່ອມຕໍ່ IP ລະຫວ່າງເຄື່ອງຈັກທັງພາຍໃນ DC ດຽວກັນແລະລະຫວ່າງພວກມັນ.
ນັ້ນແມ່ນເຫດຜົນທີ່ເຄືອຂ່າຍຖືກເອີ້ນວ່າໂຮງງານ, ຄືກັນກັບ, ສໍາລັບການຍົກຕົວຢ່າງ, ໂຮງງານປ່ຽນພາຍໃນກ່ອງເຄືອຂ່າຍໂມດູນ, ທີ່ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບໃນ. SDSM14.

ໂດຍທົ່ວໄປ, topology ດັ່ງກ່າວເອີ້ນວ່າໂຮງງານ, ເນື່ອງຈາກວ່າ fabric ໃນການແປພາສາຫມາຍຄວາມວ່າ fabric. ແລະມັນຍາກທີ່ຈະບໍ່ເຫັນດີ:

ໂຮງງານແມ່ນ L3 ຢ່າງສົມບູນ. ບໍ່ມີ VLAN, ບໍ່ມີ Broadcast - ພວກເຮົາມີໂປລແກລມທີ່ປະເສີດທີ່ LAN_DC, ພວກເຂົາຮູ້ວິທີການຂຽນຄໍາຮ້ອງສະຫມັກທີ່ມີຊີວິດຢູ່ໃນ L3 paradigm, ແລະເຄື່ອງ virtual ບໍ່ຈໍາເປັນຕ້ອງມີ Live Migration ດ້ວຍການຮັກສາທີ່ຢູ່ IP.

ແລະອີກເທື່ອຫນຶ່ງ: ຄໍາຕອບຂອງຄໍາຖາມວ່າເປັນຫຍັງໂຮງງານແລະເປັນຫຍັງ L3 ຢູ່ໃນແຍກຕ່າງຫາກ ບົດຄວາມ.

DCI - Data Center Interconnect (Inter-DC)

DCI ຈະຖືກຈັດຕັ້ງໂດຍໃຊ້ Edge-Leaf, ນັ້ນແມ່ນ, ພວກເຂົາເປັນຈຸດອອກຂອງພວກເຮົາໄປຫາທາງດ່ວນ.
ສໍາລັບຄວາມງ່າຍດາຍ, ພວກເຮົາສົມມຸດວ່າ DCs ແມ່ນເຊື່ອມຕໍ່ກັນໂດຍການເຊື່ອມຕໍ່ໂດຍກົງ.
ໃຫ້ພວກເຮົາຍົກເວັ້ນການເຊື່ອມຕໍ່ພາຍນອກຈາກການພິຈາລະນາ.

ຂ້ອຍຮູ້ວ່າທຸກໆຄັ້ງທີ່ຂ້ອຍເອົາອົງປະກອບອອກ, ຂ້ອຍເຮັດໃຫ້ເຄືອຂ່າຍງ່າຍຂຶ້ນຫຼາຍ. ແລະໃນເວລາທີ່ພວກເຮົາອັດຕະໂນມັດເຄືອຂ່າຍ abstract ຂອງພວກເຮົາ, ທຸກສິ່ງທຸກຢ່າງຈະດີ, ແຕ່ວ່າໃນຫນຶ່ງທີ່ແທ້ຈິງຈະມີ crutches.
ນີ້​ແມ່ນ​ຄວາມ​ຈິງ. ຢ່າງໃດກໍຕາມ, ຈຸດຂອງຊຸດນີ້ແມ່ນການຄິດແລະເຮັດວຽກກ່ຽວກັບວິທີການ, ບໍ່ແມ່ນການ heroically ແກ້ໄຂບັນຫາຈິນຕະນາການ.

ໃນ Edge-Leafs, underlay ແມ່ນຖືກຈັດໃສ່ໃນ VPN ແລະສົ່ງຜ່ານກະດູກສັນຫຼັງ MPLS (ການເຊື່ອມຕໍ່ໂດຍກົງດຽວກັນ).

ນີ້ແມ່ນແຜນວາດລະດັບສູງສຸດທີ່ພວກເຮົາໄດ້ຮັບ.

ກຳນົດເສັ້ນທາງ

ສໍາລັບເສັ້ນທາງພາຍໃນ DC ພວກເຮົາຈະໃຊ້ BGP.
ຢູ່ໃນລໍາຕົ້ນ MPLS OSPF+LDP.
ສໍາລັບ DCI, ນັ້ນແມ່ນ, ການຈັດຕັ້ງການເຊື່ອມຕໍ່ຢູ່ໃນໃຕ້ດິນ - BGP L3VPN ຫຼາຍກວ່າ MPLS.

ໂຄງ​ການ​ເສັ້ນ​ທາງ​ທົ່ວ​ໄປ​

ບໍ່ມີ OSPF ຫຼື ISIS (ໂປໂຕຄອນການກໍານົດເສັ້ນທາງທີ່ຫ້າມຢູ່ໃນສະຫະພັນລັດເຊຍ) ໃນໂຮງງານ.

ນີ້ຫມາຍຄວາມວ່າຈະບໍ່ມີການຄົ້ນພົບອັດຕະໂນມັດຫຼືການຄິດໄລ່ເສັ້ນທາງທີ່ສັ້ນທີ່ສຸດ - ພຽງແຕ່ຄູ່ມື (ຕົວຈິງແລ້ວອັດຕະໂນມັດ - ພວກເຮົາເວົ້າກ່ຽວກັບການອັດຕະໂນມັດຢູ່ທີ່ນີ້) ການຕັ້ງຄ່າໂປໂຕຄອນ, ບ້ານແລະນະໂຍບາຍ.

ໂຄງການເສັ້ນທາງ BGP ພາຍໃນ DC

ເປັນຫຍັງ BGP?

ກ່ຽວກັບຫົວຂໍ້ນີ້ມີ RFC ທັງ​ຫມົດ​ ຊື່ວ່າ Facebook ແລະ Arista, ເຊິ່ງບອກວິທີການສ້າງ ຂະຫນາດໃຫຍ່ຫຼາຍ ເຄືອຂ່າຍສູນຂໍ້ມູນໂດຍໃຊ້ BGP. ມັນອ່ານເກືອບຄືກັບນິຍາຍ, ຂ້ອຍຂໍແນະ ນຳ ມັນ ສຳ ລັບຕອນແລງທີ່ອິດເມື່ອຍ.

ແລະຍັງມີພາກທັງຫມົດໃນບົດຄວາມຂອງຂ້ອຍອຸທິດຕົນເພື່ອເລື່ອງນີ້. ຂ້ອຍເອົາເຈົ້າໄປໃສ ແລະ ຂ້ອຍກໍາລັງສົ່ງ.

ແຕ່ຢ່າງໃດກໍ່ຕາມ, ໃນສັ້ນ, ບໍ່ມີ IGPs ທີ່ເຫມາະສົມສໍາລັບເຄືອຂ່າຍຂອງສູນຂໍ້ມູນຂະຫນາດໃຫຍ່, ບ່ອນທີ່ຈໍານວນຂອງອຸປະກອນເຄືອຂ່າຍແລ່ນເຂົ້າໄປໃນຫລາຍພັນຄົນ.

ນອກຈາກນັ້ນ, ການນໍາໃຊ້ BGP ຢູ່ທົ່ວທຸກແຫ່ງຈະຊ່ວຍໃຫ້ທ່ານບໍ່ເສຍເວລາໃນການສະຫນັບສະຫນູນໂປໂຕຄອນທີ່ແຕກຕ່າງກັນແລະ synchronization ລະຫວ່າງພວກມັນ.

ດ້ວຍຫົວໃຈ, ໃນໂຮງງານຂອງພວກເຮົາ, ທີ່ມີລະດັບສູງຂອງຄວາມເປັນໄປໄດ້ຈະບໍ່ເຕີບໂຕຢ່າງໄວວາ, OSPF ຈະພຽງພໍສໍາລັບຕາ. ຕົວຈິງແລ້ວເຫຼົ່ານີ້ແມ່ນບັນຫາຂອງ megascalers ແລະ cloud titans. ແຕ່ຂໍໃຫ້ຈິນຕະນາການພຽງແຕ່ສໍາລັບການປ່ອຍຈໍານວນຫນ້ອຍທີ່ພວກເຮົາຕ້ອງການ, ແລະພວກເຮົາຈະໃຊ້ BGP, ດັ່ງທີ່ Pyotr Lapukhov bequeathed.

ນະໂຍບາຍການກຳນົດເສັ້ນທາງ

ໃນສະວິດ Leaf, ພວກເຮົານໍາເຂົ້າຄໍານໍາຫນ້າຈາກສ່ວນຕິດຕໍ່ເຄືອຂ່າຍ Underlay ເຂົ້າໄປໃນ BGP.
ພວກເຮົາຈະມີກອງປະຊຸມ BGP ລະຫວ່າງ ແຕ່ລະຄົນ ຄູ່ Leaf-Spine, ເຊິ່ງຄໍານໍາຫນ້າ Underlay ເຫຼົ່ານີ້ຈະຖືກປະກາດຜ່ານເຄືອຂ່າຍທີ່ນີ້ແລະບ່ອນນັ້ນ.

ພາຍໃນສູນຂໍ້ມູນຫນຶ່ງ, ພວກເຮົາຈະແຈກຢາຍຂໍ້ມູນສະເພາະທີ່ພວກເຮົານໍາເຂົ້າເຂົ້າໄປໃນ ToRe. ໃນ Edge-Leafs ພວກເຮົາຈະລວບລວມພວກມັນແລະປະກາດໃຫ້ພວກເຂົາກັບ DCs ຫ່າງໄກສອກຫຼີກແລະສົ່ງພວກເຂົາລົງໄປຫາ TORs. ນັ້ນແມ່ນ, ແຕ່ລະ ToR ຈະຮູ້ວິທີການໄປຫາ ToR ອື່ນໃນ DC ດຽວກັນແລະບ່ອນທີ່ຈຸດເຂົ້າແມ່ນເພື່ອໄປຫາ ToR ໃນ DC ອື່ນ.

ໃນ DCI, ເສັ້ນທາງຈະຖືກສົ່ງເປັນ VPNv4. ເພື່ອເຮັດສິ່ງນີ້, ໃນ Edge-Leaf, ການໂຕ້ຕອບຂອງໂຮງງານຈະຖືກຈັດໃສ່ໃນ VRF, ໃຫ້ໂທຫາມັນ UNDERLAY, ແລະເຂດໃກ້ຄຽງກັບ Spine on Edge-Leaf ຈະເພີ່ມຂຶ້ນພາຍໃນ VRF, ແລະລະຫວ່າງ Edge-Leafs ໃນ VPNv4-. ຄອບຄົວ.

ພວກເຮົາຍັງຈະຫ້າມການປະກາດຄືນໃຫມ່ຂອງເສັ້ນທາງທີ່ໄດ້ຮັບຈາກກະດູກສັນຫຼັງກັບຄືນໄປບ່ອນພວກເຂົາ.

ໃນໃບແລະກະດູກສັນຫຼັງພວກເຮົາຈະບໍ່ນໍາເຂົ້າ Loopbacks. ພວກເຮົາພຽງແຕ່ຕ້ອງການໃຫ້ພວກເຂົາກໍານົດ Router ID.

ແຕ່ໃນ Edge-Leafs ພວກເຮົານໍາເຂົ້າມັນເຂົ້າໄປໃນ Global BGP. ລະຫວ່າງທີ່ຢູ່ Loopback, Edge-Leafs ຈະສ້າງກອງປະຊຸມ BGP ໃນ IPv4 VPN-family ກັບກັນແລະກັນ.

ພວກເຮົາຈະມີກະດູກສັນຫຼັງ OSPF+LDP ລະຫວ່າງອຸປະກອນ EDGE. ທຸກສິ່ງທຸກຢ່າງແມ່ນຢູ່ໃນເຂດດຽວ. ການ​ຕັ້ງ​ຄ່າ​ງ່າຍ​ດາຍ​ທີ່​ສຸດ​.

ນີ້ແມ່ນຮູບທີ່ມີເສັ້ນທາງ.

BGP ASN

Edge-Leaf ASN

ໃນ Edge-Leafs ຈະມີ ASN ຫນຶ່ງໃນ DCs ທັງຫມົດ. ມັນເປັນສິ່ງສໍາຄັນທີ່ມີ iBGP ລະຫວ່າງ Edge-Leafs, ແລະພວກເຮົາບໍ່ໄດ້ຮັບການຕິດຢູ່ໃນ nuances ຂອງ eBGP. ໃຫ້ມັນເປັນ 65535. ໃນຄວາມເປັນຈິງ, ນີ້ອາດຈະເປັນຈໍານວນສາທາລະນະ AS.

ກະດູກສັນຫຼັງ ASN

ໃນກະດູກສັນຫຼັງພວກເຮົາຈະມີຫນຶ່ງ ASN ຕໍ່ DC. ໃຫ້ເລີ່ມຕົ້ນທີ່ນີ້ດ້ວຍຕົວເລກທໍາອິດຫຼາຍຈາກລະດັບຂອງເອກະຊົນ AS - 64512, 64513 ແລະອື່ນໆ.

ເປັນຫຍັງ ASN ໃນ DC?

ໃຫ້ພວກເຮົາແຍກຄໍາຖາມນີ້ອອກເປັນສອງຢ່າງ:

• ເປັນຫຍັງ ASNs ຈຶ່ງຄືກັນຢູ່ໃນກະດູກສັນຫຼັງທັງໝົດຂອງໜຶ່ງ DC?
• ເປັນຫຍັງພວກມັນແຕກຕ່າງກັນໃນ DCs ທີ່ແຕກຕ່າງກັນ?

ເປັນຫຍັງ ASNs ດຽວກັນຢູ່ໃນກະດູກສັນຫຼັງທັງຫມົດຂອງຫນຶ່ງ DC?

ນີ້ແມ່ນສິ່ງທີ່ເສັ້ນທາງ AS-Path ຂອງເສັ້ນທາງ Underlay ໃນ Edge-Leaf ຈະມີລັກສະນະຄື:
[leafX_ASN, spine_ASN, edge_ASN]
ເມື່ອທ່ານພະຍາຍາມໂຄສະນາມັນກັບຄືນໄປບ່ອນ Spine, ມັນຈະຍົກເລີກມັນເພາະວ່າ AS (Spine_AS) ຂອງມັນຢູ່ໃນບັນຊີລາຍຊື່ແລ້ວ.

ຢ່າງໃດກໍຕາມ, ພາຍໃນ DC ພວກເຮົາມີຄວາມພໍໃຈຢ່າງສົມບູນວ່າເສັ້ນທາງ Underlay ທີ່ຂຶ້ນໄປຫາ Edge ຈະບໍ່ສາມາດລົງໄປໄດ້. ການສື່ສານທັງຫມົດລະຫວ່າງເຈົ້າພາບພາຍໃນ DC ຕ້ອງເກີດຂຶ້ນພາຍໃນລະດັບກະດູກສັນຫຼັງ.

ໃນກໍລະນີນີ້, ເສັ້ນທາງລວມຂອງ DCs ອື່ນໆຈະເຂົ້າຫາ ToRs ໄດ້ຢ່າງງ່າຍດາຍໃນກໍລະນີໃດກໍ່ຕາມ - AS-Path ຂອງພວກເຂົາຈະມີພຽງແຕ່ ASN 65535 - ຈໍານວນ AS Edge-Leafs, ເພາະວ່ານັ້ນແມ່ນບ່ອນທີ່ພວກເຂົາຖືກສ້າງຂຶ້ນ.

ເປັນຫຍັງພວກມັນແຕກຕ່າງກັນໃນ DCs ທີ່ແຕກຕ່າງກັນ?

ໃນທາງທິດສະດີ, ພວກເຮົາອາດຈະຈໍາເປັນຕ້ອງໄດ້ລາກ Loopback ແລະບາງເຄື່ອງ virtual ບໍລິການລະຫວ່າງ DCs.

ຕົວຢ່າງ, ໃນເຈົ້າພາບພວກເຮົາຈະດໍາເນີນການ Route Reflector ຫຼື VNGW ດຽວກັນ (Virtual Network Gateway), ເຊິ່ງຈະລັອກກັບ TopR ຜ່ານ BGP ແລະປະກາດ loopback ຂອງມັນ, ເຊິ່ງຄວນຈະສາມາດເຂົ້າເຖິງໄດ້ຈາກ DCs ທັງຫມົດ.

ດັ່ງນັ້ນ, ນີ້ແມ່ນສິ່ງທີ່ AS-Path ຂອງມັນຈະເບິ່ງຄືວ່າ:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

ແລະບໍ່ຄວນມີ ASNs ຊໍ້າກັນຢູ່ທຸກບ່ອນ.

ນັ້ນແມ່ນ, Spine_DC1 ແລະ Spine_DC2 ຈະຕ້ອງແຕກຕ່າງກັນ, ຄືກັນກັບ leafX_DC1 ແລະ leafY_DC2, ຊຶ່ງເປັນສິ່ງທີ່ພວກເຮົາກໍາລັງເຂົ້າຫາ.

ດັ່ງທີ່ທ່ານອາດຈະຮູ້, ມີ hacks ທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຍອມຮັບເສັ້ນທາງທີ່ມີ ASNs ຊ້ໍາກັນເຖິງວ່າຈະມີກົນໄກການປ້ອງກັນ loop (allowas-in on Cisco). ແລະເຖິງແມ່ນວ່າມີການນໍາໃຊ້ທີ່ຖືກຕ້ອງຕາມກົດຫມາຍ. ແຕ່ນີ້ແມ່ນຊ່ອງຫວ່າງທີ່ມີທ່າແຮງໃນຄວາມຫມັ້ນຄົງຂອງເຄືອຂ່າຍ. ແລະຂ້າພະເຈົ້າເອງໄດ້ຕົກເຂົ້າໄປໃນມັນສອງສາມເທື່ອ.

ແລະຖ້າພວກເຮົາມີໂອກາດທີ່ຈະບໍ່ໃຊ້ສິ່ງທີ່ເປັນອັນຕະລາຍ, ພວກເຮົາຈະໃຊ້ປະໂຫຍດຈາກມັນ.

ໃບ ASN

ພວກເຮົາຈະມີ ASN ສ່ວນບຸກຄົນໃນແຕ່ລະສະຫຼັບ Leaf ໃນທົ່ວເຄືອຂ່າຍ.
ພວກເຮົາເຮັດສິ່ງນີ້ສໍາລັບເຫດຜົນຂ້າງເທິງ: AS-Path ໂດຍບໍ່ມີການ loops, BGP configuration ໂດຍບໍ່ມີການ bookmarks.

ສໍາລັບເສັ້ນທາງລະຫວ່າງ Leafs ຜ່ານຢ່າງລຽບງ່າຍ, AS-Path ຄວນມີລັກສະນະນີ້:
[leafX_ASN, spine_ASN, leafY_ASN]
ບ່ອນທີ່ leafX_ASN ແລະ leafY_ASN ຈະດີທີ່ຈະແຕກຕ່າງກັນ.

ອັນນີ້ຍັງຕ້ອງການສໍາລັບສະຖານະການທີ່ມີການປະກາດຂອງ VNF loopback ລະຫວ່າງ DCs:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

ພວກເຮົາຈະໃຊ້ ASN 4-byte ແລະສ້າງມັນໂດຍອີງໃສ່ຕົວເລກຂອງ Spine's ASN ແລະ Leaf switch, ຄືເຊັ່ນນີ້: Spine_ASN.0000X.

ນີ້ແມ່ນຮູບທີ່ມີ ASN.

ແຜນການ IP

ໂດຍພື້ນຖານແລ້ວ, ພວກເຮົາຈໍາເປັນຕ້ອງຈັດສັນທີ່ຢູ່ສໍາລັບການເຊື່ອມຕໍ່ຕໍ່ໄປນີ້:

1. ວາງທີ່ຢູ່ເຄືອຂ່າຍລະຫວ່າງ ToR ແລະເຄື່ອງ. ພວກມັນຕ້ອງເປັນເອກະລັກພາຍໃນເຄືອຂ່າຍທັງໝົດເພື່ອໃຫ້ເຄື່ອງໃດສາມາດສື່ສານກັບເຄື່ອງອື່ນໄດ້. ພໍດີ 10/8. ສໍາລັບແຕ່ລະ rack ມີ /26 ມີສະຫງວນ. ພວກເຮົາຈະຈັດສັນ /19 ຕໍ່ DC ແລະ /17 ຕໍ່ພາກພື້ນ.
2. ເຊື່ອມຕໍ່ທີ່ຢູ່ລະຫວ່າງໃບ/Tor ແລະກະດູກສັນຫຼັງ.

   ຂ້າພະເຈົ້າຢາກຈະມອບຫມາຍໃຫ້ພວກເຂົາດ້ວຍວິທີ algorithm, ນັ້ນແມ່ນ, ຄິດໄລ່ພວກມັນຈາກຊື່ຂອງອຸປະກອນທີ່ຕ້ອງການເຊື່ອມຕໍ່.

   ໃຫ້ມັນເປັນ ... 169.254.0.0/16.
   ຄື 169.254.00X.Y/31ບ່ອນທີ່ X - ຈໍາ​ນວນ​ກະ​ດູກ​ສັນ​ຫຼັງ​, Y — ເຄືອ​ຂ່າຍ P2P /31.
   ນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດເປີດຕົວໄດ້ເຖິງ 128 racks, ແລະເຖິງ 10 Spines ໃນ DC. ທີ່ຢູ່ເຊື່ອມຕໍ່ສາມາດ (ແລະຈະ) ຖືກຊ້ໍາຈາກ DC ຫາ DC.

3. ພວກເຮົາຈັດຕັ້ງຈຸດເຊື່ອມຕໍ່ Spine-Edge-Leaf ໃນເຄືອຂ່າຍຍ່ອຍ 169.254.10X.Y/31, ບ່ອນທີ່ຄືກັນ X - ຈໍາ​ນວນ​ກະ​ດູກ​ສັນ​ຫຼັງ​, Y — ເຄືອ​ຂ່າຍ P2P /31.
4. ເຊື່ອມຕໍ່ທີ່ຢູ່ຈາກ Edge-Leaf ກັບ MPLS backbone. ໃນທີ່ນີ້ສະຖານະການແມ່ນແຕກຕ່າງກັນບາງຢ່າງ - ສະຖານທີ່ທີ່ຊິ້ນສ່ວນທັງຫມົດຖືກເຊື່ອມຕໍ່ເຂົ້າໄປໃນ pie ຫນຶ່ງ, ດັ່ງນັ້ນການນໍາໃຊ້ທີ່ຢູ່ດຽວກັນຈະບໍ່ເຮັດວຽກ - ທ່ານຈໍາເປັນຕ້ອງເລືອກ subnet ຟຣີຕໍ່ໄປ. ເພາະສະນັ້ນ, ໃຫ້ພວກເຮົາເອົາເປັນພື້ນຖານ 192.168.0.0/16 ແລະ​ພວກ​ເຮົາ​ຈະ​ເອົາ​ຄົນ​ທີ່​ເປັນ​ອິດ​ສະຫຼະ​ອອກ​ຈາກ​ມັນ.
5. ທີ່ຢູ່ Loopback. ພວກເຮົາຈະໃຫ້ຂອບເຂດທັງຫມົດສໍາລັບພວກເຂົາ 172.16.0.0/12.
   • ໃບ - / 25 ຕໍ່ DC - ດຽວກັນ 128 racks. ພວກເຮົາຈະຈັດສັນ /23 ຕໍ່ພາກພື້ນ.
   • ກະດູກສັນຫຼັງ - / 28 ຕໍ່ DC - ເຖິງ 16 ກະດູກສັນຫຼັງ. ໃຫ້ຈັດສັນ /26 ຕໍ່ພາກພື້ນ.
   • Edge-Leaf - /29 ຕໍ່ DC - ເຖິງ 8 ກ່ອງ. ພວກເຮົາຈະຈັດສັນ /27 ຕໍ່ພາກພື້ນ.

ຖ້າພວກເຮົາບໍ່ມີຂອບເຂດການຈັດສັນພຽງພໍໃນ DC (ແລະຈະບໍ່ມີ - ພວກເຮົາອ້າງວ່າເປັນ hyperscalers), ພວກເຮົາພຽງແຕ່ເລືອກ block ຕໍ່ໄປ.

ນີ້ແມ່ນຮູບທີ່ມີທີ່ຢູ່ IP.

Loopbacks:

ຄຳ ນຳ ໜ້າ
ບົດບາດຂອງອຸປະກອນ
ພາກພື້ນ
ДЦ

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
MLG

172.16.0.64/27
cn
 

172.16.0.64/29
sha

172.16.0.72/29
sia

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
MLG

172.16.2.128/26
cn
 

172.16.2.128/28
sha

172.16.2.144/28
sia

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
MLG

172.16.12.0/23
cn
 

172.16.12.0/25
sha

172.16.12.128/25
sia

ຊັ້ນໃຕ້ດິນ:

ຄຳ ນຳ ໜ້າ
ພາກພື້ນ
ДЦ

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
MLG

10.1.0.0/17
cn
 

10.1.0.0/19
sha

10.1.32.0/19
sia

ລາບາ

ຜູ້ຂາຍສອງຄົນ. ເຄືອຂ່າຍດຽວ. ADSM.

Juniper + Arista. Ubuntu. ສະບາຍດີເອວາເກົ່າ.

ຈໍານວນຂອງຊັບພະຍາກອນໃນເຄື່ອງແມ່ຂ່າຍ virtual ຂອງພວກເຮົາໃນ Mirana ແມ່ນຍັງຈໍາກັດ, ດັ່ງນັ້ນສໍາລັບການປະຕິບັດພວກເຮົາຈະນໍາໃຊ້ເຄືອຂ່າຍທີ່ງ່າຍດາຍທີ່ຈະຈໍາກັດ.

ສອງສູນຂໍ້ມູນ: Kazan ແລະ Barcelona.

• ສອງກະດູກສັນຫຼັງແຕ່ລະຄົນ: Juniper ແລະ Arista.
• ຫນຶ່ງ torus (ໃບ) ໃນແຕ່ລະ - Juniper ແລະ Arista, ກັບຫນຶ່ງເຈົ້າພາບເຊື່ອມຕໍ່ (ໃຫ້ເອົາ Cisco IOL ນ້ໍາຫນັກເບົາສໍາລັບການນີ້).
• ຫນຶ່ງ Edge-Leaf node ແຕ່ລະ (ສໍາລັບໃນປັດຈຸບັນພຽງແຕ່ Juniper).
• ຫນຶ່ງ Cisco ປ່ຽນເພື່ອປົກຄອງພວກເຂົາທັງຫມົດ.
• ນອກເໜືອໄປຈາກກ່ອງເຄືອຂ່າຍ, ເຄື່ອງຄວບຄຸມສະເໝືອນກຳລັງແລ່ນຢູ່. ແລ່ນ Ubuntu.
  ມັນ​ມີ​ການ​ເຂົ້າ​ເຖິງ​ອຸ​ປະ​ກອນ​ທັງ​ຫມົດ​, ມັນ​ຈະ​ດໍາ​ເນີນ​ການ​ລະ​ບົບ IPAM / DCIM​, bunch ຂອງ Python scripts , Ansible ແລະ​ສິ່ງ​ອື່ນໆ​ທີ່​ພວກ​ເຮົາ​ອາດ​ຈະ​ຕ້ອງ​ການ​.

ການຕັ້ງຄ່າເຕັມ ຂອງອຸປະກອນເຄືອຂ່າຍທັງຫມົດ, ທີ່ພວກເຮົາຈະພະຍາຍາມຜະລິດໃຫມ່ໂດຍໃຊ້ອັດຕະໂນມັດ.

ສະຫລຸບ

ມັນ​ຍັງ​ໄດ້​ຮັບ​ການ​ຍອມ​ຮັບ​? ຂ້ອຍຄວນຂຽນບົດສະຫຼຸບສັ້ນໆພາຍໃຕ້ແຕ່ລະບົດຄວາມບໍ?

ດັ່ງນັ້ນພວກເຮົາເລືອກ ສາມ​ລະ​ດັບ​ ເຄືອຂ່າຍ Kloz ພາຍໃນ DC, ນັບຕັ້ງແຕ່ພວກເຮົາຄາດວ່າຈະມີການຈະລາຈອນຕາເວັນອອກ - ຕາເວັນຕົກຫຼາຍແລະຕ້ອງການ ECMP.

ເຄືອຂ່າຍໄດ້ຖືກແບ່ງອອກເປັນທາງດ້ານຮ່າງກາຍ (underlay) ແລະ virtual (overlay). ໃນເວລາດຽວກັນ, overlay ເລີ່ມຕົ້ນຈາກເຈົ້າພາບ - ດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ຄວາມງ່າຍດາຍຂອງຂໍ້ກໍານົດສໍາລັບ underlay.

ພວກເຮົາເລືອກ BGP ເປັນໂປຣໂຕຄອນການກຳນົດເສັ້ນທາງສຳລັບເຄືອຂ່າຍເຄືອຂ່າຍເພື່ອຄວາມຢືດຢຸ່ນແລະຄວາມຍືດຫຍຸ່ນຂອງນະໂຍບາຍຂອງມັນ.

ພວກເຮົາຈະມີ nodes ແຍກຕ່າງຫາກສໍາລັບການຈັດຕັ້ງ DCI - Edge-leaf.
ກະດູກສັນຫຼັງຈະມີ OSPF+LDP.
DCI ຈະຖືກຈັດຕັ້ງປະຕິບັດໂດຍອີງໃສ່ MPLS L3VPN.
ສໍາລັບການເຊື່ອມຕໍ່ P2P, ພວກເຮົາຈະຄິດໄລ່ທີ່ຢູ່ IP ຕາມສູດການຄິດໄລ່ໂດຍອີງໃສ່ຊື່ອຸປະກອນ.
ພວກເຮົາຈະກໍານົດ loopbacks ຕາມພາລະບົດບາດຂອງອຸປະກອນແລະສະຖານທີ່ຂອງເຂົາເຈົ້າຕາມລໍາດັບ.
ຄຳນຳໜ້າທາງລຸ່ມ - ພຽງແຕ່ຢູ່ໃນສະວິດ Leaf ຕາມລໍາດັບຕາມສະຖານທີ່ຂອງມັນ.

ໃຫ້ສົມມຸດວ່າດຽວນີ້ພວກເຮົາບໍ່ມີອຸປະກອນຕິດຕັ້ງເທື່ອ.
ດັ່ງນັ້ນ, ຂັ້ນຕອນຕໍ່ໄປຂອງພວກເຮົາຈະເປັນການເພີ່ມພວກມັນເຂົ້າໃນລະບົບ (IPAM, ສິນຄ້າຄົງຄັງ), ຈັດຕັ້ງການເຂົ້າເຖິງ, ສ້າງການຕັ້ງຄ່າ ແລະນຳໃຊ້ມັນ.

ໃນບົດຄວາມຕໍ່ໄປພວກເຮົາຈະຈັດການກັບ Netbox - ສິນຄ້າຄົງຄັງແລະລະບົບການຄຸ້ມຄອງສໍາລັບພື້ນທີ່ IP ໃນ DC.

ຂອບ​ໃຈ

• Andrey Glazkov aka @glazgoo ສໍາລັບການອ່ານຫຼັກຖານແລະການແກ້ໄຂ
• Alexander Klimenko aka @v00lk ສໍາລັບການພິສູດແລະດັດແກ້
• Artyom Chernobay ສໍາລັບ KDPV

ແຫຼ່ງຂໍ້ມູນ: www.habr.com