ผู้ดูแลระบบแบบแฮนด์ฟรี = ไฮเปอร์คอนเวอร์เจนซ์?

ผู้ดูแลระบบแบบแฮนด์ฟรี = ไฮเปอร์คอนเวอร์เจนซ์?
ผู้ดูแลระบบแบบแฮนด์ฟรี = ไฮเปอร์คอนเวอร์เจนซ์?

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

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

ปรากฎว่าคุณจ่ายเพิ่มขึ้น 10–15% เพื่อความสะดวกในการติดตั้ง นี่คือสิ่งที่จุดประกายตำนานในชื่อ เราใช้เวลานานในการมองหาว่าเทคโนโลยีจะถูกนำมาใช้อย่างเหมาะสมที่สุดที่ใด และเราพบมัน ความจริงก็คือ Cisco ไม่มีระบบจัดเก็บข้อมูลของตัวเอง แต่พวกเขาต้องการตลาดเซิร์ฟเวอร์ที่สมบูรณ์ และพวกเขาสร้าง Cisco Hyperflex ซึ่งเป็นโซลูชันที่มีพื้นที่จัดเก็บในตัวเครื่องบนโหนด

และทันใดนั้นก็กลายเป็นทางออกที่ดีมากสำหรับศูนย์ข้อมูลสำรอง (Disaster Recovery) ฉันจะบอกคุณว่าทำไมและอย่างไรตอนนี้ และฉันจะแสดงการทดสอบคลัสเตอร์ให้คุณดู

ในกรณีที่จำเป็น

ไฮเปอร์คอนเวอร์เจนซ์คือ:

  1. การถ่ายโอนดิสก์ไปยังโหนดคอมพิวเตอร์
  2. การรวมระบบย่อยการจัดเก็บข้อมูลเข้ากับระบบย่อยการจำลองเสมือนโดยสมบูรณ์
  3. การถ่ายโอน/บูรณาการกับระบบย่อยเครือข่าย

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

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

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

ดังนั้น ตอนนี้ผมจะพูดถึงการออกแบบและการทดสอบระบบ และจากนั้นเกี่ยวกับสถานการณ์การใช้งานจริง XNUMX-XNUMX สถานการณ์พร้อมข้อมูลที่ประหยัด

การทดสอบ

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

การเปลี่ยนแปลงในเวอร์ชัน 4ข้อบกพร่องจำนวนหนึ่งได้รับการแก้ไขแล้ว

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

ตอนนี้ปัญหาในวัยเด็กทั้งหมดได้รับการแก้ไขแล้ว HyperFlex สามารถรองรับทั้ง ESXi และ Hyper-V อีกทั้งยังสามารถ:

  1. การสร้างคลัสเตอร์แบบยืดออก
  2. การสร้างคลัสเตอร์สำหรับสำนักงานโดยไม่ต้องใช้ Fabric Interconnect จากสองถึงสี่โหนด (เราซื้อเซิร์ฟเวอร์เท่านั้น)
  3. ความสามารถในการทำงานกับระบบจัดเก็บข้อมูลภายนอก
  4. รองรับคอนเทนเนอร์และ Kubernetes
  5. การสร้างโซนความพร้อมใช้งาน
  6. บูรณาการกับ VMware SRM หากฟังก์ชันการทำงานภายในไม่เป็นที่น่าพอใจ

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

เราจะพิจารณาโซลูชันสำหรับ VMware เนื่องจากโซลูชันนี้ถูกสร้างขึ้นมาและมีฟังก์ชันการทำงานที่มากกว่า มีการเพิ่ม Hyper-V ไปพร้อมกันเพื่อให้ตามทันคู่แข่งและตอบสนองความคาดหวังของตลาด

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

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

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

บริการพิเศษ VM Cisco HyperFlex Data Platform controller ซึ่งสร้างขึ้นในแต่ละโหนดการจัดเก็บข้อมูล มีหน้าที่รับผิดชอบในตรรกะการดำเนินการทั้งหมดของระบบย่อยของดิสก์ ในการกำหนดค่า VM บริการของเรา มีการจัดสรร vCPU แปดตัวและ RAM ขนาด 72 GB ซึ่งถือว่าไม่น้อยนัก ฉันขอเตือนคุณว่าโฮสต์นั้นมีฟิสิคัลคอร์ 28 คอร์และ RAM 512 GB

