Admin ບໍ່ມີມື = hyperconvergence?

ນີ້ແມ່ນ myth ທີ່ຂ້ອນຂ້າງທົ່ວໄປໃນພາກສະຫນາມຂອງຮາດແວເຊີຟເວີ. ໃນການປະຕິບັດ, ການແກ້ໄຂ hyperconverged (ເມື່ອທຸກສິ່ງທຸກຢ່າງຢູ່ໃນຫນຶ່ງ) ແມ່ນຈໍາເປັນສໍາລັບຫຼາຍສິ່ງ. ໃນປະຫວັດສາດ, ສະຖາປັດຕະຍະກໍາທໍາອິດໄດ້ຖືກພັດທະນາໂດຍ Amazon ແລະ Google ສໍາລັບການບໍລິການຂອງພວກເຂົາ. ຫຼັງຈາກນັ້ນ, ແນວຄວາມຄິດແມ່ນເພື່ອເຮັດໃຫ້ກະສິກໍາຄອມພິວເຕີຈາກ nodes ດຽວກັນ, ແຕ່ລະແຜ່ນມີແຜ່ນຂອງຕົນເອງ. ທັງໝົດນີ້ໄດ້ຖືກລວມເຂົ້າກັນໂດຍບາງຊອບແວທີ່ສ້າງລະບົບ (hypervisor) ແລະແບ່ງອອກເປັນເຄື່ອງ virtual. ເປົ້າຫມາຍຕົ້ນຕໍແມ່ນຄວາມພະຍາຍາມຕໍາ່ສຸດທີ່ສໍາລັບການບໍລິການຫນຶ່ງ node ແລະຕໍາ່ສຸດທີ່ຂອງບັນຫາໃນເວລາທີ່ການຂະຫນາດ: ພຽງແຕ່ຊື້ຫນຶ່ງພັນຫຼືສອງຂອງເຄື່ອງແມ່ຂ່າຍດຽວກັນແລະເຊື່ອມຕໍ່ໃຫ້ເຂົາເຈົ້າໃກ້ຄຽງ. ໃນທາງປະຕິບັດ, ເຫຼົ່ານີ້ແມ່ນກໍລະນີທີ່ໂດດດ່ຽວ, ແລະຫຼາຍຂື້ນເລື້ອຍໆພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບຈໍານວນຂໍ້ນ້ອຍກວ່າແລະສະຖາປັດຕະຍະກໍາທີ່ແຕກຕ່າງກັນເລັກນ້ອຍ.

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

ມັນ turns ໃຫ້ ເຫັນ ວ່າ ທ່ານ ຈ່າຍ 10-15% ເພີ່ມ ເຕີມ ສໍາ ລັບ ຄວາມ ງ່າຍ ຂອງ ການ ຕັ້ງ. ນີ້ແມ່ນສິ່ງທີ່ກະຕຸ້ນໃຫ້ myth ໃນຫົວຂໍ້. ພວກເຮົາໃຊ້ເວລາເປັນເວລາດົນນານຊອກຫາບ່ອນທີ່ເຕັກໂນໂລຊີຈະຖືກນໍາໃຊ້ທີ່ດີທີ່ສຸດ, ແລະພວກເຮົາໄດ້ພົບເຫັນມັນ. ຄວາມຈິງແລ້ວແມ່ນວ່າ Cisco ບໍ່ມີລະບົບການເກັບຮັກສາຂອງຕົນເອງ, ແຕ່ພວກເຂົາຕ້ອງການຕະຫຼາດເຄື່ອງແມ່ຂ່າຍທີ່ສົມບູນ. ແລະພວກເຂົາໄດ້ເຮັດ Cisco Hyperflex - ການແກ້ໄຂທີ່ມີການເກັບຮັກສາທ້ອງຖິ່ນໃນ nodes.

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

ບ່ອນທີ່ຕ້ອງການ

Hyperconvergence ແມ່ນ:

1. ການ​ໂອນ​ແຜ່ນ​ກັບ​ຂໍ້​ມູນ​ການ​ຄິດ​ໄລ່​.
2. ການເຊື່ອມໂຍງຢ່າງເຕັມທີ່ຂອງລະບົບຍ່ອຍການເກັບຮັກສາກັບລະບົບຍ່ອຍ virtualization.
3. ການ​ຖ່າຍ​ໂອນ / ການ​ເຊື່ອມ​ໂຍງ​ກັບ​ລະ​ບົບ​ຍ່ອຍ​ເຄືອ​ຂ່າຍ​.

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

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

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

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

ການທົດສອບ

ຕົວຢ່າງຂອງພວກເຮົາປະກອບດ້ວຍສີ່ເຊີບເວີ, ແຕ່ລະອັນມີ 10 SSD drives ຂອງ 960 GB. ມີແຜ່ນສະເພາະສໍາລັບການດໍາເນີນການຂຽນ caching ແລະເກັບຮັກສາເຄື່ອງ virtual ການບໍລິການ. ການແກ້ໄຂຕົວມັນເອງແມ່ນສະບັບທີສີ່. ທໍາອິດແມ່ນຂີ້ຕົວະຢ່າງກົງໄປກົງມາ (ການຕັດສິນໂດຍການທົບທວນຄືນ), ອັນທີສອງແມ່ນປຽກ, ທີສາມແມ່ນຂ້ອນຂ້າງຄົງທີ່, ແລະອັນນີ້ສາມາດເອີ້ນວ່າການປ່ອຍຫຼັງຈາກສິ້ນສຸດການທົດສອບເບຕ້າສໍາລັບປະຊາຊົນທົ່ວໄປ. ໃນລະຫວ່າງການທົດສອບຂ້ອຍບໍ່ເຫັນບັນຫາໃດໆ, ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຄືກັບໂມງ.

