การสร้างโซลูชันที่ทนทานต่อข้อผิดพลาดโดยใช้สถาปัตยกรรม Oracle RAC และ AccelStor Shared-Nothing

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

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

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

ตู้เหล่านี้จะต้องมีชุดอุปกรณ์และซอฟต์แวร์ที่จำเป็นทั้งหมดที่จะช่วยให้การทำงานของฐานข้อมูล Oracle โดยไม่คำนึงถึงสถานะของ "เพื่อนบ้าน" กล่าวอีกนัยหนึ่ง การใช้โซลูชันการกู้คืนความเสียหายแบบ Cross-Rack ช่วยลดความเสี่ยงของความล้มเหลว:

• เซิร์ฟเวอร์แอปพลิเคชันของออราเคิล
• ระบบจัดเก็บข้อมูล
• ระบบสวิตชิ่ง
• ความล้มเหลวของอุปกรณ์ทั้งหมดในตู้โดยสมบูรณ์:
  • การปฏิเสธอำนาจ
  • ระบบทำความเย็นล้มเหลว
  • ปัจจัยภายนอก (มนุษย์ ธรรมชาติ ฯลฯ)

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

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

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

โซลูชัน AccelStor NeoSapphire™ All Flash Array เหมาะสำหรับสถานการณ์ต่างๆ เช่น การกู้คืนความเสียหายแบบ Cross-Rack H710 ใช้สถาปัตยกรรมแบบไม่มีการแบ่งปัน รุ่นนี้คือระบบจัดเก็บข้อมูลแบบสองโหนดที่ใช้เทคโนโลยี FlexiRemap® ที่เป็นกรรมสิทธิ์เพื่อทำงานร่วมกับแฟลชไดรฟ์ ขอบคุณ FlexiRemap® NeoSapphire™ H710 สามารถส่งมอบประสิทธิภาพสูงสุด 600K IOPS@4K การเขียนแบบสุ่ม และ 1M+ IOPS@4K การอ่านแบบสุ่ม ซึ่งไม่สามารถทำได้เมื่อใช้ระบบจัดเก็บข้อมูลแบบ RAID แบบคลาสสิก

แต่คุณสมบัติหลักของ NeoSapphire™ H710 คือการทำงานของสองโหนดในรูปแบบของเคสที่แยกจากกัน ซึ่งแต่ละโหนดมีสำเนาข้อมูลของตัวเอง การซิงโครไนซ์โหนดดำเนินการผ่านอินเทอร์เฟซ InfiniBand ภายนอก ด้วยสถาปัตยกรรมนี้ ทำให้สามารถกระจายโหนดไปยังตำแหน่งต่างๆ ได้ในระยะไกลสูงสุด 100 เมตร จึงเป็นโซลูชันการกู้คืนความเสียหายแบบ Cross-Rack โหนดทั้งสองทำงานพร้อมกันอย่างสมบูรณ์ จากฝั่งโฮสต์ H710 ดูเหมือนระบบจัดเก็บข้อมูลแบบคอนโทรลเลอร์คู่ทั่วไป ดังนั้นจึงไม่จำเป็นต้องดำเนินการตัวเลือกซอฟต์แวร์หรือฮาร์ดแวร์เพิ่มเติมหรือการตั้งค่าที่ซับซ้อนเป็นพิเศษ

หากเราเปรียบเทียบโซลูชันการกู้คืนความเสียหายแบบ Cross-Rack ทั้งหมดที่อธิบายไว้ข้างต้น ตัวเลือกจาก AccelStor จะโดดเด่นกว่าตัวเลือกอื่นๆ อย่างเห็นได้ชัด:

AccelStor NeoSapphire™ ไม่ได้แชร์สถาปัตยกรรมใดๆ เลย
ซอฟต์แวร์หรือฮาร์ดแวร์ระบบจัดเก็บข้อมูล "เสมือนจริง"
โซลูชันที่ใช้การจำลองแบบ

ความพร้อมใช้งาน

เซิร์ฟเวอร์ล้มเหลว
ไม่มีการหยุดทำงาน
ไม่มีการหยุดทำงาน
ไม่มีการหยุดทำงาน

สวิตช์ล้มเหลว
ไม่มีการหยุดทำงาน
ไม่มีการหยุดทำงาน
ไม่มีการหยุดทำงาน

ระบบจัดเก็บข้อมูลล้มเหลว
ไม่มีการหยุดทำงาน
ไม่มีการหยุดทำงาน
หยุดทำงาน

ความล้มเหลวทั้งตู้
ไม่มีการหยุดทำงาน
ไม่มีการหยุดทำงาน
หยุดทำงาน

ต้นทุนและความซับซ้อน

