Oracle-sessie weggevallen over VPN? Controleer de keepalive-lagen

Vijfentwintig minuten nuttig databasewerk levert bijna geen uitvoer op, en vanaf elk apparaat op het pad ziet die stroom er inactief uit. Inactieve toestand is precies wat wordt opgeruimd. Het rapport achteraf heeft altijd dezelfde vorm: de query liep, toen verdween de sessie, en het resultaat kwam nooit aan.

Vier controles bepalen of een stille sessie overleeft, en ze lopen van de socket naar buiten. Doe ze in volgorde, want elke controle gaat ervan uit dat de vorige laag zijn werk doet.

Welke stroom wordt stil

De verbinding die ertoe doet, is degene die het databaseverkeer draagt, herkenbaar aan haar eigen adressen en poorten. Niets anders ververst haar. Een ping naar een gateway, een tweede SQL-verbinding vanaf dezelfde host en de eigen hartslag van de tunnel zijn afzonderlijke stromen met afzonderlijke toestand op elk apparaat dat ze volgt.

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

De socket-lijst toont timers en wachtrijtoestand voor de levende verbinding, wat informatiever is dan een bereikbaarheidstest. De sysctl-waarden zijn de kernel-standaarden voor keepalive-gedrag, en de volgende paragraaf legt uit waarom ze voor jouw sessie misschien nooit gelden. Een standaard die nooit afgaat, is niet te onderscheiden van helemaal geen standaard.

Schrijf de adressen, de poorten en de interface op die de verbinding gebruikt. Wanneer een sessie sterft, zijn het die details waarmee je het juiste apparaat kunt vragen wat het deed, in plaats van te vragen of het netwerk in de lucht was.

Verloopt het idle-beleid of begrenst het

Twee beleidsregels geven hetzelfde symptoom en vragen om tegengestelde reacties. Een idle-timeout verwijdert toestand die kwalificerend verkeer had kunnen verversen, en een keepalive kan dat voorkomen. Een absolute sessielimiet verwijdert de stroom na een vaste duur ongeacht activiteit, en geen enkele keepalive verandert dat.

Vraag de eigenaar van elk tussenliggend apparaat welke van de twee het implementeert. Een firewall, een NAT-apparaat, een load balancer en een cloudgateway kunnen allemaal toestand vasthouden, en ze hoeven het niet eens te zijn. De nauwste zet de deadline die je moet verslaan.

Dat onderscheid vertelt je ook wanneer je moet stoppen met afstellen. Is het beleid een absolute limiet, dan is de juiste oplossing een kortere werkeenheid, een hervatbare taak of een goedgekeurde uitzondering, en de controle hieronder bevestigt dan alleen dat keepalives niets uitmaakten.

De socket-schakelaar achter de Linux-standaarden

Keepalive is per socket optioneel. De kernel-standaarden beschrijven hoe probes zich gedragen zodra een socket het mechanisme heeft ingeschakeld, en ze schakelen het niet in voor bestaande verbindingen. Een toepassing die er nooit om vraagt, krijgt geen probes, wat de sysctl-waarden ook zeggen.

Daarom verandert het verhogen van de getallen alleen niets voor een databaseclient. De clientbibliotheek of de toepassing moet het mechanisme inschakelen, en waar de stack besturing per verbinding biedt, wint een gerichte instelling het van een wijziging voor de hele host die ongerelateerde diensten raakt.

Het interval tot de eerste probe is ook geen query-timeout. Een gezonde verbinding blijft stil tussen probes, en een dode peer wordt herkend volgens probe-interval en -aantal. Die drie waarden als een timeout lezen is hoe mensen instellingen bereiken die een storing veel te laat of veel te gretig detecteren. Ze sturen de detectie, niet het geduld van de toepassing.

EXPIRE_TIME is een database-instelling, geen netwerkoplossing

Oracle Net biedt een eigen levendigheidsmechanisme, geconfigureerd in het effectieve profiel voor het proces en niet in een willekeurig bestand dat toevallig een vergelijkbare naam heeft. De waarde wordt in minuten uitgedrukt.

SQLNET.EXPIRE_TIME = 5

Het primaire doel is serverzijdige detectie van dode verbindingen, en op platforms die het uitgebreide model ondersteunen stelt het ook het TCP keepalive-gedrag voor die verbindingen af. Dat is een nuttige eigenschap: de databaselaag kan probes regelen zonder de clienttoepassing te vragen iets te wijzigen.

De voorbeeldwaarde hierboven is een gecoördineerde keuze tegen een veronderstelde deadline, geen aanbeveling. De gedocumenteerde algemene richtlijn is een langer interval, en het juiste getal hangt af van de geïnstalleerde implementatie, de probe-overhead die je accepteert en de werkelijke verversingsregels op het pad. Zet de instelling in het profiel dat het betreffende proces leest, en bevestig dat het proces haar heeft opgepikt. Oracle documenteert de profiellocaties en het detectiegedrag in zijn parameterreferentie.

Test het stille interval en plan dan het herstel

Laat een nieuwe toegestane verbinding een stille periode doorlopen die langer is dan de deadline die je probeert te verslaan, en let op het levendigheidsverkeer en het resultaat in de toepassing. Leg geen payloadinhoud vast die je niet nodig hebt; timers en verbindingstoestand beantwoorden de vraag.

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

Verdwijnt de sessie alsnog, dan hoort de deadline bij een apparaat dat je nog niet hebt gevraagd, of is het beleid een absolute limiet. Overleeft ze, noteer dan welke laag is gewijzigd, zodat de volgende stille bewerking het onderzoek niet herhaalt.

Beslis ten slotte wat er gebeurt als de verbinding toch wegvalt, want levendigheidscontroles verlagen de frequentie en nemen de mogelijkheid nooit weg. Stel de vastgelegde uitkomst van de databasebewerking vast voordat je haar opnieuw indient: het verlies van het antwoord bewijst niets over de vraag of het werk is vastgelegd. Voor alles wat het sluiten van een laptop of een tunnelherstart moet overleven, is een door de server beheerde taak met een duurzaam resultaat het sterkere ontwerp, en een keepalive is geen scheduler.