🥇วิธีตรวจสอบดิสก์ด้วย fio เพื่อประสิทธิภาพที่เพียงพอสำหรับ etcd

บันทึก. แปล: บทความนี้เป็นผลมาจากการวิจัยขนาดเล็กที่ดำเนินการโดยวิศวกรของ IBM Cloud เพื่อค้นหาวิธีแก้ไขปัญหาจริงที่เกี่ยวข้องกับการทำงานของฐานข้อมูล etcd งานที่คล้ายกันนี้เกี่ยวข้องกับเรา อย่างไรก็ตาม การไตร่ตรองและการดำเนินการของผู้เขียนอาจน่าสนใจในบริบทที่กว้างขึ้น

สรุปโดยย่อของบทความทั้งหมด: fio และ etcd

ประสิทธิภาพของคลัสเตอร์ etcd นั้นขึ้นอยู่กับความเร็วของที่เก็บข้อมูลพื้นฐาน etcd ส่งออกเมตริก Prometheus ต่างๆ เพื่อตรวจสอบประสิทธิภาพ หนึ่งในนั้นคือ wal_fsync_duration_seconds. ในเอกสารสำหรับ etcd มันบอกว่าพื้นที่เก็บข้อมูลนั้นถือว่าเร็วเพียงพอหากเปอร์เซ็นไทล์ที่ 99 ของเมตริกนี้ไม่เกิน 10 มิลลิวินาที...

หากคุณกำลังพิจารณาตั้งค่าคลัสเตอร์ etcd บนเครื่อง Linux และต้องการทดสอบว่าไดรฟ์ (เช่น SSD) เร็วพอหรือไม่ เราขอแนะนำให้ใช้เครื่องทดสอบ I/O ยอดนิยมที่เรียกว่า FiO. ก็เพียงพอแล้วที่จะรันคำสั่งต่อไปนี้ (ไดเร็กทอรี test-data ต้องอยู่ในพาร์ติชันที่ติดตั้งของไดรฟ์ทดสอบ):

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

ยังคงเป็นเพียงการดูผลลัพธ์และตรวจสอบว่าเปอร์เซ็นไทล์ที่ 99 เหมาะสมหรือไม่ fdatasync ใน 10 มิลลิวินาที ถ้าเป็นเช่นนั้น แสดงว่าไดรฟ์ของคุณทำงานได้เร็วเพียงพอ นี่คือตัวอย่างผลลัพธ์:

fsync/fdatasync/sync_file_range:
  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ระบุค่าที่เหมาะสมสำหรับกรณีการใช้งานของคุณ วิธีการเลือกพวกเขาจะกล่าวถึงด้านล่าง
ระหว่างการทดสอบเท่านั้น fio โหลดระบบย่อยของดิสก์ ในชีวิตจริง มีแนวโน้มว่ากระบวนการอื่นจะเขียนลงดิสก์ (นอกเหนือจากที่เกี่ยวข้องกับ wal_fsync_duration_seconds). โหลดเพิ่มเติมนี้สามารถเพิ่มขึ้นได้ wal_fsync_duration_seconds. กล่าวอีกนัยหนึ่ง ถ้าเปอร์เซ็นไทล์ที่ 99 จากการทดสอบด้วย fioน้อยกว่า 10 ms เล็กน้อยเท่านั้น มีโอกาสที่ดีที่ประสิทธิภาพการจัดเก็บจะไม่เพียงพอ
สำหรับการทดสอบคุณจะต้องมีเวอร์ชัน fio ไม่ต่ำกว่า 3.5เนื่องจากรุ่นเก่าไม่ได้รวมผลลัพธ์ fdatasync ในรูปของเปอร์เซ็นไทล์
ข้อสรุปข้างต้นเป็นเพียงข้อความที่ตัดตอนมาเล็กน้อยจากข้อสรุปทั่วไป fio.

เพิ่มเติมเกี่ยวกับ fio และ etcd

คำสองสามคำเกี่ยวกับ WAL เป็นต้น