ต้นทุนการแก้ปัญหา
ต่ำ*
สูง
สูง

ความซับซ้อนในการปรับใช้
ต่ำ
สูง
สูง

*AccelStor NeoSapphire™ ยังคงเป็นอาร์เรย์ Flash ทั้งหมด ซึ่งตามคำจำกัดความแล้วไม่มีค่าใช้จ่าย "3 โกเปค" โดยเฉพาะอย่างยิ่งเนื่องจากมีการสำรองความจุเป็นสองเท่า อย่างไรก็ตาม เมื่อเปรียบเทียบต้นทุนสุดท้ายของโซลูชันกับต้นทุนที่คล้ายกันจากผู้ขายรายอื่น ต้นทุนก็ถือว่าต่ำ

โทโพโลยีสำหรับการเชื่อมต่อแอปพลิเคชันเซิร์ฟเวอร์และโหนดอาร์เรย์ Flash ทั้งหมดจะมีลักษณะดังนี้:

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

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

งานเตรียมการเกี่ยวกับอาเรย์

อุปกรณ์และซอฟต์แวร์ที่ใช้

ข้อมูลจำเพาะของเซิร์ฟเวอร์และสวิตช์

ส่วนประกอบ
ลักษณะ

เซิร์ฟเวอร์ฐานข้อมูล Oracle 11g
สอง

ระบบปฏิบัติการเซิร์ฟเวอร์
Oracle Linux

เวอร์ชันฐานข้อมูลออราเคิล
11g (อาร์เอซี)

โปรเซสเซอร์ต่อเซิร์ฟเวอร์
CPU Intel® Xeon® E16-5 v2667 2 คอร์สองตัว @ 3.30GHz

หน่วยความจำกายภาพต่อเซิร์ฟเวอร์
128GB

เครือข่ายเอฟซี
16Gb/s FC พร้อมมัลติพาธติ้ง

เอฟซี เอชบีเอ
อีมูเล็กซ์ Lpe-16002B

พอร์ต 1GbE สาธารณะเฉพาะสำหรับการจัดการคลัสเตอร์
อะแดปเตอร์อีเธอร์เน็ต Intel RJ45

สวิตช์เอฟซี 16Gb/s
โบรเคด 6505

พอร์ต 10GbE ส่วนตัวเฉพาะสำหรับการซิงโครไนซ์ข้อมูล
Intel X520

AccelStor NeoSapphire™ ข้อมูลจำเพาะของอาร์เรย์แฟลชทั้งหมด

ส่วนประกอบ
ลักษณะ

ระบบจัดเก็บ
NeoSapphire™ รุ่นที่มีความพร้อมใช้งานสูง: H710

เวอร์ชันรูปภาพ
4.0.1

จำนวนไดรฟ์ทั้งหมด
48

ขนาดไดรฟ์
1.92TB

ประเภทไดรฟ์
SSD

พอร์ตเป้าหมาย FC
พอร์ต 16x 16Gb (8 ต่อโหนด)

พอร์ตการจัดการ
สายเคเบิลอีเธอร์เน็ต 1GbE เชื่อมต่อกับโฮสต์ผ่านสวิตช์อีเธอร์เน็ต

พอร์ตฮาร์ทบีท
สายเคเบิลอีเธอร์เน็ต 1GbE เชื่อมต่อระหว่างโหนดจัดเก็บข้อมูลสองโหนด

พอร์ตการซิงโครไนซ์ข้อมูล
สายเคเบิล InfiniBand ความเร็ว 56Gb/s

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

หลังจากการกำหนดค่าเริ่มต้นเสร็จสมบูรณ์ คุณสามารถจัดการอาร์เรย์จากโหนดใดก็ได้

ต่อไป เราจะสร้างวอลุ่มที่จำเป็นและเผยแพร่ไปยังแอปพลิเคชันเซิร์ฟเวอร์

ขอแนะนำอย่างยิ่งให้สร้างหลายวอลุ่มสำหรับ Oracle ASM เนื่องจากจะเพิ่มจำนวนเป้าหมายสำหรับเซิร์ฟเวอร์ ซึ่งในที่สุดจะปรับปรุงประสิทธิภาพโดยรวม (เพิ่มเติมเกี่ยวกับคิวในอีก статье).

ทดสอบการกำหนดค่า

ชื่อปริมาณการจัดเก็บข้อมูล
ขนาดปริมาตร

ข้อมูล 01
200GB

ข้อมูล 02
200GB

ข้อมูล 03
200GB

ข้อมูล 04
200GB

ข้อมูล 05
200GB

ข้อมูล 06
200GB

ข้อมูล 07
200GB

ข้อมูล 08
200GB

