Date: มีนาคม 13, 2018
ป้ายกำกับ:SQL Server Failover Cluster
ทำไมคุณถึงต้องการสร้างอินสแตนซ์ของคลัสเตอร์ Failover Cluster ในเซิร์ฟเวอร์ Azure Cloud?
มีการอภิปรายที่น่าสนใจเกิดขึ้นในวันนี้ที่ Twitterverse โดยทั่วไปมีคนถามคำถาม“ มีใครตั้งค่าเซิร์ฟเวอร์ SQL Failover Cluster Instance ใน Azure หรือไม่” การสนทนาที่ตามมาเกี่ยวข้องกับผู้เชี่ยวชาญ SQL Server ที่เคารพนับถือ และจะนำไปสู่คำถามต่อไปนี้ "ทำไมคุณต้องสร้างอินสแตนซ์ของคลัสเตอร์ Failover Cluster ของ SQL Server AlwaysOn ในคลาวด์"
คำถามนั้นสามารถตีความได้สองวิธี:“ เหตุใดคุณจึงต้องการความพร้อมใช้งานสูงในระบบคลาวด์” หรือ“ ทำไมคุณไม่ใช้กลุ่มความพร้อมใช้งาน AlwaysOn แทนกลุ่มอินสแตนซ์ของ Failover Cluster”
ลองตอบคำถามแต่ละข้อในแต่ละครั้ง
คำถามที่ 1 – ทำไมคุณต้องมีความพร้อมใช้งานสูงใน Azure Cloud?
- คุณอาจคิดว่าเพียงเพราะคุณโฮสต์อินสแตนซ์ SQL Server ของคุณใน Azure ว่าคุณได้รับการคุ้มครองโดย SLA uptime 99.95% ถ้าคุณคิดว่าคุณจะผิด เพื่อที่จะใช้ประโยชน์จาก SLA 99.95% คุณต้องมีอินสแตนซ์ SQL อย่างน้อยสองชุดที่ทำงานอยู่ในชุดผลิตภัณฑ์ที่พร้อมใช้งาน ด้วยอินสแตนซ์เดียวของการทำงานของ SQL คุณสามารถคาดหวังได้อย่างแน่นอนว่าจะมีเวลาหยุดทำงานน้อยที่สุดในช่วงเวลาการบำรุงรักษา แต่คุณยังอ่อนแอต่อความล้มเหลวที่ไม่คาดคิด
- อินสแตนซ์ที่สองของ SQL Server ไม่สามารถโหลดสมดุลได้ คุณต้องใช้กลไกบางอย่างเพื่อให้เซิร์ฟเวอร์ซิงค์กัน เพื่อให้แน่ใจว่าหากมีปัญหากับเซิร์ฟเวอร์เครื่องใดเครื่องหนึ่งเซิร์ฟเวอร์อื่นจะสามารถดำเนินการต่อเพื่อขอรับบริการต่อได้ โซลูชันความพร้อมใช้งานสูงเช่น AlwaysOn Availability Groups, AlwaysOn Failover Cluster Instances และแม้แต่ Mirroring ฐานข้อมูลที่เลิกใช้ก็สามารถให้บริการ SQL Server ในสถานการณ์ดังกล่าวได้ดี โซลูชันอื่น ๆ เช่นการจัดส่งบันทึกและการจำลองแบบธุรกรรมอาจช่วยให้สามารถซิงค์ข้อมูลระหว่างเซิร์ฟเวอร์ได้ แต่จะไม่ถือว่าเป็นโซลูชันที่พร้อมใช้งานสูงและจะไม่รับประกันความพร้อมใช้งานของ SQL Server ของคุณ
- บางครั้ง Microsoft จำเป็นต้องทำการบำรุงรักษา Azure ซึ่งอาจทำให้โดเมนอัปเกรดทั้งหมดและอินสแตนซ์ทั้งหมดที่ทำงานอยู่ในโดเมนการอัปเกรดนั้น คุณไม่ได้มีการพูดเมื่อใดที่จะเกิดขึ้น ดังนั้นคุณจำเป็นต้องมีกลไกเพื่อให้แน่ใจว่าหากจำเป็นต้องนำอินสแตนซ์ SQL Server หลักของคุณออกคุณสามารถคาดหวังว่าอินสแตนซ์ SQL Server สำรองของคุณจะใช้เวลามากกว่าภาระงานโดยไม่พลาดจังหวะ โซลูชันความพร้อมใช้งานทั้งหมดที่กล่าวมาข้างต้นสามารถมั่นใจได้ว่าคุณจะยังคงทำงานต่อไปในกรณีที่ Microsoft ดำเนินการบำรุงรักษาในโดเมนการอัปเกรดของเซิร์ฟเวอร์หลักของคุณ Microsoft จะดำเนินการบำรุงรักษาในโดเมนอัปเกรดเดียวในเวลาเดียวกัน วิธีนี้จะทำให้แน่ใจได้ว่าเซิร์ฟเวอร์สำรองของคุณจะออนไลน์อยู่เสมอโดยสมมติว่าคุณใส่ทั้งสองชุดไว้ในชุดการจองห้องพักเดียวกัน
- คุณจะทำอย่างไรถ้าต้องการการบำรุงรักษาประสิทธิภาพการผลิตใน SQL Server ของคุณ? บางทีคุณอาจต้องการติดตั้ง Service Pack หรือโปรแกรมแก้ไขด่วนอื่น ๆ ? หากไม่มีเซิร์ฟเวอร์รองที่ไม่ผ่านไปคุณจะต้องกำหนดเวลาหยุดทำงานตามแผน หนึ่งในข้อดีหลัก ๆ ของโซลูชันความพร้อมใช้งานที่มีประสิทธิภาพสูงคือความสามารถในการอัพเกรดกลิ้งเพื่อลดผลกระทบจากการหยุดทำงานที่วางแผนไว้
คำถามที่ 2 – เหตุใดคุณจึงไม่ใช้ AlwaysOn Availability Groups แทน Failover Cluster Instances?
- ประหยัดเงิน! เซิร์ฟเวอร์ SQL Server AlwaysOn ต้องการ Enterprise Edition ของ SQL Server ทำไมไม่ประหยัดเงินและปรับใช้ SQL Server Standard Edition และสร้างอินสแตนซ์คลัสเตอร์ล้มเหลว 2 โหนด? ถ้าคุณไม่ต้องการ Enterprise Edition ด้วยเหตุผลอื่น ๆ นี่เป็นเกมง่ายๆ
- ป้องกันอินสแตนซ์ SQL Server ทั้งหมด กลุ่มความพร้อมใช้งาน AlwaysOn จะป้องกันฐานข้อมูลที่ผู้ใช้กำหนดเท่านั้น คุณไม่สามารถปกป้องฐานข้อมูล System และ MSDB ได้ ถ้าคุณสร้างอินสแตนซ์ของคลัสเตอร์ล้มเหลวของ SQL Server แทนคุณกำลังปกป้องอินสแตนซ์ทั้งหมดรวมถึงฐานข้อมูล System และ MSDB
- ง่ายต่อการบริหาร ใน Azure คุณจะถูก จำกัด ให้เฉพาะกับผู้ฟังที่เป็นลูกค้าเท่านั้น ซึ่งจะ จำกัด ให้คุณเป็นเพียงกลุ่มที่พร้อมให้บริการเท่านั้น ในทางตรงกันข้ามกับ Failover Cluster Instance ผู้ฟังไคลเอ็นต์เพียงรายเดียวคือสิ่งที่คุณต้องการเท่านั้นจึงไม่มีข้อ จำกัด
- ความเหนื่อยล้าของคนงาน AlwaysOn AG คุณต้องคอยสังเกตกระทู้ของคนทำงานที่มีอยู่ เธรดของผู้ปฏิบัติงานที่พร้อมใช้งาน จำกัด จำนวนฐานข้อมูลที่คุณสามารถป้องกันได้ด้วย AlwaysOn AG ในทางตรงกันข้าม AlwaysOn Failover Clustering ที่มีการจำลองแบบระดับบล็อก DataKeeper ไม่ใช้ทรัพยากรมากขึ้นสำหรับแต่ละฐานข้อมูลที่คุณเพิ่ม ซึ่งหมายความว่าคุณสามารถปรับขนาดเพื่อปกป้องฐานข้อมูลนับร้อยโดยไม่มีค่าใช้จ่ายเพิ่มเติมที่เกี่ยวข้องกับ AlwaysOn AG
- กระจายการสนับสนุนธุรกรรม AlwaysOn AG ไม่สนับสนุนธุรกรรมแบบกระจาย (DTC) หากแอ็พพลิเคชันของคุณต้องการการสนับสนุน DTC คุณจะต้องดูที่ AlwaysOn Failover Cluster Instance แทน
- การสนับสนุนเทคโนโลยีการจำลองแบบอื่น ๆ ถ้าคุณวางแผนที่จะตั้งค่าการจำลองแบบ Peer to Peer ระหว่างฐานข้อมูลสองแห่งที่มีการป้องกันโดย AlwaysOn AG คุณสามารถลืมได้ ในความเป็นจริงมีข้อ จำกัด หลายอย่างที่คุณควรทราบเมื่อคุณปรับใช้ AlwaysOn Availability Groups AlwaysOn FCI ไม่มีข้อ จำกัด ดังกล่าว
ข้อสรุป
การรู้ว่าคุณรู้อะไรข้างต้นไม่ควรถามจริงๆว่า "ทำไมฉันต้องใช้ AlwaysOn AG ใน Cloud เมื่อฉันสามารถมีวิธีแก้ปัญหาการสต๊อกแบบ AlwaysOn Failover Cluster ที่มีประสิทธิภาพมากขึ้นและราคาไม่แพง?"
หากคุณมีความสนใจในการสร้างอินสแตนซ์ของคลัสเตอร์ล้มเหลว AlwaysOn ใน Azure ให้ตรวจสอบบล็อกโพสต์ของฉันทีละขั้นตอน: วิธีการกำหนดค่าเซิร์ฟเวอร์อินสแตนซ์ของคลัสเตอร์ล้มเหลว SQL Server ใน Microsoft Azure