ຄວາມໄວການເກັບຮັກສາທີ່ເຫມາະສົມກັບ etcd? ຂໍໃຫ້ fio

ເລື່ອງສັ້ນກ່ຽວກັບ fio ແລະ ອື່ນໆ

ການປະຕິບັດກຸ່ມ ແລະອື່ນ ສ່ວນໃຫຍ່ແມ່ນຂຶ້ນກັບການປະຕິບັດການເກັບຮັກສາຂອງມັນ. etcd ສົ່ງອອກບາງ metrics ກັບ Prometheusເພື່ອໃຫ້ຂໍ້ມູນປະສິດທິພາບການເກັບຮັກສາທີ່ຕ້ອງການ. ຕົວຢ່າງ, wal_fsync_duration_seconds metric. ເອກະສານສໍາລັບ etcd ເວົ້າວ່າ: ສໍາລັບການເກັບຮັກສາທີ່ຈະພິຈາລະນາໄວພຽງພໍ, ເປີເຊັນ 99 ຂອງ metric ນີ້ຈະຕ້ອງຫນ້ອຍກວ່າ 10ms. ຖ້າທ່ານກໍາລັງວາງແຜນທີ່ຈະດໍາເນີນການກຸ່ມ etcd ໃນເຄື່ອງ Linux ແລະຕ້ອງການປະເມີນວ່າບ່ອນເກັບຂໍ້ມູນຂອງທ່ານໄວພຽງພໍ (ເຊັ່ນ: SSD), ທ່ານສາມາດນໍາໃຊ້. fio ເປັນເຄື່ອງມືທີ່ນິຍົມໃນການທົດສອບການດໍາເນີນການ I/O. ດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້, ບ່ອນທີ່ test-data ແມ່ນໄດເລກະທໍລີພາຍໃຕ້ຈຸດເຊື່ອມຕໍ່ບ່ອນເກັບຂໍ້ມູນ:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

ທ່ານພຽງແຕ່ຕ້ອງການເບິ່ງຜົນໄດ້ຮັບແລະກວດເບິ່ງວ່າອັດຕາສ່ວນຮ້ອຍລະ 99 ຂອງໄລຍະເວລາ fdatasync ໜ້ອຍກວ່າ 10 ms. ຖ້າເປັນດັ່ງນັ້ນ, ທ່ານມີບ່ອນເກັບຂໍ້ມູນໄວສົມຄວນ. ນີ້ແມ່ນຕົວຢ່າງຂອງຜົນໄດ້ຮັບ:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

ຫມາຍເຫດ

• ພວກເຮົາໄດ້ປັບແຕ່ງຕົວເລືອກ --size ແລະ --bs ສໍາລັບສະຖານະການສະເພາະຂອງພວກເຮົາ. ເພື່ອໃຫ້ໄດ້ຜົນທີ່ເປັນປະໂຫຍດຈາກ fio, ໃຫ້ຄຸນຄ່າຂອງຕົນເອງ. ໄປເອົາພວກມັນຢູ່ໃສ? ອ່ານ ວິທີທີ່ພວກເຮົາໄດ້ຮຽນຮູ້ທີ່ຈະ configure fio.
• ໃນ​ລະ​ຫວ່າງ​ການ​ທົດ​ສອບ​, ການ​ໂຫຼດ I/O ທັງ​ຫມົດ​ແມ່ນ​ມາ​ຈາກ fio​. ໃນສະຖານະການຊີວິດຈິງ, ອາດຈະມີການຮ້ອງຂໍການຂຽນອື່ນເຂົ້າມາໃນບ່ອນເກັບມ້ຽນນອກເຫນືອຈາກສິ່ງທີ່ກ່ຽວຂ້ອງກັບ wal_fsync_duration_seconds. ການໂຫຼດເພີ່ມເຕີມຈະເພີ່ມມູນຄ່າຂອງ wal_fsync_duration_seconds. ດັ່ງນັ້ນຖ້າເປີເຊັນທີ 99 ໃກ້ກັບ 10ms, ພື້ນທີ່ຈັດເກັບຂໍ້ມູນຂອງທ່ານກຳລັງຈະໝົດໄວ.
• ເອົາສະບັບ fio ບໍ່ຕໍ່າກວ່າ 3.5 (ອັນກ່ອນໜ້ານີ້ບໍ່ສະແດງຄ່າເປີເຊັນຂອງໄລຍະເວລາ fdatasync).
• ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ຕົວຢ່າງຂອງຜົນໄດ້ຮັບຈາກ fio.

