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"

შეადარეთ ეს მისამართი თქვენს კონფიგურირებულ მსმენელს. შეუსაბამობა ნიშნავს მეორე მსმენელს ან სახელს, რომელიც სადღაც მოულოდნელად წყდება, და ორივეს ცოდნა ღირს, სანამ შემდეგი გადატვირთვა თქვენს ნაცვლად გამოსცდის თქვენს შესწორებას. შემდეგ გადატვირთეთ ჰოსტი შესული მომხმარებლის გარეშე და დაადასტურეთ, რომ მიბმა წარმატებულია. სწორედ ეს ერთი ტესტია განსხვავება გამართულ მსმენელსა და შემდეგი პაჩის ღამეს წარმატებულ დროებით გადაწყვეტას შორის.