RAM ฟรีจำนวนมาก NVMe Intel P4500 และทุกอย่างช้ามาก - เรื่องราวของการเพิ่มพาร์ติชั่นสว็อปที่ไม่สำเร็จ

ในบทความนี้ ฉันจะพูดถึงสถานการณ์ที่เพิ่งเกิดขึ้นกับหนึ่งในเซิร์ฟเวอร์ในระบบคลาวด์ VPS ของเรา ซึ่งทำให้ฉันต้องนิ่งงันเป็นเวลาหลายชั่วโมง ฉันกำหนดค่าและแก้ไขปัญหาเซิร์ฟเวอร์ Linux มาเป็นเวลาประมาณ 15 ปีแล้ว แต่กรณีนี้ไม่สอดคล้องกับแนวทางปฏิบัติของฉันเลย - ฉันตั้งสมมติฐานผิด ๆ หลายประการและหมดหวังเล็กน้อยก่อนที่จะสามารถระบุสาเหตุของปัญหาได้อย่างถูกต้องและแก้ไขได้ .

คำนำ

เราใช้งานระบบคลาวด์ขนาดกลาง ซึ่งเราสร้างบนเซิร์ฟเวอร์มาตรฐานที่มีการกำหนดค่าต่อไปนี้ - 32 คอร์, RAM 256 GB และไดรฟ์ PCI-E Intel P4500 NVMe ขนาด 4TB เราชอบการกำหนดค่านี้มากเนื่องจากไม่จำเป็นต้องกังวลเกี่ยวกับค่าใช้จ่าย IO โดยให้ข้อจำกัดที่ถูกต้องที่ระดับประเภทอินสแตนซ์ VM เพราะ NVMe Intel P4500 มีประสิทธิภาพที่น่าประทับใจ เราสามารถจัดเตรียม IOPS เต็มรูปแบบให้กับเครื่องและพื้นที่เก็บข้อมูลสำรองไปยังเซิร์ฟเวอร์สำรองข้อมูลที่มี IOWAIT เป็นศูนย์ได้พร้อมๆ กัน

เราเป็นหนึ่งในผู้ศรัทธาเก่าที่ไม่ใช้ SDN แบบไฮเปอร์คอนเวิร์จและสิ่งของวัยรุ่นที่มีสไตล์และทันสมัยอื่น ๆ เพื่อจัดเก็บไดรฟ์ข้อมูล VM โดยเชื่อว่ายิ่งระบบเรียบง่ายเท่าไรก็ยิ่งง่ายกว่าในการแก้ไขปัญหาในเงื่อนไขของ "กูรูหลักได้หายไปแล้ว สู่ภูเขา” ด้วยเหตุนี้ เราจึงจัดเก็บวอลุ่ม VM ในรูปแบบ QCOW2 ใน XFS หรือ EXT4 ซึ่งใช้งานบน LVM2

นอกจากนี้เรายังถูกบังคับให้ใช้ QCOW2 โดยผลิตภัณฑ์ที่เราใช้สำหรับการจัดระเบียบ - Apache CloudStack

ในการสำรองข้อมูล เราจะถ่ายภาพโวลุ่มแบบเต็มเป็นสแน็ปช็อต LVM2 (ใช่ เรารู้ว่าสแน็ปช็อต LVM2 ทำงานช้า แต่ Intel P4500 ก็ช่วยเราได้เช่นกัน) พวกเราทำ lvmcreate -s .. และด้วยความช่วยเหลือ dd เราส่งสำเนาสำรองไปยังเซิร์ฟเวอร์ระยะไกลที่มีพื้นที่เก็บข้อมูล ZFS ในส่วนนี้เรายังคงมีความก้าวหน้าเล็กน้อย เนื่องจาก ZFS สามารถจัดเก็บข้อมูลในรูปแบบบีบอัด และเราสามารถกู้คืนข้อมูลได้อย่างรวดเร็วโดยใช้ DD หรือรับวอลุ่ม VM แต่ละรายการโดยใช้ mount -o loop ....

