Date: กันยายน 10, 2018
ป้ายกำกับ:Load Balance, PowerShell, Windows Server 2012, การทำซ้ำ, การปรับใช้, ตัวจัดการการกำหนดค่าระบบศูนย์, ผู้จัดการทรัพยากร Azure, พยานเมฆ, เซิร์ฟเวอร์ SQL หลายอินสแตนซ์
คุณสมบัติ Azure ILB ใหม่ช่วยให้คุณสามารถสร้างคลัสเตอร์ล้มเหลว SQL Server แบบหลายกรณีใน Azure
คุณลักษณะใหม่ Cloud Witness เป็นที่ชื่นชอบในขณะนี้ ก่อนที่เราจะดูที่คุณลักษณะใหม่ขององค์ประชุมใน Windows Server 2016 ฉันคิดว่าสิ่งสำคัญคือต้องรู้ว่าเรามาจากที่ใด ในบทความก่อนหน้าของฉันการทำความเข้าใจเกี่ยวกับองค์รวมของเซิร์ฟเวอร์ Windows Server 2003 ในคลัสเตอร์ Windows Server 2012 ฉันเข้าสู่รายละเอียดบางอย่างเกี่ยวกับประวัติและวิวัฒนาการของ quorum ของคลัสเตอร์ ขอแนะนำให้คุณตรวจสอบว่าโพสต์เข้าใจว่าโควรัมทำงานได้อย่างไรใน Windows Server 2012 R2 นอกจากนี้คุณลักษณะใหม่ ๆ ของ Windows Server 2016 จะทำให้การปรับใช้คลัสเตอร์ของคุณมีความยืดหยุ่นมากขึ้นได้อย่างไร
พยานเมฆ
พยาน Cloud ช่วยให้คุณสามารถใช้ Azure Blob Storage เพื่อทำหน้าที่เป็นพยานให้กับกลุ่มของคุณได้ พยานคนนี้จะอยู่ในสถานที่ของพยานดิสก์หรือแบ่งปันไฟล์พยาน การกำหนดค่าของ Cloud Witness ทำได้ง่ายมาก จากประสบการณ์ของฉันค่าใช้จ่ายถัดไปไม่มีอะไรที่จะเป็นเจ้าภาพใน Azure ข้อเสียเพียงอย่างเดียวคือโหนดคลัสเตอร์จะต้องสามารถสื่อสารผ่านอินเทอร์เน็ตได้ด้วย Azure Blob Storage ของคุณ บ่อยครั้งที่โหนดคลัสเตอร์ห้ามไม่ให้สื่อสารกับอินเทอร์เน็ตสาธารณะ ดังนั้นคุณจะต้องประสานงานกับทีมรักษาความปลอดภัยของคุณหากคุณต้องการเปิดใช้งาน Cloud Witness มีเหตุผลที่น่าสนใจมากมายสำหรับการใช้ Cloud Witness เพื่อสร้างคลัสเตอร์ล้มเหลวของ SQL Server แบบหลายอินสแตนซ์ใน Azure แต่สำหรับฉันมันทำให้รู้สึกมากที่สุดในสามสภาพแวดล้อมที่เฉพาะเจาะจงมาก: Failover Cluster ใน Azure, Branch Office Clusters และ Multisite Clusters
เมื่อมองใกล้
ลองดูที่แต่ละสถานการณ์เพื่อดูว่า Cloud Witness สามารถช่วยได้อย่างไร รูปที่ 1 – เมื่อคุณกำลังพยายามสร้าง SQL Server Failover Cluster แบบหลายอินสแตนซ์ใน Azure บัญชีเก็บข้อมูลระบบคลาวด์ควรได้รับการกำหนดค่าที่เก็บข้อมูลแบบ redundant Storage ตามปกติ (LRS) [/ คำอธิบาย]
การใช้งานที่มีการใช้งานสูง
หากคุณกำลังย้ายไปที่ Azure (หรือผู้ให้บริการระบบคลาวด์จริงๆ) คุณจะต้องการให้แน่ใจว่าการปรับใช้ของคุณมีให้ใช้งานได้มาก หากคุณกำลังดำเนินการเกี่ยวกับ SQL Server, File Servers, SAP หรือภาระงานอื่น ๆ ที่รวมกลุ่มกันแบบคลัสเตอร์กับ Windows Server Failover Clustering คุณจะต้องใช้พยานแชร์ไฟล์หรือ Cloud Witness เนื่องจากไม่สามารถใช้ Disk Witness ใน Azure ได้ ด้วย Windows Server 2012 R2 หรือ Windows Server 2008 R2 คุณจะต้องใช้ Share Share Share กับ Witness Windows Server 2016 ทำให้สามารถใช้ Cloud Witness ได้ ข้อได้เปรียบของ Cloud Witness คือคุณไม่จำเป็นต้องรักษาอินสแตนซ์อื่นของ Windows ใน Azure เพื่อโฮสต์ไฟล์แชร์ แต่ Microsoft ช่วยให้คุณสามารถใช้ประโยชน์จากพื้นที่เก็บข้อมูลแบบหยดได้ วิธีนี้จะช่วยให้คุณได้รับโซลูชันที่มีราคาไม่แพงซึ่งเป็นวิธีที่ง่ายในการจัดการและยืดหยุ่นมากขึ้น
ที่ตั้ง
เมื่อมองไปที่การปรับใช้คลัสเตอร์ในสำนักงานสาขาค่าใช้จ่ายและการบำรุงรักษาอยู่เสมอพิจารณา สำหรับห่วงโซ่การค้าปลีกที่มีสถานที่นับร้อยหรือหลายพันแห่งการมี SAN ในแต่ละตำแหน่งอาจเป็นสิ่งที่ต้องห้ามปราม แต่ละตำแหน่งอาจเรียกใช้โหนดคลัสเตอร์ Hyper-V สองโหนดในคอนฟิกูเรชันที่ผสานรวม Hyper-S2D หรือโซลูชันการจำลองแบบของ บริษัท อื่นเพื่อโฮสต์เครื่องเสมือนหลายเครื่อง ตอนนี้สิ่งที่ Cloud Witness สามารถทำได้คือช่วยให้ธุรกิจหลีกเลี่ยงค่าใช้จ่ายในการเพิ่มเซิร์ฟเวอร์ทางกายภาพเพิ่มเติมในแต่ละตำแหน่งเพื่อทำหน้าที่เป็น Share Share Share หรือเพิ่มต้นทุนในการเพิ่ม SAN ไปยังสถานที่แต่ละแห่ง
ขจัดความต้องการศูนย์ข้อมูลที่ 3
และในที่สุดเมื่อใช้งานกลุ่มแบบหลายกลุ่ม Cloud Witness ช่วยลดความจำเป็นในการเป็นศูนย์กลางข้อมูลที่ 3 เพื่อเป็นเจ้าภาพจัดการแชร์ไฟล์ ก่อนที่จะมีการนำ Cloud Witness แนวทางที่ดีที่สุดจะชี้ให้เห็นว่าพยานแชร์ไฟล์อาศัยอยู่ในตำแหน่งที่ 3 การเข้าถึงดาต้าเซ็นเตอร์อันดับที่ 3 เพื่อเป็นเจ้าภาพในการเป็นพยานร่วมกันของไฟล์ไม่ได้เป็นไปได้เสมอไปและยังได้นำเสนออีกหนึ่งชั้นของความซับซ้อน การใช้ Cloud Witness ทำให้คุณไม่จำเป็นต้องรักษาตำแหน่งที่ตั้งที่ 3 และสามารถเข้าถึงพยานได้จากอินเทอร์เน็ตสาธารณะลดความต้องการของเครือข่ายด้วย
การรับรู้ไซต์
เมื่อสร้างกลุ่ม multisite มีปัญหาอื่น ๆ อยู่เสมอ การควบคุม failover เพื่อให้เหมาะกับไซต์ในท้องถิ่นเป็นไปไม่ได้ แม้ว่าคุณจะสามารถระบุเจ้าของที่ต้องการได้การตั้งค่าเจ้าของที่ต้องการจะเข้าใจผิดโดยทั่วไป ผู้ดูแลระบบอาจไม่ได้ตระหนักถึงสิ่งนี้ แต่คุณรู้หรือไม่แม้ว่าจะไม่ได้ระบุเซิร์ฟเวอร์ว่าเป็น Preferred Owner เซิร์ฟเวอร์จะถูกผนวกโดยอัตโนมัติไปยังจุดสิ้นสุดของรายการ Preferred Owners ที่จัดทำโดยคลัสเตอร์ ผลลัพธ์ของความเข้าใจผิดนี้คือแม้ว่าคุณอาจระบุเฉพาะเซิร์ฟเวอร์ภายในเครื่องเป็น Preferred Owners คุณอาจมี failover ทรัพยากรคลัสเตอร์ไปยังไซต์ DR และนี่คือแม้กระทั่งเมื่อมีโหนดที่สมบูรณ์แบบที่ดีที่มีอยู่ในไซต์ท้องถิ่น เห็นได้ชัดว่านี่ไม่ใช่สิ่งที่คุณคาดหวังและการใช้การรับรู้ไซต์จะช่วยขจัดปัญหานี้ให้ก้าวไปข้างหน้า การรับรู้ไซต์ช่วยแก้ปัญหานี้ได้โดยเลือกไซต์ท้องถิ่นเสมอเมื่อตัดสินใจเลือกโหนดเพื่อนำทางออนไลน์ ดังนั้นในกรณีปกติภาระงานที่คลัสเตอร์จะเข้าแทนที่โหนดภายในเสมอจนกว่าคุณจะหยุดทำงานโดยสมบูรณ์ ในกรณีที่หนึ่งในโหนด DR จะมาออนไลน์ เดียวกันถือเป็นจริงเมื่อคุณกำลังทำงานอยู่ในไซต์ DR คลัสเตอร์จะกู้คืนปริมาณงานบนเซิร์ฟเวอร์ในไซต์ DR ถ้าทำงานก่อนหน้านี้บนโหนดในไซต์ DR การรับรู้ไซต์มักจะชอบโหนดภายใน
โดเมนข้อบกพร่อง
การสร้างความตระหนักในไซต์เป็นโดเมนฟอรัม โดเมนข้อบกพร่องจะไปอีกขั้นและช่วยให้คุณสามารถกำหนดตำแหน่งโหนด Chasse และ Rack นอกเหนือจากไซต์ได้ โดเมนข้อบกพร่องมีประโยชน์สามประการคือความเกี่ยวข้องกับการจัดเก็บในกลุ่มแบบยืดอายุการเก็บข้อมูลที่เพิ่มขึ้นทำให้พื้นที่เก็บข้อมูลมีความยืดหยุ่นเพิ่มขึ้น ช่วยเพิ่มการแจ้งเตือนเกี่ยวกับบริการสุขภาพโดยการรวมข้อมูลเมตาเกี่ยวกับตำแหน่งของแหล่งข้อมูลที่เกี่ยวข้องซึ่งเป็นการปลุก ความเกี่ยวข้องในการจัดเก็บจะช่วยให้แน่ใจได้ว่ากลุ่มงานและพื้นที่เก็บข้อมูลของคุณทำงานอยู่ในตำแหน่งเดียวกัน คุณไม่ต้องการให้ VM อ่านและเขียนข้อมูลที่อยู่ใน CSV ในเมืองอื่น อย่างไรก็ตามผมคิดว่าผู้ชนะที่ใหญ่ที่สุดในที่นี้คือ Space Space Storage (S2D) SD2 จะใช้ประโยชน์จากข้อมูลที่คุณระบุเกี่ยวกับตำแหน่งของคลัสเตอร์โหนด (ไซต์แร็คแชสซี) เพื่อให้แน่ใจว่าสำเนาข้อมูลที่เขียนขึ้นเพื่อความซ้ำซ้อนทั้งหมดจะอยู่ในโดเมนฟอรัมที่แตกต่างกัน ช่วยให้แน่ใจได้ว่าการจัดวางข้อมูลได้รับการปรับให้เหมาะสมเพื่อให้ความล้มเหลวของ Single Node, Chassis, Rack หรือ Site ไม่สามารถลดการใช้งาน S2D ทั้งหมดได้ คอสมอสดาร์วินมีวิดีโอยอดเยี่ยมในช่อง 9 ซึ่งอธิบายถึงแนวคิดนี้อย่างละเอียด
สรุป
Windows Server 2016 เพิ่มการปรับปรุงใหม่ ๆ ให้กับองค์รวมของคลัสเตอร์ซึ่งจะให้ประโยชน์ในทันทีกับการปรับใช้คลัสเตอร์ของคุณ นอกจากนี้โปรดตรวจสอบการปรับปรุงคลัสเตอร์ใหม่ ๆ ที่น่าสนใจอื่น ๆ เช่นการปรับรุ่นระบบกลิ้ง, ความยืดหยุ่นของเครื่องเสมือน, Workgroup และกลุ่มโดเมนหลายแห่งและอื่น ๆ หากต้องการอ่านเกี่ยวกับเคล็ดลับอื่น ๆ เช่นการสร้าง SQL Server Failover Cluster In-One แบบหลายอินสแตนซ์ใน Azure กับ Cloud Witness โปรดอ่านบทความของเรา ทำซ้ำโดยได้รับอนุญาตจาก Clusteringformeremortals.com