ວິທີການ AWS ປຸງແຕ່ງການບໍລິການ elastic ຂອງມັນ. ການຂະຫຍາຍເຄືອຂ່າຍ

ຂະຫນາດຂອງເຄືອຂ່າຍ Amazon Web Services ແມ່ນ 69 ເຂດທົ່ວໂລກໃນ 22 ພາກພື້ນ: ອາເມລິກາ, ເອີຣົບ, ອາຊີ, ອາຟຣິກາແລະອົດສະຕາລີ. ແຕ່ລະເຂດມີເຖິງ 8 ສູນຂໍ້ມູນ - ສູນປະມວນຜົນຂໍ້ມູນ. ແຕ່ລະສູນຂໍ້ມູນມີເຄື່ອງແມ່ຂ່າຍຫຼາຍພັນຫຼືຫຼາຍຮ້ອຍພັນເຄື່ອງແມ່ຂ່າຍ. ເຄືອຂ່າຍດັ່ງກ່າວໄດ້ຖືກອອກແບບໃນລັກສະນະທີ່ທຸກສະຖານະການທີ່ບໍ່ເປັນໄປໄດ້ຖືກພິຈາລະນາ. ສໍາລັບຕົວຢ່າງ, ພາກພື້ນທັງຫມົດແມ່ນຢູ່ໂດດດ່ຽວຈາກກັນແລະກັນ, ແລະເຂດການເຂົ້າເຖິງໄດ້ຖືກແຍກອອກເປັນໄລຍະທາງຫຼາຍກິໂລແມັດ. ເຖິງແມ່ນວ່າທ່ານຈະຕັດສາຍເຄເບີນ, ລະບົບຈະປ່ຽນໄປຫາຊ່ອງທາງການສໍາຮອງຂໍ້ມູນ, ແລະການສູນເສຍຂໍ້ມູນຈະມີຈໍານວນແພັກເກັດຂໍ້ມູນຈໍານວນຫນ້ອຍ. Vasily Pantyukhin ຈະເວົ້າກ່ຽວກັບຫຼັກການອື່ນໆທີ່ເຄືອຂ່າຍຖືກສ້າງຂຶ້ນແລະວິທີການໂຄງສ້າງຂອງມັນ.

Vasily Pantyukhin ໄດ້ເລີ່ມຕົ້ນເປັນຜູ້ບໍລິຫານ Unix ໃນບໍລິສັດ .ru, ເຮັດວຽກຢູ່ໃນຮາດແວ Sun Microsystem ຂະຫນາດໃຫຍ່ເປັນເວລາ 6 ປີ, ປະກາດໂລກທີ່ມີຂໍ້ມູນເປັນສູນກາງຢູ່ EMC ເປັນເວລາ 11 ປີ. ໂດຍທໍາມະຊາດມັນພັດທະນາໄປສູ່ຄລາວສ່ວນຕົວ, ຫຼັງຈາກນັ້ນຍ້າຍໄປສາທາລະນະ. ໃນປັດຈຸບັນ, ໃນຖານະສະຖາປະນິກ Amazon Web Services, ລາວໃຫ້ຄໍາແນະນໍາດ້ານວິຊາການເພື່ອຊ່ວຍດໍາລົງຊີວິດແລະພັດທະນາໃນ AWS cloud.

ໃນສ່ວນທີ່ຜ່ານມາຂອງ AWS trilogy, Vasily delved ເຂົ້າໄປໃນການອອກແບບຂອງເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍແລະການຂະຫຍາຍຖານຂໍ້ມູນ. ບັດ Nitro, hypervisor ທີ່ອີງໃສ່ KVM, ຖານຂໍ້ມູນ Amazon Aurora - ກ່ຽວກັບສິ່ງທັງຫມົດນີ້ໃນອຸປະກອນການ "ວິທີການ AWS ປຸງແຕ່ງການບໍລິການ elastic ຂອງມັນ. ຂະຫຍາຍເຊີບເວີ ແລະຖານຂໍ້ມູນ" ອ່ານສໍາລັບສະພາບການຫຼືເບິ່ງ ວີດີໂອ ຄຳປາໄສ.

