ການປະຕິບັດການຈັດເກັບ SSD ໃນລະບົບການເກັບຮັກສາ QSAN XCubeSAN

ເທກໂນໂລຍີເພື່ອປັບປຸງການປະຕິບັດໂດຍອີງໃສ່ SSDs ແລະນໍາໃຊ້ຢ່າງກວ້າງຂວາງໃນລະບົບການເກັບຮັກສາໄດ້ຖືກປະດິດສ້າງມາດົນແລ້ວ. ກ່ອນອື່ນ ໝົດ, ມັນແມ່ນການໃຊ້ SSD ເປັນພື້ນທີ່ເກັບຮັກສາ, ເຊິ່ງມີປະສິດທິພາບ 100%, ແຕ່ລາຄາແພງ. ດັ່ງນັ້ນ, ເທັກໂນໂລຍີທີ່ອິດເມື່ອຍ ແລະ ການເກັບຂໍ້ມູນຖືກໃຊ້, ບ່ອນທີ່ SSDs ຖືກນໍາໃຊ້ພຽງແຕ່ສໍາລັບຂໍ້ມູນທີ່ນິຍົມທີ່ສຸດ ("ຮ້ອນ"). Tiering ແມ່ນດີສໍາລັບສະຖານະການຂອງໄລຍະຍາວ (ມື້ - ອາທິດ) ການນໍາໃຊ້ຂໍ້ມູນ "ຮ້ອນ". Caching, ໃນທາງກົງກັນຂ້າມ, ແມ່ນສໍາລັບການນໍາໃຊ້ໄລຍະສັ້ນ (ນາທີ - ຊົ່ວໂມງ). ທັງສອງທາງເລືອກເຫຼົ່ານີ້ຖືກປະຕິບັດໃນລະບົບການເກັບຮັກສາ QSAN XCubeSAN. ໃນບົດຄວາມນີ້ພວກເຮົາຈະເບິ່ງການປະຕິບັດຂອງ algorithm ທີສອງ - SSD caching.

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

ຕົວຊີ້ວັດສໍາລັບການນໍາໃຊ້ cache SSD ສໍາລັບການອ່ານ:

• ຄວາມເດັ່ນຂອງການປະຕິບັດການອ່ານຫຼາຍກວ່າການດໍາເນີນການຂຽນ (ສ່ວນຫຼາຍແມ່ນປົກກະຕິສໍາລັບຖານຂໍ້ມູນແລະຄໍາຮ້ອງສະຫມັກເວັບ);
• ການປະກົດຕົວຂອງຄໍຂວດໃນຮູບແບບຂອງການປະຕິບັດຂອງຮາດໄດ array;
• ຈໍານວນຂໍ້ມູນທີ່ຕ້ອງການແມ່ນຫນ້ອຍກວ່າຂະຫນາດຂອງ SSD cache.

ຕົວຊີ້ບອກສໍາລັບການນໍາໃຊ້ cache SSD ອ່ານ + ຂຽນແມ່ນຄືກັນ, ຍົກເວັ້ນລັກສະນະຂອງການດໍາເນີນງານ - ປະເພດປະສົມ (ຕົວຢ່າງ, ເຄື່ອງແມ່ຂ່າຍຂອງໄຟລ໌).

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

