การเปรียบเทียบโดยสังเขปของสถาปัตยกรรม SDS หรือการค้นหาแพลตฟอร์มการจัดเก็บข้อมูลที่เหมาะสม (GlusterVsCephVsVirtuozzoStorage)

บทความนี้เขียนขึ้นเพื่อช่วยคุณเลือกโซลูชันที่เหมาะสมสำหรับตัวคุณเอง และเข้าใจความแตกต่างระหว่าง SDS เช่น Gluster, Ceph และ Vstorage (Virtuozzo)

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

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

แวววาว

เริ่มจาก Gluster ซึ่งผู้ผลิตแพลตฟอร์มไฮเปอร์คอนเวิร์จใช้งานอย่างแข็งขันด้วย SDS ที่ใช้โอเพ่นซอร์สสำหรับสภาพแวดล้อมเสมือน และสามารถพบได้บนเว็บไซต์ RedHat ในส่วนพื้นที่เก็บข้อมูล ซึ่งคุณสามารถเลือกจากตัวเลือก SDS สองตัวเลือก: Gluster หรือ Ceph

Gluster ประกอบด้วยนักแปลจำนวนมาก - บริการที่ทำหน้าที่กระจายไฟล์ทั้งหมด ฯลฯ Brick เป็นบริการที่ให้บริการดิสก์หนึ่งดิสก์ Volume คือโวลุ่ม (พูล) ที่รวมอิฐเหล่านี้เข้าด้วยกัน ถัดมาคือบริการสำหรับการกระจายไฟล์ออกเป็นกลุ่มโดยใช้ฟังก์ชัน DHT (distributed hash table) เราจะไม่รวมบริการ Sharding ไว้ในคำอธิบาย เนื่องจากลิงก์ด้านล่างจะอธิบายปัญหาที่เกี่ยวข้อง

เมื่อเขียน ไฟล์ทั้งหมดจะถูกจัดเก็บไว้ใน Brick และสำเนาของไฟล์จะถูกเขียนไปยัง Brick บนเซิร์ฟเวอร์ตัวที่สองพร้อมกัน ถัดไป ไฟล์ที่สองจะถูกเขียนไปยังกลุ่มที่สองของสองอิฐ (หรือมากกว่า) บนเซิร์ฟเวอร์ที่แตกต่างกัน

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

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

จากคำอธิบายอย่างเป็นทางการ สถาปัตยกรรม นอกจากนี้เรายังเข้าใจโดยไม่ได้ตั้งใจว่า Gluster ทำงานเป็นที่จัดเก็บไฟล์นอกเหนือจาก RAID ฮาร์ดแวร์แบบคลาสสิก มีความพยายามในการพัฒนาที่จะตัด (Sharding) ไฟล์ลงในบล็อก แต่ทั้งหมดนี้เป็นส่วนเสริมที่ทำให้เกิดการสูญเสียประสิทธิภาพในแนวทางสถาปัตยกรรมที่มีอยู่แล้ว บวกกับการใช้ส่วนประกอบที่กระจายอย่างอิสระดังกล่าวโดยมีข้อจำกัดด้านประสิทธิภาพเช่น Fuse ไม่มีบริการข้อมูลเมตาซึ่งจะจำกัดประสิทธิภาพและความสามารถในการยอมรับข้อผิดพลาดของพื้นที่จัดเก็บข้อมูลเมื่อกระจายไฟล์ลงในบล็อก ตัวบ่งชี้ประสิทธิภาพที่ดีขึ้นสามารถสังเกตได้ด้วยการกำหนดค่า "Distributed Replicated" และจำนวนโหนดควรมีอย่างน้อย 6 เพื่อจัดระเบียบแบบจำลอง 3 ที่เชื่อถือได้พร้อมการกระจายโหลดที่เหมาะสมที่สุด

การค้นพบเหล่านี้ยังเกี่ยวข้องกับคำอธิบายประสบการณ์ผู้ใช้ด้วย แวววาว และเมื่อเปรียบเทียบกับ Cephและยังมีคำอธิบายประสบการณ์ที่นำไปสู่ความเข้าใจในการกำหนดค่าที่มีประสิทธิผลมากขึ้นและเชื่อถือได้มากขึ้นอีกด้วย “การจำลองแบบกระจาย”


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

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