ເລື່ອງຍາວກ່ຽວກັບ fio ແລະອື່ນໆ

WAL ແມ່ນຫຍັງໃນແລະອື່ນໆ

ປົກກະຕິແລ້ວຖານຂໍ້ມູນໃຊ້ ບັນທຶກການຂຽນລ່ວງໜ້າ; etcd ໃຊ້ມັນຄືກັນ. ພວກເຮົາຈະບໍ່ປຶກສາຫາລືກ່ຽວກັບບັນທຶກການຂຽນລ່ວງໜ້າ (WAL) ໃນລາຍລະອຽດທີ່ນີ້. ມັນພຽງພໍສໍາລັບພວກເຮົາທີ່ຈະຮູ້ວ່າສະມາຊິກແຕ່ລະຄົນຂອງກຸ່ມ etcd ຮັກສາມັນຢູ່ໃນການເກັບຮັກສາຢ່າງຕໍ່ເນື່ອງ. etcd ຂຽນແຕ່ລະການດໍາເນີນການ key-value (ເຊັ່ນ: ການປັບປຸງ) ກັບ WAL ກ່ອນທີ່ຈະນໍາໃຊ້ມັນກັບຮ້ານ. ຖ້າຫນຶ່ງໃນສະມາຊິກບ່ອນເກັບມ້ຽນຂັດຂ້ອງແລະປິດເປີດໃຫມ່ລະຫວ່າງການຖ່າຍພາບ, ມັນສາມາດຟື້ນຟູການເຮັດທຸລະກໍາຢູ່ໃນທ້ອງຖິ່ນນັບຕັ້ງແຕ່ snapshot ສຸດທ້າຍໂດຍເນື້ອຫາ WAL.

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

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

ແຕ່ຫນ້າເສຍດາຍ, ການຂຽນໃສ່ບ່ອນເກັບຂໍ້ມູນຄົງທີ່ບໍ່ໄດ້ເກີດຂຶ້ນທັນທີ. ຖ້າການໂທ fdatasync ຊ້າ, ການປະຕິບັດຂອງລະບົບ etcd ຈະທົນທຸກ. ເອກະສານສໍາລັບ etcd ເວົ້າວ່າວ່າການເກັບຮັກສາແມ່ນຖືວ່າໄວພໍຖ້າ, ໃນເປີເຊັນທີ 99, ການໂທ fdatasync ໃຊ້ເວລາຫນ້ອຍກວ່າ 10ms ເພື່ອຂຽນໃສ່ໄຟລ໌ WAL. ມີ metrics ທີ່ເປັນປະໂຫຍດອື່ນໆສໍາລັບການເກັບຮັກສາ, ແຕ່ໃນຂໍ້ຄວາມນີ້ພວກເຮົາພຽງແຕ່ເວົ້າກ່ຽວກັບ metric ນີ້.

ການ​ຄາດ​ຄະ​ເນ​ການ​ເກັບ​ຮັກ​ສາ​ທີ່​ມີ fio​

ຖ້າທ່ານຕ້ອງການປະເມີນວ່າການເກັບຮັກສາຂອງທ່ານເຫມາະສົມກັບ etcd, ໃຊ້ fio, ເຄື່ອງມືການທົດສອບການໂຫຼດ I/O ທີ່ນິຍົມຫຼາຍ. ມັນຄວນຈະເປັນການລະນຶກເຖິງວ່າການດໍາເນີນງານຂອງແຜ່ນສາມາດແຕກຕ່າງກັນຫຼາຍ: synchronous ແລະ asynchronous, ຫຼາຍໆຫ້ອງຮຽນຂອງການໂທລະບົບ, ແລະອື່ນໆ. ດັ່ງນັ້ນ, fio ແມ່ນຂ້ອນຂ້າງຍາກທີ່ຈະໃຊ້. ມັນມີຕົວກໍານົດການຈໍານວນຫຼາຍ, ແລະການປະສົມທີ່ແຕກຕ່າງກັນຂອງຄຸນຄ່າຂອງພວກມັນເຮັດໃຫ້ເກີດການໂຫຼດ I / O ທີ່ແຕກຕ່າງກັນຫຼາຍ. ເພື່ອໃຫ້ໄດ້ຕົວເລກທີ່ພຽງພໍສໍາລັບ etcd, ທ່ານຄວນໃຫ້ແນ່ໃຈວ່າການທົດສອບການຂຽນຈາກ fio ແມ່ນໃກ້ຊິດເທົ່າທີ່ເປັນໄປໄດ້ກັບການໂຫຼດຕົວຈິງຈາກ etcd ເມື່ອຂຽນໄຟລ໌ WAL.

