โซลูชันไฮเปอร์คอนเวอร์จ AERODISK vAIR พื้นฐานคือระบบไฟล์ ARDFS

สวัสดีผู้อ่าน Habr ในบทความนี้ เราจะเปิดซีรีส์ที่จะพูดถึงระบบไฮเปอร์คอนเวิร์จ AERODISK vAIR ที่เราพัฒนาขึ้น ในตอนแรกเราอยากจะเล่าทุกอย่างให้ฟังในบทความแรกแต่ระบบค่อนข้างซับซ้อนดังนั้นเราจึงจะกินช้างเป็นชิ้นๆ

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

ในบทความต่อๆ ไป เราจะพูดถึงรายละเอียดเพิ่มเติมเกี่ยวกับส่วนประกอบทางสถาปัตยกรรมต่างๆ (คลัสเตอร์ ไฮเปอร์ไวเซอร์ โหลดบาลานเซอร์ ระบบตรวจสอบ ฯลฯ) กระบวนการกำหนดค่า แจ้งปัญหาการออกใบอนุญาต แสดงการทดสอบข้อขัดข้องแยกกัน และแน่นอนว่าเขียนเกี่ยวกับการทดสอบโหลดและ การปรับขนาด นอกจากนี้เรายังจะอุทิศบทความแยกต่างหากให้กับ vAIR เวอร์ชันชุมชนด้วย

Aerodisk เป็นเรื่องราวเกี่ยวกับระบบจัดเก็บข้อมูลหรือไม่? หรือทำไมเราถึงเริ่มทำไฮเปอร์คอนเวอร์เจนซ์ตั้งแต่แรก?

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

เราได้ลองใช้วิธีแก้ปัญหาแบบโอเพ่นซอร์สมากมายและในที่สุดก็แก้ไขปัญหานี้ได้ แต่วิธีแก้ปัญหานั้นซับซ้อนมากและยากที่จะทำซ้ำ นอกจากนี้โซลูชันนี้ยังอยู่ในหมวดหมู่ “Does it work? อย่าสัมผัส! ดังนั้นเมื่อแก้ไขปัญหานั้นแล้วเราจึงไม่พัฒนาแนวคิดในการแปลงผลงานของเราให้เป็นผลิตภัณฑ์อย่างเต็มรูปแบบอีกต่อไป

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

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

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

แนวคิด vAIR แรก

เราจงใจละทิ้งการใช้โซลูชันโอเพ่นซอร์สสำเร็จรูปสำหรับการจัดระเบียบพื้นที่จัดเก็บข้อมูลแบบขยาย (ceph, gluster, luster และอื่นๆ ที่คล้ายคลึงกัน) เพื่อสนับสนุนการพัฒนาของเราเอง เนื่องจากเรามีประสบการณ์ในโครงการมากมายกับโซลูชันเหล่านี้แล้ว แน่นอนว่าโซลูชันเหล่านี้ก็ยอดเยี่ยม และก่อนที่จะทำงานกับ Aerodisk เราได้ดำเนินโครงการบูรณาการกับพวกเขามากกว่าหนึ่งโครงการ แต่การทำให้งานเฉพาะเจาะจงสำหรับลูกค้ารายหนึ่ง ฝึกอบรมพนักงาน และอาจซื้อการสนับสนุนจากผู้จำหน่ายรายใหญ่ถือเป็นเรื่องหนึ่ง และเป็นอีกเรื่องหนึ่งในการสร้างผลิตภัณฑ์ที่จำลองแบบได้ง่ายซึ่งจะใช้สำหรับงานต่างๆ ซึ่งเราในฐานะ ผู้ขายอาจจะรู้เกี่ยวกับตัวเราด้วยซ้ำเราจะไม่ เพื่อจุดประสงค์ที่สอง ผลิตภัณฑ์โอเพ่นซอร์สที่มีอยู่ไม่เหมาะสำหรับเรา ดังนั้นเราจึงตัดสินใจสร้างระบบไฟล์แบบกระจายด้วยตัวเอง
สองปีต่อมา นักพัฒนาหลายคน (ซึ่งรวมการทำงานบน vAIR เข้ากับระบบจัดเก็บข้อมูล Engine แบบคลาสสิก) บรรลุผลลัพธ์ที่แน่นอน

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