แน่นอนว่าคุณสามารถลบอิมเมจเต็มของวอลุ่ม LVM2 ไม่ได้ แต่สามารถเมาท์ระบบไฟล์ในไฟล์ RO และคัดลอกอิมเมจ QCOW2 ด้วยตัวเอง อย่างไรก็ตาม เราต้องเผชิญกับความจริงที่ว่า XFS แย่ลงจากสิ่งนี้ และไม่ใช่ในทันที แต่ในลักษณะที่คาดเดาไม่ได้ เราไม่ชอบเลยจริงๆ เมื่อไฮเปอร์ไวเซอร์โฮสต์ "ค้าง" อย่างกะทันหันในช่วงสุดสัปดาห์ กลางคืน หรือในวันหยุด เนื่องจากข้อผิดพลาดที่ไม่ชัดเจนว่าจะเกิดขึ้นเมื่อใด ดังนั้นสำหรับ XFS เราจึงไม่ใช้การติดตั้งสแน็ปช็อต RO เพื่อแยกโวลุ่ม เราเพียงแค่คัดลอกโวลุ่ม LVM2 ทั้งหมด

ในกรณีของเราความเร็วของการสำรองข้อมูลไปยังเซิร์ฟเวอร์สำรองนั้นพิจารณาจากประสิทธิภาพของเซิร์ฟเวอร์สำรองซึ่งอยู่ที่ประมาณ 600-800 MB/s สำหรับข้อมูลที่ไม่สามารถบีบอัดได้ ตัวจำกัดเพิ่มเติมคือช่องสัญญาณ 10Gbit/s ที่เซิร์ฟเวอร์สำรองเชื่อมต่ออยู่ ไปยังคลัสเตอร์

ในกรณีนี้ สำเนาสำรองของเซิร์ฟเวอร์ไฮเปอร์ไวเซอร์ 8 เครื่องจะถูกอัปโหลดไปยังเซิร์ฟเวอร์สำรองเดียวพร้อมกัน ดังนั้น ดิสก์และระบบย่อยเครือข่ายของเซิร์ฟเวอร์สำรองข้อมูลซึ่งช้าลง จะไม่อนุญาตให้ระบบย่อยของดิสก์ของโฮสต์ไฮเปอร์ไวเซอร์โอเวอร์โหลด เนื่องจากระบบย่อยเหล่านี้ไม่สามารถประมวลผลได้ เช่น 8 GB/วินาที ซึ่งโฮสต์ไฮเปอร์ไวเซอร์สามารถทำได้ได้อย่างง่ายดาย ผลิต.

กระบวนการคัดลอกข้างต้นมีความสำคัญมากสำหรับเรื่องราวเพิ่มเติม รวมถึงรายละเอียด - การใช้ไดรฟ์ Intel P4500 ที่รวดเร็ว การใช้ NFS และอาจใช้ ZFS

เรื่องสำรอง

ในแต่ละโหนดไฮเปอร์ไวเซอร์ เรามีพาร์ติชั่น SWAP ขนาดเล็กขนาด 8 GB และเรา “เปิดตัว” โหนดไฮเปอร์ไวเซอร์นั้นเองโดยใช้ 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 RAID แบบเดิม ซึ่งสิ่งนี้มีความเกี่ยวข้อง ดังนั้นจึงมีการย้ายโหนด อย่างที่เป็น. โดยรวมแล้ว นี่เป็นเพียงโค้ดที่น่าสนใจที่อธิบายความไร้ประโยชน์นี้ ionice ในกรณีที่มีการกำหนดค่าดังกล่าว

ให้ความสนใจกับธง iflag=direct สำหรับ DD. เราใช้ IO โดยตรงเพื่อหลีกเลี่ยงแคชบัฟเฟอร์เพื่อหลีกเลี่ยงการเปลี่ยนบัฟเฟอร์ IO โดยไม่จำเป็นเมื่ออ่าน อย่างไรก็ตาม, oflag=direct เราไม่ทำเช่นนั้นเนื่องจากเราประสบปัญหาด้านประสิทธิภาพของ ZFS เมื่อใช้งาน

เราใช้โครงการนี้สำเร็จมาหลายปีโดยไม่มีปัญหา

แล้วมันก็เริ่มขึ้น... เราค้นพบว่าหนึ่งในโหนดไม่ได้รับการสำรองข้อมูลอีกต่อไป และโหนดก่อนหน้านั้นทำงานด้วย IOWAIT ที่น่ากลัวถึง 50% เมื่อพยายามทำความเข้าใจว่าเหตุใดการคัดลอกจึงไม่เกิดขึ้น เราพบปรากฏการณ์ต่อไปนี้:

Volume group "images" not found

เราเริ่มคิดว่า "จุดจบมาถึงแล้วสำหรับ Intel P4500" อย่างไรก็ตาม ก่อนที่จะปิดเซิร์ฟเวอร์เพื่อเปลี่ยนไดรฟ์ ก็ยังจำเป็นต้องสำรองข้อมูลก่อน เราแก้ไข LVM2 โดยการกู้คืนข้อมูลเมตาจากการสำรองข้อมูล LVM2:

vgcfgrestore images

เราเปิดตัวการสำรองข้อมูลและเห็นภาพวาดสีน้ำมันนี้:

เราเสียใจมากอีกครั้ง - ชัดเจนว่าเราไม่สามารถใช้ชีวิตแบบนี้ได้ เนื่องจาก VPS ทั้งหมดจะต้องทนทุกข์ ซึ่งหมายความว่าเราก็ต้องทนทุกข์เช่นกัน เกิดอะไรขึ้นไม่ชัดเจนเลย - iostat แสดง IOPS ที่น่าสมเพชและ IOWAIT สูงสุด ไม่มีแนวคิดอื่นใดนอกจาก “มาแทนที่ NVMe กันเถอะ” แต่ข้อมูลเชิงลึกก็เกิดขึ้นทันเวลาพอดี

การวิเคราะห์สถานการณ์ทีละขั้นตอน

นิตยสารประวัติศาสตร์. ไม่กี่วันก่อนหน้านี้ บนเซิร์ฟเวอร์นี้ จำเป็นต้องสร้าง VPS ขนาดใหญ่ที่มี RAM ขนาด 128 GB ดูเหมือนจะมีหน่วยความจำเพียงพอ แต่เพื่อความปลอดภัย เราจึงจัดสรรพื้นที่อีก 32 GB สำหรับพาร์ติชั่นสว็อป VPS ถูกสร้างขึ้น ทำงานให้สำเร็จ และเหตุการณ์ถูกลืม แต่พาร์ติชัน SWAP ยังคงอยู่

คุณสมบัติการกำหนดค่า. สำหรับเซิร์ฟเวอร์คลาวด์ทั้งหมดจะมีพารามิเตอร์ vm.swappiness ถูกตั้งค่าเป็นค่าเริ่มต้น 60. และ SWAP ถูกสร้างขึ้นบน SAS HDD RAID1

เกิดอะไรขึ้น (อ้างอิงจากบรรณาธิการ). เมื่อทำการสำรองข้อมูล DD สร้างข้อมูลการเขียนจำนวนมากซึ่งถูกวางไว้ในบัฟเฟอร์ RAM ก่อนที่จะเขียนไปยัง NFS แกนของระบบตามนโยบาย swappinessกำลังย้ายหน่วยความจำ VPS หลายหน้าไปยังพื้นที่สว็อป ซึ่งอยู่บนโวลุ่ม HDD RAID1 ที่ช้า สิ่งนี้ทำให้ IOWAIT เติบโตอย่างแข็งแกร่งมาก แต่ไม่ใช่เพราะ IO NVMe แต่เนื่องมาจาก IO HDD RAID1

วิธีแก้ปัญหา. พาร์ติชันสลับ 32GB ถูกปิดใช้งาน การดำเนินการนี้ใช้เวลา 16 ชั่วโมง คุณสามารถอ่านแยกกันเกี่ยวกับวิธีการและสาเหตุที่ SWAP ปิดได้ช้ามาก การตั้งค่ามีการเปลี่ยนแปลง swappiness ให้มีค่าเท่ากับ 5 ทั่วเมฆ

สิ่งนี้จะไม่เกิดขึ้นได้อย่างไร?. ประการแรก หาก SWAP อยู่ในอุปกรณ์ SSD RAID หรือ NVMe และประการที่สอง หากไม่มีอุปกรณ์ NVMe แต่เป็นอุปกรณ์ที่ช้ากว่าซึ่งจะไม่สร้างปริมาณข้อมูลดังกล่าว น่าแปลกที่ปัญหาเกิดขึ้นเนื่องจาก NVMe นั้นเร็วเกินไป

หลังจากนั้นทุกอย่างก็เริ่มทำงานเหมือนเดิม - โดยไม่มี IOWAIT

ที่มา: will.com