SDSM ແມ່ນສິ້ນສຸດລົງ, ແຕ່ຄວາມປາຖະຫນາທີ່ບໍ່ສາມາດຄວບຄຸມໄດ້ທີ່ຈະຂຽນຍັງຄົງຢູ່.

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

ດ້ວຍບົດຄວາມນີ້ຂ້ອຍຈະເລີ່ມຕົ້ນຊຸດກ່ຽວກັບວິທີການ ກັບຂ້ອຍ ອັດຕະໂນມັດປາກົດ.
ຕາມວິທີການ, ພວກເຮົາຈະເຂົ້າໃຈຂັ້ນຕອນຂອງອັດຕະໂນມັດ, ການເກັບຮັກສາຕົວແປ, ການອອກແບບທີ່ເປັນທາງການ, RestAPI, NETCONF, YANG, YDK, ແລະພວກເຮົາຈະເຮັດການຂຽນໂປຼແກຼມຫຼາຍ.
ກັບຂ້າພະເຈົ້າ ຫມາຍຄວາມວ່າ a) ມັນບໍ່ແມ່ນຄວາມຈິງທີ່ມີຈຸດປະສົງ, b) ມັນບໍ່ແມ່ນວິທີການທີ່ດີທີ່ສຸດ, c) ຄວາມຄິດເຫັນຂອງຂ້ອຍ, ເຖິງແມ່ນວ່າໃນລະຫວ່າງການເຄື່ອນໄຫວຈາກບົດຄວາມທໍາອິດເຖິງບົດຄວາມສຸດທ້າຍ, ສາມາດປ່ຽນແປງ - ມີຄວາມຊື່ສັດ, ຈາກຂັ້ນຕອນຂອງຮ່າງເພື່ອ ການພິມເຜີຍແຜ່, ຂ້າພະເຈົ້າໄດ້ຂຽນຄືນທຸກສິ່ງທຸກຢ່າງຢ່າງສົມບູນສອງຄັ້ງ.

ເນື້ອໃນ

1. ຈຸດປະສົງ
   1. ເຄືອຂ່າຍແມ່ນຄ້າຍຄືອົງການຈັດຕັ້ງດຽວ
   2. ການ​ທົດ​ສອບ​ການ​ຕັ້ງ​ຄ່າ​
   3. ຮຸ່ນ
   4. ການຕິດຕາມແລະການປິ່ນປົວຕົນເອງຂອງການບໍລິການ

2. ໝາຍ ຄວາມວ່າ
   1. ລະບົບສາງ
   2. ລະບົບການຄຸ້ມຄອງພື້ນທີ່ IP
   3. ລະບົບລາຍລະອຽດການບໍລິການເຄືອຂ່າຍ
   4. ກົນໄກການເລີ່ມຕົ້ນອຸປະກອນ
   5. ຮູບແບບການກຳນົດຄ່າຜູ້ຂາຍ-ບໍ່ເຊື່ອຟັງ
   6. ອິນເຕີເຟດໄດເວີສະເພາະຜູ້ຂາຍ
   7. ກົນໄກການສົ່ງການຕັ້ງຄ່າໃຫ້ກັບອຸປະກອນ
   8. CI / CD
   9. ກົນໄກສໍາລັບການສໍາຮອງແລະຊອກຫາ deviations
   10. ລະບົບການຕິດຕາມ

3. ສະຫລຸບ

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

ມັນເປັນເລື່ອງຕະຫລົກຫຼາຍປານໃດທີ່ຄັ້ງທີສອງທີ່ເຈົ້າຕ້ອງຜ່ານເສັ້ນທາງດຽວກັນ.

ທໍາອິດຂ້ອຍຕ້ອງຂຽນບົດຄວາມກ່ຽວກັບເຄືອຂ່າຍດ້ວຍຕົນເອງເນື່ອງຈາກຄວາມຈິງທີ່ວ່າພວກເຂົາບໍ່ໄດ້ຢູ່ໃນ RuNet.

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

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

ພວກເຮົາຈະພະຍາຍາມເອົາສູນຂໍ້ມູນ LAN DC ຂະຫນາດກາງແລະດໍາເນີນການໂຄງການອັດຕະໂນມັດທັງຫມົດ.
ຂ້ອຍຈະເຮັດບາງອັນເກືອບເປັນເທື່ອທຳອິດກັບເຈົ້າ.

ຂ້ອຍຈະບໍ່ເປັນຕົ້ນສະບັບໃນແນວຄວາມຄິດແລະເຄື່ອງມືທີ່ອະທິບາຍຢູ່ທີ່ນີ້. Dmitry Figol ມີທີ່ດີເລີດ ຊ່ອງທີ່ມີສາຍໃນຫົວຂໍ້ນີ້.
ບົດຄວາມຈະທັບຊ້ອນກັນໃນຫຼາຍດ້ານ.

LAN DC ມີ 4 DCs, ປະມານ 250 ສະວິດ, ເຄິ່ງຫນຶ່ງອາຍແກັ routers ແລະຄູ່ນ່ຶຂອງ firewalls.
ບໍ່ແມ່ນເຟສບຸກ, ແຕ່ພຽງພໍທີ່ຈະເຮັດໃຫ້ທ່ານຄິດເລິກເຊິ່ງກ່ຽວກັບອັດຕະໂນມັດ.
ຢ່າງໃດກໍຕາມ, ມີຄວາມຄິດເຫັນວ່າຖ້າທ່ານມີຫຼາຍກວ່າ 1 ອຸປະກອນ, ອັດຕະໂນມັດແມ່ນຈໍາເປັນ.
ໃນຄວາມເປັນຈິງ, ມັນເປັນການຍາກທີ່ຈະຈິນຕະນາການວ່າທຸກຄົນສາມາດດໍາລົງຊີວິດໂດຍບໍ່ມີການຢ່າງຫນ້ອຍຊຸດຂອງຫົວເຂົ່າ.
ເຖິງແມ່ນວ່າຂ້ອຍໄດ້ຍິນວ່າມີຫ້ອງການທີ່ທີ່ຢູ່ IP ຖືກເກັບໄວ້ໃນ Excel, ແລະແຕ່ລະພັນອຸປະກອນເຄືອຂ່າຍຖືກຕັ້ງຄ່າດ້ວຍຕົນເອງແລະມີການຕັ້ງຄ່າທີ່ເປັນເອກະລັກຂອງຕົນເອງ. ນີ້, ແນ່ນອນ, ສາມາດຖືກຖ່າຍທອດອອກເປັນສິລະປະທີ່ທັນສະໄຫມ, ແຕ່ຄວາມຮູ້ສຶກຂອງວິສະວະກອນຈະຜິດຫວັງແນ່ນອນ.