เราไม่ได้ใส่ใจกับชื่อของระบบไฟล์มากนัก และเรียกมันสั้นๆ ว่า ARDFS (ลองเดาดูสิว่ามันย่อมาจากอะไร)

ต้นแบบนี้ดูดี (แน่นอนว่ายังไม่มีรูปลักษณ์ แน่นอนว่ายังไม่มีการออกแบบด้านภาพ) และแสดงผลลัพธ์ที่ดีในแง่ของประสิทธิภาพและการปรับขนาด หลังจากผลลัพธ์ที่แท้จริงครั้งแรก เราได้เริ่มดำเนินโครงการนี้ โดยจัดสภาพแวดล้อมการพัฒนาที่ครบครันและทีมแยกต่างหากที่เกี่ยวข้องกับ vAIR เท่านั้น

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

เจาะลึกระบบไฟล์ ARDFS

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

โครงสร้างการจัดเก็บ

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

ดิสก์เสมือน (ออบเจ็กต์การจัดเก็บข้อมูลสำหรับเครื่องเสมือน) จะถูกเพิ่มที่ด้านบนของพูล ARDFS ซึ่งสร้างขึ้นจากบล็อกเสมือนขนาด 4 เมกะไบต์ ดิสก์เสมือนจัดเก็บข้อมูลโดยตรง นอกจากนี้โครงร่างการยอมรับข้อบกพร่องยังถูกตั้งค่าที่ระดับดิสก์เสมือนอีกด้วย

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

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

แผนการยอมรับข้อผิดพลาดในการจัดเก็บ

สามารถมีรูปแบบการยอมรับข้อผิดพลาดได้สองแบบสำหรับดิสก์เสมือนใน vAIR:

1) ปัจจัยการจำลองหรือเพียงแค่การจำลอง - วิธีการทนต่อข้อผิดพลาดนี้ทำได้ง่ายเพียงแค่ใช้ไม้และเชือก การจำลองแบบซิงโครนัสจะดำเนินการระหว่างโหนดที่มีปัจจัย 2 (2 สำเนาต่อคลัสเตอร์) หรือ 3 (3 สำเนา ตามลำดับ) RF-2 อนุญาตให้ดิสก์เสมือนทนทานต่อความล้มเหลวของโหนดหนึ่งในคลัสเตอร์ แต่ "กิน" ครึ่งหนึ่งของปริมาตรที่มีประโยชน์ และ RF-3 จะทนต่อความล้มเหลวของ 2 โหนดในคลัสเตอร์ แต่สงวนไว้ 2/3 ของ ปริมาณที่มีประโยชน์ตามความต้องการ รูปแบบนี้คล้ายกับ RAID-1 มาก กล่าวคือ ดิสก์เสมือนที่กำหนดค่าใน RF-2 สามารถต้านทานความล้มเหลวของโหนดใดโหนดหนึ่งในคลัสเตอร์ได้ ในกรณีนี้ ข้อมูลทุกอย่างจะเรียบร้อยดี และแม้แต่ I/O ก็จะไม่หยุดทำงาน เมื่อโหนดที่เสียหายกลับมาให้บริการ การกู้คืน/การซิงโครไนซ์ข้อมูลอัตโนมัติจะเริ่มต้นขึ้น

ด้านล่างนี้เป็นตัวอย่างการกระจายข้อมูล RF-2 และ RF-3 ในโหมดปกติและในสถานการณ์ที่ล้มเหลว