ສ່ວນນີ້ຈະສຸມໃສ່ການຂະຫຍາຍເຄືອຂ່າຍ, ຫນຶ່ງໃນລະບົບທີ່ສັບສົນທີ່ສຸດໃນ AWS. evolution ຈາກເຄືອຂ່າຍຮາບພຽງເປັນ Virtual Private Cloud ແລະການອອກແບບຂອງຕົນ, ການບໍລິການພາຍໃນຂອງ Blackfoot ແລະ HyperPlane, ບັນຫາຂອງເພື່ອນບ້ານທີ່ບໍ່ມີສຽງ, ແລະໃນຕອນທ້າຍ - ຂະຫນາດຂອງເຄືອຂ່າຍ, backbone ແລະສາຍທາງດ້ານຮ່າງກາຍ. ກ່ຽວກັບທັງຫມົດນີ້ພາຍໃຕ້ການຕັດ.

ການປະຕິເສດ: ທຸກສິ່ງທຸກຢ່າງຂ້າງລຸ່ມນີ້ແມ່ນຄວາມຄິດເຫັນສ່ວນຕົວຂອງ Vasily ແລະອາດຈະບໍ່ກົງກັນກັບຕໍາແຫນ່ງຂອງ Amazon Web Services.

ການຂະຫຍາຍເຄືອຂ່າຍ

AWS cloud ໄດ້ຖືກເປີດຕົວໃນປີ 2006. ເຄືອຂ່າຍຂອງລາວແມ່ນຂ້ອນຂ້າງ primitive - ມີໂຄງສ້າງຮາບພຽງ. ຂອບເຂດຂອງທີ່ຢູ່ສ່ວນຕົວແມ່ນທົ່ວໄປກັບຜູ້ເຊົ່າຄລາວທັງໝົດ. ເມື່ອເລີ່ມຕົ້ນເຄື່ອງ virtual ໃໝ່, ທ່ານໄດ້ຮັບທີ່ຢູ່ IP ທີ່ມີຢູ່ຈາກຊ່ວງນີ້ໂດຍບັງເອີນ.

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

Cloud Private Virtual

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

ສິ່ງທໍາອິດທີ່ຢູ່ໃນໃຈໃນເວລາທີ່ທ່ານຄິດກ່ຽວກັບການໂດດດ່ຽວເຄືອຂ່າຍແມ່ນຫຍັງ? ແນ່ນອນ VLANs и VRF - ການສ້າງເສັ້ນທາງ ແລະສົ່ງຕໍ່ແບບສະເໝືອນ.

ແຕ່ຫນ້າເສຍດາຍ, ມັນບໍ່ໄດ້ຜົນ. VLAN ID ແມ່ນພຽງແຕ່ 12 bits, ເຊິ່ງເຮັດໃຫ້ພວກເຮົາມີພຽງແຕ່ 4096 ພາກສ່ວນທີ່ໂດດດ່ຽວ. ເຖິງແມ່ນວ່າສະວິດທີ່ໃຫຍ່ທີ່ສຸດສາມາດນໍາໃຊ້ໄດ້ສູງສຸດ 1-2 ພັນ VRFs. ການນໍາໃຊ້ VRF ແລະ VLAN ຮ່ວມກັນເຮັດໃຫ້ພວກເຮົາມີພຽງແຕ່ສອງສາມລ້ານ subnets. ນີ້ແນ່ນອນບໍ່ພຽງພໍສໍາລັບຜູ້ເຊົ່າຫຼາຍສິບລ້ານຄົນ, ແຕ່ລະຄົນຕ້ອງສາມາດໃຊ້ subnet ຫຼາຍ.

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

ມີພຽງແຕ່ຫນຶ່ງສະຫຼຸບ - ເຮັດໃຫ້ການແກ້ໄຂຂອງທ່ານເອງ.

ໃນປີ 2009 ພວກເຮົາປະກາດ VPC - Cloud Private Virtual. ຊື່ຕິດຢູ່ແລະໃນປັດຈຸບັນຜູ້ໃຫ້ບໍລິການຟັງຈໍານວນຫຼາຍຍັງໃຊ້ມັນ.