บริการ VM สามารถเข้าถึงดิสก์จริงได้โดยตรงโดยการส่งต่อตัวควบคุม SAS ไปยัง VM การสื่อสารกับไฮเปอร์ไวเซอร์เกิดขึ้นผ่านโมดูลพิเศษ IOVisor ซึ่งขัดขวางการดำเนินการ I/O และใช้เอเจนต์ที่อนุญาตให้คุณส่งคำสั่งไปยังไฮเปอร์ไวเซอร์ API เอเจนต์มีหน้าที่รับผิดชอบในการทำงานกับสแน็ปช็อตและโคลน HyperFlex

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

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

ผู้ดูแลระบบแบบแฮนด์ฟรี = ไฮเปอร์คอนเวอร์เจนซ์?

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

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

ด้วยเหตุนี้ เราจึงมีแพลตฟอร์มไฮเปอร์คอนเวิร์จพร้อมคุณสมบัติดังต่อไปนี้:

  • มากถึง 64 โหนดในคลัสเตอร์ (สูงสุด 32 โหนดการจัดเก็บข้อมูล)
  • จำนวนโหนดขั้นต่ำในคลัสเตอร์คือสาม (สองโหนดสำหรับคลัสเตอร์ Edge)
  • กลไกการสำรองข้อมูล: การทำมิเรอร์ด้วยปัจจัยการจำลองแบบ 2 และ 3
  • คลัสเตอร์เมโทร
  • การจำลองแบบ VM แบบอะซิงโครนัสไปยังคลัสเตอร์ HyperFlex อื่น
  • การจัดระบบการสลับ VM ไปยังศูนย์ข้อมูลระยะไกล
  • สแน็ปช็อตดั้งเดิมโดยใช้เทคโนโลยี Redirect-on-Write
  • พื้นที่ใช้งานสูงสุด 1 PB ที่ปัจจัยการจำลอง 3 และไม่มีการขจัดข้อมูลซ้ำซ้อน เราไม่คำนึงถึงปัจจัยการจำลองแบบ 2 เนื่องจากนี่ไม่ใช่ตัวเลือกสำหรับการขายอย่างจริงจัง

ข้อดีอีกประการหนึ่งคือความง่ายในการจัดการและการปรับใช้ ความซับซ้อนทั้งหมดของการตั้งค่าเซิร์ฟเวอร์ UCS ได้รับการดูแลโดย VM เฉพาะทางที่จัดเตรียมโดยวิศวกรของ Cisco

การกำหนดค่าม้านั่งทดสอบ:

  • 2 x Cisco UCS Fabric Interconnect 6248UP เป็นคลัสเตอร์การจัดการและส่วนประกอบเครือข่าย (48 พอร์ตที่ทำงานในโหมด Ethernet 10G/FC 16G)
  • เซิร์ฟเวอร์ Cisco UCS HXAF240 M4 สี่เครื่อง

ลักษณะเซิร์ฟเวอร์:

ซีพียู

2 x Intel® Xeon® E5-2690 v4

แรม

16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/ระดับคู่/x4/1.2v

เครือข่าย

UCSC-MLOM-CSC-02 (VIC 1227) พอร์ตอีเธอร์เน็ต 2G 10 พอร์ต

อุปกรณ์จัดเก็บข้อมูล HBA

Cisco 12G Modular SAS ผ่านคอนโทรลเลอร์

ดิสก์จัดเก็บข้อมูล

1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB

ตัวเลือกการกำหนดค่าเพิ่มเติมนอกเหนือจากฮาร์ดแวร์ที่เลือกแล้ว ปัจจุบันยังมีตัวเลือกต่อไปนี้:

  • HXAF240c M5.
  • CPU หนึ่งหรือสองตัวตั้งแต่ Intel Silver 4110 ไปจนถึง Intel Platinum I8260Y รุ่นที่สองที่มีอยู่
  • ช่องใส่หน่วยความจำ 24 ช่อง ถอดได้ตั้งแต่ 16 GB RDIMM 2600 ถึง 128 GB LRDIMM 2933
  • ดิสก์ข้อมูลตั้งแต่ 6 ถึง 23 ดิสก์ ดิสก์แคชหนึ่งดิสก์ ดิสก์ระบบหนึ่งดิสก์ และดิสก์สำหรับบูตหนึ่งดิสก์