ດັ່ງນັ້ນ, ຢ່າງຫນ້ອຍ, fio ຄວນສ້າງການໂຫຼດຂອງຊຸດການຂຽນຕາມລໍາດັບໄປຫາໄຟລ໌, ແຕ່ລະການຂຽນຈະປະກອບດ້ວຍການເອີ້ນລະບົບ. ຂຽນຕິດຕາມດ້ວຍການໂທຫາລະບົບ fdatasync. ການຂຽນຕາມລໍາດັບໄປຫາ fio ຕ້ອງການທາງເລືອກ --rw=write. ສໍາລັບ fio ການນໍາໃຊ້ລະບົບການຂຽນໂທຫາໃນເວລາທີ່ຂຽນ, ແທນທີ່ຈະ ຂຽນ, ທ່ານຄວນລະບຸພາລາມິເຕີ --ioengine=sync. ສຸດທ້າຍ, ເພື່ອໂທຫາ fdatasync ຫຼັງຈາກການຂຽນແຕ່ລະຄັ້ງ, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມພາລາມິເຕີ --fdatasync=1. ອີກສອງທາງເລືອກໃນຕົວຢ່າງນີ້ (--size ແລະ -bs) ແມ່ນສະຄຣິບສະເພາະ. ໃນພາກຕໍ່ໄປ, ພວກເຮົາຈະສະແດງໃຫ້ທ່ານເຫັນວິທີການຕັ້ງຄ່າພວກມັນ.

ເປັນຫຍັງ fio ແລະວິທີທີ່ພວກເຮົາຮຽນຮູ້ທີ່ຈະຕັ້ງມັນ

ໃນບົດຂຽນນີ້, ພວກເຮົາອະທິບາຍກໍລະນີທີ່ແທ້ຈິງ. ພວກເຮົາມີກຸ່ມ Kubernetes v1.13 ທີ່ພວກເຮົາຕິດຕາມກັບ Prometheus. etcd v3.2.24 ຖືກໂຮດຢູ່ໃນ SSD. Etcd metrics ສະແດງໃຫ້ເຫັນ fdatasync latencies ສູງເກີນໄປ, ເຖິງແມ່ນວ່າໃນເວລາທີ່ cluster ບໍ່ໄດ້ເຮັດຫຍັງ. ການວັດແທກແມ່ນແປກ ແລະພວກເຮົາກໍ່ບໍ່ຮູ້ວ່າມັນໝາຍເຖິງຫຍັງ. ກຸ່ມປະກອບດ້ວຍເຄື່ອງ virtual, ມັນຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າບັນຫາແມ່ນຫຍັງ: ໃນ SSDs ທາງດ້ານຮ່າງກາຍຫຼືໃນຊັ້ນ virtualization. ນອກຈາກນັ້ນ, ພວກເຮົາມັກຈະມີການປ່ຽນແປງການຕັ້ງຄ່າຮາດແວ ແລະຊອບແວ, ແລະພວກເຮົາຕ້ອງການວິທີການປະເມີນຜົນໄດ້ຮັບຂອງມັນ. ພວກເຮົາສາມາດດໍາເນີນການ etcd ໃນທຸກການຕັ້ງຄ່າແລະເບິ່ງ Prometheus metrics, ແຕ່ນັ້ນແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍ. ພວກເຮົາຊອກຫາວິທີທີ່ງ່າຍດາຍພໍສົມຄວນເພື່ອປະເມີນການຕັ້ງຄ່າສະເພາະ. ພວກເຮົາຕ້ອງການກວດເບິ່ງວ່າພວກເຮົາເຂົ້າໃຈ Prometheus metrics ຈາກ etcd ຢ່າງຖືກຕ້ອງ.

