SQL Server ผูกกับที่อยู่ VPN ที่ไม่มีอยู่ตอนบูต

อ่านบรรทัดในบันทึก SQL Server เกี่ยวกับการผูกที่ล้มเหลวขณะบริการยังทำงานอยู่ แล้วคุณจะพบการพึ่งพาลำดับการบูต ไม่ใช่การแครช การรวมกันนั้นคือเบาะแส: เอนจินเริ่มทำงานก่อนที่ที่อยู่ซึ่งได้รับคำสั่งให้รับฟังจะมีอยู่บนเครื่อง อะแดปเตอร์ VPN ที่ขึ้นมาหลังลงชื่อเข้าใช้เป็นเงื่อนไขเบื้องต้นที่ไม่ดีสำหรับบริการฐานข้อมูลที่ไม่มีคนดูแล ดังนั้นไล่ตามความล้มเหลวตามลำดับที่เอนจินมองเห็น

เริ่มจากบันทึกการเริ่มระบบ ไม่ใช่จากไคลเอนต์

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

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

ปรับเส้นทางของอินสแตนซ์ให้ตรงกับการติดตั้งของคุณ และอ่านรายการอินเทอร์เฟซก่อนสรุปผล ที่อยู่ที่มีอยู่แต่เป็นของอะแดปเตอร์ผิดเป็นปัญหาที่แตกต่างจากที่อยู่ที่ยังไม่มี

ไล่ตามลำดับการผูกที่เอนจินปฏิบัติจริง

เอนจินอ่านการกำหนดค่าตัวรับฟังแล้วขอให้ระบบปฏิบัติการผูก หากที่อยู่ไม่ใช่ที่อยู่ในเครื่อง ณ ขณะนั้น การผูกสำหรับที่อยู่นั้นจะล้มเหลว ขณะที่ส่วนที่เหลือของอินสแตนซ์อาจทำงานต่อได้ตามปกติ นี่คือเหตุผลที่โปรโตคอลหรือที่อยู่อื่นยังใช้งานได้ และนี่คือเหตุผลที่ „SQL Server ล่ม“ เป็นบทสรุปที่ผิด เก็บจุดสิ้นสุดที่แน่นอนจากบันทึก: ที่อยู่ พอร์ต และโปรโตคอล เพราะการแก้ไขขึ้นอยู่กับว่าสิ่งใดในสามอย่างนี้ผิด

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

อ่านตัวรับฟังอย่างที่เอนจินอ่าน

ใน SQL Server Configuration Manager เปิดคุณสมบัติ TCP/IP ของอินสแตนซ์และสังเกตการตั้งค่า Listen All ก่อนแก้ไขที่อยู่แต่ละรายการ เมื่อ Listen All เป็น Yes ค่า Enabled ต่อที่อยู่จะถูกเพิกเฉย ดังนั้นการแก้ไขจึงไม่เปลี่ยนสิ่งที่ตัวรับฟังใช้ บันทึกสามอย่างตามลำดับ: ที่อยู่ที่คุณตั้งใจจะให้บริการ พอร์ต และตัวรับฟังควรครอบคลุมทุกที่อยู่หรือเพียงที่เดียว จากนั้นใช้การเปลี่ยนแปลงผ่านขั้นตอนการรีสตาร์ตที่รองรับและอ่านบันทึกการเริ่มระบบถัดไปเพื่อยืนยันว่าเอนจินผูกตามที่คุณขอ

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

ให้ปลายทางที่มั่นคงแก่ไคลเอนต์

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

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

หากไคลเอนต์ไปถึง 10.80.0.15 เส้นทางก็ได้รับการพิสูจน์ และฐานข้อมูลเพียงต้องอนุญาตไคลเอนต์นั้น หากไม่ถึง ให้แก้ไขการกำหนดเส้นทางและ DNS ก่อนแตะตัวรับฟังอีกครั้ง เพราะปัญหาการผูกบนเซิร์ฟเวอร์ไม่เคยเป็นเหตุผลที่ไคลเอนต์หาไม่พบ การเพิ่มที่อยู่พูลปลอมให้เซิร์ฟเวอร์ หรือเพิ่มเกตเวย์เริ่มต้นตัวที่สองเพื่อเอาใจตัวรับฟัง สร้างปัญหาเครือข่ายใหม่ทับปัญหาเก่า รักษาการกำหนดที่อยู่ของเซิร์ฟเวอร์ให้คงที่และปล่อยให้อุโมงค์นำไคลเอนต์มาหา

ตรวจสอบจุดสิ้นสุดที่ไคลเอนต์ใช้

จบด้วยการตรวจสอบระดับแอปพลิเคชันแทนการทดสอบพอร์ต เชื่อมต่อจากไคลเอนต์ด้วยบัญชีที่แอปพลิเคชันใช้และอ่านรายละเอียดการเชื่อมต่อฝั่งเซิร์ฟเวอร์ ซึ่งแสดงที่อยู่ในเครื่องที่เซสชันของคุณไปลง

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

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