ไดรฟ์ความจุ

  • HX-SD960G61X-EV 960GB ความจุ 2.5 นิ้วระดับองค์กร 6G SATA SSD (ความทนทาน 1X) SAS 960 GB
  • HX-SD38T61X-EV 3.8TB 2.5 นิ้ว มูลค่าระดับองค์กร 6G SATA SSD (ความทนทาน 1X) SAS 3.8 TB
  • แคชไดรฟ์
  • HX-NVMEXPB-I375 375GB ไดรฟ์ Intel Optane ขนาด 2.5 นิ้ว ความสมบูรณ์แบบและความทนทานสูงสุด
  • HX-NVMEHW-H1600* 1.6TB ความจุ 2.5 นิ้ว เพอร์เฟค NVMe SSD (ความทนทาน 3 เท่า) NVMe 1.6 TB
  • HX-SD400G12TX-EP 400GB ขนาด 2.5 นิ้ว เพอร์เฟค 12G SAS SSD (ความทนทาน 10 เท่า) SAS 400 GB
  • HX-SD800GBENK9** 800GB ขนาด 2.5 นิ้ว เพอร์เฟค 12G SAS SED SSD (ความทนทาน 10 เท่า) SAS 800 GB
  • HX-SD16T123X-EP 1.6TB 2.5 นิ้ว ประสิทธิภาพระดับองค์กร 12G SAS SSD (ความทนทาน 3 เท่า)

ไดรฟ์ระบบ/บันทึก

  • HX-SD240GM1X-EV 240GB 2.5 นิ้ว Enterprise Value 6G SATA SSD (ต้องอัปเกรด)

บูตไดรฟ์

  • HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB

เชื่อมต่อกับเครือข่ายผ่านพอร์ตอีเธอร์เน็ต 40G, 25G หรือ 10G

FI สามารถเป็น HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G)

การทดสอบนั้นเอง

เพื่อทดสอบระบบย่อยของดิสก์ ฉันใช้ HCIBench 2.2.1 นี่คือยูทิลิตี้ฟรีที่ช่วยให้คุณสร้างโหลดจากเครื่องเสมือนหลายเครื่องได้โดยอัตโนมัติ โหลดนั้นถูกสร้างขึ้นโดย fio ปกติ

คลัสเตอร์ของเราประกอบด้วยสี่โหนด ปัจจัยการจำลองแบบ 3 ดิสก์ทั้งหมดเป็นแบบ Flash

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

ผลการทดสอบมีดังนี้:

อ่าน 100% สุ่ม 100%

0% อ่าน 100% สุ่ม

ความลึกของบล็อก/คิว

128

256

512

1024

2048

128

256

512

1024

2048

4K

0,59 มิลลิวินาที 213804 IOPS

0,84 มิลลิวินาที 303540 IOPS

1,36ms 374348 IOPS

2.47 มิลลิวินาที 414116 IOPS

4,86ms 420180 IOPS

2,22 มิลลิวินาที 57408 IOPS

3,09 มิลลิวินาที 82744 IOPS

5,02 มิลลิวินาที 101824 IPOS

8,75 มิลลิวินาที 116912 IOPS

17,2 มิลลิวินาที 118592 IOPS

8K

0,67 มิลลิวินาที 188416 IOPS

0,93 มิลลิวินาที 273280 IOPS

1,7 มิลลิวินาที 299932 IOPS

2,72 มิลลิวินาที 376,484 IOPS

5,47 มิลลิวินาที 373,176 IOPS

3,1 มิลลิวินาที 41148 IOPS

4,7 มิลลิวินาที 54396 IOPS

7,09 มิลลิวินาที 72192 IOPS

12,77 มิลลิวินาที 80132 IOPS

16K

0,77 มิลลิวินาที 164116 IOPS

1,12 มิลลิวินาที 228328 IOPS

1,9 มิลลิวินาที 268140 IOPS

3,96 มิลลิวินาที 258480 IOPS

3,8 มิลลิวินาที 33640 IOPS

6,97 มิลลิวินาที 36696 IOPS

11,35 มิลลิวินาที 45060 IOPS

32K