นอกจากนี้ยังมีตัวบ่งชี้ประสิทธิภาพของ Gluster บางตัวที่สามารถทำได้ภายใต้เงื่อนไขบางประการ ซึ่งจำกัดอยู่เพียงเท่านั้น ความอดทนต่อความผิดพลาด

Ceph

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

สถาปัตยกรรม เซ็ฟ ซับซ้อนกว่า Gluster และมีบริการต่างๆ เช่น บริการข้อมูลเมตา แต่สแต็กส่วนประกอบทั้งหมดค่อนข้างซับซ้อนและไม่ยืดหยุ่นมากนักสำหรับการใช้ในโซลูชันเวอร์ชวลไลเซชัน ข้อมูลจะถูกจัดเก็บไว้ในบล็อกซึ่งดูมีประสิทธิผลมากขึ้น แต่ในลำดับชั้นของบริการทั้งหมด (ส่วนประกอบ) จะมีการสูญเสียและเวลาแฝงภายใต้โหลดและเงื่อนไขฉุกเฉินบางอย่าง เช่น บทความ.

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

คลัสเตอร์สามารถมีหนึ่งหรือหลายกลุ่มข้อมูลเพื่อวัตถุประสงค์ที่แตกต่างกันและมีการตั้งค่าที่แตกต่างกัน พูลแบ่งออกเป็นกลุ่มตำแหน่ง กลุ่มตำแหน่งจัดเก็บออบเจ็กต์ที่ลูกค้าเข้าถึง นี่คือจุดที่ระดับลอจิคัลสิ้นสุด และระดับฟิสิคัลเริ่มต้นขึ้น เนื่องจากกลุ่มการจัดวางแต่ละกลุ่มถูกกำหนดดิสก์หลักหนึ่งดิสก์และดิสก์เรพลิกาหลายรายการ (จำนวนเท่าใดขึ้นอยู่กับปัจจัยการจำลองแบบพูล) กล่าวอีกนัยหนึ่งในระดับลอจิคัลออบเจ็กต์จะถูกจัดเก็บไว้ในกลุ่มตำแหน่งเฉพาะและที่ระดับฟิสิคัล - บนดิสก์ที่ได้รับมอบหมาย ในกรณีนี้ ดิสก์สามารถอยู่ในตำแหน่งทางกายภาพบนโหนดที่แตกต่างกัน หรือแม้แต่ในศูนย์ข้อมูลที่ต่างกัน

ในรูปแบบนี้ กลุ่มตำแหน่งดูเหมือนเป็นระดับที่จำเป็นสำหรับความยืดหยุ่นของโซลูชันทั้งหมด แต่ในขณะเดียวกัน ก็เป็นเหมือนลิงก์พิเศษในสายโซ่นี้ ซึ่งบ่งบอกถึงการสูญเสียประสิทธิภาพการทำงานโดยไม่ได้ตั้งใจ ตัวอย่างเช่น เมื่อเขียนข้อมูล ระบบจำเป็นต้องแบ่งข้อมูลออกเป็นกลุ่มเหล่านี้ จากนั้นในระดับฟิสิคัลลงในดิสก์หลักและดิสก์สำหรับแบบจำลอง นั่นคือฟังก์ชันแฮชทำงานเมื่อค้นหาและแทรกวัตถุ แต่มีผลข้างเคียง - มีค่าใช้จ่ายและข้อ จำกัด สูงมากในการสร้างแฮชใหม่ (เมื่อเพิ่มหรือลบดิสก์) ปัญหาแฮชอีกประการหนึ่งคือตำแหน่งของข้อมูลที่ชัดเจนซึ่งไม่สามารถเปลี่ยนแปลงได้ นั่นคือหากดิสก์อยู่ภายใต้ภาระที่เพิ่มขึ้นระบบจะไม่มีโอกาสที่จะไม่เขียนลงไป (โดยการเลือกดิสก์อื่น) ฟังก์ชันแฮชจะบังคับให้ข้อมูลอยู่ในตำแหน่งตามกฎไม่ว่าจะแย่แค่ไหนก็ตาม ดิสก์เป็นเช่นนั้น ดังนั้น Ceph จึงกินหน่วยความจำจำนวนมากเมื่อสร้าง PG ขึ้นมาใหม่ ในกรณีของการซ่อมแซมตัวเองหรือเพิ่มพื้นที่จัดเก็บข้อมูล ข้อสรุปก็คือ Ceph ทำงานได้ดี (แม้ว่าจะช้าก็ตาม) แต่เมื่อไม่มีการปรับขนาด สถานการณ์ฉุกเฉิน หรือการอัปเดตเท่านั้น