ข้อมูล 09
200GB

ข้อมูล 10
200GB

Grid01
1GB

Grid02
1GB

Grid03
1GB

Grid04
1GB

Grid05
1GB

Grid06
1GB

ทำซ้ำ 01
100GB

ทำซ้ำ 02
100GB

ทำซ้ำ 03
100GB

ทำซ้ำ 04
100GB

ทำซ้ำ 05
100GB

ทำซ้ำ 06
100GB

ทำซ้ำ 07
100GB

ทำซ้ำ 08
100GB

ทำซ้ำ 09
100GB

ทำซ้ำ 10
100GB

คำอธิบายบางประการเกี่ยวกับโหมดการทำงานของอาเรย์และกระบวนการที่เกิดขึ้นในสถานการณ์ฉุกเฉิน

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

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

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

หากการเชื่อมต่อผ่านลิงค์อีเธอร์เน็ตขาดหายไป Heartbeat จะสลับไปที่ InfiniBand ชั่วคราวและจะกลับมาภายใน 10 วินาทีเมื่อได้รับการกู้คืน

การตั้งค่าโฮสต์

เพื่อให้มั่นใจถึงความทนทานต่อข้อผิดพลาดและปรับปรุงประสิทธิภาพ คุณต้องเปิดใช้งานการสนับสนุน MPIO สำหรับอาร์เรย์ ในการดำเนินการนี้ คุณต้องเพิ่มบรรทัดลงในไฟล์ /etc/multipath.conf จากนั้นรีสตาร์ทบริการ multipath

ข้อความที่ซ่อนอยู่อุปกรณ์ {
อุปกรณ์ {
ผู้จำหน่าย "เอสเตอร์"
path_grouping_policy "group_by_prio"
path_selector "ความยาวคิว 0"
path_checker "คุณ"
คุณสมบัติ "0"
ฮาร์ดแวร์_ตัวจัดการ "0"
ปรีโอ "const"
ล้มเหลวทันที
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names ใช่
detector_prio ใช่
rr_min_io_rq 1
no_path_ลองอีกครั้ง 0
}
}

ถัดไป เพื่อให้ ASM ทำงานกับ MPIO ผ่าน ASMLib คุณต้องเปลี่ยนไฟล์ /etc/sysconfig/oracleasm จากนั้นรัน /etc/init.d/oracleasm scandisks

ข้อความที่ซ่อนอยู่

# ORACLEASM_SCANORDER: จับคู่รูปแบบเพื่อสั่งการสแกนดิสก์
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: จับคู่รูปแบบเพื่อแยกดิสก์ออกจากการสแกน
ORACLEASM_SCANEXCLUDE="sd"

หมายเหตุ

หากคุณไม่ต้องการใช้ ASMLib คุณสามารถใช้กฎ UDEV ซึ่งเป็นพื้นฐานสำหรับ ASMLib

ตั้งแต่เวอร์ชัน 12.1.0.2 ของ Oracle Database เป็นต้นไป ตัวเลือกนี้จะพร้อมสำหรับการติดตั้งโดยเป็นส่วนหนึ่งของซอฟต์แวร์ ASMFD

จำเป็นต้องตรวจสอบให้แน่ใจว่าดิสก์ที่สร้างขึ้นสำหรับ Oracle ASM สอดคล้องกับขนาดบล็อกที่อาเรย์ใช้งานทางกายภาพ (4K) มิฉะนั้นอาจเกิดปัญหาด้านประสิทธิภาพการทำงาน ดังนั้นจึงจำเป็นต้องสร้างวอลุ่มด้วยพารามิเตอร์ที่เหมาะสม:

แยก /dev/mapper/ชื่ออุปกรณ์ mklabel gpt mkpart หลัก 2048s 100% ตรวจสอบการจัดตำแหน่งที่ดีที่สุด 1

การกระจายฐานข้อมูลไปยังวอลุ่มที่สร้างขึ้นสำหรับการกำหนดค่าการทดสอบของเรา

ชื่อปริมาณการจัดเก็บข้อมูล
ขนาดปริมาตร
การแมป Volume LUN
รายละเอียดอุปกรณ์วอลุ่ม ASM
การจัดสรรขนาดหน่วย

ข้อมูล 01
200GB
แมปไดรฟ์ข้อมูลการจัดเก็บข้อมูลทั้งหมดกับระบบจัดเก็บข้อมูลพอร์ตข้อมูลทั้งหมด
ความซ้ำซ้อน: ปกติ
ชื่อ:DGDATA
วัตถุประสงค์:ไฟล์ข้อมูล

4MB

ข้อมูล 02
200GB

ข้อมูล 03
200GB