ຈຸດປະສົງ

ໃນປັດຈຸບັນພວກເຮົາຈະກໍານົດເປົ້າຫມາຍທີ່ບໍ່ມີຕົວຕົນຫຼາຍທີ່ສຸດ:

• ເຄືອຂ່າຍແມ່ນຄ້າຍຄືອົງການຈັດຕັ້ງດຽວ
• ການ​ທົດ​ສອບ​ການ​ຕັ້ງ​ຄ່າ​
• ເວີຊັ່ນສະຖານະເຄືອຂ່າຍ
• ການຕິດຕາມແລະການປິ່ນປົວຕົນເອງຂອງການບໍລິການ

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

ເຄືອຂ່າຍແມ່ນຄ້າຍຄືອົງການຈັດຕັ້ງດຽວ

ປະໂຫຍກທີ່ກໍານົດຂອງຊຸດ, ເຖິງແມ່ນວ່າຢູ່ glance ທໍາອິດມັນອາດຈະເບິ່ງຄືວ່າບໍ່ສໍາຄັນຫຼາຍ: ພວກເຮົາຈະຕັ້ງຄ່າເຄືອຂ່າຍ, ບໍ່ແມ່ນອຸປະກອນສ່ວນບຸກຄົນ.
​ໃນ​ຊຸມ​ປີ​ມໍ່ໆ​ມາ​ນີ້, ພວກ​ເຮົາ​ໄດ້​ເຫັນ​ການ​ປ່ຽນ​ແປງ​ໃນ​ການ​ເນັ້ນ​ໜັກ​ເຖິງ​ການ​ຮັກສາ​ເຄືອ​ຂ່າຍ​ເປັນ​ຫົວໜ່ວຍ​ດຽວ, ດ້ວຍ​ເຫດ​ນີ້, ໂປແກຼມເຄືອຂ່າຍທີ່ຖືກ ກຳ ນົດ, ເຄືອຂ່າຍທີ່ຂັບເຄື່ອນໂດຍຕັ້ງໃຈ и ເຄືອຂ່າຍປົກຄອງຕົນເອງ.
ຫຼັງຈາກທີ່ທັງຫມົດ, ສິ່ງທີ່ແອັບພລິເຄຊັນຕ້ອງການທົ່ວໂລກຈາກເຄືອຂ່າຍ: ການເຊື່ອມຕໍ່ລະຫວ່າງຈຸດ A ແລະ B (ດີ, ບາງຄັ້ງ +B-Z) ແລະການໂດດດ່ຽວຈາກແອັບພລິເຄຊັນແລະຜູ້ໃຊ້ອື່ນໆ.

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

ນັ້ນແມ່ນ, ຍົກຕົວຢ່າງ, ຖ້າພວກເຮົາຕັດສິນໃຈວ່າຕັ້ງແຕ່ນີ້ໄປ rack switches ໃນ Kazan ຄວນປະກາດສອງເຄືອຂ່າຍແທນທີ່ຈະເປັນຫນຶ່ງ, ພວກເຮົາ.

1. ກ່ອນອື່ນ ໝົດ ພວກເຮົາບັນທຶກການປ່ຽນແປງໃນລະບົບ
2. ການສ້າງການຕັ້ງຄ່າເປົ້າຫມາຍຂອງອຸປະກອນເຄືອຂ່າຍທັງຫມົດ
3. ພວກເຮົາເປີດຕົວໂຄງການປັບປຸງການຕັ້ງຄ່າເຄືອຂ່າຍ, ເຊິ່ງຄິດໄລ່ສິ່ງທີ່ຕ້ອງການເອົາອອກໃນແຕ່ລະ node, ສິ່ງທີ່ຈະເພີ່ມ, ແລະນໍາ nodes ໄປສູ່ສະຖານະທີ່ຕ້ອງການ.

ໃນເວລາດຽວກັນ, ພວກເຮົາເຮັດການປ່ຽນແປງດ້ວຍຕົນເອງພຽງແຕ່ໃນຂັ້ນຕອນທໍາອິດ.

ການ​ທົດ​ສອບ​ການ​ຕັ້ງ​ຄ່າ​

ເປັນທີ່ຮູ້ຈັກວ່າ 80% ຂອງບັນຫາເກີດຂຶ້ນໃນລະຫວ່າງການປ່ຽນແປງການຕັ້ງຄ່າ - ຫຼັກຖານທາງອ້ອມຂອງເລື່ອງນີ້ແມ່ນວ່າໃນວັນພັກປີໃຫມ່, ທຸກສິ່ງທຸກຢ່າງມັກຈະສະຫງົບ.
ຂ້າພະເຈົ້າໄດ້ເປັນພະຍານເຖິງການຢຸດງານທົ່ວໂລກຫຼາຍສິບຄັ້ງເນື່ອງຈາກຄວາມຜິດພາດຂອງມະນຸດ: ຄໍາສັ່ງທີ່ບໍ່ຖືກຕ້ອງ, ການຕັ້ງຄ່າຖືກປະຕິບັດໃນສາຂາທີ່ບໍ່ຖືກຕ້ອງ, ຊຸມຊົນລືມ, MPLS ຖືກທໍາລາຍທົ່ວໂລກໃນ router, ຫ້າຊິ້ນຂອງຮາດແວຖືກຕັ້ງຄ່າ, ແຕ່ຄວາມຜິດພາດບໍ່ແມ່ນ. ສັງເກດເຫັນໃນວັນທີຫົກ, ການປ່ຽນແປງເກົ່າທີ່ເຮັດໂດຍຄົນອື່ນໄດ້ຖືກສັນຍາ. ມີສະຖານະການຫຼາຍໂຕນ.

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

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

ເມື່ອທ່ານຄຸ້ນເຄີຍກັບແນວຄວາມຄິດຂອງເຄືອຂ່າຍ CI / CD, ຂ້າມຄືນວິທີການກວດສອບການຕັ້ງຄ່າໂດຍການໃຊ້ມັນກັບເຄືອຂ່າຍການຜະລິດຈະເບິ່ງຄືວ່າບໍ່ມີຄວາມຮູ້ກ່ຽວກັບຍຸກກາງ. ຄ້າຍ​ຄື​ຕີ​ຫົວ​ຮົບ​ດ້ວຍ​ຄ້ອນ​ຕີ.