แน่นอนว่ามีตัวเลือกสำหรับการเพิ่มประสิทธิภาพผ่านการแคชและการแชร์แคช แต่ต้องใช้ฮาร์ดแวร์ที่ดีและยังคงสูญเสียอยู่ แต่โดยรวมแล้ว Ceph ดูน่าดึงดูดใจมากกว่า Gluster ในด้านประสิทธิภาพการทำงาน นอกจากนี้ เมื่อใช้ผลิตภัณฑ์เหล่านี้ จำเป็นต้องคำนึงถึงปัจจัยสำคัญด้วย - นี่คือความสามารถ ประสบการณ์ และความเป็นมืออาชีพในระดับสูงโดยเน้นที่ Linux เป็นอย่างยิ่ง เนื่องจากเป็นสิ่งสำคัญมากในการปรับใช้ กำหนดค่า และบำรุงรักษาทุกอย่างถูกต้อง ซึ่งทำให้ความรับผิดชอบและภาระของผู้บริหารเพิ่มมากขึ้น

Vstorage

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

สิ่งที่สามารถอยู่ร่วมกันในพื้นที่จัดเก็บได้ถัดจากบริการของไฮเปอร์ไวเซอร์ kvm-qemu และนี่เป็นเพียงบริการบางส่วนที่พบลำดับชั้นของส่วนประกอบที่เหมาะสมที่สุดที่กะทัดรัด: บริการลูกค้าที่ติดตั้งผ่าน FUSE (แก้ไข ไม่ใช่โอเพ่นซอร์ส) บริการข้อมูลเมตาของ MDS (บริการเมตาดาต้า) บริการบล็อกข้อมูลบริการ Chunk ซึ่งในระดับฟิสิคัลเท่ากับดิสก์เดียวเท่านั้น ในแง่ของความเร็ว แน่นอนว่า เป็นการดีที่สุดที่จะใช้รูปแบบที่ทนต่อข้อผิดพลาดกับสองแบบจำลอง แต่ถ้าคุณใช้แคชและบันทึกบนไดรฟ์ SSD การเข้ารหัสที่ทนทานต่อข้อผิดพลาด (ลบการเข้ารหัสหรือ raid6) ก็สามารถโอเวอร์คล็อกได้อย่างเหมาะสมบน รูปแบบไฮบริดหรือดียิ่งขึ้นในแฟลชทั้งหมด มีข้อเสียบางประการกับ EC (ลบการเข้ารหัส): เมื่อเปลี่ยนบล็อกข้อมูลหนึ่งบล็อกจำเป็นต้องคำนวณจำนวนพาริตีใหม่ เพื่อหลีกเลี่ยงความสูญเสียที่เกี่ยวข้องกับการดำเนินการนี้ Ceph เขียนถึง EC โดยเลื่อนออกไป และปัญหาด้านประสิทธิภาพอาจเกิดขึ้นได้ในระหว่างการร้องขอบางอย่าง ตัวอย่างเช่น เมื่อจำเป็นต้องอ่านบล็อกทั้งหมด และในกรณีของ Virtuozzo Storage การเขียนบล็อกที่เปลี่ยนแปลงจะดำเนินการ โดยใช้แนวทาง "ระบบไฟล์ที่มีโครงสร้างบันทึก" ซึ่งช่วยลดต้นทุนการคำนวณพาริตีให้เหลือน้อยที่สุด ในการประมาณตัวเลือกโดยประมาณด้วยความเร่งในการทำงานโดยมีและไม่มี EC มีอยู่ เครื่องคิดเลข – ตัวเลขสามารถประมาณได้ขึ้นอยู่กับค่าสัมประสิทธิ์ความแม่นยำของผู้ผลิตอุปกรณ์ แต่ผลลัพธ์ของการคำนวณจะช่วยได้ดีในการวางแผนการกำหนดค่า

