ການກໍ່ສ້າງແລະກໍາຫນົດຄ່າ CDN ຂອງທ່ານ

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

ຫຼັກການຂອງການດໍາເນີນງານແລະການທໍາງານຂອງເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາທັງຫມົດແມ່ນປະມານດຽວກັນ. ໄດ້ຮັບການຮ້ອງຂໍໃຫ້ດາວໂຫລດໄຟລ໌, ເຄື່ອງແມ່ຂ່າຍ CDN ໃຊ້ເວລາຫນຶ່ງຄັ້ງຈາກເຄື່ອງແມ່ຂ່າຍຕົ້ນສະບັບແລະໃຫ້ມັນກັບຜູ້ໃຊ້, ໃນເວລາດຽວກັນ cache ມັນໃນໄລຍະເວລາທີ່ກໍານົດໄວ້. ການຮ້ອງຂໍຕໍ່ໄປທັງຫມົດແມ່ນໄດ້ຮັບການຕອບຈາກ cache. CDNs ທັງໝົດມີທາງເລືອກໃນການໂຫຼດໄຟລ໌ລ່ວງໜ້າ, ລຶບລ້າງແຄດ, ຕັ້ງວັນໝົດອາຍຸ, ແລະອື່ນໆອີກ.

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

ແຫຼ່ງຂໍ້ມູນ: vector infographic ສ້າງໂດຍ pikisuperstar - www.freepik.com

ເມື່ອທ່ານຕ້ອງການ CDN ຂອງທ່ານເອງ

ພິຈາລະນາກໍລະນີທີ່ການເຮັດວຽກ CDN ຂອງທ່ານເອງເຮັດໃຫ້ຄວາມຮູ້ສຶກ:

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

ໃນກໍລະນີອື່ນໆ, ມັນເຫມາະສົມກວ່າທີ່ຈະໃຊ້ວິທີແກ້ໄຂທີ່ກຽມພ້ອມທີ່ມີຢູ່.

ສິ່ງທີ່ທ່ານຕ້ອງການເພື່ອເລີ່ມຕົ້ນ

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

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

• ຊື່ໂດເມນ ຫຼືໂດເມນຍ່ອຍ
• ຢ່າງຫນ້ອຍສອງເຄື່ອງແມ່ຂ່າຍໃນພາກພື້ນທີ່ແຕກຕ່າງກັນ. ເຄື່ອງແມ່ຂ່າຍສາມາດອຸທິດຕົນຫຼື virtual
• ເຄື່ອງມື geoDNS. ດ້ວຍມັນ, ຜູ້ໃຊ້, ໄດ້ແກ້ໄຂໂດເມນ, ຈະຖືກນໍາໄປຫາເຄື່ອງແມ່ຂ່າຍທີ່ໃກ້ທີ່ສຸດ

ລົງທະບຽນໂດເມນແລະສັ່ງເຄື່ອງແມ່ຂ່າຍ

ດ້ວຍການລົງທະບຽນໂດເມນ, ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍ - ພວກເຮົາລົງທະບຽນຢູ່ໃນເຂດໃດກໍ່ຕາມກັບຜູ້ລົງທະບຽນໃດໆ. ທ່ານຍັງສາມາດໃຊ້ໂດເມນຍ່ອຍສໍາລັບ CDN, ຕົວຢ່າງເຊັ່ນບາງສິ່ງບາງຢ່າງ cdn.domainname.com. ໃນຄວາມເປັນຈິງ, ໃນຕົວຢ່າງຂອງພວກເຮົາ, ພວກເຮົາຈະເຮັດແນວນັ້ນ.

ສໍາລັບການສັ່ງຊື້ເຄື່ອງແມ່ຂ່າຍ, ພວກເຂົາຄວນຈະຖືກເຊົ່າໃນພາກພື້ນແລະປະເທດທີ່ຜູ້ຊົມຜູ້ໃຊ້ຂອງທ່ານຕັ້ງຢູ່. ຖ້າໂຄງການແມ່ນ intercontinental, ມັນແມ່ນສະດວກທີ່ຈະເລືອກເອົາຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງທີ່ສະຫນອງເຄື່ອງແມ່ຂ່າຍທົ່ວໂລກໃນເວລາດຽວກັນ. ຕົວຢ່າງ: OVH, ເຊົ່າເວັບ и 100 ບາດ - ສໍາລັບເຄື່ອງແມ່ຂ່າຍທີ່ອຸທິດຕົນ, Vultr и ມະຫາສະຸດດິຈິຕອລ — ສໍາ​ລັບ​ຟັງ virtual *.