ແຄດ SSD ໃນ XCubeSAN ແມ່ນຖືກປະຕິບັດຢູ່ໃນຮູບແບບຂອງ SSD cache pools ແຍກຕ່າງຫາກ. ສາມາດມີເຖິງສີ່ຂອງພວກເຂົາຢູ່ໃນລະບົບ. ແຕ່ລະສະນຸກເກີ, ແນ່ນອນ, ໃຊ້ຊຸດ SSDs ຂອງຕົນເອງ. ແລະແລ້ວໃນຄຸນສົມບັດຂອງ virtual disk ພວກເຮົາກໍານົດວ່າມັນຈະໃຊ້ cache pool ແລະອັນໃດ. ການເປີດໃຊ້ງານ ແລະປິດການນຳໃຊ້ແຄດສຳລັບປະລິມານສາມາດເຮັດໄດ້ອອນໄລນ໌ໂດຍບໍ່ຕ້ອງຢຸດ I/O. ທ່ານຍັງສາມາດເພີ່ມ SSDs ໃສ່ສະນຸກເກີແລະເອົາພວກມັນອອກຈາກບ່ອນນັ້ນ. ເມື່ອສ້າງ SSD pool cache, ທ່ານຈໍາເປັນຕ້ອງເລືອກວ່າມັນຈະເຮັດວຽກໃນໂຫມດໃດ: read-only ຫຼື read+write. ອົງການຈັດຕັ້ງທາງດ້ານຮ່າງກາຍຂອງຕົນແມ່ນຂຶ້ນກັບນີ້. ເນື່ອງຈາກສາມາດມີຫຼາຍ cache pools, ການເຮັດວຽກຂອງພວກມັນສາມາດແຕກຕ່າງກັນ (ນັ້ນແມ່ນ, ລະບົບສາມາດມີທັງອ່ານແລະອ່ານ + ຂຽນ cache pools ໃນເວລາດຽວກັນ).

ຖ້າໃຊ້ cache pool ແບບອ່ານເທົ່ານັ້ນ, ມັນສາມາດປະກອບດ້ວຍ 1-8 SSDs. ແຜ່ນບໍ່ຈໍາເປັນຕ້ອງມີຄວາມສາມາດດຽວກັນແລະຜູ້ຂາຍດຽວກັນ, ຍ້ອນວ່າພວກມັນຖືກລວມເຂົ້າໃນໂຄງສ້າງ NRAID+. SSDs ທັງໝົດໃນສະນຸກເກີຖືກແບ່ງປັນ. ລະບົບເປັນເອກະລາດພະຍາຍາມຂະຫນານຄໍາຮ້ອງຂໍຂາເຂົ້າລະຫວ່າງ SSDs ທັງຫມົດເພື່ອບັນລຸປະສິດທິພາບສູງສຸດ. ຖ້າຫນຶ່ງຂອງ SSDs ລົ້ມເຫລວ, ບໍ່ມີຫຍັງທີ່ບໍ່ດີຈະເກີດຂຶ້ນ: ຫຼັງຈາກທີ່ທັງຫມົດ, cache ມີພຽງແຕ່ສໍາເນົາຂອງຂໍ້ມູນທີ່ເກັບໄວ້ໃນ array ຂອງຮາດໄດ. ມັນເປັນພຽງແຕ່ວ່າຈໍານວນແຄດ SSD ທີ່ມີຢູ່ຈະຫຼຸດລົງ (ຫຼືກາຍເປັນສູນຖ້າໃຊ້ແຄດ SSD ຕົ້ນສະບັບຈາກຫນຶ່ງໄດ).

ຖ້າ cache ຖືກນໍາໃຊ້ສໍາລັບການອ່ານ + ຂຽນ, ຫຼັງຈາກນັ້ນຈໍານວນຂອງ SSDs ໃນສະນຸກເກີຄວນຈະເປັນຈໍານວນຫຼາຍຂອງສອງ, ເນື່ອງຈາກວ່າເນື້ອໃນແມ່ນ mirrored ໃນຄູ່ຂອງ drives (ໂຄງສ້າງ NRAID 1+ ຖືກນໍາໃຊ້). ການ duplicating cache ແມ່ນມີຄວາມຈໍາເປັນເນື່ອງຈາກວ່າມັນອາດຈະປະກອບດ້ວຍຂໍ້ມູນທີ່ຍັງບໍ່ໄດ້ຂຽນໃສ່ຮາດດິດ. ແລະໃນກໍລະນີນີ້, ຄວາມລົ້ມເຫຼວຂອງ SSD ຈາກ cache pool ຈະນໍາໄປສູ່ການສູນເສຍຂໍ້ມູນ. ໃນກໍລະນີຂອງ NRAID 1+, ຄວາມລົ້ມເຫຼວຂອງ SSD ພຽງແຕ່ຈະເຮັດໃຫ້ແຄດຖືກໂອນໄປສູ່ສະຖານະທີ່ອ່ານເທົ່ານັ້ນ, ໂດຍຂໍ້ມູນທີ່ບໍ່ໄດ້ຂຽນຈະຖືກຖິ້ມໃສ່ຮາດດິດ. ຫຼັງ​ຈາກ​ການ​ທົດ​ແທນ SSD ຜິດ​ປົກ​ກະ​ຕິ​, ຖານ​ຄວາມ​ຈໍາ​ຈະ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ຮູບ​ແບບ​ການ​ປະ​ຕິ​ບັດ​ຕົ້ນ​ສະ​ບັບ​ຂອງ​ຕົນ​. ໂດຍວິທີທາງການ, ສໍາລັບຄວາມປອດໄພຫຼາຍກວ່າເກົ່າ, ທ່ານສາມາດມອບອຸປະກອນຮ້ອນທີ່ອຸທິດຕົນໃຫ້ກັບ cache ອ່ານ + ຂຽນ.