VPC ແມ່ນເຄືອຂ່າຍສະເໝືອນ SDN (ຊອບແວທີ່ກໍານົດເຄືອຂ່າຍ). ພວກເຮົາຕັດສິນໃຈບໍ່ປະດິດໂປຣໂຕຄໍພິເສດໃນລະດັບ L2 ແລະ L3. ເຄືອຂ່າຍເຮັດວຽກຢູ່ໃນມາດຕະຖານ Ethernet ແລະ IP. ສໍາລັບການສົ່ງຜ່ານເຄືອຂ່າຍ, ການຈາລະຈອນຂອງເຄື່ອງ virtual ແມ່ນ encapsulated ໃນ wrapper ໂປໂຕຄອນຂອງພວກເຮົາເອງ. ມັນຊີ້ໃຫ້ເຫັນ ID ທີ່ເປັນຂອງ VPC ຂອງຜູ້ເຊົ່າ.

ສຽງງ່າຍດາຍ. ຢ່າງໃດກໍ່ຕາມ, ມີສິ່ງທ້າທາຍດ້ານເຕັກນິກທີ່ຮ້າຍແຮງຫຼາຍທີ່ຕ້ອງໄດ້ຮັບການແກ້ໄຂ. ຕົວຢ່າງ, ບ່ອນໃດ ແລະວິທີການເກັບຮັກສາຂໍ້ມູນໃນແຜນທີ່ virtual MAC/IP address, VPC ID ແລະ MAC/IP ທີ່ສອດຄ້ອງກັນ. ໃນລະດັບ AWS, ນີ້ແມ່ນຕາຕະລາງຂະຫນາດໃຫຍ່ທີ່ຄວນເຮັດວຽກກັບການຊັກຊ້າໃນການເຂົ້າເຖິງຫນ້ອຍທີ່ສຸດ. ຮັບຜິດຊອບສໍາລັບການນີ້ ບໍລິການສ້າງແຜນທີ່, ເຊິ່ງກະຈາຍຢູ່ໃນຊັ້ນບາງໆໃນທົ່ວເຄືອຂ່າຍ.

ໃນເຄື່ອງຈັກລຸ້ນໃຫມ່, ການຫຸ້ມຫໍ່ແມ່ນປະຕິບັດໂດຍບັດ Nitro ໃນລະດັບຮາດແວ. ໃນຕົວຢ່າງເກົ່າ, encapsulation ແລະ decapsulation ແມ່ນອີງໃສ່ຊອບແວ. 

ໃຫ້ພວກເຮົາຄິດອອກວ່າມັນເຮັດວຽກແນວໃດໃນເງື່ອນໄຂທົ່ວໄປ. ໃຫ້ເລີ່ມຕົ້ນດ້ວຍລະດັບ L2. ໃຫ້ສົມມຸດວ່າພວກເຮົາມີເຄື່ອງ virtual ທີ່ມີ IP 10.0.0.2 ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍ 192.168.0.3. ມັນສົ່ງຂໍ້ມູນໄປຍັງເຄື່ອງ virtual 10.0.0.3, ເຊິ່ງອາໄສຢູ່ໃນ 192.168.1.4. ການຮ້ອງຂໍ ARP ແມ່ນຖືກສ້າງຂຶ້ນແລະຖືກສົ່ງໄປຫາບັດ Nitro ເຄືອຂ່າຍ. ສໍາລັບຄວາມງ່າຍດາຍ, ພວກເຮົາສົມມຸດວ່າທັງສອງເຄື່ອງ virtual ອາໄສຢູ່ໃນ "ສີຟ້າ" VPC ດຽວກັນ.

ແຜນທີ່ປ່ຽນແທນທີ່ຢູ່ແຫຼ່ງຂອງມັນເອງ ແລະສົ່ງຕໍ່ກອບ ARP ໄປຫາບໍລິການສ້າງແຜນທີ່.

ບໍລິການແຜນທີ່ສົ່ງຄືນຂໍ້ມູນທີ່ຈໍາເປັນສໍາລັບການສົ່ງຜ່ານເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍ L2.

ບັດ Nitro ໃນການຕອບໂຕ້ ARP ແທນ MAC ໃນເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍທີ່ມີທີ່ຢູ່ໃນ VPC.