ສໍາລັບ CDN ສ່ວນຕົວຂອງພວກເຮົາ, ພວກເຮົາຈະສັ່ງ 3 ເຄື່ອງແມ່ຂ່າຍ virtual ໃນທະວີບຕ່າງໆ. ທີ່ Vultr ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍສໍາລັບ $5/ເດືອນ ພວກ​ເຮົາ​ຈະ​ໄດ້​ຮັບ 25GB SSD ສະ​ຖານ​ທີ່​ແລະ​ 1TB ຂອງການຈະລາຈອນ. ເມື່ອຕິດຕັ້ງ, ເລືອກ Debian ຫຼ້າສຸດ. ເຊີບເວີຂອງພວກເຮົາ:

ແຟຣງເຟດ, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

ປະເທດສະເປນ, ip: 157.230.240.216

* Vultr ແລະ DigitalOcean ສັນຍາ $100 ສິນເຊື່ອໃຫ້ກັບຜູ້ໃຊ້ທີ່ລົງທະບຽນຜ່ານລິ້ງໃນບົດຄວາມທັນທີຫຼັງຈາກເພີ່ມວິທີການຊໍາລະ. ຜູ້ຂຽນຍັງໄດ້ຮັບການຍ້ອງຍໍເລັກນ້ອຍຈາກເລື່ອງນີ້, ເຊິ່ງເປັນສິ່ງສໍາຄັນຫຼາຍສໍາລັບລາວໃນປັດຈຸບັນ. ກະລຸນາເຂົ້າໃຈ.

ຕັ້ງຄ່າ geoDNS

ເພື່ອໃຫ້ຜູ້ໃຊ້ຖືກນໍາໄປຫາເຄື່ອງແມ່ຂ່າຍທີ່ຕ້ອງການ (ໃກ້ທີ່ສຸດ) ເມື່ອເຂົ້າເຖິງໂດເມນຍ່ອຍຫຼື CDN, ພວກເຮົາຕ້ອງການເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ມີຫນ້າທີ່ geoDNS.

ຫຼັກການແລະການດໍາເນີນງານຂອງ geoDNS ແມ່ນດັ່ງຕໍ່ໄປນີ້:

1. ລະບຸ IP ຂອງລູກຄ້າທີ່ສົ່ງຄໍາຮ້ອງຂໍ DNS, ຫຼື IP ຂອງເຊີບເວີ DNS recursive ທີ່ຖືກນໍາໃຊ້ໃນເວລາດໍາເນີນການຮ້ອງຂໍຂອງລູກຄ້າ. ເຄື່ອງແມ່ຂ່າຍ recursive ດັ່ງກ່າວແມ່ນປົກກະຕິແລ້ວ DNS-s ຂອງຜູ້ໃຫ້ບໍລິການ.
2. IP ຂອງລູກຄ້າຮັບຮູ້ປະເທດຫຼືພາກພື້ນຂອງລາວ. ສໍາລັບການນີ້, ຖານຂໍ້ມູນ GeoIP ຖືກນໍາໃຊ້, ເຊິ່ງມີຈໍານວນຫຼາຍໃນມື້ນີ້. ມີດີ ທາງເລືອກຟຣີ.
3. ອີງຕາມສະຖານທີ່ຂອງລູກຄ້າ, ໃຫ້ລາວທີ່ຢູ່ IP ຂອງເຄື່ອງແມ່ຂ່າຍ CDN ທີ່ໃກ້ທີ່ສຸດ.

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

• CloudDNS ຈາກ $9.95/ເດືອນ, ອັດຕາພາສີ GeoDNS, ໂດຍຄ່າເລີ່ມຕົ້ນມີຫນຶ່ງ DNS Failover
• Zilore ຈາກ $25/ເດືອນ, DNS Failover ຖືກເປີດໃຊ້
• Amazon ເສັ້ນທາງ 53 ຈາກ $35/ເດືອນ ສໍາລັບການຮ້ອງຂໍທາງພູມສາດສຸດທິ 50M. DNS Failover ຖືກຮຽກເກັບເງິນແຍກຕ່າງຫາກ
• DNS ເຮັດໄດ້ງ່າຍ ຈາກ $125/ເດືອນ, ມີ 10 DNS Failovers
• CloudFlare, "Geo Steering" ຄຸນນະສົມບັດແມ່ນມີຢູ່ໃນແຜນວິສາຫະກິດ

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

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

