สมมติว่าคุณต้องตรวจสอบให้แน่ใจว่าแอปพลิเคชันของคุณที่ใช้ SQL Server 2012 เป็นแบ็กเอนด์ฐานข้อมูลของมันพร้อมใช้งานตลอดเวลาแม้ว่าเครื่องเซิร์ฟเวอร์หนึ่งเครื่องจะล้มเหลวก็ตาม

ในฐานะนักพัฒนาซอฟต์แวร์และไม่ใช่ DBA ฉันกำลังพยายามเข้าใจว่าจะใช้เมื่อใดกับสถานการณ์ที่ล้มเหลว / มีความพร้อมใช้งานสูง:

• เซิร์ฟเวอร์สองตัว (หรือมากกว่า) ในคลัสเตอร์ Windows Failover, SQL Server เป็นอินสแตนซ์ของคลัสเตอร์
• อินสแตนซ์ของ SQL Server สอง (หรือมากกว่า) ที่ได้รับการปรับปรุงด้วยการจำลองแบบของทรานแซคชัน
• เซิร์ฟเวอร์ SQL สองตัว (หรือมากกว่า) ใน SQL Server Availability Group ที่กำหนดค่าในโหมดการส่งข้อมูลแบบซิงโครนัส

สถานการณ์ใดบ้างที่เหมาะกับภาระงานประเภทใดและสถานการณ์ความล้มเหลว / การหยุดทำงานประเภทใดที่สามารถจัดการได้ พวกเขายังเปรียบได้ / แลกเปลี่ยนได้?

วิธีที่ฉันชอบเห็นภาพโซลูชันที่มีความพร้อมใช้งานสูงมีดังต่อไปนี้:

SQL Server Failover Cluster อินสแตนซ์ (FCI)

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

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

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

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

กลุ่มความพร้อมใช้งาน AlwaysOn

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

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

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

สิ่งที่เป็นนามธรรมลูกค้า? ใช่คุณสามารถเลือกกำหนดค่าฟังกลุ่มความพร้อมใช้งาน AlwaysOn ได้ นี่เป็นเพียงชื่อเครือข่ายเสมือน (สามารถมองเห็นได้ผ่าน WSFC เป็นทรัพยากรคลัสเตอร์ในกลุ่มคลัสเตอร์ของ AG) ที่ชี้ไปที่แบบจำลองหลักปัจจุบัน นี่เป็นส่วนสำคัญในการเลื่อนปริมาณงานการรายงานของคุณรวมถึงการตั้งค่ารายการเส้นทางแบบอ่านอย่างเดียวบนเซิร์ฟเวอร์ใด ๆ ที่คุณต้องการเปลี่ยนเส้นทางปริมาณการใช้งานแบบอ่านอย่างเดียว (นี่คือการตั้งค่าผ่านสายอักขระการเชื่อมต่อ เซิร์ฟเวอร์นี่จะเป็นพารามิเตอร์Application Intentตั้งค่าเป็นReadOnly ) คุณจะต้องตั้งค่า URL การกำหนดเส้นทางแบบอ่านอย่างเดียวสำหรับแต่ละเรพพลิกาที่คุณต้องการรับเวิร์กโหลดการรายงานนี้ในขณะที่อยู่ในบทบาทเรพพลิเคชันสำรอง

การจำลองแบบของทรานแซคชัน

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

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

สรุป

สิ่งที่ทำให้เกิดคำถามมากมายที่จำเป็นต้องได้รับคำตอบ (ธุรกิจส่วนหนึ่ง):

1. จะต้องมีอะไรพร้อมใช้งานสูง
2. อะไรSLAบอกให้เขียนสำหรับ HA / DR?
3. การรายงานประเภทใดที่จะเกิดขึ้นและเวลาในการตอบสนองเป็นเท่าใด
4. เราจำเป็นต้องจัดการกับHA ที่กระจายตัวทางภูมิศาสตร์อย่างไร (การจำลองแบบการจัดเก็บข้อมูลมีราคาแพง แต่ต้องมี FCI AGs ไม่ต้องการที่เก็บข้อมูลที่ใช้ร่วมกันจากอินสแตนซ์แบบสแตนด์อโลนและคุณสามารถใช้พยานการแชร์ไฟล์สำหรับองค์ประชุมที่อาจไม่จำเป็นต้องใช้พื้นที่เก็บข้อมูลร่วม)