ການປ່ຽນແປງໃນ v4ແມງໄມ້ຈຳນວນໜຶ່ງໄດ້ຮັບການແກ້ໄຂແລ້ວ.

ໃນເບື້ອງຕົ້ນ, ແພລະຕະຟອມພຽງແຕ່ສາມາດເຮັດວຽກກັບ VMware ESXi hypervisor ແລະສະຫນັບສະຫນູນຈໍານວນນ້ອຍຂອງ nodes. ນອກຈາກນີ້, ຂະບວນການນຳໃຊ້ບໍ່ໄດ້ຈົບລົງສະເໝີໄປ, ບາງຂັ້ນຕອນຕ້ອງໄດ້ເລີ່ມໃໝ່, ມີບັນຫາກັບການອັບເດດຈາກລຸ້ນເກົ່າ, ຂໍ້ມູນໃນ GUI ບໍ່ໄດ້ຖືກສະແດງຢ່າງຖືກຕ້ອງສະເໝີ (ເຖິງແມ່ນວ່າຂ້ອຍບໍ່ພໍໃຈກັບການສະແດງກຣາຟປະສິດທິພາບ. ), ບາງຄັ້ງບັນຫາເກີດຂຶ້ນໃນການໂຕ້ຕອບກັບ virtualization .

ໃນປັດຈຸບັນບັນຫາເດັກນ້ອຍທັງຫມົດໄດ້ຖືກແກ້ໄຂ, HyperFlex ສາມາດຈັດການກັບທັງ ESXi ແລະ Hyper-V, ບວກກັບມັນເປັນໄປໄດ້:

1. ການສ້າງກຸ່ມທີ່ຍືດຍາວ.
2. ການສ້າງກຸ່ມສໍາລັບຫ້ອງການໂດຍບໍ່ມີການນໍາໃຊ້ Fabric Interconnect, ຈາກສອງຫາສີ່ຂໍ້ (ພວກເຮົາຊື້ພຽງແຕ່ເຄື່ອງແມ່ຂ່າຍ).
3. ຄວາມສາມາດໃນການເຮັດວຽກກັບລະບົບການເກັບຮັກສາພາຍນອກ.
4. ຮອງຮັບຕູ້ຄອນເທນເນີ ແລະ Kubernetes.
5. ການສ້າງເຂດທີ່ມີໃຫ້.
6. ການປະສົມປະສານກັບ VMware SRM ຖ້າການທໍາງານໃນຕົວບໍ່ຫນ້າພໍໃຈ.

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

ພວກເຮົາຈະພິຈາລະນາການແກ້ໄຂສໍາລັບ VMware, ນັບຕັ້ງແຕ່ການແກ້ໄຂໄດ້ຖືກສ້າງຂື້ນໃນເບື້ອງຕົ້ນສໍາລັບມັນແລະມີຫນ້າທີ່ເພີ່ມເຕີມ; Hyper-V ໄດ້ຖືກເພີ່ມຕາມທາງເພື່ອໃຫ້ທັນກັບຄູ່ແຂ່ງແລະຕອບສະຫນອງຄວາມຄາດຫວັງຂອງຕະຫຼາດ.

ມີກຸ່ມເຊີບເວີທີ່ເຕັມໄປດ້ວຍແຜ່ນ. ມີແຜ່ນສໍາລັບການເກັບຮັກສາຂໍ້ມູນ (SSD ຫຼື HDD - ຕາມລົດຊາດແລະຄວາມຕ້ອງການຂອງທ່ານ), ມີແຜ່ນ SSD ຫນຶ່ງສໍາລັບການເກັບຂໍ້ມູນ. ເມື່ອຂຽນຂໍ້ມູນໃສ່ບ່ອນເກັບຂໍ້ມູນ, ຂໍ້ມູນຈະຖືກບັນທຶກໄວ້ໃນຊັ້ນເກັບຂໍ້ມູນ (ແຜ່ນ SSD ສະເພາະ ແລະ RAM ຂອງບໍລິການ VM). ໃນຂະຫນານ, ບລັອກຂອງຂໍ້ມູນຖືກສົ່ງໄປຫາ nodes ໃນ cluster (ຈໍານວນຂອງ nodes ແມ່ນຂຶ້ນກັບປັດໄຈການຈໍາລອງຂອງກຸ່ມ). ຫຼັງຈາກການຢືນຢັນຈາກທຸກ nodes ກ່ຽວກັບການບັນທຶກສົບຜົນສໍາເລັດ, ການຢືນຢັນຂອງການບັນທຶກແມ່ນຖືກສົ່ງໄປຫາ hypervisor ແລະຫຼັງຈາກນັ້ນກັບ VM. ຂໍ້​ມູນ​ທີ່​ບັນ​ທຶກ​ໄວ້​ແມ່ນ deduplicated​, compressed ແລະ​ລາຍ​ລັກ​ອັກ​ສອນ​ໃນ​ແຜ່ນ​ເກັບ​ຮັກ​ສາ​ໃນ​ພື້ນ​ຖານ​. ໃນເວລາດຽວກັນ, ຕັນຂະຫນາດໃຫຍ່ແມ່ນສະເຫມີຂຽນໃສ່ແຜ່ນເກັບຮັກສາແລະຕາມລໍາດັບ, ເຊິ່ງຊ່ວຍຫຼຸດຜ່ອນການໂຫຼດໃນແຜ່ນເກັບຮັກສາ.