โดยทั่วไปจะใช้ฐานข้อมูล การบันทึกเชิงรุก (การบันทึกแบบเขียนล่วงหน้า, WAL) etcd ก็ได้รับผลกระทบเช่นกัน การสนทนาเกี่ยวกับ WAL อยู่นอกเหนือขอบเขตของบทความนี้ แต่สำหรับจุดประสงค์ของเรา สิ่งที่คุณต้องทราบก็คือสมาชิกคลัสเตอร์ etcd แต่ละรายจัดเก็บ WAL ไว้ในที่จัดเก็บข้อมูลถาวร etcd เขียนการดำเนินการจัดเก็บคีย์-ค่าบางอย่าง (เช่น การอัปเดต) ไปยัง WAL ก่อนที่จะดำเนินการ หากโหนดขัดข้องและรีสตาร์ทระหว่างสแน็ปช็อต etcd สามารถกู้คืนธุรกรรมตั้งแต่สแน็ปช็อตก่อนหน้าตามเนื้อหาของ WAL

ดังนั้น ทุกครั้งที่ไคลเอนต์เพิ่มคีย์ไปยังที่เก็บ KV หรืออัปเดตค่าของคีย์ที่มีอยู่ etcd จะเพิ่มคำอธิบายของการดำเนินการไปยัง WAL ซึ่งเป็นไฟล์ปกติในที่เก็บถาวร etcd ต้องแน่ใจ 100% ว่ารายการ WAL ได้รับการบันทึกจริงก่อนดำเนินการต่อ เพื่อให้บรรลุสิ่งนี้บน Linux การใช้การเรียกระบบไม่เพียงพอ writeเนื่องจากการดำเนินการเขียนเองไปยังสื่อทางกายภาพอาจล่าช้า ตัวอย่างเช่น Linux อาจเก็บรายการ WAL ไว้ในแคชเคอร์เนลในหน่วยความจำ (เช่น ในแคชเพจ) เป็นระยะเวลาหนึ่ง เพื่อให้แน่ใจว่าข้อมูลถูกเขียนลงในสื่อบันทึก ต้องเรียกใช้การเรียกระบบหลังจากเขียน fdatasync - นี่คือสิ่งที่ etcd ทำ (ดังที่คุณเห็นในผลลัพธ์ต่อไปนี้ strace; ที่นี่ 8 - ตัวอธิบายไฟล์ WAL):

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

น่าเสียดายที่การเขียนไปยังที่เก็บข้อมูลถาวรต้องใช้เวลาพอสมควร การดำเนินการเรียก fdatasync เป็นเวลานานอาจส่งผลต่อประสิทธิภาพการทำงานของ etcd ในเอกสารที่เก็บ ระบุเพื่อให้มีประสิทธิภาพเพียงพอ เปอร์เซ็นไทล์ที่ 99 ของระยะเวลาการโทรทั้งหมดจึงเป็นสิ่งจำเป็น fdatasync เมื่อเขียนไปยังไฟล์ WAL น้อยกว่า 10 ms มีเมตริกที่เกี่ยวข้องกับพื้นที่เก็บข้อมูลอื่นๆ แต่บทความนี้จะเน้นที่เมตริกนั้น

การเพิ่มมูลค่าพื้นที่เก็บข้อมูลด้วย fio

คุณสามารถประเมินว่าที่เก็บข้อมูลใดเหมาะสมสำหรับใช้กับ etcd โดยใช้ยูทิลิตี FiO — เครื่องมือทดสอบ I/O ยอดนิยม โปรดทราบว่า I/O ของดิสก์สามารถเกิดขึ้นได้หลายวิธี: ซิงค์/อะซิงค์, คลาส syscall ต่างๆ มากมาย และอื่นๆ อีกด้านหนึ่งของเหรียญก็คือ fio ใช้งานยากมาก ยูทิลิตีมีพารามิเตอร์มากมายและการผสมผสานค่าต่างๆ เข้าด้วยกันทำให้เกิดผลลัพธ์ที่แตกต่างกันโดยสิ้นเชิง ในการรับค่าประมาณที่สมเหตุสมผลสำหรับ etcd คุณต้องแน่ใจว่าโหลดการเขียนที่สร้างโดย fio นั้นใกล้เคียงกับโหลดการเขียนไฟล์ WAL ของ etcd มากที่สุด:

ซึ่งหมายความว่าสร้างขึ้น fio โหลดอย่างน้อยควรเป็นชุดของการเขียนต่อเนื่องไปยังไฟล์ โดยที่การเขียนแต่ละครั้งประกอบด้วยการเรียกระบบ writeติดตามโดย fdatasync.
หากต้องการเปิดใช้งานการเขียนตามลำดับ คุณต้องระบุแฟล็ก --rw=write.
ที่ fio เขียนโดยใช้การโทร write (มากกว่าการเรียกระบบอื่น - ตัวอย่างเช่น pwrite) ใช้ธง --ioengine=sync.
สุดท้ายก็ฟันธง --fdatasync=1 รับรองว่าทุกๆ write ควร fdatasync.
อีกสองพารามิเตอร์ในตัวอย่างของเราคือ: --size и --bs - อาจแตกต่างกันไปขึ้นอยู่กับกรณีการใช้งานเฉพาะ ส่วนถัดไปจะอธิบายการกำหนดค่า