ເມື່ອໂອນຂໍ້ມູນ, ພວກເຮົາຫໍ່ MAC ທີ່ມີເຫດຜົນແລະ IP ໃນ wrapper VPC. ພວກເຮົາສົ່ງຂໍ້ມູນທັງຫມົດນີ້ຜ່ານເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍໂດຍໃຊ້ບັດ IP Nitro ແຫຼ່ງແລະປາຍທາງທີ່ເຫມາະສົມ.

ເຄື່ອງຈັກທາງກາຍະພາບທີ່ຊຸດແມ່ນ destined ດໍາເນີນການກວດສອບ. ນີ້ແມ່ນສິ່ງຈໍາເປັນເພື່ອປ້ອງກັນຄວາມເປັນໄປໄດ້ຂອງການປອມແປງທີ່ຢູ່. ເຄື່ອງຈັກສົ່ງຄໍາຮ້ອງຂໍພິເສດໄປຫາບໍລິການແຜນທີ່ແລະຖາມວ່າ: "ຈາກເຄື່ອງຕົວຈິງ 192.168.0.3 ຂ້ອຍໄດ້ຮັບແພັກເກັດທີ່ມີຈຸດປະສົງສໍາລັບ 10.0.0.3 ໃນ VPC ສີຟ້າ. ລາວຖືກຕ້ອງບໍ? 

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

ຕໍ່ໄປ, ຂໍ້ມູນຖືກສົ່ງໄປຫາເຄື່ອງ virtual ທີ່ມັນມີຈຸດປະສົງ. 

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

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

ຄວາມງາມແມ່ນວ່າທ່ານບໍ່ຈໍາເປັນຕ້ອງ cache ຕາຕະລາງຂະຫນາດໃຫຍ່ທັງຫມົດ. ເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍເປັນເຈົ້າພາບເຄື່ອງ virtual ຈາກຈໍານວນ VPC ທີ່ຂ້ອນຂ້າງຫນ້ອຍ. ທ່ານພຽງແຕ່ຕ້ອງການ cache ຂໍ້ມູນກ່ຽວກັບ VPCs ເຫຼົ່ານີ້. ການໂອນຂໍ້ມູນໄປຫາ VPCs ອື່ນໆໃນການຕັ້ງຄ່າ "ຄ່າເລີ່ມຕົ້ນ" ຍັງບໍ່ຖືກຕ້ອງຕາມກົດໝາຍ. ຖ້າການທໍາງານເຊັ່ນ VPC-peering ຖືກນໍາໃຊ້, ຫຼັງຈາກນັ້ນ, ຂໍ້ມູນກ່ຽວກັບ VPCs ທີ່ສອດຄ້ອງກັນຈະຖືກໂຫລດໃສ່ໃນ cache. 

ພວກເຮົາຈັດຮຽງການໂອນຂໍ້ມູນໄປຍັງ VPC.

Blackfoot

ສິ່ງທີ່ຕ້ອງເຮັດໃນກໍລະນີທີ່ການຈະລາຈອນຈໍາເປັນຕ້ອງຖືກສົ່ງຕໍ່ພາຍນອກ, ຕົວຢ່າງຜ່ານອິນເຕີເນັດຫຼືຜ່ານ VPN ໄປຫາຫນ້າດິນ? ຊ່ວຍພວກເຮົາຢູ່ທີ່ນີ້ Blackfoot - ບໍລິການພາຍໃນ AWS. ມັນໄດ້ຖືກພັດທະນາໂດຍທີມງານອາຟຣິກາໃຕ້ຂອງພວກເຮົາ. ນັ້ນແມ່ນເຫດຜົນທີ່ບໍລິການນີ້ຖືກຕັ້ງຊື່ຕາມ penguin ທີ່ອາໄສຢູ່ໃນອາຟຣິກາໃຕ້.

Blackfoot decapsulates ການຈະລາຈອນແລະເຮັດສິ່ງທີ່ຈໍາເປັນກັບມັນ. ຂໍ້​ມູນ​ຖືກ​ສົ່ງ​ໄປ​ຫາ​ອິນ​ເຕີ​ເນັດ​ເຊັ່ນ​ດຽວ​ກັນ​.