ການຄັດລອກແລະການບີບອັດແມ່ນຖືກເປີດໃຊ້ຕະຫຼອດເວລາແລະບໍ່ສາມາດປິດການໃຊ້ງານໄດ້. ຂໍ້ມູນຖືກອ່ານໂດຍກົງຈາກແຜ່ນເກັບຂໍ້ມູນຫຼືຈາກ RAM cache. ຖ້າໃຊ້ການຕັ້ງຄ່າແບບປະສົມ, ການອ່ານຈະຖືກເກັບໄວ້ໃນ SSD.

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

ການບໍລິການພິເສດ VM Cisco HyperFlex Data Platform controller, ເຊິ່ງຖືກສ້າງຂື້ນຢູ່ໃນແຕ່ລະ node ການເກັບຮັກສາ, ຮັບຜິດຊອບຕໍ່ເຫດຜົນການດໍາເນີນງານທັງຫມົດຂອງລະບົບຍ່ອຍຂອງແຜ່ນ. ໃນການຕັ້ງຄ່າ VM ການບໍລິການຂອງພວກເຮົາ, ແປດ vCPUs ແລະ 72 GB ຂອງ RAM ໄດ້ຖືກຈັດສັນ, ເຊິ່ງບໍ່ແມ່ນຫນ້ອຍ. ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າເຈົ້າພາບຕົວມັນເອງມີ 28 ແກນທາງດ້ານຮ່າງກາຍແລະ 512 GB ຂອງ RAM.

ການບໍລິການ VM ມີການເຂົ້າເຖິງແຜ່ນຟີຊິກໂດຍກົງໂດຍການສົ່ງຕໍ່ຕົວຄວບຄຸມ SAS ໄປຫາ VM. ການສື່ສານກັບ hypervisor ເກີດຂຶ້ນໂດຍຜ່ານໂມດູນພິເສດ IOVisor, ເຊິ່ງຂັດຂວາງການດໍາເນີນງານ I/O, ແລະນໍາໃຊ້ຕົວແທນທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດສົ່ງຄໍາສັ່ງໄປຫາ hypervisor API. ຕົວແທນແມ່ນຮັບຜິດຊອບໃນການເຮັດວຽກກັບ HyperFlex snapshots ແລະ clones.

ຊັບພະຍາກອນຂອງແຜ່ນຖືກຕິດຕັ້ງຢູ່ໃນ hypervisor ເປັນການແບ່ງປັນ NFS ຫຼື SMB (ຂຶ້ນກັບປະເພດຂອງ hypervisor, ຄາດເດົາວ່າອັນໃດຢູ່ບ່ອນ). ແລະພາຍໃຕ້ຝາອັດປາກຂຸມ, ນີ້ແມ່ນລະບົບໄຟລ໌ທີ່ແຈກຢາຍທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດເພີ່ມຄຸນສົມບັດຂອງລະບົບການເກັບຮັກສາເຕັມທີ່ຂອງຜູ້ໃຫຍ່: ການຈັດສັນປະລິມານບາງໆ, ການບີບອັດແລະການຖອດອອກ, ພາບຖ່າຍໂດຍໃຊ້ເທກໂນໂລຍີ Redirect-on-Write, ການຈໍາລອງແບບ synchronous / asynchronous.

ການບໍລິການ VM ໃຫ້ການເຂົ້າເຖິງການໂຕ້ຕອບການຈັດການ WEB ຂອງລະບົບຍ່ອຍ HyperFlex. ມີການເຊື່ອມໂຍງກັບ vCenter, ແລະວຽກງານປະຈໍາວັນສ່ວນໃຫຍ່ສາມາດປະຕິບັດໄດ້ຈາກມັນ, ແຕ່ datastores, ສໍາລັບການຍົກຕົວຢ່າງ, ແມ່ນສະດວກກວ່າທີ່ຈະຕັດຈາກ webcam ແຍກຕ່າງຫາກຖ້າຫາກວ່າທ່ານໄດ້ປ່ຽນໄປເປັນການໂຕ້ຕອບ HTML5 ທີ່ໄວແລ້ວ, ຫຼືໃຊ້ Flash client ເຕັມຮູບແບບ. ກັບ​ການ​ເຊື່ອມ​ໂຍງ​ຢ່າງ​ເຕັມ​ທີ່​. ໃນ webcam ການບໍລິການທ່ານສາມາດເບິ່ງປະສິດທິພາບແລະສະຖານະການລາຍລະອຽດຂອງລະບົບ.