1,07 มิลลิวินาที 119292 IOPS

1,79 มิลลิวินาที 142888 IOPS

3,56 มิลลิวินาที 143760 IOPS

7,17 มิลลิวินาที 17810 IOPS

11,96 มิลลิวินาที 21396 IOPS

64K

1,84 มิลลิวินาที 69440 IOPS

3,6 มิลลิวินาที 71008 IOPS

7,26 มิลลิวินาที 70404 IOPS

11,37 มิลลิวินาที 11248 IOPS

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

  • อ่านต่อเนื่อง 4432 MB/s
  • การเขียนต่อเนื่อง 804 MB/s
  • หากตัวควบคุมตัวใดตัวหนึ่งล้มเหลว (ความล้มเหลวของเครื่องเสมือนหรือโฮสต์) ประสิทธิภาพจะลดลงเป็นสองเท่า
  • หากดิสก์จัดเก็บข้อมูลล้มเหลว การเบิกจ่ายคือ 1/3 การสร้างดิสก์ใหม่ใช้ทรัพยากร 5% ของคอนโทรลเลอร์แต่ละตัว

ในบล็อกขนาดเล็ก เราถูกจำกัดด้วยประสิทธิภาพของคอนโทรลเลอร์ (เครื่องเสมือน) CPU ของมันถูกโหลดที่ 100% และเมื่อบล็อกเพิ่มขึ้น เราจะถูกจำกัดโดยแบนด์วิธของพอร์ต 10 Gbps นั้นไม่เพียงพอที่จะปลดล็อคศักยภาพของระบบ AllFlash ขออภัย พารามิเตอร์ของแท่นสาธิตที่ให้มาไม่อนุญาตให้เราทดสอบการทำงานที่ 40 Gbit/s

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

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

การใช้งานจริง

หากต้องการจัดระเบียบศูนย์ข้อมูลสำรอง คุณสามารถใช้สองวิธี (เราไม่พิจารณาที่จะสำรองข้อมูลบนไซต์ระยะไกล):

  1. ใช้งานอยู่เรื่อย ๆ แอปพลิเคชันทั้งหมดโฮสต์อยู่ในศูนย์ข้อมูลหลัก การจำลองแบบเป็นแบบซิงโครนัสหรือแบบอะซิงโครนัส หากศูนย์ข้อมูลหลักล้มเหลว เราจำเป็นต้องเปิดใช้งานศูนย์ข้อมูลสำรอง ซึ่งสามารถทำได้ด้วยตนเอง/สคริปต์/แอปพลิเคชันการจัดเรียบเรียง ที่นี่เราจะได้รับ RPO ที่สอดคล้องกับความถี่ในการจำลอง และ RTO ขึ้นอยู่กับปฏิกิริยาและทักษะของผู้ดูแลระบบและคุณภาพของการพัฒนา/การแก้ไขข้อบกพร่องของแผนการสลับ
  2. ใช้งานอยู่ใช้งานอยู่ ในกรณีนี้ มีเพียงการจำลองแบบซิงโครนัสเท่านั้น ความพร้อมใช้งานของศูนย์ข้อมูลจะถูกกำหนดโดยองค์ประชุม/ผู้ชี้ขาดที่อยู่ในไซต์ที่สามอย่างเคร่งครัด RPO = 0 และ RTO สามารถเข้าถึง 0 (หากแอปพลิเคชันอนุญาต) หรือเท่ากับเวลาเฟลโอเวอร์ของโหนดในคลัสเตอร์การจำลองเสมือน ที่ระดับการจำลองเสมือน คลัสเตอร์แบบขยาย (Metro) จะถูกสร้างขึ้นซึ่งต้องใช้ที่เก็บข้อมูล Active-Active

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

