ความเร็วในการจัดเก็บเหมาะสำหรับ etcd? ไปถามฟีโอ

เรื่องสั้นเกี่ยวกับ fio และ etcd

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

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

เรื่องยาวเกี่ยวกับ fio และ etcd

WAL คืออะไรใน etcd

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

เมื่อไคลเอนต์เพิ่มคีย์ไปยังที่เก็บคีย์-ค่าหรืออัพเดตค่าของคีย์ที่มีอยู่ etcd จะบันทึกการดำเนินการใน WAL ซึ่งเป็นไฟล์ปกติในที่จัดเก็บถาวร etcd ต้องแน่ใจว่ารายการ WAL เกิดขึ้นจริงก่อนที่จะดำเนินการประมวลผลต่อไป บน Linux การเรียกระบบเพียงครั้งเดียวไม่เพียงพอสำหรับสิ่งนี้ เขียนเนื่องจากการเขียนจริงไปยังที่เก็บข้อมูลจริงอาจล่าช้า ตัวอย่างเช่น Linux อาจจัดเก็บรายการ WAL ไว้ในแคชในหน่วยความจำเคอร์เนล (เช่น แคชเพจ) เป็นระยะเวลาหนึ่ง และเพื่อให้ข้อมูลถูกเขียนลงที่จัดเก็บข้อมูลถาวรอย่างถูกต้อง การเรียกระบบ 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 ใช้เวลาน้อยกว่า 10 มิลลิวินาทีในการเขียนไปยังไฟล์ WAL มีเมตริกที่มีประโยชน์อื่นๆ สำหรับการจัดเก็บ แต่ในโพสต์นี้ เรากำลังพูดถึงเมตริกนี้เท่านั้น

การประมาณการที่เก็บข้อมูลด้วย fio

หากคุณต้องการประเมินว่าที่เก็บข้อมูลของคุณเหมาะสมกับ etcd หรือไม่ ให้ใช้ fio ซึ่งเป็นเครื่องมือทดสอบโหลด I/O ที่ได้รับความนิยมอย่างมาก ควรจำไว้ว่าการทำงานของดิสก์อาจแตกต่างกันมาก: ซิงโครนัสและอะซิงโครนัสการเรียกระบบหลายคลาส ฯลฯ ด้วยเหตุนี้ 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 แสดงเวลาแฝง fdatasync สูงเกินไป แม้ว่าคลัสเตอร์ไม่ได้ทำอะไรเลย เมตริกนั้นแปลกและเราไม่รู้ความหมายจริงๆ คลัสเตอร์ประกอบด้วยเครื่องเสมือน จำเป็นต้องเข้าใจว่าปัญหาคืออะไร: ใน SSD จริงหรือในเลเยอร์การจำลองเสมือน นอกจากนี้ เรามักทำการเปลี่ยนแปลงการกำหนดค่าฮาร์ดแวร์และซอฟต์แวร์ และเราต้องการวิธีประเมินผลลัพธ์ เราสามารถเรียกใช้ etcd ในทุกการกำหนดค่าและดูเมตริกของ Prometheus ได้ แต่นั่นเป็นเรื่องที่ยุ่งยากเกินไป เรากำลังมองหาวิธีที่ค่อนข้างง่ายในการประเมินการกำหนดค่าเฉพาะ เราต้องการตรวจสอบว่าเราเข้าใจเมตริก Prometheus จาก etcd ถูกต้องหรือไม่

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

ก่อนอื่น เราใช้ strace เพื่อสำรวจเซิร์ฟเวอร์ etcd สำหรับ Kubernetes เมื่อไม่มีการโหลดในคลัสเตอร์ เราเห็นว่าบันทึก WAL เกือบทั้งหมดมีขนาดเท่ากัน: 2200–2400 ไบต์ ดังนั้น ในคำสั่งที่จุดเริ่มต้นของโพสต์ เราจึงระบุพารามิเตอร์ -bs=2300 (bs หมายถึงขนาดเป็นไบต์สำหรับแต่ละรายการ fio) โปรดทราบว่าขนาดของรายการ etcd ขึ้นอยู่กับเวอร์ชันของ etcd, การแจกแจง, ค่าพารามิเตอร์ ฯลฯ และส่งผลต่อระยะเวลา fdatasync หากคุณมีสถานการณ์ที่คล้ายกัน ให้ตรวจสอบกระบวนการ etcd ของคุณด้วย strace เพื่อหาตัวเลขที่แน่นอน

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

เราอ่านเอกสารประกอบสำหรับ fio และเลือกตัวเลือกสำหรับสคริปต์ของเรา เพื่อให้ fio สร้างโหลดที่คล้ายกับ etcd เรายังตรวจสอบการเรียกของระบบและระยะเวลาด้วยการเรียกใช้ fio จาก strace ซึ่งคล้ายกับ etcd

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

ลองด้วยตัวคุณเอง

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

ที่มา: will.com