ມີໂຫມດປະເພດອື່ນຢູ່ໃນກຸ່ມ - computing nodes . ເຫຼົ່ານີ້ສາມາດເປັນເຊີບເວີ rack ຫຼື blade ໂດຍບໍ່ມີແຜ່ນໃນຕົວ. ເຊີບເວີເຫຼົ່ານີ້ສາມາດເອີ້ນໃຊ້ VMs ທີ່ຂໍ້ມູນຖືກເກັບໄວ້ໃນເຊີບເວີທີ່ມີແຜ່ນ. ຈາກທັດສະນະຂອງການເຂົ້າເຖິງຂໍ້ມູນ, ບໍ່ມີຄວາມແຕກຕ່າງກັນລະຫວ່າງປະເພດຂອງໂຫນດ, ເພາະວ່າສະຖາປັດຕະຍະກໍາກ່ຽວຂ້ອງກັບການ abstraction ຈາກສະຖານທີ່ທາງດ້ານຮ່າງກາຍຂອງຂໍ້ມູນ. ອັດ​ຕາ​ສ່ວນ​ສູງ​ສຸດ​ຂອງ​ຂໍ້​ມູນ​ຂອງ​ຄອມ​ພິວ​ເຕີ​ກັບ nodes ການ​ເກັບ​ຮັກ​ສາ​ແມ່ນ 2:1​.

ການ​ນໍາ​ໃຊ້​ຂໍ້​ມູນ​ຂອງ​ຄອມ​ພິວ​ເຕີ​ເພີ່ມ​ຄວາມ​ຢືດ​ຢຸ່ນ​ໃນ​ເວ​ລາ​ທີ່​ການ​ຂະ​ຫຍາຍ​ຊັບ​ພະ​ຍາ​ກອນ cluster​: ພວກ​ເຮົາ​ບໍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ຊື້ nodes ເພີ່ມ​ເຕີມ​ທີ່​ມີ​ແຜ່ນ​ຖ້າ​ຫາກ​ວ່າ​ພວກ​ເຮົາ​ພຽງ​ແຕ່​ຕ້ອງ​ການ CPU / RAM​. ນອກຈາກນັ້ນ, ພວກເຮົາສາມາດເພີ່ມ cage ແຜ່ນໃບຄ້າຍຄືແລະປະຫຍັດການຈັດວາງ rack ຂອງເຄື່ອງແມ່ຂ່າຍ.

ດັ່ງນັ້ນ, ພວກເຮົາມີເວທີ hyperconverged ທີ່ມີລັກສະນະດັ່ງຕໍ່ໄປນີ້:

• ເຖິງ 64 nodes ໃນ cluster (ເຖິງ 32 nodes ການເກັບຮັກສາ).
• ຈຳນວນຂັ້ນຕ່ຳຂອງ nodes ໃນກຸ່ມແມ່ນສາມ (ສອງອັນສຳລັບກຸ່ມ Edge).
• ກົນໄກການຊໍ້າຊ້ອນຂໍ້ມູນ: ການສະທ້ອນກັບປັດໄຈການຈໍາລອງ 2 ແລະ 3.
• ກຸ່ມ Metro.
• Asynchronous VM replication ກັບກຸ່ມ HyperFlex ອື່ນ.
• Orchestration ການປ່ຽນ VMs ເປັນສູນຂໍ້ມູນທາງໄກ.
• ພາບຖ່າຍພື້ນເມືອງໂດຍໃຊ້ເທກໂນໂລຍີ Redirect-on-Write.
• ສູງສຸດ 1 PB ຂອງພື້ນທີ່ໃຊ້ໄດ້ຢູ່ທີ່ປັດໄຈການຈໍາລອງ 3 ແລະບໍ່ມີການຊໍ້າຊ້ອນ. ພວກເຮົາບໍ່ໄດ້ຄໍານຶງເຖິງປັດໄຈ replication 2, ເນື່ອງຈາກວ່ານີ້ບໍ່ແມ່ນທາງເລືອກສໍາລັບການຂາຍທີ່ຮ້າຍແຮງ.

ບວກໃຫຍ່ອີກອັນໜຶ່ງແມ່ນຄວາມງ່າຍໃນການຈັດການ ແລະການນຳໃຊ້. ຄວາມສັບສົນທັງໝົດຂອງການຕັ້ງຄ່າເຊີບເວີ UCS ແມ່ນໄດ້ຮັບການເບິ່ງແຍງໂດຍ VM ພິເສດທີ່ກະກຽມໂດຍວິສະວະກອນ Cisco.

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

• 2 x Cisco UCS Fabric Interconnect 6248UP ເປັນກຸ່ມການຈັດການ ແລະອົງປະກອບເຄືອຂ່າຍ (48 ພອດທີ່ເຮັດວຽກຢູ່ໃນໂໝດ Ethernet 10G/FC 16G).
• ສີ່ເຊີບເວີ Cisco UCS HXAF240 M4.

ຄຸນ​ລັກ​ສະ​ນະ​ຂອງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​:

CPU

2 x Intel® Xeon® E5-2690 v4

RAM

16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/ອັນດັບສອງ/x4/1.2v

ເຄືອຂ່າຍ

UCSC-MLOM-CSC-02 (VIC 1227). 2 ຜອດອີເທີເນັດ 10G

