ปรับปรุง IO ด้วย FlashCache

ฉันมีเซิร์ฟเวอร์ที่มี 2 HDD (2x 1 TB) ทำงานใน RAID 1 (SW-RAID) ฉันต้องการที่จะปรับปรุงประสิทธิภาพ IO flashcacheโดยใช้ มีกำลังทำงานเสมือนเครื่อง KVM LVMที่มันใช้

เกี่ยวกับเรื่องนี้ฉันมีคำถามต่อไปนี้:

• มันจะใช้งานได้หรือไม่ flashcacheใช้งานได้กับอุปกรณ์บล็อกอย่างไรก็ตามอุปกรณ์เหล่านี้เป็นเครื่องเสมือนทั้งหมดที่มีการตั้งค่าของตัวเอง
• ฉันจะคาดหวังว่าจะเพิ่มประสิทธิภาพได้เท่าไหร่ เครื่องเสมือนส่วนใหญ่ใช้เว็บไซต์และเกมโฮสต์
• SSD ต้องมีขนาดใหญ่แค่ไหน SSD ขนาดใหญ่จะมีประสิทธิภาพเพิ่มขึ้นหรือไม่เนื่องจากสามารถแคชไฟล์ได้มากขึ้นหรือไม่
• จะเกิดอะไรขึ้นถ้า SSD ตาย จะflashcacheเรียกไฟล์จาก HDD แบบเดิมและฉันสามารถเปลี่ยน SSD ได้หรือไม่
• จะเร็วกว่ามากwritebackเมื่อเทียบกับwritethroughและwritearound?

ฉันไม่สามารถเข้าถึงระบบทดสอบได้ดังนั้นฉันสามารถติดตั้งflashcacheบนเซิร์ฟเวอร์ที่ใช้งานจริงโดยไม่ต้องถอดดิสก์ได้หรือไม่ ฉันพบบทเรียนที่ยอดเยี่ยมที่นี่ซึ่งฉันจะใช้

Flashcache สำหรับผู้ที่ไม่เคยเห็นมาก่อนเป็นวิธีการขยาย Linux block-cache ด้วยไดรฟ์ SSD มันถูกกว่าการใช้เซิร์ฟเวอร์ที่มี RAM ครึ่ง TB เพียงเพื่อแคช

มันจะใช้งานได้หรือไม่

มันควรจะ. ลินุกซ์บล็อกแคชแคชทำงานโดยการเข้าถึงบล็อกไม่ไฟล์ ตราบใดที่คุณไม่ให้เครื่อง KVM สามารถเข้าถึงอุปกรณ์บล็อกได้โดยตรง (คุณไม่ได้ใช้งาน) Linux Block Cache จะเปิดใช้งาน แต่ถ้าคุณจะให้เครื่อง KVM ปิดกั้นการเข้าถึงอุปกรณ์โดยตรงคำตอบที่มีความชัดเจนน้อย

หากคุณใช้ดิสก์เสมือนที่สำรองข้อมูลไฟล์นั้นจะใช้งานได้อย่างแน่นอน

หากคุณกำลังใช้ดิสก์เสมือนที่ได้รับการสนับสนุน LV ฉันไม่รู้

ฉันจะคาดหวังว่าจะเพิ่มประสิทธิภาพได้เท่าไหร่

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

SSD ต้องมีขนาดใหญ่แค่ไหน

การหาขนาดที่แน่นอนที่คุณต้องการคือสิ่งที่เราไม่สามารถช่วยเหลือได้ มากกว่านั้นชัดเจนกว่า แต่การหาอัตราส่วนที่แน่นอนระหว่าง cache-SSD และที่เก็บข้อมูลหลักไม่ใช่เรื่องง่าย

สิ่งที่ทำให้สับสนนี้คือการตั้งค่าการเขียนให้ล้างข้อมูลทันทีเช่นการทำงานของระบบไฟล์และการกำหนดค่าฐานข้อมูลบางอย่าง การเขียนเหล่านั้นจะถูกแคชในเวลาสั้น ๆ เท่านั้นและประสิทธิภาพการทำงานของมันจะไม่ได้รับผลกระทบใด ๆ จากการมีหรือไม่มี flashcache

จะเกิดอะไรขึ้นถ้า SSD ตาย

สิ่งเดียวกันนี้เกิดขึ้นเมื่อคุณบอกให้ Linux วางแคช แต่มีปัญหา ด้วยการวางแคชการเขียนที่ไม่ได้ฟลัชใด ๆ ที่อยู่ในบล็อกแคชจะถูกลบทิ้งไปยังดิสก์ จะเกิดอะไรขึ้นเมื่อ SSD หายไปขึ้นอยู่กับโหมดแคช :