ການສືບຕໍ່ອິນຊີຂອງແນວຄວາມຄິດກ່ຽວກັບ ລະບົບ ການຈັດການເຄືອຂ່າຍ ແລະ CI/CD ກາຍເປັນສະບັບເຕັມຂອງການຕັ້ງຄ່າ.

ຮຸ່ນ

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

ໃຫ້ເວົ້າວ່າສະບັບປະຈຸບັນແມ່ນ 1.0.0.
ທີ່ຢູ່ IP ຂອງການໂຕ້ຕອບ Loopback ຢູ່ໃນຫນຶ່ງໃນ ToRs ມີການປ່ຽນແປງບໍ? ນີ້​ແມ່ນ​ເປັນ​ສະ​ບັບ​ເລັກ​ນ້ອຍ​ແລະ​ຈະ​ເປັນ​ເລກ 1.0.1​.
ພວກເຮົາໄດ້ປັບປຸງນະໂຍບາຍການນໍາເຂົ້າເສັ້ນທາງເຂົ້າໄປໃນ BGP - ເລັກນ້ອຍຢ່າງຮຸນແຮງ - ແລ້ວ 1.1.0
ພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະກໍາຈັດ IGP ແລະປ່ຽນເປັນ BGP ເທົ່ານັ້ນ - ນີ້ແມ່ນການປ່ຽນແປງການອອກແບບຮາກແລ້ວ - 2.0.0.

ໃນເວລາດຽວກັນ, DCs ທີ່ແຕກຕ່າງກັນອາດຈະມີຮຸ່ນທີ່ແຕກຕ່າງກັນ - ເຄືອຂ່າຍກໍາລັງພັດທະນາ, ອຸປະກອນໃຫມ່ກໍາລັງຖືກຕິດຕັ້ງ, ລະດັບໃຫມ່ຂອງກະດູກສັນຫຼັງຈະຖືກເພີ່ມຢູ່ບ່ອນໃດຫນຶ່ງ, ບໍ່ແມ່ນຢູ່ໃນບ່ອນອື່ນ, ແລະອື່ນໆ.

ກ່ຽວກັບ ສະບັບພາສາ semantic ພວກເຮົາຈະສົນທະນາໃນບົດຄວາມແຍກຕ່າງຫາກ.

ຂ້ອຍເຮັດເລື້ມຄືນ - ການປ່ຽນແປງໃດໆ (ຍົກເວັ້ນຄໍາສັ່ງ debugging) ແມ່ນການປັບປຸງສະບັບ. ຜູ້ເບິ່ງແຍງລະບົບຕ້ອງໄດ້ຮັບການແຈ້ງໃຫ້ຮູ້ກ່ຽວກັບການ deviations ຈາກສະບັບປະຈຸບັນ.

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

ການຕິດຕາມແລະການປິ່ນປົວຕົນເອງຂອງການບໍລິການ

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

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

ພວກເຮົາຈະຕ້ອງການອັນໃດເພື່ອປະຕິບັດແຜນການທີ່ທະເຍີທະຍານດັ່ງກ່າວ?

• ມີບັນຊີລາຍຊື່ຂອງອຸປະກອນທັງຫມົດໃນເຄືອຂ່າຍ, ສະຖານທີ່ຂອງເຂົາເຈົ້າ, ພາລະບົດບາດ, ຮູບແບບ, ສະບັບຊອບແວ.
  kazan-leaf-1.lmu.net, Kazan, ໃບ, Juniper QFX 5120, R18.3.
• ມີລະບົບການອະທິບາຍການບໍລິການເຄືອຂ່າຍ.
  IGP, BGP, L2/3VPN, ນະໂຍບາຍ, ACL, NTP, SSH.
• ສາມາດເລີ່ມຕົ້ນອຸປະກອນ.
  ຊື່ເຈົ້າພາບ, Mgmt IP, ເສັ້ນທາງ Mgmt, ຜູ້ໃຊ້, RSA-Keys, LLDP, NETCONF
• ຕັ້ງຄ່າອຸປະກອນ ແລະນໍາເອົາການຕັ້ງຄ່າໄປສູ່ເວີຊັນທີ່ຕ້ອງການ (ລວມທັງເກົ່າ).
• ທົດສອບການຕັ້ງຄ່າ
• ກວດເບິ່ງສະຖານະຂອງອຸປະກອນທັງໝົດເປັນໄລຍະໆເພື່ອຄວາມບ່ຽງເບນຈາກອຸປະກອນປະຈຸບັນ ແລະ ລາຍງານໃຫ້ຜູ້ທີ່ມັນຄວນຈະເປັນ.
  ຂ້າມຄືນ, ບາງຄົນໄດ້ເພີ່ມກົດລະບຽບໃສ່ ACL ຢ່າງງຽບໆ.
• ຕິດຕາມປະສິດທິພາບ.

ໝາຍ ຄວາມວ່າ

ມັນມີສຽງສັບສົນພໍທີ່ຈະເລີ່ມ decomposing ໂຄງການເຂົ້າໄປໃນອົງປະກອບ.

ແລະ​ຈະ​ມີ​ສິບ​ຂອງ​ເຂົາ​ເຈົ້າ​:

1. ລະບົບສາງ
2. ລະບົບການຄຸ້ມຄອງພື້ນທີ່ IP
3. ລະບົບລາຍລະອຽດການບໍລິການເຄືອຂ່າຍ
4. ກົນໄກການເລີ່ມຕົ້ນອຸປະກອນ
5. ຮູບແບບການກຳນົດຄ່າຜູ້ຂາຍ-ບໍ່ເຊື່ອຟັງ
6. ອິນເຕີເຟດໄດເວີສະເພາະຜູ້ຂາຍ
7. ກົນໄກການສົ່ງການຕັ້ງຄ່າໃຫ້ກັບອຸປະກອນ
8. CI / CD
9. ກົນໄກສໍາລັບການສໍາຮອງແລະຊອກຫາ deviations
10. ລະບົບການຕິດຕາມ