ແຕ່ສໍາລັບການນີ້, ສອງບັນຫາຕ້ອງໄດ້ຮັບການແກ້ໄຂ. ທໍາອິດ, I/O load ທີ່ etcd ສ້າງເມື່ອຂຽນໃສ່ WAL ມີລັກສະນະແນວໃດ? ໃຊ້ລະບົບໃດແດ່? ຂະຫນາດຂອງບັນທຶກແມ່ນຫຍັງ? ອັນທີສອງ, ຖ້າພວກເຮົາຕອບຄໍາຖາມເຫຼົ່ານີ້, ເຮັດແນວໃດພວກເຮົາສ້າງຈໍານວນການເຮັດວຽກທີ່ຄ້າຍຄືກັນກັບ fio? ຢ່າລືມວ່າ fio ເປັນເຄື່ອງມືທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍທີ່ມີທາງເລືອກຫຼາຍ. ພວກເຮົາໄດ້ແກ້ໄຂບັນຫາທັງສອງຢ່າງດ້ວຍວິທີດຽວ - ການນໍາໃຊ້ຄໍາສັ່ງ lsof и ສາຍແຮ່. lsof ລາຍຊື່ຕົວອະທິບາຍໄຟລ໌ທັງຫມົດທີ່ໃຊ້ໂດຍຂະບວນການແລະໄຟລ໌ທີ່ກ່ຽວຂ້ອງຂອງພວກເຂົາ. ແລະມີການຕິດຕາມ, ທ່ານສາມາດກວດເບິ່ງຂະບວນການທີ່ແລ່ນແລ້ວ, ຫຼືເລີ່ມຕົ້ນຂະບວນການແລະກວດເບິ່ງມັນ. strace ພິມການໂທລະບົບທັງຫມົດຈາກຂະບວນການທີ່ຖືກກວດສອບ (ແລະຂະບວນການລູກຂອງມັນ). ອັນສຸດທ້າຍແມ່ນມີຄວາມ ສຳ ຄັນຫຼາຍ, ເພາະວ່າ etcd ແມ່ນພຽງແຕ່ໃຊ້ວິທີການທີ່ຄ້າຍຄືກັນ.

ພວກເຮົາທໍາອິດໃຊ້ strace ເພື່ອຄົ້ນຫາເຄື່ອງແມ່ຂ່າຍ etcd ສໍາລັບ Kubernetes ໃນເວລາທີ່ບໍ່ມີການໂຫຼດຢູ່ໃນ cluster. ພວກເຮົາເຫັນວ່າບັນທຶກ WAL ເກືອບທັງໝົດມີຂະໜາດດຽວກັນ: 2200-2400 bytes. ດັ່ງນັ້ນ, ໃນຄໍາສັ່ງໃນຕອນຕົ້ນຂອງການຕອບ, ພວກເຮົາກໍານົດພາລາມິເຕີ -bs=2300 (bs ຫມາຍຄວາມວ່າຂະຫນາດໃນ bytes ສໍາລັບແຕ່ລະ fio entry). ໃຫ້ສັງເກດວ່າຂະຫນາດຂອງລາຍການ etcd ແມ່ນຂຶ້ນກັບຮຸ່ນ etcd, ການແຈກຢາຍ, ຄ່າພາລາມິເຕີ, ແລະອື່ນໆ, ແລະຜົນກະທົບຕໍ່ໄລຍະເວລາ fdatasync. ຖ້າທ່ານມີສະຖານະການທີ່ຄ້າຍຄືກັນ, ກວດເບິ່ງຂະບວນການ etcd ຂອງທ່ານດ້ວຍ strace ເພື່ອຊອກຫາຕົວເລກທີ່ແນ່ນອນ.

