คุณสมบัติ Azure ILB ใหม่ให้คุณสร้างคลัสเตอร์ Failover SQL Server แบบหลายอินสแตนซ์
ที่ Microsoft Ignite เมื่อเดือนกันยายนที่ผ่านมา Microsoft ได้ประกาศเกี่ยวกับ Azure หนึ่งในประกาศเหล่านี้คือความพร้อมใช้งานทั่วไปของวีไอพีหลาย ๆ ตัวเกี่ยวกับตัวโหลดบาลานซ์ภายใน เหตุใดจึงสำคัญกับ SQL Server DBA จนถึงตอนนี้ถ้าคุณต้องการปรับใช้ SQL Server ที่มีความพร้อมใช้งานสูงใน Azure คุณจะถูก จำกัด ให้ใช้ FCI เซิร์ฟเวอร์ SQL เดียวต่อหนึ่งคลัสเตอร์หรือกลุ่มผู้ฟังกลุ่มความพร้อมใช้งานเพียงครั้งเดียว ข้อ จำกัด นี้บังคับให้คุณปรับใช้คลัสเตอร์ใหม่สำหรับแต่ละอินสแตนซ์ของ SQL Server ที่คุณต้องการป้องกันใน Failover Cluster นอกจากนี้ยังบังคับให้คุณจัดกลุ่มฐานข้อมูลทั้งหมดของคุณลงในกลุ่มความพร้อมใช้งานเดียวหากคุณต้องการการเปลี่ยนเส้นทางอัตโนมัติและการเปลี่ยนเส้นทางไคลเอ็นต์ในการกำหนดค่า AlwaysOn AG ของคุณ
วิธีออกจากข้อ จำกัด เหล่านี้
ข้อ จำกัด เหล่านั้นได้รับการยกขึ้นด้วยคุณสมบัติใหม่ของ ILB ในบทความนี้ฉันจะแนะนำคุณเกี่ยวกับขั้นตอนการปรับใช้ SQL Server FCI ใน Azure ที่มีอินสแตนซ์ของ SQL Server สองอิน ในการโพสต์ในอนาคตฉันจะแนะนำคุณผ่านกระบวนการเดียวกันสำหรับ SQL Server AlwaysOn AG
เริ่มต้นด้วยคลัสเตอร์ล้มเหลวเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์
สร้างอินสแตนซ์พื้นฐานเดียวของ SQL Server FCI ใน Azure ตามที่อธิบายในโพสต์ของฉันการปรับใช้ Microsoft SQL Server 2014 Failover Clusters ใน Azure Resource Manager โพสต์นั้นอธิบายกระบวนการสร้างคลัสเตอร์ Failover Cluster Server แบบหลายอินสแตนซ์ ใช้ DataKeeper เพื่อสร้างทรัพยากรโวลุ่มที่จำลองแบบแล้วซึ่งใช้ในคลัสเตอร์ลองสร้าง Internal Load Balancer (ILB) แล้วแก้ไขทรัพยากร IP ของคลัสเตอร์ SQL Server Cluster เพื่อทำงานกับ ILB หากคุณต้องการข้ามกระบวนการนั้นและเริ่มต้นการกำหนดค่าของคุณคุณสามารถใช้เทมเพลตการปรับใช้ Azure ที่สร้าง FCI เซิร์ฟเวอร์ SQL แบบ 2 โหนดโดยใช้ SIOS DataKeeper สมมติว่าตอนนี้คุณมีโหนดพื้นฐาน SQL Server FCI สองขั้นตอนแล้ว อินสแตนซ์มีดังนี้:
- สร้าง DataKeeper Volume Resource อื่นในโวลุ่มอื่นที่ไม่ได้ใช้งานอยู่ในปัจจุบัน คุณอาจต้องเพิ่มดิสก์เพิ่มเติมในอินสแตนซ์ Azure ของคุณหากคุณไม่มีโวลุ่มที่พร้อมใช้งาน เป็นส่วนหนึ่งของกระบวนการสร้างโวลุ่มนี้ทรัพยากร DataKeeper Volume ใหม่จะถูกลงทะเบียนใน Available Storage ในคลัสเตอร์ อ้างถึงบทความที่อ้างถึงก่อนหน้านี้สำหรับรายละเอียด
- ติดตั้งอินสแตนซ์ที่มีชื่อของ SQL Server บนโหนดแรกโดยระบุ DataKeeper Volume ที่เราเพิ่งสร้างเป็นที่เก็บข้อมูล
- “ เพิ่มโหนด” ในคลัสเตอร์บนโหนดที่สอง
- ล็อคหมายเลขพอร์ตของอินสแตนซ์ที่มีชื่อใหม่นี้ลงในพอร์ตที่ไม่ได้ใช้งาน ในตัวอย่างของฉันฉันใช้พอร์ต 1440
ปรับ ILB เป็นอินสแตนซ์ที่สอง
ต่อไปเราต้องปรับ ILB เพื่อเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังอินสแตนซ์ที่สองนี้ นี่คือขั้นตอนที่คุณต้องทำตาม: เพิ่มที่อยู่ IP ส่วนหน้าซึ่งเหมือนกับที่อยู่ IP ของคลัสเตอร์ SQL ที่คุณใช้สำหรับอินสแตนซ์ที่สองของ SQL Server ดังที่แสดงด้านล่าง 
ต่อไปเราจะต้องเพิ่มโพรบอื่นเนื่องจากอินสแตนซ์อาจทำงานบนเซิร์ฟเวอร์อื่น ดังที่แสดงด้านล่างฉันเพิ่มโพรบที่โพรบพอร์ต 59998 (แทนที่จะเป็น 59999 ปกติ) เราจะต้องตรวจสอบให้แน่ใจว่ากฎใหม่อ้างอิงการสอบสวนนี้ เราจะต้องจำหมายเลขพอร์ตนั้นเนื่องจากเราจะต้องอัปเดตที่อยู่ IP ที่เชื่อมโยงกับอินสแตนซ์นี้ในระหว่างขั้นตอนสุดท้ายของกระบวนการนี้ 
ตอนนี้เราจำเป็นต้องเพิ่มกฎใหม่สองข้อใน ILB เพื่อให้ปริมาณข้อมูลตรงที่กำหนดไว้สำหรับ SQL ลำดับที่ 2 นี้ แน่นอนว่าเราต้องเพิ่มกฎเพื่อเปลี่ยนเส้นทางพอร์ต TCP 1440 (พอร์ตที่ฉันใช้สำหรับอินสแตนซ์ที่มีชื่อของ SQL) แต่เนื่องจากตอนนี้เราใช้อินสแตนซ์ที่ตั้งชื่อแล้วเราจะต้องมีพอร์ตเพื่อรองรับบริการเบราว์เซอร์เซิร์ฟเวอร์ SQL พอร์ต UDP 1434 ในภาพด้านล่างแสดงกฎสำหรับบริการเซิร์ฟเวอร์เบราว์เซอร์ SQL โปรดทราบว่าที่อยู่ IP ของ Front End อ้างอิงที่อยู่ FrontendIP ใหม่ (10.0.0.201), พอร์ต UDP 1434 สำหรับทั้งพอร์ตและพอร์ตแบ็กเอนด์ ในกลุ่มคุณจะต้องระบุเซิร์ฟเวอร์สองตัวในคลัสเตอร์และในที่สุดให้แน่ใจว่าคุณเลือก Health Probe ใหม่ที่เราเพิ่งสร้างขึ้น 
ตอนนี้เราจะเพิ่มกฎสำหรับ TCP / 1440 ดังแสดงในภาพด้านล่างเพิ่มกฎใหม่สำหรับพอร์ต TCP 1440 หรือพอร์ตใด ๆ ที่ถูกล็อคไว้สำหรับอินสแตนซ์ที่มีชื่อของ SQL Server ตรวจสอบให้แน่ใจว่าได้เลือกที่อยู่ IP FrontEnd ใหม่และ Health Probe ใหม่ (59998) ตรวจสอบให้แน่ใจด้วยว่า IP แบบลอยตัว (การส่งคืนเซิร์ฟเวอร์โดยตรง) ถูกเปิดใช้งาน 
ขั้นตอนสุดท้าย
หลังจากที่มีการกำหนดค่าตัวโหลดบาลานซ์ขั้นตอนสุดท้ายคือการเรียกใช้สคริปต์ PowerShell เพื่ออัปเดตที่อยู่ IP ของคลัสเตอร์ใหม่ที่เชื่อมโยงกับอินสแตนซ์ที่ 2 ของ SQL Server สคริปต์ PowerShell นี้จำเป็นต้องเรียกใช้บนโหนดคลัสเตอร์อย่างใดอย่างหนึ่ง
# กำหนดตัวแปร
$ ClusterNetworkName =“”
# ชื่อเครือข่ายคลัสเตอร์
(ใช้ Get-ClusterNetwork บน Windows Server 2012 ขึ้นไปเพื่อค้นหาชื่อ)
$ IPResourceName =“”
# ชื่อทรัพยากรที่อยู่ IP ของอินสแตนซ์ที่สองของ SQL Server
$ ILBIP =“”
# ที่อยู่ IP ของอินสแตนซ์ที่สองของ SQL
ซึ่งควรจะเหมือนกับที่อยู่ IP ของ Frontend ใหม่เช่นกัน
Import-Module FailoverClusters
# ถ้าคุณใช้ Windows Server 2012 หรือสูงกว่า:
รับ-ClusterResource $ IPResourceName |
Set-ClusterParameter -Multiple @ {ที่อยู่ = $ ILBIP; ProbePort = 59998;
SubnetMask = "255.255.255.255"; เครือข่าย = $ ClusterNetworkName; EnableDHCP = 0}
# หากคุณใช้ Windows Server 2008 R2 ให้ใช้สิ่งนี้:
#cluster res $ IPResourceName / priv enabledhcp = 0 ที่อยู่ = $ ILBIP probeport = 59998
SubnetMask = 255.255.255.255
ตอนนี้คุณมี SQLI FC Server หลายอินสแตนซ์ที่ทำงานได้อย่างสมบูรณ์ใน Azure แจ้งให้เราทราบหากคุณมีคำถามใด ๆ ในการสร้างคลัสเตอร์ Failover Cluster Server แบบหลายอินสแตนซ์พร้อมด้วยคุณสมบัติ Azure ILB ที่สร้างขึ้นใหม่จาก Clusteringformeremortals.com
r Failover Cluster แบบหลายอินสแตนซ์ใน Azure บัญชีเก็บข้อมูลระบบคลาวด์ควรได้รับการกำหนดค่าที่เก็บข้อมูลแบบ redundant Storage ตามปกติ (LRS) [/ คำอธิบาย]