ຂໍ້ມູນຖືກ decapsulated ແລະຫໍ່ຄືນໃນ IPsec ເມື່ອໃຊ້ VPN.

ເມື່ອໃຊ້ Direct Connect, ການຈະລາຈອນຈະຖືກ tagged ແລະຖືກສົ່ງໄປຫາ VLAN ທີ່ເຫມາະສົມ.

ຍົນ HyperPlan

ນີ້ແມ່ນການບໍລິການຄວບຄຸມການໄຫຼເຂົ້າພາຍໃນ. ການບໍລິການເຄືອຂ່າຍຈໍານວນຫຼາຍຮຽກຮ້ອງໃຫ້ມີການຕິດຕາມ ສະຖານະການໄຫຼຂອງຂໍ້ມູນ. ຕົວຢ່າງ, ເມື່ອໃຊ້ NAT, ການຄວບຄຸມການໄຫຼຕ້ອງຮັບປະກັນວ່າແຕ່ລະ IP: ຄູ່ພອດປາຍທາງມີພອດຂາອອກທີ່ເປັນເອກະລັກ. ໃນກໍລະນີຂອງຜູ້ດຸ່ນດ່ຽງ NLB - Network Load Balancer, ການໄຫຼເຂົ້າຂອງຂໍ້ມູນຄວນຈະຖືກສົ່ງໄປຫາເຄື່ອງ virtual ເປົ້າຫມາຍດຽວກັນສະເຫມີ. ກຸ່ມຄວາມປອດໄພແມ່ນ firewall ຂອງລັດ. ມັນຕິດຕາມກວດກາການຈະລາຈອນຂາເຂົ້າແລະ implicitly ເປີດ ports ສໍາລັບການໄຫຼຊອງຂາອອກ.

ໃນຄລາວຂອງ AWS, ຄວາມຕ້ອງການການຕອບສະໜອງການສົ່ງສັນຍານແມ່ນສູງທີ່ສຸດ. ນັ້ນຄືເຫດຜົນ ຍົນ HyperPlan ສໍາຄັນຕໍ່ການປະຕິບັດຂອງເຄືອຂ່າຍທັງຫມົດ.

Hyperplane ຖືກສ້າງຂຶ້ນໃນເຄື່ອງ virtual EC2. ບໍ່ມີ magic ຢູ່ທີ່ນີ້, ພຽງແຕ່ cunning. ເຄັດລັບແມ່ນວ່າເຫຼົ່ານີ້ແມ່ນເຄື່ອງ virtual ທີ່ມີ RAM ຂະຫນາດໃຫຍ່. ການດໍາເນີນງານແມ່ນເຮັດທຸລະກໍາແລະດໍາເນີນການສະເພາະໃນຫນ່ວຍຄວາມຈໍາ. ນີ້ອະນຸຍາດໃຫ້ທ່ານບັນລຸຄວາມລ່າຊ້າພຽງແຕ່ສິບໄມໂຄວິນາທີ. ການເຮັດວຽກກັບແຜ່ນຈະຂ້າຜົນຜະລິດທັງຫມົດ. 

Hyperplane ແມ່ນລະບົບການແຈກຢາຍຂອງເຄື່ອງຈັກ EC2 ຈໍານວນຫຼວງຫຼາຍ. ແຕ່ລະເຄື່ອງ virtual ມີແບນວິດ 5 GB/s. ໃນທົ່ວເຄືອຂ່າຍພາກພື້ນທັງຫມົດ, ນີ້ສະຫນອງ terabits incredible ຂອງແບນວິດແລະອະນຸຍາດໃຫ້ປະມວນຜົນ. ລ້ານເຊື່ອມຕໍ່ຕໍ່ວິນາທີ.

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

ເພື່ອນບ້ານທີ່ມີສຽງດັງ

ຍັງມີບັນຫາຢູ່ ເພື່ອນບ້ານທີ່ມີສຽງດັງ - ເພື່ອນບ້ານທີ່ມີສຽງດັງ. ໃຫ້ສົມມຸດວ່າພວກເຮົາມີ 8 nodes. ໂນດເຫຼົ່ານີ້ປະມວນຜົນກະແສຂອງຜູ້ໃຊ້ຄລາວທັງໝົດ. ທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າດີແລະການໂຫຼດຄວນໄດ້ຮັບການແຈກຢາຍຢ່າງເທົ່າທຽມກັນໃນທົ່ວທຸກຂໍ້. Nodes ແມ່ນມີອໍານາດຫຼາຍແລະມັນຍາກທີ່ຈະ overload ພວກມັນ.

