ทฤษฎีบท 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 ไม่ใช่ความสามารถในการปรับขนาดในแนวนอน แต่เป็นความทนทานต่อความผิดพลาด
หากโหนดหยุดตอบสนองต่อสัญญาณฮาร์ทบีท โหนดที่ตรวจพบสัญญาณนี้ก่อนจะเริ่มการโหวตดิสก์ หากโหนดที่หายไปยังคงไม่ตอบสนอง โหนดใดโหนดหนึ่งจะรับผิดชอบในการกู้คืนข้อมูล:
- "หยุด" ทุกหน้าที่อยู่ในแคชของโหนดที่หายไป
- อ่านบันทึกการทำซ้ำของโหนดที่หายไปและนำการเปลี่ยนแปลงที่บันทึกไว้ในบันทึกเหล่านี้มาใช้ใหม่ ในขณะที่ตรวจสอบว่าโหนดอื่นมีเวอร์ชันล่าสุดของเพจที่ถูกแก้ไขหรือไม่
- ย้อนกลับธุรกรรมที่ยังไม่เสร็จสิ้น
เพื่อลดความซับซ้อนของการทำ Failover ระหว่างโหนด Oracle จึงได้นำเสนอแนวคิดของบริการ นั่นคือ อินสแตนซ์เสมือน อินสแตนซ์สามารถรองรับบริการได้หลายบริการ และบริการสามารถย้ายข้อมูลระหว่างโหนดได้ อินสแตนซ์แอปพลิเคชันที่รองรับส่วนเฉพาะของฐานข้อมูล (เช่น กลุ่มไคลเอ็นต์) จะทำงานร่วมกับบริการหนึ่ง ในขณะที่บริการที่รับผิดชอบส่วนนั้นของฐานข้อมูลจะย้ายข้อมูลไปยังโหนดอื่นหากโหนดใดโหนดหนึ่งล้มเหลว
IBM Pure Data Systems สำหรับธุรกรรม
โซลูชันคลัสเตอร์สำหรับ DBMS ปรากฏในพอร์ตโฟลิโอของ Big Blue ในปี 2009 โดยในเชิงอุดมคติแล้ว โซลูชันนี้ถือเป็นตัวต่อยอดจากคลัสเตอร์ Parallel Sysplex ซึ่งสร้างขึ้นบนฮาร์ดแวร์ "ทั่วไป" ในปี 2009 DB2 pureScale ซึ่งเป็นชุดซอฟต์แวร์ได้เปิดตัว และในปี 2012 IBM ได้นำเสนออุปกรณ์ฮาร์ดแวร์และซอฟต์แวร์ชื่อ Pure Data Systems for Transactions อย่าสับสนกับ Pure Data Systems for Analytics ซึ่งก็คือ Netezza ที่เปลี่ยนชื่อใหม่นั่นเอง
เมื่อมองแวบแรก สถาปัตยกรรม pureScale จะคล้ายกับ Oracle RAC กล่าวคือ โหนดหลายโหนดเชื่อมต่อกับระบบจัดเก็บข้อมูลที่ใช้ร่วมกัน และแต่ละโหนดจะรันอินสแตนซ์ DBMS ของตัวเองพร้อมพื้นที่หน่วยความจำและบันทึกธุรกรรมของตัวเอง อย่างไรก็ตาม DB2 แตกต่างจาก Oracle ตรงที่มีบริการล็อกเฉพาะ ซึ่งแสดงด้วยชุดกระบวนการ db2LLM* ในการกำหนดค่าคลัสเตอร์ บริการนี้จะถูกปรับใช้กับโหนดแยกต่างหาก ซึ่งเรียกว่า coupling facility (CF) ใน Parallel Sysplex และ PowerHA ใน Pure Data
PowerHA มีบริการดังต่อไปนี้:
- ผู้จัดการบล็อค;
- แคชบัฟเฟอร์ทั่วโลก
- พื้นที่การสื่อสารระหว่างกระบวนการ
การเข้าถึงหน่วยความจำระยะไกลใช้เพื่อถ่ายโอนข้อมูลจาก PowerHA ไปยังโหนดฐานข้อมูลและย้อนกลับ ดังนั้นการเชื่อมต่อคลัสเตอร์จึงต้องรองรับโปรโตคอล RDMA PureScale สามารถใช้ทั้ง Infiniband และ RDMA ผ่านอีเทอร์เน็ตได้
หากโหนดต้องการเพจแต่ไม่ได้อยู่ในแคช โหนดจะร้องขอเพจจากแคชส่วนกลาง และจะอ่านเพจจากดิสก์ก็ต่อเมื่อไม่มีเพจนั้นอยู่ ซึ่งแตกต่างจาก Oracle ตรงที่คำขอจะส่งไปยัง PowerHA เท่านั้น ไม่ใช่โหนดข้างเคียง
เมื่ออินสแตนซ์แก้ไขแถว อินสแตนซ์จะล็อกแถวนั้นไว้ในโหมดเอกสิทธิ์ และเพจที่มีแถวนั้นไว้ในโหมดแชร์ ล็อกทั้งหมดจะถูกลงทะเบียนในตัวจัดการล็อกส่วนกลาง เมื่อธุรกรรมเสร็จสมบูรณ์ โหนดจะส่งข้อความไปยังตัวจัดการล็อก ซึ่งจะคัดลอกเพจที่แก้ไขแล้วไปยังแคชส่วนกลาง ปลดล็อก และยกเลิกการใช้งานเพจที่แก้ไขแล้วในแคชของโหนดอื่นๆ
หากเพจที่มีแถวที่กำลังถูกแก้ไขนั้นถูกล็อคอยู่แล้ว ตัวจัดการการล็อคจะอ่านเพจที่แก้ไขแล้วจากหน่วยความจำของโหนดที่ทำการแก้ไข ปลดการล็อค ทำให้เพจที่แก้ไขแล้วในแคชของโหนดอื่นไม่ถูกต้อง และส่งการล็อคเพจกลับไปยังโหนดที่ร้องขอ
"Dirty" หรือเพจที่แก้ไขแล้ว สามารถเขียนลงดิสก์ได้จากทั้งโหนดปกติและ 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 แพลตฟอร์ม NonStop ได้ใช้งาน DBMS เชิงสัมพันธ์ ซึ่งตัวแรกคือ SQL/MP และตัวหลังคือ SQL/MX
ฐานข้อมูลทั้งหมดถูกแบ่งออกเป็นส่วนต่างๆ ซึ่งแต่ละส่วนได้รับการจัดการโดยกระบวนการ Data Access Manager (DAM) ของตัวเอง กระบวนการนี้ทำหน้าที่บันทึกข้อมูล แคชข้อมูล และล็อกข้อมูล การประมวลผลข้อมูลจะถูกจัดการโดยกระบวนการ Executor Server ที่ทำงานบนโหนดเดียวกันกับตัวจัดการข้อมูลที่เกี่ยวข้อง ตัวจัดตารางเวลา SQL/MX จะแบ่งงานระหว่างตัวดำเนินการและรวบรวมผลลัพธ์ เมื่อจำเป็นต้องมีการเปลี่ยนแปลงที่สอดคล้องกัน จะมีการใช้โปรโตคอล commit แบบสองเฟสที่จัดเตรียมโดยไลบรารี TMF (Transaction Management Facility)
NonStop SQL สามารถจัดลำดับความสำคัญของกระบวนการต่างๆ เพื่อไม่ให้คิวรีวิเคราะห์ที่ยาวเกินไปรบกวนการทำงานของธุรกรรม อย่างไรก็ตาม วัตถุประสงค์ของมันคือการประมวลผลธุรกรรมสั้นๆ ไม่ใช่การวิเคราะห์ นักพัฒนารับประกันความพร้อมใช้งานของคลัสเตอร์ NonStop ที่ระดับห้า "เก้า" ซึ่งหมายความว่ามีเวลาหยุดทำงานเพียงห้านาทีต่อปี
ทรัพย์ ฮานา
การเปิดตัว HANA DBMS (1.0) ที่เสถียรครั้งแรกเกิดขึ้นในเดือนพฤศจิกายน 2010 และแพ็คเกจ SAP ERP ได้เปลี่ยนมาใช้ HANA ในเดือนพฤษภาคม 2013 แพลตฟอร์มนี้ใช้เทคโนโลยีที่ได้มา ได้แก่ TREX Search Engine (ค้นหาในที่เก็บข้อมูลแบบคอลัมน์), P*TIME DBMS และ MAX DB
คำว่า "HANA" ย่อมาจาก High Performance ANalytical Appliance DBMS นี้ถูกส่งเป็นโค้ดที่สามารถรันบนเซิร์ฟเวอร์ x86 ใดก็ได้ แต่การติดตั้งใช้งานจริงจะได้รับอนุญาตเฉพาะบนฮาร์ดแวร์ที่ผ่านการรับรองเท่านั้น โซลูชันต่างๆ มีจำหน่ายจาก HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi และ NEC การกำหนดค่าของ Lenovo บางรุ่นยังอนุญาตให้ใช้งานได้โดยไม่ต้องใช้ SAN โดยมีคลัสเตอร์ GPFS บนไดรฟ์ภายในทำหน้าที่เป็นพื้นที่จัดเก็บข้อมูลที่ใช้ร่วมกัน
ต่างจากแพลตฟอร์มที่ระบุไว้ข้างต้น HANA เป็น DBMS ในหน่วยความจำ ซึ่งหมายความว่าภาพข้อมูลหลักจะถูกเก็บไว้ใน RAM และมีเพียงบันทึกและสแนปช็อตตามระยะเวลาเท่านั้นที่จะถูกเขียนลงในดิสก์เพื่อการกู้คืนหลังภัยพิบัติ
แต่ละโหนดคลัสเตอร์ HANA มีหน้าที่รับผิดชอบข้อมูลส่วนของตนเอง และแผนผังข้อมูลจะถูกเก็บไว้ในส่วนประกอบเฉพาะ นั่นคือ เนมเซิร์ฟเวอร์ ซึ่งอยู่บนโหนดประสานงาน ข้อมูลจะไม่ถูกทำซ้ำระหว่างโหนด ข้อมูลล็อกจะถูกจัดเก็บไว้ในแต่ละโหนดเช่นกัน แต่ระบบจะมีตัวตรวจจับเดดล็อกส่วนกลาง
เมื่อเชื่อมต่อกับคลัสเตอร์ HANA ไคลเอ็นต์จะดาวน์โหลดโทโพโลยีของไคลเอ็นต์และสามารถเข้าถึงโหนดใดๆ ได้โดยตรงตามข้อมูลที่ต้องการ หากธุรกรรมส่งผลกระทบต่อข้อมูลบนโหนดเดียว โหนดนั้นสามารถดำเนินการภายในเครื่องได้ อย่างไรก็ตาม หากมีการแก้ไขข้อมูลบนหลายโหนด โหนดเริ่มต้นจะติดต่อกับโหนดประสานงาน ซึ่งจะเปิดและประสานงานธุรกรรมแบบกระจาย โดยคอมมิตธุรกรรมโดยใช้โปรโตคอลคอมมิตแบบสองเฟสที่ปรับให้เหมาะสม
โหนดประสานงานมีการทำซ้ำ ดังนั้นหากโหนดประสานงานล้มเหลว โหนดสำรองจะเข้ามาแทนที่ทันที อย่างไรก็ตาม หากโหนดข้อมูลล้มเหลว วิธีเดียวที่จะเข้าถึงข้อมูลได้คือการรีสตาร์ทโหนดนั้น โดยทั่วไป คลัสเตอร์ HANA จะมีเซิร์ฟเวอร์สำรองเพื่อรีสตาร์ทโหนดที่สูญหายให้เร็วที่สุด
ที่มา: will.com
