RAM ຟຣີຫຼາຍ, NVMe Intel P4500 ແລະທຸກສິ່ງທຸກຢ່າງແມ່ນຊ້າທີ່ສຸດ - ເລື່ອງຂອງການເພີ່ມການແບ່ງປັນທີ່ບໍ່ປະສົບຜົນສໍາເລັດ

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

Preamble

ພວກເຮົາປະຕິບັດການຟັງຂະຫນາດກາງ, ເຊິ່ງພວກເຮົາສ້າງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍມາດຕະຖານທີ່ມີການຕັ້ງຄ່າຕໍ່ໄປນີ້ - 32 cores, 256 GB RAM ແລະ 4500TB PCI-E Intel P4 NVMe drive. ພວກເຮົາມັກການຕັ້ງຄ່ານີ້ເພາະວ່າມັນກໍາຈັດຄວາມຕ້ອງການທີ່ຈະກັງວົນກ່ຽວກັບ IO overhead ໂດຍການສະຫນອງຂໍ້ຈໍາກັດທີ່ຖືກຕ້ອງໃນລະດັບປະເພດຕົວຢ່າງ VM. ເນື່ອງຈາກວ່າ NVMe Intel P4500 ມີປະສິດທິພາບທີ່ຫນ້າປະທັບໃຈ, ພວກເຮົາສາມາດສະຫນອງການສະຫນອງ IOPS ເຕັມຮູບແບບໃຫ້ກັບເຄື່ອງຈັກແລະການເກັບຮັກສາສໍາຮອງຂໍ້ມູນກັບເຄື່ອງແມ່ຂ່າຍສໍາຮອງທີ່ມີສູນ IOWAIT.

ພວກເຮົາແມ່ນຫນຶ່ງໃນຜູ້ທີ່ເຊື່ອເກົ່າຜູ້ທີ່ບໍ່ໄດ້ໃຊ້ hyperconverged SDN ແລະສິ່ງທີ່ທັນສະໄຫມ, ຄົນອັບເດດ:, ໄວຫນຸ່ມທີ່ຈະເກັບຮັກສາປະລິມານ VM, ເຊື່ອວ່າລະບົບທີ່ງ່າຍດາຍ, ມັນງ່າຍຕໍ່ການແກ້ໄຂບັນຫາໃນເງື່ອນໄຂຂອງ "guru ຕົ້ນຕໍໄດ້ຫມົດໄປ. ສູ່ພູເຂົາ.” ດັ່ງນັ້ນ, ພວກເຮົາເກັບຮັກສາປະລິມານ VM ໃນຮູບແບບ QCOW2 ໃນ XFS ຫຼື EXT4, ເຊິ່ງຖືກນຳໃຊ້ຢູ່ເທິງສຸດຂອງ LVM2.

ພວກເຮົາຍັງຖືກບັງຄັບໃຫ້ໃຊ້ QCOW2 ໂດຍຜະລິດຕະພັນທີ່ພວກເຮົາໃຊ້ສໍາລັບ orchestration - Apache CloudStack .

ເພື່ອປະຕິບັດການສໍາຮອງຂໍ້ມູນ, ພວກເຮົາເອົາຮູບພາບເຕັມຂອງປະລິມານເປັນພາບຖ່າຍ LVM2 (ແມ່ນແລ້ວ, ພວກເຮົາຮູ້ວ່າພາບຖ່າຍ LVM2 ແມ່ນຊ້າ, ແຕ່ Intel P4500 ຊ່ວຍພວກເຮົາຢູ່ທີ່ນີ້ຄືກັນ). ເຮົາ​ເຮັດ lvmcreate -s .. ແລະດ້ວຍການຊ່ວຍເຫຼືອ dd ພວກເຮົາສົ່ງສໍາເນົາສໍາຮອງໄປຫາເຄື່ອງແມ່ຂ່າຍຫ່າງໄກສອກຫຼີກທີ່ມີການເກັບຮັກສາ ZFS. ໃນທີ່ນີ້ພວກເຮົາຍັງມີຄວາມຄືບຫນ້າເລັກນ້ອຍ - ຫຼັງຈາກທີ່ທັງຫມົດ, ZFS ສາມາດເກັບຂໍ້ມູນໃນຮູບແບບທີ່ຖືກບີບອັດ, ແລະພວກເຮົາສາມາດຟື້ນຟູມັນໄດ້ຢ່າງໄວວາໂດຍໃຊ້ DD ຫຼືໄດ້ຮັບປະລິມານ VM ສ່ວນບຸກຄົນໂດຍໃຊ້ mount -o loop ....