เซิร์ฟเวอร์สองตัว (หรือมากกว่า) ในคลัสเตอร์ Windows Failover, SQL Server เป็นอินสแตนซ์ของคลัสเตอร์

1. ภาระงานประเภทใด "ขึ้นอยู่กับ" - แต่อย่างจริงจังนี่เป็นประโยชน์สำหรับแอปพลิเคชันออนไลน์ที่คุณต้องมีในศูนย์ข้อมูลความพร้อมใช้งานระดับสูง คุณได้รับการปกป้องจากความล้มเหลวของเครื่องหนึ่งเครื่องหรือระบบปฏิบัติการเดียว การเข้าสู่ระบบงานฐานข้อมูลใหม่การบำรุงรักษาและอื่น ๆ ทั้งหมดจะถูกเก็บไว้โดยอัตโนมัติโดยความจริงที่ว่ามันเป็นคลัสเตอร์ที่มีสองโหนที่เป็นเหมือนกันที่ใช้ร่วมกันที่เก็บข้อมูลเดียวกันเพื่อให้พวกเขามีฐานข้อมูลระบบเดียวกันทั้งหมด failover ที่รวดเร็วมาก แต่ยังคงมีอาการสะอึกที่ดูเหมือนว่า SQL Server รีสตาร์ทเมื่อเกิด failover

2. ข้อเสีย / ข้อกังวล - จุดเดียวของความล้มเหลวคือที่เก็บข้อมูลของคุณและส่วนประกอบทั้งหมด ผู้ค้า SAN มักจะพูดว่า "SAN ไม่ได้ล้มเหลว" แต่มีชิ้นส่วนที่เคลื่อนไหวมากมายในเครือข่ายพื้นที่จัดเก็บและเมื่อฉันบล็อกที่นี่พวกเขาก็สามารถทำได้ นอกจากนี้ - คุณกำลังจ่ายเงินสำหรับเซิร์ฟเวอร์รองที่ไม่สามารถทำอะไรได้นอกจากแฮงค์และรอ .. ตอนนี้คุณสามารถทำ Active / Active / Multi-Node และมีอินสแตนซ์ที่ใช้งานสองตัวที่สามารถ failover ในทิศทางใดทิศทางหนึ่งและใช้โหนดที่สอง

3. Automatic Failover? อัตโนมัติ "ที่สุด" ไม่จำเป็นต้องมีพยานมันเป็นกระจุก นี่คืองานของกลุ่มเพื่อให้ราบรื่นที่สุด ขณะนี้มีสิ่งเหล่านี้เมื่อเกิดความล้มเหลวคุณจะ "รู้สึก" เพราะ SQL ต้องเริ่มต้นทำงานหรือการเชื่อมต่อต้องชี้ไปที่ ที่นี่เมื่อมันเกิดขึ้นโดยทั่วไปคุณจะรู้สึกเหมือนการรีสตาร์ท SQL, DBs จะกลับมาและเรียกใช้การกู้คืน / ฯลฯ

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

อินสแตนซ์ของ SQL Server สอง (หรือมากกว่า) ที่ได้รับการปรับปรุงด้วยการจำลองแบบของทรานแซคชัน

1. ภาระงานประเภทใด ฉันจะไม่ไปที่นี่สำหรับกรณีที่ต้องการความพร้อมใช้งานสูงหรือการกู้คืนความเสียหายเป็นครั้งแรก ไม่ได้อยู่ใน SQL 2012 อย่างแน่นอน แต่โดยทั่วไปนี่เป็นสิ่งที่ดีถ้าคุณต้องไปที่ศูนย์ข้อมูลที่ไม่ได้ปิดคุณไม่สามารถใช้ AG ได้ (อาจเป็นปัญหาโดเมนที่ทำให้คุณไม่สามารถใช้งาน Windows คลัสเตอร์ที่ต้องการสำหรับ AG) บางทีคุณอาจต้องการ ในมาตรฐาน SQL Server ซึ่งสามารถทำการจำลองแบบได้ แต่ไม่ใช่ AGs แต่คุณยังต้องการมีความสามารถในการอ่านในด้านรองและไม่ตรงกัน
2. ข้อเสีย / ข้อกังวล -มันเป็นการจำลองแบบ มันมีค่าใช้จ่ายมันสามารถหลุดจากการซิงค์คุณสามารถพัฒนาปัญหาเกี่ยวกับประสิทธิภาพที่ด้านที่มาเป็นต้น
3. Automatic Failover - ไม่คุณต้องจัดการเอง ไม่ว่าจะผ่าน CNAME ที่ชี้ไปยังสิ่งใดสิ่งหนึ่งและในทางทฤษฎีคุณสามารถเขียนกระบวนการของคุณเองเพื่อทำสิ่งนี้ แต่ออกจากกล่องได้หรือไม่ หมายเหตุที่นี่