ນີ້, ໂດຍວິທີທາງການ, ເປັນຕົວຢ່າງຂອງວິທີການເບິ່ງເປົ້າຫມາຍຂອງວົງຈອນໄດ້ປ່ຽນແປງ - ມີ 4 ອົງປະກອບໃນຮ່າງ.

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

ອົງປະກອບທີ 1: ລະບົບສາງ

ແນ່ນອນ, ພວກເຮົາຕ້ອງການຮູ້ວ່າອຸປະກອນໃດຕັ້ງຢູ່ບ່ອນໃດ, ເຊື່ອມຕໍ່ກັບຫຍັງ.
ລະບົບສາງແມ່ນພາກສ່ວນໜຶ່ງຂອງວິສາຫະກິດໃດນຶ່ງ.
ສ່ວນຫຼາຍມັກ, ວິສາຫະກິດມີລະບົບສາງແຍກຕ່າງຫາກສໍາລັບອຸປະກອນເຄືອຂ່າຍ, ເຊິ່ງແກ້ໄຂບັນຫາສະເພາະຫຼາຍ.
ເປັນສ່ວນຫນຶ່ງຂອງຊຸດຂອງບົດຄວາມນີ້, ພວກເຮົາຈະເອີ້ນວ່າ DCIM - Data Center Infrastructure Management . ເຖິງແມ່ນວ່າຄໍາສັບ DCIM ຕົວຂອງມັນເອງ, ເວົ້າຢ່າງເຂັ້ມງວດ, ປະກອບມີຫຼາຍ.

ສໍາລັບຈຸດປະສົງຂອງພວກເຮົາ, ພວກເຮົາຈະເກັບຮັກສາຂໍ້ມູນຕໍ່ໄປນີ້ກ່ຽວກັບອຸປະກອນຢູ່ໃນມັນ:

• ຈຳ ນວນສິນຄ້າຄົງຄັງ
• ຊື່/ຄຳອະທິບາຍ
• ຕົວແບບ (Huawei CE12800, Juniper QFX5120, ແລະອື່ນໆ.)
• ຕົວກໍານົດການລັກສະນະ (ກະດານ, ການໂຕ້ຕອບ, ແລະອື່ນໆ.)
• ບົດບາດ (ໃບ, ກະດູກສັນຫຼັງ, Router ຊາຍແດນ, ແລະອື່ນໆ.)
• ສະຖານທີ່ (ພາກພື້ນ, ເມືອງ, ສູນຂໍ້ມູນ, rack, ຫນ່ວຍງານ)
• ການເຊື່ອມຕໍ່ລະຫວ່າງອຸປະກອນ
• Topology ເຄືອຂ່າຍ

ມັນເປັນທີ່ຊັດເຈນຢ່າງສົມບູນວ່າພວກເຮົາເອງຕ້ອງການຮູ້ທັງຫມົດນີ້.
ແຕ່ນີ້ຈະຊ່ວຍສໍາລັບຈຸດປະສົງອັດຕະໂນມັດບໍ?
ບໍ່ຕ້ອງສົງໃສ.
ຕົວຢ່າງເຊັ່ນ, ພວກເຮົາຮູ້ວ່າຢູ່ໃນສູນຂໍ້ມູນທີ່ໃຫ້ຢູ່ໃນສະວິດ Leaf, ຖ້າມັນເປັນ Huawei, ACLs ເພື່ອກັ່ນຕອງການຈະລາຈອນທີ່ແນ່ນອນຄວນຈະຖືກນໍາໃຊ້ໃນ VLAN, ແລະຖ້າມັນເປັນ Juniper, ຫຼັງຈາກນັ້ນຢູ່ໃນຫນ່ວຍ 0 ຂອງການໂຕ້ຕອບທາງດ້ານຮ່າງກາຍ.
ຫຼືທ່ານຕ້ອງການເປີດຕົວເຊີບເວີ Syslog ໃໝ່ໃຫ້ກັບທຸກຂອບໃນພາກພື້ນ.

ໃນມັນພວກເຮົາຈະເກັບຮັກສາອຸປະກອນເຄືອຂ່າຍ virtual, ຕົວຢ່າງເຊັ່ນ routers virtual ຫຼືຕົວສະທ້ອນຮາກ. ພວກເຮົາສາມາດເພີ່ມເຄື່ອງແມ່ຂ່າຍ DNS, NTP, Syslog ແລະໂດຍທົ່ວໄປແລ້ວທຸກສິ່ງທຸກຢ່າງທີ່ກ່ຽວກັບເຄືອຂ່າຍຫນຶ່ງຫຼືທາງອື່ນ.

ອົງປະກອບທີ 2: ລະບົບການຈັດການພື້ນທີ່ IP

ແມ່ນແລ້ວ, ແລະໃນປັດຈຸບັນມີທີມງານຜູ້ທີ່ຕິດຕາມຄໍານໍາຫນ້າແລະທີ່ຢູ່ IP ໃນໄຟລ໌ Excel. ແຕ່ວິທີການທີ່ທັນສະໄຫມຍັງເປັນຖານຂໍ້ມູນ, ມີຫນ້າດ້ານຫນ້າກ່ຽວກັບ nginx / apache, API ແລະຫນ້າທີ່ກວ້າງຂວາງສໍາລັບການບັນທຶກທີ່ຢູ່ IP ແລະເຄືອຂ່າຍແບ່ງອອກເປັນ VRFs.
IPAM - ການຈັດການທີ່ຢູ່ IP.

ສໍາລັບຈຸດປະສົງຂອງພວກເຮົາ, ພວກເຮົາຈະເກັບຂໍ້ມູນຕໍ່ໄປນີ້ໄວ້ໃນມັນ:

• VLANs
• VRF
• ເຄືອຂ່າຍ/ເຄືອຂ່າຍຍ່ອຍ
• ທີ່ຢູ່ IP
• ຜູກມັດທີ່ຢູ່ກັບອຸປະກອນ, ເຄືອຂ່າຍໄປຫາສະຖານທີ່ ແລະໝາຍເລກ VLAN