ເພື່ອສ້າງ CDN ຂອງພວກເຮົາ, ພວກເຮົາຈະນໍາໃຊ້ CloudDNS, ອັດຕາພາສີ GeoDNS.

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

ໃນກໍລະນີຂອງພວກເຮົາ, CDN ຈະຖືກຍົກຂຶ້ນມາໃນໂດເມນຍ່ອຍ cdn.sayt.in. ໂດຍການເພີ່ມເຂດ sayt.in, ສ້າງບັນທຶກ A-ທໍາອິດສໍາລັບ subdomain ແລະຊີ້ທັງຫມົດຂອງອາເມລິກາເຫນືອກັບເຄື່ອງແມ່ຂ່າຍໃນ Chicago:

ໃຫ້ເຮັດຊ້ໍາຄືນການດໍາເນີນການສໍາລັບພາກພື້ນອື່ນໆ, ຈື່ຈໍາທີ່ຈະສ້າງຫນຶ່ງ entry ສໍາລັບພາກພື້ນເລີ່ມຕົ້ນ. ນີ້ແມ່ນສິ່ງທີ່ເກີດຂຶ້ນໃນທີ່ສຸດ:

ການເຂົ້າໃນຕອນຕົ້ນສຸດທ້າຍໃນ screenshot ຫມາຍຄວາມວ່າທຸກຂົງເຂດທີ່ບໍ່ໄດ້ກໍານົດ (ແລະເຫຼົ່ານີ້ແມ່ນເອີຣົບ, ອາຟຣິກາ, ຜູ້ໃຊ້ອິນເຕີເນັດດາວທຽມ, ແລະອື່ນໆ) ຈະຖືກສົ່ງກັບເຄື່ອງແມ່ຂ່າຍໃນ Frankfurt.

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

ການຕິດຕັ້ງໃບຢັ້ງຢືນ SSL

CDN ຂອງພວກເຮົາຈະເຮັດວຽກຜ່ານ HTTPS, ດັ່ງນັ້ນຖ້າທ່ານມີໃບຢັ້ງຢືນ SSL ສໍາລັບໂດເມນຫຼືໂດເມນຍ່ອຍ, ອັບໂຫລດພວກມັນໃຫ້ກັບເຄື່ອງແມ່ຂ່າຍທັງຫມົດ, ຕົວຢ່າງ, ໄປຫາໄດເລກະທໍລີ. /etc/ssl/yourdomain/

ຖ້າບໍ່ມີໃບຮັບຮອງ, ທ່ານສາມາດໄດ້ຮັບໃບຮັບຮອງຟຣີຈາກ Let's Encrypt. ທີ່ສົມບູນແບບສໍາລັບການນີ້ ACME Shellscript. ລູກຄ້າແມ່ນສະດວກແລະງ່າຍຕໍ່ການຕັ້ງຄ່າ, ແລະສໍາຄັນທີ່ສຸດ, ມັນຊ່ວຍໃຫ້ທ່ານສາມາດກວດສອບໂດເມນ / ໂດເມນຍ່ອຍໂດຍ DNS ຜ່ານ ClouDNS API.

ພວກເຮົາຈະຕິດຕັ້ງ acme.sh ຢູ່ໃນເຊີບເວີດຽວເທົ່ານັ້ນ - ເອີຣົບ 199.247.18.199, ຈາກນັ້ນໃບຢັ້ງຢືນຈະຖືກຄັດລອກໄປຫາຜູ້ອື່ນທັງຫມົດ. ເພື່ອຕິດຕັ້ງ, ດໍາເນີນການ:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

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