ການເກັບຮັກສາ HBA

Cisco 12G Modular SAS ຜ່ານຕົວຄວບຄຸມ

ແຜ່ນເກັບຮັກສາ

1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB

ຕົວເລືອກການຕັ້ງຄ່າເພີ່ມເຕີມນອກ​ເຫນືອ​ໄປ​ຈາກ​ຮາດ​ແວ​ທີ່​ເລືອກ​, ທາງ​ເລືອກ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​ແມ່ນ​ມີ​ຢູ່​ໃນ​ປັດ​ຈຸ​ບັນ​:

• HXAF240c M5.
• ຫນຶ່ງຫຼືສອງ CPUs ຕັ້ງແຕ່ Intel Silver 4110 ຫາ Intel Platinum I8260Y. ລຸ້ນທີສອງສາມາດໃຊ້ໄດ້.
• 24 ຊ່ອງໃສ່ຫນ່ວຍຄວາມຈໍາ, ແຖບຈາກ 16 GB RDIMM 2600 ເຖິງ 128 GB LRDIMM 2933.
• ຈາກ 6 ຫາ 23 ແຜ່ນຂໍ້ມູນ, ແຜ່ນ caching ຫນຶ່ງ, ແຜ່ນລະບົບຫນຶ່ງແລະແຜ່ນ boot ຫນຶ່ງ.

Capacity Drives

• HX-SD960G61X-EV 960GB 2.5 ນິ້ວ Enterprise Value 6G SATA SSD (1X endurance) SAS 960 GB.
• HX-SD38T61X-EV 3.8TB 2.5 ນິ້ວ Enterprise Value 6G SATA SSD (1X endurance) SAS 3.8 TB.
• Caching Drives
• HX-NVMEXPB-I375 375GB 2.5 ນິ້ວ Intel Optane Drive, Extreme Perf & Endurance.
• HX-NVMEHW-H1600* 1.6TB 2.5 ນິ້ວ Ent. Perf. NVMe SSD (3X endurance) NVMe 1.6 TB.
• HX-SD400G12TX-EP 400GB 2.5 ນິ້ວ Ent. Perf. 12G SAS SSD (10X endurance) SAS 400 GB.
• HX-SD800GBENK9** 800GB 2.5 ນິ້ວ Ent. Perf. 12G SAS SED SSD (10X endurance) SAS 800 GB.
• HX-SD16T123X-EP 1.6TB 2.5 ນິ້ວ Enterprise performance 12G SAS SSD (3X endurance).

ລະບົບ/ບັນທຶກ Drives

• HX-SD240GM1X-EV 240GB 2.5 ນິ້ວ Enterprise Value 6G SATA SSD (ຕ້ອງການການອັບເກຣດ).

Boot Drives

• HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.

ເຊື່ອມຕໍ່ເຄືອຂ່າຍຜ່ານພອດ 40G, 25G ຫຼື 10G Ethernet.

FI ສາມາດເປັນ HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).

ການທົດສອບຕົວມັນເອງ

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

ກຸ່ມຂອງພວກເຮົາປະກອບດ້ວຍສີ່ nodes, replication factor 3, ແຜ່ນທັງຫມົດແມ່ນ Flash.

ສໍາລັບການທົດສອບ, ຂ້າພະເຈົ້າໄດ້ສ້າງສີ່ datastores ແລະແປດ virtual machines. ສໍາ​ລັບ​ການ​ທົດ​ສອບ​ການ​ຂຽນ​, ມັນ​ສົມ​ມຸດ​ວ່າ​ແຜ່ນ​ຖານ​ຄວາມ​ຈໍາ​ບໍ່​ເຕັມ​ທີ່​.

ຜົນ​ການ​ທົດ​ສອບ​ມີ​ດັ່ງ​ນີ້​:

100% ອ່ານແບບສຸ່ມ 100%.

0% ອ່ານ 100% Random

ຕັນ/ຄວາມເລິກແຖວ

128

256

512

1024

2048

128

256

512

1024

2048

4K

0,59 ms 213804 IOPS

0,84 ms 303540 IOPS

1,36ms 374348 IOPS

2.47 ms 414116 IOPS

4,86ms 420180 IOPS

2,22 ms 57408 IOPS

3,09 ms 82744 IOPS

5,02 ms 101824 IPOS

8,75 ms 116912 IOPS

17,2 ms 118592 IOPS

8K

0,67 ms 188416 IOPS

0,93 ms 273280 IOPS

1,7 ms 299932 IOPS

2,72 ms 376,484 IOPS

5,47 ms 373,176 IOPS

3,1 ms 41148 IOPS

4,7 ms 54396 IOPS

7,09 ms 72192 IOPS

12,77 ms 80132 IOPS

16K

0,77 ms 164116 IOPS

1,12 ms 228328 IOPS

1,9 ms 268140 IOPS

3,96 ms 258480 IOPS

3,8 ms 33640 IOPS

6,97 ms 36696 IOPS

11,35 ms 45060 IOPS

32K

1,07 ms 119292 IOPS

1,79 ms 142888 IOPS

3,56 ms 143760 IOPS

7,17 ms 17810 IOPS

11,96 ms 21396 IOPS

64K

1,84 ms 69440 IOPS