แผนผังง่ายๆ ของส่วนประกอบในการจัดเก็บไม่ได้หมายความว่าส่วนประกอบเหล่านี้ไม่ดูดซับ ทรัพยากรเหล็ก แต่หากคุณคำนวณต้นทุนทั้งหมดล่วงหน้า คุณสามารถไว้วางใจในการทำงานร่วมกันถัดจากไฮเปอร์ไวเซอร์ได้
มีแผนการเปรียบเทียบการใช้ทรัพยากรฮาร์ดแวร์โดยบริการจัดเก็บข้อมูลของ Ceph และ Virtuozzo

หากก่อนหน้านี้มีความเป็นไปได้ที่จะเปรียบเทียบ Gluster และ Ceph โดยใช้บทความเก่า ๆ โดยใช้บรรทัดที่สำคัญที่สุดจากนั้นกับ Virtuozzo จะยากกว่า มีบทความไม่มากเกี่ยวกับผลิตภัณฑ์นี้และข้อมูลสามารถรวบรวมได้จากเอกสารประกอบเท่านั้น เป็นภาษาอังกฤษ หรือเป็นภาษารัสเซียหากเราถือว่า Vstorage เป็นที่เก็บข้อมูลที่ใช้ในโซลูชันไฮเปอร์คอนเวอร์จบางอย่างในบริษัทต่างๆ เช่น Rosplatforma และอะโครนิส

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

ลองพิจารณากระบวนการบันทึกในการกำหนดค่าฮาร์ดแวร์ไฮบริดด้วยส่วนประกอบที่อธิบายไว้ข้างต้น: การบันทึกจะเริ่มไปที่โหนดที่ไคลเอนต์เริ่มต้น (บริการจุดเชื่อมต่อ FUSE) แต่องค์ประกอบหลักของบริการข้อมูลเมตา (MDS) แน่นอน นำลูกค้าโดยตรงไปยังบริการก้อนที่ต้องการ (บล็อก CS บริการจัดเก็บข้อมูล) นั่นคือ MDS ไม่ได้มีส่วนร่วมในกระบวนการบันทึก แต่เพียงนำบริการไปยังก้อนที่ต้องการ โดยทั่วไปเราสามารถเปรียบเทียบการบันทึกด้วยการเทน้ำลงในถังได้ แต่ละบาร์เรลมีบล็อกข้อมูลขนาด 256MB

นั่นคือหนึ่งดิสก์คือจำนวนถังดังกล่าวนั่นคือปริมาตรดิสก์หารด้วย 256MB แต่ละสำเนาจะถูกแจกจ่ายไปยังโหนดหนึ่ง สำเนาที่สองเกือบจะขนานกับโหนดอื่น ฯลฯ... หากเรามีสามแบบจำลองและมีดิสก์ SSD สำหรับแคช (สำหรับการอ่านและการเขียนบันทึก) การยืนยันการเขียนจะเกิดขึ้นหลังจากการเขียน บันทึกไปยัง SSD และการรีเซ็ตแบบขนานจาก SSD จะดำเนินการต่อไปบน HDD ราวกับว่าอยู่ในพื้นหลัง ในกรณีที่มีการจำลองสามรายการ บันทึกจะถูกคอมมิตหลังจากการยืนยันจาก SSD ของโหนดที่สาม อาจดูเหมือนว่าผลรวมของความเร็วในการเขียนของ SSD สามตัวสามารถหารด้วยสามและเราจะได้ความเร็วในการเขียนของหนึ่งเรพลิกา แต่สำเนาจะถูกเขียนแบบขนานและความเร็วแฝงของเครือข่ายมักจะสูงกว่าความเร็วของ SSD และในความเป็นจริงประสิทธิภาพการเขียนจะขึ้นอยู่กับเครือข่าย ในเรื่องนี้ หากต้องการดู IOPS จริง คุณจะต้องโหลด Vstorage ทั้งหมดอย่างถูกต้อง วิธีการนั่นคือการทดสอบโหลดจริง ไม่ใช่หน่วยความจำและแคช โดยจำเป็นต้องคำนึงถึงขนาดบล็อกข้อมูล จำนวนเธรด ฯลฯ ที่ถูกต้อง

