การแก้ไขปัญหาการเชื่อมต่อ Azure ILB ในการเชื่อมต่อคลัสเตอร์ของ SQL Server Failover Instance

ฉันใช้เครื่องมือต่อไปนี้เพื่อช่วยฉันในการแก้ปัญหาเกี่ยวกับการเชื่อมต่ออินสแตนซ์ของ Failover Cluster Instance ของ SQL Server โดยเฉพาะประเด็นการเชื่อมต่อ Azure ILB ที่น่ารำคาญ ฉันจะพยายามปรับปรุงบทความนี้เมื่อใดก็ตามที่ฉันพบเครื่องมือใหม่

NETSTAT

เครื่องมือแรกคือการทดสอบง่ายๆเพื่อตรวจสอบว่า SQL Cluster IP กำลังฟังอยู่ที่พอร์ตที่ควรจะฟังหรือไม่ ในกรณีนี้ที่อยู่ IP ของคลัสเตอร์ SQL คือ 10.0.0.201 แต่ใช้อินสแตนซ์ที่เป็นค่าเริ่มต้นซึ่งเป็นพอร์ต 1433

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

C:  Users  dave.SIOS> netstat -na | หา "1433"
TCP 10.0.0.4:49584 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49592 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49593 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49595 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.201:1433 0.0.0.0:0 LISTENING
ที่จัดตั้งขึ้น
TCP 10.0.0.201:1433 10.0.0.4:49592 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49593 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49595 ESTABLISHED

เมื่อฉันสามารถตรวจสอบว่า SQL กำลังฟังพอร์ตที่ถูกต้องฉันใช้ PSPING เพื่อพยายามเชื่อมต่อกับพอร์ตจากระยะไกล

PSPING

PSPing เป็นส่วนหนึ่งของแพ็กเกจ PSTools ที่มีให้จาก Microsoft ฉันมักจะดาวน์โหลดเครื่องมือและใส่ PSPing โดยตรงในโฟลเดอร์ System32 ของฉันดังนั้นฉันสามารถใช้เมื่อใดก็ตามที่ฉันต้องการโดยไม่ต้องเปลี่ยนไดเรกทอรี

ตอนนี้สมมติว่าทุกอย่างถูกกำหนดค่าอย่างถูกต้องจากมุมมอง ILB, Cluster และ Firewall คุณควรสามารถ ping ที่อยู่ IP ของคลัสเตอร์ SQL และพอร์ต 1433 จากเซิร์ฟเวอร์แบบพาสซีฟ คุณจะได้รับผลลัพธ์ที่แสดงด้านล่าง …