ເມື່ອອອກໃບຢັ້ງຢືນ, ໂດເມນຈະຖືກກວດສອບໂດຍ DNS ໂດຍໃຊ້ API, ດັ່ງນັ້ນໃນບັນຊີສ່ວນບຸກຄົນ ClouDNS ໃນເມນູ Reseller API, ທ່ານຈໍາເປັນຕ້ອງສ້າງ API ຜູ້ໃຊ້ໃຫມ່ແລະຕັ້ງລະຫັດຜ່ານສໍາລັບມັນ. ຜົນໄດ້ຮັບ auth-id ກັບລະຫັດຜ່ານຈະຖືກຂຽນໄວ້ໃນໄຟລ໌ ~/.acme.sh/dnsapi/dns_cloudns.sh (ບໍ່ຕ້ອງສັບສົນກັບໄຟລ໌ dns_clouddns.sh). ນີ້ແມ່ນບັນດາເສັ້ນທີ່ຈະຕ້ອງບໍ່ສະແດງຄວາມຄິດເຫັນ ແລະແກ້ໄຂ:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

ໃນປັດຈຸບັນພວກເຮົາຈະຮ້ອງຂໍໃຫ້ມີໃບຢັ້ງຢືນ SSL ສໍາລັບ cdn.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

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

ຂະບວນການທັງຫມົດຂອງການໄດ້ຮັບໃບຢັ້ງຢືນສາມາດໃຊ້ເວລາເຖິງ 2 ນາທີ, ຢ່າຂັດຂວາງມັນ. ຖ້າມີຂໍ້ຜິດພາດໃນການກວດສອບໂດເມນ, ລອງແລ່ນຄຳສັ່ງອີກຄັ້ງ. ໃນທີ່ສຸດພວກເຮົາຈະເຫັນບ່ອນທີ່ໃບຢັ້ງຢືນໄດ້ຖືກອັບໂຫລດ:

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

ທັງຫມົດທີ່ພວກເຮົາໄດ້ປະໄວ້ສໍາລັບ SSL ແມ່ນເພື່ອຄັດລອກໃບຢັ້ງຢືນທີ່ໄດ້ຮັບກັບສອງເຄື່ອງແມ່ຂ່າຍອື່ນໆໃນຂະນະທີ່ຮັກສາເສັ້ນທາງໄປຫາໄຟລ໌. ໃຫ້ສ້າງໄດເລກະທໍລີດຽວກັນຢູ່ໃນແຕ່ລະພວກມັນແລະເຮັດສໍາເນົາ:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

ເພື່ອປັບປຸງໃບຢັ້ງຢືນເປັນປົກກະຕິ, ສ້າງວຽກ CRON ປະຈໍາວັນໃນເຄື່ອງແມ່ຂ່າຍທັງສອງດ້ວຍຄໍາສັ່ງ:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

ໃນກໍລະນີນີ້, ການເຂົ້າເຖິງເຄື່ອງແມ່ຂ່າຍແຫຼ່ງຫ່າງໄກສອກຫຼີກຕ້ອງໄດ້ຮັບການກໍາຫນົດຄ່າ ໂດຍກະແຈ, i.e. ໂດຍບໍ່ມີການໃສ່ລະຫັດຜ່ານ. ຢ່າລືມເຮັດມັນ.

ການຕິດຕັ້ງແລະກໍາຫນົດຄ່າ Nginx

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

root@cdn:~# apt update
root@cdn:~# apt install nginx

ແທນທີ່ຈະເປັນຄ່າເລີ່ມຕົ້ນ, ພວກເຮົາໃຊ້ config ຈາກ spoiler ຂ້າງລຸ່ມນີ້:
nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;            

    proxy_temp_path    /var/cache/tmp;
    proxy_cache_path   /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d;
    proxy_cache_bypass $http_x_update;

server {
  listen 443 ssl;
  server_name cdn.sayt.in;

  ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer;
  ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key;

  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://sayt.in;
    }
  }
}

ແກ້ໄຂໃນການຕັ້ງຄ່າ:

• ຂະໜາດສູງສຸດ — ຂະ​ຫນາດ​ຂອງ​ຖານ​ຄວາມ​ຈໍາ​, ບໍ່​ເກີນ​ຊ່ອງ​ແຜ່ນ​ທີ່​ມີ​ຢູ່​
• ບໍ່ເຄື່ອນໄຫວ - ເວລາເກັບຂໍ້ມູນຈາກຖານຄວາມຈຳທີ່ບໍ່ມີໃຜເຂົ້າເຖິງ
• ssl_certificate и ssl_certificate_key — ເສັ້ນທາງໄປຫາໃບຢັ້ງຢືນ SSL ແລະໄຟລ໌ທີ່ສໍາຄັນ
• proxy_cache_valid - ເວລາເກັບຂໍ້ມູນຈາກຖານຄວາມຈຳ
• proxy_pass — ທີ່​ຢູ່​ຂອງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ຕົ້ນ​ສະ​ບັບ​ທີ່ CDN ຈະ​ຮ້ອງ​ຂໍ​ໄຟລ​໌​ສໍາ​ລັບ​ການ​ຖານ​ຄວາມ​ຈໍາ​. ໃນຕົວຢ່າງຂອງພວກເຮົາ, ນີ້ sayt.in

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍ. ຄວາມຫຍຸ້ງຍາກສາມາດເກີດຂື້ນພຽງແຕ່ໃນການຕັ້ງຄ່າເວລາເກັບຂໍ້ມູນເນື່ອງຈາກຄວາມຄ້າຍຄືກັນຂອງຄໍາສັ່ງ ບໍ່ເຄື່ອນໄຫວ и proxy_cache_valid. ໃຫ້ວິເຄາະພວກມັນດ້ວຍຕົວຢ່າງຂອງພວກເຮົາ. ນີ້ແມ່ນສິ່ງທີ່ເກີດຂື້ນເມື່ອ inactive=7d и proxy_cache_valid 90d:

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

ແກ້ໄຂແລ້ວ nginx.conf, ໂຫຼດການຕັ້ງຄ່າຄືນໃໝ່:

root@cdn:~# service nginx reload

CDN ຂອງພວກເຮົາພ້ອມແລ້ວ. ສໍາລັບ $15/ເດືອນ. ພວກເຮົາໄດ້ຮັບຈຸດປະກົດຕົວຢູ່ໃນສາມທະວີບ ແລະ 3 TB ຂອງການຈະລາຈອນ: 1 TB ໃນແຕ່ລະສະຖານທີ່.

ການກວດສອບການເຮັດວຽກຂອງ CDN

ໃຫ້ເບິ່ງ pings ກັບ CDN ຂອງພວກເຮົາຈາກສະຖານທີ່ຕັ້ງພູມສາດທີ່ແຕກຕ່າງກັນ. ການບໍລິການ ping ໃດຈະເຮັດວຽກສໍາລັບການນີ້.

ຈຸດເປີດຕົວ
ເຈົ້າພາບ
IP
ເວລາສະເລ່ຍ, ms

ເຢຍ​ລະ​ມັນ Berlin
cdn.sayt.in
199.247.18.199
9.6

ເນເທີແລນ, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

ຝຣັ່ງ ປາຣີ
cdn.sayt.in
199.247.18.199
16.3

ອັງກິດ, ລອນດອນ
cdn.sayt.in
199.247.18.199
14.9

ການາດາ, Toronto
cdn.sayt.in
149.28.121.123
16.2

ສະຫະລັດ, San Francisco
cdn.sayt.in
149.28.121.123
52.7

ສະຫະລັດ, Dallas
cdn.sayt.in
149.28.121.123
23.1

ສະຫະລັດ, Chicago
cdn.sayt.in
149.28.121.123
2.6

ສະຫະລັດ, ນິວຢອກ
cdn.sayt.in
149.28.121.123
19.8

ປະເທດສະເປນ
cdn.sayt.in
157.230.240.216
1.7

ຍີ່ປຸ່ນ ໂຕກຽວ
cdn.sayt.in
157.230.240.216
74.8

ອົດ​ສະ​ຕາ​ລີ, Sydney
cdn.sayt.in
157.230.240.216
95.9

ຜົນໄດ້ຮັບແມ່ນດີ. ໃນປັດຈຸບັນພວກເຮົາຈະວາງຮູບພາບການທົດສອບຢູ່ໃນຮາກຂອງເວັບໄຊທ໌ຕົ້ນຕໍ test.jpg ແລະກວດເບິ່ງຄວາມໄວການດາວໂຫຼດຂອງມັນຜ່ານ CDN. ມັນ​ໄດ້​ຖືກ​ເວົ້າ​ວ່າ - ເຮັດໄດ້. ເນື້ອຫາຖືກຈັດສົ່ງຢ່າງໄວວາ.

ໃຫ້ຂຽນ script ຂະຫນາດນ້ອຍໃນກໍລະນີທີ່ພວກເຮົາຕ້ອງການລ້າງ cache ໃນຈຸດ CDN.
purge.sh

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