ທ່ານ​ສາ​ມາດ​, ແນ່​ນອນ​ວ່າ​, ບໍ່​ແມ່ນ​ຮູບ​ພາບ​ເຕັມ​ທີ່​ຂອງ LVM2 ໄດ້​, ແຕ່​ການ​ຕິດ​ຕັ້ງ​ລະ​ບົບ​ໄຟລ​໌​ໃນ​ RO ແລະຄັດລອກຮູບພາບ QCOW2 ດ້ວຍຕົນເອງ, ຢ່າງໃດກໍຕາມ, ພວກເຮົາປະເຊີນກັບຄວາມຈິງທີ່ວ່າ XFS ກາຍເປັນບໍ່ດີຈາກນີ້, ແລະບໍ່ແມ່ນທັນທີ, ແຕ່ໃນທາງທີ່ບໍ່ສາມາດຄາດເດົາໄດ້. ພວກເຮົາກໍ່ບໍ່ມັກມັນໃນເວລາທີ່ hypervisor ເປັນເຈົ້າພາບ "ຕິດ" ຢ່າງກະທັນຫັນໃນທ້າຍອາທິດ, ໃນຕອນກາງຄືນຫຼືໃນວັນພັກເນື່ອງຈາກຄວາມຜິດພາດທີ່ບໍ່ຊັດເຈນວ່າມັນຈະເກີດຂຶ້ນເມື່ອໃດ. ດັ່ງນັ້ນ, ສໍາລັບ XFS ພວກເຮົາບໍ່ໄດ້ໃຊ້ snapshot mounting ໃນ RO ເພື່ອສະກັດປະລິມານ, ພວກເຮົາພຽງແຕ່ຄັດລອກປະລິມານ LVM2 ທັງຫມົດ.

ຄວາມໄວຂອງການສໍາຮອງຂໍ້ມູນກັບເຄື່ອງແມ່ຂ່າຍຂອງສໍາຮອງຂໍ້ມູນແມ່ນຖືກກໍານົດໃນກໍລະນີຂອງພວກເຮົາໂດຍການປະຕິບັດຂອງເຄື່ອງແມ່ຂ່າຍສໍາຮອງ, ເຊິ່ງແມ່ນປະມານ 600-800 MB / s ສໍາລັບຂໍ້ມູນ incompressible; ຂີດຈໍາກັດຕື່ມອີກແມ່ນຊ່ອງ 10Gbit / s ທີ່ເຄື່ອງແມ່ຂ່າຍສໍາຮອງຂໍ້ມູນໄດ້ຖືກເຊື່ອມຕໍ່. ໄປຫາກຸ່ມ.

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

ຂະບວນການຄັດລອກຂ້າງເທິງແມ່ນມີຄວາມສໍາຄັນຫຼາຍສໍາລັບເລື່ອງຕໍ່ໄປ, ລວມທັງລາຍລະອຽດ - ການນໍາໃຊ້ໄດ Intel P4500 ໄວ, ການນໍາໃຊ້ NFS ແລະ, ອາດຈະ, ການນໍາໃຊ້ ZFS.

ເລື່ອງສຳຮອງ

ໃນແຕ່ລະ hypervisor node ພວກເຮົາມີການແບ່ງປັນ SWAP ຂະຫນາດນ້ອຍຂອງຂະຫນາດ 8 GB, ແລະພວກເຮົາ "roll out" the hypervisor node ຕົວຂອງມັນເອງໂດຍໃຊ້. DD ຈາກຮູບພາບອ້າງອີງ. ສໍາລັບປະລິມານລະບົບໃນເຊີບເວີ, ພວກເຮົາໃຊ້ 2xSATA SSD RAID1 ຫຼື 2xSAS HDD RAID1 ໃນຕົວຄວບຄຸມຮາດແວ LSI ຫຼື HP. ໂດຍທົ່ວໄປ, ພວກເຮົາບໍ່ສົນໃຈສິ່ງທີ່ຢູ່ໃນທັງຫມົດ, ເນື່ອງຈາກວ່າປະລິມານລະບົບຂອງພວກເຮົາດໍາເນີນການຢູ່ໃນໂຫມດ "ເກືອບອ່ານເທົ່ານັ້ນ", ຍົກເວັ້ນ SWAP. ແລະເນື່ອງຈາກພວກເຮົາມີ RAM ຫຼາຍຢູ່ໃນເຄື່ອງແມ່ຂ່າຍແລະມັນບໍ່ເສຍຄ່າ 30-40%, ພວກເຮົາບໍ່ຄິດກ່ຽວກັບ SWAP.