ເມື່ອໃຊ້ຟັງຊັນ SSD caching ໃນ XCubeSAN, ມີຄວາມຕ້ອງການຈໍານວນຫນຶ່ງສໍາລັບຈໍານວນຫນ່ວຍຄວາມຈໍາຂອງຕົວຄວບຄຸມການເກັບຮັກສາ: ຄວາມຈໍາຂອງລະບົບຫຼາຍ, ຂະຫນາດໃຫຍ່ຂອງ cache pool ຈະມີຢູ່.

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

• ຂະໜາດບລັອກ (Cache Block Size) – 1/2/4 MB
• ຈໍາ​ນວນ​ຂອງ​ການ​ຮ້ອງ​ຂໍ​ໃຫ້​ອ່ານ block ໃດ​ຫນຶ່ງ​ເພື່ອ​ໃຫ້​ມັນ​ໄດ້​ຖືກ​ຄັດ​ລອກ​ໄປ​ທີ່​ຖານ​ຄວາມ​ຈໍາ (Populate-on-Read Threshold) – 1..4
• ຈໍາ​ນວນ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ຈະ​ຂຽນ block ໄດ້​ເພື່ອ​ໃຫ້​ມັນ​ຖືກ​ຄັດ​ລອກ​ໄປ​ທີ່​ຖານ​ຄວາມ​ຈໍາ (Populate-on-Write Threshold) – 0..4

ໂປຣໄຟລ໌ສາມາດປ່ຽນແປງໄດ້ທັນທີ, ແຕ່ແນ່ນອນ, ດ້ວຍເນື້ອໃນຂອງການຕັ້ງແຄດຄືນໃໝ່ ແລະ “ການອຸ່ນຂຶ້ນ” ໃໝ່ຂອງມັນ.

ພິຈາລະນາຫຼັກການຂອງການດໍາເນີນງານຂອງ SSD cache, ພວກເຮົາສາມາດຊີ້ໃຫ້ເຫັນການດໍາເນີນງານຕົ້ນຕໍໃນເວລາທີ່ເຮັດວຽກກັບມັນ:

• ການອ່ານຂໍ້ມູນໃນເວລາທີ່ມັນບໍ່ຢູ່ໃນ cache;
• ອ່ານຂໍ້ມູນໃນເວລາທີ່ມັນມີຢູ່ໃນ cache;
• ການຂຽນຂໍ້ມູນໃນເວລາທີ່ໃຊ້ cache ອ່ານ;
• ການຂຽນຂໍ້ມູນໃນເວລາທີ່ໃຊ້ cache ອ່ານ + ຂຽນ.

ການອ່ານຂໍ້ມູນໃນເວລາທີ່ມັນບໍ່ຢູ່ໃນ cache