3,6 ms 71008 IOPS

7,26 ms 70404 IOPS

11,37 ms 11248 IOPS

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

• ອ່ານຕາມລຳດັບ 4432 MB/s.
• ຂຽນຕາມລໍາດັບ 804 MB/s.
• ຖ້າຕົວຄວບຄຸມຫນຶ່ງລົ້ມເຫລວ (ຄວາມລົ້ມເຫຼວຂອງເຄື່ອງ virtual ຫຼືເຈົ້າພາບ), ການປະຕິບັດການຫຼຸດລົງແມ່ນສອງເທົ່າ.
• ຖ້າແຜ່ນເກັບຂໍ້ມູນລົ້ມເຫລວ, ການຫຼຸດລົງແມ່ນ 1/3. Disk rebuild ໃຊ້ເວລາ 5% ຂອງຊັບພະຍາກອນຂອງແຕ່ລະ controller.

ໃນບລັອກຂະຫນາດນ້ອຍ, ພວກເຮົາຖືກຈໍາກັດໂດຍການປະຕິບັດຂອງຕົວຄວບຄຸມ (ເຄື່ອງຈັກ virtual), CPU ຂອງມັນຖືກໂຫລດຢູ່ທີ່ 100%, ແລະເມື່ອຕັນເພີ່ມຂຶ້ນ, ພວກເຮົາຖືກຈໍາກັດໂດຍແບນວິດຂອງພອດ. 10 Gbps ບໍ່ພຽງພໍທີ່ຈະປົດລັອກທ່າແຮງຂອງລະບົບ AllFlash. ແຕ່ຫນ້າເສຍດາຍ, ຕົວກໍານົດການຂອງຕົວສະແດງຕົວຢ່າງທີ່ສະຫນອງໃຫ້ບໍ່ອະນຸຍາດໃຫ້ພວກເຮົາທົດສອບການດໍາເນີນງານຢູ່ທີ່ 40 Gbit / s.

ໃນຄວາມປະທັບໃຈຂອງຂ້ອຍຈາກການທົດສອບແລະການສຶກສາສະຖາປັດຕະຍະກໍາ, ເນື່ອງຈາກ algorithm ທີ່ຈັດວາງຂໍ້ມູນລະຫວ່າງ hosts ທັງຫມົດ, ພວກເຮົາໄດ້ຮັບການຂະຫຍາຍ, ການປະຕິບັດທີ່ຄາດເດົາໄດ້, ແຕ່ນີ້ຍັງເປັນຂໍ້ຈໍາກັດໃນເວລາອ່ານ, ເພາະວ່າມັນເປັນໄປໄດ້ທີ່ຈະບີບອອກຫຼາຍຈາກແຜ່ນທ້ອງຖິ່ນ, ໃນທີ່ນີ້ມັນອາດຈະຊ່ວຍປະຢັດເຄືອຂ່າຍທີ່ມີປະສິດຕິຜົນຫຼາຍ, ຕົວຢ່າງ, FI ທີ່ 40 Gbit / s ສາມາດໃຊ້ໄດ້.

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

ການນໍາໃຊ້ຕົວຈິງ

ເພື່ອຈັດຕັ້ງສູນຂໍ້ມູນສໍາຮອງ, ທ່ານສາມາດນໍາໃຊ້ສອງວິທີການ (ພວກເຮົາບໍ່ໄດ້ພິຈາລະນາວາງ backup ຢູ່ໃນເວັບໄຊທ໌ຫ່າງໄກສອກຫຼີກ):

1. Active-Passive. ແອັບພລິເຄຊັນທັງໝົດຖືກຈັດຢູ່ໃນສູນຂໍ້ມູນຫຼັກ. ການຈຳລອງແມ່ນ synchronous ຫຼື asynchronous. ຖ້າສູນຂໍ້ມູນຫຼັກລົ້ມເຫລວ, ພວກເຮົາຈໍາເປັນຕ້ອງເປີດໃຊ້ການສໍາຮອງຂໍ້ມູນ. ນີ້ສາມາດເຮັດໄດ້ດ້ວຍຕົນເອງ / scripts / ຄໍາຮ້ອງສະຫມັກ orchestration. ໃນທີ່ນີ້ພວກເຮົາຈະໄດ້ຮັບ RPO ທີ່ເຫມາະສົມກັບຄວາມຖີ່ຂອງການຈໍາລອງ, ແລະ RTO ແມ່ນຂຶ້ນກັບປະຕິກິລິຍາແລະທັກສະຂອງຜູ້ບໍລິຫານແລະຄຸນນະພາບຂອງການພັດທະນາ / debugging ຂອງແຜນການສະຫຼັບ.
2. Active-Active. ໃນກໍລະນີນີ້, ມີພຽງແຕ່ການຈໍາລອງແບບ synchronous; ຄວາມພ້ອມຂອງສູນຂໍ້ມູນແມ່ນຖືກກໍານົດໂດຍ quorum / arbiter ທີ່ຕັ້ງຢູ່ຢ່າງເຂັ້ມງວດຢູ່ໃນເວັບໄຊທ໌ທີສາມ. RPO = 0, ແລະ RTO ສາມາດບັນລຸ 0 (ຖ້າແອັບພລິເຄຊັນອະນຸຍາດໃຫ້) ຫຼືເທົ່າກັບເວລາລົ້ມເຫລວຂອງ node ໃນກຸ່ມ virtualization. ໃນລະດັບ virtualization, ກຸ່ມຂະຫຍາຍ (Metro) ຖືກສ້າງຂື້ນທີ່ຮຽກຮ້ອງໃຫ້ມີການເກັບຮັກສາ Active-Active.

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