ข้อมูล 04
200GB

ข้อมูล 05
200GB

ข้อมูล 06
200GB

ข้อมูล 07
200GB

ข้อมูล 08
200GB

ข้อมูล 09
200GB

ข้อมูล 10
200GB

Grid01
1GB
ความซ้ำซ้อน: ปกติ
ชื่อ: DGGRID1
วัตถุประสงค์: ตาราง: CRS และการลงคะแนนเสียง

4MB

Grid02
1GB

Grid03
1GB

Grid04
1GB
ความซ้ำซ้อน: ปกติ
ชื่อ: DGGRID2
วัตถุประสงค์: ตาราง: CRS และการลงคะแนนเสียง

4MB

Grid05
1GB

Grid06
1GB

ทำซ้ำ 01
100GB
ความซ้ำซ้อน: ปกติ
ชื่อ: DGREDO1
วัตถุประสงค์: ทำซ้ำบันทึกของเธรด 1

4MB

ทำซ้ำ 02
100GB

ทำซ้ำ 03
100GB

ทำซ้ำ 04
100GB

ทำซ้ำ 05
100GB

ทำซ้ำ 06
100GB
ความซ้ำซ้อน: ปกติ
ชื่อ: DGREDO2
วัตถุประสงค์: ทำซ้ำบันทึกของเธรด 2

4MB

ทำซ้ำ 07
100GB

ทำซ้ำ 08
100GB

ทำซ้ำ 09
100GB

ทำซ้ำ 10
100GB

การตั้งค่าฐานข้อมูล

• ขนาดบล็อก = 8K
• พื้นที่สว็อป = 16GB
• ปิดการใช้งาน AMM (การจัดการหน่วยความจำอัตโนมัติ)
• ปิดใช้งานหน้าขนาดใหญ่แบบโปร่งใส

การตั้งค่าอื่นๆ

# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-สูงสุด = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # อย่าตั้งค่านี้หากคุณใช้ Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓กริดซอฟต์ nproc 2047
✓ ตารางฮาร์ด nproc 16384
✓ ตาราง soft nofile 1024
✓ กริดฮาร์ดโนไฟล์ 65536
✓ กริดซอฟต์สแต็ค 10240
✓ กริดฮาร์ดสแต็ค 32768
✓ ออราเคิลซอฟท์ nproc 2047
✓ ออราเคิลฮาร์ด nproc 16384
✓ ออราเคิลซอฟท์ nofile 1024
✓ ออราเคิลฮาร์ดโนไฟล์ 65536
✓ ออราเคิลซอฟท์สแต็ค 10240
✓ ออราเคิลฮาร์ดสแต็ค 32768
✓ ซอฟท์เมมล็อค 120795954
✓ ฮาร์ดเมมล็อค 120795954

sqlplus “/เป็น sysdba”
แก้ไขกระบวนการชุดระบบ=2000 scope=spfile;
แก้ไขชุดระบบ open_cursors=2000 scope=spfile;
แก้ไขชุดระบบ session_cached_cursors=300 scope=spfile;
แก้ไขชุดระบบ db_files=8192 scope=spfile;

การทดสอบความล้มเหลว

เพื่อจุดประสงค์ในการสาธิต HammerDB ถูกใช้เพื่อจำลองโหลด OLTP การกำหนดค่า HammerDB:

จำนวนคลังสินค้า
256

ธุรกรรมทั้งหมดต่อผู้ใช้
1000000000000

ผู้ใช้เสมือน
256

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

ทดสอบความล้มเหลวของโหนดใดโหนดหนึ่ง

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

การทดสอบความล้มเหลวของตู้ด้วยอุปกรณ์ทั้งหมด

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

หากมีความจำเป็นต้องปรับใช้โซลูชันการกู้คืนความเสียหายแบบ Cross-Rack ที่ทนทานต่อข้อผิดพลาดสำหรับ Oracle ในราคาที่สมเหตุสมผลและใช้ความพยายามในการปรับใช้/การดูแลระบบเพียงเล็กน้อย Oracle RAC และสถาปัตยกรรมจะทำงานร่วมกัน AccelStor แบ่งปัน-ไม่มีอะไรเลย จะเป็นหนึ่งในตัวเลือกที่ดีที่สุด แทนที่จะเป็น Oracle RAC อาจมีซอฟต์แวร์อื่นๆ ที่ให้บริการการทำคลัสเตอร์ เช่น DBMS หรือระบบเวอร์ชวลไลเซชันเดียวกัน หลักการสร้างวิธีแก้ปัญหาจะยังคงเหมือนเดิม และบรรทัดล่างคือศูนย์สำหรับ RTO และ RPO

ที่มา: will.com