1. ຄໍາຮ້ອງຂໍຈາກເຈົ້າພາບມາຮອດຜູ້ຄວບຄຸມ;
2. ເນື່ອງຈາກສິ່ງທີ່ຮ້ອງຂໍບໍ່ໄດ້ຢູ່ໃນແຄດ SSD, ພວກມັນຈະຖືກອ່ານຈາກຮາດດິດ;
3. ຂໍ້ມູນການອ່ານແມ່ນຖືກສົ່ງໄປຫາເຈົ້າພາບ. ໃນເວລາດຽວກັນ, ການກວດສອບແມ່ນເຮັດເພື່ອເບິ່ງວ່າຕັນເຫຼົ່ານີ້ແມ່ນ "ຮ້ອນ";
4. ຖ້າແມ່ນ, ຫຼັງຈາກນັ້ນພວກມັນຈະຖືກຄັດລອກໃສ່ SSD cache ສໍາລັບການນໍາໃຊ້ຕໍ່ໄປ.

ອ່ານຂໍ້ມູນເມື່ອມັນມີຢູ່ໃນແຄດ

1. ຄໍາຮ້ອງຂໍຈາກເຈົ້າພາບມາຮອດຜູ້ຄວບຄຸມ;
2. ເນື່ອງຈາກຂໍ້ມູນທີ່ຮ້ອງຂໍແມ່ນຢູ່ໃນ SSD cache, ມັນຖືກອ່ານຈາກບ່ອນນັ້ນ;
3. ຂໍ້ມູນການອ່ານແມ່ນຖືກສົ່ງໄປຫາເຈົ້າພາບ.

ການຂຽນຂໍ້ມູນໃນເວລາທີ່ໃຊ້ cache ອ່ານ

1. ຄໍາຮ້ອງຂໍການຂຽນຈາກເຈົ້າພາບມາຮອດຕົວຄວບຄຸມ;
2. ຂໍ້ມູນຖືກຂຽນໃສ່ຮາດດິດ;
3. ຄໍາຕອບທີ່ຊີ້ບອກເຖິງການບັນທຶກທີ່ປະສົບຜົນສໍາເລັດຈະຖືກສົ່ງກັບເຈົ້າພາບ;
4. ໃນຂະນະດຽວກັນ, ມັນຖືກກວດເບິ່ງວ່າບລັອກແມ່ນ "ຮ້ອນ" ຫຼືບໍ່ (ຕົວກໍານົດຂອບເຂດ Populate-on-Write ຖືກປຽບທຽບ). ຖ້າແມ່ນ, ຫຼັງຈາກນັ້ນມັນຖືກຄັດລອກໃສ່ SSD cache ສໍາລັບການນໍາໃຊ້ຕໍ່ມາ

ການຂຽນຂໍ້ມູນໃນເວລາໃຊ້ read+write cache

1. ຄໍາຮ້ອງຂໍການຂຽນຈາກເຈົ້າພາບມາຮອດຕົວຄວບຄຸມ;
2. ຂໍ້ມູນຖືກຂຽນໄວ້ໃນ SSD cache;
3. ຄໍາຕອບທີ່ຊີ້ບອກເຖິງການບັນທຶກທີ່ປະສົບຜົນສໍາເລັດຈະຖືກສົ່ງກັບເຈົ້າພາບ;
4. ຂໍ້ມູນຈາກ SSD cache ແມ່ນຂຽນໃສ່ຮາດໄດໃນພື້ນຫລັງ;

ກວດສອບການດໍາເນີນການ

ຢືນທົດສອບ

2 ເຊີບເວີ (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) ຖືກເຊື່ອມຕໍ່ໂດຍສອງພອດຜ່ານ Fiber Channel 16G ໂດຍກົງກັບລະບົບການເກັບຮັກສາ XCubeSAN XS5224D (16GB RAM/controller).

ພວກເຮົາໄດ້ໃຊ້ 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, ລວມກັນໃນ RAID5 (15+1), ສໍາລັບ array ຂໍ້ມູນ ແລະ 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, AS100GB.

2 ປະລິມານຖືກສ້າງຂຶ້ນ: ຫນຶ່ງສໍາລັບແຕ່ລະເຄື່ອງແມ່ຂ່າຍ.