บันทึกการบันทึกที่กล่าวถึงข้างต้นบน SSD ทำงานในลักษณะที่ทันทีที่ข้อมูลเข้าสู่ข้อมูลบริการจะอ่านทันทีและเขียนลงใน HDD มีบริการข้อมูลเมตา (MDS) หลายอย่างต่อคลัสเตอร์ และจำนวนจะถูกกำหนดโดยองค์ประชุม ซึ่งทำงานตามอัลกอริทึม Paxos จากมุมมองของไคลเอ็นต์ จุดเมานต์ FUSE คือโฟลเดอร์จัดเก็บข้อมูลคลัสเตอร์ที่โหนดทั้งหมดในคลัสเตอร์มองเห็นพร้อมกัน แต่ละโหนดมีไคลเอ็นต์ที่เมานต์ตามหลักการนี้ ดังนั้นที่เก็บข้อมูลนี้จึงพร้อมใช้งานสำหรับแต่ละโหนด

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

โดยสรุป เราสามารถเน้นที่ด้านบนสุดของทั้งสาม: Virtuozzo Storage เกิดขึ้นที่หนึ่งในแง่ของประสิทธิภาพและความน่าเชื่อถือของสถาปัตยกรรม Ceph เกิดขึ้นที่สอง และ Gluster เกิดขึ้นที่สาม

เกณฑ์ในการเลือก Virtuozzo Storage: เป็นชุดส่วนประกอบทางสถาปัตยกรรมที่เหมาะสมที่สุด ซึ่งได้รับการปรับปรุงให้ทันสมัยสำหรับแนวทาง Fuse นี้ด้วยเส้นทางที่รวดเร็ว ชุดการกำหนดค่าฮาร์ดแวร์ที่ยืดหยุ่น การใช้ทรัพยากรน้อยลง และความสามารถในการแบ่งปันกับการคำนวณ (คอมพิวเตอร์/การจำลองเสมือน) นั่นคือมันเหมาะอย่างยิ่งสำหรับโซลูชันไฮเปอร์คอนเวิร์จ ซึ่งเขาเป็นส่วนหนึ่งของ อันดับที่สองคือ Ceph เนื่องจากเป็นสถาปัตยกรรมที่มีประสิทธิผลมากกว่าเมื่อเทียบกับ Gluster เนื่องจากการดำเนินการในบล็อก รวมถึงสถานการณ์ที่ยืดหยุ่นกว่าและความสามารถในการทำงานในคลัสเตอร์ขนาดใหญ่

มีแผนที่จะเขียนการเปรียบเทียบระหว่าง vSAN, Space Direct Storage, Vstorage และ Nutanix Storage, การทดสอบ Vstorage บนอุปกรณ์ HPE และ Huawei รวมถึงสถานการณ์จำลองสำหรับการบูรณาการ Vstorage เข้ากับระบบจัดเก็บข้อมูลฮาร์ดแวร์ภายนอก ดังนั้นหากคุณชอบบทความนี้ ก็คงเป็นเช่นนั้น ยินดีที่ได้รับคำติชมจากคุณ ซึ่งสามารถเพิ่มแรงจูงใจสำหรับบทความใหม่ ๆ โดยคำนึงถึงความคิดเห็นและความปรารถนาของคุณ

ที่มา: will.com