เรามีเครื่องเสมือนที่มีความจุข้อมูล (มีประโยชน์) ที่ไม่ซ้ำใคร 8MB ซึ่งทำงานบนโหนด 4 vAIR เห็นได้ชัดว่าในความเป็นจริงไม่น่าเป็นไปได้ที่จะมีปริมาณน้อยเช่นนี้ แต่สำหรับโครงการที่สะท้อนถึงตรรกะของการดำเนินงาน ARDFS ตัวอย่างนี้เป็นสิ่งที่เข้าใจได้มากที่สุด AB คือบล็อกเสมือนขนาด 4MB ที่มีข้อมูลเครื่องเสมือนเฉพาะ RF-2 สร้างสำเนาสองชุดของบล็อกเหล่านี้ A1+A2 และ B1+B2 ตามลำดับ บล็อกเหล่านี้ "วาง" ข้ามโหนด โดยหลีกเลี่ยงการตัดกันของข้อมูลเดียวกันบนโหนดเดียวกัน กล่าวคือ สำเนา A1 จะไม่อยู่บนโหนดเดียวกันกับสำเนา A2 เช่นเดียวกับ B1 และ B2

หากโหนดใดโหนดหนึ่งล้มเหลว (เช่น โหนดหมายเลข 3 ซึ่งมีสำเนาของ B1) สำเนานี้จะถูกเปิดใช้งานโดยอัตโนมัติบนโหนดที่ไม่มีสำเนาของสำเนานั้น (นั่นคือ สำเนาของ B2)

ดังนั้นดิสก์เสมือน (และ VM ตามลำดับ) สามารถอยู่รอดได้อย่างง่ายดายจากความล้มเหลวของโหนดเดียวในรูปแบบ RF-2

รูปแบบการจำลองแบบแม้จะเรียบง่ายและเชื่อถือได้ แต่ก็ประสบปัญหาเดียวกันกับ RAID1 ซึ่งมีเนื้อที่ไม่เพียงพอ

2) การลบโค้ดหรือการลบโค้ด (หรือที่เรียกว่า "การเข้ารหัสซ้ำซ้อน", "การเข้ารหัสการลบ" หรือ "โค้ดซ้ำซ้อน") มีอยู่เพื่อแก้ไขปัญหาข้างต้น EC เป็นรูปแบบความซ้ำซ้อนที่ให้ความพร้อมใช้งานของข้อมูลสูงโดยมีค่าใช้จ่ายพื้นที่ดิสก์ต่ำกว่าเมื่อเทียบกับการจำลองแบบ หลักการทำงานของกลไกนี้คล้ายกับ RAID 5, 6, 6P

เมื่อเข้ารหัส กระบวนการ EC จะแบ่งบล็อกเสมือน (4MB ตามค่าเริ่มต้น) ออกเป็น "ส่วนข้อมูล" ขนาดเล็กหลาย ๆ ส่วน ขึ้นอยู่กับโครงร่าง EC (เช่น รูปแบบ 2+1 จะแบ่งแต่ละบล็อกขนาด 4MB ออกเป็นชิ้นขนาด 2MB 2 ชิ้น) จากนั้น กระบวนการนี้จะสร้าง "ชิ้นส่วนที่เท่าเทียมกัน" สำหรับ "ชิ้นส่วนข้อมูล" ที่ไม่ใหญ่ไปกว่าส่วนที่แบ่งออกก่อนหน้านี้ เมื่อถอดรหัส EC จะสร้างส่วนที่ขาดหายไปโดยการอ่านข้อมูล “ที่ยังคงอยู่” ทั่วทั้งคลัสเตอร์

ตัวอย่างเช่นดิสก์เสมือนที่มีรูปแบบ 2 + 1 EC ซึ่งใช้งานบนโหนดคลัสเตอร์ 4 โหนดจะทนต่อความล้มเหลวของโหนดเดียวในคลัสเตอร์ในลักษณะเดียวกับ RF-2 ได้อย่างง่ายดาย ในกรณีนี้ ต้นทุนค่าโสหุ้ยจะลดลง โดยเฉพาะอย่างยิ่งค่าสัมประสิทธิ์กำลังการผลิตที่มีประโยชน์สำหรับ RF-2 คือ 2 และสำหรับ EC 2+1 จะเป็น 1,5