ອີກເທື່ອຫນຶ່ງ, ມັນເປັນທີ່ຊັດເຈນວ່າພວກເຮົາຕ້ອງການໃຫ້ແນ່ໃຈວ່າເມື່ອພວກເຮົາຈັດສັນທີ່ຢູ່ IP ໃຫມ່ສໍາລັບ ToR loopback, ພວກເຮົາຈະບໍ່ stumble ກັບຄວາມຈິງທີ່ວ່າມັນຖືກມອບຫມາຍໃຫ້ຜູ້ໃດຜູ້ຫນຶ່ງ. ຫຼືວ່າພວກເຮົາໃຊ້ຄໍານໍາຫນ້າດຽວກັນສອງຄັ້ງຢູ່ປາຍທີ່ແຕກຕ່າງກັນຂອງເຄືອຂ່າຍ.
ແຕ່ນີ້ຊ່ວຍແນວໃດກັບອັດຕະໂນມັດ?
ງ່າຍດາຍ.
ພວກເຮົາຮ້ອງຂໍຄໍານໍາຫນ້າໃນລະບົບທີ່ມີບົດບາດ Loopbacks, ເຊິ່ງປະກອບດ້ວຍທີ່ຢູ່ IP ທີ່ມີຢູ່ສໍາລັບການຈັດສັນ - ຖ້າພົບ, ພວກເຮົາຈັດສັນທີ່ຢູ່, ຖ້າບໍ່ແມ່ນ, ພວກເຮົາຮ້ອງຂໍໃຫ້ມີການສ້າງຄໍານໍາຫນ້າໃຫມ່.
ຫຼືເມື່ອສ້າງການຕັ້ງຄ່າອຸປະກອນ, ພວກເຮົາສາມາດຊອກຫາຈາກລະບົບດຽວກັນທີ່ VRF ການໂຕ້ຕອບຄວນຈະຕັ້ງຢູ່.
ແລະໃນເວລາທີ່ເລີ່ມຕົ້ນເຄື່ອງແມ່ຂ່າຍໃຫມ່, script ເຂົ້າໄປໃນລະບົບ, ຊອກຫາວ່າ switch server ຢູ່ໃນ, ທີ່ port ແລະ subnet ທີ່ຖືກມອບຫມາຍໃຫ້ກັບການໂຕ້ຕອບ - ແລະຈະຈັດສັນທີ່ຢູ່ຂອງເຄື່ອງແມ່ຂ່າຍຈາກມັນ.

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

ອົງປະກອບ 3. ລະບົບການອະທິບາຍການບໍລິການເຄືອຂ່າຍ

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

• ພື້ນຖານໂຄງລ່າງ
• ລູກ​ຄ້າ.

ອະດີດໄດ້ຖືກອອກແບບເພື່ອສະຫນອງການເຊື່ອມຕໍ່ພື້ນຖານແລະການຄວບຄຸມອຸປະກອນ. ເຫຼົ່ານີ້ລວມມີ VTY, SNMP, NTP, Syslog, AAA, ໂປຣໂຕຄໍເສັ້ນທາງ, CoPP, ແລະອື່ນໆ.
ສຸດທ້າຍຈັດການບໍລິການສໍາລັບລູກຄ້າ: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, ແລະອື່ນໆ.
ແນ່ນອນ, ຍັງມີກໍລະນີຊາຍແດນ - ບ່ອນທີ່ຈະປະກອບມີ MPLS LDP, BGP? ແມ່ນແລ້ວ, ແລະໂປຣໂຕຄອນການກຳນົດເສັ້ນທາງສາມາດນຳໃຊ້ໄດ້ສຳລັບລູກຄ້າ. ແຕ່ນີ້ບໍ່ສໍາຄັນ.

ທັງສອງປະເພດຂອງການບໍລິການແມ່ນ decomposed ເຂົ້າໄປໃນ primitives ການຕັ້ງຄ່າ:

• ການໂຕ້ຕອບທາງກາຍະພາບ ແລະເຫດຜົນ (tag/anteg, mtu)
• ທີ່ຢູ່ IP ແລະ VRF (IP, IPv6, VRF)
• ACLs ແລະນະໂຍບາຍການປຸງແຕ່ງການຈະລາຈອນ
• ໂປຣໂຕຄໍ (IGP, BGP, MPLS)
• ນະ​ໂຍ​ບາຍ​ການ​ກໍາ​ນົດ​ເສັ້ນ​ທາງ (ຄໍາ​ນໍາ​ຫນ້າ​ບັນ​ຊີ​ລາຍ​ການ​, ຊຸມ​ຊົນ​, ຕົວ​ກັ່ນ​ຕອງ ASN​)​.
• ການບໍລິການຜົນປະໂຫຍດ (SSH, NTP, LLDP, Syslog ... )
• ເປັນຕົ້ນ.

ພວກເຮົາຈະເຮັດແນວໃດແນ່ນອນ, ຂ້າພະເຈົ້າຍັງບໍ່ທັນມີຄວາມຄິດ. ພວກເຮົາຈະເບິ່ງມັນຢູ່ໃນບົດຄວາມແຍກຕ່າງຫາກ.

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

ອົງປະກອບທີ 4: ກົນໄກການເລີ່ມຕົ້ນອຸປະກອນ

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

1. ໃສ່ອຸປະກອນໃນລະບົບສາງ.
2. ເລືອກທີ່ຢູ່ IP ການຈັດການ.
3. ຕັ້ງຄ່າການເຂົ້າເຖິງພື້ນຖານຂອງມັນ:
   ຊື່ເຈົ້າພາບ, ທີ່ຢູ່ IP ການຈັດການ, ເສັ້ນທາງໄປຫາເຄືອຂ່າຍການຈັດການ, ຜູ້ໃຊ້, ກະແຈ SSH, ໂປຣໂຕຄໍ - telnet/SSH/NETCONF

ມີ​ສາມ​ວິ​ທີ​ການ​:

• ທຸກສິ່ງທຸກຢ່າງແມ່ນຄູ່ມືຢ່າງສົມບູນ. ອຸປະກອນຖືກນໍາມາໃສ່ບ່ອນຕັ້ງ, ບ່ອນທີ່ບຸກຄົນທົ່ວໄປທົ່ວໄປຈະເຂົ້າໄປໃນລະບົບຕ່າງໆ, ເຊື່ອມຕໍ່ກັບ console ແລະ configure ມັນ. ສາມາດເຮັດວຽກຢູ່ໃນເຄືອຂ່າຍ static ຂະຫນາດນ້ອຍ.
• ZTP - Zero Touch Provisioning. ຮາດແວມາຮອດ, ຢືນຂຶ້ນ, ໄດ້ຮັບທີ່ຢູ່ຜ່ານ DHCP, ໄປຫາເຄື່ອງແມ່ຂ່າຍພິເສດ, ແລະຕັ້ງຄ່າຕົວມັນເອງ.
• ໂຄງສ້າງພື້ນຖານຂອງເຄື່ອງແມ່ຂ່າຍຂອງ console, ບ່ອນທີ່ການຕັ້ງຄ່າເບື້ອງຕົ້ນເກີດຂຶ້ນໂດຍຜ່ານພອດ console ໃນໂຫມດອັດຕະໂນມັດ.