สถานการณ์ที่ 1: เรามีศูนย์ข้อมูลหลักและศูนย์ข้อมูลสำรอง ซึ่งเป็นแพลตฟอร์มการจำลองเสมือนบน VMware vSphere ระบบการผลิตทั้งหมดตั้งอยู่ในศูนย์ข้อมูลหลัก และการจำลองเครื่องเสมือนจะดำเนินการในระดับไฮเปอร์ไวเซอร์ ซึ่งจะช่วยหลีกเลี่ยงการเปิด VM ไว้ในศูนย์ข้อมูลสำรอง เราจำลองฐานข้อมูลและแอปพลิเคชันพิเศษโดยใช้เครื่องมือในตัวและเปิด VM ไว้ หากศูนย์ข้อมูลหลักล้มเหลว เราจะเปิดใช้ระบบในศูนย์ข้อมูลสำรอง เราเชื่อว่าเรามีเครื่องเสมือนประมาณ 100 เครื่อง ในขณะที่ศูนย์ข้อมูลหลักทำงานอยู่ ศูนย์ข้อมูลสำรองสามารถเรียกใช้สภาพแวดล้อมการทดสอบและระบบอื่นๆ ที่สามารถปิดได้หากศูนย์ข้อมูลหลักสลับไป อาจเป็นไปได้ว่าเราใช้การจำลองแบบสองทาง จากมุมมองของฮาร์ดแวร์จะไม่มีอะไรเปลี่ยนแปลง

ในกรณีของสถาปัตยกรรมคลาสสิก เราจะติดตั้งระบบจัดเก็บข้อมูลแบบไฮบริดในศูนย์ข้อมูลแต่ละแห่งพร้อมการเข้าถึงผ่าน FibreChannel การจัดระดับ การขจัดข้อมูลซ้ำซ้อน และการบีบอัด (แต่ไม่ออนไลน์) เซิร์ฟเวอร์ 8 เครื่องสำหรับแต่ละไซต์ สวิตช์ FibreChannel 2 ตัว และอีเทอร์เน็ต 10G สำหรับการจัดการการจำลองแบบและการสลับในสถาปัตยกรรมคลาสสิก เราสามารถใช้เครื่องมือ VMware (Replication + SRM) หรือเครื่องมือของบุคคลที่สาม ซึ่งจะถูกกว่าเล็กน้อยและบางครั้งก็สะดวกกว่า

รูปภาพแสดงแผนภาพ

ผู้ดูแลระบบแบบแฮนด์ฟรี = ไฮเปอร์คอนเวอร์เจนซ์?

เมื่อใช้ Cisco HyperFlex จะได้รับสถาปัตยกรรมต่อไปนี้:

ผู้ดูแลระบบแบบแฮนด์ฟรี = ไฮเปอร์คอนเวอร์เจนซ์?

สำหรับ HyperFlex ฉันใช้เซิร์ฟเวอร์ที่มีทรัพยากร CPU/RAM ขนาดใหญ่ เพราะ... ทรัพยากรบางส่วนจะไปที่ VM คอนโทรลเลอร์ HyperFlex ในแง่ของ CPU และหน่วยความจำ ฉันยังกำหนดค่าการกำหนดค่า HyperFlex ใหม่เล็กน้อยเพื่อไม่ให้เล่นร่วมกับ Cisco และรับประกันทรัพยากรสำหรับ VM ที่เหลือ แต่เราสามารถละทิ้งสวิตช์ FibreChannel ได้ และเราจะไม่ต้องใช้พอร์ต Ethernet สำหรับแต่ละเซิร์ฟเวอร์ การรับส่งข้อมูลในเครื่องจะถูกสลับภายใน FI

ผลลัพธ์คือการกำหนดค่าต่อไปนี้สำหรับศูนย์ข้อมูลแต่ละแห่ง:

เซิร์ฟเวอร์

เซิร์ฟเวอร์ 8 x 1U (RAM 384 GB, 2 x Intel Gold 6132, FC HBA)

8 x HX240C-M5L (RAM 512 GB, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)

SHD

ระบบจัดเก็บข้อมูลแบบไฮบริดพร้อม FC Front-End (20TB SSD, 130 TB NL-SAS)

-

แลน

2 x สวิตช์อีเทอร์เน็ต 10G 12 พอร์ต

-

SAN

2 x สวิตช์ FC 32/16Gb 24 พอร์ต

2 x ซิสโก้ UCS FI 6332

ใบอนุญาต

วีเอ็มแวร์ เอนท์ พลัส

การจำลองแบบและ/หรือการจัดการการสลับ VM

วีเอ็มแวร์ เอนท์ พลัส

ฉันไม่ได้ให้สิทธิ์การใช้งานซอฟต์แวร์การจำลองแบบสำหรับ Hyperflex เนื่องจากเรามีให้ใช้งานได้ทันที

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