เพื่ออธิบายให้ง่ายขึ้น สิ่งสำคัญคือบล็อกเสมือนแบ่งออกเป็น 2-8 (ทำไมจาก 2 ถึง 8 ดูด้านล่าง) "ชิ้นส่วน" และสำหรับชิ้นส่วนเหล่านี้ "ชิ้นส่วน" ของความเท่าเทียมกันของปริมาตรที่คล้ายกันจะถูกคำนวณ

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

ด้านล่างนี้คือตัวอย่างที่มีเครื่องเสมือน 8 MB และ 4 โหนดเหมือนกัน แต่มีรูปแบบ EC 2+1

บล็อก A และ B แบ่งออกเป็นสองส่วน ชิ้นละ 2 MB (สองชิ้นเพราะ 2+1) นั่นคือ A1+A2 และ B1+B2 ต่างจากแบบจำลองตรงที่ A1 ไม่ใช่สำเนาของ A2 แต่เป็นบล็อกเสมือน A ซึ่งแบ่งออกเป็นสองส่วนเหมือนกับบล็อก B โดยรวมแล้วเราได้รับ 4MB สองชุด แต่ละชุดประกอบด้วยสองชิ้น 2-MB ถัดไป สำหรับแต่ละชุดเหล่านี้ ความเท่าเทียมกันจะถูกคำนวณด้วยปริมาตรไม่เกินหนึ่งชิ้น (เช่น 2 MB) เราจะได้ความเท่าเทียมกันเพิ่มเติม + 4 ชิ้น (AP และ BP) โดยรวมแล้วเรามีข้อมูล 2×2 + ความเท่าเทียมกัน 2×XNUMX

ถัดไป ชิ้นส่วนต่างๆ จะถูก "จัดวาง" ไว้ระหว่างโหนดต่างๆ เพื่อไม่ให้ข้อมูลตัดกันกับความเท่าเทียมกัน เหล่านั้น. A1 และ A2 จะไม่อยู่บนโหนดเดียวกันกับ AP

ในกรณีที่เกิดความล้มเหลวของโหนดหนึ่ง (เช่น โหนดที่สามด้วย) บล็อกที่ล้ม B1 จะถูกกู้คืนโดยอัตโนมัติจากความเท่าเทียมกันของ BP ซึ่งถูกเก็บไว้ในโหนดหมายเลข 2 และจะถูกเปิดใช้งานบนโหนดที่มี ไม่มีความเท่าเทียมกัน B เช่น ชิ้นส่วนของบีพี ในตัวอย่างนี้ นี่คือโหนดหมายเลข 1

ฉันแน่ใจว่าผู้อ่านมีคำถาม:

“ทุกสิ่งที่คุณอธิบายได้รับการนำไปใช้มานานแล้วทั้งโดยคู่แข่งและในโซลูชันโอเพ่นซอร์ส อะไรคือความแตกต่างระหว่างการใช้งาน EC ใน ARDFS ของคุณ”

แล้วจะมีฟีเจอร์ที่น่าสนใจของ ARDFS มาฝากครับ

ลบการเข้ารหัสโดยเน้นที่ความยืดหยุ่น

ในตอนแรก เราได้จัดเตรียมรูปแบบ EC X+Y ที่ยืดหยุ่นพอสมควร โดยที่ X เท่ากับตัวเลขตั้งแต่ 2 ถึง 8 และ Y เท่ากับตัวเลขตั้งแต่ 1 ถึง 8 แต่จะน้อยกว่าหรือเท่ากับ X เสมอ โครงร่างนี้มีให้ไว้ เพื่อความยืดหยุ่น การเพิ่มจำนวนชิ้นข้อมูล (X) ซึ่งแบ่งบล็อกเสมือนจะช่วยลดต้นทุนค่าโสหุ้ย ซึ่งก็คือการเพิ่มพื้นที่ใช้สอย
การเพิ่มจำนวนชิ้นพาริตี (Y) เพิ่มความน่าเชื่อถือของดิสก์เสมือน ยิ่งค่า Y มากขึ้น โหนดในคลัสเตอร์ก็จะล้มเหลวมากขึ้นเท่านั้น แน่นอนว่าการเพิ่มปริมาณพาริตีจะลดปริมาณความจุที่ใช้งานได้ แต่นี่เป็นราคาที่ต้องจ่ายสำหรับความน่าเชื่อถือ