ການທົດສອບ 1. ແຄດ SSD ແບບອ່ານຢ່າງດຽວຈາກ 1-8 SSDs

SSD Cache

• ປະເພດ I/O: ການປັບແຕ່ງ
• Cache Block Size: 4MB
• Populate-on-read Threshold: 1
• Populate-on-write Threshold: 0

ຮູບແບບ I/O

• ເຄື່ອງມື: IOmeter V1.1.0
• ຄົນງານ: 1
• ພົ້ນເດັ່ນ (Queue Depth): 128
• ຂໍ້ມູນຈໍາເພາະການເຂົ້າເຖິງ: 4KB, 100% ອ່ານ, 100% Random

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

ການທົດສອບ 2. SSD cache ໃນໂຫມດອ່ານ + ຂຽນດ້ວຍ 2-8 SSDs

SSD Cache

• ປະເພດ I/O: ການປັບແຕ່ງ
• Cache Block Size: 4MB
• Populate-on-read Threshold: 1
• Populate-on-write Threshold: 1

ຮູບແບບ I/O

• ເຄື່ອງມື: IOmeter V1.1.0
• ຄົນງານ: 1
• ພົ້ນເດັ່ນ (Queue Depth): 128
• ຂໍ້ມູນຈໍາເພາະການເຂົ້າເຖິງ: 4KB, 100% ຂຽນ, 100% Random

ຜົນໄດ້ຮັບດຽວກັນ: ການຂະຫຍາຍຕົວຂອງການປະຕິບັດການລະເບີດແລະການຂະຫຍາຍຂະຫນາດຍ້ອນວ່າຈໍານວນຂອງ SSDs ເພີ່ມຂຶ້ນ.

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

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

ການທົດສອບ 3. emulation ຖານຂໍ້ມູນ

SSD Cache

• ປະເພດ I/O: ຖານຂໍ້ມູນ
• Cache Block Size: 1MB
• Populate-on-read Threshold: 2
• Populate-on-write Threshold: 1

ຮູບແບບ I/O

• ເຄື່ອງມື: IOmeter V1.1.0
• ຄົນງານ: 1
• ພົ້ນເດັ່ນ (Queue Depth): 128
• ຂໍ້ມູນຈໍາເພາະການເຂົ້າເຖິງ: 8KB, 67% ອ່ານ, 100% Random

ການຕັດສິນ

ການສະຫລຸບທີ່ຊັດເຈນ, ແນ່ນອນ, ແມ່ນປະສິດທິພາບທີ່ດີຂອງການນໍາໃຊ້ cache SSD ເພື່ອປັບປຸງການປະຕິບັດຂອງລະບົບການເກັບຮັກສາໃດໆ. ນຳໃຊ້ກັບ QSAN XCubeSAN ຄໍາຖະແຫຼງນີ້ໃຊ້ໄດ້ຢ່າງເຕັມສ່ວນ: ຟັງຊັນ SSD caching ໄດ້ຖືກປະຕິບັດຢ່າງສົມບູນ. ນີ້ກ່ຽວຂ້ອງກັບການສະຫນັບສະຫນູນຮູບແບບການອ່ານແລະອ່ານ + ຂຽນ, ການຕັ້ງຄ່າທີ່ຍືດຫຍຸ່ນສໍາລັບສະຖານະການການນໍາໃຊ້ໃດກໍ່ຕາມ, ເຊັ່ນດຽວກັນກັບການປະຕິບັດຂອງລະບົບໂດຍລວມ. ດັ່ງນັ້ນ, ສໍາລັບຄ່າໃຊ້ຈ່າຍທີ່ສົມເຫດສົມຜົນຫຼາຍ (ລາຄາໃບອະນຸຍາດແມ່ນທຽບກັບຄ່າໃຊ້ຈ່າຍຂອງ 1-2 SSDs), ທ່ານສາມາດເພີ່ມປະສິດທິພາບໂດຍລວມຢ່າງຫຼວງຫຼາຍ.

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