ພວກເຮົາຈະເວົ້າກ່ຽວກັບສາມຢ່າງໃນບົດຄວາມແຍກຕ່າງຫາກ.

ອົງປະກອບທີ 5: ຮູບແບບການກຳນົດຄ່າຂອງຜູ້ຂາຍ-agnostic

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

1. ຢ່າປັບຕົວເຂົ້າກັບສ່ວນຕິດຕໍ່ສະເພາະສໍາລັບການພົວພັນກັບອຸປະກອນ. ບໍ່ວ່າຈະເປັນ CLI, NETCONF, RESTCONF, SNMP - ຮູບແບບຈະຄືກັນ.
2. ຢ່າຮັກສາຈໍານວນແມ່ແບບ / ສະຄິບຕາມຈໍານວນຜູ້ຂາຍໃນເຄືອຂ່າຍ, ແລະຖ້າການອອກແບບປ່ຽນແປງ, ໃຫ້ປ່ຽນສິ່ງດຽວກັນໃນຫຼາຍໆບ່ອນ.
3. ໂຫຼດການຕັ້ງຄ່າຈາກອຸປະກອນ (ສໍາຮອງຂໍ້ມູນ), ເຮັດໃຫ້ມັນເຂົ້າໄປໃນຮູບແບບດຽວກັນແລະປຽບທຽບໂດຍກົງກັບການຕັ້ງຄ່າເປົ້າຫມາຍທີ່ມີຢູ່ແລ້ວເພື່ອຄິດໄລ່ delta ແລະກະກຽມ patch ການຕັ້ງຄ່າທີ່ຈະປ່ຽນພຽງແຕ່ພາກສ່ວນທີ່ຈໍາເປັນຫຼືເພື່ອກໍານົດ deviations.

ເປັນຜົນມາຈາກຂັ້ນຕອນນີ້, ພວກເຮົາໄດ້ຮັບການຕັ້ງຄ່າເອກະລາດຈາກຜູ້ຂາຍ.

ອົງປະກອບ 6. ການໂຕ້ຕອບຂອງໄດເວີສະເພາະຜູ້ຂາຍ

ທ່ານບໍ່ຄວນຍົກຍ້ອງຕົວເອງດ້ວຍຄວາມຫວັງວ່າມື້ຫນຶ່ງມັນຈະເປັນໄປໄດ້ທີ່ຈະກໍາຫນົດຄ່າ ciska ໃນແບບດຽວກັນກັບ Juniper, ພຽງແຕ່ສົ່ງສາຍດຽວກັນກັບພວກເຂົາ. ເຖິງວ່າຈະມີຄວາມນິຍົມເພີ່ມຂຶ້ນຂອງກ່ອງຂາວແລະການປະກົດຕົວຂອງການສະຫນັບສະຫນູນສໍາລັບ NETCONF, RESTCONF, OpenConfig, ເນື້ອຫາສະເພາະທີ່ໂປໂຕຄອນເຫຼົ່ານີ້ໃຫ້ແຕກຕ່າງຈາກຜູ້ຂາຍກັບຜູ້ຂາຍ, ແລະນີ້ແມ່ນຫນຶ່ງໃນຄວາມແຕກຕ່າງດ້ານການແຂ່ງຂັນຂອງພວກເຂົາທີ່ພວກເຂົາຈະບໍ່ຍອມແພ້ງ່າຍ.
ນີ້ແມ່ນປະມານຄືກັນກັບ OpenContrail ແລະ OpenStack, ທີ່ມີ RestAPI ເປັນການໂຕ້ຕອບ NorthBound ຂອງພວກເຂົາ, ຄາດວ່າຈະມີການໂທທີ່ແຕກຕ່າງກັນຫມົດ.

ດັ່ງນັ້ນ, ໃນຂັ້ນຕອນທີຫ້າ, ຮູບແບບຜູ້ຂາຍເອກະລາດຕ້ອງເອົາຮູບແບບທີ່ມັນຈະໄປຫາຮາດແວ.
ແລະໃນທີ່ນີ້ວິທີການທັງຫມົດແມ່ນດີ (ບໍ່): CLI, NETCONF, RESTCONF, SNMP ງ່າຍດາຍ.

ດັ່ງນັ້ນ, ພວກເຮົາຈະຕ້ອງການໄດເວີທີ່ຈະໂອນຜົນໄດ້ຮັບຂອງຂັ້ນຕອນທີ່ຜ່ານມາເຂົ້າໄປໃນຮູບແບບທີ່ຕ້ອງການຂອງຜູ້ຂາຍສະເພາະ: ຊຸດຄໍາສັ່ງ CLI, ໂຄງສ້າງ XML.

ອົງປະກອບ 7. ກົນໄກການສົ່ງການຕັ້ງຄ່າໃຫ້ກັບອຸປະກອນ

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

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (ເຖິງແມ່ນວ່າມັນເປັນການເກີນກວ່າເພາະວ່າມັນເປັນວິທີທີ່ຈະສົ່ງ FIB, ບໍ່ແມ່ນການຕັ້ງຄ່າ)

ໃຫ້ຈຸດ t ຢູ່ທີ່ນີ້. CLI ເປັນມໍລະດົກ. SNMP... ໄອ ໄອ.
RESTCONF ຍັງເປັນສັດທີ່ບໍ່ຮູ້ຈັກ; REST API ໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍເກືອບບໍ່ມີໃຜ. ດັ່ງນັ້ນ, ພວກເຮົາຈະສຸມໃສ່ NETCONF ໃນຊຸດ.

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

ທີສອງ, ແລະພວກເຮົາຈະເຮັດແນວໃດກັບເຄື່ອງມືນີ້?
ນອກຈາກນີ້ຍັງມີທາງເລືອກຂະຫນາດໃຫຍ່ຢູ່ທີ່ນີ້:

• script ທີ່ຂຽນດ້ວຍຕົນເອງຫຼືເວທີ. ໃຫ້ແຂນຕົວເຮົາເອງກັບ ncclient ແລະ asyncIO ແລະເຮັດທຸກຢ່າງດ້ວຍຕົວເຮົາເອງ. ມັນມີມູນຄ່າຫຍັງໃຫ້ພວກເຮົາສ້າງລະບົບການນໍາໃຊ້ຕັ້ງແຕ່ເລີ່ມຕົ້ນ?
• Ansible ກັບຫ້ອງສະຫມຸດທີ່ອຸດົມສົມບູນຂອງໂມດູນເຄືອຂ່າຍ.
• ເກືອທີ່ມີການເຮັດວຽກຫນ້ອຍຂອງມັນກັບເຄືອຂ່າຍແລະການເຊື່ອມຕໍ່ກັບ Napalm.
• ຕົວຈິງແລ້ວ Napalm, ເຊິ່ງຮູ້ຈັກຜູ້ຂາຍສອງສາມຄົນແລະນັ້ນແມ່ນ, ສະບາຍດີ.
• Nornir ເປັນສັດອີກຊະນິດຫນຶ່ງທີ່ພວກເຮົາຈະທໍາລາຍໃນອະນາຄົດ.

ທີ່ນີ້ favorite ຍັງບໍ່ທັນໄດ້ເລືອກ - ພວກເຮົາຈະຊອກຫາ.

ມີຫຍັງອີກແດ່ທີ່ສໍາຄັນຢູ່ທີ່ນີ້? ຜົນສະທ້ອນຂອງການນໍາໃຊ້ການຕັ້ງຄ່າ.
ປະສົບຜົນສໍາເລັດຫຼືບໍ່. ຍັງມີການເຂົ້າເຖິງຮາດແວຫຼືບໍ່?
ມັນເບິ່ງຄືວ່າຄໍາຫມັ້ນສັນຍາຈະຊ່ວຍໃຫ້ມີການຢືນຢັນແລະການກວດສອບຄວາມຖືກຕ້ອງຂອງສິ່ງທີ່ໄດ້ດາວໂຫລດມາໃສ່ອຸປະກອນ.
ນີ້, ບວກກັບການປະຕິບັດທີ່ຖືກຕ້ອງຂອງ NETCONF, ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຂອງອຸປະກອນທີ່ເຫມາະສົມ - ບໍ່ມີຜູ້ຜະລິດຈໍານວນຫຼາຍສະຫນັບສະຫນູນຄໍາຫມັ້ນສັນຍາປົກກະຕິ. ແຕ່ນີ້ແມ່ນພຽງແຕ່ຫນຶ່ງໃນເງື່ອນໄຂເບື້ອງຕົ້ນໃນ RFP. ໃນທີ່ສຸດ, ບໍ່ມີໃຜກັງວົນວ່າບໍ່ແມ່ນຜູ້ຂາຍລັດເຊຍດຽວຈະປະຕິບັດຕາມເງື່ອນໄຂການໂຕ້ຕອບ 32 * 100GE. ຫຼືລາວເປັນຫ່ວງ?

ອົງປະກອບ 8. CI/CD

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

ແຕ່, ດັ່ງທີ່ໄດ້ກ່າວມາແລ້ວຂ້າງເທິງ, ພວກເຮົາບໍ່ແມ່ນຄົນປ່າບາງຄົນທີ່ຕ້ອງການມ້ວນທຸກຢ່າງໂດຍກົງເຂົ້າໃນການຜະລິດ.
ການຕັ້ງຄ່າທີ່ສ້າງຂຶ້ນຈະຕ້ອງຜ່ານ Pipeline CI/CD ກ່ອນ.

CI/CD ຫຍໍ້ມາຈາກ ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ, ການນຳໃຊ້ຢ່າງຕໍ່ເນື່ອງ. ນີ້ແມ່ນວິທີການທີ່ທີມງານບໍ່ພຽງແຕ່ວາງອອກໃຫມ່ທີ່ສໍາຄັນໃນທຸກໆຫົກເດືອນ, ແທນທີ່ເກົ່າຢ່າງສົມບູນ, ແຕ່ຍັງເປັນປະຈໍາ incrementally ປະຕິບັດ (Deployment) ຟັງຊັນໃຫມ່ໃນສ່ວນຂະຫນາດນ້ອຍ, ແຕ່ລະແມ່ນການທົດສອບທີ່ສົມບູນແບບສໍາລັບຄວາມເຂົ້າກັນໄດ້, ຄວາມປອດໄພແລະ. ການປະຕິບັດ (ການປະສົມປະສານ).

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

ມີຂໍ້ຍົກເວັ້ນຂອງຄໍາສັ່ງ debugging, ຢ່າງແທ້ຈິງການປ່ຽນແປງທັງຫມົດໃນເຄືອຂ່າຍຕ້ອງຜ່ານ CI / CD Pipeline - ນີ້ແມ່ນການຮັບປະກັນຂອງພວກເຮົາຂອງຊີວິດທີ່ງຽບສະຫງົບແລະການເຮັດວຽກທີ່ຍາວນານ, ມີຄວາມສຸກ.

ອົງປະກອບ 9. ລະບົບກວດຫາຂໍ້ມູນສຳຮອງ ແລະ ຜິດປົກກະຕິ

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

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

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

ຕົວຢ່າງ, ກົດລະບຽບຂອງ Firewall ສໍາລັບການນັບຈໍານວນແພັກເກັດຕໍ່ IP ສະເພາະເພື່ອທ້ອງຖິ່ນແກ້ໄຂບັນຫາແມ່ນເປັນການຕັ້ງຄ່າຊົ່ວຄາວທໍາມະດາຢ່າງສົມບູນ.

ອົງປະກອບ 10. ລະບົບການຕິດຕາມ

ໃນຕອນທໍາອິດ, ຂ້າພະເຈົ້າຈະບໍ່ໄດ້ກວມເອົາຫົວຂໍ້ຂອງການຕິດຕາມ - ມັນຍັງເປັນຫົວຂໍ້ voluminous, controversial ແລະສະລັບສັບຊ້ອນ. ແຕ່ເມື່ອສິ່ງຕ່າງໆໄດ້ກ້າວຫນ້າ, ມັນໄດ້ຫັນອອກວ່ານີ້ແມ່ນສ່ວນຫນຶ່ງທີ່ສໍາຄັນຂອງອັດຕະໂນມັດ. ແລະມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຂ້າມມັນ, ເຖິງແມ່ນວ່າບໍ່ມີການປະຕິບັດ.