ເພື່ອລຶບ cache ທັງຫມົດ, ພຽງແຕ່ດໍາເນີນການມັນ, ໄຟລ໌ແຍກຕ່າງຫາກສາມາດຖືກອະນາໄມເຊັ່ນນີ້:

root@cdn:~# ./purge.sh /test.jpg

ແທນທີ່ຈະສະຫລຸບ

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

• ເພື່ອເພີ່ມຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງ CDN, ແນະນໍາໃຫ້ຕັ້ງຄ່າ DNS Failover, ເຊິ່ງຊ່ວຍປ່ຽນບັນທຶກ A ຢ່າງໄວວາໃນກໍລະນີຂອງການທໍາລາຍເຄື່ອງແມ່ຂ່າຍ. ນີ້ແມ່ນເຮັດຢູ່ໃນບັນທຶກ DNS ກະດານຄວບຄຸມຂອງໂດເມນ.
• ສະຖານທີ່ທີ່ມີການຄຸ້ມຄອງທາງພູມສັນຖານທີ່ກວ້າງຂວາງບໍ່ຕ້ອງສົງໃສວ່າຕ້ອງການ CDNs ຈໍານວນຫລາຍ, ແຕ່ຢ່າເປັນຄົນຂີ້ຄ້ານ. ສ່ວນຫຼາຍແລ້ວຜູ້ໃຊ້ຈະບໍ່ສັງເກດເຫັນຄວາມແຕກຕ່າງທີ່ສໍາຄັນເມື່ອທຽບກັບ CDN ທີ່ໄດ້ຮັບຄ່າຈ້າງຖ້າທ່ານວາງເຄື່ອງແມ່ຂ່າຍໃນ 6-7 ສະຖານທີ່: ເອີຣົບ, ອາເມລິກາເຫນືອ (ຕາເວັນອອກ), ອາເມລິກາເຫນືອ (ຕາເວັນຕົກ), ສິງກະໂປ, ອົດສະຕາລີ, ຮົງກົງຫຼືຍີ່ປຸ່ນ.
• ບາງຄັ້ງ hosters ບໍ່ອະນຸຍາດໃຫ້ໃຊ້ເຄື່ອງແມ່ຂ່າຍທີ່ເຊົ່າເພື່ອຈຸດປະສົງ CDN. ດັ່ງນັ້ນ, ຖ້າຫາກວ່າທ່ານທັນທີທັນໃດຕັດສິນໃຈທີ່ຈະນໍາໃຊ້ເຄືອຂ່າຍການຈັດສົ່ງເນື້ອໃນເປັນການບໍລິການ, ຢ່າລືມອ່ານກົດລະບຽບຂອງຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງໂດຍສະເພາະລ່ວງຫນ້າ.
• ສຳຫຼວດ ແຜນ​ທີ່​ການ​ສື່​ສານ​ໃຕ້​ນ​້​ໍ​າ​ເພື່ອສະແດງວິທີການເຊື່ອມຕໍ່ຂອງທະວີບແລະພິຈາລະນານີ້ໃນເວລາສ້າງເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາ
• ພະຍາຍາມກວດສອບ pings ຈາກ​ບ່ອນ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ ກັບເຄື່ອງແມ່ຂ່າຍຂອງທ່ານ. ດ້ວຍວິທີນີ້, ທ່ານສາມາດເບິ່ງພາກພື້ນທີ່ໃກ້ຄຽງກັບຈຸດ CDN ແລະ configure GeoDNS ຢ່າງຖືກຕ້ອງກວ່າ
• ອີງຕາມວຽກງານ, ມັນຈະເປັນປະໂຫຍດທີ່ຈະປັບ Nginx ສໍາລັບຄວາມຕ້ອງການຖານຄວາມຈໍາສະເພາະແລະຄໍານຶງເຖິງການໂຫຼດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ. ບົດຄວາມກ່ຽວກັບ Nginx cache ໄດ້ຊ່ວຍຂ້ອຍຫຼາຍໃນເລື່ອງນີ້ - ທີ່ນີ້ ແລະການເລັ່ງການເຮັດວຽກພາຍໃຕ້ການໂຫຼດຫນັກ: ທີ່ນີ້ и ທີ່ນີ້

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