การพึ่งพาประสิทธิภาพของวงจร EC แทบจะเป็นไปโดยตรง ยิ่ง "ชิ้นส่วน" ยิ่งมาก ประสิทธิภาพก็จะยิ่งต่ำลง แน่นอนว่า จำเป็นต้องมีมุมมองที่สมดุลที่นี่

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

ด้านล่างนี้เป็นตารางเปรียบเทียบโครงร่าง RF และ EC หลายแบบ (อาจเป็นไปไม่ได้ทั้งหมด)

ตารางแสดงให้เห็นว่าแม้แต่การรวมกันแบบ "เทอร์รี่" ที่สุด EC 8+7 ซึ่งช่วยให้สูญเสียโหนดได้สูงสุด 7 โหนดในคลัสเตอร์พร้อมกัน "กิน" พื้นที่ใช้งานน้อยกว่า (1,875 เทียบกับ 2) กว่าการจำลองแบบมาตรฐาน และปกป้องได้ดีกว่า 7 เท่า ซึ่งทำให้กลไกการป้องกันนี้แม้ว่าจะซับซ้อนกว่า แต่ก็น่าดึงดูดยิ่งขึ้นในสถานการณ์ที่จำเป็นเพื่อให้มั่นใจถึงความน่าเชื่อถือสูงสุดในสภาพพื้นที่ดิสก์ที่จำกัด ในเวลาเดียวกัน คุณต้องเข้าใจว่าทุกๆ "บวก" ของ X หรือ Y จะเป็นค่าใช้จ่ายด้านประสิทธิภาพเพิ่มเติม ดังนั้น ในรูปสามเหลี่ยมระหว่างความน่าเชื่อถือ การประหยัด และประสิทธิภาพ คุณต้องเลือกอย่างระมัดระวัง ด้วยเหตุนี้ เราจะเขียนบทความแยกต่างหากเพื่อลบขนาดการเข้ารหัส

ความน่าเชื่อถือและความเป็นอิสระของระบบไฟล์

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

แน่นอนว่าการซิงโครไนซ์ข้อมูลเมตา FS โดยใช้ DBMS ภายนอกนั้นเป็นวิธีแก้ปัญหาที่ใช้งานได้ แต่จากนั้นความสอดคล้องของข้อมูลที่จัดเก็บไว้ใน ARDFS จะขึ้นอยู่กับ DBMS ภายนอกและพฤติกรรมของมัน (และพูดตามตรง มันเป็นผู้หญิงที่ไม่แน่นอน) ซึ่งใน ความคิดเห็นของเราไม่ดี ทำไม หากข้อมูลเมตา FS ได้รับความเสียหาย ตัวข้อมูล FS เองก็อาจกล่าวได้ว่า “ลาก่อน” ดังนั้นเราจึงตัดสินใจใช้เส้นทางที่ซับซ้อนมากขึ้นแต่เชื่อถือได้

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

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

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

ใครต้องการปาฏิหาริย์นี้?

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

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

เมื่อใดระบบจัดเก็บข้อมูลจะดีกว่า GCS

ในขณะที่เราทำงานร่วมกับตลาด เรามักถูกถามว่าเมื่อใดควรใช้รูปแบบคลาสสิกกับระบบจัดเก็บข้อมูล และเมื่อใดควรใช้ไฮเปอร์คอนเวอร์เจนท์ บริษัทหลายแห่งที่ผลิต GCS (โดยเฉพาะบริษัทที่ไม่มีระบบจัดเก็บข้อมูลในผลงาน) กล่าวว่า "ระบบจัดเก็บข้อมูลกำลังล้าสมัย มีเฉพาะไฮเปอร์คอนเวิร์จเท่านั้น!" นี่เป็นข้อความที่เป็นตัวหนา แต่ก็ไม่ได้สะท้อนถึงความเป็นจริงทั้งหมด

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

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