โซลูชัน Cisco HyperFlex มีราคาถูกลงถึง 13%

สถานการณ์ที่ 2: การสร้างศูนย์ข้อมูลที่ใช้งานอยู่สองแห่ง ในสถานการณ์สมมตินี้ เรากำลังออกแบบคลัสเตอร์แบบขยายบน VMware

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

ผู้ดูแลระบบแบบแฮนด์ฟรี = ไฮเปอร์คอนเวอร์เจนซ์?

ที่ HyperFlex เราเพียงสร้าง Stretch Cluster โดยมีจำนวนโหนดเท่ากันบนทั้งสองไซต์ ในกรณีนี้ จะใช้ปัจจัยการจำลองแบบ 2+2

ผู้ดูแลระบบแบบแฮนด์ฟรี = ไฮเปอร์คอนเวอร์เจนซ์?

ผลลัพธ์คือการกำหนดค่าต่อไปนี้:

สถาปัตยกรรมคลาสสิก

ไฮเปอร์เฟล็กซ์

เซิร์ฟเวอร์

เซิร์ฟเวอร์ 16 x 1U (RAM 384 GB, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)

16 x HX240C-M5L (RAM 512 GB, 2 x Intel Gold 6132, 1,6 TB NVMe, SSD 12 x 3,8 TB, VIC 1387)

SHD

2 x ระบบจัดเก็บข้อมูล AllFlash (150 TB SSD)

-

แลน

4 x สวิตช์อีเทอร์เน็ต 10G 24 พอร์ต

-

SAN

4 x สวิตช์ FC 32/16Gb 24 พอร์ต

4 x ซิสโก้ UCS FI 6332

ใบอนุญาต

วีเอ็มแวร์ เอนท์ พลัส

วีเอ็มแวร์ เอนท์ พลัส

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

ในแง่ของต้นทุน HyperFlex มีราคาแพงกว่า 5% เป็นที่น่าสังเกตว่าในแง่ของทรัพยากร CPU/RAM ฉันมีความเบี่ยงเบนสำหรับ Cisco เนื่องจากในการกำหนดค่าฉันเติมช่องตัวควบคุมหน่วยความจำอย่างเท่าเทียมกัน ค่าใช้จ่ายสูงกว่าเล็กน้อย แต่ไม่ใช่ตามลำดับความสำคัญ ซึ่งแสดงให้เห็นชัดเจนว่าไฮเปอร์คอนเวอร์เจนซ์ไม่จำเป็นต้องเป็น "ของเล่นสำหรับคนรวย" แต่สามารถแข่งขันกับแนวทางมาตรฐานในการสร้างศูนย์ข้อมูลได้ สิ่งนี้อาจเป็นที่สนใจสำหรับผู้ที่มีเซิร์ฟเวอร์ Cisco UCS และโครงสร้างพื้นฐานที่เกี่ยวข้องอยู่แล้ว

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

สำหรับการสนับสนุน คุณจะได้รับจากผู้ขายรายเดียวนั่นคือ Cisco เมื่อพิจารณาจากประสบการณ์ของฉันกับเซิร์ฟเวอร์ Cisco UCS ฉันชอบมัน ฉันไม่จำเป็นต้องเปิดมันบน HyperFlex ทุกอย่างทำงานเหมือนเดิม วิศวกรตอบสนองอย่างรวดเร็วและสามารถแก้ปัญหาได้ไม่เพียงแต่ปัญหาทั่วไปเท่านั้น แต่ยังรวมถึงกรณี Edge ที่ซับซ้อนด้วย บางครั้งฉันก็หันไปหาพวกเขาพร้อมกับคำถาม: “เป็นไปได้ไหมที่จะทำสิ่งนี้ หรือ “ฉันกำหนดค่าบางอย่างที่นี่ และมันไม่ต้องการทำงาน ช่วย!" - พวกเขาจะค้นหาคำแนะนำที่จำเป็นอย่างอดทนและชี้ให้เห็นการกระทำที่ถูกต้อง พวกเขาจะไม่ตอบว่า: "เราแก้ปัญหาฮาร์ดแวร์เท่านั้น"

การอ้างอิง

ที่มา: will.com

เพิ่มความคิดเห็น