ແຕ່ພວກເຮົາສ້າງສະຖາປັດຕະຍະກໍາຂອງພວກເຮົາໂດຍອີງໃສ່ສະຖານະການທີ່ບໍ່ເປັນໄປໄດ້. 

ຄວາມເປັນໄປໄດ້ຕໍ່າບໍ່ໄດ້ຫມາຍຄວາມວ່າເປັນໄປບໍ່ໄດ້.

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

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

ໃຫ້ເຮົາເຮັດສິ່ງທີ່ແຕກຕ່າງ. ພວກເຮົາຈະຈັດສັນພຽງແຕ່ 3 nodes ໃຫ້ກັບຜູ້ໃຊ້ແຕ່ລະຄົນ. 

ເຄັດລັບແມ່ນການຕັ້ງຂໍ້ສຸ່ມໃຫ້ກັບຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນ. ໃນຮູບຂ້າງລຸ່ມນີ້, ຜູ້ໃຊ້ສີຟ້າຕັດກັນກັບຫນຶ່ງໃນສອງຜູ້ໃຊ້ອື່ນໆ - ສີຂຽວແລະສີສົ້ມ.

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

ຈໍານວນຜູ້ໃຊ້ທີ່ຈະຕັດກັນ

ຄວາມເປັນໄປໄດ້ໃນອັດຕາສ່ວນ

0

18%

1

54%

2

26%

3

2%

ຂໍໃຫ້ສະຖານະການໃກ້ຊິດກັບຄວາມເປັນຈິງ - ໃຫ້ເອົາ 100 nodes ແລະຜູ້ໃຊ້ 5 ຄົນໃນ 5 nodes. ໃນກໍລະນີນີ້, nodes ທີ່ບໍ່ມີຈະຕັດກັນກັບຄວາມເປັນໄປໄດ້ຂອງ 77%. 

ຈໍານວນຜູ້ໃຊ້ທີ່ຈະຕັດກັນ

ຄວາມເປັນໄປໄດ້ໃນອັດຕາສ່ວນ

0

77%

1

21%

2

1,8%

3

0,06%

4

0,0006%

5

0,00000013%

ໃນສະຖານະການທີ່ແທ້ຈິງ, ດ້ວຍຈໍານວນ HyperPlane nodes ແລະຜູ້ໃຊ້ຈໍານວນຫຼວງຫຼາຍ, ຜົນກະທົບທີ່ອາດເກີດຂື້ນຂອງເພື່ອນບ້ານທີ່ບໍ່ມີສຽງຕໍ່ຜູ້ໃຊ້ອື່ນໆແມ່ນມີຫນ້ອຍ. ວິທີການນີ້ເອີ້ນວ່າ ການປະສົມ sharding - shuffle shuffle. ມັນຫຼຸດຜ່ອນຜົນກະທົບທາງລົບຂອງຄວາມລົ້ມເຫຼວຂອງ node.

ການບໍລິການຫຼາຍຢ່າງຖືກສ້າງຂຶ້ນບົນພື້ນຖານຂອງ HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.

ຂະໜາດເຄືອຂ່າຍ

ຕອນນີ້ໃຫ້ເວົ້າກ່ຽວກັບຂະຫນາດຂອງເຄືອຂ່າຍຂອງມັນເອງ. ສໍາລັບເດືອນຕຸລາ 2019 AWS ໃຫ້ບໍລິການຂອງຕົນໃນ 22 ພາກພື້ນ, ແລະອີກ 9 ແຜນການ.

• ແຕ່​ລະ​ພາກ​ພື້ນ​ປະ​ກອບ​ດ້ວຍ​ເຂດ​ຈໍາ​ນວນ​ຫນຶ່ງ​. ມີ 69 ຂອງພວກເຂົາໃນທົ່ວໂລກ.
• ແຕ່ລະ AZ ປະກອບດ້ວຍສູນປະມວນຜົນຂໍ້ມູນ. ທັງໝົດມີບໍ່ເກີນ 8 ອັນ.
• ສູນຂໍ້ມູນມີເຄື່ອງແມ່ຂ່າຍຈໍານວນຫລາຍ, ບາງບ່ອນມີເຖິງ 300.

