Date: กุมภาพันธ์ 14, 2021
ป้ายกำกับ:SQL Server Failover Cluster
การใช้ Amazon FSX สำหรับอินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL – สิ่งที่คุณต้องรู้!
หากคุณกำลังพิจารณาปรับใช้อินสแตนซ์ Microsoft SQL Server ของคุณเองใน AWS EC2 คุณมีการตัดสินใจบางอย่างเกี่ยวกับความยืดหยุ่นของโซลูชัน แน่นอนว่า AWS จะเสนอ SLA 99.99% ให้กับทรัพยากรการประมวลผลของคุณหากคุณปรับใช้สองอินสแตนซ์ขึ้นไปในโซนความพร้อมใช้งานที่แตกต่างกัน แต่อย่าเพิ่งหลงเชื่อมีปัจจัยอื่น ๆ อีกมากมายที่คุณต้องพิจารณาเมื่อคำนวณความพร้อมใช้งานของแอปพลิเคชันที่แท้จริง ฉันเพิ่งเขียนบล็อกเกี่ยวกับวิธีคำนวณความพร้อมใช้งานแอปพลิเคชันของคุณในระบบคลาวด์ คุณควรอ่านบทความนั้นอย่างรวดเร็วก่อนที่จะดำเนินการต่อ
เมื่อพูดถึงการตรวจสอบให้แน่ใจว่าอินสแตนซ์ Microsoft SQL Server ของคุณพร้อมใช้งานสูงจริงๆแล้วจะมีตัวเลือกพื้นฐานสองตัวเลือก: Always On Availability Group (AG) หรือ SQL Server Failover Cluster Instance (FCI) หากคุณกำลังอ่านบทความนี้ฉันตั้งสมมติฐานว่าคุณทราบดีถึงตัวเลือกทั้งสองนี้และกำลังพิจารณาอย่างจริงจังที่จะใช้อินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL แทน SQL Server Always On AG
ประโยชน์ของอินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL ของ Microsoft
รายการต่อไปนี้สรุปสิ่งที่ AWS กล่าวว่าเป็นประโยชน์ของ SQL Server FCI:
โดยทั่วไปแล้ว FCI เป็นที่ต้องการมากกว่า AG สำหรับการปรับใช้ SQL Server ที่มีความพร้อมใช้งานสูงเมื่อสิ่งต่อไปนี้เป็นข้อกังวลลำดับความสำคัญสำหรับกรณีการใช้งานของคุณ:
ประสิทธิภาพต้นทุนใบอนุญาต: คุณต้องมีสิทธิ์การใช้งาน Enterprise Edition ของ SQL Server เพื่อเรียกใช้ AGs ในขณะที่คุณต้องการเพียงสิทธิ์การใช้งาน Standard Edition เพื่อเรียกใช้ FCI โดยทั่วไปแล้วราคาถูกกว่า Enterprise Edition 50–60% แม้ว่าคุณจะสามารถเรียกใช้ AG รุ่นพื้นฐานบน Standard Edition ได้โดยเริ่มจาก SQL Server 2016 แต่ก็มีข้อ จำกัด ในการรองรับฐานข้อมูลเพียงฐานข้อมูลเดียวต่อ AG สิ่งนี้อาจกลายเป็นความท้าทายเมื่อต้องจัดการกับแอปพลิเคชันที่ต้องใช้ฐานข้อมูลหลายฐานข้อมูลเช่น SharePoint
การป้องกันระดับอินสแตนซ์เทียบกับการป้องกันระดับฐานข้อมูล: ด้วย FCI อินสแตนซ์ทั้งหมดจะได้รับการป้องกัน – หากโหนดหลักไม่พร้อมใช้งานอินสแตนซ์ทั้งหมดจะถูกย้ายไปยังโหนดสแตนด์บาย สิ่งนี้จะดูแลการล็อกอินของ SQL Server งาน SQL Server Agent ใบรับรอง ฯลฯ ที่เก็บไว้ในฐานข้อมูลระบบซึ่งจัดเก็บทางกายภาพในที่เก็บข้อมูลแบบแบ่งใช้ ในทางกลับกันด้วย AG ในทางกลับกันเฉพาะฐานข้อมูลในกลุ่มเท่านั้นที่ได้รับการปกป้องและไม่สามารถเพิ่มฐานข้อมูลระบบลงใน AG ได้ – อนุญาตให้ใช้เฉพาะฐานข้อมูลผู้ใช้เท่านั้น เป็นความรับผิดชอบของผู้ดูแลระบบฐานข้อมูลในการทำซ้ำการเปลี่ยนแปลงอ็อบเจ็กต์ระบบในการจำลอง AG ทั้งหมด สิ่งนี้ทำให้ความเป็นไปได้ที่จะเกิดข้อผิดพลาดของมนุษย์ซึ่งทำให้ฐานข้อมูลไม่สามารถเข้าถึงแอปพลิเคชันได้
การสนับสนุนคุณลักษณะ DTC: หากคุณใช้ SQL Server 2012 หรือ 2014 และแอปพลิเคชันของคุณใช้ Distributed Transaction Coordinator (DTC) คุณจะไม่สามารถใช้ AG ได้เนื่องจากไม่ได้รับการสนับสนุน ใช้ FCI ในสถานการณ์นี้
ความท้าทายกับ FCI ในคลาวด์
แน่นอน. ความท้าทายในการสร้าง FCI ที่ครอบคลุมโซนความพร้อมใช้งานคือการขาดอุปกรณ์จัดเก็บข้อมูลที่ใช้ร่วมกันซึ่งโดยปกติจำเป็นต้องใช้ เนื่องจากโหนดของคลัสเตอร์ถูกกระจายไปตามศูนย์ข้อมูลหลายแห่ง SAN แบบดั้งเดิมจึงไม่ใช่ตัวเลือกที่ใช้ได้สำหรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน นั่นทำให้เรามีทางเลือกสองทางสำหรับการจัดเก็บคลัสเตอร์: ทรัพยากรระดับพื้นที่เก็บข้อมูลของบุคคลที่สามเช่น SIOS DataKeeper หรือ Amazon FSx ใหม่
มาดูสิ่งที่คุณต้องรู้ก่อนตัดสินใจเลือก
ข้อตกลงระดับการให้บริการ
ตามที่ฉันเขียนไว้ในวิธีคำนวณความพร้อมใช้งานแอปพลิเคชันของคุณ SLA แอปพลิเคชันโดยรวมของคุณนั้นดีพอ ๆ กับลิงก์ที่อ่อนแอที่สุดของคุณ ในกรณีนี้ FSx SLA 99.9%
โดยปกติความพร้อมใช้งาน 99.99% หมายถึงจุดเริ่มต้นของสิ่งที่ถือว่า "พร้อมใช้งานสูง" นี่คือสิ่งที่ AWS สัญญากับคุณสำหรับทรัพยากรการประมวลผลของคุณเมื่อมีการปรับใช้สองรายการขึ้นไปในโซนความพร้อมใช้งานที่แตกต่างกัน
ในกรณีที่คุณไม่ทราบความแตกต่างระหว่างสามเก้ากับสี่เก้า …
- ความพร้อมใช้งาน 99.9% ช่วยให้หยุดทำงานได้ 43.83 นาทีต่อเดือน
- ความพร้อมใช้งาน 99.99% ช่วยให้หยุดทำงานได้เพียง 4.38 นาทีต่อเดือน
ด้วยการโฮสต์พื้นที่จัดเก็บคลัสเตอร์ของคุณบน FSx แม้ว่าคุณจะมีความพร้อมในการประมวลผล 99.99% ความพร้อมใช้งานแอปพลิเคชันโดยรวมของคุณจะเป็น 99.9% ในทางตรงกันข้ามไดรฟ์ข้อมูล EBS ที่ครอบคลุมโซนความพร้อมใช้งานเช่นในการปรับใช้ DataKeeper จะมีคุณสมบัติสำหรับ SLA 99.99% ทั้งในชั้นพื้นที่จัดเก็บข้อมูลและการประมวลผล ซึ่งหมายความว่าความพร้อมใช้งานโดยรวมของคุณคือ 99.99%
สถานที่จัดเก็บ
เมื่อกำหนดค่า FSx เพื่อความพร้อมใช้งานสูงคุณจะต้องเปิดใช้งานการสนับสนุนหลาย AZ การเปิดใช้งานหลาย AZ จะทำให้คุณมี AZ ที่ "ต้องการ" และ AZ "สแตนด์บาย" ได้อย่างมีประสิทธิภาพ เมื่อคุณปรับใช้โหนด SQL Server FCI ของคุณคุณจะต้องการกระจายโหนดเหล่านั้นใน AZ เดียวกัน
ในสถานการณ์ปกติคุณจะต้องตรวจสอบให้แน่ใจว่าโหนดคลัสเตอร์ที่ใช้งานอยู่อยู่ใน AZ เดียวกับโหนดหน่วยเก็บข้อมูล FSx ที่ต้องการ นี่คือการลดระยะทางและเวลาแฝงในการจัดเก็บข้อมูลของคุณ แต่ยังช่วยลดค่าใช้จ่ายที่เกี่ยวข้องกับการถ่ายโอนข้อมูลข้าม AZ ด้วย ตามที่ระบุไว้ในคู่มือราคา FSx“ ค่าธรรมเนียมการถ่ายโอนข้อมูลมาตรฐานใช้สำหรับการเข้าถึงระบบไฟล์ระหว่าง AZ หรือระหว่างภูมิภาค”
ในสถานการณ์ที่โชคร้ายที่คุณมีความล้มเหลวของ SQL Server FCI แต่ไม่ใช่ความล้มเหลว FSx ไม่มีกลไกใดที่จะผูกทั้งพื้นที่จัดเก็บและคำนวณเข้าด้วยกัน ในกรณีที่ FSx ล้มเหลวจะกลับไปที่โซนความพร้อมใช้งานหลักโดยอัตโนมัติ อย่างไรก็ตามแนวทางปฏิบัติที่ดีที่สุดกำหนดให้ SQL FCI ยังคงทำงานบนโหนดรองจนกว่าจะมีการวิเคราะห์สาเหตุรากและโดยทั่วไปแล้วการล้มเหลวจะถูกกำหนดให้เกิดขึ้นในช่วงระยะเวลาการบำรุงรักษา ซึ่งจะทำให้คุณตกอยู่ในสถานการณ์ที่พื้นที่เก็บข้อมูลของคุณอยู่ใน AZ อื่นซึ่งจะต้องเสียค่าใช้จ่ายเพิ่มเติม ปัจจุบันค่าใช้จ่ายในการถ่ายโอนข้อมูลข้าม AZ ทั้งขาเข้าและขาออกคือ 0.01 ดอลลาร์ / GB
หากไม่จับตาดูสถานะ FSx และ SQL Server FCI ของคุณอย่างใกล้ชิดคุณอาจไม่รู้ด้วยซ้ำว่ากำลังทำงานอยู่ในภูมิภาคต่างๆจนกว่าคุณจะเห็นค่าธรรมเนียมการถ่ายโอนข้อมูลเมื่อสิ้นเดือน
ในทางตรงกันข้ามในคอนฟิกูเรชันที่ใช้ SIOS DataKeeper การล้มเหลวของหน่วยเก็บข้อมูลเป็นส่วนหนึ่งของการกู้คืน SQL Server FCI เพื่อให้แน่ใจว่าที่เก็บข้อมูลมักจะล้มเหลวด้วยอินสแตนซ์ SQL Server สิ่งนี้ทำให้มั่นใจได้ว่า SQL Server จะอ่านและเขียนไปยังไดรฟ์ข้อมูล EBS ที่เชื่อมต่อโดยตรงกับโหนดที่ใช้งานอยู่ โปรดทราบว่า DataKeeper จะต้องเสียค่าใช้จ่ายในการถ่ายโอนข้อมูลที่เกี่ยวข้องกับการดำเนินการเขียนซึ่งจำลองแบบระหว่าง AZ หรือภูมิภาค ต้นทุนการถ่ายโอนข้อมูลนี้สามารถลดลงได้ด้วยการใช้การบีบอัดที่มีอยู่ใน DataKeeper
การควบคุมล้มเหลว
ในคอนฟิกูเรชันหลายซับเน็ต FSx มีโซนความพร้อมใช้งานที่ต้องการและความพร้อมใช้งานสแตนด์บาย หากไฟล์เซิร์ฟเวอร์ FSx ในโซนความพร้อมใช้งานที่ต้องการประสบกับความล้มเหลวเซิร์ฟเวอร์ไฟล์ใน AZ สแตนด์บายจะกู้คืน AWS รายงานว่าเวลาในการกู้คืนนี้ใช้เวลาประมาณ 30 วินาทีกับการแชร์มาตรฐาน ด้วยการใช้การแชร์ไฟล์ที่มีอยู่อย่างต่อเนื่อง Microsoft รายงานว่าเวลาเฟลโอเวอร์นี้อาจใกล้ถึง 15 วินาที ในช่วงเวลาล้มเหลวนี้จะมีไฟดับที่เกิดขึ้นเมื่อการอ่านและการเขียนหยุดชั่วคราว แต่จะดำเนินต่อไปเมื่อการกู้คืนเสร็จสมบูรณ์
FSx หลายไซต์เปิดใช้งานข้อผิดพลาดอัตโนมัติ ซึ่งหมายความว่าสำหรับ FSx ที่ไม่ได้วางแผนไว้ทุกครั้งคุณจะมีข้อผิดพลาดที่ไม่ได้วางแผนไว้ด้วย ในทางตรงกันข้ามโดยทั่วไปเมื่อ SQL Server FCI ประสบกับความล้มเหลวที่ไม่ได้วางแผนไว้คุณอาจจะปล่อยให้มันทำงานในลำดับรองหรือกำหนดเวลาการล้มเหลวหลังจากชั่วโมงหรือในช่วงการบำรุงรักษาถัดไป
บริการวิเคราะห์เซิร์ฟเวอร์ SQL คลัสเตอร์ไม่รองรับ FSX
หากคุณต้องการคลัสเตอร์ SSAS คุณจะต้องมีทรัพยากรดิสก์แบบคลัสเตอร์เช่น SIOS DataKeeper เอกสารไวท์เปเปอร์ How to Cluster SQL Server Analysis Server ระบุอย่างชัดเจนว่าไม่สามารถใช้ SMB ได้และต้องใช้คลัสเตอร์ไดรฟ์ที่มีอักษรระบุไดรฟ์ ในทางตรงกันข้ามทรัพยากร DataKeeper Volume จะแสดงตัวเองเป็นดิสก์คลัสเตอร์และสามารถใช้กับ SSAS ได้
สรุป
แม้ว่า FSx จะเหมาะสมกับการใช้งาน SMB ทั่วไปเช่นไฟล์ผู้ใช้ Windows และบริการอื่น ๆ ที่ไม่สำคัญซึ่ง SLA ความพร้อมใช้งาน 99.9% เพียงพอ แต่ FSx เป็นตัวเลือกที่ยอดเยี่ยมหากแอปพลิเคชันของคุณต้องการความพร้อมใช้งานสูง (99.99%) หรือโซลูชัน HA / DR ที่ครอบคลุม ภูมิภาค SIOS DataKeeper คือขนาดที่เหมาะสม