ประการที่สอง โครงสร้างพื้นฐานที่กำลังถูกสร้างขึ้นเป็นส่วนใหญ่ (หมายถึงสหพันธรัฐรัสเซีย) ถูกสร้างขึ้นตามรูปแบบคลาสสิกโดยใช้ระบบจัดเก็บข้อมูล ไม่ใช่เพราะผู้คนไม่รู้เกี่ยวกับไฮเปอร์คอนเวอร์เจนซ์ แต่เป็นเพราะตลาดไฮเปอร์คอนเวอร์เจนซ์เป็นของใหม่ โซลูชั่นและ ยังไม่มีการกำหนดมาตรฐาน คนไอทียังไม่ได้รับการฝึกอบรม พวกเขามีประสบการณ์น้อย แต่จำเป็นต้องสร้างศูนย์ข้อมูลที่นี่และเดี๋ยวนี้ และกระแสนี้จะคงอยู่ต่อไปอีก 3-5 ปี (และต่อมาคือมรดกอีกประการหนึ่ง ดูจุดที่ 1)

ประการที่สาม มีข้อจำกัดทางเทคนิคล้วนๆ เกี่ยวกับความล่าช้าเล็กน้อยเพิ่มเติมอีก 2 มิลลิวินาทีต่อการเขียน (ไม่รวมแคชในเครื่อง) ซึ่งเป็นต้นทุนของพื้นที่จัดเก็บแบบกระจาย

อย่าลืมเกี่ยวกับการใช้ฟิสิคัลเซิร์ฟเวอร์ขนาดใหญ่ที่ชอบการปรับขนาดแนวตั้งของระบบย่อยของดิสก์

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

และโซลูชั่นไฮเปอร์คอนเวิร์จจะทำงานได้ดีกว่าระบบจัดเก็บข้อมูลที่ไหน?

จากประเด็นข้างต้น สามารถสรุปได้ชัดเจนสามประการ:

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

โซลูชั่นเหล่านี้คืออะไร?

1. บริการโครงสร้างพื้นฐานมาตรฐานทั้งหมด (บริการไดเรกทอรี เมล EDMS เซิร์ฟเวอร์ไฟล์ ระบบ ERP และ BI ขนาดเล็กหรือขนาดกลาง ฯลฯ) เราเรียกสิ่งนี้ว่า "การประมวลผลทั่วไป"
2. โครงสร้างพื้นฐานของผู้ให้บริการคลาวด์ ซึ่งจำเป็นต้องขยายในแนวนอนอย่างรวดเร็วและเป็นมาตรฐานและ "ตัด" เครื่องเสมือนจำนวนมากสำหรับลูกค้าได้อย่างง่ายดาย
3. โครงสร้างพื้นฐานเดสก์ท็อปเสมือน (VDI) ซึ่งเครื่องเสมือนของผู้ใช้ขนาดเล็กจำนวนมากทำงานและ "ลอย" อย่างเงียบ ๆ ภายในคลัสเตอร์ที่เหมือนกัน
4. เครือข่ายสาขา ซึ่งแต่ละสาขาต้องการโครงสร้างพื้นฐานมาตรฐาน ทนทานต่อข้อผิดพลาด แต่มีราคาไม่แพงสำหรับเครื่องเสมือน 15-20 เครื่อง
5. คอมพิวเตอร์แบบกระจายใดๆ (เช่น บริการข้อมูลขนาดใหญ่) โดยที่ภาระไม่ได้ไป "เชิงลึก" แต่เป็น "ความกว้าง"
6. สภาพแวดล้อมการทดสอบที่ยอมรับความล่าช้าเล็กน้อยเพิ่มเติมได้ แต่มีข้อจำกัดด้านงบประมาณ เนื่องจากสิ่งเหล่านี้เป็นการทดสอบ

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

ดังนั้น…

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

เรายินดีรับฟังคำถาม ข้อเสนอแนะ และข้อโต้แย้งที่สร้างสรรค์

ที่มา: will.com