ຕອນນີ້ໃຫ້ພວກເຮົາສະເລ່ຍທັງຫມົດນີ້, ຄູນແລະໄດ້ຮັບຕົວເລກທີ່ຫນ້າປະທັບໃຈທີ່ສະທ້ອນໃຫ້ເຫັນ Amazon cloud scale.

ມີການເຊື່ອມຕໍ່ optical ຫຼາຍລະຫວ່າງ Availability Zones ແລະສູນຂໍ້ມູນ. ຫນຶ່ງໃນພາກພື້ນທີ່ໃຫຍ່ທີ່ສຸດຂອງພວກເຮົາ, 388 ຊ່ອງທາງໄດ້ຖືກວາງໄວ້ພຽງແຕ່ສໍາລັບການສື່ສານ AZ ລະຫວ່າງກັນແລະກັນແລະສູນການສື່ສານກັບພາກພື້ນອື່ນໆ (ສູນການຂົນສົ່ງ). ໃນຈໍານວນທັງຫມົດນີ້ເຮັດໃຫ້ Crazy 5000 Tbit.

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

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

ເສັ້ນສະແດງສະແດງໃຫ້ເຫັນວ່າສ່ວນແບ່ງຂອງຜູ້ໃຫ້ບໍລິການເນື້ອຫາແລະຜູ້ໃຫ້ບໍລິການຟັງແມ່ນເຕີບໂຕ. ເນື່ອງຈາກວ່ານີ້, ສ່ວນແບ່ງຂອງການຈະລາຈອນທາງອິນເຕີເນັດຂອງຜູ້ໃຫ້ບໍລິການ backbone ແມ່ນຫຼຸດລົງຢ່າງຕໍ່ເນື່ອງ.

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

ຂ້ອຍສົງໄສວ່າອິນເຕີເນັດຈະປ່ຽນແປງແນວໃດໃນ 10 ປີຖ້າແນວໂນ້ມນີ້ຍັງສືບຕໍ່?

ຊ່ອງທາງທາງດ້ານຮ່າງກາຍ

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

ໃນບາງພາກພື້ນພວກເຮົາຕ້ອງໃຊ້ສາຍພິເສດ. ຕົວຢ່າງເຊັ່ນ, ໃນເຂດ Sydney ພວກເຮົາໃຊ້ສາຍເຄເບີ້ນທີ່ມີສານເຄືອບຕ້ານແມງໄມ້ພິເສດ. 

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

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

ນີ້ແມ່ນສ່ວນສຸດທ້າຍຂອງ trilogy ຈາກ Vasily Pantyukhin ກ່ຽວກັບອຸປະກອນ AWS. IN ທໍາອິດ ພາກສ່ວນອະທິບາຍການເພີ່ມປະສິດທິພາບຂອງເຄື່ອງແມ່ຂ່າຍແລະການຂະຫຍາຍຖານຂໍ້ມູນ, ແລະໃນ ຄັ້ງທີສອງ — ຫນ້າ​ທີ່ serverless ແລະ Firecracker.

ກ່ຽວກັບ ໂຫຼດສູງ ++ ໃນເດືອນພະຈິກ Vasily Pantyukhin ຈະແບ່ງປັນລາຍລະອຽດໃຫມ່ຂອງອຸປະກອນ Amazon. ລາວ ຈະບອກ ກ່ຽວກັບສາເຫດຂອງຄວາມລົ້ມເຫລວແລະການອອກແບບຂອງລະບົບແຈກຢາຍຢູ່ Amazon. ວັນທີ 24 ຕຸລາຍັງເປັນໄປໄດ້ ຈອງ ປີ້ໃນລາຄາທີ່ດີ, ແລະຈ່າຍຕໍ່ມາ. ພວກເຮົາກຳລັງລໍຖ້າທ່ານຢູ່ HighLoad++, ມາລົມກັນນຳກັນ!

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