ทฤษฎีบท CAP เป็นรากฐานสำคัญของทฤษฎีระบบแบบกระจาย แน่นอนว่าความขัดแย้งโดยรอบไม่ได้บรรเทาลง: คำจำกัดความในนั้นไม่เป็นที่ยอมรับ และไม่มีข้อพิสูจน์ที่เข้มงวด... อย่างไรก็ตาม ด้วยการยืนหยัดอย่างมั่นคงบนตำแหน่งของสามัญสำนึกในชีวิตประจำวัน เราเข้าใจโดยสัญชาตญาณว่าทฤษฎีบทนี้เป็นเรื่องจริง
สิ่งเดียวที่ไม่ชัดเจนคือความหมายของตัวอักษร "P" เมื่อคลัสเตอร์ถูกแบ่งออก จะตัดสินใจว่าจะไม่ตอบสนองจนกว่าจะถึงองค์ประชุม หรือจะให้คืนข้อมูลที่มีอยู่ ขึ้นอยู่กับผลลัพธ์ของตัวเลือกนี้ ระบบจะจัดประเภทเป็น CP หรือ AP ตัวอย่างเช่น Cassandra สามารถทำงานด้วยวิธีใดวิธีหนึ่งได้ ขึ้นอยู่กับการตั้งค่าคลัสเตอร์ แต่ขึ้นอยู่กับพารามิเตอร์ของคำขอเฉพาะแต่ละรายการ แต่ถ้าระบบไม่ใช่ "P" แล้วแยกแล้วจะเป็นยังไง?
คำตอบสำหรับคำถามนี้ค่อนข้างคาดไม่ถึง: คลัสเตอร์ CA ไม่สามารถแยกได้
คลัสเตอร์ชนิดใดที่ไม่สามารถแยกได้
คุณลักษณะที่ขาดไม่ได้ของคลัสเตอร์ดังกล่าวคือระบบจัดเก็บข้อมูลที่ใช้ร่วมกัน ในกรณีส่วนใหญ่ นี่หมายถึงการเชื่อมต่อผ่าน SAN ซึ่งจะจำกัดการใช้โซลูชัน CA สำหรับองค์กรขนาดใหญ่ที่สามารถดูแลรักษาโครงสร้างพื้นฐาน SAN ได้ เพื่อให้เซิร์ฟเวอร์หลายเครื่องทำงานกับข้อมูลเดียวกันได้ จำเป็นต้องมีระบบไฟล์แบบคลัสเตอร์ ระบบไฟล์ดังกล่าวมีอยู่ในพอร์ตโฟลิโอ HPE (CFS), Veritas (VxCFS) และ IBM (GPFS)
ออราเคิล อาร์เอซี
ตัวเลือก Real Application Cluster ปรากฏครั้งแรกในปี 2001 พร้อมกับการเปิดตัว Oracle 9i ในคลัสเตอร์ดังกล่าว อินสแตนซ์เซิร์ฟเวอร์หลายรายการทำงานกับฐานข้อมูลเดียวกัน
Oracle สามารถทำงานร่วมกับทั้งระบบไฟล์แบบคลัสเตอร์และโซลูชันของตัวเอง - ASM, การจัดการพื้นที่เก็บข้อมูลอัตโนมัติ
แต่ละสำเนาจะเก็บบันทึกประจำวันของตัวเอง ธุรกรรมดำเนินการและกระทำโดยอินสแตนซ์เดียว หากอินสแตนซ์ล้มเหลว โหนดคลัสเตอร์ตัวใดตัวหนึ่ง (อินสแตนซ์) ที่ยังเหลืออยู่จะอ่านบันทึกและกู้คืนข้อมูลที่สูญหาย ดังนั้นจึงรับประกันความพร้อมใช้งาน
อินสแตนซ์ทั้งหมดจะรักษาแคชของตัวเอง และหน้าเดียวกัน (บล็อก) สามารถอยู่ในแคชของหลายอินสแตนซ์พร้อมกันได้ ยิ่งไปกว่านั้น หากอินสแตนซ์หนึ่งต้องการเพจและอยู่ในแคชของอินสแตนซ์อื่น อินสแตนซ์นั้นสามารถรับจากเพื่อนบ้านได้โดยใช้กลไกการรวมแคชแทนการอ่านจากดิสก์
แต่จะเกิดอะไรขึ้นหากหนึ่งในอินสแตนซ์จำเป็นต้องเปลี่ยนแปลงข้อมูล
ลักษณะเฉพาะของ Oracle คือไม่มีบริการล็อคเฉพาะ: หากเซิร์ฟเวอร์ต้องการล็อคแถว บันทึกการล็อคจะถูกวางโดยตรงบนหน้าหน่วยความจำซึ่งมีแถวที่ถูกล็อคอยู่ ด้วยแนวทางนี้ Oracle จึงเป็นแชมป์ด้านประสิทธิภาพในบรรดาฐานข้อมูลขนาดใหญ่ บริการล็อคไม่เคยกลายเป็นคอขวด แต่ในการกำหนดค่าคลัสเตอร์ สถาปัตยกรรมดังกล่าวสามารถนำไปสู่การรับส่งข้อมูลเครือข่ายที่รุนแรงและการหยุดชะงักได้
เมื่อบันทึกถูกล็อค อินสแตนซ์จะแจ้งอินสแตนซ์อื่นๆ ทั้งหมดที่เพจที่จัดเก็บบันทึกนั้นมีการเก็บรักษาไว้แต่เพียงผู้เดียว หากอินสแตนซ์อื่นจำเป็นต้องเปลี่ยนบันทึกบนเพจเดียวกัน อินสแตนซ์นั้นจะต้องรอจนกว่าจะคอมมิตการเปลี่ยนแปลงในเพจ กล่าวคือ ข้อมูลการเปลี่ยนแปลงจะถูกเขียนลงในเจอร์นัลบนดิสก์ (และธุรกรรมสามารถดำเนินต่อไปได้) อาจเกิดขึ้นได้ว่าหน้าจะมีการเปลี่ยนแปลงตามลำดับหลายชุดจากนั้นเมื่อเขียนหน้าลงดิสก์คุณจะต้องค้นหาว่าใครเก็บเวอร์ชันปัจจุบันของหน้านี้ไว้
การสุ่มอัปเดตเพจเดียวกันในโหนด RAC ที่แตกต่างกันทำให้ประสิทธิภาพของฐานข้อมูลลดลงอย่างมาก จนถึงจุดที่ประสิทธิภาพของคลัสเตอร์อาจต่ำกว่าประสิทธิภาพของอินสแตนซ์เดียว
การใช้ Oracle RAC อย่างถูกต้องคือการแบ่งพาร์ติชันข้อมูลทางกายภาพ (เช่น การใช้กลไกตารางที่แบ่งพาร์ติชัน) และเข้าถึงแต่ละชุดของพาร์ติชันผ่านโหนดเฉพาะ วัตถุประสงค์หลักของ RAC ไม่ใช่การปรับสเกลในแนวนอน แต่รับประกันความทนทานต่อข้อผิดพลาด
หากโหนดหยุดตอบสนองต่อฮาร์ทบีท โหนดที่ตรวจพบโหนดนั้นจะเริ่มขั้นตอนการลงคะแนนเสียงบนดิสก์ก่อน หากไม่ได้ระบุโหนดที่หายไปไว้ที่นี่ โหนดใดโหนดหนึ่งจะรับผิดชอบในการกู้คืนข้อมูล:
- “ค้าง” หน้าทั้งหมดที่อยู่ในแคชของโหนดที่หายไป
- อ่านบันทึก (ทำซ้ำ) ของโหนดที่หายไปและนำการเปลี่ยนแปลงที่บันทึกไว้ในบันทึกเหล่านี้ไปใช้อีกครั้ง พร้อมตรวจสอบว่าโหนดอื่นมีการเปลี่ยนแปลงหน้าที่เวอร์ชันล่าสุดหรือไม่
- ย้อนกลับการทำธุรกรรมที่ค้างอยู่
เพื่อให้การสลับระหว่างโหนดง่ายขึ้น Oracle มีแนวคิดของบริการ - อินสแตนซ์เสมือน อินสแตนซ์สามารถให้บริการได้หลายบริการ และบริการสามารถย้ายระหว่างโหนดได้ อินสแตนซ์แอปพลิเคชันที่ให้บริการส่วนหนึ่งของฐานข้อมูล (เช่น กลุ่มไคลเอนต์) ทำงานร่วมกับบริการเดียว และบริการที่รับผิดชอบฐานข้อมูลส่วนนี้จะย้ายไปยังโหนดอื่นเมื่อโหนดล้มเหลว
IBM Pure Data Systems สำหรับธุรกรรม
โซลูชันคลัสเตอร์สำหรับ DBMS ปรากฏในพอร์ตโฟลิโอ Blue Giant ในปี 2009 ตามหลักการแล้ว คลัสเตอร์นี้เป็นผู้สืบทอดของคลัสเตอร์ Parallel Sysplex ที่สร้างขึ้นบนอุปกรณ์ "ปกติ" ในปี 2009 ชุดซอฟต์แวร์ DB2 pureScale ได้รับการเผยแพร่ และในปี 2012 IBM ได้เสนออุปกรณ์ที่เรียกว่า Pure Data Systems for Transactions ไม่ควรสับสนกับ Pure Data Systems for Analytics ซึ่งไม่มีอะไรมากไปกว่าการเปลี่ยนชื่อ Netezza
เมื่อมองแวบแรก สถาปัตยกรรม pureScale จะคล้ายกับ Oracle RAC: ในทำนองเดียวกัน โหนดหลายโหนดเชื่อมต่อกับระบบจัดเก็บข้อมูลทั่วไป และแต่ละโหนดจะรันอินสแตนซ์ DBMS ของตัวเองพร้อมพื้นที่หน่วยความจำและบันทึกธุรกรรมของตัวเอง แต่ต่างจาก Oracle ตรงที่ DB2 มีบริการล็อคเฉพาะที่แสดงโดยชุดของกระบวนการ db2LLM* ในการกำหนดค่าคลัสเตอร์ บริการนี้จะอยู่บนโหนดแยกต่างหาก ซึ่งเรียกว่า Coupling Facility (CF) ใน Parallel Sysplex และ PowerHA ใน Pure Data
PowerHA ให้บริการดังต่อไปนี้:
- ผู้จัดการล็อค;
- แคชบัฟเฟอร์ส่วนกลาง
- พื้นที่ของการสื่อสารระหว่างกระบวนการ
ในการถ่ายโอนข้อมูลจาก PowerHA ไปยังโหนดฐานข้อมูลและด้านหลัง จะใช้การเข้าถึงหน่วยความจำระยะไกล ดังนั้นการเชื่อมต่อระหว่างคลัสเตอร์จึงต้องสนับสนุนโปรโตคอล RDMA PureScale สามารถใช้ทั้ง Infiniband และ RDMA ผ่านอีเธอร์เน็ต
หากโหนดต้องการเพจ และเพจนี้ไม่ได้อยู่ในแคช โหนดจะร้องขอเพจในแคชส่วนกลาง และหากไม่มีอยู่ตรงนั้น ก็สามารถอ่านจากดิสก์ได้ ต่างจาก Oracle ตรงที่คำขอจะส่งไปที่ PowerHA เท่านั้น และไม่ใช่ไปยังโหนดข้างเคียง
หากอินสแตนซ์กำลังจะเปลี่ยนแถว อินสแตนซ์จะล็อกอินสแตนซ์นั้นในโหมดเอกสิทธิ์เฉพาะบุคคลและหน้าที่ซึ่งแถวนั้นอยู่ในโหมดแชร์ ล็อคทั้งหมดได้รับการลงทะเบียนในตัวจัดการล็อคส่วนกลาง เมื่อธุรกรรมเสร็จสมบูรณ์ โหนดจะส่งข้อความไปยังตัวจัดการการล็อก ซึ่งจะคัดลอกเพจที่แก้ไขไปยังแคชส่วนกลาง ปล่อยการล็อก และทำให้เพจที่แก้ไขในแคชของโหนดอื่นใช้ไม่ได้
หากเพจซึ่งมีแถวที่แก้ไขนั้นถูกล็อคอยู่แล้ว ตัวจัดการการล็อคจะอ่านเพจที่แก้ไขจากหน่วยความจำของโหนดที่ทำการเปลี่ยนแปลง ปล่อยการล็อค ทำให้เพจที่แก้ไขใช้งานไม่ได้ในแคชของโหนดอื่น และ มอบการล็อคหน้าให้กับโหนดที่ร้องขอ
“สกปรก” ซึ่งก็คือการเปลี่ยนแปลง สามารถเขียนเพจลงดิสก์ได้ทั้งจากโหนดปกติและจาก PowerHA (castout)
หากโหนด pureScale ตัวใดตัวหนึ่งล้มเหลว การกู้คืนจะถูกจำกัดเฉพาะธุรกรรมที่ยังไม่เสร็จสมบูรณ์ในเวลาที่เกิดความล้มเหลว: หน้าที่แก้ไขโดยโหนดนั้นในธุรกรรมที่เสร็จสมบูรณ์จะอยู่ในแคชโกลบอลบน PowerHA โหนดจะรีสตาร์ทในการกำหนดค่าที่ลดลงบนหนึ่งในเซิร์ฟเวอร์ในคลัสเตอร์ ย้อนกลับธุรกรรมที่ค้างอยู่ และปลดล็อค
PowerHA ทำงานบนเซิร์ฟเวอร์สองเครื่อง และโหนดหลักจำลองสถานะพร้อมกัน หากโหนด PowerHA หลักล้มเหลว คลัสเตอร์จะยังคงทำงานต่อไปโดยใช้โหนดสำรอง
แน่นอนว่า หากคุณเข้าถึงชุดข้อมูลผ่านโหนดเดียว ประสิทธิภาพโดยรวมของคลัสเตอร์ก็จะสูงขึ้น PureScale ยังสามารถสังเกตได้ว่ามีการประมวลผลข้อมูลบางส่วนโดยโหนดเดียว จากนั้นโหนดทั้งหมดจะประมวลผลการล็อกที่เกี่ยวข้องกับพื้นที่นั้นโดยไม่ต้องสื่อสารกับ PowerHA แต่ทันทีที่แอปพลิเคชันพยายามเข้าถึงข้อมูลนี้ผ่านโหนดอื่น การประมวลผลการล็อคแบบรวมศูนย์จะกลับมาทำงานอีกครั้ง
การทดสอบภายในของ IBM เกี่ยวกับเวิร์กโหลดการอ่าน 90% และการเขียน 10% ซึ่งคล้ายกับเวิร์กโหลดการผลิตในโลกแห่งความเป็นจริงอย่างมาก แสดงสเกลเกือบเชิงเส้นสูงสุด 128 โหนด น่าเสียดายที่เงื่อนไขการทดสอบไม่ได้รับการเปิดเผย
HPE NonStop SQL
กลุ่มผลิตภัณฑ์ของ Hewlett-Packard Enterprise ยังมีแพลตฟอร์มที่พร้อมใช้งานสูงอีกด้วย นี่คือแพลตฟอร์ม NonStop ซึ่งออกสู่ตลาดในปี 1976 โดย Tandem Computers ในปี 1997 บริษัทถูกซื้อกิจการโดย Compaq ซึ่งต่อมาได้ควบรวมกิจการกับ Hewlett-Packard ในปี 2002
NonStop ใช้เพื่อสร้างแอปพลิเคชันที่สำคัญ เช่น HLR หรือการประมวลผลบัตรธนาคาร แพลตฟอร์มดังกล่าวนำเสนอในรูปแบบของซอฟต์แวร์และฮาร์ดแวร์ที่ซับซ้อน (อุปกรณ์) ซึ่งรวมถึงโหนดคอมพิวเตอร์ ระบบจัดเก็บข้อมูล และอุปกรณ์สื่อสาร เครือข่าย ServerNet (ในระบบสมัยใหม่ - Infiniband) ทำหน้าที่ทั้งการแลกเปลี่ยนระหว่างโหนดและการเข้าถึงระบบจัดเก็บข้อมูล
ระบบเวอร์ชันก่อนหน้าใช้โปรเซสเซอร์ที่เป็นกรรมสิทธิ์ซึ่งซิงโครไนซ์ระหว่างกัน: การดำเนินการทั้งหมดดำเนินการพร้อมกันโดยโปรเซสเซอร์หลายตัว และทันทีที่โปรเซสเซอร์ตัวใดตัวหนึ่งเกิดข้อผิดพลาด โปรเซสเซอร์ตัวใดตัวหนึ่งก็ถูกปิด และตัวที่สองยังคงทำงานต่อไป ต่อมาระบบได้เปลี่ยนไปใช้โปรเซสเซอร์แบบเดิม (MIPS ตัวแรก จากนั้นเป็น Itanium และสุดท้ายคือ x86) และเริ่มใช้กลไกอื่น ๆ สำหรับการซิงโครไนซ์:
- ข้อความ: แต่ละกระบวนการของระบบมีแฝด "เงา" ซึ่งกระบวนการที่ใช้งานอยู่จะส่งข้อความเกี่ยวกับสถานะของกระบวนการเป็นระยะ หากกระบวนการหลักล้มเหลว กระบวนการเงาจะเริ่มทำงานจากช่วงเวลาที่กำหนดโดยข้อความสุดท้าย
- การลงคะแนนเสียง: ระบบจัดเก็บข้อมูลมีส่วนประกอบฮาร์ดแวร์พิเศษที่ยอมรับการเข้าถึงที่เหมือนกันหลายรายการและดำเนินการเฉพาะเมื่อการเข้าถึงตรงกันเท่านั้น แทนที่จะซิงโครไนซ์ทางกายภาพ โปรเซสเซอร์จะทำงานแบบอะซิงโครนัส และผลลัพธ์ของงานจะถูกเปรียบเทียบในช่วงเวลา I/O เท่านั้น
ตั้งแต่ปี 1987 เป็นต้นมา DBMS เชิงสัมพันธ์ได้ทำงานบนแพลตฟอร์ม NonStop - SQL/MP ตัวแรก และ SQL/MX ในภายหลัง
ฐานข้อมูลทั้งหมดแบ่งออกเป็นส่วนๆ และแต่ละส่วนมีหน้าที่รับผิดชอบในกระบวนการ Data Access Manager (DAM) ของตัวเอง มีกลไกการบันทึกข้อมูล การแคช และการล็อค การประมวลผลข้อมูลดำเนินการโดยกระบวนการเซิร์ฟเวอร์ผู้ดำเนินการที่ทำงานบนโหนดเดียวกันกับตัวจัดการข้อมูลที่เกี่ยวข้อง ตัวกำหนดเวลา SQL/MX แบ่งงานระหว่างผู้ดำเนินการและรวมผลลัพธ์ เมื่อจำเป็นต้องทำการเปลี่ยนแปลงตามที่ตกลงไว้ จะใช้โปรโตคอลการคอมมิตแบบสองเฟสที่จัดทำโดยไลบรารี TMF (สิ่งอำนวยความสะดวกการจัดการธุรกรรม)
NonStop SQL สามารถจัดลำดับความสำคัญของกระบวนการเพื่อให้การสืบค้นเชิงวิเคราะห์ที่ยาวไม่รบกวนการดำเนินการธุรกรรม อย่างไรก็ตาม จุดประสงค์คือการประมวลผลธุรกรรมระยะสั้นอย่างแม่นยำ ไม่ใช่การวิเคราะห์ นักพัฒนารับประกันความพร้อมใช้งานของคลัสเตอร์ NonStop ที่ระดับห้า "เก้า" นั่นคือการหยุดทำงานเพียง 5 นาทีต่อปี
ทรัพย์ ฮานา
HANA DBMS (1.0) เวอร์ชันเสถียรรุ่นแรกเกิดขึ้นในเดือนพฤศจิกายน 2010 และแพ็คเกจ SAP ERP เปลี่ยนเป็น HANA ในเดือนพฤษภาคม 2013 แพลตฟอร์มนี้ใช้เทคโนโลยีที่ซื้อมา: TREX Search Engine (ค้นหาในที่เก็บข้อมูลแบบเรียงเป็นแนว), P*TIME DBMS และ MAX DB
คำว่า “HANA” เองเป็นตัวย่อว่า “เครื่องวิเคราะห์ประสิทธิภาพสูง” DBMS นี้จัดทำในรูปแบบของโค้ดที่สามารถทำงานบนเซิร์ฟเวอร์ x86 ใดก็ได้ อย่างไรก็ตาม การติดตั้งทางอุตสาหกรรมจะได้รับอนุญาตเฉพาะกับอุปกรณ์ที่ได้รับการรับรองเท่านั้น โซลูชันที่มีให้บริการจาก HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC การกำหนดค่า Lenovo บางอย่างอนุญาตให้ทำงานได้โดยไม่ต้องใช้ SAN - บทบาทของระบบจัดเก็บข้อมูลทั่วไปจะเล่นโดยคลัสเตอร์ GPFS บนดิสก์ในเครื่อง
ต่างจากแพลตฟอร์มที่กล่าวข้างต้น HANA เป็น DBMS ในหน่วยความจำ กล่าวคือ อิมเมจข้อมูลหลักจะถูกจัดเก็บไว้ใน RAM และเฉพาะบันทึกและสแน็ปช็อตเป็นระยะเท่านั้นที่จะถูกเขียนลงในดิสก์เพื่อการกู้คืนในกรณีที่เกิดภัยพิบัติ
โหนดคลัสเตอร์ HANA แต่ละโหนดมีหน้าที่รับผิดชอบในส่วนของข้อมูลของตนเอง และแผนผังข้อมูลจะถูกจัดเก็บไว้ในส่วนประกอบพิเศษ - เนมเซิร์ฟเวอร์ ซึ่งอยู่บนโหนดผู้ประสานงาน ข้อมูลจะไม่ซ้ำกันระหว่างโหนด ข้อมูลการล็อคจะถูกจัดเก็บไว้ในแต่ละโหนดเช่นกัน แต่ระบบมีตัวตรวจจับการหยุดชะงักส่วนกลาง
เมื่อไคลเอ็นต์ HANA เชื่อมต่อกับคลัสเตอร์ ไคลเอ็นต์จะดาวน์โหลดโทโพโลยี จากนั้นจึงสามารถเข้าถึงโหนดใดๆ ได้โดยตรง ขึ้นอยู่กับข้อมูลที่ต้องการ หากธุรกรรมส่งผลกระทบต่อข้อมูลของโหนดเดียว โหนดนั้นก็สามารถดำเนินการได้ภายในเครื่อง แต่หากข้อมูลของหลายโหนดเปลี่ยนแปลง โหนดเริ่มต้นจะติดต่อกับโหนดผู้ประสานงาน ซึ่งจะเปิดและประสานงานธุรกรรมแบบกระจาย โดยกระทำโดยใช้ โปรโตคอลการคอมมิตแบบสองเฟสที่ปรับให้เหมาะสม
โหนดผู้ประสานงานถูกทำซ้ำ ดังนั้นหากผู้ประสานงานล้มเหลว โหนดสำรองจะเข้าควบคุมทันที แต่ถ้าโหนดที่มีข้อมูลล้มเหลว วิธีเดียวที่จะเข้าถึงข้อมูลได้คือการรีสตาร์ทโหนด ตามกฎแล้ว คลัสเตอร์ HANA จะดูแลรักษาเซิร์ฟเวอร์สำรองเพื่อรีสตาร์ทโหนดที่สูญหายบนคลัสเตอร์โดยเร็วที่สุด
ที่มา: will.com