เซิร์ฟเวอร์ SQL สองตัว (หรือมากกว่า) ใน SQL Server Availability Group ที่กำหนดค่าในโหมดการส่งข้อมูลแบบซิงโครนัส

นี่คือสิ่งที่ฉันได้รับการช่วยเหลือผู้คนในการใช้งานมากขึ้นเมื่อเร็ว ๆ นี้แม้ว่าบางครั้งฉันยังคงไปที่การจัดกลุ่ม

1. ภาระงานประเภทใด นี้เป็นที่ดีเมื่อฉันมีชุดที่สามารถจัดการฐานข้อมูลที่เก็บไว้ในซิงค์และทรัพยากรและเวลาเพื่อให้แน่ใจว่างานเข้าสู่ระบบฐานข้อมูลใหม่เข้าพัก ฯลฯ ในการซิงค์ (แม้ว่าทีมที่ทักษะ SQL ได้สร้างที่ดีเพิ่มในการ ทำให้สิ่งนี้เป็นแบบอัตโนมัติสำหรับคุณทำให้ตัวเลือกนั้นแข็งแกร่งยิ่งขึ้น) ฉันชอบสิ่งนี้เมื่อฉันต้องการแยกสิ่งต่าง ๆ ออกจากกันโดยสิ้นเชิง ฉันป้องกันปัญหาฮาร์ดแวร์ปัญหาระบบปฏิบัติการปัญหาการติดตั้ง SQL ปัญหาการแพตช์และปัญหา SAN / Storage ฉันยังได้รับประโยชน์จากความสามารถในการมีรอง (ถ้าฉันต้องการจ่ายใบอนุญาตองค์กรสำหรับมัน) เป็นรองที่ใช้งานได้ที่ฉันสามารถอ่านสำรองข้อมูลเป็นต้นและในอนาคตฉันสามารถเพิ่มที่สามได้ ที่สองที่ไม่ซิงโครนัสที่ไซต์ระยะไกลและมี failover / DR
2. ข้อเสีย / ข้อกังวลการออกใบอนุญาตจำนวนสูงสุดของแบบจำลองต้นทุนการออกใบอนุญาตในการใช้ประโยชน์จากผลประโยชน์ที่ใหญ่ที่สุดบางอย่าง (แอ็คทีฟสำรอง) ต้องการองค์กรจำเป็นต้องใช้พื้นที่จัดเก็บมากกว่าการทำคลัสเตอร์เป็นสองเท่า
3. Automatic Failover - ใช่ สิ่งนี้สามารถเกิดขึ้นได้ด้วยการตั้งค่าการเป็นพยานและนักพัฒนาแอปของคุณสามารถเชื่อมต่อกับผู้ฟังแทนโหนดดังนั้นการเกิดความล้มเหลวเกิดขึ้นกับจุดที่ผู้ฟังชี้และคุณน่าจะอยู่ตรงนั้น ใช่คุณสามารถทำได้ที่นี่ - และควร - แต่แน่นอนคุณควรทดสอบให้ดี

สรุป

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

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

ยังเป็นสิ่งสำคัญที่จะต้องพิจารณาสิ่งที่ใช้ร่วมกัน

Failover Clustering ใช้สองหรือโหนดเซิร์ฟเวอร์อื่น ๆ ร่วมกันอย่างใดอย่างหนึ่งดิสก์อาร์เรย์ หากดิสก์อาร์เรย์หยุดทำงานแสดงว่าคุณสูญเสียบริการไม่ว่าจะมีโหนดเซิร์ฟเวอร์กี่เครื่องก็ตาม หากห้องเซิร์ฟเวอร์ที่ดิสก์อาเรย์นั้นติดไฟหรือท่วมคุณจะสูญเสียบริการ

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

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

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