อัปเดต!. ในความคิดเห็นผู้อ่านคนหนึ่งแนะนำให้ลอง (บางทีเขาอาจจะกำลังดำเนินการเรื่องนี้ด้วยตัวเอง) ดังนั้นฉันจึงได้เพิ่มส่วนเกี่ยวกับโซลูชันนี้ ฉันยังเขียน เพราะกระบวนการแตกต่างจากที่อื่นมาก
พูดตามตรงฉันยอมแพ้และยอมแพ้ (อย่างน้อยก็ตอนนี้). ฉันจะใช้ . ทำไม เพราะเก็บของ! ใครจะคิดว่าฉันจะปรับแต่งพื้นที่เก็บข้อมูลมากกว่า Kubernetes เอง ฉันใช้ เนื่องจากมีราคาไม่แพงและประสิทธิภาพดี และตั้งแต่เริ่มแรกฉันก็ปรับใช้คลัสเตอร์โดยใช้ . ฉันไม่ได้ลองใช้บริการ Kubernetes ที่มีการจัดการจาก Google/Amazon/Microsoft/DigitalOcean ฯลฯ ฯลฯ เพราะฉันต้องการเรียนรู้ทุกอย่างด้วยตัวเอง ฉันยังประหยัด
ใช่แล้ว ฉันใช้เวลามากมายในการตัดสินใจว่าจะเลือกพื้นที่จัดเก็บข้อมูลใดเมื่อประเมินสแต็ก Kubernetes ที่เป็นไปได้ ฉันชอบโซลูชันโอเพ่นซอร์สมากกว่า ไม่ใช่แค่เพราะราคาเท่านั้น แต่ฉันได้ดูตัวเลือกที่ต้องชำระเงินสองสามตัวเลือกด้วยความอยากรู้อยากเห็น เนื่องจากมีเวอร์ชันฟรีที่มีข้อจำกัด ฉันได้จดตัวเลขบางส่วนจากการทดสอบล่าสุดเมื่อเปรียบเทียบตัวเลือกต่างๆ และตัวเลขเหล่านี้อาจเป็นที่สนใจสำหรับผู้ที่เรียนรู้เกี่ยวกับพื้นที่เก็บข้อมูล Kubernetes แม้ว่าตอนนี้ฉันจะบอกลา Kubernetes เป็นการส่วนตัวแล้วก็ตาม ฉันยังต้องการที่จะพูดถึง ซึ่งสามารถจัดเตรียมวอลลุม Hetzner Cloud ได้โดยตรง แต่ฉันยังไม่ได้ลองใช้ ฉันพิจารณาพื้นที่จัดเก็บข้อมูลที่กำหนดโดยซอฟต์แวร์คลาวด์เพราะฉันต้องการการจำลองแบบและความสามารถในการติดตั้งวอลุ่มถาวรบนโหนดใดๆ ได้อย่างรวดเร็ว โดยเฉพาะอย่างยิ่งในกรณีที่โหนดล้มเหลวและสถานการณ์อื่นๆ ที่คล้ายคลึงกัน โซลูชันบางอย่างนำเสนอสแน็ปช็อต ณ เวลาใดเวลาหนึ่งและการสำรองข้อมูลนอกสถานที่ซึ่งสะดวก
ฉันทดสอบโซลูชันการจัดเก็บข้อมูล 6-7 รายการ:
อย่างที่บอกไปแล้ว หลังจากทดสอบตัวเลือกส่วนใหญ่จากรายการแล้ว ฉันจึงตัดสินใจเลือก OpenEBS ในตอนแรก OpenEBS ติดตั้งและใช้งานง่ายมาก แต่พูดตามตรง หลังจากทดสอบด้วยข้อมูลจริงภายใต้ภาระงาน ฉันรู้สึกผิดหวังกับประสิทธิภาพของมัน นี่เป็นโอเพ่นซอร์สและนักพัฒนาก็ทำด้วยตัวเอง มีประโยชน์มากเสมอเมื่อฉันต้องการความช่วยเหลือ น่าเสียดายที่มันมีประสิทธิภาพต่ำมากเมื่อเทียบกับตัวเลือกอื่นๆ ดังนั้นการทดสอบจึงต้องทำใหม่อีกครั้ง ปัจจุบัน OpenEBS มีเอ็นจิ้นการจัดเก็บข้อมูล 3 ตัว แต่ฉันกำลังโพสต์ผลลัพธ์การวัดประสิทธิภาพสำหรับ cStor ฉันยังไม่มีหมายเลขสำหรับ Jiva และ LocalPV
โดยสรุป Jiva นั้นเร็วกว่าเล็กน้อย และโดยทั่วไป LocalPV ก็เร็ว ไม่แย่ไปกว่าเกณฑ์มาตรฐานของดิสก์โดยตรง ปัญหาของ LocalPV คือสามารถเข้าถึงโวลุ่มได้บนโหนดที่เตรียมไว้เท่านั้น และไม่มีการจำลองเลย ฉันมีปัญหาในการกู้คืนข้อมูลสำรองผ่าน บนคลัสเตอร์ใหม่เนื่องจากชื่อโหนดแตกต่างกัน ถ้าเราพูดถึงการสำรองข้อมูล cStor ก็มี ซึ่งคุณสามารถสำรองข้อมูลสแน็ปช็อตนอกสถานที่ ณ เวลาใดเวลาหนึ่งได้ ซึ่งสะดวกกว่าการสำรองข้อมูลระดับไฟล์ด้วย Velero-Restic ฉันเขียน เพื่อให้ง่ายต่อการจัดการการสำรองข้อมูลและกู้คืนด้วยปลั๊กอินนี้ โดยรวมแล้ว ฉันชอบ OpenEBS มาก แต่ประสิทธิภาพของมัน...
Rook ยังเป็นโอเพ่นซอร์สและแตกต่างจากตัวเลือกที่เหลือในรายการตรงที่เป็นตัวจัดการพื้นที่จัดเก็บข้อมูลที่ดำเนินงานการจัดการพื้นที่จัดเก็บข้อมูลที่ซับซ้อนด้วยแบ็กเอนด์ที่แตกต่างกัน เช่น , และอื่น ๆ ซึ่งทำให้งานง่ายขึ้นมาก ฉันมีปัญหากับ EfgeFS เมื่อลองใช้เมื่อไม่กี่เดือนที่ผ่านมา ดังนั้นฉันจึงทดสอบกับ Ceph เป็นหลัก Ceph ไม่เพียงนำเสนอพื้นที่จัดเก็บแบบบล็อกเท่านั้น แต่ยังมีพื้นที่จัดเก็บอ็อบเจ็กต์ที่เข้ากันได้กับ S3/Swift และระบบไฟล์แบบกระจายอีกด้วย สิ่งที่ฉันชอบเกี่ยวกับ Ceph คือความสามารถในการกระจายข้อมูลโวลุ่มไปยังดิสก์หลายตัว เพื่อให้โวลุ่มนั้นใช้พื้นที่ดิสก์มากกว่าที่จะใส่ลงในดิสก์แผ่นเดียวได้ สะดวกสบาย. คุณสมบัติที่ยอดเยี่ยมอีกประการหนึ่งคือเมื่อคุณเพิ่มดิสก์ลงในคลัสเตอร์ ระบบจะกระจายข้อมูลบนดิสก์ทั้งหมดโดยอัตโนมัติ
Ceph มีสแนปช็อต แต่เท่าที่ฉันรู้ ไม่สามารถนำมาใช้โดยตรงใน Rook/Kubernetes ได้ จริงอยู่ที่ฉันไม่ได้เจาะลึกเรื่องนี้ แต่ไม่มีการสำรองข้อมูลนอกสถานที่ ดังนั้นคุณจะต้องใช้บางอย่างกับ Velero/Restic แต่มีการสำรองข้อมูลระดับไฟล์เท่านั้น ไม่ใช่สแน็ปช็อต ณ เวลาใดเวลาหนึ่ง สิ่งที่ฉันชอบเกี่ยวกับ Rook มากคือการทำงานกับ Ceph ได้ง่ายเพียงใด โดยซ่อนสิ่งที่ซับซ้อนเกือบทั้งหมดและมีเครื่องมือในการพูดคุยกับ Ceph โดยตรงเพื่อแก้ไขปัญหา น่าเสียดายที่ในระหว่างการทดสอบความเครียดของวอลุ่ม Ceph ฉันยังคงประสบปัญหาอยู่ ซึ่งทำให้ Ceph ไม่เสถียร ยังไม่ชัดเจนว่านี่เป็นข้อบกพร่องใน Ceph เองหรือเป็นปัญหาในวิธีที่ Rook จัดการ Ceph ฉันปรับแต่งการตั้งค่าหน่วยความจำ และมันก็ดีขึ้น แต่ปัญหายังไม่ได้รับการแก้ไขอย่างสมบูรณ์ Ceph มีประสิทธิภาพที่ดี ดังที่คุณเห็นในเกณฑ์มาตรฐานด้านล่าง นอกจากนี้ยังมีแดชบอร์ดที่ดี
ฉันชอบลองฮอร์นมาก ในความคิดของฉัน นี่เป็นวิธีแก้ปัญหาที่น่าหวัง จริงอยู่ นักพัฒนาเอง (Rancher Labs) ยอมรับว่ายังไม่เหมาะกับสภาพแวดล้อมการทำงาน และสิ่งนี้แสดงให้เห็น เป็นโอเพ่นซอร์สและมีประสิทธิภาพที่ดี (แม้ว่าจะยังไม่ได้เพิ่มประสิทธิภาพก็ตาม) แต่โวลุ่มใช้เวลานานมากในการเชื่อมต่อกับพ็อด และในกรณีที่เลวร้ายที่สุดจะใช้เวลา 15-16 นาที โดยเฉพาะอย่างยิ่งหลังจากกู้คืนข้อมูลสำรองขนาดใหญ่หรือ การอัพเกรดภาระงาน มีสแน็ปช็อตและการสำรองข้อมูลนอกสถานที่ของสแน็ปช็อตเหล่านี้ แต่ใช้ได้กับวอลุ่มเท่านั้น ดังนั้นคุณยังคงต้องใช้บางอย่างเช่น Velero เพื่อสำรองข้อมูลทรัพยากรอื่น ๆ การสำรองและกู้คืนข้อมูลมีความน่าเชื่อถือมาก แต่ช้าอย่างไม่เหมาะสม อย่างจริงจังเพียงช้าอย่างไม่น่าเชื่อ การใช้งาน CPU และโหลดของระบบมักจะเพิ่มขึ้นอย่างรวดเร็วเมื่อทำงานกับข้อมูลจำนวนปานกลางใน Longhorn มีแดชบอร์ดที่สะดวกในการจัดการ Longhorn ฉันบอกไปแล้วว่าฉันชอบลองฮอร์น แต่มันต้องมีการปรับปรุงบ้าง
StorageOS เป็นผลิตภัณฑ์ที่ต้องชำระเงินตัวแรกในรายการ มีเวอร์ชันสำหรับนักพัฒนาซอฟต์แวร์ที่มีขนาดพื้นที่จัดเก็บข้อมูลที่มีการจัดการจำกัดที่ 500GB แต่ฉันไม่คิดว่าจะมีการจำกัดจำนวนโหนด แผนกขายบอกฉันว่าราคาเริ่มต้นที่ 125 ดอลลาร์ต่อเดือนสำหรับ 1 TB ถ้าฉันจำไม่ผิด มีแดชบอร์ดพื้นฐานและ CLI ที่สะดวกสบาย แต่มีบางอย่างแปลก ๆ เกิดขึ้นกับประสิทธิภาพ: ในการวัดประสิทธิภาพบางอย่างมันค่อนข้างดี แต่ในการทดสอบความเครียดของระดับเสียงฉันไม่ชอบความเร็วเลย โดยทั่วไปฉันไม่รู้ว่าจะพูดอะไร ฉันก็เลยไม่ค่อยเข้าใจมากนัก ที่นี่ไม่มีการสำรองข้อมูลนอกสถานที่ และคุณจะต้องใช้ Velero กับ Retic เพื่อสำรองข้อมูลโวลุ่มด้วย แปลกเพราะสินค้ามีการชำระเงิน และนักพัฒนาก็ไม่กระตือรือร้นที่จะสื่อสารบน Slack
ฉันเรียนรู้เกี่ยวกับ Robin บน Reddit จากผู้อำนวยการด้านเทคนิคของพวกเขา ฉันไม่เคยได้ยินเกี่ยวกับเขามาก่อน อาจเป็นเพราะฉันกำลังมองหาวิธีแก้ปัญหาฟรี แต่ Robin ก็ได้รับค่าตอบแทน พวกเขามีเวอร์ชันฟรีที่ค่อนข้างใจกว้างพร้อมพื้นที่เก็บข้อมูล 10TB และสามโหนด โดยรวมแล้วผลิตภัณฑ์ค่อนข้างดีและมีคุณสมบัติที่ดี มี CLI ที่ยอดเยี่ยม แต่สิ่งที่ยอดเยี่ยมที่สุดคือคุณสามารถสแนปช็อตและสำรองข้อมูลแอปพลิเคชันทั้งหมดได้ (ในตัวเลือกทรัพยากรซึ่งเรียกว่า Helm release หรือ “แอปแบบยืดหยุ่น”) รวมถึงวอลุ่มและทรัพยากรอื่นๆ ดังนั้นคุณจึงสามารถทำได้โดยไม่ต้องใช้ Velero และทุกอย่างจะยอดเยี่ยมถ้าไม่ใช่สำหรับรายละเอียดเล็ก ๆ น้อย ๆ: หากคุณกู้คืน (หรือ "นำเข้า" ตามที่เรียกใน Robin) แอปพลิเคชันบนคลัสเตอร์ใหม่ - ตัวอย่างเช่นในกรณีของการกู้คืนจากภัยพิบัติ - การฟื้นฟู แน่นอนใช้งานได้ แต่ยังคงสำรองข้อมูลแอปพลิเคชันต่อไปซึ่งเป็นสิ่งต้องห้าม สิ่งนี้เป็นไปไม่ได้ในรุ่นนี้ ดังที่ผู้พัฒนาได้ยืนยันแล้ว พูดง่ายๆ ก็คือแปลก โดยเฉพาะอย่างยิ่งเมื่อพิจารณาถึงข้อดีอื่นๆ (เช่น การสำรองและกู้คืนข้อมูลที่รวดเร็วอย่างไม่น่าเชื่อ) นักพัฒนาสัญญาว่าจะแก้ไขทุกอย่างในรุ่นถัดไป โดยทั่วไปแล้วประสิทธิภาพดี แต่ฉันสังเกตเห็นสิ่งแปลก: ถ้าฉันรันการวัดประสิทธิภาพโดยตรงบนวอลลุมที่เชื่อมต่อกับโฮสต์ ความเร็วในการอ่านจะเร็วกว่าการรันวอลลุมเดียวกันจากภายในพ็อดมาก ผลลัพธ์อื่นๆ ทั้งหมดเหมือนกัน แต่ในทางทฤษฎีแล้วไม่ควรมีความแตกต่างกัน แม้ว่าพวกเขากำลังดำเนินการแก้ไขอยู่ แต่ฉันก็ไม่พอใจกับปัญหาในการกู้คืนและสำรองข้อมูล - ฉันคิดว่าในที่สุดฉันก็พบวิธีแก้ปัญหาที่เหมาะสมแล้ว และฉันก็เต็มใจที่จะจ่ายเงินเมื่อฉันต้องการพื้นที่เพิ่มหรือเซิร์ฟเวอร์เพิ่มเติม
ฉันไม่มีอะไรจะพูดมากที่นี่ นี่เป็นผลิตภัณฑ์ที่ต้องชำระเงิน เจ๋งและแพงไม่แพ้กัน การแสดงนั้นยอดเยี่ยมมาก นี่คือตัวบ่งชี้ที่ดีที่สุดจนถึงตอนนี้ Slack บอกฉันว่าราคาเริ่มต้นที่ 205 ดอลลาร์ต่อเดือนต่อโหนด ตามที่ระบุไว้ใน GKE Marketplace ของ Google ไม่รู้ว่าถ้าซื้อตรงจะถูกกว่าไหม ฉันไม่สามารถจ่ายได้ ดังนั้นฉันจึงผิดหวังมากที่ใบอนุญาตสำหรับนักพัฒนา (สูงสุด 1 TB และ 3 โหนด) นั้นไม่มีประโยชน์จริง ๆ กับ Kubernetes เว้นแต่คุณจะพอใจกับการจัดเตรียมแบบคงที่ ฉันหวังว่า Volume License จะดาวน์เกรดเป็นนักพัฒนาโดยอัตโนมัติเมื่อสิ้นสุดช่วงทดลองใช้งาน แต่นั่นกลับไม่เกิดขึ้น สิทธิ์การใช้งานสำหรับนักพัฒนาสามารถใช้ได้โดยตรงกับ Docker เท่านั้น และการกำหนดค่าใน Kubernetes นั้นยุ่งยากและจำกัดมาก แน่นอนว่าฉันชอบโอเพ่นซอร์สมากกว่า แต่ถ้าฉันมีเงิน ฉันจะเลือก Portworx อย่างแน่นอน จนถึงตอนนี้ ประสิทธิภาพของมันก็ไม่สามารถเปรียบเทียบกับตัวเลือกอื่นๆ ได้
ฉันเพิ่มส่วนนี้หลังจากเผยแพร่บทความแล้ว เมื่อมีผู้อ่านแนะนำให้ลองใช้ Linstor ฉันลองใช้แล้วก็ชอบ! แต่ฉันต้องค้นคว้าเพิ่มเติมอีกหน่อย ตอนนี้ฉันบอกได้ว่าประสิทธิภาพค่อนข้างดี (ฉันได้เพิ่มผลการทดสอบประสิทธิภาพไว้ด้านล่างแล้ว) ที่จริงแล้ว ฉันได้ประสิทธิภาพเท่ากับการทดสอบประสิทธิภาพดิสก์โดยตรง โดยไม่มีค่าใช้จ่ายเพิ่มเติม (อย่าถามว่าทำไมตัวเลขของ Portworx ถึงดีกว่าการทดสอบประสิทธิภาพดิสก์โดยตรง ฉันไม่รู้เหมือนกัน คงเป็นเวทมนตร์มั้ง) ดังนั้น Linstor ดูเหมือนจะมีประสิทธิภาพมากทีเดียว การตั้งค่าไม่ได้ยากนัก แต่ก็ไม่ง่ายเหมือนตัวเลือกอื่นๆ ก่อนอื่น ฉันต้องติดตั้ง Linstor (โมดูลเคอร์เนลและเครื่องมือ/บริการ) และตั้งค่า LVM สำหรับการจัดสรรพื้นที่แบบบาง (thin provisioning) และการรองรับสแนปช็อตภายนอก Kubernetes โดยตรงบนโฮสต์ จากนั้นสร้างทรัพยากรที่จำเป็นในการใช้พื้นที่จัดเก็บข้อมูลจาก Kubernetes ฉันไม่ค่อยพอใจที่มันใช้งานไม่ได้ในบางกรณี CentOS และต้องใช้ Ubuntuแน่นอนว่ามันไม่ใช่เรื่องใหญ่ แต่ก็ค่อนข้างน่ารำคาญเพราะเอกสารประกอบ (ซึ่งยอดเยี่ยมมาก) กล่าวถึงแพ็กเกจหลายตัวที่ไม่มีอยู่ใน repository ของ Epel ที่ระบุไว้ Linstor มีฟังก์ชัน snapshot แต่ไม่มีการสำรองข้อมูลแบบ off-site ดังนั้นผมจึงต้องใช้ Velero กับ Restic อีกครั้งสำหรับการสำรองข้อมูล volume ผมชอบ snapshot มากกว่าการสำรองข้อมูลระดับไฟล์ แต่ก็พอรับได้หากโซลูชันนั้นมีประสิทธิภาพและเชื่อถือได้ Linstor เป็นโอเพนซอร์ส แต่มีบริการสนับสนุนแบบเสียเงิน ถ้าผมเข้าใจถูกต้อง คุณสามารถใช้งานได้โดยไม่มีข้อจำกัดแม้ว่าคุณจะไม่มีสัญญาบริการสนับสนุน แต่ผมต้องตรวจสอบอีกครั้ง ผมไม่รู้ว่า Linstor ได้รับการทดสอบกับ Kubernetes มากแค่ไหน แต่เลเยอร์การจัดเก็บข้อมูลนั้นอยู่นอก Kubernetes และดูเหมือนว่าจะมีมานานแล้ว ดังนั้นน่าจะได้รับการทดสอบในสภาพแวดล้อมจริงมาแล้ว มีโซลูชันใดที่จะทำให้ผมเปลี่ยนใจและกลับไปใช้ Kubernetes หรือไม่ ผมไม่รู้ ฉันต้องศึกษาเรื่องการจำลองข้อมูลให้ละเอียดกว่านี้อีกหน่อย เดี๋ยวค่อยดูกัน แต่ความประทับใจแรกนั้นดีมาก ฉันอยากใช้คลัสเตอร์ Kubernetes ของตัวเองมากกว่า Heroku เพราะมีความอิสระมากกว่าและได้เรียนรู้สิ่งใหม่ๆ เนื่องจาก Linstor ติดตั้งไม่ง่ายเหมือนตัวอื่นๆ ฉันจะเขียนบทความเกี่ยวกับเรื่องนี้ในเร็วๆ นี้
เกณฑ์มาตรฐาน
น่าเสียดายที่ฉันไม่ได้จดบันทึกการเปรียบเทียบไว้มากนักเพราะฉันไม่คิดว่าจะเขียนถึงการเปรียบเทียบนั้น ฉันมีเพียงผลลัพธ์จากการวัดประสิทธิภาพ fio พื้นฐานและสำหรับคลัสเตอร์โหนดเดียวเท่านั้น ดังนั้นฉันจึงยังไม่มีตัวเลขสำหรับการกำหนดค่าที่จำลองแบบ แต่จากผลลัพธ์เหล่านี้ คุณสามารถเข้าใจคร่าวๆ ได้ว่าคาดหวังอะไรจากแต่ละตัวเลือก เพราะฉันเปรียบเทียบพวกมันบนเซิร์ฟเวอร์คลาวด์เดียวกัน 4 คอร์ RAM 16 GB พร้อมดิสก์เพิ่มเติม 100 GB สำหรับโวลุ่มที่ทดสอบ ฉันรันการวัดประสิทธิภาพสามครั้งสำหรับแต่ละโซลูชันและคำนวณผลลัพธ์โดยเฉลี่ย พร้อมทั้งรีเซ็ตการตั้งค่าเซิร์ฟเวอร์สำหรับแต่ละผลิตภัณฑ์ ทั้งหมดนี้ไม่มีหลักวิทยาศาสตร์เลย เพียงเพื่อให้คุณมีแนวคิดทั่วไป ในการทดสอบอื่นๆ ฉันคัดลอกรูปภาพและวิดีโอขนาด 38 GB จากเล่มนี้เพื่อทดสอบการอ่านและการเขียน แต่น่าเสียดายที่ฉันไม่ได้บันทึกตัวเลขไว้ กล่าวโดยย่อ: Portworkx เร็วกว่ามาก
สำหรับการวัดประสิทธิภาพปริมาณ ฉันใช้รายการนี้:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4ขั้นแรก ฉันสร้างวอลลุมที่มีคลาสพื้นที่จัดเก็บที่เหมาะสม จากนั้นจึงรันงานกับ fio เบื้องหลัง ฉันใช้เวลา 1 GB เพื่อประเมินประสิทธิภาพและไม่ต้องรอนานเกินไป นี่คือผลลัพธ์:
ฉันได้ไฮไลต์ค่าที่ดีที่สุดสำหรับแต่ละเมตริกด้วยสีเขียวและค่าที่แย่ที่สุดเป็นสีแดง
ข้อสรุป
อย่างที่คุณเห็น ในกรณีส่วนใหญ่ Portworx ทำงานได้ดีกว่าตัวอื่น แต่สำหรับฉันมันแพง ฉันไม่รู้ว่า Robin มีราคาเท่าไหร่ แต่มีเวอร์ชันฟรีที่ยอดเยี่ยม ดังนั้นหากคุณต้องการผลิตภัณฑ์แบบชำระเงิน คุณสามารถลองใช้ได้ (หวังว่าพวกเขาจะแก้ไขปัญหาด้วยการคืนค่าและการสำรองข้อมูลในเร็วๆ นี้) จากโปรแกรมฟรีทั้งสามตัว ฉันมีปัญหาน้อยที่สุดกับ OpenEBS แต่ประสิทธิภาพของมันต่ำมาก น่าเสียดายที่ฉันไม่ได้บันทึกผลลัพธ์เพิ่มเติม แต่ฉันหวังว่าตัวเลขและความคิดเห็นของฉันจะช่วยคุณได้
ที่มา: will.com