ສະຖານະການ 1: ພວກ​ເຮົາ​ມີ​ສູນ​ຂໍ້​ມູນ​ຕົ້ນ​ຕໍ​ແລະ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​, ເປັນ​ເວ​ທີ virtualization ໃນ VMware vSphere​. ລະບົບການຜະລິດທັງຫມົດແມ່ນຢູ່ໃນສູນຂໍ້ມູນຕົ້ນຕໍ, ແລະການຈໍາລອງເຄື່ອງ virtual ແມ່ນດໍາເນີນຢູ່ໃນລະດັບ hypervisor, ນີ້ຈະຫຼີກເວັ້ນການຮັກສາ VMs ເປີດຢູ່ໃນສູນຂໍ້ມູນສໍາຮອງ. ພວກເຮົາເຮັດເລື້ມຄືນຖານຂໍ້ມູນ ແລະແອັບພລິເຄຊັນພິເສດໂດຍໃຊ້ເຄື່ອງມືໃນຕົວ ແລະເປີດ VMs ໄວ້. ຖ້າສູນຂໍ້ມູນຫຼັກລົ້ມເຫລວ, ພວກເຮົາເປີດລະບົບໃນສູນຂໍ້ມູນສຳຮອງ. ພວກເຮົາເຊື່ອວ່າພວກເຮົາມີປະມານ 100 ເຄື່ອງ virtual. ໃນຂະນະທີ່ສູນຂໍ້ມູນຫຼັກເຮັດວຽກຢູ່, ສູນຂໍ້ມູນສະແຕນບາຍສາມາດແລ່ນສະພາບແວດລ້ອມການທົດສອບ ແລະລະບົບອື່ນໆທີ່ສາມາດປິດໄດ້ຖ້າສູນຂໍ້ມູນຫຼັກປ່ຽນໄປ. ມັນເປັນໄປໄດ້ວ່າພວກເຮົາໃຊ້ການຈໍາລອງແບບສອງທາງ. ຈາກທັດສະນະຂອງຮາດແວ, ບໍ່ມີຫຍັງປ່ຽນແປງ.

ໃນກໍລະນີຂອງສະຖາປັດຕະຍະກໍາຄລາສສິກ, ພວກເຮົາຈະຕິດຕັ້ງຢູ່ໃນສູນຂໍ້ມູນແຕ່ລະລະບົບການເກັບຮັກສາແບບປະສົມທີ່ມີການເຂົ້າເຖິງຜ່ານ FibreChannel, tiering, deduplication ແລະ compression (ແຕ່ບໍ່ແມ່ນອອນໄລນ໌), 8 ເຊີບເວີສໍາລັບແຕ່ລະເວັບໄຊທ໌, 2 FibreChannel switches ແລະ 10G Ethernet. ສໍາລັບການຈໍາລອງແລະການສະຫຼັບການຈັດການໃນສະຖາປັດຕະຍະກໍາຄລາສສິກ, ພວກເຮົາສາມາດນໍາໃຊ້ເຄື່ອງມື VMware (Replication + SRM) ຫຼືເຄື່ອງມືພາກສ່ວນທີສາມ, ເຊິ່ງຈະມີລາຄາຖືກກວ່າເລັກນ້ອຍແລະບາງຄັ້ງກໍ່ສະດວກກວ່າ.

ຕົວເລກສະແດງໃຫ້ເຫັນແຜນວາດ.

ເມື່ອນໍາໃຊ້ Cisco HyperFlex, ສະຖາປັດຕະຍະກໍາຕໍ່ໄປນີ້ແມ່ນໄດ້ຮັບ:

ສໍາລັບ HyperFlex, ຂ້ອຍໃຊ້ເຄື່ອງແມ່ຂ່າຍທີ່ມີຊັບພະຍາກອນ CPU / RAM ຂະຫນາດໃຫຍ່, ເພາະວ່າ ... ຊັບພະຍາກອນບາງຢ່າງຈະໄປຫາ HyperFlex controller VM; ໃນແງ່ຂອງ CPU ແລະຫນ່ວຍຄວາມຈໍາ, ຂ້ອຍຍັງໄດ້ປັບການຕັ້ງຄ່າ HyperFlex ເລັກນ້ອຍເພື່ອບໍ່ໃຫ້ຫຼີ້ນກັບ Cisco ແລະຮັບປະກັນຊັບພະຍາກອນສໍາລັບ VMs ທີ່ຍັງເຫຼືອ. ແຕ່ພວກເຮົາສາມາດປະຖິ້ມສະວິດ FibreChannel ໄດ້, ແລະພວກເຮົາຈະບໍ່ຕ້ອງການພອດ Ethernet ສໍາລັບແຕ່ລະເຊີບເວີ; ການຈະລາຈອນໃນທ້ອງຖິ່ນຈະຖືກປ່ຽນພາຍໃນ FI.

