SQL Server sitoo VPN-osoitteen, jota ei ole käynnistyksen aikana

Lue SQL Serverin lokirivi epäonnistuneesta sidonnasta palvelun vielä käydessä, niin olet löytänyt riippuvuuden käynnistysjärjestyksestä, et kaatumisen. Juuri tämä yhdistelmä on vihje: moottori käynnistyi ennen kuin osoite, jolla sen piti kuunnella, oli koneessa olemassa. Kirjautumisen jälkeen nouseva VPN-sovitin on huono edellytys valvomattomalle tietokantapalvelulle, joten seuraa vikaa siinä järjestyksessä kuin moottori sen näkee.

Aloita käynnistyslokista, älä asiakkaasta

Avaa instanssin virheloki ja lue verkon alustuksen ympäriltä olevat merkinnät, älä vain viimeistä riviä. Moottori kertoo, mitä osoitteita se yritti ja mitkä protokollat otti käyttöön, ja tuo merkintä on ajalta ennen kuin yksikään asiakas yhdisti. Katso nyt, mitä isäntäkoneessa on juuri nyt. Jos määritetyn osoitteen omistava liitäntä ilmestyy vasta, kun käyttäjä kirjautuu sisään ja käynnistää asiakkaan, osoite puuttui käynnistyksessä ja sidontavirhe on täysin selitetty.

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

Sovita instanssin polku asennukseesi ja lue liitäntäluettelo ennen johtopäätöksiä. Osoite, joka on olemassa mutta kuuluu väärälle sovittimelle, on eri ongelma kuin osoite, jota ei vielä ole.

Käy läpi sidontajärjestys, jota moottori todella noudattaa

Moottori lukee kuuntelijan kokoonpanon ja pyytää sitten käyttöjärjestelmää sitomaan. Jos osoite ei tuolloin ole paikallinen, sidonta epäonnistuu kyseisen osoitteen osalta, kun taas instanssin muu osa voi jatkaa normaalisti. Siksi muut protokollat tai muut osoitteet voivat yhä toimia, ja siksi „SQL Server on alhaalla“ on väärä yhteenveto. Säilytä lokista tarkka päätepiste: osoite, portti ja protokolla, koska korjaus riippuu siitä, mikä kolmesta on väärin.

Palvelun uudelleenkäynnistys sovittimen ilmestymisen jälkeen saa kuuntelijan yleensä onnistumaan, ja juuri se on ansa. Se todistaa riippuvuuden sen poistamisen sijaan, ja se katkaisee jokaisen yhdistetyn käyttäjän aina, kun tunneli yhdistää uudelleen.

Lue kuuntelija niin kuin moottori sen lukee

Avaa SQL Server Configuration Managerissa instanssin TCP/IP-ominaisuudet ja huomioi Listen All -asetus ennen yksittäisten osoitteiden muokkaamista. Kun Listen All on Yes, osoitekohtaiset Enabled-arvot jätetään huomiotta, joten niiden muokkaaminen ei muuta mitään, mitä kuuntelija käyttää. Kirjaa kolme asiaa järjestyksessä: osoite, jota aiot palvella, portti ja se, pitäisikö kuuntelijan kattaa kaikki osoitteet vai vain yksi. Käytä sitten muutos tuetulla uudelleenkäynnistysmenettelyllä ja lue seuraava käynnistysloki vahvistaaksesi, että moottori sitoi sen, mitä pyysit.

Kaikilla osoitteilla kuunteleminen ei ole pääsynvalvontaa. Jos laaja kuuntelija on todella tarpeen, jokainen tavoitettavissa oleva liitäntä tarvitsee oman palomuurin ja tietokannan valtuutusratkaisunsa, mukaan lukien mikä tahansa internetiin päin oleva liitäntä.

Anna asiakkaalle vakaa kohde

Asiakas ei tarvitse, että tietokannan isäntä kantaa poolin osoitetta. Reititetty ratkaisu toimii niin, että palvelin kuuntelee vakaassa yksityisessä osoitteessaan, kun VPN-yhdyskäytävä välittää asiakkaan liikenteen sille ja kuljettaa vastauksen takaisin.

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

Jos asiakas tavoittaa osoitteen 10.80.0.15, polku on todistettu ja tietokannan tarvitsee vain valtuuttaa kyseinen asiakas. Jos ei, korjaa reititys ja DNS ennen kuin kosket kuuntelijaan uudelleen, koska palvelimen sidontaongelma ei koskaan ollut syy siihen, ettei asiakas löydä sitä. Väärän poolin osoitteen lisääminen palvelimelle tai toisen oletusyhdyskäytävän lisääminen kuuntelijan miellyttämiseksi luo uuden verkko-ongelman vanhan päälle. Pidä palvelimen osoitteistus staattisena ja anna tunnelin tuoda asiakkaat sille.

Vahvista päätepiste, jota asiakas käytti

Lopeta sovellustason tarkistukseen porttitestin sijaan. Yhdistä asiakkaasta tilillä, jota sovellus käyttää, ja lue palvelinpuolen yhteyden tiedot, jotka näyttävät paikallisen osoitteen, johon istuntosi laskeutui.

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"

Vertaa tätä osoitetta määrittämääsi kuuntelijaan. Ristiriita tarkoittaa toista kuuntelijaa tai nimeä, joka ratkeaa jossain odottamattomassa paikassa, ja molemmat kannattaa tietää ennen kuin seuraava uudelleenkäynnistys testaa korjauksesi puolestasi. Käynnistä sitten isäntä uudelleen ilman sisäänkirjautunutta käyttäjää ja vahvista, että sidonta onnistuu. Juuri se yksi testi erottaa korjatun kuuntelijan väliaikaisratkaisusta, joka pettää seuraavana päivitysyönä.