ຫຼັງຈາກນັ້ນ, ເພື່ອໃຫ້ໄດ້ຮັບຄວາມຄິດທີ່ດີກ່ຽວກັບສິ່ງທີ່ລະບົບໄຟລ໌ etcd ກໍາລັງເຮັດ, ພວກເຮົາເລີ່ມຕົ້ນມັນດ້ວຍ strace ແລະທາງເລືອກ -ffttT. ດັ່ງນັ້ນພວກເຮົາໄດ້ພະຍາຍາມກວດເບິ່ງຂະບວນການຂອງເດັກແລະບັນທຶກຜົນຜະລິດຂອງແຕ່ລະຄົນໃນໄຟລ໌ແຍກຕ່າງຫາກ, ແລະຍັງໄດ້ຮັບບົດລາຍງານລາຍລະອຽດກ່ຽວກັບການເລີ່ມຕົ້ນແລະໄລຍະເວລາຂອງການໂທແຕ່ລະລະບົບ. ພວກເຮົາໄດ້ໃຊ້ lsof ເພື່ອຢືນຢັນການວິເຄາະຂອງພວກເຮົາກ່ຽວກັບຜົນຜະລິດ strace ແລະເບິ່ງວ່າຕົວອະທິບາຍໄຟລ໌ໃດຖືກໃຊ້ເພື່ອຈຸດປະສົງໃດ. ດັ່ງນັ້ນດ້ວຍການຊ່ວຍເຫຼືອຂອງ strace, ຜົນໄດ້ຮັບສະແດງໃຫ້ເຫັນຂ້າງເທິງນີ້ໄດ້ຮັບ. ສະຖິຕິເວລາ synchronization ຢືນຢັນວ່າ wal_fsync_duration_seconds ຈາກ etcd ແມ່ນສອດຄ່ອງກັບການໂທ fdatasync ກັບຕົວອະທິບາຍໄຟລ໌ WAL.

ພວກເຮົາໄດ້ຜ່ານເອກະສານສໍາລັບ fio ແລະເລືອກທາງເລືອກສໍາລັບສະຄິບຂອງພວກເຮົາເພື່ອໃຫ້ fio ເຮັດໃຫ້ເກີດການໂຫຼດທີ່ຄ້າຍຄືກັນກັບ etcd. ພວກເຮົາຍັງໄດ້ກວດເບິ່ງການໂທລະບົບແລະໄລຍະເວລາຂອງພວກເຂົາໂດຍການແລ່ນ fio ຈາກ strace, ຄ້າຍຄືກັບ etcd.

ພວກເຮົາໄດ້ເລືອກຢ່າງລະມັດລະວັງຄ່າຂອງຕົວກໍານົດການ --size ເພື່ອສະແດງການໂຫຼດ I/O ທັງໝົດຈາກ fio. ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ແມ່ນຈໍານວນ bytes ທັງຫມົດທີ່ຖືກຂຽນໄວ້ໃນບ່ອນເກັບຂໍ້ມູນ. ມັນໄດ້ຫັນອອກເປັນອັດຕາສ່ວນໂດຍກົງກັບຈໍານວນຂອງການຂຽນ (ແລະ fdatasync) ການໂທລະບົບ. ສໍາລັບຄ່າທີ່ແນ່ນອນຂອງ bs, ຈໍານວນການໂທ fdatasync = ຂະຫນາດ / bs. ເນື່ອງຈາກພວກເຮົາມີຄວາມສົນໃຈໃນອັດຕາສ່ວນຮ້ອຍ, ພວກເຮົາຕ້ອງມີຕົວຢ່າງພຽງພໍເພື່ອໃຫ້ແນ່ໃຈວ່າ, ແລະພວກເຮົາຄິດໄລ່ວ່າ 10^4 ຈະພຽງພໍສໍາລັບພວກເຮົາ (ນັ້ນແມ່ນ 22 mebibytes). ຖ້າ --size ແມ່ນນ້ອຍກວ່າ, outliers ອາດຈະເກີດຂຶ້ນ (ຕົວຢ່າງ, ການໂທ fdatasync ຫຼາຍຄັ້ງໃຊ້ເວລາດົນກວ່າປົກກະຕິແລະສົ່ງຜົນກະທົບຕໍ່ເປີເຊັນທີ 99).

ລອງໃຊ້ເອງ

ພວກເຮົາໄດ້ສະແດງໃຫ້ທ່ານເຫັນວິທີການໃຊ້ fio ແລະເບິ່ງວ່າການເກັບຮັກສາໄວພຽງພໍສໍາລັບ etcd ເພື່ອປະຕິບັດໄດ້ດີ. ຕອນນີ້ທ່ານສາມາດລອງໃຊ້ມັນດ້ວຍຕົວທ່ານເອງໂດຍໃຊ້, ຕົວຢ່າງ, ເຄື່ອງ virtual ທີ່ມີການເກັບຮັກສາ SSD ໃນ IBM Cloud.

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