Evolving Thought ແມ່ນສ່ວນໜຶ່ງຂອງຂະບວນການ CI/CD. ຫຼັງ​ຈາກ​ການ​ວາງ​ອອກ​ການ​ຕັ້ງ​ຄ່າ​ກັບ​ເຄືອ​ຂ່າຍ​, ພວກ​ເຮົາ​ຈໍາ​ເປັນ​ຕ້ອງ​ສາ​ມາດ​ກໍາ​ນົດ​ວ່າ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ແມ່ນ​ເຫມາະ​ສົມ​ກັບ​ມັນ​ໃນ​ປັດ​ຈຸ​ບັນ​.
ແລະພວກເຮົາກໍາລັງເວົ້າບໍ່ພຽງແຕ່ແລະບໍ່ຫຼາຍປານໃດກ່ຽວກັບຕາຕະລາງການນໍາໃຊ້ການໂຕ້ຕອບຫຼືການມີ node, ແຕ່ກ່ຽວກັບສິ່ງທີ່ subtle ຫຼາຍ - ການມີເສັ້ນທາງທີ່ຈໍາເປັນ, ຄຸນລັກສະນະກ່ຽວກັບພວກເຂົາ, ຈໍານວນຂອງກອງປະຊຸມ BGP, ປະເທດເພື່ອນບ້ານ OSPF, ການປະຕິບັດ End-to-End. ການບໍລິການຫຼາຍເກີນໄປ.
syslogs ກັບເຄື່ອງແມ່ຂ່າຍພາຍນອກຢຸດເຊົາການເພີ່ມ, ຫຼືຕົວແທນ SFlow ທໍາລາຍ, ຫຼືການຫຼຸດລົງໃນແຖວເລີ່ມຂະຫຍາຍຕົວ, ຫຼືການເຊື່ອມຕໍ່ລະຫວ່າງບາງຄູ່ຂອງຄໍານໍາຫນ້າທໍາລາຍລົງບໍ?

ພວກເຮົາຈະສະທ້ອນເລື່ອງນີ້ໃນບົດຄວາມແຍກຕ່າງຫາກ.

ສະຫລຸບ

ເປັນພື້ນຖານ, ຂ້າພະເຈົ້າໄດ້ເລືອກຫນຶ່ງໃນການອອກແບບເຄືອຂ່າຍສູນຂໍ້ມູນທີ່ທັນສະໄຫມ - L3 Clos Fabric ກັບ BGP ເປັນໂປໂຕຄອນກໍານົດເສັ້ນທາງ.
ເວລານີ້ພວກເຮົາຈະສ້າງເຄືອຂ່າຍໃນ Juniper, ເພາະວ່າໃນປັດຈຸບັນການໂຕ້ຕອບ JunOs ແມ່ນ vanlove.

ຂໍໃຫ້ຊີວິດຂອງພວກເຮົາມີຄວາມຫຍຸ້ງຍາກຫຼາຍຂຶ້ນໂດຍການໃຊ້ເຄື່ອງມື Open Source ແລະເຄືອຂ່າຍຜູ້ຂາຍຫຼາຍ - ດັ່ງນັ້ນ, ນອກເຫນືອຈາກ Juniper, ຂ້ອຍຈະເລືອກເອົາຜູ້ໂຊກດີອີກຄົນຫນຶ່ງ.

ແຜນການສໍາລັບການພິມເຜີຍແຜ່ທີ່ຈະມາເຖິງແມ່ນບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:
ທໍາອິດຂ້ອຍຈະເວົ້າກ່ຽວກັບເຄືອຂ່າຍ virtual. ກ່ອນອື່ນ ໝົດ, ເພາະວ່າຂ້ອຍຕ້ອງການ, ແລະອັນທີສອງ, ເພາະວ່າຖ້າບໍ່ມີນີ້, ການອອກແບບເຄືອຂ່າຍໂຄງສ້າງພື້ນຖານຈະບໍ່ຊັດເຈນຫຼາຍ.
ຫຼັງຈາກນັ້ນ, ກ່ຽວກັບການອອກແບບເຄືອຂ່າຍຕົວມັນເອງ: topology, routing, ນະໂຍບາຍ.
ໃຫ້​ເຮົາ​ຈັດ​ຕັ້ງ​ຫ້ອງ​ທົດ​ລອງ.
ໃຫ້ຄິດກ່ຽວກັບມັນແລະບາງທີການປະຕິບັດການເລີ່ມຕົ້ນອຸປະກອນໃນເຄືອຂ່າຍ.
ແລະຫຼັງຈາກນັ້ນກ່ຽວກັບແຕ່ລະອົງປະກອບໃນລາຍລະອຽດ intimate.

ແລະແມ່ນແລ້ວ, ຂ້ອຍບໍ່ສັນຍາວ່າຈະສິ້ນສຸດຮອບວຽນນີ້ຢ່າງສະຫງ່າງາມດ້ວຍການແກ້ໄຂທີ່ກຽມພ້ອມ. 🙂

ການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດ

• ກ່ອນທີ່ຈະເຂົ້າໄປໃນຊຸດ, ມັນຄຸ້ມຄ່າທີ່ຈະອ່ານຫນັງສືຂອງ Natasha Samoilenko Python ສໍາລັບວິສະວະກອນເຄືອຂ່າຍ. ແລະບາງທີຜ່ານ ແນ່ນອນ.
• ມັນຍັງຈະເປັນປະໂຫຍດທີ່ຈະອ່ານ RFC ກ່ຽວກັບການອອກແບບໂຮງງານຜະລິດສູນຂໍ້ມູນຈາກເຟສບຸກໂດຍ Peter Lapukhov.
• ເອກະສານສະຖາປັດຕະຍະກໍາຈະເຮັດໃຫ້ເຈົ້າມີຄວາມຄິດກ່ຽວກັບວິທີການ Overlay SDN ເຮັດວຽກ. ຜ້າ Tungsten (ເມື່ອກ່ອນເປີດ Contrail).

ຂອບ​ໃຈ

Roman Gorge. ສໍາລັບຄໍາເຫັນແລະການແກ້ໄຂ.
Artyom Chernobay. ສໍາລັບ KDPV.

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