C:  Users  dave.SIOS> psping 10.0.0.201:1433
PsPing v2.01 - PsPing - ping, latency, ยูทิลิตีการตรวจวัดแบนด์วิดท์
ลิขสิทธิ์ (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP เชื่อมต่อกับ 10.0.0.201:1433:
5 ซ้ำ (อุ่นเครื่อง 1) การทดสอบการเชื่อมต่อ:
เชื่อมต่อกับ 10.0.0.201:1433 (อุ่นเครื่อง): 6.99ms
กำลังเชื่อมต่อกับ 10.0.0.201:1433: 0.78ms
กำลังเชื่อมต่อกับ 10.0.0.201:1433: 0.96ms
กำลังเชื่อมต่อกับ 10.0.0.201:1433: 0.68ms
กำลังเชื่อมต่อกับ 10.0.0.201:1433: 0.89ms
หากไม่ได้กำหนดค่าอย่างถูกต้องคุณอาจเห็นผลลัพธ์คล้ายกับต่อไปนี้ ...
C:  Users  dave.SIOS> psping 10.0.0.201:1433
TCP เชื่อมต่อกับ 10.0.0.102:1433:
5 ซ้ำ (อุ่นเครื่อง 1) การทดสอบการเชื่อมต่อ:
กำลังเชื่อมต่อกับ 10.0.0.102:1433 (อุ่นเครื่อง): 
การดำเนินการนี้กลับคืนเนื่องจากหมดเวลาหมดอายุแล้ว
กำลังเชื่อมต่อกับ 10.0.0.102:1433 (อุ่นเครื่อง): 
การดำเนินการนี้กลับคืนเนื่องจากหมดเวลาหมดอายุแล้ว
กำลังเชื่อมต่อกับ 10.0.0.102:1433 (อุ่นเครื่อง): 
การดำเนินการนี้กลับคืนเนื่องจากหมดเวลาหมดอายุแล้ว
กำลังเชื่อมต่อกับ 10.0.0.102:1433 (อุ่นเครื่อง): 
การดำเนินการนี้กลับคืนเนื่องจากหมดเวลาหมดอายุแล้ว
กำลังเชื่อมต่อกับ 10.0.0.102:1433 (อุ่นเครื่อง): 
การดำเนินการนี้กลับคืนเนื่องจากหมดเวลาหมดอายุแล้ว

หาก PSPing เชื่อมต่อ แต่แอปพลิเคชันของคุณกำลังมีปัญหาในการเชื่อมต่ออยู่คุณอาจต้องเจาะลึกขึ้น ฉันได้เห็นโปรแกรมบางอย่างเช่น Great Plains ต้องการเชื่อมต่อกับพอร์ต 445 หากแอ็พพลิเคชันของคุณไม่สามารถเชื่อมต่อได้ แต่ PSPing จะเชื่อมต่อค่าปรับเป็น 1433 จากนั้นคุณอาจต้องติดตามเครือข่ายและดูว่าพอร์ตใดที่แอปพลิเคชันของคุณกำลังพยายามเชื่อมต่ออยู่ ขั้นตอนสุดท้ายของคุณคือเพิ่มกฎการโหลดบาลานซ์สำหรับพอร์ตเหล่านั้นด้วย

ชื่อสถานที่

วางแผนที่จะใช้อินสแตนซ์ที่มีชื่ออยู่หรือไม่? คุณต้องแน่ใจว่าคุณได้ล็อคบริการ TCP ของคุณเพื่อใช้พอร์ตแบบสแตติก ในเวลาเดียวกันคุณต้องแน่ใจด้วยว่าคุณได้เพิ่มกฎลงใน balancer โหลดของคุณเพื่อเปลี่ยนเส้นทาง UDP 1434 สำหรับบริการเบราว์เซอร์ SQL มิฉะนั้นคุณจะไม่สามารถเชื่อมต่อกับอินสแตนซ์ที่มีชื่อของคุณได้

FIREWALL

การเปิดพอร์ต TCP 1433 และ 59999 ควรครอบคลุมทุกขั้นตอนด้วยตนเองที่จำเป็น แต่เมื่อแก้ปัญหาเกี่ยวกับการเชื่อมต่อฉันมักปิดไฟร์วอลล์ Windows เพื่อกำจัดไฟร์วอลล์เป็นสาเหตุที่เป็นไปได้ของปัญหา อย่าลืม Azure ยังมีไฟร์วอลล์ที่เรียกว่า Network Security Groups ถ้าใครเปลี่ยนจากค่าดีฟอลต์ที่อาจบล็อกการเข้าชมด้วย

NAME RESOLUTION

ลองพิมพ์ชื่อคลัสเตอร์ SQL ควรแก้ไขไปยังที่อยู่ IP ของคลัสเตอร์ SQL Server แม้ว่าฉันได้เห็นมากกว่าสองสามครั้งแล้วก็ตามบันทึก DNS A ที่เกี่ยวข้องกับชื่อเครือข่ายคลัสเตอร์ของ SQL หายไปอย่างลึกลับจาก DNS หากเป็นกรณีนี้ให้อ่านชื่อ SQL Custer และที่อยู่ IP เป็นบันทึก A ใน DNS

ผู้จัดการการกำหนดคอนฟิก SQL

ใน SQL Configuration Manager คุณควรเห็นที่อยู่ IP ของคลัสเตอร์ SQL และพอร์ต 1433 หากบังเอิญคุณได้ติดตั้งอินสแตนซ์ที่มีชื่อคุณจะต้องเข้าสู่ที่นี่และล็อกพอร์ตไว้ที่พอร์ตเฉพาะและทำให้กฎการถ่วงดุลของคุณแสดงพอร์ตดังกล่าว เนื่องจากข้อ จำกัด Azure ILB ของ ILB ต่อ AG เพียงอย่างเดียวฉันจึงไม่เห็นเหตุผลที่ถูกต้องในการใช้อินสแตนซ์ที่มีชื่อ ทำให้ตัวเองง่ายขึ้นและใช้อินสแตนซ์เริ่มต้นของ SQL (ปรับปรุง: ณ ตุลาคม 2016 คุณสามารถมีที่อยู่ IP หลายต่อ ILB ดังนั้นคุณจึงสามารถมีอินสแตนซ์ SQL หลายอินสแตนซ์ในคลัสเตอร์ได้)

 

ทำซ้ำโดยได้รับอนุญาตจาก Clustering For Mere Mortals