ทำไมเราถึงเลือก fio และวิธีที่เราเรียนรู้วิธีตั้งค่า

บันทึกนี้มาจากกรณีจริงที่เราเจอ เรามีคลัสเตอร์บน Kubernetes v1.13 พร้อมการตรวจสอบบน Prometheus SSD ถูกใช้เป็นที่เก็บข้อมูลสำหรับ etcd v3.2.24 เมตริก Etcd แสดงเวลาแฝงสูงเกินไป fdatasyncแม้ว่าคลัสเตอร์จะไม่ได้ใช้งาน สำหรับเรา เมตริกเหล่านี้ดูน่าสงสัยมาก และเราไม่แน่ใจว่าเมตริกเหล่านี้แสดงถึงอะไรกันแน่ นอกจากนี้ คลัสเตอร์ประกอบด้วยเครื่องเสมือน ดังนั้นจึงไม่สามารถบอกได้ว่าความล่าช้าเกิดจากการจำลองเสมือนหรือ SSD เป็นสาเหตุ

นอกจากนี้ เรายังพิจารณาถึงการเปลี่ยนแปลงต่างๆ ในการกำหนดค่าฮาร์ดแวร์และซอฟต์แวร์ ดังนั้นเราจึงต้องการวิธีการประเมิน แน่นอน มันเป็นไปได้ที่จะเรียกใช้ etcd ในแต่ละการกำหนดค่าและดูเมตริกของ Prometheus ที่สอดคล้องกัน แต่นั่นต้องใช้ความพยายามอย่างมาก สิ่งที่เราต้องการคือวิธีง่ายๆ ในการประเมินการกำหนดค่าเฉพาะ เราต้องการทดสอบความเข้าใจของเราเกี่ยวกับเมตริก Prometheus ที่มาจาก etcd

สิ่งนี้จำเป็นต้องแก้ปัญหาสองประการ:

อันดับแรก โหลด I/O ที่สร้างโดย etcd เมื่อเขียนไปยังไฟล์ WAL มีลักษณะอย่างไร ใช้การเรียกของระบบอะไร บล็อกบันทึกมีขนาดเท่าใด
ประการที่สอง สมมติว่าเรามีคำตอบสำหรับคำถามข้างต้น วิธีสร้างโหลดที่สอดคล้องกับ fio? หลังจากนั้น fio — ยูทิลิตี้ที่ยืดหยุ่นอย่างยิ่งพร้อมพารามิเตอร์มากมาย (ตรวจสอบได้ง่าย เช่น ที่นี่ - ประมาณ แปล.).

เราแก้ไขปัญหาทั้งสองด้วยวิธีตามคำสั่งเดียวกัน lsof и strace:

ด้วย lsof คุณสามารถดูตัวอธิบายไฟล์ทั้งหมดที่ใช้โดยกระบวนการ รวมถึงไฟล์ที่อ้างถึง
ด้วย strace คุณสามารถวิเคราะห์กระบวนการที่กำลังทำงานอยู่หรือเรียกใช้กระบวนการและดูได้ คำสั่งแสดงการเรียกระบบทั้งหมดที่ทำโดยกระบวนการนี้ และถ้าจำเป็น แสดงการเรียกที่สืบทอดมา สิ่งหลังมีความสำคัญสำหรับกระบวนการที่กำลังทำการ Forking และ etcd เป็นหนึ่งในกระบวนการดังกล่าว

สิ่งแรกที่เราทำคือการใช้ strace เพื่อตรวจสอบเซิร์ฟเวอร์ etcd ในคลัสเตอร์ Kubernetes ขณะที่ไม่ได้ใช้งาน

จึงพบว่ากลุ่มบันทึก WAL นั้นจัดกลุ่มหนาแน่นมาก ขนาดของส่วนใหญ่อยู่ในช่วง 2200-2400 ไบต์ นั่นคือสาเหตุที่คำสั่งในตอนต้นของบทความนี้ใช้แฟล็ก --bs=2300 (bs คือขนาดเป็นไบต์ของบล็อกการเขียนแต่ละบล็อก fio).