ຂະບວນການສໍາຮອງຂໍ້ມູນ. ວຽກ​ງານ​ນີ້​ເບິ່ງ​ຄື​ແນວ​ນີ້​:

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

ຕັ້ງ​ໃຈ ionice -c3, ໃນຄວາມເປັນຈິງ, ສິ່ງນີ້ແມ່ນບໍ່ມີປະໂຫຍດຢ່າງສົມບູນສໍາລັບອຸປະກອນ NVMe, ນັບຕັ້ງແຕ່ຕົວກໍານົດເວລາ IO ສໍາລັບພວກມັນຖືກກໍານົດເປັນ:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

ຢ່າງໃດກໍຕາມ, ພວກເຮົາມີຈໍານວນຂອງຂໍ້ມໍລະດົກທີ່ມີ SSD RAIDs ທໍາມະດາ, ສໍາລັບພວກເຂົານີ້ມີຄວາມກ່ຽວຂ້ອງ, ດັ່ງນັ້ນເຂົາເຈົ້າກໍາລັງເຄື່ອນຍ້າຍ. AS IS. ໂດຍລວມແລ້ວ, ນີ້ແມ່ນພຽງແຕ່ລະຫັດທີ່ຫນ້າສົນໃຈທີ່ອະທິບາຍເຖິງຄວາມໄຮ້ປະໂຫຍດ ionice ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ການ​ຕັ້ງ​ຄ່າ​ດັ່ງ​ກ່າວ​.

ເອົາໃຈໃສ່ກັບທຸງຊາດ iflag=direct ການ DD. ພວກເຮົາໃຊ້ IO ໂດຍກົງຂ້າມຜ່ານ cache buffer ເພື່ອຫຼີກເວັ້ນການທົດແທນ IO buffers ທີ່ບໍ່ຈໍາເປັນໃນເວລາອ່ານ. ແນວໃດກໍ່ຕາມ, oflag=direct ພວກເຮົາບໍ່ໄດ້ຍ້ອນວ່າພວກເຮົາໄດ້ພົບກັບບັນຫາການປະຕິບັດ ZFS ໃນເວລາທີ່ໃຊ້ມັນ.

ພວກເຮົາໄດ້ນໍາໃຊ້ໂຄງການນີ້ຢ່າງສໍາເລັດຜົນເປັນເວລາຫລາຍປີໂດຍບໍ່ມີບັນຫາ.

ແລະຫຼັງຈາກນັ້ນມັນໄດ້ເລີ່ມຕົ້ນ... ພວກ​ເຮົາ​ໄດ້​ຄົ້ນ​ພົບ​ວ່າ​ຫນຶ່ງ​ໃນ nodes ບໍ່​ມີ​ຕໍ່​ໄປ​ອີກ​ແລ້ວ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​, ແລະ​ທີ່​ຜ່ານ​ມາ​ແມ່ນ​ແລ່ນ​ກັບ IOWAIT monstrous ຂອງ 50%. ເມື່ອພະຍາຍາມເຂົ້າໃຈວ່າເປັນຫຍັງການຄັດລອກບໍ່ເກີດຂຶ້ນ, ພວກເຮົາພົບປະກົດການດັ່ງຕໍ່ໄປນີ້:

Volume group "images" not found

ພວກເຮົາເລີ່ມຄິດກ່ຽວກັບ "ຈຸດຈົບໄດ້ມາຮອດ Intel P4500," ແນວໃດກໍ່ຕາມ, ກ່ອນທີ່ຈະປິດເຄື່ອງແມ່ຂ່າຍເພື່ອທົດແທນການຂັບ, ມັນຍັງມີຄວາມຈໍາເປັນທີ່ຈະເຮັດການສໍາຮອງຂໍ້ມູນ. ພວກເຮົາແກ້ໄຂ LVM2 ໂດຍການຟື້ນຟູ metadata ຈາກການສໍາຮອງຂໍ້ມູນ LVM2:

vgcfgrestore images

ພວກເຮົາໄດ້ເປີດຕົວການສໍາຮອງແລະໄດ້ເຫັນຮູບແຕ້ມນ້ໍາມັນນີ້:

ອີກເທື່ອຫນຶ່ງພວກເຮົາໂສກເສົ້າຫຼາຍ - ມັນເປັນທີ່ຊັດເຈນວ່າພວກເຮົາບໍ່ສາມາດດໍາລົງຊີວິດແບບນີ້, ເພາະວ່າ VPSs ທັງຫມົດຈະທົນທຸກ, ຊຶ່ງຫມາຍຄວາມວ່າພວກເຮົາຈະທົນທຸກຄືກັນ. ສິ່ງ​ທີ່​ເກີດ​ຂຶ້ນ​ແມ່ນ​ບໍ່​ຈະ​ແຈ້ງ​ທັງ​ຫມົດ - iostat ສະແດງໃຫ້ເຫັນ IOPS ທີ່ຫນ້າສົງສານແລະ IOWAIT ສູງສຸດ. ບໍ່ມີແນວຄວາມຄິດໃດນອກເໜືອໄປຈາກ “ໃຫ້ມາແທນທີ່ NVMe,” ແຕ່ຄວາມເຂົ້າໃຈໄດ້ເກີດຂຶ້ນໃນເວລານັ້ນ.

ການວິເຄາະສະຖານະການໂດຍຂັ້ນຕອນ

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

ຄຸນນະສົມບັດການຕັ້ງຄ່າ. ສໍາລັບເຄື່ອງແມ່ຂ່າຍຟັງທັງຫມົດ, ພາລາມິເຕີ vm.swappiness ຖືກຕັ້ງເປັນຄ່າເລີ່ມຕົ້ນ 60. ແລະ SWAP ຖືກສ້າງຂື້ນໃນ SAS HDD RAID1.

ເກີດ​ຫຍັງ​ຂຶ້ນ (ຕາມ​ບັນ​ນາ​ທິ​ການ​). ໃນເວລາທີ່ສໍາຮອງຂໍ້ມູນ DD ຜະລິດຂໍ້ມູນການຂຽນຫຼາຍ, ເຊິ່ງຖືກຈັດໃສ່ໃນ RAM buffers ກ່ອນທີ່ຈະຂຽນໃສ່ NFS. ຫຼັກລະບົບ, ນໍາພາໂດຍນະໂຍບາຍ swappiness, ກໍາລັງເຄື່ອນຍ້າຍຫຼາຍໆຫນ້າຂອງຫນ່ວຍຄວາມຈໍາ VPS ໄປຫາພື້ນທີ່ swap, ເຊິ່ງຕັ້ງຢູ່ໃນປະລິມານ HDD RAID1 ຊ້າ. ນີ້ເຮັດໃຫ້ IOWAIT ເຕີບໂຕຢ່າງແຂງແຮງ, ແຕ່ບໍ່ແມ່ນຍ້ອນ IO NVMe, ແຕ່ເນື່ອງຈາກ IO HDD RAID1.

ບັນຫາໄດ້ຖືກແກ້ໄຂແນວໃດ. ການແບ່ງສ່ວນແລກປ່ຽນ 32GB ຖືກປິດໃຊ້ງານ. ນີ້ໃຊ້ເວລາ 16 ຊົ່ວໂມງ; ທ່ານສາມາດອ່ານແຍກຕ່າງຫາກກ່ຽວກັບວິທີການແລະເປັນຫຍັງ SWAP ປິດຊ້າຫຼາຍ. ການຕັ້ງຄ່າໄດ້ຖືກປ່ຽນແປງ swappiness ກັບຄ່າເທົ່າກັບ 5 ໃນທົ່ວຟັງ.

ນີ້ຈະບໍ່ເກີດຂຶ້ນໄດ້ແນວໃດ?. ກ່ອນອື່ນ ໝົດ, ຖ້າ SWAP ຢູ່ໃນອຸປະກອນ SSD RAID ຫຼື NVMe, ແລະອັນທີສອງ, ຖ້າບໍ່ມີອຸປະກອນ NVMe, ແຕ່ອຸປະກອນທີ່ຊ້າກວ່າທີ່ຈະບໍ່ຜະລິດປະລິມານຂໍ້ມູນດັ່ງກ່າວ - ທາດເຫຼັກ, ບັນຫາເກີດຂຶ້ນຍ້ອນວ່າ NVMe ໄວເກີນໄປ.

ຫຼັງຈາກນັ້ນ, ທຸກສິ່ງທຸກຢ່າງກໍ່ເລີ່ມເຮັດວຽກຄືເກົ່າ - ກັບສູນ IOWAIT.

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