Writethrough : การเขียนทั้งหมดจะถูกเขียนไปยังแคชและที่เก็บข้อมูลหลักพร้อมกันดังนั้นโอกาสที่ SSD จะสูญเสียอย่างฉับพลันทำให้เกิดข้อผิดพลาดบน VMs มีขนาดเล็กมาก

Writearound : การเขียนทั้งหมดจะถูกเขียนไปยังที่เก็บข้อมูลหลักและแคชเฉพาะเมื่ออ่าน ไม่มีโอกาสเกิดข้อผิดพลาดใน VMs

Writeback : การเขียนทั้งหมดไปที่ Cache ก่อนและเขียนไปยังที่เก็บข้อมูลหลักในพื้นหลัง มีแนวโน้มมากที่สุดที่จะทำให้เกิดข้อผิดพลาดใน VM ของคุณหาก SSD ล้มเหลวและฉันจะไม่ใช้โหมดนี้ในการผลิต

จะเร็วกว่าการเขียนมากเพียงใดเมื่อเปรียบเทียบกับการเขียนทับและการเขียนซ้ำ?

ขึ้นอยู่กับว่าคุณเขียนไปมากแค่ไหน หากการเขียนของคุณทำให้ที่เก็บข้อมูลหลักอิ่มตัวเป็นระยะการเพิ่มประสิทธิภาพอาจมีความสำคัญ หากคุณอ่านด้วยการเขียนเป็นส่วนใหญ่คุณจะไม่สังเกตเห็นการปรับปรุง

นอกจากนี้การเขียนกลับเป็นนโยบายที่ไม่ดีสำหรับสิ่งที่คุณทำดังนั้นอย่าใช้มัน

ใช่มันจะทำงานได้ดีตราบใดที่คุณใช้อุปกรณ์บล็อกที่เหมาะสม และมีเคล็ดลับ

เมื่อ LVM สแกนหา PV ก็ควรเห็นพาร์ทิชันผ่านฮาร์ดไดรฟ์ตัวจริงและผ่านอุปกรณ์ flashcache "เสมือน" เช่นกัน

อาการหนึ่งที่เห็นได้ชัดคือเครื่องมือ LVM บ่นเกี่ยวกับ PVs ที่ซ้ำกัน

การแก้ไขเพื่อหลีกเลี่ยงคำเตือนเหล่านั้นและที่สำคัญตรวจสอบให้แน่ใจว่าอุปกรณ์ flashcache จะถูกใช้โดย LVM2 /etc/lvm/lvm.confคือการปรับตัวเข้ากับตัวกรองใน

LVM.CONF(5)manpage จะอธิบายได้ดีกว่าผม แต่ผมจะทำให้คุณมีตัวอย่างถ้าทุกปริมาณทางกายภาพได้รับการสนับสนุนโดย flashcache:

filter = [ "a/.*dm.*/" ]

นอกจากนี้ยังมีชั้นจากผู้สร้าง lessfs ที่จะช่วยให้คุณสร้างอุปกรณ์ไฮบริดระหว่าง SSD และ HDD ประสิทธิภาพการทำงานของระดับนั้นดีกว่า Flashcache

http://www.lessfs.com/wordpress/

http://www.lessfs.com/wordpress/?p=776

// คริสเตียน

แอปพลิเคชั่นบางตัวเปิดไฟล์ในลักษณะที่ไม่มีบัฟเฟอร์

http://man7.org/linux/man-pages/man2/open.2.html

O_DIRECT (ตั้งแต่ Linux 2.4.10) พยายามลดผลกระทบที่แคชของ I / O ไปยังและจากไฟล์นี้ โดยทั่วไปจะทำให้ประสิทธิภาพลดลง แต่มีประโยชน์ในสถานการณ์พิเศษเช่นเมื่อแอปพลิเคชันทำการแคชของตัวเอง ไฟล์ I / O จะทำโดยตรงกับ / จากบัฟเฟอร์พื้นที่ผู้ใช้ การตั้งค่าสถานะ O_DIRECT ด้วยตนเองพยายามถ่ายโอนข้อมูลแบบซิงโครนัส แต่ไม่ให้การรับประกันของการตั้งค่าสถานะ O_SYNC ว่าข้อมูลและข้อมูลเมตาที่จำเป็นจะถูกถ่ายโอน เพื่อรับประกัน I / O แบบซิงโครนัสจะต้องใช้ O_SYNC นอกเหนือจาก O_DIRECT ดูหมายเหตุด้านล่างสำหรับการสนทนาเพิ่มเติม

ตัวอย่างเช่นนี่เป็นเรื่องธรรมดามากสำหรับฐานข้อมูล ดังนั้นตรวจสอบอีกครั้งว่า flashcache ใช้ได้กับแอพพลิเคชั่นชุดนี้หรือไม่