โปรดทราบว่าขนาดของบล็อกการเขียน etcd อาจแตกต่างกันไปขึ้นอยู่กับเวอร์ชัน การปรับใช้ ค่าพารามิเตอร์ ฯลฯ - มีผลต่อระยะเวลา fdatasync. หากคุณมีกรณีการใช้งานที่คล้ายกัน ให้วิเคราะห์ด้วย strace กระบวนการ etcd ของคุณเพื่อรับค่าล่าสุด

จากนั้น เพื่อให้ได้แนวคิดที่ชัดเจนและครอบคลุมเกี่ยวกับวิธีการทำงานของ etcd กับระบบไฟล์ เราจึงเริ่มจากด้านล่าง strace ด้วยธง -ffttT. สิ่งนี้ทำให้สามารถจับภาพกระบวนการลูกและเขียนผลลัพธ์ของแต่ละไฟล์ไปยังไฟล์แยกต่างหาก นอกจากนี้ยังได้รับข้อมูลโดยละเอียดเกี่ยวกับเวลาเริ่มต้นและระยะเวลาของการเรียกระบบแต่ละครั้ง

เรายังใช้คำสั่ง lsofเพื่อยืนยันความเข้าใจของคุณเกี่ยวกับผลลัพธ์ strace ในแง่ของการใช้ตัวอธิบายไฟล์เพื่อจุดประสงค์ใด ฉันได้ข้อสรุปแล้ว straceคล้ายกับด้านบน การจัดการทางสถิติพร้อมเวลาซิงโครไนซ์ยืนยันว่าเมตริก wal_fsync_duration_seconds จากการโทรจับคู่ etcd fdatasync ด้วยตัวอธิบายไฟล์ WAL

เพื่อสร้างด้วย fio ปริมาณงานที่คล้ายกับจาก etcd มีการศึกษาเอกสารของยูทิลิตี้และเลือกพารามิเตอร์ที่เหมาะสมกับงานของเรา เราได้ตรวจสอบแล้วว่าการเรียกระบบที่ถูกต้องกำลังดำเนินการอยู่ และยืนยันระยะเวลาโดยเรียกใช้ fio ของ strace (เหมือนที่ทำในกรณี etcd)

ให้ความสนใจเป็นพิเศษกับการกำหนดค่าของพารามิเตอร์ --size. ซึ่งแสดงถึงโหลด I/O ทั้งหมดที่สร้างโดยยูทิลิตี fio ในกรณีของเรา นี่คือจำนวนไบต์ทั้งหมดที่เขียนไปยังสื่อ เป็นสัดส่วนโดยตรงกับจำนวนการโทร write (และ fdatasync). สำหรับเฉพาะ bs จำนวนการโทร fdatasync เป็น size / bs.

เนื่องจากเราสนใจเปอร์เซ็นไทล์ เราจึงต้องการให้จำนวนตัวอย่างมีจำนวนมากพอที่จะมีนัยสำคัญทางสถิติ และตัดสินใจว่า 10^4 (ซึ่งตรงกับขนาด 22 MB) ก็เพียงพอแล้ว ค่าพารามิเตอร์ที่น้อยลง --size ให้เสียงที่ดังกว่า (เช่น การโทร fdatasyncซึ่งใช้เวลานานกว่าปกติมากและส่งผลต่อเปอร์เซ็นไทล์ที่ 99)

มันขึ้นอยู่กับคุณ

บทความแสดงวิธีใช้ fio เราสามารถตัดสินได้ว่าสื่อที่มีไว้สำหรับใช้กับ etcd นั้นเร็วพอหรือไม่ ตอนนี้ก็ขึ้นอยู่กับคุณแล้ว! คุณสามารถสำรวจเครื่องเสมือนด้วยที่เก็บข้อมูลแบบ SSD ในบริการ IBM Cloud.

ปล.จากผู้แปล

ด้วยกรณีการใช้งานสำเร็จรูป fio สำหรับงานอื่นๆ ดูที่ เอกสาร หรือโดยตรงที่ ที่เก็บโครงการ (มีมากกว่าที่กล่าวถึงในเอกสาร)

PPS จากผู้แปล

อ่านเพิ่มเติมในบล็อกของเรา:

ที่มา: will.com

วิธีตรวจสอบดิสก์ด้วย fio เพื่อประสิทธิภาพที่เพียงพอสำหรับ etcd