ຜົນໄດ້ຮັບແມ່ນການຕັ້ງຄ່າຕໍ່ໄປນີ້ສໍາລັບແຕ່ລະສູນຂໍ້ມູນ:

ເຊີບເວີ

ເຊີບເວີ 8 x 1U (RAM 384 GB, 2 x Intel Gold 6132, FC HBA)

8 x HX240C-M5L (RAM 512 GB, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)

SHD

ລະບົບການເກັບຮັກສາແບບປະສົມກັບ FC Front-End (20TB SSD, 130 TB NL-SAS)

-

LAN

2 x ສະຫຼັບອີເທີເນັດ 10G 12 ພອດ

-

SAN

2 x FC ສະຫຼັບ 32/16Gb 24 ພອດ

2 x Cisco UCS FI 6332

ໃບອະນຸຍາດ

VMware Ent Plus

ການຈຳລອງ ແລະ/ຫຼື ການຈັດລຽງການສະຫຼັບ VM

VMware Ent Plus

ຂ້າພະເຈົ້າບໍ່ໄດ້ໃຫ້ໃບອະນຸຍາດຊອບແວ replication ສໍາລັບ Hyperflex, ເນື່ອງຈາກວ່ານີ້ແມ່ນມີຢູ່ໃນກ່ອງສໍາລັບພວກເຮົາ.

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

ການແກ້ໄຂ Cisco HyperFlex ໄດ້ກາຍເປັນ 13% ລາຄາຖືກກວ່າ.

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

ສະຖາປັດຕະຍະກໍາຄລາສສິກປະກອບດ້ວຍເຄື່ອງແມ່ຂ່າຍ virtualization, SAN (FC protocol) ແລະສອງລະບົບການເກັບຮັກສາທີ່ສາມາດອ່ານແລະຂຽນກັບປະລິມານທີ່ຂ້ອນຂ້າງຍາວລະຫວ່າງພວກເຂົາ. ໃນແຕ່ລະລະບົບການເກັບຮັກສາພວກເຮົາໃສ່ຄວາມອາດສາມາດທີ່ເປັນປະໂຫຍດສໍາລັບການເກັບຮັກສາ.

ທີ່ HyperFlex ພວກເຮົາພຽງແຕ່ສ້າງ Stretch Cluster ທີ່ມີຈໍານວນດຽວກັນຂອງ nodes ໃນທັງສອງສະຖານທີ່. ໃນກໍລະນີນີ້, ປັດໄຈການຈໍາລອງຂອງ 2+2 ຖືກນໍາໃຊ້.

ຜົນໄດ້ຮັບແມ່ນການຕັ້ງຄ່າຕໍ່ໄປນີ້:

ສະຖາປັດຕະຍະກໍາຄລາສສິກ

HyperFlex

ເຊີບເວີ

ເຊີບເວີ 16 x 1U (RAM 384 GB, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)

16 x HX240C-M5L (RAM 512 GB, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)

SHD

2 x ລະບົບການເກັບຮັກສາ AllFlash (150 TB SSD)

-

LAN

4 x ສະຫຼັບອີເທີເນັດ 10G 24 ພອດ

-

SAN

4 x FC ສະຫຼັບ 32/16Gb 24 ພອດ

4 x Cisco UCS FI 6332

ໃບອະນຸຍາດ

VMware Ent Plus

VMware Ent Plus

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

ໃນແງ່ຂອງຄ່າໃຊ້ຈ່າຍ, HyperFlex ໄດ້ກາຍເປັນລາຄາແພງກວ່າ 5%. ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າໃນແງ່ຂອງຊັບພະຍາກອນ CPU / RAM ຂ້ອຍມີ skew ສໍາລັບ Cisco, ເພາະວ່າໃນການຕັ້ງຄ່າຂ້ອຍຕື່ມຊ່ອງຄວບຄຸມຫນ່ວຍຄວາມຈໍາເທົ່າທຽມກັນ. ຄ່າໃຊ້ຈ່າຍແມ່ນສູງກວ່າເລັກນ້ອຍ, ແຕ່ບໍ່ແມ່ນໂດຍຄໍາສັ່ງຂອງຂະຫນາດ, ເຊິ່ງຊີ້ໃຫ້ເຫັນຢ່າງຊັດເຈນວ່າ hyperconvergence ບໍ່ຈໍາເປັນຕ້ອງເປັນ "ຫຼິ້ນສໍາລັບຄົນຮັ່ງມີ", ແຕ່ສາມາດແຂ່ງຂັນກັບວິທີການມາດຕະຖານໃນການສ້າງສູນຂໍ້ມູນ. ນີ້ອາດຈະມີຄວາມສົນໃຈກັບຜູ້ທີ່ມີເຄື່ອງແມ່ຂ່າຍຂອງ Cisco UCS ແລະໂຄງສ້າງພື້ນຖານທີ່ສອດຄ້ອງກັນສໍາລັບພວກເຂົາ.

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

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

ເອກະສານ

• ຂໍ້ມູນຈໍາເພາະ
• ສູນຂໍ້ມູນສະເໝືອນ
• ສູນຂໍ້ມູນໃນລິ້ນຊັກໂຕະ
• ເມລຂອງຂ້ອຍ - [email protected]

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