Oracle-økt droppa over VPN? Sjekk keepalive-laga

Tjuefem minutt med nyttig databasearbeid gir nesten ingen utdata, og frå kvar eining på vegen ser den straumen inaktiv ut. Inaktiv tilstand er nettopp det som blir samla opp. Rapporten etterpå har alltid same form: spørjinga køyrde, så forsvann økta, og resultatet kom aldri fram.

Fire kontrollar avgjer om ei stille økt overlever, og dei går frå socketen og utover. Gjer dei i rekkefølgje, for kvar av dei gjer rekning med at laget før gjer jobben sin.

Kva straum blir stille

Sambandet som betyr noko, er det som ber databasetrafikken, identifisert av sine eigne adresser og portar. Ingenting anna fornyar det. Ein ping til ein gateway, eit anna SQL-samband frå same vert og eigen hjarteslag i tunnelen er separate straumar med separat tilstand på kvar eining som følgjer dei.

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

Socket-oversikta viser timar og køtilstand for det levande sambandet, noko som er meir informativt enn ein nåbarheitstest. sysctl-verdiane er standardverdiane i kjernen for keepalive-åtferd, og neste avsnitt forklarar kvifor dei kanskje aldri gjeld for økta di. Ein standardverdi som aldri blir utløyst, kan ikkje skiljast frå ingen standardverdi i det heile.

Skriv ned adressene, portane og grensesnittet sambandet brukar. Når ei økt døyr, er det desse detaljane som lèt deg spørje rett eining kva ho gjorde, i staden for å spørje om nettverket var oppe.

Om inaktivitetsregelen løper ut eller avgrensar

To reglar gir same symptom og krev motsette svar. Ein inaktivitets-timeout fjernar tilstand som kvalifiserande trafikk kunne ha fornya, og ein keepalive kan hindre det. Ei absolutt øktgrense fjernar straumen etter ei fast varigheit uansett aktivitet, og ingen keepalive endrar det.

Spør eigaren av kvar mellomliggjande eining kva av dei to ho implementerer. Ein brannmur, eit NAT-apparat, ein lastbalansar og ein skygateway kan alle halde tilstand, og dei treng ikkje vere samde. Den snevraste set fristen du må slå.

Den skilnaden fortel deg òg når du skal slutte å justere. Er regelen ei absolutt grense, er rett løysing ei kortare arbeidseining, ein jobb som kan takast opp att, eller eit godkjent unntak, og kontrollen nedanfor stadfestar då berre at keepalives ikkje gjorde nokon skilnad.

Socket-brytaren bak Linux-standardverdiane

Keepalive er valfritt per socket. Standardverdiane i kjernen skildrar korleis prober oppfører seg når ein socket først har aktivert mekanismen, og dei aktiverer han ikkje for eksisterande samband. Eit program som aldri ber om det, får ingen prober, uansett kva sysctl-verdiane seier.

Difor endrar det ingenting for ein databaseklient å auke tala åleine. Klientbiblioteket eller programmet må aktivere mekanismen, og der stakken tilbyr styring per samband, vinn ei avgrensa innstilling over ei endring for heile verten som påverkar urelaterte tenester.

Intervallet til første probe er heller ikkje ein spørjetimeout. Eit friskt samband er stille mellom probene, og ein død peer blir kjend att etter probeintervall og tal. Å lese dei tre verdiane som éin timeout er korleis folk endar med innstillingar som oppdagar feilen anten altfor seint eller altfor ivrig. Dei styrer oppdaginga, ikkje tolmodet til programmet.

EXPIRE_TIME er ei databaseinnstilling, ikkje ein nettverksfiks

Oracle Net tilbyr sin eigen livlegheitsmekanisme, konfigurert i den effektive profilen for prosessen og ikkje i ei vilkårleg fil som tilfeldigvis har eit liknande namn. Verdien blir uttrykt i minutt.

SQLNET.EXPIRE_TIME = 5

Hovudføremålet er serversidig oppdaging av døde samband, og på plattformer som støttar den forbetra modellen justerer han òg TCP keepalive-åtferd for desse sambanda. Det er ein nyttig eigenskap: databaselaget kan syte for prober utan å be klientprogrammet endre seg.

Dømevedien over er eit samordna val mot ein føresett frist, ikkje ei tilråding. Den dokumenterte generelle rettleiinga er eit lengre intervall, og det rette talet avheng av den installerte implementasjonen, probe-overheaden du godtek og dei faktiske fornyingsreglane på vegen. Set innstillinga i profilen som den aktuelle prosessen les, og stadfest at prosessen har teke ho opp. Oracle dokumenterer profilplasseringane og oppdagingsåtferda i sin parameterreferanse.

Test det stille intervallet, og planlegg så atthenting

Lat eit nytt tillate samband gå gjennom ein stille periode som er lengre enn fristen du prøver å slå, og følg med på livlegheitstrafikken og programresultatet. Ikkje fang nyttelastinnhald du ikkje treng; timar og sambandstilstand svarar på spørsmålet.

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

Om økta framleis forsvinn, høyrer fristen til ei eining du enno ikkje har spurt, eller regelen er ei absolutt grense. Om ho overlever, noter kva lag som vart endra, slik at neste stille operasjon ikkje gjer undersøkinga om att.

Til slutt avgjer du kva som skjer når sambandet faktisk fell, for livlegheitskontrollar reduserer frekvensen og fjernar aldri moglegheita. Fastslå det registrerte utfallet av databaseoperasjonen før du sender han på nytt: tap av svaret beviser ingenting om korvidt arbeidet vart stadfesta. For alt som må overleve at ein laptop blir lukka eller at ein tunnel startar på nytt, er ein servereigd jobb med eit varig resultat det sterkare designet, og ein keepalive er ingen planleggjar.